公司是做管理类软件来，自己也有幸连着参与了公司几个项目的从需求、开发、部署、交付、维护整个流程，算是过了几遍整个项目的”生命周期”了。发现在项目过程中沟通真的很重要，这个沟通包括对外的与客户的沟通，对内与项目小组成员，于boss的沟通，也来简单分享下对于这些沟通的理解吧。

你给任何一个公司打电话一般都是前台接线，或者是自动给你转到分机，或者是前台帮你转接过去吧，想想为什么是这样呢？约定俗成，对就是约定！为了建立起良好的沟通的约定，来完成项目过程中的沟通工作，有这么多工作需要做，按照标准的中式思维，我们需要成立一项目小组，这个小组的成员至少应包括软件提供商的项目经理、客户的主管部门负责人（如果是全公司参与的项目，至少需要一个副总及以上级别的人员），为什么需要这么一个有分量的儿人物，很简单，首先，小兵说话没威信，配合起来效率低，很多的事宜是需要领导拍板才能定论的；其次，管理类项目，如果上层没下决心提高管理水平，上再多的软件、系统都是白搭。需要软件提供商及客户各指派一人来充当前台接线，各种资料、数据的转发，各种问题的汇总等。

需求分析阶段

如果把整个项目中的沟通按重要性从高到低依次画出个1、2、3、4…来的话，需求分析阶段的沟通工作无疑是最重要的，也就是1级重要，这一阶段需要反复的跟客户沟通，确认。而这一块的工作又是最不容易的，管理大师们早就总结出来了“管理无定式”，只要有利于提高本组织的管理，能更好的为产出（可能是产品、也可能是服务、甚至还可能是咨询等等）服务，就是一个好的管理方案。而一般的管理类软件提供商（专业的外包公司除外），都会有一个自己的平台（框架），软件提供商会去根据客户的提出新的需求结合市场要求不断的完善这一平台。这样就极有可能出现极具“个性化”的管理方案，不巧的是这个管理方案中客户要求的某些功能对软件提供商原来的平台冲击很大，当然你客户可能认为这是软件提供商的技术不够好。应该说凡是需要在原来平台下定制的项目（产品实施除外）都会遇到方案给平台带来的冲击问题，只是在管理类项目里这个表现的比较突出而已。

也恰恰因为这是管理类项目，处理起来反而更灵活，在仔细了解客户需求后（很有可能客户看到了twitter上那个follower就想要来个审核、审批、审批、申述balabala…），因为客户往往要的不是某个具体的功能，而这个功能给他带来的管理上的提升。这个时候，作为软件提供商需要在于客户充分沟通后挖掘出深层次的需求（当然不能超出项目范围，我总不能给你做个绩效管理的软件，顺带把你的OA也加进去吧？），结合自己在同类其他项目的经验，评估下市场需求：这类功能是不是大家都有需求，都有需求的时候是不是考虑升级、完善下自己的平台；当然如果只是客户的“个性化”，对于这类“个性化”的需求，首先根据自己以往的经验结合自身平台的其他功能调整下，出具一些能来满足客户的需求的解决方案，但是必须明确两点，从管理角度，以咨询顾问的身份提醒他：这些”个性化“的管理办法会对他以后的管理工作带来哪些不便利，系统始终是需要人来维护的，一般情况下回事软件提供商来负责后期的维护升级，明确告知客户因为这些”个性化“的方案会给他以后的维护、升级带来哪些不便利。这样一来基本上能很好的将项目功能上的需求很好的框在自己平台下（如果平台太烂了也就无话可说了）。 记住了做项目不是谁欠谁的，而是大家一起为了达到一个共同的目标，在应对这类问题的时候，软件提供商更多的应该是变换成顾问的角色，提供一些Options供客户选择，同时明确的告诉客户，每个Option的利弊。

一旦跟客户敲定某种特定的方案的时候，作为软件提供商，根据自己以往的经验，分析总结出来可能会带来遇到那些方面的阻力，包括抵触情绪，尚未健全的机制下是否能提供方案中要求的数据等等各方面的因素，跟项目小组中客户沟通，让客户及时完善健全制度，组织培训等来普及贯彻管理方案从而化解抵触情绪，进一步保障项目的实施，同时为客户带来管理上的提升。

P.S.这里的阶段只是为了描述问题清晰，而不存在时间上的DeadLine，需求无法冻结，设计PPT那家伙也没法知道我需要输出演示模板页脚不从1开始吧。所以堵不如疏。

定制开发阶段

这一阶段其实也分很多小的环节，至少表面上看包括功能设计、开发、测试、文档等等，详细很多的理论模型也对这一阶段有很详细的分析研究。这一阶段，按照前面说到的重要性，我理解为理解为2级重要 ，那么从沟通的角度需要会有哪些值得关注的地方呢？

平常跟Boss级别的人出去混饭吃的时候，发现服务员总是第一个就把菜单给Boss，当然这不能怪人服务员势力，为啥？Boss不满意这下顿就不来你这吃了！其他人不满意呢？不会的，Boss能当上Boss多少也有点能耐要是这点小事还搞不懂还Boss个球哦，肯定是能兼顾到大多数人的口味的，可能极个别的儿女对某道菜不满意，也不会说什么，为啥？Boss喜欢，就能埋单(听起来可能不厚道，但不失为一种高效的解决问题的办法)。

在项目不出现大的滑铁卢的情况下，功能设计这一阶段其实是决定你后期实施是否顺利的一个很重要因素，管理类项目实施后，往往都是参与面广，使用人员多，所谓众口难调，这时候需要软件供应商把握住那位Boss的口味了，Boss喜欢你的界面风格，认同你的操作模式，OK！可是在项目没部署上线前，Boss从哪里能看到你的东西呢，功能设计,把功能设计书或小样先给那位Boss看看，有问题及时更正。其实大多数情况下也不会有多少改动，但是这样一来一是客户提前看到了系统的概貌，心里有底，及时到时候交付有问题，也不会超出期望值多少。而且还给了客户修正需求的机会，工作量一样的，双方相对都会比较满意，何乐而不为呢？

开发、测试、文档这个对内的沟通我就不说了，到处都是，只是这一阶段需要软件提供商很好的跟客户沟通让好客户很好的了解项目进度，以便很好的配合实施。

实施部署阶段

这一阶段主要工作是软件提供商和客户对很多的基础数据、信息的整理、确人，最终装入系统。数据的收集、整理这一过程可能会跟很多不同的系统、不同的人来打交道，我认为这些是1级重要的沟通。

一般的管理类软件采购费用都包含实施费的，是需要软件提供商负责实施的，管理类软件涉及到的信息面比较广，数据的信息都比较敏感，举个例子，你把张三的奖金基数设错了，人家工资拿少了，不找你麻烦才怪。 当然这两个例子可能不太通用，只是根据项目的不一样多少会存在这样那样的类似的数据。而这些数据如果错误，会增加很多的额外的数据修改、矫正修改工作量，与其花很多时间来亡羊补牢、莫不如未雨绸缪。

一个建议的方案是（这也是需要项目小组中需要一个有分量的人物的原因之一），软件提供商提供一套规范的数据收集表格，针对各数据相关表格，组织培训客户各相关负责人。等这些数据收集回来后，软件提供商整理汇总这些数据，如果发现有疑问（80%情况下会有一堆的问题），集中安排几天组织跟各相关负责人，逐一确认。确认无误后，从新整理规范这套数据收集表格，装入系统。而这套规范后的数据手机表格，则可以留给用户，作为在地面操作与软件系统中过度期间数据收集规范的一套工具。在这一过程中，其实已经开始对最终用户做一些培训了，接下来需要软件提供商建议客户组织对系统操作层面的学习，甚至可以组织一些考试性质的巩固性练习。

这里比较有意思的是你可能会遇到很多的阻力，很多的客户内部原来灵活的、松散的、至是无记录的数据，因为上了这个管理项目而变得死板、规范，这样前期可能会给某些特定的人群带来更多的工作量，这时候需要再次建议客户组织的理论层面的培训学习，提升管理水平。

交付维护

项目终于上线了，是时候该欢呼了?不，长征才刚刚开始，交付前是需要准备我完备系统维护手册，系统操作手册，后期支持维护表等等大量的文档。还是需要沟通。

这个层面上的沟通，能很好的帮助软件提供商改进自己的产品，发现客户新的需求，从来带来新的Money！

其实你会发现这已经不是普通意义上的项目实施了，这是一次很好的咨询实战。

      群中一个兄弟上来抱怨公司经理不是淫，原文如下：

【3.0】22:52:46
今天又跟经理杠上了，他给了我一个不可能完成的任务，我绞尽脑汁出了个方案，今天开会他自己似乎意识到这个问题，又怕别人说他，吗的，给我个台阶让我下不来
【3.0】 22:53:04
我要气死
[3.5]22:53:20
蹦极不 :53:29
弄死他
[3.5]2:53:33
削他
) 22:53:40
抽他丫的
[3.5]:53:44
瘪犊子玩意
【3.0】深) 22:54:01
吗的，气死我了
[3.5]深com> 22:54:28
鸟人尽干鸟事。。
【3.0】深) 22:56:54
今天我还是心平气和的讲这个不可能完成任务的方案，结果他说的一些话让人气愤，故意说一些达不到的要求，让我台阶下不来
【3.0】) 22:58:30
我根本感觉他是在无理取闹，这口气我绝对不能咽下
[2.0].com> 22:59:09
找台湾的帮派 搞他
[3.5]) 22:59:20
哥们 忍忍吧
[2.0]蜈蚣< 22:59:32
不愿找台湾的  找山鸡也行
[2.0]蜈蚣.com> 22:59:38
都是讲义气的
冥影( 23:00:18
找几个大陆古惑仔
【3.0】深23:00:45
你们的思想太幼稚
冥影 23:00:50
要不 请他吃饭撑死他 ？？~~

        为免去不必要滴麻烦，  去掉了Q好及昵称。   

       根据后面的聊天记录分析， 大概就是经理给了他一个任务，可能是交代任务描述的不是很清楚，然后这位兄弟花了很大力气做出个解决方案，可能是项目日常交流会议上，将这个解决方案列举了出来，然后又不是经理想要滴，然后就有了上面滴话语，先不讨论这位兄弟是否受委屈了，更别谈后边那些支招滴兄弟了。

          这样类似的聊天每周几乎都能碰到，只是最近看了一些东西，想了一些东西，有点想法，这才斗胆给人支了一招。

[*.*]流氓23:05:31
那你在这次讲解你的 解决方案前 有先列出来他原来的邮件吗？
[*.*]流氓23:05:47
就是他给你指派这个 不可能完成任务的邮件？
【3.0】深) 23:06:01
他是口头说的这个任务，要我整理方案，做拿proposal
【3.0】深) 23:06:15
先拿个proposal
【3.0】深) 23:06:47
他也是一时兴起，根本没仔细考虑
[*.*]流氓23:06:48
这个就是问题所在
没依据，就像你去拿单子，tm的吃完喝完 给你拍胸脯 保证
[*.*]流氓> 23:06:57
结果tm的还是需要竞标啥的一样
[*.*]流氓> 23:07:53
作为一个用脑袋吃饭的人（我一直认为程序员是脑力劳动者）
[*.*]流氓> 23:08:03
你需要对自己的劳动负责
[*.*]流氓> 23:08:16
就是你每次做的工作一定是要有一些用处的
[*.*]流氓> 23:08:37
而不是未来某人吃饱了没事拍脑袋拍出来的乱七八糟的想法
【3.0】深) 23:08:49
吗的，就是呀
[*.*]流氓> 23:09:01
拍脑袋的事情是老板干的，拍完之后实施落实是目前咱们要做的
[*.*]流氓> 23:09:20
这个时候你需要有一个简单的整理需求及评估需求的
[*.*]流氓> 23:09:22
过程
[*.*]流氓> 23:09:49
比如很简单的你这个事情如果换做是我我会这么处理
【3.0】深) 23:10:00
最好有个录音笔

[*.*]流氓> 23:11:10
1、我会记录下来他拍脑袋想出来的需求
2、我会将这些记录mail给当时在场的同事、或者相关人员
3、我会mail中注明我对需求的理解是否跟他的要求一致
4、我会简单的大概评估下我需要多少资源（时间、人力）来支持完成这个需求

5、我会吧完成这个需求的一个风险（比如会耽误我手头上的其他事情）

【3.0】深) 23:11:50
这个办法不行的，你不了解我们经理的为人
[*.*]流氓> 23:11:58
不行你试过吗？
[*.*]流氓> 23:12:05
就算这个办法不行

[*.*]流氓> 23:12:34
如果你前面做了这5件事情

你今天讲解你的 解决方案的时候把这个邮件或者相关记录一列
[*.*]流氓> 23:12:43
他还能难为你吗?
【3.0】深) 23:12:49
我们经理，很自大，认为全世界他是最牛的，全世界是围绕他转的
【3.0】深) 23:13:06
你拿东西，他鸟都不鸟你
[*.*]流氓> 23:13:19
明眼人一看就晓得谁对谁错
如果这个公司不是他的，上头人也能很快都能发现你的能力

       自己刚毕业那会，做的工作很简单，就是每天照着要求Code，慢慢的开始接触一些Code之外的事情，发现以前的效率很低下，看问题的方法也不太对。

       1、刚毕业那会，组要就是拿任务、code。拿到任务后，简单的看看表结构，看看限制字段啥的，开始码代码，往往等代码出来后发现不是头要的，但是头是个很好说话滴人，改吧，改了发现还是缺点啥，只是那会整好项目紧，凑合着用了。

        2、后来开始接触客户，做技术支持，BossJ要求跟客户的沟通邮件或者是电话内容，要通知给其他相关人员查看，目的有如下几个：如果这个事情需要其他人员协助，人家能很好的做好准备调配资源；如果这个事情人以前遇到过，能迅速的帮组你解决；让你的Boss知道你在干活，你在为这个事情投入，Boss才会认可为你发的这份工资；也便于记录日常客户常见的到的问题，给以后做相关工作人员一个参考。

       3、最近一段算是负责项目吧，当项目/工作需要困难，或者是进度可能要拖后的时候，尽早的通知厉害相关人员。对客户，降低客户期望值，也为后期如真的拖后进度沟通做铺垫，用BossJ的话说就是别把自己堵墙角有时候；对内，能给大家一个目标，建立起责任感，让大家都朝着这个目标去使劲。

        没啥技术含量，纯属扯谈，如有雷同，绝对偶然！