升到管理岗位并不意味着你可以完全脱离基础工作，而是要在基础工作当中承担起统筹、把控的作用，凭借自己的业务经验以及通过不断地提升自我能力，更好更高效地带领团队完成基础工作任务。团队中的产品经理最近提了几个问题，趁此机会做一下分享。 这是产品问答的第三篇，主要讲：“如何更进一步参与基础工作？”。 问：脱离了基础工作，我有点不知所措，我还可以在哪方面去做更多呢？ 答： 提升到管理岗位，说明你工作已被认可，工作获得不小的进步。 中国有句古话叫“百尺竿头，更进一步”，意思是：获得一定成就之后不要自满，继续前进以追求更大进步。 你提出这个问题，说明你在继续学习上有充足心理准备，这是一件非常好的事情。每个人的学习路径都不同，想要指导甚至帮助别人规划学习，我还没有那么大的自信。 我只能从个人角度提出一些建议，仅供参考。
一、不做甩手掌柜
从执行岗提升到管理岗之后，最要不得的，就是完全脱离基础工作。1. 要承担产品信息承上启下的作用
要保证自己对于产品战略、产品路线图的全面理解，不但要知道是什么，还要知道为什么是这样，而不是那样。要“知其然，知其所以然”。 接着，就是在团队中，对理解的信息进行宣教，让团队在基础认识上保持一致。这可以节省很多时间，让团队省去很多不必要的多次沟通和争论。同时，也可以让团队在执行相关任务时，明白方向是什么，哪部分是核心。2. 要承担基础工作中，最核心最决定成败的部分
就如上一篇《产品问答 | 提岗管理后，如何进行团队管理及项目管理？》中所提到的：你应该是最了解团队工作前提的人——即已经确定的产品战略、产品路线图。 那么，你需要承担对应各端的关键模块、关键页面的设计，保证产品基础的工作和上层信息一致。如果只进行了信息传递，而不参与进去，最后结果物可能会有很大偏差。必然会返工、重复，导致时间成本的浪费。3. 在承担核心部分的基础工作时，同步推进交付物标准
清晰可执行的交付物标准，是保证产品交付物高质量的前提。 如何保证制定的标准清晰且执行？如何保证团队准确理解和执行标准？ ——制定标准不能假大空，不能建立在虚无幻想之上，否则标准就可能变成桎梏，不但不能提高效率和质量，还会拖后腿。 制定交付物标准有几个原则： 自身积累经验： 在工作中逐渐积累的，产出高质量交付物的经验，最适合转化为标准。 我进行产品设计时，使用“产品线+产品端+版本号+文件描述+6位日期+大写字母序号”的命名方式。同时，在进行较大量的修订时，都会复制文件进行命名。 例如：我第一次编写某版本原型是命名为“登月计划-系统后台-V2.2.3-界面原型190201A”，我在3天后进行较大量内容的修订，复制并命名为“登月计划-系统后台-V2.2.3-界面原型190204B”。 这样，我每个版本的记录都会保存在，这样的好处有很多的。我可以回顾整个迭代过程，可以随时找回某个重要版本的内容。 研发团队建议： 产品设计时经常将“用户需求”这个词，产品交付物也有“用户”——就是负责开发的RD们。在制定标准时，要参考这些“用户”的需求。 在某个项目的标准制定过程中，开发团队提出希望中后台的需求文档，能以交互原型的基础来来实现。这样在开发时，不需要来回切换交互原型和需求文档，还要寻找之间的一致性。在搜集到这个需求后，团队为满足需求进行了尝试和修订。最终找到合适的呈现方法，满足了开发团队的需求，提高了开发的效率。 可读易用性： 产品要关注“用户体验”，产品交付物也一样。写给人看的东西，一定要保证可读性；用于开发参照，一定要保证易用。 在制定标准时，为了满足可读易用性，我有如下经验：- 规范专业术语。规范文档本身的用语，便于阅读者更高效理解；
- 能用数学就不用文字。数学是最精确的语言，在准备传递信息方面，远好于任何其他语言文字；
- 描述时说人话。好的描述文字，要保证没有专业基础的人也基本看懂；
- 不写复杂，不写长句。复杂表述和长句子，对于阅读者很不友好；
- 格式和标点符号要规范。规范的格式和标点，能提高文档的理解效果；
- 所有图片保证清晰。不清晰的图片，还不如没有；
- 目录、引用和跳转。目录、引用及跳转等，能让文档更方便被使用。
二、构建团队沟通规则
作为产品管理人员，还需要逐步构建团队的沟通规则。 团队沟通规则有：执行标准、工作流程、交付物标准、文件交互规范等等。 在下面会我分享自己的做法和经验，但最终你还是要找到，最适合自己团队的方法。1. 执行标准
团队工作中会涉及到各类型的执行事务，对这些事务逐步建立规范，有很多好处。 近几年我从事的都是企业应用类系统产品规划，这就需要很频繁和客户企业管理层及业务人员进行沟通、访谈等。这些沟通访谈量很大，往往需要团队中的产品经理分担。 但如何保证他们在采集及整理信息时，不会漏掉重要信息？如何评测他们访谈的技巧和效果呢？ 我的灵感来自于呼叫中心，很多呼叫中心都会全程记录服务人员与顾客的沟通录音。然后，安排固定时间来回顾，分析服务人员的话术、沟通技巧等等。所以，我也尝试每次访谈都全程录音。 我发现有很多好处：首先可以在访谈时将关注点从记录转移到沟通上；其次回顾录音并分析记录效果也更好。 于是，我将访谈“全程录音”作为访谈的执行标准，推行到产品团队。 我无需参与所有访谈，却不担心信息的遗失，也可以据此对团队中的访谈工作进行客观评价，并助其逐渐提升。 这样的执行标准，因各团队的具体工作而不同。 如何去寻找并制定执行标准呢？ 回顾一下团队管理过程：一定有些工作，团队的结果和你的预期有差距。 那么，就可以作为一个探索的起点，去思考：哪些方法可以能够转化为执行标准？2. 工作流程
建立工作流程，可以让团队在日常工作上保持有序，节省很多沟通成本。 什么样的工作需要建立流程？如何建立工作流程呢？ 你应该发现，一定有些工作符合如下特点：- 需要多个人配合完成，很多步骤会产出标准产物；
- 经常需要按照某种顺序被执行，前置工作完成才能继续下一步；
- 这类工作不是一次性的，需要不断的循环执行。
- 之前大家是如何处理和配合的？
- 存在哪些问题或出现过哪些失误？
- 将搜集来的【信息1】成最初的流程图。
- 分析【信息2】问题出现的原因
3. 交付物标准
交付物标准，在前文已经讲过，这里不再赘述。4. 文件交互规范
产品团队的规划工作，最终都以文件的形式落地。规范文件的编辑、迭代、传递等交互过程，有助于提高工作效率，也能避免文件遗失。 我在工作中有一套文件编辑和迭代的规范。 所有的文件夹我都按照类别及层次命名，并在前面加了三位数字序号。当这套规范被熟用以后，我不在电脑前也能迅速告诉他人，某个文件在什么位置。
之前文章提到过，我对文件迭代都有命名规范，以保证重要版本的保留。
另外，我以自己的Nas为载体，搭建了多端实时同步备份的文件服务。保证团队实时在同一套文件体系下工作，无需通过邮件或其他工具传输文件。
文件交互的规范，需要按照自身经验和团队情况灵活制定，只有能提高效率的规范，才是最好的规范。
三、提升业务能力
作为产品团队管理，提升业务能力也非常重要。 什么是产品业务能力呢？ 产品业务能力有：业务理解、业务建模、业务抽象及业务解耦等。1. 业务理解
一个合格的产品，不能停留在被动接收信息、接收需求的层面。要主动走出需求范围，往前探究产品需求产生的源头——即产品所要满足的业务情况。 产品相当于海面上的冰山一角，真正埋藏在海面下，支持产品的是实际业务。只有深入理解了业务，站在更宏观的角度，才能更清晰更全面的看到产品本质。 前几年做的互医平台，是针对乳腺癌单病种单科的辅助诊疗业务平台。当时接手后发现，系统很多功能混乱、重复，而且能没人说的清楚为何要开发成这样。于是，决定从已成型的系统泥潭中脱身，重新开始理解乳腺癌的实际业务。 首先，我花一个月时间阅读乳腺癌诊疗最专业的两份指南——欧美的《NCCN指南》和国内的《中国抗癌协会乳腺癌诊治指南与规范》，建立对乳腺癌发病、诊断、诊疗等方面的基本认识，同时也梳理出一个问题集。 然后，我找几位合作比较深入的科室医生，提出我的问题集和一些个人看法。通过他们的热心解答，我基本建立对乳腺癌诊疗更完整的理解。 回头看，原来的系统和真实的业务隔了一层纱，很多功能建立在模糊不清的信息上。 上面说的业务是2B的，其实2C业务也有自身业务源头：产品背后的商业逻辑、用户的实际场景等，需要你自己去搜集、分析和理解。2. 业务建模
建立业务理解后，如何让业务转变为可实现的产品方案呢？ 从业务理解转化到产品方案，要通过两层检验：业务建模和产品战略。 对业务建立了基础认识，就算入了一半行了，不会再出现听不懂业务人员的问题或描述的情况，也可以更深一步和他们进行沟通交流。 这时，就需要搜集更加全面的业务信息，通过和业务环节的各类代表沟通，逐渐建立对实际业务的全面了解。这里说的不是他们想要系统实现什么功能，而是他们现有业务场景下的行为逻辑。 我建立了对乳腺癌诊疗的基本业务理解后，开始对多个科室的业务人员（主治医生、助理医生、护理人员等）进行访谈调研（这里用到我前文所讲的“全程录音”。） 全面了解不同科室的业务路径——如何筛选患者？患者如何挂号？如何看病？如何确诊？如何安排手术？如何进行术后治疗？如何随访？等等。 然后，先把不同科室的业务路径分别绘制流程图并确认，最后再把多个流程图整合为一个更完整的业务流程图。 最后总结一下：业务建模就是基于基本业务理解，通过深入访谈调研搜集并完成业务流程图。 成型业务流程图，还需要产品战略的指导和检验，之前有详细说过，这里不再赘述。3. 业务抽象与解耦
业务抽象是指：对要实现的业务中的重复性进行归纳，业务解耦是指对要实现的业务中的逻辑环节进行拆分。 要实现的业务： 建立完整的业务建模之后，需要进行实现范围的确定。不是所有的业务环节我们都要通过信息化产品来满足，寻找合适边界是实现业务的第一步（这个部分未来会找机会详细解说）。 前面对业务抽象和业务解耦的解释，听起来都比较难理解，我用例子来分别说明： 在乳腺癌诊疗平台上，患者在复诊时要进行挂号预约；在化疗阶段，每个疗程患者都需要确定化疗日期；在内分泌阶段患者需要确定配药日期。 原有系统对于上述几个业务，都分别作为一个单独的功能实现的。 深入分析后，可以发现：不论是挂号看医生、预约治疗还是预约配药，其实都是对医院服务资源的预约、分配和使用。 根本逻辑都是：供给方安排资源和资源限制条件，需求方对资源进行预约和使用。 基于上述分析，我们把所有类似的业务都通过：“资源安排-资源产生-资源预定-资源消耗”的业务流来实现，就是对上述业务的抽象。 同时我们发现：上述业务流，每个节点都有不同的业务规则。 比如：- 资源安排，有些资源需要配置医生、配置地点，有些资源需要配置限制条件（自费患者才可以使用）。
- 资源产生，有些资源即时生效，有些资源要在固定时间才触发，有些资源预产量为一个月，有些则为一周。
- 把资源安排及限定拆分为排班模块，用来管理各种可被预约的资源及资源使用的限制条件；
- 把资源限制的部分信息放在患者信息管理中去实现；
- 把资源调整拆分为假期设置模块，用来灵活的根据假期来调整资源（包含已被预约的资源）；
- 把资源预定拆分为预约模块，用来比对资源的存量、资源的限制和使用者的信息，并最终决定预约结果。这就是业务的解耦。
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
