Golang项目管理组员管理.md
任务
概述
必要性： 所有参与者得到明确的目标，确保所有相关者都对预期结果有共同的理解，提高效率。
任务、拆分与评估:
组员的所有任务必须告知组长，由组长或老板授权下发，不然组长不承认其合规。
小组长向下面管理组员，组长一般只跟小组长沟通
所有执行的任务必须细分到可以在一个短时间周期（例如，3天内）完成。
任务的评估应当是一个团队活动（任务相关人员和组长共同评估），确保任何时间随时沟通，每周将在周会中复盘。
每到一个大型提测时，在拆分任务时预留一个处理bug的子任务并评估时间，以保证交付日期更接近真实，防止紧急任务插入过于频繁
优先级应该基于业务价值和依赖关系。高业务价值和多依赖的任务应该有较高的优先级。
优先级需要考虑不同任务间的关系，有前后有联动的应该安排好优先级，有前后依赖需要提前安排时间，尽量做到前置先做，后置后做，避免后置任务组员不好测试，最好是时间重叠，这样方便调试，而且评估工期时应该同时联系其他相关的人员，尽量多维评估工期。
任务不填开始时间和结束时间，填工时，8小时为一天，因为前期 BUG 和紧急任务都比较多，一旦插入一个则会大量调整排期的时间。
如有bug优先级高，则通知组长可以暂停已开始的任务来开始处理bug。
任务执行时必须在禅道维护状态，开始执行了就点击开始任务。
延期的任务会记录下来，放到周会时讨论。
组员的流程:
需求阶段
需求接收
从组长那里接收模块需求，描述需求背景和目标
需求分析
分析流程、功能点、技术实现方案、风险等细节
需求评审
对产品经理的需求文档持续分析
参与产品经理需求评审会议并以技术角度提出、确认问题以免流程中遗漏、冲突等问题和人力、时间等资源问题。
开发阶段
任务评估与拆分: 将模块进一步拆分为小任务，进行时间和优先级的评估。
持续沟通: 在日报会中分享进展和遇到的问题（即使已经解决的问题）。
任务执行: 根据任务优先级开始执行任务，随时向组长汇报问题。
紧急任务的处理: 根据组长的通知，调整任务的优先级或延期任务。
反馈: 在项目的关键时点或结束时，参与回顾会议。
组长的流程:
需求分解与分配: 将项目需求拆分为模块，并分配给小组。
组长审查: 汇总组员的评估，再次审核。
任务录入管理工具: 将经过审核的任务录入到禅道。
组织持续沟通: 确保组员间的沟通，并组织日报和周会，提供稳定时间给组员沟通渠道。
固定的评审时点: 周会设定评审会议，跟踪项目进度，调整任务优先级。
处理紧急任务: 在禅道中插入紧急任务，并通知受影响的组员。
持续监督任务的完整性: 对于预估时间过长的任务，与相关组员沟通拆分。
组织反馈循环: 在项目结束时，组织回顾会议。
组员任务主流程图
延期：紧急任务、技术难题、人力风险等等造成。
> 任务下发流程
1. 项目经理或大组长下发模块任务到禅道
2. 大组长会通知小组长接任务
3. 小组长接任务后进行任务分配, 由分配到的人进行任务拆分和工时评估后汇报结果给大组长
4. 大组长将上面的录入到禅道(可能会重新评估出新任务或工时不一致的情况, 所以组员开始任务时要确认工时)
5. 组员去 开始任务 完成任务 结束任务
任务拆分参考
>> 需求
构想到需求, 形成需求
需求评估
需求评审
需求开发设计文档
需求开发
开发自测
测试用例评审
风险项参考
概述
识别记录风险的目的是为了评估和规避风险，不是要追责，请大家踊跃提出风险。
需求风险
需求的频繁变更导致的工作重复。
不明确或模糊的需求。
错误或遗漏的需求。
沟通与协作风险:
团队成员间、团队与其他团队、团队与利益相关者之间的沟通障碍。
对外部团队或组织的依赖导致的沟通障碍。
技术风险
采用新技术或工具可能导致的问题。
与现有系统的集成问题。
性能、安全性和可靠性问题。
人员风险:
关键人员的离职或长期（>2天）缺席。
团队成员技能或经验不足。
时间与资源风险:
评估不准确，导致时间不足。
资源（如开发者或设备）不足或不可用。
对其他团队或外部组织的依赖导致的延迟。
质量风险:
代码或产品中的缺陷。
不足的测试或不恰当的测试策略。
缺乏合适的质量保证措施。
问题
发现问题，根据来源评估优先级，建立任务到禅道
风险管理(组长关注)
>> 识别收集风险
>> 记录分类风险
>> 设定优先级|指派处理人
>> 跟踪进度
周会
复盘项
任务评估回顾，降低延期风险，规整结算目标
变动的评估项，提高评估能力
延期任务回顾
风险项回顾
困难
大量任务同时进行，调整排期特别痛苦？作为风险汇报上去
一个需求版本的周期大概预算？ 作为风险提上去
模块需求拆分由组长和组员拆分？ 是
有依赖项的任务怎么办？ 汇报风险
培训
禅道使用培训