最近和几位技术经理聊天，都遇到一个类似的问题：如何应对和管理工作中不确定的东西？
相比编写代码等工作，技术管理的事情要"恼火"很多。写代码可以得到比较确定的输出，做出的计划也基本能执行。对于老手来说，工作不能完成的事情很少，及时有也能及时发现。
技术管理不一样，需要应对不同的人、事、外部系统，存在大量的不确定性、风险、决策、责任。这对于刚刚从技术工作转技术管理工作的人来说是巨大挑战。
我把讨论的相关内容整理下来，在这一期的技术管理来聊聊不确定性的问题。
拥抱不确定性的心理
对于很多人来说（包括我自己），技术管理的难点往往是心理上的。表现可能会有这么几点：
- 如果不是我自己的执行任务，可能无论是做事方法、产出结果都无法满足内心的期望。
- 项目过程中存在各种突发状况，害怕自己可能无法应对。
- 我必须成为一个全面的专家，否则可能会在同事面前丢脸。
- 有很多东西我依然不会，害怕可能被坑。
- 外部依赖无法干预，需要求人，而他们的态度可能非常不友好。
- 需要博弈和谈判的东西，我不能把握一定成功。
- 出现问题，我得承担全部责任，老板也可能会把全部责任给我。
- 害怕做出决策，无法做出完美的决策，决策可能会带来不利影响。
- 我追求完美，不同的人来做这些事情可能混乱不堪。
- 我无法预判后续事件的走向，预判失败有可能打脸。
这些问题或许有很多管理技巧和经验应对，但是更多的是心理方面挑战，因为我尚未看到任何一位管理者能完美做到上述 10 点，甚至他们做的也很糟糕。
从某种程度上来说，管理工作就是和失败、挫折、救火、背锅、打脸等负面遭遇一起出现的，这些负面遭遇往往来自于不确定性。
这种心理问题来源于两个点：一个是童年的教育和成长经历，另外一个是现实的条件制约。
现实的条件制约很容易理解，就是输不起，也没人兜底。比如家庭有小孩、老人需要用钱，需要稳定资金流，那么就很难放弃稳定的技术工作转向不确定性的工作，而管理工作虽然相比创业来说，也要比技术工作不确定性大很多。
另外一点就是童年的教育和成长经历是否允许我们接纳不确定性。出生于商人家庭的孩子天生就拥有冒险精神，而大多数家庭更多教育理念还是安分守己，因此这类人成长与确定性的路线中，没有经历不确定性的历练。
这类人想要做出心理上的转变需要经历一个极其痛苦的过程。好在，我们并不需要完美的做到上面 10 点，只要能做到其中一些即可。
如何做到在心理上接纳不确定性？我请教过很多人，当都没有得到有效的"方法论"。有一些人仿佛天生如此，而有一些人经历过长期的历练，但已经不知道自己如何做到的了，他们的经验难以被复制。
而我自己属于后者，好像属于"躺平派"，不得不接纳不确定性的世界和自己的能力限制，接受"不确定性"的"毒打"。
直到我读到过一本书《诠释人性：如何用自然科学理解生命、爱与关系》提到了一个观点让我豁然开朗。
作者卡米拉·庞是伦敦大学生物化学博士，她从小是一名自闭症患者，强迫心理总是伴随于她。她终身都在和不确定性心理对抗，直到她在学习物理学的"熵增"概念时，对不确定性有了重新认识。
虽然 "熵增" 已经是一个"烂大街"的概念了，但她从另外一个角度解读了熵增。
卡米拉讲述了一个故事，她遇到了一些非常优秀的人在公众面前光鲜亮丽，但是在回家后却放飞自我，居家环境脏乱差，衣服到处放。用熵增来解释就是，混乱和不确定性本来就是宇宙的基本规律，如果在工作中把精力花光来对抗熵增，那么在生活中就无力应对了。
生命就是一台从环境中提取能量以此对抗熵增的机器。人们把能量用到了最重要的一部分（工作），所以就没有能量来让家庭保持整洁。
我们期待秩序，但是社会中的、工作中不是所有的问题都那么有秩序。换个角度来看上面 10 点也许有了一些答案：
问题：如果不是我自己的执行，可能无论是做事方法、产出结果都无法满足内心的期望。
答案：我们无法要求所有人严格按照自己的想法做事，这不现实，且无意义，只看最终结果就行了。
问题：项目过程中存在各种突发状况，害怕自己可能无法应对。
答案：代码中也有很多 Exception，关键是有没有足够的 Try Catch，实在不行就报 500 错误吧。
问题：我必须成为一个全面的专家，否则可能会在同事面前丢脸。
答案：管理是 IO 密集型工作，而专家是计算密集型工作。
问题：有很多东西我依然不会，害怕可能被坑。
答案：不是所有模型都能支撑未来业务，关键是有没有预留拓展点，实在不行就重构。
问题：外部依赖无法干预，需要求人，而他们的态度可能非常不友好。
答案：IO 密集型任务处理外部调用的时候怎么办呢？试试响应式编程，当对方不响应时，就处理其它任务，直到返回事件。
问题：需要博弈和谈判的东西，我不能把握一定成功。
答案：输了可能没有成本，而赢了却很赚。
问题：出现问题，我得承担全部责任，老板也可能会把全部责任给我。
答案：管理者的薪资中已经包含了一部分担责的部分，责任很大的人甚至什么都不用干，薪资就挺高。
问题：害怕做出决策，无法做出完美的决策，决策可能会带来不利影响。
答案：没有完美的决策。
问题：我追求完美，不同的人来做这些事情可能混乱不堪。
答案：如果完美能赚钱，老板一定投入大量资源来"完美"。
问题：我无法预判后续事件的走向，预判失败有可能打脸。
答案：老板说，你这么牛*，你来这里坐。
构建工作弹性
虽然不确定性无法消除，但其实也有一些技巧让不确定性对工作带来的伤害降低，一个经验是构建弹性化的工作。
我把弹性从不同的维度总结了几个方面：
- 人员弹性：构建人员能力情况的弹性。
- 时间弹性：构建交付时间的弹性。
- 设计弹性：构建交付方案的弹性。
其实弹性这个问题并不难，但是留意到的人不多，所以把项目做成刚性项目去了，所以被很多问题搞得措手不及，走进恶性循环。
人员弹性是指在人员计划安排时，注意人员能力在一定程度上的重合。举个例子，现在的很多项目都是前后端分离。那么前端人员、后端人员如果严格根据任务量测算安排，就会导致不匹配。
前后端分离是社会化分工的趋势，但是代价就是集成风险变高。如果后端某个迭代前端或者后端人员不够，就会空转。考虑在团队中培养 10% 的全栈人员，这样在前后端方面就具有人员弹性了。
而时间弹性更好理解。按照敏捷开发的迭代思路，如果每个迭代只规划 100 个人天工作量，而做完刚好 100 人天，那么经常会出现时间不匹配问题。比较好的方法是，100 人天刚性需求+40人天弹性需求，团队尽量在状态比较好的时候冲刺提前 20% 左右，当遇到一些状况，例如方案需要变更就能用提前量作为缓冲，保证整体交付节奏健康。
设计弹性是指在做技术方案时根据业务情况做出一些取舍，如果时间紧急可以放弃一些非功能性需求指标要求，然后在迭代后期封板后再进行技术优化。例如迭代前期完成功能性需求，在封板后再补充权限、性能的非功能性需求工作，这些工作不会阻塞测试人员的测试工作。
设计弹性对于外部系统管理类似，很多外部系统无法及时完成需要的 API，可以提前通过 Mock 准备测试数据，不影响当前开发工作。
总结
对于不确定性管理的问题，我曾问过一位老板。他给出了一个不同的答案，在他看来不确定的东西意味着机会，已经被人消除了不确定性的事情意味着没钱赚。同理，在充满混乱的行业比形成秩序的行业商机更多（例如，2010 年的手机市场和 2023 年的手机市场）。
而有时候处理不确定性的工作会比处理确定性的工作更有价值，至少暂时不会被 AI 和应用程序替代。