项目管理
我有很多年轻的产品同事及朋友，每次和他们聊起来，都会和我抱怨，说自己的项目计划2个月，但是现在都远超两个月了还没上线，都怪那些业务、运营甚至老板不停改需求不断加需求。但是从来没有谁和我说项目延期，需求不定的问题源自自身。难道真的问题都在别人身上吗？其实不然，所有类似问题，主要还是出在我们这些产品经理身上。为什么呢？
我用倒推法来举证：
这张图是我归纳了所有与我有所交流的产品经理所遇问题以后总结出的。
我在每一个步骤的流程中都加了一句话。这每一句话都代表一个看似平淡无奇，实则是相当致命的错误行为，而这些“小细节”也正是导致整个项目延期的罪魁祸首。
当然，也有朋友和我说：“我不去做需求评审，不做设计评审，不做XXX都是为了节约时间加速工期，但谁知道那些业务方不靠谱，他们连自己要什么都不知道？一直提需求改需求，导致我们开发延期。”
可是！
正是因为我们这些产品经理没有去做这些评审，才会导致业务方不清楚自己要什么！
为什么那么说呢？
如果业务很明确知道自己要什么，还要我们产品经理做啥？（开个玩笑）
首先，我们要明确业务是做什么的
无论项目是ToB还是ToC，业务人员，大多是处在第一线的人员，销售、运营、市场等等，那他们有什么共性吗？有！而且很明显！他们的工作面对的都是用户，是以“人”为单位的。而人的不确定性特别大，这就导致了业务方的工作大多都是杂乱无章的，再加上工作岗位问题或者工作习惯问题，从而导致业务方在使用系统时遇到困难，经常不能及时做记录，最后导致业务方提供到产品的需求大多都是常见问题，而且是最近遇到什么就提什么，过段时间遇到另外一些，然后又提一些。从此循环反复，无穷无尽。（这也是为什么总有产品同学说业务方都不知道自己要什么，我们只能跟着他们说的改。）
既然现在我们知道了为什么业务总会循环反复提一些“很有道理，且无法反驳”的需求，那我们是否应该去做些什么，去堵住他们的嘴，不让他们如此肆意妄为？是的，而且很简单。
具体方式如下：去了解业务，而且要比业务还了解业务。
是不是觉得说的很废话，很没必要？如果觉得很废话，我赞同。但是如果觉得很没必要，那只能说：你错了！
了解业务，是产品经理迈出第一步的重要前提
有多重要呢？重要到决定了产品接下来的走向！举个不太恰当的栗子，就如同两条公共端点射线形成的夹角，哪怕起初角度只是一点点的偏差，但射线到了一定长度以后，差距会变得非常明显！
那该怎么做呢？其实也很简单，就是问问问，化身为十万个为什么！千万不要觉得不好意思问，不然等项目交付的时候，有你脸红的时候。
现在知道要去问了，怎么问，这个方法也很重要。
我这里有四个步骤可以参考：
- 问前：去了解业务流程，即正常工作流。了解他们业务从哪开始，到哪结束，以及中途经历的正常的流程。（先不去考虑异常流程）
- 提问：在了解工作流的前提下，针对性提出问题，问业务分别每一步都会遇到什么问题，且目前是如何处理的。（一定要目前！！不要去管他们期望的解决方案）
- 反问：在前两步都了解的前提下，提出自己的反问，可以针对现有的解决方式，可以针对他们提出的期望方式，也可以针对其他你想到的。记住，一定要反问，一可以加强记忆，二可以化被动为主动，避免业务提出过多无用需求。（当然，业务提的所有需求都要记下，不要当场反驳，节省时间）
- 根据以上三点，画出业务流程图，即正常的业务流+每个环节可能出现的异常流，并附以业务方现有解决方案。
如果很完美做到这四步的同学还是被业务无情追着加需求，那么你可能还欠缺下面这一步。
需求整理及反馈
需求整理我想不需要多说，但是反馈这个行为，在我身边的年轻产品中很少有人做得到。可能是对业务方太有信心，也可能是产品太害羞，总之就是需求只确认过一次。
其实大可不必去考虑太多，我们是产品经理，目的是做一款人人夸的产品。现在为业务方做服务，就是希望得到他们的认同，而对他们来说，他们也很希望我们能做出一款他们用着顺心的产品，因此，他们是会竭力配合我们的工作，而不是找我们茬，故意给我们使绊子。所以尽管放心去做反馈吧，哪怕业务近期没时间，也要等到他们有时间，甚至让他们挤时间。相比起将来需求反复改的时间浪费来说，这点时间还是等得起的。大不了这个项目不做了，原因也是业务方不配合（轻松甩锅）。
需求反馈以后，肯定少不了一波补漏，这个时候，千万不要抱怨业务没有一次说清需求。因为换成你，你也不一定一次记得全。
所以一定要把他们提的需求按照之前的四步再走一遍，但是有一个小前提，如果这次对接的需求与第一次总结后得出的业务流程图不符，一定要问清楚为什么不一样，具体以哪一次为主，而不是一味听取他们的建议，还是那句话，业务自己也很混乱。
这一次反馈后，得出的需求以及业务流程图，才是有参考价值的。
然后再根据整体业务走向去划分可能存在的系统模块，并用四象法则去判断需求紧急度及重要度。
有了模块，就有了系统的大致框架；有了需求，就有了功能，如何只需把功能填充到各个模块中即可。当你将整个系统的大致框架搭出来，并将内部功能填充完时，你就会发现。做个系统真的好简单。不是吗？
现在有了一条清晰的业务流程，也有了一个明确的系统雏形，接下来是什么呢？当然肯定不是画原型图啦！远远没到这一步呢！
接下来要做的是与业务的功能评审！！！
这时应该拉上业务负责人，拉上一线业务代表，对你的模块划分，你的模块内拥有的功能进行评审，去了解是否缺少功能（即不做就影响业务正常流转的需求），是否有多余的不必要功能（大多是产品经理单方面觉得很有必要的伪需求），当然如果此时业务方提出一些期望性需求，记录下来，但要和他们明确表示，这一期是不做的。
如果与业务方的需求评审没过，请继续上述过程。当然，如果前期基础打得好，基本上不需要太久的调整就能搞定。
再然后应该怎么做呢？原型？别慌！快了，但还没！这时应该是再去找业务聊，不过这一次不需要开会，只需要当面确定一下之前的内容即可。
等需求都完全确定下来以后，我相信，如果你按照上面的步骤走过来，你心里已经知道自己要做什么东西了。这时，应该是把你整理出来的功能都梳理一遍。以业务流为核心，以模块为单位进行梳理。等打好这些基础以后，再去画原型图才是最合适的。
但是！！！到了原型图，就有朋友开始考虑什么用户体验，什么交互设计。千万别！！切记！！
因为到最后你会庆幸，还好一开始没有想那么多！！！
正确应该怎么做呢？画几张简单的图，附上应该包含的功能即可，最多最多也就是稍微排得好看点，显得态度比较端正的低保真，怎么交互怎么跳转都不需要画出来！！
然后下一步，就是
拉上你项目组内的设计&开发，来一波功能评审
在功能评审之前，你要知道一个前提，他们不是业务，但他们要了解业务，要让他们知道接下来要做什么，为什么而做。大家是一个项目组的成员，有同一个目标，只不过是用各自不同的专业技能去合作，共同实现这个目标。
有了这个前提以后，你就知道，你不能对他们有任何隐瞒，把自己知道的关于这个项目的业务内容完完全全告诉大家，让大家一同参与到项目中。
那么问题来了，评审会上，除了产品经理，其他人完全不了解业务，如何让他们迅速了解业务呢？很简单，拿出你之前做好的项目流程图，跟着流程图和他们逐一介绍流程，并介绍现在业务是怎么做的，我们应该怎么实现去为业务提高效率（或者其他），只有这样，大家才会站在一个角度去思考同一件事。介绍完业务以后，把你的系统架构拿出来，把你的功能列表拿出来，把你的原型图拿出来（其实整理在一起就差不多是PRD雏形了），让他们知道你是怎么去考虑的，让大家看看你考虑的是否齐全，并鼓励大家集思广益。去参考大家的建议，在会议上，把有争议的点记录下来，然后把没有争议的点进行分工，先一步安排下去，让后台开发先开始搭架构、准备数据库等。至于那些有争议的点，可以回头去问业务，确认以后回来与设计&开发针对性的开一个小评审会，解决这些问题。然后就是让设计去准备素材（竞品截图等）。
那接下来产品经理要做什么呢？这时候才是真正的原型图，中低保真+交互流程。等产出交互流程图以后，第一时间丢给开发和设计，同时将PRD中一些不合理的地方进行修改，生成一份完整的PRD，发给组内所有成员，包括自己领导和业务方领导（管他看不看，只是一个反馈）
那到了这里，产品就要开始催设计催开发了吗？并不是！
这时候产品经理应该拿着交互流程图屁颠屁颠去找业务方，去和他们领导，和他们的一线代表开个评审会，当然，这个会就是产品经理的个人表演秀了，和业务介绍我们根据之前确定的业务流程，做出点交互流程，分别有哪些模块，模块有哪些功能等等。如果业务觉得没问题，那么恭喜，这个版本一直到测试阶段以前你都会很顺利。如果有问题怎么办？也不要紧，和他们谈，只要不是有悖于业务流程图的，都谈，至于一些业务的奇思妙想去不去实现，那已经是我们一句话的事情了！当然，通常来说，为了满足业务的操作需求，产品们通常会答应做一些微调，但这些微调根本不会影响到后台的架构开发和设计的设计规范，所以随他们去吧！！
二次业务评审结束以后，第一时间将反馈内容通知给项目组内所有成员，包括存在感特低的前端，和他们说我们改了哪里，哪里没改。说实话，哪怕是大改也不要紧，项目初期这些坑还是能承受的。
再然后，产品经理应该怎么做呢？
完善文档，跟进设计，一定要让设计做2-3个风格的demo
为什么是demo而不是全部呢？因为怕挨刀子……（开个玩笑）因为要提高效率就要少做。只需要把几个特定页面做出2-3种风格即可。（风格自己把控）
等出图以后，纠集业务方领导、我方领导去挑风格，只有他们自己选的，才是他们喜欢的。（当然也可能都不符合他们要求，那就重复该操作）。等风格确定以后，再由设计去按照这个风格去全面设计，同时把UI图定期打包反馈至业务，当然，如果他们认为很满意不需要看，那另说。
等UI全部完成以后，尝试做一套以UI图为基础的高保真交互稿，拿去与业务方领导及我方领导做确认，认为没问题，就全部丢给前&后台两组开发。别问为什么还要给后台开发，他们写接口有用的。
再然后，产品需要做什么呢？闲着没事干啦？其实不然，这个时候才是真正产品展现实力的时候了。要保证这个项目如期上线，不是说前面做的好就搞定了，还需要持续的项目管理。毕竟不能虎头蛇尾。
项目管理是产品经理必须的技能，但也是很多年轻产品经理的短&硬伤。没有学过相关知识的产品可能很难掌握，但是我可以给大家提一个简单的方法，可以应急。比如说，不了解工期如何去判断，那就去问相关人员，让他们自行给出工期，然后拿着工期去请教领导or经验比较足的其他同事是否合理。当然，这种方法比较局限，就不细说了。
那如果实在不行怎么办，可以跳过相关人员，直接请教项目组内的资历比较深的开发，请他们指点一二。
项目管理这一块不建议自学，容易给自己挖坑，还是多多请教有经验的大牛或者多看看人家写的文章吧！！可以参考这篇文章《在高级产品经理眼中，好的项目管理流程是怎样的（上）》
项目管理只是一项把控项目进度，并保证项目在一定限度内不会延期的能力。除此之外，很有可能导致项目延期的另一因素，那就是测试。哪怕前期规划得再好，项目管理得再好，最终逃不过存在BUG得命运。
那如何能保证开发在开发过程中尽量快地写出更多功能，而产生更少的BUG呢？
用我个人不专业的话来说，就是只要保证他们的开发逻辑不要乱，基本上的BUG都是小BUG，无伤大雅且不会占用太多工期（特殊情况不议），基本上是不会出现致命性的BUG。那如何做到保证开发逻辑没问题呢？只需要保证开发架构不要乱，只需要保证产品规划不乱，只需要保证需求规划清晰。说到底，还是前期的铺垫很重要。切忌不要前期为了所谓的“快”，而不去梳理逻辑，导致开发末期，很多需求以补丁形式临时加上，最后出现一点点问题，造成无法轻易修改或者直接大改，导致几个小BUG花费大量工期。
当一款产品经历过了发现需求 → 需求收集/整理 → 需求转化为功能 → 功能开发完成 → 测试确保无误 → 上线的过程，才算是从0-1的过程。也是产品经理真正迈出第一步的过程，接下来，道阻且长，但是做到事情不过就是这些循环，至于考虑一款产品以后的趋势，走向，只有等产品经理到了一定高度才会去考虑，在这篇文章中就不赘述了。
