Чего делать точно не стоит — это пытаться выдать аварию за штатную профилактику.
Так, на прошлой господрядчик пытался скрыть аварию в государственной системе, на которую завязана вся фарм отрасль России.
Зрелость инженерной организации проявляется не только в том, как редко случаются аварии — они бывают у всех. Зрелость в том, КАК компания реагирует на аварии. Но не буду повторятся, про это я уже писал подробно ранее: жемчужина от cloudflare и пример stackoverflow.
Банки, такси и доставка продуктов давно живут в интернете, в этом нет ничего странного. Но то, сколько IT в современной стройке я не знал, пока не познакомился с Сережей Фуксманом.
Серёжа — вице-президент по информационным технологиям в группе компаний ПИК. Он управляет сотнями разработчиков в одной из самых крупных строительных корпораций в мире. Я позвал Сережу в подкаст, чтобы разобраться, чем занимается он и его команда, где на стройке применяют компьютерные технологии и как вообще можно автоматизировать одну из самых коррумпированных сфер бизнеса.
Внутри полный 🤯 и многие вещи похожи на научную фантастику 💫
Слушайте везде: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
Как управляют разработкой в самом популярном музыкальном сервисе в мире?
5 лет назад Spotify рассказали о своей системе управления разработкой, Spotify model. Сегодня о ней знает любой менеджер в IT, а многие положения из этой системы стали стандартами де-факто.
На прошлой неделе я поговорил с Юлей Куропатенковой, инженерным менеджером в Spotify. Юля отвечает за бэкенд авторизации. Она рассказала, что за эти годы их система управления разработкой сильно изменилась, сколько программистов и команд в Spotify, кто и за что отвечает. До Spotify Юля поработала в дочке IBM и поэтому может сравнить два диаметрально противоположных подхода к организации разработки.
Слушайте на всех платформах: Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и веб-версия.
Мы с Федей ищем технического директора в igooods себе на замену.
igooods — это доставка продуктов из гипермаркетов. Сотни тысяч клиентов, тысячи заказов в день, миллиард оборота в месяц. 36 городов России. В партнерах — Метро, Лента, Призма, Вкусвилл, Ашан, Глобус, Карусель, Окей.
Техническая команда — 31 человек. Под капотом рельса и реакт, нативные мобильные приложения для iOS и Android.
Вы заберёте разработку, которая находится в процессе трансформации от небольшой уютной тусовки к машине по зарабатыванию денег. За последние полгода производство стало работать чётче, но до швейцарских часов ему пока далеко — много вещей делаются на ручном контроле. Вам предстоит выстроить QA, доукомплековать продуктовые команды, до конца перейти на сервисную архитектуру (цель — через полгода перестать писать код в монолит) и создать систему управления техдолгом.
Вторая задача — подчинить разработку бизнесу, работая бок о бок с CPO. Каждый джуниор-фронтендер должен знать, на какую метрику повлияет задача, которую он сейчас делает, а любая гипотеза про деньги должна проверяться не дольше трёх недель.
Мы с Федей запустили эти процессы, но чтобы завершить работу, нужно жить в Питере.
Команда прекрасная, но это не значит, что вам не придется много работать руками. Оно того стоит — вы выстроите первоклассную разработку в одном из крупнейших сервисов доставки продуктов в России.
Офис в Питере, помощь с переездом. Подчинение напрямую владельцу бизнеса; основной рабочий партнер — CPO Андрей Родин.
Пишите краткий рассказ о себе мне в личку или на s@samat.me.
Как запускать проекты без жиры и прочей скукотени? Набрасываем с Федей на вентилятор и делимся основными принципами в честь сдачи проекта одному из клиентов.
Когда мы с Федей шли в igooods, то сразу договорились, что нужно развивать технический бренд — он помогает нанимать и удерживать крутых специалистов. Для этого нужно писать статьи и выступать на конференциях; рассказывать, какие крутаны у нас работают и какие интересные технические штуки мы делаем. Благо, историй достаточно.
Стыдно, но пока мы сделали на этом фронте очень мало.
Тем приятнее, что на прошлой неделе мы наконец-то выступили на онлайн-конференции с Андреем Родиным, директором по продукту igooods. Делились тем, как пережили пик заказов при коронавирусе. Андрей рассказал про телеграм-бота, который позволил нам нанять менее квалифицированный персонал для сборки заказов без потери качества. Андрей сам собрал прототип в конструкторе ботов, а наш замечательный бэкендер Сережа прикрутил к нему бэкенд по АПИ за рекордные сроки. Я рассказал, как мы с технической командой роняли и поднимали серверы под нагрузкой.
Хочу поделиться приемом, который помог нам подготовиться к выступлению. Я подготовил слайды по теме Андрея. Андрей их, конечно, переделал под себя; мне достаточно было сделать очень плохую заготовку, чтобы процесс пошел.
Попробуйте делегировать кому-то написание первой версии статьи или выступления, которое вы давно откладываете. Просто объясните в общих чертах, о чем вы хотите рассказать. У исполнителя не будет тормозов по поводу того, что доклад получается не идеальный, ведь не ему его потом рассказывать. Подобный черновик поможет начать работу; довести выступление или статью до ума — уже дело техники и упорства, с этим вы точно справитесь.
В чем заключается работа технического директора? Обычно я отвечаю отрывочно или углубляюсь в какой-то аспект профессии, который интересует меня в тот момент.
Мы с Федей уже почти месяц вместе составляем системный ответ на этот вопрос. Для командной работы мы завели личную базу знаний (что-то вроде своей википедии) в Notion. Мы храним там общие задачи, план и знания, которые собрали в ходе работы. Если заменить информацию о конкретном клиенте подробным описанием, зачем мы делаем тот или иной шаг — может получиться книга «как руководить разработкой в продуктовой компании».
Вот структура/оглавление, которые у нас сложились. Этот список можно использовать как основу чеклиста для стартапа или небольшой технологической компании.
Глава I, про бизнес и процессы.
1. Чего бизнес хочет от разработки? Важно не остановиться на конкретной хотелке «напрогайте нам X», а докопаться до бизнес-гипотезы, которую хотят проверить.
2. Как построена работа над продуктом: кто преобразует гипотезу в задачу, как ставится задача разработке, доносится ли гипотеза до программиста, интересуется ли они ею? В здоровой продуктовой команде техническая экспертиза подключается на самом раннем этапе.
3. Что происходит после запуска фичи? Анализируется ли результат? Понимают ли программисты, как они повлияли на бизнес?
4. Как происходит планирование и приемка работы? Смотрим на четкость и ритмичность. Четкость: плохо — «мы тут что-то не особо хорошо описанное напланировали, о том успеем или нет — не задумывались», хорошо — «в понедельник у пользователей в продакшене появится X», нужны конкретные обещания и контроль их выполнения. Ритмичность: продуктовая работа — это почти всегда постепенное улучшение и очень редко — один героический забег. Чтобы система работала годами, ей нужна цикличность, с запланированными фазами «напряжение-расслабление».
Глава II, люди.
5. Команда: в каком состоянии ребята, нравится ли им работа, нравятся ли коллеги, конкурентная ли компенсация? План развития ребят, 360 reviews, 1-1.
6. Уникальность знания. Что будет, если сотрудник уволится или заболеет (bus factor)? Документация, стоимость погружения новых людей в проект.
7. HR: достаточно ли мы рассказываем миру о том, хорошо лиу нас работать? Ведение профессионального блога, выступление на профильных конференциях.
Глава III, технологии.
7. Operations: отказоустойчивость, масштабируемость, мониторинг, incident management, бэкапы, учения. Автоматизация процессов в разработке: среды разработки, деплой, откат, etc..
8. Архитектура и код: модульность, связанность, тесты. Тесты: насколько велика вероятность сломать проект? Радость разработчика: насколько комфортно ребятам работать?
9. Информационная безопасность: DDoS, дырки в коде, операционная безопасность, социальная инженерия. Проводим ли ли пентесты, есть ли баунти-программа, как реагируем на сообщения об уязвимостях?
—
Федя шутит, что это — опасная книга, люди увидят, что работа довольно простая и платить нам за неё много денег необязательно. Я так не думаю, сложности с количеством клиентов нет и кайф, что нам не стыдно открыть кухню. Получится самим улучшить ситуацию по нашей инструкции — отлично.
Проблемы, которые мы видим на рынке у разных компаний — очень схожи. Но этот пост уже и так неприлично длинный, об этом — в следующий раз.
P.S. У нас есть отличная вакансия для рубиста в Питере.
Роман Павлушко своими руками программировал первые версии Авито в команде из двух ребят и за 10 лет вырастил команду разработки до 400 человек.
Проект прошел путь от очередного сайта объявлений до одного из самых популярных сервисов русского интернета, а работать программистом в Авито — это знак качества на рынке труда.
Я спросил у Ромы, какие ошибки он допускал, чего боялся и как у него всё это получилось.
Слушайте на всех подкаст-платформах страны:
Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.
Ура, классный эпизод получился!
Саша руководит мобильными разработчиками Сбербанк Онлайн, а Ярик - дизайнерами. Это сотни специалистов.
Я боялся, что гости окажутся энтерпрайз менеджерами с процессом головного мозга, с которыми не о чем будет говорить, только палкой тыкать. На деле получилась одна из самых бодрых записей. Был магический момент, когда ребята впервые рассказали публично, как через адский факап, они пришли к распределённой системе разработки с десятками кросфункциональных команд. Кайф. Теперь хочется позвать тинькова для дисса ;)
Слушайте и подписывайтесь на всех платформах: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.
Хотите послушать у нас кого-то конкретного или про какую-то тему? Пишите в личку, на почту podcast@samat.me или просто комментарием в любом удобном месте.
P.S. Торжественно обещаю не перебивать гостей так часто и смеяться потише.
Один из крупных руководителей инженеров в убере опубликовал очень большой, подробный рассказ, как он проводит performance reviews - это когда оценивается работа сотрудника за существенное время. Квартал? Год?
Я думаю, что важно обсуждать максимум вещей на регулярных 1-1 раз в пару недель, не реже раза в месяц.
Автор замечает в самом начале, что как и любую статью про менеджмент, ее стоит воспринимать как источник информации, идей и вдохновения, а не как инструкцию к действию. Информации и ссылок там много. За одну серию ссылок на описания уровней ответсвенности программистов в разных компаниях большое спасибо.
Объём труда вложенный в статью внушает уважение и небольшой страх, что лично я многие вещи делаю по наитию, и может быть не очень хорошо, а вот у чувака СИСТЕМА. Респект, уважуха и хороший повод инженерным менеджерам задуматься, как мы можем делать свою работу лучше. Аминь.