进入产品经理的角色不到一年，也踩过了不少坑。还记得当初走出校门，迷茫的找工作，看到产品经理的职位，描述的神乎其神，想着我要做一款属于自己的产品，我要向乔帮主一样改变世界，我要把产品当成我自己的儿子一样把她造出来并养大，于是带着这份未知的神秘色彩，耗费了四个月的时间，当上了一名苦逼的产品，表面上由公司CEO（原腾讯产品总监）直接带的，可是这些坑依旧得自己踩一遍才能长记性；后来老大推荐了一本《人月神话》，是关于项目管理的，看着很有共鸣，刚刚读完，结合自己的实际经历来跟大家谈一谈，在做产品的过程中如何做好项目管理。
书的第一章写了关于职业的乐趣和苦恼，虽然此书写于40多年前，但在如今的现实中也确实是这样，我们有时候会享受创造出一款产品，满足我们内心对创造的渴望；与此同时也会给我们带来许多苦恼，无处不在的bug、处理不完的需求、没有资源、项目延期、还有可能面临被淘汰，等等。
我刚开始做产品的时候，觉得我把需求明确了、做了一个规划并交给开发，让他们开发去吧，我就喝着咖啡等着验收就行，总是以一个乐观主义的心态去看待产品进展，觉得一切都会按部就班的进行，可是真的问题来了，真的就如猛兽般来了，究其原因：其一是太乐观主义；其二是没有跟技术总监确定好项目进度安排；其三是产品设计的时候没有考虑到产品的完整性；其四是因为我们的思维永远是存在bug的。（这里更多的是技术总监的职责，就捎带而过）当产品延期，我们总想着去增加人手，可是增加人手并不一定带来效率的增加，反而更加会拖延项目，增加人手会增加沟通成本、培训成本，这些都会造成时间上的浪费，所以，项目最初要按照两个法则来就要做好工期的安排：（1）项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量；（2）时间分配大致按照1/3计划（产品设计前期工作）、1/6开发、1/4构建测试和最早期系统测试、1/4系统统一测试。
至于产品概念的完整性，我们需要参照贵族专制。在产品设计中，概念完整性应该是最重要的考虑因素，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的产品，哪怕其中包含这精妙的设计，我们要能够剔除杂音；同时产品的易用性也是跟产品概念的完整性紧密联系的。产品的完整性可以通过在写PRD、MRD的过程中总结出来。明确产品概念的完整性之后，其次是控制产品的规模体量，控制产品的规模也要从用户研究和用户需求出发，设定规模、确定功能、划分模块、设定目标。书中也说到控制规模的三个原则：（1）制定总体规模包括后台存储、访问的预算，鄙人刚入行的时候在此也踩过坑，只考虑了前端的页面和逻辑，却忘记了设计后台的增删改查和存储；（2）指明模块定义的同时，定义明确的功能，要落实到需求列表中，经过审核且确定的，包括必要的输入输出；（3）从整体、面向用户的角度思考问题，这一点不必多说。
在产品的开发过程中，开发人员承担产品实现的责任，所以我们产品只能建议，不能支配，并且时刻准备着为需求实现提供一种实现的方法，但是也要时刻准备着接受其他任何能达成目标的方法，我们要以目标为导向。那么开发是以什么为目标呢？——原型，所以当原型作为标准的时候，我们必须控制原型的修改，这样可以尽量减少讨（si）论（bi），所以我们在写PRD的时候一定基于上面说到的概念完整性，把我产品定位，准确描述产品原型。当然，再精确的说明也会让不同的人产生歧义，所以沟通也是非常重要的，我们要建立一个沟通日志，记录日常的沟通情况、出现的问题以及解决办法。
文档在项目管理中的作用：（1）每份文档的准备工作是集中考虑、明确全盘计划和统一意见的结果，文档上的内容是拿来就可执行的；（2）文档的更新维护是项目监督和预警机制；（3）文档本身也可以作为项目监督和状态控制的依据，所有的进程应按照文档进行；（4）文档是沟通的基础。所以我们在进入开发阶段之前，就应该与各个部门确认文档，文档指导的是一个精确、可执行、清晰的方向，总得来说，文档是一种总结全面、意思表达清楚、结构清晰的“可执行”文件。文档进入了开发阶段，也会遇到各种各样的问题，发生一些变化，产品能做的是为开发人员及时设计方案，当然方案还是要根据文档设定的目标设计，决定权在开发人员手中。另外，每个产品文档都应该有自己的日程表和冻结日期，在此之后的变更属于下一版本的内容，当然也可以简单的建立一个需求管理及变更的说明，写明需求或问题来源、背景、解决办法、负责人、上线时间等。
产品人也是优秀的设计人员，在这个“小步快跑、快速迭代”的时代，不断重复地抽取和细化产品的需求、快速制作精准原型的角色也是由我们充当，详细的需求包括了所有的用户界面、人机交互界面，包括前端后端，以及与其他软件系统的接口。如果失误了，需求工作对系统的影响比其他任何一个部分都大，甚至都要推到重来。也正是因为我们不可能一次就将原型做到完整、精确，所以才要求我们能快速制作原型。原型通常展示了产品的功能主线，但最好也加上对无效输入、退出等异常情况，也可以在开发文档的全局声明中指出。原型的目的是明确实际的概念结构，解决用户的问题。
END，欢迎讨论！
