大话软件开发项目管理（一）

对于一个软件开发类项目的整个Schedule的估算，对很多软件项目负责人甚至是一些有经验的软件项目管理人员都是一个难题。

下面讲一个开场白故事（此故事纯属虚构，如有雷同，纯属巧合）。某一天某老板或领导（A）把软件项目开发负责人（B）以及把产品负责人（C）一起叫到办公室，欣然的说某个大客户有个需求XXX（此处省略20字），具体的需求大概是XXXXXXXX（此处省略500字），然后问A 问B，这个技术上没有什么问题吧? 技术负责人B想了一会儿，回答说这个项目技术上应该没有什么问题。老板（A）欣然，立马让产品负责人（C）做出了一个概要的产品功能设计。3天后老板（A）又把软件项目负责人（B）和产品负责人（C）叫到办公室，A拿着C的产品概要设计问B：“这个项目什么时候能做出来?一个月?三个月?半年?.....”。B犹豫了一会儿，说需要先拿着产品概要设计先看看，1天后给出评估结果，老板A欣然同意，并让尽快给个结论。软件项目负责人拿着产品的概要设计赶紧召集团队中的技术专家一起将产品概要设计从技术上细分为若干技术功能模块，然后逐一对每个技术模块进行技术难点和相应的开发工作量评估（此处省略若干讨论细节XXXXXX），然后进行工作量累加得到整个项目的工作量（以人月为单位计量），最后用评估出来的项目总工作量除以团队中有多少可用于该项目的人数得出了该项目的Schedule（开发+测试）大概需要3个月时间。第2天，B拿着项目开发Schedule评估报告到老板那儿汇报这个项目大概需要3个月时间。老板（A）一听觉得很欣然，即符合客户的时间要求又符合经验预期。赶紧召集产品、技术部门准备相关文档进行项目立项（此处项目立项过程省去1000字）。

接下来当然就是软件项目负责人赶紧组织技术人力进行相关的概要设计，代码开发，单元测试，产品测试等若干项目开发环节了（此处省略2000字）。2个半月过去了，老板A把软件项目负责人叫到办公室，说准备半个月后将产品交付给客户的相关事宜。软件项目负责人这时有些吞吐了，说这个项目可能半个月后还完成不了。老板一听，十分诧异，why? what happened?............。项目负责人只好吞吐的说：最早对某几个XX模块的实现方案少考虑了一些工作量，某几个XX模块的实现方案变了，增加了一些工作量.........现在整个团队都在日夜的加班赶进度，但是半个月后很可能这个项目还完成不了。老板A听后（老板也确实看到了整个开发部门最近加班很多），问软件项目负责人（B）那这个项目到底什么时候能完成? B咬了咬牙关，说到请再多给一个月时间吧，一个月后应该可以完成了。老板（A）看到B的态度，十分勉强的说到：那你们那边继续赶进度吧，我再和客户解释一下，只能这样了。接下来的一个月时间，开发部门更是没日没夜的加班了，软件项目负责人（B）自己也冲到一线coding了。一个月以后，老板（A）把软件负责人（B）叫到办公室，问道：这次半个月后项目总可以交付给客户了吧。B神情有些无耐的说到：XX总，很对不起，按正常情况这个项目半个月后可以完成的，但是最近技术部门人员发生一些状况：开发部门的那个技术牛人“老鸟”因为北京买房压力大，最近打算离职回老家发展；开发部门那个“小菜”因为最近和女朋友闹分手，工作也不在状态；开发部门那个“中鸟”因为另外一家公司给了现在差不多1倍的薪水打算跳槽..........最近开发部门的人力..........（此处省去500字）。老板A一听脑子都快炸了，只问了一句：那项目什么时候能搞定嘛？软件负责人有气无力的回答：我们尽快赶，大概XXX时候应该可以了.................。老板（A）............无言，只说了一句：去干吧。又一个月后，软件项目负责人（B）终于带领团队把项目干完了，非常高兴的拿着项目结果去告诉老板（A），老板（A）也感觉一丝欣慰，同时告诉软件项目负责人（B）：前几天客户对XX几个模块需求变了下，你重新按照客户的需求改了准备交给客户吧。这时，B............。

这个故事的结局无非2种，一种是项目没有客户规定的时间底线完成，项目负责人（B）被炒鱿鱼了。老板最后通过这个项目对软件项目负责人（B）评价有2点：1）技术不过硬，导致项目工作量评估不准确；2）团队管理能力差，不能保持团队人员稳定。项目负责人也是一脸委屈，解释到：1）项目前期的概要评估，我们也不能十分精确的把每个模块实现细节都能考虑到的啊；2）公司都2-3年不给大家涨工资了，北京、上海生活压力这么大，开发人员不稳定我也很难控制啊。3）这个需求还老变，项目不得不耽搁啊。故事的另外一种结局，在项目负责人（B）的带领下，最后终于完成了项目了，但是老板（A）和软件项目负责人（B）都吓出了一身冷汗，B也通过这个项目累爬下了......。

文章后续，请听下回分解。