最近不断有猎头联系我，问我有没有兴趣看看其他的机会，其中包括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页）。
打印 | 张贴于 2007-10-22 23:11:00 | Tag:Software Engineering
留言反馈
Windows Vista 复制，删除，大批文件的速度竟然会比 Windows XP 慢四五十倍 (我曾经在 Vista 下删除过一个 cygwin 目录，里面大约有4万多个小文件，vista 竟然花了一个半小时才删除完，同样的目录在 XP 下删除只要不到 30 秒)，通过windows file sharing 复制一个1.4 GB 的文件，在 XP 下 8 分钟，在 vista 下 30 分钟。我的朋友在两年前 vista beta 1 时就把这个问题报给了M$, 可惜直到现在都没有解决，只内部release了两个 hotfix, 从来不公开发放, 打完hotfix 后速度还是落后 XP 几倍。而且这几个bug 在vista sp1 里依然没有解决。
M$ Zune windows client 更是 QA 的噩梦，即使升级到最新版本还是比猪都慢，而且 bug 满天飞。如果这也代表了这个星球上的最高水平的话，那你说的星球一定不是地球。
[quote]但就整体软件工程水平来说，微软仍然代表了这个星球上的最高水平[/quote]
thx.
http://www.yodao.com/blogender/result2.jsp?flag=m&keyfrom=list.male&url=http://blog.joycode.com/mvm/rss.aspx
曾经在上一家公司开发软件，经理老是叹息：能做和做好差别是相当大的，有时候想想，一群家伙能将头脑中的东西变成现实是很不可思议（这世界变数太多了：和老婆吵架、车被撞了、脑震荡了、幻想了、被本拉登盯上了...），这辈子都花在研究软件开发也总感不够，分享、团队合作、规范等等都是人能够更好的将事情做好的方式。
About google, one word: 谋事在人。
那个兄弟进微软前进微软后技术都不错，所以蛮多兄弟拿他的话为戒。
很喜欢看年轻小朋友们快意恩仇的文字，也特烦别人“夹起尾巴做人”的说教，但是还是为一些小朋友捏一把汗 ---- 年轻时对这么多不熟悉的事情（技术的，生活的，微软的，非微软的，国内的，国外的...）发表如此激昂的评价，会不会十年以后再看到觉得汗 or 寒...哦，可能不要十年，因为在微软一年等于 7 年...笑...
实际上他只是留下那么一句酸溜溜的话，以后也不会再回来看你的回复。
1. 说“不就是一个小QA leader罢了”的那位兄弟
我们看人看事，皆应不唯上，不唯书，只唯实。看人不能只看官职。Joel Spolsky是“a software developer in New York City”， Robert Scoble 在去年离开Microsoft之前是“technical evangelist”，王建硕在离2004年开微软之前是Consultant。但这些人都在IT行业（至少是软件行业）有相当的影响力，可以说是thought leader级别的人物。他们在微软的时候，事实上都不是职位很高的人，基本上都属于一线经理（first line）或者individual contributor。但这不妨碍他们的blog和他们的观点在互联网上影响很多人。
2. 说“井底之蛙而已”的那位兄弟，请问你是否曾经在微软工作过？
如果你曾经是微软的一个全职的SDE、SDET或PM，后来又在其他公司工作过，那很欢迎你把你的感受详细地说出来。我也很想知道其他的“牛比的公司”在软件工程方面和微软的做法有什么共同点、不同点。很多时候A公司的人只知道A公司是怎么做的（比如我），B公司的人只知道B公司是怎么做的，相互缺乏共同的背景和语言，最好是有一个人在A公司和B公司都工作过。如果你是这样的人，希望你能把你独到的看法分享给大家（包括我）。
如果你从未在微软工作过，那你不妨亲身经历一下。在我这只青蛙眼里，这口井足够大。在没有把这口井好好研究透之前，我并不急于跳出这口井。我想我在这篇blog中已经表达了这样的意思了。
另外一方面，我不觉得我是一只纯粹的井底之蛙。我在2002-2004年间花了两年左右的时间去了解国内的软件行业，走过了很多城市，和国内很多做软件的人（有工程师，有主管，有地方官员，也有一些管理层）都有接触。这篇blog里面的那七大类问题就是我自己总结出来的。
关于“微软（中国）的烂人我见得也不少”，你是想以此证明“这个mvm也是烂人”么？苏格兰的羊有黑的有白的。就算你见过一百万只苏格兰的黑羊，也不等于苏格兰的羊全是黑的。坦白说，逻辑上正确是任何讨论（debate）的基本条件。
关于“微软这么多人，你只不过是个微不足道的小角色”，请参见我对“不就是一个小QA leader罢了”的评论
《移山之道》就是想通过一个实际中国小软件公司开发软件的过程，在动态过程中回答这样的问题。
不过，写软件的目的是为了让软件成功地发布，而不是为了证明‘我用了某某方法’，希望《移山之道》的读者也能像MVM 同志一样，潜心做几个软件，这样回过头来看软件方法的书，就更能有体会了。
感谢MVM 的书评，希望他能化更多的篇幅评论《移山之道》的缺点。。。
邹欣
www.yishan.cc
就象有些牌子主板需要砍掉些测试环节降低成本弄个别的牌子跟别人抢市场一样
貌似还有一本黄色的
这句话怎么读也不会理解成这个意思啊……
在小气的神的blog上也看了看《Software Estimation》的书评，有一读的冲动了！
这句话没完全读懂。你暗指是说自己比very highly regarded的更强？？