客户旅程_我对工程管理的旅程的现场笔记

客户旅程

我正在经历一个所谓的“ 职业青春期 ”。 我正在成长，并要担任工程经理一职。 这更多是对我有机地担任的职位和我事实上已经从事一段时间的工作的认可，而不是由外部因素决定的突然变化。

然而，改变是困难的。 一方面感觉就像是我职业的自然发展，另一方面，感觉就像我必须改变工作方式的一切。

有三个维度可供探索：“ 我如何看待自己 ”，“ 我如何解决问题 ”和“ 其他人如何看待我 ”。

我如何看待自己

我一直把自己看作是程序员。 我喜欢编码，但现在我不再这样做了。 我的新职责集中在确保团队成员（而不是我）可以高效地编码。 操我，我确实错过了编码。

我记得我的代数教授曾经告诉过我们一个轶事：数学家和工程师之间曾经有过一场辩论，关于辩论的技巧是最重要的。 数学家们宣称自己是一门高级学科，因为没有数学就不可能存在工程学。 干净利落。 工程师指出，没有现实的应用程序，数学本身就一文不值。 辩论进行了一段时间，工程师们在实用性的基础上赢得了争论：仅仅为了数学而做数学没有任何实际好处。 当一切似乎都消失了时，数学家的院长站起来说：“我们之所以做爱，是因为我们喜欢它，而不仅仅是生孩子。 与数学相同，我们这样做是因为我们喜欢，而不是因为您需要它！”。 不用说，数学家赢了。

在很多情况下，工程师不为产品编码，我们编码是因为我们喜欢它。 我们为代码编写代码。

编程是一样的。 在很多情况下，工程师不为产品编码，我们编码是因为我们喜欢它。 我们为代码编写代码。 架构良好的代码库一定程度上可以使我们内部感到温暖和模糊。 确切地说，产品需求成为次要的。

产品小组的另一边是产品团队，其职责是推动新功能和面向用户的改进。 对于他们来说，代码只是达到目的的一种手段。 他们不在乎底层技术是Java还是python，或者前端是Vue还是React。 同样，当我购买炸薯条时，我不会操心马铃薯的种植地。 或伏特加酒。

工程团队和产品团队之间的关系坎bump，每个团队都追求自己的目标和愿景。 基于两者之间的平衡，我看到了4种情况：

• 他们俩都糟透了-将弱势的工程团队与弱势的产品团队相结合是灾难的根源。 这里没什么可做的。 继续。
• 弱小的工程团队和强大的产品团队-产品具有所有正确的功能，但速度慢且笨拙。 经常发生崩溃，新的发展总是落后于计划。 充满安全漏洞。 想想Windows 95/98 / Millenium Edition / XP（我使用Windows已有十多年了，所以我不知道新版本如何）
• 强大的工程团队和虚弱的产品团队-产品运作得非常好，它可靠，强大，安全，不会崩溃。 没有人想要使用它。 考虑一下Linux的核心版本：Slackware，Kali，Arch。
• 强大的工程团队和强大的产品团队-产品美观，可用，可靠，安全且坚固。 想想Google或Apple。

当然，最后一种情况是可取的。 各地的公司都在努力实现这一目标，并花费巨资聘请最优秀的人才。 但是有时，结果并没有达到人们预期的水平。 罪魁祸首是有效沟通中永远存在的问题。 两个团队，两个价值观，两个不同的愿景。 圆根本不相交的维恩图。

这就是工程经理的职位。我的工作是弥合两方之间的沟通。 为此，我需要更好地了解产品人员。

我从两个方面开始：首先-在会议期间要特别注意。 与整个shebang：积极聆听，做笔记，提问。 其次，通过将产品指标与技术指标联系起来，找到一种通用语言。 例如跳出率和性能得分。 当我们查看针对相同目标的两个工作流而不是“我们与他们”的方法时，进行协作更容易。

感觉就像再度进入青春期。 那时，我发现女孩实际上并不那么糟糕。 现在，我了解到产品所有者和项目经理也不是那么糟糕。 希望这次会更好...

我该如何解决问题

作为工程师，我必须解决技术问题。 当遇到这些问题时，我正在应用技术解决方案。 往往直截了当：“ 重构此 ”，“该单元测试 ”，“ 升级这些库 ”。 偶尔有“ 谁写了这个白痴？ 哦，六个月前是我……没关系！ ”。 随着时间的流逝，我真的很擅长解决这类问题。

但这就是过去。 作为一名工程经理，我无法遵循我的最初直觉并潜入水中。如果存在导致团队无法找到解决方案的问题，我需要确定并解决该问题，排除障碍，让团队找到技术解决方案。

自己尝试编写解决方案是错误的事情。 它没有解决团队内部的潜在问题，因此，将来很可能会重新出现。 即使我尝试，影响也会很小。 我无法超越团队的其他成员。 我很好，但我不是那个*好。 而且，如果可以的话，就不需要团队了。

我无法超越团队的其他成员。 我很好，但我不是那个*好。

不幸的是，我已经在实践中多次看到这种情况，并且结果始终是灾难性的：尽管付出了额外的努力确实帮助团队实现了一个或两个次要的里程碑，但相关经理却不知所措，最终精疲力尽。 由于根本没有解决根本问题，因此团队陷入混乱。 最后，经理或团队中的很大一部分都辞职了。

我需要学习远离游戏。 从球员那里，我需要成为教练。 但这是容易的部分。 困难的部分是其他工程师的线路管理。

就家畜而言，众所周知，猫很难训练。 他们非常独立，不会成群结队。 他们不听指示，而团队合作不是他们的自然状态。 到目前为止，我们有一个成语-放牧猫-传达了组织和控制一组本来无法控制的实体的困难。

我已经工作了几个月，对曾经有过的每位经理都感到难过

我们有一句话： 管理软件工程师就像放羊！ 甚至有关于它的书： 放牧猫和编码员：非技术人员或放牧猫的 软件开发 ：程序员的入门入门，带领程序员命名。 没错 就像他妈的一样复杂。 我已经工作了几个月，对于我曾经有过的每位经理，我已经感到难过。

我需要将自己的发展从纯粹的硬技能转变为软技能。 到目前为止，我的重点是学习框架X或Y或了解最新趋势。 现在，我需要能够处理矛盾的讨论，而又不会丢下我的狗屎。

别人怎么看我

改变的最后一点是我与同伴的关系。 作为在公司工作了多年的一名工程师，我被视为退伍军人之一。 长老。 我在Frontend的大多数同事都接受了我的采访。 我设计了采访过程。 我的观点很重要。

作为工程经理，我是新秀。 刚开始，用我的脚趾测试水域。 尝试向经验丰富的人学习。 从他们的成功和错误。 我知道我也必须从自己的错误中吸取教训，但这是我想从小处着手的领域。

是时候检查明天的会议了……

翻译自: https://hackernoon.com/field-notes-from-my-journey-into-engineering-management-rver3wcl

客户旅程