Microsoft Project is not that flexible as many people imagined. It may look great in general. But it turned out to be a huge overhead for a project manager if the project manager wants to use it to tracking *everything*.
I was using Microsoft Project for FDC Credit Card Migration, (code name: Broadway). In the beginning (Oct.2006), I made the project file pretty complete: tasks, dependencies (SF, FS, FF, SS), checkpoints, resource assignment, resource usage percentage, etc. At that moment I was so carefully assigning resource (about 10 engineers) and checked the resource graph, resource usage and gantt chart back and forth to make sure everyone looks flat and no one would be overloaded too much. The .mpp and the schedule looked perfect.
Later, along the course of 2 months development and stabilization cycle, I gave up on it. It was too costly to make sure the .mpp reflect the latest status. Resource assignment change, resource availability change, unforeseen tasks popped up, planned task got cut/shrunk, some tasks got blocked or delayed, etc.
A true believer of Microsoft Project may argue that I was not patient enough, not skillful in using Microsoft Project enough, I was not born to be PM, etc.. May be true.
最近不断有猎头联系我，问我有没有兴趣看看其他的机会，其中包括AutoDesk，Morgan Stanley（软件研发部门），等等。职位都是QA Lead/Manager一类的。不是没有考虑过去微软外面看看。自从2004年秋天离开上海去北京的工程院开始正式作SDE/T（以及现在的测试主管）至今，已经三年了。这三年里面，一直是埋头做公司里面的产品，埋头做自己的事情，埋头学习，从我所在组积累的方法和经验里学习，从接触到的其他组学习。这三年里，再也没有去关心过微软以外的其他地方是怎么做软件的。
2004年秋天之前，我在工作中一直接触到国内各种各样的软件公司：2002年冬天的软件开发管理大会，2003年和全球技术中心的同事在各个软件园讲软件项目管理和软件测试，以及自己的编写培训材料，2004年上半年和微软中国的同事一起配合支持北方区的ISV（独立软件供应商）合作伙伴。那段时间里面，一直感受到微软内和微软外之间的碰撞。当时我总结了在各种对外培训、投标、会议等中收到听到的问题，应该说是当时国内做软件的人的普遍问题：
- 市场前景与产品功能
- 如何进行市场预测和用户需求调查
- 如何平衡市场前景和产品功能
- 如何得出产品的Feature List
- 开发流程和团队
- 如何在资源不足的中小企业中实施开发流程？如何裁剪？做项目时间紧，不能跟着整套流程做，有什么办法可以解决？微软的经验有什么精简的实现方法？
- 对用户订制的软件应用系统的开发管理。
- 怎么解决人员流动带来的问题，怎么在架构、设计中加入人员流动风险控制？如何保证极少数核心技术人员的流失或意外事件不给公司造成严重的损失？关键技术人员以离职要求涨工资怎么办？国营软件企业内无法突破工资与奖励的制度瓶颈怎么办？
- 如何形成企业内知识共享环境？如何积累历次项目的经验？微软的“师徒关系”在团队管理中的应用。
- 十几年以来，微软的开发流程是怎么一步步进化的？微软组织结构是如何一步步从小到大进化的？微软在软件开发管理方面从失败中获得的经验？
- 有哪些典型的错误开发方式，并提出可行的解决方案及办法
- 微软开发流程与CMM的区别？
- 怎么做变更管理？开发团队管理组织中的决策模型和流程？一个项目被取消的原因和评判标准？
- 开发
- 开发团队如何划分任务？如何预估和控制进度？
- 开发团队的管理，如何科学的评估开发人员的级别、绩效？统计哪些指标？
- 是否一定要Daily Build？
- 代码库的管理，如何、何时上锁，权限如何控制？
- 开发后期发现很多或者还有很多Bug怎么办？
- 可扩展性应用程序的设计方法，思路。
- 测试
- 测试应从哪些方面考虑？如何选择测试方法与工具（自动化测试/压力测试/性能测试等）？如何进行具体的测试，比如CPU性能？性能测试？有没有测试的实例？
- Test Lead怎么考核？Tester的考核与量化管理，数据如何采集？如何培养测试经理？测试经理的培训?
- 如何提高Test Team的地位？
- QA部门何时、何种形式、如何参与到整个项目中？
- 希望提供Bug管理工具和测试工具。
- 文档
- 微软如何做需求管理？微软做不做、怎么做用户需求文档？软件项目（而非产品）开发初期怎么做需求文档？
- 整个项目一共有哪些文档？如何管理文档？文档何时、何种原因可以修改？文档修改后怎么通知所有人？
- “需求说明”、“概要设计”、“详细设计”与“Feature List”、“Function Spec”、“Implementation Spec”的区别？其中要定义哪些内容？Function Spec和Implementation Spec要详细到什么程度？希望结合实例讲解文档。
- PM
- PM做不做产品设计？PM是否写代码？PM是否能同时参加多个项目，如果是，有什么成功经验？
- PM是否、如何担当产品市场分析、决定产品的技术实现、决定Developer使用的工具和技术路线？
- 产品达不到客户需求怎么办？PM夹在客户和Developer之间怎么处理两方面的要求？
- 如何培养一个PM？如何考核PM的工作业绩？
- 其他
- 希望了解实际的开发管理案例，以及与其他公司的案例比较；详细的行动指南、Check List等工具。
- 想获得软件企业的管理软件和工具软件。
- 希望获得面向不同发展阶段、不同规模大小的企业的更有针对性的培训。
我是带着这些问题去北京的工程院的。当时我给我的经理的邮件是这么写的：“过去一年多我做了很多开发流程、测试、配置管理等的培训，我很热爱培训工作，能够给中国的软件业者解决困惑他们很久的问题让我觉得非常有意义、有价值、有成就感。培训过程中感觉training skill已经不再是做好培训的瓶颈，而是觉得知识不够用。例如，培训中有一些学员很关心的问题（也是很关键的问题）我自己也找不到很好的答案，例如怎么做单元测试、自动化测试、怎么写好Implementation Spec等。我很想能够再多一些实际的锻炼，在开发、项目中寻找这些问题的答案”。
当时我也把这些问题转发给了邹欣。我不敢说这个问题列表对邹欣写《移山之道》有很大帮助，但我看到《移山之道》已经回答了这里面的很多问题。
我不知道今天的中国软件行业，带头的公司里，是不是已经都建立了必要的基础架构，例如：缺陷管理，代码库，文档库，测试自动化，等等。2003年，我接触到的还有很多公司在用Word/Excel填写“缺陷单”，还有很多公司没有做daily build，还有很多做测试的人还停留在把黑盒白盒挂在嘴上的阶段。如果有机会的话，我很想看看现在国内软件企业的项目管理水平是什么样子的。是不是还有很多人在争论到底是CMM好还是RUP好？
我也很想看看其他的跨国公司是怎么做软件的，比如IBM、GOOGLE、SAP、Adobe、etc。我很想知道EA等是怎么测试他们的游戏的：也用大量的自动化么？怎么自动化？怎么自动化的测试“帝国时代”或Call of Duty 3？Adobe是怎么测试Photoshop的？还有Google呢？
今年八月份的时候看到这么一封内部邮件：
I worked with a Test Architect here at MS a few years ago who is very highly regarded in the software testing industry … very much top of his game. He left MS about 2.5 years ago for Google to help them create a testing discipline and launch quality assurance practices. He just got in touch with me this morning and has left Google (Looking for another job in the area, but not necessarily MS.) I asked him why he left Google, and he said: “The short version of the Google story is that they don't have the people, the background, or the infrastructure for advanced testing, so my work didn't fare well there.”
既然一个如此very highly regarded的测试架构师都对Google的测试摇头了，我也不必去淌这趟浑水了。最合适我的，还是继续呆在微软做我的测试：既然当时我选择做测试的原因是我想要回答我自己心中关于测试的那些问题，既然微软这些年所积累下来的测试方法、经验、教训和内部工具是如此的丰富，我又有什么理由要自己到一个不成熟的环境中去重新探索呢？
正如那个Test Architect所评论的，我也相信，虽然Google已经是一个商业上的成功，但就整体软件工程水平来说，微软仍然代表了这个星球上的最高水平，虽然微软自己的方法论和实践不如学院派的理论那么高妙，虽然微软操作系统的名声一直被苹果和Linux压一头，虽然大家都喜欢说微软要用三个版本才能完善一个产品，虽然大家都嘲笑Office里80%的用户只用其20%的功能，虽然微软没有写过航天飞机的控制系统，虽然微软的数据库仍然不能取代IBM的Mainframe在银行里的位置，虽然微软的软件总是延期发布。
微软在软件工程上的经验不是一本书能讲的完的，也不是几本书能讲得完的。《移山之道》是一个缩影，是一个很好的入门。看《移山之道》的同时，还可以再看《软件开发的科学与艺术》、《软件开发项目管理》，以及《微软项目：求生法则》（一套三本，红绿蓝）。此外，Steve McConnell的所有著作都值得看。虽然Steve McConnell并不完全是一个微软的人，但微软的实践与他的书里的阐述非常有内在的一致性。举例来说，我自己最近一年以来就从他的《Software Estimation》中受益极多极多。
但是，光看这些书是绝对不够的。这些都只是paper knowledge，即便这些书本身来自于作者们多年的摸爬滚打。实践，只有实践才通向领悟。实践，反思，交流，尝试，再实践，然后才能真正达到know-how，否则，只会流于“形似而神不似”（《移山之道》，第319页）。
我们组的code base已经有五六年了，虽然比不上Windows或Office，但也有年头了。经年累月的加功能，一拨拨人走，一拨拨人来。我们平时总是戏称自己是在一个垃圾堆上建一个更大的垃圾堆，而且还要保证这个垃圾堆不会倒掉。像我们做online service的，老的代码是无论如何丢不掉的。一旦第一个版本进了production以后，以后只能incremental的改动。如果要重起炉灶，光是那些数据就让人受不了，都是轮TB来的，单单做一遍replication都不知道要做上几天，如果数据库的schema都改了，再好的dev也不敢保证他的migration code能处理所有的老数据、脏数据，再好的test也不敢保证他的test能把所有的老数据脏数据给cover了。所以，越到后来，越没人敢动数据库。从另一个角度深深的体会到，v1的产品不是那么可以随心所欲做的。v1时候的疏忽或者幼稚，将来是要付出很大代价的。
看以前人的code是一种特别有趣的感觉，好像是在和以前的一个dev在对话，跨越时空的，有点像下围棋的人打古谱，那是一种跨越千年的心灵和心智的交流，我跨得少了点，只跨了五年而已。上半年的时候看了一块多线程的代码，是一个后台console application的，把Mutex、AutoResetEvent、ManualResetEvent、WaitHandle运用的非常华丽。看了那块code以后发现自己对多线程的理解又上了一个台阶。最近在看一段五年前的C++的code，注释相对少一些，不过因为代码写得比较straightforward，所以看起来不吃力。那些注释大部分都是解释code的，但中间有一个地方有这么一行注释：
// do I need to close before Open?
看的我大笑，看来真的是没有全能的developer，每个dev都有自己精通的东西，都有自己不懂的东西。很少有dev能够通吃managed code、unmanaged code、network、win32和SQL database的。很好的C#的程序员有可能设计出来的SQL database的性能是很差的。巧的是，我看得这两块代码的两个作者都跑去Google了。
一个online service的系统，做到五年，做v1的dev和test基本上就剩不了几个了。我们组也不例外。现在有很多很老的feature，好好的已经跑了四五年了没人动过，突然需要re-write，就很吃力。文档是肯定找不到的了，就算能找到，也是不up to date的。最让人挠头的是test automation都没有了。当初的很多test都是manual的，等到SDE/T慢慢多起来可以有人有时间做test automation了，那些最老的feature就已经稳定了，所以也就没人去automate那些manual test cases了。现在要re-write，没有test automation做最后一道防线，不免让人非常心里发毛。但也不得不做，只能硬着头皮上，尽量think through一点，实在不行，只能在production里面打hotfix了。希望不要有太多hotfix。//cross fingers
说到文档，大家都在喊文档的重要性，说developer要写implementation spec。其实，坦白说，in practice，文档是一种很昂贵的手段，单写一份spec还好，但要保证这份spec一直和code保持一致，那就是件代价很高昂的事情，很得不偿失的。从我们组现在的开发实践的体会来看，最好的documentation的方式是：一，把代码写得容易读一些，多写注释；二，把test case维护好，并且尽量做到automated。以前曾经看到过这么一种说法：it’s the test case that finally shapes the product。非常有道理的。从这点来说，我很同意scrum/xp里面所说的less document is better。
微软的SDE/T（即Software Development Engineer in Test）大致相当于其他很多软件公司里的QA（Quality Assurance），但又有所不同。用比较理论化的语汇来说，SDE/T在微软的工作是负责自动化测试和白盒测试。SDE/T通常需要编写测试计划、测试用例、测试工具和测试代码，需要做debug并尽量在源代码中找到bug发生的位置。SDE/T可以说是测试团队里的dev：从工作职责来说，SDE/T是tester；从日常工作内容和所需要的技能来说，SDE/T是developer。
对SDE/T这么一个特殊的工作存在很多的误解。一个叫David Larson的SDE/T Lead在我们公司内部Blog上写了一篇题为“SDET's wanting to move to SDE”的blog，纠正了一些常见的关于SDE/T的似是而非的认识：
As we continue to emphasize CS skills and our sdets become better developers, the issue of people wanting to move from and SDET to an SDE role will become more and more common.
People considering moving to dev often have a mixture of fact and misconceptions. I try to address the following common points of view:
"I want to move to dev because...
1. "I love to code." Generally SDE's do less coding than SDET's. Many people want to move to dev because they love doing development and want to do more of it. The reality is that there are often more design and process over-head in a dev organization than in test. It's not uncommon for a dev organization to spend several months in design meetings without writing a single line of code. I like to present the case of a guy in my last group that was in test, changed to a dev, worked there for two years and then moved back to test so that he could do more coding. I encourage them to talk with their lead about the type of work they love to do so that they can be given more of that type of work if possible.
2. "They get paid more." This may have been a hard truth before Comp 2000 but not so much today. It's often the case the sdet's are hired at a lower level or with lower expectations. We then work on training them and bring them up to the standards that already exist in many dev organizations. For someone with rock-solid development skills there are huge opportunities to mentor others, lead by example, and demonstrate skills that are in high demand in test. . I tell people that in test they can be super-star (with the corresponding compensation).
3. "I want the satisfaction of shipping something." This is a hard one because it often means they have not had the proper guidance from their peers and/or lead. Many IC's in test are not used to thinking of what they do as a "product". They think what they write is throw-away code. Their working environment does little to change this point of view. This results in tools that can't be used by any other group, tests that lack componentization, lack of documentation, and ignorance of good development practices. When a test organization has the institutionalized view that they produce internal products, then IC's starting thinking of shipping versions of a tool, shipping updates to common libraries they own, shipping test suites to be run by an SE team. The sdet gets to ship far more, far more often than dev. I encourage them to think of their work in this light and to spread the word to their peers.
4. "They are more respected than testers." First off I tell then that they are not just testers. They are developers that work in a test organization. That's what it means by SDET. I then talk to them about ways they can work with PM, DEV, and the rest of their test team to insure that everyone knows what they have to offer in terms of development skills. I give examples of teams I've worked on where the people in dev would often go to an sdet for advice. They did this because the sdet had proven and demonstrated their competence, skill, and professional expertise in CS knowledge and skill.
5. "An SDET is a stepping stone to dev." Sometimes this is the same as the respect issue. Sometimes the person thinks that they weren't "good enough" to be a dev and to move to dev is a mark of success for them. This point of view is usually motivated by something else that's covered in the previous points. Ask more questions, specifically try to find out why they had the goal of being dev, then address those points individually.
However, I want to stress that, for the good of Microsoft, we have happy employees. Regardless of the career direction a person wants to go in, if it's good for the company then we should support it and give as well-round advice as possible.
做一个SDE/T的确是很幸福的事情：可以写更多的代码，写起代码来自由，只要能保证feature/code coverage，怎么写都可以，界面可以ugly一点，功能自己决定，想加什么就加什么，还可以把自己的名字放在About对话框里让用的人都知道是我写的。而dev就不行：不能署名，加了新feature要改code，feature被cut掉了code还要再改，fix bug的时间多于写代码的时间，大部分的日子里都要面对着长长的active bug列表。难怪我身边很多SDE/T都不想转去做SDE。
Jim McCarthy（曾经是Visual C++组的Product Unit Manager，《Dynamics of Software Development》的作者）在1994年的一段录像中说过这么一句话：“If there is one thing for which Microsoft should be remembered in software engineering, it's the daily build process”。
Cusumano在《Microsoft Secrets》中提到，最晚在1989年，微软就已经在使用daily build流程了。除了微软，当时也已经在使用或者部分使用daily/weekly/biweekly/monthly build流程的公司还有DEC、IBM、Lotus、Borland等。
根据Garth Wolfendale（现任微软咨询服务的高级顾问及企业架构师）回忆，70年代他在DEC工作时，daily build流程已经在David Cutler领导的VMS项目组里面初露端倪了（"The base-level /frequent/regular/daily build process evolution took root during development of VMS, with Dave Cutler heading the project"）。当David Cutler在八十年代跳槽到微软时，daily build流程也被引入了Windows的开发管理中。
Mark Lucovsky，微软曾经的Distinguished Engineer和Windows架构师，曾经设计了HailStorm（即.NET My Services）但最终失败，在微软工作了十六年以后，去年此时跳槽去了Google。
刚才看了此君在今年二月，即加盟Google三个月以后写的一篇Blog: "Shipping Software"。概括起来说，Mark Lucovsky对Google、Amazon等互联网公司的软件发布方式大加赞扬，他说“They have embraced the network, deeply understand the concept of 'software as a service', and know how to deliver incredible value to their customers efficiently and quickly”。他举例说，当Amazon的工程师修复了网上书店中的一个Bug以后，经过一天的测试，晚上就可以发布到服务器上，第二天顾客就可以用到更新过的代码了。相比之下，MarkL认为微软的软件发布方式太慢、太落后了——“In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM”。
Mark Lucovsky恐怕是太热爱他的新公司了，或者是因为HailStorm最终未能发布而耿耿于怀，在他的这篇题为"Shipping Software"的文章里，他对微软有强烈的反噬情绪。他显然眼里只有Google和互联网。但他不应该一味追捧Release To Web而忘记了软件世界中其他的领域——还有很多“传统”的软件公司（例如Oracle、Adobe、AutoDesk、Apple、IBM）仍然在用和微软类似的软件发布流程：光盘、不定期的补丁在网上供下载、每隔几个月或几年发布一个major release。
并不是所有的软件都适合“Software as Service”的，有些软件可以是Hosted，比如一些LOB系统（Salesforce.com）以及与沟通协作相关的软件等；而有些软件必须是local的，例如Office、Photoshop、Final Cut、DB2、Quake III等——如果强行把他们一一都挪到浏览器里面，浏览器就又会变得像现在的操作系统一样庞大无比。
至于MarkL所提到的"in large corporations, they won't see the software for a year or more post RTM"，这简直太正常了。说到底，Google的所有软件和服务，都不是Business Critical的。
