团队成员自作主张的思维根源

我们经常碰到这样的场景：程序员没有按照设计师的设计稿完成开发，自主主张对设计稿中“无足轻重”的局部内容进行变通处理。

可能造成的结果：

1）程序员的变通处理是正确的。补救了项目组可能造成的损失。

2）程序员的变通处理是错误的。

为什么会发生这种情况？

一、从程序员的角度看

1）程序员认为设计师的设计不靠谱，并坚定地认为自己的变通是对的。

2）程序员设计师设计的功能或效果很难做出来，稍微变通一下可以节约很多时间。

二、从设计师的角度看

1）设计师认为程序员没有尊重其设计成果，破坏了用户体验。

2）设计师的设计越来越随意直至变成给程序员参考的草图。设计师认为不论其设计得如何出色，反正自己的设计成果都不会被落实。

三、从用户的角度看

1）我想要的都已经同设计师说了，你们做出来的差太远了，不是我想要的。

2）我懒得再和设计师说了，反正都是白费口舌。

四、从流程的角度看

1）设计师的设计稿获得了团队主要成员的评审吗？设计稿的权威不是设计师的，是来自评审小组的签字，代表的是项目组的公权，不是私权。

2）设计师只是一个工种，负责设计，有设计的评审参与权（甚至是最主要的），但没有评审决策权。

3）程序员也只是一个工种，负责编码，有甚至没有评审参与权（次要的），但没有评审决策权，更不允许其质疑甚至对抗评审通过的设计稿。

问题的根源究竟在哪里？

1）流程不明。尤其是评审缺位。评审是对阶段成果的验收，是将私权上升为公权的过程。没有评审的项目成果是废品，不会得到项目组成员的尊重，不能依赖某个岗位的个人权威建立其它环节对项目成果的敬畏。

2）组织纪律性差。明确的流程必须坚决执行，否则将变成个人英雄主义，做不成大事。必须关注私权向公权的适时转化。私权可以质疑，公权不容对抗。