成长思考：做产品还是做项目？做交付还是做迭代？

Chihiro 2023-08-08 04:44:57

一、背景

毕业后在一家中型互联网公司某部门就职产品经理岗位，部门以公司产品为开发平台，承接各种数字化转型项目，以项目经验孵化各行业普遍共性问题的解决方案。入职以来，日常工作内容为需求调研、需求分析、产品设计、跟踪开发、产品测试、用户反馈与功能迭代、实施与交付。

二、问题

由于团队人员配比不足，无法细分职责到具体岗位，每天面对多而繁杂的各种事，难免会产生疑问：明明是产品经理，为什么感觉大部分的时间都在做非产品经理的事？做这些事有没有意义？

三、经历

1. 了解公司，了解部门、了解项目、了解团队

公司是一家传统的面向工业行业的互联网企业，客户对象大多是重资产流程性行业，而部门某种意义上可看作公司的外包，专门负责啃硬骨头，负责处理时间紧、任务重的项目，若人手不足，直接调配外包人员来堆叠人力，因此部门的人员流动较大，工作交接过程中信息损耗程度极高。

可能是由于上市盈利和经营范围要求，公司承接了一个集成化大型系统中的陌生领域的B to C子系统，项目特点是上线时间要求急，开发任务量大，合同范围边界不清晰，需求模糊，用户的数字化水平低，决策分散等。

项目从立项至终验经历了整整2年时间，大概时间节点为2021年1月-4月项目立项、调研；2021年5月-7月项目开发，部署；2021年8月-10月修补功能，初验；2021年11月-2021年12月完善功能，产品上线；2022年1月-2022年9月产品优化与迭代；2022年10月项目试运行结束，终验。

由于人员配比不足，研发组长由于主要精力都在项目中的C端方向，所以默认B端方向由我单独来安排计划与分配任务，在团队中兼任项目经理、产品经理、测试、交付与实施的角色，即除了写代码，其他工作均是我来完成。历经一年多时间，在只有不到1.5个开发人力的情况下，系统按期上线，并保障稳定运行10个月。

2. 区分客户、区分用户、区分项目、区分产品

1）选型失误，举步维艰

项目开发与优化周期接近18个月，经历了多次返工及功能迭代，导致原本12个月的工期延长到了18个月，究其原因，工作到产品经理层面的时候很多前置工作已经确定，根据招投标文件确定好技术架构，领导层面出于种种原因会根据功能清单及标书要求选择合适的开发平台。

但是领导也有预估不到的情况，有时也会判断失误，因此再决定技术架构及产品选型之前的技术讨论将是启动前期需要仔细论证及决策的，否则项目一旦启动，地基开始搭建，后续更改技术架构几乎是不可能的事项。

评审需求时经常遇到开发的答复说实现不了，某些功能依赖于技术平台，平台不支持的功能，他们也没办法，大多数人不想做第一个吃螃蟹的人，不想去通过自己写代码实现某些定制化的需求。而一些需求又确实不能妥协，通过现有的技术平台又无法实现，产品和研发之间就差打起架来，功能上线寸步难行，

2）五脏不全，效率低下

一个合格的团队是由项目团队、产品团队、开发团队、测试团队、UED团队等组成。在项目制为主的公司里，构成往往不会这么全，实际情况往往是身兼多职，公司会让开发人员兼职“交付经理和项目经理”既负责开发工作，又负责现场的需求收集及项目交付；让产品经理兼职实施和交付人员，常驻现场，直接对接客户需求……

项目开展过程中，主要的工作内容是对接主要用户收集一线需求、与主要领导沟通汇报项目进度、协同其他厂家对接系统、产品原型设计、系统业务测试、产品培训与项目实施等工作。因此每天的时间安排十分混乱，经常多事并行，优先级不仅仅由需求侧确定，很大程度上也受限于人员的效率。

可想而知，在多任务并行的情况下，每项工作都无足够的时间处理，尤其是设计阶段的思考、测试阶段的场景覆盖。在这种背景下，项目进度无法明确把控进度，而且很多突发事项经常打乱节奏，看起来公司节约了人力，实际上效率大打折扣。

3）决策慌乱，迷失方向

决策能够直接影响项目的成功与否，无论是团队内部的管理决策还是客户对象的需求决策都能影响产品上线的质量。在团队里，项目经理负责需求和工期的决策、产品经理负责功能与设计的决策、研发经理负责上线时间及产品质量的决策，三者兼备才是保证一个项目高质量交付的基础，同时还需要业主方的配合与决策把关。

从大的方向看此项目属于智慧城市项目范畴内，系统建设具有一定的非标准化特性，由于主要一把手的管理思维不同，定制化项目基本上是常态，因此对于关键问题的决策将会直接影响一个项目的成败，衡量好各方利益得失，以最小的成本赢得项目的快速交付将是考察一个团队的核心指标。

智慧城市项目大多关联管理者的政绩要求，因此大多数项目都会要求快速部署。根据前期的功能清单快速搭建起业务系统，而后根据甲方需求再进行修改，这种实施方案在行业内可能已经屡见不鲜，大多数公司能较好的完成初期的工作内容，交付出部分常用且重要的功能，待回款建立强关联关系时再逐渐响应优化内容。

倘若决策失误，或者关键节点未向领导汇报确认，一旦自以为是，盲目开始，势必会出现需求不符合管理者要求的状况，项目势必返工，浪费人力、财力。找准能做决策、能拍板的领导者，将为项目直接指明方向。

4）定制开发，不成体系

用户会随着场景的不同产生不同的需求，对这种特殊需求的分析能力是考验产品经理基本能力是否过关的一个有效验证。

一般情况下，对于简单的功能需求，只需要产品经理抽象出业务流程，通过流程图、线框图等可视化图形表达出模型向甲方确认后产出原型即可进入评审阶段，开发团队会基于现有开发平台能力，和过往的开发经验认知对功能设计给予评价和反馈，两方达成一致，即可进入到功能开发阶段；而对于较为复杂的功能需求，则需要产品经理能够准确的理解甲方的意图，尤其是具备话语权或者领导者的特殊要求。

对于开发而言，以标准化的通用需求快速开发部署，直接浪费前期的大量工作量。

比如查看考勤详情需求，一般而言设计思路是按照根据组织架构自上而下按照公司、部门等维度以时间、个人为检索条件查询考勤记录和员工出勤情况，而管理者希望是通过员工一次的考勤情况直接扩大范围查询一段时间内的考勤记录，交互操作上的差异是：【选择部门-选择时间-选择人员-切换时间】和【选择部门-选择人员-选择时间】，因此在设计的时候，若无法洞察到管理者的特殊诉求，很容易给客户留下业务抽象能力和理解能力不足等印象。

然而这类项目倘若直接以客户表达的诉求为设计终点，又容易陷入后期客户变更需求导致的增加开发工作量，而通用的功能设计实现难度较大，开发成本较高，因此如何以合情合理的理由说服客户对产品经理来说也是一个极大的考验，让客户相信团队的专业度，相信给出的建议是具有权威和信服力的，才能有效避免一些由客户需求变更带来的附件问题。

5）工期紧张，变相偷懒

项目过程中由于业务体量较大、工期紧，中期增加了很多外包人员，由于项目欠缺项目管理，整个开发过程散乱、无序，各种规范均未建立起来的情况下就贸然开始开发，后果可想而知：缺乏产品文档，导致开发起来全凭产品经理的口述；缺乏接口文档，交接梳理降低了开发效率；缺乏测试文档，导致bug复现率极高且场景测试不全，产品上线后发生了很多事故。

于个人而言，由于团队配额不足，推动建立体系和规范的过程无法一蹴而就，且需要整个团队的配合，对于部门的管理风格来说也是不切实际的，因此到后期基本演变成各个岗位为减少自身工作量各自为战，变相的偷懒，表面上是快速解决了当下暴露出的问题，实则降低了项目交付的效率，因为问题迟早都会暴露，只不过都默认了解决问题的那个人并非自己。

因此在这种环境下就不得不去适应并且寻找方法增加效率，对产品的负责态度、个人的工作态度在这个时候便会突显非常重要的价值，以自身的工作态度影响团队成员，并促使大家保持一致的目标，让所有人能感受到成就感，项目才不至于一塌糊涂，毕竟亡羊补牢，为时未晚，但凡是个正常人都不会想着项目越做越差，只会越做越好。

3. 人力成本、开发成本、时间成本、项目成本

兼顾多个岗位带来的直观感受是在各种成本之间学会了平衡与取舍，专职产品经理时，一心只想着优化体验、满足客户需求、迭代功能等。

而现在懂得兼顾人力成本（投入的团队人数）、开发成本（需要的开发资源及时间）、时间成本（项目交付期限内需要的时间）、项目成本（项目利润），考虑的是能否在使用合理资源的情况下，较好地完成一个功能的上线，会去结合团队整体的情况评估需求的优先级，合理排期，安排资源，从而更好的保证开发进度，促进项目正常交付。

但是弊端也很明显，作为产品经理，首要考虑的应该是需求合理性及功能的适配性，开发资源等要素不是考虑的重点，这样以来主要精力会被占用，导致一部分精力受限或者限制功能设计的可扩展性。

领导常说我们做的是项目，不做产品，有些功能不用考虑那么完善，满足客户需求即可，不用耗费较大的人力成本去开发一个使用人数较少，适应范围较大的功能。

但从个人成长的角度来说，设计的时候还是要以产品的角度考虑功能，评审后再针对具体的项目进行简化和取舍，否则时间久了设计思维和设计视野很快就会被限制在一个开发平台内，对产品功能的嗅觉能力会变得极不敏感，最后俨然变成一个处处妥协的完全听从客户要求的“传话人”而非“需求分析师或者产品经理”。

要求所有岗位都能履行职责往往是理想状态，可遇不可求！大家都希望有一个配合起来很愉快很顺利的团队，都希望和高素质的人合作办事，和高效率的人一起工作事半功倍，但是往往一个项目的成功和失败遵循的是木桶效应，项目的上限受限于短板。

作为团队的桥梁，产品应该学会合理的协调各方，向下兼容，遇到能力和素质较差的不能仅仅只学会抱怨，适当地采用其他方法，站在他们的角度思考，锻炼同理心，学会与每个人交朋友，才能帮助这个集体成长，帮助项目取得成功。

在有限的资源下，消耗合理的时间，完成合理范围内的功能开发与交付，才能最大程度的减少项目成本，为部门和公司创收！而平衡好这个关系仅靠一个角色基本上是不可能实现的，但是同时做了多岗位的角色后，再去处理这个关系反而会显得比较容易，也许这就是做了这么多“杂事”后的最大收获吧，学会了“平衡”。