НеСерьёзное 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 можно. Но делать ТЗ — лучше по-своему.

НеСерьёзное IT, выпуск 2

Сегодня с нами снова YoMan78 — и история о том, как одна шутка едва не уничтожила чемпионат среди пенсионеров.

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

Подмоченная репутация🤫
Году так примерно в 2006-м был у нас проект — достаточно крупная игровая платформа со своим покером и блэк-джеком для заказчиков из Бостона.

Команда была притертая, работали помногу, подолгу, кода написано было громадное громадье, включая свои фреймворки и библиотеки. Все это крутилось тогда еще на настоящем железе, без облаков, и моей обязанностью было это дело мониторить, изображая то ли девопса, то ли L3-поддержку.

Тут важно помнить, что в те времена деньги зарабатывать было куда сложнее, и ночные подъемы по тревоге — потому что покерный турнир не посчитал призы или стол застыл — были нормой.

Once upon a time я был на выходных на морях, и среди ночи зазвонил телефон. Наш CTO рассказал страшное: турнир завис.

*️⃣Это был чемпионат senior league, где играли стенка на стенку старички из домов престарелых (пансионов для богатых, кто не хочет задалбывать детей, а то и внуков своей деменцией). А подбил их на это непосредственно отец инвестора, который как раз в таком доме и жил.

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

Уже под утро выяснилось, что процесс рухнул при попытке выдать приз за 11-е место. То есть игрок уже вылетел, но на 11-е место они шутки ради назначили утешительный приз.

Проблема показала себя во всей красе, когда я увидел описание приза — "A heated bedpan for an old faggot". А что не так? Ну, казалось — пошутили и пошутили, но нет! Все уперлось в проектные требования.

Процесс упал, выдавая такой приз, потому что не смог записать это в базу из-за сработавшего триггера. В списке inadmissible words было слово "faggot", но по злой воле случая проверка на выдачу приза работала, а на создание турнира с таким призом из админки — нет.

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

Эпилог
Через пару дней скинули оплату за овертайм, и СТО даже зачитал письмо благодарности от одного из тех старичков. Дословно, конечно, не помню, но что-то вроде этого:

"Спасибо за то, что когда нас осталось 10 человек на последнем столе, вы сделали перерыв на пару часов. А то предыдущие перерывы были настолько короткие, что я даже до туалета дойти не успевал."

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

🥳Отличные новости! Мы участвуем в Центральноазиатском международном экономическом форуме (ЦМЭФ-2025) — одном из ключевых событий этого лета и всей международной экспедиции «Путешествие в сердце Евразии». Форум собирает более 500 участников из стран Центральной Азии и России: лидеров бизнеса, власти, науки и культуры.

Для нас это большая честь — выступать на одной сцене с крупнейшими представителями российского и международного бизнеса!

Сегодня Александр Сельдемиров, генеральный директор ITQuick, выступит в деловой программе форума о технологической независимости и трансформации рынка под влиянием цифровых сервисов и ИИ.

Мы искренне рады, что наш голос слышен на таких площадках. Это не только признание, но и вдохновение. Значит, то, что мы делаем — действительно важно и ценно.

Спасибо организаторам за приглашение и за возможность быть частью такого события🤗

Как ИТ-решения помогают бизнесу на этапе нестабильного роста❓

Момент нестабильного роста — это когда в компании всё вроде бы «хорошо», но уже тревожно: заявок больше, чем ресурсов, баги начинают сыпаться в прод, менеджеры бегают как оголённые провода, а ERP на 1С начинает сбоить в пик дня. Это не провал — но и не стабильность. И именно здесь ИТ-решения могут либо вытянуть бизнес вверх, либо зарыть его в бюрократию и “систему ради системы”.

❗️Главное — не перегнуть с автоматизацией
Ошибка многих команд — “автоматизировать всё”, не разобравшись, что реально тормозит бизнес. Иногда не нужна CRM “за миллион” — достаточно упорядочить процессы и завести Excel с правами доступа.

📈Подбирать инструменты под рост, а не под текущую боль
В момент подрагивающего роста важно выбирать решения, которые масштабируются. Не покупайте софт “под 5 менеджеров”, если через 3 месяца их будет 15. Лучше — модульные платформы, API-friendly инструменты и понятная интеграция с будущими системами.

❓ИТ — это не только про системы, но и про процессы
Новый таск-трекер не решит проблему, если команда не умеет декомпозировать задачи. А отчёты из BI-системы бесполезны, если бизнес не понимает, как на них реагировать. Перед внедрением — всегда диагностика процессов. Иногда “не работает” — это не про ИТ.

🌱Рост ≠ хаос. Нужно встроить “порядок в изменениях”
ИТ должно не тормозить, а поддерживать динамику. Важно выстраивать архитектуру изменений: фича-флаги, тестовые среды, CI/CD — всё, что позволяет вносить изменения быстро и безопасно.

👍Точка роста — лучшее время строить “будущий фундамент”
Да, может казаться, что “не до этого”. Но именно в этот момент можно сделать умные заделы: например, разнести систему авторизаций, чтобы потом не переписывать, или зашить в архитектуру поддержку разных ролей. Это дешево сейчас — и очень дорого потом, если упустить.

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

ЦМЭФ 2025 в Душанбе✨
Что будет с нами, когда ИИ начнёт создавать ИИ?

На днях прошёл ЦМЭФ — один из главных экономических форумов Центральной Азии. Более 500 участников из шести стран: бизнес, госструктуры, эксперты, медиа.

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

Один из ключевых треков — «Цифровизация и ИИ: будущее единого цифрового пространства». На нём выступил наш руководитель и сооснователь Jumse Александр Сельдемиров.

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

Основное из выступления:
1️⃣ИИ уже влияет на бизнес-процессы и принятие решений. Следующий шаг — ИИ, который будет проектировать другие ИИ. Это не фантастика, а ближайшее будущее.

2️⃣Для стран СНГ важно не просто «догонять» крупные рынки, а выстраивать собственные экосистемы: развивать цифровой суверенитет, удерживать экспертизу и данные, растить кадры и технологические команды.

3️⃣Внедрять ИИ можно только там, где уже есть порядок и зрелость: грамотная архитектура, оцифрованные процессы, прозрачные данные и желание меняться.

Центральная Азия активно формирует своё будущее — и мы точно хотим быть частью этого диалога!

*Инсайты с форума, если интересно, можно подсмотреть в канале Александра

**Фото любезно предоставлены Росконгрессом😎

«Мы просто хотели CRM, а получилось ERP» 👀
или как бизнес попадает в ловушку бесконечного "а давайте ещё вот это"

Типичная история:
— Нам нужна простая CRM. Чтобы заявки не терялись.
— Хорошо, вот прототип.
— Супер, только ещё бы сразу счёт выставлять…
— Добавим.
— И чтобы клиент видел статус.
— Сделаем.
— И чтобы склад подтягивался.
— Уже не CRM, но ладно.
— И чтобы бухгалтерия сразу видела, и с логистикой связать, и зарплату считать, и BI, и чат-ботов, и пуши, и мобилку...
— …Добро пожаловать в ERP.

Примерно так рождаются монстры, которых никто не просил, но все участвуют. Проект растёт как на дрожжах, бюджет пухнет, сроки уплывают, а команда не понимает, что делать в первую очередь. Заказчик уже сам запутался, чего хотел. А ведь всё начиналось с желания “упростить воронку продаж”.

Почему это плохо?
➖Нет приоритетов — всё важно, всё горит, ничего не работает.

➖Неясные цели — что значит “система должна помогать бизнесу”? Как измерим?

➖Раздутая архитектура — всё связано со всем, изменить одну кнопку — переделать три модуля.

➖Выгорание команды — “каждый день новые фичи, только без зарплаты”.

Как не попасть в эту ловушку:
✅Фиксируем MVP
Минимум, который решает бизнес-проблему. Прямо с таблицей “что входит / что нет”.

✅Делим проект на фазы
Сначала CRM, потом счета, потом склад. Без “всё сразу”.

✅Отслеживаем “ползущие” требования
“А давайте ещё вот это” — в бэклог, не в прод.

✅Смотрим в корень
Иногда “нам нужна интеграция с логистикой” — это просто “нам не перезванивают курьеры”.

✅Продуктовое мышление
Лучше сделать одну фичу, которая реально экономит деньги, чем три, которые “просто красиво”.

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