我从年开始带团队，这其实是第11个年头了，这些年大大小小的团队带了不少，也见识过各种各样的“人才”。
我没有进过大厂，所以本文仅仅是我个人这些年摸索出来的一点经验和思考，对于迷信大厂迷信权威的读者来说本文可能不值一读。
虽然本文仅仅是我个人的一些经验和思考，我也没有任何名气，但我保证你能从本文中读到许多以前可能从未触碰过的观点，这些观点不一定对，但一定与你在其他管理学书籍中读到的不一样。无论你是赞同还是反对，你都将获得一个新的角度看待团队管理。
全文1.6万字，第二篇内容比较抽象、晦涩，建议收藏分次阅读，阅读中怀疑、怀疑中思考、思考中获得。我希望读者朋友们能够保持怀疑、开放、独立思考的能力的阅读本文，这样你才可能收获更多。
第一篇项目管理
项目管理，即管事，对事负责。
第1章、需求管理
需求管理分为三部分：需求文档管理、功能页面需求管理、测试用例管理。
1.文档管理
文档管理首先要实现各种需求文档的统一管理，不要到处都是文档，需要的时候却找不着。
其次是文档的即时更新。比如我们跟甲方沟通过程中的需求文档，从一开始到签合同，中间可能产生了很多个版本，我们需要将这些版本都统一管理到一起。如下图所示：
除了需求文档，项目开发资源其实也应该管理到一起，比如服务器资源、账号、开发指南，等等等等。如下图：
2.功能需求管理
功能需求，即页面需求。我们一个软件项目，最终都是会被拆分成无数个功能页面来完成开发的。
那么页面需求应该放到什么地方统一管理呢？原型？UI图？需求文档？
我们团队以前尝试过通过Axure（一款原型设计软件）来管理需求，就是把开发需求直接写在原型页面上。当需求改变时，先修改Axure源文件，然后再发布。
这样做很快便遇到2个无法调和的问题。
问题1：开发需求其实比原型页面变动的频率高得多。有时候因为开发需求描述不准确或者不够详细，不得不修改Axure文件，很不划算。
问题2：大量的测试用例无法直接写到Axure上面，也让测试用例管理变得无比艰难。
于是我们团队最终得到如下的需求管理模式：
（1）使用Axure画原型，然后生成html，然后通过阿里云OSSBROWSER上传到阿里云OSS，然后将OSS做成静态网站，加上域名映射就可以公网访问了，比Axure官方预览速度提升几十倍；
（2）按照原型页面结构1:1创建在线需求文档结构；
（3）只有非常原始的、明确的需求我们才写到原型页面上，开发需求以及可能变动频率较高的需求，我们都维护到在线需求文档里面；
（4）测试用例维护到在线需求文档里面。
以我们商城系统中的购物车页面需求为例。原型（UI）如下：
在线需求文档如下图所示：
点击查看大图
从上图中可以看出，这个页面隐藏的开发需求其实是很复杂的，原型不可能把每一个开发需求都体现出来，而上图中的开发需求并不是一开始就这样的，你现在看到的已经是我们维护过很多次的版本了。
所以，开发需求其实是会频繁变动的，而在线需求文档管理，才能将需求维护成本降到最低。（Axure或UI图维护开发需求的成本太高太高了，最终导致需求没人维护）
3.测试用例管理
我们团队曾尝试过多种方式管理测试用例，最终终于探索出来一条低成本高效的测试用例管理之路。
从原理上讲，测试用例的最佳载体就是需求文档。由于我们已经将需求文档在线化，所以基于在线需求文档来管理和维护测试用例，本就应该是顺理成章的事。
值得一提的是，需求管理通常是由测试主管负责，而测试用例管理通常是由测试同学负责。测试主管根据原型录入所有需求之后，测试同学按照分配自己的模块持续录入测试用例。
测试用例录入之后，这样一个完整的页面（功能）需求就算完成了。这时可以基于这个需求一键创建任务或提bug，如下图：
从上图可以看到，创建任务或bug时，可以直接勾选测试用例。如果勾选了测试用例，那么当程序员提交任务时，系统会提示先完成测试用例的验证，避免未经过严格的自测就提交：
除此之外，一个完整的需求还关联了跟该需求相关的开发任务和曾经出现过的bug，如下图：
开发人员在查看任务详情的时候，也可以直接看到测试用例和完整的需求详情：
4.本章小结
这才是一个完整的需求管理过程。包括：
原始的项目需求资料、客户资料；
开发环境资料，开发、测试指南；
Axure产品原型；
页面级在线需求文档（关键）；
关联到需求的测试用例；
关联到需求的开发任务和曾经出现过的bug；
很多团队需求管理一团糟，一会需求不是最新的、一会又出现多个版本的需求、一会需求文档找不到，因为需求拖慢进度甚至导致程序员、产品、测试、UI之间扯皮的事太多太多了。管理好需求是管理好项目的基本保障。
第2章、项目迭代管理
很多程序员团队处理不好开发新版与维护旧版，以及项目快速迭代的关系，所以工作总是感觉像一团乱麻。
我们团队在项目迭代方面摸索出一条非常值得分享的经验，也是我们项目管理理论体系中的核心。当你看完本章内容，你就会明白，不管多大的项目多大的团队，用我们这种方式来管理，轻松实现有条不紊。
接下来，请看我们团队是如何实现的。
1.初始化项目
在我们团队，项目原型画完评审之后，UI同学按照原型出UI图，测试主管或项目经理按照原型1:1在唐虞阁中录入需求文档。
全部需求文档录入完成之后，测试同学继续完善测试用例，同时，项目经理基于需求文档编写API文档。
我们团队摸索了很多年，自创了一套通过JavaScript来编写API文档的框架，每一个API文档就是一个js文件，该文件通过git或svn管理，服务器自动加载该js文件，然后将API文档按格式呈现。优势：用极少的代码实现复杂的文档；充分利用git/svn版本管理功能；充分利用JS动态语言特性让编写更灵活；充分利用IDE智能提示和强大的JS编辑能力。本文后面会专门开一章节介绍，此处不再展开。
API文档编写完成之后，通常第一批测试用例也差不多完成了。接下来便是创建开发任务了。
一个需求通常分为服务器API开发任务和前端开发任务，前端又可能分为ios、android、小程序、web前端等。所以，项目经理会根据需要分别创建相应工种的任务，并评估该任务的标准产出。（关于标准产出请见本文第二篇第5章）
注意，这时候所有任务通常都没有指派开发者，通常也没有设置截止日期。
举个例子，假如一个拥有个页面的项目，需求数就是个左右，任务数就是两三百个，根据客户端数量而定。
当这两三百个任务全部完成创建和评估（标准产出）后，项目就算初始化完成。这时我们可以看到所有的任务都是未指派开发者的，也没有设置截止日期。如下图所示：
项目初始化完成之后，接下来便是安排开发了。
2.安排第一周任务
项目经理根据自己判断或客户要求，自行选择哪一部分任务先开发，哪些后开发。然后将任务指派给具体的开发人员，并设置截止日期为当周周日。
注意，我们并不会强制要求员工必须在截止日期前完成任务，超时也并不会有任何惩罚。设置截止日期，仅仅是为了帮助员工只用关心自己本周的任务。如下图：
项目经理安排的一周的任务量，通常也会稍稍高于该员工的能力。如上图所示，杨艺本周目标标准产出27小时，但是她通常只能完成20小时的产出（按照一周上班35小时计算的话）。
第一周任务安排完成后，项目经理可以看到每个员工的工作量，以及大家的开发内容分布，如下图：
根据这个分布图，就可以一目了然的知道任务量、任务难度、需求范围安排是否合理了。
3.后续每周安排任务
如上一小节所述，项目经理会给每个成员都稍微多安排一点工作，那么每周结束时大概率就有一部分任务无法完成，这个很正常。
这时，比如又到周末了，项目经理会将本周未完成验收的全部任务重新修改截止日期为下一周周日。从而保证下一周开始时，上一周的全部任务都是已做完、已测试、已验收。
比如上一小节中给杨艺安排了27小时产出，她完成验收的只有12小时，然后另外有几个任务提交了还没有测试，另外还有一个任务完成了60%。杨艺上周完成任务如下图所示：
杨艺本周安排的任务如下图所示：
可以看到这周实际上已经有3小时任务已完成，只是未验收而已。等到本周验收完成后，这些任务都可以归档为本周完成的了。
4.加上bug管理
bug管理和任务管理的方式其实一模一样。
项目经理会对每一个bug评估标准产出和难度，有了这个标准产出就很容给开发人员安排。
因为每周每个人的上班时间是固定的，每个人的能力水平在一周内也几乎是不变的，这就表示：每个人一周能完成多少小时的标准产出其实几乎也是没啥变化的。
比如，一个初级别员工一周能完成15小时标准产出，项目经理就给他安排20小时左右的工作量；一个高级别员工一周能完成30小时标准产出，项目经理就给他安排40小时工作量。
这个20小时或40小时工作量是包含任务和bug的总的工作量。
而对于员工自己来讲，每周登录系统，只需看TA本周的任务和bug即可，不需要看上一周也不需要看下一周的。通常一周的任务数量10个左右，一眼就能瞟完，只要没有特别指定截止日期的，员工都可以自行安排开发顺序。
这实际上大大降低了员工的工作压力，提升了员工自由度，永远不会有那种工作怎么干都干不完的感觉。
写到这里，我总是想起不少朋友对准确评估标准产出没有信心甚至无从下手。我想说的是：只要你是真的懂技术，请去尝试一周吧，尝试将你们项目里的每一个开发任务都悄悄的评估一个标准产出（不要告诉别人），坚持一周，最多两周，你会发现这真的很简单，并且自己对干这件事已经轻车熟路了。如果两周后还不会，再来找唐虞阁主，我负责手把手教会，但前提是你真的懂技术。
5.本章小结
我见过好些特别能吹的项目经理，说自己有多么丰富的敏捷管理经验。问他怎么敏捷的，说半天归根到底就是把项目需求拆分成多个版本发布而已。
我们每一款产品也会分版本发布，但这只与甲方合同有关，与敏捷毫无关系。
真正的敏捷，是我们团队这样：每周对已验收的任务进行归档，然后把未验收的任务全部放到下一周继续。员工永远只需要