Авторитет аналитика как фактор производительности команды

в 13:34, , рубрики: аналитика, люди, отношения с коллегами, управление персоналом, Учебный процесс в IT

Основано на реальных событиях и собственном участии в них.

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

Уже через несколько недель руководством было замечено что новый отдел работает медленнее, не укладывается в сроки и угрожает сорвать релиз. Первое что пришло в голову — вероятно, новый аналитик не справляется, надо ему помочь!

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

Отдел продолжал отставать по срокам и руководство стало проявлять нетерпение.

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

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

Сразу после этого я поговорил с Вадимом и внезапно всё стало ясно.
Проблема лежала далеко за пределами профессиональных навыков. Команда просто не воспринимала Вадима как аналитика.
В результате, у каждого была накоплена целая куча псевдообъективных претензий к его работе.
Члены команды требовали все его документы на ревью, придирались к формулировкам требований, спорили по каждому вопросу, доходя даже до прямого игнорирования требований, самодеятельности и попыток решать какие-то вопросы с заказчиком через голову Вадима.
При том, что когда он был просто разработчиком, никаких конфликтов у них не было.

Пришлось поработать «психотерапевтом».

В течении следующих двух недель я проводил коллективные встречи следующего содержания.

  • Разбирал написанные Вадимом ТЗ, объясняя почему он сделал именно так, а не иначе
  • Объяснял как правильно работать с требованиями и зачем
  • Показывал абстрактные примеры исследования предметной области

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

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

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

Так что если и вы столкнетесь с таким, не зацикливайтесь на навыках, посмотрите на людей.

Автор: davvol

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js