管理规划

身为产品经理的我们，无论你是否想过做管理，或者有没有机会做管理，职业特性致使“带团队”这件事变得不可避免。换句话说，你叫什么不重要，头衔也不重要，重要的是，为了产品实现，你不得不依托你的团队，你不就是正在带着你的小团队做事吗。

有点工龄的产品经理多少都会具备先天的优势“规划驱动型思维”，对应到管理中就是上边车马模型中的“管理规划”。很多产品经理总是期待解决掉这些问题之后，事情就会好转。这恰恰因为缺少“全盘规划”的思想才会导致两眼一抹黑不知从何下手。如果你能真正开始尝试通过理清未来的发展来理顺当前问题的时候，就开始有点从容了。

用大家都说烂的话术就是“方向把控”。用车马模型做比喻，现在让你驾驭一辆马车，在驾驶它上路之前，想必聪明的你想到的第一个件事就是要弄清楚你所驾驭的是辆什么车。

如果你拉的是一辆长途旅行车。你的目的地就可以设定的非常清楚和鲜明，平安、快速、舒适地把客人送到指定目的地，就是你的职责和使命。你的车内是否舒适、马匹的选择是否快速、选择的路线是否安全等等都是你要考虑的。

而如果你拉的是一辆观光旅游车。你的目的地可以很清楚，也可以不清楚，因为你这辆车的使命在路上，核心是这个过程能否让观光客满意。此时，你的车体设计能否让乘客很方便观赏路上的景色、你的马匹选择是否速度适中、以及路线的选择是否风景优美，就变成了此时你要考虑的。

而如果你拉的是一辆送货的货车，那么你需要考虑的就是你的车是否满足货物要求的环境、一车次能拉多少货、以及马匹和路线的选择，以尽快到达交货地点。要考虑的问题和长途旅行、旅游观光，每辆车设计出来，都是为了满足特定需求的，团队亦是如此。

弄清楚它是一个背负着什么样职责和使命的团队，决定了你需要设定什么样的工作目标，并通过哪些要素来衡量你的目标；决定了你需要什么样的人加入你的团队，以及需要多少；还决定了你选择什么样手段，投入什么样的资源来完成工作。

可以用一个问题的追问来判断自己是否已经获得“初出茅庐”称号。“你是否可以毫不迟疑、非常简练地说出你团队的职责和使命呢？”追问一下，“你的团队成员是否可以毫不迟疑、非常简练地说出你团队的职责和使命呢？”怎么样，是不是发现自己还是个小菜鸡…

职能

刚入行的时候，师傅就指导我学会多追问自己。对于是否真正清楚团队职能可以先问自己三个问题：

• 公司为什么要给我这批资源（指这个团队）？是希望我产出什么？
• 这个团队存在的独特价值是什么？
• 你用什么维度来衡量团队的价值高低？

如果能清楚条理的回答，证明自己是知道团队职能的。如果你能用非常“简洁”的语言来陈述它，那证明你真的很优秀。

那再来一个死亡追问：“你团队的成员，也都能准确无误地说出来吗？”怎样，是否觉得自己需要做的事情更多了呢。大家对自己团队的只能清晰明了，意味着大家有一定的主动性，意味着大家更容易理解自己工作的价值和意义，意味着大家对团队有一定的认同感和归属感。

可以从“基本职责”和“使命感”两个维度看待团队职能。对于基本职责无需多言，比如开发同学的职能是保证每个项目高质量交付和顺利上线。谈到“使命”儿子大家脑海里第一浮现出的就是”画大饼“，而它对于团队的的“幸福感”、“归属感”这些潜移默化提升团队战斗力的素质提升有着至关重要的作用。对于“使命感”个人虽知它的分量，但是因为实践几乎为零，后续有了新的感悟再来补充…

在这里引用别人的一个小故事：

我带过一位测试经理，他带的测试团队工作非常认真负责，他个人和他团队在整个技术部有口皆碑，很受认可。就是这么靠谱的一位 leader，一天突然跟我说想看看别的发展机会，因为做了几年测试，工作太熟悉了，没有挑战，也没有成长。 于是我问他，“你觉得你团队的工作没有挑战，你能否告诉我你团队是做什么的吗？” 他说：“我负责的是测试团队，负责交付高质量的项目，目前大家做得不错，也比较熟练。” 我继续问他：“你的团队叫‘QA’团队，你知道‘QA’是什么意思吗？” 他回答说：“Quality Assurance，质量保证吧？” 我继续问：“既然你负责咱们公司所有产品的质量保证工作，那你觉得就是做好测试吗？” 他若有所悟。我继续对他说：“如果你认为自己团队就是做测试的，保证项目的高质量发布就是你的使命；而如果你把用户能感知到的所有产品质量问题，都纳入质量保障的工作范畴，那你团队还有太多的事情没有做，比如线上质量问题的搜集、整理、跟进、解决、反馈等，以及你是否搭建了产品质量的评估体系。显然都还没做。所以你看，一个仅仅做好测试工作的团队 leader，和一个能搭建公司完整质量保障体系的团队 leader，你觉得挑战和能力要求是一样的吗？” 听我这么一说，他顿时豁然开朗，欣然地筹划团队新的发展去了。时隔一年多后，他还在带着原来的团队稳步地发展和成长，并没有贸然换工作。

有时候，我们觉得自己没有成长，是被自己潜意识的职责定位给限制住罢了。

目标

谈到目标这个话题，想必大家都磨出茧子了，那在这里再磨亿次吧…

首先评判一个目标合理性的标准可以用SMART原则，这是我在考那没啥用的PMP学到的…

只有在一个有限的时间内可以完成的目标是最起码的。
首先要做到目标是可以衡量的，有时限的。比如“我们的目标是发布系统 1.0。”，这显然是就是个屁，不可衡量啥也不是。需要换种描述方式“我们的目标是到明年3月底，发布系统 1.0，支持GMV数据统计、全量数据导出功能。”这就比较合理了。

既然聊到这里，不得不讲这么几个问题场景，想必大家一定一定TMD头痛过：
第一类问题的常见说法：

• 这类问题常见的说法就是，
• “我们团队只能做到个程度”
• “这些项目能做完就不错了”…

面对这类问题要“以终为始”，时刻围绕团队要交付的重要成果，结合优先级调配补充资源，而不是仅仅基于相对遥远的目标推进。

第二类问题的常见说法：

• “我们要在 10 月底，完成架构改造”
• “我们要在 12 月底，上线反作弊系统 1.0”

这类问题，就是缺少可衡量性或者结果性描述。

第三类问题的常见说法：

• “我明明已经按照明确的目标拆分工作任务了，但为什么团队成员很难推动呢？”

这类问题，很可能是目标仅仅对上级和自己来说很清晰，但是没有刻意地向团队成员来传达，导致团队成员对于整个团队的方向感不清晰，那么前面我提到的那些目标能带来的效果就无法显现，因此我们时刻要在例会上进行目标向下同步确认。

第三类问题的常见说法：
“上个月刚定好的目标，就因为老板一句话要对业务方向做调整，反复修改目标。”
这类问题在我们互联网行业中很常见，有时候空降个上级就意味着换一个执行目标。对于这类问题，有大佬指点要在团队内部制定“隐性的专业目标”，比如产品团队对产品设计能力的要求，开发团队对系统性能的要求等等，这可以让团队成员在个人发展方向上的目标在实际业务中有所体现。

团队

这里谈团队三大视角：团队状态、团队资源、人才培养。

你希望在某个时间节点到来的时候，把团队发展成什么状态。换句话说就是，到那个时候团队会是什么样子呢？

那么对于一个团队长什么样子，你要用什么指标来衡量呢？
通常来说是如下三个：首先是团队的规模。也就是你团队有多少人，这其中要理清楚有多少人是现有的，有多少人是接下来要新增的，即实际人数和预算人数，加起来就是你规划的团队总规模。
其次是团队的分工。即，你的团队都负责哪些业务，每个业务配置了多少人力，以及这些人员都如何分工，人力分布和业务目标是否匹配等。
最后是团队的梯队。一个团队的梯队情况代表了团队的成熟度和复原力。梯队成熟的团队，不会因为一些偶然的因素（比如某个核心员工休假，或者某个技术负责人离职等）就随便垮掉。复原力强的团队只是短暂影响部分业务进展，但是不会伤筋动骨、元气大伤，很快就会恢复正常。这个复原力很像技术服务的健壮性，会让团队非常有韧劲，经得起折腾。
综上，如果你从规模、分工和梯队三个要素来描述你团队的情况，就能看清团队的“样貌”了。

从资源角度来审视团队。从资源视角来看待团队，是一个成熟管理者的标志之一。
因为站在公司角度来看，每个团队都是一批人力资源，所以有个专门的职能角色叫 HR（人力资源）。
在现在很多互联网公司里，技术团队往往是最昂贵的资源和成本，预算人力，实质上就是预算资源。所以，作为一个管理者，在盘点自己当前人力和预算人力的时候，需要有成本意识，要考虑投入这么多资源和成本是否值得，是否合理。
其实，即便你不考虑这个问题，你的上级也会考虑，所以，你预算人力的时候，最好能给出十分充分的理由：为什么你需要这些人？为什么是这么多？你的依据和估算逻辑是什么？
当然，你并不需要把所有的推演过程都汇报给上级，但是这并不意味着你不需要一个令人信服的推演逻辑，毕竟光靠“拍脑袋”肯定是不行的。
那么怎样才能够合理推算呢？取决于你对业务的理解，以及你希望达成的目标。毕竟需要投入的人力和目标是息息相关的，和手段的选择也是密切相关的，换句话说你的各项决策都影响着资源的估算，可以参照行业资源配比情况。比如行业里产品、设计、开发、测试、运维等不同角色都有大体的比例，虽然不可照搬，但可用于参照，尤其是业务类型相似的。

团队规划的第三个视角，是从人才培养角度来看梯队规划。关于对团队的盘点，除了团队的发展目标和资源投入视角，还需要从人才培养角度来看。即，到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。一般来说，你重点培养的都是你团队最核心的人，也包括最有潜质的人，但是一般只涉及你的直接下级和他们的个别下级这两层，其他层次的人才培养则是你下级管理者的职责。当然，对于新经理来说，只需关心自己的直接下级就可以了。关于人才的选拔和培养，我们会在后面“团队建设”相关的章节中详细探讨，这里我们就先了解做规划的时候，要涵盖重点人才的培养目标，就可以了。关于新人的培养和引进，这里提出一个新概念叫“团队消化能力”。鉴于团队现实的梯队情况和新人导师的精力问题，一个团队能够良性吸纳的新人是有限的；如果新人引进过快，就会快速冲淡当前的团队状态，就和新组建一个团队差别不大了，这时很多新经理会顾此失彼，团队也近乎失控。所以，这主要看你的取舍。有的管理者倾向于有步骤、有节奏地发展，而有的管理者迫于业务压力，也就不考虑团队消化能力了。这些做法无所谓谁对谁错，只是因人而异罢了。但是无论做哪种选择，考虑你团队能消化多少新人，是你做团队规划时需要关注的一个问题。

那么如何估算团队消化能力呢？不可否认，带新人是需要花费老员工一些时间和精力的。所以要看看你团队都有谁能带人，分别带几个比较合理。所谓合理，就是需要兼顾他们对业务的投入。看看你团队的新人培养机制是否成熟健全。如果你团队有成熟的新人入职培养机制和熟悉业务的学习资料，那么能同时消化的新人就会多一些。所以，作为一个“踏实”的管理者，把这些基础的管理工作做起来，对于团队的长线发展是很有好处的。即便你的直接上级是个“急功近利”的老板，你也可以有自己的管理风格，不是吗？

上面我们从三个视角探讨了做团队规划的逻辑和要点，那么，如果真的要给上级提交一份规划报告，关于团队部分，你应该以什么形式来呈现呢？我建议你要以你和上级约定俗成的习惯和形式来呈现。假如你们还没有明确的要求和约定，那么你可以参照下面的形式，大体上也是三个部分。第一部分，绘制一张组织结构图。这张图需要体现我前面提到的团队状态三要素：规模，包括当前人数、预算人数和总人数。分工，体现团队人力都分布在哪些业务上，以及各个业务都由谁来负责。梯队，包括团队的级别和梯队分布情况。

第二部分，列出整个团队的资源盘点情况。大体是这样的：A 级别：x 人，其中当前 m 人，预算新增 n 人；B 级别：y 人，其中当前 m 人，预算新增 n 人；C 级别：z 人，其中当前 m 人，预算新增 n 人；……第三，列出重点培养对象，以及负责业务。大体是这样的：张三，XX 业务核心工程师，到年底能完全负责 XX 业务，并能带新人；李四，YY 业务负责人，到年底能带 n 人独立负责 YY 业务；……

路径

可能很多一线技术管理者会说，我需要考虑的资源类型非常单一，基本上每次申请资源都是增加人力，这没有什么难的。我想说，增加人手没有问题，只是在采用“增加人手”这个方案之前，你是否考虑到如下的三个问题了呢？第一个问题，你是否了解资源的丰富性呢？一提到资源申请，人们大多会想到的是人、财、物这三大项。对于做技术团队管理的你来说，“人”，是最常见的资源。而且，“财”和“物”的预算一般也围绕着团队的人数来做，比如团建费用、培训费用、差旅费用、办公设备等等，都是基于团队人数来预算的，整体上并不复杂。但这里我需要提醒你的是，还有其他几类资源也需要关注，可不要忽略。首先是时间。很多管理者会忽略时间这个最重要的资源。对于任何一项工作，你预算多少人和你预算多少时间是分不开的。所以，做规划的时候，也需要了解上级对于各项工作的时间预期是什么样的。这意味着，上级允许你花多少时间来做这些工作。千万别认为，上级批准了你的人力预算就等于给了你充足的资源，因为还得看看上级给了你多少时间。而且，上级固然有上级的期待，但你还是得有自己的判断，因为你最清楚各项工作的具体情况，需要综合你对紧急重要程度的理解做出判断。所以，请把时间当做资源来看待，这样你会更加清楚对于投入的理解。其次是信息。信息资源，是另外一个常被忽视的资源。有的时候，你需要更多的公司内外的信息，可能是业务的，也可能是人员的；你的工作如果需要特殊的信息和数据，需要提前和上级沟通，寻求必要的支持。最后是权限。和信息资源类似，也是出于做好某项工作的目的，你可以看看需要开通哪些之前不具备的权限，以及这些权限是否可获得。比如有的公司一线管理者是有沟通绩效权限的，而有的公司则不允许。如果你要把绩效作为重要的人才培养和激励手段的话，就得考虑你能否获取这样的权限。类似的还有，你是否拥有使用奖金激励的权限，你是否被允许参加某个会议的权限等，这都可以是你要关注的资源。所以你看，除了人、财、物，你还需要很多资源的支持，所以当你评估一个平台是否有发挥空间时，可不只是看职位高低，人员多寡。你能否得到全方位的支持，也是很重要的因素。当然，前提是你知道自己需要什么。

第二个问题，你是否意识到手段的多样性呢？工程师出身的管理者，“炫技”的情况比较常见，其中一个显著特征就是，只有自己开发的作品才是最好的，一有机会就重构，因为，“前人写的东西实在是太烂了，不能忍受”，崇尚亲力亲为，凡事自己开发。所以，一旦有大的新需求，用他们的话说，那得“招聘一些工程师才能做”。站在工程师视角上，追求工作的极致品质，恰恰是一种良好的工匠精神。但是站在管理者视角上，就需要评估一段时间内的产出效率了。衡量一项工作“到底需要花 5 天做到 70 分，还是 10 天做到 90 分”，是管理者的日常工作。90 分方案未必就比 70 分方案好，此时，就需要优秀工程师出身的你放弃一些执念了。一旦放松这个念头，你就会发现，完成一项工作，原来还有很多的手段可以选择。下面我就来列举一些。比如你想做一个新功能，诸如“人脸识别”“自动推荐”“反作弊”等。以下的做法是不同的管理者所采用过的：自学自研；招聘专业级人才；借调工程师；跨部门合作；请外包或者外部专业人士兼职做；采购云服务；购买现成的解决方案。在不同的公司、不同的期待之下，不同的管理者会做出不同的选择。这不同的选择会带来不同的效果，同时也意味着不同的成本。对于自学自研来说，由于靠自己团队的力量，资金开销比较低，维护成本也可控；而由于需要边学边做，时间成本会比较高。对于招聘来说，不确定性比较高，招聘顺利固然好，但招聘不顺则时间完全不可预期，整体上时间成本比较高。对于人才借调来说，如果能借调到合适的人，各方面的成本是最低的，但是需要这个事情足够重要才能获得支持。在中大型公司里的管理者，可以把这个方法作为可选路径之一，而早期公司，一般并不具备这个条件。对于跨部门合作来说，项目推进的可控性取决于合作情况，这里最大的风险就是合作成本能否控制住。对于外包来说，时间和资金成本一般都可控，用来做尝试性项目或者 demo 是比较合理的。但如果是长期的任务，你会发现外包的解决方案可维护性比较差，迁移和替换的成本会比较高。采购云服务，对于中小公司来说，其实是很好的解决方案，对人才成本、维护成本、时间成本，都可以降得很低，特别适合初创公司，所以你看业内的云服务层出不穷，确实有价值。买方案，是时间成本很低，资金成本略高的一种方案。在应急的情况下，或者是公司非核心业务的场景下，这倒不失为一种好的解决方案。以上的说法和判断，是我基于我之前的团队情况给

第三个问题，即人力资源的持续性。通俗说就是，不是所有的人力短缺，都要通过招聘来解决。在我给互联网公司做技术管理咨询的过程中，遇到不少中小型公司的技术负责人或创始人，动辄让我帮忙介绍某技术领域的资深专家。他们常常会这样跟我说：说法 1：“对于我们这个业务来说，数据很重要，我需要搭个数据团队，能帮我介绍一位数据大牛吗？”可实际情况是，自己连数据需求都描述不清楚，只是直觉上认为这能给公司带来价值，其实每天的数据量，拉个表格都能看清楚了。说法 2：“我们接下来要做智能推荐系统，得招两个专门做推荐算法的。”但实际情况是，大部分数据都是格式化数据，却连最基本的推荐策略都还没做，还远远达不到专业瓶颈。说法 3：“我们需要招两个做专业图像处理和模式识别的。”但实际情况是，公司业务的核心竞争力在于 O2O 业务，而不在于图像处理技术。以上的这些说法，显然，他们太高估招聘能解决的问题了，而且太低估人才选用育留的成本了。事实上，牛人一般会嫌业务量小、平台小招聘不来，即便来了，成天形单影只的，也未必留得住。所以，招聘作为一种迟缓的解决问题的手段，更多地是看长线是否需要。对于工程师思维特别重的管理者来说，他们尤其倚重技术；对于不懂技术的管理者来说，他们又特别迷信技术。而职业的技术管理者，就需要在这之间找到一个平衡，提供一个既能够解决问题，成本又合理的可操作的执行方案，而不是一个“走一步算一步”的对策。

以上的三个意识如果你都具备，能够从资源丰富性、手段多样性和人才持续性来预算你的资源，说明你已经是一位老道的管理者了。我们通常会说，管理者要做战略，所谓战略是什么呢？其实就是筹划把资源投在什么方向，以达成什么目标。所以，资源视角就是战略视角。至此，我们探讨完了管理规划的全部四个要素：职能、目标、团队和路径。细心的你也许会发现，探讨路径以及预算资源的时候，离不开目标和团队；而盘点团队的时候，又脱不开目标和路径；而设定目标的时候，也需要基于当前团队的情况和可用资源。也就是说，尽管我们是把目标、团队、路径分开来探讨的，但是这几个要素之间并不是割裂的，而是相互联系的。所以，只有你把这三个要素统筹起来，梳理明白，才能“产出”一份完整的管理规划。