自春节到现在,我陷入一种困境里:突然间,我好像成了“夹心饼干”?

事情是这样的,由于业务变动,最近我开始负责一个核心产品的版本迭代管理。我敞开心扉拥抱变化,但两个月下来,事情比我想象中得更棘手。

先交代下背景。

在我之前的工作经历里P l Q 8 D – # $,我和前线的团队交涉比较多,销售、售前架构师、产品架构师、服务商、ISV,都相对比较熟稔。熟稔到什么地步呢,就是他们跟我说声hi,我都几乎能料到他下一句话想问什么、想要什么,我可以怎么推杯换盏地应对他们。和他们站在同一条船上久了,我深谙支e 7 / 9 ) + [持项目有多不易,我理解客户对产品的诉求有多急切,也愿意尽最大努( M G K y k ! B L力去争取产品研发的资源投z e l / x E $ d _入。

但是,一切开始不一样了。自打我接手l 3 ` & U A F k w产品研发工作,开始负责c 8 . f D C S I !产品整体规划和版本迭代管理后,我多了一重身份。F – : – 3 W h随着我深入了解产品的细C E = % k {节,了解看似简单实则不易的需求背后沉淀了这H B d P么多研发、测试的人力P J \ G } X V– , Q J c D 9 5,我不得不站出来为产品研发团g I H [ c #队说说话了。

这也就导致,我清楚客户需求的合理性和迫切性,但我也在警惕产品研发资源的不合理占用。于项目团队而言,作为产品接口人的我开始谨慎承诺,小心防守;于研发团队而言,作为项目w g / O Y经理的我抱着一揽子需求回来,生怕我狮子大开口。

b h a R k 5 p % K外不r | ` x是人了不是?我反思过,是不是该去学一学怎么端水?

把情绪放一放,我给自己一个版本的试炼机会,也趁此摸清楚了项目支持和产品管理的平衡之术。

我和其他团队的产C y b H 8 a h品经理聊了下,有些同y / Z N学一开始就是走产品S 4 K \策划路线,始终站在产研的角度,专心琢磨如何让产品做得更好;有些同学一直都是在客户现场,或是出差去现场的路上,f ( b [ M E x 5 ^他懂行懂客户,能根据客户需求拟制解决方案。

其中不乏有产品经理负责版本迭代管理,但总会遇到各种各样的n @ | m =问题:怎么去权衡各大项目反馈的需求优先级?怎么应对空降的需求带来的资源占用?怎么让前线团队放心、让研发团队齐心呢?

不少团队都倾向于将产品研发管理专门交给项目经理去负责,由项目经理协调产p w , \ B 9 B品、设计、研发、测试的资V S l源,并跟进整体版本迭代的进展。这的确权责分明,产品做需求,开发写代码,各司其职,何乐而不为?

可事实上,版本管理的重点不在于由产品研发团队中的哪个角色来承担,关键在于如何去管理这个版本。既然团队内暂时没有这i ` N s e F R h ul / u的角色来5 b ( \ 3 G } k支撑,那么我大可以利用自己的多重身份“夹带私货”,不是吗?

一、不仅是0 A r | + B规划版本

规划版本前先规划产品roadmap。

为什么前线项目组总f ! A是源源不断地_ d C S G i {投递需求——我要斩断不重要不紧急的客户需求。

为什么研发同学总是下意识拒绝需求——我要调动产研资源实现优先级最高的产品能力。

从客户需求到产品能力之间是e M { { + X有Gar . m U q U 3 {p的,我要搭桥造梁,就需要一个支撑。

那么,怎么规划产品的阶段性里程碑?

1. 从团队KPI入手

今年团队的考核目标是什么,是产品收入?用户活跃度?标杆H Z z案例数?项, S % Z U d Q l q目的复制情况?d – #

2. 制定个人@ w D t i ; [ ,OKR

基于团c w g F % ( D v队的目标,落实到个人所负责的产品目标,去看在该目标下你要输出的关键结果是什么。

比如你们考核的是要在全国范围内树立至少2个国家级标杆项目,那么对应的这类型项目最关注的需求场景是什么;为了满足这样的需求场景,产品要实现哪些能力、配套提供哪y : \ D { q A t些服务支持。

3. KANO模型

这是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的工具,需求分五类:基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求。

① 基本型需求(必备型需求)

客户认为必须有,没有的话这C – 5 S ! o J个功能就不具有交付意义的需求。

针对这类需求,一旦你没满足客户,客户的满意度: & T _ e z ( 7将一落千丈,你可能马上就要被踢出局。比如顾客买一个保+ – h z O温杯,它能正常装热水g * + ` A R,顾客不会为此感到满意;但如果这杯子有裂缝,杯盖拧不紧,或是保温效果差,那么顾客对这个杯子的满意度就, 5 % u W ( / 2 9会明显下降,投诉接踵而至。

② 期望型需求

客户期望你可以实现的需求8 p K _,一旦你实现了,客户满意度会显著提升,你提供的产品超出客户期望越多,客户就越满意。

但相应的,如果你拒绝满足客户需求或是表e ) v H # ^ a b现不好的话,客户也会立马提出不满。比如客户期望贵司提供的问题响应机制可以更快捷、故障处理可以更高效,那么一旦你优化了问题处理流程,提高对客户的响应效率,客户就越满意。

③ 兴奋型需求(魅力型需求)

客户既不会过分期望,又不会明显不满的需求,即,有更好,没有也能接受。

比如早期海底捞向客户推出生日当天全体员工向顾客唱生日歌,这种服务的确会让顾客惊喜,但如果不, b L E f提供这个服务,顾客也不会不满。这类需求通常能在某些时机打动客户,赢得客户决策人更多的关注。

④ 无w p 0差异型需求

这类需求对客户没有影响,有或没有都无所谓。

这种需求怎么会被人提出来呢,可能是客户对标了不同的产品,或是灵光乍现想到的,这样的需求在c b ^ O应对的时候需要甄别,不必过分投入在这类需求上。

⑤ 反向S n 5型需求

该需求会引起大部分人的强烈不满,你实现该需求反而会降低客户* : 5 Z }的满意度。

比如客户管理层提出一些强管J H / P W理的需求,乍一听很合理,但深究下来,这需求对员工不友好。即便你短暂地满足了客户高层的需求,但长远来看一定会收到客户的投诉,毕竟客户采购软件并不仅限于在管理层使用,更多时候r I 0还是为了服务于全体员工。

针对这类需求,你且缓缓,先冷静旁u W q S t s 1 u .观,做好充分的客户需求调研后,再决定是否要做。

根据上) J s z E g V述三方面,在实际规划– { A ~产品蓝图4 ^ w H A 7 B时,可以从以下两方面去考虑:

  1. 一方面根据团队OKR划定产品方向,圈定几个需要冲刺的功能模块,分月度、季度去迭代功能、做项目验证w D ,,再炮制到其他项目中落地;
  2. 另一方面摆正心态,正视客户反馈) g z r ;的需求,全力以赴满足基本型需求,] = d U 1 Z重视产品义务范畴内的事项,确保在市场竞争中不丢分。同时,尽力去满足客户的期望型需求,提供大多数客户关注的额外服务和产品,引导客户的决策链n O 6对本产品有更2 J ` G f & \多的倾向性;最后才是争取实现客户的: R ]兴奋型需求,提高客户用户的粘性W | M l 5 B A J和复购率。

你看,通过层层过滤,你会发现有不少客户需c k : } m * / j ;求其实没那么重要,它并不能为产品的销售有什么催化作用,甚5 . m X M ` h至在占用产研资源后还讨不到一点好处。

二、不仅是管理版本

前文提到如何在规划版本前规划好产品阶段性的里程碑4 f +,围绕里程碑去规划每个月的版本内容和版本节奏。

但实际上在管理版本中最大的问题不在于做哪些需求,而是什么需求要先做。每一位架构师都认为自己负责的客户提的需求最靠谱、最重要、最紧急,动辄就是“这是某位CTO提的”、4 ( ~ z p a C Y“这个需求已经上升到我司的某位高管”之类的……通往产品发布的管道就这么宽,全堵在这段路上,谁也动不了,谁也不想让。

这时候除了根据KANO模型对需求做一层初步的分类之后,每个类目下依然存在不少需求,怎么排优先级?

向外看,竞争对手相比你的优势在哪?它推崇的关键控标点有什么?研究竞品并不可耻,市场J x ? I | [ Y K a就这么大,池子里的鱼就这么多{ j 1 N * , % w P,为了捕获更多的猎物,取长补短也是顺理成章的。

向内看,你7 & b 2 N a不必把这份责任全部放在自己身上,建立版本评审委员会,邀请领导、产品和研发负责人、前线反馈需求的架构师k P + m M d r #,共同来评审这些需求的优先级。通过责任公摊和事务公开,形成一个集体公认的版本需求池。

在需求池初具雏形后,你要及时组织产品研发团队开版本启动会,宣导需r O K B d 4 q V求池里的所有需求,请产品和研发初步给出工作量的预估。一个版本迭代的周期就这么长的时间,对于比较复~ o # ? c Y !杂的需求,适时地拉长阵线去细化产品方案,才能确保不浪费研发的资源。

记住K | b 8 0排优先级时,不可只关注客户需求而忽视了去建设能满足更多客户的核心优势。

在明确版本需求和需求的优先级后,P M c我们再来看下如何调动资源投入到版本迭代。

1. 资源投入情况

  • 项目经理:负责整体版本规划和需求管理,跟进版本迭代进程,对版本的整体发布负责;
  • 产品经理:负责产品需求的方案设计和评审,负责与设计、研发y @ [ N、测试协作开展需求的建设,对需求的实现情况负责;
  • 研发:负责产B D P m { l p品需求的技术方案设计和实现,把控需求的研发进度;
  • 设计:完成需g + S Q 1 l p U u求UI设计和视觉设计,输出设计切D A C ! R图;
  • 测试:输出测试用例,把控需求的质量。

这些角色在参与版本迭代时都有各自的期望,在不同的环节里都需要换位思考下。

比如t ) h R z $ ^研发s 1 ,,最怕产品方案没考虑完全就火急火燎地找上来要技术实现,前期方案的不周全大概率会引发后期需求的变更,这对研发而言就是资源的浪费。

那么站在研发的角度,产品经理对待需求就不能只是在讲一个简单的用户故事,客户需求和产品能力之间的gap有多大,取决于你如何去理解需求、如何去细化需求场景、如何打磨好你的产品。

相应的,在版本迭代的过程中,项目经理预留给产品经理思考方案的时间要充分,不能为了满足更多的需求而忽视了产品的细节。产品不可只看细节,也不可全然不顾细节( p i | S

不注重各个方面的细节,终究会连累到之前积累的口碑;当t 2 I } & * ?所有人都盯着你缺的那一筐土的时候,没有人会关心已经堆好的九仞土山。

2. 团队机制与过程控制

既然是一个长期工程,那么何不如从一开始就下功夫定流程,定机% ` 9 X P q * A制,把涉及到的角色的工作Q 5 1 # N \ X地图画出来?

前面提到,我给自己一个版本的时间窗,去印证这个团队机制的可行性。具体流程是什么样呢?

1)明确版本节奏

一个半月2个小版本1个大版本(ab为小版本,c为大版本),小版本内X Y u 9 7 W部测试体验9 k B ^ i [ =,大版本对外正式发布。

2)规范迭代流程

建立版本评审委员会,从版本规划开始,做好向上汇报和对内同步,保证信息公开透明。没错,你是版本总体负责人,但你没必要把很多责任往自己身上揽,尤其涉及到需要上升决策的事情,分摊责任也同样是在分摊风险。

② 版本需求确定后,预留充分的时间给到产品经理调研需求、设计产品方案,并树立一个标杆性事件:开展版本启动会。由各= E w产品经理大体宣讲需求,明w O S j确需求的研发负责人,全员投票评估需求的合理性和可行性。

③ 需求进一步得到产品和研发的评估后,产品和研发负责人各自组成feature team,启动对需求的实现之h . g ; B H ;,再配合设计、测试的资源,让需求在版本发布计划的时间y 1 V窗内有序地_ 1 X推进,并适时地同步进展和风险,确保需求相关人对需求的理解是一致的。

3)加强过程控制

流程是有了,但流程里涉及到的环节比较多,需要抓住最关键的部分加强管控。9 a H 6 N Z

一个是需求评审环节,这决定了这个需求后续的实现路径,绝不能轻视。对于相对复杂且重要的需求,对于空降的高优先级需求,能不能插队也不是研发或产品或% 6 u ? 0 P架构师说了算y ? K a d b j U,都必须严格上升到版本评审委员会共同决议。

一个是研发排期环节,版本的发布时间窗是基本固9 ^ @ e t ~定的,研发排期的评估除了根据需求的优先级、实现的工作量之外,还要根据发布计划的时间点看能赶上哪一个发布计划,以确保给客户承诺的交付时间是相对可靠的。

一个是产品体验环节,不少团队在前期需求设计上严防死\ 3 Y G j ( w守,可一旦步入研发阶段,产品经% # n 0理除了间或响应研发的问题咨询外,对需求本身的实现过程和实7 S J X + M A z现结果是有d 2 F d e C a F点轻视的。

这里需要尤其重视需求研发完成后的产品体验环节,产品经理必须完整地按测试用例走查一遍功能,确保最终的功能与最初需求的设计是契合的。若有偏– N k H 9 s v ?差,是否要变更或追加需求,则同样需要引入版本评审委员会(与该W @ 3 e ~需求相关的人员)一起来评估。

三、不仅是一颗糖

产品如期发布了,这时候我对前线的架构师是否就有了交代?不够。

z C v k v ` / A )想下,架构师对产品的能力是清晰的吗?他们提的客户需求为什么在不少产品研发同学看来不太合理呢?归根结底是因为项目支持和产品建设脱节了。

两拨人,一拨人忙着做项目,一拨人忙着做需求,各自作战j t ? q y `,各自为政。

你可能会说,产% v } d J : I mU u P } a R \ s做出来不就是为了更好地在项目里售卖和交付吗?没错,但在实际运作的过程中确实存在这样的问题。于是你会发现,前线团队对产品一知半解,产研团队对项目一穷二白。

这是常态,但可以被改变。

回过头来看整个版本迭代流程,你会发现有很多环| } 7 / ; _ A o节完全可以借助前线架构师的力量。g 3 D

  • 在版本规划初期,项目经理可以请架构师? 7 d $ H 5给出有力的项目背景佐证需求的} x B k c Z N f ,合理性;
  • 在需求调G 5 w ] + ) % x研时,产品经理与架构师的深入访谈,n f H z可以更充分地了解需求场景和目标,如有必要也可以跟架构师一起拜访客户;
  • 在需求研发完成转产品体验时,产品经理邀请架构师一起体验功能,确保功能的效果与架构师的预期一, I \ = g [ l y致;
  • 在产品发布后,产品经理可以请架构师一同编制功能故事,描述功能的操作路径、实现效果和价值,以便客户更好地使用4 7 – ! U v o l C功能。

整个过] y c P d \ ? I程里,前线架构师与产研团队有了更多的互动和融合,这是我们给到架构师的一颗糖,它不仅提升了架构师对产品的理解力,也加深了产研团队对客户X W A t的认识。

同样的,产品发布后交付给到客户后,这时候我对产研团队是否就有了交代?不够。

% h f ; M I K M 8多时候一个新版c 6 9本从规划到发布,一个多月过去了。这一个月期间,客户也许还在追着要这个能力,也许早已不在意这个需求。但是产研资源也确确实实地( o 0 O b 4 W s O投入进来了,他们需要一颗糖,可能不够甜,但总比交付出去下落不明要! E j 6 F好得多。

因此我们会要求,前线实施团队\ Z } * c 8 a =交付新版本给* g ` b ; ( 2客户后,需要主动了解客户的使用情况:有没v X [ ( f n有用?用[ [ R Y g i ! O得怎么样?有全面推广起来吗?还有其他反馈^ ! 3 – T V ? 3 E吗?这些都要定期追踪,了解客户不同层: n h ^ M X级的用户对新版本发布的新[ h 5 & T C ]功能的想法,正向反馈负向反馈都好,都要有个交代。

通过这样的交代,一个更加完备的产品故事应运而生,产品经理有更多的实践素材去佐证功能的价值,架( h ! W h 1 }构师有更充分的底稿去应对客户的挑战。

四、小结

我相信k 6 Z V ^ I不少成熟的团队必定有自己一套完善的版? O q t a :本管理方法,对于客户需求和产品能力的转化也是运筹帷幄,对此我要恭喜你。的0 = 1 c W k确,同一个问题会有很多解题的思路,我从这次的事件中也想通9 l T Y } u一个道理,那就是如何去克制把问题简单化处理的冲动,避免陷入对观点做取舍的二元偏误里

在对外和前线团队的持续沟通中,我清楚了项目的百种不易;在对W ~ G G z u内和研发团队的共同作战中,我理解了产品的所思所想。如何去平衡项目和产品,让项5 7 8目驱动产品的提升,让产品更好地服务于项目,让原本若即若离的两拨人汇聚成一股更强劲的力量,这是我从中体会最深的。

我想,捋完一遍思路后,我大概不需要去学怎么O p ^ v _ 3 @ @成为端水大师了。

#专栏作家#

健壮的大姐姐,微信公a F O众号:健壮的大姐姐(ID: is_strong),人人都是产品经理专栏作} s m ( Q家。腾讯高级产品经理,专注于To B服务项目管理和行业分析,欢迎各路好汉一起探讨。

本文为人人都是产品经理《原创激励计划》出品,未经许可,禁止转载。

给作者打赏,鼓励TA抓紧创作!

4人打赏

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注