| 随时睁大雪亮的眼睛，看看是不是有个?zhn)而未决的问题Q一定要有个?或是׃自?来负责研I到底哪里出错，也许q种研究既花旉又无聊，但LN发生之后再来花好几个星期收拾D局要好得多?/p> |
问了(jin)错的问题Q而导致错的答案，训练自己问出正确的问题！
| 如果(zhn)能很清楚告诉别人，(zhn)想要的I竟是什么，q样别h才能l?zhn)真正需要的帮助Q而不是做一些似是而非的虚工?/p> |
勉强自己接下不可能完成的dQ实在是以长痛代替短痛的做法Q而且长痛的是整个团队Q该拒绝的时候绝对不能含p；
不要Z(jin)讨好别h而伤宛_方的工作q程Q?zhn)永远要根据自q目标Q做适当的决{?/strong>
必须保护目不受外界的左叻I其是当q种操控来自Ҏ(gu)人物之手?/strong>
副品对公司或品都没有{略上的价|充其量只是一U消费者回馈?/strong>
不值得开发的功能׃要做?/strong>
软g产品的开发，不能只ؓ(f)?jin)有、挑战性，或是够有个性够令h眩目?/strong>
遵@标准重于一切，特别是关于用者界面的部分?/strong>
定(zhn)所要求的报告真的值得属下暂停工作Q花那么多时间去写?/strong>
h意定期会(x)议的价|定它值得每个人放下手上的工作?/strong>
召开M?x)议之前Q请定本次?x)议的目的是什么，达成q个目的的条件是什么，然后Q务必达到开?x)的目的?/strong>
不要利用q程表来׃ə目的进行，q对组的士气伤宛_大了(jin)?/strong>
让日E表l持适度的紧q，但又是可以做到的Q好让组员振奋、不松懈Q专?j)致力于目的推q?/strong>
l对不要草率定出不可能的期限Q导致组员ؓ(f)?jin)赶q度而损害品的质量?/strong>
把长期的大项目，分成几个完整而独立的项目，各小目必须有一个主题?/strong>
Z(jin)保持创意的活力和团队士气Q必让每一个小目都有令h兴奋的结果?/strong>
不要让程序设计师的学?fn)停滞不前，要让E序设计师有Z(x)练不同领域的技术，培养十八般武艺样L(fng)通的l员?/strong>
训练新进E序设计师时Q先培养他对整个公司所有项目都有h(hun)值的技术，然后才培L目独有的技术?/strong>
不要舍不得放(zhn)最优秀的程序设计师到别的项目去。如果他在?zhn)的项目已l没有新的东西可学，Z(jin)公司和他个h的前途，(zhn)应该把他推荐到别的目Q让他的成长怸间断?/strong>
定每位l员、每两个月都有一Ҏ(gu)术上q步?/strong>
一发现某处需要改q，q即采取更正的行动?/strong>
]]>
下面是来自china-pub的书评：(x)
| 作者详l描qC(jin)他在国领导目的各U实际的{略Ҏ(gu)Q教(zhn)如何开发高质量的YӞ而且l不延误。本书是为每一位从事研发工作的朋友而写Q相信?zhn)在读q本书之后，一定急于推荐l?zhn)的主、同事和(zhn)的朋友?/td> |
卓越的领D从不同的角度看世界。若是公司被大火烧得_օQ他非但不ؓ(f)丢饭惊慌，反而利用火焰来烧烤一大。当每个人都摇头dQ卓的领导者仍有充分的信心(j)保持乐观Q对每g事都从正面角度来思考。就因ؓ(f)凡事都看光明面，卓越的领Dƈ不把p|当失败，反将其当作学?fn)克服障的l验。正因如此，卓越的领D乐意尝试各U稀奇古怪的xQƈ从中获得重大的突_(d)即不成功，他只把这ơ经验当成获得信息的方式之一。这U领gh不一定要有经验，而是需要强烈的q取?j)和明确的理惻I能够理想与他h沟通，鼓舞他h共同q寻理想的能力，再加上一Ҏ(gu)?x)，q就是能理惛_现的卓越领导者?/p>
每当有h完成?jin)一Ҏ(gu)的功能或特色Q就发个e -mail l大家?/strong>
例如Q?/strong>
| “我已完成Faxmangler 的搜M取代功能。Frank” |
每当q度快要落后?jin)，到我的办公室私下讨论原因，我们一起开动脑{寻求解决之道?/strong>
例如Q?/strong>
| 当某位程序设计师觉得自己可能要落后了(jin)Q我?x)和他谈Q研I将来如何避免这U事情。是我们在制定进E时疏漏?jin)某一个重要环节吗Q或是时间表定得太乐观了(jin)Q是不是有个错虫( b u g )在作，宛_E序很难写或无法试Q不论问题是什么，我们一定想办法解决掉，q且预防它将来再发生?/p> |
可能减项目中组彼此间的依赖?/strong>
目标是明确Q达成目标的q程׃(x)有效率?/strong>
建立最适当的程序设计优先考虑序Qƈ且让所有的E序设计师确实遵守?/strong>
| 排出一个优先表：(x)
|
一旦?zhn)掌握了(jin)这个概念，把它应用在项目上Q?zhn)可以大声说自q实是在聪明地工作Q而不是辛苦地工?/strong>
一发现Bugqx除掉Q别拖g?/strong>
作者给出的提示Q?/strong>
| 错虫愈晚清除Q时间花得愈多? 在开发的q程q即除虫，可以让?zhn)早些学到l验Q然后就不会(x)再犯同样的错误；相反圎ͼ如果C(jin)目后期才发玎ͼ(zhn)可能已l犯q多ơ同L(fng)错误而不自知?/p> 发现错虫而立即除错是一U缓冲器Q提醒那些讲求快速而不够}慎的E序设计师，以后多加心(j)?/p> 若能保持没有M错虫Q?zhn)p比较准确估出目的完成时间?/p> 要求错虫随时发现随时改，{于是在开发过E中引进一个小的质量理机制Q多方的防微杜渐Q保护品的正确性?/strong> |
学习(fn)前h的经验；
好方法要让大家分享；
目只要有偏差，需要调_(d)l对不可以放任自！
定期暂停手边的工作，然后往前思考，随时做必要的修正Q以避免未来的大障碍?/strong>
| 有什么事情是我今天能做，而且可以帮助目在未来几个月内顺利进行的Q?/p> |
]]>
- 一只和谐的团队Q?
- l团队一个明的目标Q让大家都知道这个目标ƈ把它印入脑vQ?
- 让品保h员明白自׃仅仅是ؓ(f)?jin)Bug而加入团队的Q?
- 建立合适的(g)查点和里E碑Qƈ利用(g)查点和里E碑(g)验团队的健康度；
- 不要xg误，要不断的修正Ҏ(gu)但不要过度的修正目标Q?
- 努力让团队中成员产生共鸣Q?
希望大家共勉Q?/p>
Be like the doctors 用医生的Ҏ(gu)
当病人已l药石罔效时Q医生通常?x)对病情有所保留Q避免病人太q?zhn)观或恐惧Qƈ且尽量鼓qZ持希望，最好能让病人有个期望完成的目标?/p>
ȝl对不会(x)斩钉截铁地断a什么医疗行Z定会(x)有什么样的结果，反而是?
一U自在且充满信心(j)的口吻说Q?#8220;试试看吧Q一切都q没有确定呢?/p>
另外一件应该向ȝ学习(fn)的事情是Q即使是再小再简单的ȝ行ؓ(f)Q都带着几分风险Q所以医生会(x)_(d)(x)“当然QQ何情况都是有可能的，L率再高我都不能跟你说癑ֈ之百没问题?/p>
法则二十八：(x)
Remember the triangle:features, resources, times 软g开发金三角Q特艌Ӏ资源和旉
作ؓ(f)一位Y件开发的领导人，你得集中注意力在三g事情Q资源（人和钱）(j)、特Ԍ产品与其品质Q和旉。这三g事是软g开发的核心(j)Q其他的都是外围?/p>
资源、特色和旉是三角Ş的三个边QQ何一边的变化Q都?x)?jing)响到另外一Ҏ(gu)两边。所以如果时间落后了(jin)Q去看你的三角ŞQ看看对特色和资源的影响Q当有h谈到可以增加什么功能特色时Q你得立刻谈h间和资源Q以昑־你思虑?
详反应敏捗所以，理者的W一要务是把q个三角形放在心(j)里，随时利用q个模式来思考问题，你会(x)发现{案都在q个三角形内?/p>
法则二十?ji)?x)
Don't know what you don't know 不懂别装?/strong>
法则三十Q?/p>
Don't go dark 建立适当的检查点
法则三十一Q?/p>
Beware of a guy in a room 留心(j)没有(g)查点的组?/strong>
法则三十二：(x)
If you build it, it will ship 软g要经常徏构，p利推出
法则三十三：(x)
Get a known state and stay there 掌握实际情况
法则三十四：(x)
Use ZD milestones 零缺炚wE碑
零缺点不代表软g中没有错虫，也不表示没有遗漏的功能，而是指团队的成品辑ֈ?jin)事先规划的品质水准Q也l过试验证Q就是零~点里程?/p>
法则三十五：(x)
Nobody reaches the ZD milestone until everybody does 所有组员一起到N~点里程?/strong>
法则三十六：(x)
Every milestone deserves a no-blame postmortem 完成每个里程后Q心(j)qx和地(g)?/strong>
法则三十七：(x)
Stick to both the letter and the spirit of the milestones 把握里程的实质意义与精?/strong>
法则三十八：(x)
Get a handle on "normal" 培养正常的团队运?/strong>
法则三十?ji)?x)
A handful of milestones is a handful 里程不宜太多，才好掌握
法则四十Q?/p>
Every little milestone has a meaning (story) all its own 每一个里E碑应有专属的宗?/strong>
法则四十一Q?/p>
Look for the natural milestones L自然出现的里E碑
以下是六U自然出现的里程：(x)
1. 产品设计于E_?
2. 中间产品被明定义?
3. 团队真正?jin)解要花多少旉和努力才能完成目标（通常q会(x)发生很多ơ，而且多半是进度落后的时候）(j)?
4. 产品设计被删减，或是资源增加Q或是进度g误，
或是三者同时发生?
5. 开发活动停止?
6. 产品q入除错或稳定阶Dc(din)?/p>
法则四十二：(x)
When you slip, don't fall 如果滑了(jin)一跤，别就此倒地不v
- q度落后与道h养I请切讎ͼ
- 不要隐瞒事实?
- 化阻力ؓ(f)助力Q利用进度落后来Ȁ发效率?
q度落后不是问题Q被q度落后吓倒才是问题。进度落后ƈ不代表品的隑ֺ太高而无法开发。但是如果进度已l落后却未被察觉Q那表示l员们不思考、不观察、不讨论Q此时组l可说是Ȓ(f)瓦解?jin)?/p>
善用你的qgQ这是最能看Z领导能力的时候，此时也是l员最脆弱也最需要你的时候，在这个时候组员最能把你的话听q去Q此时组员的学习(fn)能力最强。如果你在办公室内激动得大喊大叫Q指天骂圎ͼ那就错失?jin)赢得组员的心(j)的大好Z(x)。你必须_(d)(x)“O KQ进度落后了(jin)Q让我们来看看问题出在那里？⋯⋯今天下午五点在会(x)议室Q我们要(g)讨每一个细节，问题一定要设法解决Q?#8221;当组员了(jin)解到你不是企囑֍责或帐Q而是真诚地想解决问题Q就?x)乐意把一切开诚布公地摊开来谈Q大家一L(fng)I题，从各U角度去设法克服问题?#8220;q度落后”反而变成大家宝늚成长l验?/p>
法则四十三：(x)
Don't trade a bad date for an equally bad date 不要因ؓ(f)q度落后而更Ҏ(gu)后期?/strong>
q度落后的程度是与计划的不确定性成正比?/p>
法则四十四：(x)
After a slip, hit the next milestone, no matter what延误?jin)这个里E碑Q就一定要如期到达下一个里E碑
我们必须明白Q每一ơ的延误Q就是你和团队信?j)的一ơ受挫，所以，延误q个里程时Q最好的补救办法是无论如何l不延误下一个里E碑。团队必L回对自己的信?j)和对理想的承诺Q因此，下一个Q务必d时完成的意义更重大，团队需要重Z?j)?/p>
法则四十五：(x)
A good slip is a net positive 把g误当作宝늚学习(fn)Z(x)
法则四十六：(x)
See the forest 见树(wi)亦见?/strong>
如果本项目有六个模块Q各? 0 %的部分已l完成，那么你已l完成了(jin)5 4 %。每个模块完成了(jin)?ji)成Q听h是个Z错的成WQ但不能当成整个目完成?jin)百分之九(ji)十Q它们之间不是相加的关系。你必须“见树(wi)亦见?#8221;。如果Q何一个模块完成比率是Ӟ那么整个目的完成率也是零?/p>
法则四十七：(x)
The world changes, so should you 世界在变Q所以你也得跟着改变
虽然你想做些改变Q你未必有勇气实行?/p>
伟大的Y件必定只有一个中?j)思想Q至于品质能够实现到什么程度，依赖领导者能否带领团队融合无C而重要的改变。如果你能在混ؕ中L识出寚w目最有意义的改变Qƈ且引导团队去适应它，它融入团队的精中Q将来就?x)在产品中表现出q项改变Q呈现在֮眼前?/p>
法则四十八：(x)
Violate at least one sacred cow x多于要求
法则四十?ji)?x)
Beta is not the time to change Beta试版不是修改功能的时?/strong>
法则五十Q?/p>
The Beta is for spin development Beta试是暖w活?/strong>
法则五十一Q?/p>
Triage ruthlessly 急救?/strong>
法则五十二：(x)
Don't shake the Jell-0 心(j)保持软g的稳?/strong>
法则五十三：(x)
Compete with the superior story 伟大的Y件应该有一个伟大的故事
法则五十四：(x)
Create a winning image 建立赢家形象
]]>
软g的设计─每一位团队成员都必须参与─q表C团队整体对功能需求的?jin)解E度?/strong>
软g设计的第一要诀是：(x)全团队中最好的xl织hQ去满֮内心(j)最深处的需要。（带领团队做案例研讨，带领大家思考如何解决一切的疑难Q让每一件事都在该做的时候做好。）(j)
法则十九(ji)Q?/p>
Go for greatness q求卓越
法则二十Q?/p>
State your theme 讑֮主题
重点是品的功能特色不能像是一袋子随便抓过来的东西Q应该把与主题无关的东西都删掉，而且你的目标也必ȝ合统一性（unity of purposeQ才行，q一Ҏ(gu)与主题互Z体的两面。将资金投注在这个目标上Q让所有的人都完全明白q个目标Qƈ且ؓ(f)q个目标努力Q做得到q些的话Q你的品就?x)完全包含这个目标?/p>
法则二十一Q?/p>
Minimize dependencies 不要倚赖不确定的?/strong>
法则二十二：(x)
Propitiate the gods qx֮的愠?/strong>
法则二十三：(x)
Portability is for canoes. 软g的可UL?/strong>
法则二十四：(x)
Design time at design time 在设计时时间因素考虑在内
开?/p>
法则二十五：(x)
Don't accept dictation 拒绝不合理的命o(h)
千万不要一味的唯命是从Q在必要的时候拒l！敢于拒绝Q?/p>
如果在上位者不让真正执行Q务的人来估计所需的进度，那就是专制?/p>
开发进度表应该׃而上来拟定，每一个h负责自己的工作，也负责设定它的时间表Q负责准时完成工作。责d充分授权是一体的两面Q二者兼备才能拟出合理的开发计划。一U非常有的q度估算Ҏ(gu)Q?/p>
法则二十六：(x)
Now go play 把工作当作游戏吧
]]>
Watch the ratio 注意人员的组成比?/strong>
“基本原则是开发h员和品保人员的比例不过2:1”q个是作者ؓ(f)我们提出的徏议，而在SUNq个比例被修改ؓ(f)1:1Q甚x1:2Q可见在目中品保h员比开发h员更加重要！
“其实真正负责软g如期完成的是品保人员。当q度落后Ӟ我们W一个要看的是品保h员：(x)人数够不够？有没有充分授权？有没有确实参与设计？q度上能不能跟开发h员配合良好？能不能一有问题出现就立刻提出警告Q品保h员和开发h员的理念一致吗Q是不是跟开发h员过度亲密而放_(d)”
“一个健全的软g开发团队一定要W合上述的h数比例原则，q_每一位品保h员所支援的开发h员不过两位?#8221;能做到吗Q至在我们公司q个Q基本上Q很难！
法则七：(x)
Use feature teams q用特色监督组
融入dQI d e n t i t yQ?充分的授权和责Q感，使hh控制权和影响力，愈能使自׃d融ؓ(f)一体?/p>
建立pQC o n s e n s u sQ?p是特色监督小l的气氛?/p>
Cq等QB a l a n c eQ?׃特色监督组的每一位成员都是不同的背景、专长，不同的工作角色和不同的观念，没有谁比谁优的情ŞQ所以每个h的地位都是^{的?/p>
权威是来自学识，而非职位?/strong>
在一个理想的目中，基本上有两种角色存在Q创造者（c r e a t o rQ和推动者（f ac i l i t a t o rQ。创造者是一些专业h员，例如开发程序、行销、Y件品保和文g撰写Q而推动者则负责凝聚团队p和维持最佳的开发环境?/p>
法则八：(x)
Use program managers 目l理的职?/strong>
目l理是Y件开发团队的一份子Q他的职责是Q?
• 领导大家定义Z个成功的产品?
• 引导大家对品注入深切的期望和信c(din)?
• 带领团队理惛_玎ͼ变成可预见的产品诞生?/p>
目l理应该要有技术的背景Q而且必须在两U层面非怸_：(x)一是对开发品所使用的技术很熟?zhn)Q二是拥有徏构Y件的技术领D力。项目经理必ȝ于哄骗、驱{、鼓励、要求他的团队做出最好的软g和表现出最好的工作效能Q他清楚知道软g制作q程中每一的投入和出细节，他必L得用最好的方式定义产品和维持健全的技术。最后，目l理q必L团队的发a人，面对媒体、客戗以?qing)整个组l?/p>
目l理是Y件开发的核心(j)人物?/strong>
你想?jin)解q个团队Q看看他们的软gq道了(jin)Q反之亦然?/p>
团队_Q?/p>
1. 一h同心(j)协力Q集合大家的脑力Q共同创造一Ҏ(gu)能胦(ch)产?/p>
2. 个h的创造力是一U神奇的东西Q源自于潜在的hcd(j)智潜能，它被情感丰富Q而被技术束~?/p>
3. 一h全心(j)全意地A(ch)献自q创造力Q结合成巨大的力量。结合的创造力׃q一h的互动关pR彼此激荡，而更加复杂?/p>
4. q种复杂的情况之下，领导变成像是人际互动的交响乐指挥Q辅助ƈ疏导各种微妙的h际沟通?/p>
5. 在团体中的沟通和互动是正而健hQ能够ɘq一h的力量完全结合，?x)生相加相乘的效果Q抵销互斥。沟通顺畅能使思想在团队中充分交流传达?/p>
6. 团队工作的品质比时程更重要，而作品的伟大是需要对“团队_”特别加强Q才能达成?#8220;团队_”可视Z别成员精的q_|而个人的_Q?p s y c h eQ则是他能感觉、能思考、能推论的内在力量?/p>
7. 倘若忽视?#8220;团队_”Q则只会(x)有^庸的成果?/p>
法则?ji)?x)
Be an authority Q?not an authority figure 要权威，不要霸权
权威的目的是让每一位团队成员都有自q专业权威Q和团队的专业自信，q才是管理者真正的权威?/p>
竞争
创新无处不在Q绝对不可以停滞不前Q?/strong>
如果你无法时时掌握时代的脉搏Q如果你怠于响应周围q速而剧烈的变化Q特别是竞争者的行动Q如果你不能持箋地创新原有的技术，永远保持领先Q那么别人马上就?x)趁虚而入Q取代你而成为市(jng)Z的优胜者，掌֮的心(j)和他们的荷包?/p>
定?jin)你的情况之后，应该先考虑采取标准步法?/strong>
标准步法Q?/strong>
法则十：(x)
Alone? A market without a competitor ain't 没有竞争Ҏ(gu)Q未必是好事
Q注QQ何h都有敌hQ）(j)
法则十一Q?/p>
Dead beat? Break out of a feature shoot-out 竞争者紧q不舍？推出创新的功能特Ԍ注：(x)x设法的压制你的敌人！Q?/strong>
法则十二Q?/p>
Behind? Ship more often with new stuffs 落后竞争Ҏ(gu)Q加大投入，更快推出新版本（注：(x)沉下?j)来Q夺回领圎ͼQ?/strong>
法则十三Q?/p>
Ahead? Don't ever look back 领先竞争Ҏ(gu)Q不要回_(d)注：(x)挑战自己Q战胜自己！Q?/strong>
准时地、经常地推出C品是软g开发业中最大的金科玉律?/strong>
法则十四:
Take the Oxygen along 保持新鲜
快速变q的节奏是信息社?x)的常态，你必d速前q，否则p伍了(jin)?/p>
֮
x设法的让֮qh上你的品！
法则十五Q?/p>
Enrapture the customer l顾客惊?/strong>
֮最低的希望是你能够理解他所感受到的痛苦l验?/p>
法则十六Q?/p>
Find the sweet spot L靶心(j)
法则十七Q?/p>
It's a relationship, not a sale 与顾客徏立关p，而不是卖产品
法则十八Q?/p>
Cycle rapidly 加速品推出的周期
]]>
首先看一下《微软团队：(x)成功U诀》分别在china-pub和豆瓣上的书评把Q?/p>
china-pub
| 本书叙述?jin)吉?麦卡锡带领微软Visual C++开发团队的故事Q告诉读者如何构Z个优U的Y件开发团队，如何在一D|间内成功地开发一个YӞ而且此后不断地完成新版，q一直受到市(jng)场的肯定。他自己思考的l晶和种U惨痛的教训归纳?strong>54?/strong>a意赅的法则，从品设计、程序开发到成功的营销Q无所不包Q在微YQ本书是每一位项目经理的必读圣经?/td> |
豆瓣
|
作ؓ(f)一位经验丰富的老手Q作者将自己思考的l晶和种U惨痛的教训归纳?strong>54?/strong>a意赅的法则，从品设计、程序开发与构徏、准时推Z品，到成功的营销Q无所不包。?zhn)?x)发现本书像软g开发本w一栯人有。本书是Y件设计者、开发h员、营销人员、技术主，以及(qing)所有亟Ʋ一HY件开发奥U的人士所写的?/p> |
法则一Q?/p>
Establish a shared vision 建立一个共同的目标
在团队d立共同的目标是非帔R要的Q团队中的成员只有当有了(jin)共同的目标之后才能有归属感，才能Ҏ(gu)憬中的品生荣誉感Q才能在理中更好的调动各个成员的积极性，从而将团队推向正轨Q让产品如期发布Q?/p>
“团队中每一位成员都必须非常清楚我们要做什么、成品会(x)是什么模栗基本的产品{略是什么、什么时候必d成。凡是与共同目标相冲H的看法都必{化成一_(d)而不是把它消韟뀂和谐的p是绝对必要的Q否则Y件不可能做得好，很多事会(x)复杂化而难以收拾?#8221;
所谓目标是共同的希望，Ҏ(gu)来的事情所描绘出来的景象，比方说作者在lVC++目l开?x)时候的描述“Visual C++是最伟大、最值得?jing)傲的品，你们N不这么认为吗Q我知道我们可以如期完成它，而且用它来给Ҏ(gu)一个迎头痛击，不只我一个hq么惛_Q我们将创造微软的明日世界Q我们会(x)大有作ؓ(f)的，不是吗？”其实他已l给VC++?jin)一个很好的目标Q他让成员们觉得Q我们都是在伟大事情Q一但在团队中Ş成了(jin)荣誉感，你会(x)发现你的团队会(x)I前的团l！
法则二：(x)
Get their heads into the game 使大家主动投?/strong>
“如果每个人都在认真思考如何团队更有效率Q这个团队自然就比较Ҏ(gu)表现出高效率Q反之亦然?#8221;让每一个h都参与进来，需要管理者能够调动每一个h的积极性~让大安d的去思考问题，Z品主动的?gu)划策?/p>
需要管理者去們每一个愿意说的成员的a论或者主意，需要判断的q些a论或者主意的能力Q面对好的想法，也许它不切实际，但是也不要一子打死Q而是要进行诱|让他下次可以提出更好的更切实际的x来?/p>
鼓励创新而非Ҏ(gu)它！
Z么组员会(x)怠于思考或是不敢说出想法？
• 因ؓ(f)他们认ؓ(f)没有Z(x)重视他的x?
• 因ؓ(f)他们认ؓ(f)该由别h告诉他该做什么事?
• 因ؓ(f)他们认ؓ(f)q样做没有什么好处，只会(x)使老板q头Ş?jin)?
• 理者只发h令而已?/p>
法则三：(x)
Create a multi-release technologyplan 建立开发多版本的技术规?/strong>
授权共决Q其实就是全民参与，无论是对待成员的新想法还是对待项目的技术规范时都用全民参与。（q样好吗Q安全吗Q）(j)
法则四：(x)
Don't flip the bozo bit 别做W蛋
软g产业中最重要的事情是“让大家思考！”?/p>
“在微软我们把q种人叫作b o z oQ意思是W蛋。永q没有h?x)注意笨蛋的所作所为，即他真的有贡献Q他也不?x)有M份量。笨蛋当然是不可信Q的，你对W蛋惟一的期望是但愿他不要搞怺情?/p>
在我的部门里Q这Ud行是不允许的。我要每一个h都全?j)全力地投入Q每个h都得有A(ch)献，每一个h都可以侃侃而谈我们的品─如何在市(jng)Z竞争、何时出新版本等{，而且每个人对产品的看法都一_(d)不会(x)众说U云?/p>
自q意见加诸于他，其实是笨蛋?#8221;
需要随旉范组员出?#8220;江郎才尽”病！
法则五：(x)
Use scouts 刺探敌情
必须有一个h或者有一些h去观察未来的发展势Q预a新技术。这个角色是非常重要的！
“q次他们学乖?jin)，事先z了(jin)两位最优秀的组员担?#8220;侦察?#8221;Q做?jin)一ơ彻底的技术调查和完善的规划，l于在危机爆发之前将之化解?#8221;
““侦察?#8221;是为科技的改变而准备的Q如果你军_永远停着不动Q那你不需?#8220;侦察?#8221;?#8221;软g公司中如果没有这个角色还叫Y件公司吗Q?/p>