当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班开发了，各种各样的奇葩需求和无理变更，也会烟消云散。但是，在接下来的十几年，几乎没有那个互联网公司再去通过CMM认证。
是否CMM这种软件开发模式，就根本不适合互联网行业呢？这是一直以来我都在思考的问题。反而是跟随着互联网企业的一步步长大，我无意识的体验了很多现在流行概念的早期实践：敏捷、重构、持续集成、DevOps，这些实践一开始都非常的幼稚粗糙，但是却真正的伴随着互联网业务的逐步成长。所以，在讨论互联网服务的开发模式时，我认为必须要先搞清楚互联网服务开发的核心问题是什么。
软件到底是“服务”还是“产品”，这个话题一直都非常具有争议。作为程序开发者，实际上是非常希望软件能够是一个产品，因为软件的后续维护和修改，往往是“导致”项目失败的最常见原因。然而事与愿违的是，在互联网企业中，打多数的软件项目，表现出来的是典型的“服务”特征：
没有明确的需求合同。这导致了没有办法为软件设计固定的开发方案，也难以确定长期目标。没有预付款和客户验收。互联网服务用户来了就用，爽了就给钱，不爽了就走，连沟通的机会都不会有。甚至连明显的销售环节都没有。很多互联网公司只有市场推广部门，而没有所谓“销售”部门，因为推广就几乎等于销售，在推广的同事，就必须把销售的事情一起做了。
因此，在互联网行业中，软件开发更多的是以一种服务的形式存在。这种特征，在对需求的分析管理；开发技术的选择；集成与测试；运营和客服四个方面，都导致了不同于“产品”型软件的巨大差异:
对于一项服务来说，需求是持续变化的，你可以找到一些通用的模式，但是必须保持变化。开发效率是第一重要的，因为市场竞争中，应对需求变化快的单位将获得更多的客户。
由于服务必须保持长期的稳定可用，又要具备快速的更新部署能力，所以系统集成的效率和质量要求非常高。所幸的是系统运行的环境大多数都是在可控制的空间里（比如开发公司自己的机房内）。
服务是公司和客户的一种持续沟通和交互的过程，并非一个单向的发售行为，所以互联网服务需要更多细致的运营和维护的工具，否则难以做到迅速而细致的满足海量的互联网用户的需求。
小米的MIUI开发节奏
管理：手段.vs.工具在各种项目管理的课程里面，陈述了大量针对人去工作的方法。各种会议、报告、表格、评估、测量多不胜数，然而软件项目进度的控制，依然是一个难度堪比登月的事情。——对于很多项目经理来说，程序员们基本是一个黑盒子，他们自己都不知道一个事情需要多长时间干完，就更别提别人怎么去预估和控制。这里最大的问题，我觉得是：我们往往总是想着怎样“控制”住软件项目的进度，而忽视了如何减少不利于项目进度的因数。实际上影响软件开发进度的主要因数，一般有一下几个：
程序员的能力水平。有一些项目其中的技术，是程序员完全没接触过的类型，这里包含了学习、调试的时间。开发过程中的各种修改变更。由于对可行性、需求确认等方面的因数，开发往往会走“回头路”。有些项目做到一般会发现技术上不可行，需要修改需求；而另外一些项目是在项目做到一半甚至快完成的时候，需求方发现需要修改产品设计，因为在产品可体验之前，完全无法想象到最后会是现在的样子。各种和开发无关的过程中的事务。这里包括开会、写报告、沟通、等待开发电脑编译、处理开发服务器故障、各种开发环境和测试环境的问题处理等等……这些事情往往都看起来不是非常“有技术含量”，但是实际上会严重影响开发进度。因为开发工作需要一个稳定、专心的工作环境，频频的被各种事务打断，会让程序员反复的花费时间去“进入”工作状态——面对成千上万行程序代码，要找到之前写到哪个部分，其实不是那么简单。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
