1.4. 微软的编程和项目管理

       二十世纪末期，微软遇到一个问题——关于何协调工程同市场和商务方面，（也许可以说这是一个微软和许多其他公司共同面临的问题）。一个名叫Jabe Blumenthal的聪明人意识到应该有一个专门的角色将涉及到这两部分职能，同时扮演领导者和协调者的角色。他应该从制定计划的第一天开始就参与到项目中，直到完成测试的最后一天。应该有一个人不但具备一定的技术与程序员一起工作、并赢得他们的尊重，还应该有足够的兴趣和天分来更加广泛的参与到产品的整个制造过程中。

 

       对于这个角色的工作，他应该从花费每天的时间在执行各种各样的工作中获得乐趣。诸如如何编写规范，检视市场计划，制定项目计划，领导团队，编写战略计划，运行BUG（缺陷）分类、提高团队士气，并且做那些需要但是没有人做的任何事。这个新的角色在微软被称作“程序经理”。团队中没有人直接向他汇报，但是却被授予重大的权利来领导和驱动项目。（在管理理论中，这基本上是矩阵组织的想法：对于个体来说，就汇报有两条线：一条基于职能；另一条基于项目。因此，一个程序员或测试员或许有两个汇报关系：一个主要的，从功能出发；一个次要的，但是很强，从她所在的项目出发）。

 

       Jabe在一个叫做Multiplan的产品（后来成为Microsoft Excel）上扮演这一角色。工程和开发过程随着与商务团队协调质量的提高而提高，并且微软的整个门厅都充满了喜悦。在许多会议之后公司里的许多团队都逐渐采用了这一角色。不论你对最终的产品说什么，好还是坏，但是想法是有意义的。通过定义一个完整线的管理者，他不是一个办事员或者仆人，而是一个领导者和驱动者，微软开发团队如何工作的动力学永远改变了。这个编程经理是我在微软的大部分职业生涯所从事的角色，并且我在IE、MSN、和Windows的产品团队中工作，最终我甚至管理着一个程序经理的团队。

 

       时至今日，我不知道许多公司已经在重新定义和定型一个项目经理的专业形式走了有多远。在我与其他网络和软件开发公司的很多次交互中，碰到类似角色的机会是很少的（不论他们是工程师类型或者商务类型，或者是更为罕见的设计者类型）。许多公司使用团队结构来组织工作，但是很少有公司专门定义横跨工程和商务级别之上的角色。今天，在微软有超过5,000名程序经理（从超过50,000的总雇员中），尽管这一思想已经被削弱（并且在某些情况下被滥用），但是他的核心精神仍然可以从公司的许多团队和组织中被发现。

 

       但是不管我的名片上说什么，或者微软教导你选择去相信或者忽略，我作为一个程序经理每天的功能就是项目管理。在最简单的团队，这意味着我对尽最大可能促使项目以及项目中的每一个成员成功负责。本书的所有章节都反映了达到这一目标所涉及的核心任务，从早期计划（第三章和第四章）到编写说明书（第七章），到决策（第八章），到实施管理和发布（第14章和第15章）。

 

       下面将要陈述的这些技巧中，某些态度和个性特征开始起作用。如果不了解他们，任何领导或者管理项目的人都将处于一种严重的不利地位。