专栏首页物流IT圈产品研发组织的三个顽疾及破解

产品研发组织的三个顽疾及破解

本文起源于一次部门周例会,在这次例会中,我们可爱的产品经理和研发经理,在工作汇报过程中,清晰地“演示”了互联网公司中产品研发工作的常见问题,也是严重且根深蒂固的三个问题。

本文通过对这几个问题的探讨,希望能对今后的工作有所启发和指导。针对每个问题,通过四步阐述:现象(问题表象)、导致(的后果)、分析(原因)、建议(方案)。

技术架构边界不清导致复杂性和风险性

现象

l 变更很小但与许多场景关联,需要大量人工回归测试。

l 变更很小但业务逻辑纠缠在一起导致代码很复杂,难于修改和判断正确性,需要大量时间且风险很高,建议重写代码。

l 系统功能经常因依赖系统/模块问题导致不工作,且不能降级提供服务 和 直观定位问题,立即告诉使用方问题原因和建议行为,或者立即通知系统方发生什么故障,指导人工干预。

导致

复杂性导致小变更需要慢修改和大测试,工作受困于技术的历史负债,无法轻装上阵,严重降低研发团队的生产率和产品质量。

系统故障无论是系统自身引起还是依赖服务引起,用户都会认为是所用系统的问题,时常要为依赖服务的故障背锅。当然事后解释有些用处,但总是太被动且效果有限。

分析

这些问题的直观原因就是代码复杂,代码复杂的直观原因就是各类元素多、元素之间的关系多、代码行多,要知道普通人舒服处理要素的数量在3~7个,更多就会蒙圈。

元素及关系多因为没有很好地抽象和封装为高内聚低耦合的模块/组件/对象/服务等。另外一种常见原因就是思考问题的方法和模型不当。傅盛说过:复杂性往往来自高维简单问题到低维的映射。举个例子是以地球为中心,太阳系各个行星的轨迹很复杂,如果以太阳为中心,轨迹简单明了。

另一个问题是回归测试需要投入大量人工进行,正确做法是通过积累自动化测试案例,保障回归测试自动进行。不过要做好自动化回归测试同样依赖一个好的设计,便于测试案例针对接口契约进行。

建议

解决复杂性并不容易,软件架构与设计是一个很专业和很庞大的领域,这里简单提一些方法。

如何才能减少系统元素数量?通过抽象技术和封装技术,隐藏复杂性到组件之内,组件通过稳定的接口契约交互,而不用关心接口内的行为(组件边界内部的实现行为);通过分层技术,可以逐层进行封装,逐步逐层把大系统复杂性限制在可控范围内。

抽象及封装技术不仅仅是降低复杂度,更是组件/服务独自演进的基础,边界清楚了就能各自行动,纠缠在一起大家谁都动不了。

系统边界要隔离,弄一个防护的安全地带,依赖的系统外服务出了问题,要及时能监控到、把故障隔离到局部范围、避免连带问题、能进行降级服务。

自动化回归测试是很重要的手段,核心还不是自动化测试工具,而是积累足够多、覆盖完全的自动化测试案例,它保护对系统的修改没有引起新问题。

工作边界不清导致大量串行和同步工作

现象

l 其他团队没有空档能配合我们排期,暂停当前的需求设计开发等工作。

l 缺少配套要素支持工作开展,如设备没到位则不上线,测试环境不具备则不验证等。

l 业务方还没有提交我们需求文档,后续工作还没法开展。

l 研发都在忙于某某项目,没时间开发这个需求,所以没有对这个需求进行详细设计。

导致

被依赖工作不能开展阻碍依赖的工作的开展,相互依赖的各方越多,互相阻碍的概率越大,影响也越大。

此时,更多的合作伙伴没有成为工作的加速器,反而成为工作的障碍。

串行方式在上游工作未完成之前,阻碍下游工作开展;同步工作在任意一方没有准备好则无法开展。这两种类型的工作比较多时,会大幅度降低资源利用率和灵活性,进一步影响效率、工期、成本等。

从精力管理视角来看,这会干扰甚至打乱自己和团队的工作节奏,节奏不整齐,效率自然低。

分析

这些问题是由上游、下游、供应商、同级伙伴、所需资源之间的依赖性导致。实际上依赖是天然存在的,否则大家就没关系了,实际做的方法是降低依赖程度。

互联网公司出现此问题更多是组织管理问题,主要情景有:

l 事情很多做不完,既然有好理由放一放就先忙那些推脱不掉的事情。

l 自己先行做完自己的事情后,其他事情后续未必跟的上来,这样白白浪费自己工作,毕竟互联网公司的很多需求一旦停下来就可能永远没机会再做了。

l 边界的定义未必到位,基于定义的边界先行开展工作,后期难免要修改,浪费自己精力。

l 还有些工作,双方都认为应该对方做更好,这样子谁先做工作就有更大可能承担那些模糊地带的工作。

建议

降低依赖的重要方法还是界定清楚边界,大家按照之间的约定完成各自工作,然后交由下游或者需求方,降低自己工作节奏受外部因素的影响。例如产品经理的输出是经过评审的产品需求文档,无关目前是否有研发开发;测试人员设计测试案例的输入是需求文档、输出是测试案例,不需要系统已经开发完成;开发工作按照接口完成和验证,无需其他相关模块是否完成。

降低依赖的另一个方法是拆分工作,依赖程度不同的部分拆分开来,那些不依赖的部分就可以先做起来,例如设计的/干活的/检查的/签字的等分开。

以“巧妇难为无米之炊”为例,没有米时也可以先把锅、水、柴等准备好。没有足够的生产机器就可以先部署在少量机器上,进行试用、支持早期少量业务,业务量提高后再进行扩容。即使业务方没有提交需求,产品也可以基于理解做部分产品设计,业务方提交需求后再进行补充修正。

业务流程优化的许多方法有助于依赖降低,有许多这方面的资料,从流程视角看,尽可能缩短关键路径,减少那些串行和同步进行的工作,增加独立的自由开展的工作。工作之间关系不应该是串行和同步,而是叠加和轮动。

如果是组织管理导致的问题,由于合理原因和不合理原因都可能存在(借口推脱和怕浪费自己工作两种情况更常见),管理者需要清楚实际缘由,针对性应对,不能简单地统一处理。如果是借口,指导团队降低依赖性让工作正常开展。

工作缺少规划和重点,开展起来忙闲不均、效率低下

现象

l 对业务方(上游)需求以被动响应式方式接收,也就是完全由业务方提需求、提啥就是啥、不提就没有。

l 开展哪些重点工作由业务方(上游)要求什么决定,也就是工作重点挑选完全由业务主导。

l 工作的节奏主要由(上游)给予的压力决定。也就是工作的紧急程度完全由业务方说了算。

导致

产品团队不能主动挖掘、引导、完善合理需求,以及难以拒绝不合理需求。

难以在业务方要求基础上,主动结合产品规划、演进路线、需求关联关系、技术难度、开发工作量、割接风险等对业务方进行影响,做出更合理的建设计划和步调。由于接收的需求都是眼前要做的,很少有机会从一大堆中挑选更合适的去做。

业务方催的紧就忙死,催的不紧就闲会,这种重点失衡、节奏失衡自然导致效率低下。

分析

被动响应式的工作基本上是"脚踩西瓜皮、滑到哪里算哪里",也就不会有什么清晰的整体规划和有效的中长期工作计划。

实际工作中总会有做不完的需求,不会无事可做。但整体规划和重点工作挑选的不足,会严重影响工作的组织安排。可能工作特别忙但没有做到重点,导致最终结果(绩效)一般。可能工作不怎么忙,所做事情重要性也不够,结果就更糟糕。多数情况下,会有选择地做“重点”需求,拒绝一部分“不重要”需求。但由于整体规划和重点内容缺乏且达成共识,本能的择优缺乏有效支撑,准确度有限,总体效率自然也就低了。另外,这种情况下需求方频繁感受到的是"被拒绝",抱怨自然难免。

缺少整体规划必然缺少重点,重点是从整体工作或一组工作中挑选出来的,缺乏整体就难以有效地挑选重点。

陷入日常的琐碎需求,就缺少大块时间和充分准备(紧急事务会撕碎大块时间),解决那些高难度的重要问题和重点需求,业绩自然就不会好;日常琐碎需求,数量繁多导致思考和准备仓促,风险和故障却并不见少。

业务方由于缺乏对技术的深入理解和关注,所提要求不会结合技术实际情况。虽然双方均难于成为对方领域专家,但业务人员理解技术相对技术人员理解业务更困难一些。缺少对产品建设理解的业务方,提出的要求必然具有不合理成分,无法让双发利益最大化。

建议

业务团队和研发团队本质关系还是甲方和乙方的关系。如果定位错误,例如是平等关系、业务方有求于研发团队,后续的一系列工作都会出现问题。但在一个公司内部,清晰做出恰当定位且能有效贯彻执行动作不变形,其实并不容易,毕竟人性使然。

看看业界这种关系乙方都是怎么做的:

l 主动、深入理解甲方(业务方)需求(否则凭啥让你干),深入挖掘甲方进一步需求(不能做完一单就丢了)。

l 维护好双方关系,腿要快、嘴要甜、脑要灵、能自己干的就不要麻烦对方,能替对方干的就不要对方自己干(拓展服务内容)。

l 不刷滑头但要聪明做事,收钱时不要手软。

公司内部业务方和研发团队不是市场上的甲方乙方。基本规则还是乙方服务要专业,甲方回报要足够。研发团队的专业性表现在洞察业务需求、主动积极服务、维护良好关系;业务团队的回报足够体现在充分配合研发工作、努力争取研发资源、积极宣扬研发工作价值。

研发团队能力成熟度重要标识是:与业务方一起建立产品整体规划和重点事项,能在多长时间内让实际工作内容与规划内容保持一致,当然是时间更长更一致的能力更高。

最后再多唠叨一句:坚持“要事第一”的原则。此原则顺利执行的前提是具备全局观和前瞻性,否则就无法从一堆事中挑选出重要的事。

本文分享自微信公众号 - 物流IT圈(exiter18),作者:B端产品论坛

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Map集合比较本来需要10行代码的,现在只需要1行搞定太高效了

    业务场景:如2个城市集合 code:cityName,你需要计算他们的交集、左集、右集

    物流IT圈
  • 针对B端产品,如何顺利开展workshop?

    各位B端产品/需求分析的同学一定对workshop这个名词不陌生,它的中文名是需求访谈会。个人对C端产品不熟,本文也仅就B端产品的访谈聊一聊个人经验。本文适合0...

    物流IT圈
  • 使用消息系统集成和扩展微服务

      服务之间交互的风格有两种:同步和异步。所谓同步交互,服务调用者会发出一个调用请求,并且堵塞等到操作完成得到响应,HTTP协议是一个很好的同步交互案例,通常是...

    物流IT圈
  • protobuf使用简介

    环境:windows,java 1. protobuf概述 protobuf是Google开发一种数据描述格式,能够将结构化数据序列化,可用于数据存储,通...

    2Simple
  • 业务分析模型,该怎么搭建

    很多同学最怕听“建模型”仨字。尤其是建立“业务分析模型”。往往自己辛辛苦苦搞得LR、SVM、CNN被业务方狂喷:你这都是啥东西!脱离业务!不切实际!所以到底什么...

    接地气的陈老师
  • 面试|大数据中无处不在的ServiceLoader

    ServiceLoader是SPI的是一种实现,所谓SPI,即Service Provider Interface,用于一些服务提供给第三方实现或者扩展,可以增...

    Spark学习技巧
  • 手把手带你抓取智联招聘的“数据分析师”岗位!

    很多网友在后台跟我留言,是否可以分享一些爬虫相关的文章,我便提供了我以前写过的爬虫文章的链接(如下链接所示),大家如果感兴趣的话也可以去看一看哦。在本文中,我将...

    1480
  • 聊聊数据库范式

    最近给新员工做了一次数据库基础的培训,其中涉及个主题,就是数据库范式,从理论层面讲,数据库会包含第一范式、第二范式、第三范式、BC范式、第四范式、第五范式等,但...

    bisal
  • 技术 | Python从零开始系列连载(二十八)

    之前我水平有限,对于淘宝评论这种动态网页,由于数据在网页源码中是找不到的,所以无法抓取数据,只能使用selenium模仿人操控浏览器来抓数据,

    灯塔大数据
  • Spring Boot国际化支持

    国际化支持应该是所有的做国际化网站都需要考虑的一个问题,Spring Boot为国际化提供了强有力的支持,本文将会通过一个例子来讲解Spring Boot的国际...

    程序那些事

扫码关注云+社区

领取腾讯云代金券