另外一篇自己总结的文章:大项目设计和管理复盘 - 需求评审如何评审.
对自己:
对他人:
1.一个问题,自己先分析. 2.如果发现不是自己的原因 3.可以变成组织者(自己先定时间,这样自己才有全局性,自己才会主动过程跟进然后向别人要时间承诺,冲突就向上要资源.), 调度领导来说明情况,安排对应的同学做事.通过自己的能力做不到. 4.最终得到结论和action. 6.过程跟进,不是@了就可以了,就认为没自己事了,流程在别人那了,责任是别人背了,你是owner拿结果的那个. 别人那里并不是一个高优先级的事情,很可能遗忘掉. 不要等一个愿意主动给你结果的客户,工作伙伴. [ 数据报表导出BadCase,就是自己等着一个客户主动沟通,而不是push用户看下数据,引导用户看下数据.] 7.答应别人的事就要做到,这样才叫做靠谱.不需要别人催,push
答应别人的时间点得明确是什么阶段(自己的专业度,避免后续扯皮,产品总觉得没有沟通好就能上线了.特别是多线操作时,事前沟通没有截止时间点),把任何事情都项目化,时间轴: 1. 方案确定时间点.(了解需求和依赖方接口) 2.上线时间点
敏感性: 1. 别人不知道你的进度,事项. 你需要同步出来,信息公示 2. 感知到老板的时间耗时预期和进度,不一致,你就需要主动沟通,向上管理的核心 3.
核心总结:
1. 对自己,答应别人的事情主动完成,不要忘记
2. 对别人,管控失控,你认为重要的,别人不重要,别人不会主动给你结果, 需要想好怎么提醒对方,过程管控, 引导对方怎么做? 其实一般提醒下就ok了. 风险暴露. 很少是上升到领导层面. 我的失控例子就是 报表导出失控. 一方面没有push产品给出列表,另外一方面没有push用户下载,引导用户下载
3. 事情要会拆分,每个时期的耗时不同,这个需要经验.. 很多事情有各自的时间,例如push用户,比push同事要耗时. 有些用户时间管理比较弱,有些用户时间管理比较强.
切忌第二个环节抱怨,第四个环节丢弃. 本来是能拿闭环结果,结果拿不到好结果.
leader职责:
1.做事:
1.1 规划
规划划分. 这样才能分配落地.
找业界资料,找牛人沟通,找产品沟通.
1.2 分析
模块规划落地.
1.3 向上沟通,需求价值分析(砍需求),索要资源:
产品不一定够专业
1.4 事情跟踪:
todoList check. 做得好的表扬. 记录.每个月总结. (管理)
1.5 做好备份,每周每月审核.
1.6 一定要知道组员什么时候空出来,对产品需求有应答.晨会上. 每个人按一周四天时间安排.乘以0.2作为buffer. 作为听新的需求. 预留好听需求和产品,运维沟通的时间.
1.7 所有事情都要有头有尾,给人发邮件,一定要钉钉上告诉别人.回复才行.
2.育人:
1. 个人经验成长
2. 个人是否做得好反馈.如何能做的更好. 如何获取绩效能力成长.
3. 做好mentor机制,先自己沟通下,再找业界牛人. 自己业务领域的牛人学习下. 技术和产品.
4. 吸引新人,做好备份. 毕竟人才是要流动的.
5. 抽空学习,不仅牛人学习. 了解老大要什么..老大绩效在哪.
3. 团队氛围. 向上管理,要绩效,支持领导绩效落地:
1.人挖掘积极主动.
要合作的好,要思考老大的痛点是什么, 这件事有没有必要汇报,老大是否在意.
向下:
主动谈话 ,主动问做了什么事. 做好,培训和辅导,让其思考和询问,为什么架构这么划分,现有模块怎么拆分?
有些人,你要多关注,每天问问做了什么,有什么收获. 让人去辅导, 你要去辅导那个去辅导的人.?
2.事. 人抓好了,事肯定能落地. 不仅是上头规划的,下面也是也会主动挖掘,问题,发现难点,解决. 但是很多质上的改进,可能需要老大来识别出,比如费用模块,比如模块重拆. 比如重构怎么推进. 最上游模块,先动.
人的行事风格:
人的性格:
舒适区:
人的性格是否要改,哪些要改?
有些人想的很细,容易陷入细节. 有些人善于计划. 计划事情. 有些人天然战略,有些人天然细节.
奖罚:
沙僧是否要奖励?
考察标准
目标管理法,谷歌.
海尔管理模式，日清管理体系
谷歌周报被称为“Google Snippets” . 人: 要赞扬. 要总结. 每月总结会议,每个都要ppt产出. 事: 要跟踪,要文档.每个事情都要有负责人,即使简单也要放权. 新同学不需要当负责人. 有些人会自觉的给出产出,流程图. 有些人需要你指定目标. 2. 过程管理,新的流程: 每个项目有个负责人. 相应的wiki都是对应同学新建,leader负责督促. 同时保证各自的同学的成长,接触新的东西. 老大是技术岗,有想法. 不要提想法,跟着老大走,老大有项目,去接. 老大不是本技术岗: 把自己想法沟通下,几个想法,让老大选择一个,给方案和规划.怎么做. 3. 要有流程,owner要规范职场流程. 要做什么,不要做什么? 内部要严,确立回顾会,反省会,需求. 不一定捅到外面.让大家有紧迫感. 内部没有流程和紧迫感. 每日问题追踪和排期问题反馈. 4. 不要做压的领导,要做支持型领导,遇到问题和任务不要压,一起分析问题. 如果说没时间,一定要梳理现有什么任务,然后说引导性地让其给出时间,一起分析给出时间. 如果说有问题,一定要知道具体什么是什么,然后帮助解决,而不是只是督促,压力,引导让其给出时间. 要明确这责任田,不要陷入全辅导型,这样对方得不到成长.目的还是让辅导他出路. 5.遇到有老油条,让其在公众场合出彩. 复盘表扬或者 6.找到机会进行热备,某个模块项目太忙的时候讲讲,或者定期讲讲. 讲的方式: 实体关系,字段和业务.总结做的不好的地方: 反思,疑惑,规划,成果,询问上级需求 沟通的重点. 1. 项目晨会,信息沟通. (phoenix 外面来催) 问题 2. 上级安排任务,不明确的你主动去问 3. 你要向上级反馈,告知价值. (对账平台) 3月份做的不好的地方： 1. 规划和任务切分 — 技术债务，线上问题收集和抽象 2. 组员心理变化和沟通 — 沟通状态，听取对方状态,和相关想法，及时表扬对方，听取组员对自己的意见，改进自己。 3. 团队文档的沉淀. -方法,提高各自意识. 每个项目安排一个负责人. leader关注 4. 想法落地推进比较差. 例如技术债务,例如重构. 方法,没有进行合理规划,细化目标. 这样大家目标都不清楚. 无法落地,leader也无法推进.空头话术. 任务细化后要开会公布,团队内达成共识.先分配大块,再分配小块.总体目标时间点先确认好. 目标总是要定的,120%.只有有进度,不怕延期. 我对系统的想法想法: 每次重启都抛错,优雅重启dubbo和mq(只有close没有await); 代码架构控制系统; 事务式mq系统; 分库分表系统,具有扩容,细粒度迁移能力; redis和zk的分布式锁; mq的优雅停机;
主题: 管理沟通 内容总结: 遇到的问题: 1.组员发问其他组员在干嘛? 原因剖析: 之前觉得人员较少,晨会停止,导致组员之间信息不畅.另外一方面对各自做的其他模块或者技术工作了解不够 2.任务分配: 2.1 预订计划的人力安排和实际相作 原因剖析: 三方沟通较少(产品,leader,组员). 2.2 任务按级别分配和预期设想不太一致. 原因剖析: 自己没有主动把控,主动沟通架构设计,分享各自设计成果获取成就感. 结论和解决方案: 1. 晨会: 和xx已沟通对应工具,日会继续,5点半. 重点关注:做了什么(以其他组员能预估时间为标准), 时间投入, 疑惑 , 明日计划. 2. 周会过本周进度和下周工作时, 拉入产品大人. 3. 高级开发者任务完全分配时, 自己也主动产出文档化设计和拆解, 并一起沟通,分享设计, 增加团队仪式和成果分享.
团队目标： 1.一种是方向性的。适合中上层。 2.一种是可落地的，具体化的。对于一线leader，更要整理出这些。 1. 外部-需求方的项目，例如代驾加2期，折扣券引入 2. 内部-技术系统为了更好满足未来演变。 技术债务，单测自动化，模块重构，性能风险点排查 leader职责： 事： 1. 需求剖析：外部需求剖析，和外部需求方合理完成任务，有时候该挡则挡。 2. 任务分配： 2.1 组织团队共同需求评审，包括开发，测试 2.2 共同制定计划，根据不同交付等级确定计划，对业务和高技能者，不要越主代庖。 2.3 线上问题，日常，突发问题的分配 引导组员从时间管理和大团队意识的角度去承担 3. 规划和流程 技术债务，单测自动化，业务模块抽象和拆分能力，性能风险点排查，对问题的专项整治目标提出，新的技术理念引入，流程养成 4. 引导目标解决的计划排期—项目化 1. 面对问题，leader更多的是可能是大概的解决方向，更细化的可能需要组员去完成。 2. 强调原因，项目化 leader要沟通强调原因，将问题解决项目化，有助于目标化，有助于组员成就感的提升。 人： 1. 让成员真的接受职责 1.1 分配任务时通过时间管理和大团队理念，让组员和跨组同学能够真正承担义务 1.2 通过多次沟通，包括和跨组leader，上级领导，共同确认模块职责。 1.3 确认排期时一定要让开发者认可需求，并自己确定排期（可跟进不同交付等级辅助确定）。
3月份做的不好的地方： 1. 规划和任务切分 — 技术债务，线上问题收集和抽象 2. 组员心理变化和沟通 — 沟通状态，听取对方状态，及时表扬对方，听取组员对自己的意见，改进自己。 3. 团队文档的沉淀
将四张卡片上的做法结合自己的想法进行抽象汇总: RM短期,CS长期 上任伊始第一步RMCS 做的好的 做的不好的,作用不是那么明显的 R(Result) 空降: 1. 认真考虑重要的事情,熟悉重点业务. 2. 后续在逐步梳理了解全面的业务,接口业务背景. 了解业务和技能: 将任务分解,一起会议后会讨论方案和时间,询问式任务分配. 不了解业务和技能: 3. 工作结论,后续安排大家讨论一致后以邮件的形式广而告知,提升各自动力和时间观念. 对新人不进行任务分配和时间限制 M(morale士气) 1. 户外团建活动,放松 2. 员工遇到困难,引导其主动解决,一起沟通排查后数据,然后一起讨论解决 3. 多奖励和表扬,引导为主 4. 对上沟通,反馈最近疑惑问题和已处理方案, 得到上级反馈和更多信息 5. 召开团队会议,了解大家对当前系统的问题看法,对本身团队存在的意义讨论, 如何发扬最大价值.(小团队感觉有点虚) 6. 对团队要求的但很难主动的采用公开小罚的方式,例如单测挂了,例如会议迟到. 线上问题等重大事故等反而适合私下沟通. 7.重大问题,规则和大家讨论,特别是和老员工提前沟通,不要在大会议室宣布讨论,免得被反对. 户外团建,团队小游戏. 对老员工强制任务分配和时间限制. 盲目建立威信,靠领导出面. 自己盲目建立规矩,一定要大家共同讨论. 小团队讨论使命等宏大问题,不适合.讨论问题和怎么做好比较好. C(competence团队能力) 1. 员工遇到困难,引导其主动解决,一起沟通排查后数据,然后一起讨论解决 2. 面对冲突和不足事件时,先沟通听取意见,然后提出自己看法和建议, 让其再谈谈看法,让后续冲突减少和更愉快合作,让双方都提高. 3. 对上沟通,得到上级更多 4. 尽量做一个协调者,帮助者,支持者. 对外能汇报团队状态,允诺.对内能明确员工士气,能力,团队问题. S(system系统方法) 1. 以德服人,以能力服人,抓重点,硬骨头 2. 和员工沟通,了解员工背景和自身自信点,过往技能项目,了解员工想法(倾听引导how?), 了解其在当前系统的职责,逐渐熟悉团队能力和职责分工. 3. 在一项项任务中发现问题,整理解决问题的办法和流程
