管理感言_需求开发八字诀

总结起来就8个字：小步迭代，快速交付。   
假如说团队有4人，同时来了4个系统， 每个系统每人需要花费4天， 你会如何安排？
   可能有些朋友会说每人负责一个系统，4天后所有系统都能完成交付了。 其实不然，举一个我自己亲身经历的项目：
    2007年在吉林移动实施了BAM监控系统，前后共计投入10多人，4个模块（监控、告警、报表、工作流），历时长达10个月之久（哈哈，后来大家都调侃这次项目如同女人怀孕）。 当时的模式是：
       5~7月份：移动现场需求调研
       8~10月份： 所有模块并行开发
       11~2月份： 同步上线

  项目结束时，我们开复盘会总结过影响周期的几大因素：
       1. 技术难点
       2. 与外部系统交付花费时间
       3. 需求变化多
        ......
     其中 需求变化因素占比85%， 我们采用的是传统的瀑布开发模型，客户看到的东西是研发按照最初的需求来开发的，因为业务在发展，需求也在不断的变化，往往一个功能还没有完全开发完成需求就已经发生了变化，而研发这边很难感知的到需求的变化， 一旦客户没有及时通知到这种变化就必然会存在返工延误进度的风险。
     因此，小步迭代，快速交付 是行之有效的解决方法。
     我们可以投入足够的人力专心的开发某一个模块，甚至可以在边需求沟通边做开发，让需求变化的可能性降到最低， 拿上面的示例来说，我们投入4个人花1天的时间开发出一个系统比1个人花4天时间开发1个系统的风险要低得多。
     其实这种思想也可以延升到我们日常开发的方方面面，  比如说系统重构，甚至是某个具体小功能的开发。 拿重构来讲，通常的重构都涉及到性能调优，代码结构调整甚至包结构调整等等内容，如果很短时间内能一步到位固然完美，往往重构花费的周期比较长，这就会带来很多风险，如过程中新需求不断涌入， 这时如果不采用小步迭代、快速交付的话就会带来很多额外的麻烦，多个分支版本控制和代码合并将会成为麻烦的事儿。
     共勉。