# Прежде чем строить: проверь, что этого ещё нет

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

URL: https://posts.danashkin.ru/guides/proverit-chto-uzhe-est-do-razrabotki
Обновлено: 2026-09-14

---

## Коротко

**Главное**

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

## Почему проверка «есть ли уже» пропускается?

**Главное**

Потому что она скучная и на неё нет запроса. Идея своего инструмента приходит с энергией, хочется начать, а проверка чужого выглядит как торможение. В корпоративной среде добавляется вторая причина: никто не знает, что делают соседние отделы.

История с одного из потоков. Группа дошла до выбора проекта, участница описала идею: инструмент, который будет собирать и обновлять данные по площадкам. Задача её мучила давно, и она была готова начинать.

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

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

Есть и третья причина, менее приятная. Проверка может закончиться выводом «делать не надо», а замысел уже прожит в голове и стал приятным. Отказаться от собственной идеи тяжелее, чем от чужой, поэтому вопрос откладывают до момента, когда бросать жалко.

Второй слой той же истории: в той группе идеи участников оказались похожими друг на друга. Разные компании, разные роли, а замысел один - собрать разрозненные цифры в одно обновляемое место. Люди изобретают одно и то же гораздо чаще, чем кажется изнутри собственной головы.

## Четыре места, где искать готовое

**Главное**

Соседние отделы, уже оплаченные лицензии, неиспользуемые возможности сервисов и открытые решения. Порядок именно такой: начинать стоит с того, что уже оплачено и лежит рядом, а не с поиска в интернете.

Обход занимает вечер, если идти по списку.

| Где искать | Что искать | Как проверить |
|---|---|---|
| Соседние отделы и коллеги | тот же процесс под другим названием | разговор на десять минут, не письмо |
| Оплаченные лицензии | функции, за которые уже заплачено | попросить у бухгалтерии список подписок |
| Сервисы, которыми пользуетесь | вкладки и разделы, куда никто не заходит | открыть настройки и прочитать меню целиком |
| Открытые решения | готовые инструменты под типовые задачи | поиск по описанию задачи, а не по названию |

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

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

Про то, как вообще выбирается первая задача под автоматизацию, я писал в материале про [первую задачу для нейросети](/guides/kakuyu-zadachu-otdat-ii-pervoy): проверка «нет ли уже готового» встраивается туда как нулевой шаг.

## Как спросить у коллег, чтобы получить честный ответ?

**Главное**

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

Формулировка решает всё, и это не тонкость, а механика.

«Есть ли у нас инструмент для сбора данных по площадкам?» - человек мысленно перебирает названия систем, не находит и отвечает «нет». Ответ честный и бесполезный.

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

Что стоит спросить дополнительно:

- Кто ещё в компании занимается похожими данными?
- Что вы пробовали раньше и почему бросили?
- Чего в текущем способе не хватает больше всего?

Последний вопрос важнее остальных: он показывает, надо ли строить новое или достаточно достроить существующее. Про то, где вообще проходит граница между «хватит чата» и «нужен свой продукт», есть отдельный разбор - [задачу решает чат: зачем тогда свой продукт](/guides/chat-ili-svoy-produkt).

## Что делать, если нашлось похожее, но неудобное

**Главное**

Разбирать по частям. Готовое решение редко закрывает задачу полностью: обычно оно делает половину и делает её не так. Дальше выбор из трёх, и «собрать своё с нуля» - только один из них.

Самая частая ситуация после проверки: похожее есть, но пользоваться им никто не хочет.

Три исхода, между которыми стоит выбирать осознанно:

1. **Пользоваться как есть**

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

2. **Дособрать поверх**

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

3. **Делать своё**

   Когда расхождение принципиальное: другой процесс, другие данные, другая ответственность. Тогда решение осознанное, а не случайное.

Второй вариант недооценивают чаще всего. Многие задачи, которые формулируют как «нужна своя система», на деле требуют слоя поверх существующей: забрать данные, привести к своему виду, показать так, как удобно.

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

## Когда собирать своё всё-таки правильно?

**Главное**

Когда процесс действительно уникален, когда данные нельзя выносить наружу и когда готовое стоит дороже задачи. В этих трёх случаях [вайбкодинг](/concepts/vibecoding) оправдан и окупается быстро.

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

Признаки, при которых я сам берусь собирать:

- **Процесс правда свой.** Он вырос из вашей практики, и любое готовое решение придётся ломать под себя сильнее, чем строить с нуля.
- **Данные не должны уходить наружу.** Персональные данные, коммерческие условия, внутренняя аналитика. Тогда локальное решение выигрывает не по удобству, а по требованиям.
- **Цена готового несоразмерна.** Лицензия на команду стоит как годовая зарплата, а задача закрывается инструментом на один экран.
- **Нужна связка, которой нет ни у кого.** Данные из трёх систем, сведённые по своим правилам, - типовой случай, где готовое просто не существует.

Отдельно про масштаб. Даже когда решение принято в пользу своего, начинать надо не с полной системы, а с узкого куска, который проходит весь путь целиком. Логика такого старта разобрана в материале про то, [почему первая версия собирается насквозь](/guides/pervaya-versiya-naskvoz-a-ne-po-sloyam).

## Пять минут проверки перед стартом

**Главное**

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

Прогони по пунктам и запиши ответы. Именно запиши: устный ответ самому себе слишком легко проскочить.

1. Как эта работа делается сегодня и кем? Если ответ «никак», это отдельный сигнал.
2. Кто ещё в компании делает что-то похожее и что у него получилось?
3. За какие системы мы уже платим и что из них умеет часть этой задачи?
4. Что случится, если не делать ничего? Иногда ответ «ничего страшного».
5. Какой минимальный кусок задачи закроет большую часть боли?

**Как задать этот вопрос агенту**

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

Ещё один разворот этой же проверки - на уровне компании, а не задачи: с чего начинать внедрение и в каком порядке. Разбирал это в материале про то, [как внедрить ИИ в компании пошагово](/guides/kak-vnedrit-ii-v-kompanii-poshagovo).

## Частые вопросы

**Главное**

Что спрашивают чаще всего: сколько времени тратить на проверку, что делать при отказе коллег показывать своё, считается ли это шпионажем и как быть, если готовое нашлось после старта работы.

### Частые вопросы

**Сколько времени разумно потратить на проверку?**

Вечер на задачу масштаба недели, день на задачу масштаба квартала. Дальше начинается анализ ради анализа, а он не окупается.

**Коллега не хочет показывать свою таблицу. Что делать?**

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

**Мы уже начали делать своё и нашли готовое. Бросать?**

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

**А если готовое решение есть, но им никто не пользуется?**

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

## Главный вывод

**Главное**

Перед тем как строить, стоит потратить вечер на поиск уже существующего: у коллег, в оплаченных лицензиях, во вкладках знакомых сервисов. Своё решение от этого не отменяется, оно становится осознанным выбором.

Запомнить стоит одно: вопрос «нет ли уже такого» задаётся не для того, чтобы отказаться от идеи, а чтобы точнее её очертить. После проверки замысел почти всегда становится уже и полезнее.

Практический минимум на сегодня: возьми свою идею, найди человека, который делает похожую работу, и попроси показать её на экране. Десять минут разговора вместо недели разработки.

А ты уверен, что задача, которую ты собрался решать, уже не решена в соседнем отделе?

### Источники

- [Not invented here - синдром «изобретено не здесь», Википедия](https://en.wikipedia.org/wiki/Not_invented_here)
- [Shadow IT - решения, которые сотрудники заводят сами, Википедия](https://en.wikipedia.org/wiki/Shadow_IT)
- [Minimum viable product - минимально жизнеспособный продукт, Википедия](https://en.wikipedia.org/wiki/Minimum_viable_product)
- [Duplicate code - цена дублирования в разработке, Википедия](https://en.wikipedia.org/wiki/Duplicate_code)