随笔2：开发任务的分解过程

    在软件开发中，往往因为功能（任务）分解得不够细致而造成过程失控，可能因为功能的反复修改或遇到原来没有预见的技术难点而造成进度延迟，更有可能要推倒重来。在开发过程中，往往是公司交给一个项目组某个项目，只要求几个月完成；项目组分配到某个开发人员手里，只明确到某个人需要完成哪些模块，比如用户管理模块、邮件发送模块等。对公司为说，项目成了最小的分解单位，对开发人员来说，模块是最小分解单位。一个模块如果需要1000行代码，7个工作日，一个人在没有任何工具的支持下，一般不太可能知道具体的细节流程，无法知道会遇到什么样的技术或流程风险。

    软件开发中，十个人有九个人认为开发任务是不可量化的，只能质化，所以会出现以测试驱动开发这样的开发模式，量化，成了很难逾越的鸿沟。其实，我们平时所说能量化的东西，一般是指可以数出数目的个数，比如水果，除了可以数个儿外，还可以称重量，像软件开发这种即数不出又称不出的，理所当然就不能量化了。

    咨询行业曾经是我梦想进入的行业，可惜这个行为像软件业一样，在国外很吃香（门槛很高），在国内成了民工，包括三大咨询公司之一的麦肯锡在中国也上演滑铁卢。咨询行业和软件行业一样，他们的咨询顾问和开发人员的工作也是不容易量化的，不过，麦肯锡的顾问工作任务却是细化到每一个步骤，咨询的内容细化到每一个过程，这种无尽细化的工作方式，应该也适合软件开发，这种任务细化的分析方法叫MECE。

    MECE是麦肯锡的第一个女咨询顾问巴巴拉·明托（Barbara Minto）在金字塔原理（