业务人员和技术人员之前桥梁的角色

在QCon上，和一位朋友聊起了当前自己的状况。

自己现在主要的职责就是与业务沟通，然后一条龙服务，从业务规则制定，到需求分析，设计，开发，测试，后期维护，所有的事情都是由自己来完成。当然这只是针对一个部门，而且经过一定时间的努力，业务流程和系统流程已经有了很好的符合，即便是需求变更，也会在很短的时间内完成修改，而且和业务部门的同事已经建立起了足够的信任关系，在发生冲突的时候，也能够相互理解，商量解决。

但是始终自己还是处于技术人员的一种角色，而非管理角色，而且在业务公司（非软件公司）中，做管理性的角色，就不会是软件公司中的技术管理，而更多地会参与一些行政性事务，那与自己的性格不是非常相符，所以也不希望做那样的工作。

然而，当前这种做法，只能是为一个部门服务，如果为多个部门服务的话，那就需要更多的精力和时间，毕竟在现在的工作过程中，沟通是非常重要的部分，也占用了很大部分的时间。另外，如果说做了行政职位的话，可能就比较难以和业务部门的同事维持这种比较良好的关系了。

由此，朋友给出一个建议，是否可以担任一种类似于敏捷开发中教练的角色，起到业务人员和技术人员之间的桥梁作用，不参与到各种实质的行政工作当中，而又能够从旁观者的角度给业务部门和技术部门的同事提供一些建议和指导。

这种角色的确非常吸引人，我想这样可以：

1. 调节业务部门和开发部门人员的关系
2. 改善相互之间的沟通
3. 避免相互推诿或者踢皮球现象的出现
4. 能够避免浪费，达到精益的效果
5. 在需求发生变更的时候，及早评估和做出足够的准备，从而更好地应对

等等。

而同时对于这种角色的要求会比较高：

• 具备足够的技术知识
• 具备足够的业务知识
• 具备很好的沟通能力，与双方的关系处理的都比较好
• 能够有节有度，不要过多地参与到实际的工作中
• 具备较好的理解能力和分析能力，能够迅速找到问题所在，并及时解决

这样看来，很多方面其实都是软能力，对于这个角色，相比硬能力，软能力的重要性会更强一些。

暂时这还只是一个不成熟的想法，毕竟想要让这个角色融合到公司的组织架构中，还需要很长的路要走，而且对于如何让管理者认可，并有效地对其所作的工作做出有效地评估和检查，也是需要研究的问题。