Настольная книга тимлида разработки ПО бесплатное чтение

Виктор Большаков
Настольная книга тимлида разработки ПО

Введение

Зачем вам эта книга

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

Основой для написания книги послужили опыт из различных доступных источников и структура компетенций TeamLead Roadmap [https://tlroadmap.io/], за что автор выражает большую благодарность сообществу. Однако мнение автора частично отличается от вышеупомянутых компетенций: для ознакомления читателя с имеющимся мировым опытом и опытом автора, структура функций в книге заполнена практиками и принципами.

Данная книга будет полезна для специалистов в сфере разработки:

— Действующему тимлиду

— Разработчику, планирующему стать тимлидом

— Руководителю групп разработки, CIO, CTO, CDTO

— Руководителю подразделения разработки ПО

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

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

Руководителю групп разработки, CIO, CTO, CDTO эта книга позволит задать стандарты работы в организации, провести повышение квалификации тимлидов, оценить их квалификацию по компетенциям и даже написать требования к вакансии тимлида или должностной инструкции.

Руководителю подразделения разработки ПО, такому как Системного администрирования, Контроля качества, Проектного офиса и др., книга раскрывает функции управления командой.

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

О роли

Тимлид [Team Leader] — роль лидера команды разработки, которая включает в себя организацию эффективной работы команды и обеспечивает ее максимальную ценность для организации.

Определение в wikipedia [https://en.wikipedia.org/wiki/Team leader] звучит иначе, но отражает ту же самую суть.

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

Разделение труда в организациях очень разнообразное. В крупных компаниях разделение труда более детализировано — поле деятельности тимлида сужается, что повышает эффективность выполнения оставшихся в его зоне ответственности функций. Например, в некоторых организациях есть роль Владельца продукта [Product Owner], что позволяет тимлиду в меньшей степени заниматься проектированием функционала систем. Предположим, в другой части компаний есть роль Руководителя проектов [Project Manager], которая снимает с тимлида функции построения планов и контроля выполнения этих планов. В небольших стартапах роль тимлида может включать в себя функции Владельца продукта [Product Owner], Руководителя проекта [Project Manager], Релиз-инженера [Release Engeneer], ИТ директора [CIO]. Технического директора [СТО] и др.

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

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

Карта компетенций

Компетентность — способность (знания и опыт), позволяющая эффективно выполнять определенный класс профессиональных задач.

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

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

Контекст деятельности

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

Факторы, влияющие на деятельность тимлида:

— Организация, в рамках которой работает команда:

— Роли и конкретные сотрудники на тех или иных должностях

— Регламенты, политики и правила организации в части:

— работы с сотрудниками

— реализации процессов разработки

— формата общения между командами/подразделениями

— общие требования к программным продуктам

— Ресурсы для мотивации сотрудников

— Доступные тимлиду и команде инструменты для достижения целей

— Корпоративная культура

— Команда

— Программный продукт или продукты, над которыми работает команда

— Качество постановки задач, формализации целей входящей информации

— История формирования организации и команды, продуктов, процессов и инструментов разработки

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

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

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

Управление сотрудниками

Найм

Перед тем как раскрыть тему найма новых сотрудников, приведу напутствующие слова Мариэтты Парсекян (HR директора компании DatsTeam) тимлидам своей компании:

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

Рынок высококонкурентный в ИТ и наше предложение должно выгодно отличаться, а тимлид — это лицо нашей разработки. Надо обязательно помнить об этом, даже при отказе кандидату. С вами ассоциируется культура нашей разработки. С нашей культурой рекрутинга ассоциируется культура нашей разработки. Любой кандидат, который поговорил с вами будет нести в сообщества свое мнение о нас и растить наш DevRel, даже если мы его намеренно не растим.

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

Выявление потребностей

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

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

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

— Повысив утилизацию текущих ресурсов

— Перераспределив внутренние ресурсы организации

— Обратившись к внешнему подрядчику

— Наняв нового сотрудника

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

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

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

Перед тем как открыть вакансию, необходимо оценить:

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

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

Необходимость решения определенных задач может привести вас к вопросу Дизайна команды и Управления компетенциями. Важно переосмыслить распределение обязанностей, возможно выгоднее будет вместо найма еще одного Senior разработчика искать разработчика Junior/Middle уровня для того, чтобы разгрузить текущих разработчиков от простых задач.

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

Формирование вакансии

Вакансия — это набор требований, обязанностей, условий труда и информации о компании/продукте.

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

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

— Сделать требования к вакансии мягче, рассматривать кандидатов с меньшей квалификацией/не покрывающих все ваши потребности. В этом случае, вам придется доучить кандидата (потратить на это ресурсы компании).

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

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

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

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

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

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

Обязанности являются важной частью вакансии, поскольку позже новый сотрудник, ссылаясь на них, может отказаться выполнять часть порученной ему работы. Более формальный документ, на основании которого происходит увольнение. — это «Должностные обязанности», но перечень обязанностей в нем должен соответствовать вакансии. Для таких вакансий, как Руководитель проектов/Full stack разработчик должностные обязанности могут очень сильно отличаться, и кандидаты начинают этому уделять пристальное внимание.

Условия труда должны отражать ключевые для кандидата условия:

— Оклад, премии, мотивация

— Где нужно будет работать (офис, офисное оснащение)

— Соц. пакеты

— Инструменты (техника, IDE)

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

Отсев кандидатов по резюме

До публикации вакансии. HR-рекрутер, имея доступ к базе данных резюме, делает подборку кандидатов, удовлетворяющих требованиям вакансии.

После публикации вакансии. HR-рекрутер осуществляет первичный отсев откликов. Далее уже вы фильтруете резюме по откликам и подборкам.

Последующий процесс обработки отфильтрованных резюме HR-рекрутером включает контакт с кандидатом (предварительное собеседование) и даже предварительный отбор.

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

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

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

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

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

Собеседования

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

К собеседованию необходимо подготовится:

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

— Иметь опросник hard skills со стандартными вопросами. Выделите технические знания и опыт по секциям, для каждой сформулируйте вопросы. Эти вопросы должны продемонстрировать глубину и широту знаний/опыта кандидата. Хорошие вопросы: «В каких случаях выгоднее использовать NoSQL базы данных?», плохие вопросы: «У вас был опыт написания автотестов, знаете, как это делается?». Несмотря на набор готовых вопросов, вам нужно быть готовым к импровизации прямо во время собеседования — задавать вопросы, больше раскрывающие ту или иную компетенцию. Одним из подходов может служить попытка расспросить кандидата о системах, которые он разрабатывал, периодически доходя до мельчайших подробностей реализации.

— Иметь опросник soft skills со стандартными вопросами. Вопросы совместимости с вашей командой, компанией, продуктом и процессами. Личностные качества кандидата и все остальное можно почерпнуть из личного опыта кандидата и набора гипотетических ситуаций. Набор вопросов soft skills не имеет правильных ответов, так что ответы не могут однозначно свидетельствовать о совместимости или несовместимости вашей компании и кандидата.

— Также важно узнать, насколько быстро, в случае положительного решения, кандидат готов приступить к работе есть ли у него какие-то ограничения или планы (допустим, отпуск), о которых вы должны знать.

— У вас должна быть однотипная структура проведения собеседования — вопросы кандидату об опыте, hard skills, soft skills, тестовые задания, вопросы кандидата о компании, о команде, о продукте, о процессах, инструментах. Однотипная структура не означает, что вы ограничитесь одним и тем же набором вопросов.

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

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

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

— Если вы не один собеседуете кандидата — обсудите с коллегами кто что будет спрашивать.

Проведение собеседования:

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

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

— Сразу расскажите кандидату план беседы и регламент (сколько ориентировочно будет идти собеседование)

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

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

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

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

Фиксирование результатов собеседования:

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

— Результаты всех прошедших собеседований до момента найма (а может быть и позже) должны храниться у вас в недоступном для других сотрудников месте.

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

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

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

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

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

Еще один полезный прием — записывать видео собеседований, это может позволить:

— Получить мнение о кандидате коллег, не присутствовавших на собеседовании

— Легко передать найм кандидата в другую команду

— Перейти в другую команду на испытательном сроке

Однако для этого подхода, требуется запросить разрешение на запись у кандидата.

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

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

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

— Кандидат не сможет продемонстрировать всю глубину своих hard skills, ведь ему достаются задачи без полного погружение в контекст проекта.

— В течение дня придется потратить много ресурсов на ответы на вопросы нового сотрудника.

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

Принятие решения

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

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

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

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

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

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

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

Адаптация [Onboarding]

До того, как сотрудник выйдет работать, необходимо подготовить информацию и доступы в корпоративных системах. Этот процесс называется «Подготовка к выходу» [Pre Onboarding].

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

Подготовка к выходу [Pre Onboarding] включает в себя закупку техники и лицензий, создание учетной записи, которая попадает во внутренние системы, таск-менеджеры, системы контроля версий и системы управления учетными записями. HR-менеджеры и сотрудники корпоративной культуры подготавливают анонс выхода сотрудника, готовят welcome pack и осуществляют другие подготовительные действия. Помимо этого. HR-менеджер сообщает кандидату о том, какие документы потребуются для заключения договора.

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

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

Задачи Наставника:

— Отвечать новому сотруднику на возникающие вопросы

— Помогать правильно понимать процессы, стандарты, регламенты и принципы взаимодействия на практических возникающих ситуациях

— Помогать находить нужных людей в компании, чтобы получить доступы или другую информацию

— Помогать с выбором правильных решений при решении задач

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

Процесс Адаптации [Onboarding] начинается с выхода сотрудника на работу.

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

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

Поскольку встреча с тимлидом (наставником) может быть не очень ёмкой по объему информации, её могут запланировать и на следующий день. В рамках такой встречи тимлид рассказывает:

— О бизнесе и основных бизнес-процессах

— О продукте (ах)

— Применяемых технологиях

— Архитектуре

— Истории развития бизнеса, продуктов и команды

— Процессах, регламентах и соглашения в разработке

— О команде (составе, ролях, культуре других важных особенностях)

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

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

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

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

Испытательный период является частью Адаптации [Onboarding],

Испытательный период

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

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

Первая обратная связь

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

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

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

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

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

Вторая обратная связь

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

Окончание испытательного срока

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

Для этой встречи тимлиду необходимо:

— Запросить и получить от нового сотрудника обратную связь в свободной форме

— Собрать краткую информацию о предыдущих встречах по обратной связи

— Узнать мнение команды о новом сотруднике

— Провести оценку качества/сроков выполненных задач испытательного срока

— Сделать общую оценку уровня знаний и умений нового сотрудника

— Уточнить меняются ли какие-нибудь условия работы после прохождения испытательного срока (оклад, удаленный формат работы и др.)

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

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

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

Досье или личное дело сотрудника

У каждого сотрудника есть свой жизненный цикл в организации, включающий:

— Привлечение

— Найм

— Адаптацию

— Накопление опыта и эффективную работу

— Кадровый резерв и рост

— Увольнение

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

— Общую характеристику сотрудника

— Резюме и результат оценки знаний на собеседовании

— Итоги адаптационных встреч

— Отзывы коллег о сотруднике

— Значимые события (достижения, фатальные ошибки и конфликты)

— Премии, штрафы, индексация и пересмотры зарплаты

— Оценка персонала [Performance Review], направления роста и грейд

— Причина увольнения и сопутствующая информация

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

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

Дисциплина

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

Что обычно ожидается от сотрудника:

— Соблюдение дисциплинарных норм

— Соблюдение культуры организации и команды

— Результаты рабочего процесса

Для хорошего тимлида важен контроль всех трех пунктов. Простой пример: Сотрудник уходит на 2 часа раньше с работы, а на следующий день, с утра, у него готова задача. Хороший тимлид задастся вопросом: «А не была ли задача слишком простой? Возможно, на нее требуется один день вместо двух?». Если тщательно анализировать и исследовать соблюдение дисциплинарных норм, отслеживать общую картину производства и загрузки становится гораздо проще. В том числе это может предотвратить переутомление сотрудников, что хорошо скажется на общем эмоциональном состоянии коллектива.

Что подразумевается под дисциплинарными нормами?

— Соблюдение рабочего распорядка, в том числе доступность для связи в течение рабочего дня удаленных сотрудников

— Выполнение установленных норм и регламентных операций организации и команды

— Может быть отметка в системах учета рабочего времени

— Может быть чистота на столе

— Может быть требование возвращать на место после использования инструментов (канцелярии, книг и др.)

— Не опаздывать и присутствовать на встречах

— Следовать и выполнять регламентированные операции процесса разработки ПО

— Своевременное и точное выполнение распоряжений руководителя

— Может быть формат комментариев для пул-реквестов

— Может быть коммит промежуточных итогов в конце рабочего дня

Согласно трудовому распорядку, сотрудник должен работать заданное количество часов в день (или в неделю) из согласованного графика.

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

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

Также стоит помнить, что дисциплины не будет пока нет системы мотивации. Даже, если у организации не существует определенного регламента, тимлид все равно должен контролировать дисциплину в компании. Инструменты обеспечения дисциплины описаны в разделе «Мотивация».

Встречи «1 на 1»

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

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

— Куда планируешь отправиться в отпуск или как отдохнул в отпуске, где был?

— Что нового? Как семья?

— Для распределенной команды можно уточнять, где находится сотрудник территориально, какая у него там погода.

— Обсудить последние новости (как в компании, так и в мире)

Как правило, такие встречи проходят один раз в две недели или раз в месяц.

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

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

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

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

Административная работа

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

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

— Согласование графика отпусков, каждого отдельного отпуска, командировок

— Согласование заявок на закупку

— Фиксация данных переработок и их согласование

— Согласование табеля рабочего времени или отправка данных по больничным

— Различные отчеты для руководства

— Управление сервисами для организации разработки (таск-менеджер, репозиторий кода и др.)

Эти задачи уникальны для каждой организации.

Мотивация

Мотивация — это побуждение к действию.

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

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

Мы рассмотрим мотивацию через две основные призмы: материальность и эмоциональный окрас (т. е. позитивная мотивация или негативная).

Позитивная материальная мотивация

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

В принципе, это верно, но существуют и другие виды поощрений:

— Бонусы

— Премии

— Подарки

— Призы

— Опционы и доли

— Оплата обучения

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

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

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

Позитивная НЕматериальная мотивация

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

Вот еще несколько вещей, которые являются отличными примерами позитивной нематериальной мотивации:

— Благодарственное письмо

— Рекомендации для сотрудников в LinkedIn

— Интересные задачи

— Дать выходной

— Отпустить с работы пораньше

— Карьерный рост

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

Негативная материальная мотивация

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

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

Вот некоторые виды такой мотивации:

— Штраф

— Удержания (разовое наказание)

— Лишение премии

Негативная НЕматериальная мотивация

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

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

Вот некоторые виды негативной нематериальной мотивации:

— Порицание

— Выговор

— Уменьшение числа доступных программ соц. пакета

— Объяснительная

— Угроза увольнения

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

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

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

Поиск мотивации сотрудников

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

Несколько примеров вопросов:

— Опиши самый прорывной момент в работе

— Что помогло тебе прийти к состоянию такой высокой производительности?

— Опиши момент спада и почему он произошёл?

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

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

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

Оценка профессионального уровня и эффективности

Комплексная оценка профессионального уровня нужна организации, тимлиду, команде и сотруднику. Обычно она проводится 1–2 раза в год для соотнесения опыта и качества работы специалистов.

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

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

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

Если в вашей организации нет централизованной процедуры Оценки сотрудников [Performance Review I Assessment I Appraisal], проводите ее сами в рамках своей команды.

Оценка нужна для того, чтобы:

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

— Понять какие у сотрудника цели и ожидания от компании, оценка собственных достижений

— Оценить его текущий уровень компетенций (чтобы в том числе поставить вопрос о соответствии его текущей зарплаты)

— Оценить результаты задач роста прошлого периода и создать новые задачи для следующего периода

— Выявить неправильные взаимоотношения в коллективе, токсичных сотрудников. Похвалить сотрудника за позитивные отзывы.

Процесс Оценки сотрудников [Performance Review] включает в себя:

— Сбор статистических данных по профессиональной деятельности (количество и объем закрытых задач, количество возвращенных из тестирования задач и др.)

— Опрос команды и коллег о soft skills сотрудника (Опрос360)

— Интервью тимлида с сотрудником по достижениям за прошлый период, оценку hard и soft skills, итоги и потенциал роста

— Регистрацию результатов в Досье сотрудника

В качестве подготовки к процедуре рекомендуется составить для сотрудника набор вопросов и компетенций. Чаще всего эта информация должна соответствовать вопросам для собеседования на его должность.

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

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

Закон Гудхарта:

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

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

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

Система грейдов это стандартизация уровней специалистов. Создается шкала уровней компетенций, согласно которой происходит оценка. На систему грейдов опирается процесс пересмотра зарплат и процесс развития сотрудников.

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

Развитие сотрудников

— Вы не боитесь, что вы их обучите, а они уйдут?

— Боюсь, конечно. Но еще больше боюсь, что я их ничему не научу, а они останутся.

Дж. Уэлч (С 1981 по 2001 год генеральный директор General Electric. Его называли самым жестким боссом в мире. А потом журнал Fortune присвоил ему титул «Менеджер столетия»)

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

Процесс развития может быть инициирован следующими причинами:

— Запланировано, чаще всего после проведения Оценки сотрудников [Performance review]

— Определенная задача, для которой у сотрудников не хватает навыков

— Для изменения паттерна неправильного поведения. Т. е. когда сотрудник делает что-то не так, мы можем изменить его поведение с помощью развития

— Подготовка кадрового резерва

Инструменты для развития:

— Внутреннее и внешнее обучение

— Участие в конференциях и других тематических мероприятиях

— Сертификация

— Библиотека обучающих материалов (книги, видео и др.)

Что нужно развивать:

— Hard skills текущей должности

— Soft skills текущей должности

— Знание бизнес-процессов

— Hard skills следующей ступени карьерной лестницы (если сотрудник мотивирован карьерным ростом)

— Hard skills другой специализации (если сотрудник мотивирован горизонтальным ростом)

— Общие представление о работе окружающих специалистов

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

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

Формирование плана развития производится регулярно и требует определенных усилий со стороны тимлида. Инициацию построения и пересмотра плана обычно связывают с процедурой Performance Review.

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

Если в команде есть Эксперт («Звезда»), то наибольшую пользу принесет снятие с него рутинной работы. Такие изменения позволят максимально самореализоваться, что принесет компании большую пользу.

Расти профессионально или карьерно хотят почти все сотрудники, однако мотивация на это есть не у всех.

Увольнение сотрудников

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

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

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

Любой новый сотрудник — это инвестиция. Инвестиция бизнеса, которая может не оправдаться. Хороший тимлид, может и должен следить за инвестициями и обеспечивать их возврат в компанию. При увольнении сотрудника нужно предпринять действия, которые принесут компании максимальную пользу из уже вложенных инвестиций. Среди таких действий оценка bus-фактора и его максимальное увеличение. Этот принцип справедлив на испытательном сроке или после него по инициативе сотрудника или компании.

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

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

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

— Произошло ли это на испытательном сроке или после его окончания

— От кого исходила инициатива. Она можно исходить от работодателя или от сотрудника.

На испытательном сроке

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

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

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

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

По инициативе сотрудника

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

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

— Сотрудник переоценил себя и понял это в процессе работы

— Процессы и распределение обязанностей не подходит сотруднику

— Несистемная адаптация в компании, ничего не объяснили и неправильно поставили задачи

— Ошибка руководителя. Не обозначены роли, не построены базовые процессы, нет чёткой цели

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

Действия тимлида в случае увольнения сотрудника:

— Узнать обратную связь и причину увольнения, которая известна HR-отделу

— Провести встречу с сотрудником «1 на 1», попытаться выяснить причину ухода в личной беседе

— Сложить максимально позитивное впечатление о компании у уходящего сотрудника

— Объективно оценить обратную связь и исправить недочеты в работе адаптации, текущих процессах и др.

По инициативе компании

Основными причинами увольнения в этом случае могут быть:

— Сотрудник показывает низкую производительность или плохое качество работы вопреки оценкам на собеседовании

— Безответственное отношение к работе, дисциплинарные нарушения

— Сотрудник ведёт себя аморально с коллегами, проявляет неуважение, переходит принятые нормы поведения в коллективе/компании

— Сотрудник всячески саботирует внутренние ценности компании и противодействует им

Действия тимлида в случае увольнения сотрудника:

— Собирать необходимую информацию для аргументированного увольнения в течении испытательного срока

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

— Максимально обеспечить возврат инвестиций за время отработки

— Обратиться в НК для инициации процесса увольнения

— Провести встречу с сотрудником, HR-специалистом и своим руководителем для оглашения решения компании

— Сложить максимально позитивное впечатление о компании у уходящего сотрудника

После испытательного срока

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

По инициативе сотрудника

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

— Компания не повышает зарплату сотруднику, хотя зарплаты на рынке выросли

— Конфликт внутри коллектива

— Нет перспективы роста (горизонтального или вертикального)

— Задачи неинтересные, сотруднику не доверяют, он не имеет необходимых полномочий

— Сотрудника не ценят и его труд не уважают

— Изменились личные обстоятельства, проблемы личного характера

Действия тимлида в случае ухода сотрудника:

— Узнать обратную связь и причину увольнения, которая известна в HR

— Провести встречу с сотрудником «1 на 1», попытаться выяснить причину ухода

— Проработать варианты исправления ситуации (перевод в другую команду, проект), предоставить возможность роста, попытаться разрешить конфликт

— Максимально обеспечить возврат инвестиций за время отработки

— Сложить максимально позитивное впечатление о компании у уходящего сотрудника

По инициативе компании

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

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

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

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

Основными причинами на этой стадии могут быть:

— Компания решила сократить количество сотрудников

— Сотрудник показывает плохую производительность или качество работы

— Безответственное отношение к работе, дисциплинарные нарушения

— Сотрудник ведёт себя аморально с коллегами, проявляет неуважение, переходит принятые нормы поведения в коллективе/компании

— Сотрудник всячески саботирует внутренние ценности компании и противодействует им

Действия тимлида в случае увольнения:

— Собрать факты недобросовестной работы

— Попытаться исправить корневые причины, приведшие к увольнению

— Организовать передачу или документирование знаний, найм замены

— Несколько раз до процедуры увольнения встречаться с сотрудником «1 на 1» (или в другом формате), демонстрируя проблему и свое отношение к ней

— Обратиться в HR для инициации процесса увольнения

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

— Максимально обеспечить возврат инвестиций за время отработки

Совместная работа команды

Дизайн команды

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

Дизайн команды включает:

— Выявление роли команды в общем процессе, а также ценность, которую она должна создавать

— Моделирование процесса для достижения результатов

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

— Корректировка ролей с учетом рынка компетенций

— Найм людей заданных компетенций на соответствующие роли, в определенные локации

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

Распределенная команда имеет свои преимущества и недостатки:

— Есть возможность нанимать больше сотрудников (из других локаций)

— За счет смещения графиков работы можно расширить поддержку продуктов на нерабочее время (практика Follow-the-sun)

— Командам остается меньше времени на коммуникацию за счет сдвига по времени

— Коммуникация хуже за счет невозможности или редких очных встреч

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

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

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

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

— Градус недовольства бизнеса будет расти, поскольку оплачивать новых сотрудников уже нужно, а вместо подъема производительности получается падение. Получить прирост производительности можно спустя 3–6 месяцев. Мгновенный результат, который все ждут, в этой ситуации является утопичным.

Необходимо понимать, что, согласно лучшим практикам, менеджеры эффективно управляют 8–9 сотрудниками в команде. Это означает, что в определенный момент вам нужно будет создавать отдельные команды под вашим руководством. Это выходит за рамки роли тимлида, правильнее использовать руководство по ролям Руководитель группы разработки/CTO/CIO.

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

Тем не менее, среди того, что можно сделать это:

— держать документацию в актуальном виде (лучше меньше, но актуальную 100 %)

— иметь внедренные лучшие практики (поможет сослаться на литературу и не рассказывать о тонкостях текущего уникального процесса)

— иметь отлаженный механизм адаптации — Наставничество, Ознакомление с нужным материалом. Выдача прав. Оценка испытательного периода

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

— Вы можете оставить только часть, максимально лояльных сотрудников

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

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

— Суметь сделать очень дешево и качественно, насколько это возможно

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

— Вернувшись на шаг исполнителя в некоторых вопросах, вы оптимизируете работу на этих участках

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

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

Команда — это не отдельные исполнители и даже не набор ролей. Команда — это коллектив, работающий совместно для достижения определенной цели.

Согласно Модели Такмана, команда проходит несколько стадий своего формирования:

— Формирование (Forming)

— Конфронтация (Storming)

— Нормирование (Norming)

— Функционирование (Performing)

— Расставание (Adjourning)

Среди Soft skills, которые вы определяете у новых сотрудников важно сразу понять, насколько они подойдут вашей команде, её особенностям и микроклимату, а также культуре компании.

Построение командной работы это:

— Гармонизация работы и исключение (уменьшение) конфликтных ситуаций

— За счет совместимости взглядов

— За счет общих ценностей

— За счет личных качеств

— Описание передаваемого результата труда от одних специалистов другим в процессе разработки

— Определение принципов общения и взаимодействия (ими руководствуются сотрудники, если не определен интерфейс взаимодействия)

— Преодоление сотрудниками личных барьеров на мероприятиях по укреплению команд

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

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

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

Пример:

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

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

— Развивать доверие между сотрудниками

— Создавать опыт продуктивной коммуникации

— Формировать навыки успешного взаимодействия

— Повышать личной ответственности за результат и повышать неформальный авторитет руководителя

— Развивать лояльность к другим участникам команды и компании

Не стоит недооценивать такие мероприятия, Платон говорил:

Ты узнаешь больше о человеке за час игры, чем за год разговоров.

Общение на teambuilding мероприятиях должно проходить естественным способом, но, если этого не происходит, необходимо заняться поиском общих интересов.

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

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

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

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

Управление компетенциями

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

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

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

Преимущества совмещения функций:

— оценка задач, содержащих набор функций производится быстрее

— реализация задач, содержащих набор функций производится быстрее

— упрощается интеграционная коммуникация исполнителей разных функций

Недостатки совмещения функций:

— глубина знаний отдельной функции ниже

— качество исполнения отдельной функции ниже (исполнители фокусируются на кросс-функциональном результате)

— заменить исполнителя совмещенных функций сложнее

Применение Full-stack разработчиков против отдельно специализированных на Backend и Frontend ярко демонстрируют преимущества и недостатки разделения труда. Менее очевидным может казаться выделение роли Системного аналитика в общем процессе. Хотя при правильно выстроенном процессе и регламентированных результатах работы специалистов польза будет очевидна.

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

Кросс-функциональным командам требуется постоянно синхронизировать уровень своих компетенций.

Где найти ресурсы для выполнения определенных функций? Могут подойти:

— уже имеющиеся члены команды, если у них есть эти знания и навыки

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

— сотрудники других подразделений

— нанимаемые новые сотрудники

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

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

Планирование компетенций основано на планировании ожидаемых результатов от команды и приводит к:

— перераспределению функций в команде

— организации обучения

— передаче ожиданий от команды в другие команды

— передаче работы на аутсорс

— открытию вакансий

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

Начинающие разработчики

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

Культура команды (микроклимат)

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

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

Пример таких принципов:

— Знайте кто ваш тиммейт

— Проявляйте заботу и взаимопомощь

— Уважайте и доверяйте тиммейту

— Проявляйте аккуратность

— Смело делитесь идеями и своим видением

— Воспринимайте критику адекватно

— Разрешайте конфликты конструктивно

— Задавайте любые вопросы, отвечайте на «глупые» вопросы сдержанно

— Будьте вежливы и выражайтесь корректно

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

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

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

Преемственность принципов общения внутри команды должно проверяться на собеседовании и далее воспитываться в период адаптации.

Распределенные команды страдают от следующих проблем:

— Непрозрачно изменение настроения

— Непрозрачно изменение мотивации и вовлеченности

— Вовлеченность постепенно падает

— Ухудшается коммуникация, что приводит к конфликтам

— Страдает адаптация

Решением этих проблем являются:

— Встречи «1 на 1»

— Командировки для личного общения

— Мероприятия, укрепляющие команду

— Регламентирование процессов адаптации, включение в него большего количества контактов

Стиль управления

Существует различная классификация стилей управления:

— Теории Дугласа МакГрегора

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

— Принцип Лайкерта

По сути, продолжение теорий МакГрегора, где Ренсис Лайкерт проецирует усилия на людей или на задачи. Таким образом у него получились следующие стили управления:

Эксплуататорско-авторитарный стиль, который является самым жестким. Подчиненным такой руководитель не доверяет от слова «совсем», мотивирует чаще угрозой наказания, чем вознаграждением. Сотрудники выполняют распоряжения только из страха и, в свою очередь, не верят руководителю. Сокращение дистанции между ними невозможно.

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

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

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

— Классификация Курта Левина

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

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

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

— Управленческая решетка Блейка-Моутона

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

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

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

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

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

Принятие решений внутри команды с наличием тимлида можно разделить на следующие варианты:

Авторитарный — тимлид единолично принимает решения без совещаний с командой.

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

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

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

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

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

— поддержка применяется в том случае, если для сотрудников особенно важно чувство принадлежности к коллективу;

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

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

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

От выбранного стиля руководства зависит:

— Результативность команды (качественная и количественная)

— Психологический климат в коллективе

— Текучесть кадров

— Саботаж задач

— Наличие новых идей

— Сплоченность команды

В мире разработки ПО есть несколько моделей лидерства в командах:

— Самоорганизованные команды (нет лидера)

— Классическая модель лидера

— Servant Leadership

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

— Принимаются решения

— Решаются конфликты

— Даётся обратная связь

Управление конфликтами

Конфликты — это столкновение противоположно направленных целей, интересов, позиций, мнений или взглядов оппонентов и субъектов взаимодействия.

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

Общий алгоритм, действующий во всех случаях:

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

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

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

— Взвесить и принять решение.

— Убедиться в том, что решение соблюдается.

С позиции тимлида есть 4 разных вида конфликта:

— Между членами команды

— Между членом команды и другими подразделениями (партнерами вне организации)

— Между членом команды и самим тимлидом

— Между тимлидом и его руководством

Для рабочих конфликтов между сотрудниками применяется следующий подход:

— Верните всех к рабочему процессу и отложите решение проблемы

— Когда все остынут, соберите их лицом к лицу в одном помещении

— Обозначьте формат дискуссии: обмен фактами в качестве аргументов без эмоциональной окраски, с уважением друг к другу

— Копайте всё глубже, чаще люди говорят о последствиях, а не о первопричинах. Для этого может подойти техника «5 почему».

— Когда все первопричины выявлены, проработайте план дальнейшего решения проблемы с обеими сторонами

— Возьмите со всех обещание, что впредь разрешение конфликтов будет основываться на принятых нормах коллектива (конструктивный мирный диалог и эскалация)

— Лично проконтролируйте соблюдение сторонами договоренностей

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

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

Если конфликт произошел у подчиненного с вами (с руководителем), важно четко определить причину конфликта и самокритично ее проанализировать. Не с точки зрения вас, а с позиции интересов компании. Умейте признавать ошибки, если вы были неправы. Непризнание и нежелание бороться с ошибками причинит вред компании. Более того, сотрудник может поделиться информацией с другими, что нанесет урон вашей репутации. Если же ваш сотрудник не признает свои ошибки и недостатки, то в вашей власти принимать окончательное решение (но опять же отталкиваясь от максимальной пользы для компании). При необходимости для разрешения конфликта придется привлечь третью сторону — HR-менеджера, поскольку даже, если ваш подчиненный согласится, он может остаться при своем мнении.

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

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

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

Адаптация тимлида в команде

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

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

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

У вас не будет второго шанса произвести первое впечатление.

Коко Шанель

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

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

Составляющие авторитета:

— Компетенция и профессиональные знания

— Управленческие умения и Личностные проявления

— Авторитетный образ:

— Стильный образ

— Авторитетные знакомства

— Позитивное мышление

— Интерес к жизни сотрудников

— Амбициозные цели

— Легенды, мифы

Что нужно делать:

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

— Рассказать про себя. В рассказе о себе необходимо упомянуть о компетенциях и проф. достижениях, о своем опыте и целях. Показать ваше отношение к командам на прошлых местах работы — как вы защищали их, развивали, как принимали решения.

Интеграционные коммуникации

Знание бизнес-процессов и организационные структуры компании

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

Бизнес-процесс — это набор действий, приводящих к определенному ожидаемому результату.

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

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

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

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

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

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

Знание регламентных документов компании

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

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

К таким документам могут относиться:

— Правила внутреннего распорядка

— Политика информационной безопасности

— Положение о премировании

— Положение о пересмотре заработных плат

— Антикоррупционная политика

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

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

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

Понимание и принятие культуры компании

Под корпоративной культурой подразумевается набор элементов:

— видение развития компании — направление, в котором движется организация, ее стратегические цели;

— ценности — что является наиболее важным для компании;

— традиции (история) — сложившиеся со временем привычки, ритуалы;

— нормы поведения — этический кодекс организации, в котором прописаны правила поведения в определенных ситуациях (например, в McDonald’s создали целое руководство толщиной в 800 страниц, в котором прописана каждая возможная ситуация и одобренные руководством варианты ее решения: действия сотрудников по отношению друг к другу, к клиентам компании и т. д.):

— корпоративный стиль — внешний вид офисов компании, интерьер, фирменная символика, дресс-код сотрудников:

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

— вера и единство команды ради достижения определенных целей:

— политика ведения диалога с клиентами, партнерами, конкурентами:

— люди — сотрудники, которые разделяют корпоративные ценности компании.

Функции корпоративной культуры:

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

Мотивационная. Вдохновляет сотрудников на достижение поставленных целей и качественное выполнение рабочих задач.

Вовлекающая. Активное участие каждого отдельного члена коллектива в жизни компании.

Идентифицирующая. Способствует самоидентификации сотрудников, развивает ощущение собственной ценности и принадлежности к команде.

Адаптивная. Помогает новым игрокам команды быстро вливаться в коллектив.

Управленческая. Формирует нормы, правила управления командой, подразделениями.

Системообразующая. Делает работу подразделений системной, упорядоченной, эффективной.

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

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

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

Взаимодействие с другими подразделениями

Тимлид — это роль, которой команда делегирует представительство (голос) для внутрикорпоративного взаимодействия. Когда от команды требуется представитель для диалога с другим подразделением, появляется тимлид.

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

— Открытый диалог, доверие и терпимость.

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

— Понимание единства целей превращаем в решения.

Вы, как и другие подразделения стараетесь принести пользу компании. Глобально цели всей компании могут быть противоречивыми: «Сократить расходы на 30 % в первом квартале». «Захватить новый сегмент рынка». Руководители должны стараться согласовывать действия и их приоритеты. Другие подразделения могут ничего не знать о пользе вашей работы, так же, как и вы можете ничего не знать об их вкладе. Когда вы начинаете любое взаимодействие, помните о том, что польза от вашей работы для всей компании может оказаться меньше по сравнению с другим отделом. Правильным решением в таком случае будет выполнить ваш запрос с меньшим приоритетом, это как раз и составит максимальную выгоду для всей компании. Для четкой и правильной приоритезации необходимо описать последствия отложенного решения, его влияние и ценность вашей заявки в рамках компании.

— Регламентируем там, где нужно.

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

— Сотрудничество, а не соперничество.

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

— Эскалация в необходимых случаях.

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

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

Строить стены плохо, как их разрушить?

— Наладить обмен информацией между подразделениями и повысить ее прозрачность.

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

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

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

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

Управление ожиданиями от команды

Начните с вопросов:

— Зачем команда существует?

— Зачем команда нужна будет дальше?

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

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

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

Старайтесь максимально конкретизировать цели (в идеале по S.M.A.R.T.) — не завышайте ожидания, оставляйте резервы для покрытия рисков и заранее продумывайте шаги для достижения поставленных целей. Поскольку это командная работа, она не может избежать влияния внешних факторов. Ваша задача определить их и скорректировать ожидания от команды. Правильный подход: «задача будет сделана в срок, если мы…». Также стоит учитывать дополнительные расходы при определении сроков на поддержку продуктов, плановый рефакторинг и др.

В разных компаниях по-разному выстроен процесс формализации ожиданий и их управления, он может опираться на результаты:

— Спринтов

— Дорожной карты

— Системы контрактов.

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

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

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

PR и DevRel

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

Как этого можно добиться:

— Публиковать наиболее интересные задачи, которые вы решили

— Увлеченно рассказывать о ваших специалистах

— Приглашать другие подразделения на открытые внутренние доклады

— Публиковать статистику решаемых задач, метрик систем в проде

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

Основная цель DevRel — повысить узнаваемость бренда, что улучшит процесс найма.

Деятельность, развивающая DevRel:

— Участие в open-source проектах

— Публикация исследовательских задач, с которыми вы сталкиваетесь в работе, и их результатов

— Участие с докладами или вопросами в конференциях и митапах

— Участие в хакатонах и интервью

Деятельность PR и DevRel организации невозможна без привлечения компетентных сотрудников. Ваша инициатива и участие — ключ к успеху компании.

Владелец процесса разработки

Принципы построения процессов

При построении процессов необходимо придерживаться следующих принципов:

— Каждый процесс имеет определенную цель, вы должны сформулировать ее четко и ясно

— Превратите цель в последовательную модель входов-выходов

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

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

— Учитывайте компетенции команды при моделировании процессов

— Выделите основной процесс и обеспечивающий (помните о процессах управления)

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

Само описание процесса может быть представлено в виде:

— Регламента

— Диаграммы процесса

— Принципов действия в случае, если не регламентировано процессом

— Описанием кейсов

— Деревом принятия решения

Современное описание процесса включает:

— Наименование, версию. ФИО автора, дату изменения

— Диаграмму процесса (IDEF0, EPC, BPMN)

— Описание ролей

— Описание входов и выходов у процесса (из каких процессов приходят и в какие последующие процессы передаются)

— Описание действий или ссылку на бизнес-процесс действия

Построение бизнес-процесса — это процесс, состоящий из следующих шагов:

— Собираются и анализируются требования, цель процесса, способы достижения цели

— Формируется Проект изменения Бизнес-процессов

— Строится диаграмма «AS IS» и из нее рождается схема «TO BE»

— Предварительная схема процесса должна согласовываться со всеми участниками процесса.

— Готовятся документы, разрабатывается/дорабатывается ПО, автоматизирующее бизнес-процесс.

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

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

Здравый смысл всегда важнее любых выстроенных процессов. Этот принцип должен проходить красной нитью через любые формализованные процессы.

Нотации описания процессов

Модель IDEF0 возникла в армии, точнее, в ВВС США в 1980-х годах. Схема разворачивается одновременно слева направо, сверху вниз и по диагонали. Объекты, расположенные левее / выше, доминируют над теми, которые находятся правее/ниже. Доминирующие объекты могут включать в себя зависимые. Например, доставка заказа — это элемент, входящий в состав более масштабного процесса управления заказами. Также доминирующие объекты могут являться предшествующими этапами для зависимых: получение заявки — согласование заявки.

Графические элементы:

— Прямоугольники — действия или этапы.

— Стрелки — ресурсы, исполнители, необходимые для совершения действия или прохождения этапа.

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

Она позволяет создать модель, которая будет отражать:

— Структуру системы

— Функции

— Потоки ресурсов, информации

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

Базовая нотация BPMN включает не более 10 типов значков и помогает описать алгоритм в понятной неподготовленному бизнес-пользователю форме. Расширенная BPMN содержит около 100 значков и позволяет сделать регламент машиночитаемым, не допуская разночтений.

Её центром является именно бизнес-процесс, алгоритм прохождения которого она и показывает.

Основные элементы BPMN:

— Задача (прямоугольник)

— Событие (круг)

— Шлюз, развилка (ромб)

— Поток, ход (стрелка)

— Базы данных, документы

— Сноски

— Пулы

Главное преимущество BPMN — описание именно бизнес-процесса, делая его понятным даже для рядовых сотрудников. Сегодня BPMN пользуется популярностью. Большинство вендоров, предлагающих системы ВРМ, предусматривают работу с BPMN — схему, созданную с её помощью, можно сделать исполняемой подключив возможности информационной системы.

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

EPC (Event-driven Process Chain), фокус сделан на событиях.

Схема использует значительно больше элементов — разноцветных фигур:

— Розовые фигуры — события

— Зелёные — функции (действия)

— Жёлтые — исполнители

— Серые — ресурсы

— Оранжевые — информационные системы

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

В качестве соединительных элементов используются, помимо стрелок, разделители «и», «или», «исключающее или». Благодаря этому ЕРС лучше подходит для ветвящихся бизнес-процессов.

Чтобы выстроить схему, сначала определяется стартовое/финальное событие, затем — промежуточные события и необходимые для них исполнители, ресурсы.

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

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

Главный недостаток ЕРС в том, что её структурной единицей является событие, которое приходится создавать даже для самых незначительных этапов. ЕРС также справедливо критикуют за обилие тавтологических элементов: задача «определить исполнителей» — событие «исполнители определены», задача «согласовать договор» — событие «договор согласован». Если схема длинная и сложная, подобные и многочисленные стрелки от «исполнителей» к «событиям» ее перегружают. Особенно если один исполнитель отвечает за множество дел или на одно событие назначено несколько сотрудников.

При выборе нотации для описания процесса учитываются следующие факторы:

— IDEF0 удобнее использовать для верхнеуровневого описания процессов

— BPMN имеет протокол описания XML (BPMN 2.0) и может быть автоматизирован, например продуктом Camunda

— ЕРС легче для чтения процесса целиком, но сложнее при выделении действия для конкретной роли

На практике если процесс небольшой, его описывают в BPMN (для этого есть бесплатный удобный редактор https://bpmn.io/). Если процесс масштабный, то его дробят на более мелкие составляющие, которые описываются в BPMN, но верхнеуровнево все эти процессы связываются в схемах IDEF0.

Внедрение процессов или изменений

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

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

Запуск процесса состоит и следующих шагов:

— Информирование о начале работы согласно новому процессу (со сносками на документацию)

— Выборочный контроль исполнения шагов

— Общий контроль исполнения процесса

— Получение обратной связи от участников процесса

— Оценка эффективности нового процесса

Что может пойти не так:

— Сотрудники не следуют новому процессу умышленно (саботаж). Для начала необходимо выслушать доводы сотрудников, с чем они не согласны. Вероятно, вы не вовлекли сотрудников в этап проектирования процесса, что породило их несогласие.

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

— если их доводы не разумные, объясните почему.

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

— Сотрудники не знают, как правильно следовать новому процессу.

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

— Новый процесс имеет критические ошибки и нуждается в пересмотре

Контролируйте новый процесс первое время, как писал пластический хирург Максвелл Мальц: «Человеку нужен 21 день, чтобы привыкнуть к изменениям своего тела». Этот срок в «21 день» применяют и для других случаев, где людям необходимо привыкнуть к чему-то новому. Если это редкий процесс, то отсчитывайте 7–9 итераций этого процесса до смягчения вашего контроля.

Эволюция процесса разработки

Конструируя свой процесс, необходимо отталкиваться от основных параметров:

— Долгосрочное или краткосрочное сотрудничество у вас с заказчиком

— Насколько жестко ограничены срок и требования к продукту

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

— Меняются люди в команде

— Меняется количество людей в команде

— Меняются требования к качеству продукта

— Появляются риски, которые сыграли

— Подходит плановая оптимизация процесса

— Появляются жалобы и предложения

Вам нужно будет достаточно часто менять и адаптировать процесс разработки к изменяющимся условиям. Есть лучшая практика для оптимизации процессов — Цикл Деминга.

Цикл Деминга (PDCA) закладывает в управление процессом постоянное улучшение качества.

Эдвард Деминг заложил два варианта для цикла управленческих действий постоянного улучшения качества: PDCA (планируй/Plan — делай/Do — проверяй/Check — корректируй/Act) и PDS А (планируй/Plan — делай/Do — изучай/Study — корректируй/Act):

— Планирование: установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.

— Выполнение: выполнение запланированных работ.

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

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

Цикл Деминга ни что иное как здравый смысл, примененный к любому происходящему во времени процессу, которому необходимо постоянное улучшение. Процесс непрерывного совершенствования поддерживается многими методологиями. Например, в Scrum есть встречи Sprint Retrospective, а в ITIL есть Continual Service Improvement. Так или иначе все приходят к реестру, процессу выявления улучшений и плановой работе с ними.

Есть несколько способов поиска улучшений:

— Анализ потерь на всех этапах решения задач. Такой анализ может происходить на встречах Sprint Retrospective.

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

Лучшие практики разработки и особенности их применения

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

Kanban (применяем при высокой неопределенности в приоритетах/размерности задач/ бэклоге)

— Доска для наглядности не сможет вместить большого количества тикетов

— Работать с подзадачами на доске неудобно

— Приоритеты можно менять на лету

— Нет издержек на оценку задач

— Сложно попасть в сроки по плановым задачам

Scrum (применяем если можем планировать на 3+ итерации, нет фиксированного бюджета или требования могут измениться)

— не работает с совмещенными ресурсами (сотрудники, выполняющие задачи разных команд)

— работает в условиях краткосрочного планирования

— подразумевает отсутствие четкого конечного образа продукта

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

— подразумевает само-организованные команды, что требует найма команды с определенными soft skills

— ввиду избегания конечного образа продукта страдает область архитектурного планирования

ServiceDesk (применяем, если необходимо обеспечить единый временной норматив выполнения заявок)

— отсутствует планирование

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

— приоритет выставляет поддержка, а не бизнес.

Существует еще множество различных лучших практик, подробно рассмотреть их в рамках данной книги невозможно. Для себя вы можете почитать про RUP, ITIL. RAD, Lean SD, Six Sigma, MSF. XP. PMBOK. Prince2. Но стоит четко отделять практики WoW (way of working) вашей команды, от практик корпоративного уровня SAFe, LeSS, Disciplined Agile.

Менеджер процесса разработки

Менеджер контролирует выполнение процесса, спроектированного Владельцем процесса.

«Управляешь только тем, что можешь измерить»

американский ученый и публицист Питер Друкер

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

Как собирать информацию?

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

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

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

На основании анализа репозитория и сервиса проведения ревью можно собрать множество метрик, например:

— выгорания — коммиты, комменты в нерабочее время

— лени — мало кода, мало коммитов, мало ревью, мало задач, мало активных дней

— фокуса на задачу — простой после ревью, простой после тестирования и ожидание релиза

— качество — churn, возврат из тестирования, фиксы на проде

— bus-фактор — области изменения кода

— качество постановки задач — частота изменений описаний, churn

— технический долг — высокий complexity, низкий уровень рефакторинга legacy

Как выявлять проблемы?

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

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

Как реагировать?

Есть 3 варианта реакции на выявленные проблемы:

— Коммуникация с другими подразделениями и внешними контрагентами

— Исправление процесса с владельцем процесса

— Управленческое воздействие на сотрудников

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

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

Наконец, ваши сотрудники могут не соблюдать предписанный процесс (умышленно или неосознанно). Сами управленческие воздействия мы разбирали выше в блоке «Мотивации членов команды».

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

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

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

Аналитика

Вход процесса: Заинтересованные лица, требования к системам

Цели процесса:

— Оценка объема аналитики по задачам

— Скорректированные ожидания заказчиков

— Согласованное описание требований заказчиков

— Обновленная документация продукта

— Обученные сотрудники, проведенное демо и др.

Метрики:

— Удовлетворенность работой аналитика (Заказчик/Архитектор/Разработчик/…)

— Количество задач с описанными требованиями

Программирование

Вход процесса: Согласованные требования по задаче

Цели процесса:

— Оценка сложности и времени выполнения задач

— Написание кода, реализующего рабочие требования

— Проверка соответствия кода соглашениям/стандартам

Метрики:

— Соответствие времени решения задачи плановым показателям

— % прохождения статического анализа кода

— % прохождения автоматизированного тестирования

— % прохождения ручного тестирования

— Количество выполненных задач

— Объем выполненных задач

Контроль качества

Вход процесса: Выполненная задача

Цели процесса:

— Оценка сложности и времени тестирования задач

— Соответствие нового функционала заданным требованиям и ожиданиям заказчика

— Отсутствие дефектов в связи с внедрением нового функционала

Метрики:

— Оценка сложности и времени тестирования задач

— Среднее время ожидания тестирования

— Скорость тестирования задач

— % пропущенных ошибок

— % автоматизированных тест-кейсов

Качество можно рассматривать шире, например в рамках теории Total Quality Management.

Публикация новых версий

Вход процесса: Готовая к публикации новая версия

Цели процесса:

— Опубликованная новая версия

— Минимальный ущерб в связи с публикацией новой версии (простой, ошибки)

— Минимальная стоимость процесса сборки и публикации

Метрики:

— Среднее время ожидания публикации задачи после успешного тестирования

— Сумма простоя в процессе публикации

— Количество инцидентов во время публикации

— Количество публикаций в целом

Обслуживание и поддержка

Вход процесса: Система, с которой работают пользователи

Цели процесса:

— Минимизация времени обслуживания заявок пользователей

— Минимизация отказов и времени даунтайма системы

— Минимизация стоимости процесса

Метрики:

— Метрики SLA

— Uptime

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

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

Прием, распределение и контроль задач в подразделении

Качество постановки задач

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

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

Методики постановки задач:

— S.M.A.R.T. является аббревиатурой, где каждая буква означает критерий эффективности поставленных целей или задач.

— Specific — (конкретный) — нацельте на конкретную область для улучшения

— Measurable — (измеримый) — дайте количественную оценку или предложите показатель прогресса

— Assignable/Attainable — (назначаемый/достижимый) — укажите конкретного исполнителя

— Realistic — (реалистичный) — опишите, какие результаты могут быть реально достигнуты при наличии ресурсов

— Time related/Tangible — (связанный со временем/осязаемый) — укажите, когда может или должен быть достигнут результат

— User story (пользовательские истории). Если говорить про Agile разработку, то пользовательские истории рекомендованы как наиболее простой и понятный заказчику способ. Но вместе с простотой появляются проблемы с невыявленными требованиями. Предложено несколько формул пользовательских историй:

— Я как <Роль> могу <Функционал>, чтобы <Получить ценность>

— Для того чтобы мне <Получить ценность> как <Роль>, я могу <цель/возможность>

— Как <Кто> <Когда> <Где> я <Хочу>, потому что <Причина>

— К пользовательским историям и не только часто применяется I.N.V.E.S.T. метод

— Independent (независимость) — Старайтесь избегать создания задач, которые зависят друг от друга

— Negotiable (обсуждаемость) — задачи не являются формальным контрактным обязательством или требованиями

— Valuable — ценность для пользователя и покупателя

— Estimable (оцениваемость) — разработчики должны иметь возможность оценить размер задачи

— Small (компактность) — от размера задачи зависит очень многое, слишком большие и слишком маленькие задачи сложно оценивать

— Testable (тестируемость) — подтверждением того, что задача разработана успешно, служит удачное прохождение тестов

— DoD (Definition of Done) — критерий готовности, некий формальный набор работ/мероприятий, свидетельствующий о законченности задачи. В этот список могут попасть автотесты, документация и проведено ревью. Набор необходимых условий для решения задачи.

— Acceptance Criteria — критерии приемки, конечный набор свойств системы, говорящий о том, что задача выполнена. Набор достаточных условий для решения задачи.

— Технические задания по ГОСТу или нет — ёмкие опросники со множеством вопросов, которые раскрывают перечень различных требований.

— Есть еще некоторый набор интересных подходов CLEAR, PURE, CPQQRT

Какой же метод выбрать? В чем компромисс?

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

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

— Задачи, имеющие высокую ценность для бизнеса

— Задачи, ошибка в которых будет дорого стоить для бизнеса

Методы оценки задач, риски

Зачем оценивать задачи?

— Для планирования и понимание того, когда и какой функционал может появиться

— Для оценки экономической целесообразности реализации этой задачи

— Для оценки эффективности работы команды

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

Как происходит оценка:

— Ознакомление с требованиями задачи, уточнение вопросов.

— Проектирование решения, валидация спроектированного решения.

— Декомпозиция спроектированного решения.

— Оценка сложности и объема исполнения, а также рисков, связанных с реализацией и процессом.

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

Оценка НЕ РАВНО (#=) срок реализации. Оценка — это длительность выполнения задачи. Срок реализации — это результат процесса планирования оцененных задач.

Единицы измерения оценки задач:

— Человеко-часы или человеко-дни, реже недели или месяцы

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

— Story points — измеряют усилия, которые нужны, чтобы выполнить элемент Бэклога Продукта или любой другой отрезок работы. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. История, которой присвоено значение 2, должна быть вдвое больше истории со значением 1 и соответствовать двум третям истории со значением 3.

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

— У разных команд будет разный размер Story point. Не стоит приводить их в соответствие без особой необходимости.

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

— Без оценок

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

Существуют различные техники оценки задач:

— Покер планирование (с вариациями оценки Фибоначчи, размерами футболок, выкидыванием значения на пальцах) — игра с принятием индивидуальных решений по оценке и групповым анализом индивидуальных оценок.

— Диаграмма сходства (Affinity Mapping) — объединения схожих по трудности/объему/рискам задач в группы.

— Дерево декомпозиции — классическое разбиение задачи на части и их оценка.

— Сортировка задач — упорядочивание задач по шкале времени.

Планирование и декомпозиция задач

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

«Любой план — это ложь!», сказал мне как-то топ-менеджер Zara в процессе автоматизации их склада. Но зачем люди этим занимаются? Выстраивание планов — это поиск, попытка привести действия команды к наиболее оптимальному получению результата.

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

Обычно необходимо ответить на вопросы — какие задачи будут решены за следующую итерацию (спринт) или когда будет завершен проект?

Планирование проектов — это отдельная область, описанная в РМВОК, Prince2 и других гибких методологиях. В основном такое планирование опирается на:

— выявление задач

— нахождение и выстраивание параллельной работы

— нахождение зависимых задач и решение задач критической цепи

Планирование проектов производится с помощью Диаграммы Ганта.

Для планирования итераций (спринтов) можно также применить принципы планирования проектов, но в упрощенном варианте. Однако будет полезным не только выявлять зависимости и критический путь, но и распараллелить работы. В повседневном планировании вы занимаетесь распределением задач между исполнителями или установкой определенных правил распределения задач.

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

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

Делегирование и эскалация

Делегирование — процесс передачи части функций другим членам команды.

Принципы делегирования:

— ожидаемые результаты

— обозначить ответственность

— наделить необходимыми правами (всестороннее делегирование, но без избыточных прав)

— делегирование лицу, имеющему необходимые компетенции

— своевременность делегирования

— отсутствие конфликтов по части ответственности

— поддержка при выполнении функций

— возврат полномочий (обозначить время/событие и процесс)

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

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

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

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

Шаги эскалации в проектном управлении:

— Проинформировать вышестоящее лицо, имеющее полномочия решить проблему

— Проанализировать причины проблемы и ее потенциальное влияние

— Разработать несколько альтернативных решений проблемы и оценить их достоинства и недостатки

— Описать ситуацию вышестоящему лицу, с вариантами решения и собственными рекомендациями

— Объяснить последствия несвоевременного решения проблемы

— Задокументировать результаты эскалации и зафиксировать извлеченные уроки

Повседневный контроль задач

Для разных процессов повседневный контроль задач будет отличаться. Так или иначе он сводится к:

— получению сводной информации по прогрессу задач

— выявлению задач, где необходимы управленческие решения

— решению проблем и задач

Что может дать сводную информацию по прогрессу?

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

— Для итерационных процессов применяется диаграмма сгорания

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

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

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

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

Автоматизируйте повседневную работу с помощью ботов, которые напомнят сотрудникам о:

— Зависших задачах

— Актуализации статусов, оставшемся времени по задачам и дотировании затраченного времени на задачи

— Текущих метриках спринта, показателях эффективности

Прием результатов

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

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

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

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

Технический лидер

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

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

Существует 2 варианта технического надзора в команде:

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

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

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

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

За что отвечает технический лидер:

— План будущего использования технологии

— Стандарты, регламенты, ограничивающие способ использования технологии в компании и отдельных проектах

— Контроль технологических стандартов и регламентов в отдельных частях работ или итоговых результатах

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

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

Обеспечение наилучших условий труда и инструментов

Выбор инструментов разработки

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

Как выбрать инструменты, которыми команда будет пользоваться?

Есть несколько критериев, влияющих на выбор:

— Функциональность и надежность

— Стоимость

— Опыт компании и коллег

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

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

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

Разработка своих собственных инструментов (если речь идет о значительных затратах времени) должна оцениваться бизнесом как длительные вложения.

Автоматизация процесса разработки

© Виктор Большаков, 2022

ISBN 978-5-0055-9147-0

Создано в интеллектуальной издательской системе Ridero

Введение

Зачем вам эта книга

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

Основой для написания книги послужили опыт из различных доступных источников и структура компетенций TeamLead Roadmap [https://tlroadmap.io/], за что автор выражает большую благодарность сообществу. Однако мнение автора частично отличается от вышеупомянутых компетенций: для ознакомления читателя с имеющимся мировым опытом и опытом автора, структура функций в книге заполнена практиками и принципами.

Данная книга будет полезна для специалистов в сфере разработки:

– Действующему тимлиду

– Разработчику, планирующему стать тимлидом

– Руководителю групп разработки, CIO, CTO, CDTO

– Руководителю подразделения разработки ПО

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

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

Руководителю групп разработки, CIO, CTO, CDTO эта книга позволит задать стандарты работы в организации, провести повышение квалификации тимлидов, оценить их квалификацию по компетенциям и даже написать требования к вакансии тимлида или должностной инструкции.

Руководителю подразделения разработки ПО, такому как Системного администрирования, Контроля качества, Проектного офиса и др., книга раскрывает функции управления командой.

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

О роли

Тимлид [Team Leader] – роль лидера команды разработки, которая включает в себя организацию эффективной работы команды и обеспечивает ее максимальную ценность для организации.

Определение в wikipedia [https://en.wikipedia.org/wiki/Team_leader] звучит иначе, но отражает ту же самую суть.

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

Разделение труда в организациях очень разнообразное. В крупных компаниях разделение труда более детализировано – поле деятельности тимлида сужается, что повышает эффективность выполнения оставшихся в его зоне ответственности функций. Например, в некоторых организациях есть роль Владельца продукта [Product Owner], что позволяет тимлиду в меньшей степени заниматься проектированием функционала систем. Предположим, в другой части компаний есть роль Руководителя проектов [Project Manager], которая снимает с тимлида функции построения планов и контроля выполнения этих планов. В небольших стартапах роль тимлида может включать в себя функции Владельца продукта [Product Owner], Руководителя проекта [Project Manager], Релиз-инженера [Release Engeneer], ИТ директора [CIO], Технического директора [CTO] и др.

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

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

Карта компетенций

Компетентность – способность (знания и опыт), позволяющая эффективно выполнять определенный класс профессиональных задач.

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

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

Контекст деятельности

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

Факторы, влияющие на деятельность тимлида:

– Организация, в рамках которой работает команда:

– Роли и конкретные сотрудники на тех или иных должностях

– Регламенты, политики и правила организации в части:

– работы с сотрудниками

– реализации процессов разработки

– формата общения между командами/подразделениями

– общие требования к программным продуктам

– Ресурсы для мотивации сотрудников

– Доступные тимлиду и команде инструменты для достижения целей

– Корпоративная культура

– Команда

– Программный продукт или продукты, над которыми работает команда

– Качество постановки задач, формализации целей входящей информации

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

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

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

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

Управление сотрудниками

Найм

Перед тем как раскрыть тему найма новых сотрудников, приведу напутствующие слова Мариэтты Парсекян (HR директора компании Dats. Team) тимлидам своей компании:

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

Рынок высококонкурентный в ИТ и наше предложение должно выгодно отличаться, а тимлид – это лицо нашей разработки. Надо обязательно помнить об этом, даже при отказе кандидату. С вами ассоциируется культура нашей разработки. С нашей культурой рекрутинга ассоциируется культура нашей разработки. Любой кандидат, который поговорил с вами будет нести в сообщества свое мнение о нас и растить наш DevRel, даже если мы его намеренно не растим.

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

Выявление потребностей

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

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

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

– Повысив утилизацию текущих ресурсов

– Перераспределив внутренние ресурсы организации

– Обратившись к внешнему подрядчику

– Наняв нового сотрудника

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

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

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

Перед тем как открыть вакансию, необходимо оценить:

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

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

Необходимость решения определенных задач может привести вас к вопросу Дизайна команды и Управления компетенциями. Важно переосмыслить распределение обязанностей, возможно выгоднее будет вместо найма еще одного Senior разработчика искать разработчика Junior/Middle уровня для того, чтобы разгрузить текущих разработчиков от простых задач.

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

Формирование вакансии

Вакансия – это набор требований, обязанностей, условий труда и информации о компании/продукте.

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

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

– Сделать требования к вакансии мягче, рассматривать кандидатов с меньшей квалификацией/не покрывающих все ваши потребности. В этом случае, вам придется доучить кандидата (потратить на это ресурсы компании).

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

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

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

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

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

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

Обязанности являются важной частью вакансии, поскольку позже новый сотрудник, ссылаясь на них, может отказаться выполнять часть порученной ему работы. Более формальный документ, на основании которого происходит увольнение, – это «Должностные обязанности», но перечень обязанностей в нем должен соответствовать вакансии. Для таких вакансий, как Руководитель проектов/Full stack разработчик должностные обязанности могут очень сильно отличаться, и кандидаты начинают этому уделять пристальное внимание.

Условия труда должны отражать ключевые для кандидата условия:

– Оклад, премии, мотивация

– Где нужно будет работать (офис, офисное оснащение)

– Соц. пакеты

– Инструменты (техника, IDE)

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

Отсев кандидатов по резюме

До публикации вакансии, HR-рекрутер, имея доступ к базе данных резюме, делает подборку кандидатов, удовлетворяющих требованиям вакансии.

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

Последующий процесс обработки отфильтрованных резюме HR-рекрутером включает контакт с кандидатом (предварительное собеседование) и даже предварительный отбор.

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

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

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

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

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

Собеседования

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

К собеседованию необходимо подготовится:

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

– Иметь опросник hard skills со стандартными вопросами. Выделите технические знания и опыт по секциям, для каждой сформулируйте вопросы. Эти вопросы должны продемонстрировать глубину и широту знаний/опыта кандидата. Хорошие вопросы: «В каких случаях выгоднее использовать NoSQL базы данных?», плохие вопросы: «У вас был опыт написания автотестов, знаете, как это делается?». Несмотря на набор готовых вопросов, вам нужно быть готовым к импровизации прямо во время собеседования – задавать вопросы, больше раскрывающие ту или иную компетенцию. Одним из подходов может служить попытка расспросить кандидата о системах, которые он разрабатывал, периодически доходя до мельчайших подробностей реализации.

– Иметь опросник soft skills со стандартными вопросами. Вопросы совместимости с вашей командой, компанией, продуктом и процессами. Личностные качества кандидата и все остальное можно почерпнуть из личного опыта кандидата и набора гипотетических ситуаций. Набор вопросов soft skills не имеет правильных ответов, так что ответы не могут однозначно свидетельствовать о совместимости или несовместимости вашей компании и кандидата.

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

– У вас должна быть однотипная структура проведения собеседования – вопросы кандидату об опыте, hard skills, soft skills, тестовые задания, вопросы кандидата о компании, о команде, о продукте, о процессах, инструментах. Однотипная структура не означает, что вы ограничитесь одним и тем же набором вопросов.

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

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

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

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

Проведение собеседования:

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

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

– Сразу расскажите кандидату план беседы и регламент (сколько ориентировочно будет идти собеседование)

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

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

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

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

Фиксирование результатов собеседования:

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

– Результаты всех прошедших собеседований до момента найма (а может быть и позже) должны храниться у вас в недоступном для других сотрудников месте.

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

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

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

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

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

Еще один полезный прием – записывать видео собеседований, это может позволить:

– Получить мнение о кандидате коллег, не присутствовавших на собеседовании

– Легко передать найм кандидата в другую команду

– Перейти в другую команду на испытательном сроке

Однако для этого подхода, требуется запросить разрешение на запись у кандидата.

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

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

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

– Кандидат не сможет продемонстрировать всю глубину своих hard skills, ведь ему достаются задачи без полного погружение в контекст проекта.

– В течение дня придется потратить много ресурсов на ответы на вопросы нового сотрудника.

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

Принятие решения

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

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

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

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

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

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

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

Адаптация [Onboarding]

До того, как сотрудник выйдет работать, необходимо подготовить информацию и доступы в корпоративных системах. Этот процесс называется «Подготовка к выходу» [Pre Onboarding].

Лучшими практиками считается четко выстроенный план Подготовки к выходу [Pre Onboarding] и Адаптации [Onboarding]. Часто этот процесс полностью или частично автоматизирован с помощью типового набора задач и контроля их исполнения.

Подготовка к выходу [Pre Onboarding] включает в себя закупку техники и лицензий, создание учетной записи, которая попадает во внутренние системы, таск-менеджеры, системы контроля версий и системы управления учетными записями. HR-менеджеры и сотрудники корпоративной культуры подготавливают анонс выхода сотрудника, готовят welcome pack и осуществляют другие подготовительные действия. Помимо этого, HR-менеджер сообщает кандидату о том, какие документы потребуются для заключения договора.

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

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

Задачи Наставника:

– Отвечать новому сотруднику на возникающие вопросы

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

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

– Помогать с выбором правильных решений при решении задач

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

Процесс Адаптации [Onboarding] начинается с выхода сотрудника на работу.

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

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

Поскольку встреча с тимлидом (наставником) может быть не очень ёмкой по объему информации, её могут запланировать и на следующий день. В рамках такой встречи тимлид рассказывает:

– О бизнесе и основных бизнес-процессах

– О продукте (ах)

– Применяемых технологиях

– Архитектуре

– Истории развития бизнеса, продуктов и команды

– Процессах, регламентах и соглашения в разработке

– О команде (составе, ролях, культуре других важных особенностях)

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

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

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

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

Испытательный период является частью Адаптации [Onboarding].

Испытательный период

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

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

Первая обратная связь

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

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

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

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

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

Вторая обратная связь

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

Окончание испытательного срока

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

Для этой встречи тимлиду необходимо:

– Запросить и получить от нового сотрудника обратную связь в свободной форме

– Собрать краткую информацию о предыдущих встречах по обратной связи

– Узнать мнение команды о новом сотруднике

– Провести оценку качества/сроков выполненных задач испытательного срока

– Сделать общую оценку уровня знаний и умений нового сотрудника

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

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

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

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

Досье или личное дело сотрудника

У каждого сотрудника есть свой жизненный цикл в организации, включающий:

– Привлечение

– Найм

– Адаптацию

– Накопление опыта и эффективную работу

– Кадровый резерв и рост

– Увольнение

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

– Общую характеристику сотрудника

– Резюме и результат оценки знаний на собеседовании

– Итоги адаптационных встреч

– Отзывы коллег о сотруднике

– Значимые события (достижения, фатальные ошибки и конфликты)

– Премии, штрафы, индексация и пересмотры зарплаты

– Оценка персонала [Performance Review], направления роста и грейд

– Причина увольнения и сопутствующая информация

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

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

Дисциплина

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

Что обычно ожидается от сотрудника:

– Соблюдение дисциплинарных норм

– Соблюдение культуры организации и команды

– Результаты рабочего процесса

Для хорошего тимлида важен контроль всех трех пунктов. Простой пример: Сотрудник уходит на 2 часа раньше с работы, а на следующий день, с утра, у него готова задача. Хороший тимлид задастся вопросом: «А не была ли задача слишком простой? Возможно, на нее требуется один день вместо двух?». Если тщательно анализировать и исследовать соблюдение дисциплинарных норм, отслеживать общую картину производства и загрузки становится гораздо проще. В том числе это может предотвратить переутомление сотрудников, что хорошо скажется на общем эмоциональном состоянии коллектива.

Что подразумевается под дисциплинарными нормами?

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

– Выполнение установленных норм и регламентных операций организации и команды

– Может быть отметка в системах учета рабочего времени

– Может быть чистота на столе

– Может быть требование возвращать на место после использования инструментов (канцелярии, книг и др.)

– Не опаздывать и присутствовать на встречах

– Следовать и выполнять регламентированные операции процесса разработки ПО

– Своевременное и точное выполнение распоряжений руководителя

– Может быть формат комментариев для пул-реквестов

– Может быть коммит промежуточных итогов в конце рабочего дня

Согласно трудовому распорядку, сотрудник должен работать заданное количество часов в день (или в неделю) из согласованного графика.

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

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

Также стоит помнить, что дисциплины не будет пока нет системы мотивации. Даже, если у организации не существует определенного регламента, тимлид все равно должен контролировать дисциплину в компании. Инструменты обеспечения дисциплины описаны в разделе «Мотивация».

Встречи «1 на 1»

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

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

– Куда планируешь отправиться в отпуск или как отдохнул в отпуске, где был?

– Что нового? Как семья?

– Для распределенной команды можно уточнять, где находится сотрудник территориально, какая у него там погода.

– Обсудить последние новости (как в компании, так и в мире)

Как правило, такие встречи проходят один раз в две недели или раз в месяц.

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

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

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

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

Административная работа

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

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

– Согласование графика отпусков, каждого отдельного отпуска, командировок

– Согласование заявок на закупку

– Фиксация данных переработок и их согласование

– Согласование табеля рабочего времени или отправка данных по больничным

– Различные отчеты для руководства

– Управление сервисами для организации разработки (таск-менеджер, репозиторий кода и др.)

Эти задачи уникальны для каждой организации.

Мотивация

Мотивация – это побуждение к действию.

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

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

Мы рассмотрим мотивацию через две основные призмы: материальность и эмоциональный окрас (т.е. позитивная мотивация или негативная).

Позитивная материальная мотивация

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

В принципе, это верно, но существуют и другие виды поощрений:

– Бонусы

– Премии

– Подарки

– Призы

– Опционы и доли

– Оплата обучения

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

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

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

Позитивная НЕматериальная мотивация

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

Продолжение книги