Притчи для падаванов

Ну что-то же нужно делать!

Гена с Чебурашкой опаздывают на поезд. Поезд уже отошёл, набирает скорость. Они что есть сил бегут за ним с чемоданами по перрону, кричат. Уже понятно, что не успеют.

И тут Гена бросает чемоданы и с размаху бьёт Чебурашке в бубен.

– Гена, за что?!

– Но ведь надо же что-то делать!!!

У меня был разработчик – назовём его Костя – который в спокойной обстановке работал нормально. Но стоило появиться давлению – сроки горят, все ждут результат, руководство нервничает – он начинал делать то, что я называл «биться головой о клавиатуру».

Появился баг – сервер в какой-то момент начинал жёстко грузить. Улетал по памяти, каскадная нагрузка, всё ложилось. Раньше не грузило, теперь грузит – фиг знает почему.

И вот что делает Костя. Смотрит на код, находит метод, который кажется ему подозрительным, переписывает и запускает нагрузочное тестирование. Тест идёт полтора-два часа. Результат – не помогло. Берёт другой метод. Переписывает. Два часа. Не помогло. Подключает коллегу – теперь они вдвоём сидят и переписывают всё, что кажется большим или подозрительным. Без гипотез, без логики – просто «ну вот это выглядит стрёмно, давай перепишем».

Четыре дня. Два человека. Я это называю monkey development – как monkey testing, только вместо тыканья в интерфейс ты тыкаешь в код наугад.

Сел с ними, говорю: окей, давайте попробуем по-другому. Раньше не грузило – теперь грузит. Значит что-то изменилось, правильно?

Откатились по коммитам до момента, где всё работало. Проверили – работает. Дальше даже думать не надо – тупое половинное деление. Коммит посередине – работает или нет? Нет – первая половина. Да – вторая. Ещё раз пополам. Ещё раз.

Минут через сорок нашли конкретный коммит, конкретный метод, который всё положил.

Сорок минут. Против четырёх дней двух человек.

И я понимаю, почему так получилось. Баг есть, прод страдает, все нервничают. Сидеть и думать – это как будто ничего не делаешь. А переписать метод и запустить тест – это действие, это прогресс, это можно на дейли сказать «мы работаем, проверяем гипотезы». Только это не гипотезы. Это Гена бьёт Чебурашку. Поезд-то уже ушёл, но надо же что-то делать.

Всё стадо

Стоят на холме два быка – старый и молодой. Внизу проходит стадо коров. Молодой пихает старого под бок:

– Ну давай, ну давай быстренько сбежим с холма! Вон ту, молоденькую, видишь? Или вон ту, стройненькую! Ну давай, быстренько!

Старый бык долго слушает, качает головой и говорит:

– Нет. Мы медленно спустимся с холма и медленно покроем всё стадо.

У нас был сервис с чатами. Личные сообщения, групповые чаты – всё стандартное. И в какой-то момент посыпались баги, связанные с прочитанностью сообщений. Сообщение показывается непрочитанным, хотя ты его открывал. Или наоборот – прочиталось, а потом снова стало непрочитанным. Или в группе показывает три непрочитанных, открываешь – а там пусто.

И каждый раз ребята реагировали как молодой бык. Прибежал баг – побежали чинить. Пофиксили. Через неделю новый баг – опять побежали. Потом ещё один. И ещё. Каждый раз – реактивно, каждый раз – точечный фикс конкретной проблемы.

А проблемы не кончались. Потому что каждый фикс – это ещё одна заплатка на франкенштейне.

Система сообщений когда-то писалась наспех. Просто чтобы работало. И для простых чатов – работало нормально. Но потом появились групповые чаты. Потом каналы. Потом треды. Потом супер-чаты с топиками. Каждую новую фичу прикручивали к старому фундаменту, который на неё не был рассчитан. И фундамент начал трещать.

В какой-то момент я понял: мы молодые быки. Бегаем с холма за каждой коровой, а стадо уходит.

И мы остановились. Сели. Разобрались, как вообще должна работать механика прочитанности – в личных чатах, в группах, в каналах, в тредах. Не как она работает у нас, а как она должна работать в принципе. Посмотрели, как это устроено архитектурно. Продумали data-модель. Нарисовали, как это должно выглядеть на концептуальном уровне.

А потом сравнили с тем, что у нас есть.

И стало понятно, что проблема – не в багах. Баги – это симптомы. Проблема в том, что архитектурно всё было сделано неправильно с самого начала. Из говна и палок, как водится. И никакое количество точечных фиксов это не спасёт.

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

Самое сложное было – не дёргаться. Баги сыпятся, все нервничают, а ты сидишь и рисуешь data-модель. Но старый бык на то и старый, что умеет не дёргаться.

Шлюх менять, а не кровати

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

– Сынки, а чего это вы делаете? Переезжаете?

– Не, бабуль, мебель расставляем по фэншую. Когда всё правильно расставим – сразу выручка вырастет!

Бабушка качает головой:

– Сынки, я тут давно работаю. Ещё до революции это здание убирала. А был тут раньше публичный дом. И когда у них падала прибыль – они кровати не переставляли. Они сразу девочек меняли.

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

Ну и что делать? Можно писать регламенты, договариваться о правилах, внимательнее ревьюить. Короче, двигать кровати.

Посмотрел я на это и думаю: не, так не пойдёт. Проблема же не в том, как мы работаем. Проблема в самом коде.

Взяли и сделали большой рефакторинг – перевели приложение на реактивный подход, на RxJava. Это когда события в одном месте вызывают реакции в других, но без жёсткой связки. Каждый кусок сам по себе, хочешь данные – просто подписываешься.

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

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

С командами, кстати, бывает похоже.

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

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

Жёстко? Ну да. Но иногда проблема не в процессах, а в том, кто работает. И тут уж сколько мебель ни двигай – не поможет.

Я не тактик, я стратег

Жили-были мыши. Все их обижали. Однажды пришли мыши к сове:

– Мудрая сова, помоги! Все нас едят. Скоро нас совсем не останется. Что делать?

Подумала сова и говорит:

– Мыши! Станьте ежами. Будете колючими – и для охотников недоступны.

Побежали мыши радостно: станем ежами! станем ежами! Вдруг одна остановилась:

– А кто-нибудь знает, как стать ежами?

Никто не знает. Побежали обратно к сове:

– Сова! А как нам стать ежами?

– Мыши, идите на хер. Я не тактик, я стратег.

Сидим на совещании. Мы, представители другого департамента, и наш руководитель. Обсуждаем критически важную штуку – от неё зависит следующий квартал, а может и два.

Проблема простая: нам нужно что-то от второго департамента. Мы от них зависим, а они от нас – нет. Мы для них просто одна из нагрузок.

И вот мы сидим, приводим аргументы. Логичные, разумные – руководитель их до этого полностью разделял, на всех прошлых встречах кивал, говорил «всё правильно, давайте так». А ребята из второго департамента включают режим «ничего не слышу, ничего делать не буду». Без аргументов, без объяснений, просто – нет и всё.

Их руководителя на встрече нет. Наш – есть. Он всё слышит, видит что вторая сторона вообще не готова разговаривать. И в какой-то момент встаёт и говорит:

– Ну ладно, мне пора. Разбирайтесь, это ваша проблема. Потом расскажете, как решили.

И уходит.

А у нас нет никаких механизмов влияния на второй департамент. Вообще никаких. Единственный способ – эскалировать на уровень руководителей. Для этого и нужен был наш руководитель на этой встрече. А он встал и ушёл.

Мыши, станьте ежами.

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

Ну вот так. Стратегия была – «вы должны договориться». А как договориться, когда у тебя нет ни полномочий, ни ресурсов, ни доступа к тем, кто может решить вопрос – это уже тактика. А он не тактик.

Я потом думал, а что вообще можно было сделать. Ну смотри: если люди просто саботируют процесс без аргументов – это же история про «менять шлюх, а не кровати». Рыба гниёт с головы, значит проблема в руководителе того департамента.

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

Второй вариант – менять своего руководителя. Потому что если он в такой ситуации умывает руки, то он и дальше будет умывать.

Оба пути ведут к тому, что надо лезть через голову. А я не очень люблю такие игры.

Если честно, хорошей стратегии у меня нет. Так что если кто знает – расскажите.

Яма с крокодилами

Ты хочешь познакомиться с девушкой. Она стоит в десяти метрах от тебя. Между вами – яма с крокодилами.

Если ты прыгнешь на два метра – тебя съедят. На пять – съедят. На девять восемьдесят – тоже съедят. Крокодилам плевать, как близко ты был. Не долетел – значит не долетел.

Но и прыгать на сто метров тоже не надо. С той стороны хорошая лужайка, стоит скамейка, сидит девушка. Десять метров – ровно столько, сколько нужно.

В 2006 году Yahoo договорилась купить Facebook за миллиард долларов. Цукерберг согласился. Оставалось подписать. И прямо на подписании CEO Yahoo сказал: «Нам придётся заключить сделку за 850 миллионов, а не за миллиард».

Сэкономили 150 миллионов. Цукерберг промолчал и ушёл. Сделка не состоялась.

Через несколько лет Facebook стоил сотни миллиардов. Yahoo в итоге продали по запчастям. Прыжок на 9.80. Крокодилы не оценили.

И это был не единственный раз. Yahoo присматривалась к LinkedIn, Twitter, YouTube – и каждый раз не допрыгивала. Не важно, сколько попыток ты сделал и сколько денег сэкономил по дороге. Важен только результат: ты на той стороне или нет.

Но есть и другая сторона этой истории. Прыжок на сто метров.

Мы с ребятами когда-то делали стартап. Мне нужно было написать бэкенд, и я выбрал Elixir. Мощный язык, построен на Erlang VM, держит безумные нагрузки. Я сделал бэкенд, который мог бы обслуживать тысячи одновременных пользователей. Архитектура – космос.

А потом мы пошли продавать. И оказалось, что это нахер никому не нужно.

Ноль пользователей. Бэкенд, который держит бесконечную нагрузку, при нагрузке ноль. Красивый, мощный – и абсолютно бесполезный.

Правильнее было сделать лендинг. Просто лендинг. Проверить, готов ли вообще кто-то за это платить. И только когда убедились – писать бэкенд. Это были бы те самые десять метров. А я прыгнул на сто – приземлился далеко за лужайкой, в чистом поле, где никого нет.

И вот тут важная мысль, которая часто теряется за яркостью метафоры: не обязательно прыгать вообще. Можно пройти сто метров вправо и обойти яму. Можно попросить друга с вертолётом. Можно найти мост.

В IT это работает буквально. Сидишь, куришь мануалы, пытаешься разобраться сам – это прыжок через яму. А можно пойти к тому, кто в теме, и спросить. «Бери вот это решение, а вот это не бери». Пять минут разговора – и ты на той стороне без прыжка.

Есть психологический тест – «пустыня». Ты идёшь по пустыне, перед тобой стена, за ней оазис. Опиши стену. И большинство людей описывают что-то непреодолимое – бетон до неба, колючая проволока, бесконечная в обе стороны.

Но это же стена в твоей голове. Не обязательно её перелезать. Можно сломать. Обойти. Сделать подкоп.

Крокодилы настоящие. Яма настоящая. А вот идея, что единственный путь – это прыжок, – она только у тебя в голове.

Вот сила воли!

Решил мужик бросить пить. Идёт по улице, видит любимый магазин – и думает: а усложню-ка я себе задание. Зайду в магазин, но покупать ничего не буду.

Зашёл. Видит свою любимую водку. Думает: усложняю задание – покупаю, но домой принесу и наливать не буду.

Купил. Принёс. Поставил на стол. Думает: а налью-ка я, но пить не буду.

Налил. Смотрит. Думает: в рот возьму, но не проглочу.

Отпил глоток… сглотнул.

– Во сила воли! Не хотел же – а выпил!

Фокус этого анекдота в том, что каждая следующая уступка кажется крошечной по сравнению с предыдущей. Ты уже купил водку и принёс домой – ну что такого, если налить? Масштаб отступления уменьшается, а ты не замечаешь, что давно прошёл точку невозврата.

У меня есть история ровно про это. Я уехал в отпуск, а у нас был регламент обновления прода. Простой, понятный, написанный кровью предыдущих факапов. Три правила:

Код-ревью – асинхронно. Ревьюер не имеет права сесть рядом с автором и спросить «а чё тут?». Вся коммуникация через комментарии к коду. Потому что когда тебе объясняют голосом – ты киваешь. А когда читаешь молча – вынужден реально вникать.

Перед продом – обязательно обновляем тестовый стенд и проверяем.

Прод обновляем в нерабочее время, желательно под выходные.

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

Ревьюер сел рядом с автором. Ну а что такого? Так же быстрее. Покивал, апрувнул.

Тестовый стенд не завёлся. «Ну он же неполный, на проде-то точно заведётся». Мы ведь уже код отревьюили – чего время тратить.

Обновили прод в понедельник. Днём. В пик.

Сглотнул.

Прод лёг полностью. Пока откатились, пока разобрались – три-четыре рабочих дня недоступности. Катастрофа.

Выхватил за это я. Моя зона ответственности. Неважно, что был в отпуске, неважно, что лично ничего не деплоил. Регламент мой, команда моя – значит и факап мой.

И ребята – не раздолбаи. Они не проснулись с мыслью «забьём на правила». На них давили, сроки горели, а человек, который установил регламент, – где-то на Алтае. Нужна серьёзная стойкость, чтобы в такой момент выбрать регламент, а не начальство.

Но вот в чём штука: они проиграли не когда обновили прод в понедельник. Они проиграли, когда сели рядышком на код-ревью. Это была дверь магазина. Дальше – просто инерция.

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

Поймал лоха, бей до смерти

Фраза так себе, конечно. Зато запоминается.

Услышал её у Дмитрия Гоблина Пучкова и решил попробовать. Можно было бы говорить «конец – делу венец» или «цыплят по осени считают». Но от классики почему-то в одно ухо влетает, в другое вылетает. А вот эту фразу ребята запомнили сразу. Ну и ладно, работает – и хорошо.

Была у меня команда, и там как-то само собой сложилось. Один разработчик – назовём его Петя – берёт задачу, копается в ней пару недель. Разбирается в требованиях, смотрит код, пишет что-то. Уже вник, уже контекст в голове.

И тут его дёргают на что-то срочное. Петя передаёт задачу коллеге – назовём его Вася – типа, там немного осталось, доделай.

Вася открывает – а там ничего не понятно. Код написан по-своему, логика была в голове у Пети. Вася садится разбираться. Неделя-полторы уходит просто на то, чтобы понять, что тут вообще происходит.

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

А один раз у нас задача перешла от человека к человеку три раза. Там отгул, тут срочное, здесь ещё что-то. Три передачи. Это было что-то с чем-то.

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

Вот тогда и появилась эта фраза. Поймал лоха – бей до смерти. Взял задачу – доделай. Не переключайся, не передавай. Сначала закончи, потом берись за новое.

Как-то прижилось. Ребята стали доводить задачи до конца. Может, фраза яркая, может, просто надоело по три раза вникать в одно и то же – не знаю. Но работает.

Отложенная игра

«Отложенная игра в конечном итоге становится хорошей, а поспешно выпущенная игра навсегда остаётся плохой.»

Это сказал Сигэру Миямото – человек, который придумал Mario и Zelda. Уж он-то знает, о чём говорит.

В играх это особенно больно видно. Вот Cyberpunk 2077 – ждали годами, хайп был невероятный. Выпустили сырым. На старых консолях вообще не работало, баги повсюду. Потом несколько лет патчили, вытягивали, переделывали. Сейчас игра уже нормальная. Но ярлык «кривой релиз» приклеился намертво.

No Man’s Sky – та же история. На релизе – разочарование. Обещали одно, получили другое. Команда потом героически вытаскивала игру несколько лет, добавляла контент, чинила. Сейчас хвалят. Но сколько людей так и не вернулись, потому что первое впечатление было – обман?

С играми особенно жёстко, потому что релиз часто одноразовый. Это не мобильное приложение, где можно тихо выкатить апдейт. Люди покупают, играют, составляют мнение. И если первое впечатление – «это сыро», то всё, поезд ушёл.

В обычном IT вроде попроще. Но это только на первый взгляд.

Есть такая штука – релиз-трейны. Это когда ты выпускаешь продукт регулярно, например раз в неделю. Но фишка не в том, чтобы быстро выкатывать и быстро чинить. Фишка в другом.