⬆️ ⬇️

No project managers needed.

Please note that there is no question mark in the title. I do not want to argue whether project managers are needed in modern software development or not. Practice shows no. I'm just trying to figure out why it happened.



Working for more than 20 years in the IT industry, I began to build each new development from a project office. Moreover, on several occasions I had to explain to the management why to hire peems. With the presence of department heads, it is not so easy to explain to people who are not directly involved in the development of software, what exactly project managers will do. We had to overcome noticeable resistance.



But for me it was an axiom that the project office and project managers are the basis of success. And tell me someone about five years ago that project managers are not needed, I would argue with him until the end.





Editor's note: this text is the result of a report by Dmitry Kruglov from Arrival at the Piamnaya meeting.



Or still need



Let's start with the fact that we try to protect this profession. At least, because the results at the last places of work have been achieved, in particular, thanks to the successfully built project offices.



Project management is not a prerogative of IT. This is a science that is over 50 years old. Science, which has its own holy book . Of course, PMBoK is not the only one of its kind, there is PRINCE and, for certain, some more books more or less claiming laurels. But PMBK is the basis of international standards and this indicates its high level of recognition. So we will build on it.



Let's play a game: if you work as a project manager, try, without looking ahead, to recall your main areas of activity from the point of view of an international standard and an institute that is over 50 years old?



For example, manage project requirements. Or manage expectations. Maybe you remember about time management. Surely colleagues representing a business regularly ask when exactly this or that task will be ready. Maybe you remember about the management of stakeholders, which is much less common. What else? Communication management. The latter is as rare as stakeholders. But this is an important and difficult task in our time, when all the project participants prefer to share important information in the Telegram, instead of the e-mails required by the project charter. How can you manage communications if you are not just called to a chat room where you discuss, for example, the quality of your work?



Compare what was remembered with the list from PMBoK:





All items are very sane. It seems that this activity really needs to be done by every project manager. Some of this may be less obvious, such as project integration. But if you have done with the forces of several teams a truly major feature that you need to put together before launching, then you understand what this point is about. By the way, the task of developing one functionality in several teams in parallel is still not systematically solved.



Gantt Chart



If there is activity, there must be its result. My personal opinion is that the work was done in the presence of the corresponding artifact. For a programmer, this is working code. For a testing specialist, test scripts developed or executed, errors generated in the system or automated tests created. For the designer - graphic layouts.



What is the artifact of a project manager? Of all the possible artifacts, including messages in Telegram: “Add me, finally, to your chat, I can’t manage the project without it!” - first of all I would mark the Gantt chart. This is a great tool that can answer many questions about the project and helps to visualize most areas of the project manager. After all, a good Gantt chart contains terms, resources, cost, dependencies. There you can add as requirements for communications requirements. You can even add management of stakeholders and their expectations using milestones and describing the expected result. It turns out a universal tool for all occasions.





Most of the tasks of these areas are solved through the management of one entity - the Gantt diagram.



Its popularity and versatility is confirmed by the number of tools and services that allow you to create your charts. Try typing “Gantt online” in your search and see how long you will get a list of links for every taste and color.



What turns out: we have a profession, there is an activity and there is a good artifact, as its result. So what's the catch?



It's all about the nuances. For example, with Ganttom is not so good.



First, diagrams of large projects sooner or later become unreadable. I had experience with a project of “more than a year” scale in Microsoft Project. To print his plan, it was necessary to glue together six sheets of A4. On one sheet the text was too small.



Secondly, the charts of large projects are very time consuming. Making changes can often be made only by the author himself, otherwise the plan falls apart due to a complex system of dependencies.



Thirdly, it must be admitted that many diagrams no one except the project manager himself reads. It turns out that this artifact was produced by PM and it alone needs and is understandable.



In modern software development, Gantt, for the most part, refused. We stopped using this artifact in creating a product, so do we need its author?



If you try to google the topic of the utility of project managers in IT, it becomes clear that this discussion has been going on for a long time. She managed to become another holivar, such as the confrontation between iOS and Android, Windows or OS X fans. Only the quotes in the search results are even more emotional: “Do we need PM?”, “Why did we decide to get rid of PM”, “Is Is PM's work worthless? "



I do not presume to say that the balance in the global dispute is leaning in favor of abandoning PM, but at least the number of supporters of this view is significant.



Flexible methodologies



Starting working in a company where I have a task to build a development team once again, I realized that for the next six months or a year I have no tasks for PM. At first I added it to the organizational structure out of habit. And then with his own hand and struck out. He struck out intuitively, but wondered: "Why did this happen?".



My study of the causes led to the understanding that IT possesses a number of unique qualities that allowed the implementation of flexible methodologies. There is a classic comparison: building a house and developing software. This is somewhat similar discipline, no wonder in both there is the role of the architect. Both there and there, there is a set of functional and non-functional requirements, there is infrastructure, internal communications, assembly, delivery and integration.



But construction is carried out in the real world and has a very long and expensive production cycle before the first test, before receiving the first feedback, before getting the result. The cost of mistakes in construction is very high.



In IT product is digital. And the production cycle can be very short. For two decades, we were able to create tools and technologies that led to the emergence of flexible development methodologies. Here I am ready to argue that the causal relationship is just this: the ability to quickly experiment and get a working result led to the emergence of methodologies for how to do it. Of course, this is a short positive feedback, and the tools continue to evolve. And then again the methodologies were refined. And so on, in a spiral, we rush towards a shorter and shorter time to market.



Roles



Flexible methodologies have become the de facto standard and brought new roles to the software development process. And these new roles began to take away activities and artifacts from project managers.





Product owner (PO)



There are projects that have several customers, several owners and several decision makers. PM for them is the person who achieves a compromise. He brings them all together, helps to prioritize, reconciles. Someone says: “No,” someone's interests are lobbying. But business understands that in continuous search for compromises resources are spent inefficiently. Most of all the most valuable resource is spent - time.



Therefore, in flexible methodologies, it is easy to do - they say something to one person from a business: “You are the last for money, for traffic and for conversion. And to be honest, we don’t care what and with what priority you are doing in the product. The main thing is that by the end of the year the conversion should increase from 1% to 1.1%, otherwise the project is unprofitable. ” And the PO gets the right to make decisions individually, determines the priority itself, creates the corresponding artifacts (plans, roadmap, requirements) and takes a piece of work from PM.



Techlide (TL)



Ten years ago, IT began to change the established architecture.



Before these changes, technologies and tools were mainly created for the “layered architecture” - a database layer, a business process layer, an aggregation layer, and a client layer. But as soon as this approach became classical, as soon as the companies acquired the corresponding divisions of the departments, flexible methodologies arrived. And everyone decided that “puff cakes” are bad and you need to form cross-functional teams.



Not to say that this was a new idea. What is the name of universal developers? Full stack. One of the developers over the age of 30 said at the interview: "I was a full stack developer at a time when the term full stack did not exist yet." Once we were all full stack, because you had to do everything, including database administration and director's computer settings.



Cross-functional teams have brought a new role: technid. Techlide not only pressed the heads of departments, but also took over the technical part of the work of PM. First of all, everything related to the assessment of complexity and timing. By the time of the transition to flexible methodologies, many were resigned to the fact that the development team should itself evaluate the terms of its work.



Systems Analyst (SA)



A system analyst is not a new role, and in many Agile methodologies it does not exist. I can’t say for sure, but maybe in an explicit form it is in SAFE. But SAFE, in general, is a borderline methodology. However, this role is extremely useful and interesting. She, like a lubricant in a complex mechanism, allows him to work quietly and smoothly. A system analyst is partly a product owner, partly an architect. It clarifies and details the business requirements to the level of specific features. The best systems analysts are able to promote their ideas and vision in both directions, using a combination of technical literacy and soft skills. Where system analysts work, the project manager is deprived of requirements management activities.



Scrum Master (SM)



Scrum Master strongly pressed the role of the project manager. It is a pity that now SM themselves have become candidates for extinction.



Seriously, sooner or later Scrum Master will teach in schools. There will be lessons about Agile, where Scrum Master will tell 12-year-old schoolchildren how flexible methodologies work and what practices exist. Already, experience in Agile has become a widespread phenomenon among developers. In interviews, 19 out of 20 people work on two-week iterations, and talking about processes turns into an enumeration of their parameters:



- What is the assessment?

- Story Points.

- What is Velocity?

- 68.

- How do you plan projects?

- In T-shirt estimates of S, M, L.



This is a very quick conversation. With the current techlids, all process parameters can be discussed in an hour. After that, they go to work with the team and they do not need a Scrum Master for this. The industry has almost digested this role and moves on.



Of course, not everywhere. Surely there are many companies that need to reach out to market standards and this is not a quick process. In Russia and in 10 years it will be possible to find a Scrum Master job in some Lenoblhozpromlespal when the organization decides to transfer its three programmers to Agile.



During its popularity, Scrum Master managed to completely take away from PM all the questions within the project team. They took it not for themselves, but for the team members, facilitating their involvement in project work. By the way, this noticeably raised the level of IT maturity in the eyes of the business.



Or still not needed



What remains? I took the liberty to single out those tasks that, when working on flexible methodologies, are solved by other roles.





What is left of the project managers after this? Remains communication, integration and procurement. It seems not so much to keep on the role of a dedicated person? It's time to say that PMs are not needed. But no.



Still need



There are categories of IT-projects in which failure without a dedicated manager is almost guaranteed.



Projects in the real world



Those who work with mobile development know that not everything is so smooth with the speed of making changes and the price of a mistake. If you missed an error in mobile development and noticed it not immediately, then it will be difficult to update to the entire audience. Some users will not update their applications and the error will remain. From this problem, for example, approaches with the remote control of the functionality of mobile applications have grown.



But this is a hundredth of the pain of PMs who manage the development of software, for example, to manage the sorting conveyor in a warehouse with a scale of 5 million units of goods. In such projects, dozens of dependencies on equipment suppliers, iterations are measured in months, and the cost of the error increases by an order of magnitude.



Equipment projects take us back from the digital worlds to our reality, in which the classical PMBoK management is still relevant.



Umbrella projects



On umbrella projects flexible methodologies stalled. Such projects are large and complex. Complexity means explicit and implicit dependencies, and on a certain scale, development without a dedicated project manager becomes extremely inefficient. In such projects, at PM, the main tasks are project integration, dependency management, and timing.



High cost projects



There will always be industries in which errors should be eliminated to the maximum - medicine, aviation, space industry, the military sphere. In these areas, when a mistake happens, people either die or huge amounts of money are lost. Examples are easy to find on the Internet. Start with a story about the European rocket "Arian-5".



In such areas PM will remain in demand, but they will be very high demands in terms of competence and experience. And the smaller the share of such projects, the harder will be the selection of candidates.



Projects without part of the roles



Life is a harsh thing, and it is not always possible to take a person to each of the roles for a particular person. While the world is not perfect, there will remain PMs who do the work of the Product Owner. Or PMs that are de facto working as techlides. Such combinations are often peculiar to startups.



If we extend in time the trends that are taking place in the industry now, we are waiting for the future, in which the PM role in its pure form will remain relevant for a small number of software projects whose work we do not yet know how to automate or distribute among others team members.






Text prepared by:

The author - Dmitry Kruglov

Editors - Evgeny Shklyar, Denis Vonsarovsky

The opinion of the author on some issues may not coincide with the opinion of the editors of the blog and the Yandex.Money company.



')

Source: https://habr.com/ru/post/446896/



All Articles