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