75 lines
7.4 KiB
Markdown
75 lines
7.4 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
092 成敏：技术负责人如何做优先级决策
|
||
你好，我是技术领导力300讲的主编成敏，最近跟一些CTO交流，聊到技术负责人做决策的话题，颇有价值，想在这里分享给你。
|
||
|
||
在整个技术团队中，技术负责人经常要做的无非是两类决策，一类是优先级决策，一类是扩展性决策。
|
||
|
||
优先级决策
|
||
|
||
一个公司有业务团队、有产品团队、有运营团队，还有客服团队等等，这些团队都有自己的目标，站在他们的角度，他们会提出许多需求给到技术团队。到技术负责人手上，可能各种各样的需求、项目排期已经排到六个月甚至更久之后了，而其他团队还在不断的提需求过来。
|
||
|
||
在这种情况下，哪些事先做，哪些事后做，或者哪些事干脆是不用做的，就是技术负责人需要做的优先级决策。
|
||
|
||
那根据什么来做决策？肯定不是看谁的嗓门大，也不是看这个需求是来自谁，比方说CEO。最终决定优先级的，是这件事情跟组织的目标到底有多大的关系，也就是优先级决策与组织目标直接关联。
|
||
|
||
其中，最核心的一个原则就是不做不该做的事情，这是提升效率最有效的方式。
|
||
|
||
交流中，有一个CTO当初是空降到现在的公司的，关于这个话题，他分享了一个他的例子：
|
||
|
||
|
||
我作为CTO刚加入公司的时候，公司每周都有一个项目排期会，产品经理和技术负责人会参加，确定接下来要做的事情。会上基本上就是产品经理之间互相争论，最后他们确定下做哪些事，然后技术负责人把这些事排到to do list里去，做出排期。
|
||
|
||
我参加两次之后就觉得这事不行，不能这么做，因为我发现，首先，这个排期表非常的长，长到每次都要滚好几页才能看完整个需求列表。其次，最老的一个to do list，已经是一年以前的了。我就特别不能理解，既然这个功能这么久没做好像也没影响什么，那当初为什么还要做。
|
||
|
||
到第三个星期开会的时候，我就动手了，我对参会的产品经理说：“你们提需求可以，提什么都可以，我们作为技术团队，支持你们是天经地义的。但是，你们能不能不光提要求，也给我一个做这件事情的理由，或者这件事情做成能达成的结果。”
|
||
|
||
所以，我就提了个要求，所有的产品经理在提需求之前要先回答我三个问题：第一个问题，为什么要做？第二个问题，做了之后会带来什么好处？第三个问题，这个好处在最终的数据上怎么体现出来。
|
||
|
||
如果这三个问题你都回答了，那我们技术团队二话不说赶紧做，加班加点的帮你做。结果，整整一个月都没有人提新需求。
|
||
|
||
|
||
回到今天的主题，怎么判断什么是不该做的事情呢？ 其实可以归纳为三点。
|
||
|
||
第一，要求马上开始，却没有明确可度量的目标与交付时间的事情，先不要做。 比如CEO突然找到你说，有件事情我们必须得马上开始干。那什么时候要结果呢？说是越快越好。那要做到什么程度呢？说是越完善越好。那这件事你就可以拒绝掉，先不做了，等具体的目标、预期出来之后再做。
|
||
|
||
第二，丝丝入扣、设计完美的大系统，先不要做，特别是如果还要花费很长时间才能出结果的话，那就直接拒绝掉，这种事情一定不值得做。技术人都有想造轮子的冲动，不管是自己去直接造轮子也好，还是推翻别人的东西，全都重构也好，技术人都会有这种冲动，这并不奇怪。
|
||
|
||
之前跟一个读者聊天，他现在的工作是在一个大公司里面维护老代码，就跟我抱怨说，每次维护老代码都是一边改一边骂，最想做的就是把它推翻掉，全部重写一遍。
|
||
|
||
但从另一个角度看，所有的代码在最开始的时候，其实都没有那么糟糕，它们是在演进的过程中逐渐变糟糕的。就算你新造了个轮子，解决的也不过是现在或未来一段时间内的问题而已，随着业务的发展、系统的演进，一样会变得糟糕。
|
||
|
||
第三，要克制精益求精的冲动。 这也是技术团队普遍都有的一种冲动，总想把事情做到最好、最完美。但任何东西，只要有时间、有资源，就总有优化的空间。所以技术团队或多或少都会有这样的想法，你再给我点时间、再给我点资源，我能把它做得更好。
|
||
|
||
但是这种“更好”是不是当前技术团队乃至公司需要的，资源是不是要放在这件事情上，是技术负责人需要衡量，并做出决策的。
|
||
|
||
扩展性决策
|
||
|
||
作为技术负责人，除了要做优先级决策之外，还要做扩展性决策。很多公司在发展过程中都会遇到这样的问题，目前的团队在现阶段是合适的，所选择的技术架构在现阶段是合适的，但一段时间之后，他就不再合适了，怎么办？
|
||
|
||
所以，技术负责人很重要的能力就是管理扩展性，换句话说，你要对你业务未来的发展有一个大概的预计，然后在组织架构、人员构成、技术架构等方向为业务保留足够的扩展性。
|
||
|
||
1.组织的扩展性，比如要不要独立出一个公共的技术部门，负责公司基础设施的搭建；比如要不要搭建一个研究型的团队，专门负责创新相关的研究；比如要不要把组织架构从功能型的重组为矩阵式的等等。
|
||
|
||
2.人员的扩展性，这个其实可以归结为到底要招些什么样的人进来。需要考虑的是，现在的人才储备是不是最合适的，未来一段时间内，团队技术上会不会有大的调整，公司业务上会不会有新的发展。比如，如果公司想要拓展人工智能相关的业务，那技术团队就要先招一些人工智能、大数据领域的人才，做好储备，这些都会涉及到扩展性。
|
||
|
||
3.技术的扩展性，现有的技术架构能不能支撑公司业务未来的发展，如果不能，应该做哪些事情来补充，比如是引入新技术，是升级架构，还是干脆重构系统等，都需要技术负责人提前做好决策。
|
||
|
||
而做扩展性的决策的关键，依旧是看这件事情与组织目标之间的关联性，与优先级决策一样。因此，技术负责人一定要对业务、对业务未来的发展有足够的理解和认知。其实，这不仅是对技术负责人的要求，任何一个有想法的工程师，都应该这样要求自己。
|
||
|
||
小结
|
||
|
||
本文探讨了技术负责人经常要做的两类决策，优先级决策和扩展性决策。而这两类决策的关键都与组织目标有直接的关联，因此，技术负责人一定要了解公司的业务，清楚公司的目标，并将其拆解为技术团队的目标。
|
||
|
||
最后，当你面临决策难题的时候，不妨先问自己几个问题：我要解决的问题到底是什么？我的团队在组织里的作用和价值到底是什么？这些价值需要用哪些方式来更好的达成？
|
||
|
||
你在工作中是怎么管理优先级的呢？欢迎在留言区分享给大家。
|
||
|
||
感谢你的收听，我们下期再见！
|
||
|
||
|
||
|
||
|