这是产品问答的第三篇，探讨团队管理及项目管理。
问：在团队管理时，如何制定产品策略及计划？以及如果我把原型制作工作交给别人做，但出来的效果是我不满意的 但现在能力不够，做不出我想要的效果。怎么处理？（如何分配工作）？项目管理有没有什么方法让开发更敏捷？
答：随着产品逐渐成熟，产品团队也会慢慢成型。产品团队的存在，说明产品工作细化拆分，原来一个人干的事，现在可以由不同分工的人来处理了。
所以产品团队管理，就得先从产品工作的拆分说起。正规来说，产品工作的层面可以分为：展品战略、产品结构、产品框架、产品设计和产品辅助等。
1）产品战略工作，就是我们在第一个问题中提高的产品战略工作。梳理和确认好产品的战略，将未来产品工作建立在相同认知基础上，是产品工作中最宏观、最有价值的工作；
2）产品结构工作，当我们确定了产品战略之后，从战略到具体的产品工作，需要一个转化的渠道。这个转化的渠道，就是将产品战略落地，转变为一条条产品线、一个个版本、一张张的功能清单。统合起来，也就是产品的路线图（roadmap）。有了清晰的路线图，接下来就可以进入正式的产品规划设计工作阶段了；
3）产品框架工作，产品有了实现的路径，就需要按照优先级，分产品线分版本的逐步设计。这时候我们首先把眼光聚焦在版本内部，我们对所有需要实现的功能进行分析，让他们成为有机结合的整体，让功能组成一个个相关的模块。同时也把模块内及模块之间的各个功能，可能的实现流程明确出来。让需要实现的目标功能，变成清晰的多维结构。我们需要使用UML、业务流程图、数据流程图、业务拓扑图等讲这些结构表达出来。
同时当版本内的设计接近完成时，我们要把眼光切换到多版本上，考虑未来版本和功能的实现，需要当前产品结果预先作出哪些调整和伏笔。这些都完成之后，我们就可以开始按照版本来细化和设计产品了；
4）产品设计工作，单个版本的产品结构设计完成并经过各相关团队的评审和协调后，就要回归到产品部门内部进行设计了。我们需要按照产品的版本结果，设计出前中后各端的模块、功能、流程、各项要求等等，这里我们需要画原型、细化流程、设计页面、输出需求说明文档甚至高保真的交互稿。设计好的产品结果，要宣讲并交付给开发团队，同时也会接受开发团队的各种挑战。
建议，在宣讲和交付产品结果的时候，最好能够把对象目标扩展到测试团队、运营团队、业务团队等各个相关业务团队，后面的好处你试了就知道。
5）产品辅助工作，除了上述四个产品规划层面的工作外，其他的如：竞品调研、数据采集汇总、项目跟进、Bug处理跟进、产品相关宣传说明配合等工作，都是产品辅助类工作。
这五个层面的工作，并不是每个层面都需要不同的人来负责。本身是可以互相渗透，根据团队的具体情况来身兼多职的。
1-3层面一般由产品总监、产品团队负责人或高级产品来负责。做到承上启下，配合高层确定产品战略并消化和转化，指导具体的产品规划工作。
4-5一般由产品经理、产品线经理或产品专员等负责。做好基于产品路径的落地工作，保证产品设计的效率和质量。
拆分层面的意义在于，规范好的工作层面，可以让大家在工作时，明白各自的职责范围，更高效的互相承接和配合。

另外，你说团队成员的产品不符合你的要求，不知该如何处理。
我的建议是，就算从执行层岗位开始转变为管理岗位，也千万不要做甩手掌柜，很多执行方面的工作还是要有目的性的参与。
主要从如下两个角度来考虑：
1）做为产品管理岗位，需要承担产品信息的向下传递，即承上启下的作用。你依旧需要去处理产品战略、产品范围及产品框架等方面的设计工作。同时因为接下来要据此来进行具体的产品设计规划，最理解且最能依据产品框架来设计产品的人一定是你。你需要对各端的关键模块、关键页面进行设计，建立从上到下、完整一致的信息传递。尤其是新产品或新产品线的初期版本或产品迭代中的重大版本，以你为中心和起点的产品设计才是最高效、最能保证质量的；
2）有一个词叫“言传身教”，要团队产品符合标准的产品设计交付物，一定是以清晰合理的交付标准为前提的。而对培训交付标准最好的方法，就是你要自己做出表率。通过对关键功能和页面的设计，以标准原型、标准文档的方式来建立基础，团队才能迅速熟悉和以交付标准为标的完成工作。

最后，关于项目管理方面。
我不是一个在项目管理方面，过度刻意进行控制和要求的人。
开发项目管理有很多方法论，瀑布开发、敏捷开发、螺旋开发等。方法选择的核心，应该交给开发团队，让他们选择最熟悉最方便的就可以。同时，也不是所有的项目都适合敏捷开发，不同阶段的产品非要去做敏捷开发也不一定合适。这里就不展开说了。
我想抛开项目管理的方法论，从我个人认为的项目管理更核心的角度来讲讲。
项目管理，我认为有三个要素：任务、执行者和结果。好的项目管理是处理好这三个要素之间的关系。
简单说就是，合适的任务量，有执行者运用合适的节奏，来产出满足要求的结果。
1）任务量，特别是合适的任务量，是决定项目成败的输入条件。
在产品规划的交付物方面提高要求，不使交付物成为项目开发的障碍；
不在一个版本内规划超过合理开发周期的任务量；
不把没有思考清楚或不完整的功能放入产品规划中。
做到“严于律己”，往往要比苛求开发团队实现不可能完成的任务更重要。
2）执行者，也就是项目的开发团队。
信任开发团队，比怀疑和苛求开发团队要来的划算。良好合作一定建立在互相信任的基础上。
相比去苛求开发团队完成不能完成的任务，不如反过来思考如何根据需求的优先级来缩减任务量。给予项目的时间合理，是保证项目质量的重要条件。
这里我更推荐晨会+周期性项目演示的方式：
a、每天早上在开工前，拿出15分钟左右，让开发团队对当前进度进行简短说明。同时可以提出目前出现可能影响原定进度的问题，在晨会后安排专门的时间来进行专项讨论或提供尽可能的协助。晨会可以以天为标尺，发现目前实际进度与原定计划的契合度，也可以让问题得到最及时的解决；
b、每1-2周，固定时间对项目目前的进度进行整体说明，并准备可演示物进行演示，判断当前项目的进度和阶段产物是否符合要求。
通过这样的方式，能够及早发现进度问题或影响进度的问题，从而提高对项目异常的反应速度。
3）结果，项目最终的产出物，是验证项目成败的最终指标。
仅仅在时间维度上去衡量项目成果，是没有任何意义的。没人愿意接受一个按时完成，但漏洞百出，无法提供使用的交付物。
所以对结果交付物的验收，是项目管理的最终关卡。
要验证开发交付物，首先要做到，开发前提供的产品规划交付物是清晰明确的。其次，还需要对交付物进行至少两个层面的检验：
a、功能层面，这部分工作可以交给专业的测试团队完成，但产品团队一定要在过程中积极参与及跟进；
b、实际使用层面，这部分则需要产品来独立完成。使用层面的检验，即产品团队模拟真实用户的各种使用场景，使用时的行为，输入信息要尽可能模拟真实情况。这种检验可以发现很多测试团队不容易发现，但被用户正式使用很快会遇到的问题。（这一点2B的业务类产品尤为重要）。
以上就是我对你提出的项目管理问题的解答。