联系我们
电话:1351231345
传真:020-66889888
地址:内蒙古自治区阿拉善左旗西南部
当前位置:主页 > 新宝6问答 > 问答分类1 > 问答分类1

产品问答 身居管理岗位如何更进一步参与基础工

时间:2019-03-19 10:40 作者:dongdong 点击:

  升到管理岗位并不意味着你可以完全脱离基础工作,而是要在基础工作当中承担起统筹、把控的作用,凭借自己的业务经验以及通过不断地提升自我能力,更好更高效地带领团队完成基础工作任务。

  中国有句古话叫“百尺竿头,更进一步”,意思是:获得一定成就之后不要自满,继续前进以追求更大进步。

  你提出这个问题,说明你在继续学习上有充足心理准备,这是一件非常好的事情。每个人的学习路径都不同,想要指导甚至帮助别人规划学习,我还没有那么大的自信。

  要保证自己对于产品战略、产品路线图的全面理解,不但要知道是什么,还要知道为什么是这样,而不是那样。要“知其然,知其所以然”。

  接着,就是在团队中,对理解的信息进行宣教,让团队在基础认识上保持一致。这可以节省很多时间,让团队省去很多不必要的多次沟通和争论。同时,也可以让团队在执行相关任务时,明白方向是什么,哪部分是核心。

  就如上一篇《产品问答 提岗管理后,如何进行团队管理及项目管理?》中所提到的:你应该是最了解团队工作前提的人——即已经确定的产品战略、产品路线图。

  那么,你需要承担对应各端的关键模块、关键页面的设计,保证产品基础的工作和上层信息一致。如果只进行了信息传递,而不参与进去,最后结果物可能会有很大偏差。必然会返工、重复,导致时间成本的浪费。

  ——制定标准不能假大空,不能建立在虚无幻想之上,否则标准就可能变成桎梏,不但不能提高效率和质量,还会拖后腿。

  我进行产品设计时,使用“产品线+产品端+版本号+文件描述+6位日期+大写字母序号”的命名方式。同时,在进行较大量的修订时,都会复制文件进行命名。

  例如:我第一次编写某版本原型是命名为“登月计划-系统后台-V2.2.3-界面原型190201A”,我在3天后进行较大量内容的修订,复制并命名为“登月计划-系统后台-V2.2.3-界面原型190204B”。

  这样,我每个版本的记录都会保存在,这样的好处有很多的。我可以回顾整个迭代过程,可以随时找回某个重要版本的内容。

  产品设计时经常将“用户需求”这个词,产品交付物也有“用户”——就是负责开发的RD们。在制定标准时,要参考这些“用户”的需求。

  在某个项目的标准制定过程中,开发团队提出希望中后台的需求文档,能以交互原型的基础来来实现。这样在开发时,不需要来回切换交互原型和需求文档,还要寻找之间的一致性。在搜集到这个需求后,团队为满足需求进行了尝试和修订。最终找到合适的呈现方法,满足了开发团队的需求,提高了开发的效率。

  产品要关注“用户体验”,产品交付物也一样。写给人看的东西,一定要保证可读性;用于开发参照,一定要保证易用。

  尤其在标准发布之前,最好团队内部多尝试,也尽量邀请开发代表参与体验。避免发布后的标准,沦为没有市场的产品。

  在下面会我分享自己的做法和经验,但最终你还是要找到,最适合自己团队的方法。

  团队工作中会涉及到各类型的执行事务,对这些事务逐步建立规范,有很多好处。

  近几年我从事的都是企业应用类系统产品规划,这就需要很频繁和客户企业管理层及业务人员进行沟通、访谈等。这些沟通访谈量很大,往往需要团队中的产品经理分担。

  但如何保证他们在采集及整理信息时,不会漏掉重要信息?如何评测他们访谈的技巧和效果呢?

  我的灵感来自于呼叫中心,很多呼叫中心都会全程记录服务人员与顾客的沟通录音。然后,安排固定时间来回顾,分析服务人员的话术、沟通技巧等等。所以,我也尝试每次访谈都全程录音。

  我发现有很多好处:首先可以在访谈时将关注点从记录转移到沟通上;其次回顾录音并分析记录效果也更好。

  我无需参与所有访谈,却不担心信息的遗失,也可以据此对团队中的访谈工作进行客观评价,并助其逐渐提升。

  那么,就可以作为一个探索的起点,去思考:哪些方法可以能够转化为执行标准?

  比如:经常要将各渠道搜集到的bug,整理分类并反馈给开发,并跟进bug的修复情况。

  建立工作流程,需要绘制流程图,如果涉及到跨部门协作,还需要绘制泳道流程图。绘制流程图应该是产品经理的基本功,如果你不会可以百度或找相关资料学习,就不展开说了。

  问题原因可能有:阶段交付物不清晰或缺失、缺少关键节点的确认人员、缺少节点的时间要求、缺少特殊情况的处罚机制等等。

  工作流程也需要不断迭代,根据施行的反馈及具体情况变化,逐步完善。好的流程不但可以让团队效率更高,也能让加入团队的新成员迅速进入状态。

  产品团队的规划工作,最终都以文件的形式落地。规范文件的编辑、迭代、传递等交互过程,有助于提高工作效率,也能避免文件遗失。

  所有的文件夹我都按照类别及层次命名,并在前面加了三位数字序号。当这套规范被熟用以后,我不在电脑前也能迅速告诉他人,某个文件在什么位置。

  另外,我以自己的Nas为载体,搭建了多端实时同步备份的文件服务。保证团队实时在同一套文件体系下工作,无需通过邮件或其他工具传输文件。

  文件交互的规范,需要按照自身经验和团队情况灵活制定,只有能提高效率的规范,才是最好的规范。

  一个合格的产品,不能停留在被动接收信息、接收需求的层面。要主动走出需求范围,往前探究产品需求产生的源头——即产品所要满足的业务情况。

  产品相当于海面上的冰山一角,真正埋藏在海面下,支持产品的是实际业务。只有深入理解了业务,站在更宏观的角度,才能更清晰更全面的看到产品本质。

  前几年做的互医平台,是针对乳腺癌单病种单科的辅助诊疗业务平台。当时接手后发现,系统很多功能混乱、重复,而且能没人说的清楚为何要开发成这样。于是,决定从已成型的系统泥潭中脱身,重新开始理解乳腺癌的实际业务。

  首先,我花一个月时间阅读乳腺癌诊疗最专业的两份指南——欧美的《NCCN指南》和国内的《中国抗癌协会乳腺癌诊治指南与规范》,建立对乳腺癌发病、诊断、诊疗等方面的基本认识,同时也梳理出一个问题集。

  然后,我找几位合作比较深入的科室医生,提出我的问题集和一些个人看法。通过他们的热心解答,我基本建立对乳腺癌诊疗更完整的理解。

  回头看,原来的系统和真实的业务隔了一层纱,很多功能建立在模糊不清的信息上。

  上面说的业务是2B的,其实2C业务也有自身业务源头:产品背后的商业逻辑、用户的实际场景等,需要你自己去搜集、分析和理解。

  对业务建立了基础认识,就算入了一半行了,不会再出现听不懂业务人员的问题或描述的情况,也可以更深一步和他们进行沟通交流。

  这时,就需要搜集更加全面的业务信息,通过和业务环节的各类代表沟通,逐渐建立对实际业务的全面了解。这里说的不是他们想要系统实现什么功能,而是他们现有业务场景下的行为逻辑。

  我建立了对乳腺癌诊疗的基本业务理解后,开始对多个科室的业务人员(主治医生、助理医生、护理人员等)进行访谈调研(这里用到我前文所讲的“全程录音”。)

  全面了解不同科室的业务路径——如何筛选患者?患者如何挂号?如何看病?如何确诊?如何安排手术?如何进行术后治疗?如何随访?等等。

  然后,先把不同科室的业务路径分别绘制流程图并确认,最后再把多个流程图整合为一个更完整的业务流程图。

  最后总结一下:业务建模就是基于基本业务理解,通过深入访谈调研搜集并完成业务流程图。

  成型业务流程图,还需要产品战略的指导和检验,之前有详细说过,这里不再赘述。

  业务抽象是指:对要实现的业务中的重复性进行归纳,业务解耦是指对要实现的业务中的逻辑环节进行拆分。

  建立完整的业务建模之后,需要进行实现范围的确定。不是所有的业务环节我们都要通过信息化产品来满足,寻找合适边界是实现业务的第一步(这个部分未来会找机会详细解说)。

  前面对业务抽象和业务解耦的解释,听起来都比较难理解,我用例子来分别说明:

  在乳腺癌诊疗平台上,患者在复诊时要进行挂号预约;在化疗阶段,每个疗程患者都需要确定化疗日期;在内分泌阶段患者需要确定配药日期。

  深入分析后,可以发现:不论是挂号看医生、预约治疗还是预约配药,其实都是对医院服务资源的预约、分配和使用。

  根本逻辑都是:供给方安排资源和资源限制条件,需求方对资源进行预约和使用。

  基于上述分析,我们把所有类似的业务都通过:“资源安排-资源产生-资源预定-资源消耗”的业务流来实现,就是对上述业务的抽象。

  把资源安排及限定拆分为排班模块,用来管理各种可被预约的资源及资源使用的限制条件;

  把资源调整拆分为假期设置模块,用来灵活的根据假期来调整资源(包含已被预约的资源);

  把资源预定拆分为预约模块,用来比对资源的存量、资源的限制和使用者的信息,并最终决定预约结果。这就是业务的解耦。

  作者:十八子杀,微信公众号:产品狗的思考(Productdoggy)。10年产品人,射手座,爱自由,喜摄影,好读书,涉猎广泛,望与同路人勉励前行。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。