Завал в IT-компании и как с ним бороться

25.12.23

Команда - Коммуникации

Работа в режиме завала и в режиме нарастающего завала. Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию «наблюдателя» - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. Вот тут и начинается: "Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать «что-то»".

Работа в режиме завала и в режиме нарастающего завала

Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию «наблюдателя» - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. И тут начинается: "Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать «что-то»".

Логичным «чем-то» считается варианта два:

  1. Останавливаем конвейер и все дружно разгребаем завал.

  2. Продолжаем работать разгребая как-нибудь потому что есть какая-нибудь очень важная (только по мнению высшего начальства) причина. Мол остановишь, потом надо ждать час чтобы он разогрелся, а это потеря денег и крах всего.

Если идем по первому пути, то итог обычно один – завал разгребли, набрали темп, вернулись к работе – продолжили работать на качество. Денежка капает, начальство довольно, заказчик поворчал за срыв срока, но получил в итоге результат и успокоился.

А что, если идём по второму пути? Правильно!

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

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

 

Переведем завод на типичную компанию, предоставляющую IT-услуги

Конвейер - это отлаженная цепь от «хотелки» до «какой-то крутой штуки» для заказчика.

Участки (самая длинная возможная цепочка):

  1. Сам клиент как начальное звено конвейера которое выдает потребности как генератор случайных идей или крайне редко – четко сформулированных и качественно продуманных «хотелок». Его как правило боятся останавливать из-за той самой «очень важной причины» - мол клиент уйдет от нас, потом не вернем.

  2. Менеджер (руководитель проекта) - тот человек, который принимает поток потребностей клиента и определяет путь этой потребности дальше.

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

  4. Аналитик - когда есть, когда нету, но нужный человек в таком производстве. Он может также находится на участке 2-3 как человек, который превратит потребность Случайного генератора идей в оформленную задачу и вовремя сказать клиенту «Вася, ты болван! Давай думать, а не выдумывать» или же может играть роль человека, который скажет «вот вам кнопка, давайте проверим так ли хорошо». Такого человека можно назвать технолог на производстве и креативный упаковщик одновременно.

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

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

  1. Клиент на первом участке. Завал потребностей – генерация идей в режиме «я тут решил, но еще не подумал». К чему приводит? К тому что клиент не понимает, что ему нужно, когда ему это нужно и почему ему нужно именно это. Он просто выдаёт идеи и всегда недоволен результатом, но толкает эти идеи в реализацию ибо он заказчик и он «хочет». Плоха та компания, которая не может остудить пыл этого творца, но такие бывают и их очень много.

  2. Менеджер. Завал потребностей от разных клиентов (а у него таких довольно много и даже самый организованный человек может потерять себя в таком потоке и уйти в завал). К чему приводит? К тому что менеджер забывает задачи, не следит за их распределением и исполнением в срок, не успевает «остановить творца» из первого участка и просто отдаёт это дальше (ну некогда читать большой текст «хотелки», там ребятки разберутся сами).

  3. Программист. Завал задач из-за потока безумства первых двух участков, т.к. первым всегда надо качественно и прям сейчас, а вторых у каждого программиста больше одного. К чему приводит? К тому что программист не делает вовремя или делает вовремя но не следит за качеством решения, что ведет к браку, который вернётся бумерангом через пару дней и шарахнет. Еще и обидным словом обзовут, но ему не до этого..там со второго участка еще 15 прилетело на «сделать сейчас» и с четвертого вернули 3 из 3, которые сделать успел (тоже щас надо было).

  4. Аналитик. Завал потребностей к постановке и завал задач к сдаче. Он бедняга просто проверять не успевает, его то на первый участок дёрнут, то на третьем не всё понятно, то второй придёт с криками, что надо ему помочь – он рвётся, то пятый кричит, что он не так хотел (а ты ему говорил блин!) К чему приводит? К сдвигам сроков программистов и нарушению их горизонта планирования, к уплотнению встреч для сдачи работ клиенту, соответственно теряется время на вникание в потребности и отсев неадекватных задач, теряется время на «упаковку кнопки» и её заменяют на «вот вам, пошарьтесь сами, вроде то», а если заказчика оставить наедине, то это 99% возврат и прочие проблемы этого типа.

  5. Клиент на пятом участке. А ему просто лень вникнуть прям сейчас, он вникнет когда пригодится, если его вовремя четвёртый участок не дернет. К чему приводит? К «ах вы бестолочи, я вас просил еще месяц назад и говорил, что мне срочно надо, а вы уже месяц сделать нормально не можете, я из-за вас от генерального получил по шее и по карману» и возврату на участок #3. Теперь понимая возможные завалы подведём итог: Конвейер всегда двигается дальше и чем дальше он двигается тем ближе мы к следующему участку, кто-то создал завал - больше давят обстоятельства в виде того что надо подготовить деталь к следующему участку хотя бы как то и то что следующую деталь надо еще быстрее делать..и так по кругу Особенность сферы IT что почти каждая деталь уникальна и выработать механические действия нельзя, соответственно допустить завал на участке 3 не просто вредно, а критично для всех.

 

Итак, выводы из всей болтовни такие:

  1. Если чувствуем завал задач от клиента и это не внедрение, то что-то идет не так. Нужен кто-то, кто обработает этот поток, именно обработает, а не запишет на бумажку и отдаст первому попавшемуся программисту. Конкретно берем менеджера или аналитика, даем его клиенту, они садятся и определяют ответы на вопросы "Зачем", "Когда", "Почему именно тогда", может даже это куда-то записывают. В итоге должны получить из кучи "хотелок" нормально выстроенный список задач (или описания задач), с которым уже дальше можно работать. Участок разгружен.

  2. Если чувствуем завал задач от менеджера. Когда у менеджера завал, то вы увидете вечно бегающего из кабинета в кабинет менеджера, орущего на программистов за срыв сроков и параллельно впихивающего какому нибудь программисту еще одну задачу, сверх его возможностей.

Итак: Во-первых, менеджер один не справится с завалом. Дайте ему помощь - еще одного менеджера или аналитика. Во-вторых, задайте себе вопрос: не ли завала от каждого клиента, если есть то начинаем разгребать оттуда. В-третьих, никогда не пытайтесь впихнуть невпихуемое. Это не избавит вас от проблем, только добавит. Ничего страшного предложить клиенту сроки: "через неделю", "через месяц", "через год", или и вовсе отказать, если прям ну совсем никак. В-четвертых, не жалуемся, а решаем проблему. Многие менеджеры когда их задачу не берут идут кому-то жаловаться: своему начальству, начальству программистов, высокому начальству. В итоге если там разбираться не будут то впихнут невпихуемое. Лучше в данном случае собрать обратную связь от программистов и попросить помощи в порядке: "я попробовал обратиться вот туда и вот туда, тут сказали что могут через год, а тут сказали что не хватает компетенций для решения задачи клиента, помогите с решением". И самое главное: не хватайтесь за все и сразу, иначе все это упадет на пол и придавит сверху вместе с вами. Проще говоря, поставят за вами следить какого-нибудь начальника и он будет над вами висеть пока не разгребете весь завал (если вообще разгребете).

  1. Если чувствуем завал задач на плечах программиста. Когда у программиста завал, к нему будут бегать менеджеры, он будет прыгать от одной задачи к другой не успевая сделать ничего или делая, но это будет возвращаться десятками итераций. Первое что надо сделать это поставить на стоп все новые задачи. Нет смысла их брать, потому что "надо выполнять план" или "зарплата будет маленькая, потому что мало сделал". Чем дольше игнорируется завал при принятии новых задач, тем меньше вы будете делать и тем больше будете на слуху, а тут могут и задумать о вашем увольнении.. Далее надо все задачи распределить по срочности/важности. Тут можно рисовать всякие квадраты, записывать их в н бумажку и ставить цифры возле них, кому как удобнее. И последнее понять, можно ли что-то передать, если можно то лучше сделайте это.

  2. Если чувствуем завал у аналитика. Тут увидеть легко, у аналитика забит календарь встречами, и его поведение становится похожим на поведение менеджера в завале. Так же бегает от программиста к программисту, от клиента к клиенту. Тут важно понять с чем связан завал аналитика. Это может быть из-за завала от клиента/менеджера, тогда в первую очередь надо помочь это разгрести совместно с менеджером / с клиентом. Это может быть из-за завала программиста. Аналитик в таком случае не успевает сдавать задачи и возвращать задачи из-за брака. Здесь важно определить реальные сроки чтобы все сделать и проверить и договориться с менеджером / с клиентом о новых сроках. Ну и это естественно может быть из-за перебора задач. Зовем на помощь еще одного аналитика / менеджера.

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

Вот такие размышления были в моей голове. Жду от вас обратной связи. Слава Хейтерам.

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

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Инструменты управления проектом Коммуникации Agile Бесплатно (free)

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

25.05.2026    238    0    gulakovs    1    

0

Коммуникации Подбор персонала и собеседования Бесплатно (free)

Разберем, как замкнуть HR-цикл от подбора кандидата до оформления сотрудника в одной системе с помощью 1С:Кабинет сотрудника и 1С:Персонал. Рассмотрим этапы внедрения КЭДО, настройку личных кабинетов, маршрутов согласования и интеграций с рекрутинговыми площадками, а также подходы к мягкому внедрению изменений без сопротивления сотрудников. Покажем, как автоматизация помогает сократить время приема сотрудника, снизить нагрузку на HR и бухгалтерию, уменьшить количество ошибок и получить измеримый ROI уже в первые месяцы.

22.05.2026    251    0    ekandyba    0    

1

Коммуникации Лидерство Бесплатно (free)

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

05.05.2026    559    0    IgorVasilyev    6    

1

Коммуникации Кейсы проектов Внедрение изменений Бесплатно (free)

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

29.04.2026    530    0    APishchalnikov    0    

3

Коммуникации Внедрение изменений ITIL, Служба поддержки (HelpDesk) Бесплатно (free)

Цифровой проектный офис на 1С-Коннект демонстрирует, как модель UCaaS помогает выстроить прозрачные коммуникации, повысить качество поддержки и централизовать работу инхаус и аутсорс-команд. Показываем, как единое окно обслуживания, цифровые меню, автоматизированный мониторинг и расширенные инструменты контроля качества создают масштабируемую систему поддержки любого уровня. Особое внимание уделено AI-инструментам, которые усиливают коммуникационные процессы, автоматизируют ответы, формируют протоколы встреч и помогают оптимизировать нагрузку на первые линии. Материал будет полезен тем, кто стремится выстроить современную, гибкую и управляемую систему поддержки в проектном офисе или ОЦО.

29.04.2026    468    0    user1855793    0    

1

Коммуникации Бесплатно (free)

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

15.04.2026    936    0    IgorVasilyev    14    

10

Стандарты и документация Коммуникации Россия Бесплатно (free)

Как оценить зрелость команды 1С не по общему чек-листу, а по практикам, которые реально важны для платформы? Собрал модель из 8 направлений — от управления кодом и CI/CD до AI-практик — с конкретными критериями на каждом из пяти уровней. Внутри — открытый инструмент для самооценки.

08.04.2026    988    0    maraty    10    

3

Коммуникации Лидерство Бесплатно (free)

Заметки уставшего, но еще живого руководителя про чудеса на виражах управления между владельцем и командой. Или осознанные действия? Хочется чудес, но чаще выходит «не шмагла»…

02.04.2026    1360    0    klimdw    15    

16
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. lame 78 28.12.23 09:23 Сейчас в теме
Добрый день
согласен. но стоит добавить кадровый ресурс.
те как программист, так и аналитик - могут быть просто тупые,что бл пизц просто некомпетентные как в своей области, так и в понимании общей ситуации.
(извините за мой французский)

столкнулся сейчас именно с такой ситуацией
аналитик - гордый человек. дальше своего носа не видит.
Для отправки сообщения требуется регистрация/авторизация