From engineer to manager. Part 2: Delegation and Task Formulation
In the last article From engineer to manager. Part 1: Sense of justice I talked about the feeling of justice. Returning to her, I want to repeat that the feeling of justice is a fundamental moment. And if I thought of something to tell, then each of my inaccuracies, and even more so a lie, an opinion, not supported by facts, a spelling error and agitation, would find their dissatisfied. What, in fact, can be observed here and in life every day. It’s one thing to stick to a specific side in a holivar (paradigm, standard, process), getting cuffs from some and support from others; and it is quite another thing to describe and follow your own point of view, experience and maintaining your own style. This is akin to a minefield where the rules of the game are known, but for everything that you do you bear responsibility for yourself. The same difference exists between the performer and the leader, where the latter, with his mistake, will receive a kick due to the manifested “injustice” and stuff many cones himself, if he makes mistakes, although saving him those who follow him. Therefore, in my understanding, it is better to fill the bumps ahead of time, from the level of an employee, feeling the way with soft parts of the body, not receiving additional kicks from behind - the main thing is not to lag behind and not go against the manager, however, if he is not completely wrong and does not lead everyone to a cliff. Otherwise, hold your horses, because you - the workhorse - in one team. How to set the right goal and how to perform work together with others and will be discussed in this article.
')
Once, a bad autumn day, I was called to another country to solve other people's problems with another's project. In addition to the language barrier, it was necessary to resolve the technological barrier. I had no idea what kind of project I got, how everything works in it and what to do. I was told only one thing - you were invited to pass a set of modules on time with proper quality and according to established standards. The task for me was completely ordinary and understandable, my experience and knowledge made it easy to do, and what was lacking could be tightened by reading the manuals and datasheets without losing much time — a couple of days, nothing more. But what exactly should be written in the code, how to understand and how to read the specification and what to build on the basis of its architecture, and how it relates to the framework I saw in the UML model, I had no idea.
Fortunately, to resolve this problem, I was introduced to Senior Developer, whose name was Maynul. Maynul was born, presumably from a Brahmin family, and was a very friendly and trained, enlightened man from India. I first met hand in hand with a Hindu in my work. Not somewhere remotely, where Bangalore code and tests riveted for a piece of cake, and from where came vague results with magic numbers 3, 9 and 24 from the next Ramanamam Shakati, but with an elite representative of their profession here and now live.
- Hello how are you?
- OK, I understand. How do I write? Is there any groundwork? Can I add something to the model?
To which he replied to me that, they say, it is necessary to write, like this ... And he brought me his code, where, for familiarization, he suggested that I implement a couple of dozen other functions. Well, to say that his code was Indian - to say nothing. Although there was some plaque from the current requirements, the constructions of the following type were terrifying:
Some things were not compiled at all. I wrote that it was missing, I corrected its small shoals, so that it would at least not violate the standards and compile. Then there were discrepancies in the specification between me and him, and he also proposed Hindu approaches. I saw the Hindu code in action! He did everything so that I would believe in the prejudices about the Indian coders, except that he did not dance under my nose. But questions arose and accumulated, but Indian solutions did not suit me. Therefore, one day I told him: “We have a problem, we need to solve it”. And then the following happened - Maynul began to bring specialists to me, as if they were taken by Shiva's hands: those who wrote and interpreted the specification, those who soldered microcontrollers, those who chased mathematical models. And they gave me the answers. He knew how to find people who knew how this should work. People from one team. I simply did not know the army of thousands from the entire state, and in general, it was difficult to approach anyone, and the explanations would take a lot of time. And then I understood. I gave him my problems and responsibilities - to find the device of the mechanism of people, and he covered his own - writing the correct code. Everything worked for us and we closed the project in 3 weeks with the integration of 4 dedicated ones.
Regarding the head there is a rule - delegate . But, in fact, even if you don’t get into a well-established team, where everyone has their own place, like in a watch, you can also delegate your responsibilities to those who do well with it. Even from the perspective of an ordinary employee. It works efficiently, but does not mean it's free. By giving assignments, you assume certain costs and responsibilities, sometimes even additional ones at the planning stage. Take the initiative and listen to people, regardless of the paradigm, views that you have.
On the part of the manager, trust your employees, they are usually better informed, they know better who to give the task, they know who will show more zeal. Delegate choices, delegate responsibility. Do not be afraid to work for employees, let them say what is important at the moment and how to fix it, let them give you advice not at meetings in the oval office, but in the work process at workplaces. Do not do someone else's work, but distribute it as it will be beneficial for everyone. If suddenly an employee lacks competence, ask his opinion how he would solve this problem, what he thinks he needs to solve problems. Listen more than speak. And only then offer your own, tough, unique solution. Once delegated, assess the importance of contribution to work, motivation, give the opportunity to turn around and show themselves. Look for people and methods, ways to motivate the execution of tasks, encourage self-reliance — even if it is a “theater” candy or a passing plush talisman of success — and help, do not leave the wards alone with the problem, if they need help, use your connections to attract the right resources. Advise a book, advise to go to air, but never climb under any circumstances into the code and the work of the employee, do not slow down with “good enough” criteria, let him be a measure of good code in the set timeframe.
In order to properly give advice, orientation and highlight the solution of both the manager and the task of the developer to formulate, it is necessary to set the tasks correctly. But how to set the task? First, there is the SMART methodology. Secondly, in order for the task to be understandable, the opponent must also understand it. This means that the one who sets the task must also check the correctness of understanding, in the simplest case - the repetition of the problem statement from the performer. For the task to be the easiest to understand and it could be reproduced without errors, it should be as simple as possible, i.e. if necessary, divided into elementary parts and steps, and visual, so that if the structure of the task is complex, it can be easily depicted on a piece of paper.
In my practice there was a case when I was given a very important and critical task for the whole project as follows: “We need a set of critical monitors. Try to figure it out. ” Okay, I had to clarify, however, that the list of monitors needed. For everything else, it was solely my design decision. Well, in a week or so I thought through the whole structure of classes, made quick methods and a warning system. I had a ready-made module that was connected to ready-made interfaces. However, the day before the change I had to redo everything. Since after the review code, the formidable boss, who by her authority was three times wider and taller than me, informed me that errors and monitors should be implemented in different classes (even if there is one field in the errors), and you should not use speed hacks, bit operations and error packing in bits of one word are not needed at all, but a bunch of visual switch \ if with separate int for each error should be used. And in general, it was reported to me that the concern had long ago solved the problem with monitoring, and my business to repeat (sic!) The finished code. The interface, however, is different, but remove unnecessary methods, and the interface is muffled with zeros where it is possible. I am not in principle against refactoring when it is appropriate, but when the task is converted from “yours design decision” to “use old damn code” from an incomparable project - this somehow embarrasses at the execution stage for the 1 day left. And the most interesting thing is that I was wrong about that. It was necessary to determine the rules of the game.
The best idea is to make a specification from the following considerations:
Good specification :
Those. we can understand the place of our specification in the architecture and we have a set of actions that can be covered with two tests for two actions (execute the script):
Why do not we describe how the read \ write test should pass and how should the CPU stop? First, let the developer decide how to do this. Secondly, think about testers - how to test it, and even at the request of one test? Or, worse, how to test the feature of turning off the CPU? Not always delve into the details - well. Even with low-level requirements, keep the level of abstraction that will allow test creation, and will not be limited to a review code marked as none-testable *. (* However, the principle of the black box for the same Unit tests is not always fulfilled, so it makes sense to refer to datasheets or describe non-functional layout requirements or the need to use assembler instructions, such as stopping an ISR during EEPROM recording, to be reinsured. If possible, clarification should be avoided as to which of the ten approximation functions should be used in this implementation (this should logically follow the specification).
Bad specification :
Reverse example. Which mistakes? Is overflow an error? Sensor exceeding threshold - error? Do we have a list of errors in the end? How to catch? When? There are messages coming every second - is it necessary to check each of them? And while waiting for receipt? Then detail save. It should describe the format - this is good, but you already make up the algorithm, turning the developer into a coder - do you need it - do double work? Also, how can a tester test a sequence of actions? Especially installation registers. Debugger? But what about the black-box? Yes, you're kidding!
Specification is not such a one-sided thing that architects should do. From the side of developers, this is a description of the functionality and behavior of the code for the same testers. On the part of testers, a scenario during the execution of which a failure occurred, or a violation of the standard, the reference to which will be clear to the developer, in the end it is a description of the test case and environment. On the part of the head - a clear statement of the technical problem and / or description of those. process. Strive to express thoughts correctly: structured, so that they can be divided into sub-steps, if necessary, and stylistically, to describe the script and your attitude. If it is crap, then you should write directly: “rework this pile of crap”, of course, with the condition if you are right and your position is well-grounded. Practice writing a good spec in a letter. Write texts, at least half a page per day. In the blog, in the community, in the table. Write and try to express your thoughts so that they are heard and perceived with the original message. Although the complexity of making a coil at home, at least about the soft mane of a pony. Check and read the tests to your cat, hang up a clean-up plan at the entrance or on the Internet - and he didn’t have enough time to suffer. Your task is to learn how to communicate thoughts as simply and correctly as possible. Time. Two. Three. In my case, the message is not a ready-made set of “best practices”, but a call to reflect with me and look at normal processes, examples from my own experience through the eyes of a developer who has fallen into new conditions.
Well, if the technical specification is close to the code, what about the problem statement?
Bad assignment :
A good example should contain a sequence of actions or even be described by a roadmap:
A good assignment should be:
S ) specific (what exactly we do)
M ) detailed, and therefore measurable (in this example, you can see at what stage is the task)
A ) understandable and sufficient (in this example we use the latest sources from SVN, the assembly in a specific environment)
R ) Each action is relevant if the previous stage has been successfully completed. It makes no sense to test the performance if the tests unexpectedly dropped. And even more so nothing to test, if not passed the assembly.
T ) time limited (to meet deadlines and synchronize the project).
Those. for my case, the Minul’s order was: “Today we need to know (T) how to handle the ARINC message buffer (S) for the application level A429 interface (A), when two messages with the same identifier (M1) arrive and in the case that the buffer is full ( M2). This may be due to timing errors, please find out the behavior of the piece of iron ®. "
All this, ultimately, structures and logs the dialogue between the contractor and the manager (or customer). If you do not understand the task, ask until you paraphrase it into atomic phrases. If you want to be understood, ask how understandable this task is. What solutions and proposals does the developer want to use and what place does he see the task in the architecture / project. Agree before you get down to business, plan. First of all, this will help to avoid dissatisfaction in the end, since both parties have adopted the rules of the game. It will relieve from endless alterations and insults that the code is already “good enough”. This will save questions because All the rules and answers are in the manuals, wikis, and everything that is described in the task or in the process. This, in the end, will lead to understandable reports that will be both the protection of the contractor and the argument of the manager.
The benefits of reports and why they are needed in general will be discussed next time.
Friendship is magic!
')
Once, a bad autumn day, I was called to another country to solve other people's problems with another's project. In addition to the language barrier, it was necessary to resolve the technological barrier. I had no idea what kind of project I got, how everything works in it and what to do. I was told only one thing - you were invited to pass a set of modules on time with proper quality and according to established standards. The task for me was completely ordinary and understandable, my experience and knowledge made it easy to do, and what was lacking could be tightened by reading the manuals and datasheets without losing much time — a couple of days, nothing more. But what exactly should be written in the code, how to understand and how to read the specification and what to build on the basis of its architecture, and how it relates to the framework I saw in the UML model, I had no idea.
Fortunately, to resolve this problem, I was introduced to Senior Developer, whose name was Maynul. Maynul was born, presumably from a Brahmin family, and was a very friendly and trained, enlightened man from India. I first met hand in hand with a Hindu in my work. Not somewhere remotely, where Bangalore code and tests riveted for a piece of cake, and from where came vague results with magic numbers 3, 9 and 24 from the next Ramanamam Shakati, but with an elite representative of their profession here and now live.
- Hello how are you?
- OK, I understand. How do I write? Is there any groundwork? Can I add something to the model?
To which he replied to me that, they say, it is necessary to write, like this ... And he brought me his code, where, for familiarization, he suggested that I implement a couple of dozen other functions. Well, to say that his code was Indian - to say nothing. Although there was some plaque from the current requirements, the constructions of the following type were terrifying:
sint16_t Temperature = nInTemp; bool_t Sign = TRUE; Sign = Temperature >> 15; if (Sign = TRUE) // do something // and do a little bit more else if (Sign == FALSE) { // do something } Some things were not compiled at all. I wrote that it was missing, I corrected its small shoals, so that it would at least not violate the standards and compile. Then there were discrepancies in the specification between me and him, and he also proposed Hindu approaches. I saw the Hindu code in action! He did everything so that I would believe in the prejudices about the Indian coders, except that he did not dance under my nose. But questions arose and accumulated, but Indian solutions did not suit me. Therefore, one day I told him: “We have a problem, we need to solve it”. And then the following happened - Maynul began to bring specialists to me, as if they were taken by Shiva's hands: those who wrote and interpreted the specification, those who soldered microcontrollers, those who chased mathematical models. And they gave me the answers. He knew how to find people who knew how this should work. People from one team. I simply did not know the army of thousands from the entire state, and in general, it was difficult to approach anyone, and the explanations would take a lot of time. And then I understood. I gave him my problems and responsibilities - to find the device of the mechanism of people, and he covered his own - writing the correct code. Everything worked for us and we closed the project in 3 weeks with the integration of 4 dedicated ones.
Regarding the head there is a rule - delegate . But, in fact, even if you don’t get into a well-established team, where everyone has their own place, like in a watch, you can also delegate your responsibilities to those who do well with it. Even from the perspective of an ordinary employee. It works efficiently, but does not mean it's free. By giving assignments, you assume certain costs and responsibilities, sometimes even additional ones at the planning stage. Take the initiative and listen to people, regardless of the paradigm, views that you have.
On the part of the manager, trust your employees, they are usually better informed, they know better who to give the task, they know who will show more zeal. Delegate choices, delegate responsibility. Do not be afraid to work for employees, let them say what is important at the moment and how to fix it, let them give you advice not at meetings in the oval office, but in the work process at workplaces. Do not do someone else's work, but distribute it as it will be beneficial for everyone. If suddenly an employee lacks competence, ask his opinion how he would solve this problem, what he thinks he needs to solve problems. Listen more than speak. And only then offer your own, tough, unique solution. Once delegated, assess the importance of contribution to work, motivation, give the opportunity to turn around and show themselves. Look for people and methods, ways to motivate the execution of tasks, encourage self-reliance — even if it is a “theater” candy or a passing plush talisman of success — and help, do not leave the wards alone with the problem, if they need help, use your connections to attract the right resources. Advise a book, advise to go to air, but never climb under any circumstances into the code and the work of the employee, do not slow down with “good enough” criteria, let him be a measure of good code in the set timeframe.
Goal setting
In order to properly give advice, orientation and highlight the solution of both the manager and the task of the developer to formulate, it is necessary to set the tasks correctly. But how to set the task? First, there is the SMART methodology. Secondly, in order for the task to be understandable, the opponent must also understand it. This means that the one who sets the task must also check the correctness of understanding, in the simplest case - the repetition of the problem statement from the performer. For the task to be the easiest to understand and it could be reproduced without errors, it should be as simple as possible, i.e. if necessary, divided into elementary parts and steps, and visual, so that if the structure of the task is complex, it can be easily depicted on a piece of paper.
In my practice there was a case when I was given a very important and critical task for the whole project as follows: “We need a set of critical monitors. Try to figure it out. ” Okay, I had to clarify, however, that the list of monitors needed. For everything else, it was solely my design decision. Well, in a week or so I thought through the whole structure of classes, made quick methods and a warning system. I had a ready-made module that was connected to ready-made interfaces. However, the day before the change I had to redo everything. Since after the review code, the formidable boss, who by her authority was three times wider and taller than me, informed me that errors and monitors should be implemented in different classes (even if there is one field in the errors), and you should not use speed hacks, bit operations and error packing in bits of one word are not needed at all, but a bunch of visual switch \ if with separate int for each error should be used. And in general, it was reported to me that the concern had long ago solved the problem with monitoring, and my business to repeat (sic!) The finished code. The interface, however, is different, but remove unnecessary methods, and the interface is muffled with zeros where it is possible. I am not in principle against refactoring when it is appropriate, but when the task is converted from “yours design decision” to “use old damn code” from an incomparable project - this somehow embarrasses at the execution stage for the 1 day left. And the most interesting thing is that I was wrong about that. It was necessary to determine the rules of the game.
Data sheet
The best idea is to make a specification from the following considerations:
- The specification must contain a deterministic set of actions and conditions.
- The specification requirement must be traced both up to the parent task and down to the subtasks (actions) if necessary
- Each action should be elementary and not allow different interpretations.
- The specification should contain a script or relationship scheme that is easy to describe on paper or pseudo-graphics.
- The specification should not be pseudocode or a sequence of actions and instructions, leaving design and tooling issues to the developer.
- Ideally, one action should be covered by one test (or testing, if we are not talking about program code)
- The consequence of the previous is the absence of non-functional non-functional requirements in the specification (description of the toolkit).
Good specification :
11. RAM Functionality [Requirement ID 111] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] The functionality of the RAM devices shall be tested by a write / read test of at least all used memory locations. [Requirement ID 112] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] In case of detecting a RAM fault, the unit shall be halted. Those. we can understand the place of our specification in the architecture and we have a set of actions that can be covered with two tests for two actions (execute the script):
- case without error
- error case
Why do not we describe how the read \ write test should pass and how should the CPU stop? First, let the developer decide how to do this. Secondly, think about testers - how to test it, and even at the request of one test? Or, worse, how to test the feature of turning off the CPU? Not always delve into the details - well. Even with low-level requirements, keep the level of abstraction that will allow test creation, and will not be limited to a review code marked as none-testable *. (* However, the principle of the black box for the same Unit tests is not always fulfilled, so it makes sense to refer to datasheets or describe non-functional layout requirements or the need to use assembler instructions, such as stopping an ISR during EEPROM recording, to be reinsured. If possible, clarification should be avoided as to which of the ten approximation functions should be used in this implementation (this should logically follow the specification).
Bad specification :
Fault machine [Requirement 31] [Actual Baseline 1 \ Iteration 8] [Parent requirement: 3, 5, 7, 8, 9, datasheet 23 page 5] System shall catch and store all errors in None-Volatile Memory. Errors shall be stored as follows: 1. Set IE to OFF; 2. Write Date; 3. Write Time; 4. Write Error ID; 5. Write '\0'; 6. Set IE to ON; Reverse example. Which mistakes? Is overflow an error? Sensor exceeding threshold - error? Do we have a list of errors in the end? How to catch? When? There are messages coming every second - is it necessary to check each of them? And while waiting for receipt? Then detail save. It should describe the format - this is good, but you already make up the algorithm, turning the developer into a coder - do you need it - do double work? Also, how can a tester test a sequence of actions? Especially installation registers. Debugger? But what about the black-box? Yes, you're kidding!
Specification is not such a one-sided thing that architects should do. From the side of developers, this is a description of the functionality and behavior of the code for the same testers. On the part of testers, a scenario during the execution of which a failure occurred, or a violation of the standard, the reference to which will be clear to the developer, in the end it is a description of the test case and environment. On the part of the head - a clear statement of the technical problem and / or description of those. process. Strive to express thoughts correctly: structured, so that they can be divided into sub-steps, if necessary, and stylistically, to describe the script and your attitude. If it is crap, then you should write directly: “rework this pile of crap”, of course, with the condition if you are right and your position is well-grounded. Practice writing a good spec in a letter. Write texts, at least half a page per day. In the blog, in the community, in the table. Write and try to express your thoughts so that they are heard and perceived with the original message. Although the complexity of making a coil at home, at least about the soft mane of a pony. Check and read the tests to your cat, hang up a clean-up plan at the entrance or on the Internet - and he didn’t have enough time to suffer. Your task is to learn how to communicate thoughts as simply and correctly as possible. Time. Two. Three. In my case, the message is not a ready-made set of “best practices”, but a call to reflect with me and look at normal processes, examples from my own experience through the eyes of a developer who has fallen into new conditions.
Setting goals
Well, if the technical specification is close to the code, what about the problem statement?
Bad assignment :
Create input monitoring functionality urgently. A good example should contain a sequence of actions or even be described by a roadmap:
Try to integrate last application release (from SVN) till Friday 13 in the following way: 1) Build new framework 2) Build new application with the new framework 3) Run tests 4) Run all benchmarks 5) Report to Jira If one of the steps breaks, try to re-check its default settings, and if all is correct, then report status. A good assignment should be:
S ) specific (what exactly we do)
M ) detailed, and therefore measurable (in this example, you can see at what stage is the task)
A ) understandable and sufficient (in this example we use the latest sources from SVN, the assembly in a specific environment)
R ) Each action is relevant if the previous stage has been successfully completed. It makes no sense to test the performance if the tests unexpectedly dropped. And even more so nothing to test, if not passed the assembly.
T ) time limited (to meet deadlines and synchronize the project).
Those. for my case, the Minul’s order was: “Today we need to know (T) how to handle the ARINC message buffer (S) for the application level A429 interface (A), when two messages with the same identifier (M1) arrive and in the case that the buffer is full ( M2). This may be due to timing errors, please find out the behavior of the piece of iron ®. "
All this, ultimately, structures and logs the dialogue between the contractor and the manager (or customer). If you do not understand the task, ask until you paraphrase it into atomic phrases. If you want to be understood, ask how understandable this task is. What solutions and proposals does the developer want to use and what place does he see the task in the architecture / project. Agree before you get down to business, plan. First of all, this will help to avoid dissatisfaction in the end, since both parties have adopted the rules of the game. It will relieve from endless alterations and insults that the code is already “good enough”. This will save questions because All the rules and answers are in the manuals, wikis, and everything that is described in the task or in the process. This, in the end, will lead to understandable reports that will be both the protection of the contractor and the argument of the manager.
The benefits of reports and why they are needed in general will be discussed next time.
Source: https://habr.com/ru/post/147011/
All Articles