• 简中
    • 繁中
  • 注册
  • 查看作者
  • 做好迭代管理,畀团队一粒糖

    转载:本文来自微信公众号“人人都系产品经理”(ID:woshipm),作者:林壮壮,转载经授权发布。

    喺团队工作度,产品经理需要身兼多职、兼顾多方意见。而产品版本迭代管理往往需要牵扯项目嘅多方面。那么,当产品经理住手版本迭代管理工作时,应当点样协调团队工作、做好过程控制、进而凝聚团队力量?本文作者便结合其自身经验向我哋做出‌清晰展示。

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

    事是咁样嘅:

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

    先交代下背景:

    喺我之前嘅工作经历里,我和前线嘅团队交涉比较多,销售、售前架构师、产品架构师、服务商、ISV,都相对比较熟稔。熟稔到乜嘢地步呢,就系佢们同我说声hi,我都几乎能料到他下一句话想问乜嘢、想要乜嘢,我可以点样推杯换盏地应对佢哋。

    和佢哋企喺同一条船上耐嘎啦,我深谙支持项目有多唔易。

    我理解客户对产品嘅诉求有多急切,也愿意尽最大努力去争取产品研发嘅资源投入。

    但是,一切开始唔一样嘎啦。

    自打我接手产品研发工作,开始负责产品整体规划和版本迭代管理后,我多‌一重身份。

    随住我深入认识产品嘅细节,认识睇似简单实则唔易嘅需求背后沉淀‌咁多研发、测试嘅人力后,我唔得唔站出来为产品研发团队说说话嘎啦。

    这也就导致:我清楚客户需求嘅合理性和迫切性,但我也喺警惕产品研发资源嘅唔合理占用。

    于项目团队而言,作为产品接口人嘅我开始谨慎承诺,小心防守;

    于研发团队而言,作为项目经理嘅我抱住一揽子需求回来,生怕我狮子大开口。

    里外唔系人‌唔系?

    我反思过:系唔系该去学一学点样端水?

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

    我和第啲团队嘅产品经理聊‌下,有啲同学一开始就是走产品策划路线,始终站喺产研嘅角度,专心琢磨点样让产品做得更好;有啲同学一直都系喺客户现场,或是出差去现场嘅路上,他懂行懂客户,能根据客户需求拟制解决方案。

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

    唔少团队都倾向于将产品研发管理专门交畀项目经理去负责,由项目经理协调产品、设计、研发、测试嘅资源,并跟进整体版本迭代嘅进展。

    这的确权责分明,产品做需求,开发写代码,各司其职,何乐而唔为?

    可事实上,版本管理嘅重点唔喺于由产品研发团队中嘅边个角色来承担,关键喺于点样去管理呢个版本。

    既然团队内暂时没有咁样嘅角色来支撑,噉样我大可以利用自己嘅多重身份“夹带私货”,唔系吗?

    做好迭代管理,畀团队一粒糖

    唔仅是规划版本

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

    点解前线项目组总是源源唔断地投递需求?

    ——我要斩断唔重要唔紧急嘅客户需求。

    点解研发同学总是下意识拒绝需求?

    ——我要调动产研资源实现优先级最高嘅产品能力。

    从客户需求到产品能力之间是有Gap嘅,我要搭桥造梁,就需要一个支撑。

    那么,点样规划产品嘅阶段性里程碑?

    1. 从团队KPI入手

    今年团队嘅考核目标是乜嘢,是产品收入?用户活跃度?标杆案例数?项目嘅复制情况?

    2. 制定个人OKR

    基于团队嘅目标,落实到个人所负责嘅产品目标,去睇喺该目标下你要输出嘅关键结果是乜嘢。

    比如你们考核嘅系要喺全国范围内树立至少2个国家级标杆项目,噉样对应嘅呢类型项目最关注嘅需求场景是乜嘢?为‌满足咁样嘅需求场景,产品要实现边啲能力、配套提供边啲服务支持?

    3. KANO模型

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

    做好迭代管理,畀团队一粒糖

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

    客户认为必须有,没有嘅话呢个功能就唔具有交付意义嘅需求。

    针对呢类需求,一旦你没满足客户,客户嘅满意度将一落千丈,你可能马上就要被踢出局。比如顾客买一个保温杯,佢能正常装热水,顾客唔会为此感到满意;但如果这杯子有裂缝,杯盖拧唔紧,或是保温效果差,噉样顾客对呢个杯子嘅满意度就会明显下降,投诉接踵而至。

    ② 期望型需求

    客户期望你可以实现嘅需求,一旦你实现嘎啦,客户满意度会显著提升,你提供嘅产品超出客户期望越多,客户就越满意。

    但相应嘅,如果你拒绝满足客户需求或是表现唔好嘅话,客户也会立马提出唔满。

    比如客户期望贵司提供嘅问题响应机制可以更快捷、故障处理可以更高效,噉样一旦你优化‌问题处理流程,提高对客户嘅响应效率,客户就越满意。

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

    客户既唔会过分期望,又唔会明显唔满嘅需求,即,有更好,没有都可以接受。

    比如早期海底捞向客户推出生日当天全体员工向顾客唱生日歌,呢种服务的确会让顾客惊喜,但如果唔提供呢个服务,顾客也唔会唔满。

    呢类需求通常能喺某啲时机打动客户,赢得客户决策人更多嘅关注。

    ④ 无差异型需求

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

    呢种需求点样会被人提出来呢?

    可能系客户对标‌唔同嘅产品,或是灵光乍现想到嘅,呢样嘅需求喺应对嘅时候需要甄别,唔必过分投入喺呢类需求上。

    ⑤ 反向型需求

    该需求会引起大部分人嘅强烈唔满,你实现该需求反而会降低客户嘅满意度。

    比如客户管理层提出一啲强管理嘅需求,乍一听好合理,但深究下来,呢需求对员工唔友好。即便你短暂地满足‌客户高层嘅需求,但长远来睇一定会收到客户嘅投诉,毕竟客户采购软件并唔仅限于喺管理层使用,更多时候还是为‌服务于全体员工。

    针对呢类需求,你且缓缓,先冷静旁观,做好充分嘅客户需求调研后,再决定系咪要做。

    根据上述三方面,喺实际规划产品蓝图时,可以从以下两方面去考虑:

    一方面根据团队OKR划定产品方向,圈定几个需要冲刺嘅功能模块,分月度、季度去迭代功能、做项目验证,再炮制到第啲项目中落地;

    另一方面摆正心态,正视客户反馈嘅需求,全力以赴满足基本型需求,重视产品义务范畴内嘅事项,确保喺市场竞争中唔丢分。同时,尽力去满足客户嘅期望型需求,提供大多数客户关注嘅额外服务和产品,引导客户嘅决策链对本产品有更多嘅倾向性;最后才是争取实现客户嘅兴奋型需求,提高客户用户嘅粘性和复购率。

    你睇,通过层层过滤,你会发现有唔少客户需求其实没那么重要,佢并唔可以为产品嘅销售有乜嘢催化作用,甚至喺占用产研资源后还讨唔正喺度好处。

    做好迭代管理,畀团队一粒糖

    唔仅是管理版本

    前文提到点样喺规划版本前规划好产品阶段性嘅里程碑,围绕里程碑去规划每个月嘅版本内容和版本节奏。

    但实际上喺管理版本中最大嘅问题唔喺于做边啲需求,而是乜嘢需求要先做。

    每一位架构师都认为自己负责嘅客户提嘅需求最靠谱、最重要、最紧急,动辄就是“这是某位CTO提嘅”、“呢个需求已经上升到我司嘅某位高管”之类嘅……

    通往产品发布嘅管道就咁宽,全堵喺这段路上,谁也动唔嘎啦,谁也唔想让。

    这时候除咗根据KANO模型对需求做一层初步嘅分类之后,每个类目下依然存喺唔少需求,点样排优先级?

    向外睇,竞争对手相比你嘅优势喺边?佢推崇嘅关键控标点有乜嘢?

    研究竞品并唔可耻,市场就咁大,池子里嘅鱼就咁多,为‌捕获更多嘅猎物,取长补短都系顺理成章嘅。

    向内睇,你唔必将这份责任全部放喺自己身上,建立版本评审委员会,邀请领导、产品和研发负责人、前线反馈需求嘅架构师,共同来评审呢啲需求嘅优先级;通过责任公摊和事务公开,形成一个集体公认嘅版本需求池。

    喺需求池初具雏形后,你要及时组织产品研发团队开版本启动会,宣导需求池里嘅所有需求,请产品和研发初步畀出工作量嘅预估。

    一个版本迭代嘅周期就咁长嘅时间,对于比较复杂嘅需求,适时地拉长阵线去细化产品方案,先能确保唔浪费研发嘅资源。

    记住:排优先级时,唔可只关注客户需求而忽视‌去建设能满足更多客户嘅核心优势。

    喺明确版本需求和需求嘅优先级后,我哋再来睇下点样调动资源投入到版本迭代。

    1. 资源投入情况

    • 项目经理:负责整体版本规划和需求管理,跟进版本迭代进程,对版本嘅整体发布负责;

    • 产品经理:负责产品需求嘅方案设计和评审,负责同设计、研发、测试协作开展需求嘅建设,对需求嘅实现情况负责;

    • 研发:负责产品需求嘅技术方案设计和实现,将控需求嘅研发进度;

    • 设计:完成需求UI设计和视觉设计,输出设计切图;

    • 测试:输出测试用例,将控需求嘅质量。

    做好迭代管理,畀团队一粒糖

    呢啲角色喺参同版本迭代时都有各自嘅期望,喺唔同嘅环节里都需要换位思考下。

    比如研发,最怕产品方案没考虑完全就火急火燎地找上来要技术实现,前期方案嘅唔周全大概率会引发后期需求嘅变更,呢对研发而言就是资源嘅浪费。

    那么站喺研发嘅角度,产品经理对待需求就唔可以只系喺讲一个简单嘅用户故事,客户需求和产品能力之间嘅gap有多大,取决于你点样去理解需求、点样去细化需求场景、点样打磨好你嘅产品。

    相应嘅,喺版本迭代嘅过程度,项目经理预留畀产品经理思考方案嘅时间要充分,唔可以为‌满足更多嘅需求而忽视‌产品嘅细节。产品唔可只睇细节,也唔可全然唔顾细节。

    唔注重各个方面嘅细节,终究会连累到之前积累嘅口碑;当所有人都盯住你缺嘅那一筐土嘅时候,没有人会关心已经堆好嘅九仞土山。

    2. 团队机制同过程控制

    既然系一个长期工程,噉样何唔如从一开始就下功夫定流程,定机制,将涉及到嘅角色嘅工作地图画出来?

    前面提到,我畀自己一个版本嘅时间窗,去印证呢个团队机制嘅可行性。

    具体流程是乜嘢样呢?

    做好迭代管理,畀团队一粒糖

    1)明确版本节奏

    一个半月2个小版本1个大版本(ab为小版本,c为大版本),小版本内部测试体验,大版本对外正式发布。

    2)规范迭代流程

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

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

    ③ 需求进一步得到产品和研发嘅评估后,产品和研发负责人各自组成feature team,启动对需求嘅实现之路,再配合设计、测试嘅资源,让需求喺版本发布计划嘅时间窗内有序地推进,并适时地同步进展和风险,确保需求相关人对需求嘅理解系一致嘅。

    3)加强过程控制

    流程是有嘎啦,但流程里涉及到嘅环节比较多,需要抓住最关键嘅部分加强管控。

    一个是需求评审环节,呢决定‌呢个需求后续嘅实现路径,绝唔可以轻视。

    对于相对复杂且重要嘅需求,对于空降嘅高优先级需求,能唔可以插队也唔系研发或产品或架构师说‌算,都必须严格上升到版本评审委员会共同决议。

    一个是研发排期环节,版本嘅发布时间窗是基本固定嘅,研发排期嘅评估除咗根据需求嘅优先级、实现嘅工作量之外,仲要要根据发布计划嘅时间点睇能赶上边一个发布计划,以确保畀客户承诺嘅交付时间是相对可靠嘅。

    一个是产品体验环节,唔少团队喺前期需求设计上严防死守,可一旦步入研发阶段,产品经理除咗间或响应研发嘅问题咨询外,对需求本身嘅实现过程和实现结果是有啲轻视嘅。

    这里需要尤其重视需求研发完成后嘅产品体验环节,产品经理必须完整地按测试用例走查一遍功能,确保最终嘅功能同最初需求嘅设计是契合嘅。

    若有偏差,系咪要变更或追加需求,则同样需要引入版本评审委员会(同该需求相关嘅人员)一齐来评估。

    做好迭代管理,畀团队一粒糖

    唔仅系一粒糖

    产品如期发布嘎啦,呢时候我对前线嘅架构师系咪就有‌交代?唔够。

    回谂下,架构师对产品嘅能力是清晰嘅吗?佢哋提嘅客户需求点解喺唔少产品研发同学睇来唔系几合理呢?

    归根结底是因为:项目支持和产品建设脱节嘎啦。

    两拨人,一拨人忙住做项目,一拨人忙住做需求,各自作战,各自为政。

    你可能会讲:产品做出来唔就是为‌更好地喺项目里售卖和交付吗?

    没错,但喺实际运作嘅过程中确实存喺咁样嘅问题。

    于是你会发现:前线团队对产品一知半解,产研团队对项目一穷二白。

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

    回过头来睇成个版本迭代流程,你会发现有好多环节完全可以借助前线架构师嘅力量。

    • 喺版本规划初期,项目经理可以请架构师畀出有力嘅项目背景佐证需求嘅合理性;

    • 喺需求调研时,产品经理同架构师嘅深入访谈,可以更充分地认识需求场景和目标,如有必要也可以跟架构师一齐拜访客户;

    • 喺需求研发完成转产品体验时,产品经理邀请架构师一齐体验功能,确保功能嘅效果同架构师嘅预期一致;

    • 喺产品发布后,产品经理可以请架构师一同编制功能故事,描述功能嘅操作路径、实现效果和价值,以便客户更好地使用功能。

    成个过程里,前线架构师同产研团队有‌更多嘅互动和融合,呢是我哋畀到架构师嘅一粒糖,佢唔仅提升‌架构师对产品嘅理解力,也加深‌产研团队对客户嘅认识。

    同样嘅,产品发布后交付畀到客户后,呢时候我对产研团队系咪就有‌交代?

    唔够。

    好多时候一个新版本从规划到发布,一个多月过去嘎啦。

    呢一个月期间,客户也许仲喺度追住要呢个能力,也许早已唔喺意呢个需求。

    但是产研资源也确确实实地投入进来嘎啦,佢哋需要一粒糖,可能唔够甜,但总比交付出去下落唔明要好得多。

    因此我哋会要求,前线实施团队交付新版本畀客户后,需要主动认识客户嘅使用情况:有没有用?用得点样样?有全面推广起来吗?仲有第啲反馈吗?

    呢啲都要定期追踪,认识客户唔同层级嘅用户对新版本发布嘅新功能嘅想法,正向反馈负向反馈都好,都要有个交代。

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

    做好迭代管理,畀团队一粒糖

    我相信唔少成熟嘅团队必定有自己一套完善嘅版本管理方法,对于客户需求和产品能力嘅转化都系运筹帷幄,对此我要恭喜你。

    的确,同一个问题会有好多解题嘅思路,我从呢次嘅事件中也想通一个道理,噉就系点样去克制将问题简单化处理嘅冲动,避免陷入对观点做取舍嘅二元偏误里。

    喺对外和前线团队嘅持续沟通度,我清楚‌项目嘅百种唔易;喺对内和研发团队嘅共同作战度,我理解‌产品嘅所思所想。点样去平衡项目和产品,让项目驱动产品嘅提升,让产品更好地服务于项目,让原本若即若离嘅两拨人汇聚成一股更强劲嘅力量,呢是我从中体会最深嘅。

    我谂,捋完一遍思路后,我大概唔需要去学点样成为端水大师嘎啦。

    cantonese.live 足跡 粵字翻譯

  • 0
  • 0
  • 0
  • 157
  • 请登录之后再进行评论

    登录
  • 任务
  • 发布
  • 偏好设置
  • 单栏布局 侧栏位置: