НеСерьёзное IT👨‍💻

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

Сегодняшней историей с нами поделился YoMan78. Садитесь поудобнее, сейчас будет SQL, Access и немного мести😇

Дисклеймер: все имена, места и названия вымышлены, стиль повествования сохранен для антуража.

История "Мстители"
Это было в древние времена, когда в интернет надо было дозваниваться, и каждый знал заклинание зюксельконнект. Мы и слов тогда таких не знали, фидо ушло, а баш еще не придумали.

В 1999-м, после экватора в универе, я устроился программистом в фирмочку, которая оптом торговала печатной продукцией — в первую очередь книгами, но не только.

По факту меня определили вычислительным придатком материального бухгалтера Натальи, которая пересчитывала столбики в Excel на калькуляторе Casio. Мы сидели с ней в дальней части подвала, за запертыми дверями. У меня даже была кнопка “слива” на случай налоговой проверки — надлежало оперативно зачищать серверные данные.

На складе трудились трое бойцов, одинаковых с лица: Женя, Женёк и Евгений Макарыч. Они принимали товар, собирали отгрузки и вообще отвечали за движуху. Я с помощью SQL, мата и лазерного принтера обеспечивал это шапито всем возможным: отчетами, пересортицами, переучётами, остатками. Всё было на Microsoft Access, к которому линковались FoxPro-файлики. В общем, магия XX века.

Складских офисные не любили, особенно после того как те выдули всю водку на Новый год. Взаимность была полной.

И вот как-то мне поручили распечатать для склада список остатков для переучета. Я сделал табличку в Access, распечатал. Но не удержался — вставил туда восемь позиций книг, которых не существовало в природе:
«Змеи Исландии. Малый справочник», «Мёртвые души. Том 2», «Над пропастью в чечевице»… и ещё что-то в этом духе.

Отчёт, конечно, шёл по алфавиту. Так что парни носились по всему складу, от А до Я, пытаясь найти книги-призраки. Когда они поняли, что Гоголь второй том не писал, был скандал.

А потом оказалось, что я не только пошутил с “закладками”, но ещё и SQL-запросом задвоил кучу позиций. LEFT JOIN по нескольким таблицам умножил result set — классика жанра. В результате — всех лишили премии.

Позже они подкидывали нам в кабинет крыс. Но это уже совсем другая история…

Как не слить бюджет, когда “понятно, что надо что-то делать — но непонятно, что именно”🤔

Такое случается часто: «Нужна какая-то система для управления заказами», «Хочется свою платформу, как у конкурентов» или «Давайте начнём делать MVP, а разберёмся по ходу».

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

Что делать в такой ситуации?
1️⃣Признать: задача пока не определена
Это не слабость, а нормальный рабочий этап. Даже у зрелых компаний бывают моменты, когда есть только направление, но нет структуры.
Главное — не вваливаться в “давайте хоть что-то делать”.

2️⃣Выделить “ядро” запроса
Что именно хочется улучшить/изменить/запустить?
Например: не “CRM под ключ”, а “потерянные заказы и путаница в клиентах”→ Это уже фокус.

3️⃣Собрать 3–5 ключевых ситуаций/проблем
Вместо общих описаний — конкретные истории:
➖“Клиент написал, менеджер не увидел”
➖“Есть отчёты, но никто ими не пользуется”
➖“Сделки ведутся в Excel, теряются файлы”
Эти кейсы — золото для аналитиков и архитекторов. На них строится реальная логика продукта.

4️⃣Определить, кто будет работать с будущей системой
Кто конечный пользователь? Что у него болит?
Разработка без понимания аудитории = продукт, который никому не нужен.

5️⃣Зафиксировать ограничения
Есть бюджет, сроки, стек, существующие системы, с которыми нужно дружить?
Всё это важно на старте, чтобы не строить воздушные замки.

6️⃣Привлечь аналитика или технического архитектора
Специалист поможет превратить “хочу” в структурированную задачу с блоками, связями и приоритетами.
Без этого проект будет шататься при первом же изменении.

Чем это полезно бизнесу?
Уходит неопределённость, снижается риск “переделок”, можно точно сформулировать объём MVP, появляется реальная смета и план и команда начинает разрабатывать, а не догадываться.

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

Если внутри компании туман, это не повод запускать разработку вслепую. Это повод начать с прояснения, чтобы потом двигаться быстро и по делу😎

Как проект “умирает” от слишком активного заказчика

Контроль — это прекрасно. Вовлечённый заказчик — вообще мечта. Но иногда мечта превращается в сюжет хоррора:
👻 ежедневные созвоны
👀 “покажите промежуточный результат через 2 часа”
🤓 “а я тут сам схему нарисовал, лучше, чем ваша”

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

Что начинает разваливаться первым?
➖Ответственность
“А смысл предлагать, если всё равно всё отменят?” — думает разработчик.
И начинает работать по принципу “Вы говорили — я делал”.

➖Продуктовое мышление
Когда каждое решение прилетает сверху, никакой инициативы не выживает. Только “как скажете”.

➖Скорость
Простой экран рисуется по 5 итераций: “А если синим? А можно чуть больше? А вернём как было?” → Итог: 3 недели на кнопку.

➖Фокус и мораль
Когда решения правят каждый день — команда начинает не “разрабатывать”, а “прятаться”.

А что действительно работает?
Чёткое понимание целей и метрик, нормальное ТЗ, а не голосовые по ночам, регулярные, но не круглосуточные созвоны, демки по спринтам — а не после каждой строчки кода, Jira, Notion и немного Zen, и главное — настрой: “мы вместе делаем продукт”, а не “вы делаете — я оцениваю”

Без доверия команде никакой контроль не поможет. Появляется только видимость управления, зато реальные проблемы множатся.

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

Чеклист: готовы ли вы к IT-разработке?🤔
Или почему даже “сильная идея” — это только половина дела

Кажется, что всё просто: есть идея → нужно нанять команду → и начать разрабатывать! Но именно на этом “просто” ломается каждый второй проект.

Сложности возникают чаще всего не из-за идеи, а неготовности к разработке: нет структуры, непонятен масштаб, забыты бизнес-цели. В итоге — постоянные переделки, сдвиги, ссоры с подрядчиком.

🤓Чтобы не попасть в эту ловушку — мы подготовили для вас короткий чеклист, который поможет понять, готовы ли вы к запуску IT-продукта:
✅ Есть ли ясная цель?
Что именно должен делать продукт и какую проблему он решает?
Если цели звучат как “ну, автоматизировать” — нужно копнуть поглубже.

✅Понимаете ли вы свою аудиторию?
Кто конечный пользователь? Чем он живёт? Какие задачи решает каждый день? Продукт, не основанный на реальных сценариях — будет неудобным и мёртвым.

✅Есть ли описанные процессы/логика?
Или всё только в голове? Если нет хотя бы черновых схем или бизнес-описаний, команда будет гадать — и часто не в ту сторону.

✅Известны ли ограничения?
По срокам, бюджету, платформам, интеграциям? Ограничения — не барьеры, а полезные рамки, которые помогают не растекаться.

✅Готовы ли вы к итерациям?
Не будет идеально с первого раза. Будет MVP, тестирование, обратная связь, доработки. Готовность к “неидеальности” — признак зрелого подхода.

✅Понимаете ли вы, что создание продукта — это процесс, а не разовая покупка?
Разработка — это инвестиция во что-то, что будет развиваться. Нужно быть готовыми к поддержке, развитию и масштабированию.

Если на все пункты уверенно ответили “да” — отлично, вы на старте зрелого IT-процесса.
Если на 2–3 вопроса “нет” — ничего страшного. Это как раз то, что помогает вам понять, с чего начать подготовку.

В ITQuick мы не просто начинаем писать код. Мы помогаем заказчикам пройти этот этап осознанно — от идеи до архитектурного плана. Чтобы разработка была не сюрпризом, а осмысленным процессом с прогнозируемым результатом😎

Почему “всё просто, нужно сделать как у Uber” — плохое ТЗ🤔
И как такие формулировки убивают бюджет, сроки и нервы всей команды

Слова “да там всё просто, сделайте как у Uber / Airbnb / Notion / CRM N” — звучат почти на каждом первом звонке. На первый взгляд — кажется, что так даже удобно: все уже понимают, о чём речь, есть референс и проще объяснять идею. Но на деле — это ловушка. Потому что “как у Uber” ≠ “просто”, и референс ≠ ТЗ.

Почему это плохой старт:
1️⃣У Uber — десятки команд, сотни фич и миллионы строк кода
Любой крупный сервис — это результат многих лет итераций, A/B-тестов, багфиксов и пользовательских исследований. “Как у Uber” — это не одна фича. Это сложная экосистема, архитектура, связки бэкенда и фронта, мобильные SDK, логика для каждой страны, продвинутый алгоритм маршрутизации, мониторинг и SLA.

Вы же хотите MVP? Или повторение всей платформы? → Без уточнений невозможно оценить ни сроки, ни стоимость.

2️⃣Непонятно, что именно нужно “как у Uber”
Интерфейс? Система рейтингов? Динамическое ценообразование? Геолокация в реальном времени? Архитектура под миллионы пользователей?

Без конкретизации такая формулировка — как сказать “хочу как в ресторане” и ожидать, что принесут любимое блюдо.

3️⃣Невозможно спланировать разработку
Команда должна работать с понятными сценариями: кто пользователь, какие действия он совершает, где и как это реализовано, какие ограничения и цели.

Если всё начинается с “сделайте как у Х”, то архитектура строится в воздухе. Итог: переделки, потери времени, всплывающие “а мы ещё забыли, что нужно...”.

Что делать вместо этого?
✅Определить бизнес-цель
Что именно вы хотите получить? Управление заявками? Онлайн-бронирование? Сервис вызова курьеров?

✅Опишите пользовательский сценарий
Как проходит “жизнь” пользователя в вашей системе? Что он делает шаг за шагом?

✅Уточните, что именно в Uber/Notion/другом нравится
Интерфейс? UX? Механика? Быстродействие? Подход к подписке?

✅Ограничьте масштаб
Если вы в старте — скажите об MVP. Если хотите полную платформу — нужно проработать архитектуру и этапы.

Пример переформулировки:
🫣“Сделайте как у Uber”
🤝“Нужна мобильная платформа, где пользователь видит ближайших исполнителей, может сделать заказ с геолокацией, оценить после выполнения и оплатить онлайн. Хочется, чтобы взаимодействие было таким же простым, как в Uber. Пока нужно MVP на один город и только под Android.” → Вот это уже основа для диалога, архитектуры и оценки.

В ITQuick мы умеем задавать правильные вопросы и переводить “хочу как у…” в понятные технические задачи. Потому что хороший проект начинается не с вдохновения, а с конкретики, сценариев и честных ожиданий.

Так что да — вдохновляться Uber можно. Но делать ТЗ — лучше по-своему.