资讯频道 → 非技术
阅读更多

1顶
0踩

非技术

转载新闻 工欲利其器, 必先善其事

2015-10-15 11:11 by 副主编 mengyidan1988 评论(0) 有4344人浏览
敏捷 编程



标题没有写反, 意思是如果我们想要推行某种理念/实践/工具, 必须先帮助客户把事情搞定.

这并不新鲜, 通俗讲就是必须先赢得客户信任. 但并不是说不择手段, 今天讲的是考虑客户实际情况, 不要一开始就追求理想效果, 而是循序渐进, 采取的是不是”最标准最正确”的做法不重要, 只要比之前有进步, 让客户感觉到成效就是很好的基础.

这么说比较空洞, 看几个例子：
引用

某组织引入敏捷, 并请 ThoughtWorks 帮助其实施落地. 在开始几天的站会上, 团队成员通常就某问题的细节讨论了起来, 有问有答, 你来我往, 甚是热闹. 此时作为咨询师的你我, 该怎么做呢? 

依然在站会上, 同学 A 说昨天上午碰到一个问题, 想请同学 B 帮忙看看. 注意是昨天上午. 此时作为咨询师的你我, 该怎么做呢?

其实一开始我是拒绝这种情况的. 我会打断说, 细节问题下来再讨论, 也会语重心长的跟同学 A 说, 有问题要及时请教. 然而效果呢? 效果是过了一段时间之后, 团队说站会没用.

原因呢? 原因至少有两个. 一个是我们交给团队的关于站会的要点, 团队短时间内并不能完全领会, 站会只是简单汇报自己的工作流水账, 对其他人没有什么价值. 第二个原因更重要, 就是我们打断的, 中止的, 建议提前的, 那些沟通, 并没有发生.

客户的团队是不具备沟通的习惯的. 即使我们并没有参与客户之前的工作方式中, 也可以这样断言. 因为如果你经常沟通的话, 一定会在长期的练习中学会如何沟通, 哪些该详细哪些该简略, 如何让别人更容易理解. 可是我们并没有感受到这一点, 因此客户的团队之前是没有沟通的习惯的.

那么对于不具备沟通习惯的团队来说, 有个场合能让沟通发生, 让大家讨论起来, 就已经是进步了, 就已经很有效果了. 我们要做的, 是肯定这种效果, 并把它归功于我们引入的实践, 比如站会. 所以现在我会静静的等着大家讨论完, 然后关键的是站会结束后必要的引导：
引用

大家刚才讨论了很多, 有多少人觉得有收获, 了解了之前不知道的信息, 比以前更清楚了?

一般很多人都会点头. 再接着问:
引用

是否对你今天的工作有帮助?

回答通常依然是肯定的. 然后就可以总结陈词了:
引用

嗯, 我们就希望每天的站会大家都能获得一些新的信息, 请求队友的帮助, 减少后续工作的障碍. 挺好, 继续保持。

几次之后, 我观察到的现象是:
  • 团队很积极的参加站会, 到点就有人喊.
  • 讨论比较充分, 讲自己碰到问题的比较多
  • 而居然有人开始注意到时间问题, 效率问题, 团队其他人的相关性问题, 会主动出来调节说: 会后再单独讨论吧!

就算团队自己意识不到效率问题, 我们此时再说, 细节问题线下讨论, 等等, 团队也容易领悟和接受. 因沟通习惯已经有一定基础, 无论是外界引入的调整, 还是自我调整, 都不会是揠苗助长.

类似的栗子还有很多:
  • 故事墙建起来了, 但平时没人挪卡. 那就先站会上集体挪吧, 保证站会后任务状态是最新的, 团队成员都能看到距离迭代目标还有多远.
  • 用户故事的名头喊出来了, 但故事上没有用户价值. 那就先保证有从用户角度出发的 AC 和测试用例吧.
  • 回顾会议上问题很多, 那就先挑一个短期有效果的先做起吧.
  • …

如果你还担心, 日后有人质疑你当日的说辞, 那么你只需要开场时补上一句: 大家的做法有很多改进的空间, 但我们一步一步来…

抛弃了对自己在客户心中伟光正形象的顾虑, 我们会获得更大的自由, 对客户更有帮助。

本文来自：TWInsights
作者：李光磊
  • 大小: 42.1 KB
来自: TWInsights
1
顶
0
踩
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Global site tag (gtag.js) - Google Analytics