之前阿然看到这个问题,想到自己也是非技术出身的,也来总结总结自己的一点小经验 1.让技术同学参与需求的工作 在思考需求和制作需求方案的时候,可以咨询技术小伙伴给出技术角度的意见,这边避免了需求评审时候技术同学发难说实现不了,或者说最终实现过程中遇到问题延长工期。同时,如果技术小伙伴感兴趣,也可以让他们提产品方案的建议,充分参与进来,这样产品与技术同学结合更紧密,更能够互相理解,即使说中途需求有改,让开发同学明白了其中缘由也会好得多。 举例场景: 汪:xx,请教一下,看下这个需求方案有什么实现问题,blablabla 猿:我觉得这里有点问题,你看看这样,blabla 多番讨论后,你的需求方案在评审前在技术实现方面就可以避免很多问题 2.技术基础知识还是得学 平常多问问多请教技术小伙伴一些疑惑的问题。基本的技术基础知识也可以看看人人都是产品经理专栏作家【给产品经理讲技术】的作品,通俗易懂。再深入点可以看看代码(笔者当年也是看着代码学习iOS 和 Android布局的原理),以下是笔者的部分笔记 基本技术概念是必须得有的,这样有助于你思考需求,提高大家效率。 举例场景: 某日业务费需要在你负责的App内添加H5页面,其实逻辑涉及到H5和原生的交互。你如果明白webview与原生交互有url识别和js调用原生接口两种方式的话,就可以直接叫来前端和客户端用户,咱们约定下url的形式和参数吧,事情就高效率解决了 3.沟通的前提是讲清楚需求价值 大家都是成年人都是讲道理的人,没人想浪费时间做无用功。如果你告诉开发,这个需求 CTR预期提升20%,然后拿出以往的数据经验以及竞品数据做支撑,开发一想,这样有道理对团队也有好处,自己奖金也会多多,为何不帮您呢。 4.用你的专业性证明自己靠谱 思考需求方案时,首先自己要想清楚,想清楚其中的运转方式规则,客户端要做什么后端要做什么设计要做什么,需要什么数据哪些接口。想起来之前在知乎看到一个问题,哪些产品看起来很简单技术做起来很难,问题里面提到个性化推送。如果哪天你要做个性化推荐,告诉你们技术说,咱们要做个性化推荐的系统,根据XX推荐XX,只说到这里,那就等着被喷吧。 那么正确的姿势是什么样的呢 4.1 先建立运转的模型,解构需求 这是个笔者之前涉及到的一个简易推荐系统模型,拆解成三端需求 客户端: 上传数据,涉及到的问题,上传哪些数据、什么时候上传、上传频率等等 接受推送,涉及到的问题,推送文案、打开后哪个界面、行为数据的统计 服务端1: 数据采集,涉及到采集接口 请求要推送的数据,涉及到的问题,原始数据量是否足够,取数据的频率方式 匹配排序,匹配的策略是什么,排序策略是什么 服务端2:数据的接口是否数据完备性能能够满足 4.2 拆解问题后各个击破 在跟技术小伙伴讨论前要明确3中提高的需求价值,然后请教技术小伙伴拆解好的问题各个完善,在评审时这个方案就已经是个趋于完善的方案了,技术小伙伴们也没啥理由喷你,也为实施过程铺好路了。长期过程中,技术小伙伴就会对你有很好的信任,后续的工作就好办多了。 注:以上方式均不如"研发是我好哥们"