董永乐的盲窗

　　引言：最近花了不少时间在软件开发管理上。总结出自己的一些观点，供大家参考。交付高质量的软件是一个大的系列，而需求管理是我认为最重要的头等大事。

　　需求管理很重要，大多数从事软件开发管理工作的人都知道。
　　可惜，在实际的软件开发过程中，真正重视需求管理的团队却很少。
　　究其原因，主要有以下三点：
　　工期紧
　　预算紧
　　人手紧
　　我们称之为“三紧”。
　　不妨做个白日梦，我们现在管理着这样一个项目。工期很长，而且客户很好说话，不行还可以往后延。预算很宽裕，投资人发话，钱不是问题。人手也充足，全公司找，还可以请外援，差不多能凑成“梦之队”了。
　　这样的项目一定能成功吗？
　　我们向来不以“小人之心度君子之腹”，但是，这次不妨以恶毒的心灵来揣测投资人的意图。
　　对了，这样的项目肯定有一个高不可企的目标。
　　于是，我们又开始颤栗：妈呀，又被架在火堆上烤啊！
　　不受管理的需求，正如不受约束的火焰，它可以吞噬一切。
　　管理好需求，就是让火不要乱烧。而且，该熄火的时候就得熄火。

　　管理这点事，无非道与术。
　　需求管理之道在于意识。必须首先在项目团队内部，然后在项目干系人中普及需求管理意识。
　　需求管理之术在于流程和技术支撑。具备规范的流程和必要的技术支撑才能落地。

　　先来论道。
　　项目团队内部，从项目经理到程序员，如果没有需求管理意识，如果在需求管理方面不能达成共识，必然会出现以下三个问题：
　　1、很难做到“做正确的事”。
　　2、在面对项目干系人时，缺乏信心。
　　3、无法“战胜无理手”。

　　其中，第二个问题必然导致不能对项目干系人产生预期的影响。一般来说，项目干系人缺乏“自觉”的需求管理意识（通常他们潜意识中有那么一点想法。）在需求管理意识方面，项目团队的影响起着关键作用。（这也就是“管理客户”）

　　如何让“客户”（以及其他项目干系人）具备良好的需求管理意识呢？这取决于项目团队（特别是项目经理）与项目干系人之间是否能够有效地沟通。
　　项目团队需要通过各种可能的渠道，向项目干系人灌输一个理念：成功的需求管理是项目成功的必要条件。

　　为什么呢？
　　还是回到那句话：“做正确的事”。
　　需求管理就是要保证项目的资源都用于“做正确的事”。

近期在帮几个客户检查他们开发的系统(源代码检查).

已经很久没有写过程序了. 回想起来最近一次也是5年前的事了.

这些系统都通过了UAT(用户验收测试). 但是在上线以后仍然不时地暴露出问题. 问题的原因之一就是在系统设计中几乎没有考虑鲁棒性.

其实, 鲁棒性应该成为系统的基本要求之一, 尤其是那些基础平台类的系统(Infrastructure).

我自己对鲁棒性的设计没有深入研究过, 原来做设计时, 基本是是遵循前人的经验来的. 经典的程序设计书籍中都会涉及这个问题. 但是很显然, 在进度的"压迫"下, 很多程序员忽略了这个问题.

下面转一篇网上看到的文章. 做开发或者做产品经理的朋友可以参考一下.

匠人浅谈鲁棒性(http://www.eaw.com.cn/news/display/article/7442)

[原文没有禁止转贴, 我就转过来了.]

匠人浅谈鲁棒性
作者：程序匠人    时间：2008-02-26  来源:   

N年前，匠人曾经在“侃单片机”论坛里发起过一次关于软件抗干扰的讨论。其实，当时的讨论基本上已经达到了软件所能做的一切范畴。但是随后，讨论的方向逐渐转向了“软件抗干扰是否有实际意义”上去了。虽然匠人坚持认为软件在抗干扰方面可以有所作为。但是，来自反面的意见，也让匠人深思了许久。

世纪轮回。这次，由emailli网友发起的“建议做为2008年1月的专题----软件抗干扰的方法研究 ”，又把当年的讨论场景再现。别具意味的是，对软件抗干扰本身的置疑也被再次提出。

从某种意义上来说，随着单片机硬件抗干扰性能的越来越完善。软件在此方面的用武之地，似乎确实在萎缩。试问又有几个单片机程序中应用到了软件陷阱呢？比例恐怕很小吧。

然而，匠人最近有事没事，经常喜欢在同事面前卖弄这个词——“鲁棒性”。

鲁棒性
robust
[rEJ5bQst]
adj.
强壮的；健壮的
His robust strength was a counterpoise to the disease.
他身体强壮抵住了这疾病。
粗野的，不文雅的（玩笑）

鲁棒是Robust的音译，也就是健壮和强壮的意思。

鲁棒性（robustness）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。

什么叫“鲁棒性”呢？按匠人的理解，就是，你的程序是否把所有的因素（包括异常因素）都考虑进去了，并且对可能的异常因素采取的规避、补救措施。比如：

1、我们要让一个变量做递增运算，每次+1，达到某一个阀值时清零。那么你在做阀值判断时，是判“等于”，还是判“大于等于”？（正确答案：判“大于等于”）

2、我们要根据一个变量去查表，或散转，假设这个变量正常范围=0~7。那么你有没有考虑过，如果该值大于7后，程序该怎么办？ （答案：先屏蔽（剔除）无效值，再去查表，或散转）

3、我们要让某个IO口输出“高电平”去驱动外部电路（比如说，继电器）。那么你是否只输出一次“1”就认为完事了？（答案：开辟输出缓存，定期刷新输出口）

4、串口接收数据，假设收到“0X00”时执行动作A，收到“0X01”时执行动作B。那么，你有没有考虑过，如果收到的是其他数据，该怎么办？（答案：参考第2例）

这样的例子不胜枚举，每一个细节中都存在陷阱。如果在程序设计中予以考虑，则可以规避；否则，很难说你的程序运行过程中会发生什么事情。

因此，一个好的程序，定义应该如此：“在正常情况下，可以得到正常的结果；在异常情况下，可以得到意料中的结果。”

而不是：“在正常情况下，可以得到正常的结果；在异常情况下，得到不可意料的结果。”

匠人的一些同事（新手）往往会跟匠人来犯犟。强调曰：“我的程序没有BUG啊，是输入不正常导致的。”，云云。确实，这些细节上的疏忽，不能称为BUG。我们只能称之为“鲁棒性”差！

再扩展开来看，在整个系统中，不光是软件需要考虑“鲁棒性”，硬件也同样需要考虑。

举个例子：假设系统工作电压为5V，那么当电压低于5V时，会发生什么事情？考虑过吗？OK，你说你有复位电路，电压跌落时会复位。那么匠人再问：电压快速跌落时可以复位，但如果电压缓慢下降，你的复位电路还能正常工作吗？或者，电压波动时，又会如何？

这样的细节还有很多，贯穿在整个设计过程中。对于有准备的人来说，只要事先预想到了并采取规避措施，都不是问题。对于没有准备的人来说，调试将是一场艰苦的跋涉。因为前进的道路上，“坑”太多了，指不定在哪里跌倒。

以上，为匠人信口开河。欢迎探讨。

吉姆决定继续表达他坚定的立场“我认为，大多数企业所生产的产品太过庞杂了，这反而削弱了他们的实力。他们的资源被分散了。对短期市场需求做出被动反应而推出的产品并不是最好的。我们最好还是选出几个最具有潜力的产品，并让他们不断发展而成为市场中最佳的产品。”