那些年,职场菜鸟教会我这些……


您现在的位置:康扬信息门户网 > 科技 > 那些年,职场菜鸟教会我这些……

2853人阅读

在工作场所,你遇到过非常抗拒和他们一起工作的人吗?在总结和分析了这些人的特点之后,我们能找到什么样的思考点和改进点?

在我们的日常工作中,与他人合作是不可避免的。

然而,与完全不了解自己观点的人相处往往是一种冒险——传说中的流畅合作似乎只存在于书籍中,而现实世界中的合作往往难以融入,而且大部分都相互制约。

毫无疑问,在许多项目中,我共事过的许多同事(我称之为与同事共事的人,不区分内部和外部,比如其他团队合作伙伴也可以被视为同事)开阔了我的眼界,极大地鼓舞了我,并从长期或短期合作中受益匪浅。相比之下,我也对来自相反方向的许多同事印象深刻。

我仔细回想,如果我列出“我最不想与之合作的人的特征”,我可能不是这样的人,但我也有可能使具有这些特征的人受益。

俗话说,如果你有什么东西,就去改变它;如果你一无所有,鼓励它。这也被称为“它”。

当然,在团队中,效率最低的是那些无所事事的人。

然而,与大多数人的直觉相反,做任何事情的人的效率是第二低的(如果不是最低的话)。这些人被大量积压所支配,陷入其中,无法自拔。未完成的任务可能会相互影响,直到崩溃。大多数时候,这些人甚至没有被分配手头的工作,但是他们自己承担。

如果你认为所有的任务都很重要,那就意味着所有的任务都不重要。具体来说,这种方法有许多潜在问题,对个人和团队都有害:

正如凤凰城项目中描述的场景,超级巨星成员成为团队中最大的瓶颈。当超级巨星的带宽被完全占用时,队列中的所有工作都需要进入等待状态,这条曲线呈指数级增长。

一个好的团队成员在某种程度上需要遵循unix哲学中的一个原则:一次只做一件事,做到最好。

当然,这并不妨碍团队成员在许多方面拥有优秀的技术专长。关键是集中精力做好每项任务。

最有趣的是,在这种情况下,即使同事的主观意愿很好,个人能力也很优秀,如果从外部来衡量整个团队的产出,效率仍然会低于平均水平。也就是说,缺乏策略的繁忙工作实际上是有帮助的。

在我早期的一个项目中,在产品开发的某个阶段之后,团队进行了类似bug bash的活动:收集产品中潜在的设计缺陷(包括可用性和功能性设计)。

一位同事提出了从各个方面发现的近30个“问题”,但他几乎没有给出任何有用的建议。

基本上,这是一对:这个产品完全是垃圾,我不知道如何把它变成更好的心态。后来,团队不得不从头到尾匆忙结束设计缺陷的收集,并再次开始做一些前期设计。

这种人在工作中很容易让人讨厌。一方面,他们经常释放强烈的负面能量,怨恨地看着一切。另一方面,他不愿意或不能提出任何有效的改进方法。

应该指出的是,提出问题很容易,特别是那些不需要自己解决的问题,而想出可能的解决办法相对困难。

此外,很容易想到一个直观的方案,而很难给出多个选项并比较它们的优缺点。

最后,如果你想真正解决问题或者让工作真正向前推进,你需要尝试做更困难的事情(比如列出和比较可能的解决方案,给出可行的计划),并尝试简化其他人的工作。

事实上,在这个行业里有很多伟大的神在说啊说。它们必须被称为高内聚力和低耦合度。他们经常使用s.o.l.i.d .他们非常熟悉各种编程范例。然而,当涉及到实际工作时,要么让他自己动手,要么他被迫写几行代码,这些代码可能无法通过编译,而内容却很难阅读。

在这种情况下,当他用鼠标在文件列表中逐个搜索文件时,我会抓住键盘,然后确保他没有触摸键盘。如果他心情好,我会说服他写更多的代码。

解决这个问题的方法实际上并不复杂。

胡适说:多研究问题,少谈“社会主义”。

让我说,我们应该写更多的商业代码,少谈理论。我们都知道,在实践中,用tdd写一个嘶嘶声是一回事。使用相同的方法和原则来抽象和分类复杂的业务逻辑完全是另一回事。

这些人经常混淆知道和能够做的界限,知道和做是不统一的。正如著名的漫画《一匹马》想表达的那样:

在大多数情况下,我们缺少的不是用简单的笔画画几个圆圈,而是被轻视的细节。无论如何,我们的各种理论最终都将体现在可以实际执行的软件代码中。

说话很便宜,给我看看代码。

——莱纳斯·托瓦尔兹

一些常见的参考技术有:

简而言之,坐着聊天比行动要好。

这种人讨厌变化,这种情绪可能来自在过去的项目中引入新技术后的负面体验,或者是对新事物完全缺乏兴趣,或者两者兼而有之。

一句话,你经常从他们口中听到的是,例如,“为什么不使用redux”(因为redux对我来说很熟悉),或者为什么使用“材质ui”(因为我不能)。事实上,这种情况甚至可能发生在那些曾经渴望和激进的技术人员身上。

在大多数情况下,他们没有勇气走出“舒适区”。他们错误地认为,他们掌握的技术永远不会过期,是解决手头问题的最佳方案。那么现实是没有什么是一成不变的。技术很快就会到期,通常比我们想象的要快得多。

当我加入思想工作时,错误是Xi办公室的主流。主干+茉莉在前面是一项新技术。两年后,一些团队开始偶尔用angular1.2、bower、phantomjs等进行实验。这些技术现在在哪里?

React+redux,graphql确实可以简化许多场景中的前端工作,但是谁知道下一个突破性的变化在哪里悄然酝酿?

另一端是追求所有新事物,这是不够的——它浪费了你大量的时间和精力在可能永远不会涉及的技术上。

尽管如此,我认为开发人员至少可以对新技术保持好奇和新鲜的态度,同时与他们保持一定的距离。您不一定需要在下一个项目中采用github趋势的star框架,但是需要一些时间来确保您知道它与类似产品相比的优缺点,以及主要的应用场景等。可以防止你在做技术决定时过于盲目和有偏见。

在前端和后端分工明确的团队中,前端开发人员负责实现接口,消耗后端api返回的数据,并可能格式化一些可能的数据。后端负责与下游服务交互,并为前端演示组织数据。

这种操作模式的一个极端是前端和后端只通过合同合作,而一端完全忽略另一端,将它视为一个黑盒。从表面上看,这种隔离可以带来一些好处:前端和后端的进展相对独立,并且互不影响。然而,我一直怀疑这种机械分离能否真正带来承诺的好处。

然而,它带来的问题通常是非常重要的:由于集成延迟而导致的价值交付延迟。更严重的是,人们会忽视团队作为一个整体对结果负责的根本问题。当问题出现时,他们经常互相指责。我听到了太多来自前端开发人员的抱怨:“这是后端api的问题”或者“这个问题是由后端没有超时处理网络造成的”,这自然将问题简化为“别人的问题”。

“这是后端api的一个问题”的描述本身并不是一个问题,但它不应该被视为问题的结论,相反,它应该是进一步探索的开始:更系统和端到端解决问题的开始。这种描述可以引导物理上分开的两组同事一起面对问题,并找出适合当前架构的方案。

我经常看到人们抱怨他们的遗留代码有多糟糕,添加新功能有多困难。当你试图质疑他为什么不在这些问题上采取行动时,他会告诉你这些都是历史原因——这就是代码最初的编写方式。

实际上,这种情况经常与其他症状同时出现:

这种情况和“这是一个后端问题”在本质上可以归为同一类。他们都试图让自己置身事外,并将问题归咎于他人(即使所谓的遗留代码是他们自己编写的)。如果“这是一个后端问题”在某些情况下可以用作借口,例如当后端是另一个团队甚至另一家公司提供的代码时,那么“历史遗留问题”的说法完全是无稽之谈。

这种说法故意把自己描绘成一个无法应对糟糕局面的受害者,仿佛在说,如果有一个理想的起点——让我再写一遍——他肯定能做得比现在更好。

但是我们都知道这个假设不一定是真的。事实上,从你决定写一些代码的那一刻起,代码和架构就已经在为衰退做准备了,除非你花足够的时间和精力来持续改进和修复它。

这是事物的本质,不会随着人们的客观意志而改变。

因此,历史上没有遗留下来的问题。它们只是常见的问题。解决问题的第一步始终是直面问题,并意识到历史遗留的所谓问题与我们将要开发的新需求或需要修复的在线缺陷是一样的,而卡上需求的微小变化只需签字即可。

简而言之,我们可以像故事墙一样维护技术债务板,并定期维护它,根据工作量和价值确定优先级,然后一步一步地消除它。

我从事过许多遗留项目,其中一些是我接手后已经存在了很长时间的旧代码,其他的是从头开始编写的,但是随着需求的增加和变化,它们逐渐被破坏了。

我发现有效的方法是把我新写的代码和旧的代码一样对待——建立测试以形成一个安全网,进行适度的重构(从重命名变量到删除模块),并使代码比以前稍微好一点。

当然,这需要整个团队的每个成员对代码质量有相似的理解和足够的动手能力,同时,还需要持续的努力和精力来维护它。

这篇文章列出了我在各种项目中遇到的一些不可靠的同事,包括在思想工作内外一起工作的人。甚至我自己也可能在不同的阶段表现出这里列出的一些特征。

如上所述,解决问题的第一步总是认清并正视问题。只有我们有勇气去做这件事,我们才能讨论如何解决它们。如果我只列出问题而不讨论解决办法,我就会变成上面提到的“祥林嫂”风格。幸运的是,这些问题可以通过技术手段消除(相应于上述问题)。

作者:邱陶俊思想作品,微信公众号:思想作品洞察

这篇文章最初是由@ Strike发表的。每个人都是产品经理。未经允许禁止复制。

主题地图来自unsplash,基于cc0协议。