如何用产品思维迭代项目管理流程?(创业有感)_java、c++、机器学习方向King-CSDN博客_迭代项目管理
如何用产品思维迭代项目管理流程?(创业有感)
18年3月份,接到一位创业兄弟的邀请,加入团队负责项目管理流程的规范,他表示:
现有项目的开发流程太乱,项目交付太慢。
刚开始接到这个需求,我的内心是很虚的,只有一年工作经验的PM Dog,哪有能力搞这么高大上的东西。
虽然顾虑重重,但想体验创业快感的我,还是硬着头皮上了,毕竟,万一失败了,亏的又不是我的钱……哈哈(奸诈脸)!
由于该公司扎根的垂直领域圈子太小,为了隐私起见,下文对该公司简称为:A公司。
背景
A公司是在某个垂直领域做专业的解决方案供应商,目标客户群体是大集团企业,项目周期一般是1年左右。
需求调研(用户访谈)
接手这个团队的时候,团队有20来号兄弟,其中市场部主要负责项目的同事有三名,大概了解了团队架构之后,我就询问市场部同事当前的项目管理流程。
他们是这么说的:
跟客户拿需求过来,如果自己无法评估技术的可实现性,就拿回来给研发,实现性没问题,就做……
然后我又去问了研发,研发的兄弟们是这么说的:
市场部那边,老是一句话需求,剩下的自己脑补,真让人吐血。有的时候,突然就来了个需求,明天就要上线,措不及防又是一顿熬夜赶工,交出一个应付性版本……
最后是技术部的兄弟们,他们是这么说的:
上线的版本老是不稳定,有的时候还没有测试就上线了,功能都跑不通,一脸懵逼。产品体验太差,运维压力太大,顶不住……
通过一轮的访谈下来,需求的流向看似很健康,由:市场->研发->技术->市场,其实幸亏兄弟们关系铁,不然早就拔刀相见了。
需求分析
第一、开发流程问题:没有对客户的需求进行“反馈式确定”,由开发人员直接做逻辑设计兼开发工作。
比如客户说,我要做库存管理。这一句话需求,有可能出现什么情况呢?
我方:哦,库存管理,那就做一个台账,显示客户的库存,再加个“增查改删”,OK,搞定。
增:有新品种货物进库,新增该品种库存;
查:品种太多,我加个查询框,便于快速找到该品种,查看其库存;
改:库存数量有误,需要修改;
删:该品种不做了,删除掉避免产生信息垃圾。
看似考虑得挺周全,其实还是有可能与客户的想法有出入的,比如:
增:新增品种库存时需要输入哪些字段,哪些字段是必填的等等;
查:需要对哪些字段进行条件查询功能;
改:哪些字段可以修改,哪些字段不可以修改;
删:在什么情况下可以删除,是否需要权限限制等等。
更多的可能有:台账是否具有排序功能、台账是否需要库存预警、库存预警阈值是否可自定义设置等等。
很多细节性的功能就这么忽略了。
如果你说,我们多替客户考虑,把我们能想到的功能都做上去,这样很容易造成开发资源的浪费。
如果做不到位,就会造成返工,客户对我们不信任,为后续的合作埋下隐患等等。
正确的做法是:
新增原型图评审环节:
就客户提出的需求,根据我们的理解及专业性判断,输出原型图,跟客户一起评审确定。
如果我方对功能的设计有疏忽之处,在原型图阶段就进行修改,直至满足甲方真正的需求,完成签字确定,再投入开发。
这样做的好处是:
更好地将客户的需求还原出来,对比下我们的理解跟客户的需求是否有偏差。如果出现了偏差或者客户有需求变更,也只需要修改原型图,不需要修改代码,降低修改的成本。
客户充分参与了设计,有了参与感,对后面开发出来的产品,也会比较有认同感,一般就不会有大的改动。毕竟,谁都不愿意打自己的脸。
将开发人员进行逻辑设计的工作释放,由产品经理进行设计,再输出开发文档,开发人员只需要将文档语言转化为系统语言即可。避免出现开发兼设计导致逻辑考虑不足,功能跑不通的情况出现。
这样就解决了 一句话需求研发脑补、返工、功能跑不通、体验性太差 的问题。
第二、项目迭代节奏的问题。
创业公司人少事多且繁琐杂乱,现在的市场部同事并非纯真的项目经理。只是他们把东西卖给客户了,客户有什么诉求,第一个找的肯定是他们。所以慢慢的,他们也就成为了所谓的项目经理。
在这个背景下形成的项目经理,有以下特点:
没有主动深入了解客户的使用情况,只会被动接受客户提过来的需求。
这个是很多紧急需求的本质来源。没有站在整个项目的高度上做一些开发的规划,非得等客户真正需要用到了,发现没有这个功能,然后就找到了我们的项目经理,项目经理把需求带回来,做好了再更新到客户那边,事情完结。没有做一定的项目总结及系统价值的提炼。
在整个项目的跟进过程中,项目经理充当了一个传话筒的角色,没有总结,就没有进步。没有价值点提炼,就没有存在感。最后导致我们的客户,对我们产生的印象是:我们说怎么样,你们就做成什么样,我们不说,你们也不会站在你们专业的角度来替我们思考。
基于这点,我觉得 职责需要明确,所以就以公司的名义发了封正式的公告,任命其为项目经理,对项目负责,需要把控项目的迭代节奏。
这样也就解决了 紧急需求 的问题。
协调各方资源,设计(包含了埋点设计)、开发、V1版本上线
基于以上的问题,我就做了以下三点措施:
发文任命项目经理;
梳理出开发流程,为全员做相关培训,项目经理主责落地跟进;
制作甘特图,反映我司人员在项目上的具体投入,以了解项目的收入成本比。
关于埋点分析,来源于老板的诉求: 大家看起来都很忙,但项目交付太慢,导致回款出问题;
上图是我之前做产品时的项目管理经历,就想把它借鉴过来,记录下项目人员的投入分布图。
另外,给新入职产品/项目管理的童鞋一个建议: 好好管理产品/项目的迭代历程,便于自己总结回顾并针对性地提升自己!
产品上线后
产品上线以后,跟进用户反馈、埋点数据分析,以便更好地进行下个迭代版本的设计,不断靠近产品的目的。
关于埋点数据的采集,我是让每个人以日报的形式发给我,我再进行整理,归纳到项目管理表中,最后得到了以下分布图:
慢慢的,我觉得不太对劲:我都没有接到需求,但研发的同事一直在开发的路上。
更加奇怪的是:研发一直在不停的开发,但项目验收情况依旧不容乐观。对于一个初创团队来说,研发是一个比较重的开支,所以必须得搞清楚里面是什么原因,达到 开源节流 的目的。
于是我就梳理了一下记录,发现很多的工作都是在: 修改、修复、优化,而且极其碎片化 。
经过深入了解,原来都是在补之前的坑。比如之前给客户做了一个功能,主功能能跑通,但忽略了其他的异常情况,客户到现在才发现,就得进入紧急修复状态。
我也回访了一下各部门的同事,得到以下信息:
项目经理:工作量比较大,市场打单已经耗费了我很大精力了,又要跟进项目管理,有点兼顾不过来。有时候跟研发的同事在沟通需求,约好了时间节点,我去忙其他的了,研发的同事就忘了时间节点,导致任务的延期。
研发同事:任务太多太杂了,而且总是有新的需求插队,所以经常会先把那些催得紧的需求先做了,导致其他需求的延期。有些需求没人催,久而久之也就忘了。
技术部的同事:运维占了我们很大的一部分工作量,又没有专职的测试,所以只能借着运维的间隙测一测功能是否能跑通。有的时候客户催得紧,没有办法,来不及测试,只能直接上了。
另外,我发现了研发同事有一个问题: 没有进行版本管理;
个人觉得没有版本管理,会有以下缺点:
增加同事间的沟通成本:研发更新了新版本,负责测试的技术同事没注意,还在测老版本。
开发战线拉得比较长,团队成员心理负担会较大。
在客户面前没有主动权。如果我们有做版本管理,我们可以说明版本上线的时间节点以及版本更新的内容,给我们自己喘息的时间,也显得我们有计划,比较专业。而不是客户说什么我们就做什么,而且是马上做。
综上所述,我总结下问题:
项目经理精力有限,无法做到项目的有效管理;
研发同事忙于补之前没有项目管理留下来的坑,而且还有很多隐形的坑有待发掘;
研发工作比较碎片化,项目迭代没有节奏,导致需求插队等,造成有些任务的延期;
由于有些bug没有办法及时修复,造成运维工作压力较大,没有精力测试新上线的版本,从而形成恶性循环;
版本管理需要建立。
V1版本上线后
V1版本上线后,通过数据、用户反馈发现问题,就得设计一个新版本,来解决V1版本出现的问题,我把它定义为V2。
针对以上问题,我做出了以下措施:
1. 协助项目经理组建自己的小团队,由项目经理一个人主责变为项目经理主责、团队成员担责。
之前是项目经理跟研发同事提需求,有时候无法具体到给哪位研发同事提需求,造成沟通成本的浪费及事后推责等问题。
现在我就为每位项目经理都配了一名研发、技术同事,这样从项目经理、研发、测试、运维整个落地闭环就形成了,形成了N个作战小部队。该作战部队,由项目经理掌舵,其他成员积极配合,如果该团队负责的项目出现了问题,项目经理担担责,其他团队成员担小责。
2. 为了保证需求的流转记录,推出项目管理工具:禅道。
之前对于需求的流转,项目经理疲于督促管理,口头的流转存在很大的扯皮隐患,需求的流转记录急需立字据。
经过项目管理工具的调研,大家对禅道的应用比较感兴趣,所以选择了禅道作为项目的管理工具,并制定了以下管理流程:
这样整个需求的流转清晰了,大家有迹可循,避免信息的沟通失真。
3. 版本的管理
在我们的系统上线【版本日志】界面,并全员分享版本管理的好处。
V2版本上线,继续跟进用户反馈、数据分析
经过V2版本的优化上线,基本解决了以下问题:
1. 项目管理不再是一个人的责任,而是一个团队的责任,营造了团队的作战氛围;
2. 需求流转可视化,降低沟通成本,避免信息的传递失真;
3. 增强版本管理意识,增加版本迭代日志,建立自己的迭代节奏。
经过两个版本的迭代管理,基本解决了项目的管理问题,只留下一个问题暂时没有办法解决: 填之前项目的坑 。
本来想着该问题只能随着时间的推移慢慢得到根治。
不过随着时间的推移,我觉得问题,并没有那么简单: 来自旧项目上的需求源源不断,验收却迟迟没有进展,项目款回收比较困难。
经过了解,原来之前签的项目,需求颗粒度是很粗的,后续进场开发也没有进行详细的需求调研、需求确定等,都是跟客户口头确定大概要做成什么样子,再根据自己的判断做出来,交付给客户。
客户试用,有问题,提,我们改,一直如此的重复。客户也不会轻易签字,毕竟一签字,再开发就需要另外付钱了。
这就造成了之前提到的问题: 需求不断,开发很忙,项目交付却很慢,而且需求极其碎片化,用户一会需要加这个字段,一会儿需要新增判断逻辑等等。
更致命的是,我们的专业性会慢慢的被磨没,直至客户说什么,我们就做什么,客户不说,我们也不会主动跟进。
目的地都无法确定在哪里,漫无目的地走着效率是最低。
我就跟各方同事确定,最后在市场部的同事那里得到了本质信息: 手头没有“菜单”,所以客户要什么,我们就答应做什么,项目亏不亏我不管,我们的任务是把项目签下来就ok。到时候做到什么样再去走“商务”,也就是靠关系。
这个让我大为惊讶, 我觉得我们做生意是平等的,你给我钱,我为您提供服务,必须要把账算清楚了,而不是靠走后门、刷老脸来验收项目。
结合用户调研及需求反馈,设计V3版本
于是我就着手开始制作“菜单”:
把系统功能框架罗列出来,标上对应的售价,市场打单用。
针对系统功能框架制作一份功能明细,后期进场调研时用。在这份功能明细上做增查改删,再由甲方签字,就可以进行后续的原型图设计、需求确定投入开发了。
这样就确保我们有了验收标准,有了依据有了目的地,更好地规划我们的迭代节奏。
版本迭代日志
总结一下在整个项目规范流程中的版本迭代日志
V1:
施行项目经理制,责任到人;
梳理出开发流程,为全员做相关培训,项目经理主责落地跟进;
制作甘特图,反映我司人员在项目上的具体投入,以了解项目的收入成本比。
V2:
组建项目作战小团队,主责到人、团队担责;
借助项目管理工具,做好需求的流转记录;
制定版本规范制度,上线【版本日志】模块。
V3:
上线系统功能清单及报价;
上线系统功能明细,确保有验收标准。
以上三个版本,就是我觉得最有里程碑意义的迭代历程,它让项目从需求的来源、落地、验收整个流转得以规范。看似简单,其中也走了不少弯路,希望可以给大家带来借鉴意义。