产品汪和程序猿仿佛天敌的存在，这也难免，毕竟产品和开发的视角本就不同，更何况写代（bug）码（bug）这个事情本就枯燥，那种可以在代码中发现快乐和美的同学请忽略。其实多数开发同学都是很好相处的，不过这里面需要的技巧真不是能说会道就可以的。
在这里顺便纠正一个错误，也是我之前的错误认知，沟通能力强≠能说会道！
通过我老大（我老大很厉害哒）的指引和工作中的摸索，将这段时间内与开发同学沟通的方法和心得总结一下。第一部分是正确的PM心态，第二部分是和开发沟通的关键节点和技巧。
第一部分 PM的正确心态
01 产品是大家的产品，不是PM的产品
每一个PM都要有主人翁意识，并且要为产品的成败承担主要责任，这是毫无疑问的。但是RD、UE、UI、QA是否只管完成PM的需求，就可以了呢？一定不是的！
一个产品的诞生需要经过PM-UE-UI-RD-QA的流水线，和实体所理解的生产流水线差不多，一个实体产品不受市场欢迎，难道是因为流水线的其中一环导致的吗？这不是在为PM开脱责任，是要告诉PM一个道理：你需要让团队内每一个人都知道，我们是在各自的岗位上为这个产品共同努力！
初入职场，老大问了我一个问题：“在技术评审时候，你和开发的地位关系？”，我才恍然意识到我已经将自己放在了求人办事的低姿态角色里。这对后续沟通和项目推进都是一个巨大的绊脚石，因为开发会认为这是PM的产品，开发在【帮】PM做产品，重点是那个帮字，一旦这种观念养成，整个团队的协作都会是恶性的，并且你将是一个永远抬不起头的PM。
02 产品是你的产品，你是产品的负责人
看这个标题与上一个观点似乎是违背的，其实不然。
上一个观点是你需要传达给团队的，这个观点是需要时刻警示自己的。
PM是整个产品成败 或 项目出现问题 的第一负责人。
第二部分 PM需要和开发沟通关键节点及技巧
01 方案策划
方案策划阶段，似乎看起来没有开发什么事情，有以下三种情况，让PM参与到策划阶段可以提高方案质量和团队关系。开发会很愿意和你在策划阶段沟通方案，会觉得你足够重视ta。
① 对已有方案的技术可行性和合理性不明确时，为了避免到技术评审时候开发才指出方案不可行，何不在方案策划阶段就和开发沟通一下大体方案，保证大方向正确。
② 方案无头绪时，开发见过的产品不一定比PM少，在一些常见的交互样式上，也许能给到你很好的建议，在你方案无头绪的时候，和他说明想解决的问题，也许可爱的开发同学能给到意外惊喜的答案。
③ 想和开发促进促进关系时，在上述两个任一场景下，即使你有了确定的方案，也可以去和开发聊一聊，毕竟多接触才能培养默契和关系。
02 技术评审
技术评审是项目重要节点，也是开发和PM正面对立的一个环节，所以评审中和开发沟通需要着重注意技巧。
方案阐述需要较高的技巧，我目前做的也不是很好，所以这块留在以后吧~其中一些细节点的处理方法还是值得分享一下。
开发的问题你无法解答（多半是方案产出阶段没有考虑到）时，不草率给出结论，记录下问题，会后确认好再告知各位开发。（草率给结论不仅会影响PM的公信力，还会让团队低效）
问题讨论不清楚时，沟通的双方都不在一个频道上，如果沟通内容是本次会议的主题，需要先统一认知，拉回到同一话题上，再做深入沟通；另一种就是非重要问题，若无法统一认知，不作深入讨论，PM要终止话题。
会议方向跑偏时，拉回来吧，兄弟，大家都很忙~
03 项目跟进
日常进度沟通，务必每天关注，存在偏差时和master及时确认。
具体的项目管理 见 PM日记-项目管理篇 v1.0。主要说一下沟通的形式：
群内沟通，RD在开发过程中会有一些细节问题需要和PM确认，所以群内是最及时、高效的解决方式。除此之外，定期查看进度时候也要提醒RD里程碑
开发站会，开发阶段定期开站会，大家信息互通，各自开发进度和当前遇到的问题，PM也要参加，如果涉及到资源协调等，要及时解决，保证项目进度。
04 项目复盘
待整理~
网友评论