如何完成皆大欢喜的项目：近期工作所感

最近的工作有些跌宕起伏，原先在做知识图谱的应用开发，后面又被抽调到另一个项目做新功能的开发，上周又被紧急要求推掉手头的工作，赶另外一个项目。

这个项目的问题已有一段时间，沟通不顺，技术困扰。有的时候乙方认为的完美方案在甲方这边可能并不能达到要求，相反是另一个方案更能合甲方心意。作为项目管理者在开发人员和甲方之中斡旋，是一个非常重要的议题。

如何做一个合格的开发者

• 明确的时间表：

  甲方公司很少会时刻关注开发者的每日开发进程，因此开发团队一定需要有一个开发周期表，类似于项目里程碑，这个玩意主要是让甲方图个心安，知道开发者心里有数。

• 软工作占40%：

  有句老话：程序员最讨厌不写文档的人和要他写文档的人。据说曾经有个程序员因为没写好文档被同事捅了数刀:/。

  说实话，我自己在开发的时候也不大爱写文档。从开发者的角度来看，自己亲手写的代码，总觉得外人一看代码，就应该很好理解怎么用。然而事实上实际项目中可能只有60%的时间在开发上，剩下得有20%的时间都在写部署手册和指标。

  评估指标：这个东西是实际项目中对开发团队非常有利的东西，你要是不写，甲方就会觉得开发者没做什么实事。相反要是写的特别详细，哪怕指标只提升了百分之零点几，甲方都觉得你尽力了。这个和发论文很像，哪怕你没做多少工作，评估指标换一换，文章写的好一点都可以发刊。

  部署手册：写这个玩意就是给啥也不会的小白看的。说白了，就是手把手让一个白痴会操作系统。这个确实从不同角度来看体验很不一样，对于不会Linux操作系统和vim的用户来说，对文档里的改名，复制一系列操作一脸懵逼。

  这是我工作里感受最深的点，甲方往往对开发者的代码量，工作时长没有那么重视，却对一些汇报，文档之类的软工作要求非常严格，这是双方最大的冲突来源。

  80分的硬工作，95分的软工作。

如何做一个合格的项目管理者

• 高频率的沟通：

  同样的，在甲方里也存在不同的管理等级，作为项目管理者也需要时刻向顶头上司汇报。尽管自身没有开发的压力，但是有汇报的压力。因此就需要时刻与开发者保持沟通，从这个角度来看，项目管理者只是另一个乙方。

• 专业的提问：

  同样，作为项目管理者，需要了解项目以及开发者的技术栈，以防止被开发者带偏。合理的提出专业的问题，而不是提一些愚蠢的基础问题，这一点非常重要。

运用博弈论来分析

在博弈论中，项目管理者和开发者构成了一个非零和不完全信息博弈，事实上，双方的收益矩阵可以表示如下：

开发者/项目管理者	不积极沟通	积极沟通
不积极沟通	（0，0）	（0，1.5）
积极沟通	（1，0）	（3，3）

如果双方都不积极沟通，项目容易跑偏，最后大家都不落好。如果开发者单方面积极沟通，那么甲方高层无法从项目管理者获取到及时的积极信息。相反，管理者单方面积极，则容易出现双方冲突的情况。只有在双方都积极时才能让彼此都获得最高的收益：管理者的努力让高层看到，开发者的项目完成符合甲方需求。