> 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年那个春天的会议之前说这个词和之后是会有一些理解上的差距。像很多其它词一样，这种定义属于无中生有。如果就上面举过的例子，我那个通讯运营商，当初在几家里还挺敏捷的。这是个形容词，是横向比较。第二家如果就限于那条小街上我吃过的馆子，也是挺敏捷的，因为至少投诉也好，建议也罢，有回应。但是如果将敏捷当成一个动词，只有第一家还不错。我有感受到他们有一种状态，就是想做更好的饭馆。他们也在这么做。我记得在某个关于“敏捷”的调查中，我曾经的几个问题： * 你们想做的改进有哪些？ * 你们有哪些举措？ * 这些举措得到的改进效果有哪些？ 问完之后，很多人都在顾左右而言他。 没想过做更出色的自己，老想着拿原来的方法来解决新问题。或者说，老是敢发誓，什么包按时上线、包提效、包如何如何，却不提如何验证，闪转腾挪避雷。又或者，虽然现在情况所限，只能小步调整，却偏偏要一下想清楚，结果始终不能出手的。又或者，虽然敏捷宣言里讲是“更好的方法”，但还是认为现在就“敏捷”了的。 那么，敏捷真是不存在了。
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.oulan.com/82n/yi-xiao-bu/management/agile-does-not-exist.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.