Настольная книга тимлида разработки ПО. Книга тимлида разработки по Издательские решения
 Скачать 0.67 Mb.
|
|
Виктор Большаков Настольная книга тимлида разработки ПО «Издательские решения» Большаков В. Настольная книга тимлида разработки ПО / В. Большаков — «Издательские решения», ISBN 978-5-00-559147-0 Книга родилась из курса внутреннего обучения роли Тимлид в DatsTeam. Тем не менее её ценность для всего сообщества тимлидов заключается в обобщении необходимых компетенций. Этот набор компетенций формирует общий стандарт в отрасли разработки ПО. ISBN 978-5-00-559147-0 © Большаков В. © Издательские решения 4 Содержание Введение 7 Зачем вам эта книга 7 О роли 8 Карта компетенций 9 Контекст деятельности 11 Управление сотрудниками 12 Найм 12 Выявление потребностей 12 Формирование вакансии 13 Отсев кандидатов по резюме 14 Собеседования 15 Принятие решения 17 Адаптация [Onboarding] 18 Испытательный период 19 Повседневное управление сотрудниками 21 Досье или личное дело сотрудника 21 Дисциплина 21 Встречи «1 на 1» 22 Административная работа 23 Мотивация 23 Оценка профессионального уровня и эффективности 25 Развитие сотрудников 27 Увольнение сотрудников 29 На испытательном сроке 29 После испытательного срока 31 Совместная работа команды 33 Дизайн команды 33 Формирование и укрепление команды 35 Управление компетенциями 37 Культура команды (микроклимат) 39 Стиль управления 40 Управление конфликтами 43 Адаптация тимлида в команде 45 Интеграционные коммуникации 46 Знание бизнес-процессов и организационные структуры компании 46 Знание регламентных документов компании 47 Понимание и принятие культуры компании 48 Взаимодействие с другими подразделениями 49 Управление ожиданиями от команды 51 PR и DevRel 52 Владелец процесса разработки 53 Принципы построения процессов 53 Нотации описания процессов 55 Внедрение процессов или изменений 57 Эволюция процесса разработки 58 В. Большаков. «Настольная книга тимлида разработки ПО» 5 Лучшие практики разработки и особенности их применения 60 Менеджер процесса разработки 61 Аналитика 63 Программирование 64 Контроль качества 65 Публикация новых версий 66 Обслуживание и поддержка 67 Прием, распределение и контроль задач в подразделении 68 Качество постановки задач 68 Методы оценки задач, риски 70 Планирование и декомпозиция задач 72 Делегирование и эскалация 73 Повседневный контроль задач 74 Прием результатов 75 Технический лидер 76 Обеспечение наилучших условий труда и инструментов 77 Выбор инструментов разработки 77 Автоматизация процесса разработки 78 Управление продуктом 79 Жизненный цикл продукта (цели, стратегия, дорожная карта) 79 Функциональные характеристики 81 Проектирование функций (на базе бизнес-процессов) 81 Описание функций 81 Нефункциональные характеристики 83 Архитектура приложений 83 Выбор технологий 84 Архитектурный контроль 84 Технический долг 85 Поддерживаемость и отказоустойчивость 85 Производительность 86 Безопасность 86 Личные качества 88 Коммуникации 88 Стиль менеджмента 90 Саморазвитие 92 Тайм-менеджмент 94 Чек-лист тимлида 96 В. Большаков. «Настольная книга тимлида разработки ПО» 6 Настольная книга тимлида разработки ПО Виктор Большаков © Виктор Большаков, 2022 ISBN 978-5-0055-9147-0 Создано в интеллектуальной издательской системе Ridero В. Большаков. «Настольная книга тимлида разработки ПО» 7 Введение Зачем вам эта книга Автор постарался собрать полный набор компетенций Тимлида и раскрыть их для наи- более эффективного применения, указав на достоинства и недостатки существующих подхо- дов. Несмотря на то, что книга ориентирована на повышение профессионального уровня тим- лидов команды DatsTeam, она будет полезна и другим специалистам, поскольку в ней собраны лучшие практики и рассматривается полный спектр деятельности роли тимлид. Основой для написания книги послужили опыт из различных доступных источников и структура компетенций TeamLead Roadmap [ https://tlroadmap.io/ ], за что автор выражает большую благодарность сообществу. Однако мнение автора частично отличается от вышеупо- мянутых компетенций: для ознакомления читателя с имеющимся мировым опытом и опытом автора, структура функций в книге заполнена практиками и принципами. Данная книга будет полезна для специалистов в сфере разработки: – Действующему тимлиду – Разработчику, планирующему стать тимлидом – Руководителю групп разработки, CIO, CTO, CDTO – Руководителю подразделения разработки ПО Действующий тимлид сможет переосмыслить свои подходы, применить новые и струк- турировать свою деятельность. Во многом это поможет справиться с текущими проблемами и избежать их появления в будущем. Разработчику, планирующему стать тимлидом, книга даст понимание о функциях этой профессии, так как зачастую разработчики не видят полноты деятельности тимлида. Руководители, стоящие выше, в свою очередь, не видят нужного потенциала по организацион- ным и личностным качествам в разработчике на эту должность. Когда же неподготовленный разработчик получает желаемую роль, он сталкивается с новым типом задач, которые из-за отсутствия знаний и опыта в этой сфере, приводят к проблемам. Руководителю групп разработки, CIO, CTO, CDTO эта книга позволит задать стан- дарты работы в организации, провести повышение квалификации тимлидов, оценить их ква- лификацию по компетенциям и даже написать требования к вакансии тимлида или должност- ной инструкции. Руководителю подразделения разработки ПО, такому как Системного администри- рования, Контроля качества, Проектного офиса и др., книга раскрывает функции управления командой. Книга бесплатная и свободно распространяется в электронном виде. При цитировании необходимо указывать название книги и автора. В. Большаков. «Настольная книга тимлида разработки ПО» 8 О роли Тимлид [Team Leader] – роль лидера команды разработки, которая включает в себя организацию эффективной работы команды и обеспечивает ее максимальную ценность для организации. Определение в wikipedia [ https://en.wikipedia.org/wiki/Team_leader ] звучит иначе, но отражает ту же самую суть. В каждой организации свой набор ролей и распределение функций между ними. Для определения роли за основу берутся методологии, лучшие практики, книги, а также опыт сотрудников. Разделение труда в организациях очень разнообразное. В крупных компаниях разделение труда более детализировано – поле деятельности тимлида сужается, что повышает эффектив- ность выполнения оставшихся в его зоне ответственности функций. Например, в некоторых организациях есть роль Владельца продукта [Product Owner], что позволяет тимлиду в мень- шей степени заниматься проектированием функционала систем. Предположим, в другой части компаний есть роль Руководителя проектов [Project Manager], которая снимает с тимлида функции построения планов и контроля выполнения этих планов. В небольших стартапах роль тимлида может включать в себя функции Владельца продукта [Product Owner], Руководителя проекта [Project Manager], Релиз-инженера [Release Engeneer], ИТ директора [CIO], Техниче- ского директора [CTO] и др. В концепции само-организованных команд не существует такой роли, как тимлид. Такие команды формируются из само-мотивированных сотрудников, распределяющих между собой ответственность за максимизацию результатов. При реализации такой концепции необходимо учитывать, что амбиции лидера хотя бы одного из членов команды будут значительно мешать достижению целей. А появление неформального лидера и вовсе может свести к минимуму пользу от реализации концепции. Команда – группа людей, работающих совместно для достижения определенных целей. В более широком смысле у лидера может быть достаточно большая команда. Но именно под ролью тимлида подразумевается управление командой, работающей по единому процессу (в том числе единому технологическому циклу), с единым планированием и, единым пулом задач. В. Большаков. «Настольная книга тимлида разработки ПО» 9 Карта компетенций Компетентность – способность (знания и опыт), позволяющая эффективно выполнять определенный класс профессиональных задач. Тимлид это роль, требующая компетентности в решении определенных задач. Последующие главы книги будут подробно раскрывать особенности каждой компетенции тимлида, практики и принципы которых необходимо придерживаться. В. Большаков. «Настольная книга тимлида разработки ПО» 10 В. Большаков. «Настольная книга тимлида разработки ПО» 11 Контекст деятельности Тимлид осуществляет свою деятельность в определенных обстоятельствах, которые определяют подходы, инструменты и цели. Факторы, влияющие на деятельность тимлида: – Организация, в рамках которой работает команда: – Роли и конкретные сотрудники на тех или иных должностях – Регламенты, политики и правила организации в части: – работы с сотрудниками – реализации процессов разработки – формата общения между командами/подразделениями – общие требования к программным продуктам – Ресурсы для мотивации сотрудников – Доступные тимлиду и команде инструменты для достижения целей – Корпоративная культура – Команда – Программный продукт или продукты, над которыми работает команда – Качество постановки задач, формализации целей входящей информации – История формирования организации и команды, продуктов, процессов и инструментов разработки Каждый фактор оказывает значительное влияние и его необходимо учитывать при орга- низации работы команды. Например, создание микроклимата команды, конфликтующего с корпоративной культу- рой, будет фактором возмущения для других сотрудников и руководства организации. Другая ситуация – авторитарный стиль управления тимлида будет постоянно ставиться под сомнение руководством организации с демократическим стилем управления. При трудоустройстве на роль тимлида необходимо оценивать соответствие ваших пред- почтений и существующее положение этих факторов в организации. Достаточно часто между тимлидами возникают споры об эффективности тех или иных практик без учета этих внешних факторов. Эти споры возникают не только между тимлидами разных организаций, но и даже между тимлидами в одной организации. В. Большаков. «Настольная книга тимлида разработки ПО» 12 Управление сотрудниками Найм Перед тем как раскрыть тему найма новых сотрудников, приведу напутствующие слова Мариэтты Парсекян (HR директора компании Dats. Team) тимлидам своей компании: Главное, что надо понимать, Рекрутинг в ИТ это работа команды, это диалог, взаимодействие и эффективная обратная связь в процессе найма. Залог успешных плейсментов – это понимание, что у нас одна задача, мы в одной лодке, быстрое реагирование на изменения рынка, быстрая обратная связь и отсутствия нагромождений в виде большого числа интервью и тестов. Рынок высококонкурентный в ИТ и наше предложение должно выгодно отличаться, а тимлид – это лицо нашей разработки. Надо обязательно помнить об этом, даже при отказе кандидату. С вами ассоциируется культура нашей разработки. С нашей культурой рекрутинга ассоциируется культура нашей разработки. Любой кандидат, который поговорил с вами будет нести в сообщества свое мнение о нас и растить наш DevRel, даже если мы его намеренно не растим. Вам будет крайне полезно провести несколько образовательных встреч с HR-менедже- ром, где вам расскажут необходимую информацию по трудовому кодексу, а вы в ответ расска- жете о технологиях, компетенциях команды, процессах и др. Выявление потребностей При нехватке ресурсов для решения бизнес-задач, возникает давление со стороны биз- неса. Часто это выражается в недовольстве результатами команды – желанием вывести часть сотрудников в выходные дни или созданием новых рисков для бизнеса, заставляя команду делать изменения продуктов быстрее и менее качественно. Необходимо вовремя определять момент нехватки ресурсов, а лучше иметь прогноз от самого бизнеса. Следите за количеством и объемом поступающих задач, средним временем решения задач, запрашивайте планы бизнеса по росту, планам трансформации бизнеса, кон- курентной борьбе. Выявление потребностей – зачастую это признание бизнесом нехватки ресурсов и необходимость отдельного финансирования для решения подобных проблем. Решить их можно по-разному: – Повысив утилизацию текущих ресурсов – Перераспределив внутренние ресурсы организации – Обратившись к внешнему подрядчику – Наняв нового сотрудника Никто не любит переработки, но некоторые организации все же прибегают к этому методу. Злоупотребление переработками ведет к выгоранию команды – в скором времени это может привести к замедлению разработки, поскольку часть команды может уволится, часть уйти в отпуск, а еще одна часть просто сильно понизить уровень своей производительности и мотивации. Однако столь радикальный режим может стать решением острых проблем орга- низации. В. Большаков. «Настольная книга тимлида разработки ПО» 13 Если в компании несколько команд разработки, различные подразделения, имеющие спе- циалистов схожей компетенции, важно узнать о возможности временного или постоянного перераспределения ресурсов. Если важно пройти локальный текущий пик высокого спроса на ресурсы, имеет смысл рассмотреть аутсорсинг или аутстаффинг для краткосрочного привлечения этих ресурсов. Вам может не подойти такой способ, если в организации высокий уровень бюрократии, вход в про- ект слишком долгий и дорогой, присутствуют высокие риски информационной безопасности. Причин может быть множество. Перед тем как открыть вакансию, необходимо оценить: – Насколько объем работы для данной вакансии постоянен. Не получится ли так, что через несколько месяцев эту позицию придется сократить. – Время, затраченное на поиск и адаптацию кандидата. Если в среднем найм и адаптация занимает от трех и более месяцев, то пиковая нагрузка может быть пройдена и острая потреб- ность в сотруднике исчерпает себя. Необходимость решения определенных задач может привести вас к вопросу Дизайна команды и Управления компетенциями. Важно переосмыслить распределение обязанностей, возможно выгоднее будет вместо найма еще одного Senior разработчика искать разработчика Junior/Middle уровня для того, чтобы разгрузить текущих разработчиков от простых задач. Кадровый резерв – это сотрудники, имеющие потенциал для того, чтобы сменить должность или роль, то есть выполнять другие обязанности (более сложные или управленче- ские функции). Проанализируйте возможности роста своих сотрудников или сотрудников дру- гих команд. Такой рост внутри компании повысит уровень лояльности не только того сотруд- ника, который получит новую роль, но и других сотрудников, которые увидят пример роста в компании. Формирование вакансии Вакансия – это набор требований, обязанностей, условий труда и информации о ком- пании/продукте. Набор требований – это одна из наиболее важных частей в вакансии с точки зрения тимлида, ведь именно эту информацию ему необходимо будет подготовить. Перечень требова- ний формируется на основании потребностей и отражает компетенции (знания и опыт), кото- рыми должен обладать новый сотрудник. Есть базовые требования, с которыми работает ком- пания: гражданство, решение удаленной работы или в офисе. Эти требования будут добавлены к вашим по умолчанию. Также HR-рекрутер может убрать дискриминационные требования. Если на рынке мало специалистов, удовлетворяющих все ваши требования, то есть несколько вариантов развития событий: – Сделать требования к вакансии мягче, рассматривать кандидатов с меньшей квалифи- кацией/не покрывающих все ваши потребности. В этом случае, вам придется доучить канди- дата (потратить на это ресурсы компании). – Увеличить уровень оплаты труда, возможно, даже выше рыночной заработной платы. К сожалению, поступать так достаточно рискованно, текущие сотрудники потребуют повыше- ния их окладов до того же уровня (выше рынка). Иногда в организациях стандартизируют уровни оплаты труда для определенных категорий специалистов, что затрудняет найм при нехватке специалистов на рынке. – Дольше искать нужного кандидата. Вполне возможно вы дождетесь подходящего под ваши требования и финансовые возможности специалиста. В. Большаков. «Настольная книга тимлида разработки ПО» 14 Вы можете не знать спрос и предложение. Для этого можно на некоторое время выставить требования максимально жесткими и постепенно их ослаблять, но обычно рекрутеры в орга- низации могут быстро провести анализ и сразу предложить корректировки. На специализированных сайтах поиска работы (например hh.ru) есть ряд стандартных полей требований: Опыт работы, График работы и др. Отнеситесь к этим полям с вниманием, кандидаты выставляют фильтры и могут не увидеть вашу вакансию. Вы можете помочь рекру- теру, указав на ресурсы, на которых лучше размещать вакансию и которые часто посещаются нужными специалистами. Необходимо учесть интересы кандидатов. Вам нужно сформулировать набор минималь- ных и достаточных требований. Сделайте акцент на ключевых компетенциях, опыт или знания которых сыграют ключевую роль в принятии решения. Обязанности – перечень типов задач, которые необходимо будет решать специалисту. Эту часть вакансии тоже зачастую формирует тимлид. Обязанности являются важной частью вакансии, поскольку позже новый сотрудник, ссы- лаясь на них, может отказаться выполнять часть порученной ему работы. Более формальный документ, на основании которого происходит увольнение, – это «Должностные обязанности», но перечень обязанностей в нем должен соответствовать вакансии. Для таких вакансий, как Руководитель проектов/Full stack разработчик должностные обязанности могут очень сильно отличаться, и кандидаты начинают этому уделять пристальное внимание. |