A couple of words about the project diary
Confucius once said: "A wise man learns from his own experience, a sage from a stranger." In this article I will try to take another step towards the “smart person” and share how you can accumulate your experience throughout the project.
It is known that it is painful, offensive and unpleasant to step on a rake. However, if a rake lies in a completely unexpected place, they have just been left there, and in the courtyard deep night and not a damn thing is visible, it is permissible. It is not only painful and annoying to step on the rake for the second time, but also ashamed.
How not to step on a rake to the project manager? The question is, in fact, not obvious. It is clear that there is no universal medicine for this. The first and easiest option is “this will come with experience.” That is why experience is a very valuable resource, the loss of which needs to be minimized. One of these ways to preserve the experience of past projects as much as possible, I actively apply and now I will describe it to you. It is called - the diary of the project.
So, first decide what is at stake. By project diary, I mean an absolutely trivial thing - a table in which I write down significant events that occur during a project. I record both my decisions and events that, in my opinion, have an impact on the course of the project. For example:
In general, it is clear that most of the entries are descriptions of my decisions with comments about their effectiveness. And it is clear that most of the decisions are erroneous.
')
Each entry consists of four columns: date, description, category and conclusions.
Description - this is a detailed text, where several sentences describe the fact that arose during the project. Examples of descriptions are given in the previous section.
Category - the simplest classification of events. I actually have three of them: win, fail and "???". Obviously, the first one says that the decision or factor was successful, the second one shows that we “flew” strongly because of this decision, and in the case of the third category, I have not yet decided whether to consider this event successful. Sometimes the category draw (the event had no effect on the project) occurs, but it appears extremely rarely.
It happens that an entry from one category wanders into another. For example, the entry “Gave the go-ahead to refactoring section X. We’ll see if the 40 hours it should take will pay off” migrated from the fail category when the refactoring was delayed for two weeks to the win category, when the result was a clean and tidy version which was immediately handed over to the customer, saving a lot of time on the bugfixes in the initially “plasticine” implementation.
Or, even clearer: “I continue to delay the team until late in the days of deploys” at first had the category of win, because We met in a short time and received a significant bonus from customers (of course, the team was pleased with the high premium). Immediately after that, one of the key developers began to openly "slip" from scratch, and it became obvious that he was "burned out". I had to send him on vacation, and the project dragged on much more than it could if we worked “exactly” all the time. As a result, the fact that the team was delayed at night migrated from win to fail.
Conclusions - in my opinion, the most important column. Here I try to describe as fully as possible what results this event has caused, and what conclusions I need to draw from this. This, of course, the most difficult.
In general, the conclusions can be the simplest and most obvious, for example, “It is necessary to store documents in the version control system”
author's note: this record appeared after I inadvertently overwritten the file with the estimates for the iteration and had to restore them in half a day .
On the other hand, the output can take many lines, such as: “At the analysis stage, you need to require examples of how the result should look. This encourages the customer to think about what he wants to receive. The same for changes: apparently, you can not start work until the interface is approved. It does not make sense to rely on textual descriptions (especially bad ones) - you always need a picture. ”
Author's note: we are talking about an insufficiently developed textual TK for changing a part of the system, which we accepted in a hurry, believing that the customer knows how best. Then, after the implementation of the first version, it turned out that the customer wanted something completely different, but did not write it. I had to breed long (and, thank God, successful) diplomacy with the customer with the conviction that he really wants something completely different, and not what he wrote .
My last project, which took several thousand man-hours, had a five-page diary. Rereading it, I am sometimes horrified how I could allow this or that stupidity, which naturally had serious consequences. But, if you are completely honest with yourself and regularly re-read what you wrote, without allowing yourself to write off failures as external factors, then it is quite possible to avoid similar mistakes in the future. What I really hope for.
PS I want to emphasize that the examples may be fictional, and the coincidence - random
It is known that it is painful, offensive and unpleasant to step on a rake. However, if a rake lies in a completely unexpected place, they have just been left there, and in the courtyard deep night and not a damn thing is visible, it is permissible. It is not only painful and annoying to step on the rake for the second time, but also ashamed.
How not to step on a rake to the project manager? The question is, in fact, not obvious. It is clear that there is no universal medicine for this. The first and easiest option is “this will come with experience.” That is why experience is a very valuable resource, the loss of which needs to be minimized. One of these ways to preserve the experience of past projects as much as possible, I actively apply and now I will describe it to you. It is called - the diary of the project.
What do I mean by “project diary”
So, first decide what is at stake. By project diary, I mean an absolutely trivial thing - a table in which I write down significant events that occur during a project. I record both my decisions and events that, in my opinion, have an impact on the course of the project. For example:
- Gave Vasya the task of analytics. Hope to cope well. In this case, I can focus on managing and interacting with the customer, and partly delegate the analyst to him
- I sent Vasya on unplanned vacation for 2 weeks. The decision was made spontaneously, looking at his exhausted appearance. This will delay the project a little, but will increase Vasya’s performance.
- The application was approved by Apple, but withdrawn at the initiative of the customer due to errors in section X. Errors were found on our QA in the testing process, but I made a decision not to consider them critical and release the application ( author's note: yes, I’m ashamed about it remember, but the fact took place )
- Impressed customers and received a bonus
In general, it is clear that most of the entries are descriptions of my decisions with comments about their effectiveness. And it is clear that most of the decisions are erroneous.
')
Record structure
Each entry consists of four columns: date, description, category and conclusions.
Description - this is a detailed text, where several sentences describe the fact that arose during the project. Examples of descriptions are given in the previous section.
Category - the simplest classification of events. I actually have three of them: win, fail and "???". Obviously, the first one says that the decision or factor was successful, the second one shows that we “flew” strongly because of this decision, and in the case of the third category, I have not yet decided whether to consider this event successful. Sometimes the category draw (the event had no effect on the project) occurs, but it appears extremely rarely.
It happens that an entry from one category wanders into another. For example, the entry “Gave the go-ahead to refactoring section X. We’ll see if the 40 hours it should take will pay off” migrated from the fail category when the refactoring was delayed for two weeks to the win category, when the result was a clean and tidy version which was immediately handed over to the customer, saving a lot of time on the bugfixes in the initially “plasticine” implementation.
Or, even clearer: “I continue to delay the team until late in the days of deploys” at first had the category of win, because We met in a short time and received a significant bonus from customers (of course, the team was pleased with the high premium). Immediately after that, one of the key developers began to openly "slip" from scratch, and it became obvious that he was "burned out". I had to send him on vacation, and the project dragged on much more than it could if we worked “exactly” all the time. As a result, the fact that the team was delayed at night migrated from win to fail.
Conclusions - in my opinion, the most important column. Here I try to describe as fully as possible what results this event has caused, and what conclusions I need to draw from this. This, of course, the most difficult.
In general, the conclusions can be the simplest and most obvious, for example, “It is necessary to store documents in the version control system”
author's note: this record appeared after I inadvertently overwritten the file with the estimates for the iteration and had to restore them in half a day .
On the other hand, the output can take many lines, such as: “At the analysis stage, you need to require examples of how the result should look. This encourages the customer to think about what he wants to receive. The same for changes: apparently, you can not start work until the interface is approved. It does not make sense to rely on textual descriptions (especially bad ones) - you always need a picture. ”
Author's note: we are talking about an insufficiently developed textual TK for changing a part of the system, which we accepted in a hurry, believing that the customer knows how best. Then, after the implementation of the first version, it turned out that the customer wanted something completely different, but did not write it. I had to breed long (and, thank God, successful) diplomacy with the customer with the conviction that he really wants something completely different, and not what he wrote .
A few words in conclusion
My last project, which took several thousand man-hours, had a five-page diary. Rereading it, I am sometimes horrified how I could allow this or that stupidity, which naturally had serious consequences. But, if you are completely honest with yourself and regularly re-read what you wrote, without allowing yourself to write off failures as external factors, then it is quite possible to avoid similar mistakes in the future. What I really hope for.
PS I want to emphasize that the examples may be fictional, and the coincidence - random
Source: https://habr.com/ru/post/116251/
All Articles