Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Командообразование

Модель Белбина для IT сила и слабость разных команд

05.11.2020 12:07:06 | Автор: admin
В работе с некоторыми командами бывают ситуации, когда что-то работает само, и об этом не надо думать. Сами доделываются задачи, сама развёртывается Continuous Integration есть люди, которые этим занимаются, и за рабочими процессами не нужно специально следить. Но в других командах это само не происходит.

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

Максим Цепков IT-архитектор и бизнес-аналитик, навигатор и эксперт по миру Agile, работающий с самыми разнообразными системами от бирюзовых организаций до Спиральной динамики. О моделях Белбина Максим рассказывает часто (смотрите семинар, доклад на SPMconf и на COMAQA, а также статью о ролях).

Сегодня мы публикуем расшифровку доклада, посвященного модели команд по Белбину, с которым Максим выступил на конференции TeamLead Conf 2020.




Что предлагает Рэймонд Мередит Белбин


Исследование Белбина


В 60-х годах прошлого века, когда мир приходил в себя после войны, психологи начали переносить опыт формирования военных команд на гражданские. Рэймонд Белбин провел исследование психологии и поведения человека, поставив себе задачу разобраться, как устроены успешные команды. Для этого у него была роскошная возможность формировать неудачные команды, чтобы разобраться в механике и понять причины провала.
Модель была встроена в полугодовой курс повышения квалификации менеджеров (английский аналог МВА) как имитация по развитию бизнеса в условиях неопределенности в коммуникации с окружением. Но соревновались команды реальных менеджеров, развивающих бизнес и пришедших повышать квалификацию.

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

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

Также Реймонд выяснил, что, понимая модель, даже неудачная команда может компенсировать свои слабые стороны и тоже достичь успеха. Об этом у Белбина написано две книги:



Читать их стоит именно в таком порядке. Хотя половина контекста там перекрывается, они про разное: первая больше про историю исследований, а вторая про подбор и формирование команды. На официальном сайте belbin.com есть много материалов для тех, кто заинтересуется темой всерьез, включая научные исследования применения модели. Многие из тех, кто практикует эту систему, являются научными сотрудниками и выступают на ежегодных профессиональных конференциях.

Содержание модели Белбина


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

Белбин выявил 9 командных ролей и выяснил, что у каждого человека есть от одной до трех предпочтительных ролей:



Реймонд протестировал людей на эти роли, после чего смог описать:
  • Конфигурации ролей для сильных и слабых команд;
  • Рекомендации по формированию сильной команды;
  • Способы компенсировать конкретные слабости команды.

Позднее Rob Thomsett, американский исследователь, адаптировал модель Белбина для IT на него ссылается Эдвард Йордан в своей книге Смертельный марш. В книге, кстати, есть список из 20 причин провальных IT-проектов.

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

Сегодня я расскажу про проблемы команды, а по мере рассказа покажу роли, которые описал Белбин.

Проблемы команды


Много идей и разговоров, но работа движется слабо


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

Диагноз: в команде нет людей на две роли исполнителя:

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

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

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

Нет идей, ступор при проблемах и затруднениях


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

Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли Генератор и Исследователь ресурсов, и они совсем разные:

Генератор (Plant) активно порождает оригинальные идеи и видит самореализацию в их воплощении. Он горит своими идеями, причем не очень важно, насколько они подходят проекту. Запилить какую-нибудь сложную систему фреймворка, декларативное описание форм, еще что-то, что не очень нужно, зато прикольно и красиво это про него. У Генератора есть важная черта когда он придумал идею и хочет реализовать ее, то он нацелен на то, чтобы она пригодилась и была рабочей.

Исследователь ресурсов (Resource Investigator) не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить и т.д. Он загорается ими и видит самореализацию в их адаптации и воплощении.

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

Бесконечные споры между конкурирующими идеями


Бывает и противоположная ситуация, когда существуют бесконечные споры между конкурирующими идеями. Например, как сделать общение фронтенда с бэкендом по разным паттернам. Или как использовать промежуточные транспортные Java-объекты: какими способами, какие нужны фреймворки и паттерны, использовать ли отдельно для каждого класса фабрику для порождения объектов или нет, и т.д.

Диагноз: в команде несколько конкурирующих Генераторов или Исследователей ресурсов, конкурирующих за реализацию своих идей. Два Генератора в команде такая же плохая идея, как и ни одного.

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть. Например, в одном из проектов я был Генератором и придумывал новые идеи. Но руководитель проекта тоже видел свою реализацию в придумывании новых идей. Я это засек и начал ему оппонировать без выдвижения своих идей, переключившись на роль Аналитика-стратега (которая тоже у меня есть). И это сработало.

Реализация сложных идей не продвигает к результату


Бывает и так, что идеи есть, но они сложные. В этом случае команда либо не движется к результату, либо останавливается где-то на полпути. Это случается, когда есть мощный генератор, придумывающий новые сложные фреймворки и идеи, и которые сразу идут в реализацию. Но потом выясняется, например, что декларативное описание форм, которое он придумал, 100% проблем не решает, и даже 50% решает с трудом. Он его усложняет, но все кейсы и особые случаи все равно не натягиваются, и начинается ступор.

Диагноз: идеи от Генератора принимаются без критики, потому что у него нет достойного оппонента Аналитика-старатега, или не получается обсуждение.

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

Основная задача Аналитика-стратега (Monitor Evaluator) оценивать идеи и варианты, искать истину и синтезировать сложное решение с учетом всех нюансов. Если его в команде нет, ревью постановок и обсуждения нужно специально фасилитировать, потому что Генераторы харизматичны, но обидчивы.

Паралич принятия решений


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

Примеры:
  • Способ реализации непонятной задачи: Давайте еще поисследуем. Мы посмотрели три фреймворка и нужно делать выбор. Но у каждого есть свои плюсы и минусы. Что же делать? Давайте еще поисследуем.
  • Определение исполнителя для задачи с неясными перспективами решения. Есть противная задача: написать сложную алгоритмику системы скидок или комиссий, которую придумали маркетологи. Но никому не хочется этим заниматься.
  • Релиз с дефектами. При выпуске релиза определили список дефектов. И дальше релиз либо нужно выпускать в таком виде, считая, что дефекты не так страшны (ведь пользователи ждут функционал), либо отсрочить выпуск релиза. Лучше всего сразу принять решение. Но бывают ситуации, в которых наступает паралич кажется, что дефекты магическим образом исправятся за последние два дня, оставшиеся до даты выхода
.
Диагноз: нет руководителей Координатора или Шейпера.

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

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

Шейпер (Shaper) это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: Идем туда!

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

Слишком уверенный лидер


Противоположная ситуация.

Диагноз: у руководителя-Шейпера нет уважаемого им оппонента (Координатора или Аналитика-стратега) для обсуждения решений. Это обратная сторона Шейпера без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий. Как и Генератору, оппонент нужен ему для обсуждения решений.

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

Лечение: создать внешние механизмы обратной связи для проверки курса движения команд, если нельзя найти оппонента в команде чтобы у Шейпера были оппоненты для проверки курса движения. Если вы знаете, что у команды харизматичный лидер и есть опасность, что он заведет не туда, то периодически его решения нужно проверять. Причем у Шейпера в этом месте слепая зона он не может сам оценить выбранный им курс. Хотя со временем он может прокачаться и оценивать свою работу адекватно.

Непродуктивная команда звезд


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

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

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

Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что кто-то должен быть арбитром. Успешность команды звезд была одной из первых гипотез Белбина, которую он проверил. Когда Белбин собрал лучших людей в команду, все сказали: О, мы знаем, кто выиграет в этом соревновании!. А команда неожиданно пришла к финишу последней, раздираемая внутренними противоречиями.

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

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

Некому завершать работу


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

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

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

Лечение: чек-листы и административный контроль за реальным завершением задач не нужны, когда педант есть в команде. Увы, в IT педантов мало.

Нет сотрудничества


Симптомы: поиск виновных в проблемах и неудачах, отсутствие взаимопомощи, люди указывают на несовершенства других.

Диагноз: нет человека, который бы заботился о взаимоотношениях и сглаживал острые углы, это слепая зона у руководителя. Оказывается, это отдельная роль. Это не Координатор, и тем более не Шейпер, то есть роль не должна быть руководящей.

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и в управлении явно не участвует.

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

Одинаковые слабости у всех членов команды


Симптомы: команда повторяет ошибки, а в некоторых ситуациях даже впадает в ступор и не может двигаться.

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

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

Человек и команда


Человек в команде


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

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

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

Достоинства и недостатки


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

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

Еще у каждой роли есть допустимые недостатки как продолжение ее достоинств, и недопустимые, которые мешает выполнять основные функции роли и/или даже разрушают команду. Грань между ними тонка увеличиваясь, допустимый недостаток становится недопустимым. Любой человек может совмещать две-три роли, при этом сильные качества в одной могут быть недостатками в другой. Чтобы понимать это, у вас должна быть адекватная саморефлексия.

Зрелость команды


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

Но когда вы себя понимаете и знаете свои достоинства и недостатки, сильные и слабые стороны, то становитесь зрелым человеком в команде. В исследованиях Белбина на втором этапе даже несбалансированные команды побеждали, когда осознавали свои недостатки и стремились компенсировать их.

Проигравшие команды же разделились на две категории:
  • Те, кто не осознавал и/или не признавал недостатков. Например, опытные и сложившиеся менеджеры, которые пришли повышать свою квалификацию, не понимали про какие-то роли и их недостатки. О каких недостатках речь? Мы такими компаниями и командами руководили! Уж как-нибудь без этих особо умных обойдемся!
  • Фаталисты, которые не стремились исправиться. Они узнали о ролях и решили для себя о, мы слабая команда, мы идем к проигрышу. И не предпринимали ничего, чтобы это исправить.
  • Зрелость в осознании себя внутри команды и знание роли, а также когда ваша самооценка, имидж и факты совпадают, приводят к зрелости как себя, так и команды.


Формирование команды


Пригодность и приемлемость


При составлении команд имеют значение как профессиональные знания и навыки (Белбин это называет пригодность), так и приемлемость по командному профилю (роли):
  • Пригодные и приемлемые им работа скучна, это просто ступенька карьеры.
  • Приемлемые и непригодные развиваются, и им интересно работать в команде.
  • Неприемлемые, но пригодные проблемные. Работу делают, но в команде из-за них возникают трения.

Непригодных и неприемлемых надо уволить из команды в другой команде они могут подойти по профилю и проявить свои сильные стороны:



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

Ключевые моменты при формировании команды:


  • Нужны идеи, исполнители и организаторы.
  • Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.
  • На несколько ключевых ролей (ядро команды) выбирайте профессионалов (пригодных по знаниям и навыкам) и у которых нет резких конфликтов по ролям. Они обеспечат выполнение работы.
  • Дополняйте команду пусть и не столь выдающимися специалистами, но приемлемыми по командному профилю. Даже если они имеют формально недостаточный уровень по знаниям и навыкам, они будут расти и эффективно работать.
  • При включении новых людей в сложившуюся команду приемлемость критичнее, чем знания и навыки. Если новый сотрудник подходит по своей роли, это снизит шторминг после его появления в команде.
  • Командный дух не обеспечивает успеха, а конфликт между Шейперами и Генераторами не стоит решать при помощи их примирения его надо делать конструктивным.
  • Однородные команды слабы и часто выбирают себе подобных.
  • Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды.

Состав сбалансированной команды:


  • Руководитель Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;
  • Один сильный Генератор;

При этом хорошим будем следующее распределение умственных способностей:
  • умный Генератор;
  • еще один умный не-Генератор, который ему оппонирует;
  • умный Координатор;
  • остальные чуть ниже среднего уровня.


Размер команды


Эксперименты Белбина показали, что оптимальный размер команды 5-7 человек. Целевым было шесть, но выяснилось:
  • Ни 5, ни 7 человек не проигрывают и не выигрывают;
  • 8 человек могут быть успешны, но возрастает нагрузка на руководителя, а также требования к нему;
  • 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва;
  • В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.


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

Команды-победительницы:


  • Смешанные сбалансированные команды, где представлены все роли.
  • Однородные команды из стабильных экстравертов. В IT это редкость, но все же такие встречаются. Эти команды хорошо работают за счет сотрудничества, так как им нравится трудиться вместе. Роли в таких командах могут быть не выделены, но сотрудничество помогает преодолеть проблемы. Правда, они так же весело могут пойти на дно.
  • Команды, во главе которых суперзвезда: если стратегия лидера верна, команда движется к победе, если нет к поражению. И то, и другое будет стремительным.
  • Команды типа Аполлон (команды звезд): острый ум, ресурсы и таланты, но и большие сложности в их применении. Ключ к успеху хороший Координатор. Для сложных проектов такие команды особенно хороши, но нужно внимательно выбирать руководителя проекта.


Заключение


Вы познакомились с теорией. Как ее можно применить в повседневной жизни? Во-первых, вы можете проверить свои роли в команде (пройдя тест) и осознать свои сильные и старые стороны. И далее можете использовать это для собственной работы, выборе своего места или проекта.

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

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

И пара слов про тестирование. Многие роли яркие, вы их можете увидеть и без теста. Как и многие конфликты можно опознать без тестирования. Но у человека бывает несколько ролей, и вы можете не знать про другие, так как по поведению можно видеть только одну из них ту, которую он сейчас играет. В первой книге опубликован тест на 8 ролей (без специалиста), и он позволит их выявить и лучше применять решения.

А тем временем конференция TeamLead 2020 переносится на 25-26 февраля 2021 года. Наш опыт в онлайне показал, что это лучше чем ничего, но этого недостаточно. Мы приходим на конференции за общением, решениями, знакомствами, новыми идеями и обсуждениями. А работа с людьми, управление, софт-скиллы тем более очень сильно зависит от нюансов, поэтому личное общение здесь крайне важно.

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

По любым вопросам пишите на organization@ontico.ru, всё разрулим и всё решим.
Подробнее..
Категории: Управление проектами , Управление персоналом , Управление разработкой , Психология , Управление командой , Командообразование , Управление людьми , Teamlead , Блог компании конференции олега бунина (онтико) , Команда мечты , Роль , Команды

Тимлид и здоровье его команды

23.11.2020 20:22:46 | Автор: admin

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

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

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

Теперь вы не только пишете код в большее количество рук. Вы ищете внутри команды технических лидеров и даете им реализовать свои амбиции, что дает рост людей. Чувствуете разницу?

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

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

Этап развитиякоманды

Если вы только что наняты или переведены, то попробуйте применить одну из моделей например модель групповой динамикиТакмена. В четырех словах: формирование команды, притирка, работа над принятыми ранее ролями, но уже конструктивно и собственно работа над задачами.

Если же вы сами набрали команду, то не стоит подразумевать, что путешествие по стадиям формирования будет происходить само собой, оставляя вас наблюдателем, потому как путешествие по модели, допустим, Такмена это далеко не вот этот график:

Идеальная сферическая команда ввакуумеИдеальная сферическая команда ввакууме

Скорее вот такой:

Реальная команда в атмосфере компанииРеальная команда в атмосфере компании

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

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

Что с этим делать?В первую очередь это инструмент рефлексии. Не столь важен ответ, сколько попытка построить кривую и попутно понять, что происходило с вами в последние месяцы.

Отпуски, переработки, дежурства

Эти составляющие выносятся за скобки рабочего процесса, считая что отпуск отнимает пропорциональный кусок ресурсов, а переработки дают прирост на 150200% и требуют только компенсации в разумный срок. На деле нелинейность складывается не только из первого порядка причин вроде батарейка разряжается или вливание в работу после отпуска, но и второго страдающей групповой работы людей разного состояния. Уставший менеджер не тянет бодрого аналитика, выгорающий бэкендер не может договориться с полным энтузиазма фронтендером.

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

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

Предыстория побед и поражений

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

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

Что делать?Добавлять новых героев в свой эпос, интересоваться не только решением задач, но и тем, как и какими эмоциями эти задачи были решены.

Текущие конфликты

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

А вот иррациональные конфликты или полный штиль повод присмотреться.

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

Цели и задачи стоящие перед командой и отдельными участниками

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

Это могут быть задачи развития от HR, всякие наследованные KPI, задачи на аналитику или обучение от соседних отделов, цели гильдии, например бэкендеров, выступления.

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

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

Цели командыесли вы не участвовали в их принятии полезно прояснить и договориться заново. Есть шанс что они отпали автоматически, но мы говорим о здоровье команды и не хотим подцепить амнезию:-)

Договоренности и обязательства

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

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

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

Самостоятельность

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

Что измерять?

Еще одна интерпретация рычагавластиЕще одна интерпретация рычагавласти

Представим рычаг, груз авторитета с одной стороны и независимость с другой. Где вы? Даже команда с высокой степенью зрелости может быть задавлена высокой авторитарностью. Куда будет двигаться опора решать вам, но текущее положение можно оценить по принимаемым решениям и вашем положении (или вашего предшественника) в них.

Искренность и токсичность

Можно много ссылаться на индустриальные стандарты токсичности, профессиональный юмор и критическое мышление, но кто будет спорить с тем, что команда верящая в свою пользу, более функциональна?

Что важно?Отслеживать вектор демотивации и не делать преждевременных действий. Вытаскивать конструктивную критику из юмора и трезво смотреть на нее.

Неформальные взаимодействия

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

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

Обучение

Уточните планы и ресурсы для обучения в компании. Наблюдайте за тем, как разработчики делится идеями и новостями индустрии. Ваше восприятие обучения зависит от роли и опыта.

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

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

Концентрация знаний

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

Стоит беспокоиться?Это не повод для суеты и насильного обмена опытом со всеми участниками. Можно как минимум осведомлять о существования атланта который держит важный сервис своей спиной, а еще лучше фасилитировать обмен опытом внутри команды.

Трансформация

Запущена ли трансформация ролей, процессов? Она может быть формальная например изменение оргструктуры, либо неформальная, когда вы приходите в новую команду и проясняете текущее положение дел, собираетесь пойти думать и вдруг кто-то вспоминает: А! Мы тут задумали перепилить воркфлоу, так что все что я говорил с понедельника станет не актуально. Предыдущий лид был согласен, ты же знаешь?.

Для чего?Выждать если необходимо или возглавить изменения. Иногда это повод для того, что бы отложить выводы о состоянии команды до окончания изменений.

Производительность

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

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

Возвращаясь к моделям в начале распространим это и на статью. Быть может в вашей команде есть составляющие, которые в данный момент влияют сильнее, чем все вместе взятое выше.

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

Попробуйте применить разные линзы для взгляда на команду. Если вы любите больше формализации, процессов и индикаторов попробуйте методику Health Checkот Spotify.

Подробнее..
Категории: Agile , Управление персоналом , Управление разработкой , Здоровье команды , Командообразование , Управление людьми , Тимлид , Команда

В поисках Нео

19.06.2020 18:10:12 | Автор: admin
В продолжение первой части нашей эпопеи о поиске и интеграции джунов в команду.

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

Как и в первой части, я напомню, что лишь делюсь опытом и высказываю своё мнение. Не более того.

Составляем карточку вакансии


image

Один из самых важных критериев успешности ваших поисков выбор правильной HR площадки.
Так как мы всё-таки работаем с IT сегментом, то я бы рекомендовал использовать Хабр Карьеру

В качестве дополнительных источников трафика можно рассматривать HH, LinkedIn (в РФ заблокирован), тематические тележные IT каналы, например хороший канал по поиску джавистов, мобайл разрабы, ну и личные ресурсы, если таковые имеются.

Название вакансии


Как лучше назвать вакансию

Довольно важная вещь, я всегда рекомендую писать максимально коротко и по делу.
Если мы ищем фронтендера, то так и нужно писать Frontend developer, однако, если вам хочется покрыть всевозможные кейсы, то у вас возникнут с этим проблемы, т.к. кейсов тут немало:
Ключи developer || разработчик

  1. Frontend
  2. Front-end
  3. Front end
  4. Фронтенд
  5. Фронт-енд
  6. Фронт енд

Тут либо тратить много денег (зачем?), либо пихать всё в один заголовок. Правда, потом прилетит НЛО и заберёт к себе в поликлинику, на опыты.

Квалификация


Выбор квалификации

Тут всё зависит от того кого (а главное для чего) вы ищите. Если мы следуем теме нашей пасты, то это Intern/Junior. Не знаю зачем Хабр разделяет их и даёт возможность схалявить на интернах, но пусть так.

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

К Junior'ам я отношу ребят которые знают язык уже более продвинуто и знакомы с кухней современного веб-строя: ну там, React, Vue, Angular, хоть что-то из основной тройки; и которые уже в состоянии писать что-то похожее на веб-приложения. А в последнее время я в обязательном порядке ставлю в требования знание хуков, так как без них сейчас вообще никуда.

Вознаграждение


Справедливая зарплата для джунов и интернов

Считаю справедливым стажёрам платить не менее 30к, а если ребята смышлёные и не боятся овертаймов и проявляют инициативу, да и вообще смышлёные не по возрасту можно поднять и до 50к.

Для джунов считаю справедливым выставлять от 50к и до 70-80к, в зависимости от личных навыков. Всё в динамике, каких-то жёстких прайсов у меня не было никогда.

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

Описание вакансии


image

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

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

О компании


Я стараюсь преподносить команду в максимально дружелюбном и неформальном стиле (насколько это возможно). Правда, раскрыть всю идею в одном абзаце не выходит, так как первый абзац (интро) не должно быть длинным, в противном случае ваша ЦА просто не увидит основные блоки в первые секунды (они самые важные) в которые вы должны зацепить человека.

Кого ищем?


В данном блоке я составляю примерный портрет человека, которого бы я хотел увидеть в команде. Кстати, о навыках и знании инструментов об этом я также стараюсь упомянуть в этом блоке: к примеру, я пишу о том, что мы активно пользуемся фишками Github'a и надеемся, что наш новоиспечённый член команды тоже неравнодушен к нему.

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

Что делаем?


Тут нужно постараться рассказать про основной вид деятельности команды. Обычно я пишу обобщённо, стараясь донести в каких сферах мы работаем и какие направления предпочитаем. Ну, то есть, я пишу, что мы любим пилить различные *aaS, eCommerce, B2B, Digital проекты, ну и парочку примеров из того, что мы уже запустили или над чем работаем в паблике; для наглядности, так сказать.

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

Что не любим?


Считаю важным писать про вещи типа: что любим/что не любим. Так вы сможете отсеять людей не подходящих вам по духу. Например, я так отсеивал людей которые задавали вопросы в духе: Мы же отдыхаем в День России?, У вас ведь 8-и часовой рабочий день? или людей которые явно (или не очень) котируют тот или иной инструмент, который мы предпочитаем обходить стороной.

С чем работаем


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

Отдельное внимание я уделяю Github и Octokit

image

Смысл в том, что у гитхаба отличный поиск, есть экшены и собственное API и знание этих вещей необходимо для нашей работы, а потому об умении, или наоборот неумении работать с Github лучше всегда знать заранее, так как от этого будет напрямую зависеть дальнейший флоу работы с джуном

Бонусы


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

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

Я и раньше об этом думал. Правда, вопрос был в целесообразности и ресурсах. Ресурсы появились, а целесообразность никуда не пропала парни всё также болеют, филонят в метеокритические дни и т.д.

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

Короче, заботьтесь о своих падаванах, иначе у вас будет постоянная текучка.

Дополнительные инструкции или CTA


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

Живой пример был сегодня: написала мне некая Katlyn из компании BlueReceipt очередные горе-интеграторы Shopify.

Предложила скипнуть 1 этап и перейти сразу к 30-и минутному тесту по JavaScript, дабы убедиться в моей компетенции. Мало того, что сайт кривой: линки не пашут, а в некоторых местах тупые грамматические ошибки, так ещё и кадры тупые.

Нет. Ок. Приемлемо. Но, не когда человек приходит ко мне через профайл на CodersRank

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

В дополнительных инструкциях я строго наказываю в отклике оставлять ссылку на решённое вводное задание, остальное по желанию.

Все отклики без ссылок на форки с решённым вводным я просто удалял. Итого на последней вакансии было 90 человек, которые оставили отклики.

image

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

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

Вводное и тестовое задание не одно и то же


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

Было принято решение сделать с ребятами репу с полноценным бэкенд и фронтенд сервисамии сломать.

Тут вероятно стоит немного прояснить.
Тест было принято разбить на вводное и тестовое.

Я применяю подход monorepo для большинства наших проектов.

Поломав рабочую монорепу, я создал вводное задание.

Поломав местами redux и кое-какие куски кода, было придумано тестовое для фронтендеров, ну и, само собой, таким же образом появилось тестовое для бэкендеров.

При том, для фронтендеров условия были куда лучше, нежели для бэкендеров, так как для фронтендеров я поднял на нашем техническом домене полноценное, работающее GraphQL API, чтобы они могли нормально работать.

Бэкендерам повезло меньше: на тот момент я не смог придумать как отдать им рабочий фронт без подключения нашего штатного devops окружения, и не спалив при этом рабочий фронт для проходивших тестовое в соседней папке.

Решение появилось, но уже после старта.

Отдельно про бэкенд могу сказать следующее: задание было очень сложным, однако, нашлись те, кто его осилил, а на таких и была сделана ставка. То есть, ребята, которым интересен подобный стек: Typescript, NestJS, GraphQL, CQRS, Protobuff, gRPC, *DD таких оказалось всего двое.

Подытожим


В завершении второй части могу сказать лишь следующее:

  • старайтесь оптимизировать траты вашего времени за счёт подобных решений, это не только сэкономит вам время, но и проверит некоторые личные качества кандидатов, которые собираются у вас учиться, а софт скиллы не менее важны в нашем деле
  • если хотите собрать дружную команду на долгосрок делайте так, чтобы люди были счастливы, и дело тут даже не в высокой ставке, так как зачастую народ просто просирает деньги неизвестно куда, а потом жалуется, что сидит на дошиках это не дело, скажу я вам! Поощряйте здоровый образ жизни, занятия спортом, закупайте раз в полгода-год нужную и полезную для работы технику, или какие-то плюшки на ДР ваших маленьких помощников которые просто сделают работу более комфортной
  • не тупите! и не заставляйте людей заниматься ненужной рутинной, отправлять вам какие-то письма на какие-то там ящики, высылать инфу о последних проектах. Если вас заинтересовал какой-то человек и вам так нужно соберите инфу о нём сами, благо в 2020 живём
  • следите за развитием своих людей, это очень важно, ведь ни сегодня так завтра вы окажетесь на грани кадровой пропасти из-за того, что ваши парни не развиваются

В третьей части я расскажу как правильно интегрировать джунов в командный процесс и помочь им освоиться в новой (а может и первой) команде.
Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Учебный процесс в it , Обучение программированию , Web-разработка , Обучение , Джуниор , Джуниор-разработчик , Командообразование

Как построить самовоспроизводящуюся практику

13.10.2020 12:18:27 | Автор: admin


Сегодня расскажем, как организовать устойчивое развитие команды, которая не подвержена кадровым кризисам. Где руководитель не тонет в оперативке, сотрудники не скучают годами на одинаковых задачах, старшие специалисты не бронзовеют, а привлечение новых сотрудников не стоит как крыло самолёта. Если не найдёте в тексте ничего нового для себя, поздравляем! А мы наступили на все приведённые грабли. Может быть, кого-то наш опыт убережёт от ошибок. Или подскажет решение.

В основе этой статьи воркшоп, который мы ведём для руководителей производственных команд. Начинаем его с опроса: Что вам мешает выкладываться и получать удовольствие от работы? Ответы получаем такие: руководители по горло в администрировании, опытные ребята со временем упираются в потолок и гаснут. Талантливые начинают звездить и манипулировать. На молодых специалистов особо не ставят, ими некому заниматься работа горит. Некогда точить, надо пилить и вот это всё.

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

Практикой (или центром компетенций) мы называем группу специалистов одного направления, то, что в других компаниях называют отделом, подразделением, департаментом: практика дизайнеров, проджект-менеджеров, бизнес-аналитиков, QA-инженеров, разработчиков. В Redmadrobot, например, три практики разработчиков по направлениям: iOS-, Android- и Front-end + Back-end. Кроме решения функциональных задач на проектах практика производит и управляет знаниями. И работает относительно автономно от других практик, например, сама себе ставит квартальные цели в рамках общей стратегии компании.

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

Практика здорового человека

Теперь по порядку, почему всё нормально работает.

Команда


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

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

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

А вот картина, которая встречается гораздо чаще:

Практика курильщика

Здесь лид за всё отвечает сам, остальные специалисты плотно заняты на проектах. Есть ли в команде стажёры или молодые специалисты? Обычно нет. Это затраты и головная боль а команда и так еле успевает делать основную работу.

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

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

Это можно предотвратить, если настроить процессы на двух контурах: на внешнем работу с профсообществом, и на внутреннем работу со стажёрами. Сначала разберём внешний.


Работа с профсообществом

Повестка, технологии, кейсы


Если компания амбициозная, она старается быть в технологическом авангарде, делать передовые проекты и зарабатывать на них. Такие компании есть в каждой отрасли, на них все равняются. Работа с R&D прописана у них на уровне стратегии. Важная функций лида практики быть в курсе изменений в своей области и регулярно предлагать команде свежую повестку для освоения и реализации на проектах.

Повестка берётся из профессионального сообщества локального или международного масштаба. Это так называемые best practices: новые технологии и методики работы в ответ на новые запросы бизнеса и потребности пользователей. Примеры такой повестки: переход на server-side Kotlin в разработке, внедрение кастдева вместо рыночной аналитики в маркетинге и т.д, и т.п.

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

Чтобы специалисты были в курсе повестки, лид планирует загрузку команды таким образом, чтобы оставалось время на освоение, разработку и внедрение технологий на проекты. И организует распространение знаний между сотрудниками. Мы в Redmadrobot передаём знания через групповые мероприятия: технологизации, школы, воркшопы.

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

Так результаты работы компании и отдельных практик становятся видимыми. У заинтересованных специалистов появляется способ сделать профессиональную репутацию себе и команде. Потенциальные клиенты могут рассмотреть, что и как делает компания. Будущие сотрудники с какими задачами и технологиями работает команда, кто её заказчики.

Например, повестка аналитика данных в HR. Когда мы раскусили эту тему: собрали модель данных, описали процесс и критерии для сборки, получили первую статистику сразу же выпустили отчётный текст, чтобы показать, как работает технология в команде из нескольких сотен сотрудников. Этот кейс принёс нам первое место от hh.ru.

Ещё примеры:

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

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

Бывает и так, что руководство создаёт экспериментальное R&D направление, например, внутри практики разработки. Направление генерирует активность, но новые технологии не тестируются на проектах и не приносят прибыль. А компания ещё и тратит бюджет на работу таких экспериментаторов.

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

А ещё бывает, что руководитель единственный известный эксперт в практике. Он плотно вовлечён в профсообщество, развивает личный бренд: пишет статьи и выступает, на его громкое имя в компанию приходят новые сотрудники. У него большой простор для манипуляций: если решит уйти, за ним могут уйти и все, кто пришёл на него. Если вы не успели вырастить преемников, практика посыпется. Классический бас-фактор.

Работа со стажёрами

Фреймворки, знания, стажёры


Это внутренний контур. Если процессы в нём налажены хорошо, освоенные и реализованные на проектах технологии пополняют базу знаний практики. Знания библиотеки и фреймворки, репозитории в GitHub, борды в Miro, инструкции по работе с инструментами, а также учебные программы на основе отработанных паттернов решения задач. В производстве знаний участвуют сами специалисты, знания свободно распространяются внутри компании, загружаются в новых сотрудников и тех, кто идёт на повышение или меняет роль.

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

Мы учили разработчиков с момента основания Redmadrobot в 2008. Брали на работу лучших из лучших, но всех приходилось переучивать программировать под мобильные платформы с языков С, С# и др. Это было связано с особенностями разработки под мобилку: для iOS и Android ещё не было требований, кроме набора платформенных фреймворков. Специалисты не знали общепринятых правил разработки и не имели опыта за исключением разового, т.к. на их прошлой работе не было налаженной практики.

Летом 2015 мы организовали первую стажировку. Придумали программу, формат домашек и критерии оценки. Затем каждый год программу меняли и старались дополнять актуальными темами. Порог входа тоже варьировался. В первый год набрали увлечённых студентов с минимальными знаниями в мобилке. Во второй джунов и мидлов. Ещё через год брали уровень не ниже мидла, с обязательным опытом коммерческой разработки, потом снова студентов и т.д.

После первой же стажировки стало ясно, что нанимать разработчиков с необходимыми компетенциями стало проще. И что есть выхлоп на рынок. В комментариях к анонсу здесь, на Хабре, спрашивали: Когда следующий набор?. Выпускники рассказывали в соцсетях, как всё устроено изнутри, чему они научились за 2 месяца. На собеседования стали приходить ребята, которые через анонс узнали про компанию. Так к нам в команду попало много классных людей.

Узнаваемость главный эффект, а дополнительный наши ребята, организаторы и ведущие занятий, тоже получают от стажировок хороший опыт. Готовят контент для лекций, из которого потом получаются технические статьи и выступления. Прокачиваются как лекторы и наставники, после каждой лекции получают обратную связь о качестве материала и преподавания. С каждым годом к нам приходят всё более прокаченные ребята, и готовиться нужно ещё ответственнее. С 2015 года время мы прокачали 120 разработчиков и 22 пригласили в команду.

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

Если в практике всего пара человек


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

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

Как построить воспроизводящуюся практику. Главное:


  • Транслировать стратегию равномерно на всю компанию, чтобы каждый понимал что он делает и зачем.
  • Организовать систему передачи знаний и фреймворков внутри практики, чтобы исключить бас-фактор.
  • Растить помощников для руководителя, чтобы помогали развивать практику и высвободили у лида рабочие часы на стратегическое управление.
  • Осваивать и реализовывать новые технологии прямо на проектах, чтобы не терять деньги.
  • Наладить производство кейсов, чтобы визуализировать результаты.
  • Запустить систему работы со стажёрами, чтобы обеспечить приток молодых специалистов и держать в тонусе всю команду.


Текст: Настя Зальцман, HR-директор, и Артур Сахаров, директор производства.
Редактура: Таня Павлова, картинки: Полина Резванова.
Подробнее..
Категории: Управление персоналом , Управление разработкой , Командообразование , Управление проектами и командой , Блог компании redmadrobot , Построение компании

Recovery mode Как поднять боевой дух команды на удаленке?

16.06.2021 10:13:29 | Автор: admin

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

Эта статья от том, как я организовал Хакатон для IT компании в Малайзии в самые первые месяцы пандемии. Игра была целиком посвещена Linux администрированию, траблшутингу и хакингу. При этом она позволяла поучаствовать всем сотрудникам, от junior инженера технической поддержки до senior архитектора.

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

Дано:

  • Компания системный интегратор в Куала Лумпуре;

  • Интернациональная команда IT-специалистов;

  • 99.99% персонала внезапно ушло на удаленку.

Задачи:

  • Позволить сотрудникам отвлечься от работы и снизить уровень стресса;

  • Развить навыки, используя геймификацию;

  • Развить внутренний бренд для будущих IT игр.

В чем заключалась сложность?

  • Неравномерный уровень подготовки и квалификации.

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

  • Сменный график работы сотрудников.

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

  • Локальный менталитет.

К особенностям местного населения необходимо привыкнуть. Работают в компании в основном малайцы, индийцы и китайцы. Преимущественно они не задают вопросов, опасаются участвовать в чем-то новом и непонятном. Раз в неделю 80% сотрудников покидает офис на 2,5 часа по религиозным соображениям. На корпоратив добрая половина придет только если пообещать им лотерею и призы (очень популярная практика у местных компаний). Заинтересовать таких людей участием в игре было нелегко.

[Спойлер]

Мне удалось =)

А где Гарри? Шалит с новым хакатоном.А где Гарри? Шалит с новым хакатоном.

  • Неразбериха из-за пандемии.

Я называю это удаленка через force. С началом пандемии нам пришлось работать из дома не по своей воле. Не все к этому были готовы. Отдельные сотрудники и даже целые департаменты долго приводили свои рабочие процессы в порядок. Многие не представляли, как можно втиснуть в график еще больше работы.

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

  • Демотивированный персонал.

Мы затеяли игру, чтобы мотивировать инженеров на новые свершения, но как это сделать если они уже демотивированны резкой сменой обстановки, отсутствием живого общения и неожиданными препятствиями в работе? Был шанс, что сотрудники не станут участвовать потому, что воспримут наши Linux задачки как лишнюю работу, на которую просто нет времени. Если я и так каждый день ковыряюсь в серверах, то это не может быть весело, правильно?

[Спойлер]

Еще как может! Риск не собрать аудиторию не оправдался.

Типичный сотрудник в самом начале пандемии.Типичный сотрудник в самом начале пандемии.

План подготовки и проведения хакатона

В моем случае выполнение всех этих действий позволило мне успешно провести мероприятие.

  • Разработка концепта игры.

Я решил, что темой хакатона будет Linux администрирование. Соответственно, задания должны были строиться вокруг базовых административных задач: проверялось умение использовать command line, браузерные тулзы, знание SQL, DNS, самые основы шифрования.

Хакатон должен был длиться несколько дней. Поэтому я придумал систему уровней и кодов. Каждый уровень представлял собой одну виртуальную машину, в которую участникам нужно было зайти по SHH и найти спрятанный код. На каждой из машин был запущен Apache c простым сайтом, где размещались подсказки. Ну или нет =)

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

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

На этом же этапе была продумана система поощрений.

  1. Top-3 самые ценные индивидуальные призы;

  2. Top-10 дополнительный специальный пак призов;

  3. Первые 50 участников гарантированные призы из дешевого ценового диапазона.

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

  • Технический дизайн.

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

В качестве хостинг площадки был выбран AWS. Игровые серверы и хост с веб формой были подняты на t2.medium EC2 инстансах. К каждому инстансу был привязан 1 бесплатный домен. В качестве базы данных использовалась Amazon DynamoDB. Форма была написана на Python и фреймворке Flask. Бэкенд формы был выполнен на основе FaaS (Function as a Service) подхода с помощью связки API Gateway + Lambda + DynamoDB.

Выбор такой технологической базы был обусловлен субъективными пожеланиеми организаторов, наличием необходимой корпоративной облачной подписки, и знаменитым правилом start where you are. Последний принцип подсказал, что можно взять подходящую web форму, используемую в продакшене, и переписать ее под нужды игры. Пользуясь случаем, Алекс и Саша, огромное спасибо за помощь с AWS деплойментом и девелопментом формы. Без вас мне бы было значительно сложнее.

  • Презентация концепта руководству и получение бюджета.

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

[Спойлер]
Как ощущаешь себя когда получаешь максимальный бюжет на проект.Как ощущаешь себя когда получаешь максимальный бюжет на проект.

  • Разработка дизайна и внешнего вида.

Сначала я определился с названием бренда для внутренних игр и выбрал цвета на свой вкус. На мое счастье в компании был дизайнер, который помог подготовить несколько вариантов логотипа. Я написал и согласовал ТЗ. Итоговый логотип в белом, черном и цветном вариантах был использован для рассылок и печати на призах. Абсолютно все материалы были выдержаны в одном стиле, распространялись под одним брендом и сопровождались одним и тем же логотипом. Недавно, когда я рассылал тизеры о новом хакатоне мне уже не задавали вопросов о том, что происходит. Инженеры точно знали, чего ожидать.

  • Выбор и заказ призов.

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

  • Рассылка тизеров до начала игры.

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

  • Сюжетное обрамление.

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

  • Релиз.

Первое письмо было отправлено на весь офис и содержало начало истории, ссылки и правила игры. Тут же посыпались вопросы: коллеги просили подсказки, пытались уточнить правильно ли они понимают задание, а также старались выудить полезную информацию любой ценой. Не то чтобы получалось. Я был кремень.

Один из финальных тизеровОдин из финальных тизеров

  • Элемент обучения.

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

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

  • Организовать постоянный follow up.

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

  • Выдать призы.

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

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

  • Собрать обратную связь.

Действовать следовало итеративно и с фидбеком. Поэтому всем участникам был разослан опросник. 25% заполнили его. Об ответах в описании результатов.

Весь подготовительный процесс занял 2 месяца и 68 человеко-часов главного организатора. Но результат стоил того.

Результаты:

  • Боевой дух команды вырос.

Игра подразумевала индивидуальное участие и решение задач. Однако, мне доподлинно известно, что люди объединялись в команды, устраивали созвоны и брейнштормы. Активным участникам точно было не скучно. Люди, которым в силу неопытности удалось прорваться только через несколько уровней, определенно научились чему-то новому. Цель отвлечь участников и снизить градус напряжения была достигнута.

  • Позитивный фидбек от участников.

Одним из факторов, которые говорят о безоговорочном успехе мероприятия, является факт участия тяжелых на подъем сотрудников. Хакатон имел успех и среди линейных менеджеров, которые по долгу службы не работают с Linux напрямую, и среди инженеров-ветеранов.

Три наиболее частые причины почему участники согласились играть:

  1. Возможность проверить свои скиллы;

  2. Любовь к играм и соревнованиям;

  3. Любопытство.

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

  • Карт-бланш и бюджет на проведение новых хакатонов.

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

Личное:

Что получил лично я? Опыт, море позитива и желание делать Хакатоны и дальше, в том числе и на коммерческой основе. У меня есть планы на новые игры и, определенно, есть ресурсы, чтобы их воплотить.

А еще я сформулировал и взял на вооружение...

Ключевые принципы организации хакатонов.

  • Знайте свою целевую аудиторию.

Хакатоны - для всех!Хакатоны - для всех!

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

  • Агитируйте правильно.

[Спойлер]
Землю - крестьянам, игры - айтишникам!Землю - крестьянам, игры - айтишникам!

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

  • Управляйте сложностью.

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

[Спойлер]
У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?

  • Позвольте играть не так как задумано.

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

[Спойлер]
А Барсик один в игре ковыряется, посмотри на него!А Барсик один в игре ковыряется, посмотри на него!

  • Призы хорошо, но не главное.

[Спойлер]
А как же сектор приз?А как же сектор приз?

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

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

Спасибо, что прочли. Увидимся в будущих публикациях!

Подробнее..
Категории: Хакатоны , Игры , Командообразование , Игры для программистов , Команда , Командообразование в ит , Корпоративная культура , Командная работа , Командный дух , Тимбилдинг , Игра в терминале

Перебраться через забор или история о том, как стать командой за три часа

25.11.2020 22:06:19 | Автор: admin
Существуют разные мнения о том, как команды становятся командами. Есть несколько наиболее популярных моделей, которые говорят о невозможности стать командой быстро. Это может быть долгий процесс со своей динамикой.

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

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

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


Ну, вы поняли.

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

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

Так впервые мы все увидели друг друга только на первом планировании. И поскольку это было не просто планирование, а PIP (Product Increment Planning мероприятие в SAFe, посвященное высокоуровневому планированию работы команд на следующие несколько спринтов), то нам предстояло разобраться со многими вещами за ограниченный отрезок времени.

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

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


Кстати, наш Product Increment Planning, будь он в оффлайне, мог бы выглядеть так.

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

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

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

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

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

Робкий костер разгорелся в уверенное яркое пламя.

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

Это было удивительно следить за тем, как они за считанные минуты открыли для себя, что все они часть команды.

Выступление на TED на эту тему мне попалось намного позже.

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

Я же, как Скрам Мастер, направляла движение дискуссии, когда это было необходимо, предупреждая возникновение чувства, что сама дискуссия заходит в тупик.

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

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

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

И если бы меня спросили: Как команды становятся командами? Долгий ли это процесс?, я бы ответила, что истинную командную идентичность они обретают тогда, когда перебираются через забор, то есть преодолевают первую трудность, действуя слаженно и сплоченно. И в том, чтобы это случилось как можно скорее, и есть ответственность лидера.

А что именно он может для этого сделать, звучит, как тема для следующей статьи :)
Подробнее..
Категории: Командообразование , Командообразование в ит , Блог компании deutsche telekom it solutions (ex t-systems) , Командный дух

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru