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

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

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

类似的问题实际上还有不少，比如修改完用户密码后是应该保持客户登录还是应该跳转强制重新登录？那现在软件质量不好，到底不好到什么程度呢？那基于现在这个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个月，我们团队从无到有，从小到大，大家都付出了很多的汗水、艰辛，也体验了不少的 困苦、沮丧，我们大家一直是抱成一团，一直在践行咱们的核心价值：快乐协作、目标清晰、勇于担当、行动迅速、沟通昌达、结果满意，不断坚持敏捷、不断地尝试、不断地地改进，克服一个又一个困难，迈过一个又一个的坎，一起收获着流汗的快乐，沮丧后的希翼，成长中的欢悦。

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

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

职场里，特别是初入职场最怕的学不到东西，没法往更高处走。所以各大企业开始校园巡讲的时候总是会把无条件加班之类的东西包装成，会有充足的挑战在等着你，把起步价薪水过低的情况包装成会一个良好的职业规划，而不用去计较那3-500的薪资差异。不过为啥从来没有一个企业说可以在这点上即给充足的挑战又有良好的福利能跟员工达成双赢呢。最近帮老家亲戚的小孩看工作岗位，牢骚下而已，扯远了，回到正题。

公司采用Scrum的方式来开发软件，这个过程要求所有的短平快的产出以便能跟用户交流，收集其反馈然后进入迭代改进。

由于前期人员到位不及时，各个角色人员都缺失，很多不建议重叠的角色都重叠在自己身上，整个开发的效率很大程度上取决于自己的产出效率，特别是设计这一块。设计出不来活，自己就会投入工作的60-70%的时间去做设计，这样整个项目的需求及进度反而没人管了，恶性循环其结果估计好不到哪儿去。

话说“穷则变，变则通”被逼急了没办法了，我需要更多的时间来关心需求、关心整个项目的进度，所以我做了一系列艰难的决定，这其中就有我要将设计降下去，我要抓大放小，大框架我搭好后，细节的交给开发人员自己来做设计。

决定既然是艰难的，那执行起来肯定不会顺利到哪儿去。现在还在执行中结果如何暂且还不知道。

想想这个过程其实也蛮有意思的，以前自己总觉得什么事都需要自己过一遍才感觉放心，需求、设计、甚至还会去看看大家些的sql语句，往往看到的都是过程，忽略了对结果的关注。感觉自己总是试着去当一个babyset，总以为自己会比别人做的更好，搞得自己很累，大家也不见得轻松。

倒是这个艰难的觉得让我开始轻松起来，我有更多地时间去做需求，去细化故事，没了设计的先入为主和羁绊，拆分其故事来可能会更简单呢。也能将更多的时间投入到进度跟踪，团队建设和其他的管理工作中了。

反过来看看被我决定的那帮兄弟，刚开始接手那肯定是非常非常难受的。因为以前啥都做好了照着文档干活，到现在你必须自己绞尽脑汁的不停的思考为什么要加这张表，这个字段我不加行不行，还会时不时的扎堆讨论某个设计实现是否合理，虽然在这部分上花的时间明显多了，但是开发起来却更得心应手了。我相信在这个过程中，他们肯定也掌握了一些比单纯开发更多地技能。从长期来看，无论对公司还是个人，我想这可能是某种意义上的双赢吧。

接下来我要做的就是规范设计流程，制定评估标准，以便更多的开发人员能完全的掌控驾驭在现在的框架下设计实现某些功能。当然还有更多的艰难决定去让更多地人觉得难受…

最开始，客户主管会计说她需要需要一个财务轧帐功能，需要按月查看应收应付、实收实付、预收预付情况。我们就按照各需求给客户做了轧帐功能。

做完之后给客户现场演示，他们也认同了这个功能，觉得是他们想要的功能。演示完后的第二天这客户的主管会计电话过来沟通。说需要按照不同的业务类型来做轧帐。当时我正在做一些其他功能的设计，只是简单的记录下她的要求。

今天她再次电话联系我，说给我发了个邮件有一个她期望的界面。我当时心想真是个好客户，都直接把UI 给我设计好了。后来一看还真是有那么几分样子，Excel里列举出了他们所有要求。

后来一细看原来他们的要求是前后矛盾的，就预收预付这一块，一开始客户是要求按照她什么时候录入系统来做完实际业务预收预付的时间。可当她自己开始解释自己设计的Excel表的时候发现原来她们还需要一个转凭证的功能，并且按照凭证时间来做轧帐。

这个过程本身很有意思，也让我开始慢慢开始尝到Scrum的甜头。我很庆幸我没有马上去动手设计某些具体的UI或者DB，没有一开始的就埋头很细节的东西，而是等到另外的时间来做一个讨论，而且这个讨论时客户发起的。

觉得这个事儿跟某些大家常说的“生气时不做决定、高兴时不做承诺”很像，不在兴头上胡乱做决策。因为这时候往往会不自觉地屏蔽掉很多的其他信息朝一个死胡同去走。

首先是试着将一些很大的Story切割，切割成相对较少的、有商业价值的故事。为了这个Boss还采购了很多书，业界比较响亮的《用户故事与敏捷方法》也被买回来了，可惜我自认为没到那个境界，翻译版的读起来特别别扭，看不下去了。找了些其他的资料，参考着小范围内的重写了一些story。

然后根据上几个Sprint的观察，发现沟通是很很多不畅，大家的理解不一致，又开始加强在沟通环节的投入。但实际上效果都不好。

而今天的一次重构，好像让我发现了问题的根源–我们开发本身不够敏捷。现下已经完成的代码里，任何一个修改，都会带来不可预知的灾难。因为我们根本没法在每次交付的时候保证自己完成的东西是否已经满足既定的需求，更别提按照敏捷的思路来进行迭代了。

敏捷本身是要去快速交付，快速完成可以工作的软件。起码交付出来的东西必须可以工作才对。无论如何去剔除故事，捡业务里面相对简单重要的故事来做，需要满足客户的需求这个终极需求不会改变。如果每个故事或者开发的task本身交付出来就无法保证正确性，又何来在其上的调整完善呢。

或许敏捷在task级别或者编码级别对开发者的要求要比瀑布的高，还是我们的team压根就还没上路？

最近对项目进展缓慢我个人觉得有两个原因。

1、 开发组的技术能力 可能还真的没达到可以实施敏捷的水平，或者是没能达到很好的发挥敏捷益处的水平。

2、 咱们目前三个组的配合上和衔接上也有一些不协调的地方。

目前对于第一点，我觉得暂时没啥好的解决方案，只能不断的提高大家的技能水平。

但是对于第二点我倒是有些想法。就是对原来我们做的那个领完任务然后开始给设计讲解对需求或者设计的理解来扩充一下。

我觉得要强迫大家多思考，然后再开始做，思考的过程中需要包括对风险的评估、对自己业务范围内编码设计的评估，那怎么来强迫呢，最简单的就是将给别人听，给别人讲明白了。本来我们就需要大家都来理解业务，来挑战设计，以便以后能将设计降到每个小team里。

因为每个sprint都需要来分组，我就想在原来讲个我听的过程稍微扩充一下，讲的过程中带上一些实现的思路，让另外一个组也听听。这样至少两个组都能了解业务，对他自己遇到同样或者类似的场景，可能借鉴或者参考对方组的思考方式。但是昨天跟@P讨论时候又有一些新的想法。就是在两个组互讲的基础上，再往外扩张下。将测试和框架拉进来。

本来在开发拿到story或者任务的时候，测试会根据他们的理解编写他们的用例或者测试点，这个测试点是否合理从现在测试对业务的理解还不够，还需要跟设计和业务人员做一个确认。这些测试点往往都是业务上的比较容易漏掉的部分，者用例某种意义上是需要开发特别注意的的地方。

这时候我想能不能让开发和测试再做一个简单的沟通，开发组能从测试的角度去理解业务，可以在自己编码时针对一些测试或者从业务角度需要考虑的问题上多下工夫。

因为前面有想让开发的来讲解他们的一个简单的实现思路，这时候如果框架能稍微帮着把一下关，我觉得又能提高一些效率，框架组可以利用他们的经验，来做一些指导，同时也能事先的理解一些现在看起来很低级的错误或者不好的实现是怎么产生的，看着能不能从框架角度来屏蔽这些问题。这样就能把现在框架的被动等待问题，反过来提前预防问题。

框架参与的这个过程，可以试着从一些开发没考虑的角度来对开发的实现思路做一些引导性的提问，这个过程可以将框架的思维方式慢慢的传递给开发组，也是一个提升开发组能力的方式。

基本的思路就是，业务已设计为头，设计是否合理可以大家都有一些讨论，框架对技术把关。

距离带来的效率

一般我们都会安排一些时间到客户的office或者会议室讨论一些大的需求。在预计的时间内，很难达到想要的结果，往往会超时，效果一般还不理想。而当我通过电话或者邮件来确认一些问题的时候，往往会更高效，甚至更发现问题。

好像非面对面的沟通反而效率更高了，后来我想想可能是大家在非面对面的情况下有更多地空间和时间来做思考，然后决策需要那种结果。

选择题

有的时候客户要实现某些个业务需求，但是往往又不清楚自己到底要一个什么具体的实现方式，我们就会试着给客户设计几种解决方案。然后我们挨个给客户讲解这些解决方案，客户往往会按照我提出的顺序，选择在中间（如果只有两个选项，一般会选择最后一个）给他介绍的一个解决方案。

晚上google了一番，发现 心理学 里好像有专门讲这个的东西，周末再看看吧

起这个题目是源于一个以前看过的美剧 Fringe ，讲述的是基于时空重叠理论下两个宇宙，一些对公众而言很前沿、很新奇、离奇的案件。正好我们的项目是全新的队员，用的是全新的框架，全新的控件，连我这个PM也是全新的。

团队初建，一人多角再正常不过了哦，因为推不出去。

客户需求最熟悉的人肯定是最适合来做设计的。这时候没法管你是不是新手，该上路你就的上！上就上吧，到了路上再说咯。恕不知，这路不是乡间小道，而是高速。

熟读唐诗三百首，不会作诗也会吟啊。新手上路了，不会漂移还不会1档啊。现下就碰到一些由这个新手引发的这样一些问题。

就一块1024*768的地儿，该怎么折腾你看着办。没啥好折，先搬以前的东西往上套吧，套出来好不好看，先一边凉快去，把活干完再说，什么！1024*768塞不下了，不够地儿？贴膏药上tab。一个声音出来了，tab太复杂了，简化 。没辙，好吧，再来个1024*768….这么一分,人客户不干了，我没事要跑几个1024*768哦，改吧。那还是贴狗皮膏药吧，给你个tab，切换吧。

搞过几次1024*768这块地儿后，这个新手就开始喜欢上贴狗皮膏药了，贴来贴去，开发的不干了。

开发：“你以为狗皮膏药真像你画的这么容易贴啊，你这么贴我搞不出来哦。”

新手：“兄弟我就要结果，怎么搞你看着办吧！”

开发：“$#@!$#$(&(&),框架组，这个控件不好使，我都调试一天了，出不来设计要的效果啊”

框架：”稍等，我看看先！”

….

时间就这么过去了2个月。

来了个棘手的活，这丫的要留下每笔操作业务，DB层面设计没招了，新手问了问谷姐，找到了一些设计，发现还蛮不错的链表式的DB设计，在数据库里存着一颗树，也试着演练了一遍，发现这些招数不是那么难，然后就找来一干人等讨论这个招数难用程度，是否能满足业务，讨论后通过！。新手毕竟是新手没能很好的预估这个是个七伤拳啊，好设计伤了自己哦。大家为了这颗树累的半死。

几次折腾下来，team开始焦虑了，因为复炸的设计，让大家无法按进度进行。新手开始要调整了。但是发现上的这条高速是那种不跑到终点没出口的高速，甚至连叉路口都看不到。怎么办呢，蒙头走到黑吧。

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

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

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