Чек-лист: твой проект скоро развалится, если…

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

• Весь проект держится на одном человеке
  И он — не документация. Ушёл в отпуск — проект замер.

• Задачи ставятся в личке, на встрече или в голове
  "Я же в телеге писал задачу". Без трекинга всё разваливается.

• Никто не может объяснить, что по приоритету
  Всё срочно, всё горит, всё одновременно. Ну вы поняли.

• Прод выкатывается вручную, или в пятницу вечером
  Даже не баг, а фича. Проблемы по подписке.

• Тестов нет, баги ловим по фидбеку
  Багрепорт от клиента — это не QA.

• Архитектура — это слово из чужого лексикона
  Потому что “нам и так норм”. До первой перегрузки.

• Вопросы “а как это работает?” решаются методом тыка
  Потому что комментировать код — западло.

• Бэкапы где-то есть… но никто не проверял
  Олег говорил, что сохранял себе дамп локально

• Ушёл один человек — и половина знаний ушла с ним
  Значит, их не было в проекте — только в его голове.

Если вы загнули 3–4 пальца — значит пора встать и осмотреться.
Пока “всё работает” — это ещё не стабильность, это просто везение.

Некоторые проблемы уже рассмотрел подробнее в своих статьях

Фича ради фичи

Как легко потерять смысл разработки, добавляя “полезности”

• Сделаем ещё кнопку, она “точно нужна”

• Добавим фильтр, и сортировку, и модалку, ну мало ли

• Вот бы выгрузку в Excel, и график, и пуши!

…Проект набирает скорость. Только куда?

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

Парадокс: чем больше фич, тем хуже продукт

Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.

У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»

Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.

Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги.
Людям не нужно «все и сразу», им нужна качественная точечная фича

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.

Человек-комбайн

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

Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.

Первый этап

Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.

Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».

Второй этап

Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.

Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.

Третий этап

Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…

Судный день

Без него — никто не знает, как деплоить, где что лежит, как починить баг.

Документации нет, у разработчиков паника.

Прод падает. Клиенты жалуются. Команда — в ступоре.

Восстановление занимает недели. А иногда — проект просто не поднимается.

Как не угодить в ловушку?

Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.

Коромысло с одним ведром — всегда перевесит в одну сторону.

Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.