第9章 Customer-oriented Development（面向客户软件开发）
Customer（“客户”）这个词，是指花钱购买拟开发软件产品的人或负责验收软件产品的人。我们可以简单地把最终用户视为“客户”。在所有项目中，通过改善客户关系提高开发速度是一条普遍适用的原则。
9.1 客户对于快速开发的重要性
以下是在快速开发软件项目中需要花费精力经营客户关系的两个主要理由：
l 良好的客户关系能够提高实际的开发速度。如果与客户具有合作而非敌对的关系，能够与之进行较好的沟通，实际上就是消灭了一个导致开发低效、产生严重错误的主要来源。
l 良好的客户关系能够让客户感觉开发速度较快。许多客户之所以关心开发速度，是因为他们害怕你根本完不成项目。如果在开发过程中向客户提供较好的进度可视性，则会增加客户对开发人员的信任度，其对速度的关注将相应减少，而把注意力转向功能、质量等方面，从而使开发速度仅成为众多因素之一。
9.2 面向客户的开发实践
9.2.1 需求分析
需求分析中最具挑战性的问题是如何获得真正的需求。一项基于经验的研究表明：若客户在制定需求的过程中有“很高”的参与度，则能将软件生产率提高50%左右。
在制定需求规格书时让客户多参与固然重要，但同时需说明的是：需求规格书不能完全由客户编写，否则同样会使生产率降低。
| 最佳实践：User-interface Prototyping（用户界面原型法） 1. 在开始使用用户界面原型法之前，应确保每个人都明白用户界面原型的唯一作用是引导用户需求，因此是用完即扔的。确保管理层和开发人员都了解这一点。 2. 构建原型的开发人员应该是有开发经验的人员，他/她应该具有良好的开发意识，即使用最小的代价来构建原型。因此： (1) 应选择适合于快速界面开发的原型语言。 (2) 关注于用户能看到的界面，而对后台的数据处理、网络访问、文件读写等操作则可以用stub（假象）来替代。 3. 把构建出的原型交付给最终用户，由用户本人来测试、使用，并提供反馈意见。确保用户不只是被构建的原型所吸引，而是真正考虑了原型是否已包括了所需要的全部功能。设计一个checklist，以便与用户进行全面的审核。 4. 根据用户的反馈意见，修正原型，并向客户演示更新后的原型，确保双方对系统的理解一致。 |
9.2.2 软件设计
| 最佳实践：Designing for Change（面向变更的设计） 1. 在软件开发生命期的早期就应该引入面向变更的设计。 2. 应该在设计阶段或更早的阶段，识别最有可能发生需求更改的区域，创建潜在变更的清单。下面是经常发生需求变更的源头： l 硬件依赖性 l 文件格式 l 输入与输出 l 非标准的语言特性 l 难以设计和实现的部分 l 全局变量 l 特定数据结构的实现 l 抽象数据类型的实现 l Business rules（业务规则） l Sequence in which items will be processed l 当前版本中好不容易才排除的需求 l 当前版本中很轻易就排除的需求 l 为下一版本规划的feature 3. 采用Information Hiding（“信息隐藏”）方法将可能发生变更的设计结果隐藏在它自身的模块中，常用的方法有： l 模块的接口应设计成与模块内部的变更无关。 l 使用数据驱动法，并确定好数据是存储在源文件中还是外部文件中。 l 将为通用功能编写的代码与为专用功能编写的功能分开。 4. 定义程序族，而非一次只考虑一个程序。设计者应该尽力预测整个程序族的需要，包括横向的版本（内部发布，英文版，欧洲版和远东版）和后续的版本。 |
9.3 管理客户期望
软件开发领域的诸多问题，尤其是关于开发速度的争执，大都源于客户对项目持有的不现实的期望。不现实的期望常由于进度计划引起。许多项目在需求和资源尚未确定的情况下，便由客户制定了进度计划。如果开发人员对一份不现实的进度计划表示同意，必然会使客户产生不现实的期望。轻率的许诺在项目初期或许会令各方满意，但从长远来看，这会损害开发人员的信用，并破坏同客户的关系。
因此，开发人员协助用户在制定进度计划时建立现实的期望，是项目成功的关键之一。开发人员可以采取以下的做法：
l 努力弄清客户的期望值。这可以减少大量的矛盾和额外的工作量。
l 培训客户，使他们更好地理解软件开发过程。
l 坚决拒绝客户提出的不合理的进度计划，坚持由科学的估算过程得到的估算结果。
第10章 激励机制
毫无疑问，激励是决定工作表现最重要的影响因素。大多数关于生产率的研究表明，激励对生产率的影响比任何其它因素都大。尽管激励因素看不见摸不着，但怎样激励软件开发人员也并非神秘莫测。本意将详细阐述激励开发人员以提高开发速度的方法。
10.1 典型的Developer Motivation
不同的人会因不同因素而得到激励。激励开发人员的因素并不问题和激励管理人员的因素相同。表10-1按开发人员和管理人员将各自激励因素的重要程度进行了排序。
| 顺序 | 程序员和分析师 | 软件经理 |
| 1 | Achievement | Responsibility |
| 2 | Possibility of growth | Achievement |
| 3 | Work itself（工作乐趣） | Work itself |
| 4 | Personal life | Recognition |
| 5 | Technical-supervision opportunity | Possibility of growth |
| 6 | Advancement（晋升） | Interpersonal relations, subordinate |
| 7 | Interpersonal relations, peers | Interpersonal relations, peers |
| 8 | Recognition | Advancement |
| 9 | Salary | Salary |
| 10 | Responsibility | Interpersonal relations, superior |
| 11 | Interpersonal relations, superior | Company policies and administration |
| 12 | Job security（工作保障） | Job security |
| 13 | Interpersonal relations, subordinate | Technical supervision opportunity |
| 14 | Company policies and administration | Status |
| 15 | Working conditions | Personal life |
| 16 | Status（身份地位） | Working conditions |
开发人员与管理人员之间的比较很有意思。与管理人员相比，开发人员较少关心责任感和受认可程度。若要激励开发人员，更应强调技术挑战性、自主性、学习并使用新技能的机会、职业发展以及对他们私人生活的尊重等。
应注意：不同的激励因素对不同的人有不同的效果。一般的激励因素可能对大部分人都起作用，但若能针对某个人考虑对他有用的激励因素，则效果会更好。
10.2 最重要的5个激励因素
10.2.1 Achievement
软件开发人员喜欢工作。激励开发人员的最好方式就是为他们提供一个良好的环境，让他们能轻松进行喜欢的工作——开发软件。
10.2.1.1 Ownership
Ownership是achievement motivation的关键。当人们实现他们自己的目标而非他人的目标时，他们会更努力地工作。因此，在做以下的决策时，软件经理都必须让开发人员参与其中：
l 同意按新的进度计划交付
l 同意交付新的feature或feature modification
l 招聘新的团队成员
l 挑选赴项目外短期任务的开发人员
l 产品设计
l 技术方面的权衡决策（例如：是以牺牲Feature B为代价来提高Feature A的性能，还是相反）
l 改变办公室空间
l 改变计算机硬件
l 改变软件工具
l 同意交付团队已有规划或尚未规划的产品（例如：由客户使用的原型或产品的预发布版本）
l 同意使用新的开发过程（例如：一种新的变更控制方式，或一种新的需要规格书样式）
10.2.1.2 Goal Setting
设定明确的开发速度目标是加速软件开发的简单有效的方法，但却容易被人忽略。你可能会问：如果设定了development-time的目标，开发人员会为了实现这一目标努力工作吗？答案是肯定的，如果他们懂得该目标是如何与其它目标相一致，并且如果这组目标从整体上讲是合理的话。但是，如果这组目标是朝令夕改或者从整体上讲完全不可能达到，那么开发人员则会不予理睬。
| 最佳实践：Goal Setting（目标设定） 1. 产品经理或客户只需简单明确地把自己想要得到什么告诉开发人员： l 想要最快的进度 l 想要最小的项目风险 l 想要项目进度的可视性程度最大 2. 但是，只设定一个目标！同时设定多个目标反而让人不知所措。 3. 一旦设定好目标，管理人员就应该同软件开发人员一亲，关注于该目标。 |
10.2.2 发展机遇
一个企业可以考虑从以下几方面鼓励员工的职业发展：
l 提供报销学费的进修机会
l 给员工提供参加培训或自学的假期
l 报销购买专业书籍的费用
l 安排开发人员到能扩展他们技能的项目上工作
l 为每个新的开发人员指定mentor（这既向新人也向mentor表明了企业致力于职业发展）
l 避免过度的进度压力（进度压力过大会给开发人员造成企业的首要任务是不管任何人力代价开发新产品的印象）
10.2.3 Work Itself（工作乐趣）
工作中有5个方面是激励的源泉：
l 技能的多样性
l 任务的完整性
l 任务的重要性
l 自主性
l 工作反馈
工作乐趣也说明了为什么对软件开发人员来说，quality比schedule更具激励作用。能在技术前沿领域有所创新是技术型人才最大的动力。
10.2.4 私人生活
对一个公司来说，要想用私人生活因素来激励员工，就必须做出实际的计划使开发人员有时间享受个人生活，比如：
l 安排休假和假期
l 弹性工作时间（允许员工在工作日偶尔外出）
l 不加班
10.2.5 Technical-Supervision Opportunity
Technical-supervision opportunity并不局限于将某人指定为项目的technical lead。你可以更广泛地运用这种激励手段：
l 指派每个人分别作为某个特定领域的技术负责人，如user-interface design、database operations、printing、graphics、report formatting、analytics、networking、interfacing with other applications、installation、data conversion，等等。
l 指派每个人分别作为某个特定任务的技术负责人，如technical review、reuse、integration、tool evaluation、performance evaluation、system testing，等等。
l 除新手外，指定所有的人作为mentor。可以指派second-level mentor与first-level mentor一直工作，second-level mentor有助于mentoring activity更好地开展，他们也可以为first-level mentor提供更具技术经验的建议。
10.2.6 利用其它的激励因素
10.2.6.1 Reward和Incentive
开发人员会因为公司不进行奖赏而变得倦怠，因此奖励对long-term motivation来说非常重要。但是，现金形式的奖励必须谨慎处理。开发者一般都善于进行数学计算，他们会估算出和他们的付出相比，奖金是否值得。糟糕的奖励制度就是给了最佳表现者6%的奖励，同时也给了表现平庸者5%的奖励。最终，最佳表现者的积极性受到了挫伤并离开了公司。
向团队成员表达出纯精神上的感谢态度也很重要。一个公司如果想要在本行业保持20年以上的领先地位，就必须要有卓有成效的非货币形式的激励措施。公司可以考虑以下的一些方式：
l 对取得某个特定的成绩表达真诚的赞赏。
l 团队的T恤、polo衫、手表、徽章、招贴画、奖杯等。
l 幽默或严肃的证书、纪念品等。
l 重大成果的特别庆祝活动。根据小组的喜好，可以是在喜欢的饭店进餐，或者是看演出、潜水、滑冰、旅行，也可以是在老板的依据晚宴。
l 为该小组分布特殊政策，如周五可以着便装上班，为该小组添置乒乓球桌，冰箱里放置免费饮料等。
l 专门的（外地）培训方案
l 晋升或提拔
l 特殊奖金
10.2.6.2 Performance Review
正确地进行业绩评价具有很大的激励作用，而对员工的业绩评价不当则会明显挫伤积极性。业绩评价是管理者所能提供的最重要、最贴切的工作反馈，并会长时间影响下属的表现（可能是正面的，也可能是负面的）。因此，业绩评价必须是经过高度权衡之后才做出的。
如果一个组织一年内进行1-2次业绩评价，就可以利用这种高度权衡的方法。必须注意的是：进行业绩评价应当增加而不是削弱开发人员的工作动力。
10.3 士气杀手
10.3.1 糟糕的工作环境
良好素养的开发人员更看重公司能够为他们提供工作条件从而可以高效地工作。如果工作环境的基本要求都不达标，那么就会挫伤这些开发人员的积极性。
| 最佳实践：高效工作环境 1. 努力为开发人员营造一个敞亮、安静和不易受打扰的工作环境。以下是一些考虑因素： l 合适的光照、供暖（最好有窗户）。 l 足够大的桌子和相对封闭的工作间隔。 l 比较安静，可以集中精力工作（如推行电邮或网上即时通讯）。 l 可方便地使用办公设备（复印机、打印机、传真、会议室）和办公用品（笔、纸、白板）。 l 能立即或很快修理计算机故障。 l 好用的软件工具。 2. 开发人员、团队负责人和低层管理者通常没有权力把一个小组移到一个高效的办公环境中。但如果项目的进度压力很大，并且管理层很关心提高生产率，那么可以试着要求提供更为安静和私密的办公空间，并承诺提高生产率来回报公司。 3. 注意选择在不紧张的时间段来改善办公室环境，最好是在两个项目之间。 |