极客视点
极客时间编辑部
极客时间编辑部
113241 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/04:51
登录|注册

以业务系统演化,看产品与开发的矛盾与统一

讲述:初明明大小:4.46M时长:04:51
罗贯中在《三国演义》中用一句“分久必合,合久必分”来概括近千年历史的兴衰。如果把这句话借用到业务系统演化过程中去,从产品经理和技术人员对业务理解的角度出发,描绘产品经理与技术人员的悲欢恩怨,也是适用的。
如何理解“也是适用”背后的含义呢?我们先从业务系统演化的几个阶段开始说起。
纵观软件系统的演化过程,基于软件系统的业务系统也随之进化。其进化过程大致表现为 3 个阶段:业务系统信息化时代、业务系统互联网化时代、业务系统社会化时代。
而业务系统的不断变化,对过去高效运作的业务架构和组织形式带来不小的冲击。如何在纷扰的变化中抓住主要矛盾,让业务系统适应新的环境以及平稳过渡呢?产品经理和技术人员对业务理解是关键一环,这使得我们对业务系统的开发产生了以下几点思考。

第一,传统软件开发模式下基于确定性的统一

在传统软件开发阶段,业务系统主要表现在把原来人工处理的流程信息化。这一时期的软件开发过程有个显著的特点,就是业务流程、职责和边界都比较明确。
传统软件开发阶段的业务系统开发过程,大体上遵循瀑布模型的方式实现业务需求。从开发过程的各个阶段来看,产品经理和开发人员的工作分工是比较清晰的。产品经理所扮演的角色是收集和分析需求、概要设计和详细设计以及协同沟通等;开发人员承担的工作则主要集中在编码,以及部分用例测试和发布上线等环节。
刨除瀑布模型自身的优缺点,由于经过了产品经理的归纳和整理,以及开发人员的工作仅仅是编写代码,则大体可以认为产品经理与开发人员对业务的逻辑与本质的理解是确定和一致的。也正是因为以上的情况,才把传统软件开发阶段的产品经理与开发人员的合作关系称之为基于确定性的统一。

第二,敏捷开发下存在分歧

当业务系统进入具有快速变化特点的互联网时代的同时,也对业务系统提出了更高的要求。新的环境下,人们逐步转移到敏捷开发的阵营上来。在敏捷开发的过程中,人们大多数把注意力放在了“快”上面,以至于认为能快速把流程跑通,能实现功能就是完成了业务系统。
另外,人们在 “迭代”和“重构”的理解上也开始出现偏差,“迭代”和“重构”逐步变成了肆意的调整需求。人们经常能看到开发人员无奈的眼神以及听到开发人员充满怨气的声音:什么?需求又变了。从此,江湖上开始流传起了产品经理与开发人员的恩怨故事。
究其原因,是因为敏捷开发在实施过程中出现了需求片面化的问题,造成了对业务蓝图缺乏全面的认识和理解。以至于在不同阶段和不同环境下,对同一需求的认知出现“横看成岭侧成峰”的现象,分歧也由之产生。

第三,面向业务系统社会化的融合

业务系统源自于社会现实世界,是对社会上已存在的业务流程和未来商业趋势的抽象与归纳。在业务系统社会化的环境下,为了快速应对多业务体系发展,业务系统应该具有融合、滋养和开放的特点。
社会化业务系统一个显著的特性就是,具有相似性的各商业逻辑已抽象成一个确定的业务内核,业务内核清楚地知道其在社会中的作用和地位。基于该业务内核派生出多种业务实例继承了该业务内核的基因,并在组合了各业务模块的基础上进行创新以提供不同的业务能力。
在这种情况下,拥有业务基因的业务内核具有确定的边界。产品经理和开发人员在此基础上相互配合,共同探讨业务本质以及自己对业务的理解,这样才有利于组织以业务为中心,群策群力,共同推进业务发展。
总而言之,争执源自于认知偏差。从产品经理与开发人员的恩怨故事来看,表面上是需求变更和长期以来双方矛盾积累导致的彼此不信任,更深层次的原因是无法框定业务背后的商业逻辑以及双方对业务本质的认知差异。
在业务系统演化过程中,如何抽象业务逻辑、沉淀领域模型、演绎出具有确定性的业务内核以及使产品经理与开发人员在业务内核的理解上趋于一致,最后在此基础下形成产品经理和开发人员融合与统一,是现在人们需要思考的重点。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 旭东(Frank)
    产品和研发是否对业务的认知在大的层面上一致是关键,Netflix的文化中让每个人都懂自己的业务,才能对公司发展做到真正的同心协力,群策群力。 研发不是对冲刺和迭代的需求变化抱怨,更多的是为了产品把自己的片面认识确定的传递给研发,而后又要研发来替他们买单,这才是真正的原因。解决这个问题需要产品尽力把需求挖出来,梳理好,整理通。如果产品做不到这一点,那就把这种不确定性传递给研发,寻求帮助和理解,达到群策群力,通力合作,共同努力解决。这样才能让研发更信任产品是在和研发一起解决问题,而不是找个背锅侠。 好多时候产品还忘了一点,研发有可能是你产品的第一波用户,如果他们对产品体验提出想法和建议一定认证对待。
    4
收起评论
大纲
固定大纲
第一,传统软件开发模式下基于确定性的统一
第二,敏捷开发下存在分歧
第三,面向业务系统社会化的融合
显示
设置
留言
1
收藏
22
沉浸
阅读
分享
手机端
快捷键
回顶部