微软研发致胜策略

 

第一章奠定基础

1．千万不要把程序设计师的时间浪费在改善产品以外的工作上。

2．保护程序设计师不受任何阻碍和干扰。

3．永远记得自己真正的目标，然后让团队用最有将效又最愉快的方法把它完成。

4．理清详细的项目目标，可以避免在不必要的工作上浪费时间。

5．不要因为制定目标需要花很多时间，或是别人都有没有做，就省略了目标的制定。制定明确详尽的目标所花的时间，绝对会让团队得到更大的好处。

6．事前决定最合适的优先考虑顺序，以及各考虑点的质量规范，能够指引开发团队的工作。

*重点提示：

l        公司聘请程序设计师，是为了开发高品质的软件，但如果经常被杂事打扰、分心，就无法保持专注在真正该做的事情上。主管必须确定程序设计师能专心投入在具有策略价值的工作上，而不是打杂，凡是会阻碍软件开发的东西，主管应该毫不犹豫地把它排除。

l        然而，有很多杂事其实是无法避免的，大公司尤其如此，那就只好将它的负面效应尽量减少，方法是不断自问：“我到底想要完成什么？”“我该怎么做才能既保持这件工作的好处，又能避免它的坏处？”要满足实质上的需求，而不是表面上的作业程序。

l        拥有明确目标所带来的好处虽然不是立竽见影，但没有明确目标所造成的混乱绝对是显而易见。没错，建立明确目标是一件费时又无趣的工作，但比起项目延误或失控的危险，肯定是值得付出的。请记得使用者界面函数库的实例，项目目标只要稍微改好一些，就会明显地减轻压力，项目目标再修正一次，问题就几乎都迎刃而解了。

l        每一位成员都必须有一致的程序优先考虑顺序，程序的可维护性是最重要的吗？可移植性？体积？速度？为了让软件产品符合项目的目标，必须让程序设计师明白本项目的程序优先考虑顺序，他们在程序设计时才知道该如何取舍。同时，您还得对每一项优先考虑点事先建立质量规范指导，以避免到时候质量不合格又得重写部分程序，导致时间浪费和项目延误。愈早定出质量规范指针，愈能省时省力。

 

第二章策略性的作业方式

1．一发现错虫就立即清除掉，别拖延。

2．妥善运用可以促进开发成效的策略性工作方式。

3．不要把策略性工作方式当作训练的教条，应该向组员解释这些工作方式的内涵与用意。

4．提出精确详尽的问题，可以引导出真正有效的策略性工作方式，帮助项目目标顺利完成。

5．策略不是死的定律，要把它当作指导原则来活用。大部分的时候都应该遵循，但也有例外的时候。

6．在您的软件开发活动中，小心谨慎地运用负回路的观念，让项目顺利进行；但务必要注意避免反馈回路的不良副作用。

*重点提示：

l        小小的改变可能产生惊人的效果，所以，请仔细观察您现有的作业方式，会很容易发生问题吗？耗费很多时间吗？矫枉过正或防弊重于兴利吗？会不会让人员心生挫败，而造成生产力低下？如果是的话，请找出一种简单又有效的方式改善这些情况。

l        当您决定采用任何一种策略性作业方式，请解释您的用意，让组员充分了解是什么方面应该改善。这种开放的做法会在无形中教育组员，让组员学会思考，也许，时间久了之后，他也能想出很不错的点子。

l        当您针对问题寻求解决方案时，一遍又一遍地修正您问自己的问题，培养自己能够提出精确的问题，想出更好的答案。但光是精确还不够，精确的问题也可能是错的问题，让您得到没有帮助的答案。您必须注意，问题是否切中要害，是否是您真正想达到的目的，是否是您的理想状况。不要自问：“如何叫程序设计师加班？”要问：“如何增强工作效率？”

l        策略愈是吸引人，愈会有多人认同它，甚至把它当成牢不可破的定律。请提醒您的组员，再好的策略也不能应付每一种情况，“避免用goto”是公认的好的程序设计策略，它让程序可读性提高，但是当不用goto的结果是可读性反而更低时，您得教程序设计师如何权衡取舍。

l        每当您建立一个反馈回路时，请务必考虑它的副作用和长期使用的效果。最好的反馈回路不但可以随着时间增强效益，也能同时减少负面的作用。

 

第三章保持进度

1．每天都要问自己：“有什么事情是我今天能做，而且会帮助项目在未来几个月内进行顺利的？”

2．不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它。

3．人们开口要求的东西未必是他真正想要的。处理他的要求之前，请务必确定他究竟想要做什么。

4．绝对不要答应别人自己做不到的事情，这样对双方都有益无害。

5．不要为了讨好别人而伤害双方的工作进程，您永远要根据自己的目标，做适当的决策。

6．是您在为项目负责。不要让任何人的建议阻碍项目的进行，包括上级的建议。

7．天下没有真正免费的软件

8．应该开发策略上具有重要性的功能，而不是把媒体的评比项目都做齐全。

9．软件产品的开发，不能只为了有趣、挑战性，或是够有个性够令人眩目。

10．            不要把时间浪费在无法改善产品的工作上，即使这么做在将来会有潜在的利益，也要与现在投入的时间成本做个衡量。

*重点提示：

l        不要让意外出现的问题打乱项目的脚步，如果您要项目顺利进行，您得花点时间思考未来。今天做个小小的动作，可以防范许多意想不到的问题，即使真发生了无法避免的灾难，您也能在风雨中稳稳掌舵。如果您随时问自己：“有什么事情是我今天能做的，而且可以帮助项目在未来几个月内顺利进行？”您就会知道该采取什么行动。

l        在您准备解决一个问题之前，先确定您找到了问题的症结。还得对话框函数库存的例子吧， word小组的抱怨不小心误导了问题的症结，使得函数库小组极力设法优化，却徒劳无功。因此，在您企图解决任何问题之前，请务必确定已经对问题有了彻底的了解。

l        在投入大量时间于任何一件工作之前，请想一想这件工作是否能满足真正的需求。您还记得那怪异的下拉式列表框，其实应该是个级连式菜单的例子吧。当您接获任何一项要求，最好了解一下背后的原因，提出这项要求的人究竟想要什么。这样可以节省许多宝贵的时间。

l        基于非常多的原因，有些主管很难对提出需求的小组说“不”。在比较严重的情况下，主管会“知其不可而为之”，答应对方自己做不到的承诺。如果您发现自己常常不好意思说“不”，请将心比心替对方想一想，万一到时候做不出来，是不是会造成更严重的后果？如果您是需求小组，您对该到货的东西迟迟不见，是不是焦急又恼怒？您必须对其他的小组负责，就像您希望他们也能对您要求的工作负责一样。

l        每当您接到一项请求，要您在产品中加入某一项功能特色，请先想一想这项工作在策略上重不重要，如果不，就不要开发它；至于这个功能特色是否免费、是不是很酷、竞争对手有没有，都不是重点。特别是有些整组的功能，它们看起来很重要，因为它给您一种没有它就不够完整的感觉。您必须牢记，产品的策略性比完整性重要。如果您不敢确定这项功能特色是否有策略上的重要性，只要想一想这项请求的动机。就可明白大半了。

 

第四章走极端的狂热

1．确定您所要求的报告真的值得属下暂停工作，花那么多时间去写。

2．利用项目检查报告来改进软件开发的工作程序。为了使报告发生作用，报告中必须确实描述我们这次解决问题的每一个详细步骤，以及将来应该如何运用这项新发现。

3．请注意定期会议的价值，确定它值得每个人放下手上的工作。

4．召开任何会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的。

5．试着排除不必要的后续工作。

*重点提示：

l        尽量不要让组员写没有用处的报告，即使非写不可，也要尽量减少对开发工作干扰，务必让每一份报告的价值超过它的成本。

l        项目检查报告是很有价值的报告，您应该善用。但是检查报告必须清楚陈述解决问题或提高工作效率的方法，而且其中的建议能够确实被执行，否则用处十分有限。

l        召开会议之前，请确定会议的结果够重要，值得为此打断程序开发的工作，占用组员的时间。特别留意定期召开的例行会议，通常定期的开会最后只不过是因循的习惯而已，并不值得参加。

l        如果您准备召开一个会议，请将时间安排在一个时段的最前面或最后面，尽量减少工作的中断与时间的切割。

l        每次开会之前，务必确定您开这个会的目的是什么，而在开会时一定要达到某种程度的结论，即使是有条件的决策也比完全没有要好。

 

第五章进度狂

1．不要利用进程表来驱使项目的进行，这对小组的士气伤害太大了。

2．让日程表维持适度的紧迫，但又是可以做到的，好让组员振奋、不松懈，专心致力于项目的推进。

3．绝对不要草率定出不可能的期限，导致组员为了赶进度而损害产品的质量。

4．把长期的大项目，分成几个完整而独立的小项目，各小项目必须有一个主题。

5．为了保持创意的活力和团队士气，必须让每一个小项目都有令人兴奋的结果。

*重点提示：

l        如果您定的日程表使组员产生“落后恐惧症”，为了赶上期限而牺牲了产品的质量，那么该检讨的是这个日程表而不是组员；如果您定出的日程表是个无法达到的目标，只是为了从组员身上压榨出更多的工作时间，那只不过是打击团队士气，对产品毫无帮助。一旦组员发现自己身处绝境，那您永远无法让他们表现出最佳状态，等到项目结束（也许更快），他们就会另谋高就，找个是人做的工作。

l        将项目分割成数个小项目，各有阶段性目标的做法，可以让组员更加投入，并且营造出“赢”的气氛，让组员受到项目有进步的鼓舞。理想的小项目期限大约是两个月，这样给组员适当的急迫感，而促使他们积极地工作，特别是当小项目有一个明显又令人振奋的主题时。您应该试着把小项目设计得令人兴奋又期待，使用权小组在完成后有股冲动想说：“哇！看看我们完成的工作！太棒了！”随着每一个小项目的完成，小组会有愈来愈强的信念，相信自己的工作台是非常重要的，对使用者而言是非常有价值的。觉得自己的工作台有价值、有贡献，这是一种很大的成就感，这种感觉最能鼓舞组员凝聚团队的力量，共同创造出最优秀的产品，而且会很快做地出来。

 

第六章学无止境

1．不要让程序设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。

2．训练程序设计师时，先培养他对整个公司所有项目都有价值的技术，然后才培养本项目独有的技术。

3．不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学，为了公司和他个人的前途，您应该把他推荐到别的项目，让他的成长永不间断。

4．确定每位组员、每两个月都有一项技术上进步。

5．一发现某处需要改进，就立即采取更正的行动。

6．不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长。

*重点提示：

l        绝对不要让组员一直做同样的工作，这样是限制了他的学习，使他停滞在原来的领域。一旦程序设计师精通了某一个领域，就让他换别的领域做做看，永远让他们学习新的技术。

l        各种技术的用途范围有所不同，有的技术在一般的项目都用提上，有的技术只有在特定性质的项目才用得上。当您训练您的组员时，必须让他们的技术能在公司发挥最大的用处，最好的办法就是，把应用范围最广的技术放在训练的最前期，应用范围最小的技术放在最后训练。

l        优秀的程序设计师是项目经理最需要的，所以经理们通常舍不得让自己手下功力最强的人到别组去，但是如果这位第一高手在本组内再也没有新东西可学时，经理就应该让他到别的项目去，一方面他个人可以重新开始另一次的成长，一方面让接替他的人学着承担重要的工作，最后公司的平均程序技术水准因而提升，对大家都很有好处。

l        为了确保每位程序设计师的技术都在稳定地进步，一定要让每个人有个努力的目标，最好的方法是把个人的成长和项目每两个月的阶段性目标相结合，这样一年就有至少六次的进步了。假定一位组员在公司待了五年，那么他就学了30种新技术、或是读了30本好书、或是15项技术加15本书，对他的工作能力影响多大啊。

l        最好的成长目标是出于当时的需要。如果您发现有位组员工作缺乏效率，或总是在犯同样的错误，最好抓住机会立即为他立一个目标，并且要求他立刻开始改进。这种当时设立的目标让人印象深刻，又是马上寻求改善，效果通常会非常好。比起年终考评那种模模糊糊的建议，更能引起程序设计师的重视。

 

第七章态度问题

1．要让每一位程序设计师都明白，写出零错误程序是很不容易的，所以应该多花功夫用各种方法做最彻底的测试。

2．纠正程序设计师以为加除错码会花太多时间的观念，应该训练程序设计师第一个反应是考虑加上除错码是否有道理，第二是考虑加除错码是否符合项目的目标与工作的优先级。

3．不要让凡事不能的态度阻碍了创新。

4．不要让程序设计师以为使用者并不在乎软件的质量。

5．不要给使用者次品，宁愿延期交货，务必追求质量完美。

6．程序设计师必须经常以使用者的观点来看自己写的程序，程序设计师必须能体会使用者的感受。

7．在包装盒里的每一件东西，都是产品的一部分。

8．将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作。

9．从您的每件工作中创造最大的资源，不管是利用现有的杠杆，或是创造新的杠杆。

*重点提示：

l        新进的程序设计师必须了解，写出“零错误程序”并不是容易的事，如果他们有这种认知，就不会轻易坚持自己的程序已经完成，没有错虫。有经验的程序设计师知道，写出“零错误程序”很困难，但是并非不可能，那是需要多下点功夫才能做到的，程序设计师应该在把程序送交测试小组之前，彻底用除错工具追踪过程序的执行。由于写“零错误程序”是这么困难，有错虫的程序一旦被置入软件，那就会造成极大的损失，要大量的时间、人力才能大海捞针似地挖出这个错虫，所以程序设计师务必审慎再审慎，用一切的办法侦测和预防错误，即使要自己改变程序风格也无妨。

l        小心那种“太难了”、“太花时间”或是“太麻烦”的反射性反应。当您遇到别人有这种反应，请先问自己他有没有认真思考过这件事的重要性、以及是否符合项目目标，如果您认为他其实未经深思熟虑，只是直觉的反应，那您就应该把您的想法告诉他，请他重新评估，也许就会有公平的答案。

l        人们遇到经验范围之外的事情，多少有恐惧感，就会认为“这完全不可能”而强烈反对。试着消除这种习惯性的反应，设法给组员灌输“只要花时间想想看，大部分的事情都做得到”的观念。您不妨以个问题来对付那种“凡事不能”的态度：“我了解这是做不到的，但是‘如果’做得到，那你会怎么做？”然后您就会发现惊人的转变，您马上就会听到组员七嘴八舌地说应该这样做、那样做，说的是他们刚刚坚持做不到的事情。这个“如果”把他们带离直觉的反应，带到全新的思考模式，这才是他们应该做的。

l        把使用者当作什么都不懂的外行人，是非常不好的观念。每当您发现有人表露出这种心理，一定要立即纠正，提醒他们使用者才是真正受产品好坏影响最深的人，他们和程序设计师一样关心软件的执行速度和质量。

l        教导程序设计师以使用者的角度看产品。程序设计师必须对产品有整体性的认知，包装盒内一切有形无形的东西都是产品的一部分，使用者并不在乎其中一部分好或不好，也不会想知道里面有多少不同的小组各负责几个组件，也不在乎究竟用什么语言写成，他不在乎软件是怎么做出来的，这只对软件公司有意义，他们只知道产品是那家公司出的。程序设计师当然不会每个程序都参与，但是他们必须了解产品是一个整体，任何一部分不符品质标准，都得研究对策，而不是只做自己被分配到的程序。只要大家都关心产品中比较弱的组件，自然那一部分就会被设法改善。

l         杠杆原理是您最有用的观念，找到您工作中杠杆，您可以为小组、项目、公司、甚至软件业创造无可限量的价值。无论如何，尽量利用资源并创造资源，这个原则是绝对错不了的。在您写程序的时候注意到程序代码的共享性，训练组员的时候注意他对公司的价值，即使是像函数命名这种小事，都有杠杆的存在。不管做任何事，都有杠杆的存在。不管做任何事，都要想到“善用资源”，为未来做好准备。

 

第八章沉船的感觉

1．如果进度发生落后，那表示有个地方出错了。您应该找出问题，并加以解决，不要一味要求组员加班，在问题没有解决之前，加班是没有用的。

2．别误信加班等于增加生产能力，长期的加班只会伤害生产能力，对项目没有帮助。

3．周未是属于组员私人的时间，不是公司的。公司不应该以打败竞争对手为理由，要求员工周未加班。

4．强调思考的重要性，而不是长时间工作。

5．训练开发小组懂得在正常工作时间内掌握好工作的效率，不要让他们超时工作，因为超时工作只是浪费时间的假面具。

6．与程序设计师共同研拟出每日活动的时间表，把无法预期的临时公务变成固定时间

处理的事情，并且把程序开发的工作放在最优先的地位，不要让其他次要的事情干扰到

程序。

*重点提示：

l        经常加班就是项目出问题的明显信号，也许是因为主管和观念错误或是目标不够清楚，不论是什么原因，项目经理绝对不能忽视这种现象，要对这个问题正确处理，项目经理必须协助组员在每周40小时的工作时间里，把事情做得更有效率。

l        我经常听到高层主管称赞组员每天为公司工作很长的时间：“您对公司的贡献值得嘉奖，

l        为了组员把办公时间用在正确的地方，并提高部门的工作效率，项目经理不但要为他们排除任何不必要的会议、报告和杂事，还要协助他们好好运用宝贵的上班时间。您应该协助组员安排适当的每日活动表，用一些小技巧，让组员有长段又不受干扰的时间，适合进行开发工作。

l        如果您关心组员的生活，就不要让他们把全部的时间都投入在工作。每天只要确定他们卖力工作了八小时，就可以把他们赶出办公室了，当然这样做也许会有老板看不顺眼，但是如果您像我一样相信均衡、健康的生活是一切创意的原动力，就坚持这份理念吧！

l        每周工作40小时并不是金科玉律，只不过是美国的传统，而软件开发项目大都以此为前提编定日程表。所以如果一个项目需要程序设计师每周工作40小时以上才能赶上进度，就表示有问题，也许是日程表定得太乐观，也许是程序设计师需要再训练。绝对不应该让程序设计师加班来弥补这个漏洞。

 

给领导者的话

主管应该把自己视为团队中一分子，与其他人平等，而不是高高在上。