高挑战事情先做还是后做？

Posted 2021-12-29 安柏霖

负面案例

这个也是最近一个技术组中遇到的问题，在做优化的时候，遵循了“工欲善其事必先利其器”的原则，所以花了挺长时间去打造工具流程这些。
以及先把难得东西先做了；
带来的一个问题，一些简单的事情迟迟不能落地，结果“半天没出活”，项目组也是感觉比较焦虑；
甚至其他团队也过来要一起做一些优化，提一些建议等等，让整件事情更乱了。

正面案例

当然我们在开发过程中，更多的是“工欲善其事必先利其器”的正面案例，以及先做高挑战的事情；
比如在做天刀手游的过程中，我们设立了很多底层的“颠覆性”的修改，则是最好的程序最优先做；
简单的事情留到后期做，最终是取得了比较好的结果。
如果反过来，先做了简单的事情，那么这些底层高风险的优化，留到后期，可能会出现风险评估下来做不了的情况。

宏观视角，具体问题具体分析

前面两个情况，写出来，我们马后炮一下固然简单，但是团队身处其中的时候选择起来未免还是有困难。
实际工作中，其实问题也往往不这么一清二楚，可能就是一个70%，60%合理性的这种。

这里谈下个人看法；
首先要有一个宏观视角，把整个开发过程的方方面面罗列出来，这里包括不限于

• 开发点，开发所需的人力，时间，产生的结果，依赖项
• 团队当前的状况，是压力大急需结果，还是可以从容不迫，可以长远打算
• 人力分布，几种人力排布下，在整个周期会产生什么样的结果
• 。。。

然后几种策略下做好沙盘推演，具体问题具体分析。

团队状况

回到第一个负面案例：
如果团队现在士气受到开发进度影响，比较焦虑，那么就要放下“长远打算”，尽快的出来一些进展（比如性能优化），让大家处在一些比较安全的情况下会比较好；

这里倒是可以谈几个状况：

• 上策：上工治未病，当然是尽早的规划，让项目组知道什么阶段有什么问题，在进入焦虑期之前问题已经解决大半，这种最好
• 中策：技术团队有良好的信誉，在团队焦虑期，依旧有对技术团队的信任，那么这里依旧用开发视角最有策略来处理依旧可以
• 下策：扁鹊这种，紧急缓解症状，处理容易的问题，把问题从大化小，然后逐步缓解；
  最后的case，就已经进入了对开发效率不利的状况，长期如此，团队就是整天救火，会很不好；

受迫性失误以及其意义

这里谈下最后的case，就是事情压过来，已经避无可避；
那么就进入“狭路相逢勇者胜”，硬钢硬抗，拼的是当下战斗的爆发力，把事情紧急灭火；
这里大概率会出现，避免了最严重的损失，但是整体上已经不是最优的情况了（应该还差挺远）

同时，后续复盘至关重要，可以评估下，进入这种“受迫性失误”我们损失了多少。
一定做到“肉痛”，记得牢牢地；
然后在后续的长期规划中，才能足够的用力；

战略懒惰

长期规划在我个人看来，比紧急灭火要难非常多，因为要靠大脑汇集所有因素，格外的烧脑；
长期的开发，或者紧急灭火，有点像跑步机上跑步，虽然一身汗，消耗能力也多，但是没那么费劲；
长期规划则是一个力量训练，举一个大重量，那是真的难。
所以战略懒惰的出现，才是一个正常现象，我们要规避这个，除了有这个“避免战术勤奋弥补战略懒惰”的意识，就要让自己在之前的战术勤奋中吃的苦头，牢记在心。

人力分布

这里容易出现的问题就是因为“受迫性团队压力”或者规划糟糕；
比如一个典型case：

1. 现在一堆事情，中间有简单的有难的
2. 所有人尽快处理好容易开发的，容易出结果的事情
3. 资深程序做了应该更junior开发者做的事情–这个阶段看起来很好
4. 简单事情做完了，难得事情只有senior能做，junior只能在旁边拍手叫好。。。

所以赢得空间，合理规划就是了，道理非常直接，不展开了。

sum

总归道理是死的，各个点上生搬硬套，肯定不行；

• 多算胜,少算不胜,何况不算乎，整体规划才行；
• 基于原则，结合实际，落地才给力；