从程序员到半个CTO

我身边不少年轻的开发，很多人有一个想法，想转型管理岗。原因有二，一是岁数大了不想加班写代码。第二，到了技术岗的天花板。本人年过40，做开发快20年。目前在创业公司做CTO，除了做技术管理，仍然常写代码，感觉精力毫无问题。

转型管理的想法没有对错，如果是为了事业上更进一步，那么你努力历练自己积累经验，如果你只是懒得写代码了，那你要想好怎么解决自己的中年危机。

自己分享的一点浅薄的项目管理常识，给希望从纯开发转型到管理的朋友，先从做半个CTO开始。

一 把你的团队小型化

本人觉得，最佳开发团队人数就是7-10人，最多别超过20个。这里不是说项目最多只能20人参与，而是如果项目超过一定规模，一定要进行划分，不同的人负责不同的子项目，然后通过层级关系管理。当然，我这里仅仅说的是项目管理，不涉及到任何公司治理或团队管理的范畴。

要使项目成功，实际上就是让你所在的中小团队沟通无隙，充分协作。在一个大团队里，很难做到。第一：沟通成本很大，第二：每个人能掌握的信息和关系都是有限的，完全扁平化的项目管理会使得效率下降太多。还有一个误区，别觉得研发管理只是你自己的事情，其他人给你干活就可以了。没有成员之间的互相沟通，你是没有充分的信息来进行决策和计划的，即便你再牛逼，经验再丰富，也不能代替每个专业的成员思考。

二 需求一定会变，但仍要明确

明确需求是重中之重。以前本人喜欢一碰到项目就想到用什么技术实现，做得多么的优雅漂亮，但是如果没有把需求调研清楚，实际上做出来可能南辕北辙。现在的敏捷开发也好，迭代开发也好，其实质还是在逐步明确需求和适应需求，项目从一个最小需求集出发，逐渐细化需求，当用户看到原型图和设计图的时候，用户的需求就可能有调整或者变化，当用户开始使用第一个版本的时候，用户的需求仍有可能调整和变化。开发的过程实际上是明确需求的过程。

当我们真正去实现用户需求的时候，一定要明确需求的细节；如果不明确，那就先放置到下一个迭代或者继续调查用户需求。需求的明确还包括要让每个人都非常了解需求；需求决定了产品如何设计，架构如何去做，工作如何分工，测试如何进行；需求不了解，基本上是建造空中楼阁。需求文档是项目管理中唯一不可省略的文档，而且要及时更新，保证每个人都能查阅理解。一旦有新成员加入项目，非常有效的方式就是看需求文档，否则，即便你有耐心对所有的人员一一讲解，沟通的过程中也会耽误时间。

三 停止扯皮，从任务记录开始

现在不少公司采用早站立会的方式来安排一天的任务。研发不同于做业务，本人认为在任务安排上，该说清楚的说清楚，最好也要写清楚，不能等着动手之后再去扯皮。在一个项目中，有老手，也有新手，不能同等对待，光靠默契还不够，必须明确化。有人说，敏捷宣言都说了，有效沟通胜过复杂的文档，这个我同意，每个任务都出一个任务书，详细写清楚每个细节，确实有点过，但纵观我参与的项目，完全靠口头布置任务，一切只在心中，不留存记录，带来的是无尽的混乱和费时的沟通返工。

譬如，一个接口如何定义，一个功能实现或改进需要改哪些地方，需要哪些人参与，如何一步一步完成，这些细节的安排就不能省略，由着每个人自己灵活处理。有人说，这不是又进入了文档环节了吗？其实不要害怕文档，文档并不一定是那种长篇累牍的，可以是碎片似的，敏捷式的。这种任务记录应该是在大家都有共识的需求背景下，规范各自的行为，尤其是在任务接口和步骤方面让每个人能够通畅的合作。没有这个做保障，只能是一片混沌。别觉的手写任务多麻烦，不该省的步骤绝对不能省，总之，这是每个人工作的依据，忽视不得。

四 关键信息要做好管理

正如任务要明确一样，关键信息一定要记录下来，以便随时查阅。这些信息包括：会议纪要，工作计划，任务安排，缺陷问题等。无论什么样的的会议或者讨论，都必须要有一个结论，而且要记录下来。开会的成本是很高的，不能为开会而开会，不能会而不决。因为无论大小会议，要么有重要的事情要宣布，要么要讨论重要的事情，即便当时达成了一致，会议纪要也要在会后发布给所有人，这样才能真正达到开会的目的。

有时候即便两个人需要讨论一下工作如何开展，这样的讨论也要有结论有记录，因为既然要讨论，肯定是重要的协作信息，一是从书面达成一致，避免理解有误，二是其他人不必再去询问或讨论，直接看结论了。记录的方式有很多种，邮件，文档等都可以，最好是用专业的开发管理工具，能够记录关键信息，譬如需求变化，任务安排，缺陷跟踪，会议纪要等。还有一点很重要，就是记录应该及时发给相关人员，通过邮件或者即时通讯方式，不用担心信息碎片化，思考是随时随地的，不要到了要动手做或者开会的时候临时再思考，那样是极其损伤效率的。

五 光重视测试妹子，还不够

没有质量的项目是失败的，设计得再巧妙，实现得再优雅，用不起来是绝对不行的。有人说，很简单，测试吧。但我经过的很多项目，都是先开发，开发快完成的时候临时抽调几个测试小妹来进行测试，这样的问题是，测试小妹能做的大部分事情就是点点界面，看看是不是会崩溃。这样的测试，是不可能保障质量的。对于逻辑比较复杂的项目，如业务系统等，正确性是首先要保证的，临时参与的测试人员，很可能对于测试结果是否正确都没有太大把握；所以项目初期就应该有一个经验丰富逻辑能力强的测试人员参与进来，了解业务和需求，了解原型和UI，甚至要了解接口。这样，开始测试时才会有一个测试管理者来主导整个项目的测试。

更有效的质量管理手段是，测试要跟随开发，即不要等到开发全部完成后再进行测试，而是分阶段迭代进行，开发一部分，测试一部分，有重大缺陷能及时发现并修正。

接口测试是最容易实现自动化的测试方式，测试成本低，一定要做，而且应该是由程序员来做，接口实现和接口测试最好分别由不同的程序员来编程，这是测试驱动开发和结对编程最有效的体现。对于时间紧迫的项目，可能无法完全实施自动化测试，能够把接口测试做好就不错了。

六 选自己合适的管理工具

工欲善其事，必先利其器。如果不去发明工具使用工具，人类依然处于茹毛饮血阶段。在我刚进入这个行业的时候，普遍对管理工具不太感冒，觉得研发高大上，智商高的人根本不需要什么管理工具。然而，上面说过，研发项目是一个不确定性非常高的项目，突发事件很多，信息沟通非常频繁，让人去记住这些东西是根本不可能的事情，为什么不把人的精力用来思考对付真正的难题，而要去记忆那些变化非常快的信息呢？有人说，有邮件和QQ就够了，邮件用于正式的记录，QQ用于临时沟通。我不反对邮件和QQ，这是有效的沟通手段，然而对于研发这种信息密集变化快速的项目管理，要很快的查询和获取信息，要高效的完成任务，邮件和QQ是不够的。例如测试人员发现了一个缺陷，通过QQ发到群里去讨论，很快群里就会充斥着很多聊天记录，很难对某一个缺陷进行讨论。所以一定要选择一个好的管理工具，达到事倍功半的效果。

从我了解的情况来看，目前研发团队采用的工具有以下几种，一是采用开源的缺陷管理工具，如Bugzilla，Redmine, Mantis，好处是免费，能修改，坏处是需要自己部署维护，有变更的需求还需要开发人员修改，而且这些以前的开源工具都是上个世纪的产物，界面丑陋，体验性很差，如果还需要安排开发人员长期维护的话，成本很高；二是购买商业软件如JIRA，好处是功能全面，质量稳定，坏处是按人头购买license，价格昂贵，然后升级困难，更新缓慢；三是采用市面上比较流行的协作工具，如Teambition, Tower, Worktile等，这样的通用性协作工具在安排一些日常工作时有用，但对于研发管理这种信息密集型管理还是会感到力不从心，比如很多协作型工具采用看板的方式来管理缺陷，这个是完全不够用的；四是采用Bugclose这样的在线项目管理工具，好处是专门为研发管理设计，不需要安装部署和维护，简单好上手适应各种开发模式。