技术管理看这一篇就够了

“不确定性”&风险把控

作为一个程序员，在其职业生涯发展过程中，随着工作年限的增长，项目经验和技术能力会不断提升。而在这个过程中，都绕不开一个问题：技术管理。

技术管理，说的通俗一点，就是你如何带领一个团队完成一次次的产品迭代，一个个的项目开发。这里面牵涉的东西很多很杂，包括研发、测试、运维、产品、项目管理、数据分析…

不一而足，不同类型的项目、不同的公司文化，在这个事情的做法上都会有差异。

但不管这些差异如何，有一些共同的思维，或者说方法论，是相通的。而从本序列开始，我将分享一下自己在这方面的一些经验和思考。

在我看来，技术管理首先就是要应对”不确定性“问题。就人的认知来讲，做任何事情，你的思路都是从一个”朦胧“到逐步”清晰“的过程，项目的进展也是一个从思路、到方案、到落地的一个逐步细化过程。

这个过程中，不可避免的存在各种”灰度“，或者说”不确定性“。而管理，就是要提前防范这里面的各种”不确定性“，并采取对应措施，让整个团队、整个项目最终经过重重干扰，到达终点。

那都有哪些”不确定性“呢？下面是我的一些总结归纳：

需求的不确定性

做产品或者做项目时，产品经理或者大老板，或者其他相关人员，都会有很多“想法”。

有些想法很成熟，逻辑严密，很有系统性；而有些想法还欠火候，需要进一步细化；还有些想法，纯粹是头脑风暴，想想而已…

而由于各种外部条件，比如工期的约束，绩效的追逐，老大的压力…很可能在一个想法没有完全想清楚的情况下，就开始了实施。

这就是一个重大的“不确定性”。遇到这种情况，作为技术的leader，需要去和产品经理、和相关业务方、上级老大等，进行广泛的沟通，最终在这个事情上，要达成“共识”：到底哪些东西清晰的，我们可以开做；哪些还需要进一步思考，细化…

技术的不确定性

在做一个新项目时，你可能会遇到技术选型的问题，团队中成员都没有掌握过的某个框架，或者某个开源库，某个对接的第3方开放API等等…

对于这种情况，必须在项目早期，做尽可能多的调研、测试。引入的技术框架，什么特性可以支持，什么特效支持不了；技术选型，不同方案的优缺点…

尤其是一些关键的技术细节，如果在前期不调研做实，等到中后期，才发现某个feature支持不了，或者有问题，可能将对整个的技术架构和项目进度，产生严重影响。

人员的不确定性

系统耦合性高，一个关键模块的开发人员的突然离职，新来成员对项目不熟悉，然后慢慢摸熟，上路，等最后项目完工，离预定工期已经差了一大截。

对于这种情况，一个应对策略就是：不要把项目最核心的东西，让一个人去开发维护，别人都插手不了。要分摊风险，在技术的架构设计层面，保证整个系统耦合性不要太高，根据团队成员的水平，每个人都可以cover一块东西。这样某个人离职，有相应的人可以补上。

组织的不确定性

公司越大，业务越复杂，部门越多。随便做一个项目，都可能跟好几个业务部门打交道。这些部门可能还在异地，平时只能即时通信，或者远程电话沟通。

对于这种情况，前期必须要做尽可能多的沟通，调研对方提供的业务能力，哪些目前有，哪些目前在开发中，哪些还没有…

在充分沟通的基础上，跟对方敲定排期表，不定期的同步进度，Push对方，保证对方的进度和自己在一个节奏上。

历史遗留问题

一般当你进入一个公司，除了创业型公司，很少会一上来就做一个新项目。首先都是会接手前人留下的老项目，在此基础上进行迭代升级。

运气好呢，老项目技术架构很清晰，文档清楚，业务清楚，还有熟悉的其他同事

运气不好呢，遗留项目欠了很多技术债，之前的开发人员也走了，业务很多不熟悉。

对于这种情况，你就需要对项目进行完整的梳理了：从产品到技术，找各个接口人聊，可能经过了两三个月，你才对整个系统有了一个全局的把控。

最后

上面列举了带团队做项目的过程中，遇到的几个常见的“不确定性”问题，真正做的过程中，不同项目又会有差别。

这里主要想强调的是：要有这种“风险把控”的意识，有了这种意识，你在项目早期，自然会去努力的想各种各样的“不确定性”，然后早做打算，未雨绸缪。

塑造团队中的影响力

刚入职场时，大家都很青涩，能力也都差不多。然后几年之后，有的人升成了leader，负责更大的事情；有的人还在原地踏步，没有多大提升。

影响一个人职业生涯的因素有很多，有公司业务问题，有运气问题，有跟的人/团队是不是靠谱的问题，有个人和领导性格是否合拍的问题。这些问题呢，很多超出了一个技术人的掌控范围。

而本文呢，想从最底层谈谈，作为一个技术人，如何务实的一点点塑造你自己的影响力。而这个事情里面，没有运气成分，是任何一个人，只要你用心做，都可以做到的。

关键时候要能顶的上

在一个组织开展业务的过程中，必然会有一些比较“关键”的point：

某个bug困扰了团队1个星期，也没有人搞定；

某个成员离职，他负责的模块没有人接手；

某个用户反映的问题，像牛皮癣一样，总是时不时发生，没办法根治；

某个需求发生工期延误，到了快上线的时候，上不了；
……
如此种种，有的人的解决办法是“能避开就避开”，有的人解决办法是主动迎上，“死磕”，不解决誓不罢休……

打工思维，还是老板思维

你是打工思维，安排的事干完了，其他一概不管。只管好自己那一亩3分地，技术搞完了，产品、运营、业务发展，一概不关心。产品体验好不好，业务发展前景如何，与你无关。

你是老板思维，你会想这个产品的价值究竟在哪？

这个产品有什么问题，如何改进？

团队的协作流程又什么问题，如何改进？

技术架构有什么问题，如何改进？

某些用户投诉一直没解决，如何处理？
……

空杯心态

术业有专攻。再牛叉的人，他也只是在某个领域很厉害，换个领域，他可能什么都不懂。

技术、产品、运营、测试、运维。。每个领域都有自己的门道。再细化一点，单说技术：前端、后端、架构、算法、数据。。每个子领域也都有自己很深的门道。

说这，是想说明，任何时候，你需要意识到自己的“无知”。只有意识到自己是“无知的”，是有“局限的”，你才可能不断去吸收别人的意见，不断去改进自己的工作方法，提升自己的专业能力、视野。

不然就会一直呆在自己的舒适区里面，刚愎自用。自认为知道的很多，其实很少。

持续改进

世界上从来没有做到100分的事情。产品也好，业务流程也好，技术架构也好，项目管理也好，运营也好。。只要你想“鸡蛋挑骨头”，总是可以挑出要改进的地方。

说这，是想说明，你得有“批判性”思考的习惯。不要觉得“差不多”就可以了，要追求极致，其实有很多事情要做。

大家从小到大都在考试，都知道这样一个道理：从不及格到60分，很容易；从60分做到80分，难一点；从80分做到95分，很难；从95分到100分，每增加1分，难上加难。

做事情跟考试一样，有的人选择做很多事情，但每个事情都只及格；有的人选择做一个事情，不断往100分靠近。

建言献策

接着上面一个问题，如果你有“批判性思考”的能力，你能看到一个组织存在的各种问题，并想出应对的解放办法。

然后多和同事、和领导沟通这些事情，无论对于个人成长，还是组织，都是一个正向作用。

最后

说了这么多，最后我们换位思考一下：

如果你看到公司某个同事，他关键时候顶的上，他做事追求极致，他思考总是很全面，他对业务的了解总是比其他技术人员要多，他总是很虚心的接受改进，他总是时不时给公司提出自己的建议。。你会如何看待？

技术的价值模型

作为一个程序员，特别是有技术追求的程序员，最经常关注的就是：技术有多么牛，多么复杂，多么酷炫。。可当被问到你做的东西，有什么“价值”时，往往却很难说清楚。

在这里，我想抛出这样一个终极问题：技术的价值到底是什么？

我们都知道Github上有很多开源项目，那么这些项目的价值大小，是如何衡量的呢？下面有一些考虑因素：

以技术复杂度来衡量？

以代码行数来衡量？

以技术的先进与否衡量？

以是否有创新性衡量？

我想都不是。在个人看来，衡量这些项目的关键指标是：多少人使用了这个开源项目。

即使这个开源项目代码量很少，功能也很简单，但如果很多组织、很多个人都在用，那它就是有巨大价值的！

从这个意义上讲，技术所追求的”价值“和产品所追求的”价值“是一样的，殊途同归，最终都是要为“用户”服务。

下面我总结了这样一个4层的价值模型：

第1个层次

程序员最熟悉的，经常谈论的：我这个系统有多少多少个业务模块，我这个系统功能多么强大，我这个系统采用了多少多少新技术，我这个系统采用了某个牛叉的算法…

第2个层次

追问一下，在你所做的所有工作中，最核心的是采取了哪个措施？最终可能会抽象出1到2个。

再追问一下，这1到2个大的技术改进，有什么价值，通常都会追问到软件的各个非功能性需求：

可重用性：我做了某个jar包，某个组件，某个服务，别人不再需要重复造轮子。

可扩展性：来了一个新的需求，我只需要配置一下，或者做很简单的代码开发，就搞定了，不需要改很多系统。

可维护性：整个系统解耦做的很好，代码也很整洁。要叠加功能，或者找人接手，都比较容易。

高性能：用户体验很好，所有请求都在100ms内返回

高并发：能支持千万到亿的用户并发访问

稳定性：系统时不时出bug，宕机，用户报case，我把这些问题都解决了。还加了监控，出了问题立即会有报警。

高可靠：我做了灾备方案，某个机器宕机，系统不受影响

一致性：我做到了强一致性，极大提高了业务体验

……

第3个层次

我做的系统，为公司带来了什么业务价值：

极大提升了用户体验？因此促进了用户增长？

提高了用户的活跃度？

为公司增加了收入？

降低了公司的研发成本？

提升了公司的运维效率？

为公司开辟了一个新的市场？

第4个层次

公司的本质：市场经济下的一个追求利润最大化的组织。

从公司角度来讲，技术也好，产品也好，运营销售也好，最终目的都是要增加公司利润。而增加利润，要么”开源“，要么“节流”。所以你做的任何东西，基本都会被归结到这个层次。

当然，还有一类是“战略性投入”的项目，虽然它本身不直接挣钱，或者挣钱很少，但是为了支撑其他挣大钱的业务而发挥重要作用。

最后

技术、产品、运营，殊途同归！