项目日志1－前期计划沟通篇

        最近在公司内带一个还算较大的项目，目前正处于项目的计划和文档编写阶段，因为之前都是作为项目组的成员来参加项目，这次是完全自己负责整个项目，所以有一些特别的感想

        1.需要全面了解整个团队的水平

            相信每个团队都一样，有比较资深的老家伙，技术资历比较深，也有些刚毕业不久的实习生，工作1－2年的小生，这次项目里一开始没有事先过多考虑到这个问题，虽然在工作量分配时作了一些倾斜－－如比较核心的功能模块还是分配给老人，但是现在感觉下来还是感觉对某几个新人的工作有些便多，导致这两天他们在加班搞,感觉有些过意不去－－因为有些东西他们的熟悉程度不是非常深刻，这一点没有事先考虑清楚，后期会让几个老人有重点的关注一下－－不是监视他们，而是帮助他们如何能在压力下快速的成长起来

           －－后续的经验：

           项目开始前PM就要对整个团队的实力作一个整体评估，根据每个人的特点去分配不同的任务－－即能让新人得到成长，又能给团队带来最大的价值

        2.项目组的成员是否对需求还有疑惑

            我们公司的流程是产品经理会发出PRD（Product Requirement Document产品需求文档），然后组织会议评审，每个人对需求的理解不一定一致的，有很多细节的东西可能在写UseCase时候甚至是编码测试时才发现，发现问题的时间点越早，花费的成本就越少，但是并不是每个人都能发现这个问题，有时候PRD评审的时候被产品经理忽悠的云里雾里的，似懂非懂，写UC的时候遇到了问题，如果不主动去问他，很少主动的来暴露问题，这是很可怕的，程序员按照自己的理解写出来了代码，结果却不是产品设计的初衷

            －－经验之谈

            1）带着问题去评审。一般会要求产品经理将PRD在评审前1－2天发出来，这样开发同学可以先了解一下大致的东东，把有疑惑的地方记录下来，然后在评审的时候一并把问题抛出来，一来问题计较集中，产品方面可以当面解决，另一个可以做到心中有数，对整个需求有框架的了解 

            2）积极主动发现问题，解决问题。作开发的同学性格相对闷一些，有了问题不及时去和产品确认，等你问到他有没有问题的时候才说，这里那里可能不是很了解，这是非常不可取的，有了问题一定要第一时间去找相关的人确认掉，解决掉，迷惑的东西越多，后期项目的风险就月大。

        3.设计文档什么时候做？

            这次的项目里几乎没有安排大家系统设计的时间，设计和UC的时间是黏在一起的，PRD评审过后就UC去了，目前发现这种弱化设计的方式是很有坏处的，对于小的需求的日常来说是可以的，但是对于项目这个环节是不能缺少的，看到项目组的成员在UC时就遇到了一些问题，如数据从哪里取的，本来以为是简单的查表得到，但是经过多方纠结以后才发现需要绕N个弯路依赖多个系统才能实现，这些东西其实是需求在UC前去考虑的

            －－经验教训

            系统设计绝不能弱化，特别是项目，需要分配时间来对关键的功能点作设计方案出来，然后去评估各种方案的利弊，选择最优方案，把问题和风险提前化，透明化

        4.UC文档的规范是否了解一致？

           项目的UC阶段后，简单看了一下各个项目组成员写的东东，参差不齐，主要有以下几个问题

           1)UC的命名不规范

           2)对于UC文档中各个文档块的功能描述不是很清晰，如有页面交互部分，业务规则部分，发现很多同学把业务规则的东西写到页面交互中去了，分支流和异常流的理解也不一致

           3)对业务逻辑描述的不够清晰完善。我抓了几个UC然后采用我问你答的方式进行沟通，发现我从当前UC上问到的很多问题在UC中都没有描述到或者有歧异－－这就给代码实现阶段埋下了伏笔，UC必须完整的实现PRD里的功能，而且保证产品开发和测试理解的都是一致的

           4)UC＝详细设计

            在我们公司内部UC文档的作用被放大化了，要求UC里必须详细到每个显示字段对应到数据库的哪个字段，问题就是写文档成本增高了，优势也很明显就是可以在写UC时详细知道每一个细节是怎么实现

            －－经验之谈

            1)刚开始以这种方式来写的时候很抵触，总感觉这个UC文档写起来怪怪的，UC应该是写给用户看的，用户管你数据库的哪个表哪个字段是什么意思干嘛？但是基于我们公司目前的现状，需求方是即懂技术又懂业务的人员，测试人员也需要关心DB，所以这种方式还是有意义的

            2)UC阶段就可以了解每个功能的实现方案，这就极大的降低了代码阶段带来的迷惑，还是那句话－尽早发现问题，把问题扼杀在摇篮里

        5.外部沟通

            问题：目前公司的现状是一个部门作一件事情，我们要作的功能需要其他部门协助才能完成，怎样驱动其他部门来协作呢

            1).产品经理会在项目前和各个部门协调配合人员－－只管圈人，配合的时间点由项目PM来协调完成

               这个就对PM有了更高的要求，专业打杂的，到处电话找人协调时间点，各个部门的响应不一样，有的很积极配合，有问必答形的，有的却爱理不理，有的虽然答应给做，但是优先级排的却很低

            2).项目过程中的沟通如何高效的完成？

               需求阶段不可能估测到所有的问题，UC和编码阶段也会不断的有问题浮现出来，这些问题怎么解决，何时去解决？

 

            3)怎么问问题？

            看到几个同学，包括我有时候也是，有问题拿起电话一顿说，别的部门有时候并不了解我们的需求，可能我们讲了半天，对方还云里雾里的，这种沟通方式是很低效的。

 

            －－经验之谈

           1)对于外部的东西，一定尽早的去确认时间点，包括发布时间点，联调时间点，如果有风险，尽早的暴露出来，如果自己搞不定，找各方的老大协调资源，各方沟通结论性的东西一定要邮件的形式发出来，用于存档(证据~~)

           2)问别人问题前先把问题考虑清楚，如果有多个问题最好1，2，3简单罗列下，用简洁的形式给自己默默的解释一遍，然后再去问

           3)问别人之前自己考虑一下对方可能怎么答复，我们的目标是怎样的，如他人无法满足我们需求的时候是否然他提供其他方案或者其他接口人，自己要准备多重方案，对方的时间也是有限的，一次能把所有的问题都搞清楚是最好的了

           教训：这次项目目前有几个外部时间点还没有最终确认下来，所以需要加油了~~

        6.需求的取舍

           产品有时候会生活在共产主义社会里，呼里哇啦大讲一坨，但是作为项目的管理人员一定要注意，有时候一个很小的功能就可能导致系统大篇幅的改动，这个时候就要从需求的优先级，实现的成本，系统的可维护性来考虑了，对于那些非主流程的功能点如果改动量很大，要花费大量的人力物力去实现，而且这个功能不见得就是用户需要的，这个时候就需要和需求方来确认，是否要保留这个功能或者其他备选方案来实现

项目刚开始没几天，一切也都在摸索中，过程中也接到不少外部同学的挑战，这个也正常，有人愿意来帮你指出错误，这是个好事情，这样成长的更快，问题只会越来越少的，加油