先说一个身边真正发生过的故事，可能大家会对故事情节感觉非常熟悉。

　　一家小型电子商务公司，管理者就是公司的创始人，他有些技术开发背景。因为产品面向海外市场，他也比较关注产品设计与可用性。由于他对自己的技术、设计能力的自信，总是对开发部与设计部成员的能力持怀疑态度，经常插手他们的工作。

　　一次，开发人员就新产品需求、设计文档的要求，提出开发方案A。这位管理者看后，以其经验判断认为不理想，并给出方案B。开发人员觉得方案B有些问题，但一时又没有找到有说服力的例证，无奈只好以此方案进行开发。

　　果然，在开发过程中，由于管理者仓促间所提出方案，在设计上确实存在不合理的疏漏，导致项目出现了一些问题。当开发人员想方设法将问题一一解决后，突然发现，这个DEBUG后的开发方案B，已经变得与他们最初提出的方案A并无二致。

　　而此时，该项目已经严重超期，那位管理者还为此非常不满，认为是开发人员能力的问题导致的。此后，管理者对开发工作的介入变得更多，而开发人员也开始变化，一部分对领导的这种超权行为越来越不满意，矛盾变得更加激化，后面工作中的沟通变得更加困难；另一部分则变得越来越没有积极性，领导要求怎么做就怎么做。

　　刚好看到UCDChina.com中的一篇文章《管理者不应直接参与产品的开发与设计》，感觉说得太有道理了。上面这个故事，可以用来充实文章的论据。

　　其实团队管理者关注团队产品的成败，是非常正常的心态。他们插手设计、开发工作，无非是希望把产品更得更好，动机是无庸质疑的。尽管如此，还是不建议管理者过多的介入具体的开发与设计工作，即使是领域专家型的管理者，过多的插手具体设计、开发工作，也得不到预期的结果，可能对于项目来说，往往事与愿违，由此产生的恶性干扰多于良性的指导，这是得不偿失的。

　　为什么会这样？原因很多：

　　1、因为管理者与团队成员的权重不同，有管理者参与的项目，往往不能非常公平地对待其它项目涉众。尽管，管理者本意是以其对项目的理解和自身的经验，为设计、开发团队提供一些指导和建议，至少也会增加一种思路。但往往事与愿违，管理者介入后，一般会导致所有项目涉众的思维模式，会被管理者所左右，就因为他是团队的管理者。

　　大家想想，是否经常遇到这样的情况，设计、开发人员深思熟虑后形成的方案，经常因为管理者的一点儿质疑，而被否决；而管理者的灵光一闪，都可能形成一个决策，如果其它团队成员想到推翻它，必须经过周密、详实的举证与论述，这本就不公平，对项目也绝对没有好处，这会影响到团队成员的思路，甚至导致他们逐渐推动思考的动力。

　　2、因为技术背景与对项目的关注点不同，管理者与设计、开发人员会处在不同层面，看问题角度肯定是不同的。其实，能从多个不同角度看待产品，这本来是好事，可以把问题考虑得更全面一些。但如果以管理者的角度，去干扰设计、开发中的问题，那就是另外一码儿事了。

　　《论语?泰伯》：“子曰：不在其位，不谋其政。”

　　这句话说得非常好，这不是推卸责任意思，而恰恰是出于更负责的角度考虑。为了便于理解，这里把“位”理解为“职位”。

　　每个职位有不同的职责，职责会影响人的立场，不同立场、知识背景的人理解、处理同一个问题，其结果肯定是不一样的。也许管理者认为自己可以做到“换位思考”，即便如此也是搁靴搔痒的状态，其结果绝对差强人意。比如，管理者明白不能让UI设计师去考虑代码优化的问题，那又为什么自己去犯同样的错误呢？

　　正所谓术业有专攻，专业的工作还是让专业的人去做，那才可能达到令人满意的结果。

　　3、有人说，在IT行业，许多管理者都是优秀程序员或策划、设计师出身，这种领域专家型的管理者插手做具体设计、开发工作，应该有对项目、对团队成员有帮助。

　　其实不然，前面提到的两点问题，对于这样的管理者也依然存在。而且，文章开头提到的那位管理者也曾经是开发人员，本身也是位不错的产品设计师。为什么团队成员在他的指导下，项目进展依然不顺利呢？

　　从事过产品设计、程序开发工作的朋友应该很清楚，这样的工作需要投入大量的时间与精力，这是一个反复尝试与迭代的过程。好的设计与优秀的编码，绝对不是通过纸上谈兵或灵光一闪就可以得到的（当然，这个世界是有天才存在的，也许他们拍拍脑袋就可以把产品设计得非常完美，程序编码也可以没有任何BUG，但毕竟这种天才少得没有说服力）。有的时候，即使写好伪代码，也不能百之百的确保业务逻辑没问题。

　　而团队的管理者，往往事务缠身，他们没有精力（也不应该）深入于其中任何一项具体工作，那样就会犯下过于关注细节的管理大忌。而浅尝辄止的心态，恰恰又是做好设计与开发工作的大忌。这样看来，管理者兼顾设计、开发工作，并取得好的结果，根本是一项不可能完成的任务。

　　当然，领域专家型的管理者是可遇而不可求的，他丰富的经验与思路都是对团队成员有帮助的，但仅此而已，具体的设计、开发工作还是应该让设计师和程序员来做。

　　基于上面分析，如果管理者仍执意要插手设计与开发工作，就必须保证自己的观点（或决策）是100%准确与全面的，这样才不会对项目有负面影响。

　　当然，这样的要求是不合理的，也没有人敢做此承诺，所以，管理者们还去做好本职工作吧，那里才是发挥你们特长的地方。好的管理者，要懂得放权，要对团队成员应该有足够的信任，相信他们的工作能力，也相信他们的工作态度。正所谓：用人不疑，疑人不用。

　　如果管理者实在想参与设计、开发工作，那就干脆转行吧。