该帖子同步发自：(fayjie的博客  访问该博客)

　　从很多软件项目实施顾问的角度看来，软件项目实施过程往往是制度化的，呆板的，程序化的。而且项目实施管理中使用的工具体现的数字也是僵硬的，甚至是冷冰冰的。此外项目实施管理的P(性能要求)、C(劳动力成本)、T(项目时间)、S(项目的规模)四个要素相互掣肘，这让每个项目实施管理者在不断的权衡中再次不断的权衡。毕竟性能低下，或者成本超高，或者延迟交付，或者项目的规模总是处于变动，都不是每个项目实施管理者面愿意看到的。但是无论我们是如何的谨慎，C=f(P，T，S)或者C=2P+3T+4S都只是理想的状态。这些变量值我们永远只能估算，精确的表达式谁也无法知晓。

　　其实相比于无限追求贴近项目完美标准，莫若能够在控制与精确间达到平衡。一个良好控制的项目，虽然过程中也难免会出现各种各样的突发状况，但对波动与异常的管理，也能够帮助我们保证项目的正常运转，而在这种变化中，其实也是有许多快乐的过程。就像舞动的步伐，沿着既定的路线行走，难免会跨过路沿，或者停留，被路边的风景所惑。我们所要做的就是尽可能的不要与目标的偏离值太大，然后继续进行下去。

　　自己的接下来我来分享我自己在做国内的一家著名手机厂商的SRM项目中的快乐体验。

　　沟通的快乐

　　项目实施管理中的沟通既包括团队内部的沟通，也包括跟客户之间的沟通。

　　内部沟通中我们只要做到让我们的项目成员了然如心的确切知道我们当前已经做的哪些工作，还有哪些工作即将要完成，完成的时间，谁来完成和我们当前跟计划的偏离值，如何让我们的工作步调尽可能的与计划MATCH，最大程度的让每个成员都心中有数。我们每天都应该在合适的时候Review我们当天的工作进展，继续明确或者布置明天的工作任务，这样，工作内容明确了，避免了误解，对项目的进展大有裨益。团队的合作本来就应该是快乐的。

　　外部沟通中我们在掌控住客户的需求的时候，我们尽量让我们的客户知道我们每天或者几天内都做了哪些对项目有进展有意义的工作，遇到的哪些问题，我们不妨把一些可能会影响下一步的关键事项提前让客户知道，最大程度的让客户知道项目的进展情况，而不是怀疑自己被游离于项目之外。毕竟客户的关注程度(或者吸引客户的参与)对项目的进展有及其重大的意义。这样，客户也会体验到参与的快乐。

　　分享的快乐

　　每个项目在不同的阶段总会遇到个别看似困难的问题，这个时候我们或许可以分析一下，这个问题对客户意味着什么?对项目的进展意味着什么?换句话说，搬走它会给整个项目带来哪些益处?如果这个困难的解决将给我们的项目带来加分的话，我们可能会多付出一些成本在这个问题上面。不要太计较此时的付出(尽管这些付出要导致我们的成本有些提升)，因为，此时的付出将会在项目的后续阶段得到足够或者超出你期望的补偿。

　　我自己就有一个这样的经历：当R&D决心要攻克一个性能上的问题，且通过努力攻克了这个性能瓶颈，我们在由衷为他感觉到骄傲的时候，为项目的下一步进展感到光明的时候，别忘了一件重要的事情，快乐是需要大家分享的。我们不要吝惜跟客户分享这个快乐，更不能忽略这种分享，因为我们的客户也同时是我们的工作伙伴。

　　向客户学习的快乐

　　每个软件项目都是我们进行实务研究的最佳机会，不需要支付高昂的费用，而会有实践专家们极其耐心的与你一起来分析其当前最有成效的操作流程和这种操作流程背后的业务支撑模式。我们得知原来很多设想或者曾了解过的流程或者新方法原来在这里有着如此生动的应用，此时往往有醍醐灌顶，茅塞顿开的惊喜，

　　综上所述，软件项目实施中尽管存在一些呆板，程序化的内容，但是我们还是可以从软件项目实施过程有许多不呆板，不程序化的收获，如：面临压力时的乐观心情，清晰条理的思维方式，领先的行业领域知识等等，而且这些才是我们真正的收获。