如何告诉后端出身的领导:这个前端需求很难实现

38,793 阅读8分钟

本文源于一条评论。

test.png

有个读者评论说:“发现很多前端的大领导多是后端。他们虽然懂一点前端,但总觉得前端简单。有时候,很难向其证明前端不好实现。

这位朋友让我写一写,那我就写一写。

反正,不管啥事儿,我高低都能整两句,不说白不说,说了也白说。本文暂且算是一条评论回复吧。愿意看扯淡的同学可以留一下。

现象分析

首先,前半句让我很有同感。因为,我就是前端出身,并且在研发管理岗上又待过。这个身份,让我既了解前端的工作流程,又经常和后端平级一起交流经验。这有点卧底的意思。

有一次,我们几个朋友聚餐闲聊。他们也都是各个公司的研发负责人。大家就各自吐槽自己的项目。

有一个人就说:“我们公司,有一个干前端的带项目了,让他搞得一团糟”

另一个人听到后,就叹了一口气:“唉!这不是外行领导内行吗?!

我当时听了感觉有点别扭。我扫视了一圈儿,好像就我一个前端。因此,我也点了点头(默念:我是卧底)。

是啊,一般的项目、研发管理岗,多是后端开发。因为后端是业务的设计者,他掌握着基本的数据结构以及业务流转。而前端在他们看来,就是调调API,然后把结果展示到页面上。

另外,一般项目遇到大事小情,也都是找后端处理。比如手动修改数据、批量生成数据等等。从这里可以看出,项目的“根基”在后端手里。

互联网编程界流传着一条鄙视链。它是这样说的,搞汇编的鄙视写C语言的,写C的鄙视做Java的,写Java的鄙视敲Python的,搞Python的鄙视写js的,搞js的鄙视作图的。然后,作图的设计师周末带着妹子看电影,前面的那些大哥继续加班写代码。

当然,我们提倡一个友好的环境,不提倡三六九等。这里只是调侃一下,采用夸张的手法来阐述一种现象。

这里所谓的“鄙视”,其本质是源于谁更接近原理。

比如写汇编的人,他认为自己的代码能直接调用“CPU”、“内存”,可以直接操纵硬件。有些前端会认为美工设计的东西,得依靠自己来实现,并且他们不懂技术就乱设计,还有脸要求100%还原。

所以啊,有些只做过后端的人,可能会认为前端开发没啥东西。

好了,上面是现象分析。关于谁更有优越感,这不能细究啊,因为这是没有结论的。如果搞一个辩论赛,就比方说”Python一句话,汇编写三年“之类论据,各有千秋。各种语言既然能出现,必定有它的妙用。

我就是胡扯啊。不管您是哪个工种,请不要对号入座。如果您觉得被冒犯了,可以评论“啥都不懂”,然后离开。千万不要砸自己的电脑。

下面再聊聊第二部分,面对这种情况,有什么好的应对措施?

应对方法

我感觉,后端出身的负责人,就算是出于人际关系,也是会尊重前端开发的

“小张啊,对于前端我不是很懂。所以请帮我评估下前端的工期。最好列得细致一些,这样有利于我了解人员的工作量。弄完了,发给我,我们再讨论一下!”

一般都是这么做。

这种情况,我们就老老实实给他上报就行了,顶多加上10%~30%处理未知风险的时间。

但是,他如果这样说:“什么?这个功能你要做5天?给你1天都多!

这时,他是你的领导,对你又有考核,你怎么办?

你心里一酸:“我离职吧!小爷我受不了这委屈!”

这……当然也可以。

如果你有更好的去处,可以这样。就算是没有这回事,有好去处也赶紧去。

但是,如果这个公司整体还行呢?只是这个直接领导有问题。那么你可以考虑,这个领导是流水的,你俩处不了多长时间。哪个公司每年不搞个组织架构调整啊?你找个看上的领导,吃一顿饭,求个投靠呗。

或者,这个领导只是因为不懂才这样。谁又能样样精通呢?给他说明白,他可能就想通了。人是需要说服的。

如果你奔着和平友好的心态去,那么可以试试以下几点:

第一,列出复杂原因

既然你认为难以实现,那肯定是难以实现。具体哪里不好实现,你得说说

记得刚工作时,我去找后端PK,我问他:“你这个接口怎么就难改了?你不改这个字段,我们得多调好几个接口,而且还对应不起来!”

后端回复我:“首先,ES……;其次,mango……;最后,redis……”

我就像是被反复地往水缸中按,听得”呜噜呜噜“的,一片茫然。

虽然,我当时不懂后端,但我觉得他从气势上,就显得有道理

到后来,还是同样的场景。我变成了项目经理,有一个年轻的后端也是这么回复我的。

我说:“首先,你不用……;其次,数据就没在……;最后,只需要操作……”。他听完,挠了挠头说,好像确实可以这么做。

所以,你要列出难以实现的地方。比如,没有成熟的UI组件,需要自己重新写一个。又或者,某种特效,业内都没有,很难做到。再或者,某个接口定得太复杂,循环调组数据,会产生什么样的问题。

如果他说“我看到某某软件就是这样”。

你可以说,自己只是一个初级前端,完成那些,得好多高级前端一起研究才行。

如果你懂后端,可以做一下类比,比如哪些功能等同于多库多表查询、多线程并发问题等等,这可以辅助他理解。不过,如果能到这一步,他的位子好像得换你来坐。

第二,给出替代方案

这个方案,适用于”我虽然做不了,但我能解决你的问题“。

就比如那个经典的打洞问题。需求是用电钻在墙上钻一个孔,我搞不定电钻,但是我用锤子和钉子,一样能搞出一个孔来。

如果,你遇到难以实现的需求。比如,让你画一个很有特色的扇形玫瑰图。你觉得不好实现,不用去抱怨UI,这只会激化问题。咱可以给他提供几个业界成熟的组件。然后,告诉他,哪里能改,都能改什么(颜色、间距、字体……)。

我们有些年轻的程序员很直,遇到不顺心的事情就怼。像我们大龄程序员就不这样。因为有房贷,上有老下有小。年龄大的程序员就想,到底是哪里不合适,我得怎样通过我的经验来促成这件事——这并不光彩,年轻人就得有年轻人的样子。

第二招是给出替代方案。那样难以实现,你看这样行不行

第三,车轮战,搞铺垫

你可能遇到了一个硬茬。他就是不变通,他不想听,也不想懂,坚持“怎么实现我不管,明天之前要做完”。

那他可能有自己的压力,比如老板就是这么要求他的。他转手就来要求你。

你俩的前提可能是不一样。记住我一句话,没有共同前提,是不能做对比的。你是员工,他是领导,他不能要求你和他有一样的压力,这就像你不能要求,你和他有一样的待遇。多数PUA,就是拿不同的前提,去要求同样的结果。

那你就得开始为以后扯皮找铺垫了。

如果你们组有多个前端,可以发动大家去进谏。

”张工啊,这个需求,确实不简单,不光是小刘,我看了,也觉得不好实现“

你一个人说了他不信,人多了可能就信了。

如果还是不信。那没关系,已经将风险提前抛出了

“这个需求,确实不好实现。非要这么实现,可能有风险。工期、测试、上线后的稳定性、用户体验等,都可能会出现一些问题”

你要表现出为了项目担忧,而不是不想做的样子。如果,以后真发生了问题,你可以拿出“之前早就说过,多次反馈,无人理睬”这类的说辞。

”你居然不想着如何解决问题,反倒先想如何逃避责任?!“

因此说,这是下下策。不建议程序员玩带有心机的东西。

以上都是浅层次的解读。因为具体还需要结合每个公司,每个领导,每种局面。

总之,想要解决问题,就得想办法

我是掘金@TF男孩,一个可以点播话题聊天的IT男。