您尝试打开的文件
by Victoriya Kalmanovich
由Victoriya Kalmanovich
您是否尝试过重新打开软件团队的身份？ (Have you tried turning your software team’s identity off and on again?)
This series portrays my experience as an R&D group leader of a group that has the same behavior as a failing startup. In my last two blog posts, I’ve presented a short background regarding the developers and the technologies. This blog post will deal with the vague definition of a group’s identity.
本系列描述了我作为一个团队的研发团队负责人的经历，该团队的行为与失败的创业公司相同。 在上两篇博客文章中，我简要介绍了有关开发人员和技术的背景。 这篇博客文章将讨论一个模糊的群体身份定义。
In my last blog post, I portrayed an image almost too good to be true. An image of a productive software group, full of energy and hunger for projects. I knew I must look away from newly gained success and only into the problems, however unfortunate that made me feel.
在我的上一篇博客文章中 ，我描绘的图像太好了，难以置信。 一个富有成效的软件团队的形象，充满活力和对项目的渴望。 我知道我必须将目光从新近获得的成功转移到其他问题上，尽管不幸使我感到难过。
On the one hand, I felt the need to present the milestones I’ve created to restore some kind of productivity. I wanted to show the boss all the recent successes — the coding methodology, working regulations and other concepts we’ve begun implementing. I wanted to present the training concepts and procedures we’ve established. I wanted to present the strong cooperation I’ve led with another organization. This cooperation granted an opportunity to combine the organization’s knowledge pool and create better professional training for my group. On top of these, one of our projects was accepted to an acceleration program. I really wanted to show that off as well.
一方面，我感到有必要介绍我为恢复某种生产力而创建的里程碑。 我想向老板展示最近取得的所有成功-编码方法，工作规定和我们已开始实施的其他概念。 我想介绍我们已经建立的培训概念和程序。 我想介绍一下我与另一个组织的强有力的合作。 这项合作为合并组织的知识库和为我的小组创造更好的专业培训提供了机会。 最重要的是，我们的一个项目被加速计划接受。 我真的也想证明这一点。
But I knew this image would soon fade unless I continued targeting the main issues. The primary issue was this next hard truth. The group didn’t have a strong basis and it was just a matter of time until it might collapse again. I identified it as the group’s lost identity.
但是我知道除非我继续针对主要问题，否则这种形象很快就会消失。 首要问题是下一个硬道理。 该小组没有坚实的基础，只是时间问题，直到它再次崩溃。 我将其标识为该组的身份丢失。
什么是团体身份？ (What is a group identity?)
When we reach a point in life where we seek our unique identity we look into various questions. Where am I from? What is my heritage? Who influences me? What’s exciting for me? What’s the reason I wake up in the morning? These questions helped me shape my personal identity both as a human being and as a leader. The same process happens one way or another in every organizational structure.
当我们到达生活中寻求独特身份的时候，我们会研究各种问题。 我从哪里来？ 我的遗产是什么？ 谁影响我？ 什么让我兴奋？ 我早上醒来的原因是什么？ 这些问题帮助我塑造了作为人和作为领导者的个人身份。 同一过程在每个组织结构中以一种或另一种方式发生。
Defining a group’s identity must happen the moment a manager takes the reins. They must look at the group’s responsibilities and define each group member’s position. It clears many things up. It provides clear borders regarding the manager’s and the developers’ responsibilities.
定义组的标识必须在经理接管时发生。 他们必须查看小组的职责并定义每个小组成员的职位。 它清除了很多东西。 它为管理人员和开发人员的职责提供了明确的界限。
This process must occur at the group manager’s level and even higher. It is rare that a complex organizational understanding such as an identity can depend on the team leads’ scope or lower. It is also unfair to the team leads, who already have enough on their plate.
此过程必须在组经理甚至更高的级别上进行。 诸如身份这样的复杂组织理解很少取决于团队负责人的范围或更低。 这对于已经有足够实力的团队负责人也是不公平的。
As you may recall from my previous blog post, I talked about the vicious zero-products cycle. This cycle started somewhere, so I started retracing the group’s steps. I realized that the moment the last official product version was released was the breaking point. This was the point where there was no clear view on what the group’s main objective was, what was its purpose and what was the product it was responsible for delivering.
您可能还记得我以前的博客文章，我谈到了恶性的零产品周期。 这个周期开始于某个地方，所以我开始追溯小组的步骤。 我意识到发布最后一个正式产品版本的那一刻才是转折点。 在这一点上，对于该小组的主要目标是什么，其目的是什么以及负责交付的产品的种类，没有明确的看法。
主要目标是什么？ (What was the main objective?)
The main objective was software and system maintenance for a very complex system. In order to perform software maintenance on such a large amount of code, a developer must work on the code. The developer must understand it and get to know its genius functions, but also its inherent faults and flaws. The developer must feel the code. They can only gain this feeling through massive research and deep understanding of procedures within the system.
主要目标是非常复杂的系统的软件和系统维护。 为了对如此大量的代码执行软件维护，开发人员必须处理这些代码。 开发人员必须了解它并了解其天才功能，还必须了解其固有的缺陷和缺陷。 开发人员必须感受代码。 他们只有通过大量研究和对系统内过程的深刻理解才能获得这种感觉。
In my view, it is impossible to maintain the entire system simultaneously, as a result of a small number of maintenance dedicated developers and a very serious lack of knowledge. So I declared that maintaining specific domains every year was good enough for us. The alternative would be scattered maintenance that would only lead to more gaps in the long run.
在我看来，由于少量的维护专用开发人员和非常严重的知识匮乏，不可能同时维护整个系统。 因此，我宣布每年维护特定域名对我们来说已经足够了。 替代方案是分散的维护，从长远来看只会导致更多的差距。
Let’s look at a simple example such as inserting an image on a screen. This is easy in modern systems written in readable code that follows proper coding methodologies.
让我们看一个简单的示例，例如在屏幕上插入图像。 在采用遵循适当编码方法的可读代码编写的现代系统中，这很容易。
In our case, to insert a feature, the developer needed to follow more complex steps. They would research the entire screen’s code and the entire code of screens that might be affected by the change. It might take up to a month of research. After the research would’ve developed some conclusions. They would try to decipher the relevant piece of the system’s architecture and find a few ways to implement image insertion.
在我们的案例中，要插入功能，开发人员需要遵循更复杂的步骤。 他们将研究整个屏幕的代码以及可能受更改影响的屏幕的整个代码。 研究可能需要长达一个月的时间。 经过研究，我们将得出一些结论。 他们将尝试破译系统体系结构的相关部分，并找到几种实现图像插入的方法。
In parallel, and this is the important part, the developer must document EVERYTHING. Every difficult method. Every process they discover. Every architecture or network insight they have. Every unusual phenomenon and its investigation all the way to its origin. This is crucial since the existing documentation and most of the written code are barely readable.
同时，这是重要的部分，开发人员必须记录所有内容。 每种困难的方法。 他们发现的每个过程。 他们拥有的每种架构或网络见解。 每一个异常现象及其调查一直到其起源。 这是至关重要的，因为现有文档和大多数书面代码几乎不可读。
The objective seems very straightforward, but regulated documentation and code maintenance is not the only thing that defines a group’s identity. The group has to have a purpose. Our purpose went missing.
目标似乎很简单，但是规范文档和代码维护并不是定义组标识的唯一方法。 该小组必须有一个目标。 我们的目的不见了。
目的去了哪里？ (Where did the purpose go?)
At some point, software maintenance was performed under no regulations and slowly went out of the professional focus. What started flowing instead were side projects. Side projects became the main objective. Whenever a client approached one of the teams, in need of a quick fix, the group would pivot in that direction. People were working on side projects for the sake of working. The difficult yet crucial maintenance was completely abandoned.
在某些时候，软件维护是在没有规定的情况下进行的，并且慢慢地超出了专业的关注范围。 相反，开始流行的是附带项目。 附带项目成为主要目标。 每当客户需要快速解决方案中的一个团队时，团队就会朝这个方向发展。 人们为了工作而从事辅助项目。 困难而又至关重要的维护工作已被完全放弃。
When I started my position as group leader, almost every group member told me they didn’t know exactly what the group was actually meant to do. They felt they had no real goals when they came to work. Side projects scattered the purpose.
当我开始担任小组组长的职务时，几乎每个小组成员都告诉我他们并不确切知道该小组的实际职责。 他们觉得上班时没有真正的目标。 辅助项目分散了目的。
为什么有时我们需要管理客户？ (Why do we sometimes need to manage our clients?)
A software group cannot blindly do what the client wants. Especially when the client changes their mind frequently. For example — back when I was a software developer, my team and I were working on a navigation project similar to “Waze”. Our product owner kept requesting changes that made no difference whatsoever to the system’s functionality. It was always a request to change button colors or move toolbars around the UI. This kept the team from making any progress for a very long time.
软件组不能盲目做客户想要的事情。 特别是当客户经常改变主意时。 例如，当我还是一名软件开发人员时，我和我的团队一直在从事类似于“ Waze”的导航项目。 我们的产品负责人不断要求进行更改，这些更改对系统的功能没有任何影响。 始终要求更改按钮颜色或在UI上移动工具栏。 这使团队长时间无法取得任何进展。
In my software group, the problem was on a larger scale. The group didn’t have one indecisive client. It had a few separate clients and each client pulled in their own direction. There wasn’t one integrating factor, looking at the larger picture and managing the clients and the projects. For a long time, the group worked through a queue — first client in meant first project the group developed. Therefore, almost any type of project could be brought to the group. In time the group began dealing with QA, IT and even hardware issues, rather than software development.
在我的软件小组中，问题更大。 该小组没有一个优柔寡断的客户。 它有几个单独的客户，每个客户都朝着自己的方向发展。 没有一个整合因素，要看大图并管理客户和项目。 长期以来，该小组一直在排队工作–第一个客户是该小组开发的第一个项目。 因此，几乎任何类型的项目都可以带到小组中。 随着时间的推移，该小组开始处理质量检查，IT甚至硬件问题，而不是软件开发。
Retrieving the purpose, and consequently the motivation, was an ongoing process. It began with a definition — I’ve defined, along with my team leads, our projects. We’ve prioritized them in accord with our clients’ demands, thus setting a roadmap we will not slip from, as happened in the past. This roadmap indicated our objective — system’s software maintenance was declared our purpose.
检索目的以及动机的过程是一个持续的过程。 它从定义开始-我已经与团队负责人一起定义了我们的项目。 我们已根据客户的需求对它们进行了优先排序，从而确定了我们不会像过去那样走过的路线图。 该路线图表明了我们的目标-宣布系统软件维护是我们的目标。
We’ve added one more project to the roadmap, a second main project, related to the system but not directly. It added to the purpose since it had great unimplemented potential. I believed it would be great for PR and to enhance the developers’ belief in their own skills. This dedicated roadmap focused the teams. We knew that by the end of the year we needed to deliver two products end-to-end.
我们在路线图中添加了另一个项目，第二个主要项目与系统相关，但不直接相关。 它具有很大的未实现潜力，因此增加了该目的。 我认为这对PR并增强开发人员对自己技能的信念将是一个很好的选择。 这份专门的路线图集中了团队。 我们知道，到今年年底，我们需要端到端交付两种产品。
Setting the professional compass was important. The bigger problem was regaining the developers’ trust in the group. After so many years, my developers — both experienced and new — had no fuel nor will to work. After some of my scheduled one on one talks, I mapped each developer’s strengths. If for example, one developer was really good at research — I let them do the research.
设置专业指南针很重要。 更大的问题是重新获得开发人员对该小组的信任。 这么多年后，我的开发人员(无论是经验丰富的还是新手)都没有燃料，也没有工作意愿。 在安排好一些一对一的讲座后，我绘制了每个开发人员的优势。 例如，如果有一位开发人员真的很擅长研究-我让他们进行研究。
After mapping individual strengths, I mapped team strengths. Some paired programming was performed in order to strengthen some developer’s self-esteem. We’ve held a professional workshop for team leads, to strengthen management abilities. I addressed the issues I picked up when I observed the programming process and the issues the developers themselves had presented.
在绘制个人优势之后，我绘制了团队优势。 为了增强开发人员的自尊心，执行了一些配对编程。 我们为团队领导举办了一次专业研讨会，以增强管理能力。 当我观察编程过程以及开发人员自己提出的问题时，我解决了我遇到的问题。
那么如何恢复身份？ (So how was the identity restored?)
By finding a definition and restoring order. We’ve defined our field of expertise. I’ve put borders around our designated projects and let no other project cross that border. Limited the issues we work on (no more hardware issues!). Made sure there was proper usage of coding methodologies and version control. Made everyone document their work. Strengthened each programmer’s strengths. Sharpened the team leads’ set of soft skills.
通过查找定义和恢复顺序。 我们已经定义了我们的专业领域。 我已经在我们指定的项目周围设置了边界，并且没有其他项目越过该边界。 限制了我们正在处理的问题(没有其他硬件问题！)。 确保正确使用编码方法和版本控制。 让每个人记录他们的工作。 增强了每个程序员的实力。 加强了团队负责人的软技能设置。
I targeted both professional and personal values in order to restore the group’s inevitable software DNA.
我以职业和个人价值观为目标，以恢复团队不可避免的软件DNA。
The difficulties of leading changes in an unforgiving environment, leading innovation instead of sinking and how to survive as a young female in a very ego driven male environment? Stay tuned, all this and more as the series unravels!
在无情的环境中领导变革的困难，领导创新而不是沉迷的困难以及如何在自我驱动的男性环境中作为年轻女性生存？ 请继续关注本系列，所有这些以及更多内容都将在此揭开序幕！
Part 1 — How Can Corporations Heal a Dying Software Group?
Part 2 — Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?
Parts 1+2 — How I started the process of healing a dying software group
您尝试打开的文件
1157
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
