如何进行团队管理及项目管理？

当你升到管理岗，项目管理和团队管理就成了你的“家常便饭”。关于项目管理与团队管理，你或许会有一些疑问：如何制定产品计划，才能合理有序地分配团队工作，高效地完成项目呢？怎么做项目管理才能使开发更敏捷呢？那么，以下就由笔者来为大家一一解答这些问题吧！

随着产品逐渐成熟，产品团队也会慢慢成型。产品团队的存在，说明产品工作已经细化拆分。原来一、两个人干的事，现在可以由不同分工的人来处理了。

因此，产品团队的管理，得先从产品工作的拆分说起。

一般来说，产品工作的层面可以分为：产品战略、产品结构、产品框架、产品设计和产品辅助等。

产品战略工作

就是我们在第一篇问答（如何系统思考产品需求）中提高的产品战略工作。

梳理和确认好产品战略，让未来产品工作建立在相同认知基础上，是产品工作中最宏观且最有价值的工作。

产品结构工作

当我们确定了产品战略之后，从战略到具体的产品规划，需要进行信息的转化。

这种转化，就是将产品战略落地，转化为一条条产品线、一个个版本、一张张的功能清单，也就是产品的路线图（roadmap）。

有了清晰的路线图，接下来就可以进入正式的产品规划设计工作阶段了。

产品框架工作

有了实现的路径，就需要按照优先级，分产品线分版本的逐步设计。

这时，我们首先把眼光聚焦在版本内部，我们对所有需要实现的功能进行分析，让他们成为有机结合的整体，让功能组成一个个相关的模块。

同时，也把模块内及模块之间的各个功能，可能的实现流程明确出来。让需要实现的目标功能，变成清晰的多维结构。我们需要使用UML、业务流程图、数据流程图、业务拓扑图等讲这些结构表达出来。

同时，当版本内的设计接近完成时，我们要把眼光切换到多版本上——考虑未来版本和功能的实现，需要当前产品结果预先作出哪些调整和伏笔。这些都完成之后，我们就可以开始按照版本来细化和设计产品了。

产品设计工作

单个版本的产品结构设计完成，并经过各相关团队的评审和协调后，就要回归到产品部门内部进行设计了。

我们需要按照产品的版本结果，设计出前、中、后各端的模块、功能、流程、页面等，这里我们需要画原型、细化流程、设计页面、输出需求说明文档甚至高保真的交互稿。

设计好的产品结果，要宣讲并交付给开发团队，同时也会接受开发团队的各种挑战。

另外建议：在宣讲和交付产品结果的时候，最好能够把对象目标扩展到测试团队、运营团队、业务团队等各个相关业务团队，这样做的好处你试了就知道。

产品辅助工作

除了上述四个产品规划层面的工作外，其他的如：竞品调研、数据采集汇总、项目跟进、Bug处理跟进、产品相关宣传说明配合等工作，都是产品辅助类工作。

这几个层面的工作，并不是每个层面都需要不同的人来负责。本身是可以互相渗透，根据团队的具体情况来身兼多职。

1-3 层面

一般由产品总监、产品团队负责人或高级产品来负责。做到承上启下，配合高层确定产品战略并消化和转化，指导具体的产品规划工作。

4-5 层面

一般由产品经理、产品线经理或产品专员等负责。做好基于产品路径的落地工作，保证产品设计的效率和质量。

拆分层面的意义在于：规范好的工作层面，可以让大家在工作时，明白各自的职责范围，更高效的互相承接和配合。

另外，你说团队成员的产品不符合你的要求，不知该如何处理。

我的建议是：就算从执行层岗位开始转变为管理岗位，也千万不要做甩手掌柜，很多执行方面的工作还是要有目的性的参与。

有目的的参与，可以体现在如下两个方面：

做为产品管理岗位，需要承担产品信息的向下传递——即承上启下的作用，你需要去处理产品战略、产品范围及产品框架等方面的设计工作。

同时，因为接下来要据此来进行具体的产品设计规划，最理解且最能依据产品框架来设计产品的人一定是你。你需要对各端的关键模块、关键页面进行设计，建立从上到下、完整一致的信息传递。

尤其是新产品或新产品线的初期版本或产品迭代中的重大版本，以你为中心和起点的产品设计，才是最高效、最能保证质量的。

有一个词叫“言传身教”，要团队产出符合标准的产品设计交付物，一定是以清晰合理的交付标准为前提的。

而对培训交付标准最好的方法，就是你要自己做出表率。通过对关键功能和页面的设计，以标准原型、标准文档的方式来建立基础，团队才能迅速熟悉和以交付标准为标的完成工作。

最后，关于项目管理方面。

项目管理

我不是一个在项目管理方面，过度刻意进行控制和要求的人。

开发项目管理有很多方法论——瀑布开发、敏捷开发、螺旋开发等。

方法选择的核心，应该交给开发团队，让他们选择最熟悉最方便的就可以。同时，也不是所有的项目都适合敏捷开发，不同阶段的产品非要去做敏捷开发也不一定合适，这里就不展开说了。

我想抛开项目管理的方法论，从个人认为的项目管理更核心的角度来讲讲。

项目管理，我认为有三个要素：任务、执行者和结果。

好的项目管理是处理好这三个要素之间的关系。简单说就是，合适的任务量，有执行者运用合适的节奏，来产出满足要求的结果。

任务量

合适的任务量，是决定项目成败的前提条件——在产品规划的交付物方面提高要求，不使交付物成为项目开发的障碍。

不在一个版本内规划超过合理开发周期的任务量。

不把没有思考清楚或不完整的功能放入产品规划中。

做到“严于律己”，认真对待产品规划输出物，往往要比苛求开发团队实现不可能完成的任务更重要。

执行者

执行者就是项目的开发团队。

信任开发团队，比怀疑和苛求开发团队要来的划算，良好合作一定建立在互相信任的基础上。

相比去苛求开发团队完成不能完成的任务，不如反过来思考：如何根据需求的优先级来缩减任务量？

给予项目合理的任务时间，是保证项目质量的重要条件。

这里我更推荐“晨会+周期性项目演示”的方式：

每天早上在开工前，拿出15分钟左右，让开发团队对当前进度进行简短说明。同时可以提出：目前出现可能影响原定进度的问题，在晨会后安排专门的时间，来进行专项讨论或提供尽可能的协助。晨会可以天为标尺，发现目前实际进度与原定计划的差距，也可以让问题得到最及时的解决；

每1-2周，固定时间对项目目前的进度进行整体说明，并准备可演示物进行演示，判断当前项目的进度和阶段产物是否符合要求。

通过这样的方式，能够及早发现进度问题或影响进度的问题，从而提高对项目异常的反应速度。

结果项目最终的产出物，是验证项目成败的最终指标。仅仅在时间维度上去衡量项目成果，是没有任何意义的。没人愿意接受一个按时完成，但漏洞百出，无法提供使用的交付物。

所以，对结果交付物的验收，是项目管理的最终关卡。

要验证开发交付物，首先要做到，开发前提供的产品规划交付物是清晰明确的。

其次，还需要对交付物进行如下两个层面的检验：

功能层面：这部分工作可以交给专业的测试团队完成，但产品团队一定要在过程中积极参与及跟进；

实际使用层面：这部分则需要产品来独立完成。使用层面的检验——即产品团队模拟真实用户的各种使用场景，使用时的行为，输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现，但被用户正式使用很快会遇到的问题。（这一点2B的业务类产品尤为重要）。