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

Контроль — это прекрасно. Вовлечённый заказчик — вообще мечта. Но иногда мечта превращается в сюжет хоррора:
👻 ежедневные созвоны
👀 “покажите промежуточный результат через 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, потом счета, потом склад. Без “всё сразу”.

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

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

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

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

Один день из жизни разработчика👨‍💻
История выдумана, любые совпадения с реальностью случайны

Хотел утром “быстренько” закрыть таску из бэклога — там, казалось бы, пара строчек кода. Открыл, поправил, закоммитил… и тут конфликт в гите.

“Ладно, разрулю за пять минут”, — подумал я.

Через три часа я уже знал, кто из команды не делает pull неделями, кто случайно перезаписал чужой код, и почему баг, который мы фикcили в прошлом спринте, вернулся из мёртвых.

В итоге: таска на 15 минут ушла в прод только вечером. В бэклоге, кстати, еще три новых таких же “быстрых” задачки ждут...

Что будет определять успех продуктов в ближайшие годы😎

Вчера Александр Сельдемиров ходил на встречу с Михаилом Воробьёвым и словил кучу полезных инсайтов, которыми мы не можем не поделиться с любимыми подписчиками. Они обсуждали тенденции, которые, по их мнению, будут определять будущее IT и бизнеса в ближайшие 3–5 лет.

1️⃣Скорость интеграции — вопрос выживания
Побеждать будут продукты, которые можно встроить в инфраструктуру заказчика максимально быстро — за месяц, максимум два. Если интеграция занимает больше времени или ломает внутренние процессы компании — продукт обречён остаться «за бортом». Модель API First становится не просто трендом, а условием выживания. Бизнес хочет собирать решения как кубики Lego — быстро и безболезненно.

2️⃣Новый баланс ролей: человек — помощник ИИ
Сегодня ИИ помогает нам, но в ближайшие 2–3 года ситуация изменится: мы станем помощниками ИИ. Задача человека будет не соревноваться с алгоритмами, а уметь управлять их «оркестром» — подбирать, комбинировать и направлять разные модели под конкретные задачи. Скоро появятся команды, где вместо людей фронтенд пишет одна нейросеть, тесты — другая, бэкенд — третья, а человек выступит тимлидом для ИИ.

Новый вектор развития — погружение в специфику работы моделей и развитие способностей управления нейросетями. Как говорится, не можешь победить — возглавь👑

3️⃣Управление через цифры
Эмоциональное управление компаниями уходит в прошлое. Бизнес растёт эффективно только тогда, когда все процессы оцифрованы и измеримы. Чем больше метрик мы собираем и анализируем, тем выше точность управленческих решений — и тем проще привлекать инвесторов. Если хочешь расти быстрее рынка, инвестденьги и прозрачная аналитика — обязательны.

4️⃣Встречи с конкурентами — как источник роста
Парадоксально, но именно во времена турбулентности и стагнации рынка сотрудничество с конкурентами даёт мощный рывок. Совместные обсуждения, обмен опытом, поиск точек взаимодействия помогают всем участникам рынка выживать и развиваться. В Армении, например, председатели всех банков собираются раз в месяц, чтобы обсудить текущие задачи и обменяться идеями — и это работает.

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

Эти инсайты мы забрали со встречи с Михаилом Воробьёвым — и их уже достаточно, чтобы поменять взгляды на то, каким должен быть продукт и бизнес завтра.

Первый выпуск AI Candy Show с прекрасной Sabrin✨

Время идет и мы не стоим на месте — ITQuick запустили свое шоу AI Candy Show, в котором обсуждаем ИИ в обычной жизни и IT, зачем/где/какое нужно ПО, не забудем и про финтех. В общем будет интересно и полезно!

Для разогрева в первом выпуске подняли насущный вопрос для многих девушек — Где и как найти мужа айтишника?

В какие ссылки перейти, чтоб просто оказаться там?
© Монеточка

Spoiler: Ссылки на онлайн чаты с айтишниками дадим под следующим видео🤝

Если хотите поучаствовать в интервью и поделиться своим экспертным мнением, пишите в комментарии или Дмитрию

Традиционное заседание SPb CIO Club "PRO Лидерство и управление командой"😎

На следующей неделе Дмитрий Вирин, наш директор по развитию, выступит на заседании SPb CIO Club (профессиональное сообщество ИТ-директоров ведущих компаний Северо-Западного региона).

💭 Нам постоянно приходится искать хороших IT-шников и просматривать сотни резюме. В какой-то момент мы решили автоматизировать этот процесс и создали внутренний продукт Jumse.

О чем поговорим в рамках темы "Применение AI в оценке компетенций IT-специалистов"?
1. Как сэкономить время и повысить эффективность технических собеседований
2. Как генеративный ИИ помогает моделировать реальные практические задачи для кандидатов и сотрудников
3. Возможность для ИТ-директора\руководителя\тимлида видеть карту компетенций команды.
4. Применение для оценки внутренних сотрудников: выявление зон роста, формирование планов развития.
5. Примеры кейсов из разных отраслей (банки, ритейл, телеком).
6. Как изменились метрики: скорость подбора, точность найма, рост вовлеченности разработчиков.
7. Роль AI в формировании новых стандартов оценки специалистов.
8. Какие навыки и компетенции будут проверяться в первую очередь в ближайшие годы.

🗓 28 августа в 19:00
📍 м. Василеостровская, Уральская улица, дом 1, литера Ч

С нетерпением ждем встречи с вами и возможности обсудить все, что вам будет интересно о Jumse!

IT-словарь👨‍💻
Настоящий смысл слов познается только на личном опыте

Disclaimer: история выдумана, все совпадения случайны

Первый день в новой компании. Онбординг прошёл блестяще: выдали ноут, показали туалет и тут же скинули в баг-трекер. Всё, ты в команде, можно больше никому не представляться.

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

И вот ты уже не новичок. Ты полноценный член команды.
Потому что настоящий онбординг — это не ноут и туалет, а твой первый дедлайн, когда у тебя ещё нет доступа к половине сервисов, но таски уже в статусе In progress...