目录
第一部分 序
目标
第二部分 团队建议
一 小组划分
第三部分 小组计划
一 小组任务管理
二 小组工作氛围
1 组员能力成长
3 组员幸福感提升
三 小组工作协同
四 小组建设规划
第四部分 2021目标和计划
附件
平台研发部计划按岗位划分成立4个小组:产品设计组、前端研发组、后端研发组、测试支持组,4个小组分别设立组长(主管),组长需在本周提出小组管理思路,要求如下:
思路
产品设计组、前端研发组、后端研发组、测试支持组,4个小组分别设立组长(主管)归属于部门直管。
按照职能部门划分团队适用于团队规模小,团队技术力量薄弱,需要提高团队或部门凝聚力和某些任务战斗力。
按照业务线划分团队适用于团队规模较大,团队技术实力强或者可以快速建设起来,需要在业务线深耕并且有高质量交付验收要求的或者业务是其生命线的情况。
业务线/职能部门架构图
根据月/季度规划任务列表,按照敏捷开发模式快速迭代。
首先,任务拆分
任务拆分遵循smart原则(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound)是为了利于员工更加明确高效地工作,更是为了管理者将来对员工实施绩效考核提供了考核目标和考核标准,使考核更加科学化、规范化,更能保证考核的公正、公开与公平。下边简单介绍smart原则具体内容:
所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可,或没有将目标有效的传达给相关成员。
衡量性就是指目标应该是明确的,而不是模糊的。应该有一组明确的数据,作为衡量是否达成目标的依据。如果制定的目标没有办法衡量,就无法判断这个目标是否实现。
目标是要能够被执行人所接受的,如果上司利用一些行政手段,利用权力性的影响力一厢情愿地把自己所制定的目标强压给下属,下属典型的反映是一种心理和行为上的抗拒:我可以接受,但是否完成这个目标,有没有最终的把握,这个可不好说。
目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标,但对其他的目标完全不相关,或者相关度很低,那这个目标即使被达到了,意义也不是很大。
目标特性的时限性就是指目标是有时间限制的。
其次,任务顺序合理
任务前置依赖和后置顺序逻辑遵循连贯性,持续性,可迭代。
最后,任务粒度大小适中
任务可根据月/季度任务列表中选取优先级最高的任务进行里程碑规划,原子任务等,原子任务建议3-5天;里程碑任务建议2-4周。
从产品PRD评审,预计工期,预计交付约束,质量等;到UI设计稿交付;然后架构设计,任务拆分,详细设计,开发交付代码,自测,CODEREVIEW审核,集成测试,联调测试,版本合并,部署,提测等;再然后到测试,测试报告,产品人员验收和交付。任何一个环节跟踪,预警,危机处理机制等均会对产品整体质量,交付工期有不可估量的影响。
总体分三大环节跟踪管理:
首先,交付件包括业务/产品PRD,原型,任务功能清单,UI设计搞,切图,样式等。
其次,需求或者已审需求变更大必须评审。
然后,评审参与人员研发负责人和测试负责人必须参与达成一致,最好参与研发和测试工程是,UI设计师也参与评审。
最好,经过反复评审的需求通过后,方可交予UI设计师,研发和测试方。
首先,接收到产品和UI交付件后,快速沟通和考虑产品设计逻辑,预计质量,条件约束,预计工期和研发实力和现状匹配程度等,一般情况是没啥问题的。
然后,进行架构设计,设计评审,任务拆分和讨论,详细设计和评审,这个过程必须有研发设计评审,架构师参与评审来保证降低返工次数和返工。
最后,进入开发阶段,开发完成,自测,代码走查或者评审(评审前开发责任人必须通过工具走查完成),开始集成,联调,联调完成后,发起提测,测试冒烟测试,功能测试,性能测试,总结测试报告,交予产品验收。
在研发工作开展和持续过程中技术经理或者架构师需要把握和推动研发进度顺利进行,预测技术难点,开发工作量大小,同时保障风险预警,风险升级,风险处理渠道畅通无阻。
验收,和交付主要有产品方完成。
以激励为主,对应配备惩戒机制辅助。
激励任务完成数量多,并且质量高的员工;惩戒任务完成数量少,并且bug多的员工。
奖励团队协同获得要求方好评,并且工作方式匹配多高,效率高,太多好的员工。
主要任务分配因人而异,指导和协助,激励和惩戒因时因人而异,针对不同组员分配具有不同挑战的任务;在不同时间段分配技术难度和工作量大小不同,给予指导和帮助不同;对任务执行结果和质量好坏给予不同激励和惩戒。
引导和协助员工自己职业计划和工作任务统一匹配,帮助员工达成任务预计目标,让员工自己从中感受到成就感。
月/季度一次团队聚餐,逐渐固化团队之间工作,业务,技术,沟通交流机制,以一方为主导负责,另一方积极响应配合,避免临界地带出现和扩散。
扩大员工福利范围和已有福利分量(根据实际情况而定)
晚上加班10点后,企业微信打车回家;简化晚上加班晚餐报销流程,或者统一报销。
以业务线,产品和职能两个维度划分和建设团队;一实一虚建立起小组员工,组长,部门之间对应的底层网络,中层组长和顶层部门的立体的协同的金字塔结构。
首先,任务组员负责制,如果出现停止,延期,质量预警,需由组员发起预警告知直接组长,组长保证预警和预警上升通道顺畅。
然后,任务之间有依赖关系的,并且发生预警,需由任务责任人推动和跟进保证任务预警上升通道畅通。
最后,任务依赖关系各自责任方必须保证阻塞任务及时解决并且跟进。
2021年第一季度
2021年第二季度
1 增补后端工程师数量不足的现状
2 考虑团队建设经费预算(可以考虑组内筹集)
3 需要部门根据后端人员数量现状考虑团队支撑业务线任务量的大小,并且保证在合理区间内。
序号 |
团队稳定性 |
团队技术实力 |
业务支撑能力 |
协同能力 |
1 |
激励员工,积极参与任务,并且从中获取成就感 |
共同配合,适当迎接有些小挑战的任务 |
支持顺利完成基本业务规划 |
协助部门达成基本目标 |
2 |
安排团队聚餐和娱乐健身活动 |
培养团队向心力和鼓励支持创造其参与业界业务技术论坛会机会 |
指导帮助员工完成有挑战的任务 |
对跨部门协同工作,激励员工积极参与和主动配合完成 |
3 |
考虑和指定奖励机制,营造奖励仪式感。 考虑和保证优秀员工职级晋升渠道畅通和按时晋升甚至提前晋升。 |
激发和安排业务,技术分享 培养和组建组内最小核心员工,普通员工梯队 |
引导激发员工主动去承担业务支撑研发工作。并且项目完工后积极复盘,发现盲区,亡羊补牢,提升员工认知。 |
引导和创造协同完成后总结和复盘。发现不足和总结经验。 |
1 PRD:描述产品需求的文档
2 CODEREVIEW:检查代码中是否存在代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求(功能、性能)等等。