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

Недавно мы закончили важный проект — 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

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

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

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

«первым делом я поднимаю 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-файлам из жиры. Жира тоже работает, но это гроб гроб кладбище как скучно, к тому же, это медленнее, а значит — дороже. Дополнительная проблема завода — привычные правила игры создают чувство безопасности: «я делаю всё по правилам, плохой результат — не моя вина».

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

Вы программист и хотите работать с нами? Пишите Фёдору Борщёву на [email protected].

Хотите заказать наши услуги? Пишите Самату Галимову, [email protected] и @samatg в телеграме.

0
52 комментария
Написать комментарий...
Sendero

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

Ответить
Развернуть ветку
Samat Galimov

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

Ответить
Развернуть ветку
Александр Величковский

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

Ответить
Развернуть ветку
Samat Galimov

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

Ответить
Развернуть ветку
4 комментария
Аккаунт удален

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

Ответить
Развернуть ветку
Samat Galimov

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

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

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

Ответить
Развернуть ветку
1 комментарий
Кирилл Арутюнов

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

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

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

Ответить
Развернуть ветку
Samat Galimov

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

Конечно, помогаем с обещаниями, если видим, что они нереалистичны. 

Ответить
Развернуть ветку
2 комментария
Sergey

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

Есть такая должность бизнес-аналитик, без него - я хз как еще победить человеческую лень/междусобойчики и хитрожопость )

Ответить
Развернуть ветку
Роман Макаров

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

Ответить
Развернуть ветку
Todd

Потом задач будет больше 50 и вариант с notion они повторно перезапишут в ту самую Jira которую ругали ;)

Захотят сделать ретроспективу, а данных нет, есть примитивные строчки в списке кому чего надо сделать.

Опсы будут поддерживать продукт, а т.к. issue tracker'а не было, то и предыдущий опыт считай что ушел в никуда.

Про базу знаний тоже ничего не написали.

«Сделал дело, слезай с тела» проект :)

Ответить
Развернуть ветку
Samat Galimov

Э не, основная метрика нашего технического успеха - это простота изменений. Decoupled, strongly tested, вот это все. 

Ответить
Развернуть ветку
Маргарита Лукина

MVP подход никак не мешает продумывать архитектуру. Один из самых важных показателей качества кода - расширяемость и масштабируемость. Если программист не думает, что он пишет, то любой подход придет через пару лет к "добавление фичи требует переписывания ядра".

Ответить
Развернуть ветку
Todd

Крутое решение с точки зрения чуваков которые сделали MVP, с задней мыслью «потом все с нуля переделают», получили деньги и свалили.

В остальном – «блокнот» придется все равно переводить в полноценный issue tracker.

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

Про базу знаний тоже не заметил упоминаний, может пропустил.

Jira которую поносили всю статью не виновата в том как ее используют люди. Бюрократия это не про инструменты.

Ответить
Развернуть ветку
Вадим Чиняев

выдумал проблему, обосрал, выдумал решение - ок, люблю vc )

во всех этих историях про то как правильно имеет смысл руководствоваться отзывами заказчика, когда по факту продукт готов. Если продукт MVP - какие претензии?

Ответить
Развернуть ветку
5 комментариев
Никита Долматов

А что записывают в видео-демо бэкендеры – пример работы запросов –, или QA-инженеры?

Ответить
Развернуть ветку
Samat Galimov

бэкендеры запросики и какой-то минимальный PoC фронт

с QA сложнее!

Ответить
Развернуть ветку
Владимир Войтенко

бэкендеры пишут тесты. написанные тесты доказательство сделанной работы. Задача без тестов == "не было сделано ничего"

Ответить
Развернуть ветку
Евгений Демин

+1. Отличный вопрос, сам таким же задался, когда читал статью

Ответить
Развернуть ветку
1 комментарий
Арина Власова

Трамп ворвался на грядки неожиданно))

Ответить
Развернуть ветку
Михаил Меньшенин

Спасибо за статью, интересный опыт. Подписан и на Самата, и на Федора в телеграме. Очень нравится читать.

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

Что будет, если проблема пользователя придет в середине недели? Кто будет решать важная она или нет? Кто будет воспроизводить? Кто будет исправлять? Что будет с "обещанными задачами"?

Ответить
Развернуть ветку
Samat Galimov

Любое внешнее воздействие — это повод пересмотреть обещания. Кажется вполне нормально сказать в среду «я не успеваю, потому что придумали более важную задачу». Главное — не делать так перед дедлайном.

Ответить
Развернуть ветку
Mikhail Stepanov

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

Ответить
Развернуть ветку
Samat Galimov

Я там приложил скриншот реального списка задач в notion на запуске!

Где ставить задачи - не суть важно, главное - кто и как. Жира тут скорее прилагательное. 

Ответить
Развернуть ветку
Дмитрий Пелипас

не удержался

Ответить
Развернуть ветку
rediska1114

Спасибо за интересную статью!

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

Вместо исполнения четких задач — мне говорят что должно получиться, а я уже думаю как это лучше сделать. И в эти моменты действительно часто задаю вопрос «А можно ли без этой фичи запустить MVP» и «Может эту вещь можно сделать лучше». И это прекрасно!

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

Ещё раз спасибо, благодаря вашей статье я узнал, что это нормальная практика, и оказывается бывает нормально

Ответить
Развернуть ветку
Tenetovich

С тобой точно что-то не так, а именно:
1. Ты называешь коллег разрабами-винтиками. А ты разраб-винторез? Интересно увидеть твое CV и достижения.
2. Называешь системы взаимодействия в прибыльных компаниях "бюрократической системой". Расскажи про свой стартап и его метрики, очень интересно послушать.
3. Решаешь какие фичи запускать в MVP. Просто смешно.

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

Самат и Фёдор, благодаря вашей статье появился еще один IT единорог ломающий своим гигантским рогом устои IT.

Ответить
Развернуть ветку
1 комментарий
Dmitry Dmitriev

А как хранятся требования к продукту, если ТЗ суть зло и заводить задачи скучно? Вот начинаем мы делать фичу №73 через год, а она, вроде, косвенно начинает влиять на фичу №14 сделанную где-то на старте. Как это разрулить без чётко прописанного требования? Собрались обсуждать и сообразить как эти фичи должны работать вместе, но вот помнят все первую фичу по разному, ибо её потом ещё патчили пару раз и дорабатывали... как тут быть?

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

Ответить
Развернуть ветку
Samat Galimov

Короткий ответ: тестами! Если ты сломаешь предыдущую фичу - то узнаешь от этом в своём CI. Не все можно покрыть тестами, конечно. 

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

Поэтому, лучше тестов для этого, кажется, человечество ещё ничего не изобрело.  

Ответить
Развернуть ветку
1 комментарий
ivan krapivin

Почему у вас Трамп на заглавном фото?

Ответить
Развернуть ветку
Samat Galimov

У этой фотки есть какая-то история, just google, но для меня это просто фотка бабки на даче. 

Ответить
Развернуть ветку
Dmitry Derbenev

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

Ответить
Развернуть ветку
Samat Galimov

Bus factor он в первую очередь про тесты и нормальный код. 

Про проценты не скажу, к сожалению; я себя успокаиваю тем, что я не Яндекс и не Гугл, мне не важно, сколько их на рынке в целом, нужный мне десяток я точно найду, тем более, что вся работа удалённая. 

Ответить
Развернуть ветку
Аккаунт удален

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

Ответить
Развернуть ветку
Samat Galimov

Простота изменений (качество архитектору) и коллегиальность технических решений ортогональны системам управления, если вы это имели в виду. 

Ответить
Развернуть ветку
Николай

Давно читаю телеграм-канал Фёдора Борщёва - очень много интересных статей о разработке, бизнесе и ведении проектов. Здорово, что вы делитесь своими подходами - всегда интересно смотреть за тем, как небольшая команда спецов делает продукт, который можно безболезненно масштабировать и ставить на энтерпрайзные рельсы по мере роста

Ответить
Развернуть ветку
Leor M

Не знаю, писали здесь уже или нет. Но issues можно вести в гитхабе, раз вы им пользуетесь. А в будущем, когда проект вырастет, перенести все issues простым скриптом в жиру или любой другой трекер. В принципе, тоже самое можно и в Notion сделать.

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда