Так получилось, что в компаниях, где я работал, очень любили всякие тесты из арсенала HR. Всех – и руководителей, и рядовых исполнителей, прогоняли через эти тесты.
Тесты, как правило, определяли тип личности применительно к профессиональной деятельности – к чему человек наиболее склонен, что ему дается легко, какая деятельность заставляет напрягаться, а за что лучше вообще не браться.
К своему удивлению, мы обнаружили, что разные тесты выявляют примерно одни и те же наклонности. Если показал один тест, что человек, например, душа компании, рубаха-парень, то и остальные тесты дают схожие результаты.
Наверное, в этом нет ничего странного, тесты ведь строятся по одним и тем же принципам, и делят людей примерно на одни и те же типы личностей, придуманные учеными прошлого века.
Но лично мне такая сходимость результатов помогла поверить в типы личностей, и их влияние на профессиональную деятельность человека. К тому же, я имел возможность наблюдать людей с известными мне «портретами» в течение нескольких лет, и правильность характеристик только подтверждалась.
Не буду рассказывать про сами тесты – этой информации полно в интернете, да и ваши HR, если попросите, с радостью накидают вам с десяток.
Я хотел рассказать не о тестах, а о моих личных наблюдениях: как люди с разными характеристиками ведут себя в команде, какие роли исполняют хорошо, а за какие им лучше не браться, в какой работе и в какой момент кого лучше использовать (в хорошем смысле).
Рассказывать буду, в основном, на примере программистов и сис.админов. Иногда буду выходить за установленные пределы, т.к. в команде ИТ нескольких типов личности не было вообще, но они гуляли в соседних отделах.
Рассказывать буду на примере командных ролей Белбина — лично мне этот тест кажется наиболее удачным. Не слишком много типов, сложно запутаться, при этом много информации в интернете, и пройти тест не составит труда — тем, кто хочет.
Итак, тест Белбина делит людей на типы, согласно ролям в команде:
По результатам теста, обычно, человек имеет 2-3 ярко выраженные роли, редко — одну, совсем редко — ни одной, средненько так все. Обычно размазанность результата говорит о нечестном заполнении.
Итак, выходи по одному.
Конкретно для программистов роль не очень полезная, потому что не всегда, не каждый день нужная. Координатор хорошо умеет за короткий срок справляться с кризисной ситуацией.
Например, упал сервер. Иди железный, или виртуальный, или приложений. Ну чего там, все свои — сервер приложений, типа 1Сного, по непонятной причине сожрал всю память, весь процессор и зависла консоль.
Вроде ничего страшного — за редчайшими исключениями, потери данных не случится. Но пугает, стопорит и заставляет тупить в такой ситуации одно — цейтнот. Времени нет, людишки бегают со своими вечными «аааа, у меня машина под погрузку стоит!», или налог на прибыль через 2 часа сдать надо — не важно. Каркуши и кликуши всегда найдутся.
Так вот, подобная ситуация — идеальна для использования координатора. Он быстро берет ситуацию в свои руки, начинает отдавать четкие, короткие указания, обычно — по делу. Всем остальным надо просто заткнуться и выполнять, и тогда все получится.
Заметьте — у координатора получается не потому, что он самый умный, или опытный. Он просто не теряется, как остальные.
Если выключить цейтнот — например, уронить сервер в новогодние каникулы, когда людей нет, то с ситуацией справится любой чувак из команды. Но в цейтноте лучше всего это удается координатору.
Да, важное замечание — координатор хорошо справляется именно с руководством процессом решения проблемы, а не с самим решением.
Координатор, на первый взгляд, больше всего похож на того парня, которого мы привыкли называть руководителем. У нас среди менеджеров оказалось много координаторов, и они все радовались — эге-гей, даже тест подтвердил, что мы — руководители, это прям наш тип личности!
Но, увы, координатор — это, скорее, диспетчер, прораб для разнарядки, офис-менеджер, и т.д., ну вы поняли. Скажем так, это низший уровень управления, когда ты отдаешь приказы непосредственно, и на очень короткий промежуток времени – максимум на день. Что, собственно, и подтвердилось со временем.
В обычное, не кризисное время, координатор среди программистов приносит больше вреда, чем пользы. Начинает раздавать очевидные поручения, менять приоритеты на лету, типа «так, сбегай помоги Лилечке, она красивая», «эй, бросай свой OneScript и закрывай месяц!», «так, давай показывай прогресс, уже 15 минут прошло». Надо вовремя дать понять этому чуваку, что не надо лезть руководить тем, что работает. Наступит кризис – вот тогда и бери вожжи.
Ужас, конечно, если программистам попался начальник с таким типом личности – тогда, как говорится, бегаешь и «жопа в мыле» (идиоматическое выражение). Был у меня такой начальник, месяца на полтора меня хватило (или его, не помню).
Это, на мой взгляд, самая полезная роль в команде программистов. Мотиватор – это человек, который умеет двигать вперед других людей.
Он может вдохновить, приказать, может манипулировать, бросить вызов. Главное, наверное – он умеет подобрать нужные слова для конкретного человека. Потому что он либо от природы хороший психолог, либо чему-то такому научился, либо просто черт языкастый.
Двигать вперед и работу, и развитие команды, и саморазвитие конкретного человека, вовремя давая ему информацию или заставляя задуматься о чем-то вне контекста работы.
Почему мотиватор – самый полезный чувак для программистов? Потому что, как ни крути, мы с вами –ленивые слизни немного неповоротливые.
Но беда в том, что среди программистов и их начальников такие ребята встречаются крайне редко, а извне редко кто приходит программистов взбодрить. Заказчики, которые топают ногами и ставят дедлайны – это не мотиваторы, а, как правило, латентные паразиты.
Среди всех, кто у нас был оцифрован по Белбину, только два человека были выраженными мотиваторами, и все – за пределами ИТ. Потому примеров природных мотиваторов из программистов у меня нет.
Но есть и хорошая новость. Мотиватор – это то, чему можно научиться. Так круто, как у природных, вряд ли получится, по одной простой причине – им мотивировать интересно, а нам придется делать это через силу, по крайней мере поначалу.
Я достаточно долго учился у природных мотиваторов, кое-какие навыки сумел приобрести. По сравнению с теми ребятами я, конечно, лохушка беспонтовая, но в среде программистов с пивом тянул.
Про навыки мотиватора хорошо и много написано в книгах по прикладной психологии, эмоциональному лидерству, и вообще лидерству, ну и во всяком нон-фикшн, типа Трансерфинга.
Лично мое мнение – хотя бы один человек в команде обязательно должен стать мотиватором, хотя бы немного. Для этого придется постараться, но чего уж теперь. Можно тешить себя тем, что навыки мотивирования – очень универсальные, и их приобретение внесет правильный вклад в комплект увольнения.
Лично мне этот душа команды кажется самым бесполезным чуваком для программистов.
Это тот парень, который всех зовет пить пиво в пятницу после работы, или летом в поход, или затевает разговоры «за жизнь» во время работы, или первым кричит «парни, айда жрать!» в 12-00.
Не знаю, может это какие-то предубеждения, но меня такой программист (а он у нас в команде был) больше бесил, чем сплачивал с остальными. Настаивать не буду, но мне кажется, что насильно смешивать личное и рабочее – неправильно и вредно.
Оно прикольно, конечно, но плохо влияет на работу – а мы на работу, вроде как, работать пришли. Если я захочу пива попить, то найду с кем, и повод мне не нужен, и с организацией посиделок справлюсь как-нибудь.
Таких «душ компании» было много раньше, на заводах, в деревнях и небольших городах. Благодаря им в коллективе всегда существует две системы ценностей – профессиональная и бытовая, и они почти всегда конфликтуют.
Если ты хорошо и много/эффективно работаешь, то ты выпадаешь из бытовой системы ценностей – чай ведь не пьешь с 9-00 до 10-00. Соответственно, и наоборот – тот, кто знает больше всех анекдотов, историй про рыбалку, и приносит из дома самые вкусные пироги – редко бывает передовиком производства.
Но тут, повторяю, мое личное мнение. Собственно, как и все изложенное в статье. Если вам нравятся рубаха-парни в команде – на здоровье. Мне не нравятся. Поэтому я лимитировал длительность их историй о рыбалке :)
Мотиватор для команды важнее.
Перевод дурацкий, в оригинале он называется «resource investigator» — эксперт по ресурсам. В команде программистов, особенно внедренцев – чрезвычайно полезный парень.
Дипломат – это человек, которому интересно и легко строить внешние, по отношению к команде, связи. В наших реалиях – это связи с пользователями, заказчиками, собственниками, ЛПР и т.д.
Особенно такой человек незаменим, как вы понимаете, на внедрениях – там, где нужно проводить очень много работы с внешним окружением. Особенно это важно не на франч-внедрениях, где отношения, так сказать, на одну ночь, а в активных фикси-командах, которые нормальными темпами развивают корпоративную информационную систему предприятия.
Потому что долгосрочный успех команды, так или иначе, сильно зависит от внешнего окружения. Можно быть хоть самой-крутой-супер-пупер-командой, но если ваши друзья – только Лилечка из бухгалтерии и Серега из отдела продаж, а остальные вас считают сборищем самодовольных дебилов с конской зарплатой, то долго этот праздник не продлится.
Нам повезло – было целых два дипломата, так сказать, разного уровня.
Один – специалист по горизонтальным связям, который быстро завел множество связей (в хорошем смысле слова…хотя, кто его знает) с необремененными высокими должностями сотрудниками почти во всех отделах. Не то чтобы прям закадычными друзьями стали, но на адекватные просьбы о помощи реагировали почти радостно – хотели помочь хорошему парню. Мы, как команда, нагло использовали эти связи, если нам это было нужно для внедрения или изменений.
Второй – специалист по вертикальным связям, направленным вверх по лестнице. У этого парня был сознательно построен довольно устойчивый прямой канал коммуникаций с верхами – собственником, директором, топ-менеджерами.
Особенно помогал контакт с собственником и директором, т.к. с его помощью можно было очень значительно влиять на руководителей высокого и среднего звена, которые зачастую являются тормозом внедрений и изменений.
Получается, больше всего не повезло руководителям среднего звена – они попадали под пресс и сверху, и снизу, от двух слишком назойливых resource investigators.
Это человек, который любит придумывать идеи. Идеи – это его продукт, результат, которым он гордится. Неважно, будет кто-то эту идею реализовывать, или нет, генератору достаточно идею придумать и озвучить – и он считает, что хорошо потрудился и исполнил свою миссию.
Генераторов среди программистов достаточно много, ибо профессия у нас творческая. Генератор-программист, работающий на фиксе в обычной компании – типа завода или оптовой торговли – может, если расширит свой кругозор в смежных бизнес-областях, выйти за пределы ИТ и сделать впечатляющий карьерный рывок. Причина проста – среди нетворческих профессий генераторов идей очень мало, поэтому в смежных областях ощущается, прям физически, недостаток качественных идей.
Идеи типа «главбух придумал ЭДО подключить», или «финдир придумал на FIFO в упр.учете перейти», или «Директор по логистике придумал WMS внедрить», или «Директор по коммерции раскурил, что внедрение CRM повышает продажи на 10%» — фуфло, увы. Формально это – идеи, но их качество равно нулю.
Генератор-программист умеет придумывать качественные прикладные идеи, потому что, как это ни банально, он – программист. Посудите сами.
Если, например, подпустить идиота (не программиста) к формированию требований к информационной системе, то его идеи будут кормить bash.org. Все ведь слышали, хоть раз, идею о «большой красной кнопке» (еще зеленая бывает)? Еще часто идеи идиотов начинаются с фразы «Вот бы одинэска умела…», ну и там дальше бессмысленные фантазии начинаются, типа компьютер включать по утрам, формы круглыми рисовать, с мобильного телефона работать «как на компьютере» (= в толстом клиенте), персоналом управлять через экзоскелет и т.д.
Все эти идеи – бессмысленный набор букв, который не стоит и произносить, по одной простой причине – они нереализуемы, а потому – бесполезны. Ну, как идея «сделать мир во всем мире». Такие идеи произносятся идиотами только для одного – чтобы быть произнесенными.
Генератор-программист имеет одно ключевое отличие – его идеи контекстно-зависимые. Потому что он программист, особенно если еще и 1Сник, и у него всегда в голове есть что? Ограничения платформыбудь они неладны.
Ограничения платформы сидят в голове, как система координат, заставляя помнить, что можно, а что нельзя. Разумеется, эти ограничения расширяются постоянно – и платформавроде как, если верить зазеркалью, развивается, и внешние по отношению к 1С фреймворки прочно вошли в практику, но контекст определен всегда.
Конечно, всегда есть новые технологии, блокчейны, искусственные интеллекты, и всякие там opensource. Но если задать контрольный вопрос «На что способны современные ИТ-технологии?» программисту, то он ответит «на многое, но еще дохера чего не могут, идите вбивайте накладную и не мешайте OneScript раскуривать». А если задать тот же вопрос идиоту, то он ответит «На всё!».
Возвращаюсь к выходу за рамки ИТ. Теперь вы понимаете, почему идеи программиста, который разобрался, например, в логистике, будут ценны? Потому что он будет знать ограничения, и высказанная им идея уже прошла (в его голове) проверку по ограничениям. Хотя, конечно, в итоге остаются вопросы вроде «вот тут только не уверен, что так можно, надо погуглить и мануалы покурить» :)
А теперь возвращаемся к команде программистов. Генератор для них очень важен. В первую очередь, его наибольшая ценность – нестандартные решения в рамках ограничений. Генератор поможет избежать, например, тысяч строк говнокода, придумав небольшое решение для целого класса задач, на чем-нибудь типа компоновки.
Опять же, нестандартные решения – это не обязательно что-то из ряда вон. Иногда только генератор увидит возможность использования типового механизма там, где остальные видят только новый километр кода.
Но у команды с генератором может быть полно проблем.
Во-первых, генератор – нарцисс. Если он выдает идею, ее обязательно надо лайкнуть, иначе он серьезно обидится. Потому что он же, бедняжка, старался, думал, ночей не спал, а тут – холодное молчание в ответ.
Во-вторых, генератор в команде должен быть один. Если их будет двое, это будет кошмар – они обязательно начнут «меряться идеями», впадать в уныние и депрессию, если второй придумал что-то покруче. Нет, не так – унывать будет из-за того, что поддержали чужую идею.
Если их все-таки двое, то придется учиться правилам совместного проживания.
В-третьих, за генератором надо записывать. Лучше, конечно, его самого заставить это делать. Потому что у генераторов дырявая память, и если не записать идею, то он ее искренне придумает во второй раз, и вам снова придется лайкать и восхищаться. А если не запишет, но запомнит, то будет еще несколько лет припоминать – ага, я вам говорил, а вы проигнорировали, никогда меня не слушаете, бла-бла-бла.
Но все не так плохо. Генераторы вполне способны взрослеть и становиться адекватными. Помогает, как ни странно, уже упомянутая запись идей – куда-нибудь в информационную систему. Когда идея записана, генератор ее отпускает и перестает с ней носиться, как с писаной торбой.
Но главное произойдет потом. Когда генератор вернется к записанной ранее идее, он сам, первый, скажет, что идея лажовая. Потому что, если это нормальный генератор, и не ленится записывать, то список будет большим – сотни, тысячи идей – и никакого смысла за них цепляться не будет, можно смело вычеркивать брак. Потому что не страшно – новых идей еще миллион в голову придет.
Ну и не пытайтесь убедить генератора, что «идея – это ничто, вот продакшн – это результат». У него есть железный контраргумент – «ну давай, попробуй придумать идею сам, а я ее запрограммирую и выдам в продакшн». Муки творчества НЕгенератора того не стоят, да и эта скотина будет торчать рядом и потешаться.
Такие вещи лучше просто отпустить – каждому свое.
Еще его называют «критик». Это чувак, который умеет грамотно рассматривать решения, идеи, процессы, системы и выносить вердикты.
Например, он хорошо может прогнозировать результаты внесенных изменений. В нашей 1Сной практике это важно, сами знаете – надо понимать, как изменения в одном объекте метаданных могут повлиять на другой объект.
Среди программистов таких ребят довольно много, они не в дефиците. Наверное, аналитик – вообще распространенный тип личности для всех инженерных профессий.
В командной работе важно и полезно спрашивать мнение аналитика. Ему, как и всем перечисленным ранее типам, интересно анализировать и критиковать чужие идеи, предложения, планы и цели. Поэтому не переживайте, если подсовываете ему что-то для анализа – для аналитика это в кайф. Разумеется, если речь не о двух выгруженных в эксель оборотках, между которыми надо найти отличия.
Аналитик хорошо дополняет генератора идей, если они оба адекватные. Один придумывает идею, второй ее анализирует. Оба при деле, никому не обидно, всем интересно. Это можно превратить в игру.
Аналитик в команде программистов хорошо подходит на роль скрам-мастера – человека, который наблюдает за работой остальных и видит, на чем программисты тупят и теряют время. Ему это удается достаточно легко, потому что найти потерю для аналитика – кайф, ведь потеря – это ошибка в системе. Любимое блюдо аналитика.
Правда, из аналитика получится только половина скрам-мастера – та, которая увидел проблему. А как ее решить, аналитик не придумает – тут нужен генератор. А аналитик потом покритикует, примерит решение к проблеме, найдет нестыковки интерфейса, сообщит генератору, тот новое что-нибудь придумает и т.д.,до бесконечности, остановите их уже кто-нибудь, итеративно.
Есть две крайности в аналитике, за которыми надо следить.
Первая – перфекционизм и чрезмерная увлеченность. Если не задавать ограничений, то он будет анализировать расположение элементов на форме до бесконечности.
Вторая – не подпускайте его к системе, которая уже почти в продакшн. Аналитику плевать, что у вас там дедлайн и нервы на пределе, он будет тыкать всех носом в недостатки, «которые же очевидны, как вы не видите». Даже если это те же чуток сбитые привязки на форме. Отправьте анализировать следующий проект. Или пусть душа команды его в столовку сводит :).
Это самый распространенный тип личности – как среди программистов, так и среди сотрудников вообще.
Это человек, который будет делать то, что говорят. А то, чего не говорят, делать не будет.
Эта формула хорошо описывает и его достоинства, и недостатки. Если исполнителю правильно, вовремя ставить задачу, то он с высокой вероятностью ее выполнит. Ну а если выполнил, а следующей задачи нет, то что? Правильно, пойдет тупить на фейсбук. Или в столовку с душой команды.
Исполнители любят инструкции, планы, графики, процессы, системы и все такое прочее. Именно они формируют ту массу, которая радостно и безропотно помогает строить ад – потому что им так велели.
При этом исполнители – лучшая среда для внедрения изменений. Например, для перехода программистов на скрам. Достаточно четко, последовательно объяснить, что теперь задачи не вон там, а вон тут, на доске, и сроков у них больше нет, и фигачать надо не до конца задачи, а до конца недели.
А им особо без разницы, потому что у них четкая и понятная система координат на работе – если ты делаешь то, что велено, то ты молодец. Вот этим и надо пользоваться.
Иногда, конечно, бесят такие программисты – им же надо все разжевывать, и задачу, и процесс, и куда сходить, и с кем поговорить, и что почитать, и где файлики с остатками лежат. Но бесят они в том случае, если не знаешь тип личности. А когда знаешь – все, понятно, вот такой вот он чувак, и обращаться с ним надо именно так.
Самая страшная на свете гадость, которую делают исполнители в этом мире – становятся руководителями. Ведь для того, чтобы исполнитель руководил, кто-то должен руководить исполнителем. Не стратегически руководить, давая цели на год, а прям каждый день – задачи ставить, под запись в корпоративный блокнот, сроки, объяснять детали, обозначать ресурсы и т.д.
А потом этот руководитель-исполнитель идет к своим подчиненным, и начинается жевание соплей. Нет, как самому что-то сделать, исполнитель еще как-то понимает, а как это делегировать подчиненным, да еще отслеживать исполнение – аааа, лучше пристрелите меня.
Типичное поведение таких руководителей – «мне проще все сделать самому». На самом деле проще, потому что умеет делать, а не руководить. И проблема не в подчиненных, а в руководителе – как говорится, прошу прощения, «не хочешь с*ать, не мучай *опу».
Конечно, если кто-то когда-то напишет нормальную инструкцию «как руководить отделом», то у исполнителя все получится. Но это будет не исполнитель, а диспетчер.
А так – ничего, хорошие ребята. Если умеешь их готовить.
Раньше я думал, что специалист – этот тот же исполнитель, только узкоспециализированный, что ли.
Но, когда оказалось, что один из моих подчиненных сис.админов – специалист, я наконец-то понял, что с этим парнем не так.
Специалист – это человек, который нормально, с интересом и энтузиазмом решает задачи только в той области, которую он избрал, и в которой он действительно специалист.
Ни о какой исполнительности и речи нет. Но, в отличие от исполнителя, здесь есть энтузиазм.
Например, специалист у нас – по серверному оборудованию и ПО (и винда, и линукс). Если у вас, дай Бог, возникла серьезная задача по настройке серверов, да еще и задача не рядовая, а важная для компании – например, устранение уязвимости – этот парень будет сидеть в серверной сутками, без перерывов и выходных.
Просто потому, что ему это интересно – решать задачи по своей специализации.
А все остальные задачи он будет решать, спустя рукава. Или, как говорят про очень многих сисадминов, «будто в штаны навалил». Ни о какой исполнительности, дисциплине, сроках, качестве обычно речи не идет. Сделал – и то хорошо.
И, к сожалению, или к счастью, таких специалистов именно за их «специализм» и ценят. Потому что решение задачи, попавшей четко в круг интересов, в выходные и ночами, в системе ценностей почти любого руководителя выглядит как серьезная приверженность фирме.
Меня такие подходы долго бесили. Понимаю, интересно тебе с сервером копаться, но, блин, картриджи тоже кто-то менять должен, и витую пару иногда прокладывать приходится.
Но конкретно в нашем случае решение нашлось само – в связи с расширением взяли сисадмину помощника, пониже квалификацией, но – о счастье – исполнителя. И все, наступил порядок и гармония во всех делах, которые главный сисадмин не любил. А у него, наконец-то, появилось время вволю поковыряться в серверах, купить и настроить вторую циску, автопереключение на резервный канал интернета, поднять vpn между офисами и ууууу, там огромный список был, который он сам написал и с радостью делал.
Это шикарнейший тип личности, но вынужден огорчить – среди программистов мне его увидеть не довелось, в нашей команде такого не было.
Но был один яркий, насыщенный, природный финишер среди параллельных мне руководителей. С него и напишу портрет.
Финишер – это тот, кто умеет и любит доводить дела до конца. Дела – это и небольшие задачи, и большие проекты.
Никто в компании не умел так делать длинные проекты, как этот человек.
Судите сами. За время моих наблюдений человеку несколько раз выпадало руководить проектами, длительность которых составляла от 6 до 24 месяцев. Хорошие, большие проекты, с большими бюджетами, разноплановые.
Теперь угадайте, насколько промахивался человек с фактической датой завершения проектов? 1 день максимум! Это не шутка!
Причем, там не было никаких подгадываний, скрам-уловок, сокращения требований, размазывания задач по времени.
Во-первых, когда человека ставили руководить проектом, ему сразу говорили срок – точный, до дня. И никакого плана, только цель.
Человек, в обязательном порядке, составлял максимально полный и подробный план, бюджет, обозначал исполнителей и ресурсы, объем аутсорсинга. Все согласовывал, разумеется.
И делал. Точно в срок, все пункты плана. Понятно, что внутри проекта возникали отклонения – что-то затягивалось, где-то аутсорсеры подводили, или кассовый разрыв внезапный прерывал финансирование и, соответственно, некоторые работы или закупки. Как у всех, короче, это же жизнь.
Но важно не то, что происходило, а то, как на это реагирует руководитель. И вот этот, собака, финишер, от нас, обычных лоботрясов, отличается тем, что всегда найдет, как вернуться в график! У него даже мысли нет, что возникшими – объективными, внешними – препятствиями можно прикрыться, отмазаться, пересогласовать срок.
Его (финишера) ключевая компетенция – всегда понимать, что надо сделать, и сделать – то, что приведет к финишу. Финиш – это работа, выполненная в срок.
Я этой компетенцией искренне восхищаюсь, потому что я этому еще не научился. Но понимаю и очевидные минусы.
Главный минус – это постоянное, конвейерное производство суррогатов. Выше вы видели, что человек получает цель, и превращает ее в перечень задач, от которого потом почти не отступает. Такой подход – главный рассадник суррогата.
Для финишера цель проекта, его смысл и польза не имеют ровным счетом никакого значения. Все, что важно – правильный финиш. Он кайфует от того, что попал, как стрелок в мишень. Ну, или как в анекдоте – кайфует, когда бежал за автобусом, и успел вскочить на подножку. А потом спрашивает – а это какой номер?
Второстепенный, но тоже важный минус – финишер страшно, постоянно и больно выносит всем мозги. Если финишеру надо сделать проект, а ты, не дай Бог, стоишь у него на пути – не жди пощады. Хоть какая у тебя должность, репутация, авторитет – финишер до президента дойдет, но ты сделаешь то, что надо для его проекта. Подписывался ты, или в первый раз слышишь о его проекте – вынь да положь.
Но финишер – он хитрый, если адекватный. Вынесет тебе и всем мозги, пока идет проект, а потом, по окончании, придет, обнимет, приголубит, расплачется и скажет, что это не он плохой,а злая воля Сарумана гнала его по степям Средиземья директор заставил, а ты его лучший друг, и вовсе не хотел он на тебя кричать и жаловаться, просто вопрос жизни и смерти стоял, бла-бла-бла. И простишь, куда деваться. До следующего проекта.
Поэтому, лично я не стал у этого конкретного финишера чему-либо учиться – методы мне не нравятся. Но цель – научиться делать проекты вовремя – мне по душе.
Предваряя вопрос «а у тебя какой профиль по Белбину?», отвечу: Генератор идей + Критик + Дипломат. Могу придумать идею, могу обосрать чужую, могу сделать все чужими руками. Работаю медленно, плохо и только из-под палки.
Поняв это, я прогнал по тесту Белбина свою небольшую команду, и мы перераспределили обязанности, заменив недостающие компетенции и навыки.
В команде было, кроме меня, 4 программиста. У троих была ярко выражена роль Исполнитель, поэтому с них были сняты все обязанности, выходящие за ее рамки. Они стали меньше общаться с заказчиками и пользователями, т.к. не Дипломаты. И я, и они сами, перестали мучиться, выдавливая из себя идеи — это была моя работа.
Один из них оказался Душой команды, поэтому стал кем-то вроде медиатора — гасил конфликты, созывал всех на обед и побухать в выходные.
Но были и пробелы. Например, не хватало координации, этой роли не было ни у кого из нас. Поэтому мы просто заменили эту роль автоматизацией и методикой расстановки приоритетов, вроде этой. По сути, применили роли Генератор идей и Исполнитель, чтобы придумать и автоматизировать методику, заменяющую человека-координатора на координирующую машину.
Аналогично поступили и с ролью Финишера — в систему приоритетов добавили автоматическую балансировку, в зависимости от степени завершенности проекта. Не скажу, что прям мегакруто получилось — у тетки из статьи получалось лучше, но, в целом, результат устроил.
А вот роль Мотиватор пришлось-таки осваивать мне. Опыт тоже ценный, потому что, вроде бы, получилось. Об этом будет отдельная статья.
После всех этих модификаций нас перестали называть «программистами», «отделом информационных технологий» и т.п. — мы стали бандой. Это не мы так себя назвали, а один удрученный финансовый директор, так и не сумевший пробиться со своими глупостями через нашу круговую оборону.
Главное в модели Белбина, на мой взгляд — принять, понять и адаптироваться. Если в команде нет ни одного Генератора идей, то не надо фантазировать, что «да нам только волю дай, мы столько идей придумаем!». Если, черт побери, нет ни одного Исполнителя, то вообще ни черта не получится — все будут друг другом руководить, мотивировать, но работать будет некому. А если нет Координатора, то будет очень много бессмысленной, бесполезной, или даже вредной работы, которая никому не нужна.
Тесты, как правило, определяли тип личности применительно к профессиональной деятельности – к чему человек наиболее склонен, что ему дается легко, какая деятельность заставляет напрягаться, а за что лучше вообще не браться.
К своему удивлению, мы обнаружили, что разные тесты выявляют примерно одни и те же наклонности. Если показал один тест, что человек, например, душа компании, рубаха-парень, то и остальные тесты дают схожие результаты.
Наверное, в этом нет ничего странного, тесты ведь строятся по одним и тем же принципам, и делят людей примерно на одни и те же типы личностей, придуманные учеными прошлого века.
Но лично мне такая сходимость результатов помогла поверить в типы личностей, и их влияние на профессиональную деятельность человека. К тому же, я имел возможность наблюдать людей с известными мне «портретами» в течение нескольких лет, и правильность характеристик только подтверждалась.
Не буду рассказывать про сами тесты – этой информации полно в интернете, да и ваши 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Сник, и у него всегда в голове есть что? Ограничения платформы
Ограничения платформы сидят в голове, как система координат, заставляя помнить, что можно, а что нельзя. Разумеется, эти ограничения расширяются постоянно – и платформа
Конечно, всегда есть новые технологии, блокчейны, искусственные интеллекты, и всякие там opensource. Но если задать контрольный вопрос «На что способны современные ИТ-технологии?» программисту, то он ответит «на многое, но еще дохера чего не могут, идите вбивайте накладную и не мешайте OneScript раскуривать». А если задать тот же вопрос идиоту, то он ответит «На всё!».
Возвращаюсь к выходу за рамки ИТ. Теперь вы понимаете, почему идеи программиста, который разобрался, например, в логистике, будут ценны? Потому что он будет знать ограничения, и высказанная им идея уже прошла (в его голове) проверку по ограничениям. Хотя, конечно, в итоге остаются вопросы вроде «вот тут только не уверен, что так можно, надо погуглить и мануалы покурить» :)
А теперь возвращаемся к команде программистов. Генератор для них очень важен. В первую очередь, его наибольшая ценность – нестандартные решения в рамках ограничений. Генератор поможет избежать, например, тысяч строк говнокода, придумав небольшое решение для целого класса задач, на чем-нибудь типа компоновки.
Опять же, нестандартные решения – это не обязательно что-то из ряда вон. Иногда только генератор увидит возможность использования типового механизма там, где остальные видят только новый километр кода.
Но у команды с генератором может быть полно проблем.
Во-первых, генератор – нарцисс. Если он выдает идею, ее обязательно надо лайкнуть, иначе он серьезно обидится. Потому что он же, бедняжка, старался, думал, ночей не спал, а тут – холодное молчание в ответ.
Во-вторых, генератор в команде должен быть один. Если их будет двое, это будет кошмар – они обязательно начнут «меряться идеями», впадать в уныние и депрессию, если второй придумал что-то покруче. Нет, не так – унывать будет из-за того, что поддержали чужую идею.
Если их все-таки двое, то придется учиться правилам совместного проживания.
В-третьих, за генератором надо записывать. Лучше, конечно, его самого заставить это делать. Потому что у генераторов дырявая память, и если не записать идею, то он ее искренне придумает во второй раз, и вам снова придется лайкать и восхищаться. А если не запишет, но запомнит, то будет еще несколько лет припоминать – ага, я вам говорил, а вы проигнорировали, никогда меня не слушаете, бла-бла-бла.
Но все не так плохо. Генераторы вполне способны взрослеть и становиться адекватными. Помогает, как ни странно, уже упомянутая запись идей – куда-нибудь в информационную систему. Когда идея записана, генератор ее отпускает и перестает с ней носиться, как с писаной торбой.
Но главное произойдет потом. Когда генератор вернется к записанной ранее идее, он сам, первый, скажет, что идея лажовая. Потому что, если это нормальный генератор, и не ленится записывать, то список будет большим – сотни, тысячи идей – и никакого смысла за них цепляться не будет, можно смело вычеркивать брак. Потому что не страшно – новых идей еще миллион в голову придет.
Ну и не пытайтесь убедить генератора, что «идея – это ничто, вот продакшн – это результат». У него есть железный контраргумент – «ну давай, попробуй придумать идею сам, а я ее запрограммирую и выдам в продакшн». Муки творчества НЕгенератора того не стоят, да и эта скотина будет торчать рядом и потешаться.
Такие вещи лучше просто отпустить – каждому свое.
Аналитик
Еще его называют «критик». Это чувак, который умеет грамотно рассматривать решения, идеи, процессы, системы и выносить вердикты.
Например, он хорошо может прогнозировать результаты внесенных изменений. В нашей 1Сной практике это важно, сами знаете – надо понимать, как изменения в одном объекте метаданных могут повлиять на другой объект.
Среди программистов таких ребят довольно много, они не в дефиците. Наверное, аналитик – вообще распространенный тип личности для всех инженерных профессий.
В командной работе важно и полезно спрашивать мнение аналитика. Ему, как и всем перечисленным ранее типам, интересно анализировать и критиковать чужие идеи, предложения, планы и цели. Поэтому не переживайте, если подсовываете ему что-то для анализа – для аналитика это в кайф. Разумеется, если речь не о двух выгруженных в эксель оборотках, между которыми надо найти отличия.
Аналитик хорошо дополняет генератора идей, если они оба адекватные. Один придумывает идею, второй ее анализирует. Оба при деле, никому не обидно, всем интересно. Это можно превратить в игру.
Аналитик в команде программистов хорошо подходит на роль скрам-мастера – человека, который наблюдает за работой остальных и видит, на чем программисты тупят и теряют время. Ему это удается достаточно легко, потому что найти потерю для аналитика – кайф, ведь потеря – это ошибка в системе. Любимое блюдо аналитика.
Правда, из аналитика получится только половина скрам-мастера – та, которая увидел проблему. А как ее решить, аналитик не придумает – тут нужен генератор. А аналитик потом покритикует, примерит решение к проблеме, найдет нестыковки интерфейса, сообщит генератору, тот новое что-нибудь придумает и т.д.,
Есть две крайности в аналитике, за которыми надо следить.
Первая – перфекционизм и чрезмерная увлеченность. Если не задавать ограничений, то он будет анализировать расположение элементов на форме до бесконечности.
Вторая – не подпускайте его к системе, которая уже почти в продакшн. Аналитику плевать, что у вас там дедлайн и нервы на пределе, он будет тыкать всех носом в недостатки, «которые же очевидны, как вы не видите». Даже если это те же чуток сбитые привязки на форме. Отправьте анализировать следующий проект. Или пусть душа команды его в столовку сводит :).
Исполнитель
Это самый распространенный тип личности – как среди программистов, так и среди сотрудников вообще.
Это человек, который будет делать то, что говорят. А то, чего не говорят, делать не будет.
Эта формула хорошо описывает и его достоинства, и недостатки. Если исполнителю правильно, вовремя ставить задачу, то он с высокой вероятностью ее выполнит. Ну а если выполнил, а следующей задачи нет, то что? Правильно, пойдет тупить на фейсбук. Или в столовку с душой команды.
Исполнители любят инструкции, планы, графики, процессы, системы и все такое прочее. Именно они формируют ту массу, которая радостно и безропотно помогает строить ад – потому что им так велели.
При этом исполнители – лучшая среда для внедрения изменений. Например, для перехода программистов на скрам. Достаточно четко, последовательно объяснить, что теперь задачи не вон там, а вон тут, на доске, и сроков у них больше нет, и фигачать надо не до конца задачи, а до конца недели.
А им особо без разницы, потому что у них четкая и понятная система координат на работе – если ты делаешь то, что велено, то ты молодец. Вот этим и надо пользоваться.
Иногда, конечно, бесят такие программисты – им же надо все разжевывать, и задачу, и процесс, и куда сходить, и с кем поговорить, и что почитать, и где файлики с остатками лежат. Но бесят они в том случае, если не знаешь тип личности. А когда знаешь – все, понятно, вот такой вот он чувак, и обращаться с ним надо именно так.
Самая страшная на свете гадость, которую делают исполнители в этом мире – становятся руководителями. Ведь для того, чтобы исполнитель руководил, кто-то должен руководить исполнителем. Не стратегически руководить, давая цели на год, а прям каждый день – задачи ставить, под запись в корпоративный блокнот, сроки, объяснять детали, обозначать ресурсы и т.д.
А потом этот руководитель-исполнитель идет к своим подчиненным, и начинается жевание соплей. Нет, как самому что-то сделать, исполнитель еще как-то понимает, а как это делегировать подчиненным, да еще отслеживать исполнение – аааа, лучше пристрелите меня.
Типичное поведение таких руководителей – «мне проще все сделать самому». На самом деле проще, потому что умеет делать, а не руководить. И проблема не в подчиненных, а в руководителе – как говорится, прошу прощения, «не хочешь с*ать, не мучай *опу».
Конечно, если кто-то когда-то напишет нормальную инструкцию «как руководить отделом», то у исполнителя все получится. Но это будет не исполнитель, а диспетчер.
А так – ничего, хорошие ребята. Если умеешь их готовить.
Специалист
Раньше я думал, что специалист – этот тот же исполнитель, только узкоспециализированный, что ли.
Но, когда оказалось, что один из моих подчиненных сис.админов – специалист, я наконец-то понял, что с этим парнем не так.
Специалист – это человек, который нормально, с интересом и энтузиазмом решает задачи только в той области, которую он избрал, и в которой он действительно специалист.
Ни о какой исполнительности и речи нет. Но, в отличие от исполнителя, здесь есть энтузиазм.
Например, специалист у нас – по серверному оборудованию и ПО (и винда, и линукс). Если у вас, дай Бог, возникла серьезная задача по настройке серверов, да еще и задача не рядовая, а важная для компании – например, устранение уязвимости – этот парень будет сидеть в серверной сутками, без перерывов и выходных.
Просто потому, что ему это интересно – решать задачи по своей специализации.
А все остальные задачи он будет решать, спустя рукава. Или, как говорят про очень многих сисадминов, «будто в штаны навалил». Ни о какой исполнительности, дисциплине, сроках, качестве обычно речи не идет. Сделал – и то хорошо.
И, к сожалению, или к счастью, таких специалистов именно за их «специализм» и ценят. Потому что решение задачи, попавшей четко в круг интересов, в выходные и ночами, в системе ценностей почти любого руководителя выглядит как серьезная приверженность фирме.
Меня такие подходы долго бесили. Понимаю, интересно тебе с сервером копаться, но, блин, картриджи тоже кто-то менять должен, и витую пару иногда прокладывать приходится.
Но конкретно в нашем случае решение нашлось само – в связи с расширением взяли сисадмину помощника, пониже квалификацией, но – о счастье – исполнителя. И все, наступил порядок и гармония во всех делах, которые главный сисадмин не любил. А у него, наконец-то, появилось время вволю поковыряться в серверах, купить и настроить вторую циску, автопереключение на резервный канал интернета, поднять vpn между офисами и ууууу, там огромный список был, который он сам написал и с радостью делал.
Финишер
Это шикарнейший тип личности, но вынужден огорчить – среди программистов мне его увидеть не довелось, в нашей команде такого не было.
Но был один яркий, насыщенный, природный финишер среди параллельных мне руководителей. С него и напишу портрет.
Финишер – это тот, кто умеет и любит доводить дела до конца. Дела – это и небольшие задачи, и большие проекты.
Никто в компании не умел так делать длинные проекты, как этот человек.
Судите сами. За время моих наблюдений человеку несколько раз выпадало руководить проектами, длительность которых составляла от 6 до 24 месяцев. Хорошие, большие проекты, с большими бюджетами, разноплановые.
Теперь угадайте, насколько промахивался человек с фактической датой завершения проектов? 1 день максимум! Это не шутка!
Причем, там не было никаких подгадываний, скрам-уловок, сокращения требований, размазывания задач по времени.
Во-первых, когда человека ставили руководить проектом, ему сразу говорили срок – точный, до дня. И никакого плана, только цель.
Человек, в обязательном порядке, составлял максимально полный и подробный план, бюджет, обозначал исполнителей и ресурсы, объем аутсорсинга. Все согласовывал, разумеется.
И делал. Точно в срок, все пункты плана. Понятно, что внутри проекта возникали отклонения – что-то затягивалось, где-то аутсорсеры подводили, или кассовый разрыв внезапный прерывал финансирование и, соответственно, некоторые работы или закупки. Как у всех, короче, это же жизнь.
Но важно не то, что происходило, а то, как на это реагирует руководитель. И вот этот, собака, финишер, от нас, обычных лоботрясов, отличается тем, что всегда найдет, как вернуться в график! У него даже мысли нет, что возникшими – объективными, внешними – препятствиями можно прикрыться, отмазаться, пересогласовать срок.
Его (финишера) ключевая компетенция – всегда понимать, что надо сделать, и сделать – то, что приведет к финишу. Финиш – это работа, выполненная в срок.
Я этой компетенцией искренне восхищаюсь, потому что я этому еще не научился. Но понимаю и очевидные минусы.
Главный минус – это постоянное, конвейерное производство суррогатов. Выше вы видели, что человек получает цель, и превращает ее в перечень задач, от которого потом почти не отступает. Такой подход – главный рассадник суррогата.
Для финишера цель проекта, его смысл и польза не имеют ровным счетом никакого значения. Все, что важно – правильный финиш. Он кайфует от того, что попал, как стрелок в мишень. Ну, или как в анекдоте – кайфует, когда бежал за автобусом, и успел вскочить на подножку. А потом спрашивает – а это какой номер?
Второстепенный, но тоже важный минус – финишер страшно, постоянно и больно выносит всем мозги. Если финишеру надо сделать проект, а ты, не дай Бог, стоишь у него на пути – не жди пощады. Хоть какая у тебя должность, репутация, авторитет – финишер до президента дойдет, но ты сделаешь то, что надо для его проекта. Подписывался ты, или в первый раз слышишь о его проекте – вынь да положь.
Но финишер – он хитрый, если адекватный. Вынесет тебе и всем мозги, пока идет проект, а потом, по окончании, придет, обнимет, приголубит, расплачется и скажет, что это не он плохой,
Поэтому, лично я не стал у этого конкретного финишера чему-либо учиться – методы мне не нравятся. Но цель – научиться делать проекты вовремя – мне по душе.
Моя банда
Предваряя вопрос «а у тебя какой профиль по Белбину?», отвечу: Генератор идей + Критик + Дипломат. Могу придумать идею, могу обосрать чужую, могу сделать все чужими руками. Работаю медленно, плохо и только из-под палки.
Поняв это, я прогнал по тесту Белбина свою небольшую команду, и мы перераспределили обязанности, заменив недостающие компетенции и навыки.
В команде было, кроме меня, 4 программиста. У троих была ярко выражена роль Исполнитель, поэтому с них были сняты все обязанности, выходящие за ее рамки. Они стали меньше общаться с заказчиками и пользователями, т.к. не Дипломаты. И я, и они сами, перестали мучиться, выдавливая из себя идеи — это была моя работа.
Один из них оказался Душой команды, поэтому стал кем-то вроде медиатора — гасил конфликты, созывал всех на обед и побухать в выходные.
Но были и пробелы. Например, не хватало координации, этой роли не было ни у кого из нас. Поэтому мы просто заменили эту роль автоматизацией и методикой расстановки приоритетов, вроде этой. По сути, применили роли Генератор идей и Исполнитель, чтобы придумать и автоматизировать методику, заменяющую человека-координатора на координирующую машину.
Аналогично поступили и с ролью Финишера — в систему приоритетов добавили автоматическую балансировку, в зависимости от степени завершенности проекта. Не скажу, что прям мегакруто получилось — у тетки из статьи получалось лучше, но, в целом, результат устроил.
А вот роль Мотиватор пришлось-таки осваивать мне. Опыт тоже ценный, потому что, вроде бы, получилось. Об этом будет отдельная статья.
После всех этих модификаций нас перестали называть «программистами», «отделом информационных технологий» и т.п. — мы стали бандой. Это не мы так себя назвали, а один удрученный финансовый директор, так и не сумевший пробиться со своими глупостями через нашу круговую оборону.
Главное в модели Белбина, на мой взгляд — принять, понять и адаптироваться. Если в команде нет ни одного Генератора идей, то не надо фантазировать, что «да нам только волю дай, мы столько идей придумаем!». Если, черт побери, нет ни одного Исполнителя, то вообще ни черта не получится — все будут друг другом руководить, мотивировать, но работать будет некому. А если нет Координатора, то будет очень много бессмысленной, бесполезной, или даже вредной работы, которая никому не нужна.
