【直播回放】项目管理之“真心话大冒险” ｜ 践行者第28期
-
原创
- 践行者
- 2023-12-08 11:17:16
- 196
为什么做出来的产品和想象的不一样？什么样的计划才算“靠谱”的计划？工期紧、问题多，质量和交付要如何取舍？本期践行者邀请到了敏捷教练王用涛老师、独立咨询师李国柱老师、华为资深顾问潘继平老师和精益六西格玛设计黑带大师宋涛老师，一起揭开项目管理背后的秘密。
一、直播实录
Q1：如何看待最终产品和早期计划差距很大的情况？
王用涛老师：钱不够，预算资源差很多。一个产品的需求从客户开始，接下来会传给销售、产品、测试等人员。这像我们小时候常玩的“传话筒”游戏：有人说第一句话，传给第二个人，第二个人再传给第三个人，以此类推。有时我们用中文传递，但更有挑战性的是用英语传递信息。需求的流转其实和游戏一样，在传递过程中可能会有很多人的主观猜测和判断，很难保持完全一致。
那如何玩好这个传递游戏呢？一是每次传达少量信息；二是发音更清晰些，让对方听到每句话；三是传给对方时，让他复述一遍，看是否真正理解。当然，还有一种更简单的方法：如果有能力可以把这些小伙伴全都召集到一起，大家一起讲会比较容易。
回到需求管理中，也是上述几条措施：
- 把产品要做的需求都找出来；
- 需求要全面，不能漏掉信息，比如关于功能的、安全架构方面的详细信息等等；
- 在统一的平台进行需求管理，避免出现有的需求在Word中管理，有的需求在XR中管理的情况。
最后一点也是最关键的，在流程流转的每一个阶段，都要有及时反馈和调整的过程，比如给上游看一下是否可行，及时纠正偏差。
宋涛老师：
听到用涛老师的观点有感而发，我也想补充一点：像汽车行业做智能驾驶，其实大家不太清楚要做什么，要做成什么样子，这其实是探索的过程。在这个过程中，就会产生大家对同一句话的理解不一，这时我们就要通过一些好的方法澄清原本并不清晰的需求。
李国柱老师：
需求在传递过程失真的情况比比皆是，我服务过的团队曾遇到的问题中，差不多1/4都是需求传递不清晰导致的。所以，我们在传递需求的时候，也要清楚地说明我们的目标受众和目的、价值，促使大家相互理解，并对“怎样算做好”这个问题达成共识。
Q2：计划怎么做才算靠谱？
李国柱老师：关于计划，普遍有一个误区：很多人认为只要计划足够细致，就是靠谱的，实际上这离靠谱还有很大的距离。靠谱的计划应该是弹性的、主次分明、详略得当的，过于拘泥细节会浪费很多精力，得不偿失，我们需要用滚动规划的形式来做计划。
项目的成功并不是交付原来的设想，如果说我们发现原有的计划已经不合时宜，就需要做一些调整，我们的项目始终围绕实现用户价值，这才是靠谱背后的核心思想。
我认为，项目成功的核心是交付价值，我们要始终围绕实现用户的价值这一核心来做事。
宋涛老师：
感觉国柱老师的观点与NVIDIA（英伟达）CEO黄仁勋的观点不谋而合。现在市值1万多亿的英伟达，公司本身没有计划，核心观点就是“Continue Planning”，计划根据实际情况适配，而不是说半年前定的计划必须严格执行，不执行，KPI或交互就要受影响等等。
潘继平老师：
除了我们现在谈的这个计划，还有很多计划。比如说我们接到项目，人员、设备、软件什么时候进场，都是有爬坡计划的，这也是需要围绕价值交付的。
Q3：如果计划永远赶不上变化，为什么还要做计划？
潘继平老师：在目前情况下，变更其实避免不了。那应该怎么管理？
一方面是人员，我们会提前达成共识，通过每个月至少一次的对齐会议（一般两周开一次），让大家都能了解变更情况。在人员管理方面，会有一类人选择谨慎变更，就算变更也会和团队一同沟通；而另一类随意变更的人员的话，我们会有一些流程制度、准入规则等进行管控，从而管理变更。还有一个问题是为什么会出现变更？深层的原因可能是人们对问题分析不够准确，可能在知识或专业方面有所欠缺。这时我们要考虑是否有专业的人进行引导、辅助。
另一方面是管理方式，我们会对不同的项目进行识别（管人还是管事），以及流程制度中怎样设定准入规则，尽量减少变更等等。对于比较明确的项目，我们可能会用瀑布的方式；对于不太清晰、需求不明确的项目，我们会用敏捷的方式。
这种管理方式的选择是基于我们能观察到的信息：比如我观察到两周内做的需求比较清楚，两周之后就不太清楚时，我们可以用一周或两周的节奏进行迭代；如果发现项目的可见度不足，存在信息不对称的情况，我们可能会采用另一种方式，即划分阶段，提高可见度。例如，我们可以制定一个阶段计划，使项目进展更清晰可见。接下来的两个月可能会是下一个版本的发布时间，因为我们已经对两个月的情况有了清晰的了解。之后，可能会缩短到一个月发布一个版本。此外，从回顾总结来看，我们可以通过画像指导我们的工作方式。另外，在组织环境中，我们可以用其他的模型识别可能遇到的变更，并采取相应措施进行应对。
李国柱老师：
前些年某些行业领域会频繁变更，传统制造业好一些，但近两年制造业也呈现频繁变更的趋势，所以变更管理要做好真的是很大的挑战，团队共识是很重要的事情。
Q4：汽车行业的两位老师，谁的企业变更多？
王用涛老师：不管在哪个企业，大家对变更并没有那么多反感。其实，更多人是“既要又要还要”，大家对这个有很大的抵触。计划已经排好了，或者是留了20%的buffer，但不断出现的变更会导致团队不得不加班来应对。所以，我特别赞同继平老师提到的“变更一定要有准入条件，不能随意变更”。变更需要经过评审确保变更的价值，且要进行置换，而不是无限地增加。
我非常同意继平老师所讲到的变更观点。没有不变的项目，我们要做的是在大规模的变更下，尽可能降低变更的影响或使其变成可控的。例如，需要有经验的管理人员和项目团队来提前规划和考虑变更，确保事情得以顺利进行。同时，我们也需要考虑到所有变更带来的价值、对公司、客户的价值、如何控制这个最终机制。
在汽车行业中，变更的情况非常有趣，因为它与硬件供应商有关。比如奥迪的变更叫“AECO”，一旦正式发布“AECO”，甲方愿意为此付费。在互联网软件领域，变更出现给付费用的比较少。但在汽车行业，如果有零部件的变更，甲方愿意支付费用。然而，对于乙方来说，业务应该如何处理这些变更，这就需要项目经理发挥更好的调节作用，帮助大家理解变更的原因，并提供尽可能减轻变更影响的好方法。
Q5：如何看待软件质量重回舞台？
徐东伟老师：质量是一个非常重要的话题，在敏捷中，质量不能投降，没有质量一切都白费。提高质量相当于精细化运作，或者是经过浮躁之后真正地回归本源。
Q6：工期和交付质量哪个要投降？
宋涛老师：工期和质量是一个事物的两面。在质量管理领域中，我们喜欢强调“质量管理体系”，这意味着我们需要从系统论的角度来看待这个问题。
在项目中，负责质量管理的人有点像踩刹车，而项目经理则负责踩油门。无论是项目还是质量，共同的目标是确保乘客安全到达目的地。如果我们只顾着加速，很可能在路上出问题，这时候就需要质量人员踩刹车。然而，刹车也会出现一个问题，就是问题和交付的决策权。比如开车是司机做出决策，但司机后面还有其他人，他们可能会给出指示（即Back-seat driver），那到底是谁对最终结果负责？这个决策者需要根据经验、知识和管理纬度上决策，需要看公司是否给予他足够的权力和控制范围，这时候，更需要通过一种机制来保障。
其次，我们在谈质量时，实际上从系统的角度来看，不仅仅是关注问题和交期。质量是“fitness for purpose”，有时候交付是为了快速获得反馈，这时候问题可能并不是唯一重要指标，交付本身可能更重要。但有时候我们的交付涉及到人的生命安全、法律法规要求，这会影响到用户的使用体验，这时候，质量安全会更重要。例如，最近各种互联网大厂的宕机事件。
对于项目的交付，如果问题可能造成重大影响，整个团队应该坐下来盘点，理解对客户价值的影响程度，做一定的trade-off，而不是只关注问题的数量。我看到很多人喜欢用一些复杂的公式来计算质量目标，认为只有达到这个数值才能继续进行。这个时候，项目经理和质量经理会很无奈，因为大家不是关注产品是否能够适应客户的使用目的，同时能为公司带来价值的，而是为了数字而争执。
Q7：如何平衡软件的工期和质量交付？
潘继平老师：我们在接手项目的初期就已经有约定。我们采用质量策略的方法，对质量进行分级、分类处理。例如，致命的Bug必须要全部修复，建议性Bug可以不修复。这种分类和分级的发布策略可以帮助我们确定最终的质量策略。如果我们需要提前发布，我们会利用测试结果的质量分类和分级进行排序，并根据策略选定需要测试与不需要测试的内容。因此，对于质量的测试用例，我们也叫做测试说明书，会对其进行分级分类，明确需要测试的与不需要测试的。当有变更或变化时，我们能够及时应对，通过自我监控和分级分类的方式，轻松应对任何变更。
徐东伟老师：
质量的重要性不可忽视。
• 当不注重质量时，很多时候它会迫使我们延长工期。低质量会导致返工，对客户和用户产生影响，这是无法逃避的事实。
• 质量和工期逃不掉技术债务。这就是说，我们并不是要求在上线之前必须解决所有问题，而是需要在质量和工期之间寻求平衡。我们明知道有问题，但仍然选择上线，这就是技术债务。而债务什么时候债还需要斟酌。例如，某件事情需要借债来做，我们将借来的资金用于投资或其他更划算的事情。在这种情况下，临时借贷是值得的，只要最终能够偿还就是一种好的方式。因此，质量和工期之间的平衡需要进行分级和权衡的过程。
Q8：项目总是变更，瀑布模型下的阶段怎么管理与界定？
潘继平老师：瀑布模型的前提是对整个需求都比较清晰，按职能一个阶段一个阶段的划分。这需要有明显的准入与准出要求，需要找需求提出方确认没问题再进入下一个阶段。
宋涛老师：
严格意义上讲，现在几乎没有企业是完全按照瀑布模型做项目的。其实，大部分企业特别是汽车行业，是按照V模型来做的，他们会在实际工作范围，将大V变成小V，比如在这短时间先交付有着清晰需求的产品版本，其他不清晰的需求或者一些变更会放在下一个V模型中，再做交付。这就是通过多个V模型的迭代过程，最终交付整个产品。
Q9：项目执行中总有优化的需求，如何规划新项目的周期呢？
徐东伟老师：需要看手里现有需求的优先级，移出去才能接收新东西，做好取舍。
王用涛老师：
好的PO可以排优先级。优化的需求大多数情况下没那么重要，优化需求一旦加入，原计划的需求就会延期，可以用具体的事实和例子与客户、老板沟通。
潘继平老师：
当部门每天都有内外部新需求进来时，我们可以邀请高level的领导来同客户、产品达成项目共识（比如什么需求可以排入计划，规则是什么等等），后面会按照规则走。总结来讲就是允许需求变更，但变更是有窗口期的，一旦过了窗口期就不允许变更，这样通过变更的各种条件限制，达到各方都满意的效果。
Q10：敏捷模式和瀑布模式对交付价值的衡量有不同吗？同一个需求紧急插入，其客观价值会受到影响吗？
王用涛老师：一个需求的价值对客户来说是固定的，不会因为使用了敏捷还是瀑布就发生变化，所以是不是紧急插入不会影响其价值。除非这个需求和时间强相关，今天错过，明天就没有意义了，这时的紧急插入才会对客户产生更大的价值。
宋涛老师：
我理解这个问题想表达“价值”的时间维度。即，如果错过了时间窗口，那交付的价值有可能会因错过市场机会而降低。但本质上讲，这个不应该是敏捷或瀑布模型的问题。无论是敏捷还是瀑布，最终还是需要交付客户价值和业务价值，这个是不变的。敏捷和瀑布各有各的优势，各有各的适用场景。
潘继平老师：
这话题范围有点大，需求价值可以从不同视角来看，有用户价值、项目发起方价值、交付团队的价值等。他们各自代表的立场不同，所以价值也不同。客户希望能解决问题，并带来业务价值；发起方更多关注的是财务、战略等方面的收益；交付团队关注实现难易程度和自我能力的锻炼。不管什么立场，都有可能因为时间点的变动而让价值发生变化。以引入AI提升项目管理系统为例，现在引入和再过两年引入价值肯定都不一样。
当然，这不是绝对的，还要讲究天时地利人和。商业论证里关于“如何决策、需求做不做”的内容，就是在评估需求的价值在什么时机会更合适。因为时间点变动、环境的变动，需求的价值可能会有变动。
二、送给大家一句话
王用涛老师：需求的最终目的是给客户、给自己带来最大价值。李国柱老师：靠谱的项目管理源自于靠谱的计划。
潘继平老师：我们要拥抱变更，交付价值，管控好风险，这样才能达到事成人爽。
宋涛老师：质量和交付是事物的一体两面，希望在保障安全的前提下，我们能够加速前进，给客户交付价值。
徐东伟老师：希望大家都能成为六边形项目经理！
联系人： 杨苗
电话： 13165050229
Email： yangmiao@easycorp.ltd
QQ： 2692096539
地址：青岛市黄岛区长江西路118号青铁广场18楼
