> For the complete documentation index, see [llms.txt](https://www.oulan.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.oulan.com/82n/yi-xiao-bu/management/agile-does-not-exist.md).
# 吃饭、协作和敏捷不存在
大众点评变成Lv8之后，写评论的动力反倒是少了。一个是自己做饭的次数多起来，另一个是现在的饭馆着实没有什么可写，同质化严重。直到前几天吃了一家，今天吃了另一家，两家一对比之下，还真的是有点不一样。所以动了写一写的念头。
## 排队截止、站会和即时调整
先来说说第一家。这一家的口味是不错的，吃饭的场地和器皿配置也很有格调。不过让人印象深刻的有3个点：
1 排队截止。现在很多商家都有排队叫号功能了。这家会有些区别，就是叫到一定程度，就截止了。因为会超出他们的服务时间范围。按照他们的解释，您就无法得到充分的服务了。
2 站会。在开工之前，很多商家都会开站会。还有的形式搞的很多花样，比如绕着商圈跑步之类、喊口号之类。这家的方式是很安静的那种，路过的时候听到了几句，好像是在围绕发生的问题和改进进行的。
3 即时调整。服务这家做的是非常到位的。比如菜品到了一定程度，就会有人上来撤盘或者换小盘。锅底汤少了很快就有人来添汤。茶水也是，基本不需要呼喊服务员。虽然一个服务员要服务很多桌，但好像他们并不忙乱。而且很有意思的是，店长在的位置会有个小的即时调整的沟通。比如店长如果发现什么问题，就顺便把相关的人叫到一起直接调了。比如我们要加餐巾纸，送过来的没有太及时，那边发现后不单把餐巾纸送来，还顺道把我们的水果换成了冰的。
## 干等、次序和无动于衷
再来说说第二家。
也很典型。
怎么说呢？我过去的时候他们其实没有多少桌客人。门口的服务员是不少。很热情。落座以后验了团购券就开始等待。当然干蒸菜需要时间这没问题，可是真没有预期需要花多长时间。大约过了20分钟终于上来一道青菜。然后就过来提醒米饭要自己盛，然后过去了又提醒要用自己桌上的碗（因为那边没有盛米饭的碗）。以为荤菜很快就上了就盛好米饭等着，但是又过了10多分钟仍然没有来，菜和米饭都凉了。于是问服务员。态度是很好，不过还是要等。大概是装备有些问题云云，员工是新员工云云。说要送瓶饮料，结果我一句我也不是为了一瓶饮料，就不提了（哈哈，我可不是拒绝啊）。
## 什么可以改进
可改进点倒是和他们有交流，比如：
* 他们可以自己体验一下这个吃饭过程（服务员自己也要吃饭，把过程中的问题记录一下就好了）。不过呢，可能会有刻板印象，因为他们操作设备很熟悉了，去吃饭的人不一定，一个操作不好，就有点尴尬
* 客人落座后应该有个提醒，就是本店非预制菜，大概一道菜需要15-18分钟。这样客人等待有个预期。虽然店内配了小吃，不过是调味料，比如辣椒酱和咸菜，客人等待的时候这些不适合
* 关于盛饭，最好由服务员代劳。虽然客人可以自取，但至少在盛饭环节负责说如何干的服务，可以主动参与一下最好
* 桌子上应该有个可以调整盘子位置的工具。那个工具目前只有服务员才有，我想调个位置，热盘子+桌面，让人简直不要废太多力气。而服务员好像不知道什么是就近原则，我那道荤菜多的一面一开始就给我放在了离我远的位置
* ……
收钱的妹子还反馈不错。不过由于没有啥回报，所以估计是鸡同鸭讲了。
我还根据他家的价位和进来的客人情况，想建议他们提供单人套餐。另外或者也可以参照第一家的情况可以即时复盘和调整。不过看他们的态度，就做罢了，这个我可以过一段时间再来验证一下。
关于改进，自然不是什么都可以改进，不是什么团队都可以改进的。
我们上面介绍的第一家店明显是支持改进的。他们也一直在改进。第二家店就如我所述，对于我来说不爽点和解决方案我都有所反馈，“听”起来他们也会调整，就剩下找时间验证了，虽然感觉起来够呛，不过事实说话。不过我知道有些店肯定是不会改的，这种例子太多，就不举具体的了。因为我一说他们有问题，得到的通常都是反驳或者推脱，至于后来是不是有人的位置被干掉了，就不得而知了。
## 角色职责、标准流程和协作策略
很好玩的是，第二家饭馆体验完，在星巴克正好遇到一位人力资源大咖在给小弟讲授绩效。听到了一些关键词，诸如设定绩效目标、工作职责，然后以终为始，定期检查绩效表现。
确实，这些都很重要。不过就这么看起来，关于角色职责和标准流程，第一家应该轻量一些，协作策略方面他们更多。而第二家，大概率协作策略方面少一些，对角色职责和标准流程的要求更多。
当然，角色职责和标准流程最重的我在修改手机套餐的时候赶上了。打电话都改不了，非要让去现场，甚至要给我转至某省公司去对接。最后说能给我打个电话处理，居然时效是24小时。就好像是有个人在那，你捅了一下，24小时才给一下反馈。不过他们的部门反馈是极快的，我打完电话，就接到两个电话问我满意度了。
是不是很有意思呢？我们再回到第二家的问题上，对于角色职责和标准流程，似乎他们是分割得很清晰的。所以可能在协作策略上他们可能存在下面的问题：
这样的团队，即便我们启用了一些措施，比如照抄第一家的流程，可能也未必会取得一样的效果。
## 敏捷不存在
举了这两家饭馆的例子。就第一家而言，不由自由地就让我想到了“敏捷”这个词。之所以用这个词儿的说法。是因为2001年那个春天的会议之前说这个词和之后是会有一些理解上的差距。像很多其它词一样，这种定义属于无中生有。如果就上面举过的例子，我那个通讯运营商，当初在几家里还挺敏捷的。这是个形容词，是横向比较。第二家如果就限于那条小街上我吃过的馆子，也是挺敏捷的，因为至少投诉也好，建议也罢，有回应。但是如果将敏捷当成一个动词，只有第一家还不错。我有感受到他们有一种状态，就是想做更好的饭馆。他们也在这么做。我记得在某个关于“敏捷”的调查中，我曾经的几个问题：
* 你们想做的改进有哪些？
* 你们有哪些举措？
* 这些举措得到的改进效果有哪些？
问完之后，很多人都在顾左右而言他。
没想过做更出色的自己，老想着拿原来的方法来解决新问题。或者说，老是敢发誓，什么包按时上线、包提效、包如何如何，却不提如何验证，闪转腾挪避雷。又或者，虽然现在情况所限，只能小步调整，却偏偏要一下想清楚，结果始终不能出手的。又或者，虽然敏捷宣言里讲是“更好的方法”，但还是认为现在就“敏捷”了的。
那么，敏捷真是不存在了。
