取消周报，拥抱新看板

概要：

探讨研发管理特点，剖析周报制度和看板方法利弊，提出iSoftBook看板与运行机制，统一研发任务管理与周报制度，探索一种高质高效的研发协同机制和工具。

目录

一、引言

二、研发管理挑战

2.1、不可见性

2.2、难预设性

2.3、高浪费性

2.4、易倦怠性

三、周报管理制度

3.1、周报制度的价值

3.2、周报制度问题

四、看板管理方法

4.1、核心特性

4.2、看板方法的价值

4.3、看板方法的问题

五、iSoftBook看板

5.1、设计目标

5.2、设计原则

5.3、布局结构

5.4、多维视图

5.5、运行策略

5.6、度量管理

5.7、推荐实践

六、结论

参考文献

---

一、引言

2020年7月，阿里巴巴集团取消员工周报。一石激起千层浪，消息瞬间冲上头条。

任何制度的变动都是高成本的尝试。研发公司为什么实行周报？又为什么取消周报？取消周报之后又当如何实施研发管理？

研发管理是可持续研发效能和质量提升的根本机制。本文探讨研发管理特点，剖析周报制度和看板方法利弊，提出iSoftBook看板与运行机制，统一研发任务管理与周报制度，探索一种高质高效的研发协同机制和工具。

二、研发管理挑战

2.1、不可见性

IBM大型机之父Fred Brooks指出软件是不可见的和无法可视化的[1]。软件是抽象逻辑实体，不具有空间形体，难以利用几何抽象反映其总体结构。即使绘制了软件的控制流、数据流、数据结构等视图，但也仅是表达了软件的某个方面，就像盲人摸象一样，难以从这些叠加的视图上抽取出软件的总体结构。软件研发很多时候都像编制那件具有魔法的“皇帝新衣”，看不见，摸不着。

2.2、难预设性

敏捷方法开拓者、软件开发教父Martin Fowler在“新方法学”中指出[2]：软件研发的绝大部分工作都是设计活动，甚至编码都是设计活动，而非建造活动。建造活动能基于设计图纸制定详尽的计划并机械执行。而设计活动是创造性活动，难以制订详尽的计划和预算，是难以预设的。软件研发过程中再强大的管理者、再大费周章的计划工作也难以为工程师制定详尽的开发任务和时间计划。

2.3、高浪费性

《精益软件开发》[3]、IEEE论文“Software Development Waste”[4]等利用详实的调查数据，分析和总结了软件开发中的大量浪费，包括构建不需要的特性、返工、任务切换、知识流失、无效沟通、不必要的复杂解决方案等。基于调查数据统计，软件研发浪费的时间或者成本甚至会占到40%以上。

2.4、易倦怠性

研发工程师面对复杂的代码、糟糕的文档、不切实际的期望，极易产生倦怠。知名的 Python Requests库的开发者 Kenneth Reitz指出[5]：倦怠十分狡猾，它悄然而至。缺乏时间管理易于产生倦怠。如果你有一个可以在 2 小时内完成的工作，但你有 3 小时的可用时间，那么你会自动花掉所有可用的时间来完成它，这是人类的通病。而自我管理会提升员工的参与性和工作卷入，降低倦怠。 面对软件研发不同于传统工程的显著特点和挑战，究竟采取怎样的研发管理体系呢？

三、周报管理制度

周报是研发组织普遍采用的一种管理方式。不止阿里，京东、去哪儿、苏宁等知名的互联网企业都有相对严苛的周报制度。更甚者，有公司还奉行日报制度，要将每天的工作都汇报给上级。

3.1、周报制度的价值

(1) 沟通交流

周报是员工和上级沟通交流的重要渠道。良好的周报可以在一定程度上消除研发工作的不可见性、难预设性所致的上下级间的信息不对称，减少管理盲区，降低软件研发中错误特性构建、质量缺陷而致的返工等浪费。

(2) 工作复盘

周报是工作总结复盘的有效手段。周报帮助员工回顾工作执行环节，总结经验、反思难点，持续改善和提高员工工作能力。通过浏览、评论等方式，周报成为团队相互学习、迁移经验、知识沉淀的宝贵财富和智力结晶。

(3) 降低倦怠

周报是员工自我管理的重要方式。通过周报，员工在工作中更有目标感和计划感，用写周报倒逼员工不断思考和执行所承担的工作，而不至于做一天和尚撞一天钟。上级通过周报检查员工的工作饱和度，督促员工做好时间管理，降低研发过程中的职业倦怠。

3.2、周报制度问题

很多公司都在使用周报进行研发任务管理，但真正把周报制度有效用起来的公司并不多。更多公司把周报变成了一个流水账工具，既浪费员工时间，更降低工作效率。周报制度存在的主要问题包括：

(1) 任务割裂

员工承担的任务彼此关联并形成整体。但每位员工站在个人角度，通过周报汇报各自承担的工作任务，造成工作任务的割裂、离散、重叠，只见树木，不见森林，上级难以总览工作任务全局执行情况，难以对周报进行有效处理。

(2) 执行走样

管理者常站在管理角度，将周报作为评判工作态度、证明工作量甚至与绩效考核挂钩的工具，周报失去了它的本质目的和作用。因此员工整理周报时，易添油加醋，甚至美化、虚报工作任务。久而久之，周报要么演变成一种暗中较劲、影响工作效率的累赘，要么演变成一种固定格式、定时上报的形式主义。

(3) 工具乏力

利用Excel或Word设定周报模板和书写周报，通过电子邮件、即时消息、OA系统等上报周报，如企业微信和钉钉都有周报功能模块。但该类工具体系下，周报只有管理者可以看到，其他同事难以看到并进行浏览与评论。不仅管理者评阅麻烦，同时周报的沟通协作、相互学习、迁移经验等功能大大削弱。

四、看板管理方法

面对研发的不可见性、难预设性，业界开始设计和使用各种各样的“人人可见的看板”，实现项目状态共享和可视化，并与敏捷方法、精益方法等理念和实践相结合，增进研发过程的控制与改进。

图1 敏捷看板

图2 Atlassian Jira 看板

2010年，David J. Anderson深受大野耐一的丰田生产方法（TPS）、高德拉特的约束理论（TOC）、戴明的质量管理以及敏捷开发的影响，在奠基之作《看板方法：科技企业渐进变革成功之道》提出并完整阐释了现代研发领域的看板方法[6]。

图3 David J. Anderson 精益看板

4.1、核心特性

David J. Anderson的看板方法将软件开发过程视为一种价值流，核心机制是限制在制品（work-in-progress）的拉动机制。其实施的5项核心特性是：

(1) 可视化工作流程

确定流程控制的起点和终点，分析工作项类型，运用看板绘制团队实际工作流程，可视化展示工作过程和用户价值流动。

(2) 限制进行中的工作

设定每个过程状态下同一时间内允许的最大任务数量，限制并行工作的任务数，减少同一状态同一时间内任务的堆积。

(3) 度量和管理流动

追踪看板中的工作任务，运用累计流图等度量任务前置时间、WIP限额、准时交付率、交付速率、流动效率及其变化趋势，增强看板系统的可预测性。

(4) 明确过程策略

将过程视为主导行为的一组策略集合，通过明确定义的一组策略来描述过程。明确的策略、透明性和可视化三者结合，赋能团队成员自我决策，增强领导层信任。

(5) 识别改进机会

运用约束理论、精益方法、统计过程控制等模型方法识别和消除瓶颈、降低浪费、管理变异，驱动研发过程持续改善式的变革。

4.2、看板方法的价值

(1) 增进研发过程可视化

看板是一种目视管理的工具，清晰呈现工作进展、任务滞留时间、每个人的贡献和负载、团队的负载能力等，增进研发过程透明度和能见度，降低了管理和沟通成本。如果你看不到，你就无法控制。

(2) 持续改进研发流程

看板方法与团队现有开发流程无缝结合，不是直接改变现有开发流程，而是帮助团队识别过程阻塞和瓶颈，激发协作、消除阻塞，实现研发流程的渐进式改良，降低变革实施阻力。

(3) 激发团队自组织

基于人人可见的看板，开展任务协调，建立职责共享文化，带来共同愿景、协作、自组织、自我驱动等正向激励，构建学习型组织，提升组织的社会资本。

4.3、看板方法的问题

(1) 模型适用受限

看板方法源自制造业，遵循流水线生产中在制品数量限定和任务拉动规则，并在微软等大公司得到实践。该方法适合于高度自组织、具有强力话语权、成员能力均衡的研发团队，适合具有市场主导权的产品研发。但在当前这个瞬息变化的商业时代，研发普遍呈现更高的变化性和不确定性，看板方法难以适用。看板方法提出多年以后，其宣称的目标：保护研发团队免受无尽需求困扰、实现持续稳定的研发步调，在很多组织至今未能实现，是该模型适用受限的证明。

(2) 过程单一固定

看板方法借鉴制造业的流水线生产方式，实施时需要把团队当前的流程绘制到看板上，可视化团队当前的研发流程，从而看板上通常呈现出如分析、设计、实现、测试、部署等阶段构成的一套固定研发流程。但研发团队中，因任务类型、质量约束、执行阶段等的不同，各研发任务常具有不同的研发流程，看板方法绘制的固定研发流程难以适用于多变的各类研发任务。看板方法虽然运用泳道、工作项类型、服务级别等方法差别处理不同性质的研发任务，但它们都置于同一固定的流程之下，不能根本改变看板过程单一固定的问题。

(3) 管控双重冗余

看板方法通常需与研发任务管理系统并行运行。看板方法聚焦研发任务可视化、协调和发现研发流程瓶颈并进行持续过程改进。研发任务管理系统实现大粒度研发任务分解、跟踪、度量、报表分析等工作。看板方法虽然提出了两层系统扩展机制，但其二维化的结构致其难以处理大粒度任务的层次化分解和组织。看板方法与任务管理系统虽各自聚焦研发工作不同方面，但双重运行、并行管控，带来了附加的冗余、开销和复杂度。

五、iSoftBook看板

iSoftBook是一款简单、灵活、丰富的集成研发平台，协同实现敏捷项目管理和自治知识管理。iSoftBook平台综合考虑研发任务管理和周报制度需求，设计了一套新的看板方法体系。

5.1、设计目标

面向研发管理特性，设计一套可视化看板方法体系，统一研发任务管理、周报制度和看板方法，提供一套高质高效的协同研发机制和支撑工具。

5.2、设计原则

(1) 层级结构

David J.Anderson看板展示原子任务及其执行状态。iSoftBook看板需支持任务的层级分解和状态的层级展示，其不仅实现任务管理所需的大粒度任务分解和多任务的结构化组织，并且形成任务的不同抽象层级而自然实现面向管理层的执行汇报。

(2) 聚焦时间

David J.Anderson看板采用任务拉动机制而弱化时间控制。iSoftBook看板视时间为研发管理第一要素，跟踪任务执行的开始时间、结束时间和延期状态，运用结束时间作为任务优先级，通过任务延期状态反映执行瓶颈。

(3) 隐式过程

David J.Anderson看板显示绘制任务的统一执行过程。研发不似制造业具有稳定、长线、复杂的执行过程，研发过程具有多样性和迭代性，通常在分析、设计、实现、测试、部署等几个过程中迭代。故iSoftBook看板不显示规定任务的执行过程，而是通过各个任务分解而成的子任务、及子任务执行的时间序列反映任务的执行过程，即一个任务的执行过程隐式蕴含于其子任务的执行过程。

(4) 自然迁移

David J.Anderson看板可视化现有执行过程并与现有任务管理系统结合以降低推行和变革阻力。任务分解、管理和追踪是研发团队的基本工作，iSoftBook看板直接从承担任务管理这一基本工作入手，统一任务管理与看板管理，无需单独实施看板方法，并不改变现有执行过程且支持过程持续改进，实现团队管理无阻力的自然迁移。

5.3、布局结构

iSoftBook设计一张电子看板，管理研发任务并可视化任务执行状态，其布局包括任务执行区、描述区、资产区和工具栏。

图4 iSoftBook看板

任务执行区：显示任务承担人、执行开始时间、结束时间、任务状态盘、任务计划人和计划时间等信息。任务状态盘显示和控制任务执行状态，并利用灰色、黄色、绿色等颜色反映任务正常执行、延期开始和延期完成及完成百分比。

任务描述区：编辑和描述任务具体信息。

任务资产区：关联执行任务所需的输入和输出的文档、提交等资产。

任务工具栏：提供任务折叠、展开、创建、编辑、删除、关注等操作的工具按钮。

5.4、多维视图

iSoftBook看板不仅通过层级任务的折叠与展开，实现高层任务展示和下层任务钻探，并提供丰富视图，从不同维度可视化展示项目执行状态。

(1) 全局视图：展示项目近期全体任务的逻辑组织和执行情况。

(2) 个人视图：展示项目中本人近期承担的任务和执行状态。

(3) 成员视图：分组展示项目中各成员近期承担的任务和执行状态。

5.5、运行策略

运行策略是看板的核心实践。iSoftBook看板聚焦协同和交流，制定并实施简单而明晰的运行策略，协调看板上任务的操作，赋能团队成员在规则约束之下实现自组织管理。

(1) 全员计划法则

项目团队成员皆可创建顶层任务及任一任务的子任务，并仅可管理自己所创建的任务，包括对其描述、删除、指派承担人和计划执行时间等。

(2) 双向制衡法则

任务承担人根据任务执行实际情况，负责任务在“ToDo”“Doing”、“Done”三个状态之间推进。任务计划人或项目成员能评审任务执行情况，对任务执行状态进行逆向回退。任务的状态是任务承担人、计划人、评审人间制衡而达到的一个结果，保障任务完成的质量和状态的真实性，因为研发任务难以定义机械的完成标准并进行机械的验证。

(3) 统一管控法则

项目管理员对项目的所有任务进行全权管控，对项目成员计划的任务进行调整和完善，对任务承担人和计划人双向制衡过程中的冲突进行裁决， 具体包括任务增加、删除、修改、任务承担人、执行时间和执行状态等的调整。

(4) 组织检视法则

项目所在组织部门的管理者及其上级管理者能够访问项目的任务看板，查看项目任务执行状态和近期工作计划安排，掌握项目执行瓶颈和存在的问题，从而起到周报制度的效用。

5.6、度量管理

iSoftBook看板统计任务近期执行情况并可视化展示。包括近期完成任务数、正常执行任务数、未计划任务数、延期开始任务数、延期完成任务数，并综合成为一个分数量化执行情况。并针对单个项目、用户所管理项目、所参与项目、所管理人员等维度提供任务仪表盘，从不同抽象层次、不同方面统计任务执行情况。

图5 iSoftBook看板仪表盘

5.7、推荐实践

运用iSoftBook看板和其运行策略，根据看板中任务粒度、任务性质、时间跨度、是否明确规定任务完成时间等而形成不同的管理实践，在团队管理与员工赋能之间进行灵活平衡，支持自顶向下和自底向上的融合管理，实现项目可视化敏捷管控。

(1) 严格管理模式

任务计划人详细规定任务和子任务及其完成时间，时间计划精确到天，任务承担人遵照计划的任务与时间执行。

(2) 高层管理模式

任务计划人只计划高层任务和其完成时间，时间计划精确到周、两周或月。任务承担人自己制定子任务和完成时间并执行。

(3) 开放管理模式

任务计划人只提出高层任务或者其子任务，但不计划任务的完成时间。任务承担人需自己计划高层任务和子任务的完成时间并遵照执行。

(4) 评审管理模式

任务计划人只提出高层任务或者其子任务，他和任务承担人都不计划任务的完成时间。但任务承担人记录任务实际执行的开始时间与完成时间，供管理者与团队评审。

(5) 自主管理模式

项目组团队成员自己提出高层任务和其子任务并成为任务的计划人，团队成员自组织承担任务并计划任务的开始时间和完成时间，项目管理人仅在必要时对团队制定的计划进行完善和调整。

六、结论

本文分析了研发管理的不可见性、难预设性、高浪费性、易倦怠性等特性，剖析了周报管理制度和看板管理方法的价值和问题，指出赋能员工、提升工作透明性并进而实现员工的“自我控制”、来自同僚的”压力控制”和“爱的控制”等“微妙的控制”机制，是研发管理的核心之道。

据此设计了iSoftBook看板，阐释了iSoftBook看板的设计目标、设计原则、布局结构、多维视图、运行策略和推荐实践。iSoftBook看板聚焦时间，整合了看板方法、周报制度和任务计划三项功能，实现了层级结构和隐式过程而变革了David J.Anderson的精益看板。在快速变化的新商业环境下，为了减少官僚主义成本并减负一线员工，iSoftBook看板为研发组织寻找更加敏捷和卓有成效的管理机制与工具进行了一个探索，并提供自由研发云平台和社区版研发平台，欢迎体验与使用。

参考文献

[1] Brooks, Frederick. "No Silver Bullet:Essence and Accidents of Software Engineering," IEEE Computer(April 1987"), PP.10-19.

[2]Fowler, Martin . "The New Methodology." Software World 36.1(2005):p.3-6.

[3] M. Poppendieck, T. Poppendieck, Lean Software Development – An Agile Toolkit for Software Development Managers, Addison-Wesley, Boston, 2003, ISBN 0-321-15078-3.

[4]Sedano, Todd , P. Ralph , and Cécile Péraire. "Software Development Waste." IEEE/ACM International Conference on Software Engineering IEEE, 2017.

[5] Kenneth Reitz. The Reality of Developer Burnout. https://speakerdeck.com/kennethreitz/the-reality-of-developer-burnout,2020.

[6]David J. Anderson.看板方法:科技企业渐进变革成功之道.华中科技大学出版社, 2014.