Lean

那一年，我在西安。现在在深圳。但，时常怀念在西安的生活。 每到一个处吃饭（除了星级酒店），不管它是面馆、快餐店、排挡，还是路边小摊，我都会观察它们是如何经营的。 那一年，西安火车站旁，看上去非常普通的面馆，大概60平米左右，却使用了不一样的经营方法。让我一下子感觉发现了新大陆。 当时，在上火车前，想吃点什么。因为没时间，就直接走进了路边的一家面馆。面馆处于火车站正大门前的一个丁字路口边上，人流量自然没得说。 推开门，径直走向前台。可是前台就几个客人，再环视面馆，座位基本都满了。当我走到前台时，那几个客人已经开始找座位。我跟前台说：你好，来碗臊子面。 前台：你自己找个座位先坐下来，然后叫服务员点菜。 我：不用拿号吗？ 前台：不用。 然后，我一会儿就找到一个空座位。心中有种侥幸感：还好有座位。即使，我是与一个看起来很凶的大汉共享这张二人桌。 现在想想，这是多年在火车站旁消费带来的条件反射：在火车站旁，有位置就不错了。 桌上有菜单和基本上每个“快餐店”都会有的桌号。 我举手示意服务员，她1分钟左右就过来了，后来观察到，她是专门负责点餐的。 点完就马上付钱。 这位点餐员提醒我：你千万不要乱换座位，要不等下找不到你的。 面也没有等多久就上来了。这时，我才发现，店里，没有我们经常听到的大声吆喝：5号，5号，臊子面……看到送餐员从厨房后面出来，直接就走到了相应的客户桌上，十分精准。 当我吃完，要去赶火车时，我也不担心要排队买单。老板也不用担心我跑单。因为在点餐时已经付过了。 这家面馆，在我看来属于快餐店一类。现在我们来看看这店与一般的快餐店有什么不同： 它没有客户号，只有桌号 这样，送餐时，菜，桌一一对应，节约送餐员的送菜时间，也缩短了客户取餐的时间。 一般的快餐店送餐员全店的找“4号客户”，实在找不到，就大声吆喝，这给我们带来不好的用餐体验不说，我们的快餐店的生意居然寄托于服务员的眼力和短时间记忆力！ 客户先找座位，再点餐 做面是需要时间的，并不是你点了，马上就可以拿到。像KFC，在前台完成点餐，取餐，买单所有流程的。在面馆里不适合。 后来，我也就明白了，为什么有些快餐店会把饭类和面类分到不同的点餐通道，我想就是因为饭类和面类之间从点餐到取餐之间的速度是不一样的，需要分开处理。 多说一句，我们做软件架构时，也会把慢速流程和快速流程分开处理。 先付款，后消费 平时，大家都喜欢先消费，后付款。一是不知道还会不会加点，二是，这种消费体验更好。想想哪个高级酒店，不是先消费，后付款。 但是对于一家火车站旁的小快餐店，是不成立的。第一，火车站旁，大多数人，想要的是快点走，点了又点的概率太小；第二，火车站旁，消费者要的是快，而不是“更高级”。 “先付款”节约了完成消费时的计算时间和叫服务员买单时间。最后，节约了客户的时间。至少，我们的生意，也不用寄托于服务员的记忆力。 最后的好处是：火车站，鱼龙混杂，“先付款”，防止了跑单。 给我带来了什么启示 后来，我见识不少火车站旁的快餐店，但是基本上都会有手托的服务员，费时费力的找“客户号”。我知道西安火车站旁的这一小面馆的经营方法，并不是行业的“共识”。虽然每家店都想赚更多的钱。 这家小面馆的经营方法并不一定适合于所有的面馆。况且，世上有没有适用于所有面馆的经营方法，也是个问题。 但是，这家小面馆，一定是看清了自己的价值流：从客户进店，到客户出店。然后，不断优化这个价值流的节点，使其更顺畅，最终实现赚更多的钱。 对于我们做软件产品的呢？我们的价值流又是什么呢？好问题！ 另一个问题：发现价值流后，如何持续优化？我的答案是：现场管理。但是软件产品的生产过程，如何做到现场管理呢？好问题！ 如果一个不懂软件开发的人，如何管理好软件产品生产过程呢？好问题！ 最后提一个问题：这家面馆的经营方法算不算精益？ 图片来网络。如果侵权，必删。

传统软件开发方法 传统软件开发方法的共同特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。 到了上世纪90年代初，CMMI和PMI项目管理知识体系成为传统产品开发管理方法的典型代表。 我个人认为，传统软件开发方法的假设是：需求确定后就不会变了。然而，时代变了，这个假设是否还站得住脚？ 从另一个角度看，我们也就理解了为什么项目经理会对需求变更如此痛恨。你想嘛，项目经理的职责是让项目按时完成（想想KPI怎么定的？），立项后，工期就定死了，我一开始把项目计划做好了，需要变更了，你让我的项目如何按时完成？ 所以，具有这样思维模式的项目经理面对敏捷和精益这样的概念时，第一念头就是：它们能帮助让项目按时完成吗？ 当然，我并不是说项目按时完成不重要。而是想表达：我们应该清楚自己最终追求的是项目按时完成，还是做好的产品服务用户。 那么，如果“需求确定后就不会变了”这个假设不成立，我们的产品开发应该如何应对呢？ 《精益产品开发》 从原则，方法，实施三个方面来说明我们应该如何应对。 产品开发与生产制造的不同 产品开发相对生产有两个最本质的不同：其一，价值的不确定性，它决定我们无法一开始就明确定义价值，或者说“价值定义”的过程应该是一个持续探索的过程，因此才有了精益创业、精益数据分析等实践体系；其二，过程的不确定性，如每个任务的处理时长不等，且可能在过程中发生变化，它决定了价值流动的管理和改进方法不同，如产品开发中看板方法就与生产中的十分不同。 在软件行业，产品开发与生产的本质不同，深有体会啊。生产常常有批量的含义，而产品开发没有，你听说过“批量生产软件”的说法吗？ 部署与发布的区别 为更好地管理发布，团队应该区分发布和部署。部署属于技术范畴的概念，发布是属于市场范畴的概念。它们具有如下意义： 部署（deployment）：将软件安装到一个特定的环境 发布（release）：让一个或一组特性对应用可见和可用。 上家公司时，我们每周会部署两次，没做完的新功能，我们同时会部署上去，只不过，用户是看不到这些功能的，应该feature toggle是off的，偶尔也会向部分用户打开。 等我们确定功能完全OK了，就会把相应的feature toggle完全打开，所有用户就可以看这个新功能了。 这是区分了部署和发布两个概念的做法。 而现在所在家公司由于历史原因，服务器要跟着APP的版本走。APP端的人每个月发布一次，以至于管理人员也认为服务器端也必须一个月发布一次。导致的问题之一就是服务器端一次性部署大量的服务，不论这些服务是否有变更接口外在行为。 这是没有区分部署和发布两个概念的做法。 看板系统的设计、站会的设计 看板系统能全面地反映需求交付过程吗？ 瓶颈和问题能在看板墙上得到即时体现吗？ 团队可以根据看板墙上的信息协作和做决定吗？ 只要问这三个问题，你就知道你的看板系统设计如何。 何勉老师在书提到了一个案例：一家企业网盘的需求被两端——前端和后端——分别实现。团队也按前端和后端来区分。每个团队还有各自的测试人员。 面对这样的情况，我们如何处理，才能更好的交付产品价值呢？我目前所在公司也遇到同样的问题，一个产品的开发甚至涉及到服务器端、APP端、Web端、硬件端。 一个需求同时涉及这么多的端。看板系统如何设计？如何站会？如何测试？好问题。 从这本书里，我得到的答案是： 只要这个需求的涉及人员的任务卡片都应该放在同一个看板上，有时甚至包括市场人员。 站会时，只要这个需求的涉及人员都应该在一起站，有时甚至包括市场人员。 小结 这些只是一部分，书中的很多想法击中了我。因为现实，我就遇到这样那样的问题，苦于不知如何解决。 另，回过头来看，不管传统软件开发方法，精益，还是敏捷，我们都应该始终记得不论开发、测试、项目管理人员，公司决策层，我们的最终目标：为用户提供更好的服务。按时完成任务只是我们达到这个目标的手段。 但是如何才能达到这个共识呢？留给读者一个问题。