产品辣些事记一次不成熟的项目管理

　　恰恰是那些你认为枯燥无用的东西，才建立起未来你职业的口碑
　　首先要和大家说两个单词：Product Manager & Project Manager ，他们的缩写都是PM，这两个单词分别代表着＂产品经理＂&＂项目经理＂，正如他们英文词汇如此相似的那样， 在日常的工作中（特别是计算机软件、互联网行业），这两个岗位在工作内容上也有相似之处。
　　其实在苏杰老师编写的《人人都是产品经理》一书中，我们就已经了解到产品汪需要做一些项目管理的事情，可能是篇幅原因，苏老师对于项目管理的实战操作也没有做太多赘述。直到有一天，一个真正的项目管理任务压在我身上时，才更好的了解了项目管理。那么今天我就和大家谈一谈之前的一次项目管理工作。
　　细分工作任务
　　这有点像数据表设计中的第一范式一样，即将任务细分到最小直到不可再分为止。在项目管理的术语中，我们称之为：创建WBS（工作分解结构），即把项目交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。WBS的分解可以采用以下三种方式进行：
　　按产品的物理结构分解；
　　按产品或项目的功能分解；
　　按照实施过程分解；
　　我上家公司是一个软硬件结合的智能仓储企业（类似于亚马逊的Kiva），在投入上线时必须保证：仓库硬件的铺设、仓储机器人的正常运行、软件功能的正常使用等。因为这几项工作环环相扣，有着很强的功能关联性（你必须做完这项才能进行下一项），所以第三种分解方式最适合我们的这个项目。
　　项目节点设定
　　细分好任务后，就是确定任务完成时间了。一般依靠乙方验收时间来设定项目周期的时间，根据自己的开发能力、补救能力等设定截止时间并预留一定的缓冲时间。当然最重要的在项目启动时，项目负责人最好向乙方公司争取充足的时间。通过这一环节我们可以注意到，如果任务分得越细，单个任务的延期就不会引起大范围的瘫痪，也更容易进行补救。
　　任务，就是上一环节分解出来的。
　　项目负责人一般设定为一人，主要为了更好的追责。有道是法不责众，一个任务关联一个负责人更容易进行管理。
　　交付产物是检验任务结束的唯一标准，软件实现了什么功能、完成文档编写……这些都可以作为交付产物。
　　任务周期（单位：人/天），因为自己不是技术出身，所以在研发时间上我会一次去咨询一些开发人员，但是周期也不是开发说多少就是多少。开发长度一般都会压缩，因为大部分人都会潜意思给自己预留一些缓冲时间。
　　如果您经历过很多次项目后，周期设置自然了然于胸；我上家公司的产品总监冯老师总能将节点安排的精确、合理！
　　项目跟进
　　个人认为这各阶段就是要当罪人的时候，每天上班前、中间、下班前都要询问一下今天已开启任务或即将开启任务的计划、情况等。被催的感觉当然不好，在项目管理过程中经常会受到任务执行者的抱怨，甚至是反抗。苏杰老师在书中提过项目结束他们的团队进行了一场聚餐，所以这项目管理也是一边要催，一边要哄。
　　同时，项目的日报、周报也得发给项目经理，同时在周报、日报中需要将遇到的问题一一列举出来，方便项目经理做好风险评估。除此之外，还要对付乙方的邮件、电话……一次项目管理后要么疯了，要么更冷静了。
　　项目结束
　　完成开发、实施后就是现场验收，最重要的是，记得双方签订验收确认书，避免最后乙方＂事后找茬＂，我就听说过一个团队被一个项目拖一年多的案例。再经过一些培训、 上线移交的工作，这个项目就基本结束了。
　　写在最后
　　能有这一次完整的项目管理经历，首先要感谢冯老师的信任，也要感谢Alex的项目管理培训，最后也要感谢当初没有杀了我的同事们。因为这是目前仅有的一次经历，所以在项目描述中有不正确的地方也欢迎大家指出，并期待能够和大家一起交流……