July 9, 2012 at 11:01From engineer to leader. 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. In the end, you do not write the code with the zeal of a trained monkey rewriting the visitor pattern thousands of times, but at first you still sit and think, draw on 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 direct work. And still, in one way or another at work, we have to deal with them. Why and how to compromise? Welcome to everyone who is interested in my opinion on this issue and those who have read my previous articles:
From an engineer to a manager. Part 1: A Sense of Justice
From engineer to leader. Part 2: Delegation and Problem Setting
I learned all the wisdom of balance and harmony, not looking at the sakura and the passing corpses of my superiors, but in harsh reality. And the reality was really harsh. In the dark, they sent us a dark manager from distant Africa. He had a magnificent white smile, which at night in a dark alley could be confused with the smile of the disappearing Cheshire Cat, but there was very little idea of what an airplane was, which, in general, we did. Even more so, the smiling manager, apparently, saw the plane once in his life, when the happy one flew to lead our project. And, unfortunately, he, apparently, also mastered computers not very long ago, unlike the bicycle, which he cruelly beaten with time, who rode home from work, holding in one hand a package from a Chinese restaurant, and in the other the schedules and plans of our project.
The project was urgent and difficult: it was necessary to lick and fix all the jambs before the upcoming certification. Because he was on-site, he had to deal with machines that had not previously been seen in the eye and did not really understand what to expect from them. It took a lot of time to learn, and therefore it was important to monitor progress, to monitor the process a lot and clearly. The project involved three teams of 6-7 people each, who were accountable to him. To take into account who did what, the manager opened an Excel table that each participant had to fill out every day: how many modules were reviewed, tested. Those. made noted on the plate. But there was problem number one: there were a lot of people, and there was only one file. Therefore, the list of tasks was accumulated by people in local files, and then transferred to the rows of the table indicating the accountable. During, when the file was released they fought and fought. And if anyone was unlucky to wait for the file to be released, it remained outside working hours to put multi-colored statuses on the tablet.
The manager held rallies every day. He told them how to fill out a table, which consumed time by the hour. 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 with a person running on the simulator, the lack of a module, etc., however, without problems with the table. So the second file and a table appeared in which it was necessary to enter bugs, with the transfer of all checked statuses from the first. However, as it turned out a week later, this is not so effective, and we still need to count something, and the manager did not 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 suggested filling out a third, in which the results would be numbers, manually calculated results and their percentages, because the manager has locked the tables for security. Moreover, it was supplemented so that there was feedback with the first one - to fill in the progress there, that if something did not succeed, then indicate the status on the module “delayed”, and in the second make corrections - problems with time.
Needless to say, problems over time appeared long before these innovations? In fact, in each of the teams one of its participants was only engaged in filling out these tables, shamelessly confusing and skipping what was in the heap of text files. And since the table files were broken due to the fact that they turned out to be errors, to save statistics they were saved by everyone (each under a separate name), after a critical change, and they multiplied by leaps and bounds, and understand what is the latest and relevant - was problematic.
The project was closed on time. The manager left of his own free will a week before the closure of the project and drove off in his blue sky far away, leaving us with harsh everyday life and black thoughts. 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 preparation should not interfere with other people working. Ideally, this is a click on the checkbox \ slider on the progress bar with a feedback in the bug tracking system, if necessary. This is not always possible, and you have to get out with unimaginable crutches in the absence of a centralized practice, but you need to simplify the reporting costs and trust the technique, as well as have an idea of the subject area in the first place. In order to at least not distract specialists from work.
In addition to trust in computing technology, one must be guided by the technique of understanding people. Taught by the example of the manager, in one of the following projects I prepared daily reports, in which, in addition to listing everything that was done during the day, was compared with the planned one automatically, it was enough to put only pass \ fail in front of the actual task. But, because the assignment 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, 11 of the 40 planned are ready.” And at the beginning of the new week I wanted to report that I had finished work twice as fast. Beautiful schedules for managers “planned” and “done” optimistically diverged and will go up. The reports passed through team lead, there is progress: it is clear when and what has been done. But the weekly briefing by the project manager turned out to be a reason to call me and ask the question: “Why are you stretching the time? For a month? Why are we holding you here? ” Justification that the work will be done tomorrow was of little interest to anyone, because such a “planned” schedule in their person also expressed my motivation, therefore the ability to perform new tasks. I stopped and thought what was wrong. First, managers, when planning, lay down risks and deadlines, often guided by the worst example. And when, instead of the worst example of an employee, they turn out to be a good professional, they don’t always have to hurry to draw conclusions and give their positive ratings for the manager. Not even so much because of the prerogatives and separation of roles, but because the general picture may not always be visible to him,
When you learn from your mistakes, it is important not to lose motivation and understanding that reports are not just a duty and a routine, but really a sharp tool for the work of the leader, programmer, tester, system administrator, and, of course, manager. You just need to get it and apply it to the place. The quintessence of my reporting experience was compiling a roadmap for one of the projects.
The roadmap was a list of all the modules that were to be worked on. It was only necessary to put down the status of the task. A couple of minutes a day. The system did everything else. I calculated who and how much did what, when, what progress, what trends, what problems, what plan, what kind of adjusted plan, effectiveness, etc. The only thing a team member had to do was click on his module and set pass \ fail, and then it would be possible to generate a report for the leader with everything necessary so that the latter could only move the progress to MS Project and, if necessary, make those corrections that he deems necessary.
The project was not trivial, for the place of usual verification and completion, I had to study electrical circuits, count voltages, current strength, look at the consequences of breaking / closing circuits and transfer their logic and their influence on the code. Fortunately, at that time, as a hobby, I became interested in electrical engineering and soldered boards in the evenings, so circuits with various manipulations on the ADC, potentiometers, voltage phases were not too vague for me. But this should be explained to my fellow programmers, and, in particular, to one newcomer. Therefore, it was very important to evaluate how we cope with this task, and how much we need real time and what costs are against the set requirements and deadlines. And to my happiness, at the same time my vacation came up. Without me, according to my estimates, my colleagues would have completed the task in a week or a little more. Giving instruction to make updates every day and keep the boss in the know; I swam calmly for two weeks with fish and fed the crocodiles, completely throwing all the problems out of my head. But upon arrival, the unexpected was waiting for me. The boss transferred his senior comrades to other fronts, seeing that everything was going well and better than expected, and left only a novice on this project. The newcomer did everything, as I expected, even before my arrival and honestly filled out the reports. But only before showing it to the authorities. Those. scoring the arithmetic mean in the data for each day, but once, before showing it to the boss. Such data was 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 that has become a serious problem. How long does it take for the next iteration? Is there any prospect of productivity growth? Does the complexity of the modules vary greatly? How did we learn new methods and approaches? All the potential from 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 you need an assessment and research, and not ordinary statistics, then you can’t allow changes in past data, if the data should reflect daily relevance or more often, it means they should be collected in such discretes, i.e. to be relevant. So this must be demanded, reminders, forced way or control. Even protected from risks by technology, the process system is not protected from human risks, and they must be foreseen and forced.
Perhaps the best solution would 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 flexibility in reachability ( Attainable : the presence of this module, the ability to process 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 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. But both in them and in freelance, as you know, it motivates good self-control and self-managment. And it’s more convenient to save actions not in the head, but in the same bug tracking system, perhaps in a cloudy environment, so that over time, you can track and find your decisions and their consequences. Set there goals - workers and personal goals of their development. Rejoice in success and growth, analyze failures and difficulties. Also, do not ask what management can do for you, but ask what you can do for management. Every week, as the last working day of the week ended, I compiled a consolidated report and out of habit, highlighted in yellow the risks associated with insufficient savvy in my new platform. A week. Month. Two. And unexpectedly, the boss called me and growled into the phone: “Hey, what can be done to increase efficiency? Manual reading is not enough? Should Tulsa be faster? ” For me, this item was not important in the report. He wandered from report to report, reporting that I work for myself, understand the manuals and forums, but still do not complete my tasks with my eyes closed, and even more so in the automatic sleep mode after stormy holidays. But for the authorities it turned out to be at least a small, but intrusive pain in the ass. The entire effective and green report, everything on time, everything seems to be fine, but one phrase spoiled the idyllic paradise of the Augean stables I dealt with. And the ice began to break. Simple and unobtrusive. I was offered solutions from above. The truth is spoken in the east, drinking glasses of green tea: "The journey of a thousand begins with one step."
Reporting can vary greatly depending on the style of the company, but my conclusion is the same: whatever format - daily Stand-up meetings, reports in papers, in project management systems, bug tracking systems, conversations over morning tea drinking, reports greatly help to regulate project status and company viability. They ultimately allow even the smallest employees to feel part of something global. That, however, should be realized as a goal and as a structure for effective work and understanding by employees, from a small to a great leader, 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 “instrument of control and analysis” or, at worst, “documentation”. But I got the answer: “Yes, they are not needed. No, of course it’s clear that they are needed, but in practice they are of no use except for wasting time. ” It was not even a misunderstanding, but the fact that they usually do not know how to use them, unless in order to show the boss. But the boss usually does not use them further than as an appendix to the product.
Then I should give specific examples of the use of reporting.
You probably know one of Murphy's laws: “ The property of the parity of errors. If the written program worked correctly, it means that during its operation an even number of errors were completed or the programmer did not understand the task . ” Unfortunately, this happens more often than we would like.
Some tasks require significant investment of time, and do not always have to be completed. And therefore, while catching bugs, one of the new revisions may very well become working before the fix, and the bug no longer appears. The developer will report that there is no more bug. However, the cause of the initial bug will not be resolved and after a while it will prove itself with new corrections. However, this does not mean that the developer messed up 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, the tests pass. But for the project, this task can be rediscovered in order to clean out both 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 schedule downloads depending on performance. She needs to be counted somehow. But also productivity is a measure of employee efficiency and development. Remember that each employee sends a weekly report in the form of a time sheet? Now let's see how much time he takes on tasks over time.
What do we see here? Completing 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 in the end, the time spent on tasks was reduced (C). Here you can see the improvement and growth of the employee, his initiative, which entailed the improvement of work. The example is lively enough until the employee ascribes heroism to himself. But our bug tracking system or roadmap, fortunately, keeps track of really completed things. Therefore, solely for the abstract example, such an analysis can be improved by simply multiplying the reciprocal of the number of completed tasks by the time taken for each day.
The graph turned out to be torn (I faked it, I repent), but it still shows the trend and influence of automation integration. The analysis of empirical data from the results obtained is a separate topic that is not the subject of this article. But with the involvement of the reporting mechanism, both the employee and the employer have a good tool for assessing effectiveness. Adding to it an estimate of the resources spent on training, one can draw other interesting conclusions. In any case, for analysis and evaluation, the availability of a log (report) creation mechanism is a great help. It remains only to motivate people and tell you what opportunities are presented by activities related to reporting.
In addition to explaining the benefits of reports and finding ways to implement a logging system, it’s great practice to introduce a personal time management for each employee. If they don’t use GTD yetplease tell them how cool and nice it is to cross out tasks. They are done, it turns out, profit! Without getting into the jungle of this topic, only with the goal of supplementing the analysis with personal files in addition to dry extracts from issues. Let employees be honest. Let them write in daily reports: “I worked on tasks for 3 hours, and studied Python for 4 hours.” Not bad, but oh dear, 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 essence, this is personal information. Trashy time, which ... However, stop! Our task is not to convict the employee of inaction, but to motivate him. That he not only saw progress in the number of tasks performed, but also in daily work on himself. And with respect to leadership - honesty and openness, so that there is a dialogue, built trust and delegation of authority with responsibility. So in the end, at one point, he came to you with the words “I studied, I studied Python, and now I want to take my project.”
PS in the article, financial reporting, audits and personnel reporting are not fundamentally affected. None of these reports should be related to or performed by the developer. If the opposite is true, it is also a sign of a management problem. If, say, the enterprise mode requires tight time control, then this should be done without attracting the time of the development engineer - an automatic access system or secretary Ellochka. If financial reporting requires the signatures of development engineers, then this is also the concern of the corporate reporting department or accountant Elvira Mikhailovna, but there is no reason to make a 2.5-link programmer-accountant-risk manager from a cyborg technical specialist.
From an engineer to a manager. Part 1: A Sense of Justice
From engineer to leader. Part 2: Delegation and Problem Setting
Overflow
I learned all the wisdom of balance and harmony, not looking at the sakura and the passing corpses of my superiors, but in harsh reality. And the reality was really harsh. In the dark, they sent us a dark manager from distant Africa. He had a magnificent white smile, which at night in a dark alley could be confused with the smile of the disappearing Cheshire Cat, but there was very little idea of what an airplane was, which, in general, we did. Even more so, the smiling manager, apparently, saw the plane once in his life, when the happy one flew to lead our project. And, unfortunately, he, apparently, also mastered computers not very long ago, unlike the bicycle, which he cruelly beaten with time, who rode home from work, holding in one hand a package from a Chinese restaurant, and in the other the schedules and plans of our project.
The project was urgent and difficult: it was necessary to lick and fix all the jambs before the upcoming certification. Because he was on-site, he had to deal with machines that had not previously been seen in the eye and did not really understand what to expect from them. It took a lot of time to learn, and therefore it was important to monitor progress, to monitor the process a lot and clearly. The project involved three teams of 6-7 people each, who were accountable to him. To take into account who did what, the manager opened an Excel table that each participant had to fill out every day: how many modules were reviewed, tested. Those. made noted on the plate. But there was problem number one: there were a lot of people, and there was only one file. Therefore, the list of tasks was accumulated by people in local files, and then transferred to the rows of the table indicating the accountable. During, when the file was released they fought and fought. And if anyone was unlucky to wait for the file to be released, it remained outside working hours to put multi-colored statuses on the tablet.
The manager held rallies every day. He told them how to fill out a table, which consumed time by the hour. 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 with a person running on the simulator, the lack of a module, etc., however, without problems with the table. So the second file and a table appeared in which it was necessary to enter bugs, with the transfer of all checked statuses from the first. However, as it turned out a week later, this is not so effective, and we still need to count something, and the manager did not 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 suggested filling out a third, in which the results would be numbers, manually calculated results and their percentages, because the manager has locked the tables for security. Moreover, it was supplemented so that there was feedback with the first one - to fill in the progress there, that if something did not succeed, then indicate the status on the module “delayed”, and in the second make corrections - problems with time.
Needless to say, problems over time appeared long before these innovations? In fact, in each of the teams one of its participants was only engaged in filling out these tables, shamelessly confusing and skipping what was in the heap of text files. And since the table files were broken due to the fact that they turned out to be errors, to save statistics they were saved by everyone (each under a separate name), after a critical change, and they multiplied by leaps and bounds, and understand what is the latest and relevant - was problematic.
The project was closed on time. The manager left of his own free will a week before the closure of the project and drove off in his blue sky far away, leaving us with harsh everyday life and black thoughts. 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 preparation should not interfere with other people working. Ideally, this is a click on the checkbox \ slider on the progress bar with a feedback in the bug tracking system, if necessary. This is not always possible, and you have to get out with unimaginable crutches in the absence of a centralized practice, but you need to simplify the reporting costs and trust the technique, as well as have an idea of the subject area in the first place. In order to at least not distract specialists from work.
Underflow
In addition to trust in computing technology, one must be guided by the technique of understanding people. Taught by the example of the manager, in one of the following projects I prepared daily reports, in which, in addition to listing everything that was done during the day, was compared with the planned one automatically, it was enough to put only pass \ fail in front of the actual task. But, because the assignment 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, 11 of the 40 planned are ready.” And at the beginning of the new week I wanted to report that I had finished work twice as fast. Beautiful schedules for managers “planned” and “done” optimistically diverged and will go up. The reports passed through team lead, there is progress: it is clear when and what has been done. But the weekly briefing by the project manager turned out to be a reason to call me and ask the question: “Why are you stretching the time? For a month? Why are we holding you here? ” Justification that the work will be done tomorrow was of little interest to anyone, because such a “planned” schedule in their person also expressed my motivation, therefore the ability to perform new tasks. I stopped and thought what was wrong. First, managers, when planning, lay down risks and deadlines, often guided by the worst example. And when, instead of the worst example of an employee, they turn out to be a good professional, they don’t always have to hurry to draw conclusions and give their positive ratings for the manager. Not even so much because of the prerogatives and separation of roles, but because the general picture may not always be visible to him,
When you learn from your mistakes, it is important not to lose motivation and understanding that reports are not just a duty and a routine, but really a sharp tool for the work of the leader, programmer, tester, system administrator, and, of course, manager. You just need to get it and apply it to the place. The quintessence of my reporting experience was compiling a roadmap for one of the projects.
Division by zero
The roadmap was a list of all the modules that were to be worked on. It was only necessary to put down the status of the task. A couple of minutes a day. The system did everything else. I calculated who and how much did what, when, what progress, what trends, what problems, what plan, what kind of adjusted plan, effectiveness, etc. The only thing a team member had to do was click on his module and set pass \ fail, and then it would be possible to generate a report for the leader with everything necessary so that the latter could only move the progress to MS Project and, if necessary, make those corrections that he deems necessary.
The project was not trivial, for the place of usual verification and completion, I had to study electrical circuits, count voltages, current strength, look at the consequences of breaking / closing circuits and transfer their logic and their influence on the code. Fortunately, at that time, as a hobby, I became interested in electrical engineering and soldered boards in the evenings, so circuits with various manipulations on the ADC, potentiometers, voltage phases were not too vague for me. But this should be explained to my fellow programmers, and, in particular, to one newcomer. Therefore, it was very important to evaluate how we cope with this task, and how much we need real time and what costs are against the set requirements and deadlines. And to my happiness, at the same time my vacation came up. Without me, according to my estimates, my colleagues would have completed the task in a week or a little more. Giving instruction to make updates every day and keep the boss in the know; I swam calmly for two weeks with fish and fed the crocodiles, completely throwing all the problems out of my head. But upon arrival, the unexpected was waiting for me. The boss transferred his senior comrades to other fronts, seeing that everything was going well and better than expected, and left only a novice on this project. The newcomer did everything, as I expected, even before my arrival and honestly filled out the reports. But only before showing it to the authorities. Those. scoring the arithmetic mean in the data for each day, but once, before showing it to the boss. Such data was 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 that has become a serious problem. How long does it take for the next iteration? Is there any prospect of productivity growth? Does the complexity of the modules vary greatly? How did we learn new methods and approaches? All the potential from 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 you need an assessment and research, and not ordinary statistics, then you can’t allow changes in past data, if the data should reflect daily relevance or more often, it means they should be collected in such discretes, i.e. to be relevant. So this must be demanded, reminders, forced way or control. Even protected from risks by technology, the process system is not protected from human risks, and they must be foreseen and forced.
What is an ideal reporting system?
Perhaps the best solution would 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 flexibility in reachability ( Attainable : the presence of this module, the ability to process 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 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, determine 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 is prioritized, it determines the timing of its implementation in a stand-alone way (regardless of the timing of the project), and requires certain behavior and reporting from it. For example, low-priority tasks can be extended over time, and high-priority tasks are performed immediately within a couple of minutes or hours. However, if the task takes time in excess of the reporting discrete, then a report is prepared on the problem. It sounds strange, but in reality it’s an answer in a bug tracking system such as banal: “I'm working on it, integer conversions implemented, 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 materially rely on without a final commit. This is necessary first of all, in order so as not to shut up on what is already considered worked out and catch the problem before it begins to affect the entire project. Use Jira, Redmine, Bugzilla, Trac, GNATS, your mail script, just use it, don't talk it out orally (sometimes the management is not up to it, and he will not always notice the importance of the problem if his thoughts are busy with something else, no matter how you try it to inform) or a belated mention in the final reports of already forgotten and distorted numbers and names.Roadmap Level:
Typically, this is a daily report of a species made X of Y for today. New \ Old \ Total. Its purpose is task control, task complexity assessment. It is a squeeze from the updated (Updated) tasks for today. Ideally, it is generated automatically based on changes to checkbox \ issues in the system. It is the analysis of these reports that allows us to talk 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 real effectiveness and development progress (based on a set of such reports) can be presented. Among other things, this is the protection of the employee himself, as Formally, it’s a protective paper from the boss that he works, and does not hack, but this is in the case of terminal super-control of the leadership (which happens more often than we would like). And again, in your service you have both bug tracking systems and monster-like project management systems such as Project or even SAP, but in the simplest case, Outlook functionality will also work, especially with an added relationship with the office. Do not complicate the five-minute business with unnecessary and expensive piles.Project Level:
This is usually a weekly report. What the employee (s) worked on, how much he did, how much was left. Its purpose is to evaluate the current state of the project, meeting deadlines, planning and risk management. It is a formalized report in the form established by the company, usually indicating risks, problems, solutions and plans. Hire an automation tool to generate them or templates in a popular office application. Some bug tracking systems already have similar functionality, so do not disdain it.Analytics Level:
quarterly progress reports. This is a list of all projects spent time and efficiency. Its purpose is management and strategic planning. It often represents 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 of the project management system or bug tracking system, but the tools for analysis, as practice shows, are always in short supply. Yes, and some problems can not be written into the workflow, so such reports are akin to an article and a small study.This may not be applicable, at first glance, for startups, where, in fact, there is no one to report. But both in them and in freelance, as you know, it motivates good self-control and self-managment. And it’s more convenient to save actions not in the head, but in the same bug tracking system, perhaps in a cloudy environment, so that over time, you can track and find your decisions and their consequences. Set there goals - workers and personal goals of their development. Rejoice in success and growth, analyze failures and difficulties. Also, do not ask what management can do for you, but ask what you can do for management. Every week, as the last working day of the week ended, I compiled a consolidated report and out of habit, highlighted in yellow the risks associated with insufficient savvy in my new platform. A week. Month. Two. And unexpectedly, the boss called me and growled into the phone: “Hey, what can be done to increase efficiency? Manual reading is not enough? Should Tulsa be faster? ” For me, this item was not important in the report. He wandered from report to report, reporting that I work for myself, understand the manuals and forums, but still do not complete my tasks with my eyes closed, and even more so in the automatic sleep mode after stormy holidays. But for the authorities it turned out to be at least a small, but intrusive pain in the ass. The entire effective and green report, everything on time, everything seems to be fine, but one phrase spoiled the idyllic paradise of the Augean stables I dealt with. And the ice began to break. Simple and unobtrusive. I was offered solutions from above. The truth is spoken in the east, drinking glasses of green tea: "The journey of a thousand begins with one step."
Reporting can vary greatly depending on the style of the company, but my conclusion is the same: whatever format - daily Stand-up meetings, reports in papers, in project management systems, bug tracking systems, conversations over morning tea drinking, reports greatly help to regulate project status and company viability. They ultimately allow even the smallest employees to feel part of something global. That, however, should be realized as a goal and as a structure for effective work and understanding by employees, from a small to a great leader, 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 “instrument of control and analysis” or, at worst, “documentation”. But I got the answer: “Yes, they are not needed. No, of course it’s clear that they are needed, but in practice they are of no use except for wasting time. ” It was not even a misunderstanding, but the fact that they usually do not know how to use them, unless in order to show the boss. But the boss usually does not use them further than as an appendix to the product.
Then I should give specific examples of the use of reporting.
Situation 1. “A reborn bug”
You probably know one of Murphy's laws: “ The property of the parity of errors. If the written program worked correctly, it means that during its operation an even number of errors were completed or the programmer did not understand the task . ” Unfortunately, this happens more often than we would like.
Some tasks require significant investment of time, and do not always have to be completed. And therefore, while catching bugs, one of the new revisions may very well become working before the fix, and the bug no longer appears. The developer will report that there is no more bug. However, the cause of the initial bug will not be resolved and after a while it will prove itself with new corrections. However, this does not mean that the developer messed up 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, the tests pass. But for the project, this task can be rediscovered in order to clean out both bugs and compensating factors so as not to have tails in the future.
Case 2: “Productivity”
In general, reports are usually needed by project managers and a task leader who will distribute tasks and schedule downloads depending on performance. She needs to be counted somehow. But also productivity is a measure of employee efficiency and development. Remember that each employee sends a weekly report in the form of a time sheet? Now let's see how much time he takes on tasks over time.
What do we see here? Completing 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 in the end, the time spent on tasks was reduced (C). Here you can see the improvement and growth of the employee, his initiative, which entailed the improvement of work. The example is lively enough until the employee ascribes heroism to himself. But our bug tracking system or roadmap, fortunately, keeps track of really completed things. Therefore, solely for the abstract example, such an analysis can be improved by simply multiplying the reciprocal of the number of completed tasks by the time taken for each day.
The graph turned out to be torn (I faked it, I repent), but it still shows the trend and influence of automation integration. The analysis of empirical data from the results obtained is a separate topic that is not the subject of this article. But with the involvement of the reporting mechanism, both the employee and the employer have a good tool for assessing effectiveness. Adding to it an estimate of the resources spent on training, one can draw other interesting conclusions. In any case, for analysis and evaluation, the availability of a log (report) creation mechanism is a great help. It remains only to motivate people and tell you what opportunities are presented by activities related to reporting.
conclusions
In addition to explaining the benefits of reports and finding ways to implement a logging system, it’s great practice to introduce a personal time management for each employee. If they don’t use GTD yetplease tell them how cool and nice it is to cross out tasks. They are done, it turns out, profit! Without getting into the jungle of this topic, only with the goal of supplementing the analysis with personal files in addition to dry extracts from issues. Let employees be honest. Let them write in daily reports: “I worked on tasks for 3 hours, and studied Python for 4 hours.” Not bad, but oh dear, 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 essence, this is personal information. Trashy time, which ... However, stop! Our task is not to convict the employee of inaction, but to motivate him. That he not only saw progress in the number of tasks performed, but also in daily work on himself. And with respect to leadership - honesty and openness, so that there is a dialogue, built trust and delegation of authority with responsibility. So in the end, at one point, he came to you with the words “I studied, I studied Python, and now I want to take my project.”
PS in the article, financial reporting, audits and personnel reporting are not fundamentally affected. None of these reports should be related to or performed by the developer. If the opposite is true, it is also a sign of a management problem. If, say, the enterprise mode requires tight time control, then this should be done without attracting the time of the development engineer - an automatic access system or secretary Ellochka. If financial reporting requires the signatures of development engineers, then this is also the concern of the corporate reporting department or accountant Elvira Mikhailovna, but there is no reason to make a 2.5-link programmer-accountant-risk manager from a cyborg technical specialist.