美文网首页
转型产品经理该怎么做(适用于0-2岁的产品经理)

转型产品经理该怎么做(适用于0-2岁的产品经理)

作者: 刻意练习产品思维 | 来源:发表于2019-10-22 08:38 被阅读0次

    <p><img src="https://img.haomeiwen.com/i6034320/72c5b00ae78d1870" /></p><section class="_editor"><blockquote><p><span>前言:创业者转型做产品人,把我近期悟出的道与理,送给大家!</span>
    </p></blockquote><p><img class="aligncenter size-full wp-image-2554684" data-ratio="0.5625" src="https://img.haomeiwen.com/i6034320/4793b340190fcf8c.png" data-type="jpeg" data-w="800" height="450" width="800"></p><p><strong><span>产品经理是干嘛的?</span></strong>
    </p><p><span><strong><span>遇到问题,提出方案,解决问题的一群人</span></strong></span></p><p>
    </p><p><span><strong><span>本文目录:</span></strong></span>
    </p><p><strong><span>一、思维模型</span></strong></p><p><strong><span>二、工作方法</span></strong></p><p><span>1、如何需求调研</span></p><p><span>2、如何需求评审</span></p><p><span>3、如何自我开展工作</span></p><p><span>4、如何与项目组成员合作</span></p><p><span>5、如何与项目组之外同事合作</span></p><p><strong><span>
    </span></strong></p><p><strong><span>三、坑有哪些</span></strong>
    </p><p><strong><span>四、项目延期</span></strong></p><p><strong><span>
    </span></strong></p><h2><span><strong><span>一、思维模型</span></strong></span></h2><p><span>什么是思维模型呢?</span></p><p><span>思维模型是我们部门负责人邓总监之前在的时候经常提到的一个词。</span></p><p><span>我所理解的是:每个人自</span><span>己在做产品思考问题给出解决方案的时候,形成的一套固有的思维方式,而且因人而异。</span></p><p><span>每个人都必须形成自己的思维模型,没有强制要求每个人的思维模型一模一样,但可以参考借鉴别人好的思维模型,从而悟出自己的道。</span>
    </p><p><span>广告(广而告之):虽然现在他已经不在我身边。但是,很感激他曾经不断的旁敲侧击,各种打磨,谢谢!</span></p><p><span>
    </span></p><p><strong><span><strong><span>我的思维模型</span></strong>:</span><span>用技术MVC架构思考解决产品问题。</span></strong>
    </p><p><img src="https://img.haomeiwen.com/i6034320/d72cdd567575628d.png" data-type="png" class="" data-ratio="0.7170236753100339" data-w="887"></p><p><span>
    </span></p><p><span>解析:</span></p><p><span>M:数据库底层,也就是事务的本质。</span></p><p><span>V:表现层,体现在原型界面上,也就是我们所有人看到在各种载体(网站、APP、小程序、公众号)上UI设计好的页面。</span>
    </p><p>
    </p><p><span>C:业务逻辑层,也就是各种事务之间,各个业务流程的流转。所以,我思考问题的顺序是:先挖掘此需求背后事务的本质以及他的价值,再分析涉及到的各环节的业务流程,最后用原型界面将整个事务过程串联起来。</span></p><p>
    </p><p><span>因为是技术出身,所以我希望将经典的MVC技术架构与我做产品经理时,思考问题的方式进行完美的结合;我不知道我是不是第一个提出使用mvc架构作为思维模型思考问题的产品,但我不希望我是最后一个。</span></p><h2><span><strong><span>二、工作方法</span></strong></span></h2><h3><span>1. 如何需求调研</span></h3><p><span>(1)问题现状:</span><span>问清楚需求方遇到什么问题,要解决什么问题,不爽在哪里,痛在哪里,不解决会怎样?最后,将需求加以记录,并与需求方确认。</span></p><p><span>(2)当前流程:</span><span>问题是出现了,那么当下你们是用什么方式规避这个问题的呢?现在你们的业务流程是怎样的呢?希望在流程上做哪些优化呢?</span>
    </p><p><span><span>(</span><span>3)用户期望:</span></span><span>你想要的结果是怎样的?怎样的结果才是令你满意的?</span></p><p><strong><span>(4)</span></strong><span>需求价值:</span><span>这个问题解决后,对你有什么好处,产生什么价值?</span>
    </p><p><strong><span>(5)</span></strong><span>可行性分析:</span><span>辨别真伪需求后,排好优先级,及时反馈结果。</span><span>做还是不做,都要给合理解释;并不是需求方说的全部就是需求,要自我加以过滤;他说的痛,是不是以偏概全,要追踪问题的本质,他到底是要解决什么问题?</span>
    </p><p><span>
    </span></p><p><span>2. 如何需求评审</span>
    </p><p><span>(1)产品出原型+规则:</span></p><p><span>评审之前,必须自己独立想清楚此次需求所有涉及到的规则。虽然,可能未必有些情况自己考虑完全周全,但必须自己用心深度思考一番。否则,召集其他项目组成员,是极其不负责任的行为。</span></p><p><span>这里,与我以前做项目经理时候的思维方式,完全不同。</span><span>相当于是我要改变以前固化的思维模型,此中过程,有些困难,还好我挺过来啦。</span></p><p><span>(2)产品初步与需求方原型评审(可多次):</span>
    </p><p><span>自己初步画的原型和规则,得先跟需求方单独过一下,确认是否达到初步预期。如果没有的话,那就要及时调整出新的原型+规则,循环往复,直到需求方满意为止。</span></p><p><span>(3)产品初步技术原型评审(可多次):</span>
    </p><p><span><span>需求方搞定,那么就要单独搞定项目组中</span><span>的</span><span>技术成员(前端、后台、测试、UI等),技术与需求方关注的是不同的视角。</span></span></p><p><span><span>需求方,是告知其有这样的页面和规则。技术,会问为什么有这样的页面和规则,能否解释清楚明了。技术提出的问题,你解释不清楚,那就要修改原型+规则,直到任何一个技术都没有问题为止,此轮评审才算结束。</span></span></p><p><span>(4)产品组织项目组所有成员正式评审:</span>
    </p><p><span>需求方与技术都搞定了,那么召集项目组所有成员,组织大会议室,进行系统当前版本的正式评审,就水到渠成了。</span></p><p><span>最后调整完毕的原型+规则,必须同步给项目组所有成员,如果此次正式评审仍有疑问,那么又要重新调整原型+规则;如果没有疑问,那么项目评审成功,顺利推进到开发阶段。</span></p><p><span>(5)项目排期:</span>
    </p><p><span>产品与技术讨论项目排期,并将最终确认的上线时间,汇报给需求方。如果有延期风险,必须事前告知需求方并给出合理理由。</span></p><p><span>(6)上线验收:</span>
    </p><p><span>测试验收需求后,进入产品+需求方验收阶段,此时一般在灰度环境,不会影响正常线上数据。双方同意上线后,测试走上线流程,项目当前版本上线成功。</span></p><p>
    </p><p><span>3. 如何自我开展工作</span></p><p><span>(1)遇到问题,先至少想个解决方案,再和别人沟通</span></p><p><span>不要无脑去与别人讨论一个你没有想清楚的问题。如果实在没想清楚当前问题,你可以去请教相关人员,再自我探寻答案。</span></p><p><span>(2)事事有反馈</span></p><p><span>出于尊重,任何人任何事,都要给予反馈。即使当下没有解决方案,即使当下很忙。消息已读未回复,容易给人造成误解,也容易让别人失望。</span></p><p><span>(3)多听少说,不要插话,不要强加个人观点</span></p><p><span>此点更像是为人处世之道,要懂礼貌。实在要插话,请先说句:不好意思。有时候,产品经理组织会议,作为主持人,必须要打断大家偏离主题相关的话题,必须要有控场能力。</span></p><p><span>这不是不尊重人,我们只是想让会议变得更高效有价值,产品经理的会议多而复杂,如果不会控场,那会浪费极其多的时间;别人讨论的时候,不要用自己的主观意识诱导别人、误导别人。特别是需求方的吐槽,让其畅所欲言,让其说个痛快。然后,自我再总结挖掘问题的本质。</span></p><p><span>(4)时刻关注问题现状、业务流程、功能价值</span></p><p><span>这三点缺一不可,很重要很重要很重要。公司当初系统改造的时候,我就吃过不少亏,就是因为自己当初还是个小白产品,没有自己的思维模型,没有关注问题现状、当下业务流程、功能的价值,为后来自己所做的产品,挖了不少坑。</span></p><p><span>结果,上下游系统嵌套太深,坑也是越陷越深,好不酸爽。</span></p><p><span>(5)对上下游系统必须要有所了解</span></p><p><span>这点,也是感悟很深。很多时候,各个系统的产品,都是只关注自己那一亩三分地,想需求想问题,没有把涉及到的上下游系统考虑进去。导致的结果就是,在自己系统没有什么问题,结果串联上下游系统就暴漏各种问题。</span></p><p><span>有些时候,也能理解,自己系统的需求不断,加班加点赶原型写规则,哪有时间去了解其他系统哦?不过,时间犹如X沟,挤挤还是有滴,各位老铁。</span></p><p><span>(6)控制好情绪,别激动</span></p><p><span>产品,被人质疑,背锅侠,被人diss,那再正常不过的啦。</span></p><p><span>你会不会做产品?你做的什么垃圾产品?我要换产品,你不行。你会不会画原型?你有没有想清楚?这个项目做出来有什么意义?你是什么垃圾?</span></p><p><span>老铁,淡定,阳光总在风雨后滴,干巴爹!</span></p><p><span>(7)多换位思考,保持同理心</span></p><p><span>不同的人,你要切换自己成为不同的角色,争取与其保持同频,明白其所思所想,这点很难,我也就说说,目前感觉依然差之十万八千里</span></p><p><span>(8)对过程和结果都要负责</span></p><p><span>很多时候,咱们明白对过程要负责。但是,结果其实我们更要负责。产品上线了,就算是完成任务了吗?后续能不迭代就不迭代?产品的死活,与我无关,反正我已经做好了。</span></p><p><span>这些想法,我认为都是不对的。我们只是做了0到1,1到100,依然是任重而道远,要有产品人该有的情怀,要创造更多的社会价值。</span></p><p><span>(9)自己做的产品一定要比任何人熟悉</span></p><p><span>自己做好的产品,一定要将输出物弄完整。至少有原型+规则+操作手册,如果有视频那就更好了。一来便于传承,二来便于后期自己回忆。</span></p><p><span>有时候自己负责的系统有点多,部分功能忘记细节,有资料的好处就体现的淋漓尽致,希望各位产品多为后人栽树,让其乘凉。</span></p><p><span><strong><span>(10)</span><span>一定要经过关键大佬同意</span></strong></span></p><p><span> </span></p><p><span>有些新的产品、新的业务、新的需求,会牵涉到多个部门多个关键人物,这个事能不能做、怎么做,一定要跟相关关键大佬正式确认,全部同意才能去做,千万不能火急火燎。</span><span>不能因为一个关键人物的单方面决定(其他大佬未知,或者不同意)的情况下,去为其做这件事。</span></p><p><span>
    </span></p><p><span>要不,不仅吃力不讨好,而且夹在中间里外不是人。总结:必须正式会议正式文件,所有关键人物必须都在,没有最终定方案,产品不做任何调整。</span></p><p><span> </span></p><p><span><strong><span><strong><span>(11)</span></strong></span></strong><strong><span>关键节点及时通知</span></strong></span></p><p><span> </span></p><p><span>#计划上线时间通知:需求方最关注的是,什么时候能上线?所以原型正式评审通过后,项目组成员必须沟通讨论评估出最终上线时间,由产品经理统计好所有时间【UI设计时间+后台开发时间+前端开发时间+测试时间】,最后反馈回给需求方和整个项目组。</span></p><p><span> </span></p><p><span>#已上线版本通知:项目上线了,要及时告知需求方和项目组所有成员,上线功能+功能价值等关键信息;</span></p><p><span> </span></p><p><span>#未来规划通知:项目当前版本上线了,未来的规划,要简明扼要的通知给需求方和项目组所有成员。</span></p><p><span> </span></p><p><span>#项目风险通知:这个必须通知,下面第大四点(项目延期怎么办)我有再次强调。不仅要通知,而且还要解释清楚原因。</span></p><p><span> </span></p><p><span><strong><strong><span><strong><span>(12)</span></strong></span></strong>会议关键人物</strong></span></p><p><span>会议关键人物必须到场,如果没到场,那会议没有开下去的意义,也没有讨论的意义。所以,提前跟相关关键人物约好确定到场时间是很关键的一个事情。</span></p><p><span>
    </span></p><p><span>我踩过的坑告诉我,相关关键人物没有参与的会议,跟没开差不多。</span></p><p><span> </span></p><p><span>4. 如何与项目组成员合作</span></p><p><span>
    </span></p><p><span>(1)我们应该互相尊重,相亲相爱形同一家人</span></p><p><span>可能因为是技术出身的产品吧,我更希望与技术是相亲相爱的情况,而不是网络上报道的相互拳打脚踢的情况。这点因人而异吧,反正我不会跟技术反目成仇。</span></p><p><span>(2)站在用户的角度去写代码</span></p><p><span>我时常提醒自己项目组的技术,不要死写代码,多思考下他背后的意义。如果你是用户,你会用这个功能吗?价值何在?有的技术就做的特别好,根本不用我提醒,反而很多时候能给予我极大的帮助。</span></p><p><span>(3)有锅我来抗</span></p><p><span>产品,很多时候是背锅侠。有时候,项目组其他成员的锅,我觉得没必要去追究,就是咱们的锅。单独再去找出问题的项目成员沟通,让其注意就好。</span></p><p><span>(4)不会为难你,但请别给我挖坑</span></p><p><span>说实话,如果我要较真,技术同事评估的工期,我自己都能评估的出来(之前创业时几乎天天给客户评估工期)。我并没有干涉技术评估的工期,并不是放任不管,而是对他们的尊重,各自评估自己的开发时间,我心中自然有一杆秤。</span></p><p><span>但是,不要总是快到上线的时候才告诉我要延期。评估工期,不是儿戏,请认真对待。我喜欢,未雨绸缪,提前告诉我任何风险,这样我好把控项目进度。</span></p><p><span>(5)所有新需求必须经过我同意</span></p><p><span>所有需求,必须经过我这边过滤。部分小改动,需求方有可能直接跟技术沟通。但必须告知我,我同意才能改,不同意我会告知需求方与技术原因。</span></p><p><span>
    </span></p><p><span>5. 如何与项目组之外同事合作</span>
    </p><p><span>(1)关键人物沟通</span></p><p><span>外部团队协作,一定要找到关键人,能拍板、有话事权、决定权的人,这样沟通协调事情事半功倍。</span></p><p><span>(2)借助外力</span></p><p><span>如果外部团队相关关键人不配合,那么请求上级领导协助,并告知此事来龙去脉。反正,逐级往上汇报,直到此事有个处理结果。不要害怕得罪人,我们是做事的人,对事不对人。</span></p><p><span>(3)所有正式的决定必须有据可查</span></p><p><span>所有正式的决定必须有资料保存(公司邮件等),便于日后以防双方忘记,或者扯皮。</span></p><p><span>
    </span></p><h2><span><strong><span>三、常遇到的坑有哪些</span></strong></span></h2><p><span><strong><span>
    </span></strong></span></p><p><span>(1)历史数据</span></p><p><span>任何一个系统改造的大难题,我就深深地被其困扰过。要把按照以前旧规则的几万条旧数据匹配系统改造后的新规则,而且还要保证这些数据上下游系统能够跑通,此种过程是极其困难和麻烦的。</span></p><p><span>(2)技术没空,导致项目延期</span></p><p><span>有的时候,被这样坑,也是无语的很。本来大家都沟通好的上线时间,突然技术跑过来说我这边没空搞你这个项目,要搞其他更重要的项目,你的项目要延期。此时,心中一万个策马奔腾。</span></p><p><span>一次还好,一次又一次,你爽吗?</span><span>你的需求方爽吗?</span></p><p><span>(3)遗漏的技术bug</span></p><p><span>测试小哥哥小姐姐其实很给力,没有他们把关,一个项目上线肯定更多问题。但百密也有一疏,上线后仍有技术bug情况,也是有的。</span></p><p><span>如果重要紧急的,要求团队成员加班加点必须解决;如果不重要紧急的,也别太为难人加班加点,双方定个宽松点的优化时间期限就好,技术都是很好的一群人,不要为难他们。</span></p><p><span>(4)需求变更</span></p><p><span>又一个老大难问题,需求变更导致的风险,是很麻烦严重的。不过,要根据自己的经验与能力判断,此次需求方变更需求的影响范围。</span></p><p><span>如果影响不大,那能改就改;如果影响较大,那必须报风险;如果是影响思维模型中的底层数据架构,那必须报严重风险。</span></p><p><span>(5)紧急需求</span></p><p><span>最怕这类人,不讲理还霸道,整个项目正常的上线流程又不是不知道,但还要提出我现在就要,一周之内就要这种不懂互联网项目正常上线流程的无理要求。</span></p><p><span>谁的事不急,谁的需求不重要?你现在要,我也给不了,小需求我可以快速评估,尽快上线,尽量做到能今天上线绝不拖延到明天。但是,大需求该怎么走流程还是得怎么走。</span></p><p><span>(6)影响上下游系统</span></p><p><span>上面已提过,再次强调其重要性。我觉得此牵一发而动全身之事,应该是整个项目组的成员,都要去考虑,而不只是产品经理。</span></p><p><span>(7)部分原型规则遗漏</span></p><p><span>这个锅,是产品经理的,考虑问题不周全。但是,我觉得不完全是,项目是有需求方、所有项目组成员一起评审的,大家都没发现,咱们不小心漏掉也是无心之举。只能通过不断刻意练习,尽量避免这种问题的发生咯。</span></p><p><span>(8)项目组临时换人</span></p><p><span>项目开发到一半,技术突然离职或者被其他项目借调,导致项目突然报风险,也是很容易让人措手不及。如果技术离职,得找人尽快接手咱们的项目。如果技术被借调,咱们产品得去了解具体原因,想解决方案。最终目的,保证项目正常上线。</span></p><p><span>(9)修数据</span></p><p><span>数据在,各上下游系统中流转,难免出现一些错漏的数据,在系统上已经是无法修改的了。这种时候,只能通过技术手段,后台修改该部分问题数据,保证数据正常流转。</span></p><p><span>(10)杂事缠身,无法专心出原型+规则</span></p><p><span>很多时候,咱们会被各种杂事干扰自己正常的工作。各个需求方的需求都很急,但却被各种杂事、会议拖慢了项目正常进度。很多事很多问题,不得不处理;很多会议,不得不参与。</span></p><p><span>此时,高效的处理问题并给出解决方案,高效的讨论会议并达到会议目标,尤其重要。这一点,仍然坚持对事不对人原则。</span></p><p><span>(11)各系统需求边界划分不清</span></p><p><span>估计很多产品,自己都没搞清楚自己做的系统目的是什么,只要需求方提出来的需求就接进来,根本不在乎自己系统的定位是什么,边界是什么。这样做,没错。</span></p><p><span>
    </span></p><p><span>但是,需求方提出的是其他系统的需求,你是不是应该找其他系统产品聊聊,将各个系统边界划分清楚?我是觉得很有必要的</span></p><p><span>
    </span></p><p><span>(12)岗位职责划分不清</span></p><p>越做越发现,产品经理的岗位职责很难界定清楚,需求沟通,产品设计,运营,客服,系统维护等等,貌似很多方面都会涉及的到。我们就像个家里的保姆,哪里需要,就去哪里解决问题。</p><p>
    </p><h2><span><strong><span>四、项目延期该怎么办</span></strong></span></h2><p><span>看到这里,相信大家也发现了,项目最大的风险就是项目延期。因为延期,导致的后果,可大可小,这点因项目而异。那么,该如何解决呢?</span></p><p><span>(1)查明原因</span></p><p><span>导致项目延期的原因:离不开需求变更、原型+规则考虑不周全、技术bug、项目工期评估有误、突然更换项目组成员等等。是其中哪个原因,还是哪几个原因,找出来,然后对症下药,争取下个版本或者其他项目,不要再犯。</span></p><p><span>(2)定解决方案</span></p><p><span>出现问题不可怕,可怕的是连产品经理都手足无措,没有解决方案。</span></p><p><span>(3)上报风险</span></p><p><span>项目都报风险,导致延期了,如果该知道的人还不知道相关原因的话,那就说不过去了。而且,必须给出大家合理解释。</span></p><p>
    </p><h2><span><strong><span>总结</span></strong></span></h2><p><span>此文之前有过一版,由于之前的排版一直被人diss,为了不是因为表现层的东西而影响了本文质量的传达,特此增加个人新的体会及排版,以便后人查阅。
    </span></p><p></p></section><p><span>
    </span></p><div yne-bulb-block="paragraph" style="white-space: pre-wrap; line-height: 1.75;"><span style="color: rgb(53, 53, 53);">
    </span></div><div yne-bulb-block="paragraph" style="white-space: pre-wrap; line-height: 1.75;"><div yne-bulb-block="paragraph" style="line-height: 1.75;"><span style="font-size: 24px; font-family: Tahoma; color: rgb(47, 47, 47); font-weight: bold;">微信公众号: 刻意练习产品经理</span></div><div yne-bulb-block="paragraph" align="justify" align="justify" style="text-align: justify; line-height: 1.75;"><span style="font-size: 16px; font-family: Tahoma; color: rgb(53, 53, 53);">关注后,输入【入群】,每天和400+一起学习!</span></div><div yne-bulb-block="paragraph" align="justify" align="justify" style="text-align: justify; line-height: 1.75;"><span style="color: rgb(53, 53, 53); font-family: Tahoma; font-size: 16px; letter-spacing: 0px;">关注后,输入【书籍】,送你20本经典好书;</span>
    </div><div yne-bulb-block="paragraph" align="justify" align="justify" style="text-align: justify; line-height: 1.75;"><span style="font-size: 16px; font-family: Tahoma; color: rgb(53, 53, 53);">关注后,输入【工具】,送你10款产品工具的安装包;</span></div><div yne-bulb-block="paragraph" align="justify" align="justify" style="text-align: justify; line-height: 1.75;"><span style="font-size: 16px; font-family: Tahoma; color: rgb(53, 53, 53);">关注后,输入【crm】,送你crm相关干货;</span></div><div yne-bulb-block="paragraph" align="justify" align="justify" style="text-align: justify; line-height: 1.75;"><span style="font-size: 16px; font-family: Tahoma; color: rgb(53, 53, 53);">关注后,输入【历史】,查看本公众号所有内容;</span></div></div><p>
    </p><p>
    </p>

    相关文章

      网友评论

          本文标题:转型产品经理该怎么做(适用于0-2岁的产品经理)

          本文链接:https://www.haomeiwen.com/subject/idmfvctx.html