【直播回放】项目管理之“真心话大冒险” | 践行者第28期

原创
践行者
2023-12-08 11:17:16
118
摘要:为什么做出来的产品和想象的不一样?什么样的计划才算“靠谱”的计划?


为什么做出来的产品和想象的不一样?什么样的计划才算“靠谱”的计划?工期紧、问题多,质量和交付要如何取舍?本期践行者邀请到了敏捷教练王用涛老师、独立咨询师李国柱老师、华为资深顾问潘继平老师和精益六西格玛设计黑带大师宋涛老师,一起揭开项目管理背后的秘密。

一、直播实录

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提升项目管理系统为例,现在引入和再过两年引入价值肯定都不一样。

当然,这不是绝对的,还要讲究天时地利人和。商业论证里关于“如何决策、需求做不做”的内容,就是在评估需求的价值在什么时机会更合适。因为时间点变动、环境的变动,需求的价值可能会有变动。

二、送给大家一句话

王用涛老师:需求的最终目的是给客户、给自己带来最大价值。
李国柱老师:靠谱的项目管理源自于靠谱的计划。
潘继平老师:我们要拥抱变更,交付价值,管控好风险,这样才能达到事成人爽。
宋涛老师:质量和交付是事物的一体两面,希望在保障安全的前提下,我们能够加速前进,给客户交付价值。
徐东伟老师:希望大家都能成为六边形项目经理!
文章分类
联系我们

联系人:

电话:

Email:

QQ:

地址:青岛市黄岛区长江西路118号青铁广场18楼

云禅道

云端的项目管理软件

尊享禅道项目软件收费版功能

无需维护,随时随地协同办公

内置subversion和git源码管理

每天备份,随时转为私有部署

免费试用