怎样给产品经理讲技术 先自己尝试评估一下需求难度

在论坛、知乎上经常看到一些「年轻的」产品经理发的引战帖,大意是:「开发大哥,我代码写的少,你可别骗我,这么简单的需求,明明一下午可以搞定,你跟我说一个星期?如果让我来的话,巴拉巴拉巴拉…」 。看到这种论调,一些没耐心的程序员就会一笑了之,甩下一句「You can you up,no can no bb」,或者「你这么屌,你咋不上天咧」之类的回复潇洒走人,但是作为一名爱管闲事的程序员,我怎么能放过这个绝佳的「站在制高点上俯瞰众生」的机会呢?
先来反驳一下这位「年轻的」产品经理 。写代码是一个典型的「纸上得来终觉浅,绝知此事要躬行」的事情,往往一些看似很简单的需求,实际上会遇到很多坑 。你看过「人在囧途」吧?一段很简单的回家路,谁知道会有那么多的坎坷 。就是这种感觉 。
举个例子,你要实现一个「视频播放的时候,用户可以设置屏幕亮度」的功能 。实际上系统提供了「设置屏幕亮度」的程序接口,你只需要去调用就可以了,核心代码可能就一两行,够简单吧?但是,一运行你就会发现各种问题 。如果用户在我的APP里提高了屏幕亮度,退出之后要不要给人家还原呢?如果用户只是暂时离开了我的APP,退出又回来,我是不是要给人恢复成原来设置的亮度呢?这些都是产品逻辑问题,你们沟通之后很快就解决了 。但是后来测试发现,「设置屏幕亮度」的接口是一个很耗时的接口,可能会造成整个APP的卡顿,这时候你就得考虑用多线程来解决 。引入多线程之后,线程之间的资源共享问题如何解决,谁先谁后的问题如何解决,等等…
【怎样给产品经理讲技术 先自己尝试评估一下需求难度】「年轻的」产品经理不会想这么多,自己爽完提上裤子就跑了,留给程序员一堆烂摊子,程序员能开心的帮你干活吗?还有就是,程序员写代码可不光是完成功能那么简单,代码写的规范不规范,鲁棒不鲁棒,扩展性怎么样,都是需要事先下功夫去设计的 。我一开始写代码的时候,就喜欢那种实现一个功能的快感,迫不及待的要秀给别人看,后来体会到并不是那么回事 。写代码就像谈恋爱,一开始轰轰烈烈,海誓山盟,谈的久了,你会发现往往一些简单的小事,要完全负起责任,才是最难的 。
说了这么多,就是想让你理解程序员写一行代码,究竟要「熬过多少患难,湿了多少眼眶」 。这是动之以情 。接下来我们谈谈如何正确的提需求,就是要晓之以理了 。
提需求要有节奏感 。
不要误会,这个节奏感不是啪啪啪的节奏感,而是说你提的需求,要跟着项目的版本周期走 。一般一个不是太拖沓的互联网产品,每个版本会经过功能开发、单元测试、集成测试、beta验证、上线几个阶段,我们分别来看一下 。
功能开发阶段,简直是程序员的美好时光 。下午懒散的阳光打在脸上,泡一杯浓香的卡布奇诺加一点点糖,戴上女朋友送的Beats大耳机循环一首轻音乐,手指在机械键盘上跳来跳去,噼里啪啦的,就像脑海中忽闪忽闪的灵感,根本停不下来,对对,就是这样的感觉 。
这期间程序员要么做产品经理提的需求,要么闷头做一些技术需求 。这是产品经理提需求的最佳时期,程序员刚刚结束了上一个版本紧张的发布期,急需要一些新鲜的需求来压压惊 。技术需求是一些性能优化、代码重构之类的事情,这个虽然是程序员自己给自己提的需求,但是你一定要给他时间去做,不然程序员每天总觉得自己写的代码乱糟糟的,没有安全感 。
单元测试是一个功能模块的需求做完之后,提给测试同学去找bug 。集成测试时所有模块的需求都单元测试完成之后,整体来一轮测试 。这时候程序员天天在改bug,你奇思妙想来一个新需求,他可能要象征性的反抗一下,但是大多数会乖乖去做 。
到了beta和发布阶段,大家都绷紧了神经,天天盯着用户反馈和线上的各种指标 。这时候你突然被一块石头砸中,有了一个绝妙的需求,请hold一下,一定要hold住,因为你提任何需求都是会拉仇恨的 。
先自己尝试评估一下需求难度 。
这个就有一点技术含量了 。有些需求天生是很难的,比如智能推荐、智能识别、搜索引擎这种,需要很强的技术能力 。还有些需求,需要前后端联调,后端开接口,商量协议,这些时间算上去总时间要翻倍 。除了这些,剩下的就是相对的了,取决于是否有现成的轮子 。程序员常说,「不要重复发明轮子」,就是说如果有现成的代码,就直接用不要自己再花时间写了 。现成轮子可以来自开源社区、自己项目的积累、还有系统平台提供的支持 。如果某个需求有现成轮子可用,那它的难度应该至少要减半 。
你想知道开源社区都是有哪些轮子,可以平时多看一些别人整理的技术博客,你可能并不需要知道里面技术上是如何实现的,你只需要记下,这个功能是有轮子可以用的,就够了 。你想知道自己项目积累了哪些轮子,去问你们的开发吧,找他们抽支烟、吃个饭,很容易就套出来了 。有些项目比较成熟,像推送、埋点上报、自动更新这些都有轮子可以用,但一些年轻的项目则不然,建立这一套东西也要花不少时间 。你想知道系统平台提供了哪些轮子,就买一本介绍你们产品平台的技术书,比如《疯狂Android讲义》、《iOS Programming》,大体翻一下就行了,主要是了解一下这个平台到底可以做哪些事情 。
没有轮子可以用的需求怎么评估呢?少侠,你眼光不错哦,每天进来看看,你就知道答案啦 。
下点功夫做准备 。
这是个普遍的道理,你让别人给你办事,吩咐半天讲不清楚,别人肯定不耐烦 。如果你的需求是抄的别人的,可以拿别人做好的效果演示一下,这是最直接了当的 。你的需求是业界首创的,可以简单画个流程图,如果这时候你能用上一两个技术上的术语,程序员肯定觉得你碉堡了 。需求讲清楚了也要顺便让人理解为什么 。这时候不要留情,把程序员带到你的产品世界里,用你丰富的经验打败他,他就会乖乖的跟你走了 。
还有一点很重要,产品经理要给开发协调一些其他资源,像设计、测试这些,如果能提前准备好,那么即使是beta甚至上线阶段加需求,程序员也会十分感动然后再拒绝你的 。
最后忍不住吐个槽 。有些产品经理动不动就拉老大来给程序员施压,我觉得这种是最low的,连文章开头那些「年轻的」产品经理,水平都比他们高到不知道哪里去了 。就好比两个小朋友打架,你打不过人家,喊的不是「放学你等着,有种操场见」,而是「我要告老师,看他怎么收拾你」 。哎我说,不要怂啊亲 。
PS:以上建议只是我自己的胡思乱想,是一家之言 。你千万别有「快来看啊,这家伙又在装逼教我们做人啦」这样的想法 。如果你觉得我伤害了你,我希望你分享出去让更多人受到伤害 。如果你觉得我说的好像是那么回事儿,我也希望你分享出去让更多人来听我叨逼叨(好吧我说实话,其实就是年前给自己定的关注量KPI没完成,怒求一波分享和推荐,T T) 。
以上就是怎样给产品经理讲技术(先自己尝试评估一下需求难度)的相关内容了,更多精彩内容请关注科猫号SEO专员!

    推荐阅读