Дневник фронтенд-разработчика

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

Дейли

13 февраля, 10:58 — Начало рабочего дня

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

13 февраля, 11:00 — Дейли

Как обычно, собрались в Зуме на дейли. Большая часть сотрудников компании работает на удаленке, многие распределены по разным городам, так что по-другому поддерживать постоянную связь сложно. Приятным бонусом к созвонам идут домашние животные коллег: у одного парня кот сидит на плече на каждом дейлике — видимо, следит за выполнением задач. Кстати, о задачах… 

У меня большая продуктовая команда из 13 человек: 8 разработчиков, 2 QA-инженера и 3 менеджера. Рассказ каждого о себе и своих делах неэффективен, поэтому на дейликах мы говорим о задачах в порядке приоритета. Такая методика давно доказала свою эффективность: наши дейли длятся не больше 15 минут, за которые все участники встречи успевают осознать общий прогресс работ. 

Сегодня мы начали разговор с новой задачки наверху доски: оказалось, что на проде вылез критичный баг и приложение крашится. Наш android-разработчик оставил другие задачи, чтобы все починить.

Постепенно спустились по доске ниже. Оказалось,

Удалить старую реализацию и при необходимости абстракцию.

Вот она, сила замены колес прямо на ходу, да еще и за пять шагов! Но переделывать свой уже открытый MR я, конечно, не буду.

15 февраля, 16:04 — Ревью

Кажется, это было ошибкой.

15 февраля, 16:58 — Все еще ревью

Мое счастье, что такой большой MR вообще согласились посмотреть. Но количество комментариев… Мама, забери меня на ручки, погладь по голове и скажи, что я все сделал правильно.

Конечно, все комментарии справедливые и даже полезные. Инициатива с кросс-командным ревью — хороший способ обмена экспертизой и получения нового опыта и насмотренности. Но палка о двух концах: комментарии-то, может, и полезные, но ради аппрува разработчика из другой команды нужно тратить время на доработки. А бывает, что ребята заняты и не могут посмотреть MR в ближайшее время и он так и висит.

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

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

А мой MR на 600 строк к таковым пока не относится, поэтому пойду дальше читать комментарии к нему и исправлять их… 

15 февраля, 17:04 — ████████████ комментарии

В смысле «это можно было уложить в две строки вместо 50»?! [ДАННЫЕ УДАЛЕНЫ]

3 амиго

20 февраля, 14:00 — Три амиго по [фиче]

Почти закончили текущую фичу, а значит, пришло время обсуждать спецификацию по следующей. А это значит…

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

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

Когда-то я ныл, что мне платят за код, а не за отсиживание пятой точки на бесконечных созвонах. Но сейчас понимаю, что три амиго — полезная встреча, пусть порой и слишком частая. Лучше я потрачу пару часов в неделю на высказывание своего «фи» дизайнеру конструктивную критику по спеке, зато сэкономлю гораздо больше времени уже во время разработки, потому что в спеке будет отображена реакция приложения на каждый возможный чих пользователя.

Пока я размышлял о высоком, дизайнер опять решил, что я рожден красить кнопки и не увижу, что его █████████ нереализуем. Настало время заняться конструктивной критикой…

Дежурства

22 февраля, 15:17 — Алерт! Алерт! Алерт!

Сидел, писал код, никого не трогал… Вдруг — бум! Прод немного взорвался, и посыпались алерты к нам в канал. 

Знаю-знаю, «фронтендер на дежурстве» — звучит как начало какого-то анекдота. Но я и в самом деле должен буду разобраться с этими алертами. 

Наши бэкенд-разработчики регулярно дежурят в нескольких каналах по разным вопросам. Так что мы решили хотя бы частично снять с них нагрузку и дежурим в канале с алертами, которые выявляются по нашим метрикам.  

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

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

Что сейчас и требуется доказать.

22 февраля, 15:50 — ЧТД

Просмотрел инциденты, удостоверился по графикам, что они действительно случились, и полез в логи нашего бэкенда. Исследовал несколько запросов, по самым длинным начал искать причину проблем на проде. Из логов нашел URL, ответы с которого были самыми долгими, сопоставил его с сервисами других команд и выяснил виновную систему. Сходил к ребятам в [другую команду] и надавал им по шее эскалировал проблему. 

Словом, чуть больше 20 минут моего времени — и проблема решена. Делов-то.

Планирование

24 февраля, 13:00 — Планирование

Очередной цикл двухнедельной разработки подходит к концу, а значит, настало время планировать дальнейшую работу. 

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

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

Что более важно, с переходом карточки в колонку «Запланировано» начинает тикать таймер LeadTime — того, сколько времени занимает разработка задачи от старта и до окончательной доставки на прод пользователям. Потом мы собираем статистику по этому значению, а по нему и ряду других метрик анализируем все наши рабочие процессы, пытаясь найти в них узкие места или какие-то проблемы. 

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

Ретроспектива

27 февраля, 16:00 — Нытинг

Древние пророчества из архивных каналов Слака гласили: «Придет век Зума и Конфлюенса, век Задач в Джире. Придет Час Вечернего Созвона и Доски на Miro, Час Безумия и Час Презрения, Час Конца. [Команда] умрет, погруженная в задачи, и возродится вместе с новым разработчиком». 

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

От слишком горького кофе в офисе до непроработанных требований к последней задаче — в телеграм-канале и публикуем вакансии в формате дайджеста.