如何正确地使用在线协作工具

Posted by CnFeat on September 1, 2015

导语

最近一个月,团队正式启用Worktile作为新的团队协作工具。工欲善其事,必先利其器,所以我在使用这个工具之前,将官网文档和用户都看了一遍,感觉自己已经对这款工具十分熟悉了。

直到某天将一资深程序员大妈拉到项目中,才发现官方文档对协作工具的使用仅仅停留在工具使用层面,没有深入的心法层面,所以大妈他一上来看到我混乱的编排,就忍不住重构了,给出了一份使用规约,并附了一个正确的使用模板。

看过文章才知道大妈原来从2013年就受邀使用 Trello,并结合自己的项目开发和知识管理的经验写了一篇使用指南,现在看来,这篇文章还尚未过时,甚至还有很大的参考作用。

后从同事处得知,大妈原来之前也使用过 Tower,那时候 Tower 才上线不久,问题不少,程序员发现 bug 并反馈 bug 几乎是直觉反应,何况这位大妈还是资深的,所以习惯性地吐槽并提交反馈意见。

一开始 Tower 的客服小哥的态度还十分热情,接一个 bug 就回一个谢谢,没想到提交的意见越来越多,堆积成山,慢慢地,客服小哥就没有回音了……

好,以上将大妈的背景故事介绍完后,我就要说我为啥要写这篇文章了,如你所见,大妈的语言风格比较独特,一般人读起来会比较费力,同时为了让更多人掌握正确使用协作工具的方法,觉得非常有必要将这篇文章稍微整理并翻译增补了下,力图将后来者能尽快将协作工具用上手。

大纲

协作工具看似简单,但内中涉及的管理概念确实极多,包括:

  • 一、概念介绍:Scrum 敏捷开发任务板说明
  • 二、组合任务:服从GTD原则
  • 三、达成共识:认同使用原则
  • 四、设定任务:符合SMART 原则
  • 五、提高效率:分享协作工具使用技巧

一、概念介绍:Scrum 敏捷开发任务板说明

Trello 和 Worktile 的设计原型来自挂在墙上的任务板,出自《硝烟中的Scrum和XP》这本书,操作方法如下图:

NOT CHECKED OUT (未完成)

表示没有完成的事情,所有杂七杂八的事情都可以用任务卡的方式往贴在这一栏。

CHECKED OUT(完成)

自己觉得事情完成了,就将该任务卡移到往 CHECKED OUT 。

DONE(终结归档)

「DONE」需要由团队来定义,只有团队成员检查,确认可以交付,并帮助将任务卡移动过去,这件事情才算是完成。

所以,务必要抱着符合大家认可的态度去做事情,否则事情永远不能被「DONE」

SPRINT GOAL(目标)

这张图的横轴表示时间点,最终点为截至日期(deadline);纵轴为任务总量。任务开始后的每一天,团队成员都需要汇总数据,标记进展状态,跟踪任务进度,以此来提醒团队不要偏离目标航线,一旦发现,马上调整,回到正轨。

UNPLANDEN ITEMS (计划外的事项)

总会遇到偏离计划但又必须去做的突发事件,这样就要将这些计划外的事项都归到一栏,其意义在复盘总结的时候能达到以下三个目的:

  • 尽可能少地安排计划外的事情
  • 尽可能在事前把计划想到周全一点
  • 要搞清楚打乱团队计划的因素是什么,如何避免?

NEXT(待办)

事实是这样的:一个项目尚未结束,另一个项目马上就要开启了,先不管是拍脑袋还是深思熟虑,团队人数就那么多,在项目尚未结束之前,与项目无关的、 紧急和重要程度都比较低的事情都只能堆在待办箱子里呆着。

二、组合任务:服从GTD原则

所有任务卡的生命周期如下:

此处插个图,大家可将五条竖栏看做五条泳道。

INBOX=》TODO=》DOING =》CHECKING=》DONE

INBOX

团队成员可以在INBOX中自由创建,收集需求

TODO

成员在TODO中主动认领,完成任务分配.

  • 自领:进入任务卡中自行领取
  • 指派:如已明确分工,可以指派某个成员为任务卡的执行人

DOING

DOING表示成员是在在执行任务卡的过程中。

原则:

  • 每个人至多只能同时执行两件任务
  • 在DOING 泳道中的任务卡不应该超过成员总数的2倍

CHECKING

通过成员间的相互CHECKING,确保任务完成预设目标。

  • CHECKING等同于科研中的「同行评审」
  • 成员间可以主动评审,也可以约定固定主持人来复查
  • 评审的人一定要留下评注,以便评审明确职责

DONE

DONE中暂存当前阶段完成的事务 - 每次活动真正完成后,都应该进行归档 - 当然,发觉有重复出现的任务,可复制任务卡重开一轮

三、达成共识:认同使用原则

工具以人为本,协同工具是为了解决小团队内部协同问题的,一定要所有成员达成共识,认同流程,才能 主动按规约推动每个任务卡的前进,否则沟通成果高过执行成本,就没人用了,所以一定要全员都认可以下原则:

  • 将一个活动各种事务,放在专用项目泳道中,宏观掌握整体进展,每个项目只关注件事情,其中的任务板设置必须与项目密切相关
  • 每个项目的成员不要超过7人,每条泳道中的任务卡不应该溢出泳道,太多任务卡和人挤在同一个泳道中将无法协同
  • 每个成员同一时刻在 DOING 泳道的任务卡不应该超过两个
  • 只要任务卡被认领或指派,就一定要有个结果,形成任务的闭环,任务卡需被成员核查过才可算完成,任务卡不能自行操作结束

严格执行

有了团队共同规约后,一定要严格执行,否则只有其中一两位成员在每天使用协作工具,其它成员从来不打开来更新,是没有用的。

协作工具说到底也只是工具,不是管理制度,要尽可能的通过任何可能的渠道强调协作工具是公司内部正式事务的唯一执行评价标准,才可能让大家在工作中喜欢上协作工具。

随时改进

众多的协作工具的原理基于敏捷开发管理经验,是对现实即时贴形成的看板系统的在线模拟,是敏捷开发管理过程的最小集合,只提供了最基本的看板功能,所以,其使用可以完全根据现实看板的使用来操作。

每个项目都有各自不同的问题,大家一定要根据使用中的问题,及时调整使用规约,让大家感觉到协作工具是收为己用的工具,越用越爽,这样才能真正发挥协作工具的真正作用。

四、设定任务:符合 5W1H 与 SMART 原则

任务卡的内容,该符合管理学中的 5W1H 与 SMART 原则:

量化(Specific)

任务应该足够明确,这就要求执行者将悬在空中的大任务拉下来,逐项分解,做个检查清单,每个检查清单都确保能完成,具体而言,一个任务卡至多在一周以内完成的,每个检查清单至多在一天完成。

可衡量(Measurable)

怎么样才算是做完了,做完了怎么才算好?这都需要一个判定指标。无法进行衡量的任务是不可能的任务,所以,能量化的就量化,不能量化的就质化。

可执行(Attainable)

不能假设所有志愿者都是经验人士 任务卡中应该尽可能的给出具体的执行指导,以便成员可以参考,也帮助理解任务的真正目的

有关联(Relevant)

协作工具之所以存在,就是因为任何一个任务在组织里都不是单独存在的,所以,成员在任务卡中可以加入其它任务卡的链接,以说明当前任务的来龙去脉,以便成员用正确的顺序来完成,比如,易拉宝的完成,就可以设立为: - 易拉宝设计- 易拉宝制作- 易拉宝部署- 易拉宝回收

用以上几个独立的SMART 任务卡进行关联性追踪

有边界(Time-based)

所有活动或项目,时间、资金和人力等各种资源都是有限的,所以,在任务卡中指明关键资源限制非常必要,大部分的协作工具都有截止时间设定,请毫不吝啬地使用。

五、提高效率:分享协作工具使用技巧

安装移动应用

大部分的协作工具都已经提供全平台兼容的移动应用,可在室外,随时查阅信息、处理问题、更新执行、关注提醒等。

无需频繁查看提醒

频繁查看就等于「刷」,「刷」而不做,那跟「刷」豆瓣微博有什么区别?所以,正确的使用方法就是明确任务之后就立刻去做,给自己设置4个番茄时钟,大概两个小时之后才去更新任务卡状态,再顺便查看提醒,及时跟上团队进度。

将任务卡视作维基

大部分的协作工具内置了非常完善的全文搜索,尽可将任务卡视作维基,这就应该要求成员在执行过程中:

  • 使用Markdown 格式
  • 尽可能地用SAMRT原则详尽地说明
  • 将所有执行的证据、链接和文档进行增补

善用 Checklist

任务卡中的 Checklist 只是个执行的要点提醒,具体每个要点的执行都会产生新的可用资源,应该以链接或是附件的形式记录在任务卡中,比如文档/设计图形,以便随时复用。这样一来,每个任务卡就自然形成了活动总结中的一个章节,会后总结就可直接复制过去。

同时,checklist 是可以复用的,那么,每次组织活动到相关环节就可将一个完备的checklist 从上次任务卡中复制过来。

正视工具

工具须以人为本,如果工具起到反作用,那还不如纸笔这种原始而高效的工具。

参考团队协作工具书

参考资料

迭代

  • 2015-09-01 21:34:32 补增部分链接
  • 2015-08-31 12:59:43 加图
  • 2015-08-31 10:06:20 补增
  • 2015-08-31 01:14:46