使新手开发经理失败的8个简单步骤



恭喜,您是新任经理! 不,老实说,我全心全意。 您听到声音里有讽刺吗? 好吧,很抱歉,我已尽力而为,但当然,伴随着兴奋,还有一些怀疑和悲伤。 您可能必须经历我和其他许多人经历的所有事情。 您已经担任软件工程师多年(或在此从事其他职业),表现出色,获得“高级”称号,被视为团队中的非正式领导。 到目前为止,可能是团队负责人。 也许有一段时间他们甚至抵制了这种“增长”,不想离开编程,失去了技能。 但实际上,他们担心自己无法应付。 最后,以某种方式说服了您抓住机会-现在就在这里。 从首席工程师到新手经理。

如何成功担任新角色? 如何再次完成所有步骤并达到每个人都期望的结果和信任水平,尤其是您自己? 数以百计的书籍和成千上万的博客正试图找到这些答案,所以我不会假装自己有成功的秘诀。 但是我知道几种绝对可以保证您失败的方法。

1.继续编程


评论肯定会掀起一场风暴。 您的公司可能期望经理继续通过两种方式进行编程。 我的经验,以及许多其他人的经验表明,通常这是通往无处可去的道路。 不可能坐在两把椅子上并充分注意这两件作品中的每件作品,因此您都将失败。 如果您对公司很幸运,那么您将被迫几乎签署拒绝程序的签名。

好的,即使您期望部分编写代码,现在绝对也不是主要任务。 关键是,您尝试编程时会不确定您担任新职位时该做什么。 因此,您正在转向熟悉且方便的工作。 这可能会在某些项目中带来短期利益,并给您带来安慰的感觉,但是我保证您正在偏离主要目标。 您损害团队的长期结果,也不会从事新职业。

任何人都不太可能希望采用并放弃宝贵而来之不易的技术经验。 本文为想要维护编程实践的经理提供了一些不错的选择。

2.只专注于工作,不专注于人


经理负有两个重要职责:组建团队和使业务受益。 我想说,应该按优先顺序排列优先级。 第一个强化了第二个。

有效工作的典型图景是项目的完成,功能的发布,错误的纠正等。如果您设法避免陷入“领先程序员”的陷阱并避免日常编程,那么您将以某种方式设法满足日常任务的通常需求以获取成功有用感。 这通常会导致一个人担任项目经理或监督者的情况:分配故障单,跟踪指标,请求状态更新,讨论体系结构,保留故事等。 简而言之,专注于工作 。 您每天都检查清单,感觉事情进展顺利。

就是这样 但这只是工作的一半。 轻松一半。 因为另一半比较难,所以与您以前做的不一样,并且可能是您最缺乏经验的地方。 这就是您团队的成长。 帮助人们不仅在技术上,而且在生产力上增长。 寻找提高参与度的方法。 一对一交谈,听,教。 事实证明,这些“轻松”活动是困难的部分。 而且,如果您忽略它,则会阻碍大多数性能。 您将获得结果,但远没有团队最大的潜力。 您将展示效率的提高,但并不是真正的进步。 您永远不会认真提高标准-而且您也不知道为什么。

团队效率始于员工本身,而不是工作。

3.通过绩效衡量您的价值


过去,作为个人员工,您很容易评估工作效率:“今天我实现了两个功能”,“修复了这个疯狂的错误”,“所有测试都通过了”。 这些是与小组成果挂钩的有形工作单位。 并在提交中指出您的名字。 很容易看到特定员工的工作并通过其结果使团队更接近其目标来对其进行评估。

但是现在,您的大部分影响都在二阶效应上。 他们更难以与团队的工作联系起来。 混乱的局面使您的工作不再正规化。 您并不总是确定自己在做任何“工作”。

因此,作为一名新经理,您通常会承担一些特定的任务-并执行这些任务以获取完整感和收益。 而且,这些任务的实际重要性可能被高估了。 演示文稿,预算,状态报告,Scrum工件-可以计算,但是不起作用。 实际上,您的工作取决于团队的成就。 他们的成就是主要目标。 最终,您的价值取决于他们的成功。 关注团队及其成功所需的条件。

4.不要谈论你的期望


您是否已明确为自己制定了对团队的期望? 来自每个人? 你告诉他们了吗?

我们自然认为另一个人的思想与我们的思想相同。 我们拥有相同的纪律,动机和逻辑。 这导致了许多假设。 如果我们查看的是具有相同规格的相同任务集,那么我们自然应该得出与完成工作的方式和时间相同的结论。 好吧好吧 因此,我们给作业分配了一定数量的信息,但未说明和假定的期望。 您知道在这种情况下会发生什么。

分配任务时,请务必就假设和期望达成一致。

“只记得记录您的发现,然后在编写任何代码之前与团队一起对它们进行审查。”

“这个故事阻碍了质量检查,因此这是您的首要任务。 我假设您需要30分钟才能暂停当前的工作。 如果故事不能在一天结束之前完成,请尽快通知我。”

制定潜意识的期望要困难得多,这些潜意识的期望直到被打破才是您所不认识的。 这是您的个人决策模型, 将如何 。 您只是假设一切都会如此。 但是,当然,您没有制定它们,而当结果不一致时,您将对其他人感到失望。 这非常使团队沮丧和士气低落。 如果您对他们的工作有期望,最好报告一下。 您不会被迫猜测。 如果不确定自己的期望,那就花点时间-整理自己并理解它们。 这是您的工作,是您对团队的责任,也许是老板的期望。

5.放弃义务


您是新任经理,想打动老板。 “我们当然可以做到”,是的,是的,是的。 保证团队将无法履行职责。 我相信我们大多数人都在另一边。 您将获得从未达成的不切实际的期限和任务。 您如何看待您的老板? 当然,一个团队可以团结起来,发掘出不可能的事情,但是我敢肯定,故事不会就此结束。 您的老板现在看起来不错-并不断做出相同的承诺。 很快,团队就失去了耐心,人们开始辞职,转到其他团队甚至离开公司。

很难逆势而上,但您必须制止这种潮流。 需要保护团队。 怎么做? 对于初学者,不要成为英雄。 对于老板,客户或业务合作伙伴的任何请求,请不要立即回答“是”。 赢得一些时间,让团队参与其中。 尽可能向员工展示全局。 为什么这对公司很重要? 如何影响客户? 真正在问我们什么? 最重要的是,让团队参与决策:“鉴于所有信息,您认为我们能做什么?”

有时您别无选择,只能接受并下达命令,但是如果团队参与讨论会更好。

6.混淆指挥与领导


站在椅子上并下达命令不是领导。 经理经常会协调工作并分配任务。 但这不要与领导层混淆。 命令分配的增加通常是我们所说的微观管理的症状-这导致团队失去自主工作能力的事实。 员工期望所有决定都来自您。 最后,您将成为团队瓶颈。 您已经创建了一个效率低下的团队,只能简单地进行通常的动作,期望下一个任务,然后漫不经心地执行。

领导者激励而不是命令。 他描绘了目标的图片并设定了方向,而不是给出方向。 他灌输了一般的目的和意义。 通过任务,战略和目标提供足够的背景信息,以便人们做出正确的决定。

7.避免刻薄交谈


如果您设法避免了大多数此类错误,那么我对您个人有挑战。 这就是团队领导者与普通经理,学生与老师,初学者与专业人士的区别。

当您是开发人员时,您可能就项目,设计,技术选择,编程方法等进行了激烈的讨论。 但是人,人际冲突和抱怨的真正问题是什么? 好吧,老板通常会这样做,如果有人在乎的话。 你猜怎么着? 现在您是老板,所有这些都飞向您。 其中一名员工使您陷入问题,或者其他人想要解决事件。 但是通常,您会亲自看到一些行为和行为上的问题。 它们与您的价值观或团队的价值观不符-您确实需要这样做。 您劳累,头脑开始提出各种借口和避免这种情况的理由。 但正是在这一刻,您的勇气和专业素质得到了检验。 最重要的一点。 这是您在组织中进行真正变革的最佳机会。 正是在这样的时刻,您可以帮助人们(包括您自己)提高到一个新的水平。 对这种情况持积极态度是建立一支高效团队的秘诀。

怎么不怕艰难的交谈和面对面解决问题? 我们必须停止运行它们。 像许多其他技能一样,学习的唯一途径是练习。 从某种意义上讲,您是在生产中进行编码。 但是,有一些准备方法和某些策略可以增加获得良好结果的机会。 互联网上有很多技巧,因此,请-选择一些测试技术。 从“基本对话”开始可能是值得的。

以下是一些基本知识:

  • 尝试尽快解决问题。 拉得越久,对话越难。
  • 具体并举例子。 这是在我脑海中浮现信息时迅速提出问题的另一个原因。
  • 准备好 考虑如何开始对话,最重要的是,您想从对话中获得什么。 主要信息是什么,预期结果是什么? 考虑该人可能的反应,问题和答案,并考虑如何回答。
  • 对话应侧重于行为或行动,而不是个人本身。 与其说“您不尊重人”,不如说“当您制作X时,它看起来就不尊重人了”。 一个好主意是关注他们的行动的后果。 对他人的影响或对人本人的负面和非显而易见的后果。
  • 选择正确的时间和地点。 在走廊上截取一个人对于快速反馈非常有用,特别是在加强以往的交谈中。 但是,如果期望进行长时间艰苦的交谈,请确保他有一个私人的地方并且有足够的时间。 最糟糕的事情是计划一些小的时间间隔,然后中断,使对话无法完成。
  • 当然,最好的计划是缺席。 不要使局势陷入复杂的冲突,而要从一开始就解决问题,然后逐步升级。 定期有效地与员工进行面谈是一个很好的机会,可以讨论仍然很小或根本没有的问题。

当我第一次准备进行这样的对话时,我非常恐惧,我遭受了好几天的痛苦。 但是,一切都比我想象中描绘的世界末日画面容易得多。 对话确实帮助并极大地简化了进一步的交流。 因此,克服恐惧-一切都不会像您想的那样糟糕,但是结果值得。 您的团队应得的,您自己会说声谢谢。

8.停止提高技能


还记得为成为一名出色的工程师而花了多年的时间来学习最新的技术,工具,语言和框架吗? 经理在这里的角色没有任何改变。 管理是一种技能,艺术,实践。 这是您随着时间的推移而获得的能力。 它需要与工程师一样的努力和奉献精神。

我发现许多与程序员相同的成功方法都可以用于管理。 博客,书籍,会议和社交网络。 在Kubernetes中有关容器管理的每篇文章中,都有一篇关于扩展精益团队的文章。 对于每本有关学习Golang的书,都有一本关于有效谈判策略的书。 对于会议上有关微服务监控的每一次演讲,都有关于使用指标和指标研究团队的最佳实践的说明。

好吧,我夸张了。 实际上,关于技术和管理的资源比例是100:1。

有糟糕的经理人,有优秀的经理人。 初学者和专家。 和编程一样,这是天赋的,但是主要的决定性因素是对学习和提高技能水平的持续渴望。



当我从开发人员转到管理人员时,我感到沮丧,但也充满活力。 从头开始,学习很多……但是我将学到很多。 我可以从全新的角度定义自己的个性。

我还有很长的路要走。 通过时,我可能会写关于如何取得成功的文章。 同时,我专心致志于没有失败。

Source: https://habr.com/ru/post/zh-CN423749/


All Articles