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

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, Курилка. Мысли и статьи участников я регулярно и с большим интересом изучаю, творчески переосмысливаю и стараюсь использовать в своей работе. Содержание Вперёд

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

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

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

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

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

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

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

Миссия и цель

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

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

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

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

• достижима:

• измерима.

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

Ценности

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

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

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

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

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

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

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

Роли и навыки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• правила,

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

• встречи,

• алгоритмы,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 типа команд в Agile: универсалы, специалисты и гибридная команда

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

В идеальном мире Agile-подхода у команд существует 3 типа структуры — рассказываем про каждую отдельно.

Универсалы

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

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

Специалисты

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

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

Гибридная команда

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

Но, если ваша цель — надежный и многосоставной продукт, оно того стоит. Такой подход обеспечивает качественную разработку программного обеспечения для больших сложных проектов, это подтверждает наш опыт и даже научные исследованияhttps://www.researchgate.net/publication/249703186_Hybrid_Agile_Development_and_Software_Quality.

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

Как это работает в Purrweb

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

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

Какие бывают роли в IT-командах

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

Вот классический набор:

• владелец продукта
• проектный менеджер
• аккаунт-менеджер
• UI/UX дизайнеры
• разработчики
• QA инженеры 

Владелец продукта (product owner, PO)

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

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

Аккаунт-менеджер

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

Проектный менеджер (project manager, PM)

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

Если вы слышите, как кто-то кричит: «Нам нужно ускориться», «Давайте сначала просчитаем риски», «Что-то работает не так», — вероятно, проджект-менеджер где-то близко.

UI/UX дизайнеры 

Эта часть команды просыпается утром и сразу думает о пользователе. Она подключается к разработке программного обеспечения на ранних этапах и следит, чтобы все в приложении было простым и понятным. Им помогают UI/UX копирайтеры, которые следят за текстом в решении и знают, как уместить важное объявление в push-уведомление, чтобы его открыли и прочитали.

Разработчики

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

QA инженеры

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

Как это работает в Purrweb

На пути к идеальной структуре мы сделали несколько ошибок и многому научились. Этот опыт помог нам узнать больше об управлении процессами разработки и разграничивать роли в IT-команде.

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

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

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

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

Как понять, что перед вами эффективная организация команды разработчиков?

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

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

• Налажена ли у них коммуникация? Посмотрите, как члены команды общаются между собой. Да, программисты не роботы и столкновения на рабочем месте неизбежны, даже при разработке программного обеспечения. Но в здоровых, хорошо организованных командах есть инструменты, как договариваться и разрешать конфликты. Можно сразу спросить: «Ребята, а как вы коммуницируете между собой? Какие приложения используете, чтобы оставаться в курсе рабочего процесса?». Если вам расскажут про Slack, Jira и Targetprocess — направление уже верное.
• Как они распределяют рабочие роли? Главное правило хорошей Agile-команды — отсутствие хаоса. Процесс разработки программного обеспечения должен быть структурирован, а каждый участник — знать, что он должен делать и к кому обращаться за советами. Чтобы проверить, как это устроено, вы можете просто спросить команду, как выглядит их рабочий процесс, кто отвечает за каждый шаг и кому вы можете задать вопрос о промежуточных результатах.

• Есть ли у них общие цели? Большинству Agile-команд не нужны четкая иерархия и строгий контроль, потому что у них общие цели и они знают, ради чего работают каждый день. Например, в Purrweb наша цель — помочь стартапам быстро проверить свои бизнес-идеи, и если вы спросите кого-либо из нашей 100 членов команды, они скажут вам тоже самое.
• Могут ли они быть независимыми? При разработке программного обеспечения строгий надзор не приносит никакой пользы ни клиенту, ни команде. Чтобы следить за каждым движением, со стороны заказчика потребуется много времени, которого у стартаперов обычно нет. А для команд пристальный контроль может демотивировать и мешать креативности. В общем, хорошая команда должна уметь работать независимо, чтобы вам не приходилось тратить все силы на управление процессами разработки. 

Итоги

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

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

Хотите познакомиться с нашей командой и получить помощь в проверке идеи для вашего стартапа? Напишите нам!