项目实例分析：大家一起来“找茬儿”

本篇文章借用项目实例进行找问题和做分析，然后分为产品管理和项目管理两个角度进行总结。

项目管理的考试中，有这样一类题型，我们俗称“找茬儿”题。题目要求是，简述一个项目管理的实例，让考生在整个案例中找出问题并进行分析。

今天，我想借用这种形式，以一个完整的TO B产品的研发过程作为实例，和大家探讨一下，在产品设计、研发的过程中，容易出现哪些问题？从 产品管理 和 项目管理 两个角度剖析一下这个“集大成”的失败案例，是如何一步步走向失败的？

案例详情如下：

某单位智能线索发现系统

某日，公司（该公司为人工智能领域的高新技术企业）副总找到产品经理安迪，告诉他公司要研发一个针对环保类问题的线索发现系统，环保部门有潜在用户正在接触。安迪在接到了任务后，像领导咨询了产品的应用场景、核心需求等背景资料。

对方痛点是 “在进行环保监管的时候，难以及时发现有效的线索。”

经常出现，主管领导都看到了某些信息，而该部门还没有发现；或者发现问题后去实地调研的时候才发现，证据早已经遭到破坏，难以取证、实施处罚。所以希望采购一个智能线索发现系统，能够自动采集互联网中的海量信息，利用机器学习的方法针对海量数据进行甄别，筛选出有效线索，推送给工作人员。

安迪获得了对方提供的一些相关资料，如下：

1. 少量以往发现的网贴线索；
2. 工作人员平时重点关注的几个网站；
3. 部分搜索关键词。

安迪在研究资料时发现，对方提供的关键词，专业术语比较多，有些通过字面意思也难以理解，不过他也并未深究。

由于业务需要，boss要求必须在一个月内完成产品的demo，指派了参与该项目的技术负责人担任项目经理，其他成员包括前端、后端工程师、算法、UI设计参与项目。

接下来，安迪开始了原型设计以及PRD文档的写作。经过了几天的忙碌，安迪产出了产品的初版原型及需求文档，产品主要包含如下功能模块：“信息采集、筛选、传播分析、自动预警、生成简报、用户管理”等几大部分。其中，在数据获取的环节，直接采用了对方提供的关键词信息和采集网站。

随后，项目组进行了内部评审，产品经理整体讲解了该系统的应用场景、设计理念以及整体的交互逻辑等等，会上，项目组成员针对产品原型和PRD文档并未提出太多问题。最后，会议决定，砍掉了诸如传播分析等实现难度比较高的功能，以确保在1个月内完成产品demo。

项目经理针对工作任务进行了分解、排期，给出了初步的项目管理计划，报送给领导，择期进行了公司管理层的产品及项目评审。领导在初步方案的基础之上，提出了不少修改意见，需求调研及原型输出的结果不太满意。

又经过了一系列的修改，产品进入了研发阶段。在此过程中，研发同学开始不断的提出各种问题，例如信息筛选的具体规则存在冲突；导出文本的样式、模板；关键词搜索的匹配问题；权限管理中的细节问题等等接踵而至。

产品经理经常需要穿梭于前端、后端的工位之间，解答各种问题。其中，部分问题是在原型和文档中已经明确标识的；有些问题是由于表述不清，研发同学理解存在偏差；有些问题是在UI进行设计的过程中，没有完全按照原型及需求文档的功能要求，遗漏了某些功能点；有些问题则是产品设计的逻辑漏洞。

有时候，产品经理与研发人员达成口头协议修改了需求，但是并没有在文档及原型中体现出来；有时候修改了文档，但却没有修改原型；在一些涉及产品逻辑的修改中，由于受到当前系统架构的限制，在功能上不得不做出调整，或者降低相应的要求来契合当前的情况。

在这个过程中，管理层也时常提出一些新的需求，并且要求在此版本中做出调整。产品就在不断的调整与妥协中艰难前行，在这过程中，还出现了前端无法胜任工作的情况，分配的任务屡屡无法按期完成，给其他成员的工作带来了很大的不便，拖慢了整体的研发速度。

产品的基本功能研发告一段落之后，测试介入项目，每天禅道之上都会提出很多的bug。从样式到核心流程，种种问题暴露出来，在测试过程中，测试同学还要不断的和产品经理核实需求，因为有些需求已经修改，但是需求文档内没有体现；有些关于系统中的极端情况，在设计过程中没有进行考虑；有些功能因前后端的技术限制只是实现了其中一部分等等情况，不胜枚举。

时间就在不断的抱怨、反复修改中过去了，虽然同学们每天都加班加点的奋斗，但是工期还是不可遏制的超了又超，以至于前期规划的所有功能并没有如期完成，再一次的压缩精简之后，发布出了第一个版本。

在将该版本提交给客户之后，对方给予如下的回应：

1. 采集到的垃圾数据过多；
2. 相关数据的地域分布不准确；
3. 存在大量重复信息；
4. 针对数据的筛选交互体验较差；
5. 数据不完整；
6. 信息的更新不及时等等情况。希望可以针对以上问题进行修改。

接下来更戏剧性的一幕出现了，公司由于其他项目人手紧张，经过评估，该项目需要进一步缩减人手，不在持续投入人力进行迭代了。所以，后来针对筛选信息的算法一直成为制约项目进行的瓶颈，对方一直不满意，所以也就迟迟没有立项的意向……

故事的结尾是这样的，又进行了一段时间反复的修改和接触以后，当时积极推动该项目的领导离职，公司对于项目进行了重新的评估，认为当前的算法能力对于完成核心任务有一定的差距，对于系统能够实现的结果持悲观态度，并且认为应用场景过于狭窄，决定项目暂时搁置……

the end

接下来，我们从产品管理和项目管理两个角度，针对项目中的问题进行梳理、分析，看看这个项目到底败在何处？又能从中吸取何种教训？

一、产品管理

1. 任何一个产品或项目，在立项之初，要解决的最重要的问题如下：① 需求、应用场景是否明确？② 核心痛点是什么？③ 市场覆盖面有多大？④ 竞品的情况如何？⑤ 我们的产品有哪些优势，壁垒有多高？在这些问题未解决的情况下，轻易投入研发，风险会非常大。
2. 需求分析阶段亦存在明显的缺陷，既然“要求一个月内完成”，则必须要围绕用户的核心痛点进行设计，一些旁支、辅助的功能，例如“自动预警、生成简报、用户管理”等则大可不必急于开发。看似功能强大，实则没有抓住用户的核心痛点。
3. 产品设计缺乏整体规划，科学的做法是围绕着用户的核心需求和痛点，设计出产品的整体结构和功能脉络，在提交MVP版本的同时，也为用户提供产品整体规划和迭代的方案。告诉用户，在此基础之上，我们后续还能满足哪些需求，这种方式即可以进一步了解对方的需求，又可以增强客户对我们的信心。
4. 在案例中，产品经理直接采用了对方提供的关键词信息和采集网站。并未对客户提供的内容进行深入分析，例如：① 提供的数据源覆盖面是否能够满足需求？② 爬取数据时，是否存在难度？③ 网帖线索作为标注数据，是否能够满足算法需求？④ 以现有关键词作为爬取数据的手段，是否能够获取到有效信息？对于上述问题都未能进行深入的了解，就造成了最终的垃圾数据过多、数据不完整等等情况，为产品失败埋下了伏笔。
5. 安迪应该在获取信息不足的情况下，主动与领导及客户方沟通，以便进一步获取信息，例如：可以到该部门针对业务人员进行实地调研；请对方派人支援数据标注；或是请行业专家提供行业背景知识。
6. 在进行管理层评审之前，产品经理最好为重要的干系人单独汇报一下产品的设计意图和功能脉络，以便取得初步的意见统一，这样在评审会上的压力就会相对减少。
7. 在产品发生任何需求变更时，都要在原型及需求文档上面体现出更新内容。在修订记录上也要呈现，以便研发人员查找。日常工作中，产品经理总是抱怨，研发同学不看需求文档。洋洋洒洒几十甚至上百页的需求文档，对于研发人员来说，确实是个不小的负担，所以我们在书写文档的时候，要尽量做到简明扼要。
8. 设计产品的过程中，一定要明确近期目标和长远规划，要使产品的系统架构满足未来扩展的需求，不能每次开发都推到重来。

二、项目管理

1. 项目经理由技术经理兼职存在问题，项目经理需要兼顾各方的情况和利益，通过不断的平衡和取舍来达到最优组合，以便更为高效的完成任务，技术经理虽然在技术方面存在优势，但往往在项目管理方面缺乏经验，在未经专业培训的情况下，是很难胜任项目经理工作的。
2. 在产品需求不明确的情况下便指定了项目组成员，存在较大的风险。很可能会造成资源与需求不匹配的情况。项目经理要针对项目组成员进行技术能力方面的评估，以便了解组内成员是否能够满足需求。对于关键岗位还要有储备资源，以便应对人员变更的风险。
3. 在项目内部评审时，相关的技术人员未能深入、透彻的了解产品的功能需求和交互逻辑。以至于在后期的开发中，还需要不断的和产品经理确认需求。在评审阶段确认需求的重要性是不言而喻的，这时需求调整的代价是最小的。所以最好在评审之前一到两天的时间，把文档和原型给到项目组成员的手中，每个人在这期间都要仔细研究自己职责范围内的问题，发现其中的问题、是否存在技术难点？工期内是否能够完成？
4. 通过正式评审的产品原型、需求文档以及项目管理计划，应该请相关领导签字确认，以便规范后期的需求变更。
5. 在输出UI设计稿或者测试计划的时候，都要有相应的评审，以确保视觉设计、测试计划满足产品功能，真实、完整的体现了产品需求。
6. 需求变更对于IT项目来说，几乎是无可避免的，所以在处理变更请求时一定要慎重，项目经理需要对变更的影响、进度、成本、效果等情况进行综合分析，以确定是否执行变更。不能一味的迎合领导的需求。
7. 测试应该在项目立项之初，就参与其中，根据文档和原型，撰写测试计划，要对产品的功能、架构做到充分了解。测试完毕之后输出测试报告。

好了，针对这个虚拟项目的分析就告一段落了，希望我的一些观点能够起到抛砖引玉的效果，欢迎小伙伴们提出一些更有建设性的意见，大家一同探讨、共同进步。

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

题图来自 Unsplash ，基于 CC0 协议目标和长远规划，要使产品的系统架构满足未来扩展的需求，不能每次开发都推到重来。