记得看某个战争片的时候有个龙套（貌似还是个知识分子）跟里面说，下次在阵地上遇到敌人轰炸，就躲到以前的弹坑里好了，因为有数据显示炮弹落到同一个弹坑的概率极低，如果真落到你这个，那你也不用躲了。低到什么程度倒是没说。

这里就说到了数据，有理论依据了。

同样的工作中用某某方法你是性能高了，未来可扩展性也好了，但针对某个场景压根就不用考虑性能，人压根也不需要扩展，你费那个劲儿干嘛哦。那反过来说，现在某个功能上缝缝补补的勉强完成需求了，可能从现在时候是节约时间了，也提高“工作”的效率了，出来混迟早要还的，狗皮膏药总有无不住窟窿的时候，一旦被别人戳破，那真是自找的。这个角度到底是省时间了还是浪费了呢？

类似的问题实际上还有不少，比如修改完用户密码后是应该保持客户登录还是应该跳转强制重新登录？那现在软件质量不好，到底不好到什么程度呢？那基于现在这个Team到底有多大的产能呢？

诸如此类的问题，针对同一个项目中，可能不同工作经验的人给出的答案都不一样，很大程度上基于个体主观的感受来回答。你说改就改啊？凭啥要强制登录呢？你说我这东西不好就不好啊，微软还天天打补丁呢？有种你做的比我快。这类的声音此起彼伏。

那怎么说服各方都理解甚至认同你的想法呢？摆数据哦，针对不同的问题，设计几个大家认同的指标，各个指标都有详细的数据支持。

凡是是不是好，怀又坏到什么程度，在没有数据支撑的时候都是个体的吐槽，摆数据看5分钟，比你没事儿就觉得、认为半个小时要直观的多。当然数据只是结果，解读数据、分析数据背后的原因最后让大家达成一致才是关键。

这里只是说要达成一致，这个一致很有可能还是不对，但是至少team的理解是一致的，即使有难那也是同担啊。一个坑里刨食还互相掐架，累死！

P.S.刚刚给一哥们扎啤烧烤庆生，然后被叫去跟boss聊工作，忍不住想吐槽几句。吐槽，纯属吐槽！

If anything can go wrong, it will.

墨菲定律（英文名：Murphy’s Law），亦称莫非定律、莫非定理、或摩菲定理，是西方世界常用的俚语。墨菲定律主要内容是：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。

项目实施很不顺利，小小总结+记录下想到的解决方法。

项目实施过程中总是试图说服客户将一些问题放到上线后来调整，为此会去做很多工作，虽然当时能让客户认同自己的观点，但是只要系统中有一些不愉快的插曲发生，客户随时会将前一秒的的应承推翻，黑下脸来，给我改完先。

这就是风险，根据 墨菲定律，这还是高风险呢，这时候就是考验PM的时候了。总结下这段时间的工作如果能做到以下几点应该能较好的控制这只风险怪兽。

• 1、内外部信息透明，别藏着掖着，让客户知晓现在的进度、大家的难点；
• 2、给客户的承诺一定要及时甚至超前兑现；
• 3、从业务角度跟客户沟通，试图说服客户能放到上线后调整的一定不会影响他业务；
• 4、管理好客户期望值，房子装修好了客厅是加不了水龙头的，但是要放个鱼缸还是有希望的；
• 5、及时反馈，对于客户提出来的要求快速给予反馈，反馈不等同于立即给出解决方案，及时客户知道提出问题现在处在哪个阶段；
• 6、积极主动，客户提出一个需求，发现系统中有类似其他的他可能会要求的地方，主动告知客户；
• 7、一份简明而清晰的需求汇总及完成表，客户也需要向领导汇报；
• 8、所谓信则灵，这个阶段是否能顺利推进很大程度取决于客户对PM(沟通人)的信赖，所以前面做的事情都是在给客户信心。
• 暂时就这么多想法了，实施完了再补充好。

2011-05-17 16:14:42秒，实现了Pre-Zero-Bug。那一刻我很兴奋，缓缓松了一口气，这口憋了18个月，请大家不要吝啬自己的掌声给自己一些掌声。（张继科）源代码行数：349249，表：147，视图：137，存储过程141，1 77，2 932 ，3 1565，4 164。

我这有一些关于咱们这个项目的故事、数据要跟大家分享，关于咱们这个项目的前世今生。

2009年10月Julian跟我说我们要启动这个项目，11月15日Julian领着我跟Simon来到烟台，我记得那天飞机一落地，好大的雪，当时我就心里一咯噔，一场硬仗要打啊。

来烟台后第三天，我们确定了团队的第一批队员：John、Jessica还有一个Jessica的同学，虽然Jessica不是第一批参与到项目里的哈，但是却是是第一批被确认的人选，很高兴第一批确定的队员里有坚持到现在的。建议为Jessica的坚持给她些掌声。

队伍起来了，就开始攻坚了，大家现在看到业务的输出都是我在做，实际上，这些业务的积累是Julian领着我们（John、Michael一起）做的，从流程图的编制规范，到具体的调整Julian都有参与，那真是个攻坚战，全新的业务，全新的团队，花了2个月左右，完成并提交了流程图，迈过了第一道坎，然后回北京开年会，Julian的体重目标顺利达成，因为累得，不是因为他是领导我这麽说，此处应该有掌声。

做完这个之后，我们进入了设计开发阶段，也是我们第二批队员加盟的时候了：Cherry、Yann、Arron、Lorry、AirLi。那个阶段我们很迷茫，我们面临好多的问题：不成熟的开发框架、业务如此庞杂；框架团队和开发团队分别处于北京和烟台。针对负责的业务，Simon和Julian 建议参照北森引入Scrum；Simon一边负责其他项目，一边领着Alan一起开发新的框架，针对异地问题 4月份Jack从北京过来。这道坎我们又迈过去了。×××（日期）我们给客户做了第一次Demo，客户给我的反馈是肯定的，好多地方容出错，但是我们比较喜欢这个东西。

接下来 我们迎来了第三批队员 烟台女婿 Patrick、烟台土著 Sam、青岛回来的Terry、 和测试团队 上海回来的Rebecca、Sally、北京过来的Milo。我们团队壮大了，解决疑难问题的能力，对质量的控制有了很大的提升。新的问题暴露了，流程上出问题了，设计层面很难保质保量，又请Michael和Jack开始加入设计，这道坎迈的很艰辛。

5-6月期间，我们遇到了软件行当常见的跳票，已然没希望按照既定的时间表给客户交付了，通过不停的跟客户沟通，我们将Lunch时间调整到10月份。

7月13日，我们搬家了，搬进了市长大厦，队伍也越来越壮大，SPT团队为项目开发提供了很多的后勤保障，咱们谢谢他们哈。

这是Simon也从北京过来了，各种框架问题在Simon和Patrick的支持下都能及时解决了，一波三折的Ted也加盟了，使得各种前端问题迎刃而解。我们开始使用TFS管理故事，我们开始将开发团队开始尝试分成两个小组：JJTS，JATG，我们开始尝试团队设计，让大家都参与进来。最多的时候我们可以两周Down掉近100个故事。

这个阶段，工作之外我们团队的活动也日渐丰富了，无论是迟家、大润发还是金沙滩，都见证了我们都举杯开怀身影，烟大、千里马球馆、华安宾馆都留下了我们尽情欢愉的笑声，金钩寨、幸福十六村、华信都还弥漫着我们支锅时的美食。团队间彼此也越来越了解，慢慢消除了一些工作中的不愉快，默契越来越好。

10月，Peter加盟，给团队带来很多业务的分享（Peter的小宝宝就要诞生了哦）。这个阶段我们再次经历跳票，我们开始外出取经，远赴青岛参加敏捷之旅，获取一些经验。我们加强对故事的管理，让团队来做设计，坚持使用燃尽图，大家更关注结果了。

跌跌撞撞进入了年底，大家都在准备计划 春节之旅、都在准备年货的时候，项目组在埋头苦干，为保证1月底上线，我们整整一个月，没有任何修整，直接干到大年28。遗憾的是这次我们铩羽而归，没能得到客户的认可。

铩羽回来，我们重新计划，开始引入MSF，开始调整管理团队，调整管理方法，引入设计审核确认、测试评审等等环节,稳扎稳打。终于经过１８个开发周期，我们拿到了zero-bug。

回头看看这18个月，我们团队从无到有，从小到大，大家都付出了很多的汗水、艰辛，也体验了不少的 困苦、沮丧，我们大家一直是抱成一团，一直在践行咱们的核心价值：快乐协作、目标清晰、勇于担当、行动迅速、沟通昌达、结果满意，不断坚持敏捷、不断地尝试、不断地地改进，克服一个又一个困难，迈过一个又一个的坎，一起收获着流汗的快乐，沮丧后的希翼，成长中的欢悦。

未来的日子里，我们将会面临一些已知的、未知的挑战，我相信咱们的团队能够禁得起挑战，扛得住冲击，大家有没有信心？有没有信心？

这次我们是在昆嵛山上为货运项目 登高庆生，下次我们到 会当凌绝顶、一览众山小 的 泰山上迎着日出 为拖车网庆生，好不好？

1、需求–财务的特殊要求往往是致命的

为生产服务的软件，如果项目涉及到钱，那财务肯定会掺乎进来。在国内财务很多的一些要求都是在业务之外的，这种的要求可能会对前期的设计带来很多的挑战，所以这部分的需求越早识别越好。

2、需求–具体业务操作的需求

生产类软件，用户天天用，越少的键盘鼠标切换越能让客户更容易的接受。

3、需求–软件用户的电脑知识水平

对于一些打字都自会一指禅的用户，请多观察人家日常对电脑使用的习惯，请着重研究人家的真实需求，而不是光听他讲。

4、团队–请用好你的兄弟团队

需要兄弟团队支援的时候，将需求提给他们的头，千万别越俎代庖，因为你永远不知道他们自己的时间会出现哪些变数。

5、团队–请保护好你的弟兄

不要让过多的外来事情打断你弟兄的工作，请让他们在最有效的时间段完成他们最需要完成的工作，剩下的时间留给弟兄们神游吧。

6、团队–干掉信息壁垒

很有必要让所有的弟兄知道所有的设计，信息壁垒会给团队带来很坏的味道，不信任往往就是来源于此，不要迷信外包行业流行的照着图纸施工，那tm就是个扯谈的玩意儿。

7、团队–充分授权

干掉信息壁垒后，更多的就是让弟兄们自己来掌握自己的时间了，只给目标和必要的辅导或者引导，不要试用你手里的权利来遏制弟兄们的创造力（虽然你很多时候是无心的）。

8、团队–适量加压

权放下去了，需要的是目标清晰，但是很多时候大家会不自觉的对目标打个折扣，所以请适量加压，一方面给自己稍微留点空间，另一方面高压下往往会有一些意想不到的收获哦。

为什么说又呢，是指的在项目刚刚开始的时候，那简直是个人格分裂啊，一方面要招人“组建”团队；另一方面需要跟客户讨论需求；最后还得自个儿设计系统。很多时候自己的工作时间都被压缩到了晚上9-11点，这个工作时间就是指的准备需求讨论的内容，整理和调整设计。

那现在又是个什么状态，一方面对于已经让客户见到或者使用的功能需要安排做用户反馈收集的事情，某种意义上还是一个需求收集、识别、拒绝的过程；另一方面还是需要跟“团队”一起完成既定计划里某些功能的设计；最后公司下一年度的计划，本年度的总结，队员的能力评估等等。

最开始这种多线程干活的时候，整个人就是个陀螺，谁来抽一鞭子，我就朝哪个方向转一转；然后等着下一鞭子，然后周而复始。那时正是感觉累死个人哦，只有无尽的疲惫，感觉相当的郁闷。后来被逼无奈，才在每天9-11点来做一些整理前瞻性的工作。那一段自己是相当的闭塞，基本上所有的时间都被项目Hold住了。虽然感觉只有自己一个人在瞎忙乎，但是那一段是对业务学习进步最快的，虽然很累但是真的有些收获，痛并快乐着！

现在这个阶段几乎每天我都会听到有同事喊：“Felix，有时间吗？”几乎每次我都需要从自己的工作（虽然我也不知道我那个点在做什么工作）中跳出来去帮着解答一些问题。但至少大家都能发现问题，说明大家都开始想问题了。然后现在每周都会整理一个项目周计划，将一些重大的（需要组织开会讨论的）事情的时间先行定下来，只能算暂时能将自己的时间稍微理顺一点了。这样能主宰自己的时间的时候是在是痛快，只是还没能达到乐的地步。

下一步要做的可能是去让“团队”所有的人都能主宰自己的时间吧。计划是让敏捷里TimeBox的概念在深入一些，所有的问题不能随时都发起，必须镶嵌在固定的TimeBox里，比如每个小时会有10分钟的讨论，只能在开始的那10分钟。

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

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