研发管理之痛

下面来自于《GitHub的研发管理之道》

代码评审工具Pull Requests

GitHub开发工作流中离不开Pull Requests的使用。稍晚些我会就“Pull Requests”写一篇更为详细的博文，现在我想说的是：生活在“Pull Request”的世界里真是一件伟大的事啊。

如果我想对代码库进行修改或添加一个新特性，我可以延伸出一个新条目，在Pull Requests中新建一条Pull Request，我的同事会在以下三种情况下复查我提交的代码：1.他们受到这些改变的影响；2.他们对这些改变很感兴趣；3.当他们时间充裕时。之后，我们可以在部分机器上运行调试这部分代码。如果一切运行正常，即可在主库中进行修改。

通过Pull Requests，我就不必再拉同事开会了，开会是件让我和同事都很头疼的事。原因是：（如下）

● 会议有害

37signals曾在Getting Real上发表过一篇文章《meetings are toxic》（译注：会议是有害的），说实话我比37signals更加讨厌、鄙视开会。

当某个问题亟待解决时，往往会召开会议来商讨。开会时，通常会邀请更多的人来参加。即便你对该会议主题十分感兴趣，最后你也将感到困扰，因为会议会让你停下手头上的实际工作，而去讨论其他工作。

除此之外，会议内容很容易遗忘。即便你做了会议记录，你也不可能记住会议的所有内容。会议上你对某些内容并没有做记要，然而三个星期后，这些内容越凸显其重要性时，你将会费尽脑汁去回忆这些内容。查看网络聊天室的聊天记录，你就不会遇到这个问题。同时网络聊天室还可以减少参会者零散的思想表达，他们会用完整明确的句子来表达自己，这样更有利于谈论的进行。

在GitHub中也将继续保持有“会议”，但会议数目不会过多。

创造力具有自我引导作用。可以说很多人都不能明确说出自己到底喜欢做什么。如果你喜欢做某件事情，那就放手去做吧。事实证明，只有真正喜欢一件事的人才会把这件事做得很漂亮。在GitHub中，员工可以利用 Pull Requests尝试他们所有的新想法，其他员工可以在此原型的基础上不断进行迭代，这是构建新产品的一个伟大方法。

像IBM这样的大公司可能比较重视资金的投入，但对于一个创业公司，这是行不通的。一个创业公司可能不必限定工作时间，不必开过多会议，员工的代码可以进行点对点的审查，从而创建一个很有趣的公司。同时注意你的公司不应该只开发你自己的产品，应该集思广益，让员工投入到产品的创新过程中。

    与之相反的现状显然即为研发管理之痛了。