Настольная книга тимлида разработки ПО. Книга тимлида разработки по Издательские решения
 Скачать 0.67 Mb.
|
|
Адаптация тимлида в команде Основная проблема адаптации руководителя в коллективе – отсутствие уважения и авто- ритета, на основании которых во многом осуществляется управление. Авторитет – это возможность руководителя влиять на действия подчиненных, не при- бегая к административной власти. Коллеги будут уважать вас за опыт, компетентность, самоотдачу и множество других вещей, о которых нужно уметь заявить. Но они не могут оценить это «с порога», поэтому зача- стую встречают вас «по одежке». Для того, чтобы не испортить первое впечатление постарай- тесь уделить особое внимание вашему дебюту в коллективе, будьте опрятны и приятны в обще- нии. У вас не будет второго шанса произвести первое впечатление. Коко Шанель Существуют субъективные «индикаторы компетентности», указывающие на лидерский потенциал человека: громкая речь, готовность брать на себя инициативу, выражение уверен- ности. Вы можете изменить свое поведение на время – этого достаточно, чтобы создать нуж- ный вам образ. Настроиться на образ лидера вам поможет следующее упражнение: напи- шите на листе бумаги амбиции и жизненные устремления, опыт вашего руководства людьми и моменты, в которых вы были счастливы. Внутрикомандная иерархия формируется быстро, порождая модели поведения, поддер- живающие и закрепляющие эту иерархию. Составляющие авторитета: – Компетенция и профессиональные знания – Управленческие умения и Личностные проявления – Авторитетный образ: – Стильный образ – Авторитетные знакомства – Позитивное мышление – Интерес к жизни сотрудников – Амбициозные цели – Легенды, мифы Что нужно делать: – Необходимо познакомиться с новым коллективом, поговорить с каждым лично и узнать каждого сотрудника – Рассказать про себя. В рассказе о себе необходимо упомянуть о компетенциях и проф. достижениях, о своем опыте и целях. Показать ваше отношение к командам на прошлых местах работы – как вы защищали их, развивали, как принимали решения. В. Большаков. «Настольная книга тимлида разработки ПО» 46 Интеграционные коммуникации Знание бизнес-процессов и организационные структуры компании Понимание бизнес-процессов компании и ее организационной структуры даст возмож- ность получить важный контекст решения ваших задач. Эти знания ценны не только для тим- лида, но и для каждого члена команды, поэтому вам необходимо транслировать их в команду. Бизнес-процесс – это набор действий, приводящих к определенному ожидаемому результату. Знание бизнес-процессов компании позволит понять то, какими должны быть результаты вашей работы и что еще вы можете автоматизировать за счет создаваемых вами систем. То есть вы увидите как потенциал для автоматизации, так и границы. Ведь, нет смысла закладывать гибкость в системах, если она не будет востребована. Команде, помимо бизнес-процессов разрабатываемого ими приложения, также будет полезно знать о внутренних процессах в компании. У бизнес-процессов есть владельцы и менеджеры. Владельцы бизнес-процессов опре- деляют какими должны быть эти процессы, получая обратную связь от менеджера процесса. Менеджеры процессов контролируют выполнение работы согласно спроектированным биз- нес-процессам, фокусируясь на результатах и воспринимая их как свод правил к выполнению. Достаточно часто компании имеют несколько бизнес-направлений, каждое из которых автоматизировано своим набором систем. Так же существуют поддерживающие процессы – они не относятся к какому-то конкретному бизнес-направлению и могут поддерживать сразу несколько систем, а то и все сразу. С ростом компаний из фокуса уходит цепочка ценности, выстроенная в организации и между подразделениями начинают возникать конфликты чаще. Вам необходимо выявлять проблемы разных приоритетов для подразделений и вовремя эскалировать такие ситуации. Организационная структура поможет каждому члену команды быстро сориентироваться, если к нему обратится коллега из другого подразделения или самому найти того, с кем необ- ходимо связаться. Это также помогает правильно эскалировать вопросы в компании. В. Большаков. «Настольная книга тимлида разработки ПО» 47 Знание регламентных документов компании В компаниях разрабатываются и утверждаются документы регламентирующие всевоз- можные процессы и подходы к работе. Поскольку часть этих документов распространяется на все предприятие, сотрудников просят, порой даже под подпись, подробнее с ними ознакомиться. При найме требуется изу- чить массу подобных документов. К таким документам могут относиться: – Правила внутреннего распорядка – Политика информационной безопасности – Положение о премировании – Положение о пересмотре заработных плат – Антикоррупционная политика За несоблюдение принятых в компании Правил/Политик/Положений, утвержденных генеральным директором, может следовать формальное наказание в виде выговора или уволь- нение. Поэтому у сотрудников должен быть исчерпывающий перечень регламентных докумен- тов доступных для чтения в любой момент времени. Более того, вы как руководящее звено компании должны знать и контролировать соблюдение этих документов командой. Поскольку эти документы иногда меняются, хорошей практикой будет периодически узнавать об их новых версиях. Такие документы меняются раз в 2—3 года, но изменения вно- сятся в них по весьма важным причинам. Если у вас не получится выстроить процесс, где вы будете получать уведомления об изменения, достаточно проводить ревью версий документов раз в год. В. Большаков. «Настольная книга тимлида разработки ПО» 48 Понимание и принятие культуры компании Под корпоративной культурой подразумевается набор элементов: – видение развития компании – направление, в котором движется организация, ее стра- тегические цели; – ценности – что является наиболее важным для компании; – традиции (история) – сложившиеся со временем привычки, ритуалы; – нормы поведения – этический кодекс организации, в котором прописаны правила пове- дения в определенных ситуациях (например, в McDonald’s создали целое руководство толщи- ной в 800 страниц, в котором прописана каждая возможная ситуация и одобренные руковод- ством варианты ее решения: действия сотрудников по отношению друг к другу, к клиентам компании и т.д.); – корпоративный стиль – внешний вид офисов компании, интерьер, фирменная симво- лика, дресс-код сотрудников; – взаимоотношения – правила, способы коммуникации между департаментами и отдель- ными членами коллектива; – вера и единство команды ради достижения определенных целей; – политика ведения диалога с клиентами, партнерами, конкурентами; – люди – сотрудники, которые разделяют корпоративные ценности компании. Функции корпоративной культуры: Имиджевая. Сильная внутренняя культура помогает создавать положительный внеш- ний образ компании и, как следствие, привлекать новых клиентов и ценных сотрудников. Мотивационная. Вдохновляет сотрудников на достижение поставленных целей и каче- ственное выполнение рабочих задач. Вовлекающая. Активное участие каждого отдельного члена коллектива в жизни ком- пании. Идентифицирующая. Способствует самоидентификации сотрудников, развивает ощу- щение собственной ценности и принадлежности к команде. Адаптивная. Помогает новым игрокам команды быстро вливаться в коллектив. Управленческая. Формирует нормы, правила управления командой, подразделениями. Системообразующая. Делает работу подразделений системной, упорядоченной, эффективной. Все компании разные, и помимо бизнес-процессов и целей, они отличаются культурой. Корпоративная культура – это та же культура команды, только работающая в рамках всей ком- пании. Одна из причин увольнения сотрудников – непринятие корпоративной культуры. То есть сотрудник не соблюдает принятые в компании нормы поведения и не разделяет ее ценности. Вы можете и должны влиять на культуру компании. Предлагать изменения или новые правила, создавать традиции и дополнять взаимоотношения новыми регламентами. Всё, что успешно работает в вашей команде может начать работать на уровне всей компании. В качестве бонуса вам и вашей команде будет приятно увидеть свой вклад в культуру компании. В. Большаков. «Настольная книга тимлида разработки ПО» 49 Взаимодействие с другими подразделениями Тимлид – это роль, которой команда делегирует представительство (голос) для внутри- корпоративного взаимодействия. Когда от команды требуется представитель для диалога с дру- гим подразделением, появляется тимлид. Важно понимать, что у подразделений могут быть разные приоритеты, представления о процессах и свое видение взаимодействия с коллегами из других отделов. Держа этот кон- текст в голове, выстраивайте взаимодействие следующим образом: – Открытый диалог, доверие и терпимость. Важно осознавать, что ваши коллеги тоже профессионалы своего дела (по крайне мере, вы должны от этого отталкиваться). В любом взаимодействии вы должны доверять компетен- ции коллег, их желанию вам помочь. Возможные непонимания необходимо встречать без нега- тивных эмоций, поскольку эти эмоции не помогают решать проблемы. – Понимание единства целей превращаем в решения. Вы, как и другие подразделения стараетесь принести пользу компании. Глобально цели всей компании могут быть противоречивыми: «Сократить расходы на 30% в первом квар- тале», «Захватить новый сегмент рынка». Руководители должны стараться согласовывать дей- ствия и их приоритеты. Другие подразделения могут ничего не знать о пользе вашей работы, так же, как и вы можете ничего не знать об их вкладе. Когда вы начинаете любое взаимодей- ствие, помните о том, что польза от вашей работы для всей компании может оказаться меньше по сравнению с другим отделом. Правильным решением в таком случае будет выполнить ваш запрос с меньшим приоритетом, это как раз и составит максимальную выгоду для всей компа- нии. Для четкой и правильной приоритезации необходимо описать последствия отложенного решения, его влияние и ценность вашей заявки в рамках компании. – Регламентируем там, где нужно. Если взаимодействие приводит к конфликтной ситуации его необходимо регламентиро- вать – согласовать с другим подразделением точный интерфейс взаимодействия. Кто, кому, что, как и когда передает? Обычно это не односторонний процесс, он снабжен обратной свя- зью, которую тоже требуется регламентировать. Помните, любые регламенты несут риски того, что одна из операций не подойдет и регламент сработает во вред, а не на пользу. – Сотрудничество, а не соперничество. Если в компании есть похожее подразделение, вы можете вместе искать способ стать лучше. При этом помните, что обмен знаниями и опытом принесет максимальную пользу для всей компании. – Эскалация в необходимых случаях. В некоторых ситуациях необходимо эскалировать вопросы до руководства. Невозможно всё регламентировать и предусмотреть, так что такие ситуации будут происходить (особенно из-за наличия конфликтующих целей). Для этого необходимо донести до руководства инфор- мацию о том, что в другом подразделении приоритеты выставлены неподходящим для вас обра- зом или стиль их работы конфликтует с вашим. В этом случае вы можете в диалоге с другим подразделением открыто заявить о необходимости эскалации вопроса для поиска более пра- вильного решения в интересах компании. Члены вашей команды и вы легко найдете повод сплотиться против единого врага. Если вы думаете, что в качестве врага можно выбрать другое подразделение компании, это заведомо неправильная позиция. Ведь через какое-то непродолжительное время такой подход выстроит отношения на ненависти и нежелании слушать и слышать другую сторону. Обычно такие отно- шения взаимны, но не долгосрочны – очень скоро это будет замечено руководством и вам будет поручено наладить отношения, выстроив плодотворный созидательный труд. Заметьте, В. Большаков. «Настольная книга тимлида разработки ПО» 50 вы можете проявить непрофессионализм и продолжать искренне ненавидеть своих коллег, но это уже ваша личная позиция, работающая против общих целей. Даже если вы 100 раз правы и в другом подразделении работают непрофессионалы, вы не можете судить о том, насколько это плохо, пока не обсудите это с руководством (может быть гораздо больше причин в пользу сложившейся ситуации, чем против нее). Строить стены плохо, как их разрушить? – Наладить обмен информацией между подразделениями и повысить ее прозрачность. – Создать культуру благодарности, чтобы усилия каждого сотрудника признавались, а не воспринимались как должное. – Обмениваться новостями, чтобы все имели доступ к информации и в коллективе фор- мировались здоровые отношения. – Разберите конфликт, формализуйте обмен информацией/результатами труда, выстро- ите процесс более формально чтобы исключить недопонимания и ошибочные ожидания. – Найдите повод регулярно вместе общаться на рабочие и нерабочие темы. Как показы- вает практика, проявлять неуважение проще через почту, мессенджеры и т. д. В живом обще- нии людям сложнее проявлять негативные эмоции и проще решать конфликты. В. Большаков. «Настольная книга тимлида разработки ПО» 51 Управление ожиданиями от команды Начните с вопросов: – Зачем команда существует? – Зачем команда нужна будет дальше? Вы должны понимать, что лишь часть ожиданий формализована и доведена до вас – это бывает связано с различием в восприятии или неспособностью систематизировать ожидания. В любом случае полного детального описания того, что от вас ожидают вы скорее всего не полу- чите. Ожидания меняются со временем, и вы должны постоянно сверяться с тем, что от вас требуется. Управление ожиданиями – это предмет двустороннего обсуждения. Если в компании или конкретном бизнес-направлении есть определенные цели, то ваша задача понять, как их можно достичь и какие для этого потребуются ресурсы и сроки. Желание делать и не нести ника- кой ответственности за сроки напрямую влияет на качество, что возвращает вас на шаг назад из позиции тимлида в позицию разработчика-исполнителя. Старайтесь максимально конкретизировать цели (в идеале по S.M.A.R.T.) – не завышайте ожидания, оставляйте резервы для покрытия рисков и заранее продумывайте шаги для дости- жения поставленных целей. Поскольку это командная работа, она не может избежать влия- ния внешних факторов. Ваша задача определить их и скорректировать ожидания от команды. Правильный подход: «задача будет сделана в срок, если мы…». Также стоит учитывать допол- нительные расходы при определении сроков на поддержку продуктов, плановый рефакторинг и др. В разных компаниях по-разному выстроен процесс формализации ожиданий и их управ- ления, он может опираться на результаты: – Спринтов – Дорожной карты – Системы контрактов. Стратегические ожидания будут размываться тактическими и операционными. Причем контроль всех уровней ожиданий будет на вашей стороне. Держите в фокусе команды страте- гические ожидания при любых обстоятельствах и временных изменениях курса. Требуйте обратную связь по достигнутым результатам. Выполненные задачи и достигну- тые цели – это ценность, которую организация получила от работы команды. Команде важно получить эту обратную связь, и ваша функция ее транслировать. Если обратная связь негатив- ная, вы должны принять удар на себя. В том случае если цель размазана и не выражена какими-то конкретными границами, найдите ориентир обратной связи в виде метрик продукта или опросов заказчиков. Бизнес редко готов делиться финансовыми результатами или оборотами, для этого существуют более безопасные метрики в виде количества активных пользователей, объема операций или воз- врата посетителей (retention). В. Большаков. «Настольная книга тимлида разработки ПО» 52 PR и DevRel Ценность внутреннего PR вашего подразделения в рамках компании может быть выра- жена в: распределении премиального фонда в вашу пользу, потенциале роста, узнаваемости ваших сотрудников, понимании другими подразделениями специфики вашей работы. Как этого можно добиться: – Публиковать наиболее интересные задачи, которые вы решили – Увлеченно рассказывать о ваших специалистах – Приглашать другие подразделения на открытые внутренние доклады – Публиковать статистику решаемых задач, метрик систем в проде DevRel — отношения с разработчиками, чаще всего подразумевается внешний Tech PR. На такую деятельность в маленьких компаниях не находят ресурса, однако если даже не выде- лять отдельного специалиста, работа коллектива может быть организована таким образом, что такой Tech PR будет появляться естественным образом. Основная цель DevRel – повысить узнаваемость бренда, что улучшит процесс найма. Деятельность, развивающая DevRel: – Участие в open-source проектах – Публикация исследовательских задач, с которыми вы сталкиваетесь в работе, и их результатов – Участие с докладами или вопросами в конференциях и митапах – Участие в хакатонах и интервью Деятельность PR и DevRel организации невозможна без привлечения компетентных сотрудников. Ваша инициатива и участие – ключ к успеху компании. В. Большаков. «Настольная книга тимлида разработки ПО» 53 Владелец процесса разработки Принципы построения процессов При построении процессов необходимо придерживаться следующих принципов: – Каждый процесс имеет определенную цель, вы должны сформулировать ее четко и ясно – Превратите цель в последовательную модель входов-выходов – Не регламентируйте то, где могут быть исключения или нужен будет творческий под- ход. Свобода в маленьких командах важнее обеспечения качества с помощью процессов. В таких масштабах команды высокий уровень ответственности рождает вовлеченность, моти- вацию и качество. С ростом компании, часто происходит разрыв цепочки ценности, снижается индивидуальный уровень ответственности, требуется формализация процессов (не всем) для поддержания качества. – Не делайте одно большое описание процесса. Древовидная структура – более удобна для изучения, каждый дочерний элемент необходимо описать отдельной схемой. – Учитывайте компетенции команды при моделировании процессов – Выделите основной процесс и обеспечивающий (помните о процессах управления) – Необходимо выявить критерии результативности процесса Само описание процесса может быть представлено в виде: – Регламента – Диаграммы процесса – Принципов действия в случае, если не регламентировано процессом – Описанием кейсов – Деревом принятия решения Современное описание процесса включает: – Наименование, версию, ФИО автора, дату изменения – Диаграмму процесса (IDEF0, EPC, BPMN) – Описание ролей – Описание входов и выходов у процесса (из каких процессов приходят и в какие после- дующие процессы передаются) – Описание действий или ссылку на бизнес-процесс действия В. Большаков. «Настольная книга тимлида разработки ПО» 54 Построение бизнес-процесса – это процесс, состоящий из следующих шагов: – Собираются и анализируются требования, цель процесса, способы достижения цели – Формируется Проект изменения Бизнес-процессов – Строится диаграмма «AS IS» и из нее рождается схема «TO BE» – Предварительная схема процесса должна согласовываться со всеми участниками про- цесса. – Готовятся документы, разрабатывается/дорабатывается ПО, автоматизирующее биз- нес-процесс. – Внедрение процесса начинается с информирования всех участников процесса о начале работы согласно новому процессу. Начальные этапы работы и шаги процесса сопровождаются тщательным контролем – Процесс может считываться внедренным, если все сотрудники действуют согласно про- цессу. Остается только контролировать показатели Здравый смысл всегда важнее любых выстроенных процессов. Этот принцип должен про- ходить красной нитью через любые формализованные процессы. В. Большаков. «Настольная книга тимлида разработки ПО» |