January 6, 2021

Женя Пешков

Интервью с новым техлидом Вторички Циан.


Наше знакомство состоялось в сентябре 2020 года на конференции Russian Python Week. Женя пришел на доклад моей секции про DDD – он просто не мог не посетить такое тематическое событие. Так и узнали друг друга.

Но тогда еще никто и не подозревал, что скоро нам предстоит поработать вместе.

Мы встретились с Женей в кафе и поговорили о нем, о его команде, о его увлечениях, об IT, о разработке и о том, что в первую очередь хочется сделать на новом месте.


Ты разработчик?

Я из Dot Net’а.

Большая у вас команда в Додо?

В IT примерно 100 человек сейчас.

А твоя команда?

Мы сейчас объединились, стало 12 человек.

Чем ты там занимаешься?

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

Ты тимлид?

Тимлид / техлид – у всех разные названия этих ролей.

В Додо запустили эксперимент. Теперь у нас есть отдельная роль People Lead. Он помогает людям расти, снимает какие-то боли, изучает запросы. У нас нет явных тимлидов. Тимлид – это ведь зачастую просто погоны. У нас тимлид ближе к футбольной метафоре, его можно сравнить с капитаном футбольной команды. Он не руководитель.

Мы долгое время шли по пути скрам-мастерства. У скрам-мастера есть процессная часть и есть часть про людей. Отсюда возникли две роли: Process Lead и People Lead. И оба они без каких-либо формальных погон. Ты этим занимаешься и все, тебе не дают какие-то дополнительные полномочия.

Проблемы здесь общие для индустрии. В команде все айтишники: программисты, тестировщики, без каких-либо навыков коучинга, менторинга, еще чего-то. People Lead’ом назначали тех, кому хочется это попробовать, тех, кто до этого брал на себя роль скрам-мастера.

Кто у вас ДСМ проводит?

Команда сама проводит. На самом деле команде не нужен лидер. Лидер – это тоже роль. И в идеале она размазана по команде. Соответственно, ДСМ больше проводил я как Process Lead, но если что, все соберутся без меня, и я это знаю. Если я в отпуск уйду – ДСМ все равно проходит. Есть примерный формат и он всем привычен. Люди по такому формату идут, даже если я отсутствую.

Как вы пришли к самостоятельности?

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

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

Мантра: начинайте завершать, заканчивайте начинать.

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

Это все так или иначе вытекает из теории ограничений, Lean. Мы не делаем работу впрок. Возможно она отменится потом. Но в IT все же есть небольшое отличие. Голдратт говорил про физическое производство, а мы говорим про умственный труд (knowledge worker). Отличие в том, что у нас цена отмены ниже. В производстве машина если начиналась делаться, она как правило доделывалась, посередине редко кто приходил и говорил, что нам это не надо. В IT такое случается, и поэтому у нас бутылочное горлышко выгоднее размещать ближе к концу цепи, хоть это и немного контритуитивно. Почему ближе к концу? Чтобы максимально эффективно его утилизировать. У нас также как у Голдратта производительность системы определяется бутылочным горлышком, и получается, что через бутылочное горлышко должны проходить задачи, которые точно пойдут на прод. Например, у нас есть какой-нибудь архитектор один на всех, он обязательно должен сделать код ревью, и его на всех не хватает. То есть он является бутылочным горлышком. Если архитектор стоит в начале производственной цепи, то он делает 100500 тасок, а потом где-нибудь на тестинге половина из них отменяется. В итоге получается, что все, кто был до этапа тестинга, работали зря.

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

Планирование у нас чуть менее детализировано. У нас нет каких-то жестких коммитов на спринт, в которые мы обязуемся попасть, часто ценой овертаймов. У нас есть еженедельное планирование. В понедельник утром мы накидываем задачи, которые хотим сделать. Это не коммит на неделю, это просто очередь, такой буффер, что точно есть. Продакт кладет свои фичи (карточки) в очередь. Баги берем приоритетом если только реально надо починить – например, деньги теряются. В этом случае баг проходит expedit’ом, это не обсуждается, просто делается хотфикс. Остальные баги – это такие же фичи. Если никто не теряет массово деньги прямо сейчас, то это просто обычная фича, и она будет конкурировать с другими фичами, в том числе продуктовыми.

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

  • кого мы лечим прямо сейчас,
  • кого мы лечим, но чуть позже, и
  • кого мы даже не будем пытаться лечить.

Это немного жестоко звучит, но это дает шанс выжить максимальному количеству, идет оптимизация выживаемости. Потому что если ты будешь в каждого больного инвестировать полное время, то ты с большой вероятностью его не спасешь. И не спасешь тех, кого мог бы спасти. В IT то же самое. Есть ресурс и он ограничен. Все хотелки все равно не сделаешь. Это просто конкуренция за ресурсы. Если новая фича принесет больше value, чем починка старой, то почему она должна уступать?

Техдолг – отдельная история. У техдолга отложенная стоимость. Стоимость задержки плоская, а потом резко взлетает. Cost of delay – это сколько денег ты теряешь оттого, что не публикуешь фичу прямо сейчас. У обычной фичи прямой рост – чем дольше нету какой-то новой фичи, тем больше денег в каждый момент ты теряешь. Есть Fix Date – это, например, когда к 1 января ты должен что-то сделать, иначе ты потом умрешь, или налоговая тебя нагнет на миллионы, или еще что-нибудь случится, т.е. прям сразу потеряешь много денег. До этого момента ты ничего не теряешь, как будто бы ничего не происходит. Если ты бизнес закроешь на ключ к этому моменту, то тебе не надо эту фичу делать вовсе. И есть Intangible – потери средств нету-нету, а потом в какой-то момент выстрелит. И самое плохое в отличие от Fix Date – ты не знаешь, когда это выстрелит. Для тебя это будет полной неожиданностью.

Кто научится работать с техдолгом, тот заработает миллиарды.

В Додо два с половиной года назад случилась такая история. Мы живем себе нормально, продукт развиваем. Первая рекламная кампания. Дали рекламу и легли. Система лежит. Она поднимается и ложится опять. Там есть предел какой-то, который мы просто не выдерживаем. Как только нагрузка переходила порог – мы ложились. Так неделю-полторы жили. У нас потом назвали это военным положением. Собрали всех в офисе, чуть ли не на круглосуточный режим. Насколько человек способен. Без выходных херачили. Выправляли какие-то вещи, которые были на виду.

Как сотрудники на это отреагировали?

Нормально отреагировали.

Чья это была ошибка?

Я думаю, это был как раз пример такого intangible cost of delay. Оно всегда внезапно происходит. Люди не знают, когда техдолг стрельнет им по ногам. Мы до этого экономили. Не умели, не использовали как практику нагрузочное тестирование. Легко говорить постфактум, что нагрузочное тестирование бы нас спасло. Во-первых, оно не бесплатное. Нас многое бы что спасло. Легко говорить после. Талеб много об этом пишет. Если б знал, что случится 11 сентября, ты по-другому бы себя вел. Но если ты начинаешь вести себя по-другому до 11 сентября, на тебя смотрят как на дурака. Ты что, упоротый что ли, куда такие меры безопасности, ничего плохого же не может произойти. Мы и так достаточно хорошо проверяем людей, оружие, еще что-то. Постфактум легко говорить.

Кто взял на себя ответственность за эту ошибку?

CTO. Ну а кому еще брать? Но мы виноватых не ищем. Blameless культура – это про нас. Кто-то и может в шутку накинуть: “я же говорил, что это стрельнет”, но не более того. Писать впрок хайлоад это тоже так себе идея. Если бы ты тогда 8 лет назад писал систему как будто она будет 30-кратный рост выдерживать от прогнозируемого, тебя бы не поняли. Вкладываться чрезмерно в какой-то хайлоад – это неправильно. Все должно быть вовремя.

Как с продактами об этом разговаривать? Порой они скептически смотрят на техдолг.

Потому что нет доверия. В доверии дело. Я помню на Зарплате мы затащили Solr вместо полнотекстового MSSQL’ного поиска. Я рад, что мы это сделали. Очень многое получили. Во-первых, то что плохо работало, стало хорошо работать. А еще там всякие лэндинги наделали, многие вещи для SEO, фасетный поиск. Задача, которая начиналась как техническая, дала жизнь многим продуктовым инициативам. Здесь все доверием решается, мне кажется. Тебе если продакт не верит, что ты не просто жрешь деньги, а делаешь что-то полезное, то он меньше спрашивает. А еще вовлеченность важна. Если человек не вовлечен, не понимает бизнес дальше своей таски, то ему тяжело даже рефакторить. Любой проект можно рефакторить около бесконечности. Я иной раз делаю фичу, цепляюсь, делаю одно, второе, третье, понимаю, что все, уже ушел куда-то, чуть ли не в другой проект и там что-то исправляю. В какой-то момент говорю стоп, это точно не в скоупе. Переделать надо, но не сейчас.

А иногда ты уходишь далеко, но понимаешь, что скоуп близко и затронуть этот кусок нужно обязательно. Эта практика из экстремального программирования по сути. Ты не выделяешь отдельно технические задачи как таковые, просто когда делаешь что-то, ты рефакторишь по пути с бизнес задачей. И такой подход хорошо работает. Да, чуть дольше делаешь. Я, кстати, поэтому коммиты и не люблю, потому что обычно все нюансы вылезают в процессе. Ты не можешь запланировать времени больше или меньше, это будет просто в потолок какое-то среднее, а у тебя разброс очень большой от совсем не надо рефакторить (там все хорошо) до слишком плохо (надо все переделывать).

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

Как дать оценку проекту?

Работающий код важнее всего. Это и во всяких Agile манифестах пишут. Зачастую ты не знаешь сходу, как сделать проект. Оттого, что ты просто скажешь, что знаешь, дело не изменится и оценка точнее не станет. Это будет просто выдавание желаемого за действительное. Если ты делаешь сайты-визитки на тильде уже не первую сотню то да, ты знаешь все. Но когда у тебя какой-то инновационный продукт, ты не можешь знать все. Иногда говорят: “Ну, поисследуйте”. Единственный вариант дать абсолютно точную оценку – это запилить фичу за фича-тогглом и сказать, что я сделаю ее за 1 день. Потом просто включить фича-тоггл. Тогда это будет честная оценка. Сколько ты будешь исследовать? Это опять же просто перекладывание из одного этапа в другой.

Задачи так или иначе кластеризуются. Например, сложные задачи делаются командой 5 дней. Проекты посложнее делаются 20 дней. Проект, состоящий из 10 простых задач, делается 25 дней. Соответственно, ты берешь свою историческую информацию и говоришь: “Вот смотри, продакт, 85% задач мы делали за неделю. Соответственно, есть шанс, что вот эту задачу мы закончим вот тогда-то. И этот шанс составляет примерно 85%”. Вот по сути наш SLA. Да, мы можем иногда не попадать, иногда сильно не попадать. Распределение экспоненциальное, к сожалению. Ты не можешь сделать сильно быстрее, но обосраться ты можешь настолько сильно, что даже в итоге не сделать совсем. И это тоже нормально. Главное все это проговорить.

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

Не все фичи одинаково полезны. В любом проекте есть must to have и nice to have части. Если пришли 2 жирных проекта, то выгоднее в первую очередь из обоих сделать must to have, а nice to have оставить на потом. А может вообще никогда не делать.

Чему бы хотел научиться?

У меня есть один крестовый поход, хочется дойти. Это придумать, что делать с мертвыми фичами. Мертвыми я называю фичи, которые есть на проде, но которые никому уже не нужны. У тебя нет шанса какими-то техническими средствами узнать, что она больше не нужна. Это должен продакт приходить и говорить, что вот эта фича отжила свое, давай ее выпилим. Ни один продакт не приходит. И ни один продакт не поставит эту задачу вперед. Зачем выпиливать, она вроде как не мешает. Но на самом деле мешает. Любой код мешает. Мешает рефакторить. Упираешься в какой-то адский метод, в котором ты не можешь что-то убрать. А потом начинаешь смотреть, что там на проде, на фронте. А там нафиг это тоже никому не надо. Просто данные в API уходят, а там их никто не ловит. Может и ловит, но не показывает пользователю. А может показывает пользователю, а пользователь уже на них не смотрит. И такие кейсы не понятно как отслеживать. Любой код удораживает производство новый фичей. Выпиливая, ты делаешь хорошо. Но вот как к этому системно подойти пока не понятно. Хорошо, если у тебя еще есть метрики, ты смотришь, что на эту страничку заходит примерно никто. Но есть у тебя, например, на главной какой-нибудь счетчик. Откуда ты знаешь, смотрят на него или нет? С мобилками отдельный челлендж. У тебя есть куча старых версий, и ты не можешь просто взять и отказаться от них. Бывает, существуют версии двухлетней давности или старше.

У тебя есть комьюнити?

У меня есть сообщество DDD-практиков (Facebook, Telegram, YouTube). Я сейчас пытаюсь уйти в сторону организаторства этого всего. Самому делать интересно, но думаю, сейчас времени на это уже не будет. Мы иногда говорим про микросервисы и прочее, но в целом да, мы про DDD и все, что с этим связано. Провели 3 митапа вживую: первый в Додо, второй в Касперском, третий в Райфе. Четвертый планировался, но из-за локдауна все отложилось. DDD коммьюнити прямо просилось. Мне интересно было попробовать. И с точки зрения сбора сообщества, и с точки зрения DDD. Потому что есть много антипаттернов разработки. Все это так или иначе оговорено, но люди не хотят это использовать. Даже уходят в отрицание того, что это важно и нужно. Ну это как бы тоже нормально – отрицать. Дискуссии какие-то.

Как и когда решил пойти в управленку?

Я даже не знаю. Несколько лет назад изучал всякие Agile, даже сертифицировался в то время еще, тогда же это было уже интересно, но все никак не получалось. Сидел на двух стульях. В какой-то момент я вообще отказался от скрама / аджайла и менеджерства, решил, что буду писать код. Но потом меня опять затянуло. И вот сейчас в менеджмент выкинуло полностью.

Ты менеджер?

Сейчас нет еще. Но хочется туда идти. Есть идеи, есть опыт, хочется теперь системно к этому подойти. Вдохновляет возможность масштабирования знаний. Много чего знаешь, умеешь, есть что сказать. И еще вижу много неоптимальности. Как раз персональные задачи, отсутствие доверия какого-то. Много в индустрии такого, не очень хорошего. Люди почему-то до сих пор верят, что у нас все детерминированно. Что ты можешь дать точные сроки за свой участок работы. При этом не думают про вовлечение. Совсем недавно только об этом стали писать. Google сегодня говорит про доверие, про recognition, про impact. Все это важно. Хочется попробовать в этом направление много чего поделать, попробовать.