管理技术项目时需要考虑的 10 个关键方面

原文：https://medium.com/hackernoon/10-key-aspects-to-consider-when-managing-tech-projects-4a56f89f1c4f

作为一名软件开发人员，如何应对自然的工作进展，以及如何继续做自己喜欢的事情

如今，对于高级软件开发人员(无论是在初创公司还是更具公司风格的公司)来说，从目前的技术角色向更具领导/管理导向的角色转变是一个自然的过程。这种进展通常是由公司/团队/产品发展中产生的几个需求推动的，要求高级开发人员将时间投入到培训/入职、规划/路线图和领导团队上，参与更多宏观层面的决策和指导，同时越来越少地参与日常工程活动。

工作的头衔并不总是“经理”。它通常是工程副总裁或技术/团队/项目负责人，这与你的职称中有经理有不同的含义，尽管它需要大量的管理活动。

在这篇文章中，我将介绍从一个更加面向技术的角色到一个更加面向管理的角色的转变是如何发生的，以及随之而来的问题。我从慈善专业的这篇可爱的文章中得到了一些灵感，你一定要看看。我还将深入探讨在您进行这一转变时所面临的挑战。

“嘿，我已经邀请你参加我们谈过的那个会议了…”

从技术到管理的跳跃是团队成长和你在项目中资历的自然进步。如果团队需要更多的开发人员，那么你可能会参与招聘过程。然后，当这些人加入团队时，你的工作就是指导/接纳他们。如果有重大的设计或架构决策发生，那么你就是负责做出最终决策的人之一。所有这些任务通常都需要大量时间，无论是审查和批准候选人、回复电子邮件还是准备和主持会议。

这意味着你将把大部分时间投入到与管理团队更直接相关的活动中，而不是实际开发软件，这对许多开发人员来说是一个巨大的打击。

然而，这种将焦点转移到更加面向管理的工作可能是不可避免的。作为一名高级开发人员，你携带着项目的技术知识，将是能够判断一个新人是否适合这个项目的人之一。您还将精确地估计任务和规划工作，因为您从一开始就已经是项目的一部分，承担了早期的设计决策并了解架构。所有这些知识都是非常有价值的，雇佣新人来做这种需要这些知识的工作在大多数情况下是不可行的。

话虽如此，这里有一些开发人员从他们的技术角色跳到更注重管理的角色的原因。

薪水

说实话，公司愿意在管理人员招聘上比在技术人员招聘上花更多的钱。我知道这很笼统，可能并不适用于所有的公司，但是作为一名软件开发人员，你比管理其他人的工作更快达到工资上限。

在我看来，这有两个明显的原因。

第一个原因是，软技能通常比硬技能(技术技能)付出更多。

第二个原因是问责制。

软技能比技术技能更难学。当然，你可能有一个超级明星工程师，他是 10 倍的开发人员，可以像其他人一样独自完成工作。但是，如果那个家伙只能独自工作，他真的与你的团队相关吗？他沟通能力差怎么办？你仍然倾向于提升他到一个更注重教练的位置吗？他会做得很好吗？

管理人员需要完成他们的工作，但他们也必须拥有强大的软技能，以解决建设项目中人的方面，如沟通、同理心、团队精神和解决问题。

问责制意味着你将成为团队成功和不足的责任人。当一切都出错的时候，你不会责怪执行操作并做错的人，你会责怪下命令的人，当你是下命令的人，而你的头在砧板上，这意味着更多的钱。

职业和生活方式

软件开发是这样一种工作，你需要不断地学习和升级你的工具包，以保持敏锐，尽可能地做好工作。但是生活和其他的责任可能会让你远离深夜的兼职工作或者典型的博客阅读。这比什么都有心理影响。人们开始觉得自己跟不上最新的技能，于是转到一份给他们更多空间的工作。

此外，随着人们的成熟，他们也对生活和人际交往有了更清晰的理解，因此他们自然会获得沟通技巧和经验，这些对管理运营很有价值。

另一方面，有些人进入软件开发的明确目的是为了往上爬，成为团队的经理。

接受新角色

对于那些正在考虑跳槽的人来说，这里有一些在转型时需要考虑的关键因素。对于这一部分，我真的需要感谢 Alexander Grosse 在 ScaleUp Porto 的 Start&Scale Week如何建立一个技术团队的精彩大师课。

1)将重点从技术工作转移到管理工作

有些人真的害怕管理工作，并努力抓住他们能做的任何技术工作。这并不是一件坏事，因为大多数兼顾技术工作和管理工作的开发人员往往会成功地做到这一点，这使他们能够更多地了解团队需要什么，以及他可以做些什么来疏通团队。如果你的上司/公司允许你从事更多的技术性工作，那就去做吧；如果没有，哎，总有副业要做！

然而，如果你仍然是一个活跃的开发者，不要走在关键的道路上。说真的。

你的时间现在被分配在众多的活动中。如果代码审查或部署依赖于你，那么你正成为团队的瓶颈，仅仅是因为自私和试图尽可能多地保留技术工作。如果你认为自己处于这个位置，不愿意放手，那么你可能不适合管理角色。

2)不要成为团队的枢纽

工程不是孤立存在的。为了向客户交付价值，工程团队需要与其他专业领域共存。让你的团队远离路障或干扰(这是经理的任务)不同于让团队远离任何外部交流。

您的开发人员应该能够与来自不同学科的其他团队和公司产品的最终用户进行互动，以便调整产品的适合度并找到软件中的缺陷。如果这变得难以管理，分配一个时间框架，团队可以在这个时间框架内执行专门针对外部依赖的工作。

3)租赁权

招聘总是一个敏感的话题。招聘过程通常要花很多时间，高层人员花费的时间越多，他们的成本就越高。如果你的公司发展到 20 人以上，你应该考虑招聘专门的人力资源人员。

需要考虑的一些要点是:

如果你需要质量，那就雇佣质量好的人。软件开发人员可能很贵，但他们可以很快赚到他们的价值。至少试着雇佣几个可靠稳定的人来指导团队的其他成员。
不要陷入推荐陷阱，也不要让团队自己做招聘。团队需要多样性，你不想要一个每个人都认为/是一样的团队。
因物有所值而雇用。强迫一个不相信 TDD 的人去做比让一个人学习一门新的语言要难得多。

关于这个话题的最后一点，关于当前软件开发工作的面试/招聘流程被打破，有几种观点。请花些时间回顾一下公司目前的流程，并给出相应的反馈。

4)有目的地入职

在讨论团队生产力和新员工的总体幸福感时，入职是一个至关重要的话题。

关于一家小公司(<10) the onboarding process is usually spontaneous. However, if your team grows beyond that then it is time to grow beyond “hey that’s your seat and please go talk to [person]”.

It is your job as team manager and leader to give people all the context they need and mentor them. You can point the newly hired engineer to the resources he needs, introduce him to the team and the team’s processes and get him started right away. People already know they will be unproductive in the early stages so don’t give them any more reasons to feel that way.

One of the most effective (and helpful in terms of growth) processes of onboarding is support. By being assigned support tasks, the newly hired member can work on his communication skills, understand different problems and parts of the product and navigate around the project while closing support tickets. This will greatly help him or her in understanding the product, the market and how everything works. It is also, in my opinion, a growth experience since one, as a developer, will understand the product’s issues from the customer’s perspective, which can lead to understanding what failed in terms of user experience and what can be improved.

5) Have 1 on 1's

There’s not much science in this. You should be having one on one conversations with you team members. In these discussions you should focus on figuring out how they’re doing, how they are adapting to the team and the company and what they see as potential problems in the future. You’ll not only be building a trusting relationship with the other person but also figuring out some underlying concerns which may not arise in the day-to-day operations.

You should also look to give (and receive) feedback in these instances. 这里有一篇很棒的文章，关于如何处理对初级开发人员的反馈(我犯了第二种错误)。

6)处理技术债务

作为一名开发人员出身的经理，你比任何人都清楚，困扰开发人员最多的事情之一就是技术债务。没有人想在一个有缺陷的基础上建造一座房子，所以，只要有可能，给你的团队一些空间来重构和重组。

技术债务可能是决定团队士气的因素之一。如果团队能够解决技术债务，他们会觉得他们的工作得到了尊重，并且在计划期间做出的妥协现在可以得到适当的解决。另一方面，永远不能做一些“家务”最终会导致沮丧、疲劳，并最终成为人们离开团队的原因。

7)激励沟通和协作

你需要知道人们在做什么。如果你不知道，那你就不知道你在做什么。使用您可以使用的工具来跟踪这一点，不仅可以了解是否一切都按预期运行，还可以在需要时解除对人们的封锁。

此外，定期进行演示。团队需要能够向公司的其他人展示他们所做的工作。这将使每个人都专注于交付正确的(像样的)东西，也将作为其他没有参与的人的状态更新。

8)定义文化和价值观

成长是文化的敌人。大多数公司以拥有令人惊叹的文化而自豪，却发现这种文化是首席执行官们信念的回声。

问问你自己，问问你的队友——“我们的文化是什么？”

如果你还没有一个明确的文化声明，那么也许是时候通知公司对此需要做些什么了，否则每个团队都会创造自己的文化，这种文化通常是由最具支配地位的人的意见来定义的。即使负责人是正直的，他们的个人价值观也可能与公司定义的文化相冲突。文化定义是一项每个人都应该参与的工作。这个定义随着团队/公司的成长和更多人的贡献而不断发展。

价值观是在公司层面和团队层面培养的东西。在软件开发团队的情况下，价值可以是实施 TDD 和代码审查，或者总是有一个明确定义的 git 流程。总是留意那些不坚持团队价值观的人。价值冲突导致的倦怠是真实存在的，它可能是团队不稳定的原因。

9)获得反馈

不是每个人都有管理经验，或者从一开始就能妥善管理。如果需要，适当的培训。这可以是读一本书，做一门课程或者开一个研讨会。请确保培训结束后，负责管理公司不同部门或团队的每个人都聚在一起，讨论在管理方法方面哪些可行，哪些不可行。

此外，如果可能的话，让其他同等地位的人来评价你的工作。同行评审总是能有效地发现工作中可以改进的地方。

10)不要长时间说教

作为导师和领导者，你有责任做出榜样，如果你现在还不知道长时间工作的坏处，那么你应该了解一下。它可能会在你不知情的情况下暗中伤害你的团队。我发现这篇文章在这个问题上很有启发性。

结论

从开发人员跳到管理人员并不是一件容易的事情，但它可能会让人们走上一条更有意义的职业道路。想想你想做什么，在什么情况下你会管理一个工程团队。还要记住，这种转变需要你精通团队工作的很多领域。

如果你喜欢这篇文章，请考虑为它鼓掌并关注我的和 [推特](https://twitter.com/CMatiasJunior) 。感谢所有反馈！