避免采用开放式工作隔间
有个老生常谈的论调，说开放式的工作隔间有助于软件项目间的沟通。问题在于这样的隔间沟通起来反而杂乱无章，连带影响生产力。有效率而良好的沟通还不如在茶水间放部汽水机来进行。开放式工作隔间有助沟通的论调乍听起来很吸引人，可是经不起确切考验，而且软件研究资料清楚显示开发人员只有在一两个人的办公室内最具生产力。

一些研究发现开发人员在隐密、安静、一两个人的办公室内工作和在开放式隔间的办公室内相比，前者的生产力比后者要高出2.5倍。软件开发是个需要高度思考的活动，如果电话响个不停，广播系统播个没完，人们在你四周走来走去，每隔几分钟就来打扰，怎么可能专心思考问题。

---------------------------------
身为主管的工作要求是每隔几分钟就转移注意力以达到管理效果。
---------------------------------

一般软件开发人员要求几个钟头内最好不要转移注意力，才能专心。许多组织没办法提供开发人员安静隐密的办公室。他们有的是空间不足，有的是要留给副总裁之类的人用。有些组织发现，将他们的开发团队安排到另一个环境去会更好些。其他组织则试着让开发人员带着耳机工作杜绝干扰，或者干脆让他们在家工作。至于其他没办法提供开发人员安静隐密而不受干扰的组织，只好自求多福了。

使用者参与度

软件使用者参与的程度对软件项目很重要。软件成功的关键在于设计出一般使用者爱用的产品。如果没有使用者的参与，软件开发人员常常会考虑技术层面而忽略使用者的需要。这样的话或许软件产品中塞进过多功能，使用者实际用到的却没几种。

要想开发出使用者爱用的软件产品惟一方法，在于问问使用者的是什么，把开发中的产品先告诉使用者，并问问使用者喜不喜欢这东西，聆听使用者的心声并参考他们的意见。

也许项目团队得努力好几次才能了解使用者要的是什么。使用者们也必须了解开发人员让他们看的雏形跟未来的成品也许相差十万八千里。有时有分辨出哪些可能是未来的“使用者”都有困难。这些都会在以后提到。

由于使用者的参与消除了一大变量——摒除了“差不多先生”的心态，这样一来项目所费的时间就少得多了。如果使用者没从头参与，以后对项目产品进行检视时，一定会指出有好些地方没照顾到他们的需要。这时开发团队就得面对一个艰难的抉择：依循原来的预算与时程目标而忽视使用者意见，或是在项目的下游阶段接纳使用者意见而让预算跟时间超出预期限制。通常开发人员会妥协，先采用可立即修正的使用者意见，而将难以立即采用的意见留到程序的下个版本去处理。说老实话，让使用者在产品还具可朔性时愈早参与愈好，而且最好是在那些不被喜欢的东西出现以前。

由于“做了比没做好，早做比晚做好”的观念，使用者对自己参与开发过程的项目反而比没让他们参与的期望更深。表面上，愈早让使用者参与开发的软件愈能满足使用者需求与期望，而这也成了一种质量的认定方式。实际上这样的软件缺陷的确更少，因为它们在开发过程中方向变动较少，而让产品架构、设计方式与实作更稳定。如果在项目中途才加入使用者需求，被迫将没想到的功能加进体质不良的现有构架中时，软件质量一定会大副下降。

除了及早参与、持续参与外，很少有软件项目一开始就找出真正良好的解决方案，一般都必须在使用者坐下来说“是的，这就是我要的软件”以前做出不同版本的使用者接口雏形。一个良好而成熟的使用者接口雏形可以让项目推出后广受欢迎，不过软件的适用性得在开发时就调练好。参照使用者所需导向而做低廉、小型的修正，就不用到了项目末期再大兴土木以致付出高昂的代价（本文使用的阶段性完成策略提供了这样的过程中修正方式）。

参予开发过程的使用者用不着很多，在Jakob Nielsen的《Usability Engineering》一书中指出，当软件适用与否的测试人数在3～9个时，价格获益比最好。

在1994年，Standish Group对8000件以上的软件项目进行检查。结论是使用者的参与是项目成功最显著的因素。在那些失败的项目中，缺乏使用者反应是失败的主要因素。计算机软件的专家指出快速开发项目能够成功的最重要因素在于让一般使用者全程参与开发过程。

----------------------------------
让使用者参与项目开发过程可说是重要的软件项目求生技能。
----------------------------------

产品简化主义

成功的软件项目开发从需求制定到产品推出、继而被接受，都需要一种“化繁为简”的定位方针。因为软件开发工作相当费神，若能将项目彻底简化必然事半功倍。功能规格、设计与实作都应该简化。许多开发人员沉迷与复杂性，误以为“数大便是美”，事实上只有简化项目才是成功的唯一出路。

当开发人员致力寻求项目目标流程的简化时，可说又向成功迈进了一大步，对一般使用者也可能造成影响。一个功能通常可分两小时版、两天版和两周版，开发人员应该一开始先弄出两小时版，通常这个版本的解决方案最简单直接，问题最少。开始实际操作后，如果解决方案还不够，他们才应制作两天版甚至两周版的解决方案，再看看这样是否可以解决问题。解决问题的一贯态度是，先简单后复杂，才不致于因噎废食。

法国作家Voltaire说一篇散文不是在“增一字则太多”时完成的，而是在“减一字则太少”时完成的。软件项目亦同，应该是从软件中去除不必要的东西以进行简化，而不是不断加上更复杂的东西。

焦点防在推出软件

有效率的开发团队全心全力着重产品的推出。微软公司尤其重视“产品推出”。对产品推出有功的开发人员会获得一个“产品推出”奖，感谢他们的努力。在微软工作了许多年的开发人员一般都有一大堆产品推出奖。这样简单的做法强调一件事，微软公司不是靠着开发软件赚钱，而是靠推出产品赚钱，当然这也是大部分生产软件的公司赚钱的方式。

对于无论是替内部使用者开发软件或对一般大众发行软件的开发人员来说，焦点是一样重要的。一个清晰的前景描述可以让任何软件开发团队对产品推出的目标相同。如果开发人员到了项目结尾都还对产品的看法有歧义，将被迫花费上许多时间、努力与金钱来让他们的看法一致。

一个清楚的架构也有助于让开发团队在目标上步伐一致。反之，就难以同心同德。如果一套良好的产品架构确立了，项目的开发焦点自然集中在技术层次上。

软件开发团队必须确保每个技术性决定都朝着简化系统功能的方向前进。如果是开发大学教育项目，也许有必要让项目任意复杂化。不过当团队在开发商用产品时，他们的任务是提供最简单的问题解决方案，任何违反这些原则的决定都应被否决掉。

本文所要传达的信息是软件开发工作本质上主要为了满足实际目标，这个工作有着浓厚的美学标准与科学成分。有效率的软件开发人员了解软件项目不是为了让他们有个筑梦堡垒，而他们也依此排定各项条件的优先级。微软公司的经验显示，这样得到的行动方针能够在项目团队中培养。没有共识的开发人员对于项目是一个累赘，对组织可说没什么用处。

====================================================================
求生检查

项目团队在项目初期就规划了一套解决高成本潜在问题的方法。

项目借助规划审查，在项目完成约10%时决定要不要继续进行下去，以此强调上游工作的重要性。

项目做到了积极的风险管理。

项目规划强调洞悉力和项目控制。

项目规划包含使用者从头到尾的参与。

项目在高生产力的环境中进行，或是假设项目成员生产力恐有不足而先做准备。

项目规划寻求由简而繁的办法，而不是反过来做。
====================================================================

[@more@]