本文首发于唐虞阁微信公众号，欢迎转载，转载请注明来源，否则将追究侵权行为。
我从2011年开始带团队，这其实是第11个年头了，这些年大大小小的团队带了不少，也见识过各种各样的“人才”。
我没有进过大厂，所以本文仅仅是我个人这些年摸索出来的一点经验和思考，对于迷信大厂迷信权威的读者来说本文可能不值一读。
虽然本文仅仅是我个人的一些经验和思考，我也没有任何名气，但我保证你能从本文中读到许多以前可能从未触碰过的观点，这些观点不一定对，但一定与你在其他管理学书籍中读到的不一样。无论你是赞同还是反对，你都将获得一个新的角度看待团队管理。
全文1.6万字，第二篇内容比较抽象、晦涩，建议收藏分次阅读，阅读中怀疑、怀疑中思考、思考中获得。我希望读者朋友们能够保持怀疑、开放、独立思考的能力的阅读本文，这样你才可能收获更多。
第一篇 项目管理
项目管理，即管事，对事负责。
第1章、需求管理
需求管理分为三部分：需求文档管理、功能页面需求管理、测试用例管理。
1. 文档管理
文档管理首先要实现各种需求文档的统一管理，不要到处都是文档，需要的时候却找不着。
其次是文档的即时更新。比如我们跟甲方沟通过程中的需求文档，从一开始到签合同，中间可能产生了很多个版本，我们需要将这些版本都统一管理到一起。如下图所示：
除了需求文档，项目开发资源其实也应该管理到一起，比如服务器资源、账号、开发指南，等等等等。如下图：
2. 功能需求管理
功能需求，即页面需求。我们一个软件项目，最终都是会被拆分成无数个功能页面来完成开发的。
那么页面需求应该放到什么地方统一管理呢？原型？UI图？需求文档？
我们团队以前尝试过通过Axure（一款原型设计软件）来管理需求，就是把开发需求直接写在原型页面上。当需求改变时，先修改Axure源文件，然后再发布。
这样做很快便遇到2个无法调和的问题。
问题1：开发需求其实比原型页面变动的频率高得多。有时候因为开发需求描述不准确或者不够详细，不得不修改Axure文件，很不划算。
问题2：大量的测试用例无法直接写到Axure上面，也让测试用例管理变得无比艰难。
于是我们团队最终得到如下的需求管理模式：
（1）使用Axure画原型，然后生成html，然后通过阿里云OSS BROWSER上传到阿里云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章）
注意，这时候所有任务通常都没有指派开发者，通常也没有设置截止日期。
举个例子，假如一个拥有100个页面的项目，需求数就是100个左右，任务数就是两三百个，根据客户端数量而定。
当这两三百个任务全部完成创建和评估（标准产出）后，项目就算初始化完成。这时我们可以看到所有的任务都是未指派开发者的，也没有设置截止日期。如下图所示：
项目初始化完成之后，接下来便是安排开发了。
2. 安排第一周任务
项目经理根据自己判断或客户要求，自行选择哪一部分任务先开发，哪些后开发。然后将任务指派给具体的开发人员，并设置截止日期为当周周日。
注意，我们并不会强制要求员工必须在截止日期前完成任务，超时也并不会有任何惩罚。设置截止日期，仅仅是为了帮助员工只用关心自己本周的任务。如下图：
项目经理安排的一周的任务量，通常也会稍稍高于该员工的能力。如上图所示，杨艺本周目标标准产出27小时，但是她通常只能完成20小时的产出（按照一周上班35小时计算的话）。
第一周任务安排完成后，项目经理可以看到每个员工的工作量，以及大家的开发内容分布，如下图：
根据这个分布图，就可以一目了然的知道任务量、任务难度、需求范围安排是否合理了。
3. 后续每周安排任务
如上一小节所述，项目经理会给每个成员都稍微多安排一点工作，那么每周结束时大概率就有一部分任务无法完成，这个很正常。
这时，比如又到周末了，项目经理会将本周未完成验收的全部任务重新修改截止日期为下一周周日。从而保证下一周开始时，上一周的全部任务都是已做完、已测试、已验收。
比如上一小节中给杨艺安排了27小时产出，她完成验收的只有12小时，然后另外有几个任务提交了还没有测试，另外还有一个任务完成了60%。杨艺上周完成任务如下图所示：
杨艺本周安排的任务如下图所示：
可以看到这周实际上已经有3小时任务已完成，只是未验收而已。等到本周验收完成后，这些任务都可以归档为本周完成的了。
4. 加上bug管理
bug管理和任务管理的方式其实一模一样。
项目经理会对每一个bug评估标准产出和难度，有了这个标准产出就很容给开发人员安排。
因为每周每个人的上班时间是固定的，每个人的能力水平在一周内也几乎是不变的，这就表示：每个人一周能完成多少小时的标准产出其实几乎也是没啥变化的。
比如，一个初级别员工一周能完成15小时标准产出，项目经理就给他安排20小时左右的工作量；一个高级别员工一周能完成30小时标准产出，项目经理就给他安排40小时工作量。
这个20小时或40小时工作量是包含任务和bug的总的工作量。
而对于员工自己来讲，每周登录系统，只需看TA本周的任务和bug即可，不需要看上一周也不需要看下一周的。通常一周的任务数量10个左右，一眼就能瞟完，只要没有特别指定截止日期的，员工都可以自行安排开发顺序。
这实际上大大降低了员工的工作压力，提升了员工自由度，永远不会有那种工作怎么干都干不完的感觉。
写到这里，我总是想起不少朋友对准确评估标准产出没有信心甚至无从下手。我想说的是：只要你是真的懂技术，请去尝试一周吧，尝试将你们项目里的每一个开发任务都悄悄的评估一个标准产出（不要告诉别人），坚持一周，最多两周，你会发现这真的很简单，并且自己对干这件事已经轻车熟路了。如果两周后还不会，再来找唐虞阁主，我负责手把手教会，但前提是你真的懂技术。
5. 本章小结
我见过好些特别能吹的项目经理，说自己有多么丰富的敏捷管理经验。问他怎么敏捷的，说半天归根到底就是把项目需求拆分成多个版本发布而已。
我们每一款产品也会分版本发布，但这只与甲方合同有关，与敏捷毫无关系。
真正的敏捷，是我们团队这样：每周对已验收的任务进行归档，然后把未验收的任务全部放到下一周继续。员工永远只需要关注自己本周的几个或十来个任务即可。
这样的敏捷，与产品版本没有半毛钱关系。
这样的敏捷，虽然实现起来非常简单，就是一瞬间管理观念的转变而已，但是带来的效果非常的明显。并且不管一个项目多大团队多少人，只需要按照这个模式一周一周的走下去，项目就会有条不紊且高质量的完成。
这才是真正的敏捷。
第3章、进度管理
试想一下，当你们公司其他项目组只能以“进度正常”、“进度延后”等模糊字眼的时候，而你却能像下面这样汇报：
当前项目已验收任务总进度52.8%，加上待验收任务总进度为58.9%，距离提交内测版截止日期剩余56个工作日，剩余标准产出856小时，按照团队之前的效率（22.5小时标准产出/天），需要38个工作日完成，也就是说还有18个工作日的富余。
你老板一定会对你刮目相看。
如何做到呢？其实真的很简单！
1. 评估所有任务标准产出
首先，让我们回顾一下前两章内容中，我们项目管理的流程：
产品原型画完；
项目经理根据原型页面1:1创建在线需求文档；
项目经理按照原型编写API文档，同时，测试小组基于在线需求文档补充测试用例；
项目经理为每一个需求，针对每一端开发人员创建开发任务，并评估该任务的标准产出（小时）。
如果按照以上流程操作，至此，整个项目所有开发任务都已经全部录入系统了，并且每个任务都评估了标准产出，这样我们就会得到该项目的总产出数字。
正是因为每个任务都有一个标准产出数字，接下来，一切都开始变得简单。
比如，你将随时知道整个项目已验收工作量，以及已提交待验收工作量，以及剩余未开始的工作量。
你可以知道每个团队成员在这个项目中的工作量分布，哪些人工作量大，哪些人工作量小，一目了然如下图：
你还可以看到各个功能模块的工作量分布，哪些模块工作量大，哪些模块工作量小，项目做完后这个数字可以用于校验我们报价的准确度，一目了然如下图：
写到这里， 我又想起一些朋友担心学不会评估标准产出而踟蹰不前。其实评估标准产出真的很简单，一开始完全可以按照“如果自己来开发这个任务需要花多少小时”当做标准产出。但是有的朋友既想提升自己的管理水平，又怕这怕那怕麻烦怕学习怕尝试，到头来还来质疑我们的管理理论，这样的态度实在不可取。
2. 避免无谓的加班
一个常态化加班的团队一定不是一个聪明的团队。
长期加班对团队的危害我在这里就不展开了，短期加班我倒是并不反对。我真正反对的是无谓的加班。
什么叫无谓的加班？
我想起曾经的一个老板，他跟我们部门经理说他压力多大，要是晚上七八点到公司看不见几个人加班，心里就发慌。于是整个公司几乎所有人都在无谓的加班，即使没啥事可干也要坐到七点多才走。
还有种无谓的加班是这种情况，因为管理者/老板无法评估项目的真实进度，因为担心逾期所以要求大家加班加点的干。早点干完后面没项目了坐着干耍都可以。慢慢地，感觉团队被掏空。
无谓的加班对团队有害无益，如何避免呢？很简单！
请看下方项目经理关于加班的汇报就明白了：
当前项目距截止日期剩余56个工作日，剩余标准产出856小时，按照团队之前的效率（16小时标准产出/天），需要54个工作日完成，富余工作日较低，特此申请本周六起周六全天加班，直到进度压力缓解。
这样的加班安排相信谁都没有怨言。
要做到这一点，如果你们团队已经建立起了本文所描述的管理模式，那你们就已经做到了。
3. 浪费时间还是节约时间？
不断地创建和评估每一个任务，下属做的每一个开发任务都必须先由管理者创建并评估，不允许下属做未安排的任务。很多朋友跟我说，如果一个管理者做了这些事，那一天就做不了其他事了，但是管理者自身也是有很多事要做的呀，自己都忙不过来的呀。
我想说的是：
（1）如果一个管理者的业务工作和管理工作在时间上无法调和的话，那首先应该保证管理工作的有序进行。因为如果管理工作做不好，整个团队其他人的工作效率和工作质量都得不到保证，很快就会让整个团队陷入乱糟糟的境地。
（2）一个管理者应该把自己拆分成两半来看，一半做管理工作，一半做业务工作。当做业务工作的时候，自己就是一个普通的项目成员，不应该拥有任何特权，应该把自己当做一个普通成员来安排任务，从而保证所有人的工作安排都有条不紊，切不可因为自己的特殊性影响整个团队。
（3）以我们团队的经验来看，一个项目经理每天上班7个小时，在项目初期可能需要全天做管理工作，但在项目初始化之后，实际上每天只需要安排1-2个小时来做管理工作就足够了。本节开篇那些表示忙不过来的管理者，有几个人每天都能保证30分钟的管理时间？这些管理者，完全就是陷入自我感动的忙碌中去了。
（4）忙归忙，乱归乱。忙不能成为乱的借口，相反，如果能在忙的时候还能把团队管理的有条不紊，那才是真水平。
有这打嘴炮的时间，不如多学学、多试试、多摸索，逐渐建立起属于自己的管理模型，这才是正道。
4. 本章小结
我们常说一个管理者对项目、团队的掌控度怎样怎样，体现了一个管理者的管理能力。
掌控的意思，就是不管大家忙成什么样了，团队的一切事情都还在有条不紊的进行，只是大家每天工作时间变长了，其他什么都没变。该怎么创建评估任务就怎么创建评估，该怎么安排任务就怎么安排，完全不会因为忙就乱了章法。
这样的管理模式需要坚定的理论支撑才能达到的，没有坚定的理论支撑，工作一忙就容易动摇，一动摇就会更乱，就更难以实现。
本文所讲述的管理模式，是我们团队在过去十多年程序员团队带队过程中不断创新摸索出来的，虽然可能不100%适用你们的团队，但我相信一定值得你们为之一试。
第4章、质量管理
程序员团队的工作质量，是通过bug来体现的。几乎所有程序员团队都使用bug管理系统，但简单的bug管理并不等于质量管理，也无法提升团队的工作质量。
利用bug管理大幅提升团队工作质量，请看我们团队是如何做到的。
1. bug扣分
首先，我们针对所有bug类型制定了严格的扣分标准，这个扣分标准只与bug的严重程度相关，而与修复bug所花的时间没有太大关系。举例如下图所示：
这样，我们测试人员在提bug的时候，就会按照这个扣分标准去评价这个bug的严重程度。
注意，上方扣分标准表格里面的“5：一般-自测不充分”这一项。相信很多团队都遇到过，开发人员完成开发后，根本就没有充分自测就提交了，开发人员想，反正有测试同学会提bug，到时改bug就好了嘛。
事实上，大量的未自测bug会大幅降低团队的工作效率。试想，开发人员完成一个几小时的任务开发，本来过一遍所有需求点（测试用例）花不了多少时间，但直接提交结果导致好几个bug。首先这浪费了测试人员的时间，其次开发人员后面修复这个bug的时候，肯定没有刚开发完成时那么熟悉，最后如果这个bug没有被发现呢？
自从我们团队加了这一条扣分标准之后，几乎就再也没有出现过这种“愚蠢”的bug了。
2. bug扣分应与工资挂钩吗？
我们建立bug扣分机制并不是用来扣员工工资的。bug扣分主要用在奖金发放和晋升的时候。
有些团队也引入了bug扣分机制，但直接与当月工资挂钩，这会给员工巨大的压力（虽然没扣几块钱），并且会让员工心里很不爽。
我们团队设计的bug扣分机制，完全不会影响员工当月工资，但是当有项目奖金或年终奖的时候，bug扣分就会成为相当重要的角色，一年的扣分可能拉开几万块的差距，所以没人敢不在乎这个数字。另外，职级晋升也会对bug扣分有明文要求，即使工作能力再强但是扣分太多也无法晋升。所以，更没人敢忽视这个数字。
bug扣分还用于同事之间的横向比较。哪个人长期扣分较多，哪个人长期扣分较少，管理者心里跟明镜似的。这都将成为人事决策的重要依据。
3. 回归测试
软件项目开发过程中，总会有些时候测试人员是比较闲的。这时我们就会安排测试人员进行回归测试。
因为我们所有需求文档都已经在线化，并且所有需求下面都有完整的测试用例，因此建立回归测试计划就变得非常简单。如下图：
创建测试计划之后，可以将待测试的需求指派给具体的测试人员，测试人员可以标记测试状态、提bug、记录测试备注等等，如下图：
4. 本章小结
建立bug扣分机制，就好像给团队中引入了一股神秘的力量，这股力量时时刻刻督促每个成员更加注重工作质量，更加注重自测。
如果将bug扣分与工资挂钩，这就会产生巨大的副作用。所以，我们团队摸索出的经验是，只将bug扣分与员工长期利益挂钩，而不要与短期利益挂钩。
最后我想说，引入bug扣分机制，不是为了要扣谁的工资，但却会实实在在大幅提升团队工作质量，避免大量“愚蠢”的bug产生，从另一个角度讲也是提升了工作效率，最终提升企业竞争力，最终所有员工都将受益。
第5章、API文档
我们团队于2018年自创的API文档服务器，对于提升我们整个开发团队的工作效率贡献了非常大的作用。
我猜大概将我们团队整体效率提升20%左右。你可能会表示非常怀疑，但当你读完本章内容后，你可能会表示相信。
1. API文档由谁编写？
在我们团队，API文档通常是由项目经理或架构师编写的。
编写者要求有非常高的编码素养，包括优秀的命名能力、优秀的系统设计能力、丰富的系统架构经验、丰富的编码经验等等。同时，还要求精通需求。
我粗略统计过我们上个项目API文档的质量，API文档第一版发布出来之后，后面被修改的概率低于5%，这还包括需求变动带来的修改。
这修改过的5%里面，大部分都还是因为笔误，因为复制粘贴时可能忘了改URL或示例数据或字段名称什么的。真正因为API文档设计错误而修改的，比如数据结构不对、业务流程设计错误等，绝对低于1%。
所以，我们第一版的API文档质量是相当高的。单就这一点，就可以避免相当可观的工作量浪费以及团队成员间扯皮。
所以，我们团队总结出的关于API文档的第一条经验就是：API文档编写工作属于高级工作，绝不应该偷懒交给初中级开发人员去写。
2. API文档何时编写？
我知道，不少团队的API文档是由服务器端开发人员编写的，很多甚至还是通过后端代码生成的，比如swagger。这会导致客户端开发人员强行依赖服务器端开发。
我们团队的API文档，是在需求确定之后，项目经理创建专门的API文档源码项目。这样，前后端开发人员依赖的都是API，而不是前端依赖后端。
API文档编写完成后，我们会把API文档的地址加到在线需求文档里面，这样当开发人员做这个需求下面的任务时，就可以清晰的看到应该调用哪个API。对于大多数页面来讲，我们这个过程都不用任何形式的沟通的，开发人员自己按照需求文档做即可，因为需求文档里面有TA需要的所有信息。如下图所示：
所以你可以看到，我们整个团队就像一个精密设计的机器一样，这个机器的各个部件都围绕需求中心运转，各个部件所需要的资源都可以从需求中心获得。所以在我们团队做常规任务开发时，几乎不需要任何的沟通，大家非常有默契。
这就是效率！
我再重新解释一遍整个机器的运行原理：
项目经理按照原型1:1录入需求文档；
项目经理按照需求文档编写API文档，测试人员按照需求文档完善测试用例；
项目经理按照需求文档创建全部开发任务，项目初始化完成；
每周，项目经理提前给每个人安排足够一周的工作量的任务；
每天，开发成员登入系统，查看自己本周的任务和bug，开发任务所需要的API文档、需求、测试用例，都可以通过任务关联的需求查看；
每天，测试人员登入系统查看已提交待测试的任务/bug，然后去验收或提新的bug。
怎么样，不知隔着屏幕你是否能感受到我们团队的效率。
3. API文档如何编写？
我们的API文档源码使用JavaScript编写，使用intellij idea作为开发工具（或者其他任何文本编辑IDE），我们工作界面大致如下图所示：
API文档JS源文件通过git或svn提交到代码仓库，唐虞阁API文档服务器会自动从配置好的源码仓库加载js文件，并呈现API文档，如下图：
从上面截图可以看出，短短20行js源代码，生成了如此丰富的API文档，这就是效率！
除此之外，充分利用intellij idea的智能提示功能、复制粘贴功能，以及JavaScript语言的动态性，都可以大幅提升编写API文档的效率。
这是我们团队摸索多年，突有一天灵光乍现，才发明的一套全新的API文档编写/渲染框架。可以说是全网编写效率最高、可维护性最高的一个框架，不服的朋友欢迎评论区交流。
不仅如此，这还是去前后端耦合的一个框架，让前后端真正分离！
这样的一个API编写体验，你不想试试吗？
4. 本章小结
优秀的API文档管理模型，帮助我们团队整体提升20%工作效率。这体现在：
API文档全部由项目经理或架构师等高级别员工编写，减少设计错误就是减少返工、减少沟通成本；
API文档项目是独立于后端和前端的，解耦前端对后端的依赖，使前后端真正分离；
由我们团队自创的API渲染引擎，让API源码足够简化，且可充分利用IDE的各种强大功能，大幅减少API编写时间，大幅降低API维护成本。
第6章、项目管理总结
以上5个章节的内容，就是我们团队在项目管理方面最核心的经验总结了。其中包含了我们团队在项目管理过程中做的大量的尝试、探索和创新。每一条经验都来之不易，希望能够对你和你的团队有所启发。
接下来，让我们继续探索管理，因为管理不只是管事，更重要的是管人。
这里的“管”字我觉得是“负责”的意思。“管事”就是对事负责，对项目负责；“管人”就是对人负责，对团队、组织负责。
我们团队在“管人”方面积累的经验和感悟，我认为其价值是远高于项目管理的。接下来，我将继续，毫无保留的为你分享，我们在团队管理中沉淀的所悟所得。
第二篇 团队管理
管理就是识人用人，本文第一篇讲的项目管理过程就是“用人”的过程。
本篇内容讲“识人”。
第1章 被玄化的管理学
管理学的理论太多太多，随便在网上一搜一箩筐。我先给大家看看管理学是如何被玄化的：
“管理就是管人性”、“管理就是通过他人来达成目标”、“管理就是把人和事做到充分结合”、“管理就是让别人做你想做的事”、“不懂管理就自己累到死”、“管理是一种手段而非目的”、“做领导必须先学会忍受孤独”、“想当好领导就不能故好人”、“做领导看人要准用人要狠”、“做领导心胸要宽格局要大”、“管理就是管人心”、“管理就是原则”、“管理就是控制”、“管理者要无为，让下属有为”、“要成为领导者，必须先学会领导自己”、“管理是向上管理，向下负责”、“管理的核心是激活人”
什么叫被玄化？就是看起来都对，一做就出错。说白了就是：被故意夸大的但却难以被复制的管理经验。这些经验大都不是管理学的主要矛盾，管理学的主要矛盾我认为就是识人用人的学问。
所以，不管你花了多少精力去钻研这些玄乎的管理学，即使学成了，也不见得适用你的团队，效果很可能微乎其微甚至适得其反。
第2章 管理很简单
我的管理理论其实很简单：通过项目管理采集评价数字，在完成项目管理的同时即完成对人的评价，即识人。
我认为管理很简单，一点也不玄乎。
在我们团队要当好一个管理者，不要求你懂人性、不要求你懂心理学、不要求你能说会道、不要求你懂人心、不要求你精于人情世故、不要求你精通人事关系。
所以，即使你是一个性格孤僻甚至怪异的人，即使你是一个特立独行的人，也完全不影响你当好一个管理者。
但有一个要求，那就是要求你必须懂业务。
什么叫懂业务：
能够将一个大项目拆分成无数个小任务的能力；
任务拆分后，能够评估每个任务的标准产出的能力；
任务拆分后，能够评估每个任务的工作难度的能力；
工作出现bug时，能够评估这个bug的严重级别的能力。
拥有这四个能力才叫懂业务。
只要拥有了这四个能力，你就可以成为一个优秀的管理者。当然，我这里所说的“优秀的管理者”，可能跟你想的有一点不一样。
第3章 如何评价一个团队的管理水平
我们团队做项目管理、做任务/bug的标准产出和难度值评估的目的，不仅仅是为了“用人”，更重要的是为了“识人”。
我个人认为，评价一个管理者的水平怎么样，关键是看TA识人用人的水平怎么样，而识人的权重与用人的权重比可能高达8:2，也就是说识人能力占8成，用人能力占2成。识人能力远比用人能力重要。
识人能力强，慢慢的团队就会聚集人才；识人能力差，慢慢的团队就会聚集庸才和小人。一个团队若都是庸才和小人，就算你有再强的用人能力，也难以力挽狂澜。
以前我认为，管理决策的加权正确率体现了一个团队的管理水平，但现在我认为这其实只是表象的管理水平。真正的管理水平：指一个管理体系能够准确评价一个成员所需时间多少的水平。
注意，我这里说的不是识别人才的正确率，而是识别人才的耗时长短。因为如果在时间尺度上没有限制的话，一个管理者迟早会认清TA的下属的。关键就是花1个月认清还是花10年认清，这才是体现管理者水平的关键。
本篇内容就是给大家分享，我们团队多年来摸索出的：如何建立快速识人管理体系。这个体系对管理者的要求很低，可以轻易复制到你的团队。
第4章 如何建立快速识人管理体系
我再次重申：我们的目标从来都不是准确识人，而是快速识人。因为如果在时间尺度上没有限制的话，一个管理者迟早能做到准确识人。关键就是花1个月还是花10年，这才是体现管理者水平的关键。
在正式开始理论展开之前，我先分享一个我们团队的例子，好让大家对快速识人的感受更深刻。
以前，我们招过一个员工，名校毕业，在大厂工作过2年，面试的时候表现也比较好，所以工资就给的高一点。但是一个月下来，其标准产出和难度值都不如工资比他低1000的同事。后来我给老板汇报了这件事，老板说需按照公司职业标准调整工资，或者走人。然后我找这个新人谈了一下，他接受了降薪，因为他自己也知道以前在大厂确实没有学到什么东西，导致工作产出值和难度值都达不到公司要求。
这个例子的积极意义在于：1）维护了团队公平；2）降低了该员工心理负担；3）减少了企业成本。
这个例子中，我们主要通过【标准产出】和【难度值】两个数字进行判断，得到了较为准确的结果。
其实，我们提的准确识人并不是要100%准确，有个百分之八九十的准确度就足够我们做出正确的决策了。只有杠精才会去追求100%的准确度。
如何做到八九十的准确度呢？关键就在于【标准产出】和【难度值】两个数字。
这2个数字均来自于我们项目管理过程。因为我们项目经理在安排及验收任务的时候，一定会对每一个任务进行标准产出和难度值的评估/修正。这样，我们每周、每月、每个项目做完就会得到每个成员在该时段内的标准产出总值和平均任务难度值。
当然，这要求一个管理者充分发挥TA的管理职能，要花时间去对每一个任务/bug进行评估，并且要有这个评估的能力。
每每写到数字化评估，我就总是想到有些朋友觉得评估标准产出和难度值太难了，甚至感觉无从下手。这里我继续啰嗦一下，只要你去尝试了就会知道，这件事并不难，最长一个月便会轻车熟路，当然，前提是你得拥有懂业务的四个能力。
因此，我们建立快速识人管理体系的方法很简单，那就是：通过项目管理采集评价数字，然后通过这些数字作横向纵向（时间）比较，就可以实现快速、准确识人。
第5章 项目管理过程中的4个评价数字
我们团队在项目管理过程中采集的4个评价数字，分别是：投入时间（Input）、标准产出（Output）、扣分（Punishment）、难度（Difficulty），简称IOPD。
先说这4个数字中最重要的一个数字：标准产出。
1、标准产出
定义：一个行业中等偏上水平的员工完成一个任务所需要花费的时间。
所以，标准产出都是以时间为单位，唐虞阁项目管理系统中的标准产出都建议采用小时为单位。
刚开始时，管理者可能对“行业中等偏上”把握不准，那么完全可以按照管理者自己的水平来评估即可，即：管理者自己做这个任务需要花多少时间就是标准产出。
特别注意，标准产出这个数字绝对不是按照任务指派人的水平去评估，一定得按照一个“标准人”的水平去评估。
标准产出带来的管理体验是颠覆性的，在我们7个数字的管理体系中是最重要的一个数字，我认为占据50%权重。实现了标准产出，就实现了50%的数字化管理体系。
引入标准产出后，企业很多问题都将变得简单，比如：老员工干得少拿得多、有些人嘴上能吹干事却不行、新员工试用期满转正定级、职级晋升、奖金发放。
根据我们团队的经验，强烈建议：标准产出不应与工资挂钩，但应与晋升和奖金挂钩。抽象的讲：标准产出不应与员工短期利益挂钩，而应与员工长期利益挂钩，从而规避KPI副作用。
2、难度
我们发现，引入难度值之后，会产生意想不到的效果。
效果1：可以看出管理者的工作安排是否合理。比如一个技术经理下面带了3个人，其中一个高级工程师，如果一个月下来这个高级工程师的平均工作难度还不如其他中低级的难度，那就说明技术经理任务安排的不合理，应该把有难度的任务安排给高级的人才。
效果2：可以清晰看出公司花高薪聘请的人才是否名副其实。比如，公司花2万月薪请了一个架构师，但是一个月下来，这个架构师完成的任务达不到企业其他架构师的难度，那就可能是这个架构师吹牛了。
效果3：让员工晋升更有理有据。能够长期持续完成更难的任务，说明这个员工的职业技能得到了提升。职业技能的提升，就应该是晋升的重要依据。这样，企业就可以降低“论资排辈”的依赖性，更放心大胆的去改革晋升机制。
晋升机制的改革，会极大的刺激员工的积极性，会对整个企业管理体系产生非常明显的积极影响。员工之间会更加注重职业技能的竞争，而不再是职业关系的经营，这会大大简化员工关系，提升整个组织的工作效率。少了职场中的“阿谀奉承”、“尔虞我诈”、“勾心斗角”等等，你会明显感觉到企业中的“乌烟瘴气”消失了，一个政治清明、积极向上的组织出现了。
这就是“难度”数字的神奇表现。
3、扣分
我们团队引入扣分数字，是因为以前很多程序员开发完一个功能后，基本不自测就提交给测试同学了，以致导致大量的bug和返工，浪费测试资源。
然后我们就引入了扣分机制。对于那些自测都不做就提交任务导致的bug，全部当做“严重”级别的扣分处理。
效果怎么样呢？
可以说是立竿见影！
当天开会宣布扣分机制，当天就再也没有产生这种没有自测的bug。为什么呢？因为这本来就是一种工作习惯的引导而已。一个人完成工作后，本来就应该自己检查一遍再提交给下一个环节处理，只要做了这个检查/自测的工作，就一定可以避免低级的工作失误。
所以说效果太快太好。
项目建立扣分机制之后，每个员工会更加注重自测。更多的自测会大大提高整个团队的工作效率，原理大家一想就明白。
其实，我们建立扣分机制，不是想要去扣员工的分。而是建立这个机制之后，整个团队中就像有了一股神秘的力量，时刻监督着大家要把工作做好、测好再提交，大幅度减少“返工”。
我看到不少的软件开发团队，开发一个新需求只需要花一周，但是测试验收要花两三周，甚至四五周。这样的团队很多很多。
我们建立的唐虞阁人才数字化评价体系，不是要去扣员工的工资，而是旨在建立一套完整的管理体系，这套体系会时刻敦促员工注意工作质量，大幅减少工作失误，而不是等到员工出现工作失误之后去扣员工的工资。
所以，唐虞之治的治，更多的是一种“预”的机制。
4、投入
投入数字记录每个员工每天的上班时长。
我有个朋友的公司，有的员工明明没啥事，每天晚上也要坐到7点多才走；还有的部门长期都比较闲，可能也是因为闲惯了，安排个事吧总是要拖很久才做完。
后来我跟朋友说，因为他们一天上班7.5小时，那就要求每个员工每天必须填满7.5小时工作内容，即使是开会也要填。
这可把那些闲的人愁坏了。每天明明没有那么多工作，一开始编一编工作内容还能应付，很快就会发现自己江郎才尽：太难编了，或者编的看着太假，自己都看不下去。
然后这些人就会主动向上级要工作了，或者实在没事就安排学习吧。以前只知道有些人比较闲，现在知道这些人到底有多闲。
就这一个简单的数字，大大提供了我朋友公司的闲置资源利用率。就这么神奇！
当然，投入数字还有其他应用场景，比如有的人请假多（家里事多）、有的人加班多，这个数字都会帮每一个员工记着。有苦劳的人，公司也绝不辜负。
第6章 贡献值
贡献值这个数字其实并非采集来的数字，而是通过IOPD模型计算而来的数字。
首先，企业需要设置贡献值算法，如下图所示：
以上图中的贡献值算法为例：贡献值 = i+o*2+o*d*5-p*5
这个算法表示：贡献值=投入时间+标准产出的2倍+标准产出X难度值的5倍-扣分的5倍。
贡献值最大的用途就是奖金分配。
比如，一年下来，我们得到如下表所示的数据：
假设公司年终拿出50万发年终奖，那么每个人应该拿多少年终奖，完全可以按照贡献值比例计算而得，如下表所示：
从上表看出，苟建国分得12.8万年终奖，易潇潇分得2.8万年终奖。每个人分得都不一样，这是因为平均不一定等于公平。
虽然每个人分得不一样，但保证每个人都没有任何怨言。不管职级高低，都能分得自己应得的那部分奖金。并且保证第二年大家会更加在乎产出、扣分、难度、投入等数字。
从上表2021年数据看，每1（股）贡献值可换2.8元年终奖，员工可以选择兑换也可以选择留到下一年一起兑换，因为说不定下一年1（股）贡献值可换10元呢。
发奖金本来是好事，但很容易处理不好导致不愉快，关键就在于两个字：公平。没有公开透明的数字化的客观的评价标准，“公平”二字在每个人心中的理解都不可能完全一样的。
所以我们团队这种方式，不仅绝无可能产生矛盾，还可以非常清晰的向员工传递公司的经营理念：什么样的员工是公司认可的。
除了根据贡献值发奖金，还可以设置质量奖（扣分比例最低的）、劳模奖（投入时间最多的）、大牛奖（难度值最高）等等。
贡献值数字除了用于奖金分配，也可以用于其他场景，比如：晋升、期权、股票、假期奖励等。
第7章 周报系统
我们团队使用唐虞阁周报系统主要有2个目的。
目的1：将所有职级的员工每周表现数字向100分制投影。
目的2：加强对管理者的监督。
先说目的1。因为员工职级不同、工资不同，他们每周的IOPD+贡献值等5个数字都是绝对数字，绝对数字的多少不容易看出谁表现好谁表现差。
比如下表所示：
上表实际上是看不出来每个员工当周表现如何的，因为每个人职级不一样，工资不一样，这时我们就需要周报系统来将绝对值转换为相对值。
首先在唐虞阁系统中配置每个员工所属职业的周报评价模型和下级打分模型，如下图：
职业模型设置之后，每个员工每周提交周报的时候，员工就可以给其上级打分，上级也需要给员工打分。这个打分都是相对员工所在职级进行打分的。
下级提交周报时给上级打分如下图：
上级评阅周报时给下级打分如下图：
我们的【效率】分是根据每个职级的“80分标准产出”来计算的。比如P1职级每周80分标准产出是15小时，员工做到15小时产出就可以得80的效率分。【质量】分是根据bug扣分来计算的，【态度】分则是管理者主观评价（我们相信长时间的主观评价也是相对比较客观的数据）。
每周周报评阅完成之后，我们就可以得到如下图所示的表格：
上表按照上级加权打分排序，就可以看出，哪个员工本周表现好哪个员工本周表现差了。
下面说目的2：加强对管理者的监督。
唐虞阁周报系统包含了一个下级给管理者打分的功能。下级给管理者打的分和评语，管理者是看不见的，只有管理者的上级才看得见。
这个机制的建立，会大幅降低管理者为所欲为的概率。比如，经常有些管理者会冒领下级的功劳，下级只能忍气吞声，有了这个机制之后，管理者再想干坏事，心理就得掂量掂量了。
还有的管理者一点不尊重下属员工，一副高高在上的样子，动不动就辱骂、责怪、甩锅下属。这样的管理者通常对其上级极其阿谀逢迎。如果没有这样的周报机制，上级领导想要发现这样的管理者还不那么容易，可能得要较长时间。
所以，我们的管理体系，就是帮助管理者更快速的识别人才、庸才。“更快”才是我们的管理目标。如果说职场是一场戏的话，我们希望小人们第一集就领盒饭，而不是等到大结局。
第三篇 总结
以下内容为我十来年总结的对团队管理的一点看法，希望能对大家有所启发：
1、管理就是识人用人的过程，管事就是对事负责，即用人过程；管人就是对人负责，即识人。
2、识人远比用人重要。管理者能识人，团队就会越来越聚集人才；管理者不能识人，团队就会越来越聚集庸人和小人。
3、识人快慢体现了一个组织的管理水平，而不是识人准确率。因为如果在时间维度上没有限制的话，再差的管理者总会实现准确识人，关键就在于耗时一个月还是10年的区别。
4、我们团队建立了完善了快速识人体系，说白了就是7个数字而已：投入、产出、扣分、难度、贡献值、上对下评分、下对上评分。
5、这7个数字的权重不是均匀的，实现标准产出就可以说完成了50%的数字化人才体系建设，完成7个数字的话，就可以说实现了95%以上的数字化人才体系建设。
6、“标准产出”是我们管理体系中核心的核心。建立了标准产出评估机制，可以说就打开了企业人才数字化的大门。
7、我们在程序员团队积累的经验是：通过项目管理采集数字，通过数字识别人才。“用人”的时候既实现了管事，又完成了识人，识人的结果反过来又会激励和更新人才，从而更好的实现“用人”。
8、管理并不难，也没那么玄乎。我认为一个管理者只需要真正在懂业务就能轻松做好一个管理者。除此之外，其他能力都很次要。
9、懂业务表示管理员拥有4个能力：
能够将一个大项目拆分成无数个小任务的能力；
任务拆分后，能够评估每个任务的标准产出的能力；
任务拆分后，能够评估每个任务的工作难度的能力；
工作出现bug时，能够评估这个bug的严重级别的能力。
10、管理的核心是公平，我们做的一切管理工作都是为了提高团队的公平度。只要团队公平度提升上来了，一切都会进入良性循环：人才会聚集、效率会提供、质量会提高、人事关系会更简单、团队氛围会更加积极，团队会越来越有战斗力。
11、未来的管理一定是数字化的。这里说的数字化，不仅仅是把项目录入系统来管理就完了，而是在做项目管理的同时，要完成对人才的评价数字的采集，然后通过这些数字来识别人才，从而让组织得到进化，为项目管理输入更优秀的人才。
12、本文所传递的管理理论，我认为不仅适用于程序员团队，也适用于其他行业。
朋友，如果你认同我的观点，欢迎点赞转发。
如果你也想试试我们这套管理体系，你可以通过唐虞阁微信公众号联系到我，我仍将毫无保留、倾尽所能帮你们团队出谋划策（免费）。这套管理体系在实施过程中肯定还会遇到一些细节问题，而我的经验可能会帮你们少走一些弯路。
