НеСерьёзное 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 мы часто сталкиваемся с тем, что у бизнеса есть желание, но нет чёткой постановки. Поэтому до старта пишем предпроектную аналитику: собираем реальные процессы, превращаем их в понятные блоки и только потом проектируем архитектуру.

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