15 技术团队真的是“成本中心”吗？如何改变这一现状？
你好，我是黄勇。今天我们来聊聊如何通过 OKR 来体现技术团队价值。
对于我们技术人而言，尤其是技术领导者，往往会面临这样一个问题：销售团队是公司的“利润中心”，而技术团队是公司的“成本中心”，如何才能体现技术团队的价值呢？
其实，这个问题也经常会被一些非技术出身的老板或其他团队同事所质疑，此时我们往往显得有些无助。因为技术团队不像销售团队，为公司赚了多少钱，这些都很容易去量化评估和清晰呈现。
然而，技术团队在不断地接需求、做项目、上系统的过程中反复循环，我们的价值似乎真的很难用一个合理的数字去度量。那么，究竟如何做才能体现出技术团队的价值呢？
如何体现技术团队的价值？
或许你也和我一样，曾经我们都思考过如何体现技术团队自身价值的问题，比如，写了多少行代码？做了多少个项目？用了多少人力成本？加了多长时间的班？可能只有“加班”这种现象能够勉强让他人觉得在技术团队上的投入是有价值的，至少会让人感受到我们“没有功劳，也有苦劳”吧。
我认为，要回答技术团队如何产生价值的问题，首先要让同事们知道工程师们每天到底在做什么。因此，你作为技术领导者，需要向同事们介绍技术团队的内部工作流程，让对方清楚意识到技术工作其实是一个工程性要求极强的工作。
此外，要想做好这份工作，不仅需要工程师们有较强的逻辑思维能力，而且团队内部还要有一系列技术规范和研发流程，对其他团队也要有相关的支持接口。
你不妨在公司内部先组织一场分享，请老板和公司全员或核心部门负责人参加，最好你亲自来做这次演讲，先让大家理解技术团队的工作内容，可以说说平时遇到的困难和挑战，也可以讲讲技术团队的工程师文化，达到能让大家理解的效果即可。
除了在技术团队核心工作方面来体现价值以外，你还需要在日常的项目中体现技术团队的价值。
在项目启动之前，项目负责人一般会向团队发布一份《项目计划》，该计划包括项目过程中具体要完成的任务，以及完成每个任务的截止时间，还有所包含的人力投入情况。当项目正式启动后，项目团队需按照这份计划落地执行，直到项目正式上线。
那么，请问项目上线意味着项目成功吗？显然回答是不一定的。也就是说，项目管理的价值仅在于让项目顺利上线，至于项目是否产生应有的价值，似乎就无法控制了。
所以接下来，你要做得第二件事情才是“改造”项目管理，并使用 OKR 工作法来“设计”项目价值，从而进一步体现技术团队的价值。
如何使用 OKR 体现项目价值？
在项目正式启动之前，你要做的是充分理解项目的价值，请试图找出以下几个问题的答案：
1.Why：为何我们要做这个项目，这个项目主要是为了解决什么问题？
2.What：对于项目所解决的问题而言，它所能产生的价值到底有多大？
3.How：项目上线后，是否能够有效地去验证项目的价值？如何验证？
此时你可能会想：这些问题不应该是产品经理应该去考虑的吗？为何要我们技术团队来找答案呢？你能产生这样的思考，完全是正常的，但不要忘记，你要解决的问题是如何体现技术团队的价值，那么你实际上要体现的其实是：技术团队所交付项目的价值。
为了让你更能理解我的思路，下面我就用 OKR 工作法来解决如何体现项目价值的问题。
假如有一天，一位产品经理跑过来告诉你：“我在注册页面增加了一个‘图片验证码’的功能，希望技术团队能尽快上线。”临走之时他也不忘补充一句“这是老板要的功能”。
当你面对产品经理这样的一句话需求，并利用老板做高压，你下一步会做些什么？或许你会考虑手头上是否有人可以安排这项工作，或者有什么现成的技术或工具可以拿来直接用。
同时，你心中也会对这位产品经理的表达方式表示不满，当这样的事情屡屡发生，久而久之就会影响团队之间的相处气氛和工作协同。
如果我自己遇到这样的情况，我会这样去做，供你参考。
我：这个功能太酷了！我们做这个“图片验证码”功能主要是为了提升用户体验吗？
产品经理：是的，市面上很多产品都有这个功能，我们也要这样去做。
我：明白了，之前我看过注册数据统计，发现注册转化率只1%，可能是用户觉得我们现在提供的“数字验证码”操作起来比较繁琐，感觉这个“图片验证码”体验上线后，我们的注册转化率肯定会有所提升，你认为大约会提升多少呢？我们一起努力啊！
产品经理：没错，注册页面的用户体验提升了，注册转化率肯定会有所提升，我估计能提升到 5%。
我：这个数字太棒了！那我赶紧请工程师们分析一下如何实现，我们一起努力，让这个项目尽快上线，尽早产生价值。
为了能与对方达成共识，并输出最终的 OKR，请注意我和产品经理的沟通方式：
- 首先，我必须高度认同他的观点，而不是对他提出的需求产生质疑，因此我不断地在对他说“太棒了”和“太酷了”这些能强烈表达感情色彩的词语。
- 其次，我在和他沟通过程中，实际上是在不断向他提出一些“引导性”的问题，我先将这个项目的价值向提升用户体验上进行引导，从而将我所知道的注册转化率过低的问题告知对方，并引起对方思考做这个项目的价值究竟在哪里。
- 最后，我在和他的沟通中，始终强调“一起努力”，这种方式会拉近我和他之间的距离，让产品和技术快速建立信任，从而让团队之间的协同变得更加高效。
在与产品经理结束对话后，我先找了一位资深的工程师，了解到实现这个功能可能需要 1 个人 1 周的时间来完成并上线，然后花了一点时间利用 OKR 工作法对此项目制定一个“项目 OKR”。
图片验证码项目 OKR
O：尽快升级注册页面用户体验，从而有效提升注册转化率
KR： 1）1 周内上线“图片验证码”功能 2）功能上线后，X个月内将注册转化率从 1% 提升到 5%
此时我并没有明确功能上线后的验证期有多久，因为我下一步就需要将此项目 OKR 与产品经理达成共识。
于是，我拿着这份项目 OKR 去找产品经理沟通并确认，他给出的验证期是 3 个月，我觉得也比较合理。随后我将此项目 OKR 写到了项目计划中，并与项目团队和其他相关团队同事以邮件的方式进行同步。
将项目 OKR 制定完毕，并将其放入项目计划中，随后将信息同步给相关人员甚至全员，这在一定程度上可以体现项目的价值，但体现价值绝不是靠一份项目计划就能完全体现出来的，我们还需要持续不断地体现项目价值，从而体现技术团队的深层价值。
如何持续地体现技术团队价值？
使用 OKR 不仅能体现项目价值，还能让项目团队对项目的目标更加聚焦。我的建议是，不要告诉工程师们应该做些什么，更不要告诉他们应该怎么去做，而要告诉他们为什么要做。作为技术领导者，你需要将项目的目标和价值充分体现出来，才能打造出一个真正的具备工程师文化的技术团队。
经过一周的开发和测试工作，图片验证码功能成功上线，此时建议你需要写一封项目上线邮件，将项目 OKR 的完成率告知相关同事们或公司全员。
图片验证码项目 OKR
O：尽快升级注册页面用户体验，从而有效提升注册转化率【完成率：50%】
KR：
1）1 周内上线“图片验证码”功能【完成率：100%】
2）功能上线后，3 个月内将注册转化率从 1% 提升到 5%【完成率：0%】
完成率计算方式非常简单，O 的完成率是其下每个 KR 完成率的平均值，KR 完成了，O 就完成了。
此外，为了让大家持续关注项目价值，你也可以和产品经理达成一致，以后每月都给大家同步一下该项目的 OKR 完成率。
而当项目的验证期结束后，你需要组织项目组以及产品经理或需求方，使用我之前介绍的“OKR 复盘四步法”对此项目 OKR 进行复盘。在复盘会议结束后，别忘了将复盘会议结论共享给团队。
我想再补充一句，对于曾经做过的项目所产生的价值，你还需要阶段性地向你的上级领导汇报，从而建立领导和你之间的信任，这同样也能体现技术团队的价值。
总结
今天我们一直在讨论如何体现技术团队价值，我们不仅要让同事们知道技术团队在做什么，更要让大家看到技术团队的产出及其成效。对于技术团队的产出而言，实际上就是我们不断上线的项目，而项目上线后是否有成效，需要通过科学合理的方法来验证。
因此，我今天提出了“项目 OKR”的概念，在项目 OKR 中，O 指“项目上线后有何价值？”KR 指“如何验证项目的价值？”在制定和执行项目 OKR 的过程中，我们需要注意一些技巧：
1.项目 OKR 无需你一个人来制定，你需要与协作伙伴们共同来完成。
2.通过“引导式”提问方法，让你的伙伴们认可通过 OKR 来验证项目价值的方法。
3.持续体现技术团队价值，通过定期向大家同步项目 OKR 完成率，这个方法值得尝试。
思考时间
除此以外，还有哪些可以提升技术团队价值的方法或技巧呢？期待你的留言与分享。
最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。
- David Mao 👍（6） 💬（1）
这篇文章中的例子我有点困惑，老师讲目标与任务要分开，不能把任务当目标，可举的例子看起来就是任务。
2019-08-03 - 行者 👍（4） 💬（1）
“不要告诉工程师应该怎么做，而是告诉工程师为什么这样做”，如果工程师沦为实现功能的工具，丧失主动性是迟早的事。
2019-08-03 - Jxin 👍（2） 💬（2）
1.代码的价值，除了按期上限功能，还有保证系统鲁棒性，系统可读性，系统响应指标，系统负载指标等等。按期上限的价值对于其他职能部门还比较好认知，但其他这些呢，怎么去告知其它部门它们的价值，又如何让其他部门认同并愿意为它们买单？ 2.工程师的价值，不局限于代码价值。产品的发展方向把控，产品是业务和技术结合的产物，不该仅由业务一条腿去把控整体发展方向（比如，结合该业务领域的技术栈发展现状和规律去助力产品发展）；各部门间协调，敏捷开发+多模块集成的工作成本和难度是比较大的，而其中的复杂度有很大一部份是偶然复杂度，也就是非技术实现的复杂度，而这份复杂度需要工程师们优秀的沟通协调能力；持续成长，我觉得这也是一个很重要的指标，程序员业务代码写着写着就失业了，这是程序员的不幸也是公司的不幸，因为一个有技术不懂业务的大牛，在新的业务环境接老项目是要踩坑的，而这份成本是由公司承担的（高速发展的互联网公司真的适合花这份时间成本？竞争激烈的市场环境，确定要承受这份事故风险？）。所以维持现有团队稳定，又保证现有团队技术水平紧追业内一线，如此的团队在长期来看才更易于沉淀技术积累，而技术积累对于以技术为核心的互联网公司亦是命脉之一。
2019-08-05 - w*waiting 👍（1） 💬（1）
外包公司： 最后O的制定，如果跟线上运营情况进行相关的话，感觉找不到抓手。 我有一个想法，是不是可以跟开发流程相关； O-优化开发流程：项目开发完成后，两周内完成项目验收，并回款 KR1-一周内让客户满意，完成验收； KR2-两周内想办法要回款。
2019-08-05 - 天涯海峰 👍（1） 💬（1）
受益匪浅.我们长期存在一个问题，做了好多功能，但产生价值的很少。感谢老师，直接哪来这种方式去用了
2019-08-04 - 许童童 👍（1） 💬（1）
这种公开透明的方式对公司的发展，以及团队的凝聚力是有很好的促进作用的。
2019-08-02 - 李双 👍（1） 💬（0）
体现技术团队价值，项目OKR，赞
2019-09-17 - 赵旭 👍（0） 💬（0）
有个疑问，OKR得是自己能掌控的，文中验证码的例子，工程师能掌控上线后数据提升？或者老板定的高目标的数据，自己不怎么认可的，能把数据指标写到自己的OKR里吗？但是没有数据支撑，一般工程师的OKR该怎么定？最后KR都成了xx时间完成XX功能的上线
2023-03-03 - leesper 👍（0） 💬（0）
对于文中这种产品，我都是先怼一顿再说，什么玩意儿
2022-01-08 - Sam_Deep_Thinking 👍（0） 💬（0）
最近在研究矩阵式组织架构，黄老师真是高手中的高手，厉害。
2021-05-16 - 张兆坤 👍（0） 💬（0）
表面上看产品对版本/功能的效果负责，技术对版本/功能的实现负责，时间长了开发就对版本/功能很漠视了，做什么版本/功能都无所谓，只要给时间给人就一切都好说话。 感谢黄勇老师提供了一种可以具体操作的解法！
2020-07-04