发人员需具备一点产品能力

为了开始今天的话题, 我先来借助几个角色, 模拟一下工作中的某些场景.

设立人物

小 A 是名刚入门的技术人员, 比较听话.
小 B 是有工作经验的一名技术人员, 平时喜欢看看产品相关的书籍, 喜欢和产品经理撕逼.
小 C 就厉害了, 不仅技术厉害, 也具有产品思维, 除了阅读产品类的书籍, 还写产品体验报告和体验竞品(和当前自己产品相关的产品).
小 D 就是一名产品经理, 具有一定的产品能力, 数据分析能力和管理能力.

人物已经设立好了, 现在让他们登场.

情景再现: 需求评审

这天风和日丽, 小 D(产品经理) 通知项目组的所有成员, 包括设计/开发/运营/测试等人员按时参加产品需求评审会议.

为了缓解大家的情绪, 小 D 买了很多零食和水果, 也算是犒劳一下大家. 小 D 开始给大家讲需求了, 像往常一样, 拿出精湛的原型, 口沫直飞的向大家展示其绵绵不绝的口才和产品思维. 小 A 一直在点头, 也不知道到底有没有听懂小 D 在说什么, 反正我看到有部分设计人员已经开始打瞌睡了.

突然, 小 C 中断了正在口述的小 D, 小 D 不慌不忙的停止了手中的一切动作, 聚精会神的听小 C 的意见和建议. 小 C 也有条不紊的将刚才的某项需求口述了一遍, 按照小 C 的逻辑, 目前的需求还是存在一些漏洞的, 这个时候, 小 D 开始认真的跟小 C 开始交流, 但是没有马上肯定小 C, 只是说我暂时记下这个点, 回头在思考一番. 产品小 D 稳如老狗, 继续自己的表演.

产品需求基本已经讲完了, 现在是大家提问题和交流的时间, 我看到有些同事揉了揉眼睛, 像是如梦初醒般的看着产品小 D, 不是旁边的同事拉住 Ta, 估计都能冲出会议室. 小 B 也不淡定了, 提出了不少问题, 并从技术的角度说明了实现的难度. 产品经理听的也是一脸懵逼, 心理想: “你实现是否有困难管我鸟事?”.

小 B 在产品小 D 那里并没有得到应有的表扬和鼓励, 反遭到同事小 C 的鄙视, 小 C 说, 你先不要告诉他实现方案, 先讨论这个需求的场景和真伪度. 小 D 默默的对小 C 投过赞赏的目光. 紧接着测试和其他人员提出了几个不痛不痒的问题, 都被老练的小 D 一一破解, 那气势, 啧啧! 势如破竹!

需求评审会议就这样结束了.

情景再现: 需求变更

在产品进入开发和设计阶段, 按理说需求变更也算是比较正常的一件事情.

这年头, 唯一不变的就是变化.

小 B 正在聚精会神的写代码, 突然小 D 跟他说, 这个地方的需求需要修改一下, 你看改动有多大?

小 B 鄙视的看着产品经理小 D, 心理在说改动有多大你心里还没有点 B数嘛. 小 B 还是控制了自己的情绪, 接着说道, 你当初应该好好思考的, 你看我都快做完了, 你才告诉我需要改动.

噼里啪啦的说完, 估计小 B 心理也暗爽了不少, 最终还是接受了这次的变动.

小 A 负责的模块, 也被产品经理修改过, Ta 和产品经理小 D 的交流基本是, 哦, 恩, 好, 可以!

当小 C 找到小 D 的时候, 并没有直接告诉小 D 需要改东改西, 而是问问小 D, 你看这样会不会更好一些?

小 C 当然明白小 D 的目的了, 于是拿出自己看过的竞品, 并说出了自己的意见, 愉快的和小 D 交流后, 居然 TMD 的砍了一个需求. 这让旁边的小 A 和小 B 羡慕不已.

总结

上面的两种情景, 我相信做过开发的同事应该都深有体会, 但是千万不要对号入座, 我只是打个比方.

从上面看出, 小 C 是一个很不错的角色, 无论是思维还是沟通能力都有别与他人, 最重要的是他没有仅仅把自己当做一名开发人员, 而是站在产品的角度去思考问题和解决问题.

需求变更是常态, 作为开发人员, 要最大限度的给产品以支持. 产品经理也是人, 当然有考虑不周的地方, 如果你不能想出更好更完美的解决方案, 请支持他的决定.

多站在别人的角度去思考问题, 换位思考, 才能保证有效的沟通. 作为一名技术人员, 尤其是在互联网行业, 多多少少都应该需要具备一定的产品思维.