CMS带来的思考:项目管理方式

本次问题

从这次的CMS来看,项目管理很难…

  • 任务分配
  • 进度追踪
  • 错误修正

目前都是靠微信和邮件交流来的。前者几乎是唯一的”及时”的沟通渠道。但是这也造成了

  • 信息冗余(同一个消息和不同人说),
  • 无法定位(因为相关信息都是在对话中),
  • 误解(通过语言/文件解释一个接口必然不精确)

等多个问题。

问题分析

我想,这也就是Stack能流行开来的原因之一。抛弃IM,纯用项目管理工具(teambition之类)不现实。

  • 首先,不少工具非常难用,只是把功能点聚合了一下。易用性和功能清晰程度之差还不如口头交流。

  • 其次,没有一个工具是所有人熟悉的,在不强制推进的情况下,就不能做到每个人快速掌握。

  • 第三,除了IM,还有什么可以保证实时性? 当要找一个人,只有微信是确保对方立刻收到通知的。

解决思路

仅从这个项目来看,gitlab是最合适的,用于代码类的工程管理。而微信应该退化为 联系不上时的辅助工具。

  1. 大部分程序员都会用git(从svn理解git也不难),git 天生有版本管理 和 协作属性。即便不用这些,每次push 之后,如果能通知到所有相关人,让他们直接去看commits说明,也好过直接在微信讨论。
  1. gitlab 有 issue,对于某件细节的讨论,完全应该专注于某个issue下,而不是在群里,或个人地交流。因为

    1. 这件事可能与多个人的工作有关,所以不适合个人交流。
    2. 但它可能并不会和所有人相关, 所以也不适合放在群里说而干扰其他人。

      事实上,如果我们以面向 问题 的角度来理解,一次工程中,遇到的 问题 才是根本。接口设计/修正/沟通也好,bug处理也好,都是很具体的问题。这些问题与多个参与成员关联,问题处理也应该限于这些人之中

  1. issue 的 open 与 close,很好地反映了待解决/未解决的问题。

    而各人各写各部分的(branch), 在 通过 单元测试(实际小项目可能被省略),自己测试, continuous integration 项目负责人审核后,merge 到 master分支。其中任何讨论,修改,都会记录下来,方便查找。而以gitlab为核心的好处,在于有效解决了 通过微信 的 信息冗余,无法定位,误解…等一系列问题。而 任务分配 可由 开始项目 时即定好,不同分支即是不同任务所属。进度追踪 依赖于 每个人所写的README.md,因为md可以有 todo list,所以应该自己勾掉做完的,而总的项目完成情况则在每次 merge 到 master的时候,由项目负责人统一更新。

简单地表示就是:

简单流程图
详细表示见附图
可能令人疑惑的是,issue的处理 在哪一步?

issue不在流程图中的原因是…它可以存在于任何一步。

每一个issue,都应该在原地解决。如果它的状态(已解决/未解决)不影响一部分人的工作,则这部分人应当不理会这个issue,仍然做自己的branch。

凡是工作与该issue的状态有关的人,都应参与到issue的讨论,直到解决再继续做。

因此,issue对于相关者的阻塞性, 和对于不相关者的不阻塞特性,使得相关的讨论可以更加集中,也要求相关者更加高效地解决这个问题,而不是互相等待。

同时,之所以要避免微信/邮件来沟通问题,还在于这样的沟通难以回溯。就像开头所说的,不可能也不应该通过搜索聊天记录/邮件来定位某次沟通的话题。虽然邮件在这一点上好些,但假设使用邮件讨论问题,如果涉及到多个人,则抄送和回复全部也使信息混乱。

总结

综上所述,可以考虑全面推行/要求使用gitlab以提高沟通及工作效率。


附图:
完整流程图

Comments