If anything can go wrong, it will.

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

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

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

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

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

因为是个业务系统，首要的一定是客户能完成日常的业务。做IT的多少都有点完美主义的情节，总希望把东西做的尽善尽美，雕琢自己的每一件作品，加上用敏捷这种灵活的开发方式，需求是源源不断的冒，甚至还包括了对客户工作流程的调整。业务中大家比较慎重的就是钱的问题，所以我们还做了很大一部分的财务辅助功能。

业务系统中大家都以为会有明确的分工，但实际上只有Title不同，实际上一个人从头到尾把业务跟完很正常，再正常不过了。这时候就无法将某些特定的操作固化到某个Page上了，因为谁都要做全部的事儿。

还是因为业务系统，用户天天用这个，要求要简洁，操作方便，速度快。可客户的业务调整的相当频繁，客户的客户朝令夕改那是再平常不过了，客户是希望在一个不动的地儿就把活儿干完（这个未经验证，个人理解如此），这种频繁改动给设计带来很大困扰。

站在巨人的肩膀上,方能看的更远

从进公司开始，自己就开始捣鼓各种平台，开始站尝试在各种巨人的肩膀上。

初入公司，搭建用于升级公司论坛和网站的环境，Windows2003的host环境、PHP + IIS + MySQL + DIzcuss。研究dizcuss，考虑数据迁移，升级公司论坛，等论坛升级完成后，不到一个月又开始尝试搭建公司邮箱环境，还是PHP+IIS+MYSQL。这些环境都能成功的应用了，开始编写一些简单的搭建文档。当然后来熟悉了PHP的环境后，开始找一些间的快捷构建方式，还真找到了。

实习的时候需要写一个小的程序，L指定使用PetShop的框架来开发，这开发环境也需要自己搭建，包括SQL+IIS，成功滴完成后，自己还是稍微的记录了一些安装部署文档。

实习接近尾声的时候开始尝试大家使用代码版本管理工具，在L的要求下，着手研究CVS，虽然也是搭建完成了，但是如何管理不太清楚，未果；当然过程中自己了解到可以使用SVN来管理员代码，未深入研究。

转年过来开始跟着头去做项目，换了开发环境，开始搭建Oracle+PLSQL+VS 的开发平台，同时为了测试，又搭建了一些Oracle+PLSql+IIS的测试平台，当然这部分的经验后来应用到了客户部署中。

做完了这个项目后，正好赶上公司接到一个客户意向要来做Exchange的升级，自己又开始掉头学习Exchange的东西，包括微软的AD啊、SeverR2啊、ISA啊。这部分搭建起来的东西还真给公司自己用了一阵。但是自己觉得盗版的东西用起来很别扭，又开始寻找一些Free的产品，正好发现了微软的BizSpark这样就顺手申请了。

紧接着这个项目来了个移动方案，又开始在Exchange的基础上研究如何将Exchange延伸到手机平台，同时又开始学习公司合作伙伴提供的Nokia的Intellisync的手机同步平台，还研究了一下Windows Mobile的这个手机平台，好像还写了一个wm上的短信群发软件，这个平台到现在还有同事在用。

不久又碰上了给一个客户做实施的时候客户的双机负载均衡的环境，公司产品的架构不支持这个场景，又开始研究这个负载均衡的软、硬件环境。虽然最后不了了之。

由于公司Marketing的老有异地电话会议，公司每次分享会总是会有一到两个同事无法参与，自己有开始了解远程桌面分享，远程会议的相关软件，有在线的、有通过Skype的，最后还是定了TeamViewer，授权是非商业用途，但是还是能凑合用用。

由于自己想标准化公司的文档，开始研究Word的模板功能，最后还真做出来一套公司的doc模板，至少现在大家还在用。

自从申请到BizSpark后，公司开始使用其中的ProjectServer，又是一番折腾，这个参与的少，主要是头S在维护。

来到烟台后开始自己带团队，自己需要搭建VSS，相对简单容易，发现异地管理VSS玩不转又开始研究SVN，头搭建完整后，自己有稍微研究了一些权限管理相关的东西。因为需要给队员搭建开发环境，自己又好好的研究了一下公司开发平台的搭建。

学习了兄弟公司的一套管理框架Scrum后，Boss觉得采用这个框架来走开发团队的管理，过程中需要很多的业务工具来支持，自己又开始寻找并学习这方面的工具。

首先制定了使用Visio画流程图的一个规范；其次需要找一些界面原型工具，这块比较了Balsamiq Mockups\rena-Prototype-Composer\Axure RP 5.6，最后考虑到学习成本选定为Axure；再次还需要一个用例绘制和管理工具，参考哦Visio和Rose，暂时还没定；业务模型打算采用表格+E/R来实施。最后一大块也是自己现在正在研究的Scrum的管理框架，决定采用兄弟公司使用的TFS来管理源代码、测试、自动构建、Bug管理、工作分配等，为了更好的展示大家的工作内容，计划使用ScrumDashBoard来做展板，使用CC.NET来做自动构建；为了知识分享，同时为了新入职同时能更快融进公司，决定采用wiki来管理、分享知识。

当然还有很多日常工作中的小软件的使用，比如这个Wordpress平台，用来写blog的windows live wirter== 就不一一罗列了。

自己使用过这么多软件，无疑都是很多人付出很多心思做出来的一些好的作品。站在巨人肩膀上，你才能看的更远。无论这些产品、平台、软件是不是巨人的肩膀，在这个信息爆炸的互联网时代，每时每刻都会有更新的更好的产品出来，如何更好的挑选这个巨人的肩膀，如何更好的整合资源，使得1+1》2的作用是一种在这个时代的必备技能。信息化

软件公司/解决方案提供商进驻到项目中了。从企业角度来收，如果是个业务系统，且是个核心业务系统，一般公司领导表达对项目的预期目标，要求公司各职能部门通力配合，balabala一大堆。从解决方案提供商的角度，一般都放低自己的姿态，努力界定好项目的范围，在项目计划时间表上打哈哈，给自己争取更多的时间，balabala一大堆。最后大家在友好和平的氛围中亲切滴交换了联系方式，就共同关心滴工期问题初步达成了一致。

我就想了，那要开这个会干嘛呢？这不想不知道，一想还真有门道。

作为第三方力量介入进来的解决方案提供商，如果不通过这个项目启动会来展示介绍自己，后期工作还真是不好开展。一来好多的项目，特别是信息化项目，往往都是由一个部门牵头，其他部门可能都不晓得有这么个事儿，通过这么个会议能很好滴让大家知道这么个事情现在就要开始干活了；二来信息化项目（那种给一两个人做的单机版的东西不计入）往往最终的使用者涉及到的面都相当的广，如果不通过这个会议来跟大家见个面，回头突然跑到人家部门，“你谁啊你，我这正干活呢，没空！”现在不一样啦，领导说了要大家全力配合，那就不一样了，虽说没有令箭，至少抓到了根鸡毛吧；三者是能敲定最终需求的人一般都是参与这个启动会滴人，也就是说后期中需求有分歧的时候，好多的东西的确认都是坐在这里开会滴，也就是项目滴关键人物了。

启动会完了，出来个啥？会议纪要总的有一个，毕竟人家领导参加了，会上发言那是旁征博引啊，你得帮人记着，有用的你写上，没用的你也的写上，回头整理出一份文字，交给人客户。这个纪要就有学问了，这个可是日后的鸡毛啊，你领导答应的要求你们全力配合滴！所以大话、空话、套话你的写，八股文里你还的套事儿，会上大家敲定的事儿你的列出来！

会是开了，总的有点啥东西吧，人家两会啥的不是天天报纸上头版头条，广而告之吗，启动会也不能例外。起项目了，对客户而言，那叫从战略高度、着眼全局，结合实际情况、从自身出发，借助高科技手段，努力加强企业自身竞争力，抢占信息化制高点，向成为行业领头羊迈出坚实的一步；从解决方案提供商来讲，成就客户发展自我，客户名录上有多了一个，涉足的行业/领域又多了一个，以后谈市场的时候又多了个例子啊。无论哪个角度，怎么滴也得来篇新闻稿之类的吧？不让上报纸，我自家网站还不能放啊。

由于是就项目交付来培训，说白了就是培训用户如何来使用某套系统，对一些其他客户常见的问题的如何解决，所以整个培训的从课件设计到辅导只有一个目的：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。

培训课件设计

以前也参加过一些其他公司的各种培训、分享，培训讲师的课件大致分成两类：一类上来就是个Guider，然后照着条目往下讲，没有什么好看的图，也没有什么很玄的动画，但是这中讲师讲的内容往往很实在，一开始你就知道他要讲啥，而且该讲的绝对不会少；另外一类是上来就是一堆很玄的效果，然后开始给你讲一堆东西，但是这堆东西每一个你都有疑问，往往你对前一页的PPT内容有一些挑战的时候，下一页或者下几页就会出来答案，你不听到最后肯定不晓得他要讲啥。（可能是参加的少，反正就只是遇到这么两个类型。）

从听众的的角度来看，虽然第一类PPT的设计不美观，但是叙事方式很符合自己口味，因为一看Guider 我就大概知道这个培训是否有继续听下去，或者是继续认真听下去的必要。第二类如果听到最后发现讲了一通自己不关心的问题那就不好了。

这三次培训的时候也试着就头写的ppt提一些建议，甚至还试着建议增删某些地方，这时候会设想自己是前来培训的学员，试着想如何才能了解这套系统，熟悉这套系统，进而利用这套系统来完成自己的工作，来提高工作效率。感觉这个时候不像是在做一个PPT，更像是在设计一个剧本，台上一分钟，台下十年工，果不其然啊。但是往往由于自己对系统太熟悉，很容易去忽视一些基本概念性东西的描述，而在培训现场往往很多的参与者因为这些概念性的东西提出一些意想不到的问题，从而需要再次加深其对这些概念的理解。

现场辅导

公司的项目有个特色：管理类项目，而且还是那种全员参与参与的管理类项目。

而往往负责确定需求的只是某个特定的部门或者某个特定的领导，而这个特定的部门或者领导也不会或者很少的将这些既定的需求去跟全员沟通，或者沟通的不够测地，特别是当调整原来业务流程的时候，参与培训的人员对整体的业务可能不熟悉。在培训的过程中尽管已经给他演示了这个业务流程有调整，但是这部分人中的个别人物还是会有一些不理解，不理解的直接后果就是认为你们的系统有错。如果这时候因为这个别人物会带动其他人对你这个系统的怀疑，一开始怀疑整个培训现场的就开始沸腾，OMG这个培训有多失败可想而知了，这时候我认为培训助理需要做的事情就是“搞定”这部分人，可以试着走到他/她跟前跟他/她沟通“您关于业务部分的困惑我们可以理解，关于这部分的业务问题，您可以在培训辅导后咱们再做一个交流，这里有一份调整后的业务流程图，您可以试着先根据这个流程照这老师的思路先熟悉下操作。”一般情况下，这些极个别人物都能很好的接受你的提议，按照流程图理解，基本都能很好的完成培训，实在不明白的，培训间隙或者培训后单独开小灶，补火！当然如果是刺儿，另当别论。

众所周知，是个系统就会有BUG，强大微软、google还是补丁不断，如果培训现场出现了Bug，只要不是致命的，统一都先跟学员沟通“请您描述下您刚才的操作，我们查询下原因。”同时记录下来，回去备查，修改bug。

对于从操作角度提出一些要求、建议的学员，无论建议好坏，我们需要满足他们的要求“您好，您的这个建议非常好，我们回去再综合讨论下，看能否做一些修改，当然也欢迎您提更多的好的意见。”记录下来，回去跟开发组讨论，需要分析一下提这个建议的原因，觉得好的建议采纳，觉得不好的建议，也要及时给提出建议人一个反馈。

记住我们的目的只有一个：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。

P.S.公司核心价值里的一条就是在正确的时间里做正确的事情，找对了目标，在培训时只有一件事儿：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。

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

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

故事男主角是一个成功的房地产商，一个坐拥某沿海城市八成房地产行业的帅气滴商人。该男主角曾有一个部下李，背叛他，自己另立门户，成立了另外一家房地产公司，且处处跟男主角作对，事事上都要压制男主角。这次一个市政府新开的楼盘，其中赚头自然不用提，两家公司都入围投标。明争暗斗免不了了。

话说又有两人A、B，A、B本为同窗好友，现在各位其主，A为男主角干活，B则是李的左膀右臂。男主角为了了解李的标派A去拉拢B，A则向B说李当初如何背信弃义，如何卑鄙恶劣，不如投靠男主角。B则表示不能对boss不衷，boss对自己如何如何等等。在A磨了一通嘴皮子后B表示考虑考虑。

终于B表示可以考虑A的建议，但是需要100W，现金。A在汇报了男主角后，表示答应。可是在A和B见面滴时候，B没有要A给出滴100w，相反他还带来200w来，要让A说出他们滴标的，说是说出来后200W+A带来的100w总共300w全归A，A在犹豫了一阵后答应了B。

开标会上，李的公司标的仅比男主角的高出100W（剧中这个标的好像是3亿4千7百万），拿下市政府滴新项目。

这个小节似乎要结束了，也没啥好说道的啦，这时候导演安排了一个小小滴转弯。

男主角公布出来的结果是，A的“变节”是故意安排滴，因为男主角故意报了一个很高滴价格，对手为了高过他，就必须出更高滴价，这样就拖住了对方的资金，无暇抽身，而对手滴死穴就是流动资金。

公司是做咨询的，其中有一项课题是战略落地，日常耳闻目儒多少学到了点皮毛，也来小小分析下这个案例吧。

男主角的目标很明确：打垮李。

姑且把这个叫男主角的战略，清除敌人。

为了达到这目标，男主角的找到了李的弱点：流动资金少。

当然这个就是他们的BSC中的财务维度（瞎凑，不一定科学）中的一个指标，就叫减少对手流动资金。

找到李的弱点后就开始执行了自己的计划，计划执行过程也很有意思。

《用间》中有云：故用间有五：有乡间、有內间、有反间、有死间、有生间。

男主角用的是乡间，用A和B间的同窗之谊，派A来拉拢B；李则利用反间，让B去拉拢A；男主角的也让A将计就计中了B的反间计，李果然上当。

这个就是BSC分解下来，利用招标项目减少对手流动资金这么一个指标，完成这个指标有有一些支持性的具体工作，“间”。当然如果要细分的话，其实还是可以分的，比如这个 利用招标项目减少对手流动资金这么一个指标 分解到了市场部，然后市场部又出来个指标 “间”给到了A，可能为了准备这个“间”会有一些协助人员 c、d、e、f等等。

只是胡乱的对号入座，权当娱乐吧，只是前一段同事W说要俺写一篇关于实施的文章要上杂志，自己先练练笔吧，估计后续还会有一些最近跟客户确定需求的相关文章。

      最近在给客户升级实施系统，期间程序用到的是公司产品的3.0版本，期间遇到了很多问题，使得升级工作举步维艰，一方面有来之数据滴不正确，一方面有原来程序的错误。

      当然这里没有要责怪谁的意思，只是有些现象让我很不理解。主要是牢骚下跟整个产品出来的质量相关的东西。

  1、什么样的软件能够release？

   一个连基本业务都不能跑通的软件可以叫Release版吗？不行。Beta版呢？不行。

   2、如果一个相同或者类似的Bug在一个项目里面出来两次，如何处理？

   找相关人员负责？负责能解决问题，能保障不出现类似滴问题？

    3、如何来管理从一个Bug上报到最终解决整个过程？

    发现了，找相关人员改掉就ok？祈祷别再出问题吧！  日后如何统计，或者日后设计中如何考虑避免这类Bug？ 别来问我，设计人员地事情。

    4、如何知道这个Bug的是否修改完成？

       都交给原来的开发人员自己修改？已经过了软件Hero时代了。谁发现滴谁验收？听起来不错，你能保障你的用例覆盖的够好？

   5、用例是否正确？用例是否合理？

   6、测试人员的安排

  。。。。。。。。。。。

    反正我是想了一圈，这种问题太多了，想不明白。先不管三七二十一，找一个方法来管理这些Bug，来记录这次实施升级过程中遇到的形形色色滴问题。

    首先想到的是做测试滴同学，张同学在一个外包公司做Tester，管她要了个内部文档，日文地，看了半天发现给我的系统不太对路，Pass掉。

    网络，51Testing，形形色色滴工具一大堆，各种管理办法五花八门，对于我这个简单的需求不太适用。

    最后在一个人的Blog(实在不好意思忘记是谁了)上找到了这张图。

         觉得挺对我胃口滴，可是这个也不简单啊。图示容易画，该如何来操作呢？诶，这时候QQ上一个朋友向我推荐开源Bug管理工具BugFree。

         找到他们的站点www.bugfree.cn，下载、安装（这中间还有个小插曲，下载下来的安装包是典型的LAMP：linux+apache+mysql+php,捣鼓了半天，才装上）。

      上周五，组织了两个人帮忙在系统上测试了一番，感觉确实能很好的满足我现在的需求。

      今天早上我又安排给大家分享了下如何来使用这个BugFree，如何记录管理好Bug。

     使用了一天，效果还可以，就是发现一个问题，大家不知道什么样的问题该记录到这个BugFree上。

      如何记录Bug这个问题是解决，可是如提高软件滴质量呢？

公司开始以系统集成商的角色广泛接触相关领域从业人员，一方面通过合作伙伴（姑且这么叫）DC联系移动视频
监控、移动报表的相关软硬件厂商，另一方面专门抽调人手（员工F）学习客户现有的Exchange平台，了解市面
上的短信平台等，并委派其为移动方案经理。

历时一个月先后接触了移动视频领域2两、移动报表一家、短信平台3家、Exchange的相关软件代理商3家。跟一家移动视频领域的企业StarV建立了合作关系，也搭建了一个简易的Exchange的演示平台。针对客户的四点需求提交了一份简单的方案，主要包括一些大的框架性的东西，主要讲解了每点需求该如何实现，并起了一个很好的名字叫移动商务管理。将方案提交给客户后，客户总体上很满意，但是觉得方案整体不够细。

历时半个月开始细化方案，但是一涉及到具体的技术细节，像 Exchange环境的Front-End架构、像ISA的防火墙
功能、像移动报表如何与现有业务系统结合、像短信平台的技术指标对联通移动的支持、像数字视频信号如何转
换成模拟信号、像手机端如何点播视频文件等等，没实际操作过相关产品的F显得很无助，但是还是在Boss J的
压力跟大力支持下提交了第二版方案，第二版版方案中直接将公司一开始要推的Nokia的 PusMail 换成了Exchange自带的PushMail，F也搭建了基于Exchange的PushMail演示环境。

这一次客户相关部门的负责人来到公司（可能有来公司考察的意味），在公司的会议室Boss J给他们讲解了第二套方案。客户明显对提出来的邮件整合、短信平台、移动报表三块没多大兴趣，倒是对那个移动视频兴致勃勃。Boss J明显已经觉察到了这一点，但是一贯的积极坚定（一个很好的习惯）促使他继续朝着很好的方向努力。客户回去后，不久就来Email告知移动报表这个老总暂时又没这个需求了，而短信平台集团将会搭建，届时将会利用集团的平台。

Boss J带领F继续照理于完善Exchange的邮件整合和移动视频，过程中了解到客户直接找到了已经建立合作伙伴关系的StarV，StarV的经营模式是不做最终客户。当公司递交完第三版方案后没几天，客户相关负责人电话练习Boss J,“很遗憾，邮件整合这块您的方案不够细，我们已经将这部分的工作交由一家专门做这个的公司来负责；倒是咱们的移动视频这块，希望能看到演示效果。”Boss J还是试图挽回这个局面。事后BossJ和F才发现提交的关于邮件整合的部分，确实明显的很不专业，虽然F的演示环境就是按照提交的方案来做的。

客户随即提交了几个文件过来期望看看在手机端的效果，F联系Starv的负责人员，解决了客户手机端观看设置等相关问题。之后Markting的就一直咬着移动视频这块跟客户周旋，期望能早日签单，不幸的消息再次传来，客户希望通过投标来找到合适的方案来升级现有的监控系统到移动视频监控。

更不幸的是Starv告知，前期提供的解决方案中用一个设备，而该设备的提供商H也将参与竞标，在StarV的联系下Boss J 跟H、Starv的相关负责人进行了一次会晤，觉得我们基本退出竞标，但是处于客户关系维护等考虑，公司将继续参与投标，并与H合作帮其挤掉其他竞标对手，标书上技术方案由H方提供。Boss J将这个情况告知F，让其将工作重心转移到其他工作。

事情到这里原本该结束才对，谁知H半路摆公司一道，技术方案明显晚于约定时间提供，给过来的技术方案完全违背公司最初给客户的推荐，而且方案本身十分简陋，基本就是一个根本拿不出手的东西，F只好将以前的方案拿过来，撇开手上其他工作，全力以赴制作标书。

唱标现场，H又给公司下了一个套：客户要求唱标内一个礼拜搭建一演示环境，而H相关负责人说是提供给公司的方案中涉及到的设备最短的采购周期需要一个礼拜。客户的口气明显很不客气，缺乏临场经验的F面对这一突发情况有些紧张，将原本准备好的讲标中一些出彩点给遗漏了，甚至还有明显的前后矛盾之处，好在公司是第一个上去讲标的，在场的几位客户负责人还没能反映过来。

而很不幸的是我就是那个专门被抽调过来的F，而万幸的是我在这一过程中学到了不少东西。描述过程中尽量采用了第三人称的视角，但是还是有些个人感情色彩。

关于过程中学到的东西，下篇博文将会做个小小的总结。
To Be continued……