今天来聊聊CRB这玩意儿。刚开始接触CRB的时候，我也是一头雾水，听着就挺高大上的，不知道是个后来自己上手捣鼓了一阵子，才算摸着点门道。
就喜欢自己瞎琢磨。一听说有CRB这个东西，我就想着，这到底是啥？是不是跟那个什么商品指数有关？还是别的什么新鲜玩意儿？网上的说法五花八门，看得我眼都花了。
我具体是怎么捣鼓CRB的
第一步：先搞清楚我要干
我发现，这CRB在不同地方说的是不一样的东西。有的是说商品研究局指数，有的说是啥建设项目评估，还有的说是什么网页引用质量。得，这么多说法，我得找个自己能实践的。
第二步：定个小目标，开始试。
我的目标很简单，就是想看看我们团队在做一个小项目的时候，哪些环节配合得哪些地方老是卡壳，然后大家一起合计合计怎么改进。我就把这个过程叫做咱们团队的“CRB实践”。
具体咋弄？
- 收集信息：项目一阶段跑完，我就先拉着大家伙儿开个小会。注意，不是批评大会，就是让每个人都说说，自己在这个阶段感觉哪儿最顺，哪儿最不顺，有没有啥特别想吐槽的或者特别想表扬的。我拿个小本本，刷刷刷地记下来。
- 整理归纳：会后，我就把收集到的这些七嘴八舌的意见整理一下。比如，好几个人都提到某个文档更新不及时导致返工，或者某个工具特别难用，拖慢了进度。这些就是“痛点”。也有人说某个同事特别给力，帮了大忙，这些就是“亮点”。
- 分析原因：针对那些“痛点”，我就琢磨，为啥会这样？是流程问题？沟通问题？还是资源不够？有时候自己想不明白，就再找相关的人单独聊聊，多听听他们的看法。
- 找出改进点：分析完了，就得想办法了。比如文档更新不及时，那是不是可以指定专人负责，并且规定更新频率？工具难用，能不能找个替代的，或者组织个小培训？
第三步：落地执行，再回头看。
找出改进点之后，不是说就完事了。关键还得去执行。比如我们当时决定，每周五下午固定半小时，大家一起快速过一下各自的CRB（就是各自负责模块的进展和问题），确保信息同步。这个小小的改动，效果还挺明显的，至少扯皮的事儿少了不少。
然后，过一段时间，比如一个月，或者一个项目周期结束，再来一次这样的“CRB回顾”，看看之前定的改进措施有没有效果，又出现了啥新问题。就这么循环往复。
捣鼓CRB的一些体会
别把CRB想得太复杂。甭管它本来的定义是关键是看它能不能帮你解决实际问题。我就把它当成一个“复盘和持续改进”的工具来用。
要让大家都参与进来。 这不是我一个人的事儿，也不是领导的事儿，是团队每个人的事儿。只有大家都愿意说真话，愿意一起想办法，这CRB才能真正跑起来。
再有，从小处着手，持续迭代。 一开始别贪多求全，指望一下子解决所有问题。找一两个最突出的问题先改起来，看到效果了，大家才有信心继续下去。
也是最重要的，就是实践，实践，再实践！ 光说不练假把式。我这套土法CRB也是在实践中一点点摸索出来的。一开始可能不完美，甚至有点乱，但只要坚持做下去，不断调整，总能找到适合自己团队的路子。
对我来说，CRB不是一个冷冰冰的缩写，而是我们团队一起努力，让工作变得更好的一段经历。虽然我这个“CRB”可能跟教科书上的不一样，但它实实在在帮到了我们。这就是我今天想分享的，一点小小的实践心得。
还没有评论，来说两句吧...