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

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. 针对系统功能框架制作一份功能明细，后期进场调研时用。在这份功能明细上做增查改删，再由甲方签字，就可以进行后续的原型图设计、需求确定投入开发了。

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

版本迭代日志

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

V1：

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

V2：

• 组建项目作战小团队，主责到人、团队担责；
• 借助项目管理工具，做好需求的流转记录；
• 制定版本规范制度，上线【版本日志】模块。

V3：

• 上线系统功能清单及报价；
• 上线系统功能明细，确保有验收标准。

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

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

题图来自Unsplash，基于CC0协议