3.19. 项目管理¶

3.19.1. 项目与产品的关系¶

分而治之的软件需要通过集成方式整体交付，软件的生产过程也是一个多人、多组织协作的过程，也需要集成。把软件看成是一个产品，产品就有策划、研发、运营和退出各个阶段，每个阶段可能由不同的人或组织完成。软件的研发阶段就是一个一个项目的实施过程，包括立项、执行和完工。这样的过程组织起来，就是一条软件生产的流水线。从早期瀑布式的软件研发，到后来敏捷研发过程、CMM，到目前风头正劲的DevOps，都是在解决软件生产流水线不同阶段的协作问题，敏捷针对软件定义、设计、构建（开发）阶段的协作，持续集成是构建（开发）与测试阶段的协作，持续交付是从定义阶段到部署（交付）阶段的协作。

Fig. 3.19.1 项目与产品的关系8¶

3.19.2. 定义¶

PM能在产品的整个生命周期中，进行产品迭代的规划、各类资源的整合（协调团队各成员）以及生产进度的把控来保证在预算内按时交付产品。 2

包括：

确保资源投入
制定项目计划
根据计划跟踪项目发展
辨别关键路径
必要时争取追加投入
向主管报告项目进展情况18

3.19.3. 最简单的项目管理¶

立项—>需求—>开发—>测试—>发布 5

Fig. 3.19.2 用Excel管理项目19¶

文档管理——流程管理——敏捷方法

3.19.4. 整体流程¶

Fig. 3.19.3 整体流程图16¶

3.19.4.1. 开发细节¶

第一次内测→第二次内测→SIT内测→UAT测试→试运营→上线跟踪。 7

第一次内测，主要由研发人员自己开发并验证；
第二次内测，主要是研发提交给测试人员进行测试，并将bug打回，让研发人员重新返工；
SIT测试，系统集成测试 (System Integration Testing ) ，由于不同模块是由不同人开发，当他们汇总起来，有可能出现问题，需要进行检测；
UAT测试，用户验收测试(User Acceptance Test)，也就是用户可接受测试，这个阶段基本上都是由产品经理主导，用户最开始拿到产品是不会使用的，这时候就需要产品经理当着用户的面去演示。
试运营，这个环节也有产品经理参与，当产品上线之后，找一两个核心人员去用一用，觉得没有问题后小面积用户使用确保产品没有问题。慢慢替代原有业务，把原来的业务淘汰使用现在的产品。
产品经理首先得制作操作手册，培训用户使用，主要教会对面负责人，让他们自己去使用，了解产品。
上线跟踪
产品上线后，要准备相关资料，真正的外包项目靠售后服务挣钱。
以后有任何小需求小功能都会找你，卖给他们的软件售后问题都可以找你，对方公司直接给售后费，后期服务对方，所以这种产品赚钱在售后方面。

3.19.5. VS Project Manager¶

产品和开发的是同样的团队和同样的人，但在驱动产品和驱动项目这两件事情上，最好还是有所差别。至少产品更关注的是产品、功能、方向和反馈；而项目则更关注进度、质量和测试等。

做好评估。几乎所有项目最终未按计划执行，其最根本原因就是在项目开始阶段，没有对需求、技术、产品有足够充分的了解，也就没有后续开发中的可控力度。高估和低估都是有问题的，所以我们常用的做法就是非常重视前期的评估，宁愿多花时间，并且对有模糊边界或者有挑战的问题，留足buffer。
将计划落实到可执行的单元和可执行的人。有了评估，然后就是将计划落实到足够力度的任务，以任务驱动开发过程，任务落实到责任人，任务要标明截止日期。在此，通过一定的工具来管理，是十分必要而可控进度的。例如我们基于自主产品PingCode 的任务驱动方式，就可以很好的将开发计划落实到任务和可执行的人，以直观的方式来告诉负责人项目整体的状态、执行者的情况、被delay的事情有哪些。总之，工具的辅助需要团队开发想法的驱动。(再多说一句：PingCode不仅可以进行以上的项目管理，还覆盖了项目、任务、需求、缺陷、迭代规划、测试、目标管理的研发管理全流程。)

3.19.6. 各个级别的产品¶

按照初、中、高级产品来理解：

初级产品可以把控项目进度，对暴露出的风险或问题能及时解决。
中级产品可以把控项目的整个进程，规避各种风险，并保证项目可以按时上线。
高级产品可以在前期预判到后期的风险问题，在设计阶段就将这些问题有效解决；并可以预留时间解决各种突发问题，保证项目按时上线或者提前上线。

项目管理也可以理解为组织协调能力，产品经理需要把控项目的整体；前期需要对版本进行管理，开发过程中需要答疑业务问题，开发结束后需要对测试过程进行管理；有时间的自己也需要参与主流程测试，主要是为了验证需求是否被很好地实现。20

3.19.7. 项目立项 15 ¶

目标是什么？极为关键，见BRD
背景是什么？即“为什么做” 交代清楚项目背景，见BRD
内容和范围是什么？即“要做什么”了解项目边界的，见BRD
结果或KPI？即“如何证明做到了” KPI：问题发生率的降低？成本的下降？收益的增加？
执行的基本思路和方案？即“怎么做”：见MRD，让评审人能知道未来的执行方向和策略
里程碑&计划：拆解项目的关键节点，并用项目管理软件分解好每个里程碑下的工作计划
职责与分工：明确产品方案、分工职责、项目排期、 Review 周期 4
资源需求：人，财，物（服务器的资源？硬件的资源？市场的资源？）
风险控制：分析可能失败的原因中提前控制、不可控的因素

3.19.8. 制定项目计划¶

明确好目标之后，就可以根据具体的，可量化的方案组织相关的干系人来评估工作量，根据工作量倒排项目计划表，将目标拆解到更小的时间颗粒度，并指定相关责任人进行任务跟进，如下图所示。

Fig. 3.19.4 项目计划¶

在这个阶段需要明确各个环节的交付产物，并识别可能的项目风险，提前制定风险应对计划，例如本公司缺乏某方面的数据，需要从外部获取，或者相关人员配置不足，需要招聘或借调人力资源的支持等等。在项目进行的过程中持续监控，以确保项目的正常进行。14

3.19.9. 周报 6 ¶

写好周报的重点在于方法论建设，知识传承的核心在于能够真正用到实际工作中且可以快速复制。而周报本身就是基于自身工作的且与团队成员有极强的契合度，因此更容易引起共鸣，产生实际的价值。产品经理切记，从入职的第一天起就要启动周报的知识传承。下面为大家提供一个周报模板。

Fig. 3.19.5 周报模板¶

这周的工作内容是推进A项目，下周还是推进A项目。如果项目一直被卡住，等到了写周报的时候似乎就没得可写了。总不能一直写“规划某个需求”，“设计某个产品”，“推动某个项目进度”，“整理某个产品的文档和资料”等……17

3.19.10. 开发看板¶

Fig. 3.19.6 开发看板12¶

在开发需求的过程中，各需求的相关人不用再去寻找邮件，或者翻看电脑保存的文档。

每个人都可以通过看板，看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如，测试工程师就可以通过看板，大概预知有多少卡片在待测试状态，从而预估自己的工作量。

3.19.11. 算法项目管理 6 ¶

算法项目不同于应用研发项目，研发功能上在一定周期的配合后，团队内部对于可行性方案、研发周期、最小可执行单元会逐渐达成共识，项目评估后可以有明确的启动和结束节点。

算法项目更多依赖算法团队的学术和工程能力，对于算法团队未执行过的领域项，算法同学一方面会对数据提出过高的要求，另一方面对于可执行的效果情况也往往不能作出很好的评估。业务的时效性和算法的可行性上往往存在着代沟

3.19.12. 项目管理知识 10 ¶

软件工程推进过程中，项目管理相关的技能方法与工具运用也非常的关键。其中各种研发流程与规范，例如敏捷开发，设计评审，代码评审，版本管控，任务看板管理等，都是实际项目推进中非常重要的知识技能点。这方面推荐学习一本经典的软件工程教材《构建之法》，了解软件项目管理的方方面面。进一步来说广义的项目管理上的很多知识点也是后续深入学习的方向，可以参考极客时间上的课程《项目管理实战20讲》。

3.19.12.1. 项目延期怎么解决的？怎么避免项目延期？ 13 ¶

3.19.12.1.1. 项目延期怎么处理？¶

了解情况：了解不能按时上线的原因及需要延期多长时间上线；
知会需求方：确定影响范围，知会需求方，讨论解决方案；
确定解决方案：协调资源加班解决；或者砍掉非核心功能保障上线时间点。

3.19.12.1.2. 怎么避免项目延期？¶

保障产品文档质量，避免需求变更导致延期，前期沟通评审功课做足；
合理评估时间，设置任务里程碑，每天过进度，及时发现风险点；
建立一个内部网络空间，所有文档资源统一存放，供团队成员共享；
利用即时聊天工具，建立一个项目群，每天通报项目进度;建立项目邮件组，所有变更达成一致后，发送邮件确认；
制定制度和标准，实行奖惩措施，制度和标准及其重要。

3.19.12.1.3. 自我考核¶

在某个负责项目中运用项目管理方法，完成一个实际的需求评估，项目规划，设计与评审，开发执行，项目上线，监控维护流程，并对整个过程做复盘总结。

3.19.13. AI相关¶

AI算法→AI工程→AI服务→AI应用 9

AI算法：就是大家平常理解的算法模型。
AI工程：因为解决一个实际问题中会涉及到多个模型的处理，多个模型之间如何协调、调用就是AI工程化要做的事情。（以CV为例，可能会涉及到去噪、编码、几何变换、增强、边缘检测、图像分割、特征提取等等）
AI服务：把AI工程化的输出能力以服务的方式提供出来，比如大家常见的公有云API调用的方式、Docker私有化容器部署等。（服务形式会根据提供的AI能力会有所不同，比如百度的OCR通用识别模型，还会带有标注、训练等功能）
AI应用：利用已有的AI服务能力结合实际的业务场景，输出用户价值。

我们需将AI部署作为一个有生命的系统，与传统的IT项目相反，人工智能项目是活生生的、会呼吸的解决方案。它们在部署的几乎任何阶段都不是静态的或不可预测的——特别是在新奇的用例中。11

生物学类比:发育阶段——并非所有新生动物都能达到成年。动物竞争、食物短缺和环境变化对生存构成了挑战。一些动物成年后仍然需要食物和住所，但不再需要父母的持续关注。成年期可以被视为人工智能部署的第三个阶段;一旦到达，AI项目仍然需要基本资源，以保持正常运作，直到项目结束。

构建一个人工智能应用程序不是“即插即用”，而是指照顾一个有生命的东西，伴随着不断增长和各种各样的需求。

换句话说:

人工智能不是IT
人工智能是概率性的，而不是确定性的
人工智能更像是研发，而不是软件
开发一个人工智能应用程序就是让生命成长并照顾一个有生命、有数据支持的有机体

3.19.13.1. AI阶段¶

Fig. 3.19.7 企业AI部署的三个阶段¶

一个人工智能应用程序要经历三个阶段。与数据科学生命周期不同，应用程序在部署阶段中向后移动是不常见的，而且——理想情况下——这些阶段不是循环的，而是线性地进行。

对于人工智能项目领导者来说，完全理解使一个人工智能项目变成现实所涉及的技术细微差别并不重要——但对于项目领导者来说，在进入一个人工智能项目时，他们应该期待自己能够小心地通过所有这三个阶段，这才是重要的。过程的各个阶段都有独特的里程碑和目标，并允许项目团队避免匆忙集成的风险，并且有足够的时间进行迭代和修补应用程序。缺乏这个框架的团队将很难评估完成一个项目所需的努力，也很难看到项目顺利部署。

3.19.13.1.1. 概念证明(PoC)¶

目标——确定人工智能是否能在一个业务功能中(通常是在一个有历史和测试数据的“沙箱”环境中)提供特定的好处。

挑战-决定正确的数据和特性来训练。选择具有足够高的潜在业务价值的问题。

在一个孤立的“沙箱”环境中进入下一阶段的标准(应用程序证明它能够显示有希望的结果——达到一些预先定义的成功标准)。

例子1 -电子商务公司采用产品推荐引擎。假设孵化期有了丰硕的成果，团队接受了新的人工智能相关流程的培训——推出推荐引擎作为默认用户体验，有大量团队致力于测试和调整推荐算法，并收集对结果的反馈。

例2 -一家采用预测分析应用程序的制造公司。假设孵化期取得了丰硕的成果，团队接受了与人工智能相关的新流程的培训——在所有特定类型的机器上安装传感器和连接器，创建一套中央仪表板来监控机器，并由专职人员维护和改进它们。