| 查看: 186 | 回复: 1 | |||
| 当前主题已经存档。 | |||
[交流]
《微软研发致胜策略》读书笔记 －的确不错
|
|||
|
微软研发致胜策略读书笔记 创建人：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 想到一个符合用户使用习惯的界面？ 等等诸如此类。简而言之，你必须开动脑筋定下规则，鼓励员工学习新的技术，养成好的工作习惯，做事更有效率，从而加快项目的进程。而不是用单纯工作时间来判断员工价值。 [ Last edited by 幻影无痕 on 2006-11-13 at 08:11 ] |
回复此楼» 猜你喜欢
食品专硕 一志愿双一流 328
已经有4人回复
-
材料调剂
已经有6人回复
-
300分，材料，求调剂，英一数二
已经有5人回复
-
求调剂，一志愿:南京航空航天大学大学 ，080500材料科学与工程学硕，总分289分
已经有5人回复
-
085600材料与化工调剂
已经有13人回复
-
材料与化工考研调剂
已经有7人回复
-
0856材料专硕353求调剂
已经有6人回复
-
07化学280分求调剂
已经有6人回复
-
086003食品工程求调剂
已经有5人回复
-
08工学调剂
已经有16人回复
yuefour
金虫 (正式写手)
- 应助: 0 (幼儿园)
- 贵宾: 9.5
- 金币: 1310.7
- 帖子: 838
- 在线: 17小时
- 虫号: 64621
- 注册: 2005-04-16
- 性别: GG
- 专业: 中医内科
2楼2005-06-20 16:19:59
