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

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

список поддерживаемых игр и турниры
список поддерживаемых игр и турниры

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

безудержная радость команды перед запуском
безудержная радость команды перед запуском

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

Люди-винтики vs люди-механизмы

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

труд на заводе в годы промышленной революции
труд на заводе в годы промышленной революции

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

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

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

Оставайтесь маленькими

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

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

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

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

Недостаток ресурсов

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

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

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

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

Недельные планы и демо

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

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

примеры недельных обещаний. Какой кайф, что всё отмечено как «готово»!
примеры недельных обещаний. Какой кайф, что всё отмечено как «готово»!

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

Вот пример такого демо от нашего дорого фронтендера Бори

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

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

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

почти все изменения оформляются как пул-реквесты в гитхабе
почти все изменения оформляются как пул-реквесты в гитхабе

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

весь CI/CD у нас сделан на прекрасном CircleCI
весь CI/CD у нас сделан на прекрасном CircleCI

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

Правильно выбирать инструменты

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

«первым делом я поднимаю gitlab и sentry»
«первым делом я поднимаю gitlab и sentry»

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

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

Федя как-то консультировал одну команду, которой достался грант Microsoft Azure для стартапов. Выданного гранта хватало как раз на две виртуалки, на одной из них ребята сделали прод, а на другой разместили огородики — gitlab, sentry, какие-то рассылали почты вроде postfix. Для CI мощностей одной виртуалки не хватало, поэтому ребята разместили воркеры на обоих тачках — надо ли говорить, что когда ребята много билдили, у них тормозил прод, а когда шла большая нагрузка на прод — не могли билдить?

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

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

Если вам было лень все это читать, вот основные принципы:

  1. Программисты, способные закрывать бизнес-задачи и спорящие о пользе с бизнесом, а не просто прогающие, что укажут;
  2. Желание оставаться маленькой командой как можно дольше;
  3. Недостаток ресурсов как механизм принятия правильных продуктовых решений;
  4. Еженедельные обещания программистов и видео-демо, которые они записывают с презентацией своей работы;

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

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

Вы программист и хотите работать с нами? Пишите Фёдору Борщёву на fedor@borshev.com.

Хотите заказать наши услуги? Пишите Самату Галимову, s@samat.me и @samatg в телеграме.

3737
52 комментария

Программисты <...> работают по чётко прописанным ТЗ в Жире

14
Ответить

ну это менеджеры так считают, как в меме «how i see / how they see me»

6
Ответить

"На собеседованиях такие программисты обычно спрашивают об устройстве бизнеса и свободе в настройке CI, а не о печеньках и ДМС." -
Я разработчик и полностью не согласен с этим! Как раз таки, чтобы думать о бизнесе и приносить пользу разработчик должен быть уверен в своем работодателе, стабильной белой зарплате, печеньках и ДМС. 

13
Ответить

Вопрос в приоритетах. 

3
Ответить

Комментарий недоступен

8
Ответить

1) дизайнер рисует макеты, бэк даёт документацию к API перед тем, как прогать все остальное. Такой проблемы не было 

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

3) ну мы тестировали все это не только два месяца :)

3
Ответить

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

Как я понимаю, основная идея — это работать с разработчиками с прокаченными софт-скилами, а хард-скилы (джун, мидл, сениор) — уже в процессе подтянутся. Или всё же не так? Сработает ли такой подход с командой, в которой не все прокаченные мидлы и сеньоры? 

Кто координирует разработчиков и помогает им выбрать обещания на неделю? Как вы организовывали этот процесс?

5
Ответить