你以为的不一定就是你以为的。
了解我的人都知道，我会经常问项目管理人士一个问题，“你们的真实项目流程是怎样的，最常见的是什么问题？”，往往我得到的回复是这句话“你以为的不一定就是你以为的”。
解释一下，这句话有两个含义，其一、真实的项目场景会远远比我们讲到的流程复杂的多，理论知识活用很重要；其二、理解误差导致沟通障碍，影响进度。
第二个问题：“那么，你们觉得需要我们做些什么，可以有所帮助”。回答是：“真实场景案例的补充”。所以，我们也在极力的找真实的实例给大家。
这是一篇很典型的项目管理流程，集结了很多项目中常遇的痛点：弱矩阵型组织、客户需求常变更、无法拒绝镀金要求等。而且做出了不菲的结果，以现有的市场份额与技术能力估算，这是一个生命周期可以持续8-10年的产品，值得大家参考。
因为干货较多，为了让大家更好的阅读，给大家做了思维导图，大家可按需要重点阅读。
大多数“软件人”都曾面临过这样的问题，金主爸爸临时提出一个很迫切的需求，用来解决他们当前的问题。这个需求可能导致产品失败的风险很大，而除了这种现象以外，过程中还可能有多次需求变更。更让人为难的是，通常情况下会要的很急，今天告诉你需求，恨不得明天就要看到产品。
每次遇到这样的需求，公司、产品经理都感觉在走一步“险棋”。一着不慎，就做成了亏了人力物力还不讨好的买卖。当然我也没有跑掉，2020年曾经历了这种情况，当时是通过NPDP中学到的门径流程和敏捷开发两个工具结合才解决的问题。因为收获很多，所以想和大家分享一下，希望对大家有所启发。门径有很详细的规划，每一个阶段结束都会有评审，从而最大程度上降低失败带来的损失。为了应对变化而生的工具，在很好的适应需求不断变更的同时也能给最终使用者带来好的体验。现实终归是现实，理想的工具在现实应用中，不可避免的要被各种“优化”从而适应现实情况。这次新产品的开发需求是金主爸爸直接提出来的。用视频 AI 形式取代人力，对一个内容很简单却十分费时费力的业务进行监管。金主爸爸是某省级政府单位，地位特殊，所以我们如果能做好，会带来不错的收益。短期来看，爸爸手下还有六、七十个监管场所都具有同样的需求；长期来看，因市场还没有此类产品，所以只要能落地就能成为全国范围内的标杆。但好机会同时带来的也有挑战，由于产品涉及到的业务细节还不清楚，我们也是第一次做这样的多系统融合复杂产品，后面免不了会有大量的改动发生。再加上金主又催得紧，3个月后要直接面向一把手演示产品效果，在这中间每周还要提交进度和成果给负责的领导，其实压力还是蛮大的。这样的机会很明显，我没有权利决定做与不做，老板肯定是不愿意放弃的，而且非常的重视，当时一声令下，就要求全公司积极动起来，把产品做出来。当然这中间需要不断的做评审，一方面根据前面的成果决定后续应该怎么继续，另一方面则是可以“及时止损”。在这里很赞叹的是老板用了一种很巧妙的方法，成功的把失败的代价降低了很多——把“商业项目”换成“科研课题”与金主“共同研发”（这个“共同研发”相信你一定懂得）。在拍板确定了产品正式立项后，由于产品有很多不确定因素，最终决定选用“敏捷开发”方式。我们组建团队其实很平常，产品开始开发后，老板就已经决定了让哪几个人来处理，团队就这样定了。只是很有意思的是，大家一致决定采用敏捷开发的方式推进。敏捷中对于一个团队的人数定义是不超过7个人，可实际中却发现这个团队的人员在不断地扩充。扩充的原因也很简单，某个模块是团队外的小 A 所负责的领域，小 A 完成后，又需要交给同样是团队外的老 B 来处理，老 B 处理后再交给团队里的小 C 处理……就这样，大家自动的把流程敏捷了起来。反反复复的不断的吸收外部支援、再把外部资源释放出去。现在回想起来，实际参与过这个项目的人达到了近20人。敏捷相对其它方法的一个优势是所有参与者都可以独立出来，把自己的精力放在一个项目上来保证每个冲刺周期的正常进展。可实际情况却是每个冲刺周期都需要协调团队外部人员尽可能的把精力放在这个项目上，甚至团队内的人员也会因为其它项目的需要被分散精力。这个项目中还算幸运，那段时间事情并不多所以团队被打扰的不算多，进而顺利的完成预设的目标。按照敏捷的流程，我原本是想用一个尽可能简单的用户故事 A 来描述产品的需求。而实际情况却变成了研发团队在听完故事 A 后，接连抛出了一连串的问题，导致不得不用 B、C、D… 来继续丰富 A，对 A 进行解释。一个原本计划20min的需求介绍会也完全失控，变成了近四个小时的讨论，原本希望一个故事 A 就能解释清楚的问题也变成了 A = B+C+D+E+…现在回顾起来，主要问题应该还是怪我自己将一个用户故事描述的太大，变得无法实施。但因祸得福的是这四个小时的讨论，不但分解出了 B、C、D、E…个故事，还探索出了产品功能实现的最优路径，顺带连 WBS 一起做了（这过程中其实还穿插了一点点的头脑风暴和思维导图，这里就不展开了）。把用户故事描述清楚虽然是每个PO应该做到的事，但是它其实并没有看到的那么容易，所以在初期连带着头脑风暴，解析问题，未必不是一种好的方式。接上方所说，由于每个星期都要向用户提交“看得见”的可交付成果，所以在完成用户故事的分解后，还特意对前面的任务进行了排序。排序过程中，首先将所有的任务/故事按“用户是否能看到”为依据进行分类，然后遵从软件开发逻辑上的顺序，将“用户能看到的”成果分插正排序中，从而保证用户每周都能看到有能够运行的成果交付使用，证明我们真的在做事情（正巧，这点在后续就被证明了是一个十分正确的决定！）。由于金主的业务扩展，新增了一种类型的车辆需要被检测，这就导致第一个成果运行中每次遇到新型车辆都无法反馈正确结果，而这个现象导致后续所有的检测任务都无法在开启，产品也将直接宣告失败。但后续的开发计划已经做好了排序，下一个冲刺周期也正在进行中，所以这时我需要做出选择，什么时候进行“返回修改”。如果立刻修改，问题可以很快得到解决，但因为占用了第二个成果的冲刺时间，在约定的下个节点肯定没法给用户交付内容。如果拖延一阵子再修改，虽然对于当前的工作没影响，下一个约定节点也能正常交付。但第一个成果 A 和第二个成果 B 之间的“触发联动”机制会频繁失效，原本的软件逻辑：由 A 任务的检测结果触发 B 任务开始执行，就无法实现。既然两种选择都是有利有害的，那就只能“两害取其轻”了，至于孰轻孰重？我惯用的判断方式是从金主的视角来看。触发联动机制，在产品还没有成型时，其实并不是很重要的“高价值展示成果”，反而在进行冲刺开发的 B 最终所呈现的内容会更加具有“观赏性”，并且B也可以采用强制手动触发的形式开启检测任务。所以相较来说，选择优先保障 B 的开发是当前的最佳选择。
不过还没有结束，解决 A 的问题始终会导致某个节点的交付成果无法按期完成的，所以我当时的解决方法是：
这个想法在和算法 Leader 聊了后，因为担心分散的工作会影响最终质量，所以放弃。
这算是最好的解决方案了，可以给出足够的时间和精力让开发进行修改，付出的代价则是需要增加工作量和对预定策略的修改（原计划在交付 B 之前要测试“由检测任务 A 的结果触发检测任务 B 的启动”这个流程是否能够顺畅运行，现在只能将这条拖延至 A 修改完成后再做，放在最后的“系统联调”阶段）。既然②是最佳方案，那我的任务就是怎么和用户沟通②中需要延长交付的时间问题了（具体过程因为和这次分享关系不大，就不做过多描述了）。第二次的重大变更来源于公司内部，正如之前所说，由于团队对于具体的开发方法还不明晰，只能走一步看一步，在这个过程中，虽然软件产品搭建还算顺利，但由于过度沉溺于实现产品功能本身，而忽略了与公司的产品战略保持一致。导致在第四次可交付成果的审核时才发现整体产品已经开始背离公司产品战略所强调的“一套代码”理念。如果继续发展下去，产品正式交付后的维护工作就几乎绑死了当前的开发人员（自己写的代码，只有自己能看懂，后续维护只能依靠当初做这套的人），同时二期项目中，公司的其他产品在和这个产品交互的时候可能会发生各种未知的问题。所以需要对底层的基础算法进行部分修改。按照预先的规划，下一个任务的优先级安排是高于对底层支撑算法改进的，但现在必须将“看不见，摸不着”的算法改进任务提前。任务提前势必将导致客户在未来一个月内见不到任何可以运行的成果。这部分应该在很多朋友身上都会遇到，就像餐馆点菜一样，食客点菜后等了一个多小时被告知“亲，告诉您一个重大的好消息！我们用了一个多小时的时间改造了后厨的灶台，现在一次可以炒两盆菜了！”那别说食客了，连我都想掀桌子…其实作为 PO（还是一个不专业的 PO）本不应该过多的干预开发，可出现这样的事情如果再不出来，这个项目可能就不用做了。这个项目到目前为止没有签合同，甚至连意向书、开发协议都没有签订，金主爸爸对这个项目的看法也是“锦上添花”而不是“雪中送炭”。所以项目到现在能正常开展，很大程度上是在依靠每周都能给“餐桌上”摆上一道“新菜”的新鲜感，让他们一直吊着食客的胃口，更期待后面的菜。但是不管怎么样，这个“灶台”如果不改，那后面的菜就根本没法炒。大概是出事的那天晚上，我和朋友聊天，当时他一直在称赞 ipad Pro 的宣传视频，在它的宣传视频里，我突然发现为了体现激光雷达这种“看不见摸不着”的技术，苹果采用了激光雷达扫描的点云图来讲故事。激光雷达扫描出的点云图，对啊！“榨菜肉丝”是菜，那“榨菜”也是菜！榨菜肉丝来不及，先上盘榨菜也行呀~在我这里，原本的任务中就要用到点云，那干脆就先把点云当做“榨菜”端上去啊！这盘“榨菜”只需要10min就能做出来，剩下几天的工作时间完全可以改造“灶台”了！（悄悄地说一句，上桌后“榨菜”竟然出奇的好吃）经过 N 次的冲刺与评审后，产品终于到了交付（上市）阶段。交付阶段中，用户依然在提出新的需求意见，考虑到项目必须要有一个结束的指标，所以这个阶段新增的需求和修改意见，我们仅采用记录的处理方式，然后把这些内容通过内部评估后作为二期项目的需求再做开发。从实际市场反应来看这个新产品的开发还是十分成功的，在交付运行4个月后，它就成为了标准样板，被金主要求在全省范围内推广。至此，以现有的市场份额与技术能力来看，产品的生命周期至少可以持续8-10年。回顾整个开发周期，中间有多次来自于 CTO 的小变更，这种镀金的要求，按理说是不合理的，但是从产品的完整性来说又是迟早要做的事，所以需要做出权衡。理论上，最佳的权衡方式应该是项目执行期间按项目需求来进行开发，把这些“未来”的需求放在上市之后，进行内部迭代。但实际中我们遇到的问题却是：
① 来自 CTO 的直接要求无法拒绝；
② 部分镀金内容在软件开发逻辑上有先后次序的关系，必须在这个阶段完成，否则就会导致推翻重来。
所以，我最后还是选择了妥协，在进行中还是同意了一些镀金的要求。但是镀金必然会有代价，这次项目中的代价就是项目时间和研发成本的急剧增加，与此同时所暴露的另一个问题是，多个影响不大的小变更在累积起来后造成的影响很容易超过原有的预期。所以项目中，如何避免镀金尤其是拒绝高层的镀金要求，还是需要做探讨和尝试，如果有朋友有好的建议也可以文章后留言给我们。敏捷开发的核心思想在于“拥抱变更”，满足产品需要，但如果没有及时关闭敏捷开发，很容易会产生范围蔓延问题。回顾整个项目里的变更需求，大致可以分为两大类：少数会影响软件可用性的变更需求和大量个性化交互、呈现定制的需求。在项目接近收尾的时候，曾经一度陷入了对后者的修改中，导致研发和 UI 资源被占用，没法及时释放。同时加上老板的镀金要求，这段时间里整个团队都不太好过，经常会遇到前面做好的内容在一两个冲刺之后又被金主要求修改。这次的最终解决方案是 “拖”，个性化需求拖延几个冲刺周期，优先完成功能性的开发。过段时间后，用户自己也会忘掉或者否定掉之前所提的要求。在完成所有功能性的开发后，随即关闭敏捷开发，进入整体调试、试运行阶段。当用户再次提出修改需求的时候，把它放进“二期规划”中进行。敏捷团队强调“自发、自组织”，但实际中几乎是不可能发生的（至少在我这里是），团队成员更多的是“被指派”状态。敏捷的特点叫“拥抱变更”，这里有个很重要也很有意思的点是在于“拥抱”，这是一个主动积极的事，但正如上面所说，实际情况中，大家并不太有这么高的热情去“拥抱”，更多的只是完成预设的任务而已，所以当变更次数变多的时候，难免就会有心态上的问题。抱怨、消极怠工、有情绪… 这些问题都上来了，毕竟不是每家公司都能像“BTA”一样有个“程序员鼓励师”的职位，团队情绪的排解其实就蛮麻烦的。由于时间比较紧张，像“聚餐”、“郊游”这种排解方式就直接Pass了，所以思来想去，调节情绪也只能依靠碎片时间了。我是直接面向客户的，所以大多数的变更或者说最令人讨厌的变更也基本都是由我传递给团队的，我可不想因为这个让团队讨厌我，所以：中午和大家一起去食堂吃个工作餐，吃完了在公司楼下晒晒太阳，天南海北的瞎聊一些，榨干自己的幽默细胞，当个“说相声”的。最典型的就是争取时间，他们评估出来这个功能需要4天交付的时候，我会去向客户报需要5-6天，一方面是为预留应对意外的时间，一方面也是不让研发们的节奏太紧张。虽然身为 PO/项目经理/售前，但明确自己和他们的关系是没有“上下级”，没有命令。大家一起吐槽项目有多坑，金主有多XX，老板有多…（大家意会即可），让他们也能感觉到，我是站在他们这边的。遇到提变更提需求的时候再嬉皮笑脸，再“伏低”一些，团队气氛自然而然的就好很多，以至于在接近收尾的阶段中，大家基本都是在嬉笑中结束的。好了，这篇文到这就结束了，看只是开始，我希望的是你的思考，如果有任何的想法，可以评论区留言哦~PS：看过别人总结的同时，也期待你的故事，我们正在征收大家的项目管理故事，然后形成知识库，反馈给大家，期待你的参与（可以公众号菜单栏联系小编哦）。
