Engineering approaches and checklist: how not to go crazy in the chaos of tasks

Hello! My name is Oleg, and I'm a frontend developer at Alfa Bank. I want to tell you a little philosophical story - about the engineering approach to development, about my first job and the rake that I collected there, about why checklisters are very important (and save lives).

And also about how to continue to work productively and not dig in a lot of small and not very tasks.

It all started with chaos.

At my first job (not Alpha, no) I was somehow taken and immediately thrown into the embrasure, they said, guy, now you do CRM, the comp is over there. What to do and how to do - I did not understand at all. What do they usually do in such a situation? That's right - they run to their colleagues and begin to check with them how to deliver the code to the server, how are things with the git, what practices we use, and which ones not, and so on. This approach helped me, and I constantly advise others to do it. Ask, ask questions, even if it seems obvious to you, specify what needs to be clarified. This is normal. It’s not normal to not ask.

My next step was to use books. Because when I was returning questions and getting answers like “Yuzay linter”, I caught myself thinking that I know how to do all this, but I don’t quite understand why. I was sincerely interested to know where the legs grow in all the processes, and I decided to look for help in the books. “Pure code”, “Perfect code” - in general, I went to the standard set, where they say that the function should not be longer than 30 lines. I must say right away that it did not help to understand everything and control the chaos.

Yes, I began to write noticeably cleaner, but the chaos in the form of a heap of tasks, which I could not normally solve, did not go away. Colleagues decided to help with wise advice like “Dude, you just don’t have enough edge, let's read about the edge here and everything will be cool with you, if you also give the Scrum-master.”

Well yes. Agile alone is a good thing. But when you work in a team. And the one-face Edge is a little strange. I started digging further, found kaizen books. And then I met the theory of system restriction and the book “Purpose”. Many probably read it, so I’ll just briefly note that one of the main messages here is not to improve everything everywhere at once, but first find one problem and fix it. Fixed - look for the next one and fix it. The author came to this through engineering approaches, because engineers do something like this - they look for a problem and solve it.

Okay, this is lyrics, let's get closer to practice.

In life

Suppose you have some kind of spherical process in a vacuum in which there is a designer, front-end and tester. The designer draws layouts and buttons in one day, the front-end works in three days with this, and the tester needs two days. It seems to be a simple scheme and it is immediately clear where to improve the process - on the front-end, because its work takes the most time. That is, the point of optimization is to find the slowest stage in the process.

But this is a simple example with three variables. Of course, work is often different. And much different. The process gets complicated when you have a backend, documentation, CI / CD and other important gizmos.



And then it will not be possible to immediately grab and say which process is the slowest and where to start. Here, the process of optimizing the slowest stage will look like this:

1. We must find the restriction, the slowest.
2. Decide how to use it as much as possible.
3. Subordinate everything to the decision.
4. To develop (expand) the restriction.
5. Go back and repeat.

It may sound messy, so I will write in more detail.

What to do, do you have any parallel tasks that you are busy with?



In this case, you will search for the longest route by days in total. In the picture above it is about 6 days. Start with it, with this longest process. It turns out that in this example you will improve the backend, because it takes 4.5 days. This is also not so difficult, but when you come to this and begin to do so, you notice that life becomes easier.

I will return to examples of my working chaos. I got a bunch of tasks and I did not have time. I realized that there is a limitation in the frontend (that is, in me), that the problem is not in the tester, because he finds bugs, namely on my side. To do something about it, I began to think how to use this restriction.

And he decided that we need to change the process so that there is only one entry point - one person who makes decisions about whether we will do the task or not. Because there were cases when one person came and said, Oleg, we need to move the button here a little to the right. And then another one. And in half an hour someone else with a similar task. And it seems that little things and garbage, but in the end I sewn up completely, trying to please everyone.

Now I try to do no more than 2 tasks in parallel (in parallel, and not simultaneously). Previously, I could give the tester a task and go do the following, but if the tester found a bug, I had to check, remember and switch to what code was written there, which is harder than it sounds when you switch often. And in general, switching is expensive. Try not to do more than 2 tasks in parallel. 3 tasks are already a way to sew up.

Let’s think about how to subordinate everything else to the decision. It seems to sound logical, yes, that if there are so many tasks, then you don’t need to throw a slide? For example, you expect a person to do three tasks of approximately equal complexity in three days. If in two days out of three he did only one task, most likely he does not fit into the plan, so throwing him more tasks from above is a little demotivating thing.

More about restrictions

Of course, restrictions can be expanded. In our example, hire another front. It is also logical, more fronts - they will have time to complete more tasks. Then the restriction will be transferred to another place.

There is also an approach in which they expand not the number of units, but their competencies. I have a living example - the tester could help me in the front end if I knew the front end. For my colleague, the scrum-master began to write the frontend on his own, because he was interested, he did some features there with a twinkle, and he had fun and the team helped him. I do not urge to do this at home, because the result can be very different, but as an example, there is such an approach - yes, and it sometimes works.

Checklist

Checklisters really help make life easier. This checklist for Alfa-Bank now helps a lot in my work , where there are quite a few stages that need to be completed.

Cheklists even save lives, I will give a small excerpt from the book “Understand the risks. How to choose the right course ":

At the dawn of aviation, pilots flew on airplanes that were not as equipped with technical equipment as they are today. Checklists began to be used in the US Air Force only after it became clear that the B-17 bomber is too large a plane and cannot be controlled by only one person. In 2009, when both engines stalled on US Airways flight 1549 immediately after taking off from La Guardia Airport, the pilots performed all the checklist actions in such an emergency, including an attempt to restart the engines. Flight attendants, again in accordance with checklists, strictly monitored the proper preparation of passengers for an emergency landing. Checklists like these are a simple and inexpensive way to increase security.

In medicine, a different picture is observed. Each year, the misuse of central venous catheters causes approximately 80 thousand cases of bloodstream infection, and as a result, about 28 thousand people die in intensive care units in American hospitals. And those patients who manage to survive spend an additional one additional week on average in intensive care. The total cost of treating such infections is estimated at $ 2.3 billion per year. What can save these people? Better medicines to treat infections, better technologies? The answer is: improving the culture of mistakes.

In 2001, Peter Pronovost of the Johns Hopkins Hospital drafted a simple checklist for emergency room physicians to check if these measures could reduce the spread of infection. Here are five successive steps designed to prevent dangerous bacteria from entering the patient:

1) wash your hands with soap;
2) treat the patient's skin with chlorhexidine antiseptic;
3) cover the patient with a sterile sheet;
4) wear a sterile mask, hat, apron and gloves;
5) apply sterile material over the catheter after the catheter is inserted into the vein.

In this list, each of the protective measures was well known, it did not contain anything new. Pronovost asked nurses working in his intensive care unit to see if doctors followed these 5 rules. Nurses reported that when installing a catheter, more than a third of all patients had one or more of these rules not followed. The rate of infection of the bloodstream in the hospital at that time was 11%.

Pronovost convinced the hospital administration to allow nurses to stop doctors if they missed any of the five prescribed measures. This revolutionary innovation violated the hierarchical structure in which paramedical personnel (mainly women) had no right to give instructions to surgeons (mainly men). After a year, during which these instructions were strictly followed, the rate of infection of the bloodstream in hospital patients decreased from 11% to 0 (!). And over the next 15 months, only 2 cases of such infection were noted. In this hospital alone, the list of instructions prevented 43 infections, 8 deaths, and saved $ 2 million.

To show that the effect of using the checklist was not limited to his hospital, Pronovost convinced more than a hundred intensive care units in Michigan to participate in a large-scale joint study. It is important to note that each of them developed its own list of actions that is most relevant to its culture.

The intensive care units participating in the study reported that previously they had a total of 695 cases of infection of the bloodstream due to the use of catheters. Just 3 months after the start of using checklists in most departments, the patient’s infection rate dropped to zero. The remaining intensive care units also managed to significantly reduce this indicator for the year and a half during which the study was conducted. This large-scale program to save lives was implemented without the use of expensive technologies and without increasing the number of hospital staff.

That is, each of these points was known, this is not some kind of novelty or something else. Peter simply designed it in checklist format and made it mandatory. All.

We try to improve not only our results, but also the results of others, so we constantly update our working checklist. If I suddenly forgot something and didn’t do something in the process, I put it on the checklist so as not to forget the next time. Previously, models were often returned to the designer for rework, although he said that he immediately understood everything and would do it right, and after that he just asked us for a checklist, I threw off a piece of it for the design, and it became easier.

I sorted my checklist by action - 1 action = 1 checklist item. The main thing here is also not to rest very strongly and not to go into checklists for the sake of checklists. Page Make Up is a good point. “Make up controls” - even more, will help not to forget about controls and their nuances.

A checklist can be hierarchical: page layout -> page layout -> page layout.

Why just coding is not enough

Tests are needed. But they are not always needed. For example, you make a landing once, and do not plan to return to it later - then there is no point in pushing it very hard. You can cover selectors with units or use end2end, but unit tests for the rest are a waste of time.

But that's why coding is not enough. Again, an example from the first work - I had to change something, I went to my colleagues and talked about it, they replied that they were busy. And my sprint is burning. And there is nobody to help. As a result, he began to understand himself in additional competencies.

Suppose you have some good skill, for example, working with CI / CD. The designer gave you the layout and went on vacation, you had a couple of edits or questions, but until he comes back from vacation, that's it, the process is worth it. Expand your skills, because if the weak point in the process is on the design side, well, the designer is sewn up for a number of reasons, you can help him. This is an additional set of knowledge, but it can be mastered. Of course, I'm not talking about completely and fully replacing a specialist, I'm talking about basic skills.

conclusions

It is useful to approach the matter as an engineer. Even if your work is not of an engineering nature. It allows you not to introduce everything thoughtlessly in a row, but to find a problem and introduce only what contributes to its solution.

Need to communicate and discuss solutions. Communication is in principle difficult to overestimate. Sometimes problems arise because of the so-called silent initiative. We had a case when we were given a .Net-developer and a simple task for him to write tests. He quickly wrote everything, tests, unit tests, selects, and then for some reason began to do something beyond what was in the task. Apparently, in the belief that this will be useful to us. As a result, all that he did made us spend a lot of time on additional synchronization, and then all this all the same went to the trash in essence. Just because of basic communication problems. Do not do like this.

Well, a list of useful books:

• System Restriction Theory (E. Goldratt)
• Critical chain project management (E. Goldratt)
• Gemba kaizen - a way to reduce costs and improve quality (M. Imai)
• Agile Management: Leadership and Team Management (A. Jürgen)
• Extreme Programming Explained (K. Beck)

A detailed presentation can be found here .

Do you use checklists, do you consider them necessary? If you have any approach to maintaining or creating a checklist, please share in the comments.