1. 源由
很多时候,企业在需求分析的时候,经常出现所谓的需求不清,进而导致需求变更频繁,最后形成一种需求怪圈,结果就是开发周期长,产品不满足实际需求等。
为什么会这么卷,通常是这几个岗位职责在相互竞争、博弈:
- 市场销售:客户导向,用户需求描述
- 产品经理:产品导向,产品规格描述
- 开发人员:开发导向,技术规格描述
根源问题通常在于这些岗位上面的一个协调和统筹岗位,因为这个岗位无法很好的拉通:用户需求、产品规格、技术规格。
2. 分析
注1:大企业“卷”很正常,只要这个大轮子能滚动起来,效益还是会有的,只不过存在一些冗余人员而已。
注2:体系会解决很多问题,同时带来更多体系自身的问题。这个是另一个话题,我们侧重注重高绩效的微小型企业。
2.1 需求来源
大体上认为,有以下几个层级的产品需求:
- 系统级:由多个产品组成系统,完成某种功能。
- 产品级:单一产品或者标准化产品,完成某种功能。
- 模块级:标准化/规范化接口,完成部分功能,配套其他产品。
注3:一般只有大公司或者研发组织上规模的企业才会有解决方案,因此系统不是微小型企业考虑的主要产品需求。
虽然微小型企业的产品并非系统级的,但是当今社会是一个协作的社会,虽然产品不是系统级,但是产品运行在系统中,那就需要分析了。
接下来谈下需求的来源,通常来说:
- 用户需求:客户需要解决问题的综合归纳
- 市场需求:整个市场有类似客户需求的总和归纳
- 解决方案:解决市场需求拟给出系统级技术规格要求及功能定义
- 产品需求:解决解决方案拟给出产品级技术规格要求及功能定义
- 模块需求:解决产品需求拟给出模块级技术规格要求及功能定义
上面给出的需求递进关系适用于大部分需求分解过程,小系统或者单品产品,不需要这么复杂,可能就会弱化解决方案这个过程。
注4:这里重点突出用户需求,市场需求MRD不仅仅是客户需求,还有更多市场,行业方面的咨询,以及市场容量(存量、预期)等方面的信息。
2.2 需求博弈
- 市场销售:客户导向,用户需求描述 //市场人员对产品理解不深
- 产品经理:产品导向,产品规格描述 //产品经理对技术不熟悉
- 研发人员:开发导向,技术规格描述 //开发人员对研发理解片面
需求主要来源于市场,而市场销售人员通常更注重销售,签单业绩。外加当前社会人员流动变化很快,对产品应用的理解通常是不足的。
当产品经理,强调开发进度,缺乏对产品技术理解时,通常称为了所谓的"schdule PM",成为了所谓的团队“监工”,反而与开发团队距离更远。
研发人员只管门前“一亩三分地”,缺少了研究问题,解决问题的能力,尤其缺乏对整个产品研发以及团队协作概念时,尝尝使用一些技术壁垒来沟通技术需求。
2.3 关键问题
万事开头难,难在整体的把控和分析。不管是微小型企业或者是大企业,都需要对需求进行一个缩放的把控。
- “放”用户需求:将用户需求进行一个“放”的动作,尽量完备整理、归纳、记录。 //交付件,用户需求列表
- “放”市场需求:在相似用户群体上,进行一个“放”的动作,收集一个需求集体的用户需求。 //交付件,用户需求列表+客户
- “缩”解决方案:在市场需求基础上进行系统级规划,形成系统级技术需求:技术规格和功能定义。
- “缩”产品需求:在解决方案基础上进行产品级规划,形成产品级技术需求:技术规格和功能定义。
- “缩”模块需求:在产品需求基础上进行模块级规划,形成模块级技术需求:技术规格和功能定义。
注5:这里的“缩”就是层层收敛,突出重点,完成主要功能,满足技术规格。
而这件事情,有能力拉通处理的人就是至关重要的岗位,需要具备:
- 从用户角度思考,解决应用问题;
- 从业务角度考虑,领域涉及的用户体量、行业发展、竞争对手、完整的用户需求;
- 从技术角度考虑,整体方案和技术架构,进而进行系统级规格功能定义;
- 从产品/模块角度,对产品进行功能面的切割和定义;
综上所述,需要具备细致的研究、分析、解决问题的能力;具备行业领域信息和资源整合的经验;具有系统级顶层设计和产品分解能力;在产品面具备强有力的执行力和落地能力。
3. 实际情况
鉴于每个公司组织结构以及岗位职能的差异,不做过多的岗位抬头的解说。
微小型企业通常有一个比较显而易见的问题:缺乏资源
这个根源问题是否能够很好的解决,完全取决于老板。请注意,这里所谈到的“取决于老板”是指决策(用人,做事等)。
一件事情成功与否的重要因素在于以下几个点:
- 因果论是否明确?
- 资源是否充足?
- 时机是否切当?
为什么微小型企业能成功,无非是占了上述一些关键点:或许做足了功课,或许资源充足(砸出一个市场),或许碰到了好时机(只要风大,猪也能飞),或许或多或少兼而有之。
企业的成功并非易事,持续的成功更加难能可贵。
在这条道路上,无非是用好手中的资源,适时适地的增加不断成功的筹码,只有这样,企业才能不断发展。