回头看看自己的201，30%的精力在项目上，10%的精力在选人，20%的精力在尝试制定规范。5%的精力在做产品规划，剩下的在神游太虚。工作上无非  

财务层面

     很惭愧这个维度的目标未能完成，存款还差的远。总结原因如下:工资有象征性的上调过，但远远达不到自己定的目标；投资上，选择股票这一微观操作上自己不太熟悉的方式，风险太大目前被套牢中；由于有合约不允许赚外快其他层面基本无收入；2011年过于宽松的用钱政策。

社会层面

      只能说曾经saybyeto单身过，可能在感情这个上面自己还是不咋开窍吧，有时候不是你的没必要强求，let it go，顺其自然的好。个人网络品牌建设仍需持续发力，烟台是个好地方，可惜太好了，没人愿意过来安逸下，自己跟网上张罗的事儿顶多也就是个朋友间的打哈哈。知识输出分享，唯一能拿的出手的就算是这个了，基本上做到了知无不言、言无不尽，很热心也很耐心的去跟周边或者远处的朋友交流自己的想法，将自己收到的新的资讯分享给大家，将自己的理解分享给大家。

内部流程

    先说扩大社交圈这个，11年倒是主动去组织参与了一些活动：K歌、打羽毛球、三国杀，后来才发现这tm还只是局限于公司内部这几个人，感觉特别的别扭。好在10.1号召了几个北京的同学来烟台旅游参观。推动公司内部知识分享，这个事儿做的不够彻底，想法很好、策划的不够好，时间过于密集，受众或者讲师都没太大收益。最后weibo、博客等的运营，一直有坚持，坚持记录对各种事情自己的看法、坚持做新知识资讯的传播纽带。

学习成长

    2011年，项目管理的知识可没少学，可惜总感觉在做一些空中楼阁的幻想，做了很多教科书式的规范，不得法们，还是让合适的人来做合适的事儿好了，自己先多学习为主，下半年更多的关注产品管理本身。时间管理这块感觉是个无止尽的话题，最后总算明白了时间管理这个提法就是个骗局，时间管理应该管理的不是时间而是使用时间的主体，自己本身，从提高各项技能入手。知识->技能，11年没少看书、看各种资料，也确实有将很多学到的知识应用到实际工作中，算是略有小成吧。

总结完发现漏了好多东西，看样子BSC这工具我用的还是不咋地啊，补充如下。

1、厨艺见长，3-5个人的小聚90分钟内吃上5-7个菜不是问题。

2、心智变广，很多犹豫不决的场景现在能更坦然的做选择，很多问题能够尝试多角度、多维度的的去思考。

3、乐于助人，原来可能更多的是想去改变别人，为了改变而改变，现在更加改变知识手段不是目的，将自己的知识、经验分享出去也是手段，认真的帮助别人成功无需太多的在乎是否按照自己的方式来。

4、更加自我，虽然认识到了很多事情不是那么简单，但是还是会一意孤行。

5、懒上加懒，虽然想明白了很多事儿，但是越来越懒得整理、整顿了，更懒得将一些很规范的东西付诸笔下，反而更喜欢口头交流。

…

总之，2011，有点小浑浑噩噩、有点小收获、没啥建树…

读万卷书不如行万里路 行万里路不如阅人无数

阅人无数不如名师指路 名师指路不如自己领悟

第一次听到完整的这段文字是还在北京，当时公司组织一个分享会，请来了一位BossC的挚友，整个场面Hold的是相当好啊，到现在，他讲的东西我都没记住，唯独记住了这段话。年前自己做PPDF的时候在这句话基础上改了改：虽说名师指路不如自己领悟，如果资源允许还是希望能多参加下行业的交流培训类的。

之所以想起这段话源自昨晚开完会跟Boss去聊天烧烤，收获不少，有些东西急不来，比如经验又比如情商。大抵没几个人会轻易承认自己智商或者情商低，但实际上人与人之间肯定会有很大的差异，不管你承认与否，有句熟话 狮屎胜于熊便。

做过或者尝试做一些管理类工作的人，应该都会发现，龙生九子各不相同的现象比比皆是。

从企业角度永远都是追利益最大化，也就免不了会去设置各类的目标，要达到某个结果肯定或多或少会困难重重，在获取这个结果的过程中，从结果导向出发，主导或者参与这达成目标的过程中的个体不触及底线（各种清规戒律）的前提，使用何种方法都OK，交出合格的答卷才是最终目的。因为企业请回来某个人就是为了解决问题滴，如果你不能解决岗位要求的问题，Sorry，Next！

只要是智力输出类工作，最难管理或者最难把控的部分就是人。关于如果去管理这类工作的方法论、工具随手问问谷哥度娘之类的没有一千也的有八百，可真正等自己需要管理类似的问题，或者自己处于类似问题中的时候这些东西就有点像，放在隔壁间的厕纸。有用，但是没法立马擦干净您滴屁股让您立刻该死滴厕所。

昨天学到一招就是，针对不同的课题设定合理的期望值采取不同的辅导措施，举个简单的例子。

又到中秋时，公司需要做一些客户关怀的活动，根据客户资料以及以往的一些沟通记录，继续与保持一个良好的客户关系。有两个人可以（同一岗位）负责这个事情：小A工作多年，经验丰富，沟通能力良好，成本5k…小B刚毕业，脑袋瓜灵活成本，成本3k…对这两个人就需要设置不同的期望值，对于小A只需要给他一个目标时间点剩下的就等结果就好，可能会期望这个活动做的有亮点，最好有客户能主动反馈谢意；对于小B，可能只要求不遗漏客户，保障每个客户都能收到信息，甚至还需要帮忙指导如何制定方案监控执行过程。

当然这个例子可能不够丰满，缺少的太多，基于那些考究觉得小A能达到这目标，又基于那些考究可以让小B来做这个事儿（往往这个才是设置期望值的关键）==== 这里只是简单的描述，说白了就是为了举例而举例。

为什么呢？如果还需要想辅导小B这样去辅导小A，那从公司角度留着小A干嘛呢？直接换成小B不就完了吗？

那自己安排任务的时候到底谁是小A谁又是小B呢？反过来说，自己在接到一些任务的时候，也需要考虑下，boss对我的期望值是小A还是小B呢？每次遇到难题的时候该怎么处理，毕竟自己坐在这座位上的唯一原因就是能给公司带来贡献，如果遇到问题就张口、如果事事都需要去问别人该怎么做，我留下来干嘛？是否可以换一种思路，把困难罗列出来，针对每一点想出来一两个方案，自行筛选出来一些方案，跟boss或者别人讨论跟多的是在一些自己拿不到主意方案的原因，而不是上来就怎么解决这些问题。

工作如此，其他方面也该如斯。任何事情都该给自己设定一个期望值（可能毫不费劲就能够到，也可能蹦一蹦才能获取），只取决你在自己的人生中是想做小A还是小B而已。那达不到自己的预期值的时候该怎么办呢？

写完又想到另外一个困惑，到底是因岗位招人还是因人设置岗位职责呢？

3年过去了，现在想想《士兵突击》可能是我看过的很好的电视剧中的唯一一个了，于我而言不仅仅是一部电视，在享受那种略带YY的男性激情的同时，教会了我很多。

记当时自己曾写下“铁打的营盘流水的兵，或许那天也会有人收到我应‘个人原因’离开，至少在离开前 像随时要离开一样准备好，像永远要留下来一样用心。”

古龙的七种武器中有一个是离别钩，自己特别喜欢他的介绍："为了相聚的离别"。

刚刚从一个同事的非官方离别晚宴上扯下来，心里虽然有些许的失落：从Team的角度，某个队员决定要离开，我相信从大家的角度肯定是经过深思熟虑的。

说的是世俗点，Team能给大家带来的可能就是：1、升官；2、发财；3、学会升官发财的本领。无论是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个月，我们团队从无到有，从小到大，大家都付出了很多的汗水、艰辛，也体验了不少的 困苦、沮丧，我们大家一直是抱成一团，一直在践行咱们的核心价值：快乐协作、目标清晰、勇于担当、行动迅速、沟通昌达、结果满意，不断坚持敏捷、不断地尝试、不断地地改进，克服一个又一个困难，迈过一个又一个的坎，一起收获着流汗的快乐，沮丧后的希翼，成长中的欢悦。

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

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

《野蛮生长》是冯仑口述，然后别人给他出的一本书，在网上断断续续的翻过几章。树虽然已经被保护起来了，但还不至于濒临灭绝，至少我到过的地方还是俯仰皆是，整好GR里看到了 像树一样成长 这篇博文。

前几天的某个下午，一帮大学同学在群里闲聊，我又成了讨论的标本了，普遍都认为过早的接触了太多面，看起来好像啥都会点，但是都一瓶子不满，半瓶子晃荡，绝大多数地儿还都是个空瓶子，但是心气儿已经老高老高了。想想现状也对，现在会的那半吊子活，跟谁拼，谁都不屑鸟我，谁都比我牛！

感谢那帮兄弟姐妹这么透彻的剖析，这年头锦上添花的太多，在冲昏头脑的时候给盆凉水的才是好人啊，扯远了。

想想潜意识里一直不安份，喜欢新鲜的环境、新鲜的事儿，工作不久，倒是做过很多不同的岗位、不少的尝试。快毕业那会儿，不晓得在哪里看来的鸡血文章中说国外一个商界成功人士（记不得人名了），在大学期间将所有的课程的入门课都去听了一遍才最终选了专业。可惜那会我的大学已经渐行渐远，只能在职场上尝试了。

世俗中人免不了俗气，需要一份工资来苟延残喘，能力范围内的也就是IT周边了，所以找了家能够围着IT内部换着干的公司，也算是在践行这个 树 的理论了。一通干下来，基本半年换个岗或者半年换个工作重心，加上骨子里那点不安分做的事儿，接触到的东西五花八门，真正沉淀下来的干货却寥寥无几，不对，是没有。

毕业的时候给自己写了张卡片，只有几个字，“25、30、…”卡片早在几次挪窝的时候不知去向了。25 指的可以让自己 放浪形骸 到25岁，允许自己不断的去看去学去试，但是到了25title后面必须挂个Manager，必须能独立运作一些东西，结果这个破目标毕业第二年就tm实现了；30是指的30之前作为老娘的儿子的我不会去太多的考虑个人问题，但是必须有一份让我30之后不纠结、不再乱试的事业；…是我TM当时能想到的就到30了，牛奔如 马总 的人才想那么远呢。

25过了一半了，是时候想想那个让我到30时候不纠结、不乱试的事业长啥样子了。

自酌自饮醉何方，断弦一曲几人怜

这样的惆怅，也就只能装装文艺范，自娱自乐了。曹操在《关云长》里说：“让我不想，容易，要我想不远，困难。”其实很多时候没人在乎你是谁，也没人在乎你想干什么，在乎的只是交出来的那份答卷而已。经过前段时间的一些事儿，自己的心智好像骤然成熟了。其实这是个悖论，就像醉酒的人从来都是嚷着我没醉一样。

不过管他3721，也来学学曹操好了，索性一不做、二不休，将那个…也想想好了，虽然不见得已经很明朗，至少有了点眉目了。

天梯石栈相钩连，杯酒劝尽，蜀道可攀！乘风破浪正当时，沧海欲济，云帆何在?

有些意外收获，有位同事给我讲了他憋了半年的一个结儿。是半年前自己还是Dev Manager & Project Manager的位置上的是推行的一种小团队管理开发人员的模式，当时是想让team里的所有人都来尝试下小组长的角色，一来可以核实下到底谁更合适做这个小组长，二来大家都体验一下，提前互换下角色，对以后工作更能互相体谅。给大家的信息是每个人都会有机会轮回。基于各方面考虑，这位同事是第一批轮到的；第二轮开始的时候给他的信息也是轮换，最后会考虑综合效果最好的人来做小组长，然后就把他撤下来了。但是由于种种原因，轮换的制度到了第二轮就没能继续下去。直到现在还没能开始轮换，而这位同事认为替换他的那个人能力不如自己，只是因为早进公司了一段时间而已，就这个事儿这位同事的受到了很大的打击，觉得很不公平，后来也做了一些违背公司员工手册的事情，就跟我很激烈的宣泄出了他的不满。

我接着也给了他一些我的反馈，当然只是基于当时的一些想法。

首先，我觉得能够跟我讲出来这个结儿，能跟我沟通这个事儿，不管出于什么目的，有什么诉求，我都很高兴，我觉得至少他在那个店能够信任我，我很感谢他的信任。那现在你说出来了，我承认是我当时工作的失职，没能做好一个负责人该做的工作，至少在团队在信任、沟通层面就已经产生了障碍。

其次，我很理解他需要宣泄，甚至我个人很鼓励将自己工作中的不愉快都喧嚣出来。当大家都感受到你的不愉快，大家会给你一些的建议或者帮助。

最后有一点，当你发现一些规则不清晰，让你很难受的时候，你憋了半年都不说，说明你不信任你所处的团队，你不会去依靠你的队友，这点完全没必要，直接了当的找当事人，当面锣对面鼓的交流可能在IT企业你会过得更轻松。这种憋着的做法在我看来，不够职业，或者不够成熟。

当时装13的把自己仍在一个管理者的位置上，就跟微薄上得瑟了下：

青年节跟同事去放松，意外的收到很多的反馈，原来做的管理工作还是有很多的不足啊。1、能让一个同事将某个想法憋了半年也没说出来，单从沟通层面就够失职的了;2、某些角色的安排规则不清晰，对于参与其中的人员也是很大的不公平;3、当大家都带着压力来工作的时候，团队建设也就无从谈起了。

觉得自己在做决策或者推动一些事情的时候应该多关注下其他人的感受。当然对于这个个案，如果这个同事有这个想法，其他人在类似的事情上应该也会有，虽然现在我不负责那个部门的事儿了，我还是应该去做一些事情，至少把我收集到的一些信息整理一下，在征得当事人同意的情况下，找到相关人的人去做一些补救工作。

过了没几天，Boss给我做一季度绩效面谈，谈到了对我的期望，以及现阶段能力的不足之处：领导力、解决问题、团队协作。

其实这3点，自我感觉做得还蛮好的，经过跟Boss一番交流发现果然是屁股决定脑袋，特别是 识别并界定问题 这个层面上。

就拿上面说的这件事情上来说我当时理解可能是 他对某些title过于看重了。实际上最大的问题不在于这个，后来我想了想(当然也不一定对)是他认为从公司角度更看重的是资历，而不是能力，这样让他觉得公司很腐朽，不能给他想要的文化氛围，不能给他想要的发展空间。从这个角度来看，我当时破坏的是公司的文化，核心价值，还好我的那些补救工作还没有开始，现在想想都后怕啊。

上周五去了趟青岛，主要是去参加AgileTour青岛站的活动，顺带去青岛海洋大学做了一次校招，在面试环节遇到两个有意思的问题，是一个迎接的研究生女生问的。

一般面试的尾声，我都会给应聘者一个提问的机会“你有没有什么要问我们的？”这个女生就问了两个问题。两个问题都很出乎我的意料。

Q：企业一般会要什么样的人？

A：各个企业对人力资源的要求不一样，至少我们现在需要的是基础知识好，各方面素质中等，但是必须有较强的学习能力。同时要能契合公司的基因，也就是企业文化…(然后就是2分钟左右的即兴发挥，希望不会误人子弟.)

Q: 作为有过很多经验的人，你认为在面试过程中面试者应该注意哪些，该如何回答一些面试的问题，对于职场新人有些什么忠告（类似的原话不记得了）？

A:（起码思考了3秒后）你这个问题着实难住我了，一来我没啥经验，毕业时间也就是3年，忠告或是建议坦谈不上，顶多算是分享一些自己认为有用的经验吧（语速很慢，又想了大概30秒）。其实这个问题很简单，凡事从结果入手，多问自己几个为什么就好了。就像今天这个面试，你的目标是什么，是为了拿到Offer还是为了参加一场面试多长长经验，这个目标清晰了，所有的回答也就是没什么需要特别注意的了。

说完这些我自己后背都一身冷汗，说的容易做的难哦，自己的目标是什么嗯?为什么 有时候很简单的一个词儿，有时候却又不是那么简单哦。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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