微软产品研发之道

微软产品研发的一些心得
服务器君一共花费了210.010 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

    奠定基础

  1. 任何不能改善产品的工作,都是浪费时间或是偏离方向。
  2. 领导者的任务是努力消除程序设计师工作上的一切障碍,让程序设计师全力专注在真正重要的工作 -- 改善产品。
  3. 千万不要把程序设计师的时间浪费在改善产品以外的工作上。
  4. 永远记得自己真正的目标,然后让团队用最有效又最愉快的方法把它完成。
  5. 理清详细的项目目标,可以避免在不必要的工作上浪费时间。
  6. 不要因为制定目标需要花很多时间,或是别人都没有做,就省略了目标的制定。制定明确详尽的目标所花的时间,绝对会让团队得到更大的好处。
  7. 事前决定最合适的优先考虑顺序,以及各考虑点的质量规范,能够指引开发团队的工作。
  8. 策略性的作业方式

  9. BUG 愈晚清除,时间花得愈多。毕竟,您得知道程序是怎么写的,才能判断那里出了 bug ;刚写完的程序记忆犹新,一年前写的程序可能早就忘了。
  10. 在开发的过程就立即除虫,可以让您早些学到经验,然后就不会再犯同样的错误;相反地,如果到了项目后期才发现,您可能已经犯过多次同样的错误而不自知。
  11. 发现 bug 而立即除错是一种缓冲器,提醒那些讲求快速而不够谨慎的程序设计师,以后多加小心。如果您坚持 bug 全都清除了才能开发新的功能,就可以防止所有的程序处于半完成状态,因为 bug 太多而使项目延误乃至无法推出;相反地,如果您允许 bug 的存在,等于是埋下了项目失控的地雷,最后看似完成的项目,其实已经失控。
  12. 若能保持没有任何 bug ,您就能比较准确估出项目的完成时间。不必猜测32项功能和1742个 bug 共要花费多少时间,只要估算32项功能的工作时间就行了。更重要的时,万一到时候有些功能做不完,您可以做多少算多少,因为软件一直保持在无错误状态。
  13. 不要把策略性工作方式当作训练的教条,应该向组员解释这些工作方式的内涵与用意。
  14. 提出精确详尽的问题,可以引导出真正有效的策略性工作方式,帮助项目目标顺利完成。
  15. 策略不是死的定律,要把它当作指导原则来活用。大部分的时候都应该遵循,但也有例外的时候。
  16. 保持进度

  17. 定期暂停手边的工作,然后往前思考,随时做必要的修正,以避免未来的大障碍。
  18. 有什么事情是我今天能做,而且可以帮助项目在未来几个月内顺利进行的?
  19. 不要浪费时间在错误的问题上,一定要先确定真正的问题在哪里,然后才去改正它。
  20. 人们开口要求的东西未必是他真正想要的。处理他的要求之前,请务必确定他究竟想要做什么。
  21. 绝对不要答应别人自己做不到的事情,这样对双方都有益无害。
  22. 不要为了讨好别人而伤害双方的工作进程,您永远要根据自己的目标,做适当的决策。
  23. 是您在为项目负责。不要让任何人的建议阻碍项目的进行,包括上级的建议。
  24. 天下没有真正免费的软件。
  25. 应该开发策略上具有重要性的功能,而不是把媒体的评比项目都做齐全。
  26. 软件产品的开发,不能只为了有趣、挑战性,或是够有个性够令人眩目。
  27. 不要把时间浪费在无法改善产品的工作上,即使这么做在将来会有潜在的利益,也要与现在投入的时间成本做个衡量。
  28. 走向极端的狂热

  29. 确定您所要求的报告真的值得属下暂停工作,花那么多时间去写。
  30. 利用项目检查报告来改进软件开发的工作程序。为了使报告发生作用,报告中必须确实描述我们这次解决问题的每一个详细步骤,以及将来应该如何运用这项新发现。
  31. 请注意定期会议的价值,确定它值得每个人放下手上的工作。
  32. 召开任何会议之前,请确定本次会议的目的是什么,达成这个目的的条件是什么,然后,务必达到开会的目的。
  33. 试着排除不必要的后续工作。
  34. 进度狂

  35. 不要利用进程表来驱使项目的进行,这对小组的士气伤害太大了。
  36. 让日程表维持适度的紧迫,但又是可以做到的,好让组员振奋、不松懈,专心致力于项目的推进。
  37. 绝对不要草率定出不可能的期限,导致组员为了赶进度而损害产品的质量。
  38. 把长期的大项目,分成几个完整而独立的小项目,各小项目必须有一个主题。
  39. 为了保持创意的活力和团队士气,必须让每一个小项目都有令人兴奋的结果。
  40. 产品的质量远比遵守期限重要。
  41. 学无止境

  42. 不要让程序设计师的学习停滞不前,要让程序设计师有机会磨练不同领域的技术,培养十八般武艺样样精通的组员。
  43. 训练新进程序设计师时,先培养他对整个公司所有项目都有价值的技术,然后才培养本项目独有的技术。
  44. 不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学,为了公司和他个人的前途,您应该把他推荐到别的项目,让他的成长永不间断。
  45. 确定每位组员、每两个月都有一项技术上进步。
  46. 一发现某处需要改进,就立即采取更正的行动。
  47. 不要用年终考评来订立学习目标,要利用年终考评来记录个人的成长。
  48. 绝对不要让组员一直做同样的工作,这样是限制了他的学习,使他停滞在原来的领 域。一旦程序设计师精通了某一个领域,就让他换别的领域做做看,永远让他们学习新的技术。
  49. 各种技术的用途范围有所不同,有的技术在一般的项目都用得上,有的技术只有在特定性质的项目才用得上。当您训练您的组员时,必须让他们的技术能在公司发挥最大的用处,最好的办法就是,把应用范围最广的技术放在训练的最前期,应用范围最小的技术放在最后训练。
  50. 优秀的程序设计师是项目经理最需要的,所以经理们通常舍不得让自己手下功力最强的人到别组去,但是如果这位第一高手在本组内再也没有新东西可学时,经理就应该让他到别的项目去,一方面他个人可以重新开始另一次的成长,一方面让接替他的人学着承担重要的工作,最后公司的平均程序技术水准因而提升,对大家都很有好处。
  51. 为了确保每位程序设计师的技术都在稳定地进步,一定要让每个人有个努力的目标,最好的方法是把个人的成长和项目每两个月的阶段性目标相结合,这样一年就有至少六次的进步了。假定一位组员在公司待了五年,那么他就学了30种新技术、或是读了30本好书、或是15项技术加15本书,对他的工作能力影响多大啊。
  52. 最好的成长目标是出于当时的需要。如果您发现有位组员工作缺乏效率,或总是在犯同样的错误,最好抓住机会立即为他立一个目标,并且要求他立刻开始改进。这种当时设立的目标让人印象深刻,又是马上寻求改善,效果通常会非常好。比起年终考评那种模模糊糊的建议,更能引起程序设计师的重视。
  53. 态度问题

  54. 要让每一位程序设计师都明白,写出零错误程序是很不容易的,所以应该多花功夫用各种方法做最彻底的测试。
  55. 纠正程序设计师以为加除错码会花太多时间的观念,应该训练程序设计师第一个反应是考虑加上除错码是否有道理,第二是考虑加除错码是否符合项目的目标与工作的优先级。
  56. 当某人说“某件事不可能做到”时,他往往是错的。
  57. 不要让凡事不能的态度阻碍了创新。
  58. 使用者和程序的撰写者一样关心速度和品质的问题。
  59. 不要让程序设计师以为使用者并不在乎软件的质量。
  60. 不要给使用者次品,宁愿延期交货,务必追求质量完美。
  61. 程序设计师必须经常以使用者的观点来看自己写的程序,程序设计师必须能体会使用者的感受。
  62. 在包装盒里的每一件东西,都是产品的一部分。
  63. 将程序的重用性当作优先考虑的目标之一,否则程序设计师将经常做重复的工作。
  64. 充分利用现有资源或创造新资源,以便从每一项工作中获得更大的价值。程序代码的再利用,就是很好的例子,当然,还有其他的地方可以运用“杠杆原理”。
  65. 如果您创造了一项资源,并且让别人知道,那么总有一天会派上用场。
  66. 从您的每件工作中创造最大的资源,不管是利用现有的杠杆,或是创造新的杠杆。
  67. 小心那种“太难了”、“太花时间”或是“太麻烦”的反射性反应。当您遇到别人有这种反应,请先问自己他有没有认真思考过这件事的重要性、以及是否符合项目目标,如果您认为他其实未经深思熟虑,只是直觉的反应,那您就应该把您的想法告诉他,请他重新评估,也许就会有公平的答案。
  68. 人们遇到经验范围之外的事情,多少有恐惧感,就会认为“这完全不可能”而强烈反对。试着消除这种习惯性的反应,设法给组员灌输“只要花时间想想看,大部分的事情都做得到”的观念。您不妨以这个问题来对付那种“凡事不能”的态度:“我了解这是做不到的,但是‘如果’做得到,那你会怎么做?”然后您就会发现惊人的转变,您马上就会听到组员七嘴八舌地说应该这样做、那样做,说的是他们刚刚坚持做不到的事情。这个“如果”把他们带离直觉的反应,带到全新的思考模式,这才是他们应该做的。
  69. 把使用者当作什么都不懂的外行人,是非常不好的观念。每当您发现有人表露出这种心理,一定要立即纠正,提醒他们使用者才是真正受产品好坏影响最深的人,他们和程序设计师一样关心软件的执行速度和质量。
  70. 杠杆原理是您最有用的观念,找到您工作中的杠杆,您可以为小组、项目、公司、甚至软件业创造无可限量的价值。无论如何,尽量利用资源并创造资源,这个原则是绝对错不了的。在您写程序的时候注意程序代码的共享性、训练组员的时候注意到他对公司的价值,即使是像函数命名这种小事,都有杠杆的存在。不管做任何事,都要想到“善用资源”,为未来做好准备。
  71. 沉船的感觉

  72. 如果进度发生落后,那表示有个地方出错了。您应该找出问题,并加以解决,不要一味要求组员加班,在问题没有解决之前,加班是没有用的。
  73. 别误信加班等于增加生产能力,长期的加班只会伤害生产能力,对项目没有帮助。
  74. 周末是属于组员私人的时间,不是公司的。公司不应该以打败竞争对手为理由,要求员工周末加班。
  75. 强调思考的重要性,而不是长时间工作。
  76. 训练开发小组懂得在正常工作时间内掌握好工作的效率,不要让他们超时工作,因为超时工作只是浪费时间的假面具。
  77. 与程序设计师共同研拟出一份每日活动的时间表,把无法预期的临时公务变成固定时间处理的事情,并且把程序开发的工作放在最优先的地位,不要让其他次要的事情干扰到写程序。
  78. 经常加班就是项目出问题的明显信号,也许是因为主管的观念错误或是目标不够清楚,不论是什么原因,项目经理绝对不能忽视这种现象,要对这个问题正确处理,项目经理必须协助组员在每周40小时的工作时间里,把事情做得更有效率。
  79. 我经常听到高层主管称赞组员每天为公司工作很长的时间:“您对公司的贡献值得嘉奖,做得很好!”这绝对是错误的信息,员工应该是因为工作做得好而受到称赞,而不是因为在办公室待得久,管理者不该把“生产效率”和“工作时间”混为一谈,有的人也许可以用更少的时间,完成两倍的工作呢。
  80. 为了让组员把办公时间用在正确的地方,并提高部门的工作效率,项目经理不但要为他们排除任何不必要的会议、报告和杂事,还要协助他们好好运用宝贵的上班时间。您应该协助组员安排适当的每日活动表,用一些小技巧,让组员有长段又不受干扰的时间,适合进行开发工作。
  81. 如果您关心组员的生活,就不要让他们把全部的时间都投入在工作。每天只要确定他们卖力工作了八小时,就可以把他们赶出办公室了,当然这样做也许会有老板看不顺眼,但是如果您像我一样相信均衡、健康的生活是一切创意的原动力,就坚持这份理念吧!
  82. 每周工作40小时并不是金科玉律,只不过是美国的传统,而软件开发项目大都以此为前提编定日程表。所以如果一个项目需要程序设计师每周工作40小时以上才能赶上进度,就表示有问题,也许是日程表定得太乐观,也许是程序设计师需要再训练。不管怎么说,这个问题一定要认真解决,绝对不应该让程序设计师加班来弥补这个漏洞。

本文地址:http://www.nowamagic.net/librarys/veda/detail/666,欢迎访问原出处。

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/666

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《代码大全(第2版)》 史蒂夫•迈克康奈尔 (Steve McConnell) (作者), 金戈 (译者)

代码大全(第2版)是著名IT畅销书作者、《IEEE Software》杂志前主编、具有20年编程与项目管理经验的Steve McConnell十余年前的经典著作的全新演绎:第2版做了全面的更新,增加了很多与时俱进的内容,包括对新语言、新的开发过程与方法论的讨论等等。这是一本百科全书式的软件构建手册,涵盖了软件构建活动的方方面面,尤其强调提高软件质量的种种实践方法。

更多计算机宝库...