标题这个帽子可能有点大，放着唬人吧。
公司是做管理类软件来，自己也有幸连着参与了公司几个项目的从需求、开发、部署、交付、维护整个流程，算是过了几遍整个项目的”生命周期”了。发现在项目过程中沟通真的很重要，这个沟通包括对外的与客户的沟通，对内与项目小组成员，于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！
其实你会发现这已经不是普通意义上的项目实施了，这是一次很好的咨询实战。
写的不错，上下期商学院吧。不过有点泛，要是能把整个项目实施过程中暴露出的问题，产生的影响，下次如何避免写清楚对大家都会有收益的。
@leo:
只是稍微泛泛的总结了一下，各个细节上的东西还没来得细考虑。