Руководство командой разработки

Как управлять командой разработки

Привет! Я Иван Антипин, заместитель директора департамента разработки в AGIMA. За свою карьеру я поработал с десятками команд. Где-то был разработчиком, где-то тимлидом, где-то помогал извне. У меня был миллион возможностей разобраться, как люди ведут себя в коллективе. Но всё же не на все вопросы существуют четкие ответы: что такое команда, как она работает, как ей управлять. Об этом мы подробно рассказываем на нашем курсе для тимлидов и на митапах. А в этой статье я попробую описать те методы и подходы, которые лично мне кажутся полезными и правильными.

Что делает из группы команду

В детстве я занимался футболом. Мой отец, профессиональный биатлонист, часто повторял: «В вашем футболе кто-то бегает, а кто-то на прогулку выходит. Вот и получается, что можно выложиться на 100%, быть лучше всех на поле и всё равно проиграть».

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

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

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

Миссия и цель

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

Разницу сложно описать, но довольно легко почувствовать. Миссия намного сложнее. Она есть только у зрелых команд. Это ответ на вопрос «Зачем мы здесь каждый день?». Зачастую миссия спускается в команду через корпоративную культуру и не всегда проговаривается вслух. Часто команда понимает ее интуитивно. Или не понимает вовсе. Выполнить миссию тяжело, если вообще возможно.

А вот цель принципиально достижима. Поэтому команда может работать без миссии, но не может работать без цели. Цель — то, что заставляет команду сплотиться и работать сообща. Ее обычно ставят по системе SMART. Она должна быть:

• ограничена во времени;

• достижима:

• измерима.

Хорошие примеры командной цели — выпустить MVP к концу лета или повысить Retantion продукта за 2 месяца.

Ценности

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

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

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

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

Правила и практики

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

Но иногда важно дополнять правила компании внутренними командными традициями. Клубы по интересам (у нас, например, есть TeamLead Club, Managers Club и архитектурные комитеты), вылазка на природу раз в год, дневная зарядка всем отделом — общие ритуалы объединяют. Иногда они появляются спонтанно, а иногда стоит внедрить что-то специально.

Роли и навыки

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

• в работе делает упор на сильные стороны человека;

• слабые стороны улучшает за счет индивидуальных планов развития.

Проще говоря, тимлид понимает Soft Skills и Hard Skills каждого члена команды и учитывает их при планировании работы.

Как развивается команда

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

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

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

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

Из этого графика можно извлечь одно важное правило:

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

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

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

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

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

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

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

Как управлять командой

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

• правила,

• регламенты,

• встречи,

• алгоритмы,

• чек-листы и т. д.

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

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

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

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

Стили лидерства

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

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

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

Личность тимлида

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

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

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

Мне кажется, все люди делятся на два типа:

1. Одни объясняют свое решение словами «Я думаю, что…».

2. Другие — словами «Я чувствую, что…».

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

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

Кризис сплочает правильно сформированную команду, а не проверяет ее на прочность.

Если вы тимлид, ответьте себе на вопрос: «Что я скажу команде, если случится так, что нам будет поработать все выходные?». Или представьте, что должен сказать вам тимлид, чтобы вы вышли в выходной на работу. Требовать и угрожать, просить или умолять, а может быть, что-то еще? Удивительно – любой из вариантов может быть правильным.

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

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

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

Выбрать метод управления ИТ-проектами — Kanban, Scrum или Agile — важная задача для любого руководителя. Но важны и детали: как правильно выстроить коммуникацию между сотрудниками, особенно в условиях наступившей тотальной удаленки, какие программы помогут организовывать совещания, обмениваться кодом или следить за ходом выполнения проекта, а также как сохранять мотивацию у сидящих дома разработчиков. «Хайтек» выяснил у руководителей российских ИТ-компаний, как они управляют своими командами, как осуществляется коммуникация между сотрудниками и какие сервисы делают распределение задач проще.

Как устроены матричные структуры ИТ-компаний

Андрей Жикин, директор по информационным технологиям Yota

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

Мы стараемся удерживать максимально плоскую структуру, поэтому 24 отдела ИТ-департамента поделены поровну: одна часть находится под руководством директора по информационным технологиям, а другая — в подчинении директора по развитию и эксплуатации ИТ-систем.

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

Организовать коммуникацию нам помогают несколько инструментов:

• На верхнем уровне помогает канбан портфеля проектов — доска, на которой в онлайн-формате регулярно синхронизируются задачи по ИТ, бизнесу, проработке проблем и прочим кейсам. Этот инструмент значительно повышает прозрачность, позволяет вовремя находить слабые места, а также выравнивать ожидания всех участников.
• На уровне проектного управления — Big Picture в Jira. Это инструмент для структуризации задач и объединения их в проекты, визуализированные диаграммами Ганта.
• На техническом уровне — описания в виде контрактов по API. Каждый проект перед стартом реализации получает описание, которое команды должны учитывать в рамках производства. Это упрощает коммуникацию на стадии разработки, так как ожидаемый результат описан достаточно четко и понятно.
• На уровне общих коммуникаций мы используем MS Teams как средство видеосвязи и «ТамТам» как мессенджер для кросс-функционального общения. Также взаимодействие сотрудников происходит в корпоративной группе во «ВКонтакте», через почтовые рассылки и реже через физические письма.

---

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

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

---

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

● MS Office 365 — отличное облачное решение для основных корпоративных потребностей;

● Jira — для структуризации задач;

● Confluence — база знаний;

● Trello/Miro — доска для Канбана.

Для управления проектами мы используем микс водопада и Agile. Например, Kanban используется как для внутренней работы команды, так и для управления портфелем проектов. Этот инструмент применяется также на уровне топ-менеджмента для внедрения глобальных изменений в компании. При этом для сохранения прогнозируемости и управляемости производства используются классические инструменты с диаграммами Ганта.

Микросервисная архитектура: каждому продукту своя команда

Игорь Калинин, основатель компании TWIN

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

Всего в штате компании 34 специалиста: большая их часть занимается разработкой, но в команде также есть тестировщики и Scrum-мастера, которые ставят задачи и контролируют их выполнение. В целом, Scrum — один из главных рабочих инструментов, но не единственный. Так, DevOps-команда и часть телефонистов используют Kanban. Мы стараемся комбинировать разные продукты, чтобы максимально эффективно организовать работу. Для коммуникации в команде используем одновременно и Telegram, и Slack, поскольку там удобно работать с кодом. А переговоры проводим в Google Meet.

В TWIN установлены довольно строгие правила отбора специалистов: отдаем предпочтение разработчикам senior-уровня и редко берем джуниоров. Большая часть команды — 80% — это старшие специалисты. Они же выступают в роли наставников для новичков, благодаря этому новый сотрудник быстрее прокачивает навыки — он одновременно обучается и тут же решает реальные рабочие задачи. Это большой стимул для роста и развития.

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

Эдгарс Пузо, генеральный директор Atos в России и СНГ

Мы реализуем переход компании на организационную структуру по индустриям. В процессе перехода было выделено шесть индустрий: финансовые услуги и страхование, здравоохранение, промышленность, государственный сектор, ресурсы и услуги, телекоммуникации и СМИ. Кроме того, в компании развиваются такие технические направления, как Microsoft, SAP, Digital Workplace, Cloud и другие, которые закрепляются в практики. В России формат деления на практики на данный момент находится на фазе становления, но на глобальном уровне он уже успешно работает.

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

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

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

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

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

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

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

Для мотивации сотрудников существует программа Accolade — система признания внутри компании. Несколько раз в год награждаются сотрудники, которые достигли выдающихся результатов сверх стандартной работы. В программе предусмотрены разные уровни наград в зависимости от достижений: bronze, silver, gold. Иерархия должностей позволяет каждому сотруднику увидеть, в каких направлениях можно расти. А корпоративная культура, включающая в себя мероприятия, конкурсы, призы, а также всевозможные активности на платформе для геймификации, позволяет мотивировать сотрудников на более неформальном уровне.

Agile-команды: свобода принятия решений и открытые синки

Евгения Христолюбская, руководитель направления по работе с сотрудниками «Учи.ру»

У нас матричная структура компании: есть вертикали основных специализаций и гибкие продуктовые команды. Таких команд — около 15.

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

Такие команды обладают достаточной свободой принятия решений и (иногда) собственным бюджетом. Каждая развивает собственный «участок» платформы. Основная коммуникация ведется в почте и в Slack. Когда наша компания перешла на удаленку, мы приобрели платную версию, которая позволяет совершать звонки и хранит всю историю переписки. Для видеозвонков мы используем Zoom и Google Meet. Кроме того, на удаленке организовывать встречи стало удобнее: коллеги стали доступнее, лучше соблюдается тайминг и даже большие встречи организовывать теперь легко.

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

Для планирования и отчетности команды используют классические для ИТ-отрасли инструменты Jira, Confluence, Figma и Notion. В компании принято ежеквартальное планирование, и в начале каждого квартала цели и задачи каскадируются от руководителей и вносятся в таск-трекер. Мы не используем трекеры рабочего времени и прочие программы для слежки за сотрудниками.

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

• Регулярные АМА-сессии для сотрудников на YouTube (AMA, Ask Me Anything, от англ. «спроси меня о чем угодно» — «Хайтек»).
• Обучающие, поддерживающие, развивающие материалы на корпоративном портале.
• Регулярные email-рассылки с рекомендациями и предложениями по досугу и обучению.
• Квизы, фотоконкурсы и онлайн-корпоративы, организация активностей на праздники.
• Митапы в рамках программы #УЧИвУЧИ.
• Еженедельная сводка новостей держит сотрудников в курсе того, что происходит в компании и разных отделах.

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

Константин Коногорский, заместитель директора по разработке ПО ВИСТ (входит в ГК «Цифра»)

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

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

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

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

Для распределения задач между командами и внутри команд мы используем современные Agile-методологии. Команды разработки работают по Scrum, а команды тестирования и DevOps — Kanban, в силу их немногочисленности.

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

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

---

Читайте также:

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

Создана первая точная карта мира. Что не так со всеми остальными?

На них держится Вселенная: как работают четыре главные силы природы

2009 г. Руководство командой разработчиков программного обеспечения Прикладные мысли С. Архипенков Содержание Предисловие Для кого? Что внутри? Благодарности Введение В какое время мы работаем? Изменение жизненной парадигмы Почему прежние методы управления людьми не работают? Глава 1. Профессиональные психологические особенности разработчиков ПО Специфика разработки программного обеспечения Тип личности и темперамент программистов Глава 2. Личная эффективность Ступени роста Управляем своей жизнью Эффективный программист Глава 3. Эффективное взаимодействие Думать и действовать в духе «выиграл/выиграл» Коммуникации Конфликты Глава 4. Руководство командами Группа и команда Командные роли Этапы формирования команды Лидерство и управление Роли и стратегии лидера Проблемы неисполнения Глава 5. Практики демотивации Классификация антипаттернов руководства Антипаттерны некомпетентности Антипаттерны мнительности Последствия применения антипаттернов Глава 6. Мотивация Гуманистическая теория мотивации Мотивация и тип личности Мотивация и опыт Глава 7. Подбор и развитие команд Набор сотрудников Оценка и развитие Сколько надо платить программисту? Стандарт People CMM Заключение или Что надо программисту для счастья? Литература Аннотация Сегодня умение руководить людьми становятся ключом к конкурентному преимуществу. Это искусство решения сложных задач при помощи других людей. Известно, что производительность программистов может отличаться в десятки раз. Задача руководителя команды разработчиков — сделать воспроизводимой высокую продуктивность интеллектуальной деятельности. Эффективный руководитель проекта программной разработки — это, в первую очередь, лидер, который, получил от команды признание своей профессиональной компетентности и своих исключительных человеческих качеств. Основываясь на последних наработках в областях управления программными проектами, психологии, соционики, социологии и личном опыте, автор излагает принципы эффективного руководства командами разработчиков программного обеспечения. Рассматриваются вопросы индивидуальной эффективности программистов, эффективных коммуникаций, разрешения конфликтов, лидерства в командах разработчиков, оценки, развития и мотивации участников проекта. Об авторе Стаж в разработке ПО более 30 лет. Занимался созданием имитационных моделей сложных космических систем в Центре управления полетами. Руководил коммерческой разработкой ПО и проектами организационного развития в компаниях PriceWaterhouseCoopers, Luxoft, CBOSS. Выполнял проекты по заказу Европейского космического агентства (ESA), Даймлер-Бенц Аэроспейс (Германия), Боинг (США), ЦБ РФ, ОАО «Газпром». Является автором книг, статей и учебных курсов по информационным технологиям и управлению проектами разработки ПО. С автором можно связаться по e-mail: Предисловие Для кого? Книга адресована, в первую очередь, менеджерам проектов и лидерам команд разработчиков программного обеспечения (ПО). Книга будет полезна руководителям отделов и служб ИТ, поскольку позволит им глубже понять особенности разработки программных систем и учесть эту специфику при построении эффективных производственных процессов в подразделении. Думаю, что изложенные мысли могут оказаться полезными в практике HR-служб, для грамотного руководства улучшениями в области подбора, оценки, развития и закрепления наиболее эффективных сотрудников. И, наконец, все остальные участники проектов разработки ПО смогут применить изложенные здесь принципы для повышения личной эффективности: адекватной постановки индивидуальных целей, стратегического планирования личного профессионального и карьерного развития, успешного решения своих задач на основе эффективного взаимодействия с другими участниками команды. Что внутри? Программирование – только один из видов творческой деятельности. Все изложенное в книге применимо и в других областях коллективного творчества. Правда, у разработки ПО, по сравнению, например, с кинематографом, театром, рекламой или другими отраслями коллективного творчества, есть свои законы и специфические особенности, которые еще мало изучены в силу молодости программной индустрии. Жизнь сложилась так, что большую ее часть я занимаюсь разработкой программ, а последние 20 лет, в основном, руковожу этим процессом. Все эти годы мне приходилось искать ответы на множество вопросов, начинающихся со слова «почему». Почему сверхвысокого IQ недостаточно для того, чтобы эффективно руководить программистами? Почему только менее 20% проектов разработки ПО завершаются в срок и укладываются в бюджет, а почти треть проектов аннулируется до их завершения [1]? Почему одни программисты могут быть на порядок, а порой и на два порядка эффективнее других? Почему сотрудники не выполняют мои поручения? Почему правильно подобранные «лебедь, рак и щука» могут оказаться гораздо эффективнее «родственных душ»? И много других. В результате у меня сложилось собственное представление («карта мира») о правильном подходе при поиске ответов на эти вопросы. Оказалось, что использование лучших языков и технологий программирования, самых совершенных инструментов разработки и систем качества не гарантируют успешность программного проекта. «Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте» [2]. Произошел сдвиг парадигмы, заставивший меня увидеть на новой карте мира множество белых пятен, которые пришлось заполнять, используя самообразование и переосмысление приобретенного опыта. Белые пятна находились, в основном, в области гуманитарных знаний: философии, прикладной психологии, социологии и соционики, и не были связаны с информационными технологиями. Полученные знания оформлялись и оттачивались в ходе практической работы, в многочисленных дискуссиях по поводу публикаций, а также на лекциях и семинарах, в которых мне приходилось отстаивать свои взгляды. Результатами этой работы я и хотел бы поделиться с коллегами по ремеслу. Буду рад, если мои мысли окажутся для кого-то практически полезными. Адекватная картина мира — правильные ответы на вопросы, начинающиеся со слова «почему», а не со слов «что» и «как», дает нам принципы и критерии выбора верного решения в постоянно меняющихся условиях, вместо попыток запастись рекомендациями на все случаи жизни. Чтобы иллюстрировать излагаемые мысли я использовал ряд «историй», которые почти все основаны на реальных наблюдениях. Первая и главная мысль, которою мне хотелось бы донести до читателя, состоит в том, что творческими командами разработчиков ПО невозможно управлять, их можно только направлять и вести. А для этого недостаточно быть эффективным управленцем, необходимо еще получить признание от команды в качестве лидера. Ответ на вопрос, почему прежние методы управления людьми не работают, дан во Введении. Следующая моя мысль о том, что все люди разные, требуются терпимость и умение принимать людей такими, какие они есть. Недостатки людей — это, как правило, оборотная сторона их достоинств. Следует эти достоинства разглядеть и постараться использовать их с максимальной отдачей для общего дела. В главе 1, на основе последних наработок в типологии Майерс-Бриггс и соционики, обсуждаются профессиональные психологические особенности разработчиков ПО, которые необходимо учитывать при формировании команд, организации их деятельности и их мотивации на достижение общего успеха. Лидер — это, главным образом, состоявшаяся личность, поэтому глава 2 посвящена личностному росту и развитию эмоционального интеллекта. В главе 3 рассмотрены вопросы эффективного межличностного взаимодействия и конструктивного разрешения производственных конфликтов на основе доверия и взаимовыгоды, без которых не бывает эффективных команд. Для российского менталитета командная работа достаточно органичный вид коллективной деятельности. Сельская община, профессиональные артели, рабочие бригады, временные научные творческие коллективы — все это страницы нашей истории. Что такое команда, ее отличие от рабочей группы, динамика ее становления, командные роли участников и стратегии руководителя на разных этапах развития команды — все это обсуждается в главе 4. Главная проблема успешного командообразования — это создание и сохранение высокой степени мотивации ее участников на общий успех. Но не может быть эффективной мотивации, если руководитель не исключил из своего управленческого арсенала демотивирующие практики. В глава 5 приведен обзор наиболее часто используемых антипаттернов руководства командами, которые приводят к фатальной демотивации исполнителей и делают невозможным создание самоорганизуемой и самоуправляемой команды. Работники приходят в компанию, как правило, не потому, что привержены ее миссии. И не для того, чтобы заработать еще больше денег для владельцев бизнеса. Работая в конкретной компании, участвуя в конкретном проекте, каждый работник стремится к достижению своих индивидуальных целей. «Лучшей заботой о компании будет вовремя сданный проект» – анонимный пост на rsdn.ru. Поэтому в главе 6 рассмотрены вопросы мотивации участников команды на достижение общего успеха в совместной работе, на основе достижения личных целей каждого. Создание и закрепление эффективной команды — это стратегическое приобретение компании, поэтому последняя глава 7 посвящена вопросам подбора, развития и сохранения эффективных команд. Мои мысли, надеюсь, принесут вам пользу. Но это произойдет только в том случае, если у вас самих уже возникли аналогичные вопросы «почему». Потому что если вопрос поставлен правильно, то это половина решения проблемы. А если таких вопросов у вас нет, то мои ответы вам вряд ли удастся куда-либо приложить. И еще. Бесполезно пытаться узнать у шахматиста его лучшие ходы. Если вы хотите найти в этой книге набор «приемчиков», освоение которых обеспечит вам эффективность в руководстве командой разработчиков, то разочарую вас — их здесь нет. Все психологические уловки и приемчики легко будут распознаны любым зрелым человеком, а большинство программистов относятся именно к этой категории. Их применение будет воспринято как попытка манипулирования с вашей стороны и навсегда подорвет доверие команды к вам. По словам У.Д. Джордана (цитируется по [3]): «Человек постоянно излучает свою сущность — то, каков он есть, а не то, каким он хочет казаться». Чтобы изменить свою жизнь, стать эффективным руководителем, надо изменить себя изнутри, изменить свое видение мира. И последнее. Представленная мной картина мира не есть истина в последней инстанции. Вы видите мир по-другому? Это естественно. Все люди разные. И это хорошо! Поскольку сопряжение разных взглядов на один и тот же объект обеспечивает стереоскопичность зрения, позволяет увидеть в изучаемом объекте дополнительное измерение, а следовательно, и новые возможности. Благодарности Безусловно, все, что написано в книге, отражает мое личное видение проблем программостроения. Многочисленные цитаты приводятся лишь для того, чтобы подчеркнуть тот факт, что высказанные мысли это не только мое личное мнение. Вместе с тем, моя картина мира формировалась не столько на основе изучения трудов авторитетных предшественников, сколько непосредственно путем анализа долгого опыта работы в области информационных технологий. Поэтому не могу не высказать благодарности, в первую очередь, своим старшим коллегам, работникам ЦУПа, у которых мне посчастливилось учиться. Также хочу поблагодарить многочисленных собратьев по ремеслу, совместно с которыми (на которых?) я набирал свой опыт, решая непростые задачи разработки программных систем. Поименно хочу поблагодарить тех из них, кто непосредственно принял участие в создании данной книги и взял на себя труд найти время, прочесть черновик рукописи и высказать свои замечания и предложения по ее улучшению, которые я с постарался учесть в окончательном варианте. Хочу выразить искреннюю благодарность менеджеру проектов компании EPAM Systems Владимиру Аркадову, руководителю направления ИТМиВТ РАН Владу Балину, руководителю направления компании «Verysell Проекты» Игорю Гундареву, разработчику ПО компании «jNetX» Кириллу Заборскому, начальнику отдела компании «Межрегиональный ТранзитТелеком» (МТТ) Александру Лебедеву, менеджеру проектов компании «Intel, Inc.» Александру Орлову. Особая благодарность членам сообщества RSDN.ru, в первую очередь, господам под никами bkat, Gaperton, Spidola, Курилка. Мысли и статьи участников я регулярно и с большим интересом изучаю, творчески переосмысливаю и стараюсь использовать в своей работе. Содержание Вперёд

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

Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

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

При классической методологии:

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

При гибкой методологии:

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

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

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

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

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

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

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

4. Обеспечиваем команду техническими инструментами

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

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

---

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

---

5. Планируем работу команды

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

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

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

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

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

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

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

Итак, что за этапы:

• Задача в работе
• Декомпозиция
• Разработка
• Ревью кода
• Тестирование
• Релиз
• Мониторинг
• Ретроспектива

Задачу взяли в работу

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

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

Декомпозиция

В чём суть. Большая и сложная задача превращается в несколько задач поменьше. Каждая такая мини-задача должна быть осмысленной и даже по отдельности нести пользу для компании.

Зачем нужно. Каждую мини-задачу можно разрабатывать отдельно и релизить отдельно.

Разработка

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

Зачем это нужно. Код сам себя не напишет.

Code Review

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

Зачем это нужно. Это помогает избегать соблазна оставить всё как есть, ведь «и так работает». Да и выпущенному коду обычно не хочется возвращаться.

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

Как проходит ревью:

1. Вы пишете код;
2. Покрываете его unit-тестами;
3. Собираете все изменения по коммитам (git commit) и отправляете в ветку в общем репозитории (git push);
4. На основе сделанных изменений создаете MR (merge request);
5. Кто-то из коллег-разработчиков берет Ваш MR и проверяет его, оставляя комментарии по спорным и проблемным местам;
6. Вы исправляете все недочеты и обновляете MR;
7. Ревьюер (не обязательно тот же самый человек) снова отсматривает ваш код и принимает его.

Тестирование

В чём суть. Проверить, что всё работает как надо.

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

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

Релиз

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

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

В это время команда изучает логи ошибок приложения (Error logs), графики, проводит Smoke-тестирование и так далее — в общем всё то, что позволяет принять решение о качестве выпущенного релиза. На основании этого этапа принимается решение о закрытии релиза или о его откате.

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

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

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

Мониторинг и оценка ценности

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

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

Ретроспектива

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

Зачем это нужно. Ретроспективы помогают своевременно устранить мешающие процессы и закрепить эффективные.

На этом всё. Запомните _г_лавное — процессы отличаются, но основы везде примерно одинаковые. Если вы понимаете, из чего состоит разработка, а не просто пишете код, то сможете добиться в IT большего.

---

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники