项目经理和开发员是两个角色，简单地说就是两顶帽子。你可以把两顶帽子都带上。

当然“分工”是社会进步的标志，挑一顶帽子“戴”到最好，总比“戴”两顶不像样子的帽子好；况且，你总有一顶更喜欢的帽子。
# 这里的所说的“开发员”是泛指，不区分架构师、测试、开发。

怎样分工呢？
# 讨论的是 PM和开发员之间的事，有的只涉及的一者的事，就略过了。
# 采用软件过程不同（偏RUP还是偏敏捷），有些动作的决策权会有浮动，本质是不会变的，让合适决策的人决策。

PM

收集、维护和传达作业条目给每个项目成员，让其知道自己的和整体的作业条目的状况，如需求（将来要做的）、功能（正在做的）、各个作业条目的进度
- 条目进度是 PM 维护和传达，判定当然不是PM的职责，PM也做不了。
- PM在这个过程中，应该弄清作业条目的依赖关系，各个条目的风险和问题。
项目资源跟进和保证
让开发员集中精力开发，不要在这个问题上分心。
招集讨论、会议
- 这是第1条的重复，其实就是传达作业条目。这里单独列出来，是因为讨论和会议，还会招集项目组以外的人，如需求方（客户）。
- 当然你可以认为需求方（客户）也是项目组成员，现状是需求方（客户）和项目成员交流并不多，也往往不坐在一起。
  什么时候要做这件事呢？
  - 惯例的时间点，如 KiffOff、需求确认讨论、里程碑时间点
  - PM 根据收集作业条目的状态决定，如条目过多，但资源不足，招集需求方作需求裁减；反之亦然，条目过少，但资源有多，招集需求方作添加实现的需求。
    注意，PM 和开发员应该在是否裁减或是添加需求实现上都是不决策的，这由需求方决定，因为他才知道各个需求的重要性。
    当然，需求方也是一个角色、帽子，作为 PM 和开发员的人也可能戴。

开发员

明确作业条目；细化分解
- 作业条目从哪里来，这个是和需求讨论的结果。
- 细化分解
  这个动作，是项目组所有的开发员一起做的，PM旁听收集。让每一个开发员和 PM 知道整个项目条目（这个PM要实时收集、维护和传达，见M1）
明确自己的作业条目，实现之
这个是费话，你不做谁来做，哈哈
给出作业条目的工时估计，认领，分配。工时估计是谁认领谁估计。
# PM 常常会忽略了这一点，拿着和工时估计毫不相干的因素干扰这个过程，比如项目想早点发布，能不能估少点？ Orz~
既然是估计，调整变化是自然的。缩短和延长都是OK的。有一点不变就是，随着推进，大家认识加深，估计变成更准确和不浮动。
# 还有什么比一个不调整的计划，能够预测未来的计划，更让人觉得匪夷所思的呢？

PS：

个人看法随便拍砖。大家可以参考《人月神话》、《规划极限编程》等等，对于项目职责划分上都有些精到的阐述。

PPS：

今天因为项目决策和安排上发生了一点争执，小小惊吓了一下项目的PM MM。
所以把这里这些自己觉得很自然的事写出来，对常识的忽略是可怕的。大家认识不一致，就更可怕了。

希望能在这方面和PM做一些交流和讨论。合作上少一些碰撞，多一些愉快。

FEATURED TAGS

生活 blog Java shell Unix/Linux unix Groovy jms mom middleware extension log4j philosophy 原则最佳实践 Shell generic gnu windows cmd tips dubbo Service 设计 class date i/o api design 服务优劣 Linux git week 日期星期计算月份命令行配置 Windows Dubbo 约定权限 Command Line 发布 java cooma release 微容器 github microcontainer 扩展点容器