关于产品/模块需求的博弈

本文探讨了企业在需求分析过程中存在的问题,特别是微小型企业在系统级、产品级和模块级需求之间的博弈。强调了用户需求、市场导向与技术规格的平衡,以及协调岗位的重要性,提出通过‘放’用户需求和‘缩’解决方案来有效管理需求的关键方法。

1. 源由

很多时候,企业在需求分析的时候,经常出现所谓的需求不清,进而导致需求变更频繁,最后形成一种需求怪圈,结果就是开发周期长,产品不满足实际需求等。

为什么会这么卷,通常是这几个岗位职责在相互竞争、博弈:

  • 市场销售:客户导向,用户需求描述
  • 产品经理:产品导向,产品规格描述
  • 开发人员:开发导向,技术规格描述

根源问题通常在于这些岗位上面的一个协调和统筹岗位,因为这个岗位无法很好的拉通:用户需求、产品规格、技术规格。

2. 分析

注1:大企业“卷”很正常,只要这个大轮子能滚动起来,效益还是会有的,只不过存在一些冗余人员而已。
注2:体系会解决很多问题,同时带来更多体系自身的问题。这个是另一个话题,我们侧重注重高绩效的微小型企业。

2.1 需求来源

大体上认为,有以下几个层级的产品需求:

  1. 系统级:由多个产品组成系统,完成某种功能。
  2. 产品级:单一产品或者标准化产品,完成某种功能。
  3. 模块级:标准化/规范化接口,完成部分功能,配套其他产品。

注3:一般只有大公司或者研发组织上规模的企业才会有解决方案,因此系统不是微小型企业考虑的主要产品需求。

虽然微小型企业的产品并非系统级的,但是当今社会是一个协作的社会,虽然产品不是系统级,但是产品运行在系统中,那就需要分析了。

接下来谈下需求的来源,通常来说:

  1. 用户需求:客户需要解决问题的综合归纳
  2. 市场需求:整个市场有类似客户需求的总和归纳
  3. 解决方案:解决市场需求拟给出系统级技术规格要求及功能定义
  4. 产品需求:解决解决方案拟给出产品级技术规格要求及功能定义
  5. 模块需求:解决产品需求拟给出模块级技术规格要求及功能定义

上面给出的需求递进关系适用于大部分需求分解过程,小系统或者单品产品,不需要这么复杂,可能就会弱化解决方案这个过程。

注4:这里重点突出用户需求,市场需求MRD不仅仅是客户需求,还有更多市场,行业方面的咨询,以及市场容量(存量、预期)等方面的信息。

2.2 需求博弈

  • 市场销售:客户导向,用户需求描述 //市场人员对产品理解不深
  • 产品经理:产品导向,产品规格描述 //产品经理对技术不熟悉
  • 研发人员:开发导向,技术规格描述 //开发人员对研发理解片面

需求主要来源于市场,而市场销售人员通常更注重销售,签单业绩。外加当前社会人员流动变化很快,对产品应用的理解通常是不足的。
当产品经理,强调开发进度,缺乏对产品技术理解时,通常称为了所谓的"schdule PM",成为了所谓的团队“监工”,反而与开发团队距离更远。
研发人员只管门前“一亩三分地”,缺少了研究问题,解决问题的能力,尤其缺乏对整个产品研发以及团队协作概念时,尝尝使用一些技术壁垒来沟通技术需求。

2.3 关键问题

万事开头难,难在整体的把控和分析。不管是微小型企业或者是大企业,都需要对需求进行一个缩放的把控。

  1. “放”用户需求:将用户需求进行一个“放”的动作,尽量完备整理、归纳、记录。 //交付件,用户需求列表
  2. “放”市场需求:在相似用户群体上,进行一个“放”的动作,收集一个需求集体的用户需求。 //交付件,用户需求列表+客户
  3. “缩”解决方案:在市场需求基础上进行系统级规划,形成系统级技术需求:技术规格和功能定义。
  4. “缩”产品需求:在解决方案基础上进行产品级规划,形成产品级技术需求:技术规格和功能定义。
  5. “缩”模块需求:在产品需求基础上进行模块级规划,形成模块级技术需求:技术规格和功能定义。

注5:这里的“缩”就是层层收敛,突出重点,完成主要功能,满足技术规格。

而这件事情,有能力拉通处理的人就是至关重要的岗位,需要具备:

  1. 从用户角度思考,解决应用问题;
  2. 从业务角度考虑,领域涉及的用户体量、行业发展、竞争对手、完整的用户需求;
  3. 从技术角度考虑,整体方案和技术架构,进而进行系统级规格功能定义;
  4. 从产品/模块角度,对产品进行功能面的切割和定义;

综上所述,需要具备细致的研究、分析、解决问题的能力;具备行业领域信息和资源整合的经验;具有系统级顶层设计和产品分解能力;在产品面具备强有力的执行力和落地能力。

3. 实际情况

鉴于每个公司组织结构以及岗位职能的差异,不做过多的岗位抬头的解说。

微小型企业通常有一个比较显而易见的问题:缺乏资源

这个根源问题是否能够很好的解决,完全取决于老板。请注意,这里所谈到的“取决于老板”是指决策(用人,做事等)。

一件事情成功与否的重要因素在于以下几个点:

  1. 因果论是否明确?
  2. 资源是否充足?
  3. 时机是否切当?

为什么微小型企业能成功,无非是占了上述一些关键点:或许做足了功课,或许资源充足(砸出一个市场),或许碰到了好时机(只要风大,猪也能飞),或许或多或少兼而有之。

企业的成功并非易事,持续的成功更加难能可贵。

在这条道路上,无非是用好手中的资源,适时适地的增加不断成功的筹码,只有这样,企业才能不断发展。

内容概要:本文系统阐述了Java Persistence API(JPA)的核心概念、技术架构、核心组及实践应用,重点介绍了JPA作为Java官方定义的对象关系映射(ORM)规范,如何通过实体类、EntityManager、JPQL和persistence.xml配置文实现Java对象与数据库表之间的映射与操作。文章详细说明了JPA解决的传统JDBC开发痛点,如代码冗余、对象映射繁琐、跨数据库兼容性差等问题,并解析了JPA与Hibernate、EclipseLink等实现框架的关系。同时提供了基于Hibernate和MySQL的完整实践案例,涵盖Maven依赖配置、实体类定义、CRUD操作实现等关键步骤,并列举了常用JPA注解及其用途。最后总结了JPA的标准化优势、开发效率提升能力及在Spring生态中的延伸应用。 适合人群:具备一定Java基础,熟悉基本数据库操作,工作1-3年的后端开发人员或正在学习ORM技术的中开发者。 使用场景及目标:①理解JPA作为ORM规范的核心原理与组协作机制;②掌握基于JPA+Hibernate进行数据库操作的开发流程;③为技术选型、团队培训或向Spring Data JPA过渡提供理论与实践基础。 阅读建议:此资源以理论结合实践的方式讲解JPA,建议读者在学习过程中同步搭建环境,动手实现文中示例代码,重点关注EntityManager的使用、JPQL语法特点以及注解配置规则,从而深入理解JPA的设计思想与工程价值。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值