六、产品/项目启动

Well begun is half done.

万事开头难，所以用上面这句话来开始本章的内容，以示启动环节的重要性。

考虑到产品与项目在立项方式、管理模式、执行过程以及目标定义等环节具有一定差异性，本章内容的构思考虑过几个不同的版本（算是为更新慢，找了一个合理的借口），选任何一个方案又觉得似乎都有一定缺陷，要么会导致内容冗长、重复；要么会使内容单薄，不能更好的覆盖全部问题；或者是内容连贯性不够，有支离破碎之感。另外考虑的一件事情是产品/项目启动，这个话题的内容实际上是非常广泛的，如果全部涉及，本章写起来会非常累（我比较懒），所以最终的决定就是下面你将看到的内容：仅关注产品/项目启动过程中与深度学习相关领域的内容，其余内容，如非必要不会去涉及。后续再依据反馈（如果有的话），进一步完善、增减内容。

为了统一后续文字的语境，先对“产品”与“项目”做出定义。

“项目”是指有合同/任务支撑（特殊情况下会没有合同，先做项目），明确了交付目标与交付时间的交付型项目。

“产品”就是我们所理解的普遍意义上的产品，更多的是基于对技术、目标客户、市场竞争等因素综合考虑后做出立项安排，虽然产品的研发过程大多也会按项目进行管理，但产品定义一般是内部可控的，不会更多的受到外部相关方的干涉。

对于产品/项目启动这个话题，在二、机器学习项目过程中有简单介绍，仅对关键问题感兴趣的话，可以跳回去看看。

在这里，我们需要讨论的产品/项目启动，准确说应该包括启动与规划。事实上，我们在内部立项进行产品研发的过程，还是会遵循一般意义上的项目管理过程的，所以我们首先从PMBOK定义的项目管理专业范围内知识的术语入手，了解下项目启动环节，我们需要关注哪些内容。

BTW：和很多参与项目管理的管理者或者拿到PMP证书的朋友沟通过程中，发现大多数人对PMBOK都有一个认知误区，认为PMBOK是一种“项目管理的方法论”，但实际上，PMI对于PMBOK对的定义是：

PMI 将项目管理知识体系 (PMBOK) 定义为描述项目管理专业范围内知识的术语。

理解 PMBOK 的定位并不是方法论这个重要定义，对我们认知、运用PMBOK提供的知识是非常、非常、非常重要的。

PMBOK知识点解析

本节所引用的内容与图片，均来自于《项目管理知识体系指南 (PMBOK ® 指南) 第6版》（中文版），在此统一声明引用源。

虽然我个人是比较喜欢尊重理论而不拘泥于理论的做事方法，以避免陷入“谨记理论的刻板遵从”而忘记了做事初衷与目标（比如很多公司把 CMMI3 最后执行成了“文档管理”，而忘记了建立CMMI体系其实想解决什么管理问题），但“不拘泥于理论”绝对不是说用“野路子”的“小作坊”模式去解决问题，而应该是：

认知理论与标准规范，理解其“本质”要解决的问题；
理智的评估“范围”、“时间”、“成本”、“质量”四要素；
基于对四要素的评估，结合“理论遵从”去做取舍；
面对四要素的取舍压力时，基于“目的”、忠于“目标”，战术选择性去“忽略”部分要素；

用一句通俗易懂的话来解释那就是：在成本有限、项目范围不可压缩的情况下，为了确保项目核心目标的“质量”可控，可牺牲的只有部分过程/文档工作，包括可能也不限于：整体需求文档、概要/详细设计文档、各种评审等。但是，这种刻意减少过程环节的安排基础是：产品经理对需求整体把控能力过关、总体设计可信任、主程对产品需求理解透彻、团队内部不会“甩锅”。

有关这种“取舍”选择方法与原则，在 PMBOK 1.2.5 剪裁(第六版 P 28)中有具体解释（毕竟实操性的东西最难写，解释其实也挺含混，就是原则层面的说明），有兴趣的同学可以去看看。

项目管理知识领域

我们知道，PMBOK定义的项目管理过程包括：启动、规划、执行、监控及收尾，共五个过程组。其中，启动、规划两个过程组，与本章所关注的产品/项目启动是相关的，具体如下图：

个人认为，我们可以用一种更简洁的方法去理解启动、规划这两个过程组需要做哪些工作：

定规矩（项目章程）
定计划（各种计划）
知需求（范围管理）
知预算（成本、资源）
识风险（风险管理）
识目标（相关方、质量）

此部分内容，暂不展开去进一步解释，后续再补充完善。

项目的生命周期

在PMBOK 的 1.2.6 项目管理商业文件 中对项目的生命周期用如下一张图做了解释：

可以看到，在进入项目生命周期之前，还有一部分项目前期准备工作需要完成。个人理解是PMI认为这一部分工作更多的是偏向与组织“商业意图”的工作，一般是由更高级别管理者或者商业团队完成，且经过前期准备的论证后，有可能最终决定是不予立项，所以没有将此部分内容归入项目管理的知识领域。

其实这些内容非常重要，个人认为，有关于项目前期准备的工作是否应该纳入PMBOK的知识领域是值得商榷的。感觉PMBOK会在未来的版本中把这些内容放入融入，也许会增加一个“准备过程组”或者“定义过程组”，将项目管理过程组扩充为六个过程组，知识点从49个变化到52个左右。正如第四版的“干系人”在第五版之后新增一个知识领域，并提升为“项目相关方管理”这样的演进逻辑一样，逐步对“看起来不重要”的但其实非常重要的内容提高权重，这些变化对于帮助项目经理的知识领域的扩展和更深刻的理解项目是有现实意义的。

事实上，大多数公司的实际项目/产品的立项阶段，很可能会安排产品经理参与做一些竞品、市场相关的分析工作，对于组织僵化或者“唯上”倾向明显的团队，也有可能是某个领导的“一句话”就立项一个项目。项目经理在着手启动项目的时候，由于项目的“商业意图”不一定经过了严谨的论证与推演，存在 项目启动就注定了失败 这一高风险可能。

由于PMI对PMBOK的知识领域的定义，和绝大多数产品经理/项目经理的自身知识结构与工作背景，以及大多数企业的工作职能/职责划分这种综合因素导致的产品经理/项目经理的知识结构的“瘸腿”现状，是我看到的很多产品不成功、项目无法验收的核心原因之一。

个人的建议是：产品经理/项目经理的知识结构一定是足够复合与宽广的，必须要理解与商业行为有关的知识与内容。

对于产品经理/项目经理来说，在项目启动环节，一定要去寻找如下几个问题的答案：

竞对如何做（了解SOTA的思路和做法，并“理解”各厂商产品间的差异的本质原因）
价值是什么（可复制性、产品价值、客户价值、社会价值、经济效益）
销售如何卖（对于 to B/G 产品，在启动规划阶段就要想清楚销售环节的竞争优势）
运营如何推（对于线上 to C产品，在启动阶段就要思考运营问题）
收入在哪里（对于 to B/G 产品，需要明确的就是目标客户群体以及定价）
用户如何用（认知用户与场景）
非预期效应（理想很丰满现实很骨感，产品使用条件部分满足、出错或者其他各种意外因素发生后，结果是什么？）

具体解释，暂不进一步展开（每个主题都涉及很多内容），后续再补充完善。

理解目标

产品目标

在讨论产品目标之前，建议对波士顿矩阵（BCG Matrix）有一定的理解。en.wikipedia、zh.wikipedia、mbalib、百度百科的解释建议都看看，这个词条百度百科的内容还是挺不错的（对于擅长买药的百度同学，该表扬还是要表扬）。波士顿矩阵将产品的类型划分为了四类：瘦狗、问题、现金牛及明星，分别代表四象限中的一个。企业所有的产品，经过合理的分析之后，都会落入四象限中的一个，依据产品的类型，会有具体的行动建议。

波士顿矩阵是市场、销售部门常用的分析工具，产品经理大多很难接触到这个名词，并参与相关的分析工作。但是，个人认为产品经理需要对波士顿矩阵的四象限有一定的认识与理解，这样在做产品目标定义，尤其是产品迭代过程中的目标方向选择时，才会做出更“理智”的判断。只有理解了四象限的定义，我们才会理解：

为什么有的产品看起来还行，但是公司给砍了（瘦狗）
为什么有的产品卖的挺好，看起来也有可以改进的问题，但是公司不采纳升级建议（现金牛）
为什么有的产品卖的并不算好，但是公司在投入大量资源进行升级（问题）
为什么公司会突然成立一个事业部，把某（几）个产品放入事业部单独运营（明星）

这样的商业行为与决策选择。

个人认为通过对波士顿矩阵四个分类的理解，对于产品经理最大帮助应该就是理解产品的“最终可能”，进而可更好的认识与理解产品定义阶段的目标认知与选择。

产品定位

任何产品，在立项阶段明确定位都是很关键的工作，定位的偏差很可能直接导致产品的早早夭折。

对于 to B/G 领域的产品来说，80%的我们以为的“新产品”都有友商已经在做，做好前期调研与市场分析工作就显的很重要；剩下的20%的“新产品”或许在公开市场上确实找不到“可对标”的产品，但是也不要乐观的以为“发现了市场空白”，先去思考下：为什么这个事情没人做。

通过项目前期的商业分析确定需要立项的产品，在确定产品定位的过程中建议至少需要思考以下问题：

最终用户是谁，最终用户会如何使用产品
最终用户使用产品的场景有哪些
竞对的产品形态如何，优缺如何
公司对于产品的期望定位是什么
- 防守型产品：竞对都有此产品，属于产品链补全，避免存在短板给对手抓住机会
- 挑战型产品：竞对有类似产品，但均存在明显短板，我司产品可在对方短板发力，获取市场机会
- 试水型产品：产品定位尚属于蓝海，存在不确定性，但值得尝试，基于市场反应灵活调整
- 跟随型产品：竞对此类产品属于BCG Matrix的“明星”类，照猫画虎并针对我司优势加以改造，搅动市场
- 定制型产品：基于特定客户的特定需求“定制”的产品，有可能加以改造后形成通用化产品（一般我们说的“用项目养产品”，大多都是此类产品）
公司内部“相关方”对于产品的定义是如何思考的
- 市场、销售等直接面对客户与市场的人员对于产品定义的思考
- 直属领导、分管领导对于产品定义与定位的思考
- 公司决策层对产品定位的要求

必须要“认清”的一件事情是，对于产品定位这件事，更多体现的公司决策者的“意志”，所以对于产品经理而言，正确理解这件事情非常重要，否则很有可能“南辕北辙”，做的非常拼命，方向却理解错了。

产品周期

任何产品都是有生命周期的。在理解产品定位与产品目标后，应该能够快速判断出产品的周期，具体可能需要结合以下内容思考：

特定行业特定场景的特定需求，复制可能性较低，后续升级可能性较低
通用技术的不同场景应用，可考虑抽象通用性部分，后续有可能在应用层面有多种变化
技术在场景内找落地可能性的验证性产品，后续存在大概率改版甚至推到重来

对于产品周期的判断，可以帮助产品经理对未来一个阶段的工作有一个总体的认识。短周期产品，仅仅关注眼前需求确保按期交付即可；而长周期产品，则需要在设计之初，就需要考虑未来升级、迭代的变化可能性，在产品架构层面预留足够的灵活性。

项目目标

相对与产品而言，项目因为有明确项目目标（合同/合同附件/技术协议等），在启动阶段项目经理需要关注的重点工作其实并不多：

精读并尽可能去理解项目合同相关文本中对于项目目标的描述
与项目前期售前阶段参与的同事沟通了解项目背景情况
明确项目工期要求

此外，对于项目目标还需要做一些延伸思考与分析：

这个项目的目标，尤其是目前看起来是“个性化需求”的东西，有没有可能产品化
目标是否存在客户对SOTA以及“最佳实践”对认知不足，并没有完全表达出在客户行业此类应用应该有的目标
目标中是否存在明显的“不当承诺”，这些承诺销售和售前会解释为“不这么写，合同就拿不下来”。这些都是明显且非常大的项目风险点，应该在启动初期就着手做风险管理与应对预案

确定相关方

“相关方”在PMBOK之前的版本中称之为“干系人”，不论是产品经理还是项目经理，在整个工作过程中找到并做好相关方的沟通与管理工作是非常重要的，一般而言，对于相关方我们需要从两个“视角”去观察、确定和认知。

视角一，按相关方的决策权重去观察、确定：

参与但不决策
- 主要是项目/产品执行过程中的绝大多数参与人员，或许会给一些建议，但大多不参与决策或者说“没有决策权”。
参与且部分决策
- 项目/产品的核心“玩家”，一般在组织内部具备一定的“地位”，所以在活动过程中“天然”具有一定的决策权。
- 这部分参与者由于对工作整体过程介入较深，一般会给出“相对正确”的判断。
决策但不直接参与
- 项目的核心决策机构人员，主要就是“领导”。
- 给出项目目标、要求和方向，不会参与工作具体过程，但会阶段性听取汇报，并作出判断。

视角二，按相关方对项目/产品的支持/重视程度去观察、确定：

参与且支持
- 基本上是项目/产品执行过程中的绝大多数参与人员，或许在部分细节会有不同或者保留意见，但大多情况下会对工作的推进提供积极且正向的支持。
参与但无明确倾向性
- 很有可能是“被动”情况下参与相关工作，工作对他来说仅仅是“工作”，一般情况下会按要求工作。
- 这部分参与者可以在过程中施加影响，逐渐使其积极、正向支持工作。
参与但不一定支持
- 一般情况是“被动”参与，或对于产品/项目的部分内容存在个人不同意见，但这种不同并非不可调和。
- 这部分参与者可以在过程中施加影响，逐渐使其放弃或者能接受不同观点，做到求同存异，共同推进工作。
参与但不支持
- 基本可以理解为产品/项目过程中最大的阻力来源，由于其个人观点（或其代表的利益方的观点，这种属于“政治”层面高级玩法，本文不探讨，后面如非必要也不会特意说明此类问题。）与整体目标存在较大差异，但做为一份“工作”，其还需要参与其中。
- 最好期望不要出现这种相关方，一旦识别到此类相关方，首先应列入“风险管理”内容中，按照一个风险源来管理。
- 如果能求同存异、在一定共识基础下配合工作推进，则可想法就其关注的内容优先且超期望满足，以换取其支持。
不参与且不支持
- 基本可以理解为“旗帜鲜明”的“反对者”。
- 一旦识别到此类相关方，做为高级别风险来管理，需要有高级别领导出面进行早期干预。
不参与但支持
- 一般而言就是项目/产品立项及核心目标提出的“领导”，是项目最重要的“政治”支持来源。
- 按阶段汇报工作，切记汇报工作不要“只报喜不报忧”，也不要“只说问题不提进度”。

通过“视角一”，我们是去发现在产品/项目过程中的主要决策者有哪些人，以及他们决策的依据是什么；通过“视角二”，我们要能明确的知道过程总哪些人会“帮助”、哪些人“立场中立”、哪些人“负帮助”。

比如，当你发现是“负帮助”的人在给你建议，并做出了“决策”，那么你就应该知道这样的决策是“真执行”还是“假执行”或者通过一定的技巧去“拒绝”了。

厘清需求

研发管理模式从“瀑布式”进化到现阶段取得广泛认同，与大量IT企业选择实践的“DevOps”，最重要的驱动因素之一就是“需求响应”迟缓。但是，我们应该意识到敏捷开发的“用户故事驱动、快速迭代”并不是说“需求管理”可以降低要求，边做边思考，走一步看一步。对于需求的理解深度与程度，是应该理性对待的，对于找到一个“老司机”可以“完美”的定义出来完整的需求，这种美好的“期望”不是不可以有。但是，我们必须认识到一个现实的情况：好的产品经理本来就极其难得，再叠加进入B/G行业的需求与AI的算法相关知识，这样的“老司机”市面上真的存在么？

所以，在“理想人选”有可能终将不可能到位的情况下，我们依然要选择用现有的人力、脑力、心力，用合适的方法推进工作的进行，最简单、有效的需求梳理方法应该就是：分类、分级。

需求分类

不同的团队文化，不同的对事物的认知方式，都会影响我们对事情“分类”的视角和思路，建议可以按以下分类角度来厘清需求。

必须实现需求
这个比较好理解，就是一个产品/项目的基础核心需求，这些需求中的任意一个不能按需求实现，就会影响一个产品/项目的立项基础，直接影响成败的需求。
锦上添花需求
此类需求可以这样来理解：不能实现，不影响产品/项目实现的基础；但是，如果实现，会让产品/项目在某方面具有更加打动客户的能力。
防守型需求
此处的“防守”是针对“竞对”而言的，做为PM我们必须要认识到一件事：你在做的事情，竞对也在做，而对同样类型的事情，基于技术储备、行业理解、接触到的客户的“引导”等因素，竞对间的理解一定会有异同。这些相同的内容，基本就是“必须实现需求”，大家都会做；而不同的内容，由于各家公司的市场能力、宣传投入及客户资源是不同的，就会出现这种情况：我司觉得并不重要的功能需求，被友商“吹上了天”，也成功的教育了市场与客户。那么，此类需求，对于我方来说，就是“防守型需求”，因为如果不做，就明显让竞对的策略取得效果，只能选择跟随、防守（虽然不一定情愿做）。
进攻型需求
与防守型需求对应，有些需求竞对可能受限于技术、行业理解等因素，选择性不去关注或者刻意回避，而我方的理解是在此类需求中可以产生竞争优势与竞争区隔。此类需求，从本质上来说不一定是必须实现的核心需求，但是做为“进攻武器”可以选择实现。最典型的可能就是“人脸特征”从96点开始不断的提高，做为用户并不知道人脸特征点数据有多少是“合适”的，厂商之间做为一种“核心能力”在不断提高，以展示其相对竞对的技术优势。
其他需求
非以上需求，无法合理归类，基本都可以放在其他。

需求分级

对于需求分级这个任务，并不需要太多高深的理论去支撑，用非常“传统”的符合直觉（当然，这个直觉是需要有一定经验积累的，否则哪叫“瞎搞”）思路去做就足矣。

重要且紧急
重要不紧急
不重要但紧急
不重要也不紧急

重要且紧急这一类显然是高优先级任务，一般来说基本上都是必须实现的需求和进攻型需求，这是比较好理解的，重点在于怎么去理解不重要但紧急的这一类任务。要理解并能正确的分类这一部分任务，首先我们需要做的是“视角转换”或者说“站在对方的角度”去思考问题。

作为技术/产品/服务/项目供应商，我们不可避免的会先入为主的基于我们对任务的理解，去分类任务、定义需求。但是，一定要清醒的意识到我们努力工作的目的是什么，即：为谁提供服务的问题，套用一句前段时间某综艺节目中“爆红”的一句话：我不要你觉得我要我觉得，我们的认知因该是：我不要我觉得，我要用户觉得。当然，最理想的状态就是能开启“上帝视角”，站在更高层面去思考需求与任务分类。

另外，对于“防守型需求”虽然在我们的计划中，可能会考虑将优先级定义为较低。但是，一定要首先想明白这个问题之后再做最终决定：这类需求不及时实现，我方会在市场竞争态势中失去什么？

认知客户场景

不管我们的目标是做一个通用化的产品，还是定制或半定制化开发去交付一个项目，我们的目标都是“Shift AI Models to Real World”。要能让我们机器学习训练的模型在用户场景中发挥作用，首先我们需要做的事情就是：认知并理解客户场景适用的算法模型特征是什么。

虽然，深度学习的引入使得特征工程显得并不那么重要了，我们只要把数据标注好，丢进DL拿到训练后的模型就可以做inference了。但是，客户实际场景和我们之前丢进DL的数据看起来是差不多的，解决就能保证满足需求么？举一个例子。

案例

在之前的项目中，我们有一个需求是“集装箱号OCR”。OCR这件事情，看起来现代技术已经非常成熟，各厂商提供的OCR API有很多可选用，还有什么难度呢？

最理想的状态下，我们可能是在这种角度下进行集装箱号的OCR。

实际上可能是这样的俯仰角度：

还有可能是这样的竖排或者不在一个平面：

也有可能不在一个平面还会有残缺：

大家有兴趣的话，可以拿这些图片丢到各厂商的通用的 OCR 中测试下效果。

可以看到这个任务虽然是一个OCR任务，但是由于客户场景的需求，导致了这个任务并没有听起来那么容易：

关注的是集装箱号的OCR识别，但集装箱上有很多文字，别的文字提取并OCR是无意义的
集装箱号在多个位置都有喷涂，不同位置OCR难度不同
集装箱号的喷涂形式、字体，并无行业标准，仅有默认共识
无法提前预判集装箱哪一个面会对准监控摄像机
通用的OCR数据集并不能取得很好的预测效果
……

对于这样真实客户场景，你说我有OCR识别算法，就能“搞定”项目交付么？显然可能性不大。有关这个任务的具体思考与落地实现，可以参考我另外两篇文章：

Container detection and container number OCR

使用Tesseract训练并识别集装箱号

正如我在Container detection and container number OCR中提到的，对于这个特定的OCR任务，其实就是26个字母+10个数字识别问题，做一个36分类的目标检测其实也是可以搞定的。放一张用Yolo v3目标检测方式实现的“OCR”效果(图片来源：长春理工大学崔循硕士研究生毕业课题论文准备阶段的实验结果)。

认知客户场景的几个关键思考

通过上面例子中的介绍，我们可以看到一个“OCR”任务，在最终交付落地的时候，其实变成了“目标检测+OCR”或者“目标检测+目标检测”的ML模型实现，与最初销售带回来的需求“客户需要一个集装箱号的识别”相比，事实上是做了任务扩展与定制化模型训练的工作。那么，我们在接到一个“任务”后，应该如何去结合用户场景去思考任务的真实需求呢？

个人觉得这件事，并不一定会有标准答案和指导手册，需求的不同，客户的不同，任务来源的不同等因素都会影响这个“场景认知”的过程和方法。但是，个人认为有一些通用的方法是可以借鉴和采用的。

熟悉客户业务

熟悉业务，这句话简直就是废话，不熟悉人家的业务，怎么去理解业务，理解场景？所以，正确的废话也很重要。

在To B/G 领域，一个重要的核心竞争力就是：对用户行业与业务的熟悉程度。熟悉并理解客户的业务最大的优势就在于对于AI落地这件事情，我们只需要去关注如何结合用户现有的业务活动，将AI创造性的“嵌入”现有业务过程中，并发挥一定的价值。但是，对于大多数AI创业公司、新玩家，内部基本上都没有此类业务专家，所以要么去行业内传统软件公司去挖人，要么与这些公司合作。其实就是一句话：

各行业领域的传统软件公司看起来做的事情比较“土气”，在现阶段要想算法落地，没有这些公司的参与或者这些公司培养的行业专家的参与，AI创业公司们要想算法落地，基本玩不转，且付出的代价也很大。

理解对方语境

新手项目经理或者咨询顾问最容易犯的错误之一就是：以为自己听懂了用户表达的需求。

对于to B/G 的项目，这种情况尤其容易发生，一方面要学会听懂话外的意思，另一方面要明白对方的立场和对项目的想法，而且还要参考对方说出需求的场合。有关这个问题，是比较复杂和考验对人性、管理、体制以及权力的认识的，要展开的话，这一个主题就可以写几万字了，所以此处不再继续展开说明，仅做一个提示。

举一个例子：

背景：刚工作不久做菜鸟项目经理的时候，去做需求调研，有一个业务流程，涉及到三个部门间的流转和处理。用户方安排的是逐部门需求调研，同样一个流程，主体虽然解释的都一致，但是在三个部门间听到了三种不同的细节处理方式和要求，而且每个部门都告诉我，听他们的没错：“就按这个做”。不得不说，抽烟这件事情有时候真是好事情。不小心在吸烟室遇到了三个部门负责人都在（两个来吸烟，一个不吸烟但是跑过来休息），于是就把我对这个流程的疑惑说了一下（当然作为曾经的学生会主席，我不会傻到乱说话），只说了我理解的主体，和三个部门都说的一致的内容，而有差异的部分只字未提。结果不出意料，三个部门在一起说的时候，就不能有明显的对自己这边有利的倾向性了，于是我算是得到了第四个版本的需求。隐约觉得这样的“非正式沟通”拿到的需求，虽然各方都能认同，但是很可能“并不是他们真实意思”的表示。但是，一个小菜鸟就算觉得有问题，也不知道问题在哪里，怎么去理解背后真实的东西。年轻和菜加在一起最大的好处就是“愣头青，不怕死”，于是我凑了几个疑问后，找机会冲到人家分管副总的办公室去做“需求调研”了，结果并不意外，拿到了第五个版本。