以下所有项目都是指技术项目

要大系统，不要大项目

要大系统，最好把整个系统作为一个系统来看，然后在系统内部有不同的分工，而整个系统的底层体系尽量统一

就像点评，整个系统都是统一的，有统一的项目结构、底层框架、接口标准等，在统一的系统结构基础上搭建不同的应用实现，这样的好处显而易见，可以有统一的业务透明的监控CAT，还可以有统一的快速构建工具等，之后要做任何业务无关的技术升级都只要统一升级底层框架，业务不需要知道，也不会受到影响

以上是大系统的好处，做技术的都懂，不赘述，下面说说大项目

我想，大部分人都是希望做大项目的，我觉得大家都懂的~

那为什么不做大（技术）项目呢？这个我觉得应该从技术的定位说起，技术作为业务的支持部门，目标是支持业务发展，做大的（技术）项目必然会影响业务需求的开发。如果说这个大的技术项目不做，后面业务会出问题，那就要反问：“之前系统有这么烂？” “你这个项目不能分块上？那是不是模块设计不合理，耦合性太强？”

全部规划，部分实施

上面讲了，既然不做大项目，又要大系统，做法其实很简单“全部规划，部分实施”，我见过的所有优秀的系统都是这么做出来的

丑丑的示意图

“全部规划，部分实施”这句话浅显易懂，可是却不容易做到

一方面需要架构设计的技术能力，要不然不可能开始做的时候就把系统全部的内容都规划清楚

另一个方面需要非常强的计划执行能力，在技术设计完成之后，需要根据系统模块的重要程度做实施计划，并且不断的监控和推动各模块的实施，最终在一定的时间内把规划的整个系统做完。从我个人的经验来说，分块推动完成一个大系统的周期长，难度要高于集中时间做一个大项目，关于计划我还有另外一篇文章会单独做分享，敬请期待~

润物细无声

没有完美的系统，所以系统一定是需要不断做优化的，这个毫无疑问，所以“润物”一定要做

而“润物”要“细无声”，如果不停的有雷雨，肯定会有人受不了