产品通过定时迭代版本来新增和优化功能,一个产品、版本或功能都是一个个内部项目,如何在一个确定的有限的时间段内,准时高效地交付高质量产品,就显得格外重要。大部分的公司没有内部项目经理,产品经理算是研发团队中最懂管理的人,并且是产品 owner,所以责无旁贷的需要负责内部项目管理的职责。
如果一个产品经理没有项目管理的经验、也没有系统性学习过项目管理的知识,那么内部项目可能面临很大的失败风险。下面总结了几点项目管教心得!!!
避免定位不清晰,目标不统一
项目开始时基础共识没有达成,定位模糊不清;之后的设计、开发因此频繁改动变化;再加上所有人对准出标准目标要求不统一,这些不确定性足够让项目失败。开始一个新的版本迭代,或开发一个新功能,需要在项目开启的时就确定以下问题:
- 功能价值:实现该功能改变了什么现状,解决了什么问题,能够带来什么价值。如果无法回答或不清晰,那么需要从新调研,甚至停止项目,因为不清楚价值,等于做了没有回报。
- 功能定位:你做的一个什么样功能,比如基础功能, 魅力功能等。
- 功能目标:项目结束后,实现哪些功能,这些功能的标准是什么。
- 开发信息:该功能在哪个版本开发(当一个产品有多个版本时),该功能是内置还是插件等信息。
- 项目时间:项目时间需要谨慎计算的,避免拍大腿决定。因为时间节点无达给出标准交付物,在某种意义上项目是失败的。时间需要相关人员进行评估,以及留出足够的缓冲时间。
- 项目成员:项目成员一定要确定,且得到相关人的知晓,因为可以避免后期成员会流动变化,比如成员被拉去临时项目。
- 项目负责人:确定项目负责人是谁,避免因角色不清晰,导致项目无人负责。或者说确定产品经理是不是项目的负责人。
当上述信息清晰确定后,就可以 Kickoff 了,将上述信息传达给相关人员,作为项目负责人一定要主动、频繁、大范围的传播,让每个人都了解,尽量降低项目的不确定性。
分期完成,避免停滞
产品经理喜欢在一个版本将功能做的尽善尽美,做出让人眼前一亮的功能。但大部分是大招没有憋出,反倒项目延期。产品经理需要遵循 MVP 原则,在项目的定位和目标的基础上,整合现有资源,将最大的价值打包交付,得到项目回报。所以在做需求时候,可以将需求分类分级,尽量在第一期实现基本型需求,而不要在魅力型需求停滞不前。否则项目结束了,却什么成果也没有。
避免成员变动
一个项目的成员不足,加班加点还是可以准时完成。但是如果一个项目成员频繁变动,那么这个项目失败的可能性就很大,主要是两方面原因:一是重复对接和沟通,需要告知新成员的工作内容及各种工作交接;第二是新成员不适合当前空缺或做不必要工作,比如整体代码架构不熟悉,甚至需要修复上一位遗留的 BUG。
项目计划及节点交付物
工作任务的评估难以量化,所以大部分项目成员都不仔细评估工作量,认为评估有什么用,只要准时完成就可以,最后完成不了又说时间不足。
项目前期需要认真评估各阶段所需的时间,并在总评估时长上留出 10% 缓冲时间,再作出详细的项目计划。比如我们经常会低估需求和设计工作量,但是一个正确的研发周期,需求设计和技术设计时间要占整个项目时长的 30% ,如果低于这个时间,那么前期设计工作做的肯定不充分,后期很有可能会频繁修改设计、接口等。
一个项目计划时间少则两周、多则几个月,所以不能最后统一交付,因为最后的交付的可能是一坨?,甚至连屎都交付不出来。所以需要指定项目时间节点,并制定每个节点的交付物,比如使用 TR1-TR7 的研发流程:
- 需求:产品经理进行用户调研、竞品分析,输出需求列表,并让相关人员进行评估,确定项目内完成的需求。
- 计划:需求可行性分析、人员安排、时间安排、形成任务书。
- 系统设计:PRD、技术详细设计(API 、架构图)。
- 研发:初版本的软件和交付文档,研发尽量分多个阶段进行验收,比如几个子功能一个 RC 版本。
- 测试与版本迭代:测试进行功能测试,研发进行迭代开发。
- 封板验证:测试进行回归测试,重要问题需进行评估是否修复。
- 发布:正式版本软件和发布相关文档。
项目负责人需要每周对这些时间节点的交付物进行进度跟踪和更新,如果发现某个节点出现延期、或交付物质量不符,应该及时找人协助,也要对项目时间进行调整。
直面困难,抛出问题
项目中会遇到很多问题,不要装作看不见问题,也不要想着只凭借自己一己之力解决问题。项目是一个团队合作的结果,我们需要直面困难,专心去学习解决问题,如果项目成员无法解决,需要及时对外抛出问题,找更有能力的人解决,至少让相关人员知道目前的问题,而不是项目成员默默等待。问题和困难不会因为时间而消失,最终还是需要解决,及时抛出和专心解决才是王道。
评审和质量把控
设计被修改是正常的事情,比如交互、样式,或者部分 API。但如果按照设计稿一比一开发,但在功能开发完成后,说设计不对,需要修改。那么各个评审会的时候干嘛呢?我认为主要以下原因导致评审会没有提出问题:
- 设计稿没有分享传播,可能是忘记、也可能是怕他人提出问题,仅在评审会过了一遍。评审会人员在简短的时间内只会查看主流程是否可行,不会对细节进行深究,所以不会提出更细节的问题。
- 设计稿和真正使用体验不同,有的问题只有在真正使用后才会发现问题,尽量做到高保真且具备交互的设计
- 交付物的输出标准不同,可能评审人员认为可通过,但是以老板的标准,可能就会被驳回。
- 产品对问题没有考虑完善,害怕频繁修改设计稿被开发怼,忍受了一些已知的问题,但在最后交付时被全部暴露。
从需求——设计——开发整个过程,一定要正式认真开好每一个评审会。评审会的资料需要准备充分,考虑详细;在开会之前将资源进行分享,提前找相关人员 review,更要多找老板、或经验更丰富的同事把关;最后就是发现问题及时修改,不要敷衍过去。评审会过完,一定要确保所有问题都解决了,且通知到相关人员。
项目负责人、产品经理、开发人员在一定程度上会有知识盲区,会忽略一些问题。所以项目需要更多经验丰富的人员来把控产品质量,比如高级研发工程师或架构师把控架构、组件、API、高可用等问题;设计师把控界面样式、交互逻辑。如果考虑不周,轻度影响后期拼命修改设计,验证可行性,改架构;更严重的是这些问题在测试发布时都没有显露,在客户环境发现问题,出现事故。
准时验收
项目应该遵循各时间节点的交付物,准时进行验收。验收发现问题时,重新评估问题风险是否影响项目整体进度,如果有影响,需及时反馈和调整。永远不要在项目结束对外解释因为未知问题导致延期。比如某子功能完成后,产品经理需对功能进行验收,设计师需对界面布局样式和设计稿进行对比,测试进行功能测试。一定要避免所有问题在最后发现, 在最后提出。
后记
某个项目是在测试阶段发现很多问题,导致项目成员加班一周才解决,搞得大家身心疲惫。不只是加班累,更重要成员失去信心,对自己的付出产生了怀疑,一个好的产品怎么会后期大量修改呢?
另外一个项目是因为项目定位、目标不明确,又遇到无法解决的问题,结果在项目后期才暴露出来,导致项目长时间延误。
对于一个没有内部项目经理的公司,产品经理或者技术人员作为项目负责人时,真的太难了,因为他们不具备专业的项目管理知识,更没有评估项目风的经验,所以项目很容易失败。
总结: 平时需要多读专业书籍。