项目管理

 

我有不少年轻的产品同事及朋友，每次和他们聊起来，都会和我抱怨，说本身的项目计划2个月，可是如今都远超两个月了还没上线，都怪那些业务、运营甚至老板不停改需求不断加需求。可是历来没有谁和我说项目延期，需求不定的问题源自自身。难道真的问题都在别人身上吗？其实否则，全部相似问题，主要仍是出在咱们这些产品经理身上。为何呢？

我用倒推法来举证：

这张图是我概括了全部与我有所交流的产品经理所遇问题之后总结出的。

我在每个步骤的流程中都加了一句话。这每一句话都表明一个看似平淡无奇，实则是至关致命的错误行为，而这些“小细节”也正是致使整个项目延期的罪魁祸首。

固然，也有朋友和我说：“我不去作需求评审，不作设计评审，不作XXX都是为了节约时间加速工期，但谁知道那些业务方不靠谱，他们连本身要什么都不知道？一直提需求改需求，致使咱们开发延期。”

但是！

正是由于咱们这些产品经理没有去作这些评审，才会致使业务方不清楚本身要什么！

为何那么说呢？

若是业务很明确知道本身要什么，还要咱们产品经理作啥？（开个玩笑）

首先，咱们要明确业务是作什么的

不管项目是ToB仍是ToC，业务人员，大可能是处在第一线的人员，销售、运营、市场等等，那他们有什么共性吗？有！并且很明显！他们的工做面对的都是用户，是以“人”为单位的。而人的不肯定性特别大，这就致使了业务方的工做大多都是杂乱无章的，再加上工做岗位问题或者工做习惯问题，从而致使业务方在使用系统时遇到困难，常常不能及时作记录，最后致使业务方提供到产品的需求大多都是常见问题，并且是最近遇到什么就提什么，过段时间遇到另一些，而后又提一些。今后循环反复，无穷无尽。（这也是为何总有产品同窗说业务方都不知道本身要什么，咱们只能跟着他们说的改。）

既然如今咱们知道了为何业务总会循环反复提一些“颇有道理，且没法反驳”的需求，那咱们是否应该去作些什么，去堵住他们的嘴，不让他们如此肆意妄为？是的，并且很简单。

具体方式以下：去了解业务，并且要比业务还了解业务。

是否是以为说的很废话，很不必？若是以为很废话，我赞同。可是若是以为很不必，那只能说：你错了！

了解业务，是产品经理迈出第一步的重要前提

有多重要呢？重要到决定了产品接下来的走向！举个不太恰当的栗子，就如同两条公共端点射线造成的夹角，哪怕起初角度只是一点点的误差，但射线到了必定长度之后，差距会变得很是明显！

那该怎么作呢？其实也很简单，就是问问问，化身为十万个为何！千万不要以为很差意思问，否则等项目交付的时候，有你脸红的时候。

如今知道要去问了，怎么问，这个方法也很重要。

我这里有四个步骤能够参考：

1. 问前：去了解业务流程，即正常工做流。了解他们业务从哪开始，到哪结束，以及中途经历的正常的流程。（先不去考虑异常流程）
2. 提问：在了解工做流的前提下，针对性提出问题，问业务分别每一步都会遇到什么问题，且目前是如何处理的。（必定要目前！！不要去管他们指望的解决方案）
3. 反问：在前两步都了解的前提下，提出本身的反问，能够针对现有的解决方式，能够针对他们提出的指望方式，也能够针对其余你想到的。记住，必定要反问，一能够增强记忆，二能够化被动为主动，避免业务提出过多无用需求。（固然，业务提的全部需求都要记下，不要当场反驳，节省时间）
4. 根据以上三点，画出业务流程图，即正常的业务流+每一个环节可能出现的异常流，并附以业务方现有解决方案。

若是很完美作到这四步的同窗仍是被业务无情追着加需求，那么你可能还欠缺下面这一步。

需求整理及反馈

需求整理我想不须要多说，可是反馈这个行为，在我身边的年轻产品中不多有人作获得。多是对业务方太有信心，也多是产品太害羞，总之就是需求只确认过一次。

其实大可没必要去考虑太多，咱们是产品经理，目的是作一款人人夸的产品。如今为业务方作服务，就是但愿获得他们的认同，而对他们来讲，他们也很但愿咱们能作出一款他们用着顺心的产品，所以，他们是会竭力配合咱们的工做，而不是找咱们茬，故意给咱们使绊子。因此尽管放心去作反馈吧，哪怕业务近期没时间，也要等到他们有时间，甚至让他们挤时间。相比起未来需求反复改的时间浪费来讲，这点时间仍是等得起的。大不了这个项目不作了，缘由也是业务方不配合（轻松甩锅）。

需求反馈之后，确定少不了一波补漏，这个时候，千万不要抱怨业务没有一次说清需求。由于换成你，你也不必定一次记得全。

因此必定要把他们提的需求按照以前的四步再走一遍，可是有一个小前提，若是此次对接的需求与第一次总结后得出的业务流程图不符，必定要问清楚为何不同，具体以哪一次为主，而不是一味听取他们的建议，仍是那句话，业务本身也很混乱。

这一次反馈后，得出的需求以及业务流程图，才是有参考价值的。

而后再根据总体业务走向去划分可能存在的系统模块，并用四象法则去判断需求紧急度及重要度。

有了模块，就有了系统的大体框架；有了需求，就有了功能，如何只需把功能填充到各个模块中便可。当你将整个系统的大体框架搭出来，并将内部功能填充完时，你就会发现。作个系统真的好简单。不是吗？

如今有了一条清晰的业务流程，也有了一个明确的系统雏形，接下来是什么呢？固然确定不是画原型图啦！远远没到这一步呢！

接下来要作的是与业务的功能评审！！！

这时应该拉上业务负责人，拉上一线业务表明，对你的模块划分，你的模块内拥有的功能进行评审，去了解是否缺乏功能（即不作就影响业务正常流转的需求），是否有多余的没必要要功能（大可能是产品经理单方面以为颇有必要的伪需求），固然若是此时业务方提出一些指望性需求，记录下来，但要和他们明确表示，这一期是不作的。

若是与业务方的需求评审没过，请继续上述过程。固然，若是前期基础打得好，基本上不须要过久的调整就能搞定。

再而后应该怎么作呢？原型？别慌！快了，但还没！这时应该是再去找业务聊，不过这一次不须要开会，只须要当面肯定一下以前的内容便可。

等需求都彻底肯定下来之后，我相信，若是你按照上面的步骤走过来，你内心已经知道本身要作什么东西了。这时，应该是把你整理出来的功能都梳理一遍。以业务流为核心，以模块为单位进行梳理。等打好这些基础之后，再去画原型图才是最合适的。

可是！！！到了原型图，就有朋友开始考虑什么用户体验，什么交互设计。千万别！！切记！！

由于到最后你会庆幸，还好一开始没有想那么多！！！

正确应该怎么作呢？画几张简单的图，附上应该包含的功能便可，最多最多也就是稍微排得好看点，显得态度比较端正的低保真，怎么交互怎么跳转都不须要画出来！！

而后下一步，就是

拉上你项目组内的设计&开发，来一波功能评审

在功能评审以前，你要知道一个前提，他们不是业务，但他们要了解业务，要让他们知道接下来要作什么，为何而作。你们是一个项目组的成员，有同一个目标，只不过是用各自不一样的专业技能去合做，共同实现这个目标。

有了这个前提之后，你就知道，你不能对他们有任何隐瞒，把本身知道的关于这个项目的业务内容完彻底全告诉你们，让你们一同参与到项目中。

那么问题来了，评审会上，除了产品经理，其余人彻底不了解业务，如何让他们迅速了解业务呢？很简单，拿出你以前作好的项目流程图，跟着流程图和他们逐一介绍流程，并介绍如今业务是怎么作的，咱们应该怎么实现去为业务提升效率（或者其余），只有这样，你们才会站在一个角度去思考同一件事。介绍完业务之后，把你的系统架构拿出来，把你的功能列表拿出来，把你的原型图拿出来（其实整理在一块儿就差很少是PRD雏形了），让他们知道你是怎么去考虑的，让你们看看你考虑的是否齐全，并鼓励你们集思广益。去参考你们的建议，在会议上，把有争议的点记录下来，而后把没有争议的点进行分工，先一步安排下去，让后台开发先开始搭架构、准备数据库等。至于那些有争议的点，能够回头去问业务，确认之后回来与设计&开发针对性的开一个小评审会，解决这些问题。而后就是让设计去准备素材（竞品截图等）。

那接下来产品经理要作什么呢？这时候才是真正的原型图，中低保真+交互流程。等产出交互流程图之后，第一时间丢给开发和设计，同时将PRD中一些不合理的地方进行修改，生成一份完整的PRD，发给组内全部成员，包括本身领导和业务方领导（管他看不看，只是一个反馈）

那到了这里，产品就要开始催设计催开发了吗？并非！

这时候产品经理应该拿着交互流程图屁颠屁颠去找业务方，去和他们领导，和他们的一线表明开个评审会，固然，这个会就是产品经理的我的表演秀了，和业务介绍咱们根据以前肯定的业务流程，作出点交互流程，分别有哪些模块，模块有哪些功能等等。若是业务以为没问题，那么恭喜，这个版本一直到测试阶段之前你都会很顺利。若是有问题怎么办？也没关系，和他们谈，只要不是有悖于业务流程图的，都谈，至于一些业务的奇思妙想去不去实现，那已是咱们一句话的事情了！固然，一般来讲，为了知足业务的操做需求，产品们一般会答应作一些微调，但这些微调根本不会影响到后台的架构开发和设计的设计规范，因此随他们去吧！！

二次业务评审结束之后，第一时间将反馈内容通知给项目组内全部成员，包括存在感特低的前端，和他们说咱们改了哪里，哪里没改。说实话，哪怕是大改也没关系，项目初期这些坑仍是能承受的。

再而后，产品经理应该怎么作呢？

完善文档，跟进设计，必定要让设计作2-3个风格的demo

为何是demo而不是所有呢？由于怕挨刀子……（开个玩笑）由于要提升效率就要少作。只须要把几个特定页面作出2-3种风格便可。（风格本身把控）

等出图之后，纠集业务方领导、我方领导去挑风格，只有他们本身选的，才是他们喜欢的。（固然也可能都不符合他们要求，那就重复该操做）。等风格肯定之后，再由设计去按照这个风格去全面设计，同时把UI图按期打包反馈至业务，固然，若是他们认为很满意不须要看，那另说。

等UI所有完成之后，尝试作一套以UI图为基础的高保真交互稿，拿去与业务方领导及我方领导作确认，认为没问题，就所有丢给前&amp后台两组开发。别问为何还要给后台开发，他们写接口有用的。

再而后，产品须要作什么呢？闲着没事干啦？其实否则，这个时候才是真正产品展示实力的时候了。要保证这个项目如期上线，不是说前面作的好就搞定了，还须要持续的项目管理。毕竟不能有始无终。

项目管理是产品经理必须的技能，但也是不少年轻产品经理的短&amp硬伤。没有学过相关知识的产品可能很难掌握，可是我能够给你们提一个简单的方法，能够应急。好比说，不了解工期如何去判断，那就去问相关人员，让他们自行给出工期，而后拿着工期去请教领导or经验比较足的其余同事是否合理。固然，这种方法比较局限，就不细说了。

那若是实在不行怎么办，能够跳过相关人员，直接请教项目组内的资历比较深的开发，请他们指点一二。

项目管理这一块不建议自学，容易给本身挖坑，仍是多多请教有经验的大牛或者多看看人家写的文章吧！！能够参考这篇文章《在高级产品经理眼中，好的项目管理流程是怎样的（上）》

项目管理只是一项把控项目进度，并保证项目在必定限度内不会延期的能力。除此以外，颇有可能致使项目延期的另外一因素，那就是测试。哪怕前期规划得再好，项目管理得再好，最终逃不过存在BUG得命运。

那如何能保证开发在开发过程当中尽可能快地写出更多功能，而产生更少的BUG呢？

用我我的不专业的话来讲，就是只要保证他们的开发逻辑不要乱，基本上的BUG都是小BUG，无伤大雅且不会占用太多工期（特殊状况不议），基本上是不会出现致命性的BUG。那如何作到保证开发逻辑没问题呢？只须要保证开发架构不要乱，只须要保证产品规划不乱，只须要保证需求规划清晰。说到底，仍是前期的铺垫很重要。切忌不要前期为了所谓的“快”，而不去梳理逻辑，致使开发末期，不少需求以补丁形式临时加上，最后出现一点点问题，形成没法轻易修改或者直接大改，致使几个小BUG花费大量工期。

当一款产品经历过了发现需求 → 需求收集/整理 →  需求转化为功能 →  功能开发完成 →  测试确保无误 → 上线的过程，才算是从0-1的过程。也是产品经理真正迈出第一步的过程，接下来，道阻且长，可是作到事情不过就是这些循环，至于考虑一款产品之后的趋势，走向，只有等产品经理到了必定高度才会去考虑，在这篇文章中就不赘述了。