以前在一些公司里面，还专门有设项目管理这个岗位，但现在是越来越少看到了。我对这个岗位并不熟悉，但印象中基本都是由以前干过开发的人担任，而且最好是前端后端都懂，这样能够更好地把握各项需求的工作量。
我不是学程序出身的，但在 100 人以内的创业团队里负责或参与过项目管理，或者更确切地来说是进度管理。
作为一个产品经理，没有工程背景，怎么做项目管理呢?以下是我的一些个人实践：
▎产品策划提前两到三个版本
产品的迭代是有一条循环的流水线的：需求发掘-版本规划-方案策划-方案评审-ui 设计-开发-测试-发布。一般而言，为了效率最大化，我们都会争取做到相邻的两次迭代之间能够无缝对接。也就是流水线上每一个环节的人在完成了当前版本的工作后，就能立即执行下一个版本的需求。
产品策划提前两到三个版本的好处是，当开发过程中发现有余量时，可以把后续版本中的一些小的需求提前穿插到当前版本。
为什么不提前策划更多版本?很简单，避免闭门造车、纸上谈兵或构筑空中楼阁。极端的案例是提前策划无限个版本，这样明显是有问题的
▎明确每个版本的重点
一般而言，在一个版本里面，我只会设置一到两个重点的需求，其余需求皆属于可调整范围内。 版本的重点不是看某个需求体量的大小，而是看这个版本的产品目标是什么。每个版本的产品目标，都是在进行版本规划时已经明确下来的了。比如我会把电商类产品的需求分为四大类：拉新、留存、活跃、销售，在所谓的资本寒冬时，由于推广成本居高不下，在短期的一两个版本内，我可能会更加关注拉新和留存类的需求。
这样的话，在碰到开发时间不足，而又要确保产品如期上线的情况，就可以轻易地对需求做出取舍。
▎对开发成本的感知
虽然我不是学程序出身的，但也上过一些前后端的基础课程，对 “程序是如何发挥作用的” 有着抽象的理解。因此，和工程师协作多了，基本自己都能大致地判断每个功能是否好做，做的话大致需要多长时间。况且，除非产品的体量已经非常大，否则一般也不会有宏大和复杂到难以估量开发成本的功能。另外，在方案评审的时候，肯定也会和工程师确认开发成本如何。
有了对开发成本的感知后，每个版本能做哪些需求也就基本了然于胸。不至于出现原本以为做得完，后来却发现时间远远不够的情况。
▎mvp 原则
最小化产品原则其实很多人都知道，但在工作上真正用到的人却不多。怎样才算最小化?这个边界我们很难定一个标准，但也没有必要抠得这么紧。只要明白 “在做一些很大的功能时，有时没有必要一个版本搞定” 就行了。当然，这句话说得简单，但如果前期没有进行全局性的思考，忽略扩展性的话，可能一不小心就埋了大坑。
在常规的迭代中运用 mvp 原则，除了基于其低成本快速试错的内涵外，其实也是为了更好地控制项目的开发周期。
▎精简而有效的文档
文档太冗长，所有人都不想去看。没有文档的话，人的脑子又没那么好使，沟通会变得反反复复，工作流不停地被打断，大大降低工作效率。怎样的文档才是精简而有效的?基本上交互的流程图及页面的元素说明得有，一些基本和关键的实现逻辑、判断流程也得有。而且文字得简练、客观、规范。这样一来，可以减少很多临时性或重复性的沟通，确保时间都花在了做事情上。
▎少改需求
指的是开发的阶段要少改需求，甚至尽量冻结需求。因为每一次改需求都需要同步变化，而及时、准确地同步变化并不是一件容易的事情。更糟糕的是因为需求的变更，导致之前已经完成的一些工作要推导重来。这样不仅增加了不在计划内的工作时间，还影响协作的情绪。
要做到少改需求，只能要求在方案评审的时候更仔细，把各方的意见和疑问充分地沟通清楚。
▎充分利用好协作工具
协作工具确实是能够明显地提升项目管理的，比如说通过统一沟通渠道从而节省时间、避免重复沟通，自动同步信息等等。国内外可供选择的协作工作不算多也不算少。虽然有些确实明显地比另外一些好，但如果由于某些原因导致团队必须用某一个不是最好的协作工具时，问题也不会太大。因为基本所有协作工具都能满足项目管理最核心的几个需求，关键是你会不会灵活地使用。
▎及时同步变化
如果需求的变化不能及时同步，将会导致沟通成本增加，以及不能通过验收而需要返工。人少的时候，同步变化其实不是什么困难的事情，但人多的时候就有难度了。虽然很多协作工具都有文档更新通知，或者文档本身就有修改记录。但即便如此，也会有很多人忽略这些变动。在同步变化上，除了确保文档及时修改、告知相关设计师、工程师和测试人员以外，我还会单独召集各平台的 leader 进行简单的站立会议，提醒其确认变更是否已安排执行，同时也相当于交接了监管的责任。
▎开发及测试进度 review
需求正式发布后，各平台 leader 都会拆分任务，将其指派给具体的个人，以及设定好完成时间。我会设置两个开发进度验收时间及两个测试验收时间。开发验收时间主要是提前确认进入是否如期，如果有延误的话，原因是什么。如果是不可抗因素，则重新评估开发的进度计划;如果是可抗的因素，则要求在后续想办法赶上原计划的进度。第一个测试验收时间和开发验收有点类似，主要是看进度是否能跟上，如果不能跟上的话，是需要及时调整还是加把劲追赶。而第二次验收时间则是评估哪些问题可以暂时搁置，哪些问题必须解决。
这两种验收时间的设置亲测十分有效，基本避免了快要到期却发现发布无望时各方的各种理由及转移责任。