2016年3月20日，春分。

春分时的田野其实并没有我们想像中春天那样繁茂，这是因为春分是一个等待、准备的时节，此时的主要的农作物还没开始播种，农事是筛种、育苗、修渠等。我们今天也做了一个准备播种的事情，那就是进行新公司文化第一课，确定我们企业的愿景、使命和价值观。

早上9点，人到齐了，开始介绍了一下今日主要议题之后，大家简单互动聊了几句，我毛遂自荐做了今天的引导师。

下面说说是如何进行的吧。

数1/2/3分三组

第一环节：概念清晰并预热

提出讨论的议题是：各组分别讨论对愿景和使命的定义，以及你觉得是愿景在先还是使命在线？

通过百度、讨论等方式大家先小组讨论，然后三组分别讲述，其他小组可与之争论，鼓励不同看法。

第一环节：制定愿景和使命

提出讨论的议题是：先各自写对企业愿景描述的几个形容词，以及要做的事。然后再一起讨论，最后给我两句话，一句是企业愿景，一句是企业使命。

1组讨论中

2组讨论中

3组讨论中

经过长时间的讨论，愿景和使命慢慢浮出水面

想好之后开始动笔

为了一个词真是绞尽脑汁啊

写完之后各组分别派一个代表给大家分享，看这中年人笑得多年轻:)

我喜欢“信任”这个字，因为我太希望获得用户对我们产品的信任了

愿景这几个词写的不错，有点感觉

各组分享中还可随时由小组内成员补充

接着大家对自己最喜爱的愿景和使命投票

下午1点40分投票结束

接着和大家一起进一步讨论有针对性的讨论具体的愿景和使命

最终确定了我们的 v0.5 版本企业文化

我们的愿景：成为一个员工幸福、客户信任、技术领先的建筑行业大数据服务商。

我们的使命：用数据的智慧改变建筑行业。

愿景使命结束之后，就是价值观了，这个更烧脑，完成这个阶段之后已经好几个人头疼了，也包括我。

一样由各组分别填写，内部合并归类删减出核心的6个价值观。

这是1组的

2组的

3组的

每组写出自己留下的最重要6条，并派人分享

最后讲完之后发现大家写的竟然如此雷同，6条中5条都一样。

因为一致，所以很容易的就确定了6个价值观，给我们节省了大量时间：合作、激情、极致、客户、学习、真诚

因为一个词的理解可能会比较宽，接下我们用一句话来描述每一个价值观，这样可以更为具象价值观指的内容。

过程中时刻讨论，

时刻沉思，

总之死了很多脑细胞才把合作和极致写完

接着激情讨论了比较久。

不断碰撞出更好的一句话

接着是又想学习与创新

有时大家脑子都不好使了就停下来吃点东西

最后终于学写完了，看看我们的价值观成果吧

• 合作：开放心态，合作是永恒的主题，不要让自己孤军奋战！
• 极致：精益求精，追求极致的产品体验，超出用户期望！
• 激情：自我燃烧，点燃团队的激情，一起干一番事业！
• 客户：让客户满意，其他一切水到渠成！
• 学习与创新：共同学习，持续创新，让我们跑得更快！
• 真诚：心胸坦荡做人，脚踏实地做事！

这就是我们一天的成果，还是不错的，感谢大家的一起投入

严肃的做人

轻松的做事

同舟共济

举杯同庆

妈的，看来我又得呆在广联达了…

todo:

1. 企业价值观排序
2. 确立企业原则
3. 各团队愿景和团队价值观的确立
4. 个人愿景和个人价值观的确立
5. …….

下面就简要说一下是如何进行的，对于新的团队也可以借鉴一下。

按照Scrum的计划会议分为上下两部分。上部分主要是产品需求人员讲业务，下半部分主要是开发估时。

一开始进行的是业务交底工作。这个过程原型是必须要准备好的。

这个环节我发了一次脾气。因为前一天我是要求2位产品负责人进行需求分析工作的，需要按照故事，从用户角度去编写卡片，并且排定优先级。这样按预期进行的话，交底应该是从概括到细节，从高优先级到低优先级讲，而且必须和开发讲明为什么要做这个功能，让开发明白所做的东西有什么价值。但这次明显没达到需求分析的要求，发完脾气之后让大家继续。其实我很少发脾气的，主要是太着急了。

因为故事也没写，所以接下来就带着团队从头开始去分析需求、写故事卡片。因产品人员有事请假，于是我带着技术和测试人员开始写故事拆任务。

首先在白板上写上故事的一般写法，引导大家按照这种方式去思考。

1. 首先是对应的是哪部分用户，分的越细越好，例如是甲方、还是咨询、还是施工方等。如果说不清，那就先写造价员或者不写。
2. 接着是把这个故事想要表达的用户的核心需求写下来
3. 最后写完成这个需求后能给用户带来什么

不清楚用户故事背后的理念，可以看我下面这张内训PPT

没多大功夫大家就写满一桌子

大家写完之后，我说故事中不能出现比较明显的技术话语，否则一定是违背故事卡片背后从用户出发的初衷。

说完之后，大家看看自己的卡片，都异口同声的说：我肯定写的都不合格，好像都是技术相关的：）

于是我引导大家打开原型，从上往下、从左往右的就每个功能开始反问大家。“为什么你们要做导航查询？”“为什么要进行对比？”….

问得大家都懵了，说又不懂业务需求，谁知道有什么用。我明确告诉大家，把现在当成需求人员来对待。以前可以不懂为什么做，但是现在每个人都要开始去关注功能背后的东西。我继续引导大家“如果做不知道有什么用的功能，是不会真正做好的。对于一个功能是这样，对于一个完整的产品更是如此。其实价值不仅对工作，对做人也是，如果一个不知道自己价值的人，生活必定是没有多大意义的。“ 后来我提醒大家可以邀请公司之前是造价用户的同事给予帮助。于是他们自己去请了同事过来进行交流…

互动的还不错，大家加深了对业务的理解，也更明确了自己要做的事情能在实际哪些业务场景中使用，增强了自己的目标感，这其实对于团队来说是很重要的。大家明白了，多品牌的不同材料比价对于甲方更为重要，他们可能在选择用什么材料。而施工方更重视同一材料不同供应商比价，因为他们是在确定的材料下进行预算…..问完之后，请走了同事，然后团队开始重写故事卡片

写完之后我告诉大家接下来重要的事情就是排定优先级。大家把黄纸贴都贴到玻璃板上围城一圈

开始讨论各自对优先级的看法

黄纸贴慢慢形成了一个队列

遇到需要细节的地方就停下来讨论一下

从站着到坐着，对故事的认识多花些时间是值得的

清楚之后，可能之前故事卡片写的不清楚，甚至可能需要重新再写故事卡片。这是大家讨论结束后对原有故事卡片的重新编写。

从下图看，左边是之前的卡片，右边是重新写的卡片。左边的是故事的写法，右边的更有点像功能点。

这次我没有要求大家按照故事的写法去写，这也是很多初为敏捷教练容易犯的错误。一定要记住故事的作用，它是用来交流达成一致的，有些产品按照看似功能的写法可能更简洁，但是只要之前大家对产品功能的业务背景进行过沟通，并达成一致即可。

以上部分是写故事卡片。这部分其实应该属于需求工作，是在开计划会议之前由产品需求团队完成的。故事写完了，接下来就是拆解任务了。通过故事的任务拆解，我们可以更细节的讨论如何去做，并得出更为精确的估时。

第一个故事拆分仍是我引导大家进行。从【数据准备】故事卡片开始，让大家把可能涉及的工作分类写上，过程中我再补充了几个。通过在白板上书写的方式先讨论清楚，再写到卡片上

接下来就没我的事了，我就旁观，偶尔引导一下。经过一段时间的讨论之后，大家把故事下的任务都拆解完毕。

接下来就是给每个任务进行估时了。因涉及UI工作，所以涉及这部分工作时就把UI同事叫过来，简单讲了一下需要完成的功能之后开始估时。其实最好是UI人员也全程参与。只是现在UI不归属我们团队管理，遇到任务时间冲突只能临时叫过来估时了。

每个任务经过大致预估，所有故事任务时间都估算完毕。目前团队基本还不能做到全栈型开发，估时方式主要还是基于主要编写代码的人估时。

估时完毕后，我继续引导大家给我一个预上线时间以及发版时间。大家给了一个，我说如果提前一周完成的话，有哪些工作可以并行。大家开始讨论，最后估时结束。

估时完成后，就要把新故事和任务放到看板上了。这是放新需求之前的看板，【发布】一行中有很多上一时间完成的。

在我实施的kanban中，每个月我会整理一次发布的内容，发布完的会打印在一张纸上，贴在看板最下面。把看板整理后，再放上这一迭代的故事卡片和任务卡片。大家可以看到，故事卡片仍是以前的样子，多的是每张故事卡片下的任务卡片。

这是执行过程中的看板，大家可以看到任务卡片往下沉，也代表着任务在执行。当一张故事卡片的所有任务完成之后，这个故事卡片就可以从【需求 done】挪到【测试 doing】了。

对于随时接受反馈的产品团队，在计划之内总是会有很多计划之外的任务。你看，这面墙上【需求 doing】的已经快贴满了，这个时候如何解决？我们现在的做法是，需求有最后时间的写上，如果开发自己感觉最后时间完成不了，则自行加班解决，总之不能逾期。当然前提之下仍是产品需求人员需要向开发讲明做这件事情的价值所在，而这正是团队更需要在日常工作中慢慢培养的工作意识。

很多团队在实践敏捷时都会应用很多最佳实践，如果你采纳的是Scrum，你一定会使用站立会议、sprint计划会议等。这些最佳实践规则很简单。拿站会来说吧，Scrum站立例会 中有个针对每个人的经典三问，不过你可千万不要被简单给迷惑了，这些实践可谓简单却不容易，看看你们把站会开的有没有出现以下现象：

1. 每次开会需要有人叫的时候大家才慢慢聚齐
2. 时不时有人迟到，你即使把站会时间推迟开也一样
3. 每次都是团队成员围着领导，然后向在做自己的工作汇报一样
4. 经常有人开小会，不注意倾听，同时有多个声音在交流
5. 每个人只说做了什么，却从不说做的怎么样？
6. ….

如果你被以上现象所命中，那么这篇文章你可以好好看看了。

Scrum有明确的站立会议最佳实践，对于Kanban来说却没有这个规定。那如果你实施的是kanban，站立会议要开吗？怎么开？接下来我就说说个人在工作中的一些想法和实践，希望能对你有些帮助。

站会是给团队的一份礼物（Gifts)

不好的站会会被大家当做一种不愿参加的例行公事，好的站会却是送个团队的一份礼物（Gifts）：

1. Good Start
   站会能给大家每天开一个好头，一个好的站会可以通过具有紧迫感的目标给大家带去一种能量，这种能量是通过大家对目标的一致理解之上而来的。
2. Improvement
   站会的目的是改善，而不是开会。每天站会暴露出来的问题都值得我们去解决，当然改善不仅限于问题，分享更好的技术和想法也同样很重要。
3. Focus
   人很容易沉迷与努力工作却忘记目标，站会能够鼓励大家关注到正确的事上，而非无意义的活动上
   
4. Team
   “团队建设”成效有限，有效的团队是构建在定期沟通、工帮作、互相助之上的。高效的团队是自主的，把团队所有成员绑定到要共同解决的障碍上是更有效的。
5. Status
   通过站会可以了解团队当前的整体状况，团队工作状态如何？团队还应该知道哪些事情？…
   

每日站立会议的好处

• 促进团队内成员的沟通和协调
• 增加团队凝聚力，产生积极的工作氛围
• 及时暴露风险和问题

看板的问题

在Scrum中有一个经典三问题：

1. 昨天做了什么？
2. 今天要做什么？
3. 遇到什么障碍，需要什么协助？

这些问题都是基于人的维度，每个人轮流说。但Kanban是基于事的，关注的是卡片上的事情，所以我想在广材执行看板的时候是不是要更改一下站会的形式。于是设计了下面几个关注看板上的故事卡片的三个问题：

1. 有没有新加入或删除的故事卡片？（响应变化）
2. 每张故事卡片昨天发生了什么变化？（关注事）
3. 今天这些故事卡片将有什么进展？（流动性）

但按照这三个问题执行后，我发现大家好像不会开会了，时常出现停顿卡壳的沉寂时间，每个人好像都在等着其他人说话似的。好几天过去了，大家仍是这样，我还需要时不时提醒大家继续。有一天早上我实在有点忍不住就开了一个简单会议，严肃的给团队反馈了现状与我预期相差太大。第二天大家竟然都非常积极的抢着说属于自己的卡片。

尝试了这两种分别基于人或事的问题开法之后，我觉得在初级敏捷kanban团队中应该结合起来使用。那如何开最合适呢？

1. 每周一的时候我会重申一下本周的目标，每月初的时候重申一下本月目标，增加目标感
2. 每天以Scrum的三个问题开始，从一定方向依次每人轮流讲，保证从团队成立之处每个人都能有话说
3. 讲完之后，由站会主持人依据kanban卡片情况制定今日开发策略
4. 如有需要讨论的问题，站会结束后立即召集相关人讨论

每日站立会议的关键要点

下面我就站会中的几个关键点再说一下：

1. 准时开始

要点说明：按计划会议制定的时间地点开会，形成团队成员的自然习惯

以往在一些技术大会和培训中，经常有人问我“出现迟到、要人叫才起来开站会”等情况。这次材价从一开始我就做了一个小尝试，非常好用。规则也很简单，定好开会时间，每次最后一个来到看板前的就来做主持。在我宣布这个规则之后，第二天就看到快到点了大家齐刷刷的赶紧跑过去，大家都会心的笑了。直到现在，这个团队开站会，大家都是主动的到点前往，从没有叫过一次。

2. 高效会议

要点说明：会议限时15分钟，每个人都保持站立

站会期间指引大家如何开高效会议，例如站会过程中注意不要讨论具体方案，但是我也不是总是这样，有时候我会故意不阻拦大家讨论。但如果看到有人心不在焉的时候，这个时候就应该组织大家停止讨论。还有一点，大家会把一些日常能够交流的反馈和内容放到站会上说，这一点至少比不说好，但是教练需要有意识的提醒他们哪些内容可以在日常遇到时就及时的找相关人员讨论沟通，而非等到第二天才来站会上公布。

3. 问题跟踪

要点说明：记下所有的问题并跟踪解决

小问题当时委派人解决，超过2个小时以上的看板上墙，有需要讨论的问题站会后立即开始，需要待定的委派人确定时间发会议邀请。

另外在一些维护性和持续性并进项目中需要注意一点的是，每日反馈的问题可能会让团队偏离原定目标，所以教练需要注意时刻把大家带回主道上，可以让团队养成在每次站会后重申一下本日目标的习惯。

站会虽小，但别小看，希望本篇介绍能够给你一些帮助。

Scrum因为简单有效，已是被大量采用的一种方法了，然而随着近来“精益”、“流动”词汇的不断提起，我认为kanban在互联网行业中一定会成为新的篇章。既然Scrum和Kanban都比较不错，那一个想采用敏捷方法的新团队，该选择Scrum还是Kanban呢？

在说之前，我们先概要的看一下Scrum和Kanban分别是什么（更为详细的可以查看我以前的文章），以及它们之间有什么不同，再来说该选择哪一个。

Scrum

Kanban

Scrum和Kanban的不同

既然是两个不同的方法，自然有不同点。在大致了解分别是什么之后，我们再来看看它们两者有什么不同：

看板的无迭代周期与Scrum的迭代周期也看似冲突，看似低效的看板WIP却会对人与人之间交互、协作的方式产生长久深远的影响，等等这些都让我对kanban刮目相看。在做kanban方法培训时，我常说到Scrum让对产品开发管理有了一个全新的认识，而Kanban又再次刷新我的认知，让我学会用一种开放的心态去接纳新的方法。

Scrum和Kanban的相同点

既然我们困扰于在这两者做出选择，那它们一定有某些共同点，那我们来看看它们的相同点有哪些，我罗列了几条：

 Scrum还是Kanban？

终于到我要回答这个问题的时候了。如果从上面不同点来看，可以说Scrum相对来说更需求稳定，而Kanban更具灵活性，所以如果你的产品经常有临时性的需求、需要更快的发布迭代，或者是一个维护性产品，那么采用Kanban是一种好的选择。不过随着团队的实践，我想最终可能会变成是Kanban+Scrum的方式。

使用Scrum还是Kanban，你都必须说服团队和管理层这些方法能真正带来改进，但行动就是最好的证明，如果不能让更大范围的团队实施，那就在你力所能及的小团队开始。你可以根据自己的喜好或熟练程度来决定先使用Kanban再应用一些Scrum的实践，还是先使用Scrum再采用Kanban的内容。但这并不重要，重要的是你如何改变现有团队的工作方式，如何让他们能在一起开一个高效的站立会议，如何让他们学会并喜欢在敏捷的方式下工作？这需要你具备一个教练型管理者的能力。

看板核心实践

如果你准备开始采用Kanban方法的话，那么我建议你先看看这几点，并去思考这些和Scrum如何融合在一起。

不过我想变换一下，变换的原因有以下几个：

1. 任务从左往右流动改为从上往下落地，支持多项目多任务的横向扩充
2. 变换时重新看每张卡片，重申一遍卡片的填写
3. 增加一些看板要素
4. 做的更漂亮一些，更大气一些，看的心情也好

下面我主要来说一下如何从头开始做一个看板墙，就当这个系列的放松篇。

先上淘宝，搜“3M胶带”，找到特价的买了两个胶条

然后买了一些便签纸

我周末在家买的，周一就收到了。

这是胶条，有股味道，得放到外面晾凉

这是各类便签纸，可以定义不同类型的看板卡片

做完新看板墙后变成这样了

是不是不错啊。接下来我们来看看在原有看板上增加了哪些新元素。

首先是各种流转规则，这是需求流转规则

这是设计流转规则

这是开发流转规则

这是测试流转规则

然后粘上全年目标、本月核心任务

还有一些搜索反馈表、内部学习分享记录表等

看板只是一种展现形式，能更直观更有利于团队沟通就行，你是不是也想重新设计一下你的看板，那就去玩玩吧。

我国的绩效管理始终处于一个较低的层面，绩效管理的作用没有完全发挥出来，给人“鸡肋”的感觉，而造成这种局面的一个很大的原因就是绩效管理实施的主体——直线管理者没有很好地认识自己在绩效管理中所扮演的角色，没有能够处理好管理与绩效管理的关系，导致了执行不力，使得绩效管理的体系、政策、方案、流程不能很好地落地，不能得到有效地落实。

只有直线管理者真正按自己的职责分工动起来，绩效管理才能向预想的方向前进，才能真正实现落地，得到有效实施。

那么，绩效管理中，直线管理者应该扮演哪几个角色，做好那些工作？

笔者以为，在绩效管理中，直线管理者主要有以下五种角色：

1. 合作伙伴；2. 辅导员；3. 记录员；4. 公证员；5. 诊断专家。

一. 绩效合作伙伴

管理者与员工的绩效合作伙伴关系是绩效管理的一个创新，也是一个亮点，它将管理者与员工的关系统一到绩效上来。

管理者与员工建立良好的绩效合作伙伴关系，有助于双方达成一致的绩效目标。从根本上来讲，在绩效的问题上管理者与员工的目标是一致的，管理者的工作通过员工完成，管理者的绩效则通过员工的绩效体现。

所以，员工绩效的提高即是管理者绩效的提高，员工的进步即是管理者的进步。员工的绩效使管理者与员工真正站到了同一条船上，风险共担，利益共享，共同进步，共同发展。

鉴于这个前提，管理者就有责任、有义务与员工就工作任务、绩效目标等前瞻性的问题进行提前的沟通，在双方充分理解和认同公司远景规划与战略目标的基础上，对公司的年度经营目标进行分解，结合员工的职位说明书与工作特点，共同制定员工的年度绩效目标。

在这里，帮助员工，与员工一起为其制定绩效目标已不再是管理者一份额外的负担，也不是浪费时间的活动，而是管理者的自愿，因为管理者与员工是绩效合作伙伴，为员工制定绩效目标的同时就是管理者为自己制定绩效目标，对员工负责，同时就是管理者对自己负责。

通常，管理者与员工应就如下问题达成一致：

• 1. 员工应该做什么工作？
• 2. 工作应该完成得多好？
• 3. 为什么做这些工作？
• 4. 什么时候应该完成这些工作？
• 5. 为完成这些工作，员工要得到哪些支持，需要提高哪些知识、技能，得到什么样的培训？
• 6. 管理者能为员工提供什么样的支持与帮助，需要为员工扫清哪些障碍？

通过这些工作，管理者与员工达成一致目标，更加便于员工有的放矢地工作，更加便于管理者对员工进行管理。

这为后续的绩效管理开了一个好头，可能开始有一点麻烦，但万事开头难，好的开始是成功的一半，绩效目标的制定是一个良好的开端。

二. 辅导员

绩效目标制定以后，管理者要做的工作就是如何帮助员工实现目标。

在员工实现目标的过程中，管理者应做好辅导员的工作，与员工保持及时、真诚、具体、有针对性的绩效沟通，持续不断地辅导员工提升业绩水平。

业绩辅导的过程就是管理者对员工进行绩效管理的过程，在这个过程中，绩效沟通是至关重要的。

绩效目标往往略高于员工的实际能力，员工需要跳一跳才能够得着，所以难免在实现的过程中遇到困难、障碍和挫折。

另外，由于市场环境的千变万化，企业的经营方针、经营策略也会出现不可预料的调整，随之变化的是员工绩效目标的调整。所有的这些都需要管理者与员工共同完成，由管理者帮助员工改进业绩，提高知识能力水平。

这个时候，管理者就要发挥自己的作用和影响力，努力帮助员工排除障碍，提供帮助，与员工做好沟通，不断辅导员工改进和提高业绩，帮助员工获得完成工作所必须的知识、经验和技能，使绩效目标朝积极的方向发展。

沟通包括正面的沟通和负面的沟通。在员工表现优秀的时候给予及时的表扬和鼓励，以扩大正面行为所带来的积极影响，强化员工的积极表现，给员工一个认可工作的机会。

在员工表现不佳，没有完成工作的时候，也应及时真诚地予以指出，以提醒员工进行改正和调整。这个时候，管理者不能假设员工自己知道而一味姑息，一味不管不问。不管不问的最终结果只能是害了员工，对员工绩效的提高和职业生涯的发展也无益。

需要注意的是，沟通不是仅仅在开始，也不是仅仅在结束，而是贯穿于绩效管理过程的整个始终，需要持续不断地进行。

因此，业绩的辅导也是贯穿整个绩效目标达成的始终。这对管理者来说，可能是一个挑战，可能不太愿意做，但习惯成自然。

笔者认为，帮助下属改进业绩应是现代管理者的一个必备的修养，一个职业的道德，当然它更是一种责任，一个优秀的管理者首先是一个负责任的人。

所以，作为一个管理者应该坚持承担员工绩效辅导员的角色。

三. 记录员

绩效管理的一个很重要的原则就是“没有意外”，即在进行绩效考核的时候，管理者与员工不应该对一些问题的看法和判断出现意外。

一切都应是顺理成章的，管理者与员工对绩效考核结果的看法应该是一致的。然而，这一原则并不是在所有企业都能顺利实现的，它需要一个良好的数据基础。与员工因绩效考核结果而发生争吵是令管理者比较头疼的一个问题，也是许多管理者回避绩效结果，回避考核与反馈的一个重要原因。

为什么会出现争吵？恐怕缺乏有说服力的真凭实据是导致这个问题的最主要原因所在。

试问，不做绩效记录，有哪一个管理者可以清楚说出一个员工一年总共缺勤多少次，分别是在哪一天，什么原因造成的？

恐怕没有，因为没有，员工才敢于理直气壮地和你争论，和你据理力争。

为了避免这种情况的出现，为了使绩效管理变的更加自然和谐，管理者有必要花点时间，花点心思，认真当好记录员，记录下有关员工绩效表现的细节，形成绩效管理的文档，以作为年终考核的依据，确保绩效考核有理有据，以事实为依据，公平公正，没有意外发生。

做好记录的最好办法就是走出办公室，到能够观察到员工工作的地方进行观察。当然，观察以不影响员工的工作为佳。所记录的文档一定是切身观察所得，不能是道听途说，道听途说只能引起更大的争论。

这样一年下来，管理者就可以全面掌握员工的绩效资料，做到“手中有粮，心中不慌了”，考核也因此更加顺畅，不会再出现意外和争吵。

四. 公证员

绩效管理的一个较为重要也是倍受员工关注的环节就是绩效考核。

绩效考核是一段时间（月度、季度、半年、年度）绩效管理的一个总结，总结员工的绩效表现，包括员工表现好的方面和需要改进的地方，管理者需要综合各个方面对员工的绩效表现做出评价。

同时，绩效考核也是公司薪酬管理、培训发展等相关人事决策的一个重要依据。所以，公平、公正显得至关重要。

绩效管理系统中的绩效考核已不再是暗箱操作，也不需要。因为，这个时候的考核，管理者所扮演的角色不仅仅是考官，而更应该是站在第三者的角度看待员工的业绩，作为公证员来公证员工的考核。

管理者之所以可以作为公证员来进行考核，主要是因为前面三个角色铺垫的结果。

在前面工作的基础上，员工的考核已不需要管理者费心，可以说是员工自己决定了自己的考核结果。

员工工作做得怎么样在设定绩效目标、日常的沟通、管理者所做的绩效记录里都得到了很好的体现，是这些因素决定了员工绩效考核成绩的高低，而非管理者，管理者只须保证其公平与公正即可。

所以管理者在绩效考核中应扮演公证员的角色。做公证员似乎是轻松的，却是前面努力的结果，是一直的努力才使得管理者可以坦然面对本来很烦人的考核，可以泰然处之，轻松应对。

这也是绩效管理所追求的目标，让一切成为自然，让员工自己管理自己的绩效。

五. 诊断专家

绩效管理的根本目的在于改善员工的绩效，进而改善企业的绩效，因此，绩效考核的结束并不意味着绩效管理过程的结束。

在绩效考核之后，直线管理者还要做一个重要的工作，就是与员工做一对一的绩效面谈，将绩效考核结果通知员工，并与员工对过去一个绩效周期的表现与员工进行绩效沟通，对员工的绩效表现进行诊断，帮助员工找出绩效表现中存在的不足，并为员工制定改进计划，做好诊断专家。

如果要对一个员工的绩效进行诊断，我们可以从知识、技能、态度和外部障碍这四个方面进行，综合四方面的信息，提出员工需要改善的绩效表现。

比如某公司管理者对员工的绩效诊断：在绩效诊断的基础上，管理者要与员工进行充分的沟通，为员工制定绩效改进计划，放入下一个绩效周期加以改进和提高。

六. 结束语

绩效管理能否成功，直线管理者的态度和能力是关键因素，如果管理者不能转变观念，仍旧认为所谓的绩效考核就是填表打分，那么绩效管理不可能取得成功；如果管理者不能很好地认识自己在绩效管理中所应该扮演的角色和承担的责任，那么，绩效管理也不可能取得成功！

所以，作为绩效管理中坚力量的直线管理者在面对绩效管理的时候的，要做好两个转变，一个是观念上的转变，从改善员工绩效的角度出发，致力于帮助员工提高能力，提升绩效水平；另一个就是行为方式上的转变，从按人力资源部的要求被动填表打分，到主动演好五种角色，真正承担起绩效管理的责任。

当直线管理者演好了“绩效合作伙伴、辅导员、记录员、公证员和诊断专家”这五个角色，那么，绩效管理的接力棒就能顺利地从人力资源部的手中传递到直线管理者的手中，绩效管理也就可以真正地在企业的经营管理中发挥帮助企业提升业绩水平的作用，成为帮助企业实现战略目标的助推器。

本|世界经理人网

在会议开始前，我给大家说了一下回顾会议的议程安排。如果你还不知道回顾会议如何开，那么可以看我10年写的 Scrum之 回顾会议。

首先我们写下了这句话“不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩”作为会议的基准。

然后和大家进行会议约定。我先带头说了一个“多说我，少说你们”，然后让大家每个人都说说。大家一片寂静，不知道说什么，我当然不能接着说，否则整个会议就我一个人开了。这个时候，作为敏捷教练，一定要耐得住安静，等待大家的回复。终于有人回复了，慢慢的大家越说越多。我看有人还没说，就指着我们刚写的一条“每个人都参与”，让所有人都参与进来了。

然后我们开始根据故事卡片进行回顾

大家开始对一张故事卡片进行回顾。不过我发现大家针对特定卡片回顾的时候还有些拘谨，或者对问题表述还不是非常清楚，讨论还未放开

于是我改变回顾议程，让大家直接把认为这两周做的好的，以及做的不好的都头脑风暴的写下来。大家写还是可以的，于是一下子就有十张左右了。不过我还觉得少了，我点了一下人数，除我之外有6个人，我说每人至少贡献三个，等凑齐18个之后进入下一议程。然后就看到大家没多久就写满了。过程中纸张总是粘不牢，总掉下来，于是我们就简单的把一些黄纸贴放在各自一栏的放黑板擦的板子上。

我开始问大家，是想先听好的，还是听不好的：） 有人说先听不好的吧。于是我从需要改进的那一列中随即抽了一张黄纸铁下来。这是一张关于沟通的。

之后我开始引导写这张纸条的同事阐述问题，并用一些问题去激发大家一起去探讨这个问题。并告诉大家，我只是对第一张卡片做个示范，等下每个人对自己写的卡片都按我做的方式去阐述问题并收集大家的改进意见。为了让更多人参与进来，我让说的人的左边位置的人作为引导师和卡片主讲者一起来对黄纸贴进行深入探讨。

我讲完之后，大家就开始了，大家开始进入状态，每个人都把自己想说的说出来，有几个问题还开始PK起来的状况。

我作为教练和Leader的双重角色，我总是在每个人说完之后才发言。过程中大家要是陷入安静的时候，我会适当的介入进行引导。

这几个小时大家讨论了很多问题。有人问，如果付总需要我们做一些东西，我们听谁的。我的回答很简单，听团队负责人的，除非不要我负责。还有一个是开发提出一个卡片任务修改多次，这时会议室就安静下来了。我看没人说话，于是介入进来和大家说，敏捷产生的重要原因就是因为需求是变化的。不过我们要分析一下需求变化，需求是问题和方案，我们对问题是一直都没变的，就是如何提示周边城市，之所以最后变了多种方案，是因为咱们开发在现在的能力之下还无法很好地实现原定方案，所以我们就折中成现在的方案。有句话我觉得很有道理，经过努力之后，我们现在所做的一定是当前情形下的最好方案。对于变化的控制，从需求角度要控制问题不变，这需要产品人员多接触客户，分析需求。而从开发角度来看，我们需要提升自己的技术能力，更好的完成更好地方案。这次发版我们有好几个任务就发生了变化，大家做的都很好，能够很快的适应变化，并顺利的在指定时间发布了，并让大家一起给自己一个掌声。

引导完之后，大家又开始继续热烈的讨论开来。一晃3个小时就过去了，大家仍畅所欲言，指出各种自己认为存在的问题。

问题全部讨论完并提出改进意见之后，我告诉大家每次回顾会议我们只要改进三个大家认为都很重要的改进点就可以了。我们接下来需要对改进点进行排序，每人三票，选出下一阶段必须改进的三个点，并指派一个人负责落地，下一次回顾会议的时候还要对这三个改进点进行回顾。

回顾会议的目的是对前一段时间所做的各种事情进行回顾，能够促进团队持续提升。对于第一次回顾会议来说，教练的组织和引导很重要，会议背后的东西大家等自己开了后慢慢体会。上面描述了大体的过程，希望能给第一次开展回顾会议的人一些帮助。

看板不需要像Scrum那样改变以往工作角色，简单通过任务上墙，配合敏捷的设计就能通过显示化日常工作来让问题自己蹦出来。在任何一个新采用看板的研发团队，执行一两周后一定会暴露出很多在开发过程中的问题，这些问题就是团队成长的空间，可以把这些问题作为团队持续改进的出发点。

上午公司开完2016战略发布会，下午来到公司想写写文字记录一下材价看板这两周中发生的事，准备下周再带着团队一起做一个回顾会议（如果还不知道回顾是什么，看看我以前写的  《回顾会议》）。

这是刚开始做的 第一个kanban

1月份这一周各种会议，我基本不在公司，不过大家经过一周的践行，已经会自己去运作看板了，这是两周后看板的样子

总体来看，看板卡片往右移，多了一些黄色小纸条。怎么多了黄色小纸条？Scrum不是说过程中不允许添加任务吗？

我们不是在用Scrum，而是看板，所以忘记那些书本上学到的或者听来的知识吧。今天我会展开来说一下这些变化，以及其中一些看板卡片。

挪来挪去的卡片

这个故事卡片是【查找周边城市材料】，这个卡片有很多可以回顾的点，有些在  第一个kanban 中已经说过了。这里我们再说说它在这两周是怎么动的。

第一周的时候，这个卡片经过设计的doing之后挪到开发的doing，但是开发对这个任务还不能肯定能完成，所以一直还未开发完，存在技术障碍，这说明我们对搜索引擎的深入一些的技术就无法胜任。深入搜索引擎学习是上半年团队研发人员的主要工作，否则不可能改变核心问题，下周看看团队是如何回顾这个卡片的：）

为了不影响其他任务的进行，我破例做了一次操作，把卡片挪回来设计的done，以便可以挪入另一个任务进来。（如果你没有听过我的看板课，不知道WIP的可以自己上网找找详细说明，简单的说就是在制品work in progress，用来明确限制流程中每个状态上最多同时进行的任务数）。

还过去的债

往往我们被工作压着往前赶，去忘记一些基础的东西不做好要付出的代价，这是一个重构的卡片，过去的建索引代码不易维护、比较混乱，建索引中还有错误，但是开发人员没去查到底是数据原本就有问题，还是代码有问题，这就么一直留着。这次项目组人员变动，交接后就立即开始了还债工作，重构了信息价和市场价的建索部分代码。

这个卡片属于技术性的任务，之前我定了一个规则：任何一个看板上的故事卡片都必须填写部分，于是测试人员后来在这卡片上补上了这部分内容。

必须建立起灰度发布的机制

这期有一个任务是去掉首页的城市选择，我觉得这已经改变了用户的习惯，所以提出必须灰度发布，还讲到一个成熟的灰度发布还必须有一个灰度发布引擎，可以根据一定的规则由发布引擎判断之后转发到不同的版本去，但至于如何去做团队自己考虑。

开发后来想到是否仍旧使用一个页面，通过访问IP来控制显示选择城市按钮，于是问我是否可行。这个时候我把自己定位于敏捷教练，所以我要控制自己的方案提出，除非他们真的想不出来，于是我说可以，并且说到，只要能实现我们所要的结果，越简单的方案越好，我们的目的是通过快速发版获得学习。

一个问题的解决方案总有多个，没多久团队又提出一个方案，是否可以发布两个包，让IDC通过IP直接转发到不同的服务器。听完之后我觉得这个方案比第一个好，适用性比较强，以后可以去做更多基于地理位置的灰度发布。

这里要说一下，我一开始想到的方案其实第一种，如果我当时分任务的时候，我要是说出我的方案，估计大家就不会想出第二种方案了，所以作为敏捷教练，时刻要记住什么时候该做什么事。

第二天站会，测试提出一个问题，说灰度发布好像没什么意义，能不做灰度发布测试嘛？当时我就和她重新说了一下灰度发布的意义，以及为什么这次任务需要发布。但是她还是说能不能不做。继续问下去，她说到：这样灰度发布测试起来好麻烦，我要用外地的机器登录才能测，所以现在是和分支的人沟通，然后远程连接他们机器操作进行测试，这个沟通和远程操作耽误的时间很长。听后我也没有立即回答方案，因为我当时也没想到什么好的解决办法，于是我对着负责这个任务的研发人员说：“你看看能否从技术上去解决这个问题？这样测试的确太麻烦了。” 接着转向测试说：“不管测试多么麻烦，这是我们现在的能力问题，但是灰度发布这个事情是必须要做的，不管多难测试，这是你需要考虑去解决如何更方便测试的问题。”

晚上我回家就想这个问题，毕竟我还是团队Leader，在没有方案的时候我必须是要有至少一个方案的。第二天早上，我准备去和开发说用VPN应该可以。我说到：“那个灰度发布测试的问题你看看能否通过VPN来解决。” 开发人员说：“这个问题已经解决了，测试已经开始测了，用网络代理，浏览器设置一下就可以了。”

又一个比我好的方案，让我再次印证了教练的最佳方法是激发团队自己找到解决问题的答案，这也保证了我们后续更方便的进行灰度发布了：）

怎么又是登录问题？

去年初接手掌中广材时，在维护老版时总接到登录不了的反馈。当时我就觉得很纳闷并有点不可思议，一个产品竟然有总反馈登录不了，那用户还怎么使用产品功能呢！考虑再三，后来我决定重新开发掌中广材，也就再没有因为登录问题困扰我们了。

今年接手广材网，感觉好像历史重演，有反馈登录不了，同样的一个遗留问题。

因为有了看板和之前我约定的一些规则，大家解决这个问题的响应时间还是比较快了，几个开发都一起来找问题，最后发现可能是公司云账户那边处理的问题：在IE11下cookie传入不到公司云账户系统导致登录不了。我说到出现问题在哪就和谁一起解决，研发都蛮主动，找了云账户研发人员，但是他们那边始终没有复现这个bug，在我们这边也就一个人的机器能复现这个问题，于是大家也不知道该如何解决了。

我看到这个黄纸贴在快速通道的开发doing呆了两天，解决不了不要紧，问问用户情况，于是和产品人员说到，和用户联系一下，具体问问他们现在怎么样了。得到的回复是：“打了，不过没人接，打不通。”我问能不能拿自己手机打？

这几天都是会，我也没有太关心此事了，今天下午回到公司，广讯通看到测试发的留言信息，是用户和她聊天的截图。

于是我和产品人员留言：联系不上用户，别人却主动找上门来了。有没有和用户说这里也可以登录？

对于用户反馈，大家缺少一些常见问题的应对，也缺少对服务的认识。如果登录不了，是否可以让他直接访问公司云账号登录页面来登录一下，这样可以初步定位一下问题是在云账号还是广材网呢？如果云账号可以登录，那是否可以先告诉用户点击广材网最上面的【登录】按钮进行登录使用呢？对用户反馈bug的服务，首要是解决用户当下之急。一般这时候反馈的用户都不是粉丝，他反馈登录不了就是要马上登录进去查材料价格，如果我们先告诉他通过上面的登录按钮点击进去登录后再解决这个技术问题，用户的感受是否会好一些呢？

我发现网站首页对登录功能竟然有三个地方，最上面，右边，以及下边栏。不知道当时为什么这么设计的，从没看过因为要让用户登录就到处放登录按钮的。这里暂且不说产品设计，回到这个技术问题，自己解决其实并不难，不过从架构设计角度来说，这个应该放在会员中心，各产品只是调用会员中心的接口，所以从产品最优来看，我会把这个问题提到公共组，如果公共组不解决，那我就会自行先去解决。

【搜索排序】加塞了

看这个图片【无法登录】黄纸贴下的【搜索排序】这张卡片，为什么要说这个呢？因为这在最开始团队所做的看板上是不存在的，是因为在元旦期间进行站长培训中获得了一些反馈，我们于是在看板上增加了一些卡片。

这里要说一下的就是，实施看板和实施Scrum有些地方是不一样的，之所以我在团队没有推行Scrum，是因为当前团队和工作任务更适合用kanban，所以大家不要误会实施敏捷就只有一种。实施敏捷一定是根据团队成员现状以及产品而定，不过对于互联网产品我更倾向于使用看板和Scrum结合的方式，以后有机会还会写本系列的后续文字与大家分享。

这个卡片任务单我们团队是完成不了的，还需后台一起来完成，属于一个协调性工作，目前来看，大家配合的都还很不错。还是上篇说到，如果大家都来玩看板，弄成一个大看板就更好玩了。

开始优化工作

接手广材网之后，我申请了SVN权限，下载源代码之后，妈啊，这么多项目。在我印象中，如果广材网是我来架构的，一定是一个项目下有很多模块，而基于历史原因，模块都成了一个单独的项目，而且很多项目都找不到主人了。公共组想法和我也一致，就一起把这事给提前做了，放上一张卡片就代表开始了。

快速通道的设计

在看板的最上面一行，我们设计为快速通道。放到这一行的卡片就意味着大家先放下手上的事情，一起去解决完之后再做手头上的事，保证尽早解决问题和反馈。至于如何判定是否放入这里，每个团队可以制定自己的规则，我把用户反馈的bug，特别是数据类问题都归为此类，见一个就要立即着手给用户解决。于是大家可以看到上面的一些黄色纸条。

去年11月份的bug竟然还没改

看板运转一周后，大家对bug的处理方式建立了。站会上我提到：“我发现广材网bug很多，材料搜索的价格过滤有问题，而且这个问题从去年底就一直存在。”测试说：“不会吧，我这些都测过啊。” 我也没说什么，就让她站会结束后复测一下。

没多久，收到广讯通一个截图，测试来到我的位置，对我说：“这是以前测试的bug，还没改，这里还有一些。现在怎么办呢？”

我一看顿时又被惊呆了，都2016年了，这里的bug还有2015年11月份的。我反问到：“你觉得现在应该怎么办？”

后来我说到：“作为一个产品把关人，如果开发不管，测试应该义不容辞的去催着改。”然后我和大家说，“所有bug今天解决掉。” 接着下午开发和我说，“bug解决完了。”

这里要说一下的是，看板故事卡片的bug不需要再上墙了，因为本来就是一个任务。这次属于特殊，所有遗留bug改完复测完就行了，不需要上墙。

【样式调整】过三关上线后却被我一眼提了好几个问题

这一期有一个任务，是把信息价栏目的样式改为和市场价一样。

这几天经常在外开会，晚上回到公司的时候大家都已经下班了，我看了一下看板。测试人员还在，看我回来了对我说今天发版了，于是我马上打开看看，发现几个明显的问题，于是给大家留言。

这么明显被我一眼就能看出的问题竟然可以逃过三个人的眼睛，第二天站会我对开发、产品人员和测试人员一一说到这个卡片的测试问题，希望以后不要再发生发布之后被我一眼就能看出的问题，并增加了一条规则：以后任何一个故事都要经过三关严格验收才能发布（开发自测、产品负责人测试、测试人员测试）。

关于发布

bug解决了，测试问我什么时候发布？我说，如果你们能保证改完后的版本一切正常，那就当天发版。

这次改的一些是小问题，不会有代码关联的影响，所以我说今天发版，只要改掉一个问题就发版，我是不能容忍一个明知道存在的bug还留在正式线上环境的。这时他们说，以前是一周发一次的，我说不能等，必须发。这时候开发提出，他改了代码，SVN的代码不能编译发布。这明显属于开发管理上的问题，于是我又增加了一条规则：开发人员必须保证SVN的源码都可以随时编译运行。等这个任务完成之后，以后就要做到每日发版，更改一个bug或反馈必须当天就发。

关于看板方法

目前来看，大家对看板只能是简单使用，一些估时、卡片填写、验收等环节都做得还不足，不过经过两周的看板，大家的工作也基本开始有序起来，接下来的就是需要以目前已发现的问题作为起点，逐步改进优化。

昨天公司战略发布会上说到混序，自组织理论很早就有了。如果说我们的团队以前是一个无序状态，现在实施看板后就开始慢慢变得有序，敏捷团队的形成就是一个自组织的过程。最后放上一张12年我的一张讲义，大家可以先自己理解一下“涌现”、“规则”等这些字眼的含义，具体内容我们以后再在《材价看板》系列慢慢说。

互联网企业看板已经玩了好几年了，以前都是我给别人培训教别人玩，现在我也开始在自己的团队玩看板了。毫不夸张的说，工信部的每个团队都可以来玩看板，越早越好，即使你没经验也不要紧，因为有我在啊。

12月22日给材价整个部门的产品研发相关人员做了一次kanban工作坊培训，

以及敏捷导入前的动员

第二天晚上，23日，我基于目前团队现状设计了一张看板卡片，样子如下图所示：

不熟悉的人看了这卡片估计也不知道如何用，所以我现在简单说一下这个卡片的设计。

看板卡片的设计

整个卡片基于敏捷中的故事卡片设计，简短的名称让团队马上知道要做什么，使用故事的写法“作为…，我想…，是为了…”来描述用户需求，在如何演示中写的是产品方案，完成定义是测试，其余的是重要性、估时等。

现在再次看看看板卡片

• 上部分：
  • 圆圈：代表目标，简短文字表达用户需求
  • 人：谁提出这个问题/需求的人，当需求完成时产品需求人员必须找这个人进行验收。尽量是外部用户，能保证需求来自于真实用户，而不是自己YY的
  • 日历：卡片提出时间
• 中间左边：
  • 左边上部分为故事描述方式，这里需要严格按照这个格式书写，虽然我知道没有哪个团队一开始能做好，例如把方案也写入了用户需求。
  • 下方为演示和验收内容，这里的演示部分由需求人员填写，验收由测试人员填写
• 中间右边：
  • 依据团队角色各自标记估计时间和实际完成时间
  • 每个圆圈代表1个小时，如果估时为8小时，那就在第一排第8个圈上面给圆圈填充实心。实际完成时，使用划横线方式来看实际时间
  • 如果出现任务过长，或者参与人员为多人并行，可以在对应角色右边贴上粉色小纸贴
• 下方：
  • X：有些需求有最后期限要求，那就在这里填写，每日站会看板的时候需要关注这个时间来定当天开发策略
  • +：把故事卡片从backlog挪入开发阶段的时间
  • V：需求上线时间
  • @：生产周期，上线时间和卡片进入研发时间的间隔，通过这个时间能看到我们的平滑交付能力。
  • 星星：问题提出人验收后对此故事完成的满意度打分，保证用户不只是在调研阶段参与进来

看板设计

看板设计是基于研发价值链，我们的看板并没有什么特殊的地方，从左往右依次是：

• idea：任何提出的想法都可以贴在这里，我和团队说了，包括学习都可以，只要学习的确对我们产品有价值。如果整个部门都实施看板，我其实希望这里还有来自外部团队人员贴的卡片。此处不需要用前面设计的看板卡片，用黄纸贴就行，写清楚大意，留下姓名即可
• backlog池：产品需求人员从idea、用户、自身分析等各种途径收集过来的用户需求。从上往下，依据优先级排放
• backlog doing/done：使用前面介绍的看板卡片把产品backlog的用户需求进行细化。在需求人员从backlog池挪到这列的doing时需要和团队进行简单的交流，保证团队所有人员都认可需求的价值。在挪到done之后，剩余阶段人员对故事完成进行估时
• 设计 doing/done：UI、UE、开发的简单设计等工作
• 开发 doing/done：开发工作
• 测试 doing/done：测试工作
• 发布：灰度或正式上线

暴露的问题

看板和卡片设计完成就是开始填写。在填写之前，我给大家对上述内容进行了讲解，并重申了广材网今年工作重点，以及看板方法执行的决心。

为了让大家知道如何填写卡片，我特意举了一个例子。这是我前天自己在卡片上写的（卡片版本不是最新的，大家就看内容）

然后让大家来做

这时候大家的几个明显的问题出现了。

1. 需求能力需要提升。
   设计卡片时，我把“作为___，在____我想____是为了____”描述的空格留的都比较小，这个目的是让产品需求人员能够简化语言，明确用户需求是什么。负责写故事的人会说卡片设计太小了，根本写不下。我把空格设计的比较小是有原因的，只要真的把需求想好，一般都是能够写下的，如果不能写下，那么可以看看是否文字不够精简，或者是不是把需求方案也写入用户需求了。
   • 写看板卡片其实就是在做编写需求文档的工作，然而需求人员其实是需要具备较强的需求能力的，这包括需求获取、需求分析和需求设计工作，最后才是需求文档。例如上面的例子来说一下需求分析吧，找到最近的城市其实目前用户有两类需求，一类是只按照相对距离来找，还有一类是在优先省内再按距离。这两类需求要是经过分析，就会出现一个抽象的需求，查找周边城市。而具体的需求是具体的规则，这样设计的需求就容易被人理解，也容易扩展和实现。
   • 当前需求面向的客户是谁？谁都知道是用户，所以如果在卡片上写”作为用户“就等于没写，至少你要把你的具体用户角色写上。然后不断的细化拆分成更具体的用户角色
   • 在需求培训中，我会给大家一个简单的需求公式：需求=问题+场景+方案。而”在___”就是场景，看看例子中大家填写的是“在搜索材料时”，使用广材网的都是找材料，所以这个场景写了也和没写一样，这个时候必须让需求提出人去获取到底什么场景下需要这个需求，我想应该是“在没有找到本地材料时”才会有这个需求，那作为需求人员就应该明确写下来
   • “是为了___”是用户要这个需求的目的，同样是前面的问题，如果写了就不能太笼统，一定要细化，否则写的都是产品的大帽子，那写了和没写一样。
   • 认真填写故事部分，不仅可以帮助需求人员梳理需求，还可以作为与研发团队交流的重要交付物，因为需求的工作不只是产生需求而不管实现，你不仅要生了需求还要负责养活，提出需求之后还要去关注交付和运营需求，这就要求你必须有理由去说服开发心甘情愿的去做这个功能。
2. 缺少与用户的互动
   
   • 需求提出人上写的都是CPC，这是产品人员的姓名，并不是用户，也就是说这个需求不能追溯到哪个用户提出的
   • 我严肃要求，以后这一栏不能填写自己，即使是自己分析出来的，这里要填写的也要是能给我们做验证的客户
   • 然后正如前面”搜索“卡片上的，把“CPC”该为为了“分站”。我一样提出，这里的客户尽量是外部客户，毕竟我们后台能找到很多VIP用户，要找到用户其实还不是那么难
   • 除了填写需求提出人之外，我还要求产品人员在填写这一栏时，要告之用户，等产品开发完成后参与验证，并打上满意度
3. 开发和测试能力需要提升
   • 开发对有些任务无法预估时间，说明在技术上我们还有很多无法有把握如何完成，这需要团队的搜索技术学习
   • 测试在看板移入研发阶段后无法及时补充看板卡片的如何验收内容，说明测试需要了解敏捷的工作方式，尽早参与到需求阶段，以及如何快速的理解需求编写主测试用例
4. 估时严重超时，不可能敏捷。
   • 我设计的各阶段最多时间为8个圈，也就是2天，之所以这么设计是因为如果每个任务阶段时间工日超过2天，那一个故事基本要超过1周才能完成，这基本上做不到快速交付，就无法流动任务，那也就谈不上敏捷了
   • 对搜索排序这个需求，问后发现这个需求说做了一个半月。有时确实存在大需求，那这个时候怎么办，一定要学会如何拆解需求，把大故事拆成小故事，这样才能保证有价值的需求能够快速交付
   • 开发、测试估时也是一样，任务估时比我预期的也长
5. 缺少基于产品的互动交流
   • 团队以往的工作方式是基于任务，无法保证工作的投入
   • 由于团队之前产品和开发的沟通交流不顺畅导致产品的完成不确定，氛围不好
   • 我再次重申敏捷的学习更多在于团队的面对面的沟通，不仅仅是自身技能的学习，还有基于产品的客户学习
6. 团队整体缺少承诺意识，跨部门缺少协作
   • 有些任务工期明显很长，太长的交付能力会让用户觉得你的承诺不靠谱
   • 敏捷要求我们对需求设定优先级，而不是统一对待所有需求，在人力有限情况下，我们更需要做有价值的需求。需求优先级的判定也是需要一些能力的。昨天在给全国分站培训上，有同事反馈一个下载报价单是乱码的问题，我问这个问题哪天反馈的。一问吓我一跳，已经提出一年了。会后我问了负责产品的同事，说是另一个部门的问题，但一直不解决。这个团队协作问题说到底还是大家对需求优先级的统一判断不一致导致。
   • 敏捷推崇延迟决策，推迟承诺，当我们决定把backlog池拉入需求阶段时才代表你开始承诺去做了。这不是说我们不要过早承诺去做，我们要做到理性的承诺，否则给予太高的期望，但你都没时间去做，这样就会带来负面的影响。而如果你一旦把这个需求拉入到了研发工作中就代表你开始承诺去完成它，你就要投入精力专注的去兑现你的承诺。

看板是一种很好的敏捷方法，但推行敏捷需要依据团队能力来设计，目前来看，广材网暴露的问题还有很多，看板后续还会不断完善，推行看板中的另一些要素，也希望对看板感兴趣的团队一起来践行，因为我相信全部门来践行看板所带来的价值会更大。