当你升到管理岗，项目管理和团队管理就成了你的“家常便饭”。关于项目管理与团队管理，你或许会有一些疑问：如何制定产品计划，才能合理有序地分配团队工作，高效地完成项目呢？怎么做项目管理才能使开发更敏捷呢？那么，以下就由笔者来为大家一一解答这些问题吧！团队中的产品经理最近提了几个问题，趁此机会做一下分享。 这是产品问答的第三篇：探讨提升管理岗位后的团队管理、项目管理。 问：在团队管理时，如何制定产品策略及计划？以及，如果我把原型制作工作交给别人做，但出来的效果是我不满意的——他现在能力不够，做不出我想要的效果，要怎么处理？（如何分配工作）？项目管理有没有什么方法让开发更敏捷？ 答： 随着产品逐渐成熟，产品团队也会慢慢成型。产品团队的存在，说明产品工作已经细化拆分。原来一、两个人干的事，现在可以由不同分工的人来处理了。 因此，产品团队的管理，得先从产品工作的拆分说起。 一般来说，产品工作的层面可以分为：产品战略、产品结构、产品框架、产品设计和产品辅助等。
产品战略工作
就是我们在第一篇问答（如何系统思考产品需求）中提高的产品战略工作。 梳理和确认好产品战略，让未来产品工作建立在相同认知基础上，是产品工作中最宏观且最有价值的工作。产品结构工作
当我们确定了产品战略之后，从战略到具体的产品规划，需要进行信息的转化。 这种转化，就是将产品战略落地，转化为一条条产品线、一个个版本、一张张的功能清单，也就是产品的路线图（roadmap）。 有了清晰的路线图，接下来就可以进入正式的产品规划设计工作阶段了。产品框架工作
有了实现的路径，就需要按照优先级，分产品线分版本的逐步设计。 这时，我们首先把眼光聚焦在版本内部，我们对所有需要实现的功能进行分析，让他们成为有机结合的整体，让功能组成一个个相关的模块。 同时，也把模块内及模块之间的各个功能，可能的实现流程明确出来。让需要实现的目标功能，变成清晰的多维结构。我们需要使用UML、业务流程图、数据流程图、业务拓扑图等讲这些结构表达出来。 同时，当版本内的设计接近完成时，我们要把眼光切换到多版本上——考虑未来版本和功能的实现，需要当前产品结果预先作出哪些调整和伏笔。这些都完成之后，我们就可以开始按照版本来细化和设计产品了。产品设计工作
单个版本的产品结构设计完成，并经过各相关团队的评审和协调后，就要回归到产品部门内部进行设计了。 我们需要按照产品的版本结果，设计出前、中、后各端的模块、功能、流程、页面等，这里我们需要画原型、细化流程、设计页面、输出需求说明文档甚至高保真的交互稿。 设计好的产品结果，要宣讲并交付给开发团队，同时也会接受开发团队的各种挑战。 另外建议：在宣讲和交付产品结果的时候，最好能够把对象目标扩展到测试团队、运营团队、业务团队等各个相关业务团队，这样做的好处你试了就知道。产品辅助工作
除了上述四个产品规划层面的工作外，其他的如：竞品调研、数据采集汇总、项目跟进、Bug处理跟进、产品相关宣传说明配合等工作，都是产品辅助类工作。 这几个层面的工作，并不是每个层面都需要不同的人来负责。本身是可以互相渗透，根据团队的具体情况来身兼多职。1-3 层面
一般由产品总监、产品团队负责人或高级产品来负责。做到承上启下，配合高层确定产品战略并消化和转化，指导具体的产品规划工作。4-5 层面
一般由产品经理、产品线经理或产品专员等负责。做好基于产品路径的落地工作，保证产品设计的效率和质量。 拆分层面的意义在于：规范好的工作层面，可以让大家在工作时，明白各自的职责范围，更高效的互相承接和配合。 另外，你说团队成员的产品不符合你的要求，不知该如何处理。 我的建议是：就算从执行层岗位开始转变为管理岗位，也千万不要做甩手掌柜，很多执行方面的工作还是要有目的性的参与。 有目的的参与，可以体现在如下两个方面： 做为产品管理岗位，需要承担产品信息的向下传递——即承上启下的作用，你需要去处理产品战略、产品范围及产品框架等方面的设计工作。 同时，因为接下来要据此来进行具体的产品设计规划，最理解且最能依据产品框架来设计产品的人一定是你。你需要对各端的关键模块、关键页面进行设计，建立从上到下、完整一致的信息传递。 尤其是新产品或新产品线的初期版本或产品迭代中的重大版本，以你为中心和起点的产品设计，才是最高效、最能保证质量的。 有一个词叫“言传身教”，要团队产出符合标准的产品设计交付物，一定是以清晰合理的交付标准为前提的。 而对培训交付标准最好的方法，就是你要自己做出表率。通过对关键功能和页面的设计，以标准原型、标准文档的方式来建立基础，团队才能迅速熟悉和以交付标准为标的完成工作。 最后，关于项目管理方面。项目管理
我不是一个在项目管理方面，过度刻意进行控制和要求的人。 开发项目管理有很多方法论——瀑布开发、敏捷开发、螺旋开发等。 方法选择的核心，应该交给开发团队，让他们选择最熟悉最方便的就可以。同时，也不是所有的项目都适合敏捷开发，不同阶段的产品非要去做敏捷开发也不一定合适，这里就不展开说了。 我想抛开项目管理的方法论，从个人认为的项目管理更核心的角度来讲讲。 项目管理，我认为有三个要素：任务、执行者和结果。 好的项目管理是处理好这三个要素之间的关系。简单说就是，合适的任务量，有执行者运用合适的节奏，来产出满足要求的结果。任务量
合适的任务量，是决定项目成败的前提条件——在产品规划的交付物方面提高要求，不使交付物成为项目开发的障碍。- 不在一个版本内规划超过合理开发周期的任务量。
- 不把没有思考清楚或不完整的功能放入产品规划中。
- 做到“严于律己”，认真对待产品规划输出物，往往要比苛求开发团队实现不可能完成的任务更重要。
执行者
执行者就是项目的开发团队。 信任开发团队，比怀疑和苛求开发团队要来的划算，良好合作一定建立在互相信任的基础上。 相比去苛求开发团队完成不能完成的任务，不如反过来思考：如何根据需求的优先级来缩减任务量？ 给予项目合理的任务时间，是保证项目质量的重要条件。 这里我更推荐“晨会+周期性项目演示”的方式：- 每天早上在开工前，拿出15分钟左右，让开发团队对当前进度进行简短说明。同时可以提出：目前出现可能影响原定进度的问题，在晨会后安排专门的时间，来进行专项讨论或提供尽可能的协助。晨会可以天为标尺，发现目前实际进度与原定计划的差距，也可以让问题得到最及时的解决；
- 每1-2周，固定时间对项目目前的进度进行整体说明，并准备可演示物进行演示，判断当前项目的进度和阶段产物是否符合要求。
- 功能层面：这部分工作可以交给专业的测试团队完成，但产品团队一定要在过程中积极参与及跟进；
- 实际使用层面：这部分则需要产品来独立完成。使用层面的检验——即产品团队模拟真实用户的各种使用场景，使用时的行为，输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现，但被用户正式使用很快会遇到的问题。（这一点2B的业务类产品尤为重要）。
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
