Завал в 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)

Давайте честно – пользователи не любят перемены. Особенно когда это касается учетных систем. В этих условиях для сохранения своей и пользовательской нервной системы важно выстроить грамотную линию поддержки: не только технической, но и психологической. Расскажем о попытках сгладить всесторонней поддержкой неизбежное раздражение пользователей в период перехода «Самоката» с Directum RX на 1С:ДО.

03.12.2024    163    0    user1852187    0    

2

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

Любой управленец периодически сталкивается с ситуациями, в которых необходимо принять волевое решение, но непонятно, с какого конца хвататься. Эдакий сферический конь висит перед носом и скалит зубы при попытке его потрогать. Страшно, но делать с этим что-то надо… Расскажем об универсальном алгоритме разбора ситуации и составлении плана действий по управленческим кейсам.

11.11.2024    369    6    dklimchuk    2    

3

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

Можно ли стать руководителем незнакомой команды, не владея стеком технологий продукта? Построить процесс найма и переформатировать структуру команд, сформировать инженерную стратегию и культуру разработки, выстроить процессы и наладить работу с продуктом? Расскажем о том, на что важно обратить внимание руководителю в новой команде.

06.11.2024    719    0    Kukabarra    2    

7

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

Шаблонное мышление у руководителя - плохо или хорошо? Как его избежать с помощью методики "6 шляп" мышления.

02.09.2024    828    0    ashtey    0    

2

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

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

25.07.2024    536    0    user1142961    0    

3

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

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

23.07.2024    1878    0    SerjoginaMaria    6    

13

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

Многие руководители считают, что сто человек работают в сто раз эффективнее, чем один. Однако масштабирование – нелинейный процесс. Производительность большой команды не всегда равна сумме производительностей ее членов. Как сделать так, чтобы члены команды усиливали друг друга, а не тормозили? Компания ИСВС проходила этот путь и знает ответ!

12.04.2024    4777    0    vasilnikol    19    

30

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

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

27.02.2024    2175    0    user1561517    3    

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

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