McDonald & Scrum
McDonald & Scrum

McDonald & Scrum

几天前去麦当劳的时候,见到一个领班模样的人在训斥一线员工,没听清楚具体是什么事情,就是觉得这样的一种管理模式或者说反馈模式非常的好,快速、有效、有针对性,然后由此联想到scrum

Scrum是一种敏捷方法,强调快速反应,讲求人的配合等等。而其团队组织方式是多功能型,由具有各种才能的人组成足以达成既定任务的团队。有清晰的工作目标,有一定的规范辅助,留给个人有一定的发挥空间,成员之间彼此协作,而scrum master则担当着现场督导的职责,确保团队能够获得完成任务所需的必要资源,以及遇到的障碍。

我所见到的麦当劳工作方式。前线的接待员会收集顾客需求,然后获取相应的食物,交付顾客,收费,完成一次顾客服务过程。而在这其中,接待员通过收银机确定食物选择后,其数据被及时交互到后台操作间,操作间基于此数据准备食物,并放入中间的食物通道,而食物通道有不同的编号,以分发不同类型或同类但口味等有变化的食物。由于整个过程的快速循环,on-shelf的食物流保持在相当低的程度,减少了因为食物变冷等造成的损失。当有接待员在获取食物时,其他人若有相同需求,可以直接通过话语告诉对方多获取一份,这可以看做是一种团队协作,而它可以减少服务所需时间。领班或其他的店堂人员会在整个店内巡视,及时发现需要加强或立即服务的事件,并控制整个局面,如二楼未整理的餐桌过多,阻碍了顾客就餐,或是有服务员的服务操作不规范等。

有时候进入夜间服务时间段时,其模式似乎有一定的变化。食物的准备没有冗余备份机制,而是完全依赖订单,当接待员下单后,先确定的单子首先获得食物,后下单则后获得,后方的操作台完全是一种on-demand的方式,由销售终端拉动。

而今天在上海逛正大广场的时候,看到那里的麦当劳又有一些不同,其接待员压根就不回头,专业的订餐员,有专门的人会获取准备好的食物。似乎是一种每个流程部分都有专门的人员在负责,而并非我在杭州常去的那个餐厅的接待员一样有更多的任务。我想这可能和餐厅的人流量有关,正大广场的人流量貌似比较大,如果接待员下单,然后获取食物,递交给顾客,那么下一位顾客等待被服务的时间就有些过于漫长。而有专人负责配餐,并送抵柜台的话,那么在接待员下好单开始服务第二位顾客的时间段里,配餐员也可以完成操作,配餐完毕,第一位顾客就可以得到食物了。更有助于快速的服务顾客,和较快周转。

那么这和scrum有什么关系呢?恩,也许没关系,也许有。scrum模式中的一些关键的工作方式和麦当劳体现出的这种模式有许多相同点。首先,团队是多功能型的,可以是多功能型的个体成员组成团队,也可以是不同专职的个体组成一个整体多功能型的团队。二,团队互相帮助,有共同的目标,如使顾客在设定时间内完成订餐过程,如在一个sprint时间段内完成选定的product backlog item。三,团队身边有一个有经验的高级人员,负责发现问题或障碍,并想方设法解决。四,团队成员间的中间产物可以呈现短时间的富余或短缺状态,但总体而言,是不多不少,比如开发人员可能开发出某段程序,而测试人员还没有设计好相应的用例,或是测试人员更早的设计了用例,等待开发人员实现所需的代码。

第五点,是我认为最重要的一点,我猜测有,但并没有很确切地看到麦当劳有这样的机制,那就是流程的状态实时查询或显示,而且是非常可视化,非常直观的方式。比如说,麦当劳完全可以统计出中午11点半到12点半之间,对于特级板烧鸡腿堡的需求量,可以有历史数据,也可以有当日动态数据,那么后台操作台可以根据此数据,做好一定的准备工作,为即将到来的就餐高峰准备好足量的汉堡,减少顾客等待的时间。而在scrum中,可以通过Continuous Integration(持续集成)等方法来达到此目的。如果在持续集成的系统当中,被执行的功能性测试用例都是基于用户需求的,那么在sprint开发过程中,不断更新的测试用例执行状况,就是对开发状况的一个直观展示。在持续集成中拥有单元测试案例的话,则可以获悉更小粒度的开发进度信息。抛开这些产品自身属性方面的反馈信息,工作人员角度也可以获得足够的信息。在每天的daily scrum,以及稍大项目中可能使用的scrum of scrums中,开发团队都会透露出详细的开发状况介绍,甚至包括情感性的描述“我们肯定能按期完成”。这些信息都能够给产品负责人或项目管理者(如果还有这个角色的话。。)非常直观的印象,从而可以为开发工作的顺利进展和如期完成提供所需的支持,或增加更多可以完成的任务。

但是,一个非常大的区别,至少我所处的项目环境和麦当劳之间的不同,是,麦当劳是零售业态,接待员直接面对的是顾客,也即终端用户,客户需求是零碎的、变化的、快速的、产生速率是变化的。他们递交的产品也是可重复的,每个产品个体的差异小到可忽略不计,且不存在后期维护成本,无需进行产品设计,也无需考虑后期维护及扩展的需求。而软件开发则不同,在一个大型系统的开发中,每个团队所面对的并非终端用户,一般是自己的上一级开发团队,比如系统平台开发团队的直接客户是应用层开发团队,而且作为一个复杂的系统,其客户需求通常是有组织的、大量的、少量变化的、产生速率恒定或受控制的。所递交的产品通常对整体重用性要求不高,必须考虑后期维护及扩展所需要的成本,并需要进行产品设计,以满足对扩展及维护的需求,降低后期成本

4条评论

fen 发表评论 取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据