前言:一个需(xū)求下来,产(chǎn)品、设计(jì)、开发、测试都评估了(le)时间。但实际开(kāi)发的(de)需(xū)求可(kě)能(néng)会有变动(dòng),老板今天要改(gǎi)这个,明天要改那个;不少东西要多(duō)方确认,最后到项目(mù)时间节点(diǎn),老板问你怎么样了(le)?你无言以(yǐ)对(duì)...
一、产品经(jīng)理为什么要(yào)管理项目(mù)进度(dù)
大(dà)公司可能(néng)会有专门的项目经理去进(jìn)行项目进度的(de)把控,初创(chuàng)型的小(xiǎo)公(gōng)司可能是CTO兼任,但是CTO可能在开发的过程中为了尽快上线(xiàn)砍(kǎn)需求(qiú),最后做出来的(de)东西质量堪忧。一个项(xiàng)目,有明确(què)的(de)开(kāi)始和结束时间,有明(míng)确的质量(liàng)监控和(hé)要求,有明确(què)的(de)投入(rù)和产出预(yù)算(suàn),这些是项(xiàng)目管(guǎn)理(lǐ)的核心。但也(yě)应该是(shì)产(chǎn)品(pǐn)经理的责任--如果产品(pǐn)经理不考虑时间,怎么(me)能够按时上(shàng)线产品?如果他(tā)不关注质量,怎么能够(gòu)推出受用户欢迎的产品?如果他不考虑(lǜ)投入产出比(这(zhè)个恰恰是很多技术出身的产品经理最不以为然的--好东(dōng)西要舍得投(tóu)入),就有可能浪费公司大量的人力、物力和时间。
二(èr)、产(chǎn)品经理如何管理项目进度(dù)
1、拒绝业务频(pín)繁的更改和插入需求
市(shì)场部(bù)门今天提出一个需(xū)求,过两天感(gǎn)觉成本可能会有点高,需要改一下规(guī)则;老板今天冒出一个想法(fǎ)觉得这个不错,需要做一下,明天又有一个新的idea要加上。这个时候你作为产(chǎn)品(pǐn)经理就(jiù)需要动(dòng)之以(yǐ)情(qíng),晓之以(yǐ)理的说服业务部门。
你可以说:“1、你(nǐ)的一个小小的规则变动可能(néng)导致技术(shù)之前做的功夫全部白费,打击士气,丧失技术对你的信任,说不(bú)好还需要买个人身保险。2、如(rú)果这样变化的话,可能会导(dǎo)致整个项目延(yán)期,无法及时上线,你(nǐ)看你是否能够接受(shòu)“。
对于老板插(chā)入的需求你可以说(shuō):“您提出的这个需求很(hěn)好,很(hěn)符合(hé)我们的实(shí)际(jì),为(wéi)了(le)不拖延项目(mù)进度,可以在下一版(bǎn)本进行(háng)规(guī)划。“
你还可(kě)以(yǐ)用数据来说服老板,暗示他提(tí)的(de)这个(gè)需求和我们(men)现在的实(shí)际情况不符。
总之一个原则就是产品项目进入开发(fā)阶段以(yǐ)后就不(bú)要再频(pín)繁变更(gèng)和插入(rù)需求。
2、可以提前规划一两个版(bǎn)本
产品的迭代是(shì)有一条循(xún)环的流水(shuǐ)线的(de):需(xū)求发掘-版(bǎn)本(běn)规划-原型策(cè)划-原型评审-UI 设计-开发(fā)-测试-发布。一般而言,为了效率最大化,我(wǒ)们都会争取(qǔ)做到(dào)相邻的两次(cì)迭代之间能够无缝对接。也(yě)就是流水线(xiàn)上每一个环节的人在完成了(le)当前版本的工作后,就能(néng)立即执行下(xià)一个版本的需求。
产品提(tí)前(qián)规划(huá)有个好处就是当你觉得技术在当前版本开(kāi)发(fā)有余量的情况下,可以将(jiāng)之(zhī)后版本的需(xū)求拿到当前版本进行(háng)开发。
为什(shí)么不(bú)提前(qián)规划5-6个版本。一(yī)般来说一个(gè)月迭代(dài)两个版本已(yǐ)经算快的了(le),提前规划(huá)5-6个版本(běn),就提(tí)前把3个月以(yǐ)后的(de)事情(qíng)规划了,互联(lián)网瞬(shùn)息万变,这(zhè)样规划显然是跟不上市场(chǎng)变化的。
3、明确每个版本迭代的目标
每个版本迭代(dài)都是有目标的(de),例(lì)如互联网电(diàn)商产品的目标可以(yǐ)分为:拉(lā)新、留存、转化、销售。所以你规划的时候就(jiù)要(yào)考虑(lǜ)你这个版本的主(zhǔ)要目标是这四个当中(zhōng)的哪一个。
这样做的好处就是在(zài)你(nǐ)项目时间不够,需(xū)要做出取舍(shě)的时(shí)候,能够轻易的(de)做出取舍(shě)。例如:资本寒冬(dōng)的(de)时候,推广成本(běn)居高不下,这个时候(hòu)你下(xià)个版本的主要目标是留(liú)存(cún),那么当你(nǐ)项目(mù)实现(xiàn)不了,需要砍需求的时候,你就(jiù)可以把不相关的需求(qiú)砍(kǎn)掉(diào),确(què)保你的项(xiàng)目顺利上线。
4、MVP原则
最小化(huà)产品原则需要你(nǐ)在规(guī)划版本的时候考虑产品功能的延展性,需(xū)不需要在(zài)一个版本里(lǐ)面把所有的功能都做完,可不可(kě)以分几个(gè)版本迭代来实现(xiàn)。例如你规划一个金融社区(qū),前期是不(bú)是可以只做用户单点(diǎn)评论功能,在以后的版本再做用户(hù)和用户之间的(de)互动。
最(zuì)小化产品原则不仅可(kě)以快速(sù)验证市场,同时也能更好的控制项目(mù)的开发周(zhōu)期。
5、产品经理不要频繁变更需(xū)求
很多时候产品经理在规划产品的时候异常情况没有考虑清楚,很多情况没(méi)有没有考虑到,导致在技术人(rén)员在开发的时候需要不断的找产品经理确(què)认,无形中增(zēng)加了沟通(tōng)成(chéng)本,延长了开发周期,尤其在沟通不顺畅的情况下。
这就要求产品经(jīng)理不要急着(zhe)出文档去开(kāi)发,一定要深思熟虑,考虑周全(quán)。
这样做(zuò)有(yǒu)两个好处:
1、增加在开发人员心目(mù)中的威信,更利于在(zài)工作当中的沟通
2、开发过程中你会很(hěn)轻松,不会有(yǒu)开发人员不断地找您确认需求,有(yǒu)利于项目(mù)的快速进行(háng)。
6、制(zhì)定明确的项(xiàng)目管理计划
第一:需要明确目标。项目什么时间(jiān)封包、什么时间(jiān)上(shàng)线要有一个一致(zhì)的目标。
第二:制(zhì)定详细(xì)计划。有了明确的目(mù)标以后就需(xū)要制定开发(fā)计划。产品(pǐn)出需求需要多久、设(shè)计需要多久、开发需要多久、测试需要(yào)多(duō)久,出一个时间节点。
这样做(zuò)有三个好(hǎo)处:1、这样会(huì)给各个部门一(yī)个压力。
2、同时当你老板问(wèn)你项目进度的时候你也有地方可查询。
3、你自己对项目进度也有(yǒu)一个大概(gài)的了解。
7、对开发成(chéng)本有(yǒu)所了解(jiě)
上面提(tí)到(dào)产品经理要制定(dìng)项目管理(lǐ)计划。如果(guǒ)产品经(jīng)理对开发成本不了解的话很容易(yì)被开(kāi)发(fā)忽悠(yōu),导致开发的周期过长。同时对技术的(de)了解,有利于和程序员进行沟通,减(jiǎn)少开发过程中的(de)沟通(tōng)成本。同(tóng)时对技术的(de)了解,有利(lì)于(yú)在产品规划(huá)的时候了解技(jì)术的实现成本,做到规划的时候有(yǒu)的放矢。
对开发技术的了(le)解当然越精细越好,如果达不到(dào)专(zhuān)家程度,至(zhì)少(shǎo)也要达到半(bàn)骨灰级的程度。
8、项目(mù)进度的Review
项目进度计划做好(hǎo)以后,把(bǎ)项目分配给每(měi)个(gè)人,但是(shì)你不能保证每(měi)个人都能(néng)在时间点之(zhī)前完成任务(wù)。产品(pǐn)经理可以每天举行几分钟的站立(lì)会议,了解(jiě)一下项目的进度,是否(fǒu)会(huì)有延期。如果延期,原因是什么?如果是不(bú)可抗因素,则(zé)重新评估开发的进度(dù)计划;如果是(shì)可抗的因素,则要求在后(hòu)续想办法赶上原计划的进度。
如果不(bú)实行(háng)每天的站立会(huì)议,可以分为两次review。第一次(cì)review主要(yào)看进度(dù)是否跟的上(shàng),如果跟不上(shàng)是及时(shí)调整还是需要加把(bǎ)劲追(zhuī)赶。第二次review主(zhǔ)要是(shì)是评估那些问题可以暂时搁浅,那些(xiē)问题(tí)必须(xū)解决。
在和他(tā)们沟通(tōng)进度,尤其(qí)在(zài)他们没(méi)有(yǒu)完成(chéng)的时候(hòu)不(bú)要训斥他们为什么没有按进度完成(chéng),要帮助他(tā)们(men)解决问题,给他们梳理一个愿景,描绘一个美好(hǎo)的目标。别人尊重你,你就是(shì)PM。别人不搭理你,你就只是一个P。
9、敏捷(jié)开发(fā)的(de)PRD文档
我这里(lǐ)所说的(de)敏捷开发的PRD文(wén)档是指原型+标注(zhù)形式的文档(dàng)。说实话,你写的冗长的word文(wén)档不仅耽误你自己的时间,开发也不一定会看(kàn),即使看了,也不方便。开(kāi)发一(yī)般直接照着(zhe)产品(pǐn)原型来(lái)开发,这个时候(hòu)就需要你有一(yī)个敏捷(jié)开发的PRD文档。
敏捷开发的PRD文档包含版本迭代历史(shǐ)、功能list、异常情(qíng)况的说(shuō)明、全局结构图和重要的流程图、第一次出现的名词(cí)解释,这些不能少(shǎo),否则你的PRD不是一(yī)个完整的文(wén)档。
10、良好的沟通
项(xiàng)目(mù)成员包(bāo)含设计、开发、测试人员。你需要(yào)和这些人良好(hǎo)的(de)沟通,和设计人员沟(gōu)通你要(yào)有感性思维,有审美能力。和开发人员沟通,你需要有技术的逻(luó)辑(jí)思维、测试人(rén)员一(yī)般比(bǐ)较严谨,和测试人员沟通你需要有(yǒu)严(yán)谨缜密的思维。
和他们沟通项目进度的(de)时候,如果你让成员不必为他所说的话负责任,你(nǐ)就能(néng)得到负责任的回答。如果(guǒ)把自己(jǐ)和工程师当成上下游的关(guān)系,把工程师对(duì)工期的估计当作对自己的承(chéng)诺。“30天才能给你(nǐ)。”“不行,我15天(tiān)就要。”这不(bú)是(shì)沟(gōu)通,这是对(duì)立面的谈判。道已错,追求术有什么用?
真正有效的(de)办法,是让彼此间的(de)沟通,永远不会成为(wéi)日后扯皮时的(de)证据。这样才有利(lì)于(yú)拿到最真(zhēn)实的信息,方便(biàn)作(zuò)为正(zhèng)确的判断。
11、使用团队协作工具
工欲善其(qí)事,必先利其器。良好的(de)团队协(xié)作工具能够(gòu)减少团(tuán)队成员之间(jiān)的(de)沟(gōu)通成本。比如说通过统一(yī)沟通渠道从而节省时间(jiān)、避(bì)免(miǎn)重复沟通,自(zì)动(dòng)同(tóng)步信息(xī)等等(děng)。市场(chǎng)上的团队协(xié)作工具(jù)不少,找一个适合自己团队目前(qián)状况的,团队成(chéng)员大(dà)多(duō)数都用(yòng)过的。因为项目协(xié)作工具大同(tóng)小异,基本上可以满足你(nǐ)的团队协作(zuò)需求(qiú)。
12、有变化及时沟通
项目在做的过程中难(nán)免(miǎn)会(huì)出现变化的(de)地方,变化不可怕,可怕的(de)是变化之后其(qí)他成(chéng)员(yuán)不知道(dào)。你试(shì)想你(nǐ)更改一个(gè)需求,技(jì)术不知(zhī)道,技术(shù)还是(shì)按照之前的需求进行开发,等快开发完(wán)成(chéng)以后,技术(shù)知道需求(qiú)变了,会不会(huì)有杀人(rén)的冲(chōng)动?
其次能当面沟(gōu)通就别(bié)打电(diàn)话,当打电话(huà)就别发邮(yóu)件,一切以沟通高效(xiào)为主。
人少的时(shí)候,同步变化其实不是什么困难的事情,但人多的时候就有难度了。虽然很多协作工(gōng)具都有文档(dàng)更新通知,或者文档本身就有修改(gǎi)记(jì)录。但即便如此,也(yě)会有很(hěn)多人忽略(luè)这些变动(dòng)。在同步变化上,除了确保(bǎo)文档及时修改、告知(zhī)相关设计师、工程师和测试人(rén)员以外,我还会单独召集(jí)各平台的 leader 进行简单(dān)的站立会议,提醒其确认(rèn)变(biàn)更是否(fǒu)已安排执行,同时也相当于(yú)交接了监管的责任。
总结:上面就是(shì)个人在实践中管理项目进度的(de)一些感悟,管(guǎn)理项目进度不是一朝一夕的事情,需要在(zài)项(xiàng)目中反复的实(shí)践(jiàn)。