产品流程、开发流程、测试流程、运维流程、售前流程改进建议

背景与目标

在全球化的进程中，信息已经是从单向传播转变为双向互动，知识的获取渠道不在是闭塞的，甚至GitHub还有开源可用的代码。用户端触达产品的渠道也越来越多，进而产品的生命周期也越来越短，对产品生命周期的延续性、连贯性提出了新的挑战。

建立或优化流程化的程序联结各个信息岛屿，共同以一致的步伐去适应市场需求。并建立或优化新产品流程体系，提高创新能力维系公司长期愿景和未来增长。

程序流程优化建议

产品阶段

接到需求：产品经理接到前方小伙伴的需求，或者内部衍生需求。

需求分析：产品经理对接到的需求做分析，分析的维度包括用户群体、财务价值等角度，具体视需求来源与内外部环境而定。这个分析也包括了内部产品矩阵的需求匹配。

市场调研：内部的需求分析结果是否真正符合市场期望，这就需要从市场调研角度入手，可以通过问卷调查、第三方公司等完成这个调研。

需求分析：根据市场反馈的结果，重新获取新需求，在结合旧的需求做分析。

内部产品矩阵：市场反馈的需求分析结果反过来看内部的产品矩阵中有没有类似的产品可以匹配这个需求的。或者是产品定位上是需要完成这个需求的产品。

商业论证：内部产品矩阵没有产品能匹配上这个需求，就需要做商业论证，并输出商业论证结果。可以从内外部的价值、法规要求等维度上分析需求价值。

愿景、使命、价值观：商业论证得出需求价值，而需求价值与愿景、使命、价值观是否匹配决定产品未来资源与战略高度。

战略：与公司愿景一致的产品需求，但与公司战略方向是否匹配，意味着未来的资源投入价值比。

未来五年目标：与公司未来的五年目标是否匹配决定于产品需求是未来需求还是伪需求。

市场调研：产品需求与愿景、使命、价值观、战略、未来五年目标可能有偏差，或者有些许偏差的情况下，可以重新结合公司的愿景、使命、价值观、战略、未来五年目标重新在去审视需求，重新在市场的角度，重新做调研。

需求分析：获取到新的市场需求，与旧需求做结合重新做分析，匹配上公司的愿景、使命、价值观、战略、未来五年目标。这里的市场调研和需求分析是为了符合内部需要，而前一步做的市场分析和需求分析是为了符合外部需要。
产品定位：产品需求以及产品未来形态与公司的战略方向等保持一致的情况下，在调整完得到完整的商业论证支撑的情况下，此时就要清晰的定位产品位于内外部的位置，比如内部产品矩阵位置、用户群体、市场等。

产品路线图：产品定位是体现产品价值，产品路线图是实现这个价值的路径。

低保真（原型）：体现了产品的展示形态，将所理解的需求及产品设计，反馈给用户确认，从而提高产品需求理解质量。（在B端低保真是可以限定客户思想随意发挥的工具，而且低保真是可以与客户需求产生N个为什么的互动，尽可能的覆盖客户未发现的需求，避免项目进行中的所带来的改动成本。）

高保真（原型）：体现了产品最终展示形态与交互方式。

产品故事地图：进入“落地”阶段的所需要的一份路线规划图。

PRD文档：由“概念化”阶段进入到“图纸化”阶段必备的文档，尽量的全面理解客户需求，正确、完整、清晰的用文字表达所接受的客户需求，避免或尽早剔除早期错误。也是用于评审和确认的文档。

评审/确认：战略评审层面是con产品定位、目标市场、目标用户、竞争对手等，战术评审层面是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等进行评审，原型评审是对展示设计、交互设计等进行评审。

产品需求宣讲：将需求以通俗易懂的语言传达给相关研发、设计、测试等人员，达成需求理解的一致，明确接下来的工作应该怎样去展开。

文档：输出相关文档。参考：https://blog.csdn.net/Su_Levi_Wei/article/details/115037915?spm=1001.2014.3001.5501

开发阶段

技术路线图：基于产品设计，产品未来规划中，在产品形态出现变化时，技术架构能否跟得上这种变化，是否可以在前期架构设计的更加灵活去应对产品路线图提出的这种变化。

整体架构设计：基于产品路线图，结合应用领域和技术发展的实际情况，设计、合理的技术架构，确保系统具有良好的特性。

网络架构设计：确保随着时间的推移、时代的发展，能够更灵活的适应网络流，以及在高峰网络流的应对措施。

后端架构设计：信息流的处理层面，确保符合产品业务需求的发展，更灵活的适应和能处理更高峰值的数据量。

前端架构设计：适应各种展示媒介、前置流，以及轻简化的业务处理，包括法规要求。

技术选型：基于产品路线图、产品商业论证，估计可能投入的资源质量，决定于前后端的技术栈选择。

数据设计：构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

组件选型：基于产品路线图，Devops、容器等组件的选型。

部署架构设计：基于安全、法规等要求的情况下，设计严密的服务交互矩阵。

架构搭建：代码、运维等具象化的体现搭建。

架构/原则宣讲：贯彻整体规范，确保自下而上共同监督，共同执行。

开发：编写代码。

文档：输出相关文档。参考：https://blog.csdn.net/Su_Levi_Wei/article/details/115037915?spm=1001.2014.3001.5501

测试阶段

测试用例：对产品测试任务的描述，体现测试方案、方法、技术和策略，包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

功能测试：对系统的所有的特性和功能都进行测试，确保符合需求和规范。

逻辑测试：确保操作行为符合系统设计预期。

压力测试：系统响应时间、运行效率、资源利用等各性能指标，是符合预期指标。

冒烟测试：确保主功能线是输出预期结果，如果冒烟测试的测试例不能通过，则不需要做进一步的测试，提高测试效率。（是交付成熟私有化产品性价比最高的测试方法）

自动化测试：一般采用脚本形式编写自动化测试用例，由机器自动执行脚本，自动将实际结果与期望结果比较，提高测试效率。（是交付成熟私有化产品性价比最高的测试方法）

基线扫描、代码扫描、组件扫描：可用阿里云、腾讯云镜等。

验收测试：确保需求是有效的传达和执行，系统是符合预期成果的。

验收报告：对发现的问题和缺陷进行分析，为纠正的存在的质量问题提供依据，同时为验收和交付做准备。

文档：输出相关文档。参考：https://blog.csdn.net/Su_Levi_Wei/article/details/115037915?spm=1001.2014.3001.5501

运维/部署阶段

 

部署要求：根据系统设计的独特性、独立性相关要求准备部署资源。

部署物料：服务器、部署包、部署清单等资源准备。

网络架构图：直观明了可视化网络中各个节点之间的链接，还有接口之间的链接，也就是反应网络中各实体间的结构关系，便于配置和排除错误。

资源配置清单：确的描述项目所需的硬件配置信息。

网络策略列表：不同安全组/域之间的网络端口，流量流向权限等。

投产上线方案：技术侧的投产流程，业务侧的配合事项进行说明，以及对上线步骤进行剖析，特别是在有关联系统的情况下。

回退方案：对上线风险进行评估，说明可能产生的故障以及触发条件，并提供对应回退方法。

部署脚本：组件部署脚本说明、应用部署脚本说明，常见文件排查等。

文档：输出相关文档。参考：https://blog.csdn.net/Su_Levi_Wei/article/details/115037915?spm=1001.2014.3001.5501

售前阶段

商务：得到商机，获得商机就要记录下相关方的信息。

项目通知：客户开始发出投标邀请，或者拿到名额了，确定是投标参与者，就开始内部同步信息。

项目入库：项目相关信息都要入库，做统一管理，包括相关方信息。

售前团队：确定是投标参与者的情况下，售前要确定本次负责人、执行人、知情者，如需要协调XX，执行人A，升级到负责人B，负责人B去处理。

客户分析：售前团队要对客户的背景、本次招标的动机做分析，确保击中痛点。

售前交流安排：商务需要安排首次的售前交流，售前能更清晰的了解客户需求，以及是否与分析相符，便于制定接下来的策略。

售前分析：对外需要再次对客户的招标诉求做分析，以及相关的部门、利益、竞争对手等做分析。对内，需要分析内部产品聚在中是否有符合客户需求的产品。

投标要求：明确列出客户对于投标的要求，比如时间、地点，以及其他限制。

效益分析：基于以上的内外部分析，进行相关的效益分析，可以从产品核心价值、财务价值等指标分析本次参与的价值，以及对应的资源配比。比如是学习的心态，那么投入的资源是需要强大的信息收集者。

投标策略：基于竞争对手与需求分析，制定相关的痛点打击方法，包括话术、展现方式等。

投标计划：包括目标、投标人员、形式、投入时间等。

应急方案：此类客户或此类标书，可能出现的常见问题，如何应对的方法。

调整/适配：调整相关的方法，适配本次客户。

画字签押：所有本次参与者确认为本次的目标达成而共同努力。

POC复盘：前中后整个生命周期的过程阶段做分析。

改进：输出相关的改进TODO List，并落地时间。

交付阶段

 

信息整合（招投标书...）：销售、商务、售前、客户前期材料、合同等都存放到相应的网盘位置。

确立团队：确定项目总监、项目经理、产品经理、技术负责人、测试负责人、运维负责人，并根据自身公司情况做裁剪。

售前宣讲：售前需要讲明客户需求、范围、核心相关方等信息。

售前交接：交接交付标准、范围标准、实施的物料版本等信息。

对客交流安排：商务负责首次对接交流的安排，需要拉项目总监、项目经理、产品经理、技术负责人、测试负责人、运维负责人到相关的微信群。

节奏、目标、方案准备：首次交流的内容、目标、内容等以专业化的角度准备，最好以PPT的形式，并确立讲解的节奏。

项目管理文档（裁剪）：根据自身公司内已有的项目全套文档的基础上，据项目要求进行裁剪。

交流：按照既定节奏，现场与客户交流，可包括验收的可遗留事项数量等。

会议纪要：每次的会议都输出会议纪要，最好有录音、录视频的动作做归档。

风险：首次交流后，都会出现与售前交流的内容不一致，以及存在的风险，这些风险要及时记录并做内部确认。

确立节奏：确定入场人员，实施周期，人员在项目入驻的周期时间。

方案调整 / 确认：根据首次交流与售前给予的东西，调整策略、方案，并依据风险项调整应对措施。

里程碑阶段：不同里程碑的目标、投入预计的确立。

详细计划：人、事、物，基于时间进行。

......：交付中，风险、待办等。

验收报告：测试验收报告（质量）、项目经理验收报告（复检）、产品经理验收报告（逻辑质量），只有经过内部这三步验收完成，才能找客户做验收。

遗留问题清单：本阶段交付的遗留事项、解决方案、负责人、预计解决时间，在非严重BUG与漏洞的情况下可以做验收。

资料归档：售前、交付、验收等全套文档归档，存放到指定的位置。

归档资料确认：项目总监、项目经理、产品经理、技术负责人、测试负责人、运维负责人、售前、商务进行邮件确认，确保材料全套移交完成。

售后清单：填写售后清单，根据售后要求提供相关材料。

全成本核算（邮件）：项目经理根据财务要求提交全成本核算材料，并由财务发布全成本核算确认。

项目归档：全项目归档，准备释放资源。

资源回收：资源释放，排期到别的项目。

复盘 / 改进：市场、需求、交付内容、期望匹配、问题、改进、TODO List，其中TODO List必须要由高层作为执行监督者。