做产品和做项目其实都是一回事，想要把项目做好，也是需要对交付团队做设计的。这篇文章，作者详细阐述了产生这个认知的全过程，供各位参考。
做了一阵子产品之后认为做产品和做项目完全是两回事，而现在觉得，其实是殊途同归。
如果说做产品，得用产品说话，打造产品的交互体验，稳定性，好的功能效果；那么做项目，与客户交互、直接给客户体验的是交付团队。
也可以说，其实做交付项目就得把交付团队当做一个产品来打造，给用户专业的感觉，舒畅的体验。
如果说好的产品来源于对产品的设计，产品的交互模式，运行速度等等，那么项目想要做好也是需要对交付团队做设计的。
设计什么呢？
设计团队的内部合作模式和问题反馈处理机制，这关系到一个团队的核心软实力，决定了体验好不好，性能强不强。
从这个角度讲，那做产品和做项目的方法论就可以统一了。
为什么会有这个认知呢，主要来源于对几个现象的思考：
基于上面这些现象做了一个思想实验：
极端情况下，假设双方的信息交互和流通是纯自发的，没有约束的，即：信息（包括需求、问题反馈）在我方与客户方之间任意两者都可以交互对接的。那就形成如下图1-1所示的效果，乱成一锅粥，所有人都应接不暇，理不清头绪。
要解决上面的问题，就得在甲方客户和我方之间构建合理的、高效的信息处理流程。也就是如何处理信息接收、信息处理、解决措施与闭环反馈这个四个步骤，如图1-2。
在信息接收这个环节，由于乙方对甲方是弱约束甚至是没有约束力的，因此乙方无法要求和控制甲方的信息流动，因此甲方在遇到问题的时候有可能向乙方的任意一个人提出，那乙方这个人该怎么做？这里面有两种情况，一种是所提问题刚好就是乙方这个人职责范围内可以处理的，那直接按照后面的解决措施流程处理；如果是职责范围之外的，那他只需要有简单接收信息的能力即可，利用表单工具登记好问题、提出者信息（方便后面联系处理），问题名称和简单描述，这项能力是所有可能与甲方客户有交集的成员都具备的，利用好工具，设计好表单的情况下处理也非常简单。当然这里面需要有一个前提，就是乙方人员的职责范围比较清晰，每个人知道这个问题该不该他由来处理。
所以，在信息接收这个一个环节需要对团队做什么样的建设：
不管是需求还是问题，都需要进一步了解其来源，全貌，这样才能发现真需求，真问题。这个环节和做产品的需求处理逻辑是一样的，但作为工程师很容易就直接按客户说的就去做了，但很多时候客户提的只是他的想法，或者解决问题的一种方法，真需求和真问题还需要我们进一步通过思考，沟通等方式挖掘出来。找到真需求和真问题是信息处理的关键，也决定了后续处理的质量，所以这一环节其实是非常有必要多耗时和耐心来处理的。
在这个一个环节需要对团队做的建设是：
如果在上一环节把真问题，真需求搞明白了，其实接起来解决措施也是比较容易清晰的。（要么就是实现不了，或者综合成本，时间要求等各方面的考虑，与客户协商进行调整）
在这个一个环节需要对团队做的建设是：
向客户（需求/问题提出者）验收功能或者确定问题关闭，这个过程简单，但很有必要，可以给客户安全感，靠谱的感觉。
在这个一个环节需要对团队做的建设是：建立交付团队的闭环反馈意识。
这四个步骤，在具体的执行上可以有两种大的做法，第一种是按需求/问题分，每个人负责某一范围的需求和问题走完全流程；第二种是按流程环节骤分，每个人只负责一个或两个环节。如果小项目小团队，试用于第一种，一个人走完全流程，实现自闭环，但这种情况需要的是能力全面的工程师。但如果是大项目大团队，那一个人是无法处理那么多需求和问题的，这就需要用第二种。
特别强调的是：信息接收和信息处理这个两个步骤是交付团队与客户发生交互的关键环节，这两个环节的处理相当于这个团队的门面和交互界面，决定了客户对这个项目团队的整体印象，这一步体现的是团队的管理能力。而解决措施这一步体现的才是这个项目团队的技术实力。
本文由 @Sherwin 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。