如何更好地说服管理者接受敏捷？
jessi...@gmail.com
首先一定是上级的信任，上级对于软件开发过程的改进的重视，这个角色最好是研发的主管。
（其他CEO的估计困难很大，因为让商业模式由契约关系改为合作关系真的太难了，对当今的专注于行业应用的软件公司来说）
对于其他改进过程的实践，我更倾向于"神似"，而不是"形似"，在具体的形式上可以妥协一些：
"高深"的理论向来都不能"武装"人，只能吓跑人，所以我从来没在我的上级，或是同事之间说过，我们要"Agile","scrum"，或"XP"，
或"pair"。
我说："头儿，我有些内部管理的想法想在我们项目中尝试下。"
头儿说："可以啊，没问题"。
我说："上次项目总结大家提的问题不是都说'计划赶不上变化'吗，那我们现在能不能尽量把周期缩短点，能预见多长，就定多长的计划呢？"
大家点头："对，是该试下"。
我说："××，你看看是不是我们俩在一起研究下这块的代码"？
然后结对开始了。
公司外部版本发布，要严格走流程，我们就不停采用内部发布，这样一点一点小版本就出来了。
。。。。。。
不知是否说明白了，可以看看"Jessica同学Scrum实践小记"。
希望对大家能有点帮助。
jessi...@gmail.com
其实我认为敏捷方法里面最核心的精髓还是"自组织团队"。
如果你的团队做到了"自组织团队"，具体工作中采取什么样的形式又有什么关系呢？
大家发挥自己最大的能力，凝成一股绳，火力都集中在同一个地方，还有攻不破的碉堡么？
On Apr 2, 6:35 pm, "jessica....@gmail.com" <jessica....@gmail.com>
wrote:
Bei
气再差一点，团队被塞进来个喜欢打太极的，能把人给郁闷至死...
在外面做了段时间项目，真是理解了Kent Beck这句话："无论表面上是什么问题，归根到底还是人的问题"
On 4月2日, 下午7时26分, "jessica....@gmail.com" <jessica....@gmail.com>
wrote:
Donald
所以，少说些主义多解决点现实问题，不管你应用的是不是敏捷的实践，都肯定会被同意的。
Bei：
根据我的经验，构建"自组织团队"与运气无关，团队领导者在团队风格方面的建设是个可以学习掌握的实践性管理工作，而不是某项受未知力量指引的工作。
在 07-4-2，Bei<Bei...@gmail.com> 写道：
--
Donald
-------------------------------------
上善若水，水善利万物而不争，处众人之所恶，故几于道。居善地，心善渊，与善人，言善信，政善治，事善能，动善时。夫惟不争，故无尤。
－－ 老子 《道德经》
jessi...@gmail.com
尤其对于国内目前本来就是非良性竞争的应用软件行业来说，又有多少公司能象华为那样财大气粗用钱去砸人呢？
每个团队都不可能是完美团队，受制于很多现实条件，或许团队里面有2个猪八戒，或许团队里面除了一个孙悟空，其他的都还不及沙僧，或是人员变更，这都是
不可避免的。
象我所在的项目，人员也总是流动，新来的刚培养1－2年，好不容易可以独档一面了，离职了。
我们另外一个项目组里，就象你说的，有个打"太极"的，比较"自私"，多做一点事情就认为自己"吃亏"。
我想，作为一个"教练"，能做的就是：能找到条件更好的队员，最好；不能找到，就要想办法发挥出每个人最大的潜力。这需要耐心，更需要信心。
两年前看到的一个帖子，"一个项目经理应该具备的能力"，对我非常有启发，说的也正是"教练"应该具备的能力，因此共享给大家：
管理方面：
个人认为管理方面的知识当然是必需的了，就不多说了。
能细致计划和预先看到存在问题的能力
处理突发事件的能力
结团队带来快乐气氛的能力 （Jessica注：这一点非常重
要）
勇于承认错误的能力（这个可是非常难做到的哦）
学习新技术的能力
解决开发中人员变动和新员工培训的能力 （Jessica注：我认为培样人的能力应该是放在管理能力第一位的）
能够跟各个相关部门进行协调的能力
个人坚定意志和领导力
事业心和责任感
承受工作压力和忍耐力
个人综合情商
其它能够帮助管理的能力...
技术方面：
新技术领域的概况了解
广泛的知识面
当前应用开发，设计，版本控制，管理，测试，系统工具的了解
所需要用到的技术领域熟练应用和了解
员工技术水平的了解和个人特长的了解
对领域内竞争对手优势技术的了解
学习新技术的能力和热情
管理团队，发挥每个人最大工作热情的能力 （Jessica注：作为"教练"最基本的能力）
和上级同级部门友好相处，保护本部门员工利益的能力
细致思维和完整清晰文档编写能力
制作简洁明了power point演示文档能力
参与招标的项目还需要有良好口才和外表，自信并能够说服别人的能力
有一定审美能力和能够为他人着像的能力，在用户界面设计和易用性方面能够发挥
建议大家无论是PM，或者是其他管理者（我认为任何一个人，无论在什么岗位都是一个管理者：管理自己，管理同事，管理上级），大家都可以对照这些为自己
打打分，不足的地方去提高，最终会成为一个合格的教练的。
盖浇饭
谈理论也未尝不可。
On 4月3日, 上午9时00分, "jessica....@gmail.com" <jessica....@gmail.com>
wrote:
> > > > 希望对大家能有点帮助。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
霍泰稳
用敏捷实践，也就是如何说服领导也参与进来。Liz Barnett，Agile Journal杂志的总
编撰文说，对任何大范围的敏捷应用，组织内自上而下的支持都必不可少。仅有草根阶
层的支持还远远不够，管理层也必须参与。还给出了如何应对管理者提出的对敏捷疑问
的解决办法，可以借鉴一下她文章说的一些经验。
如何说服领导以自上而下应用敏捷方法？链接为：
http://www.infoq.com/cn/news/2007/04/March2007AgileJournal
Top-Down Support Is Essential For Wide Scale Agile Adoption 链接为：
http://www.agilejournal.com/content/view/281/
Kevin Huo（霍泰稳）：Chief Editor, InfoQ China
E-mail: ke...@infoq.com
Phone: 13811662678
MSN: fire_fut...@hotmail.com
Blog: http://blog.csdn.net/futurelight
http://www.infoq.com
InfoQ.com：Enterprise Software Development Community
-----Original Message-----
From: agile...@googlegroups.com [mailto:agile...@googlegroups.com] On
Behalf Of 盖浇饭
Sent: Tuesday, April 03, 2007 10:11 AM
To: 敏捷中国
Subject: [agilechina] Re: 如何更好地说服管理者接受敏捷？
少说理论，多做实践，确实是一个比较好的方法。等各个实践都比较成功了，再提什么
Bei
To Donald:
It's my fault to write down the sentence "自组织团队'的构建很靠运气" at the
beginning of my post (first sentence is always impressive, right?)
without detailed explanation. Now I can figure out some drawbacks of
my team, and I'm trying to improve, sometimes what I did just like
what jessica do, giving these suggestion to my leader without mention
'XP, Agile' to make my suggestion easy to understand, sometimes I give
presentation to team members on these good practices, sometimes I post
short articles i wrote to my MSN space which could be seen by my team
member and leader, to introduce good practices; sometimes I print out
good articles and distribute to my team members. But maybe because I'm
new here, people with years of experience don't listen to these
suggestion very carefully.
I think people who have experience in consulting may understand
this situation. These big guys (form 'big company') won't change their
mind easily. But things are always getting better, at least, our test
team is trying to use NUnit, DBNUnit and Selenium to automate our test
and dev team is trying refactoring with the poor tool provided by
VS2005 now:)
Billy
On 4月3日, 上午8时33分, Donald <flying...@gmail.com> wrote:
> jessica 说的有道理，在不能将理论同现实结合的情况下提理论，最终肯定会被驳倒
> 所以，少说些主义多解决点现实问题，不管你应用的是不是敏捷的实践，都肯定会被同意的。
>
> Bei：
> 根据我的经验，构建"自组织团队"与运气无关，团队领导者在团队风格方面的建设是个可以学习掌握的实践性管理工作，而不是某项受未知力量指引的工作。
>
> 在 07-4-2，Bei<BeiL...@gmail.com> 写道：
Bei
testers with DBNUnit to save devs' time.
咖啡屋的鼠标
呵呵，肯定有效，一点点蚕食比一次性推翻要容易一些，很多管理者最害怕的就是下属给他宣扬某某理论，认为是头脑发热。虽然他们往往头脑发热得更厉
害。^_^。
On Apr 2, 6:35 pm, "jessica....@gmail.com" <jessica....@gmail.com>
wrote:
li xiao
庄表伟
Donald
在 07-4-5，li xiao<swin...@gmail.com> 写道：
> 想起一本书《这是你的船》，似乎和"自组织的团队"有异曲同工之妙
>
>
> >
>
Jeff Xiong
--
Jeff Xiong
Editor of InfoQ China: http://www.infoq.com/cn/
Contributor of CruiseControl.rb: http://cruisecontrolrb.thoughtworks.com/
li xiao
还在于读者本人，所谓"取其精髓，去其糟粕"，这点都做不到，难以恭维。
我对项目的看法有根本的转变就来自这样一句话：只有我们的项目，没有你的、我的或者他的。
把自己看成团队的一份子，共荣共辱，这需要个人的修为。即使管理者并不这样看待，也无伤大雅，对于个人，为团队做些付出，一定是有很多收获的，
你仔细去观察身边的话，那些突出的人，基本上都会有这样的特性；很多人会怨天尤人，怪别人不看重自己或者不给自己机会，但是要求别人不如要求自己。
即使从自私的角度来说，帮项目也就是帮自己，多给自己留下一些成功项目的履历又有什么坏处呢？就算项目失败，作为冲锋陷阵的一员，对项目的了解可以让你更好地从中吸取教训，冰X和徐X就是活生生的例子（这才是无论项目成功失败，都不影响个人前途的大计）……
无论书上怎么说，对正确的观点不接受，那是道不同不相为谋。
li xiao
Donald
而我之所以认为不应该推荐这两本书，也没有送出过这两本书，是因为看书的过程是一个不可控的心理过程，你没办法在送出后获得他在看书过程中的感悟。而通常合上书之后，人们会说不出当时的感想，而那种心理体验却挥之不去。这就是我所说的负面情绪。所以我宁愿采取面对面交流、培训或者研讨会的形式来讨论这些比较不好把握的书籍的内容（通常不提书名）。
你所说的这句话：只有我们的项目，没有你的、我的或者他的。
也正是我喜欢的，从我前面的回复可以看到，不过实践是，要不断的施加教育和影响，而不是寄希望于挑选到积极的合作者，即使很幸运的得到积极的合作者，其心理结构也是很复杂的，可能在某些方面很积极，而在其他方面却有很大的消极情绪，从而在某些情况下影响到积极的方面，这也是开发人员的通病之一。
在 07-4-5，Jeff Xiong<gigi...@gmail.com> 写道：
Tony Qiao
没有发挥出很大的作用。后来与yk where（我们项目的观察者） 讨论了一下，觉得这与具体组织的环境相关。我们并不应该指望"说服管理者"，能够
说服的话，再好不过（机会很小）。只能引导管理者，因为做为公司的"执行层"，无论如何还没有那么大的影响力。
所以做这事儿，应该如jessica.kjm所说，换个提法试一下。另外，"外来和尚"也是至关重要的一个因素。就像CMMI，且不说它的效果到底
如何，但从它出生到进入中国，再到中国目前的认同情况（官方或非官方），可以很好地说明这个问题。
所以，想做敏捷实践（或其它好的想法）的朋友，别太指望自己的力量去影响更大范围，在自己的影响范围内做一些事情就可以了，只要得到管理者的同意就
行（当然，大力支持更好）；有效果的话，管理者是会看到的。
公司的管理者也不容易，要平衡好多事情，才能决定做一件事情，不象处理1+1那么简单。项目经理也是一样情况。我想，在TW中，如果项目进行的好，
那个项目经理应该是非常轻松，所有的事都由Customer,BA，QA,DEV摆平；一旦项目出了问题（不只是技术问题，包括商务问题等），这个项目
经理就会深陷其中。因为管理者已经把项目交到了项目经理的头上，项目的成败由项目经理负责，包括是否亏本这件事。当然，对于那么"是否亏本与我无关"这
样的项目经理，情况就不一样啦。
写到这里，才想到这个topic的题目应该改一下，呵呵"在中国，敏捷的路怎么走更容易"，如何！哈哈。
On 4月2日, 下午7时26分, "jessica....@gmail.com" <jessica....@gmail.com>
wrote:
zongzi
对于高层管理者，就是告诉他敏捷的某种本质。我印象最深的说法是"敏捷是更加高级的生产组织（剥削）方式……结对就是最有效率的互相监视和培训方式……"
Shane Duan
外来的和尚一定是起了促进的作用．但我觉得最根本的原因还是前一阵子提出来的有关证书的话题.
CMM在这个方面上太好了．看看材料，过过考核，一年半载的就能拿着三级四级的证书出去拉项目，多方便．
上级想表现一下重视也简单啊. 出点钱就好了，都不用去审核是不是真的有用：证书都拿来了，他们要还做不出来那就一定是他们笨上了当，不是我的管理用人不当．
--
Shane
http://www.shaneduan.com
Tony Qiao
也许，当"Agile证书进入中国"，Agile也一定会全面流行起来的。
呵呵。。。。
On 4月6日, 下午3时21分, "Shane Duan" <shane.d...@gmail.com> wrote:
> 我同意主要的说法. 但我对CMM流行的原因持不同的意见．
>
> 外来的和尚一定是起了促进的作用．但我觉得最根本的原因还是前一阵子提出来的有关证书的话题.
> CMM在这个方面上太好了．看看材料，过过考核，一年半载的就能拿着三级四级的证书出去拉项目，多方便．
>
> 上级想表现一下重视也简单啊. 出点钱就好了，都不用去审核是不是真的有用：证书都拿来了，他们要还做不出来那就一定是他们笨上了当，不是我的管理用人不当．
>
> Shanehttp://www.shaneduan.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -
机枪兵
而 CMMI 将过程的因素放在第一位。所以我觉得管理者是否能接受敏捷思想，从根本上说还是要看他是站在哪一边的；如果管理者不重视人的因素，妄图靠
某种机械化管理就能一劳永逸的搞定所有项目，敏捷只会令他反感。
Donald
sale，甚至有时候是tough sale。难免会引起反感。
跟高层谈的时候，尤其要注意不要谈产品，谈细节，要谈贡献，谈目标。
jessica的这个问题，归根结底不是个技术问题，是个销售问题。
在 07-4-7，机枪兵<yidi...@gmail.com> 写道：
> 我们公司最近在准备过 CMMI，通过对 CMMI 的了解我感触最深的是敏捷与 CMMI 最大的区别是敏捷将人的因素放在项目成败与否的第一位，
> 而 CMMI 将过程的因素放在第一位。所以我觉得管理者是否能接受敏捷思想，从根本上说还是要看他是站在哪一边的；如果管理者不重视人的因素，妄图靠
> 某种机械化管理就能一劳永逸的搞定所有项目，敏捷只会令他反感。
>
> >
>
jessi...@gmail.com
InfoQ: 作为一个社区，我非常担忧这种情况，当敏捷开发起作用时，我们夸耀自己，而敏捷开发行不通时，我们彼此踢着皮球并且说这样做不"正确"。
如果敏捷开发更像是价值观而非规范或特定的习惯，那么一个机构如何才能知道何时他们真的在进行敏捷开发呢？如何才算正确地进行敏捷开发呢？
KB: 你描述了人们对结果不满意时的反应，但你忽略了人们从中学习到经验的机会。我想，因为我们怕难为情，我们已经错过了许多分享和学习的机会。
有时我们会想，"假如我是一个完美的程序员，这个项目应该就会非常成功了。如果项目不是轻松完成，那我就算失败了。"这种心态或多或少地影响了我们的行
为。
而且确实，当你承认失败时，敏捷开发社区中的人们会斥责你的失败。在避免这种令人胆战心惊的结果的同时，我们与那些有用的心得失之交臂。
成功的项目需要许多因素以及彼此的同心协力，一个人无论多聪明或者多么卓越，项目的成败都不可能由他一个人的技术能力和意志力决定。无论如何，沟通、团
队建设、时间安排、与公司其它部门协作、甚至编码窍门等，这些东西都是我们可以从失败的项目中学到并应用于未来项目中的。如果我们愿意分享心得（而不是
我们的失败感），那么作为一个社区，我们还可以做得更多。
敏捷开发一词的含糊性会成为一个障碍。问"我们做得正确吗？"（或更可能的情况--告诉别人"你做得不正确！"），这个问题并没有什么价值。"我们在学
习所有我们能学到的吗？"和"我们需要改变自己来最大限度地迎合公司的目标吗？"这两个问题更有意义。如果敏捷开发成为一种意识，那么我们并不真的需要
衡量正确与否的尺度了。你工作时有敏捷开发的意识吗？你尝试过从多个角度看问题吗？你会突破桎梏去思考吗？你会参与到团队交流中，共同向一个有价值的目
标去努力吗？你会以坦荡诚实的胸怀和负责任的态度向你们共同的目标努力吗？你参与的流程如何在组织中起作用，其意义远比一个敏捷开发专家对流程的思考要
重要。
On 4月8日, 下午9时27分, Donald <flying...@gmail.com> wrote:
> 管理者需要业绩，需要成果。所以我觉得说服的时候，实际上是在对你的上级进行一次产品销售，你要从他的角度考虑，考虑你的客户需要什么，然后从这里突破，如果说敏捷是你的产品，那么你要让你的产品变成你的客户需要的产品，要同客户的需求出发，列出能够满足他需求的特性，甚至，你可能需要结合客户的特点对你的产品进行一些定制（裁剪或修改，只要不改变你的目标即可，btw，你知道你的目标吗？不仅仅是实施敏捷吧？），而不是自顾自的鼓吹agile的好处，那是hard
> sale，甚至有时候是tough sale。难免会引起反感。
>
> 跟高层谈的时候，尤其要注意不要谈产品，谈细节，要谈贡献，谈目标。
>
> jessica的这个问题，归根结底不是个技术问题，是个销售问题。
>
> 在 07-4-7，机枪兵<yiding...@gmail.com> 写道：
zswu
Jeff Xiong
对老板还是对程序员，都一样。
On 4/12/07, zswu <wuzon...@gmail.com> wrote:
> 说服老板是很难,可是我觉得让程序员接受敏捷似乎也很难.我在公司里推广XP,首先从TDD开始,可是很多人都不接受,哪怕试一下都不愿意.我做培训,大家都"积极"参加,可是讲到最后就开始讨论很空泛的东西.完了以后就没有音信.这与我的方式有关系,也与团队的心态有关系.
>
> 应该如何让程序员接受敏捷,不知道大家如何看待这个问题.我想这个答案也可以帮助我们更好的建立一个完整团队.
>
> >
>
--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://cruisecontrolrb.thoughtworks.com/
Technical Evangelist - http://www.infoq.com/cn/
collin000
成立一个标准, Agile一定发展的更快!
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Jeff Xiong
我一直喜欢《软件工艺》里的说法：软件业应该学习好莱坞。reputation over certificate。
On 4/12/07, collin000 <coll...@gmail.com> wrote:
> 这个Agile证书我觉得到是很有前途的东东, 呵呵. 不知道TW推过么?
> 成立一个标准, Agile一定发展的更快!
>
--
Jeff Xiong
这样比较押韵
jessi...@gmail.com
任何真理之所以能够是真理，就是它本身承认它自己必须发展变化。
On 4月12日, 下午5时49分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 更正：reputation over certification
>
> 这样比较押韵
>
> On 4/12/07, Jeff Xiong <gigix1...@gmail.com> wrote:
>
> > Agile的精神在于能够适应变化，对不同的环境采取不同的行动。这恰好是很难标准化的一种特质。
>
> > 我一直喜欢《软件工艺》里的说法：软件业应该学习好莱坞。reputation over certificate。
>
> > On 4/12/07, collin000 <collin...@gmail.com> wrote:
> > > 这个Agile证书我觉得到是很有前途的东东, 呵呵. 不知道TW推过么?
> > > 成立一个标准, Agile一定发展的更快!
>
> > --
> > Jeff Xiong
> > Software Journeyman -http://gigix.thoughtworkers.org
> > Open Source Contributor -http://cruisecontrolrb.thoughtworks.com/
> > Technical Evangelist -http://www.infoq.com/cn/
咖啡屋的鼠标
--
如果不想背弃自己的灵魂，就必须背弃自己的恶习
－－－－23岁后的人生信条
li xiao
别人看到你总是付出比较少，获得比较多，自然会效仿，或者会关心一下你所使用的技术。如果自己做不好，那
真的很难说服别人的，毕竟这个东西不是一朝一夕的事情。
宇文拓
说服老板是很难,可是我觉得让程序员接受敏捷似乎也很难.我在公司里推广XP,首先从TDD开始,可是很多人都不接受,哪怕试一下都不愿意.我做培训,大家都"积极"参加,可是讲到最后就开始讨论很空泛的东西.完了以后就没有音信.这与我的方式有关系,也与团队的心态有关系.应该如何让程序员接受敏捷,不知道大家如何看待这个问题.我想这个答案也可以帮助我们更好的建立一个完整团队.
zee ho
只靠洗脑，是不成滴。
When you came to this world, there is no going back, And , when you can't go back, you only have to worry about the best way of moving forward, The rest is up to God, including the danger ---- From <Alchemist>
yk where
*****
我也一直在想这个问题呢，虽然"好莱坞式的开发团队"这个概念在80年代曾经提过，但为啥软件业到现在还没有走上那样的道路？虽然大拿的名字在业内也是如雷耳，但从整个产业的层面来说，软件开发不是明星制的；从下游产业来说，程序员经纪公司的形态也没有（普遍）出现。从这个角度想想软件和电影工业到底有啥不同，也许对软件开发会有不同的认识？不过，我现在还没想明白。各位大拿说说。
On 4/5/07, Tony Qiao <sagittatius.q...@gmail.com> wrote:
*****
Tony Qiao 好像点我的名了，呵呵。我觉得作为agile的引入者应该能够考虑到各方的利益。管理者/客户/程序员想从项目得到啥？管理者倾向于用CMM证书去拉项目，也许是因为这样的外在证书能够让客户快速建立信任。XP就得从其他方面提供这种信任，比如一个短期内能摸得着的产品.
CMM实际不太重视程序员想要啥，XP就得告诉管理者不重视程序员的需要短期长期会有啥后果，XP能提供啥策略.
CMM和XP当然都重视客户。但CMM容易把客户利益和开发团队的利益对立起来，那XP引入者就得告诉高层XP有啥策略能让双方都有利可图。其实用啥方法高层并不在乎，XP提供的方案能满足他的利益就行。XP其实提供的是另外一种视角看软件开发中的商业关系。还是敏捷者老说的那句话你能提供啥'价值'？
敏捷中国
> 最近在看一本书《重构极限编程--XP的实践与反思》，于是想到一个更加困难的问题：
>
> 如何说服看过这本书的管理者，接受敏捷？
>
*************
你可以拿着一摞攻击CMM文章和上面提到的那本书一起拿到管理者面前，跟他慢慢谈。真实的世界就是这样的，没有哪个模型是完美描述你所处的世界的。所以
重要的不是哪个模型好或者不好，而是你更能从哪个模型中吸取对你有用的东西。'No one best way.' 你自己面对的问题，还得你自己综合
各种模型去解决。毛主席说，自己动手丰衣足食：）
《重构极限编程--XP的实践与反思》这本书我看过，挺好的。 想接受敏捷的管理者，看到这样的书反倒更踏实。因为，他能知道负面问题在哪里，好预防。
他们怕那种，吹得完美无缺的方法，没有人提到负面风险。一旦负面问题出现，猝不及防，成本巨高。
Yiding He
如果队伍中存在水平不高又没有上进心、不服管教的人，那就头痛了。
苏立龙
这句话说道我心坎了.
Yiding He 写道:
> 老板对属下放心，他就会认真听取关于敏捷的话题；老板不放心的话，他宁愿推
> 行 CMMI。
>
> 如果队伍中存在水平不高又没有上进心、不服管教的人，那就头痛了。
---------------------------------
> >
咖啡屋的鼠标
老板对属下放心，他就会认真听取关于敏捷的话题；老板不放心的话，他宁愿推行 CMMI。
如果队伍中存在水平不高又没有上进心、不服管教的人，那就头痛了。
--
如果不想背弃自己的灵魂，就必须背弃自己的恶习
－－－－23岁后的人生信条
苏立龙
我想既然他能作为老板,肯定有他的能力所在.他放心的下属,并不一定思想要和他差不多.他肯定知道,条条大道通罗马.所以,他所依赖和信任的下属,一般都 会放手让他去做.如果他不放心,那你需要检讨了,可能他所考虑的问题,你没有考虑到.即使他所考虑的问题不是问题(这种可能性极小.).
我觉得老板不信任自己,首先需要反思自己.然后再去反思老板(走到这一步,我认为可以考虑离开了)
昨天看了一篇帖子:
艾森豪威尔当上统帅的经历，是马歇尔起用了艾森豪威尔。
马歇尔在美国陆军五星上将里，名列第二，仅次于潘兴。第二次世界大战时，他担任陆军参谋长。这个职务负责陆军的军政和军令，当然对陆军高级军官 的人事提名也具有全权。由于罗斯福总统非常信任他，因此，只要马歇尔提名晋升的军官，罗斯福总统均会批准。
艾森豪威尔之所以成为马歇尔满意的将帅人选，和马歇尔独到的用人标准是密不可分的。
本书第三讲曾经详细说到马歇尔如何惩罚“跑官”“要官”者的故事。然而，在品行问题之外，马歇尔也有一套严格的用人标准：
不用文过饰非、邀功推过的人。他认为高级军官必须在他们的职权范围内自己去思考和行动，遇有责任就推卸的人，不可能胜任给他的职务。
不用事必躬亲的人。因为在他看来，这种人习惯埋头于琐碎小事，没有能力处理战争中更重大的问题。
慎用性格粗暴的人。他认为这种人通常把坚定有力和蛮不讲理混为一谈。
不用悲观主义者。因为这种人往往把困难说得非常可怕，并且特别害怕用已经掌握的方法去克服这些困难。
不用不善于团结的人。他认为，战争不是一个人的事业，不善于团结的人很难将战争的协奏曲演奏好。
艾森豪威尔的个性就非常符合马歇尔的用人标准。
马歇尔是通过以下几件事最后敲定由艾森豪威尔担任盟军统帅的。
1941年夏天，艾森豪威尔担任第3集团军参谋长期间制定了一个大规模的演习计划。这次演习最突出的特点是后勤协调得好，后勤保障及时有力。这 个问题在当时是一个大难题。马歇尔看了后认为，后勤保障牵涉面极广，能协调得如此好，得益于事先计划的周密。这是艾森豪威尔第一次上马歇尔的黑色笔记本。
太平洋战争爆发后，由于艾森豪威尔曾经在麦克阿瑟将军办公室工作过6年，对菲律宾防务非常了解，和麦克阿瑟本人的关系也非常好，被调到陆军部作 战计划处负责远东事务。1941年12月10日，艾森豪威尔向马歇尔报到。马歇尔用20分钟向他说明工作调动的原因，然后问他：“我们在远东太平洋的行动 方针应该是什么？”
如果艾森豪威尔当时就回答是什么的话，那么很可能就不会有后来我们认识的艾森豪威尔了。因为马歇尔比较讨厌对重大问题脱口而出的行为，认为这种 不加考虑就给出答案的做法投机的成分非常大。
然而，艾森豪威尔却想了片刻，冷静地回答：“将军，让我考虑几个小时后再回答您的问题好吗？”
马歇尔满意地看着艾森豪威尔，只说了一个字：“好！”他的黑色笔记本上，艾森豪威尔的名字下面又多了一行字：此人完全胜任准将！
在决策美国究竟是“先欧后亚”，还是“先亚后欧”，还是“欧亚并重”的战略问题时，艾森豪威尔的表现同样出色。太平洋战争爆发后，美国上下多数 都认为应该以太平洋地区为战略重点，先打败日本人，再对付希特勒。然而，罗斯福和马歇尔则从大战略上考虑，认为必须实行“先欧后亚”战略，就是说要把美国 的主要力量先放在欧洲，而不能化整为零地用于太平洋地区。于是，1942年4月7日，马歇尔先到英国访问，和英国人达成一项联合作战的草案。回来后，他没 有对任何人透露草案的内容，只是命令艾森豪威尔飞往英国作一次实地考察，并对在英国设立美军指挥部，处理日后日益增加的兵力等问题提出建议。10天后，艾 森豪威尔回国。6月8日，他完成了一份名为《给欧洲战区指挥将领的指令》的报告。在这份报告里，艾森豪威尔详细提出了美军赴欧洲作战时各军兵种统一指挥的 问题。
艾森豪威尔在菲律宾服役6年之久，对日本人深怀仇恨，因此也应该是最主张坚持“先亚后欧”战略的人。然而，艾森豪威尔却在并不知详情的前提下， 不仅坚决主张“先欧后亚”战略，而且制定出一份非常好的关于美军赴欧作战统一指挥问题的报告建议。马歇尔认为，艾森豪威尔不是一个参谋人才，而是一个卓越 的统帅。于是，在艾森豪威尔向他汇报这个报告，并提醒马歇尔在发出这个报告前再仔细阅读一下，看是否有某些错误或不当时，马歇尔是这样回答的：“我当然要 再阅读的。但是，你也许是执行这个文件的人。如果是这样的话，你打算什么时候离开华盛顿？”
这就等于说，未来在欧洲作战的美军将由艾森豪威尔来统帅，而当时，他还只是一名新晋升的少将。不仅艾森豪威尔想不到，整个美军、整个美国都没有 想到。艾森豪威尔这个名字对于他们太陌生了。可是，一切偏偏发生了。马歇尔在给罗斯福的提名报告里，是这样解释的：艾森豪威尔不仅具有军事方面的学识和组 织方面的才能，而且还善于使别人接受他的观点，善于调节不同意见，使人感到心情舒畅，并真心地信赖他。而这些品德与长处又恰恰是我们的驻欧洲部队统帅所必 须具备的素质。
就这样，艾森豪威尔超越了366名高级将领(就是说，在他前面还有366名比他资历老的高级将领)，成为美国历史上继潘兴后第二任远征欧洲的统
帅。1942年6月24日，他离别妻儿飞赴伦敦，走马上任了。
咖啡屋的鼠标 写道:
老板放心下属？难。老板放心的下属大都是思维跟他差不多僵化的。至于Agile和CMMI，不懂国外为什么有人搞 Agile CMMI。有了解这方面的朋友吗？几天来用TDD发现，确实很有成就感，虽然做的东西不是多么有难度的东西，但是很明确自己在做什么。当上司问起工程的时候，即便没有做完， 拿出TestCase，他就不得不认可我做了的工作。不会胡乱追究我工作不认真，给我乱盖些什么都没做的帽子。（但是还是会说我做的太慢）
与此相比，我们公司有几个程序员想走人了，因为他们觉得不知道自己在做什么，整天累得半死上边还不满意。上边还认为他们能力有问题，据我观 察他们都是很聪明很有上进心的程序员，水平也不算差。可是上边还是说他们理解能力差、倔。其实传统模式下，信息传递出现偏差是很正常的事情，当上面的话语 不允许质疑的时候，上面的人就会感觉良好，出了问题就是下面的人的问题，其实问题是出在上面。当周一至周五连续加点三个星期之后，需求越来越清晰，刚性的设计造成的后果开始显现，项目进度变慢（当然不是所有人都把它归结为刚性设计造 成的问题，而是归结为程序员水平的问题，尤其当设计者在公司的地位比较高，它们的错误是不容指责的时候），项目的风险越来越大，经理说周六加班，他们说太 累，周六日想加班的时候，经理作思想工作会拿出一些例子说，你看谁谁都加了1个月班了，也没说什么；你看谁谁比你年纪大都加班，也没说什么。从我了解的几 个公司来看，他们都是这么做思想工作的，这里我感觉逻辑和价值观上都已经出现问题了，本来就低效率的工作模式，加班只会更加损坏效率。而且疲劳别人都忍 着，你就得忍着，忍着不说话的人是光荣的，受不了是可耻的，这叫什么逻辑。可是他们觉得理所应当。我们可以看出，传统模式下，很多东西都是一环套一环的，很多人习惯了以后反而你怎么说服他们改变？我相信每个人都是受过传统模式的苦的，可 是习惯了以后反而被体制化了。就像《肖申克的救赎》里的那个监狱，一开始你憎恨它，慢慢你习惯它，最后你离不开它......
在07-4-13，Yiding He <yidi...@gmail.com> 写道：
老 板对属下放心，他就会认真听取关于敏捷的话题；老板不放心的话，他宁愿推行 CMMI。
如果队伍中存在水平不高又没有上进心、不服管教的人，那就头痛了。
--
如果不想背弃自己的灵魂，就必须背弃自己的恶习
－－－－23岁后的人生信条