From engineer to manager. Part 3: Reports
Reports are a great thing. They allow you to protect both the customer, the boss, and the employee with the entire project. They allow them to be managed and evaluated. You, in the end, do not write the code with the zeal of a trained monkey thousands of times rewriting the visitor pattern, but first you sit and think, draw on a piece of paper, plan the code and tests (I believe in you!)? But on the other hand, reports are a thing of control and organization that distracts everyone from immediate work. And still, in one way or another, at work, we have to face them. Why and how to find a compromise? Welcome under the cut to all who are interested in my opinion on this issue and those who read my previous articles:
From engineer to manager. Part 1: Sense of Justice
From engineer to manager. Part 2: Delegation and Task Formulation
')
I learned all the wisdom of balance and harmony in spite of the sakura and the passing corpses of my superiors, but in the harsh reality. And the reality was really harsh. In dark times they sent us a dark manager from faraway Africa. He had a gorgeous white smile, which at night in a dark alley could be confused with the smile of a disappearing Cheshire Cat, but there was very little idea what an airplane was, which, we, in general, did. Even more, a smiling manager, apparently, saw a plane once in his life, when he was happy to fly to manage our project. And computers, unfortunately, he, apparently, also not very long ago mastered, in contrast to the cruelly beaten time bike, on which he rode home from work, holding in one hand a package from a Chinese restaurant, and in another graphic and our plans project.
The project was urgent and difficult: it was necessary to lick and fix all the shoals before the upcoming certification. Because he was on-site, he had to deal with machines that he had never seen before and did not really understand what to expect from them. A lot of time was spent on training, and therefore it was important to track progress, to control the process a lot and clearly. The project involved three teams of 6-7 people each, which were accountable to him. In order to take into account who did what, the manager started an Excel spreadsheet, which every day each participant had to fill out: how many modules were verified, tested. Those. did noted in the tablet. But here was the problem number one: a lot of people, but one file. Therefore, the list of tasks accumulated by people in local files, and then transferred to the lines of the table indicating the accountable. During the time when the file was freed, they fought and fought. And if someone was unlucky to wait for the file to be released, he would remain outside of his working hours, in order to put on the tablet multi-colored statuses.
The manager held meetings every day. He told them how to fill in a table, which was eating up an hour a day. And at one of the rallies, he realized that people have problems. And they also need to be entered in the table: the found bug, problems in a person with running on the simulator, the lack of a module, etc., however, without problems with the table. So a second file appeared and a table into which it was necessary to add bugs, with the transfer of all verified statuses from the first one. However, as it turned out a week later, it’s not so effective, and you still have to count something, and the manager didn’t have time to count and recount hundreds of changes. Therefore, he came one morning and with a smile of a Cheshire cat, purring: “Hi guys, how are you, guys?”; He proposed to fill in the third one, in which the results would be the numbers of the manually counted results and their percentages, because the manager locked the tables for security. Moreover, it was supplemented that there was a feedback with the first one - to fill in the progress there, that if something did not have time, then indicate the status to the module “delayed”, and in the second to make corrections - problems with time.
Do I have to say that problems with time appeared long before these innovations? In fact, in each of the teams, one of its participants was only engaged in filling in these tables, shamelessly confusing and missing what was in the pile of text files. And since the table files broke due to the fact that there were errors in them, to save the statistics, they saved everything (each under a separate name) after a critical change, and they multiplied like leaps and bounds, and understand what the latest and most relevant was problematic.
The project was closed on time. The manager left of his own accord a week before the project was closed and drove off on his stork into the blue distance, leaving us with the harsh everyday life and black reflections. Which were as follows: reports are good, but they should take a minimum of time. Especially in the IT field. This should be done in one click, and the rest should be considered and done by programs, and reports and their compilation should not interfere with other people’s work. Ideally, it is a click on the checkbox / slider on the progress bar with a feedback in the bug tracking system, if necessary. It is not always possible, and you have to wriggle out with unimaginable crutches in the absence of centralized practice, but you must first simplify the costs of reporting and trust the technique, as well as an idea of ​​the subject area. To, at least, not distract specialists from work.
In addition to the confidence in computing technology, one must be guided by the technique of understanding people. Taught by the example of a manager, in one of the subsequent projects I prepared daily reports, in which, besides listing everything that was done during the day, was compared with what was planned automatically, it was enough to put only pass \ fail opposite the actual task. But, since the task was planned for me as a subordinate for a month, I was very pleased that doing the work faster and more efficiently, I reflect this in the report. “Today 5 modules are written, just 11 out of 40 planned are ready.” And at the beginning of the new week I wanted to report that I finished the work twice as fast. Beautiful graphics for managers "planned" and "done" optimistically diverged and rise up. Reports passed through the team lead, there is progress: you can see when and what has been done. Why, the weekly briefing by the project manager turned out to be a reason to call me and ask the question: “Why are you stretching deadlines? For a month? Why are we keeping you here? ” The justification that the work will be done tomorrow was of little interest to anyone, because such a “planned” schedule in their face also expressed my motivation, hence the ability to perform new tasks. I stopped and thought what was wrong here. First, managers plan and put risks and deadlines, often guided by the worst example. And when, instead of the worst example of an employee, he turns out to be a good professional planned by him, he is not always in a hurry to draw conclusions and give his positive marks for the manager. Even not so much because of the prerogatives and the separation of roles, but because he cannot always see the overall picture, in which a big positive jump can only be a patching of a hole in a large ship that returns the project to the originally planned direction.
When you learn from your mistakes, it is important not to lose the motivation and understanding that reports are not just a duty and routine, but a really sharp tool for working for a manager, a programmer, a tester, and a system administrator, and, of course, a manager. You just need to correctly and to get them to the place and apply. The quintessence of my reporting experience was the compilation of a roadmap for one of the projects.
The roadmap was a list of all the modules on which to work. It only needed to affix the status of the task. A couple of minutes a day. The system did everything else itself. I counted who and how much did what, when, what progress, what trends, what problems, what plan, what adjusted plan, efficiency and so on. The only thing that a team member had to do was click on his module and put pass \ fail, and then it was possible to generate a report for the manager with everything needed, so that the latter could only move the progress in MS Project and, if necessary, make the corrections will consider it necessary.
The project turned out to be not trivial, for the place of usual verification and finishing, it was necessary to study electrical circuits, count voltages, current strength, watch the consequences of breaking / closing circuits and transfer their logic and their effect on the code. Fortunately, at that time, as a hobby, I became interested in electrical engineering and soldered the boards in the evenings, so the circuits with various manipulations over ADC, potentiometers, voltage phases were not too vague for me. But this should have been explained to my fellow programmers, and, in particular, to one newcomer. Therefore, it was very important to assess how we cope with such a task, and how much real time we need and what costs against the set requirements and deadlines. And to my happiness, at the same time, my vacation came up. Without me, in my estimation, my colleagues would have done the task a week or more. Giving instructions to make updates every day and keep the boss up to date; I calmly swam for two weeks with fish and fed crocodiles, completely throwing all the problems out of my head. But on arrival I was waiting for the unexpected. The chief transferred his senior comrades to other fronts, seeing that everything was going well and better than expected, and left only a beginner on this project. The newcomer did everything, as I expected, even before my arrival and honestly filled in the accounts. But only before showing her superiors. Those. scoring the arithmetic average in the data for each day, but once, before showing the boss. Such data were absolutely useless, they only showed the result, but did not say at all how much and how (including the complexity of the modules) we do in a day / week. And it became a serious problem. How much time is needed for the next iteration? Is there a prospect of productivity growth? Does the complexity of the modules vary greatly? How much did we learn new methods and approaches? The full potential of the reports was lost, and only a rough estimate of the worst case could be offered, as in my previous example.
From this I also learned a lesson: if evaluation and research are needed, and not ordinary statistics, then we should not allow changes in past data, if the data should reflect daily relevance or more often, then they should be collected in such samples, i.e. be relevant. So this must be required, by the remainder, by force or control. Even protected from the risks of technology, the process of the system is not protected from human risks, and they must be foreseen and forced.
The best solution would probably be to turn to SMART again.
Having a specific goal ( Specific ), its measurability ( Measurable : the number of modules, tasks, functions, tests, etc.), as well as having flexibility in reachability ( Attainable : the presence of this module, the ability to handle it at all) set the parameters of its relevance ( Relevant : the need to report on this issue in a certain way), depending on the situation and time requirements ( Time-bound ). This is what in bug tracking systems is measured by priorities: Low, Normal, High, Urgent. And to determine how and in what order updates will be made.
This may not be applicable at first glance for startups, where, in fact, there is no one to report to. But both in them and in freelancing, as is well known, it motivates self-control and self-managment quite well. And it is more convenient to keep the actions not in the head, but in the same bug tracking system, perhaps in a cloudy environment, in order to track and find their decisions and their consequences as time passes. Set there and goals - working and personal, the goals of their development. Rejoice in success and growth, analyze failures and difficulties. Also, do not ask what the guide can do for you, but ask what you can do for the guide. Each week, as the last working day of the week ended, I compiled a summary report and out of habit, I highlighted with yellow the risks associated with the lack of knowledge in a new platform for me. A week. Month. Two. And suddenly, unexpectedly, the boss called me and snarled into the phone: “Hey, what can be done to increase efficiency? Manual is not enough to read? Should Tulsa be quicker? ” For me, this item in the report was not important. He wandered from the report to the report, reporting that I work for myself, I deal with manuals and forums, but still do not perform my tasks with my eyes closed, and even more so in the automatic mode of sleepy after stormy holidays. But for the authorities it turned out to be at least a petty but annoying pain in the ass. All effective and green report, all on time, everything seems to be good, but one phrase spoiled the idyll of the paradise Augean stables with whom I dealt. And the ice has broken. Simple and unobtrusive. I was offered solutions from above. Truth is spoken in the east, while drinking a glass of green tea: "The journey of a thousand li begins with one step." And this path for me imperceptibly passed only due to the presence of feedback.
Reporting can vary greatly depending on the style of the company, but my conclusion is the same: whatever the format is - daily Stand-up meetings, paper reports, project management systems, bug tracking systems, morning tea conversations, reports help a lot project status and company viability. They ultimately make it possible for even the smallest employees to feel that they are part of something global. What, however, should be recognized as a goal and as a structure for effective work and understanding by employees from young to old, why and for whom he reports, and how to use these reports.
In the process of writing this article, I asked my loved ones: “Why do we need reports?”. I was hoping for an approximate answer from the category of “a tool for monitoring and analysis,” or, at worst, “documentation”. But I received the answer: “Yes, they are not needed. No, of course it is clear that they are needed, but in practice there is no sense from them, except for the loss of time. ” The point was not even in misunderstanding, but in the fact that they usually do not know how to use them, except to show the boss. But the boss usually does not use them further than as an attachment to the product.
Then I should give specific examples of the use of reporting.
You probably know one of the laws of Murphy: “ The property of parity of errors. If the written program worked correctly, it means that during its work an even number of errors were executed or the programmer did not understand the task ”. This, unfortunately, happens more often than desired.
Some tasks require a significant investment of time, and do not always have to be completed. And therefore during the catching of bugs, one of the new revisions may well become working before the correction, and the bug no longer manifests itself. The developer reports that the bug is gone. However, the cause of the original bug will not be resolved and it will eventually manifest itself with new corrections. However, this does not mean that the developer has missed and missed something. He has a point of support and protection, a weighty argument. From his point of view, the task - to remove the influence of the bug - is completed, the code works according to the specification, tests pass. But for the project, this task may be rediscovered in order to clear out both the bugs and compensating factors so as not to have tails in the future.
In general, reports are usually needed by project managers and a task leader who will distribute tasks and plan the load depending on performance. It must somehow be counted. But also productivity - there is a measure of efficiency and development of the employee. Remember that each employee sends a weekly report in the form of a time sheet? Now let's see how much time it takes to complete the tasks over time.
What do we see here? Performing tasks took a fairly stable time per day, but with the accumulation of experience, the time spent on tasks began to decline (point A). After the introduction of automation tools (B), there was a debugging stage, but as a result, the time spent on the tasks was reduced (C). Here you can see the improvement and growth of the employee, his initiative, which resulted in the improvement of work. The example is quite lively, as long as the employee does not ascribe heroism to himself. But our bug tracking system or roadmap, fortunately, keeps track of really completed cases. Therefore, solely for an abstract example, you can improve such an analysis by simply multiplying the reciprocal of the number of completed tasks by the elapsed time for each day.
The schedule turned out to be ragged (I fumbled, I confess), but it still shows the trend and impact of automation integration. The analysis of empirical data from the results obtained is a separate topic, which is not the topic of this article. But with the involvement of the reporting mechanism, both the employee and the employer have a good performance measurement tool. By adding to it an estimate of the resources spent on training, other interesting conclusions can be drawn. In any case, for the analysis and evaluation of the mechanism for creating a log (report) - an excellent tool. It will only remain to motivate people and tell what opportunities the reporting activities represent.
In addition to explaining the benefits of reports and finding ways to implement a logging system, a great practice would be an introduction for each employee's personal time management. If they are not yet using GTD , please tell them how great it is nice to cross off tasks. They are made, we have a profit! Without getting into the wilds of this subject, with the sole purpose of, in addition to the dry squeeze of issues, supplement the analysis with personal matters. Let the staff be honest. Let them write in the daily reports: “I worked on tasks for 3 hours, and studied Python for 4 hours.” Not bad, but oh god, we lost an hour! In fact, you can go down to the study that 20 minutes were spent on tea drinking, 30 on surfing and 10 - on an argument with a colleague. But, in fact - this is personal information. Garbage time, which ... But stop! Our task is not to catch the employee in inaction, but to motivate him. The fact that he not only saw progress in the number of tasks performed, but also in the daily work on himself. And in relation to the leadership - honesty and openness, so that there is a dialogue, built on trust and delegation of authority with responsibility. So that in the end, at one moment he came to you with the words "I studied studying Python, and now I want to take my project."
PS The article is not fundamentally affected by financial reporting, audits and time reporting. None of these statements should be dealt with and performed by the developer. If the opposite is true, it is also a sign of a management problem. If, say, an enterprise mode requires strict time control, then this should be done without time management by the development engineer — the automatic access system or secretary Ellochka. If financial reporting requires signatures of development engineers, then this is also the concern of the corporate reporting department or the accountant of Elvira Mikhailovna, but there’s no reason to make a risk manager 2.5 of a cyborg technical specialist from a cyborg technician.
From engineer to manager. Part 1: Sense of Justice
From engineer to manager. Part 2: Delegation and Task Formulation
')
Overflow
I learned all the wisdom of balance and harmony in spite of the sakura and the passing corpses of my superiors, but in the harsh reality. And the reality was really harsh. In dark times they sent us a dark manager from faraway Africa. He had a gorgeous white smile, which at night in a dark alley could be confused with the smile of a disappearing Cheshire Cat, but there was very little idea what an airplane was, which, we, in general, did. Even more, a smiling manager, apparently, saw a plane once in his life, when he was happy to fly to manage our project. And computers, unfortunately, he, apparently, also not very long ago mastered, in contrast to the cruelly beaten time bike, on which he rode home from work, holding in one hand a package from a Chinese restaurant, and in another graphic and our plans project.
The project was urgent and difficult: it was necessary to lick and fix all the shoals before the upcoming certification. Because he was on-site, he had to deal with machines that he had never seen before and did not really understand what to expect from them. A lot of time was spent on training, and therefore it was important to track progress, to control the process a lot and clearly. The project involved three teams of 6-7 people each, which were accountable to him. In order to take into account who did what, the manager started an Excel spreadsheet, which every day each participant had to fill out: how many modules were verified, tested. Those. did noted in the tablet. But here was the problem number one: a lot of people, but one file. Therefore, the list of tasks accumulated by people in local files, and then transferred to the lines of the table indicating the accountable. During the time when the file was freed, they fought and fought. And if someone was unlucky to wait for the file to be released, he would remain outside of his working hours, in order to put on the tablet multi-colored statuses.
The manager held meetings every day. He told them how to fill in a table, which was eating up an hour a day. And at one of the rallies, he realized that people have problems. And they also need to be entered in the table: the found bug, problems in a person with running on the simulator, the lack of a module, etc., however, without problems with the table. So a second file appeared and a table into which it was necessary to add bugs, with the transfer of all verified statuses from the first one. However, as it turned out a week later, it’s not so effective, and you still have to count something, and the manager didn’t have time to count and recount hundreds of changes. Therefore, he came one morning and with a smile of a Cheshire cat, purring: “Hi guys, how are you, guys?”; He proposed to fill in the third one, in which the results would be the numbers of the manually counted results and their percentages, because the manager locked the tables for security. Moreover, it was supplemented that there was a feedback with the first one - to fill in the progress there, that if something did not have time, then indicate the status to the module “delayed”, and in the second to make corrections - problems with time.
Do I have to say that problems with time appeared long before these innovations? In fact, in each of the teams, one of its participants was only engaged in filling in these tables, shamelessly confusing and missing what was in the pile of text files. And since the table files broke due to the fact that there were errors in them, to save the statistics, they saved everything (each under a separate name) after a critical change, and they multiplied like leaps and bounds, and understand what the latest and most relevant was problematic.
The project was closed on time. The manager left of his own accord a week before the project was closed and drove off on his stork into the blue distance, leaving us with the harsh everyday life and black reflections. Which were as follows: reports are good, but they should take a minimum of time. Especially in the IT field. This should be done in one click, and the rest should be considered and done by programs, and reports and their compilation should not interfere with other people’s work. Ideally, it is a click on the checkbox / slider on the progress bar with a feedback in the bug tracking system, if necessary. It is not always possible, and you have to wriggle out with unimaginable crutches in the absence of centralized practice, but you must first simplify the costs of reporting and trust the technique, as well as an idea of ​​the subject area. To, at least, not distract specialists from work.
Underflow
In addition to the confidence in computing technology, one must be guided by the technique of understanding people. Taught by the example of a manager, in one of the subsequent projects I prepared daily reports, in which, besides listing everything that was done during the day, was compared with what was planned automatically, it was enough to put only pass \ fail opposite the actual task. But, since the task was planned for me as a subordinate for a month, I was very pleased that doing the work faster and more efficiently, I reflect this in the report. “Today 5 modules are written, just 11 out of 40 planned are ready.” And at the beginning of the new week I wanted to report that I finished the work twice as fast. Beautiful graphics for managers "planned" and "done" optimistically diverged and rise up. Reports passed through the team lead, there is progress: you can see when and what has been done. Why, the weekly briefing by the project manager turned out to be a reason to call me and ask the question: “Why are you stretching deadlines? For a month? Why are we keeping you here? ” The justification that the work will be done tomorrow was of little interest to anyone, because such a “planned” schedule in their face also expressed my motivation, hence the ability to perform new tasks. I stopped and thought what was wrong here. First, managers plan and put risks and deadlines, often guided by the worst example. And when, instead of the worst example of an employee, he turns out to be a good professional planned by him, he is not always in a hurry to draw conclusions and give his positive marks for the manager. Even not so much because of the prerogatives and the separation of roles, but because he cannot always see the overall picture, in which a big positive jump can only be a patching of a hole in a large ship that returns the project to the originally planned direction.
When you learn from your mistakes, it is important not to lose the motivation and understanding that reports are not just a duty and routine, but a really sharp tool for working for a manager, a programmer, a tester, and a system administrator, and, of course, a manager. You just need to correctly and to get them to the place and apply. The quintessence of my reporting experience was the compilation of a roadmap for one of the projects.
Division by zero
The roadmap was a list of all the modules on which to work. It only needed to affix the status of the task. A couple of minutes a day. The system did everything else itself. I counted who and how much did what, when, what progress, what trends, what problems, what plan, what adjusted plan, efficiency and so on. The only thing that a team member had to do was click on his module and put pass \ fail, and then it was possible to generate a report for the manager with everything needed, so that the latter could only move the progress in MS Project and, if necessary, make the corrections will consider it necessary.
The project turned out to be not trivial, for the place of usual verification and finishing, it was necessary to study electrical circuits, count voltages, current strength, watch the consequences of breaking / closing circuits and transfer their logic and their effect on the code. Fortunately, at that time, as a hobby, I became interested in electrical engineering and soldered the boards in the evenings, so the circuits with various manipulations over ADC, potentiometers, voltage phases were not too vague for me. But this should have been explained to my fellow programmers, and, in particular, to one newcomer. Therefore, it was very important to assess how we cope with such a task, and how much real time we need and what costs against the set requirements and deadlines. And to my happiness, at the same time, my vacation came up. Without me, in my estimation, my colleagues would have done the task a week or more. Giving instructions to make updates every day and keep the boss up to date; I calmly swam for two weeks with fish and fed crocodiles, completely throwing all the problems out of my head. But on arrival I was waiting for the unexpected. The chief transferred his senior comrades to other fronts, seeing that everything was going well and better than expected, and left only a beginner on this project. The newcomer did everything, as I expected, even before my arrival and honestly filled in the accounts. But only before showing her superiors. Those. scoring the arithmetic average in the data for each day, but once, before showing the boss. Such data were absolutely useless, they only showed the result, but did not say at all how much and how (including the complexity of the modules) we do in a day / week. And it became a serious problem. How much time is needed for the next iteration? Is there a prospect of productivity growth? Does the complexity of the modules vary greatly? How much did we learn new methods and approaches? The full potential of the reports was lost, and only a rough estimate of the worst case could be offered, as in my previous example.
From this I also learned a lesson: if evaluation and research are needed, and not ordinary statistics, then we should not allow changes in past data, if the data should reflect daily relevance or more often, then they should be collected in such samples, i.e. be relevant. So this must be required, by the remainder, by force or control. Even protected from the risks of technology, the process of the system is not protected from human risks, and they must be foreseen and forced.
What is the ideal reporting system?
The best solution would probably be to turn to SMART again.
Having a specific goal ( Specific ), its measurability ( Measurable : the number of modules, tasks, functions, tests, etc.), as well as having flexibility in reachability ( Attainable : the presence of this module, the ability to handle it at all) set the parameters of its relevance ( Relevant : the need to report on this issue in a certain way), depending on the situation and time requirements ( Time-bound ). This is what in bug tracking systems is measured by priorities: Low, Normal, High, Urgent. And to determine how and in what order updates will be made.
What is the hierarchy of reports?
Report daily, then generate a weekly and quarterly report. For each level, define your system.Task Level:
As a rule, a task is an atomic quantity in which there are no other subtasks and steps. If a task has a priority, then it determines the time for its implementation in a separate image (regardless of the project timeline), and requires certain behavior and reporting from it. For example, low-priority tasks can be stretched in time, and high-priority tasks are performed immediately within a couple of minutes or hours. However, if the task takes time above the reporting discrete, then the task report is compiled. It sounds strange, but in reality it is an unsubscribe in a bug-tracking system such as the banal one: “I’ve adopted, float still in progress”. If there is no system, then a comment in the table, or a text file \ letter, then what the task can financially rely on without a final commit. This is necessary first of all in order not to shut up on what is already considered spent and catch the problem before it begins to influence the entire project. Use Jira, Redmine, Bugzilla, Trac, GNATS, your mail script, just use, do not be discouraged orally (sometimes the management doesn’t care, and he will not always notice the importance of the problem if his thoughts are busy with something else, no matter how you try to convey) or by the late mention in the final reports of already forgotten and distorted numbers and names.Roadmap Level:
As a rule, this is a daily report of the species made by X from Y for today. New \ Old \ Total. Its purpose is to control the task, assess the complexity of the task. It is a squeeze of updated (Updated) tasks for today. Ideally, it is generated based on changes to checkbox \ issues in the system automatically. It is the analysis of these reports that allows us to speak about the most accountable person, employee, about his growth over the past time, about his abilities. This is important not only for the manager, but also for the employee, when, if desired, based on the analysis, his actual effectiveness and progress in development (based on a set of such reports) can be presented. In addition, it is the protection of the employee himself, since Formally, it is a protective paper from the boss, that he works, and does not bungle, but this is in the case of the terminal super-control of the leadership (which happens more often than we would like). And again, in your service, both bug tracking systems and project management systems like Project or even SAP are already monstrous, but in the simplest case Outlook functionality will also fit, especially with the interconnection with the office. Do not complicate the five-minute case with unnecessary and costly piles.Project level:
as a rule, it is a weekly report. What the employee (s) worked on, how much he did, how much was left. Its purpose is to assess the current state of the project, meeting deadlines, planning and risk management. It is a formalized report in the form established by a company, usually with an indication of risks, problems, solutions and plans. Get an automation tool for generating them or templates in a popular office application. Some bug-tracking systems already have similar functionality, so don't disdain it.Analytics level:
Quarterly reports on the work done. This is a list of all projects, time spent and effectiveness. His appointment is management and strategic planning. It is often a visual visualization of projects in the form of a Gantt chart, graphs for analysis and calculations on which these graphs are built. Contains recommendations and conclusions. The base for them can be pulled out from the project management system or the bug tracking system, but practice shows that there are always not enough tools for analysis. Yes, and some problems can not be entered into the workflow, so these reports are akin to the article and a little research.This may not be applicable at first glance for startups, where, in fact, there is no one to report to. But both in them and in freelancing, as is well known, it motivates self-control and self-managment quite well. And it is more convenient to keep the actions not in the head, but in the same bug tracking system, perhaps in a cloudy environment, in order to track and find their decisions and their consequences as time passes. Set there and goals - working and personal, the goals of their development. Rejoice in success and growth, analyze failures and difficulties. Also, do not ask what the guide can do for you, but ask what you can do for the guide. Each week, as the last working day of the week ended, I compiled a summary report and out of habit, I highlighted with yellow the risks associated with the lack of knowledge in a new platform for me. A week. Month. Two. And suddenly, unexpectedly, the boss called me and snarled into the phone: “Hey, what can be done to increase efficiency? Manual is not enough to read? Should Tulsa be quicker? ” For me, this item in the report was not important. He wandered from the report to the report, reporting that I work for myself, I deal with manuals and forums, but still do not perform my tasks with my eyes closed, and even more so in the automatic mode of sleepy after stormy holidays. But for the authorities it turned out to be at least a petty but annoying pain in the ass. All effective and green report, all on time, everything seems to be good, but one phrase spoiled the idyll of the paradise Augean stables with whom I dealt. And the ice has broken. Simple and unobtrusive. I was offered solutions from above. Truth is spoken in the east, while drinking a glass of green tea: "The journey of a thousand li begins with one step." And this path for me imperceptibly passed only due to the presence of feedback.
Reporting can vary greatly depending on the style of the company, but my conclusion is the same: whatever the format is - daily Stand-up meetings, paper reports, project management systems, bug tracking systems, morning tea conversations, reports help a lot project status and company viability. They ultimately make it possible for even the smallest employees to feel that they are part of something global. What, however, should be recognized as a goal and as a structure for effective work and understanding by employees from young to old, why and for whom he reports, and how to use these reports.
Analysis
In the process of writing this article, I asked my loved ones: “Why do we need reports?”. I was hoping for an approximate answer from the category of “a tool for monitoring and analysis,” or, at worst, “documentation”. But I received the answer: “Yes, they are not needed. No, of course it is clear that they are needed, but in practice there is no sense from them, except for the loss of time. ” The point was not even in misunderstanding, but in the fact that they usually do not know how to use them, except to show the boss. But the boss usually does not use them further than as an attachment to the product.
Then I should give specific examples of the use of reporting.
Situation 1. “Revived bug”
You probably know one of the laws of Murphy: “ The property of parity of errors. If the written program worked correctly, it means that during its work an even number of errors were executed or the programmer did not understand the task ”. This, unfortunately, happens more often than desired.
Some tasks require a significant investment of time, and do not always have to be completed. And therefore during the catching of bugs, one of the new revisions may well become working before the correction, and the bug no longer manifests itself. The developer reports that the bug is gone. However, the cause of the original bug will not be resolved and it will eventually manifest itself with new corrections. However, this does not mean that the developer has missed and missed something. He has a point of support and protection, a weighty argument. From his point of view, the task - to remove the influence of the bug - is completed, the code works according to the specification, tests pass. But for the project, this task may be rediscovered in order to clear out both the bugs and compensating factors so as not to have tails in the future.
Situation 2: “Performance”
In general, reports are usually needed by project managers and a task leader who will distribute tasks and plan the load depending on performance. It must somehow be counted. But also productivity - there is a measure of efficiency and development of the employee. Remember that each employee sends a weekly report in the form of a time sheet? Now let's see how much time it takes to complete the tasks over time.
What do we see here? Performing tasks took a fairly stable time per day, but with the accumulation of experience, the time spent on tasks began to decline (point A). After the introduction of automation tools (B), there was a debugging stage, but as a result, the time spent on the tasks was reduced (C). Here you can see the improvement and growth of the employee, his initiative, which resulted in the improvement of work. The example is quite lively, as long as the employee does not ascribe heroism to himself. But our bug tracking system or roadmap, fortunately, keeps track of really completed cases. Therefore, solely for an abstract example, you can improve such an analysis by simply multiplying the reciprocal of the number of completed tasks by the elapsed time for each day.
The schedule turned out to be ragged (I fumbled, I confess), but it still shows the trend and impact of automation integration. The analysis of empirical data from the results obtained is a separate topic, which is not the topic of this article. But with the involvement of the reporting mechanism, both the employee and the employer have a good performance measurement tool. By adding to it an estimate of the resources spent on training, other interesting conclusions can be drawn. In any case, for the analysis and evaluation of the mechanism for creating a log (report) - an excellent tool. It will only remain to motivate people and tell what opportunities the reporting activities represent.
findings
In addition to explaining the benefits of reports and finding ways to implement a logging system, a great practice would be an introduction for each employee's personal time management. If they are not yet using GTD , please tell them how great it is nice to cross off tasks. They are made, we have a profit! Without getting into the wilds of this subject, with the sole purpose of, in addition to the dry squeeze of issues, supplement the analysis with personal matters. Let the staff be honest. Let them write in the daily reports: “I worked on tasks for 3 hours, and studied Python for 4 hours.” Not bad, but oh god, we lost an hour! In fact, you can go down to the study that 20 minutes were spent on tea drinking, 30 on surfing and 10 - on an argument with a colleague. But, in fact - this is personal information. Garbage time, which ... But stop! Our task is not to catch the employee in inaction, but to motivate him. The fact that he not only saw progress in the number of tasks performed, but also in the daily work on himself. And in relation to the leadership - honesty and openness, so that there is a dialogue, built on trust and delegation of authority with responsibility. So that in the end, at one moment he came to you with the words "I studied studying Python, and now I want to take my project."
PS The article is not fundamentally affected by financial reporting, audits and time reporting. None of these statements should be dealt with and performed by the developer. If the opposite is true, it is also a sign of a management problem. If, say, an enterprise mode requires strict time control, then this should be done without time management by the development engineer — the automatic access system or secretary Ellochka. If financial reporting requires signatures of development engineers, then this is also the concern of the corporate reporting department or the accountant of Elvira Mikhailovna, but there’s no reason to make a risk manager 2.5 of a cyborg technical specialist from a cyborg technician.
Source: https://habr.com/ru/post/147064/
All Articles