一、真实案例

1.1 案例一

       之前我在北京的一家互联网公司做产品经理，机缘巧合之下，去独立负责一个移动端产品，当时的资源比较紧张，2个Android（一个高级，一个中级），2个iOS（一个高级，一个中级），Server、测试、UI资源公司共用，开发进行到2/3阶段，领导招聘了一个初级iOS开发入场，简单沟通之后，由他负责研发第三方分享需求（即支持富文本内容分享到微信、朋友圈、微博等第三方平台），沟通时，明确表达了自己曾经做过同样的需求，比较简单，大概2～3天搞定，于是给其两天时间熟悉业务+安装环境（周一入职），周五下班前交付该需求。当我周四去问他进展的时候，他给我说了一堆问题：比如第三方插件不支持，富文本内容太多、短链接转换出问题.....，当时我很懵逼，因为本计划在周五发个小版本内测部分需求.......

1.2 案例二

        还是在那家公司，当时负责一个IM产品其中的一条产品线，当时公司采用事业线组织架构，客户端研发归属事业线，但server属于公司公共部门，当时我们客户端有个需求提给了server部门，server部门的leader也对该需求进行了排期，该排期也契合咱们客户端的整体安排，研发工作量为5人天，XXX给予支持，需求于下周三开始启动，到下周二的时候，突然server部门leader过来跟我说，XXX有事需要请加3天，暂时没有其他资源来支持，可否延期2天.........

二、案例分析

       虽然上面是两个案例，但其实拉通来看，本质是一样的，就是有delay情况发生时，未提前告知负责人。拿案例一来说，作为新入职的小伙伴，不熟悉业务，不熟悉团队，不熟悉成员，其实是可以理解的，但当自己的工作遇到问题的时候，应该第一时间告知给相关负责人，而不是埋头等待，等待负责人来问你的时候，你才说，是小需求还好，但如果是那种快速迭代，面临上百万，甚至千万人使用的产品该怎么办呢？

三、解决方案

        虽然标题写的是“开发不靠谱”，其实后来反思，并不是开发不靠谱，是我（产品经理）不够优秀导致的，如果我足够优秀，或许可以避免这个问题，如果拿到现在，我想这两个问题应该都不会发生，我现在对这个问题的解决方案有以下几种：

3.1 站立晨会

- 时间：9:50-10:00

- 时长：10分钟

- 成员：项目组所有成员，包括前端开发、后端开发、server、UIUE、测试、产品等

- 内容：昨天的工作内容、今天的工作计划、遇到的问题、需要协调的点

- 总结：产品经理把当前的晨会内容总结发出，并@相关人予以确认

3.2 群

将项目组所有成员拉进群，然后做好以下几件事：

- 群名称：根据项目取好群名称，以便查询和沟通，比如：统一权限接入需求群、语音通话Android客户端群......

- 群公告：重要事项进行公告，比如站立晨会内容、需求变更内容等

- @群成员：有需要谁知道的事情，一定要@相应的群成员

- 群记录：当别人说了什么你需要做的事的时候，请自己做好记录，这时候印象笔记就是个好工具了

3.3 面聊

这个最重要，作为一个项目组的产品经理，尽量做到每天跟每人都沟通一次，沟通的内容主要是以下几点：

- 进展怎么样

- 有没有需要我协调的事

- 以目前情况来看，项目排期有没有delay的风险

- 对需求这块的理解有没有问题

- 中午一起吃饭啊（哈哈哈，这个是开玩笑啦）

3.4 烂笔头

通过面聊、晨会、群等沟通的内容，最好记录下来，比如：

- 项目开始时间

- 需求工作量

- 计划联调时间

- 联调相关人

- 测试用例评审时间

- 提测时间

- .....

四、总结

其实，没有不靠谱的开发，只有不够优秀的产品经理，所以，你曾经埋怨过你的RD吗？如果有，请记得请他吃饭，然后告诉他：兄弟，以后我会好好对你的～如果没有，请继续保持，我们一路向前。

作者：企荣之路，国内某知名互联网公司新零售产品经理，微信公众号：企荣之路