【互联网产品助理的成长之路(1)】需求设计的大致流程及思考

一、挖掘需求

1.1 挖掘需求的途径

1.1.1 产品需求文档

  • 在产品需求列表中,找到需求的信息查看相应的需求内容以确定所要实现的场景和功能。

  • 同时在产品需求列表中也可以找到需求的提出人,可以通过和需求提出者的进一步沟通,来明确需求所发生的场景及需求所要实现的功能等信息。

协作工作管理→项目管理→项目需求列表

1.1.2 现场挖掘

现场挖掘需求需构建"场景洞察-数据量化-行为解析-闭环反馈-跨界创新"体系,通过热力图、实时仪表盘等工具捕捉用户行为与情绪,结合A/B测试与情感分析量化需求优先级,利用用户共创工作坊快速迭代原型,并跨界迁移游戏化、推荐算法等技术突破行业局限,最终实现从被动响应到主动创造的价值转变,驱动产品敏捷增长。

二、需求方案设计

2.1 需求任务的建立

在确定需求所要发生的场景后,开始建立需求设计的任务。

在建立的需求任务中,应当包含任务名称、所属组织、处理人、开始与截止时间、产品类别、产品特性等关键信息。

协作工作管理→平台管理→平台小组任务列表

2.2 需求功能设计文档的撰写

文档中一般包含如下关键信息:

  1. 基础信息:

    • 需求描述、需求来源、原始需求名称、所属模块、功能名称等;
  2. 功能设计:

    • 用例图、流程图、功能描述等;
  3. 设计要点:

    • 一般要着重强调设计的点;
  4. 功能点规划:

    • 根据用例图进行功能点规划;
  5. 风险项;

  6. 设计原型及说明:

    • 采用相应的原型设计工具,并且简要介绍图片的内容。

2.3 产品故事和计划的建立

通过需求功能设计文档,填写相应的业务需求(史诗)、用户需求(特性)、研发需求(故事)

  • **史诗:**指一个大型需求或功能集合,通常比较宏观和高层次。史诗是对一系列相关特性或用户故事的总称,代表了一个较大的目标或愿景。它们通常与项目的整体目标或战略相关联。史诗帮助团队更好地理解和规划需求,为项目提供整体的规划和方向。

  • **特性:**对史诗的进一步细化,是指一个较小的、具体的功能或需求。特性通常包含一组相关的用户故事,代表了用户所需要的一个具体功能或价值。特性是软件系统中可观察和可交付的一部分,它们被用来划分和组织开发工作,以实现史诗中设定的目标。

  • **故事:**对用户需求的一种简洁描述。它们从最终用户的角度描述系统的功能或行为,并用简短的句子来表达用户的期望和价值。

三、需求审查

3.1 组内审查

鉴于我们目前产品助理的初学者身份,若直接将设计完成的需求文档提交部门审核,极有可能因经验不足、考虑不周全等问题而被驳回。这不仅会打乱工作节奏,还会在一定程度上造成部门团队资源的浪费。所以,在初学阶段开展组内审查十分必要。

组内审查通常由我们的直接主管以及一至两名核心组员共同参与。在组内会议上,大家会针对需求文档中存在的问题展开讨论,并提出切实可行的修改建议,以便我们据此对文档进行修正。修正后的文档需再次接受组内审查,如此循环,直至通过组内审查标准,方可提交至部门进行最终审核。

3.2 部门审查

部门审查工作通常由产品人员、前后端开发人员以及测试人员共同开展。依据部门制定的规范流程进行审查,精准指出需求设计中存在的问题,并督促相关人员进行修改完善,直至符合交付标准,最终将通过审查的需求设计正式转入开发环节。

四、需求交付

通过审查的需求设计转入开发环节,开起需求开发阶段。

五、需求设计的自我思考

  • 如何快速了解需求所要实现的背景和功能。

    关键词:使用文档

    作为产品助理,或许难以在短时间内全面掌握产品的各项特性,但此时自学能力就显得尤为关键。具体而言,需学会在产品使用文档中精准检索需求关键词,深入理解其含义、功能及实现方式。通过先对需求形成初步认知,再将其与实际产品进行对照分析,从而明确需求的实现路径与设计思路。

  • 特性和故事主要由哪些部分。

    关键词:需求描述、验收标准、子需求

    一般包含需求描述、验收标准、子需求等部分。

    • 需求描述一般可以用如下格式进行书写:

      复制代码
      作为一名【用户类型】
      ​
      我希望【达成的目的】
      ​
      这样可以【开发的价值】
    • 验收标准一般包含如下部分:

      1. 前提条件;

      2. 界面元素;

      3. 界面交互;

      4. 数据说明;

      5. 异常情况;

      6. 国际化;

      7. ......

  • 优秀的产品故事和计划该如何撰写。

    关键词:规范化、细节描述

    1. 首先要注意产品故事和计划的编号问题,一般产品故事可以使用日期 进行编号,而产品故事一般需要用**"产品代码_版本号_所属模块代码_序号"**组成。通过规范的编号,有助于我们和团队对相关故事和计划的更好定位。

    2. 需求描述 部分一般追求简单,用一句话表面我的需求即可。但在验收标准部分,要追求细致,要说出每个界面各个组件的含义、功能、所调用的信息等等。

    3. 对于页面交互部分,只有流程图是完全不够的。流程图只是在宏观上讲述了交互的过程,但在细节上的讲述并不充分。因此要通过语言对交互的过程进行更细致的讲述(怎么操作、有什么效果等等)。

  • 搜索框执行"重置"操作一般所达成的效果。

    关键词:重置

    搜索框重置一般要实现搜索条件和搜索结果的重置。但若有特殊要求,也可以只对搜索条件进行重置,对搜索结果予以保留。

  • 企业工作与学校学习的差距。

    关键词:务实、高效

    在学校课程作业设计中,我们常被鼓励详尽阐述内容,通过细致入微的描述来展现深度与思考,以此争取更优异的成绩。这种训练模式无形中塑造了一种思维定式:内容越详尽、表述越清晰、篇幅越长,似乎就越能赢得认可与高分。因此,在完成课程作业时,我逐渐养成了长篇大论的习惯,力求通过丰富的细节和全面的分析来展现自己的理解与见解。

    然而,实习经历让我深刻意识到,长篇大论并非总是最佳选择。在实际工作中,过长的文字描述往往会增加沟通成本,使接收信息的一方在面对海量文字时感到疲惫不堪,反而可能削弱信息的传达效果。因此,高效沟通成为职场必备技能,学会用简短精炼的语言准确表达意图,显得尤为重要。

    同样,在学校学习期间,绘制UML图表时我也倾向于追求极致的细节,试图通过详尽的图表展示来全面覆盖知识点。但实习中我发现,过于复杂的图表不仅会增加阅读难度,还可能偏离了图表本身旨在清晰传达信息的初衷。实际上,简洁明了的图形往往更能直击要害,有效传达核心信息,而非通过堆砌图标来达到"炫技"的目的。

    实习生活教会了我务实与高效的重要性。只有摒弃冗余,聚焦核心,才能减少非必要的劳动时间,提升个人工作的实际效益。在未来的职业生涯中,我将更加注重信息的精炼与表达的高效,以实际行动践行这一理念。

相关推荐
孟健2 天前
为什么你的 AI 产品总是做不起来?90%的人忽略了这两个底层模型
产品经理·创业
华洛3 天前
AI产品发展必经之路: 从售卖工具到售卖解决方案
产品经理·产品·资讯
自友智慧校园4 天前
智慧校园建设怎么选?性价比评估就看这三点
产品经理·产品·资讯
自友智慧校园4 天前
职业院校智慧校园招投标文件编制的关键要点分析
产品经理·产品·资讯
自友智慧校园5 天前
奖学金申请不再繁琐 学工系统让线上申请变得更简单
产品经理·产品·资讯
自友智慧校园5 天前
职业院校智慧校园建设:一条切实可行的低成本高效益之路
产品经理·产品·资讯
自友智慧校园6 天前
智慧校园建设预算执行情况分析:如何科学应对偏差与调整
产品经理·产品·资讯
华洛6 天前
聊一下如何稳定的控制大模型的输出格式
前端·产品经理·ai编程
自友智慧校园7 天前
智慧校园建设:职业院校如何科学评估应用效果
产品经理·产品·资讯