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

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

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

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

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

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

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

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

精心伪造的微软客户支持和帮助文档实际上是窃取信息的 Vidar 恶意软件

网络安全公司Trustwave的安全团队SpiderLabs警告Windows用户,一个名为Vidar的新恶意软件活动将自己伪装成微软支持或帮助文件。因此,毫无戒心的用户可能很容易成为受害者,而Vidar是一个偷窃数据的恶意软件,可以窃取被利用者的信息。 微软编译的HTML帮助(CHM)文件虽然现在...

脸书被欧盟罚款 1.2 亿:大规模数据泄露

Facebook母公司Meta被欧盟罚款1700万欧元(约合1900万美元),原因是它未能阻止Facebook平台在2018年发生的一系列数据泄露事件,违反了欧盟的隐私规则。 Meta在欧盟的主要隐私监管机构爱尔兰数据保护委员会表示,他们发现Facebook“未能采取适当的技术和组织措施”。 20...

黑客用新 Rootkit 攻击银行网络从 ATM 机上窃取资金

Hackernews 编译,转载请注明出处: 据观察,一个利益熏心的黑客正在部署一个全新的针对 Oracle Solaris 系统的 rootkit,目的是ATM机网络,并在不同银行使用伪造的卡进行未经授权的现金提款。 威胁情报和事件应急公司 Mandiant 正在追踪名为 UNC2891的组织,...

育碧通报网络安全事件 全公司已采取重置密码的预防措施

在周四的一份网络安全公告中,育碧(Ubisoft)证实该公司在上周遭遇了一起“网络安全事件”。尽管攻击尝试似乎未能造成破坏,但出于安全方面的考虑,育碧还是采取了全公司范围内的密码重置措施,以防发生其它意外。在此期间,育碧暂停了部分服务,但坚称没有玩家数据受到损害。截止发稿时,该公司旗下所有游戏和服...

设备接管风险警告!F5 发现一个关键 BIG-IP 远程执行漏洞

近日,应用交付领域(ADN)全球领导者F5公司发布了一项安全警告,其研究团队监测到一个关键漏洞正在被积极利用。漏洞的追踪代码为CVE-2022-1388,CVSS 3.0评分为9.8,危险等级非常高。该漏洞允许未经身份验证的网络攻击者执行任意系统命令,执行文件操作,并禁用BIG-IP上的服务。 根...

GitHub 透露:攻击者利用偷来的 OAuth 令牌入侵了几十个组织

GitHub今天透露,一名攻击者正在使用偷来的OAuth用户令牌(原本发放给Heroku和Travis-CI),从私人仓库下载数据。自2022年4月12日首次发现这一活动以来,威胁者已经从几十个使用Heroku和Travis-CI维护的OAuth应用程序(包括npm)的受害组织中访问并窃取数据。...

评论列表

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

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

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

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

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

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

发表评论

访客

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