时间: 2021-07-30 11:42:13 人气: 6 评论: 0
笔者在某云计算厂商做过两年半的对内产品的PM，期间也遇到了不少大大小小的坑。私以为做产品经理，一定要懂得总结，平时**有一些凌乱的想法，就借此机**整理出来，将在这段经历中遇到的坑总结分享给大家，希望也能够帮助到其他跟笔者一样境遇的产品经理。
产品H为一款监控产品，从0到1在某云计算厂商内部中孵化。从笔者开始做这款产品到笔者离职，经历了两年半的时间。期间的工作除了对产品的调研、原型设计以及跟进开发测试外，还有很重要的一部分职责是内部推广。
但是，在这款监控产品对内发布之前，各个业务部门并不是不用监控的，大多数业务部门搭建了自己的Zabbix等开源监控系统，更有一些体量大、业务相对复杂点的部门自己根据自身的业务开发了监控系统。所以，产品H从一开始所面临的压力就很大，因为对业务部门而言替换产品的成本很高。
接下来，笔者想根据产品H演进的过程来讲一下遇到的坑，以及当时是怎么做的以及对于更好做法的思考。
做产品H的团队，架构师、研发、产品经理、测试等等都是初来这个公司的新人，公司招这么一批新人的目的也是因为我们这么大公司，不能老用别人家的监控产品吧。但现有的工具团队中，没有人懂该如何做好监控产品，所以从别的大厂挖了一些有相关经验的研发过来（笔者例外，之前没有运维或监控的经验，完全是新人一个）。
面对前提背景中，各业务部门已经有在使用中的监控系统，产品H想要取代那些产品，实施的思路是这样的：
先有简单的采集（服务器基础指标、端口监控指标、进程监控指标）和报警功能（如果读者对运维监控系统不太了解的话，那差不多可以比喻成业务方都在用5G手机了，然而我们开发出老年机希望他们来用），然后再给兄弟部门推广，并让兄弟部门给点使用建议给其他业务部门推广。
首先，这个思路的第一步就出现了问题。
如果想要通过产品本身的优势吸引到用户来使用，那第一步里做的事情明显远远不够，业务方们已经在用功能更加成熟的监控系统了，根本不屑于用这样的产品。如果是依靠政治手段进行推广，那一开始满足最基本的功能就想推广成功，很大程度上取决于产品经理的跨部门沟通能力。
产品H面临的就是第二种情况。
作为负责去推广这个V1.0产品H的产品经理，当年的我确实too young too simple，以为大领导都发话了，那大家一定**配合我的吧，很快就被现实打脸了——兄弟部门总是以还有别的事要忙为理由婉拒接入产品H（私底下更是直接骂这是什么傻X系统，根本没法用）。
也因为这个挫败，领导给我的绩效评了一个0.95（基准线是1）。所以，我当时面临的情况大概就是自己的团队没有能力和时间提供更好的技术和产品，而兄弟部门也拒绝接入这shi一样的监控系统，上级领导也没有通过权力来帮助我的意思。最后，本来抱怨的我调整了自己的思路，既然兄弟部门已经烦我了，那我为什么不把他们烦到底呢？
所以接下来的时间，我跟他们的沟通特别频繁，没事就往他们工位跑，一个上午可能就跑两三次，督促他们该做什么要做什么，并表达了这是我的任务希望大家帮帮忙配合一下（多亏我是女生）。
有一次他们要去团建，我缠着两个运维非要他们解决十几台机器的监控部署问题后再走，他们的领导也是很无奈~
所以，总结一下：如果你的内部产品V1.0版本不具备替换别的产品的硬实力，那作为产品经理的你就要发挥出你的软实力了。
对于内部产品，资源往往是给不足的，所以没有UI/UE也是必然的。相信大多数的产品经理虽然有不错的审美，但完全交给自己来设计视觉，**觉得该不知如何下手，好不容易找到个可以抄的UI设计，前端做出来的效果往往相差很多。
一开始，我们团队认为这是内部使用的工具型产品，没有必要追求好看的外表，而更应该注重产品本身的作用，但很快就被现实打脸。业务方即用户，根本不**站在我们的角度去想，做的不好看不好用，就是产品有问题，管你是对内产品还是对外产品，我是用户我就是老大。
后来，我们就把一些关键的页面送到UED部门排期做设计，一般普通的页面就依然由前端和产品经理来把控交互和视觉。以此来平衡产品迭代速度和优雅与否的问题。
其实很多UI设计师除了**做设计外，还**写CSS，所以如果有这样的设计师，其实给产品设计视觉效果并不**减缓产品迭代速度，反而有助于产品的快速发展。只可惜当时我所在的部门没有UI设计师的HC。
这段经历也让我意识到：虽然在产品经理需要关注的事情中产品的外观不如产品能力重要，但往往有好看的外表才**使用户有继续探索使用的意愿。所以，作为产品经理的你我，在部门无法给足你资源的情况下，就需要自己找资源了，向别的部门借人借时间也是一种途径。
有一段时间，也是产品H快速发展的时期，几乎每隔两天就有一次上线，而且这段时期也是领导的敏感期，所以领导经常突然给我们加需求，就要保证领导的需求尽快上线（当然作为产品经理，也**评估下领导的需求是否为必要，但内部产品的功能往往很难依赖于数据驱动，领导的需求也经常跟自身的岗位有关）。
虽然我也身兼产品功能测试，再加另外一位测试开发，测试还是很难跟上产品功能迭代速度。而且迭代太快，导致测试对于近期要上线的功能优先级很模糊（即便有文档和项目跟进记录），再加上我们上线前**有很多个环境进行测试验收，测试的心态一度处于奔溃的边缘……
而开发也几乎是沦为“上线工程师”，每天都要提防今天是不是有上线，作为产品经理的我，也在每天提醒开发今天要上线的内容，导致经常打断他们的思路，大家的脾气都变得有些暴躁。
很惭愧的是，我是在开发和测试都已经不爽的时候，才发现了不对，而不是一开始就看到我们的上线流程出现了严重的问题。为此，我也承受了很大的压力，主要来自于开发和测试的不信任感，即便我想要做出改变，他们也很难有所认同。
这时候，我们的架构师兼领导站出来说下周给大家一个方案。而作为产品经理的我，怎么能让领导去出具体的方案，所以周末加了个班，理出来一套方案，来供领导拍定。
既然开发和测试都已经忍受不了如此频繁的上线，那我们必然是要做出一些让步的。方案中规定每周仅周三上线一次，最晚不**过周四上午，但领导额外提出的紧急需求例外，要尽可能满足领导的要求。并且在方案中详细说明了每一个环境的作用是什么，以及每一个环境需要跟进的人员有哪些。
虽然测试和开发之前对于我老是跟进每一个环境有点儿不耐烦，但作为产品经理就是需要面对这些来自内外部的压力啊，该自己扛的责任还是要扛的。
由于某些原因，我在带队做某一个很重要的功能时，领导给安排的开发、测试人员都是新人（刚毕业或者刚入职不久），一方面他们对业务本身不是很熟悉；另一方面对互联网的流程认知有所欠缺（可能不太懂要仔细阅读PRD，以为需求评审后按照原型再凭借记忆去做就可以，甚至对产品经理岗和自己的岗位分别职责是什么都不太懂），并且这些新人在开发的过程中，全程没有高级工程师监督和指导，高级工程师全部被分配做别的产品了。
可能本身在安排资源的时候，就有些问题，但作为产品经理，不管面对什么样的资源条件，都要让团队离目标更近。所以，我也**要求尽量减少自己对资源的抱怨，自己努力做出一些改变来适应现状。
既然手里的开发资源都是新人，那么每一步都需要说明清楚细节。以下是每一步遇到的问题，以及对应的解决方法：
在一切开始前，先制定好产品的roadmap，同步给团队所有人。一个是让团队每个人都知道目标和计划，另一个是让大家做事有节奏感（找到好的节奏感，大家的协作**更加顺畅，更容易事半功倍）。
在我做需求评审的过程中，我觉得最难的是让大家注意听我刚刚说了什么，因为开**的时候，大多数人还是很难保持注意力集中。
在以前跟高级工程师讲需求的时候，他们往往**各种提问，发散思维，产品经理不仅要快速思考他们的问题还要避免因为发散过度导致跑题。但面对新人，需要注意的是：如何让他们懂得和记住我刚刚说了什么？
这时候，**议纪要就很重要了。可能越有仪式感，大家就越重视吧，**议前发送**议邀请，**议后发送**议纪要，**让大家莫名对这件事有所重视。另外一点**议纪要很清楚地梳理出本次评审**议讨论的事项和决策点，如果真有人在**议上又走神，那回过头看看**议纪要也能知道：要做什么？以及，当时提出的问题要怎么解决？
高级工程师往往已经有很好的自我要求，所以作为产品经理，面对他们不怎么需要担心他们的进度。但对于新人，往往没有很好的owner意识，在做这个功能的时候，新人开发们对于制定好的子任务时间要求没有严格遵守，请假的直接请假，滞后的也没有想要补救。
虽然做过项目复**，大家很明白自己哪些地方做的不好，但基本上还是没有改善。
所以，在需求评审**中我加了一项：研发、测试初步给定自己的时间点。
我**先给出一个deadline（比真实的时间早3-5天），根据这个deadline，研发和测试评估自己任务所需时间，以此画出一个时间轴。我**在**议纪要中，将这个时间轴发布出来，并要求如果还有问题，需邮件回复来调整时间（当然要抄送领导）。
这样做后，大家对于时间点的感受更加明确，即便前一周的进度有滞后，但想到自己的完成时间点在哪里，就**在下一周里就**把进度赶上来。
在项目开发过程中，往往**出现一些因素导致原本的需求要有所调整（要确保整体进度和质量时，往往**牺牲一些小的体验和功能）。
公司提供了jira、看板等需求管理工具，我平时**用jira来管理需求，更新了内容后，jira**自动给任务中的所有人发送邮件通知更改内容，但往往大家的邮箱每天都**收到很多封邮件，漏看更新内容也是常有的事，群里一个个@也还是**存在漏看的情况，最终就导致大家都任务理解不一致了。
为了避免这种情况，我把PRD和原型都使用在线查看的方式供研发和测试阅读。这样的好处是，我的更新都**实时上传上去，研发和测试打开看到的内容就都是最新的。
新人的经验毕竟少，所以写的功能出bug率比较高，也是意料之中的事情，但当时我们比较离谱的是自测都没有通过就提交给QA来测试。
可能大家看到时间点快到了就着急提测，结果自测并没有覆盖全面，导致整个流程都无法跑通。后来，我们就要求所有研发开发完成并自测后，通过邮件的形式提测给QA，邮件中需要写明需求说明、所在分支、测试环境、影响范围、自测case等。
感觉大家都是注重仪式感的人，有了这个提测邮件后，大家**更加谨慎的提测，毕竟被QA打回**被所有人看到，是件很丢脸的事情┓( ´∀` )┏。
做产品经理的我们，经常可以听到的话就是：V1.0版本一定要快、准、狠。
V1.0版一定要能够抓住用户最本质的需求，快速地解决问题。V1.0版越简单越能看出一个产品经理的自信。
对外产品虽然无法直接接触到用户，但通常可以根据运营数据、A/Btest等方式来作为判断依据。但对内产品，却要面对来自各个业务方甚至自己团队的大量建议和要求，就**有很多干扰信息。内部产品在做一个全新功能时，往往根据产品经理对业务方的调研做出一个自己认为是正确的V1.0版后，时常要面对的大量吐槽：缺这个功能少那个体验。
其实，这都是因为业务方不知道推出这个V1.0版想让他们来做什么事造成的。产品H跟市场上其他竞品相比，起步晚、实力悬殊，但作为用户把它跟市场上那些数一数二的产品作对比，这是再正常不过的，不过好在既然是对内产品，那就可以直接与业务方沟通这个功能的V1.0的目的是要做什么。
让业务方了解目标后，再对照V1.0的功能，看看是否可以满足，对于其他的建议和要求，也可以回复业务方在接下来的迭代中**进行上线。
还需要做好的是：记录每个需求和对应的报告人，如果他的建议和要求上线，那就及时通知，让对方有一种自己被重视的感觉，也方便建立友好的沟通。
其实，除了以上这些坑，还有好多坑，诸如：领导也**对产品提一些需求，但这些需求在领导脑子里一天就能变好几个样，那产品经理就需要把握好产品或功能的定位，抗住压力，自己去判断值不值得做以及在什么时间做。而大多数的领导还是**听进去他人的意见的，就怕没主见的产品经理。
也许读者看到我的这些经历，**觉得我这个前任公司流程管理制度上有些乱，也许很多人根本不**遇到我的这些情况。的确部门从一开始流程管理就比较混乱，因为当初大多数人都是高级工程师，都已经有一个比较好的自我规范的习惯，但随着部门中新人越来越多，这套完全靠自我驱动的方案就行不通了。
产品经理不仅要有解决产品需求的能力，还要有发现团队问题并解决的能力，内部团队没问题后，才能更好地对外输出成绩。
不管怎样，我还是从中学到了很多。产品经理就是带着一堆人去做一些实现部门目标、提升大家绩效的事情，并分析内外部环境给团队寻求资源的那个人。
在做产品H的两年半中，我能够感觉到自己已经从那个只**分析需求、管理项目的产品经理成长到能够带着团队一起实现提升业绩目标的人物了，更加清晰地认识到产品经理所面对的压力和责任，这份责任感虽然沉重，却也是让我热爱这个岗位的原因之一。
本文由@草木夏 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash, 基于CC0协议。
