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

Hello! My name is Oleg, and I am 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 I collected there, about why checklists are very important (and save lives).

And also about how to continue to work productively and not to dig in a variety of small and not very problems.
')
It all started with chaos.

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

My next step was to use books. Because when I returned questions and got answers like “Yuzai Linters”, I caught myself thinking that I knew exactly how to do all this, but I don’t quite understand why. I was genuinely interested to know where the legs grow from in all the processes, and I decided to look for help in the books. “Clean code”, “Perfect code” - in general, I went through the standard set, where they say that the function should not be longer than 30 lines. I must say, to understand everything and control the chaos that did not help.

Yes, I became noticeably cleaner to write, but the chaos in the form of a heap of tasks that I could not normally clean up did not go anywhere. Colleagues decided to help the wise advice of the form "Dude, you just do not have enough Ejayl, let's read it here about the Ejail and you will have everything cool, if anything else, we will give a scram master."

Well yes. Edgyl is a good thing in itself. But when you work in a team. And the Edgile is the same person a little strange. I began to dig further, found books on kaizen. And then I met the theory of limiting systems and the book "Goal". Many probably read it, so I’ll just briefly note that one of the main messages here is - do not improve everything everywhere and immediately, but first find one problem and fix it. Fix it - look for the next one and fix it. The author came to this through engineering approaches, because engineers do something like this - they are looking for a problem and solve it.

Ok, this is the lyrics, let's take a closer look at the practice.

In life

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

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



And then it will not work out right away to take and say which process is the slowest and where it is worth starting. Here the optimization process of the slowest stage will look like this:

1. We must find a limitation, the slowest.
2. Decide how to make the most of it.
3. Subordinate all the decision.
4. To develop (expand) the constraint.
5. Go back and repeat.

It may sound messy, so sign for more.

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



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

I will return to the examples about my working chaos. I flew 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 with it, I began to think how to use this restriction.

And I decided that I had to change the process so that there was only one entry point - one person making decisions about whether we would do the task or not. Because there were cases when one person came and said, Oleg, we need to move the button here a bit more to the right. And then another. And in half an hour someone else with a similar task. And it seems that the little things and garbage, but in the end I am completely sewn up, 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 seems when you switch frequently. And in general, switching is expensive. Try not to do more than 2 tasks in parallel. 3 tasks are now a way to sew up.

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

More about restrictions

Of course, limitations can be extended. In our example - to hire another front. It is also logical, more fronts - they will have time to do more tasks. Then the restriction is 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 - a tester could help me in the frontend if I knew the frontend. My colleague, the scram master, started writing the front-end independently, because he was interested, he made some features there with a twinkle, and he was happy to help the team. I do not urge to do it at home, because the result can be very different, but as an example, that such an approach exists - yes, and it sometimes works.

Checklists

Cheklisty really help make life easier. In my work, this checklist for Alfa-Bank is very helpful now , where there are quite a few stages that need to be completed.

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

At the dawn of aviation, pilots flew airplanes that were not as equipped with technical means as they are today. The checklists began to be used in the US Air Force only after it became clear that the B-17 bomber was too large and could not be driven by just one person. In 2009, when, immediately after takeoff from La Guardia airport, a flight of 1549 from both US Airways aircraft stalled both engines, the pilots performed all the actions provided for in such an emergency, including an attempt to restart the engines. The flight attendants, again in accordance with the check-lists, strictly followed the correct preparation of passengers for an emergency landing. Such checklists are a simple and inexpensive tool for increasing security.

In medicine, there is a different picture. Each year, incorrect use of central venous catheters causes approximately 80 thousand cases of bloodstream infection, and as a result, about 28 thousand people die in the intensive care units of American hospitals. And those patients who manage to survive spend an 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? More advanced drugs for the treatment of infections, more advanced technology? The answer is: improving the culture of error.

In 2001, Peter Pronevost, from the Johns Hopkins Hospital, compiled a simple check-list for resuscitation department doctors to check whether the complex of these measures is able to reduce the spread of infection. Here are five consecutive steps to prevent dangerous bacteria from entering the patient’s body:

1) wash hands with soap and water;
2) treat the patient's skin with a chlorhexidine antiseptic;
3) cover the patient with a sterile sheet;
4) wear a sterile mask, cap, apron and gloves;
5) put a sterile material on top of the catheter after inserting the catheter into the vein.

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

Pronevost persuaded the hospital to allow nurses to stop doctors if they missed any of the five prescribed measures. This revolutionary innovation violated the hierarchical structure in which nurses (mostly women) had no right to give instructions to surgeons (mostly men). A year later, during which these instructions were strictly followed, the rate of infection of the bloodstream in patients in the hospital decreased from 11% to 0 (!). Over the next 15 months, there were only 2 cases of such infection. Only in this hospital alone, a list of instructions prevented 43 cases of infection, 8 deaths and saved $ 2 million.

To show that the effect of using a control card is not limited to his hospital, Proneost convinced more than a hundred intensive care units in Michigan to take part in a large-scale joint study. It is important to note that each of them developed its own list of actions, the most appropriate to its culture.

The intensive care units participating in the study reported that they had previously observed a total of 695 cases of infection of the bloodstream due to the use of catheters. Only 3 months after the start of the use of checklists in most departments, the infection rate of patients fell to zero. The remaining intensive care units also managed to significantly reduce this figure over the one and a half years during which the study was conducted. This large-scale program to save lives has been implemented without the use of expensive technologies and without increasing the number of hospital staff.

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

We try to improve not only our results, but also the results of others, therefore we constantly finish our working check list. If I suddenly forgot something in the process and did not do it, I add it to the checklist so as not to forget next time. Previously, the designer was often returned models for rework, although he said that he immediately understood everything and would do it right, and after that he simply asked the checklist for us, I threw him a piece of design, and it became simpler.

I sorted my checklist by actions - 1 action = 1 checklist item. Here the main thing is also not to rest on it very strongly and not to go to the checklist for the sake of checklist. "Roll up the page" is a good item. “To make controls” is even more detailed, it will help not to forget about the controls and their nuances.

The checklist can be hierarchical: fold pages -> roll up forms -> roll up buttons.

Why just coding is not enough

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

But why code is not enough. Again, an example from the first job - I had to change something, I approached my colleagues and talked about it, they answered that they were busy. And my sprint is on fire. And there is no one to help. As a result, I began to understand myself in additional competencies.

Suppose you have some good skill, for example, working with CI / CD. The designer gave you a layout and went on vacation, you had a couple of edits or questions, but until he comes back from vacation, that's all, 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 am not talking about completely replacing a specialist, I’m talking about basic skills.

findings

It is useful to approach the case as an engineer. Even if the work is not of an engineering nature. It allows you not to thoughtlessly implement everything, 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 .Net-development and a simple task for him, to pee 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 confidence that we need it. In the end, everything that he did made us spend a lot of time on additional synchronization, and then it all went to the garbage in fact anyway. Just because of the basic problems of communication. Do not do it this way.

Well, the list of useful books:

• Systems 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 viewed here .

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