好的修改或者说变更流程应该是什么样呢，我想随便翻开任何一本软件工程的书籍你都能看见大把的建议和介绍，我在这不像重复那些陈词滥调，因为在我看来那些东西根本没什么意义，如果一种方法可以奏效就不需要一而再再而三的被强调和推进，只有那些从基层就被深深抵触的东西才需要强有力的灌输方式呢。在我的心里，好的沟通方式只有一个，那就是从实际工作中脱胎而出的，简单的说，就好像我们一开始不设置草坪上的路，然后让行人们自己去踩，最后被踩出来的绝对是大家都最喜欢的路。当然这个踩路的过程是个痛苦的过程，不过好在是内部项目，最坏情况也不过完成延期，不会影响公司总体收入，更不会有人跳楼。

在这个建立流程的过程中，那些软弱的程序员会被赋予更多的工作，我猜他本身可能就喜欢这种工作，有些书建议均衡工作量，我一点不支持这么做，如果一个人喜欢承担工作，并愿意助人为乐，我们就应该给他表现的机会，这是一种人尽其用，但是要在这里告诉他的是，一旦工作忙起来之后他如果不能保证这个时间，那么可能没有更多人会帮他，说这话的时候要委婉，但是要坚定，因为这样才能避免某人一时心血来潮赶出匪夷所思的事情，当然，话说回来，即便如此还会有人义无反顾的去响应内部客户的电话，那就随他去好了。

流程的试验期大概有2周左右，实际上一周左右就能看出端倪，有些人不知道怎么拒绝别人，于是被迫干了一些临时性工作，但是随着工作繁重程度的增加，他开始跟别人怒吼，并变得不那么和善。有些人一开始就非常有准备，知道哪些活是主管部门或者直属上级指派下来的，于是按照心理的权重对提出的临时变更需求进行处理。有些人则在任何时候都表现出一副，我确实不知道这个事情怎么做，您能不能通知我领导再让我做的方式。

第一种人可以再以后工作中具有前台豁免权，也就是说，不让他和客户打交道，只需要他在后面踏踏实实做好工作就好。

第二种人是最有潜质的，这些人以后可以专门去常驻客户那搞需求，这样不但能绝对不会让别的部门说出对你部门不利的话，还可以让很多事情事半功倍，一个会说话的人比十个会干活的人在沟通上更有用，尤其是那些有眼色又会干活的人。

第三种人是团队中的润滑剂，太多了不行，没有也不行，这些人的作用很多，比如需要杀鸡儆猴可以用他来开刀，虽然这么说可能不厚道，但是实际上，一个项目经理工作中厚道，并不是必须得品格。