NingG +

项目管理：团队成员角色和职责

2016-09-24

项目流程回顾

整体流程：

简要评价：

  1. 沟通：前期沟通时间少，导致开发过程，沟通成本较大；即，沟通的投入并不会凭空消失，前期不进行充分沟通，后期就需要还债（沟通债）；
  2. 折中：不做管理后台页面，通过 postman 直接调用 api，减少了前端开发工作量，但，增加了联调、测试的工作量；

有优化空间的地方：

  1. PRD 交付质量：PRD 及时更新，口头沟通，及时固定到 PRD，及时周知
  2. PRD 覆盖全面：只做 api，不做前端页面的功能，在 PRD 中也需要明确覆盖，避免后期出现争议
  3. 正视集体沟通：集体沟通能够降低整体沟通成本

Note: 因为信息敏感，删除了部分量化分析的细节。

经验积累

整体几个方面：

  1. 项目流程？流程是否必要？流程是否可以简化？流程的意义？（人世间的事情分为 3 类）
  2. 成员角色和责任：基本要求，做好职责内的工作，保证质量，如何衡量不同角色的产出质量？是否所有角色都有产出？
  3. 常见问题、常见风险点？如何降低项目风险？

思考：

  1. 明确：明确需求、明确责任、明确排期、明确基本守则
  2. 可量化：哪些可量化？哪些量化有意义？
  3. 三类事情，同等重要，花费时间上，避免刻意厚此薄彼：
    1. 沟通：需求沟通、跨团队协作沟通、确定业务主题流程以及接口人、汇总关联资料、整理焦点问题明确会议纪要
    2. 设计：业务模型设计、整体方案设计、拆解&估时
    3. 开发：具体的开发工作

1. 项目流程

项目主体流程： 参考 lucidchart

关注：

  1. 主体流程
  2. 准备工作：每个流程之前，需要的准备工作
  3. 输出产物：每个流程要求的输出产物

项目主体流程：

项目主体流程-新标签打开

Note：图片很大，请在新标签页打开

2. 成员角色和责任

整体考虑：

  1. 有质量的产出，有质量的交付；
  2. 基本原则：做好角色赋予的职责。

3. 项目排期

项目整体，可以拆为 3 个大的阶段：

  1. 需求分析、业务设计、技术方案设计
  2. 开发
  3. 测试

几个核心问题：

  1. 如何确定每个阶段分配的时间？依据是什么？
  2. 每个阶段的风险点？如何降低风险点？

几个基本原则：

  1. 排期尽可能合理：排期时，需要考虑整个团队的情况，成员构成、专业水平、磨合程度等，尽可能在排期期间，考虑到大的风险，提前安排；
  2. 合理排期的重要性：某一阶段排期不合理，会导致阶段内的延期，会给整个团队造成「项目可以延期的心理预期」，其他环节延期概率会增大；

下面是项目排期，各个阶段时间分配的思考（人月神话中给有建议，不太适用业务的当前场景）：

阶段 时间分配 占比 考虑因素 备注
需求分析、业务设计、技术方案设计 4 天以上，7 天以内 1/4 ~1/3 涵盖内容：需求沟通、需求完善、业务设计、跨团队沟通、接口人责任明确、技术准备 时间分配的说明：1.不建议少于 4 天，因为初次沟通之后，研发团队需要理解；2.不建议多余 7 天，因为时间过久，很多沟通的细节会遗忘；特别是，中间会有其他事情打断，造成遗忘的更快。Note：没有跨团队协作时，可适当缩减时间。
开发 7天以上，15 天以内 1/3 ~1/2 涵盖内容：方案设计、任务拆解、接口文档、具体开发、部署环境、资源申请 时间分配的说明：1.不建议少于 7 天，因为其涵盖方案设计、任务拆解等也会占用时间，需要为真正的手动开发，需要 5 天以上时间；2.不建议多余 15 天，因为超过 15 天的需求，会造成其他团资源的浪费，过大的项目，风险也会非线性增大，可以拆解需求优先级，分为 2 次进行开发。
测试 4 天以上，7 天以内 1/3 涵盖内容：全面覆盖功能点、清晰的 bug 描述 时间分配说明：1.若时间过短，测试团队压力过大，切入\熟悉业务需要时间；2.若时间过长，则考虑根据优先级拆解功能点，分 2 次开发；Note：测试阶段，是最终产品质量保证的最后阶段，也是关键阶段，一旦上游阶段发生延期，这个阶段还有补救可能。

上面图表格式不太清晰，补充一张截图：

几个时间分配：

  1. 沟通、设计、开发：3-3-3
  2. 设计、开发、测试：3-3-3
  3. 「测试」的时间占比，跟「开发」时间占比，要基本持平，根据具体业务需求，可适当调整

4. 通俗表述

  1. 正视：沟通，口头沟通，书面固定
    1. 沟通，不是额外成本
    2. 沟通，是必要的阶段
    3. 沟通，跟「方案设计」、「工程开发」一样，都是重要的阶段
    4. 沟通，结果要明确、清晰、固定成文档
  2. 产出质量：各个角色，相互协作，各个角色保证各自产出的质量，这样能解决 80% 的问题
  3. 明确授权：明确责任，授权一线
  4. 需求讨论时间：尽可能在周一、周二、周三，进行需求讨论，因为，讨论之后有大量的沟通理解工作要进行；如果在周四、周五讨论需求，会损失讨论效果，特别是初次需求讨论。

问题 1: 为什么需要提炼流程？

Re：本质是模型的抽象和提炼，是经验的累积，目标是：提升效率、保证质量、降低风险。

问题 2：如何评价流程的好坏？

Re：熵，越低越好。

问题 3：沟通、讨论、争论，核心是什么？

Re：获取善意，相互理解，尽量描述客观事实，从善意出发沟通，避免带着情绪讨论，看问题，看本质

参考资料

  1. 人月神话

原文地址：https://ningg.top/project-management-series-total-project-best-practice/
微信公众号 ningg, 联系我

同类文章:

微信搜索: 公众号 ningg, 联系我, 交个朋友.

京ICP备19013747号-1
Top