当前位置:首页 > 网络黑客 > 正文内容

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

访客3年前 (2022-01-05)网络黑客724

在论坛、知乎上经常看到一些「年轻的」产品经理发的引战帖,大意是:「开发大哥,我代码写的少,你可别骗我,这么简单的需求,明明一下午可以搞定,你跟我说一个星期?如果让我来的话,巴拉巴拉巴拉…」。看到这种论调,一些没耐心的程序员就会一笑了之,甩下一句「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专员!

扫描二维码推送至手机访问。

版权声明:本文由黑客技术发布,如需转载请注明出处。

本文链接:http://w-123.com/102731.html

“怎样给产品经理讲技术(先自己尝试评估一下需求难度)” 的相关文章

SentinelLabs 敦促 Azure Defender for IoT 用户尽快安装补丁

SentinelOne 的 SentinelLabs 去年就曾发现 Microsoft Azure 的 Defender 存在多个安全漏洞,其中部分漏洞的严重程度和影响被评为“关键”。微软已经为所有的漏洞发布了补丁,但 SentinelLabs 敦促 Azure Defender for IoT 用...

数百个 GoDaddy 托管的网站,短时间内被部署了后门

Bleeping Computer 网站披露,网络安全分析师发现 GoDaddy 管理服务器上托管的部分 WordPress 网站,被部署了大量后门,所有网站都具有相同的后门有效载荷。 据悉,这次网络攻击可能影响到许多互联网服务经销商,已知的包括 MediaTemple、tsoHost、123Re...

CPU 又曝大 bug,涉及英特尔、AMD、ARM

2018年,英特尔、AMD、ARM曝出CPU安全事件,引起广泛关注,舆论一片哗然。虽然英特尔公司表示此次事件不仅仅是英特尔,还涉及AMD/ARM等厂商,且CPU 漏洞补丁基本不会给普通用户造成任何影响,但这次bug依旧被定为成行业大事件。 时隔几年,CPU又再次曝出一个大bug,有意思的...

一项调查发现大多数人仍然在多个网站上重复使用密码

一项新的调查显示,70%成年人仍在使用同一个密码做一件以上事情。在对1041名18岁或以上美国居民的调查中,PCMag发现,25%的人承认有时会重复使用同一个密码,24%的人说他们大部分时间都这样做,而21%的人承认一直这样做。 重复使用密码是黑客喜欢的事情,尤其是许多网站和服务使用电子邮件地址作为...

SushiSwap 承认 MISO 平台遭到软件供应链攻击 损失超过 300 万美元

SushiSwap 首席技术官表示,该公司的 MISO 平台近日受到了软件供应链的攻击。SushiSwap 是一个社区驱动的去中心化金融(DeFi)平台,方便用户交换、赚取、借出、借用和利用加密货币资产。今年早些时候,Sushi 的最新产品 Minimal Initial SushiSwap Off...

Google 安全人员:“ NSO 的漏洞是我们见过的最复杂的漏洞之一”

Google的安全研究人员对NSO集团的一个零点击iMessage进行了深入研究,并揭示了该公司攻击的复杂性。Google Project Zero(零点项目)指出,ForcedEntry零点击漏洞–它已被用来针对活动家和记者–是“我们所见过的技术中最复杂的漏洞之一”。 另外,它还说明了NSO集团...

评论列表

鹿岛几钵
2年前 (2022-08-12)

我是不是要给人恢复成原来设置的亮度呢?这些都是产品逻辑问题,你们沟通之后很快就解决了。但是后来测试发现,「设置屏幕亮度」的接口是一个很耗时的接口,可能会造成整个APP的卡顿,这时候你就得考虑用多线程来解决。引入多线程之后,线程之间的资源共享问题

鸠骨萌懂
2年前 (2022-08-12)

感不是啪啪啪的节奏感,而是说你提的需求,要跟着项目的版本周期走。一般一个不是太拖沓的互联网产品,每个版本会经过功能开发、单元测试、集成测试、beta验证、上线几个阶段,我们分别来看一下。功

忿咬卿绡
2年前 (2022-08-12)

程序员肯定觉得你碉堡了。需求讲清楚了也要顺便让人理解为什么。这时候不要留情,把程序员带到你的产品世界里,用你丰富的经验打败他,他就会乖乖的跟你走了。还有一点很重要,产品经理要给开发协调一些其他资源,像设计、测试这些,如果能提前准备好,那么即使是

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。