Привет! Меня зовут Олег, и я frontend-разработчик в Альфа-Банке. Я хочу рассказать вам немного философскую историю — про инженерный подход к разработке, про мою первую работу и грабли, которые я там собрал, про то, почему чеклисты очень важны (и спасают жизни).

А еще про то, как продолжать продуктивно работать и не закопаться во множестве мелких и не очень задач.

Всё началось с хаоса.

На моей первой работе (не Альфа, нет) меня как-то взяли и сразу бросили на амбразуру, сказали, парень, теперь ты делаешь CRM, комп вон там. Что делать и как делать — я вообще не понимал. Что обычно делают в такой ситуации? Правильно — бегут к коллегам и начинают уточнять у них, как тут на сервак код доставить, как дела с гитом, какие практики используем, а какие нет, и прочее. Мне такой подход помог, и я постоянно советую делать это и другим. Спрашивайте, задавайте вопросы, даже если кажутся вам очевидными, уточняйте то, что надо уточнять. Это нормально. Ненормально — не спрашивать.

Следующим моим шагом было использование книг. Потому что когда я назадавал вопросов и наполучал ответов вида «Юзай линтеры» я поймал себя на мысли, что знаю, как именно всё это делать, но не совсем понимаю — зачем. Мне было искренне интересно узнать, откуда ноги растут во всех процессах, и я решил искать помощи в книгах. «Чистый код», «Совершенный код» — в общем, я пошел по стандартному набору, где рассказывают о том, что функция не должна быть длиннее 30 строк. Сразу скажу, разобраться во всем и контролировать хаос это не помогло.

Да, я стал заметно чище писать, но хаос в виде кучи задач, которую я не мог нормально разгрести, никуда не делся. Коллеги решили помочь мудрым советом вида «Чувак, тебе просто не хватает эджайла, давай ты тут почитаешь еще и про эджайл и всё круто будет у тебя, если что ещё и скрам-мастера дадим».

Ну да. Эджайл сам по себе штука хорошая. Но когда ты в команде работаешь. А эджайл в одно лицо это немного странно. Я начал копать дальше, нашел книги по кайдзену. А потом я встретил теорию ограничения систем и книгу «Цель». Многие наверняка её читали, поэтому я вкратце просто отмечу, что один из главных посылов тут — не улучшай всё везде и сразу, а сначала найди одну проблему и пофикси её. Пофиксил — ищи следующую и фикси её. Автор пришёл к этому через инженерные подходы, ведь инженеры примерно так и поступают — ищут проблему и решают её.

Ладно, это лирика, давайте поближе к практике.

В жизни

Допустим, у вас есть какой-то сферический процесс в вакууме, в котором есть дизайнер, фронтендер и тестировщик. Дизайнер рисует макеты и кнопочки в течение одного дня, фронтендер за три дня с этим работает, а тестировщику надо два дня. Вроде бы схема простая и сразу понятно, где надо улучшать процесс — на фронтендере, потому что его работа занимает больше всего времени. То есть смысл оптимизации в нахождении самого медленного этапа в процессе.

Но это простой пример с тремя переменными. Само собой, в работе часто бывает иначе. И сильно иначе. Процесс усложняется, когда у вас появляются бэкенд, документация, CI/CD и прочие важные штуковины.



И тут уже не получится сходу взять и сказать, какой процесс самый медленный и с чего стоит начинать. Здесь процесс оптимизации самого медленного этапа будет выглядеть так:

1. Надо найти ограничение, самое медленное.
2. Решить, как максимально его использовать.
3. Подчинить всё принятому решению.
4. Развить (расширить) ограничение.
5. Вернуться назад и повторить.

Может звучать сумбурно, поэтому распишу подробнее.

Что делать, есть у вас есть какие-то параллельные задачи, которыми вы заняты?



В этом случае самый длинный маршрут вы будете искать по дням суммарно. На картинке выше это примерно 6 дней. Начинайте с него, с этого самого длинного процесса. Получается, что вы в этом примере будете улучшать бэкенд, потому что он занимает 4,5 дня. Это тоже не так сложно, но когда вы к этому приходите и начинаете так делать, замечаете, что жить становится проще.

Вернусь к примерам о своем рабочем хаосе. Мне прилетала куча задач и я ничего не успевал. Я понял, что имеется ограничение во фронтенде (то есть во мне), что проблема не в тестировщике, потому что он баги находит, а именно на моей стороне. Чтобы что-то с этим делать, я стал думать, как использовать это ограничение.

И решил, что надо поменять процесс так, чтобы была только одна точка входа — один человек, принимающий решения насчет того, будем мы делать задачу или нет. Потому что были случаи, когда приходил один человек и говорил, Олег, нам вот тут кнопку надо передвинуть чуток правее. А потом еще один. А через полчаса кто-то еще с подобной задачей. И вроде кажется, что мелочи и фигня, а в итоге я зашивался напрочь, пытаясь всем угодить.

Сейчас я стараюсь делать не больше 2 задач параллельно (параллельно, а не одновременно). Раньше я мог дать тестировщику задачу и пойти делать следующую, но если тестировщик находил баг, мне приходилось делать чекаут, вспоминать и переключаться на то, какой код там был написан, а это тяжелее, чем кажется, когда ты часто переключаешься. Да и в целом переключение дорого обходится. Старайтесь не делать более 2 задач параллельно. 3 задачи это вот уже способ зашиться.

Давайте подумаем насчет того, как подчинить все остальное принятому решению. Вроде, звучит логично, да, что если задач и так много, то не нужно накидывать с горкой? К примеру, вы ожидаете, что человек сделает за три дня три примерно равные по сложности задачи. Если за два дня из трех он сделал только одну задачу, скорее всего, он и так не укладывается в план, поэтому кидать ему еще задачи сверху это немного демотивирующая штука.

Ещё про ограничения

Само собой, ограничения можно расширить. В нашем примере — нанять еще одного фронта. Тоже логично, больше фронтов — больше задач они успеют сделать. Тогда ограничение перенесется в другое место.

Есть еще подход, при котором расширяют не количество единиц, а их компетенции. У меня есть живой пример — тестировщик мог бы помогать мне во фронтенде, если бы знал фронтенд. У моего коллеги скрам-мастер начал самостоятельно писать фронтенд, потому что ему было интересно, он там с огоньком делал какие-то фичи, и ему весело, и команде помогало. Я не призываю делать это у себя, потому что результат может быть очень разный, но как пример, что такой подход есть — да, и он иногда работает.

Чеклисты

Чеклисты реально помогают делать жизнь проще. В моей работе сейчас очень помогает вот этот чеклист для Альфа-Банка, где довольно много этапов, которые надо пройти.

Чеклисты даже жизни спасают, я приведу небольшой отрывок из книги «Понимать риски. Как выбирать правильный курс»:

На заре авиации пилоты летали на самолетах, которые не были так оснащены техническими средствами, как в наши дни. Чек-листы стали использоваться в ВВС США только после того, как выяснилось, что бомбардировщик В‑17 – слишком большой самолет и не может управляться только одним человеком. В 2009 г., когда сразу после взлета из аэропорта Ла Гуардия у самолета US Airways рейс 1549 заглохли оба двигателя, пилоты выполнили все предусмотренные чек-листами действия в такой аварийной ситуации, включая и попытку повторного запуска двигателей. Бортпроводники, опять же в соответствии с чек-листами, строго следили за правильной подготовкой пассажиров к аварийной посадке. Подобные чек-листы – простой и недорогой инструмент повышения безопасности.

В медицине наблюдается другая картина. Ежегодно некорректное использование центральных венозных катетеров вызывает приблизительно 80 тыс. случаев инфицирования кровотока, и в результате около 28 тыс. человек умирает в реанимационных отделениях американских больниц. А те пациенты, которым удается выжить, проводят в реанимации в среднем дополнительно еще одну неделю. Общие затраты на лечение подобных инфекций оцениваются в 2,3 млрд долларов в год. Что может спасти этих людей? Более совершенные лекарства для лечения инфекций, более совершенные технологии? Ответ таков: совершенствование культуры ошибок.

В 2001 г. Питер Проновост из больницы имени Джона Хопкинса составил простой чек-лист для врачей реанимационных отделений, чтобы проверить, способен ли комплекс этих мер снизить распространение инфекции. Вот как выглядят пять последовательных шагов, призванных предотвратить попадание опасных бактерий в организм пациента:

1) вымыть руки с мылом;
2) обработать кожу пациента хлоргексидиновым антисептиком;
3) накрыть пациента стерильной простыней;
4) носить стерильную маску, шапочку, фартук и перчатки;
5) наложить стерильный материал поверх катетера после введения катетера в вену.

В этом списке каждая из защитных мер была хорошо известна, в нем не содержалось ничего нового. Проновост попросил медсестер, работающих в его отделении интенсивной терапии, понаблюдать, выполняют ли врачи эти 5 правил. Медсестры сообщили, что при установке катетера более чем трети всех пациентов одно или несколько из этих правил не соблюдались. Показатель инфекционного заражения кровотока в больнице составлял на тот момент 11 %.

Проновост убедил администрацию больницы разрешить медсестрам останавливать врачей, если те пропускали какую-либо из предписанных пяти мер. Это революционное новшество нарушило иерархическую структуру, в которой средний медицинский персонал (преимущественно женщины) прежде не имел права давать указания врачам-хирургам (преимущественно мужчинам). Через год, на протяжении которого строго соблюдались эти инструкции, показатель инфекционного заражения кровотока у пациентов больницы снизился с 11 % до 0 (!). А в течение следующих 15 месяцев было отмечено всего 2 случая такого заражения. Только в одной этой больнице список инструкций предотвратил 43 случая заражения, 8 смертей и сэкономил 2 млн долларов.

Чтобы показать, что эффект от использования карты контрольных проверок не ограничивается его больницей, Проновост убедил более сотни отделений интенсивной терапии в штате Мичиган принять участие в масштабном совместном исследовании. Важно отметить, что в каждом из них разрабатывался собственный перечень действий, наиболее соответствующий его культуре.

Участвовавшие в исследовании отделения интенсивной терапии сообщали, что ранее у них наблюдалось суммарно 695 случаев инфекционного заражения кровотока из-за использования катетеров. Всего 3 месяца спустя после начала использования чек-листов в большинстве отделений показатель инфицирования пациентов упал до нуля. Остальные отделения интенсивной терапии также сумели значительно снизить этот показатель за те полтора года, в течение которых проводилось исследование. Эта масштабная программа по спасению человеческих жизней была реализована без использования дорогих технологий и без увеличения численности персонала больниц.

То есть каждый из этих пунктов был известен, это не какая-то новинка или что-то ещё. Питер просто оформил это в формате чеклиста и сделал его обязательным. Всё.

Мы стараемся улучшать не только свои результаты, но и результаты других, поэтому постоянно допиливаем наш рабочий чеклист. Если я вдруг в процессе что-то забыл и не сделал, я вношу это в чеклист, чтобы не забыть в следующий раз. Раньше дизайнеру часто возвращали макеты на переделку, хотя он говорил, что сразу все понял и сделает как надо, и после такого он просто попросил у нас чеклист, я скинул ему кусок именно по дизайну, и стало попроще.

Свой чеклист я отсортировал по действиям — 1 действие = 1 пункт чеклиста. Здесь главное тоже не упороться совсем сильно и не уйти в чеклисты ради чеклистов. «Сверстать страницу» — хороший пункт. «Сверстать контролы» — еще подробнее, поможет не забыть про контролы и их нюансы.

Чеклист может быть иерархическим: сверстать страницы -> сверстать формы -> сверстать кнопки.

Почему просто кодить недостаточно

Тесты нужны. Но нужны не всегда. К примеру, делаете вы лендинг, один раз, и не планируете к нему потом возвращаться — тогда тут нет смысла очень сильно упарываться. Можно покрыть юнитами селекторы или использовать end2end, но юнит-тесты для остального это уже трата времени.

А вот почему кодить недостаточно. Опять же пример с первой работы — надо было мне поменять что-то, я подходил к коллегам и говорил об этом, они отвечали, что заняты. А у меня спринт горит. А помочь некому. В итоге начал разбираться сам в добавочных компетенциях.

Допустим, у вас есть какой-то хороший скилл, например, работа с CI/CD. Дизайнер дал вам макет и ушел в отпуск, у вас возникла пара правок или вопросов, но пока он не вернется из отпуска, все, процесс стоит. Расширяйте свои скиллы, потому что если слабое место в процессе будет на стороне дизайна, ну зашивается дизайнер по ряду причин, вы сможете ему помочь. Это дополнительный набор знаний, но его можно осилить. Само собой, я сейчас не говорю о том, чтобы полностью и полноценно заменять специалиста, я про базовые навыки.

Выводы

Полезно подходить к делу как инженер. Даже если работа у вас не инженерного характера. Позволяет не внедрять бездумно все подряд, а находить проблему и внедрять только то, что способствует ее решению.

Нужно общаться и обсуждать решения. Коммуникацию в принципе трудно переоценить. Иногда проблемы возникают из-за так называемой молчаливой инициативы. У нас был случай, когда нам дали .Net-разраба и простую задачку для него, пописать тесты. Он быстро написал всё, тесты, юнит-тесты, селекты, а потом зачем-то начал делать что-то сверх того, что было в задаче. Видимо, в уверенности, что нам это пригодится. В итоге всё то, что он сделал, заставило нас потратить кучу времени на дополнительную синхронизацию, а потом всё это все равно пошло в помойку по сути. Просто из-за базовых проблем коммуникации. Не надо так.

Ну и список полезных книг:

• Теория ограничения систем (E. Goldratt)
• Critical chain project management (E. Goldratt)
• Гемба кайдзен — путь к снижению затрат и повышению качества (М. Имаи)
• Agile-менеджмент: Лидерство и управление командами (А. Юрген)
• Extreme Programming Explained (K. Beck)

Подробную презентацию можно посмотреть тут.

Используете ли вы чеклисты, считаете их необходимыми? Если у вас какой-то свой подход к ведению или созданию чеклиста, поделитесь в комментариях, пожалуйста.