[Из песочницы] Авторитет аналитика как фактор производительности команды
Основано на реальных событиях и собственном участии в них.
Пару лет назад, на моём прошлом месте работы, после очередной реорганизации стало на один отдел разработки больше.
И так как аналитиков было впритык, одному из разработчиков, назовем его, Вадим, предложили переквалифицироваться.
Разработчик был умелый, общительный, с удовольствием согласился, по этому внешне все спокойно это приняли. Новый отдел оформился организационно и принялся за работу.
Уже через несколько недель руководством было замечено что новый отдел работает медленнее, не укладывается в сроки и угрожает сорвать релиз. Первое что пришло в голову — вероятно, новый аналитик не справляется, надо ему помочь!
Т.к. из всех других аналитиков в компании только я занимался обучением людей, то меня и привлекли к этому благому делу.
Подоплека проблем мне была еще не известна, по этому я, приняв на веру убеждения руководства, принялся за работу.
Сразу надо сказать, что уже в начале я понял что Вадим пишет довольно приличные ТЗ, на основании того с чем уже работал (документы других аналитиков компании, в том числе и мои), дело пошло быстро, мы кое-чего подшлифовали, научились лучше формулировать цели и ограничения доработок и через две недели документы у Вадима стали гораздо лучше.
Но это не помогло.
Отдел продолжал отставать по срокам и руководство стало проявлять нетерпение.
Тогда, я решил поговорить с остальной командой и тут то мне и открылись бездны ада.
За одну встречу с ними я узнал следующее:
-Вадим вообще не умеет писать требования.
-Вадим упертый баран, не прислушивается к команде.
-Не умеет общаться с заказчиком.
-Похоже, он безнадежен как аналитик.
Сразу после этого я поговорил с Вадимом и внезапно всё стало ясно.
Проблема лежала далеко за пределами профессиональных навыков. Команда просто не воспринимала Вадима как аналитика.
В результате, у каждого была накоплена целая куча псевдообъективных претензий к его работе.
Члены команды требовали все его документы на ревью, придирались к формулировкам требований, спорили по каждому вопросу, доходя даже до прямого игнорирования требований, самодеятельности и попыток решать какие-то вопросы с заказчиком через голову Вадима.
При том, что когда он был просто разработчиком, никаких конфликтов у них не было.
Пришлось поработать «психотерапевтом».
В течении следующих двух недель я проводил коллективные встречи следующего содержания.
- Разбирал написанные Вадимом ТЗ, объясняя почему он сделал именно так, а не иначе
- Объяснял как правильно работать с требованиями и зачем
- Показывал абстрактные примеры исследования предметной области
После каждой встречи команда благодарила меня и говорила что теперь то ей все понятно и вообще, спасибо что рассказал.
Вадим же очень удивлялся. После первой же встречи, он тет-а-тет посетовал на то что говорил команде ровно то же самое что и я, но его слова воспринимались совсем по другому.
Тогда я рассказал ему в чем дело. Конечно, его это опечалило, но я приободрил его, сказав что со временем это пройдет.
Мы продолжили коллективные сеансы терапии и через непродолжительное время работа отдела вошла в норму.
А сейчас, Вадим, вообще, считается одном из лучших аналитиков моей бывшей компании.
В дальнейшем, мне пришлось еще раз столкнуться с такой ситуацией, но я уже был готов и не тратил время зря, сразу приступая к «психотерапии».
Так что если и вы столкнетесь с таким, не зацикливайтесь на навыках, посмотрите на людей.
© Megamozg
