Как запускать проекты без жиры и прочей скукотени: вот наши главные принципы

Недавно мы закончили важный проект — UIG. Для нашего партнёрства это важная веха: за два месяца мы запустили полноценный MVP технологически сложного проекта — сервиса для проведения киберспортивных турниров. Сервис хранит расписание матчей, подсчитывает результаты, ведёт глобальные лидерборды по играм и командам, красиво эмбедит стримы, позволяет авторизоваться через дискорд и многое другое.

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

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

Менеджеры большинства ИТ-команд до сих пор строят их по принципам времён промышленной революции. Программисты ходят в офис или сидят в слеке с 9 до 18, ходят на дейли, работают по чётко прописанным ТЗ в Жире. Обычно они несут ответственность за время, которое -простояли за станком- просидели в IDE, а не за конечный результат.

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

Мы с Саматом отбираем в свои команды ребят, которым некомфортно в привычном контексте, которые хотят больше ответственности за результат. Такие программисты не любят оценивать задачи (читайте об этом подробнее здесь), часто пристают к бизнесу с неудобными вопросами и не требуют сложного обвеса в виде технический заданий, системных аналитиков, QA- и HR-менеджеров. Они не хотят быть винтиками — они хотят быть целым механизмом. На собеседованиях такие программисты обычно спрашивают об устройстве бизнеса и свободе в настройке CI, а не о печеньках и ДМС.

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

Команды больше 7 человек — это сложные системы, которые расходуют ресурсы не только на написание кода, но и на свое содержание. Чтобы не держать всё в голове, лидер нанимает тим-лидов, для экономии времени на найме и конфликтах — нанимает HR-менеджеров, а чтобы быть уверенным, что команда соблюдает правила игры — делает сложные флоу в Жире и заставляет менеджеров писать ТЗ.

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

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

Ну а ещё небольшие команды здорово обеспечивают недостаток ресурсов.

Начать фичу очень легко — можно просто написать команде письмо «теперь делаем Х». А вот сделать фичу, а тем более поддерживать её — тяжкий труд. Люди любят начинать и не любят доводить дела до конца. Даже в MVP. Вот и получаются к дедлайну продукты с хорошо продуманной регистрацией, валидацией форм, UI-китом, но с интерфейсными тупиками и без конкурентных преимуществ.

Самое хорошее средство от бесконечных начинаний — это недостаток ресурсов. Недостаток ресурсов не обязательно должен быть измеримым (не будем же мы эстимейтить таски на этапе MVP), это скорее вопрос ментального настроя людей, принимающих решения. Когда мы подключаемся к планированию MVP, мы стараемся переключить команду из режима «хорошо бы сделать Х» в режим «а мы точно не запустимся без Х?» или ещё лучше: «А какая минимальная функциональность должна быть у Х, чтобы мы запустились?».

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

Больше об этом можно почитать у легендарных создателей Basecamp в книге Getting Real, на русском похожие принципы распространяет Бюро Горбунова.

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

В начале недели каждый программист дает простые обещания — какие полезные изменения в проекте он доделает за эти 5 рабочих дней.

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

Для записи и публикации демы мы используем прекрасный сервис loom. Это видео я загрузил на ютуб, чтобы было удобнее сделать эмбед и заблюрить адрес сервиса до публичного запуска.

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

У нас настроен CI/CD, так что всё, что сделал программист, сразу же могут посмотреть другие члены команды, на живую. Вот как это работает:

☟

каждый пул-реквест автоматически тестируется и при прохождении базовых проверок деплоится на специальный тестовый сервер

☟

В нашем детстве у каждой уважающей себя семьи был свой огородик за городом. На этом огородике сажали огурцы, копали картошку, обрабатывали грядки от сорняков и делали ещё кучу ручной работы. В 2020 году все поменялось — даже в «Пятёрочке» можно найти нормальные овощи, которые вырастили профессионалы с комбайнами, сеялками и практическим подходом. Несмотря на такое разделение труда, до сих пор сохраняются бабушки, которые ездят (и таскают внуков!) на эти свои огородики.

В ИТ, даже в начинающих компаниях, огородики цветут пышным цветом: люди заводят собственные гитлабы вместо (бесплатного!) гитхаба, разворачивают собственные версии sentry, youtrack, поднимают свои кластеры kubernetes ради двух подов. То есть вместо того, чтобы пойти и купить готовые сервисы за условные 5$ в месяц — городят свои огороды, которые, если посчитать полную стоимость владения (TCO), оказываются в разы дороже.

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

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

Чтобы составить свой — начните с free-for.dev: это хороший каталог ресурсов, которые дают бесплатные лицензии для маленьких проектов. Бесплатность лицензий — не самое важное в этом сервисе, гораздо интереснее смотреть на таксономию и разбираться, какие инструменты автоматизации в принципе существуют в мире. К примеру когда-то именно оттуда я узнал, как работают APM (application performance monitoring) и автоматическое тестирование на удалённых мобилках а-ля BrowserStack.

Всё это — жестко холиварные темы. Результата можно добиться и с заводом на 100 человек, которые делают задачи по 10-мегабайтным. DOC-файлам из жиры. Жира тоже работает, но это гроб гроб кладбище как скучно, к тому же, это медленнее, а значит — дороже. Дополнительная проблема завода — привычные правила игры создают чувство безопасности: «я делаю всё по правилам, плохой результат — не моя вина».

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