小企业轻团队大项目: IT经理的困扰（四）：明星困扰
IT经理货项目理可能都会遇到这个问题，某个特别优秀的程序员或者是项目中的主力程序员，太有性格了，经常和你发出不同的声音。尤其是写代码不牛（网上有很多类似争论，项目经理要不要会写代码）的项目经理，可能还会被明星欺负。
怎么解决这种困扰呢？
?
首先，良好心态。
我很欣赏王蒙写的一篇短文《安详》，这篇短文是王蒙写给自己看的，但对每一个人都满适合。里面有一句说到：“安详属于强者，骄躁流露幼稚。安详属于智者，气急败坏显的可笑。安详属于信心，大吵大闹暴露了其实没有多少底气”。这句话说得很好。IT经理首先要具备的心态，就是安宁、平静、沉着有定。
有时候沟通就像登天一样难，但如果心态好，爬楼梯还是能看到美丽风景的。
?
如果你尊重你的程序员，如非得已，尽量不要采用冲锋式的开放方法。鼓励激情对于销售团队也许有用，但对于程序员，更多的应该Leading Quietly。当你见到明星程序员高声说话的时候，不要先入为主认为他在挑衅你的管理权威。回避正面冲突，然后单独思考一下几个问题：
a. 他是在找茬还是在反应问题？
b. 我觉得不舒服，是否仅仅是因为他音调偏高？或是他当众表达相反观点？
c. 他是否代表了其他程序员的想法？其他人没有出声是否仅仅因为自己不是明星，不敢出声？
d. 我以前是否和他沟通的不足够？
多数情况下，问了上述问题后，你会发现事情没有自己想得那么糟糕。抱着“安详”的心态，世界本身会发生改变。
?
第二，把不同的声音控制在例会中。
当面对质疑的声音的时候，多数人选择了辩论。用语言取胜，得到的结果经常不太理想，虽然短暂压制了反对声音，可能会给下一次反弹积压更大的能量。
所以，我们需要聆听，聆听不同的声音，或者说是给不同声音一个渲泄的出口。
我的建议是：让不同的声音在例会中充分表达，但仅限于此。
传统开发多数的例会，在检讨进度、需求分析、任务调整，也会让大家表达意见。表达意见的环节往往走过场，不同的看法往往在会上就马上被压制。而笔者是鼓励敏捷开发的，大多数需求分析、任务调整的工作，已经面对面和程序员沟通了。在敏捷开发的例会中，花费更多时间在反映问题，提出观点，通常是不同的声音。如果你只有一个明星程序员，这个时候发声的往往只有一个人。如果建立了这种允许不同观点的分为，更多的人愿意表达。而你会发现很多合理的反面意见，不仅仅是明星程序的想法，也是大多数程序员的想法。
大庭广众的反对声音会显得更加刺耳，而私下交流的反对声音会显得更加柔和。例会提供了一个公开发表反对声音的场合，让大家习惯在这个场合发言，而且提倡发言不针对个人。这提供了一个机会，让你可以在会议后思考，或者是与发言人单独沟通的机会。
这种例会很有效，关键在于例会的组织者需要有包容百川的心胸，同时领导力也是不可或缺的。大多数人认为合理的做法，不一定是正确的做法，或者不一定是最适合目前情况的做法。有领导力的IT经理或项目经理，在接纳不同声音的同时，也应该取得团队大多数人的理解，让大家明白为什么要走一条更艰难的路。坦诚的沟通，让每个程序员都明白公司的目标、团队的目标、你的目标，当然还有你的痛苦，都不妨在例会上分享。
这样，用强制或引导式的做法，将不同的声音限制在例会中，而不是日常工作沟通中。
?
第三，用目标控制。
敏捷开发有的时候被认为是目标散乱的，实际上并非如此。敏捷开发的最重要目标就是：满足用户多变的需求，说白了就是最大程度的让客户满意。这一目标，要时时刻刻灌输给自己的团队。做成一件事有n种方法，只有最大程度满足用户需求的那几种方法，才是考虑范围。
这样的原则如果让每个程序员都接纳，不太可能，但至少要让大部分人认同，从而变成团队的目标。
一个明星程序员，有的时候耍大牌，只要不触及“用户满意度”这条红线，都不是大问题。但如果他的任性行为会影响到项目的发展，进而给用户造成不利，那么就需要沟通（比如通过上面的例会模式），面谈等方式来解决。
?
第四，平衡的力量。
如果你发现明星程序员，是对人不对事的，是危害到项目发展的，而且你做出了努力无法改变的。那就要采取行动了：
a. 减少明星程序员在项目中的重要性：包括缩减工作量，负责更少的模块开发
b. 尽量安排比较独立的项目，减少和其他人员的沟通
c. 招聘或内部培养同等能力的替代人员
d. 功能类似的两个模块，可以考虑两个人并行开发，鼓励一定程度的内部竞争和比较
?
在笔者的项目经历中，明星程序员更多是有性格的程序员，理解、包容和沟通，都能使绝大多数问题得到解决。
?
作者:?谭砚耘@用户体验与可用性设计-科研笔记
版权属于:?谭砚耘 （TOTHETOP至尚国际?）
版权所有。转载时必须以链接形式注明作者和原始出处
如果你希望与作者交流，请发送邮件到?tanyanyun/at/163.com?别忘了修改小老鼠
