[Управление разработкой, Управление персоналом] Завал в IT-компании и как с ним бороться

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
05-Апр-2021 11:30

Цитировать

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

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

Если идем по первому пути, то итог обычно один – завал разгребли, набрали темп, вернулись к работе – продолжили работать на качество. Денежка капает, начальство довольно, заказчик поворчал за срыв срока, но получил в итоге результат и успокоился. А что, если идём по второму пути? Правильно! Завал растет, а если завал растет, то все участи выбиваются из общего темпа, детали делаются дольше, заказчики становятся злее, начальство орёт и все дружно остаются после смены и разгребают изрядно подросшую кучу, в некоторых случаях не один день! Или же люди пытаются подстроиться под ситуацию так чтобы другие участки страдали меньше и разгребался завал, т.е. перебегают с более дальних участков и начинают разгребать от начала участок за участком иначе до них результат будет идти часами и днями, а пинки под зад от наблюдателей, высшего начальства и заказчика летят всё больнее.. ну или обиднее.Переведем завод на типичную компанию, предоставляющую IT-услуги: Конвейер - это отлаженная цепь от «хотелки» до «какой-то крутой штуки» для заказчика. Участки (самая длинная возможная цепочка):

Сам клиент как начальное звено конвейера которое выдает потребности как генератор случайных идей или крайне редко – четко сформулированных и качественно продуманных «хотелок». Его как правило боятся останавливать из-за той самой «очень важной причины» - мол клиент уйдет от нас, потом не вернем.
Менеджер (руководитель проекта) - тот человек, который принимает поток потребностей клиента и определяет путь этой потребности дальше.
Программист - как правило не один, а несколько отделов где сидят программисты. Они являются "ресурсными центрами", как там внутри особо не важно, менеджер их рассматривает как возможный механизм превращения потребности клиента в решение для клиента ну или «тот, кто знает как сделать кнопку».
Аналитик - когда есть, когда нету, но нужный человек в таком производстве. Он может также находится на участке 2-3 как человек, который превратит потребность Случайного генератора идей в оформленную задачу и вовремя сказать клиенту «Вася, ты болван! Давай думать, а не выдумывать» или же может играть роль человека, который скажет «вот вам кнопка, давайте проверим так ли хорошо». Такого человека можно назвать технолог на производстве и креативный упаковщик одновременно.
Снова клиент - но тут правильнее назвать его Заказчик, потому что он заказал ту самую «крутую штуку» и ждет что сейчас ему её отгрузят и случится магия. Он же в дальнейшем будет являться службой контроля качества, потому что только его седой голове известно, что он хотел.

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

Клиент на первом участке. Завал потребностей – генерация идей в режиме «я тут решил, но еще не подумал». К чему приводит? К тому что клиент не понимает, что ему нужно, когда ему это нужно и почему ему нужно именно это. Он просто выдаёт идеи и всегда недоволен результатом, но толкает эти идеи в реализацию ибо он заказчик и он «хочет». Плоха та компания, которая не может остудить пыл этого творца, но такие бывают и их очень много.
Менеджер. Завал потребностей от разных клиентов (а у него таких довольно много и даже самый организованный человек может потерять себя в таком потоке и уйти в завал). К чему приводит? К тому что менеджер забывает задачи, не следит за их распределением и исполнением в срок, не успевает «остановить творца» из первого участка и просто отдаёт это дальше (ну некогда читать большой текст «хотелки», там ребятки разберутся сами).
Программист. Завал задач из-за потока безумства первых двух участков, т.к. первым всегда надо качественно и прям сейчас, а вторых у каждого программиста больше одного. К чему приводит? К тому что программист не делает вовремя или делает вовремя но не следит за качеством решения, что ведет к браку, который вернётся бумерангом через пару дней и шарахнет. Еще и обидным словом обзовут, но ему не до этого..там со второго участка еще 15 прилетело на «сделать сейчас» и с четвертого вернули 3 из 3, которые сделать успел (тоже щас надо было).
Аналитик. Завал потребностей к постановке и завал задач к сдаче. Он бедняга просто проверять не успевает, его то на первый участок дёрнут, то на третьем не всё понятно, то второй придёт с криками, что надо ему помочь – он рвётся, то пятый кричит, что он не так хотел (а ты ему говорил блин!) К чему приводит? К сдвигам сроков программистов и нарушению их горизонта планирования, к уплотнению встреч для сдачи работ клиенту, соответственно теряется время на вникание в потребности и отсев неадекватных задач, теряется время на «упаковку кнопки» и её заменяют на «вот вам, пошарьтесь сами, вроде то», а если заказчика оставить наедине, то это 99% возврат и прочие проблемы этого типа.
Клиент на пятом участке. А ему просто лень вникнуть прям сейчас, он вникнет когда пригодится, если его вовремя четвёртый участок не дернет. К чему приводит? К «ах вы бестолочи, я вас просил еще месяц назад и говорил, что мне срочно надо, а вы уже месяц сделать нормально не можете, я из-за вас от генерального получил по шее и по карману» и возврату на участок #3. Теперь понимая возможные завалы подведём итог: Конвейер всегда двигается дальше и чем дальше он двигается тем ближе мы к следующему участку, кто-то создал завал - больше давят обстоятельства в виде того что надо подготовить деталь к следующему участку хотя бы как то и то что следующую деталь надо еще быстрее делать..и так по кругу Особенность сферы IT что почти каждая деталь уникальна и выработать механические действия нельзя, соответственно допустить завал на участке 3 не просто вредно, а критично для всех.

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

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

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

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

Вот такие размышления были в моей голове. Жду от вас обратной связи. Слава Хейтерам.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_upravlenie (управление), #_upravlenie_komandoj (управление командой), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 19:54
Часовой пояс: UTC + 5