Geek专栏：使用 Gitlab 作为办公物品管理工具

今天Geek专栏为大家带来
乐聚研发部黄怀贤的
“使用 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 中查看物品的流转情况，维修情况。如上图，我们可以看到物品在几个人手上流转过。

减少人力消耗

需要人参与的情况：

• 物品的交接
  
  
  

由 A 发起并由 B 确认。那么部门的管理者就可以将 Issue 从 A assignee 到 B。

这中间的工作量就是两个人的评论加上部门管理者的 assignee 操作。

• 物品部门间的流转
  
  
  

由物品的持有者持有接收人的收条，并拍照上传到 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 理解足够，并且有二次开发的能力。就能非常方便地去使用它，不需要硬性地让团队的做事方式去适应它。而是它辅助你的团队更高效地做事，去掉不必要的环节，并保留非常详实的信息。

Geek专栏：使用 Gitlab 作为办公物品管理工具

今天Geek专栏为大家带来
乐聚研发部黄怀贤的
“使用 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 中查看物品的流转情况，维修情况。如上图，我们可以看到物品在几个人手上流转过。

减少人力消耗

需要人参与的情况：

• 物品的交接
  
  
  

由 A 发起并由 B 确认。那么部门的管理者就可以将 Issue 从 A assignee 到 B。

这中间的工作量就是两个人的评论加上部门管理者的 assignee 操作。

• 物品部门间的流转
  
  
  

由物品的持有者持有接收人的收条，并拍照上传到 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 理解足够，并且有二次开发的能力。就能非常方便地去使用它，不需要硬性地让团队的做事方式去适应它。而是它辅助你的团队更高效地做事，去掉不必要的环节，并保留非常详实的信息。