研发管理的三类问题

love1

《管理的常识》一书里说，管理的核心是不断的解决（推进工作过程中出现的各种）问题。同样地，我认为架构设计和研发管理的核心，都是不断的解决（系统设计实现与演化过程中的各种，研发过程和工程项目上的各种问题）问题。

三类问题

万维钢老师在《精英日课》里说，这个世界上的问题，分为三类。

第一类是目标明确、路径明确的，比如你上高中的时候，你知道把几门功课都学好，就能上个好大学，这就是一个单纯问题，但是可以看到，单纯问题也可能是非常难的。钱能直接解决的问题，一般也是这类问题。比如说，改进一个现有系统的DB性能，完成一个项目的新需求开发等等。

第二类是两难问题，选择就意味着放弃，比如两个女孩喜欢你，一个有钱，一个漂亮，选了有钱的就不漂亮，选了漂亮的就没有钱。路径很明确，但你面临的痛苦不是因为问题很难，而是不管你怎么处理，都需要付出失去的代价，放弃潜在的另一些可能，会在将来造成实际的损失。你跟小张结了婚，10年后天天吵架，后悔没有取晓丽，红玫瑰与白玫瑰。比如说，你要考虑在两个方案里选择一个做trade off，你要在质量、周期、成本中牺牲掉一部分。

第三类问题，我们叫棘手问题，这类问题，即可能没有特别明确的目标，而且也没有任何人能告诉你一个明确的路径，你现在做了什么努力，可能也短时间看不到效果，做好了不一定有很大成果，做不好肯定要背锅。大家可能都知道这个问题在，就是没有人去解决或者能去解决。最关键是，从外部的一些人看来，这些问题，很像是一个单纯问题。这特么就扯淡了。

比如说，你去一家小公司的研发团队做个leader，然后第一个月你感觉到研发体系非常混乱，你随便找个老员工一问，大家都知道很乱。你信心满满，你想把BAT的经验拿来改造体系，你找你的老板说你要搞这个事儿。你搞了几个月发现，我擦，你自己把一个棘手问题当成了单纯问题：这个公司现在很多地方可能就是依赖现在这个看起来混乱的low逼办法才能正常运作。

再比如几个常见的把棘手问题当做单纯问题的，一个创业者说我现在什么都齐备了就差一个程序员了，马云要是雇用我我一定能做一个东西打败微信，化腾要是给我足够钱和人我1年就可以打败淘宝。

所有讨论问题，如果不是你擅长的专业领域，不要想当然把别人的问题当做是单纯问题。

关于重构

多说一点，研发管理就意味着我们经常要接手老团队，维护老系统。老团队和老系统，都会存在很多问题。团队问题，这里先不讨论，只说系统，很大可能会出现：有人跟我说，某个系统代码太烂了，要重构。

如果有人跟我说，某个系统代码太烂了，要重构，我会问他几个问题：

1、系统的性能和稳定性怎么样？是不是一直在出问题。

2、业务方和重点客户对系统有什么核心诉求，抱怨的问题有哪些？

3、现在这个系统的研发资源和交付效率怎么样？

4、这个系统的业务方未来的规划是怎么样的，新需求多不多？按现有的条件，能不能满足？

这些问题，才是核心问题，比代码本身的问题，重要得多。如果这些问题不去面对，那么重构也不会解决这些问题。相反，重构带来的复杂性和其他问题，会把我们自己也变成问题。

有人会说：一般抱怨代码烂必然由上面说的问题，不难改谁去抱怨？

很好，如果抱怨它烂，就把烂的程度，度量出来。

没有量化就没有改进。

或者换个角度考虑，你怎么来衡量，你重构以后，能比现在好，好多少？

Judgement is cheap, show me the Fact.

很多时候，开发者不是不想把质量搞好，比如三天的活，我们要一天干完，没别的可选。这个时候，我们也不能只看到代码烂，而看不到开发者，为了按时交付而做出的努力。

所以，不评价事情，just 去解决问题。

plug

第二类是两难问题，选择就意味着放弃，比如两个女孩喜欢你，一个有钱，一个漂亮，选了有钱的就不漂亮，选了漂亮的就没有钱。路径很明确，但你面临的痛苦不是因为问题很难，而是不管你怎么处理，都需要付出失去的代价，放弃潜在的另一些可能，会在将来造成实际的损失。你跟小张结了婚，10年后天天吵架，后悔没有取晓丽，红玫瑰与白玫瑰。比如说，你要考虑在两个方案里选择一个做trade off，你要在质量、周期、成本中牺牲掉一部分。