小明与老王的日常:学会做这4件事,让你的产品提前上线(2)

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

太多的产品新人,甚至于工作1两年的产品汪,在开发阶段往往出现很多对接问题,影响上线进度。在此,我将程序开发阶段总结为一下4个流程,并会用故事的形式,分流程介绍我们该如何与开发对接。因内容较多,且需要与实际工作结合进行考虑,所以建议大家收藏下来,慢慢看。

下图为此系列内容的大纲

(此系列内容的大纲)

今天我们聊聊第2部分,制定开发流程与关键节点。如果没有看过第1篇文章的,请点击下面的传送门:《小明与老王的日常:学会做这4件事,让你的产品提前上线(1)》

第二天,小明按照老王的吩咐,召集了技术部的同事们进行了项目评估会议,会议中,小明从项目背景介绍、功能流程介绍、关键目标确定三个方面,向程序猿们描述了接下来要开发的产品。会后,老王将小明叫到了会议室,习惯性的点了一根烟,深吸了一口说道:小明,还不错,该讲清楚的都讲清楚了,就是在讲的时候,需要再自信点。你要对自己的产品有自信,别人才会认可你的产品。您说是吧。

小明:嗯,都是王总教的好,以后我会记住的。对了王总,那接下来我该做什么呢?

老王:别急,这次叫你过来,就是跟你说接下来的事情的。开会前,你是不是把产品原型、产品说明文档、设计稿、交互稿都交给程序猿了?

小明:嗯,是的,都发给他们了。

老王:好,那接下来,你需要做的就是协调项目经理、程序猿们一起确定项目的工作量开发顺序关键节点。当然了,我们公司没有专职的项目经理,这个你可以直接找孙总。(孙总是公司的技术总监)

确定项目开发工作量

老王抽了口烟,继续说道:首先呢,你先去找项目经理沟通一下,看项目经理能否在近期(一周左右)对项目的开发量进行一个评估。至于这个评估时间,你不要卡的太死,给他们充足的时间去仔细研究。这个阶段是程序猿了解需求的时候,我们需要给他们充足的时间去研究需求,只有需求研究透了,才不会出那么多bug嘛。

老王:那在这个阶段,你可能会遇到下面这几种种情况:

  1. 程序猿需要你帮忙解释需求。
  2. 程序猿给产品提修改建议。
  3. 程序猿要求砍掉部分需求。
  4. 提交的PRD、设计稿、交互稿缺少部分内容。
  5. 反馈回来的工作量评估表很粗糙。

小明:王总,上面这几种种情况,第4个我会处理,缺少的内容我回去找一下,看看是不是我提交的时候遗漏了,如果确实是没有做的话,到时候再从新做一下,补给他们就好了。那剩下的几个问题呢?通常我们都是怎么处理的?

老王:别急,让我慢慢跟你说。这第1个问题呢,是我们肯定会遇到且必须要做的事情。不过在做的时候,一定注意不能太急躁,不能一上来就说:需求里面说的很清楚啊,就是这这样···那样····。如果你这样做的话,程序猿肯定给你一个大大的白眼,心里想:我TM能看懂我还让你解释什么?这个时候正确的姿势应该是,从场景出发,解释用户在日常工作中是怎么使用这个功能的。如果是问到一些数据调用的问题,需要说明数据是在哪里产生的,这样程序猿们会清楚哪些数据是需要从新建立数据表,哪些是已经有现成的数据。当然了,如果你短期内也解释不清楚的话,就诚实的跟程序说,我先回去看看,等等给你答复。不要在自己不清楚的时候下结论。

老王:第2个问题呢,当程序猿给你提修改建议的时候,一定不要直接否定了,很多好的创意,都是程序猿想出来的。如果程序猿提出来的建议是你之前思考过的,你可以把你之前考虑的思路跟他沟通一下,如果能说服他最好,如果说不不了他,而且此功能对用户没有太大影响的话,可以适当的进行修改。那如果程序猿提出的建议是之前没有考虑过的,这时候你要仔细听一下程序猿是怎么说的,不要当场回复,回来再考虑一下,整理一下方案是否可行,再去沟通确认。这个时候记住一点,所有的建议,必须以方案的形式进行落地。这才有执行价值。

老王停顿了一下,看看若有所思的小明,缓缓道:那我们说说第3个问题,就是程序猿砍需求的情况。这个问题在每个项目的开发过程中,都是经常遇到的,而且还是产品经理与程序猿产生矛盾的集中点。所以在遇到这种情况之前,你首先需要弄清楚你的产品的核心功能(不可缺少的功能)是什么,辅助功能(存在会有更好的体验,没有也不影响正常使用)是什么、意淫需求(没有使用场景或者说使用场景不实际的需求)是什么,模棱两可的需求(这样也行,那样也行)。

当程序猿要求砍掉意淫需求与模棱两可的需求时,应果断砍掉。甚至于在他们没提出来之前,就应该砍掉这里面的部分需求。当提出要砍辅助功能的时候,我们就需要进行合理且善意的引导,尽量让程序员接受这个功能,可以通过场景进行引导,让程序猿觉得这是个有用的功能,能带来价值的功能。如果程序猿坚决要砍掉,我们就需要适当的做妥协,可以将这个功能放在最后开发,甚至于下一期来进行开发,尽量不要产生争执(这种功能体量普遍较小,开发周期比较快,最后开发与放在下个版本开发,对用户没有太大的影响)。至于核心功能,你需要死死的拽在手里,谁说都不能改,这个是原则上的问题。当然了,我让你改的时候,你还是要听话的。

小明:王总,我怎么感觉在这3个问题的处理方式上,都是在一直迁就着程序猿啊?

老王:这你就不懂了,这是套路。那我问你,在上面这3个问题的处理方式上,你核心功能有没有变动?

小明摇摇头道:没有。

老王:这就对嘛,我们做产品的目的,主要是看结果的,只要结果达到了,怎样都行。而在这个过程中,充分采纳程序猿的建议,一部分是有利于产品更好的发展,毕竟程序猿提出的部分建议,还是很有价值的;另一部分呢,就是让程序猿多参与到产品的规划建设中来,增加他们的主人翁精神(这个最好在规划阶段,就多跟技术进行沟通)。只有这样才能实现我昨天跟你说的,让程序猿踏上你的“贼船”。

小明想了一会,说道:王总,套路挺深啊,那您继续说,下面两个问题怎么解决?

老王:第4个问题,就是提交的PRD、设计稿、交互稿缺少部分内容的情况,这个你刚才也说了一个解决办法,这里我再给你补充一下,当项目比较紧急的时候,程序的开发与内容的补充可以同步进行。

老王:最后1个问题,反馈回来的工作量评估表很粗糙的问题。评估表内容粗糙,很大的问题在于你跟项目经理的沟通问题上。对于大多数程序猿来说,都不愿意去做写一份对后续开发没多大作用的评估表。这时,你需要跟项目经理提前沟通好,说明清楚要写一份详细的工作评估表重要性,让他协调程序猿来完成这项工作。这里我总结为两点,

第一点:评估表的详细程度,直接反应了程序猿对项目的了解程度。对于我们产品经理而言,我们不需要那么详细的评估表,我们需要的是让程序猿在写评估表的过程中,充分的了解产品需求,这样才能避免后续开发过程中不出现较大的问题。

第二点:详细的评估表也有利于项目经理对项目的管理与跟踪,对项目管理有非常重要的作用。

老王掐灭了手中的快烧尽的烟头,淡淡的说道:其实在这个阶段,归根接地就是一句话:尽可能的创造机会让程序猿们了解产品的需求,并赋予他们主人翁精神,而不是停留在表面。当工作量都已经评估好之后,我们就需要计算一下开发总时长了。在这个时候,我们需要结合公司的要求,如果公司要求必须在9月30号之前完成开发,而我们评估的时间只能在10月10号完成,那我们需要跟项目经理协调压缩项目时间。压缩项目时间可以通过增加项目成员与有效加班的方式进行处理。这个后面我有时间再跟你细讲。

确定开发顺序

老王:第一步已经跟你讲清楚了,接下来我们聊聊如何确定开发顺序。关于开发顺序,我们重点说一下两个顺序,1个是前端与后端的开发顺序;1个是功能模块的开发顺序。

老王:关于前端开发与后端开发,你能分的清吧。

小明:前端就是写页面的,后端就是写数据的,我可以这样理解吧?

老王:嗯,这样理解没毛病。从前端与后端的工作内容来看,在一些地方是没有依赖性的。例如:前端在没有数据的情况下,是可以写一些页面样式的。后端在没有前端的支持下,也是可以写一些数据接口的。那我们就可以理解为,前端与后端是可以同步进行开发的对吧。

小明:嗯。

老王:你过来看一下这张图,这是我整理的一份程序员开发顺序图。

注:具体项目的开发的开始时间可能不同,道理是一样的,前端开发与后端开发可以同步进行,但是需要保证前端在进行数据对接的时候,后端提供足够的可用数据。

小明:王总,后端开发为什么跟前端开发一起开始啊,我记得都是先切完图后端才开始开发的啊?还有就是后端开发后面有个空白的框,是什么东西啊?还有还有,就是最后那个测试,为什么跟开发一起啊,不是做完了才进行测试的吗?

老王:又着急了不是,年轻人,要稳重点。好好看图,每个横向的柱状图中,都包含了具体的开发流程,在前端进行切图、框架选取、交互开发的时候,是不需要后端提供数据的,只需要设计稿与交互稿就可以完成了。而后端开发的的过程中,数据库设计、框架选取、编写数据库接口只需要demo与PRD文档就可以解决,也不需要前端提供页面,所以这样看的话,不相干的工作是可以同时开始并进行的。

而后端开发的那个空白的框,是修改bug的时间。因为在开发过程中,前端开发中“对接数据库接口”这个过程,是需要后端“编写数据接口+功能实现”两部分做支撑的,换句话说,后端的工作进度必须领先于前端的开发进度。所以后端开发通常会提前完成,那剩下的这个时间就是用来进行bug修改与功能调试的。而关于产品测试的时间安排,就是接下来我要讲的第2部分,确定功能模块的开发顺序。

功能模块开发顺序,顾名思义就是描述先开发哪些功能模块,再开发哪些功能模块。这就跟我上次跟你说的那个讲解产品的顺序一样,要有一个先后顺序。忘记了你去翻一下上次的笔记《小明与老王的日常:学会做这4件事,让你的产品提前上线(1)》就知道了。确定这些开发顺序后,是方便我们再程序为开发完成就进入测试阶段,从而节省测试的时间。这下知道为什么测试阶段与开发阶段放在一起了吧。

明确关键节点

小明:嗯,这下清楚了。王总,您渴不渴,我去给你倒杯水。

老王:不用了,我想喝脉动,给我买一瓶脉动吧。

小明一脸鄙视,无奈地去楼下便利店给老王买了瓶脉动,并给自己买了瓶阿萨姆。

老王喝了一口脉动,缓缓地说:还有最后一个阶段了,那就是确定关键节点。这个阶段的主要目的是便于我们与项目经理对开发进度进行把控,这里呢,我们会用到两张表,这两张表分别是上面提到过的开发量评估表与功能模块开发顺序表。将这两张表组合在一起,就能确定我们项目的关键节点了。

而这张表中需要包含项目的开始时间与结束时间;每个模块的开始时间与截止时间(前端与后端是分开的,功能模块的完成时间以前端为准);每个模块(功能)的负责人、完成情况与备注等信息。其中,功能模块的划分与开发顺序是由功能模块开发顺序表提供的。具体功能的负责人与时间,是由项目评估表提供的。有了这张表,就可以对项目开发过程进行有效的管理。你过来,我找个之前项目的表给你看下。

(此处的数据为模拟数据)

老王:能理解吗?

小明:嗯,大体清楚了,回去我再整理一下,如果还有疑问,我再咨询您。我走了,王总。

老王:嗯,走的时候帮我带上门。

老王看着渐渐走出办公室得小明,点了一根烟,缓缓地道:哎,天生就是个操心的命!

相关阅读

《小明与老王的日常:学会做这4件事,让你的产品提前上线(1)》

 

作者:李英杰,二一教育高级产品经理,主要负责题库类产品的规划与运营工作。

本文由 @李英杰 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pixabay,基于 CC0 协议

祝给予赞赏的伙伴,2017年发大财!
4人打赏

评论( 16

写下你的想法
  1. 有希望一起学习,一起进步的小伙伴,可以加老王微信liyingjie153804

    回复
  2. 以讲故事的形式讲知识,跟《人人都是产品经理》这本书有点像,目前正在开发一款产品,每个节点跟您讲的都一样一样的;有个疑问就是,怎么才能如期完成啊,程序猿每天都抱怨这有问题,那有难度;但是从来不加班,怎么才能激励大家加班呢?

    回复
    1. 回复

      加班本来就是个病态,所以我不提倡加班,至于如何按期完成开发,下面一篇文章会重点介绍,记得关注哦

  3. “混”了大半年的产品经理了,第一次如此清晰的知道产品推进这个过程,求项目跟进表的模板,继续跟进老王叔~ :oops:

    回复
    1. 回复

      项目跟进表的模块可以自己根据项目进行制作,只要不遗漏关键元素就可以了

    2. 回复

      好嘞 谢谢叔~ 期待自己将来也能脑子清楚的完成一整个项目~

  4. 你不仅是一名产品经理而且还是一名段子手。

    回复
    1. 回复

      段友出征,寸草不生!吼~~

  5. 哈哈,非常生动有趣的讲解,给产品小白很好的启发,期待后续的更新 :mrgreen:

    回复
    1. 回复

      谢谢您的支持,好看的话记得多关注老王的新作哦

  6. 终于找到一篇系统讲解产品经理每个阶段要做什么事并且怎么做的文章了,小白产品很受用!感谢 ;-)

    回复
    1. 回复

      谢谢,如果觉得有用,不如分享给其他同事看看

  7. 老王,总结还不错哟

    回复
    1. 回复

      哈哈,想想自己踩过的坑。真是一把血泪史

  8. 话糙理不糙,讲到了很多关键点。只是最后的计划表还有合并单元格,这样表格能做筛选跟统计么,是不是都结构化会好一点

    回复
    1. 回复

      这个表格如果用来统计的话,确实是有点不太合适,不过这个表格主要是用来进行项目跟踪的,如果要做项目统计的,需要按照统计的需求,建立项目分表。

推荐阅读