云鹏杂记 之 小项目、大风险

云鹏杂记 之 小项目、大风险

    最近经历了一个项目，该项目是由于之前开发的一个系统部分业务发生变更而临时产生的，只需要为之前程序打少量补丁，因此开发规模很小。但就是这样一个项目，却产生了很大的风险。
    项目概况：原系统是使用JSP + Servlet开发的，本次修改涉及12个子模块，24个功能点，仅修改JSP部分。由于部分JSP页面重叠，因此实际修改页面仅14个，而代码量连注释在内则是平均每页不到20行。项目设计人员2个，其中1个是PSM，女孩；开发人员包括我在内是4个，均有该系统下开发经验，但大家同时还有其他开发任务，其中可能我的任务相对轻一些。开发时间从5月30日到6月5日，计5个工作日，期间还包括2天为周六、周日。开发之前专门就业务和编码规范作了培训，设计人员也提供了详尽的设计文档。但就是这样的安排，到了6月5日下午快下班的时候，居然还有人没有完成编码。

    项目过程：
    5月30日，编码开始。按照开发模式，我们每个人应当使用版本管理工具创建一个称之为包的东西，由项目经理审核通过后，再取得程序文件进行修改。这个过程用了我大约一上午的时间。
    6月1日，PSM发邮件，提醒大家注意程序开发过程中可能出现疏漏的地方，同时提醒两位还没有建包的开发人员尽快建包，因为没建包就意味着编码还没开始。
    6月2日、3日，开发人员加班，不过都是为了别的任务。
    6月5日上午，PSM连发两封邮件追问大家的进度，这时那两位同事才开始建包。到下午例会的时候，居然只有我按质按量地完成了任务。当时PM很生气，说：“没想到这么小的一个项目，居然产生了这么大的风险”。最后3个人晚上加班完成的任务。
    6月6日，测试按计划开始。

    一点想法：
    第一，这个项目确实很小，而且事先也做了充分准备，并给出了充裕的开发时间，但也正是因为这样，PM、PSM以及3个开发人员，谁也没有足够重视，直到开发的最后一天，才发现问题的严重性。
    第二，PSM还是年轻，没经验，不能很好地控制项目进度。至少我认为6月1日是个点，当时应该开会，而不是以邮件的形式提醒大家。这也说明，有些事情不要贪图方便而使用邮件广而告之，那样很可能没什么效果。
    第三，由于PSM对于我们来说还只是个小女孩，所以大家难免会轻视，而且大家各有重任，可谓有恃无恐。要解决这个问题，恐怕还是需要一点手腕的。
    第四，工作态度与团队精神。这个话题恐怕很难说清楚。尽管我觉得大家不应该以自己还有其他开发任务为借口，应该在完不成任务的情况下及时向公司申请支持，但从另一个角度讲，如果他们向公司申请支持，公司会如何看待他们？或许这个支持不应该是向公司申请的，而是应该向团队提出的，一个能包容缺陷的团队也应该是完美的。

    由于我来自另外一个部门，因此事后便在一个私人时间跟自己的本属领导说了这件事，并阐述了以上想法。其实我并没有幸灾乐祸的意思，倒是觉得这件事很有代表性，尤其是对那些年轻的项目经理，包括我自己而言，以后难免会遇到类似的情况，因此拿出来说一说。
    估计很多人看过我这篇文章后都会认为我说的有点道理，但同时他们也会一转头就把这篇文章忘掉。
    最后一句话：同样的问题未必不会降临到自己身上！