垂死病中惊坐起

by Victoriya Kalmanovich

由Victoriya Kalmanovich

我如何开始恢复垂死的软件团队的过程 (How I started the process of healing a dying software group)

Imagine yourselves managing a software development group which consists of very strong programmers. They research and develop one of the most complicated systems known to mankind. They write and write and write code — but eventually, no one wants software versions of that code. No one knows what they actually do day to day. The truth is — no one believes in your group.

想象一下自己管理一个由非常强大的程序员组成的软件开发小组。 他们研究和开发人类已知的最复杂的系统之一。 他们编写和编写并编写代码-但最终，没有人想要该代码的软件版本。 没有人知道他们每天实际做什么。 事实是–没有人相信您的团队。

This year I became a software development group manager, and I’ve had to deal with 15 employees in 3 teams who, from the moment they arrive until the moment they leave the office — feel transparent.

今年，我成为软件开发小组经理，我不得不与3个团队中的15名员工打交道，从他们到达公司到离开办公室，他们都感到透明。

This is my story, which will illustrate my journey as group lead, from a moment before closing the group, to a well appreciated, needed and a formal authority in the corporation. In this blog post, I will present the group’s background including a few major failure points which occurred in my group — and which can occur in many big corporations.

这是我的故事，这将说明我作为小组领导的旅程，从关闭小组之前的那一刻起，到公司受到赞赏，需要和正式授权的过程。 在此博客文章中，我将介绍团队的背景，包括团队中发生的一些主要失败点，并且在许多大公司中也可能发生。

In my professional past, I developed defense systems as a software engineer, managed autonomous vehicle projects for very big clients, developed autonomous vehicles navigation algorithms and organized events as a data science community manager. Becoming a software group manager, after a very technical professional past, was not an easy task.

在我的职业生涯中，我以软件工程师的身份开发防御系统，为非常大的客户管理自动驾驶汽车项目，开发了自动驾驶汽车导航算法，并以数据科学社区经理的身份组织了各种活动。 在经历过非常专业的技术工作后，成为软件组经理并非易事。

The more problems I’ve diagnosed in my group, the more it seemed like a failing startup — there was no money, no client, no motivation. I arrived a moment before shut down.

我在小组中诊断出的问题越多，就好像失败的创业公司越多-没有钱，没有客户，没有动力。 我在关机前片刻到达了。

Before managing my group, I heard of it from many different sources. The main idea was its low productivity and a grand waste of human resources. I had to try and understand — how can such a talented group of software engineers not get their well-deserved recognition? How can they work on such important projects and still seem to be wasting theirs and the company’s time?

在管理我的小组之前，我从许多不同的来源听说过它。 主要思想是生产率低下，人力资源大量浪费。 我不得不试着理解-这样一支才华横溢的软件工程师团队怎能不得到他们当之无愧的认可？ 他们如何处理如此重要的项目，却仍然在浪费他们的时间和公司的时间？

The more hours I spent at the office, the more challenges I discovered within the group.

我在办公室花费的时间越多，在团队中发现的挑战就越多。

I felt that in order to succeed, I needed to reach out to the people as my first step, before digging further into the projects. I scheduled one-on-one talks with everybody and a separate talk for each team. My intention was to map out my people’s thoughts, strengths and professional interests, in order to be as impartial as I could to gossip.

我认为，要取得成功，我需要先与人们接触，然后再深入研究项目。 我安排了与每个人的一对一讲座，并为每个团队分别进行了讲座。 我的意图是勾勒出我的人民的思想，才能和职业兴趣，以便尽可能地做到八卦。

In the meantime, I started mapping out all the projects the group had been working on at the time, and the picture I got was so scattered and misguided that none of them actually knew what the group’s main objective was.

同时，我开始计划该小组当时正在从事的所有项目，而我得到的画面是如此分散和被误导，以至于他们实际上都不知道该小组的主要目标是什么。

It was very clear to me that over the years the group has lost its professional identity.

对我来说很清楚，多年来，该团队已经失去了专业地位。

一群人如何失去其身份？ (How does a group lose its identity?)

When the group was established, it had a very well defined purpose and a great value as it was beneficial for the client. It was in charge of application hosting platforms and applications which were consequently hosted upon these platforms.

成立该小组时，它具有明确的目的和巨大的价值，因为它对客户有利。 它负责应用程序托管平台和因此托管在这些平台上的应用程序。

After the final version of each of the developed products was released, the spiraling began. The group received projects that had nothing to do with its main purpose, they began supporting technical issues in order to help clients other than the main client, and worst of all — the group stopped releasing versions. Unfortunate managing choices let the group’s already bad reputation deteriorate immensely. Its identity had been completely wiped out.

在每种开发产品的最终版本发布之后，螺旋式增长开始了。 该小组收到的项目与其主要目的无关，他们开始支持技术问题，以帮助主要客户以外的其他客户，最糟糕的是，该小组停止发布版本。 不幸的管理选择使该集团本来就很差的声誉大大恶化。 它的身份已被彻底抹去。

I immediately devised a plan which consisted of freshening up the teams, teaching proper agile development methodology and strengthening the teams’ leads. On the verge of change, I decided to wait. I had spotted a hostile group member.

我立即制定了一个计划，其中包括更新团队，教授正确的敏捷开发方法并加强团队的领导能力。 在变化的边缘，我决定等待。 我发现了一个敌对的小组成员。

It was a programmer who the former group manager put in a team lead position. He got to manage the strongest team of all three. As a team lead, he somehow managed to wreak havoc upon the entire group and be completely unproductive.

前程序员是团队负责人，是一名程序员。 他必须管理这三支队伍中最强大的一支。 作为团队负责人，他莫名其妙地对整个团队造成了破坏，并且完全没有生产力。

I knew I had to deal with the human resources problem before I headed on to solving the other issues.

我知道我必须先解决人力资源问题，然后再着手解决其他问题。

To sum up some of the damage he caused over the years:

总结一下他多年来造成的一些损失：

• he set irrelevant assignments to his group members他为小组成员设置了无关的任务
• disappeared for large amounts of time during the day白天消失了很多时间
• failed to complete his assignments as a programmer and his responsibilities as team lead未能完成他作为程序员的任务和作为团队负责人的职责
• created an atmosphere filled with fear from approaching him接近他营造了一种充满恐惧的气氛
• and a most serious incident — deleted large amounts of code that his team members had been working on for the past year and a half.最严重的事件-删除了他的团队成员过去一年半以来一直在处理的大量代码。

I will present one example in greater detail.

我将更详细地介绍一个示例。

During assignment planning, he received an assignment to organize the project’s GIT. Up until that time, the GIT was a great big mess that consisted of two different project versions. Since the team lead (let’s name him Steve for the sake of the example) was the most experienced senior developer, we all agreed it would be most effective if he got the assignment, since it would take him the least amount of time and efforts.

在任务计划期间，他收到了一个任务，用于组织项目的GIT。 直到那时，GIT还是一个巨大的混乱局面，由两个不同的项目版本组成。 由于团队负责人(为方便起见，将其命名为Steve)是经验最丰富的高级开发人员，因此我们都同意，如果他获得任务，那将是最有效的，因为这将花费他最少的时间和精力。

After a month, in which we’d held a few status meetings where he spoke of his progress, we found out that not only did the GIT stay exactly the way it was, but he also ordered his team members to develop upon the older version — thus creating unnecessary integration problems. Everywhere else a worker like that would’ve been immediately fired. Unfortunately, I could not fire him nor take any other disciplinary measure against him.

一个月后，我们举行了几次状态会议，他谈到了他的进度，我们发现GIT不仅保持了原样，而且还命令团队成员在旧版本上进行开发—从而造成不必要的集成问题。 到处都有这样的工人将被立即解雇。 不幸的是，我无法解雇他，也无法对他采取任何其他纪律措施。

This story with Steve reminded me of an employee I had as a regional manager for a non-profit organization a few years back. Let’s name her Suzy. As a regional manager, I was in charge of managing my branch managers on the one hand, and on the other hand developing our region’s community and business relations.

史蒂夫(Steve)的故事使我想起了几年前我曾担任非营利组织区域经理的一名员工。 我们命名她为Suzy。 作为地区经理，我一方面负责管理我的分支机构经理，另一方面负责发展我们地区的社区和业务关系。

Suzy was one of my employees. In time, we realized that being a branch manager lead her to have a strong thirst for power. She took on many responsibilities, treated her branch co-managers as her employees, disrespected her co-workers, and basically bossed everyone around.

Suzy是我的员工之一。 随着时间的流逝，我们意识到担任分行经理会导致她强烈渴望获得权力。 她承担了许多责任，把分公司的同事当作雇员对待，不尊重同事，并且基本上向周围的所有人负责。

No one had the guts to stand up to her for years, because it was a voluntary job, and we didn’t want her to use her rage against the organization. Every action had to be taken very delicately. I’d tried changing the atmosphere, adding bonding activities and a few other approaches. When we saw nothing changed her behavior, I decided to take more drastic measures.

多年来，没有人敢于与她站在一起，因为这是一项自愿的工作，而且我们不希望她利用她对组织的愤怒。 每个动作都必须非常细致地采取。 我曾尝试过改变气氛，增加联系活动和其他一些方法。 当我们看到她的行为没有任何改变时，我决定采取更严厉的措施。

I started actively managing their meetings and assigned more responsibilities to the other managers. I reduced the amount of power she supposedly had, by letting the other managers talk to the contacts she usually contacted. My response to the problem was decentralization, which ultimately led to a healthier work environment.

我开始积极管理他们的会议，并将更多的职责分配给其他经理。 通过让其他经理与她通常联系的联系人交谈，我减少了她原本应该拥有的权力。 我对这个问题的回答是权力下放，最终导致了更健康的工作环境。

Going back to Steve — the situation was much more extreme and involved one of the company’s crown jewel projects. It was clear to everyone that Steve, much like Suzy, had a thirst for power. He always requested more people for his team, and it didn’t matter to him what happened next — he just needed to be everyone’s boss. At management meetings, he had to cancel out every idea but his own, and he was always so stubborn he never really listened to his peers.

回到史蒂夫(Steve)-情况更加极端，涉及公司的皇冠珠宝项目之一。 每个人都清楚，与Suzy一样，Steve也渴望获得权力。 他总是要求团队中有更多的人，对他来说接下来发生什么无关紧要-他只需要成为每个人的老板即可。 在管理会议上，他不得不取消除他自己的想法之外的所有想法，而且他总是很固执，从来没有真正听过他的同事的意见。

Since I could not fire him, but could not keep him either, I started looking for a different position for him, far from my group. Simultaneously, I started decentralization. I gave him and his team fewer responsibilities and every new group member was forwarded to one of the other two teams.

由于我无法解雇他，但也无法挽留他，所以我开始为他寻找一个与我的团队相距甚远的职位。 同时，我开始下放权力。 我给他和他的团队更少的责任，每个新的小组成员都被转发给另外两个团队之一。

Throughout the process, I gave him performance feedback, hoping his behavior would change. His stubbornness and thirst for power prevented any change, and when he felt his power was slipping away he got angry — and so we reached a turning point.

在整个过程中，我给了他绩效反馈，希望他的行为能够改变。 他的固执和对权力的渴望阻止了任何变化，当他感到自己的权力正在减弱时，他就生气了-因此我们到达了一个转折点。

At this point, Steve and I finally had a shared interest. He wanted to seek power elsewhere, and I wanted him to seek power elsewhere. I knew he was one of the group’s many setbacks, but I also knew that dealing with any other setback before I got rid of him would be futile.

在这一点上，史蒂夫和我终于有了共同的兴趣。 他想在别处寻求权力，而我要他在别处寻求权力。 我知道他是该组织众多挫折之一，但我也知道在我摆脱他之前应对任何其他挫折都是徒劳的。

Peter Drucker once said: “Management is doing things right, leadership is doing the right things”. This thought is what kept me going in the direction I believed was right. I saw in my mind’s eye an effective software group, and I knew I had to work very hard and convince many people I was going in the right direction — in order to accomplish what I’d started. I chose to fight instead of to comfortably sit in my office and watch the group suffer defeats.

彼得·德鲁克(Peter Drucker)曾经说过：“管理在做正确的事，领导在做正确的事”。 这种想法使我朝着我认为正确的方向前进。 我在自己的眼中看到了一个有效的软件团队，并且我知道我必须非常努力地工作，并说服许多人朝着正确的方向前进，以便完成我的工作。 我选择打架，而不是坐在办公室里看着这个小组遭受失败。

To make a long story short, I got rid of Steve, he moved to another group, and I began mapping the faults and behavioral patterns I was looking forward to dealing with. As we are an R&D group, I started with the technology.

长话短说，我摆脱了史蒂夫(Steve)，他搬到了另一个小组，然后我开始绘制我期待处理的错误和行为模式。 因为我们是研发团队，所以我从技术入手。

克服技术鸿沟-可怕的情况还是创造性的冒险？ (Overcoming a technological gap — a horrible circumstance or a creative adventure?)

My next step was to figure out how to overcome technological gaps. When I say technological gaps, I don’t mean switching from Java to Node.js, oh no. We’re talking here about obsolete systems, ancient coding language (worse than hieroglyphs, trust me on that one), an impossible coding environment, no coding methodology, plenty of spaghetti code etc. The systems were implemented in such a way that there was no possible hardware upgrade without just writing everything from scratch.

我的下一步是弄清楚如何克服技术差距。 当我说技术差距时，我并不是说要从Java切换到Node.js，哦，不。 我们在这里谈论的是过时的系统，古老的编码语言(比象形文字更糟糕，请相信我)，不可能的编码环境，没有编码方法，大量的意大利面条式代码等。系统的实现方式是：没有从头开始编写所有内容，就不可能进行硬件升级。

I began solving each problem separately. I found several solutions to each problem and began prioritizing. For example, the coding environment issue. The system’s coding environment was so old, that even the company that designed it had already been shut down for many years. It was designed in a certain way that even the simple things were in fact very counter-intuitive.

我开始分别解决每个问题。 我为每个问题找到了几种解决方案，并开始进行优先排序。 例如，编码环境问题。 该系统的编码环境非常古老，以至于设计它的公司已经关闭了很多年。 它以某种方式设计，即使简单的事情实际上也非常违反直觉。

The compilation process, for one, had to be done very carefully. In order to compile one file, a programmer had to find all the files that were affected by it, all the files it might affect and files that are somehow related to it. They needed to find all these files manually, and run them through some other processes, and then when that was finally over with- they needed to wait for a few hours for the compilation to be complete. This was the least of all problems; therefore it was the first issue to attend to.

一方面，必须非常仔细地完成编译过程。 为了编译一个文件，程序员必须找到受该文件影响的所有文件，该文件可能会影响的所有文件以及与该文件有某种关系的文件。 他们需要手动查找所有这些文件，并通过其他一些过程来运行它们，然后当它们最终结束时，他们需要等待几个小时才能完成编译。 这是所有问题中最少的一个。 因此，这是第一个要解决的问题。

After massive research and thought, we found an elegant solution, that was immediately applicable. We found a way to automate the previously manual process through a third party application. However, an easy compilation was not the main goal here. My goal was to target all the faulty infrastructures, find and implement a simple solution, yet constantly remind the client we needed more budget to solve the more serious infrastructure issues.

经过大量的研究和思考，我们找到了一个很好的解决方案，该解决方案立即可用。 我们找到了一种通过第三方应用程序自动化以前的手动过程的方法。 但是，简单的编译并不是这里的主要目标。 我的目标是针对所有有问题的基础架构，找到并实施简单的解决方案，但不断提醒客户我们需要更多预算来解决更严重的基础架构问题。

This proved to be a path worth pursuing, since each problem we’ve solved uncovered more issues concerning the architecture and design of the system. This project was doomed the moment the papers were signed, but I hadn’t given up hope.

事实证明，这是一条值得追求的道路，因为我们解决的每个问题都揭示了与系统架构和设计有关的更多问题。 签署文件后，这个项目就注定了失败，但我没有放弃希望。

I started sniffing around, trying to find an interesting project related to our system. I found a project that could solve a very serious problem that we could add to the main system.

我开始四处寻找，试图找到一个与我们的系统有关的有趣项目。 我找到了一个可以解决非常严重的问题的项目，可以将其添加到主系统中。

This decision provided two things: first, the client understood there was more potential to the group than he had previously thought. And second, that we could add infrastructure upgrades as a part of the new project’s budget.

这个决定提供了两点：第一，客户知道该团队比他以前想象的潜力更大。 其次，我们可以在新项目预算中添加基础架构升级。

This had more value than just money — the developers began feeling the new spirit, they felt more needed, and they began working with extra willpower on infrastructure projects, since they knew it was meant to serve a project the client believed in. This led to an effective work environment, where people felt more productive and felt more inclined to share creative solutions.

这不仅具有金钱价值，还拥有更多的价值-开发人员开始感受到新的精神，感到更加需要，并且他们开始在基础设施项目上投入更多的意志力，因为他们知道这是为客户所信奉的项目提供服务。一个有效的工作环境，人们可以提高工作效率，更倾向于分享创造性的解决方案。

此时，您可能会问-我们的DevOps团队在哪里？ (At this point, you might ask — where is our DevOps team?)

Well, to tell you the truth — there was no designated DevOps team, nor was there a QA team, a product manager, a proper project manager and so on. We had to rely on ourselves and to be completely honest — but it was better that way.

好吧，说实话–没有指定的DevOps团队，也没有QA团队，产品经理，合适的项目经理等。 我们必须依靠自己，并且要完全诚实-但是那样更好。

In my opinion, distributing DevOps responsibilities among team members is more efficient and leads to better and faster results instead of depending on an outside team to come and rescue us from poor infrastructure. By sharing the responsibilities, I made sure that when integration and deployment time came, my group members would know how to deal with issues. By integration time, they would have come to a point in their research of the code and its behavior where things made sense. Another positive outcome was a shared interest in succeeding, leading to better teamwork and shared efforts.

我认为，在团队成员之间分配DevOps职责更加有效，并且会导致更好和更快的结果，而不是依赖外部团队来帮助我们摆脱不良基础架构的困扰。 通过分担责任，我确保在集成和部署时间到来时，我的小组成员将知道如何处理问题。 通过集成时间，他们将在对代码及其行为的研究中达到有意义的地步。 另一个积极成果是对成功的共同兴趣，从而导致更好的团队合作和共同的努力。

Each third party application we wrote made the people stronger. They felt committed to the project and wanted to do whatever it took to make sure the system was approachable — for them but also for the next generations.

我们编写的每个第三方应用程序都使人们变得更强大。 他们感到致力于该项目，并想尽一切努力确保该系统是可访问的-对他们来说，对下一代也是如此。

One of my developers began showing unusual expertise in DevOps related projects. I began quietly grooming him for the position of DevOps team expert. He was always excited to research the system’s code, to write manuals, to suggest improvements, to explore various solutions, to help others. He was a great DevOps mentor, our go-to guy.

我的一位开发人员开始展示与DevOps相关项目的非凡专业知识。 我开始悄悄地为他担任DevOps团队专家的职位。 他总是很高兴研究系统代码，编写手册，提出改进建议，探索各种解决方案以及为他人提供帮助。 他是我们出色的DevOps导师。

Suddenly there was hope. We began solving one infrastructure problem at a time. After building a few relatively small helpful applications, we could embark on an end-to-end solution to something big.

突然之间有了希望。 我们一次开始解决一个基础架构问题。 在构建了一些相对较小的有用应用程序之后，我们可以着手对大型应用程序进行端到端的解决方案。

One of our big infrastructure projects was to change the work environment from the old obsolete one to the beloved Visual Studio. This project had been postponed for many years because of low prioritizing. Since we drew infrastructure on our flag — this topic now became the top priority.

我们的大型基础设施项目之一是将工作环境从旧的过时的更改为最受欢迎的Visual Studio。 由于优先级较低，该项目已被推迟了很多年。 自从我们将基础架构吸引到了我们的旗帜-这个话题现在成为当务之急。

This project was the perfect study case. I wanted to prove that my group was both professionally capable and had fuel to see a massive project through. These things were very important to me since the group has never released a version and people outside the group claimed that the programmers were unprofessional.

这个项目是完美的研究案例。 我想证明我的团队既有能力，又有能力完成一个庞大的项目。 这些事情对我来说非常重要，因为该小组从未发布过版本，并且小组外的人声称程序员是不专业的。

My thesis was that when a manager creates an environment where every effort is put in order to reach one major goal — people would work hard to reach that one major goal. They will research, they will talk to experts and they will find a way.

我的论点是，当经理创造一种环境时，为了达到一个主要目标而竭尽全力，人们会努力工作以实现一个主要目标。 他们将进行研究，与专家交谈，他们将找到一种方法。

The first aspect I was trying to prove, through the new environment platform porting project, was that the group consisted of programmers who had a passion for their jobs. Since they began working on the project, it became very clear in a very short amount of time that they had large amounts of fuel and passion that were just waiting for the right time. They had tons of energy and they put their souls into the project.

我试图通过新的环境平台移植项目来证明的第一方面是，该小组由对工作充满热情的程序员组成。 自从他们开始从事该项目以来，很短的时间内就很清楚，他们有大量的精力和热情正等待正确的时间。 他们拥有无穷的精力，他们全力以赴。

My developers began researching, came with different solutions, coded day and night — until we decided on the proper architecture and design. This was not an easy project and we began working on it from point blank. Reviewing the code, throughout the process, made sure that programming skills were not a problem — this cleared out the second aspect of my thesis.

我的开发人员开始研究，并提供日夜编码的不同解决方案-直到我们决定合适的体系结构和设计。 这不是一个容易的项目，我们从空白开始进行研究。 在整个过程中，对代码进行复查可以确保编程技能不是问题-这使我的论文的第二个方面变得清晰。

This project’s success had opened the group to a whole new dimension. Their professional self-esteem has begun its restoration process, and they were now very eager to prove themselves worthy to other clients.

该项目的成功使团队进入了一个全新的维度。 他们的专业自尊心已经开始了恢复过程，现在他们非常渴望证明自己对其他客户有价值。

I felt improvement, but it wasn’t the group’s time yet. They needed to fill some of the other holes they had fallen into, now and again, over the years. They needed building and empowering. We needed proper marketing, and effective software group marketing comes with, believe it or not, good software products. We needed to work on development methodologies and coding standards, on proper product management and on project milestones before we could show anything to anyone.

我感觉有所进步，但还不是小组的时间。 他们需要填补这些年来不时出现的其他漏洞。 他们需要建设和授权。 我们需要适当的市场营销，并且不管您是否相信，优质的软件产品都会带来有效的软件团队营销。 在向任何人展示任何东西之前，我们需要研究开发方法和编码标准，适当的产品管理以及项目里程碑。

Overcoming the technology gap was a difficult step. It demanded many sacrifices from each group member, but it was necessary when it came to leaving the vicious zero-products cycle. It was necessary for improvement and for the upcoming products we were going to sell our future clients.

克服技术差距是困难的一步。 它要求每个小组成员做出许多牺牲，但是在离开恶性的零产品周期时，这是必要的。 这是改进的必要条件，对于即将推出的产品，我们将出售我们的未来客户。

What is a group’s identity? How do we define our group and how do we create an identity when there is none?

团体的身份是什么？ 在没有人的情况下，我们如何定义自己的小组？如何创建一个身份？

All this and more in my next blog post. Stay tuned :)

所有这些以及更多内容，请参见我的下一篇博客文章。 敬请关注 ：)

翻译自: https://www.freecodecamp.org/news/how-i-started-the-process-of-healing-a-dying-software-group-d5610cf416bc/

垂死病中惊坐起