编辑导语：在工作中，任务往往不是一个人就能完成的，团队协同必不可少。对于产品新手来说，如何才能够在一个复杂的系统中通过团队协同顺利完成产品任务，这是一个大难题。本文作者就从过来人的角度出发，指出产品新手可能存在的问题以及应该如何去解决，希望对你有所帮助。

复杂的系统涉及多个开发组件协同，我是一个产品新手，我该怎么办？

在当今职业角色更加细分的条件下，任何一个产品都不是一个人就可以搞定的。一个互联网产品，从产品经理接收到需求和分析需求，UED设计效果，到研发进行开发，产品人员或项目人员进行验收，每个阶段都需要该岗位的人各司其职。

要说资源都是一个产品的还好，但大部分时候，资源都是共享的，也就是说，当别人的需求排队在你的前面时，你无可奈何。

另外就算资源排到了你，你可能也会面对多方资源协作，共同完成任务。

成熟的产品岗位的人可能觉得没什么好说的，而菜鸟阶段的产品人员对此心有余悸：怎样才能克服心理障碍，走过团队协同的脱敏阶段顺利完成产品任务，我想这是一个需要持续心理建设的问题。

一、项目背景

我司是做零售企业ERP软件的，传统零售行业销售方式主要有两种：零售与批发。

当然零售包含线上与线下，对应到供应链构建上有几个关键元素：

• 门店：向消费者提供线上或线下的商品或服务
• 仓库：存储、运输，向门店提供服务，有的仓库也会为线上提供服务
• 供应商：非生产加工企业时，为企业提供商品或服务
• 客户：企业发生批发业务的主要参与元素，一般会大宗购买商品而享受比零售低一些的价格。

我所做的产品没有什么业务上的创新，就是针对批发客户，供其完成订货、收货等业务。以往对于企业来说，不管线下订单业务如何，对应到ERP系统中，只会做一张“批发单”。为了提升客户体验，同时减轻企业销售人员的工作压力，我们需要做一个小程序供客户使用。

如果说小程序直接对接ERP系统，我们需要额外的中间层服务来转接，避免ERP系统性能受到影响。而恰好我司之前已经形成了相对完善的中台服务，包含资料中台，订单中台，运营中台等。因此我们此次直接使用中台逻辑闭环系统。

抽象出了中台之后，还需要一个运营的平台来承接中台的界面。因此，要完成这样一个批发业务，涉及了以下几方：

• UED
• 小程序
• 运营平台界面
• 资料中台
• 订单中台
• 投放组件
• ERP系统
• 流程测试小组

假如我是一个成熟的产品也就算了，偏偏是一个小菜鸟。恰好这段时间周围同事离职，孤单一个人坐在10个办公桌前，有些问题实在hold不住了，只能无可奈何的求助办公室里日理万机的领导了。

除此以外，开发大都已经是公司大佬，他们的业务与场景经验远比我丰富，他们所经历的完整项目也远多于我。在团队协同上，一旦一方不配合，整个项目就没法推进。

因此整个项目做下来，除了一些业务场景的问题，团队协同的困难给我留下了不可磨灭的印象。正是觉得很难，当我目前暂时性的把这些问题解决了，我希望能分享出来，提醒自己，也提醒大家。

团队协同，既简单又困难。

二、问题难点与解决方案

1. 找各个大佬确定大的方案时，大佬时间很难协调

• 困难：功能方案确定了，开发方案需要确认，各组件的开发负责人需要共同讨论。然而每个开发大佬都时间紧张，我不知道该怎么去找他们协调。另外，我觉得让我一个小菜鸟找他们，我很紧张。
• 直面困难：说真的，最开始我因为这个焦虑了很久，我不知道怎么搞这个协同工作，这也是我写本篇文章的最初灵感来源，也是让我意识到怎样才是完成一个任务的推进方式。

1）首先，转变观念

我总觉得自己在做产品上是个新手，资历少，而那些开发负责人，都是在公司好多年的，有“地位”的人。

所以只要沟通，心里就会有所忌惮，觉得他们说什么就是什么，不予争论。并且担心假如自己说错了，或者态度太强硬，别人会怎么看待或者议论自己。

然而这种观念是非常错误的，首先一定要相信，人都有一个成长的过程。此刻自己手生，但不意味着自己永远是一个在门口徘徊的人。

不要太着急，给自己一点时间。另一方面成熟的职场人都是对事不对人，假如自己想错了，大方的接受别人的批评或者意见；假如觉得自己有道理，就去争论，去表达，不要害怕。

不经历点打击，又怎么成熟起来呢！

另外，大家都是辛勤的社畜，只是有人多几年，有人少几年。完全没必要就因此有“等级制度”，尊重是一回事，“地位等级”是另一回事。

2）其次，各司其职

我作为产品岗位，而研发作为开发岗位，工作职责上去分便是我来考虑功能，研发考虑实现。

所以当我提出一个新的需求，并不是在“麻烦”他们，我们都在完成自己的工作，都是在位公司与客户服务，都是为了最终的结果。

每个岗位有自己的职能，我要做的是不要让我负责的工作积压在自己手里，而应该尽快传递出去。假如是别人的问题，那么就是去催对方。每个人都完成自己的part，整个任务才能完成。

3）最后，学会见缝插针

既然大佬的时间不好约，而大家要完成任务，那么每个人就只能利用工作时间之外的空余时间了。

像上次我在沟通一个问题，便是周末晚上邀请各位开发大佬一块语音会议，确定了结果。大家这样一上班便能尽快推动下去。非常规的时候只能采用非常规手段，做了也就做了。

2. 项目计划如何制定

• 困难：开发方案确定了，因为我的经验缺乏，不知道该怎么推进项目
• 直面困难：产品有时候需要像项目经理一样，推动整个事情的进度。那么只要涉及多方协作，必然会有项目管理的概念。这时候，我们就需要常见而不一定常用的甘特图来指导我们工作。

其实不一定非得是严格的甘特图，关键是几个涉及的重要组件以及关键节点能体现出来。

以下图为例，我的产品包含这些内容：

这东西，做一次有经验了就好了。没做过的也不要害怕，有这个意识就好。

3. 开发任务排满了，协调不出人力

• 困难：各个组件的开发确认排期，却整体协调不到一个合适的时间。开发的项目都排的很满，人力资源极其匮乏。
• 直面困难：研发资源永远是紧张的，这是不可避免的。除了向开发传递自己项目或者需求的重要性之外，尝试了解目前是什么项目占用了人力资源，是否能找到该项目负责人通融。

假如自己尝试了找研发，找占用研发资源的需求负责人之外还是没有用，这时候只能向上反馈找自己的领导了。跟领导表达自己的诉求，让领导了解现状并拍板是否当前必做。

假如否，那么没关系，按照可接受的时间让开发去排期；假如必做，那么只能让领导出面找上述两种人协调了。

这时候鸡腿笑出了“职位等级”的重要性，高级别的人话语权总是更大一些，问题解决起来也会更顺畅一些。

4. 开发说做不了或者不想做，我觉得应该有这个功能

• 困难：开发过程中碰到了很多细节的问题需要决策，开发与我各有说辞，有时候难以达成一致。
• 直面困难：跟开发沟通为什么难做——是技术上不好处理，还是开发觉得这个功能没有必要，亦或是开发有排期，当前不想做，后面再做？

考虑我的功能当前阶段是否必须做：这个功能的重要程度怎么样，是可以接受去掉这个功能，或者是接受晚些版本做这个功能。
假如必须做，场景是否有考虑清楚，原因是否真的能说服开发同学？假如不做，我的场景开发是否能提供其他解决方案并且客户能接受？

协同最重要的一点在于沟通。双方都需要将心比心。但注意一点，不要因为觉得要麻烦开发就按照开发给的方案实现而不考虑实际功能。基本的产品原则还是应该保有。

5. 实现方案的变动意味着原型的变动，需要反复调整

• 困难：我司的开发流程为——产品确认需求，流转到UED团队，完成交互设计后，产品验收通过给到研发。那么在研发过程性中，不可避免的会因为一些功能的暂缓或者去掉或者添加导致原型的修改，并且假如产品经验不够多，可能会反复修改。
• 直面困难：还是前面说的问题，不要在意别人的看法，这个阶段是无法避免的，我们需要成长；每个人都有自己的职责，他们的修改不可避免。

所以就算别人因为频繁改动而态度不友善时，我们一定要沉得住气，说几句诚恳的话缓和一下气氛，保证跟各个组件的同学保持良好的交互关系。不卑不亢，互相尊重。

6. 流程指向了某些人，也有通知到，但却没有回音

• 困难：组建qq群后，在群里发言，即便艾特了关键角色，有时也得不到回应；流程指向了某些人，不知道他们是否看到，总是没有回应。
• 直面困难：这时候不得不认为钉钉是个有用的东西。尽管作为被通知者，我们感到厌烦；但作为消息发出的统治者，他看没看到，结果我们希望了然于胸。

当然很多地方是不使用钉钉的，所以我们就需要其他的协同办法。

比如，群聊中艾特对方不回复，那么艾特的时候将研发负责人和他一起艾特；假如还收不到动静，那就通过私聊、电话、面对面的方式解决问题。

我们的目标是完成任务，所以各种合理合法方式都可以考虑使用。

之前有个同事举个例子，邮件告知别人要求对方回复，结果没动静。几次以后，直接添加邮件抄送人他的领导，对方看到立刻回复。

当然，一些沟通中的小技巧需要我们慢慢摸索和感受。比如问问题前，先脑子过一遍想一下；比如表达前，先在心里打一遍腹稿。日常多注意总结体会。

三、总结

只有真正经历了，才能知道自己当下面对的困难是什么；只有真的走过来了，才能体会原来是一件这么简单的事情。

所谓的自己，不过是一个身体和一些虚无缥缈的认知与情绪。认知与情绪，都是大脑自己想出来的，控制自己的大脑，而不要让大脑控制你。

当然，这些问题，说起来简单，实际实践还需要慢慢体会其中的奥妙。毕竟，沟通协调能力，是产品们必备的一项基础能力。

本文由 @困困生活 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议