Emily拉勾网Lagou
“软件工程师常给外界留下难沟通的印象，作为前端大牛，Nicholas C.Zakas常写零BUG代码，他也承认自己在沟通上出过问题。不过，沟通是双向的，他认为合作者应多了解工程师的日常工作状态，一些时候工程师的情绪事出有因。
▌本文作者：Emily
▌拉勾网编译出品，转载请注明作者及来源
© 2016 拉勾网保留所有权利
►Nicholas 现任职于 BOX，他曾在雅虎工作过5年，任雅虎首页的前端主管，编写过包括《Maintainable JavaScript》在内的多本技术书籍。不满现状、聪明但难伺候，这是刚毕业时周围人对他的评价。他的不满常来自自我与他人对职业角色定位的撕扯。不被定义为创造者，要做出的产品方向已全部定好，工程师只负责把它敲出来。被排斥在创造之外让世界上多了一个愤怒的工程师。
曾在雅虎工作过5年Nicholas选择了离开
8个月后，他结束了第一份工作，有人建议他，下一份工作要去“对产品有深刻理解并有能力搭建出来的地方”。
Nicholas的不满很多工程师并不陌生。期望工程师在项目可行性决策时只走个过场，或者工程师只是敲代码的，最后才被通知加入项目。这让他们很难对产品生出参与感、成就感。产品经理再有修改需求、推翻重来的要求时，工程师的情绪很难被调动。
一些时候，Nicholas发现，产品经理往往对市场商业判断非常在行，提需求时却不够严谨。他对产品经理和工程师的工作场景三个阶段做了一个比喻:
A.建一栋两层有车库的房子，没有平面图，只有房子正面草图
◆
产品经理：快点开始吧，现在能开始做了吧。
工程师：我不知道建筑面积、没有平面图，地基都没打，现在没法下手啊。
◆
B.Deadline定好了
◆
工程师：等着也不是办法，还是先造一个与房子分离的车库吧。房子不知道长啥样，那我先造车库，这样房子需求改变了也可以不受影响。先建一个停一辆车的车库吧。
◆
C.车库造了一周后
◆
产品经理：房子要三层、八间浴室，是蓝色的。
工程师：还好先盖了车库。房子是蓝色的，车库也统一吧。
◆
D.车库完成
◆
工程师：信息这么少，我还能完成，好有成就感！
产品经理：车库不能跟房子分离，要能停两辆车。
工程师：@#￥%……&……&！#
在十多年的开发中，他发现类似的情况几乎每天都发生：工程师如果不做假设，就会无所事事，看着Deadline逼近；工程师一做假设，却很大概率会做出错误的猜测。在工程师的日常工作中，经常碰到提交的需求信息不全，而Deadline早已确定了，大量空白需要工程师来判断与假设。如果假设方向不对，别把问题都推向工程师。
不断变化的需求让工程师疲于应对
除了同一个项目需求时时变化，不同项目间的协调也困扰着工程师，Nicholas发现身边的工程师永远在多个项目间疲于奔命。通常情况下，研发人员永远是不够的，多个项目需要工程师或其他管理者排出优先级。他自己不能忍受的一点是，项目的优先级经常发生变化。在他看来，真正的优先级不应该是临时性的。
一些时候，外行的言辞也让他和其他的软件工程师们恼火不已。
“我也写过代码。”
“不就是几行代码吗，为什么这么大阵仗？”
“XX说这个可以一两天写完。”
从Lagou的职位列表中可以看到，同样的职位可能使用的开发语言有很大差别。工程师在语言背景和知识储备上存在差异，不同的人完成项目时间并不一样。另外，软件世界里日新月异，5年时间编程语言可能发生了翻天覆地的变化。用他人的经验或过去的经历下判断，他们就只能“呵呵”了。
另外的一种情况他也经常遭遇，项目完成后从设计到产品经理都被大大感谢了一番，但工程师的名字却从来没有被提到。工程师完成了项目，他期待的真不是一份冷冰冰的BUG报告。
Nicholas认为，工程师在这些情况下变得难沟通：
需求迟迟不提，没法赶上死线；
需求不明确，早期的假设成无用功；
需求与之前说法完全相反；
小需求带来大变动，增加了工作量，要赶Deadline。
精疲力尽时还提大变动，Deadline就在眼前。
他也给了一些建议：
1尽早让工程师加入
工程师是个逻辑性很强的群体，尽早让他们加入，明白需求从哪里来。这会避免前面提到的建完分离的车库后发现要建的是非分离双车车库。
2少打断工程师的工作
每个工程师都有自己的高产时间，在他们编码的这段时间里，少打断他们吧。要确保他们能持续编程。
3创造空间
这意味着要相信工程师的判断，一些时候产品经理懂些技术能帮他们理解架构，但别越俎代庖告诉工程师要从这里去实现。
4及时感谢与反馈
工程师想要的不是bug报告，长期劳累做出来的作品如果有点小奖励，比如一句“谢谢你的辛苦劳动”，就会让他们觉得自己被尊重。一点积极反馈就能让工程师容忍bug和产品的其他问题。
-END-
所以你有什么和开发GG打交道的奇技淫巧呢？记得给勾妹留言
