关于前端项目技术排期，我有话要说！

本文源于一条评论。

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，就是拿不同的前提，去要求同样的结果。

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

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

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

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

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

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

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

”你居然不想着如何解决问题，反倒先想如何逃避责任？！“

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

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

总之，「想要解决问题，就得想办法」。

最后