Начинается всё красиво.

Чистый backlog, ясная цель, первый релиз — как свежевыпеченный хлеб: пахнет амбициями и планами.

Проходит год, и продукт уже оброс десятками фич.
Проходит два — и ты открываешь его и думаешь: А как этим вообще пользоваться?

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

Ситуация банальная, но болезненная.
У тебя есть открытая вакансия, бюджет — один человек.
И ты выбираешь: взять уже готового мидла или вырастить джуна?

На первый взгляд — ответ очевиден...

Команда бодра, тикеты летят, всё чётко по процессу.

А потом ты открываешь продукт… и возникает ощущение, что ты случайно открыл старую версию. Полугодичной давности...

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

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

Кажется, что всё ещё можно сделать чуть-чуть лучше, чуть-чуть полнее, чуть-чуть красивее… И всё.

И как же из паразита сделать симбиота? Agile — слово, которое стартапы любят произносить на каждом питче.

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

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

Когда задачи есть, а движения — нет

Команда работает.
Задачи в трекере стоят.
Стендапы идут, код пишется, обсуждения кипят.

А результата всё нет.
Нет чувства прогресса, нет ощущения, что продукт становится ближе к релизу.
Итерации проходят одна за другой — а продукт будто топчется на месте.

Или как культура страха убивает продукт

Многие компании мечтают о сильной и самоорганизующейся команде.
О людях, которые берут на себя ответственность, двигают проект вперёд и решают проблемы без лишнего шума...

Как попытки быть ближе к пользователю иногда отдаляют от цели

В одномстартапе мы решили сделать по уму — активно собирать и учитывать обратную связь.
Видим комментарий: «Сделайте поиск попроще» — переделываем.
Пишут: «Темная тема нужна обязательно!» — добавл яем.
...

- А давайте добавим ещё фильтр…
- Хорошо бы выгрузку в Excel
- Вот бы ещё график и пуши — красиво же будет!

Проект набирает скорость. Только вот в каком направлении?

Почему стартап так и не запускается, хотя «уже почти»

Многие команды проходят этот путь. Всё вроде бы работает, осталось «совсем немного», но неделя за неделей релиз откладывается...

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

Если вы хоть раз были на стороне бизнеса, наверняка слышали (или говорили):

Сколько можно делать такую простую штуку?; Они что, не понимают, как это важно?

Но тут надо смотреть шире...

Почему даже сильные разработчики делают на авось?

Команда вроде опытная, но в проде — баги, архитектура — костыль на костыле, а фичи заливаются «на нервах»?

Когда «ускорить разработку» — значит всё сломать

Почему скорость команды — это не всегда про людей, а про инфраструктуру

Или почему shiny tech stack ≠ рабочий продукт. Каждую неделю выходят новые «киллеры» фреймворков, базы данных, фреймворки на фреймворки, UI-библиотеки, подходы к state management, архитектурные паттерны и всё прочее.