专精专业和冗余流程的管理应该在什么时候把握平衡
在写程序和架构的过程中，经常会面临到底是以快速实现功能为目标取向的单点服务系统，还是在开始设计架构和功能的时候就考虑周全的分布式具有冗余的系统架构。 以技术角度看，得出合理的结论并不是特别难。在前期快速产品迭代争取竞争优势的时期，只要能保证基本的稳定性，当然是怎么快怎么来，单点未必就不是最佳选择。
在技术管理的过程中是同样存在此类情形的，通常小创业公司，小团队在快速实现功能的时候，往往由于人员限制，是基本没有什么人员冗余考虑的，某些服务和架构几乎全部把持在单个技术人员手中，缺点是有的，如果人员忠诚度不高可能会造成一人流失，整个产品受影响，但换个角度这种情况能把持到一个人手中，通常不是技术合伙人也是核心员工，这种风险其实并不高，而且有较好的优势是技术核心人员成就感，责任心是爆棚的，这还不算什么，由于许多服务，代码都是核心的1，2个人员维护，迭代速度非常可观，给产品提供的技术驱动力就很可观。
这种技术驱动力能持续多久，取决很多方面，其中有一方面就是在产品已经具有一定规模后，CXO究竟是认为自己的产品已经形成技术壁垒，能在一定时间内阻挡竞争者，还是认为自己的产品依然需要不断的迭代，进一步拉开自己于竞品的距离。前者，CXO们会开始着手开发流程，加入项目管理，开发过程管理，运维管理，权限回收，人员冗余，通常这些也会带来测试需求上升，测试地位拉高的情形，无论是经典互联网或是新创互联网，基本都会把流程偏向与传统的软件开发流程，形成比较固化的瀑布式开发，或稍微好点的是螺旋模型。一定程度上会让产品质量得到提高，但迭代速度因为各类流程，必然不可避免的降低，期间性价比就看各自的权衡了。
还有一种CXO们，会依然保持非常快速的产品功能迭代，由于人员规模变大，流程不规范，虽然依旧能仰仗那几个核心技术人员，但人员的沟通成本是上升的，开发过程缺少规范流程，软件质量有部分是有影响的，但好在产品迭代速度快，功能和其他运营方面的出色能遮盖这部分软件瑕疵，他们依然会在瑕疵并存的过程中快速成长。这个过程对人的仰仗是多余对开发流程规范的仰仗的，如果存在靠谱的核心团队，这种模式会具技术竞争力。
没有哪种是所谓的绝对好的模式，CXO们当然不会比我笨。寥寥几笔全当笑话看吧。