工作三个月,我都学了啥——沟通篇

背景介绍:

我司非第三方代理开发商,故本文所述所讲仅针对本人在我司所学所感,具有一定局限性,读者千万别乱入。产品人员的沟通涉及诸多环节,贯穿整个产品开发周期。其中,在面对不同的群体时,在不同产品周期,需要注意的点也是不一样的。


与产品沟通:

与产品的沟通环节主要在前期需求设计阶段(有新人可能疑惑,是不是其他环境就不沟通了?非也,每个阶段都会有产品间沟通,但此处已说明是主要)

不同的pm会有不同的工作风格,这有先天的原因也有工作大环境的原因。

有pm强势得蛮不讲理,誓要把需求上线——这类人是有魄力实干家,往往能把事情完成。他们的产品理念是这样的“我的需求=真理”由于有时候会强势得蛮不讲理,以致pm的专业度很大程度决定了需求的价值量。另外,由于蛮不讲理以致对团队氛围难免存在消极的影响,长此以往,存在各个岗位爆发的危险。

对付这类人的方法,我认为可以从以下方面着手:更强势但要以理服人,道理存在两个地方,一位高权重的人手上,二产品的数据;第二个方法是设法私交,建立起良好的私交关系(良好的私交,确实能使得我们沟通畅顺一大把,如果你能好好私交每个人,那么产品路上必定顺途,然而实现这样可能性并不大。)

有pm自持经验多,于是他们的产品设计理念是这样的“我的经验=产品设计原则”。这个逻辑的bug在于,该pm的经验是否具备质&量,“质”表现在ta的经验能否具备时效性(跟得上潮流),专业性(是否存在行业制约、民族/种族制约等),适用性(细化场景适用性),简言之ta的经验是否适用于当下本产品的本需求设计;“量”表现在ta的经验是否足够多。

有pm持数据说话,他们的产品设计理念是这样的“数据说的都是对的”。相比于上面两种pm,数据pm可谓是最讲道理的pm,因为数据就摆在那里,想说服他们的大法就是用数据说话。而其局限性在于,得找到有可靠的数据。

虽说存在不同风格的产品人,但是产品内部还是比外部能更好好聊天的,因此内部的pm互撕的情况还是比较少的。


与其他岗位人员沟通概况:

无论是ui、开发、测试抑或是商务等其他岗位的人员,大体都能按照以下方式进行划分:从是否热爱产品(职业还是事业)、是否明事理两个维度分成4类——爱产品又明事理的人,爱产品不明事理的人,不爱产品但明事理的人,不爱产品又不明事理的人。

从能好好沟通的难易程度来看,明事理的人比不明事理的人能更好沟通,爱产品的人比不爱产品的人能更好沟通。由此我们按照沟通难以程度从低到高排序可以得出,爱产品明事理,不爱产品但明事理,爱产品不明事理,不爱产品不明事理。

明事理的亲基本都能用数据好好说话,而爱产品的亲有一潜在问题,可能会提不少“建议”,居多是不可靠的,此时需要pm过滤掉,且不能伤害开发。对于爱产品的一类人,我们可以打私交牌,多点沟通对产品的看法,了解开发的想法,在互撕的时候可以通过调用情感的方式展开攻势。至于不够意思的(不爱产品不明事理),我们主推强势牌,公开场合讲道理,一般而言开发在广大众目睽睽下敢撕破面皮不听道理的是比较少的。需要补充的是,即使我们知道对方是何种类型的人员,礼貌与道理都是不可缺失的。尤其要好好对待那些长老们,毕竟人家门下子弟多、门上大卡多,乱撕会带来不可估量的恶果哦。


与UI沟通:

ui原型设计是产品正式开发的第一环节。好的ui图能够为团队高速开发提供助力,反之,则是阻碍。鄙人主要遇到过两种ui坑,一是设计样式问题,表现在功能风格与总体产品风格不一以及设计不满足需求功能;二是设计节奏慢,拖累开发,导致开发周期变长。解决问题一需要pm对自己产品风格、功能需求要了解透彻清楚自己目标,不然容易误入深坑。解决问题二,注意私交,因为有时候ui可能会有多个不同产品的需求,谁的感情深厚很大程度决定了需求在ui眼里的优先级;另外,有时候部分需求可先出基本框架,再后续补充终极图,这方法作用颇大。


与开发沟通:

与开发沟通的阶段主要在于两个:需求评审,需求开发阶段。

技术是有瓶颈的。需求评审时,主要理清楚哪些是开发们真正难以实现的功能,还有了解可实现的技术方案。有时候程序员出于工作量大、耍脾气而拒绝需求,此时,需要pm们好好区分是其中深藏原因,然后得出合适的处理方案。遇到比较多的情况是,开发因多个版本的奋斗,身体达到了疲态,可以考虑减少需求,给开发一个康复期;

需求开发阶段:不排除在开发过程中,出现了新问题,此时向产品申请更改设计,此时也是需要好好甄别情况。一般而言,问题主要有两,其一开发进度慢了,开发希望采用更简单的技术方案;其二,出现了原设计未考虑到的新问题,包括技术层面与产品层面,前者主要指技术瓶颈,没法实现原方案,后者主要指没考虑到产品层面的操作特殊情况,主要表现在忽略了异常页面的设计。

对于问题一,pm注意松弛有道拿出自己的态度,为的是避免开发用此借口来影响产品质量、延长产品开发周期。对于问题二,多了解技术方案以及注意需求完整度,尽量在需求设计阶段把问题清除;其次是在问题出现了之后,能及时设计出新方案,不然就坑爹了。

其他的沟通的场合:

提bug、验收阶段:人人都有想法,管控想法真的很重要。


与测试沟通:

测试对需求的理解程度很大程度左右产品的验收质量。跟进测试的难易,我把功能分为了运营需求与非运营需求。运营需求不仅涉及了客户端的问题,还涉及了服务器、后台的问题,任何一个环节失误都会给后期运营工作带来额外负担。对于这类需求需要与测试核对运营需求,且pm应自检(设计多种测试方案),尽量避免问题。


与主管沟通:

当你还没有足够实力底气时,听他的;有底气时,辩证听。

对于喜欢乱入的主管,要有态度,“集体控诉”。


与商务沟通:

商务的眼里只有钱,他们不会跟你聊产品,沟通时别浪费自己的情怀。

商务推广收入方案的时候,为不达目的不择手段的节奏。pm注意甄别数据的可靠性,还要注意全方位调研(公司内部产品/竞品/行业等),多了解哦。另外,对于不可靠的需求,能拖则拖,能不上则不上。另外,与除了商务合作接入时需要沟通外,还有一个重要的模块就是进行收入跟进。

商务的收入方案主要有两种:自家打造的以及第三方的。对于自己设计的方案,不可靠的居多,但出于自家产品,因此一般而言都会接入,但同时接入时需要进行测试,避免乱入。

对于第三方合作,在推动需求时会与第三方进行沟通,注意要了解合作细则以及其中的关键性收入指标(按CPC计费还是CPI计费等等)。对于第三方合作,pm持有较大的选择性与话语权,因此需要pm调研产品选择合适的接入方案,避免既伤了产品又浪费开发资源。商务接入合作可能需时长,注意不要过分依赖商务能在收入上帮上多大的忙。

另外,注意合作的跟踪,当方案出现问题时,及时反应。不良合作可以考虑下架。出现异常注重发现问题原因,避免雪崩效应。


与服务器沟通:

不见得每个需求都需要服务器的亲帮忙,但需要用到服务器的功能点都应该大功能(可运营功能),重要性不言而喻。对于复杂的后台,pm可以设计出后台原型,这是为了避免服务器的亲设计出难用的后台,导致后期运营阶段耗掉大量人力。还有就是服务器需求需要产品、开发、服务器的三方人员核实,避免需求出现错漏。


总结:

作为产品人员,聊天大法的核心原则我认为有以下:好好聆听;数据说话;简单说。

好好聆听:好好聊天的基础,做一个会“听话”的人是相当重要的,一方面既能表现出对对方的尊重,其次能弄清楚问题所在以便于解决问题。

数据说话:大多数人会有被情绪冲昏头脑的情况,另外,在聊聊的过程中往往因为双方没能提供可量化的数据导致沟通受阻,浪费时间。如此若能够找到可靠的数据来聊天,相信能提高双方的沟通效率。

简单说:pm得把需求想清楚,把话说明白,能提高效率哦,这样才能让大家好好聊聊。

推荐阅读更多精彩内容