程序员大赛投票网站-需求评审的各个方面,教你如何做好评审

在产品总监的日常工作中,需求评审是非常重要的环节之一。 通过需求评审,产品总监可以及早规避风险和问题,减少可能的资源浪费。 我们怎样才能更好地审查这些需求? 需要注意哪些维度? 本文作者谈了自己的想法,我们来看看。

之前,笔者和大家聊过如何写一篇优秀的PRD(【万字】PRD看点,我来指导你写一篇优秀的PRD)。

写完PRD后,最重要的是组织评审。

根据实际情况,如公司要求或不确定因素,可以在组织即将审核之前启动需求审核。

1、需求审核

进行需求审计有很多用途。 问题越早暴露,造成的影响和纠正成本就越小。 这时候只有产品总监投入了时间和精力,产品审核可以有效防止设计资源的浪费和需求评审时的争论

1.邀请对象 2.邀请方案

提前预约,发送会议邀请函,总结评审主要内容并附上评审所用的PRD文件。

如果有不确定或可能有争议的点,可以在邀请函中注明,让参加者提前做好计划。

大多数情况下,参与者不会阅读你的邀请内容和PRD,所以提前找关键朋友讨论并就主要问题达成一致。

例如,可以与产品负责人或业务方讨论某个产品功能是否能够满足用户和业务需求; 可以与UX设计师沟通页面跳转、导航的合理设计; 可以找相关技术朋友咨询。

审核前充分的准备工作可以提高沟通效率,节省与会人员的时间,防止因重大问题返工而重复召开审核会议。

三、评价方法

做审计的时候程序员大赛投票网站,最基本的要求就是沟通和表达的能力。 说话要能说清楚,注意放慢语速(人紧张的时候很容易提高语速),陈述逻辑清晰,使用内部交流语言(同编写 PRD Require 时)。

请熟悉文档的朋友帮你记录会议记录,包括:

评审过程中,鼓励和引导参会人员发言,充分收集各方意见和建议。 尊重每个参与者的意见,无论这可能为时过早。 您应当善意肯定对方的建议,表达自己的观点,并与对方达成协议。

但也要注意控制时间。 一旦出现激烈争论或短时间内没有结果的观点,应及时打断、跳过,防止无休止的争论,浪费时间。

在善意的情况下,不应出现激烈争论的问题。 此时你必须进行会后反思:

会议结束后无需发送会议纪要。 一方面,这是对参与者的尊重。 你们的意见我都收到了。 另一面是二次确认,防止以后可能出现的搪塞。

根据会议纪要更新PRD后,记得再次发送以供确认。

2、关于UED设计

如果需求比较简单或者您对自己的PRD比较有信心,可以提交UED设计需求。

在人力充足的公司,UX设计会由专业的交互设计师来进行; 而在人手不足的情况下,产品总监会兼职交互设计师。

在目前各种交互设计规范都比较成熟的情况下(如iOS人机交互手册、MaterialDesign、AntDesign等),实现合格的交互设计是相对容易的。

UX完成之后,就是UI设计了。 对于UI设计,建议让专业的UI设计师兼任,尤其是用户界面。 一个好的设计师对于用户体验起着至关重要的作用。

给菜鸟产品总监的几点建议:

UX和UI完成后,必须仔细进行初步检查。 初步检查点包括:

对于界面设计风格,除非你有很强的把握,否则尽量不要和设计师争论,因为很容易让设计师批评他的专业性或者觉得你什么都不懂。 虽然要争论,但态度一定要和善,有理有据,不要无理取闹。

3、需求审核

当设计草案得到确认后,激动人心的需求审查就可以开始了。 需求评审的主要思路与需求审计相同,下面主要描述需要额外注意的事项。

虽然已经进行了设计评审,但是评审期间必须完成完整的评审,因为很多新朋友都会参加会议。

1.邀请对象 2.邀请方案

会议邀请函应将 PRD、UX 和 UI 一起发送给与会者。

会前记得和关键朋友,比如技术骨干、业务方等,就PRD、UX、UI进行交流。 会议的顺利进行是建立在会前充分沟通的基础上的。 需求评审会议最重要的作用是达成共识而不是讨论。

三、评价方法

还需要使用自己的沟通方式,让参与者听得清楚、听得懂,防止开发过程中问题暴露出来,造成延误风险和开发资源的浪费。

还需要邀请朋友做会议记录,不仅要记录关键的事情,还要记录时间和负责人。 例如,对于一个有争议的需求,需要指定负责确认需求的人以及何时确认解决方案。

在具体的审核过程中,也有一些方法与大家分享。

如果你计划得好,通常会有一些小的修改。 对于敏捷开发团队(尤其是C端)来说,会立即开始分配任务、评估故事点、调度迭代等。

这些实践对技术负责人、项目总监和开发团队都有很高的要求。 我主要从事B端工作,从来没有经历过这么敏捷的团队。 有需要的弟子孙子可以自行查阅资料。

会议结束后的会议记录也必须发送,明确事情、人员、时间以及完成项目进度表的期限。

更新相关产品文档并再次发送后,即可进入产品迭代。

讲完需求评审的方法之后,笔者想详细解释一下其背后的动机。 帮助读者了解PRD审核的重要性。 主要围绕几个关键点展开。

4. 为什么参与者应该阅读PRD1。 理解信息的过程

人们理解信息时,即使发生在瞬间,也是一个复杂的过程。 可以简单分为:

外界刺激+感觉获取信息; 调用相关知识储备(记忆、感知); 通过逻辑推理产生对信息的理解。

第一点是通过PRD传递信息。 想要正确传递信息,对PRD的质量要求极高。 如何写好PRD可以参考我之前的文章。

第二点是读者的专业知识、工作经验、对这个项目的知识积累等。因此,不同角色的人听到PRD时会有不同的关注和理解。

第三点是结合逻辑推理,最终产生对当前产品需求的认知和推论。

需要时间思考才能产生既定的认知并得出完整的推论。 到了复查会议再磨枪的时候,往往达不到预期的疗效。

并且让参与者尽早阅读PRD,即使他们只是全心全意地阅读,这种思维的种子已经在潜意识中种下了(大多数人的思维都是通过潜意识完成的,他们有兴趣通过以下方式搜索相关信息)自己),而当涉及到复习时,有时你会理解得更快,并且你会有越来越多的正确想法。

2. 如何让参会者更早观看PRD

少数认真的朋友会读你写的PRD。 大多数学生都忙着自己的事情,有的一开始想看,后来又忘记了; 他们中的一些人根本没有早读书的习惯。

按照“谁受益、谁负责”的原则,需要你主动出击来实现这一目标。

例如,选择在大家都不忙的时候发送会议邀请。 发出邀请后一段时间、评审会前1小时,提醒参会人员再次观看PRD。 对于关键人员(产品负责人、技术骨干等),需要提前预约线下交流,其他人在相处时可以有意无意地向对方询问新需求的想法。

其实最重要的前提就是要把PRD写好。 本来读一大段文字很难,但是读一大段不合逻辑的文字确实很难。

5、为什么要在评审会上避免争论

首先,我们可以换个角度思考。 当两个人私下争论时,我们愿意承认自己错了吗? 那么,把这个场景放在一个充满熟悉朋友的会议上怎么样?

如果你还能坦然承认自己的错误,那么我恭喜你。 而且,很多人私下争论都不服气,更不用说公开会议了。

因此,一旦在公开场合提出不同的意见,就像是不知所措。 如果他是对的,你就会感到尴尬;如果他是对的,你就会感到尴尬。 如果他错了,他就会感到尴尬。 于是,关于事情的讨论常常变成了维护面子的争论。

另外,意见众多,也很难辨别是非。 也许你们都是出于对产品的好感而提出自己的看法,但就是无法互相理解。 同时,这些面对面的争论很容易偏离主题,甚至对对方进行人身攻击。

虽然这场争吵确实是一方获胜,且不考虑败诉方的面子受损和形象受损,但得出的推论并不一定是有利的。 可能只是胜利者更擅长争论。 往往双方都会输。

因此,我们在会前一定要花更多的时间进行沟通,避免评审会陷入无休无止的争论。 再次指出程序员大赛投票网站,审议大会最重要的目的是确认。

六、为什么要向设计师指出时间 1、设计作品的特点

设计本身是一个非常主观的事情,没有明确的评判标准。 为此,设计师的工作并不像开发那样,以清晰的设计文档为目标。 设计工作往往是在思考中完成的,可能会经历无数次的推翻和重构。

“写作为先”,任何设计需求理论上都可以拉长很长,这样才能不断发现新的想法和可以调整的地方。 因此,如果没有明确的分界点,对于项目来说将是一场灾难,而设计师收集素材、寻找灵感的时间可能会超过你心目中的最终期限。

2、设计者的特点

设计师,尤其是UI设计师,常常有艺术家的腔调。 他们有自己的艺术追求和对自己职业的自豪感,思维发散,期待表达自己的想法。

一个优秀的设计师需要这样的素质,否则很难做出以步步设计(chao)设计(xi)来引爆市场的产品设计。

3.一些小建议

你不仅指出了截止日期,还帮助设计师更好地完成设计。

7. 为什么推荐使用UX草稿评审

首先,我们要认识人的认知习惯。 在人类几十万年的进化道路上,我们80%以上的信息都是通过视觉获得的,形成文字也是最近几千年的事。 整个人类认知系统在提取和理解文本方面的效率似乎远低于图片。

其次,文本是对世界的描述,但其表达能力是有限的。 我们在写PRD的时候才意识到,用文字描述一个函数是非常困难的,需要很多逻辑描述。 如果使用原型图、流程图等可视化手段,那就简单多了。

最后,文本的信息噪声往往低于图像。 主要原因是不同的人对同一个词汇可能有不同的认知。 比如有一个关于程序员非常经典的笑话,“下班路上买十个馒头,看到卖甘蔗的就买一个”。

虽然在评测中,防止信息传递失真的最好办法就是高保真原型机,每个功能的细节都可以清晰、动态地解读。 而且其制作成本比较高,而且随着行业的发展,交互规范、专业术语等可以大大改善信息失真的情况。

因此,我认为标注设计稿是最划算的方法。

8. 为什么要写会议纪要

撰写会议记录的目的是为了书面确认大家达成的共识,作为后续实施的依据。 这并不是对团队的不信任,目的也是为了信息的一致性。

口头交流是一种信息失真非常严重的手段,所以需要有PRD、UI、UX等各种产品设计文档,否则直接口头交流并不是更方便。 同样,评审会议也需要清晰地记录会议的要点,以确保大家的理解是一致的。

万一后续出现问题,会议纪要就是很好的证据,可以作为打击捏造事实企图的实锤。

有时候这样的朋友并不是故意的,但随着时间的推移,人的记忆会越来越模糊。 同时,人们有强大的心理补偿机制。 当遇到问题时,他们往往会根据对自己有利的方面来回忆甚至处理记忆。