之前阿然看到这个问题，想到自己也是非技术出身的，也来总结总结自己的一点小经验
在思考需求和制作需求方案的时候，可以咨询技术小伙伴给出技术角度的意见，这边避免了需求评审时候技术同学发难说实现不了，或者说最终实现过程中遇到问题延长工期。同时，如果技术小伙伴感兴趣，也可以让他们提产品方案的建议，充分参与进来，这样产品与技术同学结合更紧密，更能够互相理解，即使说中途需求有改，让开发同学明白了其中缘由也会好得多。
举例场景：
汪：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中提高的需求价值，然后请教技术小伙伴拆解好的问题各个完善，在评审时这个方案就已经是个趋于完善的方案了，技术小伙伴们也没啥理由喷你，也为实施过程铺好路了。长期过程中，技术小伙伴就会对你有很好的信任，后续的工作就好办多了。
注：以上方式均不如“研发是我好哥们”
