微软研发致胜策略读书笔记(转)

转载 2005年05月27日 12:40:00

创建人:X公司程序员 yunshichen   这篇是我读《微软研发致胜策略》后整理的笔记。身为一个软件开发部门的主管,你的职责是什么?单单完成项目是不足够的,如果你的目标是这样,那么你会做错很多事。我认为准确的表述应该是: 带领程序员按进度完成项目,并且让他们能通过项目中在技术,工资,团队归属感等方面成长。 本文作者用轻松愉快的笔调讨论了作为一个主管,应该怎样管理项目,并且列出了他在微软的一些做法。或者他可能没意识到,他提出的解决方法,其实都是针对一个问题: 你究竟想要做什么? 小到编程,买菜,与人交流,大到管理,人生,无非都是弄清楚你自己究竟想要做什么。弄清楚之后,通常你就能找到相应的处理方法。 读完之后我没有单纯的记下要点,我把作者的观点归纳之后,重写成如下形式。希望能给喜欢读书的同行一点思考的火花。当然了,最好建议你还是去读读这本书,然后写下你自己的见解。当你,我,他都有了自己的理论,或者中国软件业的春天就不远了。

项目的讨论

精确的项目目标
  作为主管,值得你好好花时间去设定你的项目目标。目标定下来之后,你就会清楚哪些工作该做,那些工作不该做。例如你是基础函数库的主管,如果你确定了“只有所有模块都使用的函数才是要开发的函数”的原则,那么某个模块要求你开发的工作,就不是你的目标了。
  每天花10-15分钟想想目标,并且想些解决的小窍门。例如作者某天是这样想的:
Diego负责该函数的开发,有可能需要一本技术手册。
  于是他马上去买了一本。
  就这样,明确项目目标,提前把影响程序员专心工作的障碍(包括不必要的会议,email,电话等)一一去除。主管才能把项目做好。

开会与报告
  有些会是不得不开的。例如:
  1 当某个人必须把信息传送给很多人时。
  2 信息需要双向或多向交流,人们必须立即反问才能了解信息。
  3 必须亲眼目睹或亲身经历,信息才能传达给接受者,如产品示例。
  4 有些事情须通过讨论才能进行。
  但开会中断许多人的工作。所以在开会之前,你必须动脑筋想想,你开会的目的是什么,有没有更好的方法达到同样目的。
  会议时间应选择工作效率比较低的时段,并且不会打扰程序员顺序连续工作时间的时段为宜,例如早上刚开始上班,下午刚开始上班,快下班时。特别的,如果可以选择的话,在星期一早上或星期五下午开会。这是最没效率的两个时段。
  如果会议确实召开了。一定要达到目的。即使是假设性的,有条件的结论。例如,如果其他小组的工作依赖于Diego的工作成果,那么你可以问Diego:“两个星期能完成你的工作吧?”如果他同意了,那么以此假定作为基础和其他小组讨论工作,例如进度安排等。
  作为主管,避免在会后让与会者递交一份长长的发言报告。这是双重浪费时间。如果你觉得他们的发言值得记,那么你自己记下来。再次强调,写无用的报告浪费开发人员时间。如果你确实要报告,最好单独进行,并且尽量短。

进度
  微软曾有过惨痛的教训,以进度作为项目完成的指导。任何进度落后都是不允许的,bug的不断增加不算严重问题,但只要工作没在排定的时间内完成,就是罪孽深重的。进度取代了项目目标和软件质量,变成了首要任务,每一个人都在疯狂的赶进度。
  以Mac Excel项目为例,每周的进度检讨加上报告,是微软用来控制进度的主要手段。除了这些,开发人员害得每周和测试文件人员共同检讨原因和落后状况。可想而知,只要进度落后,文件小组和测试人员只好暂时没事做,所有目光和谈话,都集中在你的程序进度落后上了。
  每周经理们会用更新的项目进度报告来更新项目总进度表,然后分发给组员。于是你一眼就会看到本周落后了多少,整个项目因此落后了多少。心痛之余,你翻到后页看看还有多少未完成的工作,上周是几百项,现在还是几百项,拼命做事,结果似乎毫无进展。就像一个笑话:如果你每次咬一小口,多久才能啃完一只大象?这张进度表就是一只大象,我们一辈子也无法吃完。
  实在是太过分强调进度了。以至于无论我们做了多少了不起的事情,都没有半点成就感。我们被落后的威胁淹没了,再怎么努力,也看不到成功的彼岸。这不是工作本身的问题,实在是那种绝望无力的感觉所致。
  更荒唐的是,进度表是基于如下原则设定的:
  1 为期两年的项目所有该做的事情都在进度表中,没有任何遗漏。
  2 每人每周实际工作时间40小时。
  3 对于每件工作的时间估计完全准确。
  4 所有程序第一次出来就是完美状态,没有bug,不需修改。
  这真是天方夜谈。
  教训:不要利用进程表来驱使项目前进,这实在太伤害小组士气了。

  在这里,作者提出了他自己的观点:不应该deadline快到了才开始紧张,平时就应该保持适当的紧张状态。多想想如何聪明的工作,不要把时间浪费在没有价值的工作上,不要浪费别人的时间,用积极的态度推动项目。总之,不应该在dealine快到来时,才动脑筋去想解决办法。平时就应该养成良好的工作习惯。
  如果你觉得时间紧迫,那么你开会总结一定不会说:“这个问题,我们留待以后再讨论……”你和组员一定无法容忍事情的拖拉,要不删除这项工作,要不立刻把它完成。
  进度的急迫多数是由于不正确的考虑,不正确的工作方式所导致。如果你定的日程表让组员产生了落后恐惧症,为了赶上期限而牺牲了产品质量,那么该检讨的是这个进度表而不是组员。如果你定出的日程表是个无法完成的目标,那只不过是打击团队士气。一旦组员发觉已深陷绝境,那你就永远无法让他们表现出最佳状态。他们就会另某高就,找个是人做的工作。

项目控制
  在完成对进度的讨论之后,作者提出了他对项目控制的见解:
  1 进度是基于某些因素上软件的大致完成日期。不要迷信它。不要草率定出不可能的期限,导致组员为了赶进度而不顾一切。
  2 把长期的大项目,分成几个完整而独立的小项目,各小项目必须有一个主题。这样既能营造适当的紧迫气氛,也让大家有完成目标的成就感。
  3 制定测试和质量监控规范,这些规范可能涉及产品的速度,健壮性,安全性等,你必须考虑并定出标准。通过质量检测规范的小项目,才算真正完成。警惕,不要把小项目写成hello world之类毫无意义的测试程序。该有的功能绝对要有,该达到的要求绝对要达到。
  4 产品的质量远比期限要重要。发现bug立刻清除。你不会知道一个bug到底有多严重,存在bug的软件产品,会让项目的完成比例被严重高估。更坏的情况下,由于bug的存在,你会不知道项目究竟什么时候能完成。

加班
  如果进度落后,那表示有个地方出错了。在没有找到问题并解决之前,不要粗暴的要求组员加班。这种加班是没有用的。
  如果你以进度落后为由,强迫组员每天工作12小时。那么他们很可能把私人活动也安排到工作时间里,并且在可能轻松的时刻尽可能偷懒。因为他知道每天必定工作12小时,不妨把私人活动如看新闻等也在上班时完成。加班,通常是浪费时间的面具。
  事实上,拼命工作并不是成功的关键,成功的关键是有一个明确的目标,具体而切合实际的计划,以及每天不断的向这个目标迈进。
  (微软不强制员工的上班时间,所以作者如此讨论。但事实上,在中国,加班一样是最没有效率的控制项目的方式。即使你强迫员工每天12小时坐在电脑前,他也很有可能面对屏幕发楞。疲倦的头脑是不可能产生任何创造性活动的。)
  加班的目的只是为了赶上进度而已。为了改善我们的工作,还有许多手段可以达到这个目的:
  1 明确工作目标:程序员是不是被太多的杂务打乱了开发工作?例如不必要的email,不必要的电话、讨论、会议。作为主管,你有责任把这些障碍找到并一一清除,还程序员一个专心开发的环境。
  2 合理安排工作:例如,看email应该在早上,中午,快下班时看,不要在开发过程中让它打乱了你的思路。早上是最有效率的时候,让头脑完成有创意的工作,而其他时间用来编码等等。
  再一次强调,你必须牢记自己的目标:按进度完成项目并让组员成长。只要你开动脑筋,你一定能想到更好的代替加班的方法来达到目的。加班并不是完成这个目标的唯一手段,事实上它是最差的,能不能赶上进度且不说,肯定妨碍了组员的成长。它并不是你的救命稻草,如果你依靠加班来完成你的管理工作,或者你该考虑走人了。  

项目检讨
  对项目进行检讨总结的意义不言而喻。但要避免大而无当的总结。检讨应该能做到:
  1 指出项目的问题所在
  2 根据问题,考虑防范措施和实际的解决办法(虽然有可能只是建议)
  3 总结经验心得。将来如何利用。
  以下是一个例子,给出了两个项目检讨的对比:
  第一个:
  问题:某软件包的Beta版使用者觉得他们的测试报告好像没人注意。因为bug在每一版都出现,这主要是因为我们没有建立一套系统的方法去追踪外部的Beta测试报告。所以我们将来应更小心的追踪外部的Beta测试报告,并加强后续处理。
  第二个:
  由于对β测试报告的疏忽。不仅影响了项目,也影响了关联的其他项目。经理已经同意重新考虑三个追踪Bug的系统,我们将在三者中择一使用,以便追踪项目的测试报告,我们还要把bug和清除bug的行动记录下来。
  这个报告是很有效的。他提出了清楚的解决方案,详细的执行步骤,由谁负责,什么时候该完成,应用在哪几个项目。还建议了bug的查找方式。
  值得一提的是,不要等项目结束了才想什么是值得一写的。应该养成平时经常记录的好习惯,积累是随时的。

管理艺术

评估方式
  年终评估是最没用的评估。对员工的评估应该随时的进行。员工有什么不足应该立即指出,并为他尽量想个改善的方法,让他能立刻成长。不要单纯在年终评估记录员工的不足。

沟通技巧
  有些员工看起来很依赖主管解决问题,其实不过是他们的沟通方式有问题。碰到这种员工,你可以要求他们:
  1 清晰表达他们待解决问题是什么
  2 有什么解决方法,包括他赞同的和否决的
  3 陈述赞同和否决的理由。
  这样下来,通过和员工多次沟通,或者你会发现你的员工并不笨,他们只是不懂得沟通技巧而已。
  一句话,你和员工的一起成长是你的目标之一,所以不要采用生硬粗暴的方式去对待员工。动脑筋想些更好的法子。

人员培养

态度正确
  你必须让你的组员态度正确。
  1 发现bug立刻清除。越晚抓bug越难抓,并且能让程序员总结经验。还有,如果bug太多,那么程序员的功力高下立现。
  2 除非我已经完全测试过了,没有bug了,否则程序不算完工。
  3 以用户的观点来看待软件,尽善尽美。
  4 改正“这不可能”的态度。最好的方法是明确目标,然后找出正确的解决方案。
  5 鼓励提问。他可能不知道答案,但他有权提出问题。
  6 未完成的功能,绝对不要给用户。
  7 善于利用别人的成果。写好的测试过的代码,只要符合自己要求,就应该用。重复就是浪费。
  8 注意提高自己代码的复用性。

提高技术
  如果某个程序员在你的项目已经毫无进步,并且他渴望提高,那么让他到其他项目去吧,让其他接他的班。短期来看你损失了一个得力干将,长期来看,你为公司培养了两个人才。
  
  新兵训练:先让新人学会一些通用性技术,这样他到其他项目组也能用。然后才让他们学会项目专有的技能。训练他们多思考。在设计阶段,他们要想得很缜密,确定这样的设计没有纰漏,写程序时要动脑筋,要懂得怎么思考怎么测试这个程序才确保没有bug;遇到bug时,不要乱猜,要思考如何有系统的搜寻bug藏身之处,要学会判断是否有相关bug没有现身;不但要学习如何对付bug,还要思考如何在一开始写程序时就避免它的发生。同时要了解这一行业新知识不断而至,他必须不断学习提高,才能跟上产业的步伐。

工作价值
  让组员明白,单纯的工作时间是不能衡量员工价值的,程序员对项目的贡献在于:
  1 指出我们在哪里浪费了人力?
  2 有什么地方可以引用别组的程序代码?
  3 有什么自动测试程序的好主意?
  4 想到一个符合用户使用习惯的界面?
  等等诸如此类。简而言之,你必须开动脑筋定下规则,鼓励员工学习新的技术,养成好的工作习惯,做事更有效率,从而加快项目的进程。而不是用单纯工作时间来判断员工价值。

读书笔记-《微软研发:致胜策略》

“卓越的领导者从不同的角度看世界。若公司被大火烧个精光,他非但不为丢饭碗而惊慌,反而利用火焰来烧烤一顿大餐。当每个人都摇头离去,卓越的领导者仍有充分的信心保持乐观,对每件事都从正面角度来思考。就因为凡...
  • kuangsha007
  • kuangsha007
  • 2004年10月09日 08:51
  • 572

微软研发致胜策略读书笔记

项目的讨论   精确的项目目标   作为主管,值得你好好花时间去设定你的项目目标。目标定下来之后,你就会清楚哪些工作该做,那些工作不该做。例如你是基础函数库的主管,如果你确定了“只有所有模块都使用的函...
  • WalkingWithJava
  • WalkingWithJava
  • 2005年05月06日 14:02
  • 1291

微软研发致胜策略

第一章奠定基础 1.千万不要把程序设计师的时间浪费在改善产品以外的工作上。 2.保护程序设计师不受任何阻碍和干扰。 3.永远记得自己真正的目标,然后让团队用最有将效又最愉快的方法把它完成。 4...
  • hanghangaidoudou
  • hanghangaidoudou
  • 2012年11月23日 11:14
  • 1100

微软研发-致胜策略品读心得

国庆节前 跟我的mentor 要了一本研发管理的书籍。10.1-10.3 一边赏景 一边遛娃 闲暇之余快速阅读了 微软研发- 致胜策略 电子书。该书的作者是微软资深开发管理者,他的写作风格 比较喜欢,...
  • hualusiyu
  • hualusiyu
  • 2017年10月09日 21:43
  • 401

微软研发制胜策略读书笔记

1、开发工作进行到比较后期时,会进入一个“视觉冻结”阶段,也就是界面固定不动,这样做的目的是让使用手册等文件能够定稿。 2、电子邮件让我们工作时不被电话打扰,开发人员彼此之间的讨论主要通过电子邮件,...
  • dj0379
  • dj0379
  • 2016年03月30日 16:54
  • 373

[读书笔记]《APP研发录》第二章

APP研发录第二章笔记 抛弃AsyncTask,自定义一套网络底层的封装框架。 设计一套App缓存策略。 设计一套MockService的机制,在没有MobileAPI的时候,也能假装获取到了网络返回...
  • CodeEmperor
  • CodeEmperor
  • 2016年04月05日 18:15
  • 1736

微软亚太研发集团实习

本人有幸参加了2012微软“智在未来”实习生计划,下面就给大家介绍下在微软实习的过程。希望对想了解微软实习的同学,特别是即将过来实习的同学能有所帮助^_^。 文章下面分为: 一. 微软亚太研发集团...
  • evergreeen
  • evergreeen
  • 2012年07月18日 11:03
  • 5557

蒙迪欧致胜如何进入工程模式查看平均油耗

把钥匙退到第一个位置,然后按住OK键(别松手哦)再把钥匙转到第二位置(豪华版换成按启动键),等显示屏出现TEST后松开。然后进入TEST界面,一直按向下键调出油耗就可以注意几个事情  1) 启动时屏幕...
  • java2000_net
  • java2000_net
  • 2012年07月11日 14:54
  • 14261

微软人工智能绘图机器人诞生,输入文字既能生成图片

人工智能的飞速发展,已经给人类的很多工作领域带来了替代的威胁。不过,在大多数人的认识中,诸如文学、艺术、音乐等需要灵感、创意的领域,似乎很难被AI所替代。但这一认识正在被AI机器人所打破。继推出可写诗...
  • za8KFnpo2
  • za8KFnpo2
  • 2018年01月23日 00:00
  • 120

晓之以理,不如动之以情——新书《以大致胜》解读(下篇)

这篇主要针对应用来解释,即特朗普如何利用说服力来取得想要达到的效果,以及给我们普通人的启发。 上篇地址:新书《以大致胜》解读(上篇) 1.特朗普的主角光环 1.1主角...
  • s1314_JHC
  • s1314_JHC
  • 2017年12月17日 11:50
  • 481
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:微软研发致胜策略读书笔记(转)
举报原因:
原因补充:

(最多只允许输入30个字)