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

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

См. также

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

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

21.08.2025    700    0    Gigantrop    0    

1

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

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

15.08.2025    627    0    izidavld    0    

7

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

14.08.2025    536    0    worker1c    1    

3

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

Бизнес-ТРИЗ – это технология для быстрого поиска решений нестандартных задач в бизнесе, благодаря которой разрешаются нерешаемые годами проблемы. Расскажем о том, как выявлять и устранять противоречия, превращать конфликты в источник прорывных идей и повышать идеальность решений.

13.08.2025    708    10    user1576201    0    

4

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

«Надо было не так», «Переделай», «Это же очевидно!» – такие слова могут выбить почву из-под ног. Долго училась принимать обратную связь без паники и самокопания – и готова поделиться работающими методами.

11.08.2025    705    0    SerjoginaMaria    2    

2

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

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

15.07.2025    657    0    user2100900    1    

0

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

Обычная жизнь человека в ИТ – это много-много общения. С заказчиками, коллегами и руководством. Но иногда происходят разговоры, после которых внутри вскипает океан эмоций. Поддавшись эмоциям, люди способны натворить много странных вещей, от которых не будет пользы ни самому «творцу», ни окружающим, ни делу. Расскажем о принципах конструктивного общения и алгоритме переговоров, позволяющем обсудить возможные решения проблемы и прийти к согласию.

14.07.2025    727    0    klimdw    0    

4

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

Подбор «идеального» 1С-разработчика часто упирается в шаблонные матрицы компетенций, которые плохо работают на практике. В этой статье рассмотрим метод интервью критических инцидентов, который помогает определить, какие качества сотрудников важны именно для вашей компании. Уделим внимание искусству задавать правильные вопросы: какие формулировки помогают раскрыть истинный уровень компетенций и на какие детали в ответах стоит обращать особое внимание. Наконец, разберемся, как структурировать полученные данные, чтобы создать четкий и объективный профиль компетенций.

03.07.2025    771    0    DuyunElena    0    

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

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