使用 Gitlab 作为办公物品管理工具。

为何使用 gitlab

主要原因是目前部门内部的项目管理是基于 Gitlab 来进行的。

Gitlab 是一个非常好的文本协作平台,以这个概念出发,Gitlab 不仅用来管理源代码,也用来管理文档,以及记录事务。

同时基于消灭重复信息的原则出发,能在一个平台的就在一个平台。这样在搜索,跳转,交流的时候都会非常的高效。

如何使用 Gitlab 来进行物品管理

首先物品管理中的物品指的是什么?目前来说我实践的是把所有实体的物品都记录下来。

比如:测试的设备,开发用的电脑,部门统一购买的书籍。书籍也纳入管理之后变方便的是,如果你想要借某本书,你通过搜索书名就能快速的找到现在持有这本书的人。

当然除了书籍,其他的物品也是可以被搜索。

如下图,是一个搜索 ipad 的结果。从截图可以看出来,这个 ipad
是从两年前登记入库的。

一些基本概念介绍

Assignee

每个事物都应该有一个责任人,或者叫负责人。

一件事情如果有多个负责人,最后就会流于形式, 大部分人都会觉得这件事情应该是别人做。如果只有一个负责人,只要给他足够的空间和资源,他就能尽心尽力。

Issue

基本上就是代表一件事,但是在物品管理的场景里面,我用它来代表一个物品。

Issue title

一个 Issue 的标题。一般就像一篇文章的题目。

如果标题写得好就像一篇文章写得好,会让跟进的人快速的了解基础背景信息。同时又能便于搜索。

在物品管理的场景里面,我们使用它来代表物品的名称。所以如果你物品的名称起的足够详细,那么搜索的时候就越方便。

Maintainer

项目的负责人,该项目所有事物都是应该由 Maintainer 确认。

Close Issue

对一个 Issue 的操作,基本上代表的事物的完结。

Bot

我自己编写的自动化程序。它能代替人工,进行一些重复性的,复杂的工作。

在物品管理中的几个要素

盘点

我们需要定期的盘点物品,防止损坏,或者因为某个人持有太多物品疏于管理。在物品已经损坏很久才去维修会有比较大的金钱以及时间成本,及早发现物品出现问题,修复的成本越低。

检索

能快速的知道某个物品在谁手上。

历史记录

比如一个手机,是从什么时候购入。都经过几个人的手。都维修了几次,维修过的问题是什么?

减少人力消耗

详细的历史记录可能需要填入很多必要的信息。比如时间,比如交接的人。以及需要将所有的信息整理到一起。

而一个好的物品管理系统。只需要一次操作,就能自动记录时间以及交接的人。同时又能将所有的历史信息汇总到一起可以快速的查看。

真正需要人工操作的是确认。即确认 A 已经从 B 手上接手对应的物品。其他的内容都由系统自动维护。

这样一来就能用最少而且是最必要的操作来达到目的,但是又有详细的信息。

对外的交接以及销毁

一些物品可能会出现部门间借用的情况,比如展会。

另外物品也可能出现销毁的情况,比如 20 年前的诺基亚手机,它已经没有作为测试机的意义了。

针对几个要素的解决办法

盘点

可以编写一个 Bot 定期抽查物品持有者对物品的保管情况。

在 Gitlab 中我实现的机器人和一个普通用户没有区别,它会去评论,触发,并检查结果。上图就是一个基本的盘点流程,由机器人触发,物品持有人拍照回复。

通过定制一些盘点机制,比如按天轮转查询每个物品,随机抽查物品。就可以比较稳妥的对物品进行比较好的保管。

同时盘点就变成分布式的工作。因为盘点的时候需要参与的是物品持有者,而连续多次盘点到某个人的概率是比较低的。

检索

检索用到的是 Gitlab 中 Issue 的概念。

如下图

每一个 Issue 都会代表一个物品。Issue 的 title 就是物品的名称。

所以只要这样记录下来,你就可以使用搜索 Issue 的方法来搜索物品。而且这是一种技能迁移,使用的人不需要学习新的知识,就能掌握这个操作。

如何知道当前物品在谁手上?

如下图,我们可以从 Issue 的信息中查看到物品现在是在谁的手上。

继续上面的方法,将 Issue 的 assignee 角色作为物品的管理者。所以只要搜索到 Issue,就能知道这个物品的持有者是谁。

历史记录

再次使用 Issue 的中已有的概念,我们可以在一个 Issue
中查看物品的流转情况,维修情况。如上图,我们可以看到物品在几个人手上流转过。

减少人力消耗

需要人参与的情况

  1. 物品的交接

由 A 发起并由 B 确认。那么部门的管理者就可以将 Issue 从 A assigee 到 B。这中间的工作量就是两个人的评论加上部门管理者的 assignee 操作。

  1. 物品部门间的流转

由物品的持有者持有接收人的收条,并拍照上传到 Issue 中。并在归还物品的时候销毁,或者交还收条。

这中间的参与者就是物品交接的两个人,写一个收条,拍照上传。
并且在很多情况下也不一定需要拍照上传,因为 Issue 仍然还是 assignee 给部门内部交接出去的人,由他全权负责。

对外交接及销毁基本上和减少人力消耗是高度相关的,后面就不再介绍。

几种可能出现的坏情况的预防

篡改历史记录

秉持我的原则,所有的历史记录都不可修改和删除。

所以使用我维护的版本 https://github.com/carlos-wong/gitlab-ce-carlos 就能解决这个问题

物品持有者悄默默的把物品 assign 给其他人

因为在 Gitlab 中有一套通知机制。所以被 assignee
的人会收到邮件通知,如果他并没有接收物品,就可以立即提出异议。

所以不存在悄默默转移物品给其他人的情况。

另外,使用我维护的版本 https://github.com/carlos-wong/gitlab-ce-carlos 设置部门的管理者为
Maintainer, 那么这样一来,只有经过 Maintainer 才能 assignee。

物品持有者悄默默地 Close 物品的记录。

首先如果使用我维护的版本
https://github.com/carlos-wong/gitlab-ce-carlos 。 那么只有 Maintainer
才能 Close Issue,所以无法悄默默地 Close 物品的记录。

另外,我做了一个复查 Bot。所有关闭的工单,都需要我回复一条指令才算完结,否则会一直提醒我确认。

如上图,只有我指定的账号回复 `pass` 才代表这个物品是被确认回收。

总结

通过以上的方法,我实践了三年的时间。从无出现过物品丢失或者损坏不报的情况。

当然,如果出现了以上的情况,也可以快速,清晰的去调查清楚。

将软件的开发管理应用到生活,项目,部门管理中。表面上看违反直觉,事实上是一种高度有效的方法。

这是一种革命性的做事方式,有别于口口相传,部落式的信息传递。

基本上如果你对 Gitlab 理解足够,并且有二次开发的能力。就能非常方便的去使用它,不需要硬性的让团队的做事方式去适应它。而是它辅助你的团队更高效的做事,去掉不必要的环节,并保留非常详实的信息。

avatar

极客世界

乐聚机器人研发总监 | 黄怀贤