it产品经理的职业规划：系统工程对产品经理工作的启发

it产品经理的职业规划：系统工程对产品经理工作的启发5. 系统启动（Launch the system）：这一步是我们要整体运行系统了，让系统开始完整地进行输入（输出我们预期的结果）。4. 系统整合（Integrate）：这里的系统整合是指将各个子系统都整合起来，使系统能够完整地运行起来。1. 描述问题（State the problem）：系统工程的第一个任务，就是把我们要去解决的问题陈述清除，即定位问题。我们需要明确我们的目标用户，了解用户的需要，探索需求，从而定义系统功能。2. 调研替代方案（Investigate alternatives）：对于用户提出的需求，我们可以调研市场上已经出现的能够相对满足（或部分满足）的产品（或者我们称之为竞品），调研这些产品的表现情况（用户评价与反馈）、成本以及风险，为我们带来经验和启发。3. 系统建模（Model the system）：在前两个任务中，需求与调研都已相对成熟，我们就可以着手来设计我

系统工程为了实现系统的最终目标，对系统的各个子系统、部件以及信息流等进行研究分析与设计，使用各种组织和管理技术，使整体系统实现最优的运行，负责整个系统的生命周期。

对于产品经理来说，要负责一个产品（从解决问题，满足需求的角度上来讲，产品也是一个系统），系统工程中的很多方法与经验，都值得产品经理学习和借鉴，来更好地管理我们产品的整个生命周期。

1 系统工程简介

那么什么是系统工程呢？我们可以先来看看ISO900对系统工程的定义：a system is an object consisting of interrelated or interacting elements（components）.

系统工程的过程则由以下七个任务来构成，被称作SIMILAR tasks。

1. 描述问题（State the problem）：系统工程的第一个任务，就是把我们要去解决的问题陈述清除，即定位问题。我们需要明确我们的目标用户，了解用户的需要，探索需求，从而定义系统功能。

2. 调研替代方案（Investigate alternatives）：对于用户提出的需求，我们可以调研市场上已经出现的能够相对满足（或部分满足）的产品（或者我们称之为竞品），调研这些产品的表现情况（用户评价与反馈）、成本以及风险，为我们带来经验和启发。

3. 系统建模（Model the system）：在前两个任务中，需求与调研都已相对成熟，我们就可以着手来设计我们的产品（系统）了，大致来讲，接下来就是使用建模工具，或者自己开发适用于该业务的建模工具来建立模型，来清晰表达需求、发现项目中的难点以及及早暴露问题。

4. 系统整合（Integrate）：这里的系统整合是指将各个子系统都整合起来，使系统能够完整地运行起来。

5. 系统启动（Launch the system）：这一步是我们要整体运行系统了，让系统开始完整地进行输入（输出我们预期的结果）。

6. 性能评估（Assess performance）：接着，我们就可以用想用的技术性指标来评估系统运行的相关情况，从而来量化当前系统的性能，评估系统是否满足了需求。

7. 再次评估（Re-evaluation）：系统评估是一个不断重复的工作伴随产品的不断迭代。

2 系统生命周期

在产品设计的早期，产品经理就应该开始考虑产品的系统生命周期的问题。我们如何进行需求探索与分析？当前的竞品或替代方案对于这些需求的满足情况如何？研发资源是否到位？系统维护与迭代是否已有方案？等等。 既然产品经理对产品的整个生命周期负责，那“系统生命周期”的如下七个环节则是需要产品经理去良好把握的关键，以确保产品工作的顺利展开。

系统生命周期的七个环节：

本文我们将重点聊聊系统工程中需求探索分析与系统测试评估方面的内容带给我们的启发。

3 需求探索与分析

需求探索与分析非常有趣，当然也非常重要，需求的明确是产品成功的基石。

我们的用户往往并不能够准确地表达他们的需求，他们往往倾向于用尽量少的语言来笼统地提出需求，比如说，“我要这个产品用起来很爽”，“简单不要搞复杂了”等等，这时候产品经理一定要做好一件事情：将用户提出的需求明确化，具体来说就是将需求明确为可量化、可测试、可实现。

举个例子，共享电单车用户说我要这个车骑起来很快，那么具体的快是怎样的一个速度区间值呢？给出一个预期的速度范围就是一个“可量化”的需求；那我们最终产出的这款共享电单车是否满足了用户的速度需求，是可以通过速度测试来知道的，这就是“可测量”；用户还说，我希望这辆电单车永远都有电，也不用换电池，对于这个需求，如果最终确认是朝着永动机的方向研发，那我们就应该立即停止项目，因为“不可实现”。

对于需求是否是“可实现”的评估，这里的一个行业经验是我们会去参考现有的相关解决方法来得到一个相对稳妥的结论。

对于需求，还有一个绕不开的话题当然就是优先级问题。通常产品经理对于优先级的定位都是通过我们熟悉的四象限定位法来确定的，重要并急需、重要不急需、不重要但急需、不重要也不急需。但如何来把握这四个象限，更多的是一种经验。系统工程中对于需求也有分类，这或许会对产品经理在优先级定位的问题上有所启发。

系统工程中我们将需求分为了两类：强制性需求（Mandatory requirements）和偏好型需求（Preference requirements）。简单来说，强制性需求指的就是为满足用户基本需求，保证产品主流程畅通必须具备的功能需求，偏好型需求则更多是指提高用户体验的相关需求。

举个例子，共享单车项目，注册登录、交纳押金、扫码开锁，还车结算等与用户主用车流程相关的需求都属于强制性需求（也就是重要并急需），没有这些功能的支持，主用车流程将受阻，用户无法正常完整使用产品，而分享朋友圈、邀请好友等功能，没有影响到主用车流程的需求，则可以归类到偏好型需求了。

当然，如果我们有一个team的任务就是研发基于共享单车系统的陌生人交友产品，用车流程则是支援部门考虑的事情，我们则专注在分享朋友圈和邀请好友上面，所以确定我们要研发实现的系统的边界（System boundary）与核心目标也是尤为重要的。

需求的探索与分析其实是一个过程，对于这个过程的理解与实践，我想用下面的这张图来说明一下：

4 系统功能性测试评估

到了验收的环节，产品经理需要做的，是确认开发交付的系统是否满足终端用户的需求。从系统工程的角度上来看，验收需要关注两个问题：功能是否完备、系统是否可靠。

1.功能是否完备：这里我的一个经验是用一个checkList来一个功能一个功能地验证。

举例：如果我们验收的是一个计算器APP（如下图所示），从需求文档中我们可以整理出下面的一个checkList来进行功能完备方面的检验。

2.系统的可靠性由这几部分组成：有效性、稳定性、安全性和保密性。

• 有效性：系统在被请求时提供相应服务的能力。
• 稳定性：系统稳定输出服务的能力。
• 安全性：系统正常工作不会导致灾难性故障的的能力。
• 保密性：系统保护自己免受攻击的能力。

产品经理对于系统的可靠性的把控方面，则通过上述的几个组成部分和测试部门的同学密切合作，通过系统测试报告来了解以及和开发同学不断完善，使产品最终可交付使用。

本文由 @罗冠林 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议