Релиз Ситидрайва
Пять управленческих решений из чужого кейса Ситидрайва, которые вызвали у меня вопросики. О планировании, коммуникации, работе со смежниками и оценке результатов.
Дисклеймер: здесь я анализирую чужие публичные профессиональные кейсы, а не их авторов. Это монолог с самой собой: насколько обоснованы чужие выводы и к чему можно придраться. Заодно проверяю теорию, что авторитет компании и публикация на известной площадке это всегда гордо и солидно.
21 марта 2025 года на Хабре вышла статья Даниила Сухарева про Ситидрайв «От монолита и чатов к FMS и FMS App: новый уровень управления каршерингом с автопарком 19 000+ авто». Кому интересно найдёте. Даниил рассказывает о разработке системы управления автопарком и мобильного приложения. За три месяца команда подготовила MVP, за три квартала обновила процессы. Результат крутой, техническая часть интересная. Но управленческие решения я бы не спешила забирать себе в практику.
1. Оценка и планирование
«Отказались от классических оценок»
Меньше встреч... ух, заманчиво. Но отказ от груммингов и оценки трудозатрат однако разные решения. В статье упоминаются Jira, балансировка загрузки и трёхмесячный срок MVP, но почти ничего о финансовом планировании.
Для внутренней разработки с выделенной командой подход может работать. В заказной без оценки объёма и стоимости далеко не уедешь: КП само себя не подготовит, фиксированный бюджет не увеличится от энтузиазма команды. Отказ от лишних церемоний поддерживаю. Отказ от контроля трудозатрат уже не окей.
2. Коммуникация
«Вся коммуникация шла через меня»
Продакт взял на себя общение со всеми заинтересованными сторонами, чтобы разработчиков не отвлекали. Для небольшой команды понятно, но появляется единая точка отказа.
Заболел продакт, ушёл в отпуск, пропустил техническую деталь = коммуникация встала. Информация проходит через интерпретацию посредника. Я за фильтрацию лишних обращений, но прямое взаимодействие специалистов должно сохраняться. Особенно когда два разработчика способны решить вопрос за пять минут без третьего участника. Надеюсь, обошлось без двенадцати подвигов.
3. Управление изменениями
«Пересобирать приложение»
В статье упоминаются ТЗ на 25 страниц, почти 300 экранов дизайна и неоднократные изменения концепции. Знакомая история, только хочется понимать стоимость этой гибкости.
Меняются требования, а значит появляются переделки, зависимости и дополнительные проверки. Насколько это повлияло на готовый функционал, неизвестно. Быстро менять направление полезно, когда стоимость разворота контролируется, а не выясняется постфактум.
4. Смежные команды
«Сделаем это сами»
Когда другие команды не могли взять доработку, автор предлагал выполнить её собственными силами. Вот здесь мой любимый вопрос про зоны ответственности. Его даже вслух задавать необязательно.
У смежной системы есть владелец, технические ограничения и обязательства по сопровождению. Самостоятельная реализация ускорит релиз, а последствия могут остаться другой команде. Я бы предпочла согласовать приоритеты, совместную работу и дальнейший ownership. Настойчивость полезный софт-скилл, но обход чужого бэклога сложно считать универсальной практикой.
5. Оценка результата
«Готово в срок»
MVP запустили. Но управленческих метрик для оценки подхода почти нет. Ни динамики скорости поставки, ни количества переделок, ни нагрузки команды. Понятно, что внутреннюю экономику никто раскрывать не обязан. А относительные показатели тоже секрет? Хи-хи.
Автор подробно описывает архитектуру, тестирование и автоматизацию. Их вклад в результат может быть существенным. Поэтому приписывать успех отказу от оценок и выбранной модели коммуникации я бы не стала.
Запустить продукт в срок — достижение команды. Если кейс посвящён управленческим решениям, покажите, что конкретно вы улучшили. На сколько процентов ускорили поставку, сократили согласования, снизили количество дефектов или блокировок. Э??? Даже сравнения до и после хватило бы.
Понимаю, что подобные кейсы часто пишут для будущих клиентов и присутствия в интернете. Прочитал заказчик или потенциальный партнер, впечатлился продуктом, захотел такой же (ну или присоединиться к сотрудничеству). Но не все идиоты и очень даже умеют читать между строк. Отказ от оценок, вся коммуникация через одного человека, самостоятельные доработки чужих систем — для внимательного читателя это вполне конкретные риски.
И есть ещё один коммерческий нюанс. Если продавать отсутствие привычных управленческих процедур как преимущество, можно привлечь клиентов, которые впоследствии не захотят платить за планирование, согласования и контроль изменений. А потом той же команде придётся объяснять, почему всё это внезапно необходимо на их проекте. Лол.
Если Даниил или его коллеги захотят дополнить кейс цифрами либо оспорить мои замечания — го, найдите меня. Возможно, внутри проекта или в личке ответы появятся. В опубликованном материале я их не увидела.
Кстати, 19 августа 2026 года Даниил опубликовал продолжение: «FMS полтора года спустя: от одного флоу до 52 типов задач, или как мы научились запускать новый тип задачи за 10 минут».
И вот здесь уже интереснее. Автор честно признаёт, что на момент первой публикации в приложении работал всего один полноценный сценарий, а автоматический диспатч не реализован до сих пор. Зато теперь есть 52 типа задач, конструктор сократил настройку типового сценария с нескольких недель до десяти минут, появились контроль исполнения и более подробные метрики.
Этот результат уже можно обсуждать. Но эффективность самого управления командой опять оценить сложно: экономия на разработке конструктора, общие трудозатраты и влияние подхода на качество поставки не раскрыты. Но за признание первоначальных ограничений и измеримость — хорош. Этих подробностей первому кейсу и не хватало.
Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.