您的位置：首页 > 其它

微软策略

2008-04-04 16:28 162 查看

[align=center]微软策略[/align]

首先还是先看一下书评。

下面是来自china-pub的书评：

作者详细描述了他在美国领导项目的各种实际的策略方法，教您如何开发高质量的软件，而且绝不延误。本书是为每一位从事研发工作的朋友而写，相信您在读过本书之后，一定急于推荐给您的主管、同事和您的朋友。

卓越的领导者从不同的角度看世界。若是公司被大火烧得精光，他非但不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面角度来思考。就因为凡事都看光明面，卓越的领导者并不把失败当失败，反将其当作学习克服障碍的经验。正因如此，卓越的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成功，他只把这次经验当成获得信息的方式之一。这种领导人不一定要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是能将理想实现的卓越领导者。

每当有人完成了一项新的功能或特色，就发个e -mail 给大家。

例如：

“我已完成Faxmangler 的搜寻与取代功能。Frank”
主管应该看一下结果，然后回一个：
“我检查过F a x m a n g l e r的搜寻与取代，不太顺畅，请再修改。Hubie”
或是：
“很好，继续加油！Hubie”
想想看，如果大家经常收送这类正面的e - m a i l，一定会觉得充满干劲，这和可恨的进度报告多么不同！程序设计师会很乐意看见这类的好消息，当自己送出完成工作的信息时，也会很有成就感；没有人会觉得这是很讨厌的报告。

每当进度快要落后了，就到我的办公室私下讨论原因，我们一起开动脑筋寻求解决之道。

例如：

当某位程序设计师觉得自己可能要落后了，我会和他谈，研究将来如何避免这种事情。是我们在制定进程时疏漏了某一个重要环节吗？或是时间表定得太乐观了？是不是有个错虫( b u g )在作祟，害得程序很难写或无法测试？不论问题是什么，我们一定想办法解决掉，并且预防它将来再发生。

尽可能减少项目中小组彼此间的依赖。

目标越是明确，达成目标的过程就会越有效率。

建立最适当的程序设计优先考虑顺序，并且让所有的程序设计师确实遵守。

排出一个优先级表：

体积大小(size)
速度(speed)
坚固性(robustness)
安全性(safety)
可测试性(testability)
容易维护(maintainability)
简洁(simplicity)
再用性(reusability)
可移植性(portability)

一旦您掌握了这个概念，把它应用在项目上，您可以大声说自己确实是在聪明地工作，而不是辛苦地工。

一发现Bug就立即清除掉，别拖延。

作者给出的提示：

错虫愈晚清除，时间花得愈多。

在开发的过程就立即除虫，可以让您早些学到经验，然后就不会再犯同样的错误；相反地，如果到了项目后期才发现，您可能已经犯过多次同样的错误而不自知。

发现错虫而立即除错是一种缓冲器，提醒那些讲求快速而不够谨慎的程序设计师，以后多加小心。

若能保持没有任何错虫，您就能比较准确估出项目的完成时间。

要求错虫随时发现随时改，等于是在开发过程中引进一个小小的质量管理机制，多方的防微杜渐，保护产品的正确性。

学习前人的经验；

好方法要让大家分享；

项目只要有偏差，就需要调整，绝对不可以放任自流！

定期暂停手边的工作，然后往前思考，随时做必要的修正，以避免未来的大障碍。

有什么事情是我今天能做，而且可以帮助项目在未来几个月内顺利进行的？

用看程序的方式找错，是既懒惰又无效率的方法；

随时睁大雪亮的眼睛，看看是不是有个悬而未决的问题，一定要有个人(或是由主管自己)来负责研究到底哪里出错，也许这种研究既花时间又无聊，但总比灾难发生之后再来花好几个星期收拾残局要好得多。

问了错的问题，而导致错的答案，训练自己问出正确的问题！

如果您能很清楚告诉别人，您想要的究竟是什么，这样别人才能给您真正需要的帮助，而不是做一些似是而非的虚工。

勉强自己接下不可能完成的任务，实在是以长痛代替短痛的做法，而且长痛的是整个团队，该拒绝的时候绝对不能含糊；

不要为了讨好别人而伤害双方的工作进程，您永远要根据自己的目标，做适当的决策。

必须保护项目不受外界的左右，尤其是当这种操控来自特权人物之手。

副产品对公司或产品都没有策略上的价值，充其量只是一种消费者回馈。

不值得开发的功能就不要做。

软件产品的开发，不能只为了有趣、挑战性，或是够有个性够令人眩目。

遵循标准重于一切，特别是关于使用者界面的部分。

确定您所要求的报告真的值得属下暂停工作，花那么多时间去写。

请注意定期会议的价值，确定它值得每个人放下手上的工作。

召开任何会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的。

不要利用进程表来驱使项目的进行，这对小组的士气伤害太大了。

让日程表维持适度的紧迫，但又是可以做到的，好让组员振奋、不松懈，专心致力于项目的推进。

绝对不要草率定出不可能的期限，导致组员为了赶进度而损害产品的质量。

把长期的大项目，分成几个完整而独立的小项目，各小项目必须有一个主题。

为了保持创意的活力和团队士气，必须让每一个小项目都有令人兴奋的结果。

不要让程序设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。

训练新进程序设计师时，先培养他对整个公司所有项目都有价值的技术，然后才培养本项目独有的技术。

不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学，为了公司和他个人的前途，您应该把他推荐到别的项目，让他的成长永不间断。

确定每位组员、每两个月都有一项技术上进步。

一发现某处需要改进，就立即采取更正的行动。

作者：阿南

，本文转自网络！！！

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航