The manager needs to be able to think, not program
Yesterday , an interesting article was published on Habré about whether a manager should be able to program. One of our managers went through fire, water, programming, testing, and design work, so she decided to write an answer. By tradition, we give such employees a free microphone. Spoiler of the article: the manager should think, not portray. In general, the word colleague.
So, in 2007, I came to work at a large telecommunications company and instantly felt serious problems in communicating with programmers and the ACS (automated control systems) division. The guys on our TK prepared us the data uploads, which we processed in Excel and Access, and then used for standard commercial needs such as mailings, developing niche tariff plans and hunting for unscrupulous sellers of our simulated connection packages. Programmers hated our technical assignments - the most innocuous remark was a call to yourself and throwing printed sheets with the words “enough to produce entities, write what you need, and not everything.” I was offended, because I wrote each TZ diligently in a university way: who is the customer, for what purposes, what fields, dates, terms, coordination, etc.
')
During the next lunch with the developers, it came to me the realization that all this is because I am not fit with my economics education and in order to learn how to communicate with programmers, you need ... to become one of them. So I went to one corporate university of Nizhny Novgorod (hello, NIIT!), Where for two years I had completely mastered: algorithms and data structures, C, C ++, Java (I wanted to shoot myself), Python (I loved her dearly), a little Assembler (and Java is nothing) and even UML diagrams and IT project management. We had a gigantic and deep UNIX course, during which I learned how to work with the console, compile in gcc, grep, write regular expressions, met vim, etc. That is, it became a direct reference sample from the article - a manager already overgrown with experience with administrative skills and knowledge of fairly deep programming fundamentals.
My technical assignments have changed - they have become almost ready-made scripts for samples and ... they have shattered the ACS-Schnick even more. What happened?
In general, I began to understand that being a manager was not noble and went to test engineers at a company that developed communication and switching systems. That is what? That's right - it turned out to be on the other side of the barricades, and now it was my turn to freak out at the sight of a project manager or, even worse, a marketer or sales person. “Blocking bug from the client”, “Critical from the client”, “Request for feature, transfer to development” - oh, these people generally understood how we work hard and that we don’t care for new features ?! How was it possible to assign a critic to a minor bug? Why do project managers so inappropriate use the words: backlog, sprint, commit, bug tracker, why they confuse Bagzilla and Mozilla Firefox, which means the expression “touch the feature so that I can hold a rally with my account”, because they don’t say so? In fact, the managers understood everything and even sympathized with our processing, but there was something behind them that neither I nor the author of the original article had mentioned.
Behind the manager are worth the money. And all the programming work, the work of the tester and the engineer is the money of the company for which it exists and of which we are paid a salary. And if the manager during working hours “throws up the architecture” and rummages through the dumps from Wireshark, in order to turn around to the programmer in all its glory, he loses this money.
As you already understood, from testing engineers I returned to managers, already reborn and conscious. Alas, I can’t talk about the intricacies of project management in RegionSoft Developer Studio , since it’s a private development and implementation that needs to be coordinated with clients, but after such a double transformation, I’m happy to share the rules by which you can become a truly successful manager.
You need to know the product at the code level (more precisely, the architecture), but not to code it. Knowledge of the product from and to - the first priority of any manager (project, product, sales, marketing). If you don’t understand how and why you can use it, don’t see the interconnection of modules and entities, you don’t realize what changes in this or that functionality will affect, you can never make a product successful in the market. A deep understanding of the functioning and working principles helps the manager to be demanding and experienced, but not an extravagant internal customer. Alas, PR and marketers with rare exceptions do not understand this, so all hope for us.
The principle is simple: do not offer new features just for the sake of being; do not write off from a competitor without looking; Do not go on about the insane customer changes. If you know the architecture of the product, you will never say to the programmer: “Well, what is difficult for you to screw a simple little thing, the customer says, it’s a matter of two hours.” Just because you understand perfectly where the changes will come out and how much work the developers and testers will need. I swear it is easier to dissuade the customer from the molds.
Do your job, programmers and engineers will do their own. To be able to analyze the code, traffic, use the debugger in the browser - excellent skills for analytical work. But at the time of communication with programmers, keep them with you. The fact is that the developers, in any case, will check the information and remove their dumps, collect and analyze the logs. And they will do it much more professionally than the manager, who figured out the information between the cases.
A manager with programming skills (or rather software design and development) is a gift of fate. The manager who spends time on mastering the command line and vim-a is an ineffective imitation.
Learn to write TK and translate from customer language to task language. This is a very important skill. Learn to take the side of the customer, analyze his requirements, assemble them and arrange them into an intelligible technical task, which can be agreed, signed and started to work. This is again the block of activity of the manager, where he must show his understanding of the development and knowledge of the product. The descriptions should correspond to the essence of the architecture, the requirements - not to go beyond the limits of realizable reality, the prices and terms - to correlate with the power of the development team, taking into account the entire workload. Otherwise, you will have to agree on the postponement of the deadline and work to the detriment of the company, and this is not the goal for which the project manager exists.
Learn to communicate with the customer. Most often, customers are far from the sphere of software development and design, it’s completely incomprehensible why you can’t add a “tiny window” or “a small feature that is inexpensive and not long” (well, for example, like this: attach the license plate reader to the system) brand recognition logic by rating plate and state number recognition). A manager is a buffer between customer desires and the capabilities of a programmer who can cut off unnecessary fantasies from requirements. A good manager will carefully study the customer’s business, consider all the requirements and be able to identify those that are really needed, substantiate the choice and convince the client that he himself thinks so.
Plan inside the team. In general, the team’s work plan with a horizon of a month or more is literally the main cheat sheet of the manager. No decision should be made without analyzing the workload of resources. And only at first glance it seems that the download is easy to predict. In the same implementations of CRM or any other software, several people are engaged in several projects at the same time, and such projects can be a year ahead. It is important not only to set priorities, but also to do this in view of the economic feasibility, criticality of the task, the size of the project. Oh yeah, and taking into account the schedule of vacations :-)
Learn to understand the risks, see and manage them. A good manager predicts, analyzes, and mitigates risk before it becomes a risk. The manager should have a whole risk management system - a table that lists potential threats, risk markers and ways to respond. And here the manager has another headache - a manager can take a risk, not particularly interested in the tablet. The team will be guilty in the end anyway, but it is definitely necessary to be ready for such a deal.
Manage your budget. The project has several budgets: the first is the cost of its implementation, the second is the cost of the customer to purchase, the third is the real cost of implementation. If you do not manage the budget, the third will turn into a monster that will devour all the commercial benefits. Therefore, the manager must know exactly the point of savings, the backlog of cost increases, which should be controlled, and understand how to manage all three aspects so that the customer is satisfied and the company is in the black. Deposits at a discount, penalties for half a day of delay and careless conditions of the contract - it's all about the budget, so do not forget that this is your task.
Be able to think critically. Each manager should have a set of project characteristics: price, time, resources, necessary tools, etc. If any question or problem arises, it is worth weighing the pros and cons, to understand the degree of influence on the whole task. For example, if you were offered to use the beta version of the newest framework in development, as a project manager you should not rush to read all manuals, but you should think about how raw the version is, what support it will have, how many bugs are in any beta, etc. Although in this example we are talking more about timblid, but it hurts the situation is widespread.
In order to form critical thinking, it is necessary to collect for oneself the tools and approaches that will allow analyzing the change of each factor in a logical and systematic way. Then the decisions will be weighted, not “WOW, let's go!”
Learn to coordinate a team on a situation, but not on agile. Your company can work on agile, implement scrum and gamification, stick to kanban, but it all falls apart from the very first inadequate, demanding, and even better, government customer, who buys a lot, is expensive, and begins to dictate his terms. In a competitive market, it is foolish to refuse money for the sake of methodologies. A good manager should be able to combine the favorite methodology of developers with the need to brainstorm, apply the waterfall model out of the blue, while ensuring the coordination of the team.
And here the manager should be able to clearly formulate, own the means of communication and collaboration, be ready to pick up the file from the server and understand the design scheme - for the purposes of lightning, clear and unambiguous communication (and not fruitless 5-hour meetings).
Learn to motivate. One can meet the thesis that a strong and intelligent team is perfectly self-motivated and self-organized. No, it is not. There is always someone who a) motivates on an ongoing basis and is interested in the progress of work; b) motivates following the results of work and communicates with the management (not always understanding and not always the programmer); c) motivates in a crisis situation, keeping the team and sustainability of the project.
A project manager is a motor that should set in motion the entire system, ensure the consistency of all elements and the highest possible efficiency. He should not be a one-sided Shiva or a two-faced Janus, he should not be an educator - he should be a competent person who knows who, when, in what time frame and for what money will solve part of the problem. If a manager wants to learn UNIX or learn programming, it is commendable and will help the work, help the realization of technical nuances. But this should not be done from the manager of a man-orchestra. Such a state of affairs will only dispel professionalism, since it is better to understand one thing, but it's cool than all the things with C grade. The arithmetic average will still be C grade. In general, dear managers, do not be the one with a bad head that does not give rest to your feet - think with your head and everything will twist as it should.
Our site with absolutely desktop business software and our flagship RegionSoft CRM.
Our Telegram channel is BizBreeze . Anything about CRM and business, according to the mind, without copy-paste and 90% without advertising. Subscribe, there is fun.
The opinion of the company RegionSoft Developer Studio may not coincide with the opinion of the employee. And maybe the same. The texts of the free microphone, we do not correct and do not agree.Hi, Habr! The article is partly correct, and she didn’t just hurt me and caught my eye, but literally trampled on the sick callosities of my managerial soul. In general, 10 years ago, when I came to work in the IT sphere, I thought in the same way as the author of the article. I'll tell you about the forks, rakes and paradise clouds of this approach.
Path: Manager - Testing Engineer - Manager
So, in 2007, I came to work at a large telecommunications company and instantly felt serious problems in communicating with programmers and the ACS (automated control systems) division. The guys on our TK prepared us the data uploads, which we processed in Excel and Access, and then used for standard commercial needs such as mailings, developing niche tariff plans and hunting for unscrupulous sellers of our simulated connection packages. Programmers hated our technical assignments - the most innocuous remark was a call to yourself and throwing printed sheets with the words “enough to produce entities, write what you need, and not everything.” I was offended, because I wrote each TZ diligently in a university way: who is the customer, for what purposes, what fields, dates, terms, coordination, etc.
')
During the next lunch with the developers, it came to me the realization that all this is because I am not fit with my economics education and in order to learn how to communicate with programmers, you need ... to become one of them. So I went to one corporate university of Nizhny Novgorod (hello, NIIT!), Where for two years I had completely mastered: algorithms and data structures, C, C ++, Java (I wanted to shoot myself), Python (I loved her dearly), a little Assembler (and Java is nothing) and even UML diagrams and IT project management. We had a gigantic and deep UNIX course, during which I learned how to work with the console, compile in gcc, grep, write regular expressions, met vim, etc. That is, it became a direct reference sample from the article - a manager already overgrown with experience with administrative skills and knowledge of fairly deep programming fundamentals.
My technical assignments have changed - they have become almost ready-made scripts for samples and ... they have shattered the ACS-Schnick even more. What happened?
- Appeared self-righteousness and chosenness with the fact that programmers were more experienced. A pimping manager who can edit files in vim and is a bit slashing in SQL has become a headache for seven people.
- Skills were broadcast on completely different systems. For example, my knowledge of Python did not fall into the lack of knowledge of SQL.
- I have grown significantly over my fellow managers, which is why confusion has arisen. But the relationship with the security service was excellent - now I knew that fraud was caught not by magic, but by scripts, removal, analysis and traffic control. We implemented interesting projects, and there universality was just right.
- The accuracy of calculating the time and cost of implementing the next project did not increase, since it is one thing to design everything, and the other to realize. I had to delve into testing and realize that UML diagrams do not solve anything. Some developers didn’t know about them, but they made the code at a breakneck pace and knew how to manage their time inside the project, while others knew everything, and they didn’t know enough — they simply didn’t have the skills. Theorists.
- The most important thing is that the understanding of the product code and the code behind the services did not provide an in-depth knowledge of the product that comes with direct interaction with the development as a user. Here the thing is: the manager is a bridge between the developer and the end user. And in order to improve something, you need to understand what the client and his staff are missing, and not why the module works in 0.15 ms, and not in 0.11 ms. I swear the user does not notice. But the fact that there is no cross, with which the program is closed, very much even notices (the real bug of one of the releases of the subscriber’s personal account).
In general, I began to understand that being a manager was not noble and went to test engineers at a company that developed communication and switching systems. That is what? That's right - it turned out to be on the other side of the barricades, and now it was my turn to freak out at the sight of a project manager or, even worse, a marketer or sales person. “Blocking bug from the client”, “Critical from the client”, “Request for feature, transfer to development” - oh, these people generally understood how we work hard and that we don’t care for new features ?! How was it possible to assign a critic to a minor bug? Why do project managers so inappropriate use the words: backlog, sprint, commit, bug tracker, why they confuse Bagzilla and Mozilla Firefox, which means the expression “touch the feature so that I can hold a rally with my account”, because they don’t say so? In fact, the managers understood everything and even sympathized with our processing, but there was something behind them that neither I nor the author of the original article had mentioned.
Behind the manager are worth the money. And all the programming work, the work of the tester and the engineer is the money of the company for which it exists and of which we are paid a salary. And if the manager during working hours “throws up the architecture” and rummages through the dumps from Wireshark, in order to turn around to the programmer in all its glory, he loses this money.
Jedi Manager Rules
As you already understood, from testing engineers I returned to managers, already reborn and conscious. Alas, I can’t talk about the intricacies of project management in RegionSoft Developer Studio , since it’s a private development and implementation that needs to be coordinated with clients, but after such a double transformation, I’m happy to share the rules by which you can become a truly successful manager.
You need to know the product at the code level (more precisely, the architecture), but not to code it. Knowledge of the product from and to - the first priority of any manager (project, product, sales, marketing). If you don’t understand how and why you can use it, don’t see the interconnection of modules and entities, you don’t realize what changes in this or that functionality will affect, you can never make a product successful in the market. A deep understanding of the functioning and working principles helps the manager to be demanding and experienced, but not an extravagant internal customer. Alas, PR and marketers with rare exceptions do not understand this, so all hope for us.
The principle is simple: do not offer new features just for the sake of being; do not write off from a competitor without looking; Do not go on about the insane customer changes. If you know the architecture of the product, you will never say to the programmer: “Well, what is difficult for you to screw a simple little thing, the customer says, it’s a matter of two hours.” Just because you understand perfectly where the changes will come out and how much work the developers and testers will need. I swear it is easier to dissuade the customer from the molds.
Do your job, programmers and engineers will do their own. To be able to analyze the code, traffic, use the debugger in the browser - excellent skills for analytical work. But at the time of communication with programmers, keep them with you. The fact is that the developers, in any case, will check the information and remove their dumps, collect and analyze the logs. And they will do it much more professionally than the manager, who figured out the information between the cases.
A manager with programming skills (or rather software design and development) is a gift of fate. The manager who spends time on mastering the command line and vim-a is an ineffective imitation.
Learn to write TK and translate from customer language to task language. This is a very important skill. Learn to take the side of the customer, analyze his requirements, assemble them and arrange them into an intelligible technical task, which can be agreed, signed and started to work. This is again the block of activity of the manager, where he must show his understanding of the development and knowledge of the product. The descriptions should correspond to the essence of the architecture, the requirements - not to go beyond the limits of realizable reality, the prices and terms - to correlate with the power of the development team, taking into account the entire workload. Otherwise, you will have to agree on the postponement of the deadline and work to the detriment of the company, and this is not the goal for which the project manager exists.
Learn to communicate with the customer. Most often, customers are far from the sphere of software development and design, it’s completely incomprehensible why you can’t add a “tiny window” or “a small feature that is inexpensive and not long” (well, for example, like this: attach the license plate reader to the system) brand recognition logic by rating plate and state number recognition). A manager is a buffer between customer desires and the capabilities of a programmer who can cut off unnecessary fantasies from requirements. A good manager will carefully study the customer’s business, consider all the requirements and be able to identify those that are really needed, substantiate the choice and convince the client that he himself thinks so.
Plan inside the team. In general, the team’s work plan with a horizon of a month or more is literally the main cheat sheet of the manager. No decision should be made without analyzing the workload of resources. And only at first glance it seems that the download is easy to predict. In the same implementations of CRM or any other software, several people are engaged in several projects at the same time, and such projects can be a year ahead. It is important not only to set priorities, but also to do this in view of the economic feasibility, criticality of the task, the size of the project. Oh yeah, and taking into account the schedule of vacations :-)
Learn to understand the risks, see and manage them. A good manager predicts, analyzes, and mitigates risk before it becomes a risk. The manager should have a whole risk management system - a table that lists potential threats, risk markers and ways to respond. And here the manager has another headache - a manager can take a risk, not particularly interested in the tablet. The team will be guilty in the end anyway, but it is definitely necessary to be ready for such a deal.
Manage your budget. The project has several budgets: the first is the cost of its implementation, the second is the cost of the customer to purchase, the third is the real cost of implementation. If you do not manage the budget, the third will turn into a monster that will devour all the commercial benefits. Therefore, the manager must know exactly the point of savings, the backlog of cost increases, which should be controlled, and understand how to manage all three aspects so that the customer is satisfied and the company is in the black. Deposits at a discount, penalties for half a day of delay and careless conditions of the contract - it's all about the budget, so do not forget that this is your task.
Be able to think critically. Each manager should have a set of project characteristics: price, time, resources, necessary tools, etc. If any question or problem arises, it is worth weighing the pros and cons, to understand the degree of influence on the whole task. For example, if you were offered to use the beta version of the newest framework in development, as a project manager you should not rush to read all manuals, but you should think about how raw the version is, what support it will have, how many bugs are in any beta, etc. Although in this example we are talking more about timblid, but it hurts the situation is widespread.
In order to form critical thinking, it is necessary to collect for oneself the tools and approaches that will allow analyzing the change of each factor in a logical and systematic way. Then the decisions will be weighted, not “WOW, let's go!”
Learn to coordinate a team on a situation, but not on agile. Your company can work on agile, implement scrum and gamification, stick to kanban, but it all falls apart from the very first inadequate, demanding, and even better, government customer, who buys a lot, is expensive, and begins to dictate his terms. In a competitive market, it is foolish to refuse money for the sake of methodologies. A good manager should be able to combine the favorite methodology of developers with the need to brainstorm, apply the waterfall model out of the blue, while ensuring the coordination of the team.
And here the manager should be able to clearly formulate, own the means of communication and collaboration, be ready to pick up the file from the server and understand the design scheme - for the purposes of lightning, clear and unambiguous communication (and not fruitless 5-hour meetings).
Learn to motivate. One can meet the thesis that a strong and intelligent team is perfectly self-motivated and self-organized. No, it is not. There is always someone who a) motivates on an ongoing basis and is interested in the progress of work; b) motivates following the results of work and communicates with the management (not always understanding and not always the programmer); c) motivates in a crisis situation, keeping the team and sustainability of the project.
A project manager is a motor that should set in motion the entire system, ensure the consistency of all elements and the highest possible efficiency. He should not be a one-sided Shiva or a two-faced Janus, he should not be an educator - he should be a competent person who knows who, when, in what time frame and for what money will solve part of the problem. If a manager wants to learn UNIX or learn programming, it is commendable and will help the work, help the realization of technical nuances. But this should not be done from the manager of a man-orchestra. Such a state of affairs will only dispel professionalism, since it is better to understand one thing, but it's cool than all the things with C grade. The arithmetic average will still be C grade. In general, dear managers, do not be the one with a bad head that does not give rest to your feet - think with your head and everything will twist as it should.
If you are an intelligent IT manager or want to become one
If you are an intelligent IT manager (implementations, system integration, development) or have worked in an enterprise and want to become one, we are looking for guys to get an office in Nizhny Novgorod for a full day - to work on complex and interesting CRM integration projects. We do not have hammocks, board games on Fridays, burger parties and lounges - we have powerful PCs, thoughtful software and a lot of interesting work. We promise the growth of professionalism, pumped experience, adequate leadership. Send your resume to contact@regionsoft.ru or call us to arrange an interview. Removed and candidates without any experience is not considered. HR-s on the interview will not be immediately hardcore.
Our site with absolutely desktop business software and our flagship RegionSoft CRM.
Our Telegram channel is BizBreeze . Anything about CRM and business, according to the mind, without copy-paste and 90% without advertising. Subscribe, there is fun.Source: https://habr.com/ru/post/352884/
All Articles