产品研发阶段：To B软件产品设计流程总结
最后更新：2020-05-22 10:55:38 手机定位技术交流文章
本文作者根据自己的实践经验，分享了To B软件产品设计在产品研发阶段的相关工作，并对各个环节中需要注意的问题进行了分析和总结，供大家参考和研究。
产品开发阶段可以说是产品经理协调和沟通的最大测试时间，因为在这个阶段，产品经理的主要工作是与大型研发领导和政要讨论和安排时间。与所有R&D团队中的每个人就需求进行会面，并回答问题；与测试团队中的每个人谈论需求并回答问题。就市场热身活动与营销团队沟通...事实上，这个阶段的产品大多是杂工~ ~ ~很多产品也是在这个阶段种植的。由于都是口头作业，让我们谈谈我认为有效的一些工作方法和技巧。
产品研发过程通常按照技术选择、功能开发和功能测试阶段进行。大多数企业都有专业的项目经理来负责进度安排和监控。我们公司不具备这种条件，但产品与技术直接相关。幸运的是，我是研发、项目经理和产品转型的路径，几乎坚持不住。因此，在介绍各种工作内容的过程中，我会穿插一些项目管理的项目。我的工作方法不一定适合所有人。让我们以批判的眼光，优先考虑参考文献。
一、整体沟通
进入这一阶段意味着你负责的产品的物料需求开发已经得到公司老板的批准。有了大老板树，你可以开展以下活动。首先，必须进行全面的沟通。必须保持这种沟通。参与者包括:
技术团队的领导(通常是技术总监，根据实际情况，通常是为您安排人员和日程的人)和产品方面的相关人员(通常产品总监必须参加会议，并且必须相当于技术总监方面的领导级别)召集所有团队人员(我们通常此时还没有正式开始，所以只安排了二级领导)和相关营销人员开会统一意见。本次会议主要从以下几个方面向大家介绍:
产品的总体情况(从产品需求设计)每个主要功能的开发时间评估每个功能模块的优先级。在此期间开发的功能的预期开始时间和在线时间有几个目的。一方面，与领导召开会议，统一他们的意见，让每个人都知道要开发的产品的内容便于领导(或安排以下人员)构思产品的整体框架。最重要的是要熟悉各部门的领导。将来在寻找他们时，他们不会被迫去想这个伙伴是谁。
会议记录通常在会议召开时记录。必须记住领导人提出的问题。那些能回答问题的人将被回答(反映在会议记录中)。那些不能在会上回答问题的人将被要求做一份质量保证清单。会后，他们将讨论和解决。他们将通过电子邮件发送给提出问题的领导，并抄送给其他参与者。如果有任何其他问题，也将通过QAList进行记录和跟踪。领导人提出的所有问题都必须得到回答，直到对方满意为止。
这样做的目的是为了结束这个过程，而不是把任何问题留到以后的阶段。一旦问题被抛在脑后，问题肯定会变成一个巨大的深坑。问题越小，在项目结束时爆发的次数越多，影响越大。许多公司都有相关的系统，但我们没有，所以质量保证由我自己用Excel维护，大概是这样的:
简介阶段:此时，您将在XXXX XX写下项目沟通会议的当前阶段:这是项目启动阶段的问题描述:直接从会议记录中摘录，不要更改，它是原始的问题发起人:提出问题的人的姓名，解决问题的目标日期:当天希望您解决问题的人:谁将解决问题，具体的人解决方案:问题预计如何解决？主要描述方案的思路和实际解决日期:提出方案是什么时候提出的？打开和关闭是两种状态。打开尚未解决，关闭已解决；确认:正常和异常是两种状态。“确定”意味着提议者对解决方案感到满意，而“不满意”。这个问题清单将贯穿整个项目过程。每个阶段提出的问题都应记录在问题列表中，并应持续进行闭环跟踪。
这里有一个例子:例如，当一个研发领导者提出一个技术问题时，他可以提出一个解决方案，但是只能在研发阶段解决。那么状态不能是关闭。在研发人员确认这已经反映在这个阶段之前，您可以将其设置为“关闭”并将其发送给提议者进行确认。
大会结束后，你和其他部门的想法已经统一了。R&D部门会为你安排(至少一开始会安排几个领导)，你可以开始下一步。
第二，解释珠三角
你需要做的第一件事是告诉开发者关于产品设计。在这个阶段，每个人都应该注意产品功能本身的实现。你应该把这个阶段要开发的功能列表、优先级和PRD。一般的解释顺序是:
谈到需求清单和优先级，我们应该让具体的研发人员对产品功能有一个整体的判断。说起珠三角，让R&D人员对具体实施有一个了解；应该注意一些小细节，如估计的用户数量、预期的并发量和客户环境，这些都会影响他们的技术选择。如果设计的产品功能更多，建议单独召开几次会议，会后让研发消化。根据我的经验，它通常每隔一天举行一次。当然，有时没有足够的时间进行研究和开发，那么我们就必须把注意力放在它上面，但是对内容的关注会更多，而且效果不是很好。
在解释期间和之后，研发人员通常会问很多问题。这个问题也应该记录在项目问题列表中，以便进行整体跟踪。上面已经提到过，这里不再讨论。
请注意，当研究人员考虑问题时，他们会从技术层面扩大视野，因此他们提出的问题可能是问题或风险。如果发现风险，问题必须转化为风险管理。我们也没有风险管理系统。我自己跟踪的，所以当我们完成的时候看起来是这样的:
风险类别:也就是说，我通常将哪些类型的风险分为资源风险、业务风险、管理风险和技术风险；风险来源:也就是说，风险可能来自哪里，我通常将其分为客户、技术、工程流程、人力资源和设备；风险描述:解释哪些风险通常可能导致项目延迟，哪些风险肯定可能导致项目延迟；风险影响:这是这种风险一旦发生可能产生的影响；风险发生现象:它是告诉每个人如何判断风险是否真正发生。跟踪时间:也就是说，到那一天或在什么阶段，可以判断不存在这种风险发生的可能性；可能性:发生的概率是多少？风险等级:根据影响判断等级，一般分为高、中、低三种，高等级必须每天跟踪；处置:风险是如何处置的，通常包括接受、规避、转移和缓解；对策:它是描述你打算如何根据你所选择的治疗方法来处理它，以尽量减少影响。状态:状态分为打开、关闭、忽略和变为问题。开盘还没有发生，有可能，收盘肯定不会发生。忽视意味着它几乎没有影响，一旦发生就会发生。当问题变成问题时，它就是真实事物的发生。如果已经发生了，就不能称之为风险。如果它被称为一个问题，它必须放在要解决的问题清单上。三、技术选择
在向R&D团队解释此事之后，他们必须选择技术类型。此时，传统的产品经理有一种很小的存在感，因为你不理解它。当时，作为研发背景的产物，我的优势得到了体现。一般来说，我们会根据技术的需要制定几个选择计划，并会召开会议告诉我们什么时候准备好。一般产品需要从以下几个方面来看待技术选择:
性能和可伸缩性:您的技术解决方案能够支持我期望的并发量吗？如果我将来有更大的并发量，您将无法支持它。安全性:您制定的方案的安全性能有保证吗？是否将披露用户信息，以及在这方面是否有任何考虑；产品本身的安全性:有可能被盗版吗？可定制性:如果客户改变了需求，你能快速响应吗？升级:这意味着如果一个产品有一个BUG或者有新的特性，如何升级？一般来说，从这五个方面问他们。如果一个计划不被考虑，将通过。如果还有一个计划，那么这个计划将被选中。如果没有人了，那么温柔地问你是否可以再想想。如果你有所有剩下的(也就是说，R&D相当不错)，让R&D提出自己的建议。他们一定有一个最满意的。如果你不明白他们说什么，你可以选择第二个建议(因为他们最满意的一定是最复杂的，不要问我是怎么知道的)。
会后，别忘了发会议记录。产品提出的问题也需要闭环管理。研发部门也需要回答这些问题。他们确定他们这么忙的时候没有时间吗？没关系。产品帮助他处理这件小事。只是时不时地问一下。
四.研发阶段
一旦一切就绪，它将进入研发阶段。在这个阶段，产品通常会回答研发人员的问题。我不会谈论这方面。如果你在产品设计过程中考虑了所有的问题，你可以给出最好的直接答案。一般的答案是告诉他们以下信息点:
这个内容是什么样的？为什么会这样？如果你做不到，你能做什么？好吧，我们先做这个。那不好。我们不再讨论它了。进入研发阶段最重要的是了解每个功能的开发。我们每天早上开一个约15分钟的早会，然后记录整体进度。因为我想更多地了解它，虽然公司有一个项目管理系统，我也有一个小的进度管理模板来记录进度信息，精确到天上，像这样:
将有每个职能、团队、工作内容(他们告诉我的)和日常情况的记录。
待机意味着计划还没有开始，计划已经开始，正在做，确定正在做，每日记录已经完成，并与总的时间表进行比较，这样你就可以对总的在线时间有一个相对准确的了解。然后根据整体时间表推它们(推的时候请带零食、奶茶、咖啡和个人防护装备)。
一般来说，当他们完成一个函数的调优时，我们会上去随意使用它。理解需求的偏差越早，对项目的影响就越小。
V.功能测试
我们的测试团队是由R&D团队组成的团队，所以整个过程是一起管理的，但是产品必须评审测试团队的测试计划和测试用例。测试计划侧重于测试启动条件、硬件环境和时间表。测试用例关注测试点是否正确，以及测试内容是否能够覆盖功能细节。审查后的问题也应列入问题清单以供后续跟进，这仍然是一个老规则。
此外，测试后应提交测试报告，其中应包括测试案例和测试结果；进行了几轮测试；BUG有趋同趋势吗？压力测试报告等。
我以前的公司甚至根据代码行数来计算质量指标，如用例覆盖率、BUG残留率等等。现在看来，这个计算更少了。
经过一段时间的研发，研发团队将向您提交以下结果:
产品包(在线或安装包)产品部署手册(通常离线提供)产品测试报告已经获得这些结果，我们的产品将开始我们的验收和市场支持相关工作。关于进一步的工作，请听下一期的解释。
#相关阅读#
市场分析阶段:To B软件产品设计过程总结
产品设计阶段:To B软件产品设计过程总结
这篇文章最初是由@Jimmy.jing发表的，每个人都是产品经理。未经允许禁止复制。
主题图来自Unsplash，基于CC0协议。
本文由 在线网速测试 整理编辑，转载请注明出处。
