这是一封写而未发的信。
模式之争，并不很有意义。有人追求短平快、有人追求某种程度的惊艳。
最怕的，就是在不同模式之间摇摆。那当真会令公司死无葬身之地。
争议的内容其实早已表达过多次，与其激烈的争议，不如实践中反馈。
所以，以下的内容，与其说写给老总的，不如说写给自己的。
W总，最近我们项目开发中，暴露出一些问题，
长久下去，担忧我们付出了巨大的努力，公司却不能得到应有的回报。
几个月观察，就公司内部开发状况看，以下几个问题或可商榷？
1. 客户服务支持与开发周期性的矛盾
现在的状况，类似ZZ这样的客户，会直接将需求发送到
研发人员手里，并直接督促进度。这种情况下，研发要克服其他的
项目压力，就非常难以及时交付，造成多方面都达不到目标的情况。
如同这次，原本预计本周五交付的3G/WiFi/触屏更新，只有触屏完
成开发，新版尚未发布出去。另外其他的客户，KK、YY等，也
正朝着这种模式在走。
我们现在的状况，会要求ZZ公司将需求汇总，我们以1周
为节点，发布更新给他们。然而，因为我们兼具其他工作的特点，
并不容易达到目标；而自身兼顾研发的角色，又无法和客户做很好的
缓冲，于是往往被动应付。
建议的客户服务模式为，由项目经理先做抵挡，阶段性汇总后，
按照1～2周为交付周期，全力集中完成。当然这1～2周，其他项目
必须让出时间。
2. 敏捷响应与需求分析的矛盾
我们现在实施的是敏捷开发模式。基本上表现在，客户提出一
个需求概念后，我们就用最短的时间的出一个设计原型，以期打动
客户。项目P1如此，项目P2如此，项目P4也是如此。
然而，站在客户的角度来看，除非市场上的确找不到同类产品
的提供者，不然为什么要用我们这些尚未经过验证的产品呢？我们
自己都觉得不保险，客户如何会选择我们。
YY的10套开发板之所有会选择我们，一来是我们的该型号的开发
板已经有足够长的时间优化，二来有前期的磨合，当然更重要也和您
卓越的口才不无关系。
ZZ公司在这种情况下，仍旧花大量的时间，在和我们一起耕耘，
我认为这不是下面研发人员的功劳，完全是W总您和对方Z总沟通的结果。
我们不能期待每次都这么幸运。
项目仓库上马，直接后果就是质量一般，竞争力不强。这种情况
下，要大量出货恐怕很难。我们也不得不在多次的试验市场的情况下，
搞出很多试验性的付出，这些付出恐怕最后都是浪费的。
改变这样的状况，我的想法，是这样的
a. 敏捷开发不注重形式，需求响应迅速，但是---仍旧需要基本的产品需求文档
这点我们当时做P1项目时，做的还行。
这次展览的项目，我认为做的很不够，甚至连要展出的机器，各自
要什么功能都没有文档定义。直到结构回来安装起来，我们才
看到有其中某台机器的需求，才看到它要连接的外设，
这个也太夸张了。
类似这样的机器，也应该看作项目，要有自己的owner，要有需
求文档。
b. 有几个支撑敏捷开发的要点，切不可少
* 设定里程碑，这个和需求文档的要求是一致的
* 持续集成。
要迫使大家将代码放入svn，并写自动编译、打包
脚本，甚至自动 nightly build.
作为持续集成的基础，以上必不可少。如果为了应付发布
产品的压力，少了这个环节，持续集变成了空话，敏捷也将
不可持续。（这部分工作我会给大家灌输并改进。）
* 测试驱动和循环迭代
经内部测试达到一个里程碑后，再经外部客户测试得到反馈
的结果，然后用文档定义第二个里程碑。
c. 系统性、整体性的规划软件项目。demo性质的程序不要做。
哪怕功能简单点，我们要做到每个里程碑的项目都可用，
而不是仅仅可以demo。
d. 应用软件先行。
如果要上一个项目，先整体性的完成应用软件，并且是完成切实
可推向市场的软件。
硬件平台可以先从其他公司买过来。这样以最小的转换代价完成
对市场的了解，也能以最快的切入速度，完成一个可以用的产品。
这样说并不是说放弃硬件，放弃嵌入式软件平台。在可以用的产品
的前提下，我们再根据产品的需求，研发最经济成本的硬件平台。
某米手机开始是做软件的（安卓刷机包），软件积累的足够多的用户，
了解了足够多的需求后，再上自己的硬件，也就顺理成章。
e. 压缩产品广度，从产品应用深度上下功夫
(转载请标明：http://www.cnblogs.com/xhawk18/)