项目与文档【3002】PJM随谈-痛彻思痛之项目管理

       说到项目管理，一路以来，都是项目Leader 或者项目经理的角色一路向前，从最早在宅急送带领大家开发系统，到进入星晨急便 核心系统的开发， 我自认为一直都在做着项目管理的工作。而且做的不错。

       进入CDC以来，接受了我自认为项目管理以来，最具挑战力的项目，支付平台的整体切换----“接入汇付天下”项目,当时说实话也没有想那么多，我是抱着做物流的心情进来的，进入之后发现这里没有我们想要做的物流建设方面的工作，此次的支付平台整体切换，真是赶鸭子上架啊，从来没有接触过支付的我，硬是顶着上了。

     之后的进程，中间也有很多的插曲，但比我预想的顺利多了，由于此项目上线后犹如一潭平静的湖水，没有荡起一纹涟漪，这个项目奇迹般的被评为乐天奖，而我本人由于带领中日双方30余人的团队，历时2个半个月，完成整个支付平台的切换，而被三哥（三木谷先生）评为了MVP奖 ，此内容将在之后由专门的页面来介绍。

      讲了这么多，这跟痛彻思痛的项目有什么关系呢？ 别急，在后面，看似一帆风顺的项目管理，有时仅仅是借助了当时的天时，地利，乃至人和，如果在当时总结了相应的经验和内容，可能就不会存在之后的这个痛彻思痛项目的发生了。

      痛彻思痛项目管理----订单操作简化专案（我们接手台湾平台的第一个项目）

       项目背景： 乐天与百度合资的乐酷天商城刚刚结束在中国市场的业务，CDC整个研发中心的主力转移到亚洲区的电商平台，第一个市场就是台湾乐天市场。 订单操作简化专案是我们接手台湾市场开发的第一个项目。此项目是对订单操作的整体优化，从订单状态， 订单页面操作，操作控制，合并显示等来优化店铺对订单的操作，从而有效提高店铺处理订单的效率。

     这是2012年的项目，已经过去两年都了，一些内容拿出，纯供学习分享之用。

1.0版项目排期

项目排期（原排期）：
mailstone(2012)
- [04/05 - 04/18] MRD(Zhang Jie) 100%
     |- [04/05 - 04/13] MRD [The Order list part]
     |- [04/16 - 04/18] MRD  [The Order detail part]
- [04/13 - 04/21] Requirement Definition (Zhou minrong)
     |- [04/05 - 04/13] [The Order list part]
     |- [04/19 - 04/21] [The Order detail part]   
- [04/23 - 05/19] Requirement Definition and Development(All)
     |- The Order list part and RpassToRb batch (hu ming xu youbo hu xiaoming)
     |- The Order detail part and common(xu feng zhang liguo qiu jiaojiao li jian)
     |- [05/15 - 05/16]Code review
- [04/23 - 04/28] ■ Dir Make html  
     |- [04/23 - 04/23]The UI specification (zhang jie  liu xinyu)
     |- [04/24 - 04/28]The html page complete(nabeshima-san,someya-san)
- [05/19 - 05/26] STG  
     |- [05/19 - 05/23]Test (Development) 
     |- [05/24 - 05/26]Test (PM)(zhang jie)
- [05/28 - 05/30] ■ QA  (someya-san,川畠 佑幾)
- [06/01 - 06/05] ■ Appscan
     |- [06/01 - 06/01]Appscan (1st)
     |- [06/05 - 06/04]Appscan (2st)
- [06/05 - 06/08] ■ Security Test
     |- [06/05 - 06/05]Security Test (1st)
     |- [06/07 - 06/07]Security Test (2st
- [06/05 - 06/21] ■ Release
     |- [06/05 - 06/09]Tasklist 
     |- [06/11 - 06/12]tasklist review
     |- [06/12 - 06/12]Release Judgement
     |- [06/12 - 06/16]Operate menu
     |- [06/18 - 06/19]Operate menu review
     |- [06/20 - 06/20]Release   

    

从这个排期上，大家能看出什么问题吗？

后来再来看这个排期的时候，发现问题还真是不少哦

1.  PDM角色和 PJM角色职能不清晰，而导致排期上出现MRD编写和Requirement Definition两项雷同的工作和排期

     历史原因： Requirement Definition的编写，是以前日本叫做Productor的岗位来编写，而这个岗位的职能当时既是项目管理者，也是产品管理者，Requirement Definition文档实际上就是MRD。

2.  开发同学做的 Requirement Definition and Development 这项工作，实际上是设计与开发工作，设计，开发及Uint test等内部排期看不出来， 设计应该有设计Review, 开发有Code review.  只有每一个阶段都确定完毕，才能进入下一个阶段。

3. 没有DEV环境的测试，直接进入STG(结合测试)，并且结合测试的时间没有根据设计和开发时间来评估。

   按照经典理论，软件工程的计划阶段应占2-3%的时间，分析阶段占10-15%的时间，设计阶段占20-25%的时间，开发阶段占15-20%的时间，测试阶段占30-40%的时间。

  如果按照经典理论来说，测试时间应该在开发时间的2倍左右，而当时STG和QA测试时间总共只有开发时间的三分之二，从后来的实践证明，测试时间是严重不足。

接下来我们进入 Requirement Definition阶段，此阶段由我这边来给讲解根据MRD来写出的Requirement Definition，后来想想，这就是MRD哦，只是更细化的MRD，马上本来应该由产品同学来讲解的MRD文档，就成了我（PJM）来讲解了，无形中在PDM和开发人员之间又增加了一个沟通层级。

好吧，不管怎么样，走到了开发，这个时候，致命的问题出现了～～～～～

1. 在不熟悉的代码上做改修，没有做深入的调研和实现方案的评估

    此次项目改修范围之大，在我们前期做工时预估的时候并没有体现出来，大家看到的是类似于三个页面内容合并为一个页面显示这样的需求，而当时我们刚刚接手台湾系统，对台湾整体平台代码并不熟悉，在不熟悉的代码上进行改修，改修难度，改修动到的范围，改修方案前期都没有做深入的调研和评估，预估出的工时在项目进行到二分之一的时候，发现剩下的工作量在剩下的排期中是肯定不能完成的！

    My god. 项目已经在日本正式立项，并进入开发阶段，这个时候发现排期不够，牵扯到一系列的改动和审批。开发经理，开发经理，在哪，我们要赶快评估未完成的开发内容，到底还需要多少人日？

    开发经理开始评估了，还是哪句话，虽然已经做到了一半的改修，但是刚接手的代码，未知的部分还有太多，开发经理此时也只能凭借做到的部分的难度系统来给出一个大体的评估，并且纠结于如果要调整排期，要给出一系列的调整理由，开发经理评估出的日期，大概还需要增加一周左右的时间，这样，这样～最终大家一致决定------ 加班吧，以辛苦换时间！

     周六日没有了，晚上8点走，没有了，我们琦躯在办公室的横窝里，期盼着项目的Schedule能拉入正常，这个时候，我们觉得有必要进行项目进度例会。每天的项目进度例会，十几个人，汇报每个人进度，眉头，眉头，眉头，紧缩的眉头，第二个致命的问题出现了

2. 在设计和开发（Requirement Definition and Development）阶段，没有做正规的设计Review,即没有一个设计Review的评审，就进入到开发阶段，到了开发阶段，发现在设计阶段没有做整体设计到导致多位开发同学各自做各自的页面，在整合在一起时候，命名空间的冲突，控件的冲突，一个同样的功能在三个页面进行了各自的编写，等等。

   My God, 一个字，乱！ 大家从一开始就没有统一的思路，设计方案的制定，设计内容的分工等等，都没有进行统一的会议讨论和告知。这个时候，我意识到，作为PJM. 我太依赖于开发经理的安排，而没有对开发经理的工作进行监督和促进，相当然的以为开发经理把这些事情都做了，这个时候回想我之前的项目，为什么同样的推进，没有出现类似的问题，是的，之前的开发经理都是在乐天做过4年以上开发，带过N个项目，并且熟知自己负责的服务和代码。这就是我之前说的人和，人到位了，确实项目管理者不用费什么功夫，项目一样正常推进。我在沾占自喜一个接一个项目成功上线，而已经忽略了项目管理本身要掌控的内容，流程而不仅仅是某个人。

调整排期吧，这已经不是通过加班可以完成的任务了，大家也累了。

排期调整了，费用追加了，每个人的工作详细到每一个“用户故事”（当时还不是敏捷开发）。

根據大家的開發進度，已將【RB Order Operation Simplification】項目的排期重新調整完畢
項目開發延長了9個工作日；
STG 測試延長了5個工作日；
QA延長了3個工作日；
整體看來，上線日期由6月20日延至7月16日。
以下是【RB Order Operation Simplification】項目的最新排期：
-------------------------------------------------------------------------------------------------------------------
     mailstone(2012)
- [04/05 - 04/18] MRD(Zhang Jie) 100%
     |- [04/05 - 04/13] MRD [The Order list part]
     |- [04/16 - 04/18] MRD  [The Order detail part]
- [04/13 - 04/21] Requirement Definition (Zhou minrong)
     |- [04/05 - 04/13] [The Order list part]
     |- [04/19 - 04/21] [The Order detail part]   
- [04/23 - 04/28] Code investigation stage (All)
     |- The Order list part and RpassToRb batch (hu ming xu youbo hu xiaoming)
     |- The Order detail part and common(xu feng zhang liguo qiu jiaojiao li jian)
- [05/02 - 05/31] Development & Unit test (All)
     |- The Order list part and RpassToRb batch (hu ming xu youbo hu xiaoming chang wenyu bai yalu)
     |- The Order detail part and common(xu feng zhang liguo qiu jiaojiao li jian)
- [05/30 - 05/31] Code review (All)
- [06/01 - 06/15] STG  
     |- [06/04 - 06/09]Test (Development) 
     |- [06/11 - 06/15]Test (PM)(zhang jie)
- [06/18 - 06/25] ■ QA (someya-san,川畠 佑幾)
- [06/26 - 06/28] ■ Appscan
     |- [06/26 - 06/26]Appscan (1st)
     |- [06/28 - 06/28]Appscan (2nd)
- [06/29 - 07/02] ■ Security Test
     |- [06/29 - 06/29]Security Test (1st)
     |- [07/02 - 07/02]Security Test (2nd)
- [07/03 - 07/16] ■ Release
     |- [07/03 - 07/04]Tasklist 
     |- [07/05 - 07/05]tasklist review
     |- [07/06 - 07/06]Release Judgement
     |- [07/09 - 07/11]Operate menu
     |- [07/12 - 07/12]Operate menu review
     |- [07/16 - 07/16]Release  
------------------------------------------------------------------------------------------------------
具體的排期如下：


Tab标签查询，及所有结果展示 huming
|- [05/07-05/08]调整DIR画面样式
|- [05/09]画面也签联动js
|- [05/10]画面刷新后保存页签状态
|- [05/14]订单搜索
|- [05/15]金额未确定
|- [05/16]未发号/授权
|- [05/17]0元请款
|- [05/18]代付款
|- [05/21]付款过期
|- [05/22]未预约
|- [05/23]预约中
|- [05/24]预约结果
|- [05/25]配送中
|- [05/28]配送失败
|- [05/29]其他配送
|- [05/30]付款方式/配送方式动态连调
|- [05/31]修改分页tag


所有操作 xuyoubo
|- [05/07-05/08]重新预约集货日
|- [05/09-05/10]重新预约出货
|- [05/11-05/14]预约出货
|- [05/15-05/16]列印DC出货条码
|- [05/17-05/18]列印托运单
|- [05/21-05/22]预约集货
|- [05/23-05/24]更改配送状态
|- [05/25]修改订单状态
|- [05/25]发送受理邮件
|- [05/28]设定会员状态
|- [05/28]汇出订单列表
|- [05/29]汇出订购清单
|- [05/29]取消订单
|- [05/30]撤销取消订单


所有批处理 changwenyu
|- [05/14]生成ATM轉入帳號
|- [05/15]申請Ibon繳費代碼
|- [05/16]授權
|- [05/17]請款
|- [05/18]確認0元請款
|- [05/21]預約DC出貨日
|- [05/21]重新預約DC出貨日
|- [05/22]列印DC出貨條碼
|- [05/23]預約集貨日
|- [05/23]重新預約集貨日
|- [05/24]更改配送狀態
|- [05/25]匯出訂單列表/匯出訂購清單
|- [05/28]匯出揀貨清單/發送受理聯絡信
|- [05/29]修改訂單狀態
|- [05/30]設定會員狀態
|- [05/31]取消訂單/撤回取消


订单详细页面
详细页面操作 xufeng 
[05/11-05/11]零元请款 取消零元请款  
[05/12-05/14]ATM帐号取消与申请  
[05/15-05/15]Ibon 帐号取消与申请  
[05/16-05/17]信用卡 授权 请款 取消授权 取消请款  
[05/18-05/20]取消 撤销取消订单 


同期batch

[05/21-05/21]rpass2rborder-all-tw/rpass2rborder-atm  
[05/22-05/22]rpass2rborder-all-tw/rpass2rborder-credit 
[05/23-05/23]rpass2rborder-all-tw/rpass2rborder-e3g 
[05/24-05/24]rpass2rborder-all-tw/rpass2rborder-ibon 
[05/25-05/25]rpass2rborder-all-tw/rpass2rborder-scheduler 
[05/26-05/26]rpass2rborder-all-tw/rpass2rborder-tcat 
[05/27-05/28]batch历史数据整理  
[05/29-05/30]内部联调


付款信息部分 Zhang,liguo
[05/11-05/14]   订单详细整个页面数据的展示   
[05/15-05/16]   后台模型合并
[05/17-05/18]   根据新模型，增加新的业务逻辑
[05/21-05/22]   更改订单状态功能实现
[05/22-05/23]   页面上各按钮，链接根据权限状态来显示
[05/24-05/26]   付款信息页签功能实现
[05/28-05-28]   原始订单的数据展示
[05/29-05-29]   与订购人编辑联调
[05/30-05-30]   与配送管理联调
[05/31-05-31]   与商品展示联调


订单信息部分 li,jian
[05/11] 编辑订单商品页面展示
[05/14-05/17] 编辑订单商品js动作
[05/18-05/23] 编辑订单详情后台调试
[05/24]新增订单商品页面及js
[05/25-05/28]  修改备注前后台及国际化


配送信息部分 qiujiaojiao
[05/11-05/29]

这次的调整，终于让我们的开发工作又进入到正轨. 

从以上的调整中，大家也可以看到，对开发人员的人员分配也进行了调整，在当时，新招入的同学负责了一部分模块，但经过这一段时间的磨合，充分发现有些同学在团队合作性上真是让人头疼，不工作，不配合，嫌活多，负面情绪，My god, 这是谁把他招进来的，这是让开发经理头疼的事情，也是让PJM头特的事情。在没有替补同学的情况下，只能给他分配较少的工作量，别的同学相对承担多一点，以保证整个排期正常推进，当然，大家都懂的，以后的项目开发中，还有哪个开发或项目经理会安排他呢？

在这个过程中，我们迫于业务的压力，发现一些从需求源头上的问题，最好拆分成两个阶段来上线，让业务线使用上一些功能。这个时候在内部进行了一次根据发布时间拆分，此部分在前期其实也没有做好，这类是归为产品规划部分考虑的事情，分几个阶段，每期上哪些功能。在这里先不多说了，此次调整如下：

台湾订单优化专案，上周五（5月11日）报送了最新排期
本周一，考虑到以下三方面因素，又做了一些最新调整
1、订单一览TAB标签页 与 MAIN MENU上的管理订单，作为一个整体效果，一起调整。
2、订单一览的TAB标签搜索，在实现上，对性能部分还存在一些风险，还需要时间做性能评估。
3、整体开发时间，调整到7月中旬，对业务使用，会有一定影响，故让一部分功能业务先行使用。


基于以上三个原因，将订单优化专案拆分为两个阶段
第一阶段(phase 1)：除订单一览TAB标签及相应批处理之外的所有功能
第二阶段(phase 2)：订单一览TAB标签及相应批处理，及MAIN MENU调整


第一阶段最新排期如下
1、项目开发时间，从延长9个工作日，调整为延长5个工作日
2、STG时间，从10个工作日，调整为8个工作日
3、QA时间，从6个工作日，调整为5个工作日
4、发布准备工作与QA阶段同步进行


mailstone(2012)（phase 1最新排期）
- [04/05 - 04/18] MRD(Zhang Jie) 100%
     |- [04/05 - 04/13] MRD [The Order list part]
     |- [04/16 - 04/18] MRD  [The Order detail part]
- [04/13 - 04/21] Requirement Definition (Zhou minrong)
     |- [04/05 - 04/13] [The Order list part]
     |- [04/19 - 04/21] [The Order detail part]   
- [04/23 - 04/28] Code investigation stage (All)
     |- The Order list part and RpassToRb batch (hu ming xu youbo hu xiaoming)
     |- The Order detail part and common(xu feng zhang liguo qiu jiaojiao li jian)
- [05/02 - 05/25] Development & Unit test (All)
     |- The Order list part and RpassToRb batch (hu ming xu youbo hu xiaoming chang wenyu bai yalu)
     |- The Order detail part and common(xu feng zhang liguo qiu jiaojiao li jian)
- [05/28 - 05/28] Code review (All)
- [05/29 - 06/07] STG  
     |- [05/29 - 06/01]Test (Development) 
     |- [06/04 - 06/07]Test (PM)(zhang jie)
- [06/08 - 06/14] ■ QA (someya-san,川畠 佑幾)
- [06/15 - 06/18] ■ Appscan
     |- [06/15 - 06/15]Appscan (1st)
     |- [06/18 - 06/18]Appscan (2nd)
- [06/19 - 06/21] ■ Security Test
     |- [06/19 - 06/19]Security Test (1st)
     |- [06/21 - 06/21]Security Test (2nd)
- [06/08 - 06/28] ■ Release
     |- [06/08 - 06/15]Tasklist & Operate menu 
     |- [06/16 - 06/16]tasklist review & Operate menu review (1st)
     |- [06/17 - 06/18]update for Tasklist & Operate menu 
     |- [06/21 - 06/21]tasklist review & Operate menu review (2nd)
     |- [06/22 - 06/22]Release Judgement
     |- [06/28 - 06/28]Release


第二阶段(phase 2)，初定为
- [06/15 - 06/29] Development & Unit test (hu ming xu youbo chang Wenyu  bai yalu)
     |- main menu part
     |- The Order list tab part
- [07/02 - 07/05] STG  
     |- [07/02 - 07/03]Test (Development) 
     |- [07/04 - 07/05]Test (PM)(zhang jie)
- [07/06 - 07/06] ■ QA (someya-san,川畠 佑幾)
- [07/09 - 07/16] ■ Release
     |- [07/09 - 07/10]Tasklist & Operate menu 
     |- [07/11- 07/11]tasklist review & Operate menu review
     |- [07/12- 07/12]Release Judgement
     |- [07/16 - 07/16]Release

在调整完排期后，我们的开发工作终于要接近尾声了，我们进入了最艰难的阶段，QA测试期

我们的QA是请的第三方的测试公司，是专业的测试团队，并且已经负责台湾乐天市场的N次工作，他们在接受到此次的MRD后，测试负责同学给我吐了一句话： 你们这是要把整个订单平台重做啊。 我的苦水啊，要是重做到好了，全新开发，偶们是在既有代码上进行改修，在不熟悉代码的情况下，现在只想用一句话描述，雷啊，到处都是雷啊

开发结束时，有一个评估，就是能否进入QA阶段，QA阶段花费不少，如果不能进入QA要提前一周提出申请。工程师将直观的理解编写的CASE测试了一遍，发现问题好像不多。就这样，进入了QA阶段。 114种物流及配送状态，QA发送过来的case 达4000过个之多，我看得眼睛都花了，4000多个CASE，完全是PDM和我这个PJM两个人来回复（一周的时间），QA提了一大堆的业务，产品，包括数据做成方面的问题，我们就在应对这些内容。现在用了敏捷开发，自己又做了产品经理之后，回想到这个项目，我就特别想笑，如果现在用“用户故事”来体现，这个项目大概相当于有100个用户故事，哈哈哈哈，这个排期的差异有多少，我们不泪奔谁泪奔？！

连轴转的感觉有了，进入QA之后，问题犹如洪水般袭来，我和产品妹妹（我们的产品经理）都感概，怎么就不再猛烈点呢，我们就完全可以不回家了。苦笑ing～～～

每天QA会新增100-200个问题，这是什么概念，QA那边是5还是6个同学，拼命的发票，我们这边同学是拼命的回票， 晚上11点，12点， 1点，2点，好吧，支不住了，还有30票没关闭，明天来了再看 

QA结束了，偶哭了，QA报告再直白不过了，不推荐上线.

基于这样的结果，台湾市场实在是太迫切想要使用这个新能功能了，此时，是上线还是不上线，我们是即纠结又渴望。改，继续改BUG，把QA发现的问题全都改掉！

在QA之后，我们又启动了自测，就是在之后的阶段，做安全测试期间，我们同时安排相应同学的回归测试，总结测到我们自己有些放心了。

项目发布了，超出预期的反响好，过程是痛苦的，结果是欣慰的，一路走来，有种脱层皮的感觉。

痛彻思痛，这个项目到底带给了我们什么样的惨痛的教训，待我细细反思过来~~~~

1. 项目流程的标准化

     还有什么内容能比这个映像更深刻的。记的有一本书叫《用流程解放管理者》，惭愧啊，买了一直没看。经过这次之后，明确确认角色职能并建立了研发团队标准项目开发流程， 在需求，调研，立项，设计，开发，测试，发布各环节，哪个角色做哪些Check, 责任到人。 这部分当然是各个角色共同商定的流程，专门有一页叫做《瀑布式开发的项目管理流程》，很详细的说到了这部分，有感兴趣的同学可以查看。 最重要的，就是在团队内进行推广，深入到每一个同学心中。

    

2. 项目的工时预估

    处于交接中的代码的基础上如何做工时预估?

    这真的是一个课题,  本身所有的开发同学还处于接手台湾平台的交接期,而这个时候又要在不熟悉代码的基础上,进行新需求的工时预估. 实践证明这个项目最终结束的时候, 实际花费的工时是预估工时的2.5倍. 当然这里面有本身MRD需求量过大, 对代码不熟悉,所以对改修范围不确定,  前期没有进行深入改修方案调研等等，问题是如果再遇到类似的问题，要怎么来相对准确的给出评估呢？

    记得曾经参加SCM课程的时候，就这个问题问过当时的老师，老师给出的建议是采用实验性的方式来推进，意思就是说先拿出一部分功能，大概控制在一周的工作量，进行实际开发，根据实际工作开发和预估开发的差值，大体判断出难度系数或者着Buffer在多少，进行2-3个周期，就能得到一个差异范围，那么在对其他部分的预估时，加入相应的差异Buffer。这是一个方法。

   那还有没有其他的方法呢？ 给出更长的方案调研时间，之后的一个项目是这样做的，就是为了更准确的预估工时，基本上由经验丰富的工程师快速将代码通看一遍（当时是给了1周），工程师内部快速讲解重点代码部分，讨论给出改修方案和改修工时，由于这个基本上是由经验丰富的工程师做主导给出工时，所以如果是分配给其他同学，初中级工程师开发的话，相应部分的工时×1.5倍。

  刚才也说到了，流程的标准化之后，其实就相应有了工时预估的标准化，各个阶段的工时出来后，再做各阶段工时比例的确认，以保证更准确的预估。

3. 项目管理者在必要时候要果断喊停

    1）对工时/排期压缩要喊停！

       如上面所说，工时出来了，排期也就相应的出来了，如果需求方或者管理者砍工时，坚决喊停！对应的时间我们有对应的输出，砍工时，OK，好吧，那我们就对应的砍一些需求，放下期再上。此部分由项目经理严格把控。

      

    2）对进度偏差要及时喊停！

     回顾整个项目，在几次开发进度预估到有风险的时候，都在期望着大家挺一挺将排期拉入回正轨，而从客观角度分析，如果进度偏离10% 黄色警报，还可以拉一拉，如果偏离15%-20%，那就是红色警报，如果偏离20%以上，偶个人认为必须叫停或重新调整排期！

     3）对阶段check有问题，要及时喊停！

      设计Review，Code review, 单体测试，结合测试， 哪一个阶段，没有通过，坚决喊停！ 此部分由开发经理严格把控，项目经理密切跟进，check每一个阶段的票是否全部关闭。

     

 4. 完善和熟知合作方流程

   比如QA测试流程，在我们得知测试CASE有4000个的时候，离开始测试时间只有1周的时间了，在预估到此次改修量大的情况下，没有主动提出要预知Case, 比如提前了解对方Schedule的安排，希望提前分批次发送CASE等调整等。

5. 最后就是项目成员