谁是 Stakeholder

背景

去年 9 月,和往常一样,App Team 的 Dev Lead 正在为下次项目发版内容评估时间。通过和产品经理的沟通,大家都希望能通过“原生 App 技术”去实现新功能。然而在完成时间评估后,根据给定的发板日期,我们却没有足够的安卓人手。最终,这项功能不得不暂时以网页的形式集成到 App 中。

与此同时,我又想到了运用跨平台技术的可能性。身边不少的同事和我一样,之前有过 React Native 的开发经验。但从开发效率以及实际效果来看,都没能达到我们的预期,并且近年来 RN 也没有实质性的重大改进。放眼当前的市场,两年前开始崭露头角的 Flutter 可能是唯一有希望的选择。虽然我个人也陆陆续续做了一些尝试,由于未曾有大型项目的经验,且市场上也没有类似的成功案例,因此自己也没有足够的信心去将此技术进一步推广到当下的项目中。

机缘巧合之下,公司的另一个项目(由外包团队负责),长久以来都以 Web app 为主,饱受性能问题困扰,正在考虑更换技术栈,但又限于成本问题,因而供应商大胆地将 Flutter 作为主力开发工具,并成功完成了上线。根据运行效果来看,速度和体验都堪比“原生 App”,就连很多 iOS 和安卓的开发小伙伴也无法分辨。这个成功的案例,让我感到 Flutter 已经足够成熟,并对开发效率和运行效果有了十足的信心,因此开始计划提案 Flutter 作为原生 App 的替代技术选择。

我和团队的小伙伴向来都习惯以事实说话,因此我们希望通过扎扎实实的产物来向别人证明自己的理论。按照公司的惯例,我们希望这个提案以及相关的产出都能以业务为导向,因此我们首先和 PdM 进行了探讨,明确了该提案对业务的价值,并且选定了 PoC 的内容。这个 PoC 不但可以在一定程度上论证技术的可靠性和可行性,也能对业务产生积极的影响。另一方面,考虑到团队建设和成员发展,拓展技术选型不但有利于团队进一步提高生产力,能让现有的成员,参与到更多的项目中。并且工程师自身也可以跨越技术平台的壁垒,为将来个人发展创造更多的可能性。

东京和上海的 App Team Leader 和 Dev Lead 都非常认可此项提案,在经过 2 个月左右的调研、开发和总结工作后。PoC 的实际运行效果让大家非常满意,对此技术的前景也非常乐观。此时我们觉得,是时候将此提案和 PoC 作为 App Team 的技术改革,分享到整个公司的研发团队,并且希望能获得上层的认可和指示。

然而,我们完全没有料想到,在我们分享了所有的成果之后,随之而来的却是多方质疑甚至是批评,其中包括“为何跨平台方案技术要选择 Flutter”,“整个讨论和决策的过程不够透明清晰”,“为何我们要将 App 中的网页功能替换为原生技术实现”,“为何没有邀请 App Team 以外的更多人参与到整个讨论中”,“技术选择和 PoC 缺少不同方案的对比和辩论” 等等。

经过了几个月的社内探讨,我们进一步补充了相关资料,根据要求梳理了遗漏的环节,目前 Flutter 的推进虽然已经重新回到了正常轨道,但其中坎坷还是非常值得我进一步反思,因而总结了以下内容。

目标和范围

从项目管理的角度来看,除了明确目标和内容范围非常重要以外,对风险的评估和应对也是必不可少的一部分。而这三者的都需要随时和相关方进行密切沟通和同步进度。没有明确 Stakeholder 或者说没有仔细分析相关方的干系程度,是这次项目推进过程中的首要疏漏。

明确 Stakeholder

公司的组织架构由技术和业务两条线并行,他们会从完全不同的视角评估同一件事。

业务更多的会从 ROI,KPI 等可以量化的数字上评估收益,因此 Flutter 提案得到了业务方面比较积极的评价,尤其是当我们拿出实质成果后证明了 Flutter 可以让我们节省一半的人力,用相同甚至少的时间取得和传统开发模式相同的效果和收益。

在技术层面,我们从始至终都将 Flutter 看作是 App 内部的一项技术改进,以至于在 Stakeholder 的判断上出现了问题。因此从更高的技术视角,我们不但要看技术解决眼下问题的有效性,还需要结合长远技术演进和发展,通盘考量引入新技术对 App 以外的系统,乃至整个组织架构的影响。更重要的是,最终的技术负责人需要对新技术引入的风险进行评估,甚至对可能造成的负面影响负责。而这个人,在我们公司就是 CTO。毕竟解决我们面临问题,不光有技术手段,还可以通过招聘,增加供应商人力,甚至寻求新的合作伙伴的方式解决。在一个非 IT 以业务为导向的公司里,IT 对新技术的引进通常比较谨慎,对风险的关注度远远高于技术可能带来的收益。

同步目标和范围

对 Stakeholder 判断的偏差,也导致了在推进的过程中我们没有很好的同步相关方对 PoC 的目标和范围的意见。从 App 角度看,Flutter 仅仅是一个跨 iOS 和安卓平台的工具。但从其他部长和 CTO 的视角,他们着眼的可能是 Cross-platform 对整个大前端的影响力和可能性。例如:我们是否能够统一 Web 和 Mobile?在 EC 项目以外,是否有其他风险影响较低,并且能发挥 Flutter 开发效率的项目?带着更高的视角和他们各自长远的眼光,当下的 Flutter PoC 对他们而言的意义,以及需要验证的内容都是不同的。

结合高层次的目标

Flutter 的 PoC 基于两个非常重要的前提:1、首先 App 的原生化是整个 IT 的大方向 2、其次原生化能带来最好的业务收益(ROI)。而这两点则需要更高层次的决策和判断。从技术角度,我们很容易证明原生 App 的速度和体验明显优于 Web,然而额外的开发成本也是显而易见的,对于当下的业务而言,原生 app 的 ROI 是否足以支持我们继续走下去?还是将来我们会以 Web app 为主,着力优化 Web 的性能?这点也需要进一步明确。而对 Stakeholder 的误判,也使得我们没能获得这方面的信息,错失了结合更高层次目标的时机,以至于最后遭受相关质疑。

推进方法

以事实或结果说话,这点未必在所有公司都行得通。特别是作为一家日企,强调的是流程的完备性,公开透明,过程中需要所有相关的第三方充分参与,各抒己见,最后的结论大家能够达成一致。而结果本身,最后成功或失败,有时候并不是最重要的。这种集体决策的模式和通常欧美公司有着明显的不同,从组织架构角度来看,一个项目会有多个 Stakeholder 从不同视角审视、评估,最后达成多方共赢的结论。而从管理视角,这些人相互制衡,避免了一方独大,达到了利益平衡和自我管理的状态。因此相比欧美,特别是科技公司,明显的感知就是决策过程非常冗长,参与人态度暧昧,需要反复周旋,最终实施的方向可能和一开始相去甚远。

事前知会

可能是因为日企独特的文化,或是日本人的表达方式,他们在公开场合很少直白的发表自己的意见。因此当你将干系人拉到同一个会议中,想讨论点什么的时候,最后往往会发现毫无收获。“事前知会” 可能是特有的日企文化,为的是在正式会议前,提前和 Stakeholder 一一沟通会议的主要目的和内容。因为是私下沟通,他们更有可能直接或间接的给你一些非正式的意见和想法,虽然他们未必会在正式场合表达,但你需要平衡他们各自的诉求,必要的时候甚至做出一定的妥协。正式会议的时候,大家希望看到的是一个能够综合多方诉求的讨论方向,会议的主要内容更多的是对细节商定,而非对项目方向的辩论。

思维导图

通过思维导图的方式,在公司里推广一个新的想法,是我从《Well Designed》书中看到的,觉得也很适合日企的沟通风格。通过例行的 1on1 以及事前知会等方式,将一个原始的想法,通过思维导图的方式,以头脑风暴的模式和关系人进行交流。这个过程,不但有助于帮你理清方方面面的诉求,获取更多的可能性,发现各方诉求的平衡点以外;更重要的是这些关系人会感到他们对这个想法具像化过程中自己的参与感和贡献,更有助于这个想法最终落地。

增加透明度和公开度

对于核心关系人之外的其他相关人员,他们虽然不会深度参与到整个决策和讨论过程中,但需要汇总他们可能提出的反对意见并及时跟进。由于知识领域的不同,他们的反对原因通常都于流程化和制度相关。因此我们需要改变传统工程师的思维和做事方法,从以仅靠事实说话的决策思路为转变为,以项目管理的方式进行决策和风险控制,并补足工程师普遍缺乏的业务和项目方面的知识技能。只有这样,我们才能更有信心的将项目的整个推进过程以更加透明和公开的方式呈现在整个公司面前。

结合公司文化和现状

公司文化和固有体制决定着大环境,也决定着某些方面的价值观和受重视程度。在业务导向的公司,技术只是帮助实现业务的工具,具体价值在 ROI 等指标上。公司往往缺少对技术投资的战略思维,因此在研究创新技术上,更多考虑的是成本和风险。这会影响到新技术落地的方方面面,科技公司会考虑技术积累和将来的竞争力而不要求短期的成效和收益。而非科技公司,则需要找到眼下切切实实的业务痛点,明确目标和价值之后,以更加严谨的方式将细小的改进一步步的落实到当前业务中去。

Show Comments