AI 项目落地应用指南--3.机器学习项目团队组成（上）

为什么需要讨论这个问题

机器学习已成为下一波技术红利的基础，这一点已有很大的共识。机器学习领域创业团队随着时间的推移与发展，已经逐步表现出对于现金流和利润的渴望，有强烈参与到政企领域市场项目的动力与意愿，但或许会乐观的认为：只需要再配备“产品经理、前端开发、后端开发和销售”就可以完成软件产品开发，参与到政企市场的项目竞争。

机器学习由“Technical”向“System”转化过程中软件工程与技术层面存在的潜在问题，在 NIPS 2014 的《Machine Learning: The High Interest Credit Card of Technical Debt》文章中做了论述：

“Machine learning offers a fantastically powerful toolkit for building complex systems quickly. This paper argues that it is dangerous to think of these quick wins as coming for free. Using the framework of technical debt, we note that it is remarkably easy to incur massive ongoing maintenance costs at the system level when applying machine learning. The goal of this paper is highlight several machine learning specific risk factors and design patterns to be avoided or refactored where possible. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, changes in the external world, and a variety of system-level anti-patterns.”

– （Reference：Machine Learning: The High Interest Credit Card of Technical Debt）

在 NIPS 2015 的《Hidden Technical Debt in Machine Learning Systems》论文中，对此问题进行了进一步讨论。

在上述文章中有一张配图，能更直观的让我们感受到 Technical 与 System 之间的巨大差异。

在上图中可以看到：“Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small black box in the middle. The required surrounding infrastructure is vast and complex”。（-- Reference：Hidden Technical Debt in Machine Learning Systems）

除“Technical Debt”之外，考虑到政企领域项目的特点，市场“新玩家”对于行业的认知、业务解决方案的理解与设计，以及项目管理、交付能力等非技术的“软实力”的欠缺与“短板”可能更难以意识到。

所以，在机器学习团队的组建过程中，我们需要具有系统的工程化思考方式与角色设定，以尽可能的避免“技术债务”与“软实力欠缺”引起的潜在的“技术灾难”与“交付灾难”。

机器学习团队基本角色

考虑到本文主要探讨的是机器学习项目，所以对于 Traditional Software Engineering 部分所涉及的不同角色，如：架构师、UI、UED、前端、后端、移动端及功能测试、自动化测试等，全部合并为“Software Develop Engineer”（SDE）进行指代。

基于上述前提，机器学习团队的角色划分建议如下表。

1. Product Manager

机器学习算法由一项“技术成果”转变为可落地交付应用的“产品”，实现满足客户功能需求的同时，在可接受的指标范围（精度、速度等）内稳定交付运行这一商用目标。产品经理是这个过程中极其重要、不可或缺的一个角色。

首先，抛开机器学习领域相关的内容，简单分析下产品经理要高质量完成产品需求定义工作，需要关注哪些内容：

• 需求挖掘：如何发现“潜在”需求，很多时候“隐性需求”或更有价值。

• 需求判断：如何识别“伪需求”，驱动需求产生的“本质”是什么。

• 需求分析：需求背后的“动机”是什么，需求的“场景”是什么，需求的“因果链”是什么。

• 用户识别：是否找准了“真实”用户，“典型用户”需求是否具有“普适”性。

• 价值分析：需求实现对用户、产品的价值，产品实现后对用户的价值。

• 风险分析：需求实现的代价、周期及需求消退周期。

洞察力对于产品经理来说，是一项非常重要的能力与软实力。如何去考察一个产品经理洞察力？似乎没有比较科学的“先验知识”，大多只能通过产品结果去做后验，所以产品经理的招聘工作并不容易。产品经理又该如何去提高洞察力呢？似乎是没有捷径的，只有对目标领域做深度认知，不断思考、深度思考，反复推演。

特别的，对于深度学习的产品经理，还需要对一个非常重要的问题进行思考：

模型预测错误的后果是什么？

1.1 主要工作内容

• 需求调研，需求分析，产品设计

• 产品解决方案定义

• 项目解决方案定义

• 产品开发过程管理

1.2 主要工作产出物

• PRD

• 产品白皮书

• 项目解决方案

• 产品开发交付

有关产品经理的工作难度与挑战，在第四章进一步详细说明。

2. Project Manager

当我们完成产品开发（有可能产品还是半成品或者仅仅是 MVP）向政企客户成功销售后，那么项目就需要正式启动了。如前一章所述，项目经理需要完成：管理、协调、控制、交付等项目生命周期内的工作。事实上，在实际操作层面，大量存在“以项目养产品”的情况：，大致解释一下。

公司在某些技术领域，比如“人脸识别”、“车辆识别”、“语音转文字”、“目标检测”等技术方向取得了比较好的精度，基本达到或者超过了 SOTA（State-of-the-art）水平，具有商业化落地应用的可能，也会有一些行业客户咨询相关技术的应用情况，更坚定了商业化信心。那么如果去实现商业化的产品？而做为技术驱动的公司，大概率是没有相关完备产品与行业解决方案储备的，所以需要在政企客户市场小步快跑，走“捷径”，快速形成产品、解决方案与产品矩阵。基本过程（套路）如下：

1 - 对照客户需求，在行业对标寻找竞争对手现有产品与方案内容组成、产品架构以及核心功能；

2 - 解决方案团队与产品经理团队共同“定义”针对用户需求的，具备足够竞争力的解决方案思路；

3 - 将上述解决方案思路，转化为高水准的产品或解决方案 PPT；

4 - 基于公司技术积累、现有产品，结合用户核心需求，快速完成 Demo 和 MVP 的开发；

5 - 如一切顺利，拿下项目后，组建项目团队，在项目团队中会特别安排产品经理与解决方案团队成员组成“需求团队”；

6 - 结合合同内容要求，现场用户需求调研获取的一手需求，行业竞争对手的产品功能，项目经理带领“需求团队”，完成既能满足项目交付，又足够具有行业通用性的“产品需求”（这是理想状态，在实际操作中各中痛苦，冷暖自知）；

7 - 需求团队与架构团队共同讨论确定三件大事：产品基础/通用/支撑功能，产品特性功能，项目功能，基于这种认识开始架构层面设计与技术路线选择（强调一下，项目是有时间限制的，不能为了追求“理想”忽略了进度。）；

8 - 研发团队快速完成在 master（Dev）分支完成第一部分基础和通用功能开发；然后分支出“pd-xx”进行项目所需的产品特性功能开发，测试合并入 master 后；分支出“pj-xx”进行项目功能的开发。在项目开发未完成前，产品分支的开发依然是服务于项目的，以便快速合并；

9 - 事实上，单一客户的需求必然有一定片面性与局限性，在做项目开发同时，需求团队需要进一步研究行业需求，快速对产品部分的需求做出更新与完善；

10 - 理想状态下，项目交付后，在我们的版本控制系统里就有一个完整的项目版本和一个基本成熟的产品版本，这样就实现了 以项目养产品，同时最大限度的降低了研发周期与成本。

不要以为下周回国的贾老板是 PPT 造车高手，政企领域大玩家都是 PPT 做产品高手。看到没有，“先有鸡还是先有蛋”的问题，可以解决为“鸡和蛋”一起有。

产品经理和项目经理分别做为产品和项目的“总经理”，是实现技术到产品到落地交付的最核心的中坚力量。这两个岗位的职责一部分是清晰可区分的，一部分又是重叠和需要共同协作完成的。

我相信，在深度学习这个领域做政企市场落地的公司，大都存在这种以项目养产品的实际操作。所以，对项目经理除了要求项目管理能力外，还需具备产品经理的“产品感”与“洞察力”，这也是为什么在本文中我会把项目经理的相关工作内容与产品经理合并在一起去说明的重要理由之一。