Хабрахабр

А кто в вашей банде?

Так получилось, что в компаниях, где я работал, очень любили всякие тесты из арсенала HR. Всех – и руководителей, и рядовых исполнителей, прогоняли через эти тесты.

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

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

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

К тому же, я имел возможность наблюдать людей с известными мне «портретами» в течение нескольких лет, и правильность характеристик только подтверждалась. Но лично мне такая сходимость результатов помогла поверить в типы личностей, и их влияние на профессиональную деятельность человека.

Не буду рассказывать про сами тесты – этой информации полно в интернете, да и ваши HR, если попросите, с радостью накидают вам с десяток.

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

Иногда буду выходить за установленные пределы, т.к. Рассказывать буду, в основном, на примере программистов и сис.админов. в команде ИТ нескольких типов личности не было вообще, но они гуляли в соседних отделах.

Система координат

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

Итак, тест Белбина делит людей на типы, согласно ролям в команде:

  • Координатор (Coordinator) – тот, кто умеет и любит управлять на оперативном уровне;
  • Мотиватор (Shaper) – тот, кто умеет и любит двигать работу вперед, грубо говоря, «подгоняя» людей положительной и отрицательной мотивацией;
  • Душа команды (Team Worker) – тот, кто умеет сплотить команду (в основном – бесцельно), быть всем другом;
  • Дипломат (по-другому – Снабженец, Resource Investigator) – тот, кто умеет взаимодействовать с другими командами и окружением вообще;
  • Генератор идей (Plant) – тот, кто умеет и любит придумывать новые идеи по всем аспектам работы команды;
  • Аналитик (Monitor Evaluator) – тот, кто умеет анализировать варианты, смотреть вперед и видеть ошибки;
  • Исполнитель (Implementer) – тот, кто любит просто делать то, что ему говорят;
  • Специалист (Specialist) – похож на Исполнителя, но хорошо понимает конкретно выделенную область;
  • Финишер (Completer Finisher) – тот, кто умеет и любит организовывать доведение дел до конца.

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

Итак, выходи по одному.

Координатор

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

Иди железный, или виртуальный, или приложений. Например, упал сервер. Ну чего там, все свои — сервер приложений, типа 1Сного, по непонятной причине сожрал всю память, весь процессор и зависла консоль.

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

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

Он просто не теряется, как остальные. Заметьте — у координатора получается не потому, что он самый умный, или опытный.

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

Да, важное замечание — координатор хорошо справляется именно с руководством процессом решения проблемы, а не с самим решением.

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

Скажем так, это низший уровень управления, когда ты отдаешь приказы непосредственно, и на очень короткий промежуток времени – максимум на день. Но, увы, координатор — это, скорее, диспетчер, прораб для разнарядки, офис-менеджер, и т.д., ну вы поняли. Что, собственно, и подтвердилось со временем.

Начинает раздавать очевидные поручения, менять приоритеты на лету, типа «так, сбегай помоги Лилечке, она красивая», «эй, бросай свой OneScript и закрывай месяц!», «так, давай показывай прогресс, уже 15 минут прошло». В обычное, не кризисное время, координатор среди программистов приносит больше вреда, чем пользы. Наступит кризис – вот тогда и бери вожжи. Надо вовремя дать понять этому чуваку, что не надо лезть руководить тем, что работает.

Был у меня такой начальник, месяца на полтора меня хватило (или его, не помню). Ужас, конечно, если программистам попался начальник с таким типом личности – тогда, как говорится, бегаешь и «жопа в мыле» (идиоматическое выражение).

Мотиватор

Это, на мой взгляд, самая полезная роль в команде программистов. Мотиватор – это человек, который умеет двигать вперед других людей.

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

Двигать вперед и работу, и развитие команды, и саморазвитие конкретного человека, вовремя давая ему информацию или заставляя задуматься о чем-то вне контекста работы.

Потому что, как ни крути, мы с вами – ленивые слизни немного неповоротливые. Почему мотиватор – самый полезный чувак для программистов?

Заказчики, которые топают ногами и ставят дедлайны – это не мотиваторы, а, как правило, латентные паразиты. Но беда в том, что среди программистов и их начальников такие ребята встречаются крайне редко, а извне редко кто приходит программистов взбодрить.

Потому примеров природных мотиваторов из программистов у меня нет. Среди всех, кто у нас был оцифрован по Белбину, только два человека были выраженными мотиваторами, и все – за пределами ИТ.

Мотиватор – это то, чему можно научиться. Но есть и хорошая новость. Так круто, как у природных, вряд ли получится, по одной простой причине – им мотивировать интересно, а нам придется делать это через силу, по крайней мере поначалу.

По сравнению с теми ребятами я, конечно, лохушка беспонтовая, но в среде программистов с пивом тянул. Я достаточно долго учился у природных мотиваторов, кое-какие навыки сумел приобрести.

Про навыки мотиватора хорошо и много написано в книгах по прикладной психологии, эмоциональному лидерству, и вообще лидерству, ну и во всяком нон-фикшн, типа Трансерфинга.

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

Душа команды

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

Это тот парень, который всех зовет пить пиво в пятницу после работы, или летом в поход, или затевает разговоры «за жизнь» во время работы, или первым кричит «парни, айда жрать!» в 12-00.

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

Если я захочу пива попить, то найду с кем, и повод мне не нужен, и с организацией посиделок справлюсь как-нибудь. Оно прикольно, конечно, но плохо влияет на работу – а мы на работу, вроде как, работать пришли.

Благодаря им в коллективе всегда существует две системы ценностей – профессиональная и бытовая, и они почти всегда конфликтуют. Таких «душ компании» было много раньше, на заводах, в деревнях и небольших городах.

Соответственно, и наоборот – тот, кто знает больше всех анекдотов, историй про рыбалку, и приносит из дома самые вкусные пироги – редко бывает передовиком производства. Если ты хорошо и много/эффективно работаешь, то ты выпадаешь из бытовой системы ценностей – чай ведь не пьешь с 9-00 до 10-00.

Собственно, как и все изложенное в статье. Но тут, повторяю, мое личное мнение. Мне не нравятся. Если вам нравятся рубаха-парни в команде – на здоровье. Поэтому я лимитировал длительность их историй о рыбалке 🙂

Мотиватор для команды важнее.

Дипломат

Перевод дурацкий, в оригинале он называется «resource investigator» — эксперт по ресурсам. В команде программистов, особенно внедренцев – чрезвычайно полезный парень.

В наших реалиях – это связи с пользователями, заказчиками, собственниками, ЛПР и т.д. Дипломат – это человек, которому интересно и легко строить внешние, по отношению к команде, связи.

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

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

Нам повезло – было целых два дипломата, так сказать, разного уровня.

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

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

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

Получается, больше всего не повезло руководителям среднего звена – они попадали под пресс и сверху, и снизу, от двух слишком назойливых resource investigators.

Генератор идей

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

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

Формально это – идеи, но их качество равно нулю. Идеи типа «главбух придумал ЭДО подключить», или «финдир придумал на FIFO в упр.учете перейти», или «Директор по логистике придумал WMS внедрить», или «Директор по коммерции раскурил, что внедрение CRM повышает продажи на 10%» — фуфло, увы.

Посудите сами. Генератор-программист умеет придумывать качественные прикладные идеи, потому что, как это ни банально, он – программист.

Все ведь слышали, хоть раз, идею о «большой красной кнопке» (еще зеленая бывает)? Если, например, подпустить идиота (не программиста) к формированию требований к информационной системе, то его идеи будут кормить bash.org. Еще часто идеи идиотов начинаются с фразы «Вот бы одинэска умела…», ну и там дальше бессмысленные фантазии начинаются, типа компьютер включать по утрам, формы круглыми рисовать, с мобильного телефона работать «как на компьютере» (= в толстом клиенте), персоналом управлять через экзоскелет и т.д.

Ну, как идея «сделать мир во всем мире». Все эти идеи – бессмысленный набор букв, который не стоит и произносить, по одной простой причине – они нереализуемы, а потому – бесполезны. Такие идеи произносятся идиотами только для одного – чтобы быть произнесенными.

Потому что он программист, особенно если еще и 1Сник, и у него всегда в голове есть что? Генератор-программист имеет одно ключевое отличие – его идеи контекстно-зависимые. Ограничения платформы будь они неладны.

Разумеется, эти ограничения расширяются постоянно – и платформа вроде как, если верить зазеркалью, развивается, и внешние по отношению к 1С фреймворки прочно вошли в практику, но контекст определен всегда. Ограничения платформы сидят в голове, как система координат, заставляя помнить, что можно, а что нельзя.

Но если задать контрольный вопрос «На что способны современные ИТ-технологии?» программисту, то он ответит «на многое, но еще дохера чего не могут, идите вбивайте накладную и не мешайте OneScript раскуривать». Конечно, всегда есть новые технологии, блокчейны, искусственные интеллекты, и всякие там opensource. А если задать тот же вопрос идиоту, то он ответит «На всё!».

Теперь вы понимаете, почему идеи программиста, который разобрался, например, в логистике, будут ценны? Возвращаюсь к выходу за рамки ИТ. Хотя, конечно, в итоге остаются вопросы вроде «вот тут только не уверен, что так можно, надо погуглить и мануалы покурить» 🙂 Потому что он будет знать ограничения, и высказанная им идея уже прошла (в его голове) проверку по ограничениям.

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

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

Но у команды с генератором может быть полно проблем.

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

Если их будет двое, это будет кошмар – они обязательно начнут «меряться идеями», впадать в уныние и депрессию, если второй придумал что-то покруче. Во-вторых, генератор в команде должен быть один. Нет, не так – унывать будет из-за того, что поддержали чужую идею.

Если их все-таки двое, то придется учиться правилам совместного проживания.

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

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

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

У него есть железный контраргумент – «ну давай, попробуй придумать идею сам, а я ее запрограммирую и выдам в продакшн». Ну и не пытайтесь убедить генератора, что «идея – это ничто, вот продакшн – это результат». Муки творчества НЕгенератора того не стоят, да и эта скотина будет торчать рядом и потешаться.

Такие вещи лучше просто отпустить – каждому свое.

Аналитик

Еще его называют «критик». Это чувак, который умеет грамотно рассматривать решения, идеи, процессы, системы и выносить вердикты.

В нашей 1Сной практике это важно, сами знаете – надо понимать, как изменения в одном объекте метаданных могут повлиять на другой объект. Например, он хорошо может прогнозировать результаты внесенных изменений.

Наверное, аналитик – вообще распространенный тип личности для всех инженерных профессий. Среди программистов таких ребят довольно много, они не в дефиците.

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

Один придумывает идею, второй ее анализирует. Аналитик хорошо дополняет генератора идей, если они оба адекватные. Это можно превратить в игру. Оба при деле, никому не обидно, всем интересно.

Ему это удается достаточно легко, потому что найти потерю для аналитика – кайф, ведь потеря – это ошибка в системе. Аналитик в команде программистов хорошо подходит на роль скрам-мастера – человека, который наблюдает за работой остальных и видит, на чем программисты тупят и теряют время. Любимое блюдо аналитика.

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

Есть две крайности в аналитике, за которыми надо следить.

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

Аналитику плевать, что у вас там дедлайн и нервы на пределе, он будет тыкать всех носом в недостатки, «которые же очевидны, как вы не видите». Вторая – не подпускайте его к системе, которая уже почти в продакшн. Отправьте анализировать следующий проект. Даже если это те же чуток сбитые привязки на форме. Или пусть душа команды его в столовку сводит :).

Исполнитель

Это самый распространенный тип личности – как среди программистов, так и среди сотрудников вообще.

А то, чего не говорят, делать не будет. Это человек, который будет делать то, что говорят.

Если исполнителю правильно, вовремя ставить задачу, то он с высокой вероятностью ее выполнит. Эта формула хорошо описывает и его достоинства, и недостатки. Правильно, пойдет тупить на фейсбук. Ну а если выполнил, а следующей задачи нет, то что? Или в столовку с душой команды.

Именно они формируют ту массу, которая радостно и безропотно помогает строить ад – потому что им так велели. Исполнители любят инструкции, планы, графики, процессы, системы и все такое прочее.

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

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

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

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

Нет, как самому что-то сделать, исполнитель еще как-то понимает, а как это делегировать подчиненным, да еще отслеживать исполнение – аааа, лучше пристрелите меня. А потом этот руководитель-исполнитель идет к своим подчиненным, и начинается жевание соплей.

На самом деле проще, потому что умеет делать, а не руководить. Типичное поведение таких руководителей – «мне проще все сделать самому». И проблема не в подчиненных, а в руководителе – как говорится, прошу прощения, «не хочешь с*ать, не мучай *опу».

Но это будет не исполнитель, а диспетчер. Конечно, если кто-то когда-то напишет нормальную инструкцию «как руководить отделом», то у исполнителя все получится.

Если умеешь их готовить. А так – ничего, хорошие ребята.

Специалист

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

Но, когда оказалось, что один из моих подчиненных сис.админов – специалист, я наконец-то понял, что с этим парнем не так.

Специалист – это человек, который нормально, с интересом и энтузиазмом решает задачи только в той области, которую он избрал, и в которой он действительно специалист.

Но, в отличие от исполнителя, здесь есть энтузиазм. Ни о какой исполнительности и речи нет.

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

Просто потому, что ему это интересно – решать задачи по своей специализации.

Или, как говорят про очень многих сисадминов, «будто в штаны навалил». А все остальные задачи он будет решать, спустя рукава. Сделал – и то хорошо. Ни о какой исполнительности, дисциплине, сроках, качестве обычно речи не идет.

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

Понимаю, интересно тебе с сервером копаться, но, блин, картриджи тоже кто-то менять должен, и витую пару иногда прокладывать приходится. Меня такие подходы долго бесили.

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

Финишер

Это шикарнейший тип личности, но вынужден огорчить – среди программистов мне его увидеть не довелось, в нашей команде такого не было.

С него и напишу портрет. Но был один яркий, насыщенный, природный финишер среди параллельных мне руководителей.

Дела – это и небольшие задачи, и большие проекты. Финишер – это тот, кто умеет и любит доводить дела до конца.

Никто в компании не умел так делать длинные проекты, как этот человек.

За время моих наблюдений человеку несколько раз выпадало руководить проектами, длительность которых составляла от 6 до 24 месяцев. Судите сами. Хорошие, большие проекты, с большими бюджетами, разноплановые.

1 день максимум! Теперь угадайте, насколько промахивался человек с фактической датой завершения проектов? Это не шутка!

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

И никакого плана, только цель. Во-первых, когда человека ставили руководить проектом, ему сразу говорили срок – точный, до дня.

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

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

И вот этот, собака, финишер, от нас, обычных лоботрясов, отличается тем, что всегда найдет, как вернуться в график! Но важно не то, что происходило, а то, как на это реагирует руководитель. У него даже мысли нет, что возникшими – объективными, внешними – препятствиями можно прикрыться, отмазаться, пересогласовать срок.

Финиш – это работа, выполненная в срок. Его (финишера) ключевая компетенция – всегда понимать, что надо сделать, и сделать – то, что приведет к финишу.

Но понимаю и очевидные минусы. Я этой компетенцией искренне восхищаюсь, потому что я этому еще не научился.

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

Все, что важно – правильный финиш. Для финишера цель проекта, его смысл и польза не имеют ровным счетом никакого значения. Ну, или как в анекдоте – кайфует, когда бежал за автобусом, и успел вскочить на подножку. Он кайфует от того, что попал, как стрелок в мишень. А потом спрашивает – а это какой номер?

Если финишеру надо сделать проект, а ты, не дай Бог, стоишь у него на пути – не жди пощады. Второстепенный, но тоже важный минус – финишер страшно, постоянно и больно выносит всем мозги. Подписывался ты, или в первый раз слышишь о его проекте – вынь да положь. Хоть какая у тебя должность, репутация, авторитет – финишер до президента дойдет, но ты сделаешь то, что надо для его проекта.

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

Но цель – научиться делать проекты вовремя – мне по душе. Поэтому, лично я не стал у этого конкретного финишера чему-либо учиться – методы мне не нравятся.

Моя банда

Предваряя вопрос «а у тебя какой профиль по Белбину?», отвечу: Генератор идей + Критик + Дипломат. Могу придумать идею, могу обосрать чужую, могу сделать все чужими руками. Работаю медленно, плохо и только из-под палки.

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

У троих была ярко выражена роль Исполнитель, поэтому с них были сняты все обязанности, выходящие за ее рамки. В команде было, кроме меня, 4 программиста. не Дипломаты. Они стали меньше общаться с заказчиками и пользователями, т.к. И я, и они сами, перестали мучиться, выдавливая из себя идеи — это была моя работа.

Один из них оказался Душой команды, поэтому стал кем-то вроде медиатора — гасил конфликты, созывал всех на обед и побухать в выходные.

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

Не скажу, что прям мегакруто получилось — у тетки из статьи получалось лучше, но, в целом, результат устроил. Аналогично поступили и с ролью Финишера — в систему приоритетов добавили автоматическую балансировку, в зависимости от степени завершенности проекта.

Опыт тоже ценный, потому что, вроде бы, получилось. А вот роль Мотиватор пришлось-таки осваивать мне. Об этом будет отдельная статья.

— мы стали бандой. После всех этих модификаций нас перестали называть «программистами», «отделом информационных технологий» и т.п. Это не мы так себя назвали, а один удрученный финансовый директор, так и не сумевший пробиться со своими глупостями через нашу круговую оборону.

Если в команде нет ни одного Генератора идей, то не надо фантазировать, что «да нам только волю дай, мы столько идей придумаем!». Главное в модели Белбина, на мой взгляд — принять, понять и адаптироваться. А если нет Координатора, то будет очень много бессмысленной, бесполезной, или даже вредной работы, которая никому не нужна. Если, черт побери, нет ни одного Исполнителя, то вообще ни черта не получится — все будут друг другом руководить, мотивировать, но работать будет некому.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть