G端产品人技能(一):项目制的产品的工作流程

0 评论 2097 浏览 8 收藏 13 分钟

G端产品的工作流程和B端、C端还是有一定得差异。比如正文作者分享的这种零散性需求,其流程和方法,都与大家认知的有很多不同。

在G端项目中,根据项目需求的大小、复杂度和涉及对象的不同,往往可以大致划分为几种不同的类型。

新项目:需重新搭建并规划产品

如政府部门的全新电子政务系统、大型企业的ERP(企业资源计划)系统建设等。这类项目通常是从零开始,需要进行全面的市场调研、需求分析、产品规划、系统设计、开发实施及后期运维等全链条工作,并伴随着长期的战略规划,其中的技术选型、架构设计、未来扩展性等都需要考虑长远。在系统的搭建上,可能需要跨部门、跨团队甚至跨公司的紧密合作,包括项目管理、产品设计、开发、测试、运维等多个环节。

针对政策的新模块需求或零散性需求,涉及不同公司负责的不同模块

如税务系统的年度更新、社保政策的调整导致的相关系统模块升级等。这类需求往往由政策变化或新政策出台引起,需要快速响应并调整现有系统,需求可能以模块化的形式出现,每个模块可能由不同的公司或团队负责,需要高效的接口对接和协同工作,且系统需要具备一定的灵活性,以便快速适应政策变化带来的需求调整。

针对后台或前端的零散需求或自用需求,只涉及自己公司的开发内容

如公司内部OA(办公自动化)系统的功能优化改进等。这类需求通常来源于公司内部用户或特定业务部门的直接需求,不涉及外部合作。往往要求快速响应和迭代,以满足业务发展的需要。可能更注重提升系统性能、优化用户界面使用效果等。

本文主要介绍第2种,针对新需求涉及到不同公司负责不同模块,其中第3种需求其实也包含在第2种需求中,属于最为简单的一类,此处我将会后续主要的流程及能力做个罗列,并且后续内容将围绕展开:

  1. 需求了解
  2. 需求前期边界沟通
  3. 了解接口文档
  4. 业务流程串联及原型输出

一、需求了解

通常,G端项目产品的模块新需求会有2种形式文件下达。

  1. 政策文件及上级负责人(或者业主)的主需求信息
  2. 具体的功能文档

但无论是哪种需求,本质都要求产品经理拥有快速高效理解文档的能力,此处针对不同的文档需求进一步讲述理解思路。

对于政策文件

  • 宏观把握,明确背景:仔细阅读政策文件,理解政策出台的背景、目的和预期效果。这有助于把握整个项目的宏观方向,确保产品设计符合国家或地方的政策导向。
  • 提炼关键信息:从政策文件中提炼出与本次产品模块更新直接相关的关键信息,如需要解决的问题、期望达到的目标、优先级等。这些信息将是后续需求分析和产品设计的核心依据。
  • 沟通确认:与上级负责人或业主进行深入沟通,确保对政策文件的理解准确无误,并进一步明确他们的具体需求和期望。通过面对面的交流,可以捕捉到文字之外的意图和关注点。
  • 需求分解与细化:将提炼出的关键信息进一步分解为具体的需求点,并考虑如何在产品中实现这些需求。这包括功能设计、界面布局、交互流程等多个方面。

特别要注意的点,阅读这件事也是需要一定积累的,想要快速读懂提炼有效信息,不要忘记日常的积累,也能够帮助快速理解自己所在的行业。

具体的功能文档

如果是明确的文档内容要求,几乎所有的功能需求,文档都有记录。所做重点就是全面阅读,理解框架,对关键的功能点、约束条件、技术要求等进行重点标注,同时梳理功能之间的逻辑关系。需要注意尝试从用户的角度出发,模拟使用场景,思考这些功能如何满足用户的需求和期望,并且从自己的角度出发,考虑是否有缺失情况,若有的话,可以及时和对方沟通或者做好内部反馈。

在理解功能需求的基础上,评估实现这些功能所需的技术难度和资源投入。同时,规划出合理的实现路径和时间表。

二、需求前期沟通边界

文档需求内容理解后,整理该需求所涉及的功能清单,为防止不同团队/企业之间的任务责任不清晰,事先进行需求沟通边界确认非常重要。

功能清单整理及内部梳理

在文档需求内容理解透彻后,产品经理整理出一份详尽的功能清单,清单包含所有需求点,以及每个需求点对应的功能描述、预期效果、优先级等信息。针对此清单组织内部会议(包括项目经理或熟悉技术的同事),对功能清单进行逐一讨论。重点分析每个功能的实现难度、技术可行性、资源需求等要点。同时,识别出哪些功能是其他公司负责的内容,哪些是需要自行开发的。

多方协作与边界确认

内部梳理完成后,产品经理应准备一份详细的沟通材料,包括功能清单、责任划分初步建议、可能的合作方式等。同时,邀请G端技术负责人共同参与其他公司技术人员的会议,再次确定彼此直接负责的事情,并处理会议过程中的疑议,对于难以达成一致的问题,可以记录下来,会后进一步研究和讨论,直至找到满意的解决方案。

为了确保合作过程中各方都能遵守既定的责任划分,明确记录各方负责的功能模块、时间节点、质量标准等关键信息,以便在后续工作中作为参考和依据。

在需求沟通前期多公司合作的项目中,确定不同公司负责的内容事项,此过程非常重要,整体沟通范围可由大到小直至实现,防止边界不清晰,导致后期实现效果有出入,彼此之间扯皮的情况发生。

三、了解接口文档

如医保系统中,公共服务部分与省份后台经办系统可能是不同公司承办的,每个公司可能只是负责某一个模块的设计。在彼此边界沟通清楚后,可能负责其他模块的对方公司会开始设计自己的接口文档,而我们所对接的模块又需要对方进行对齐,以免自己设计的原型最终实现上对方接口不支持,这样会导致后续反复修改的问题。

正因此就要求产品经理拥有阅读接口文档的能力,能够在已有的框架里,针对接口文档中的出参入参提炼出自己能获取的字段,进行串联业务流程和用户体验。

在接口文档查看之前,产品需要在前面的需求背景下,在不考虑接口文档文档的情况下进行设计字段排布构思,想好自己需要哪些字段进行展示,并通过对比接口文档的字段,取出需要展示接口字段。梳理设计思考,是因为有时候接口文档不一定符合我们的的设计需求,这时候可以提出质疑,要求对方补充。同样的,自己设计的时候,很有可能对这个业务其实理解不足够,这时候,接口可以用来查缺补漏。并针对已经梳理好的最终字段,串联流程后,产出原型。

对于接口的查看方式,可以关注以下几点:

  1. 关注必填字段及出入参
  2. 一般InDto为入参(具体可以询问开发,不同的开发或许有不同的命名方式),可以用来设计筛选,因此在原型设计的时候,要对比下自己设计的原型筛选字段接口是否能支持
  3. 一般PutDto为出参(具体可以询问开发,不同的开发或许有不同的命名方式),可以用来设计页面展示字段,比如查询之后,出现哪些字段。

此处对于接口查看方式的描述较为简单,但是个人感觉基本简单的字段查看是足够的,如果想要深入了解,建议阅读一些更为专业的文档进行知识补充。

四、业务流程串联及原型输出

本质上,业务流程串联流能力,更多的是指对业务的理解能力,对需求中的业务理解透彻之后,就能把所需的页面字段之类的进行串联,将通过接口文档和需求文档得出的字段页面进行梳理,每个页面能能串起来,实现业务上的逻辑完整性。

在进行流程串联后,将所有的流程和字段进行梳理并绘制原型,原型绘制完成后,先行检查每个逻辑完整性,是否实现闭环,后续原型经由业主确认无误后,进行内部评审,此处业主的确认很重要,得到业主的认可,意味项目不会偏离主要需求,同时后续若有相关需要调整的内容,需要其他公司配合,也能从中得到周转协调。业主确认后,进行内部评审,评审完成后,算是进入排期开发阶段。

总结

原型输出评审后,还会有开发跟进,也许跟进过程中会面临不同的需求调整,需要及时的做好版本记录并及时更新原型,G端项目制的产品,如果只做项目的话,很多公司可能会开发直接绕过,直接自己修改字段,做好原型记录,做好验收,做到细节心中有,可以提升自己的产品专业度,遇到不懂的别人也会第一时间询问自己,不容易被当背景板,但是具体的产品定位和自己想做的产品目标,也是每个项目制产品值得去思考的。

本文由 @小熊不是尼不昵 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!