大梦想家

5年开发工程师,2年实施经理,X年售前顾问,......
数据加载中……
微软团队:成功秘诀(4)

法则二十七:

   Be like the doctors    用医生的方法

    当病人已经药石罔效时,医生通常会对病情有所保留,避免病人太过悲观或恐惧,并且尽量鼓励病人保持希望,最好能让病人有个期望完成的目标。

    医生绝对不会斩钉截铁地断言什么医疗行为一定会有什么样的结果,反而是以
一种自在且充满信心的口吻说:“试试看吧,一切都还没有确定呢。

    另外一件应该向医生学习的事情是,即使是再小再简单的医疗行为,都带着几分风险,所以医生会说:“当然,任何情况都是有可能的,治愈率再高我都不能跟你说百分之百没问题。

法则二十八:

    Remember the triangle:features, resources, times    软件开发金三角:特色、资源和时间

    作为一位软件开发的领导人,你得集中注意力在三件事情:资源(人和钱)、特色(产品与其品质)和时间。这三件事是软件开发的核心,其他的都是外围。

    资源、特色和时间是三角形的三个边,任何一边的变化,都会影响到另外一边或两边。所以如果时间落后了,去看你的三角形,看看对特色和资源的影响;当有人谈到可以增加什么功能特色时,你得立刻谈起时间和资源,以显得你思虑周
详反应敏捷。所以,管理者的第一要务是把这个三角形放在心里,随时利用这个模式来思考问题,你会发现答案都在这个三角形内。

法则二十九:

    Don't know what you don't know    不懂别装懂

法则三十:

    Don't go dark    建立适当的检查点

法则三十一:

    Beware of a guy in a room    留心没有检查点的组员

法则三十二:

    If you build it, it will ship    软件要经常建构,就能顺利推出

法则三十三:

   Get a known state and stay there    掌握实际情况

法则三十四:

    Use ZD milestones    零缺点里程碑

    零缺点不代表软件中没有错虫,也不表示没有遗漏的功能,而是指团队的成品达到了事先规划的品质水准,也经过测试验证,就是零缺点里程碑。

法则三十五:

   Nobody reaches the ZD milestone until everybody does    所有组员一起到达零缺点里程碑

法则三十六:

    Every milestone deserves a no-blame postmortem    完成每个里程碑后,心平气和地检讨

法则三十七:

    Stick to both the letter and the spirit of the milestones    把握里程碑的实质意义与精神

法则三十八:

    Get a handle on "normal"    培养正常的团队运作

法则三十九:

    A handful of milestones is a handful    里程碑不宜太多,才好掌握

法则四十:

    Every little milestone has a meaning (story) all its own    每一个里程碑应有专属的宗旨

法则四十一:

    Look for the natural milestones    寻找自然出现的里程碑

以下是六种自然出现的里程碑:
1. 产品设计趋于稳定。
2. 中间产品被明确定义。
3. 团队真正了解要花多少时间和努力才能完成目标(通常这会发生很多次,而且多半是进度落后的时候)。
4. 产品设计被删减,或是资源增加,或是进度延误,
或是三者同时发生。
5. 开发活动停止。
6. 产品进入除错或稳定阶段。

法则四十二:

    When you slip, don't fall    如果滑了一跤,别就此倒地不起

  1.     进度落后与道德无关,请切记!
  2.     不要隐瞒事实。
  3.     化阻力为助力,利用进度落后来激发效率。

    进度落后不是问题,被进度落后吓倒才是问题。进度落后并不代表产品的难度太高而无法开发。但是如果进度已经落后却未被察觉,那表示组员们不思考、不观察、不讨论,此时组织可说是濒临瓦解了。

    善用你的迟延,这是最能看出你领导能力的时候,此时也是组员最脆弱也最需要你的时候,在这个时候组员最能把你的话听进去,此时组员的学习能力最强。如果你在办公室内激动得大喊大叫,指天骂地,那就错失了赢得组员的心的大好机会。你必须说:“O K,进度落后了,让我们来看看问题出在那里?⋯⋯今天下午五点在会议室,我们要检讨每一个细节,问题一定要设法解决!”当组员了解到你不是企图卸责或算帐,而是真诚地想解决问题,就会乐意把一切开诚布公地摊开来谈,大家一起研究问题,从各种角度去设法克服问题。“进度落后”反而变成大家宝贵的成长经验。

法则四十三:

    Don't trade a bad date for an equally bad date    不要因为进度落后而更改最后期限

    进度落后的程度是与计划的不确定性成正比。

法则四十四:

    After a slip, hit the next milestone, no matter what延误了这个里程碑,就一定要如期到达下一个里程碑

    我们必须明白,每一次的延误,就是你和团队信心的一次受挫,所以,延误这个里程碑时,最好的补救办法就是无论如何绝不延误下一个里程碑。团队必须挽回对自己的信心和对理想的承诺;因此,下一个任务必须准时完成的意义更重大,团队需要重建信心。

法则四十五:

   A good slip is a net positive   把延误当作宝贵的学习机会

法则四十六:

    See the forest    见树亦见林

    如果本项目有六个模块,各有9 0 %的部分已经完成,那么你已经完成了5 4 %。每个模块完成了九成,听起来是个挺不错的成绩,但不能当成整个项目完成了百分之九十,它们之间不是相加的关系。你必须“见树亦见林”。如果任何一个模块完成比率是零,那么整个项目的完成率也是零。

法则四十七:

    The world changes, so should you    世界在变,所以你也得跟着改变

    虽然你想做些改变,你未必有勇气实行。

    伟大的软件必定只有一个中心思想,至于品质能够实现到什么程度,依赖领导者能否带领团队融合无数个小而重要的改变。如果你能在混乱中辨识出对项目最有意义的改变,并且引导团队去适应它,将它融入团队的精神中,将来就会在产品中表现出这项改变,呈现在顾客眼前。

法则四十八:

    Violate at least one sacred cow    关怀多于要求

法则四十九:

   Beta is not the time to change    Beta测试版不是修改功能的时候

法则五十:

    The Beta is for spin development    Beta测试是暖身活动

法则五十一:

    Triage ruthlessly    急救术

法则五十二:

   Don't shake the Jell-0    小心保持软件的稳定

法则五十三:

    Compete with the superior story    伟大的软件应该有一个伟大的故事

法则五十四:

   Create a winning image    建立赢家形象



客户虐我千百遍,我待客户如初恋!

posted on 2008-02-29 18:00 阿南 阅读(1257) 评论(1)  编辑  收藏 所属分类: 个人原创读书笔记

评论

# re: 微软团队:成功秘诀(4) 2008-03-02 14:48 xifu

深有体会
  回复  更多评论    

只有注册用户登录后才能发表评论。


网站导航: