如何用产品思维迭代项目管理流程？（创业有感）

本文作者根据自己的创业经历，分享了项目管理以及产品版本迭代的相关经验。

18年3月份，接到一位创业兄弟的邀请，加入团队负责项目管理流程的规范，他表示：

现有项目的开发流程太乱，项目交付太慢。

刚开始接到这个需求，我的内心是很虚的，只有一年工作经验的PM Dog，哪有能力搞这么高大上的东西。

虽然顾虑重重，但想体验创业快感的我，还是硬着头皮上了，毕竟，万一失败了，亏的又不是我的钱……哈哈（奸诈脸）！

由于该公司扎根的垂直领域圈子太小，为了隐私起见，下文对该公司简称为：A公司。

背景

A公司是在某个垂直领域做专业的解决方案供应商，目标客户群体是大集团企业，项目周期一般是1年左右。

需求调研（用户访谈)

接手这个团队的时候，团队有20来号兄弟，其中市场部主要负责项目的同事有三名，大概了解了团队架构之后，我就询问市场部同事当前的项目管理流程。

他们是这么说的：

跟客户拿需求过来，如果自己无法评估技术的可实现性，就拿回来给研发，实现性没问题，就做……

然后我又去问了研发，研发的兄弟们是这么说的：

市场部那边，老是一句话需求，剩下的自己脑补，真让人吐血。有的时候，突然就来了个需求，明天就要上线，措不及防又是一顿熬夜赶工，交出一个应付性版本……

最后是技术部的兄弟们，他们是这么说的：

上线的版本老是不稳定，有的时候还没有测试就上线了，功能都跑不通，一脸懵逼。产品体验太差，运维压力太大，顶不住……

通过一轮的访谈下来，需求的流向看似很健康，由：市场->研发->技术->市场，其实幸亏兄弟们关系铁，不然早就拔刀相见了。

需求分析

第一、开发流程问题：没有对客户的需求进行“反馈式确定”，由开发人员直接做逻辑设计兼开发工作。

比如客户说，我要做库存管理。这一句话需求，有可能出现什么情况呢？

我方：哦，库存管理，那就做一个台账，显示客户的库存，再加个“增查改删”，OK，搞定。

1. 增：有新品种货物进库，新增该品种库存；
2. 查：品种太多，我加个查询框，便于快速找到该品种，查看其库存；
3. 改：库存数量有误，需要修改；
4. 删：该品种不做了，删除掉避免产生信息垃圾。

看似考虑得挺周全，其实还是有可能与客户的想法有出入的，比如：

1. 增：新增品种库存时需要输入哪些字段，哪些字段是必填的等等；
2. 查：需要对哪些字段进行条件查询功能；
3. 改：哪些字段可以修改，哪些字段不可以修改；
4. 删：在什么情况下可以删除，是否需要权限限制等等。

更多的可能有：台账是否具有 排序 功能、台账是否需要库存预警、库存预警阈值是否可自定义设置等等。

很多细节性的功能就这么忽略了。

如果你说，我们多替客户考虑，把我们能想到的功能都做上去，这样很容易造成开发资源的浪费。

如果做不到位，就会造成返工，客户对我们不信任，为后续的合作埋下隐患等等。

正确的做法是：

新增原型图评审环节：

就客户提出的需求，根据我们的理解及专业性判断，输出原型图，跟客户一起评审确定。

如果我方对功能的设计有疏忽之处，在原型图阶段就进行修改，直至满足甲方真正的需求，完成签字确定，再投入开发。

这样做的好处是：

1. 更好地将客户的需求还原出来，对比下我们的理解跟客户的需求是否有偏差。如果出现了偏差或者客户有需求变更，也只需要修改原型图，不需要修改代码，降低修改的成本。
2. 客户充分参与了设计，有了参与感，对后面开发出来的产品，也会比较有认同感，一般就不会有大的改动。毕竟，谁都不愿意打自己的脸。
3. 将开发人员进行逻辑设计的工作释放，由产品经理进行设计，再输出开发文档，开发人员只需要将文档语言转化为系统语言即可。避免出现开发兼设计导致逻辑考虑不足，功能跑不通的情况出现。

这样就解决了 一句话需求研发脑补、返工、功能跑不通、体验性太差 的问题。

第二、项目迭代节奏的问题。

创业公司人少事多且繁琐杂乱，现在的市场部同事并非纯真的项目经理。只是他们把东西卖给客户了，客户有什么诉求，第一个找的肯定是他们。所以慢慢的，他们也就成为了所谓的项目经理。

在这个背景下形成的项目经理，有以下特点：

1. 没有主动深入了解客户的使用情况，只会被动接受客户提过来的需求。
   这个是很多紧急需求的本质来源。没有站在整个项目的高度上做一些开发的规划，非得等客户真正需要用到了，发现没有这个功能，然后就找到了我们的项目经理，项目经理把需求带回来，做好了再更新到客户那边，事情完结。
2. 没有做一定的项目总结及系统价值的提炼。
   在整个项目的跟进过程中，项目经理充当了一个传话筒的角色，没有总结，就没有进步。没有价值点提炼，就没有存在感。最后导致我们的客户，对我们产生的印象是：我们说怎么样，你们就做成什么样，我们不说，你们也不会站在你们专业的角度来替我们思考。

基于这点，我觉得 职责需要明确，所以就以公司的名义发了封正式的公告，任命其为项目经理，对项目负责，需要把控项目的迭代节奏。

这样也就解决了 紧急需求 的问题。

协调各方资源，设计（包含了埋点设计）、开发、V1版本上线

基于以上的问题，我就做了以下三点措施：

1. 发文任命项目经理；
2. 梳理出开发流程，为全员做相关培训，项目经理主责落地跟进；
3. 制作甘特图，反映我司人员在项目上的具体投入，以了解项目的收入成本比。

关于埋点分析，来源于老板的诉求： 大家看起来都很忙，但项目交付太慢，导致回款出问题 ；

上图是我之前做产品时的项目管理经历，就想把它借鉴过来，记录下项目人员的投入分布图。

另外，给新入职产品/项目管理的童鞋一个建议： 好好管理产品/项目的迭代历程，便于自己总结回顾并针对性地提升自己！

产品上线后

产品上线以后，跟进用户反馈、埋点数据分析，以便更好地进行下个迭代版本的设计，不断靠近产品的目的。

关于埋点数据的采集，我是让每个人以日报的形式发给我，我再进行整理，归纳到项目管理表中，最后得到了以下分布图：

慢慢的，我觉得不太对劲：我都没有接到需求，但研发的同事一直在开发的路上。

更加奇怪的是：研发一直在不停的开发，但项目验收情况依旧不容乐观。对于一个初创团队来说，研发是一个比较重的开支，所以必须得搞清楚里面是什么原因，达到 开源节流 的目的。

于是我就梳理了一下记录，发现很多的工作都是在： 修改、修复、优化，而且极其碎片化 。

经过深入了解，原来都是在补之前的坑。比如之前给客户做了一个功能，主功能能跑通，但忽略了其他的异常情况，客户到现在才发现，就得进入紧急修复状态。

我也回访了一下各部门的同事，得到以下信息：

• 项目经理：工作量比较大，市场打单已经耗费了我很大精力了，又要跟进项目管理，有点兼顾不过来。有时候跟研发的同事在沟通需求，约好了时间节点，我去忙其他的了，研发的同事就忘了时间节点，导致任务的延期。
• 研发同事：任务太多太杂了，而且总是有新的需求插队，所以经常会先把那些催得紧的需求先做了，导致其他需求的延期。有些需求没人催，久而久之也就忘了。
• 技术部的同事：运维占了我们很大的一部分工作量，又没有专职的测试，所以只能借着运维的间隙测一测功能是否能跑通。有的时候客户催得紧，没有办法，来不及测试，只能直接上了。

另外，我发现了研发同事有一个问题： 没有进行版本管理；

个人觉得没有版本管理，会有以下缺点：

1. 增加同事间的沟通成本：研发更新了新版本，负责测试的技术同事没注意，还在测老版本。
2. 开发战线拉得比较长，团队成员心理负担会较大。
3. 在客户面前没有主动权。如果我们有做版本管理，我们可以说明版本上线的时间节点以及版本更新的内容，给我们自己喘息的时间，也显得我们有计划，比较专业。而不是客户说什么我们就做什么，而且是马上做。

综上所述，我总结下问题：

1. 项目经理精力有限，无法做到项目的有效管理；
2. 研发同事忙于补之前没有项目管理留下来的坑，而且还有很多隐形的坑有待发掘；
3. 研发工作比较碎片化，项目迭代没有节奏，导致需求插队等，造成有些任务的延期；
4. 由于有些bug没有办法及时修复，造成运维工作压力较大，没有精力测试新上线的版本，从而形成恶性循环；
5. 版本管理需要建立。

V1版本上线后

V1版本上线后，通过数据、用户反馈发现问题，就得设计一个新版本，来解决V1版本出现的问题，我把它定义为V2。

针对以上问题，我做出了以下措施：

1. 协助项目经理组建自己的小团队，由项目经理一个人主责变为项目经理主责、团队成员担责。

之前是项目经理跟研发同事提需求，有时候无法具体到给哪位研发同事提需求，造成沟通成本的浪费及事后推责等问题。

现在我就为每位项目经理都配了一名研发、技术同事，这样从项目经理、研发、测试、运维整个落地闭环就形成了，形成了N个作战小部队。该作战部队，由项目经理掌舵，其他成员积极配合，如果该团队负责的项目出现了问题，项目经理担担责，其他团队成员担小责。

2. 为了保证需求的流转记录，推出项目管理工具：禅道。

之前对于需求的流转，项目经理疲于督促管理，口头的流转存在很大的扯皮隐患，需求的流转记录急需立字据。

经过项目管理 工具 的调研，大家对禅道的应用比较感兴趣，所以选择了禅道作为项目的管理工具，并制定了以下管理流程：

这样整个需求的流转清晰了，大家有迹可循，避免信息的沟通失真。

3. 版本的管理

在我们的系统上线【版本日志】界面，并全员分享版本管理的好处。

V2版本上线，继续跟进用户反馈、数据分析

经过V2版本的优化上线，基本解决了以下问题：

1. 项目管理不再是一个人的责任，而是一个团队的责任，营造了团队的作战氛围；

2. 需求流转可视化，降低沟通成本，避免信息的传递失真；

3. 增强版本管理意识，增加版本迭代日志，建立自己的迭代节奏。

经过两个版本的迭代管理，基本解决了项目的管理问题，只留下一个问题暂时没有办法解决： 填之前项目的坑 。

本来想着该问题只能随着时间的推移慢慢得到根治。

不过随着时间的推移，我觉得问题，并没有那么简单： 来自旧项目上的需求源源不断，验收却迟迟没有进展，项目款回收比较困难。

经过了解，原来之前签的项目，需求颗粒度是很粗的，后续进场开发也没有进行详细的需求调研、需求确定等，都是跟客户口头确定大概要做成什么样子，再根据自己的判断做出来，交付给客户。

客户试用，有问题，提，我们改，一直如此的重复。客户也不会轻易签字，毕竟一签字，再开发就需要另外付钱了。

这就造成了之前提到的问题： 需求不断，开发很忙，项目交付却很慢，而且需求极其碎片化， 用户一会需要加这个字段，一会儿需要新增判断逻辑等等。

更致命的是，我们的专业性会慢慢的被磨没，直至客户说什么，我们就做什么，客户不说，我们也不会主动跟进。

目的地都无法确定在哪里，漫无目的地走着效率是最低。

我就跟各方同事确定，最后在市场部的同事那里得到了本质信息： 手头没有“菜单”，所以客户要什么，我们就答应做什么，项目亏不亏我不管，我们的任务是把项目签下来就ok。到时候做到什么样再去走“商务”，也就是靠关系。

这个让我大为惊讶， 我觉得我们做生意是平等的，你给我钱，我为您提供服务，必须要把账算清楚了，而不是靠走后门、刷老脸来验收项目。

结合用户调研及需求反馈，设计V3版本

于是我就着手开始制作“菜单”：

1. 把系统功能框架罗列出来，标上对应的售价，市场打单用。
2. 针对系统功能框架制作一份功能明细，后期进场调研时用。在这份功能明细上做增查改删，再由甲方签字，就可以进行后续的原型图设计、需求确定投入开发了。

这样就确保我们有了验收标准，有了依据有了目的地，更好地规划我们的迭代节奏。

版本迭代日志

总结一下在整个项目规范流程中的版本迭代日志

以上三个版本，就是我觉得最有里程碑意义的迭代历程，它让项目从需求的来源、落地、验收整个流转得以规范。看似简单，其中也走了不少弯路，希望可以给大家带来借鉴意义。

本文由 @铭创优品 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议