Как в ИТ-компании управляют проектами – рассказывает Project Manager Itransition

«Про бизнес.» и компания Itransition запускают серию совместных материалов о том, как устроен бизнес в ИТ. Мы расскажем об особенностях работы в ИТ-отрасли, об интересных задачах, которые решают специалисты, менеджеры и топ-менеджеры Itransition, об изменениях, которые происходят внутри компании в связи с ростом бизнеса. Мы полагаем, что интересное в нашей серии найдут для себя не только читатели-айтишники, но и те, кто работает в традиционных секторах и интересуется современными подходами в управлении персоналом, проектном менеджменте, маркетинге, продажах etc.

Первый материал серии — об управлении проектами. Вероника Трухан, Project Manager подразделения Web Development компании Itransition, рассказывает про один из проектов, который реализовывает ее команда. На этом примере Вероника показывает, в чем особенности подхода Scrum, как происходит взаимодействие между разработчиками и клиентами и из чего складываются этапы работы над проектом.

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

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

Начало проекта: первая фаза и первые требования, которые не совсем ясны

Бывают ситуации, когда потенциальный клиент не то чтобы сомневается в разработчике… Но перед началом сотрудничества еще раз хочет посмотреть за его действиями на практике. И убедиться в правильности выбора. В этом случае клиент выбирает одну из задач проекта и предлагает ее для реализации, а после принимает окончательное решение о старте всего проекта — на основе результатов выполненной демо-задачи. Мы начали с того же самого: сделали один из «кусков» будущего функционала. Показали эту фичу (элемент) клиенту. Получили одобрение. По сути, тогда и начался сам проект.

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

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

Основная же сложность заключалась в том, что мы полностью зависели от результатов работы команды back-end разработки клиента. На их стороне разрабатывается API, создается и поддерживается база данных. И для того, чтобы интерфейс приложения «ожил», необходимо, чтобы API передавало данные из базы данных на front-end.

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

О внедрении гибких методологий с самого начала проекта мы не думали. Работали, используя свод знаний по управлению проектами PMBOK. В частности, каскадный метод управления проектами (waterfall model), при котором соблюдается последовательность фаз. Каждая из них должна завершиться до начала следующей: анализ требований, проектирование, реализация функционала, его тестирование, интеграция и поддержка. Соответственно, финансовой схемой была fixed price — фиксированная стоимость за выполненную работу. 

Итог первой фазы: поставленных целей достичь не удалось… Из-за асинхронных действий двух команд функционал фазы полностью готов не был. Остались незавершенными некоторые модули системы.

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

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

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

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

С чего мы начали освоение Scrum

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

• Поговорили с product-менеджментом клиента и попросили приоритезировать известные требования и оставшиеся от первой фазы задачи. В соответствии с планом релиза версий системы
• Из получившегося списка сформировали список всех работ — бэклог (product backlog)

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

Scrum предлагает работать по спринтам, итерациям не более 1 месяца. Мы решили, что для нашего проекта идеальная длительность спринта — 2 недели.

Получалось, что краткосрочное планирование работы нашей команды должно было осуществляться на срок «2 недели и чуть-чуть дальше».

В качестве трекингового инструмента (он помогает следить за ходом проекта и выполнением задач) мы используем инструмент Jira Agile. Также у нас есть магнитная доска в кабинете. Она является «фильтром» задач высокого приоритета. Если я хочу обратить внимание разработчиков на срочные (или важные для клиента) тикеты, я пользуюсь именно ей.

Спринты объединяются в фазу. Одна фаза может состоять из 10−20 спринтов (их общая длительность 20−40 недель).

Как планируется спринт

Я считаю, что планировать спринт, как и оценивать задачи, обязательно должна вся команда, включая всех заинтересованных лиц: разработчиков, тестировщиков, дизайнеров. Если следовать классическому набору ролей в Scrum, в команде должен присутствовать scrum-мастер. Но в реальности зачастую эта роль переходит к менеджеру.

Как происходит планирование спринта? Команда собирается в одном помещении. Менеджер проекта презентует скоуп (объем работ), который, исходя из приоритетов product-менеджмента клиента, может быть реализован в данном спринте.

Чтобы понять, «заходит» ли этот объем в спринт, необходимо его оценить. Для этого мы используем метод покерного планирования (Poker Planning).

Каждый из членов команды держит в руках набор карт, как в игре в покер. На них указаны числа Фибоначчи c некоторой модификацией, включая ноль. Например: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. После презентации задачи, обсуждения ее логики и технических особенностей, разработчики проговаривают предварительный план ее реализации, а QA (тестировщики) могут обратить внимание команды на особенности ее тестирования. Далее происходит непосредственно оценка: каждый выбрасывает карту рубашкой вверх с адекватной, как он считает, оценкой сложности реализации задачи. Когда каждый сделал свой выбор, карты переворачиваются.

Получается, что вся команда оценивает одну задачу. После чего начинается дискуссия: оценки совпадают редко.

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

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

Что такое story point. Каждая команда, использующая poker planning, по-своему трактует числовые значения карт: длительность (часы, дни) или относительные единицы сложности (story points). Мы оперируем story points, то есть оцениваем сложность выполнения конкретной задачи — относительно «эталонной» задачи. Это делается для того, чтобы не привязываться к временной шкале. Ведь оценить сложность (объем работ) психологически проще, чем необходимое время на реализацию. Кроме того, это позволяет избежать навязывания мнения со стороны более авторитетных участников команды: т.н. «эффект привязки».

Что такое «эталонная» задача. Часто за один story point принимают сложность реализации небольшой фичи, например, базовой формы авторизации (форма ввода логина и пароля) в приложении. Но так как story point — абстрактная величина, имеющая смысл только в рамках проекта, то и «эталон» (базовая задача в 1 story point) для каждого проекта свой.

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

Сколько story point может быть выполнено за спринт. После оценки сложности задачи необходимо понять, сколько story points может «поместиться» в спринт. Обычно команды приходят к пониманию «объема» итерации методом проб и ошибок, на первых порах перебирая и недобирая задачи. Но зачастую к 3−4 спринту планирование проходит эффективнее, а количество story points в них становится практически стабильным.

Также мы определяем, сколько story points за один спринт может выполнить каждый разработчик, в зависимости от своего уровня (junior, middle, senior).

В «горячее» время, когда надо было реализовать приоритетные задачи, разработчики брали до 11 story points на каждого. В «штатные» спринты мы планируем загрузку в 6−8 story points разработки на каждого. Включая технические активности (написание unit- и e2e-тестов, code review и т.д.).

Также мы учитываем время на тестирование и стабилизацию. Существует такое понятие, как feature freeze, или замораживание функциональных свойств. Это заранее оговоренный момент, когда останавливается разработка функциональности и внимание команды переключается на стабилизацию и тестирование. Для нас feature freeze наступает на 6−7 рабочий день десятидневного спринта (2 календарные недели). Как правило, в спринт попадают задачи с разной оценкой, поэтому некоторые из них уходят на тестирование до момента остановки разработки.

Соответственно, в зависимости от приоритетов клиента и загрузки ресурсов (графика отпусков, праздников, болезней), вся команда может выполнить 50−70 story points за спринт.

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

При этом соотношение 50% времени на разработку и 50% на стабилизацию — это, скажем так, ненормально. Но иногда необходимо.

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

Как проходит спринт

В нашей команде мы выработали следующие процессы (они отступают от классики Scrum, но являются эффективными для нашего проекта):

1. Планирование — первый день (понедельник) спринта, не более 2 часов. О планировании подробнее было сказано выше.

2. Ежедневные летучки, а также груминг бэклога – подготовка задач на следующий спринт (daily standups + task/bug backlog grooming), продолжительностью по 20−30 минут. Помимо обмена статусами работ (что сотрудник сделал, что собирается делать, какие трудности) мы добавляем «причесывание» бэклога задач для последующих спринтов и/или разбираем, назначаем ответственных за исправление багов в текущем спринте.

Основной упор чаще всего делается на груминг и «раскидывание» (распределение) багов высокого приоритета, которые должны устранить разработчики, в том числе из числа back-end команды клиента, в рамках текущего спринта. Мы делаем это в первую очередь для того, чтобы оперативно исправлять критические ошибки, а также чтобы избежать застоя в списке «бесхозных» багов. В зависимости от активности QA и фазы спринта, речь может идти о 10−30 тикетах ежедневно.

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

Для этого я разрабатываю предварительный план на 2−3 спринта вперед. Когда освобождается время на daily standups, команда оценивает 2−3 истории или задачи «про запас».

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

3. Dev meeting — митинг разработчиков, который проводится каждый второй понедельник спринта. Продолжительность не более 1 часа.

Цель — обсуждение технических особенностей и сложностей функционала. При необходимости, привлекается менеджер и QA. Например, когда мы разрабатывали стратегию автоматизированного тестирования (написание и поддержка e2e-кейсов, их автоматизация, прохождение всех стадий «жизни» кейса, от написания до ревью и закрытия), привлекали всю команду.

4. Demo/Retro спринта — последний день спринта, не более 2,5 часов. Спринт закрывается демонстрацией реализованного функционала и обсуждением результатов прошедшего спринта (ретроспектива).

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

Побочным положительным эффектом можно считать:

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

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

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

Как измерить успешность спринта

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

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

Каждая команда сама вырабатывает критерии готовности задачи. Наш definition of done (критерий готовности) для функциональной задачи (истории):

• Готовый (оттестированный и стабилизированный) функционал
• Отсутствие багов высокого приоритета (major, critical, blocker)
• Написанные unit-тесты (если требуется)
• Написанная документация кода (если требуется)
• Успешно пройденный code review (инспекция кода)

После закрытия каждого спринта, QA-команда собирает статистику и оформляет ее в отчет (sprint report). Кроме количества и статуса багов и задач, нам интересен процент регрессии — наиболее «слабые» места приложения (в том числе API), тендеции качества. То есть любая информация, которая поможет сделать выводы о нашей работе в спринте. Отчет рассылается на всю команду.

На основе sprint report я составляю отчет для команды клиента. Вся информация им не нужна, но наиболее репрезентативные данные, интересующие обе стороны, сохраняются. Также в отчет входит план следующего спринта.

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

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

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

Отношения внутри команды​

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

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

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

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

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

Что происходит с проектом сейчас

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

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

Сейчас наша команда состоит из 7 разработчиков, 3 QA-инженеров и менеджера. Наша загрузка — полный рабочий день. Мне как менеджеру важно и ценно появление собственного аккаунт-проекта: на нем работает выделенная команда, мы тесно сотрудничаем со специалистами клиента, приложение развивается несколько лет. Мы вместе совершенствуем продукт, и, надеюсь, нетривиальные задачи будут появляться и дальше.

Материал подготовлен редакцией «Про бизнес.» совместно с Itransition