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

Легко ли живётся разработчикам? В разных компаниях — по-разному. Давайте посмотрим, как это вообще можно оценивать и как в kt.team строят команды, работать в которых легко и приятно.

Если вы читаете эту статью, скорее всего, вы прекрасно знаете, чем занимаются разработчики. Уточним на всякий случай: они создают и поддерживают прикладное программное обеспечение (web-сайты, мобильные приложения, системы распознавания документов, BI-системы, B2B-бизнес-порталы и многое другое).

Работают обычно не по одному, а в командах, так как разработка — дело трудоёмкое. При этом команды бывают очень разные. Где-то есть только разработчики, а где-то к ним присоединяется группа поддержки: проджект-менеджеры, бизнес-аналитики, системные аналитики, наставники по качеству… В этой статье мы рассмотрим, как они усиливают команду и упрощают жизнь программистов.

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

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

По методу Хэя:

• Необходимые знания и опыт: нужны узкоконкретизированные.

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

• Уровень ответственности: низкий (близкий к нулю).

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

Если в формулировке задачи ему не написали, что нужно обработать возможные исключения, или указали их не все, кодер не будет учитывать то, о чём его не предупредили. При этом он скажет: «Я не знал, что здесь могут быть исключения». Или: «Вы не описали все исключения, какие ко мне претензии?»

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

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

Основополагающая философия в IT — это Agile, гибкое управление проектами.

Сам Agile не делит людей по ролям. Структура команды здесь плоская, и ответственность за результат несёт вся команда.

В Agile есть product owner (заказчик, который принимает бизнес-решение и говорит, насколько эта фича значимая — при постановке задачи, есть ли от неё нужный эффект — после выполнения) и команда, в которой все участники равны. Роли проджект-менеджера не предусмотрено. Но в жизни не всё так просто.

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

У Agile-интегратора на принципы Agile накладывается парадигма TQM (total quality management, или всеобщее управление качеством).
Правила TQM:

• я не делаю брак;
  
  
• я не пропускаю брак;
  
  
• я не принимаю брак;
  

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

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

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

Разработчик должен предусмотреть, что пользователь может по ошибке указать 3000-й год или вообще буквы, и обработать все эти исключения. Это уровень качества выполнения задачи.

Проблема в том, что задача может быть поставлена некорректно (вы тоже наверняка с этим сталкивались). Бракованная задача — та, что плохо описана, и для её выполнения недостаточно данных.

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

Другой пример: клиент предлагает внедрить избыточное решение (например, новые маркетинговые фичи). Возможно, идея не самая лучшая, реализация уменьшит объём продаж, или мы потратим на неё слишком много времени в ущерб более важным задачам. Представляете, если всё это должен проанализировать разработчик или тимлид? Ему нужно разбираться в маркетинге, думать о рентабельности и напрягаться по поводу не только качества своего кода, но и общих бизнес-показателей проекта. Сколько времени нужно, чтобы сначала научиться этому, а потом выполнять изо дня в день?..

В команде с проджект-менеджером за уровень качества постановки задачи отвечает именно он!

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

Мы не можем сказать: «Знаешь что, клиент, какая-то у тебя не такая задача, иди-ка подумай и приходи с нормальным требованием». Поэтому проджект-менеджер принимает любые пожелания клиента и доводит их до качественного состояния: анализирует, отсекает ненужное, описывает разработчику, что нужно сделать, зачем, на какую ценность «ложится» эта задача. Для этого используем метод INVEST (или SMART) и impact mapping: это метод описания задач, который позволяет максимально глубоко продумать задачу со стороны пользовательской ценности, и методика, согласно которой конкретная задача ложится на улучшение конкретных показателей.

В задаче, описанной по INVEST, есть ответы на вопросы:

• кто (роль);
  
• где (место нахождения);
  
• что делать;
• для чего это всё нужно.

Сценарий по INVEST всегда должен включать бизнес-требование (что конкретно и в каком контексте требуется).

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

За INVEST отвечает владелец продукта, это уровень бизнес-требований, и это уровень качества владельца продукта (только он владеет нужными данными, и он будет принимать готовый результат). А прийти к нужным формулировкам ему помогает проджект-менеджер.

Важная часть обязанностей проджект-менеджера — управление коммуникациями.

Перевод с языка клиента

Сами проджект-менеджеры называют себя переводчиками с языка клиента на язык разработчиков и обратно. Если просто «бросить» команду разработчиков наедине с клиентом, они не поймут друг друга, потому что разговаривают на разных языках: клиенту нужно объяснять технические тонкости, а команде — переформулировать задачу от клиента в понятном для них виде.

Общение по принципу «одного окна»

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

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

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

Объективное планирование времени (никаких невыполнимых обещаний)

Для исполнителя очень сложно правильно оценить, сколько времени ему понадобится на выполнение задачи. Это психологическая ловушка — он будет стремиться назвать заказчику минимальный, невыполнимый срок («я же профессионал, эта задача лёгкая для меня») или, наоборот, планировать время механистически, закладывая слишком большой одинаковый резерв на все задачи. Проджект-менеджеру со стороны легче объективно оценить требуемое количество времени, а значит, команде будет легче не профакапить сроки и не допустить при этом перерасхода средств клиента.

В kt.team проджект-менеджер запрашивает оценку времени на выполнение задач от тимлида и команды и с учётом этой оценки и имеющихся ресурсов клиента даёт итоговый план.

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

Большие затраты времени на коммуникацию и протоколирование

Из восьмичасового рабочего дня около 4 часов проджект-менеджер тратит на общение с клиентом! Команда избавлена от этого — общение проджекта с разработчиками обычно ограничивается коротким утренним совещанием (daily meeting).

Проджект-менеджер общается с клиентом через большое количество каналов связи: email, телефоны, мессенджеры; на некоторых проектах также приходится отслеживать данные в ПО заказчика (например, в Jira). Иногда проджект-менеджерам приходится ездить в командировки, на территорию клиента, тратить время и силы на перелёты. Разработчик и тимлид имеют дело только с Jira (нашей внутренней системой). Побывать на большом конференц-колле с клиентом (на 1–2 часа) и выудить оттуда два абзаца ценной информации — это задача проджекта, а тимлид и команда получат эти данные в концентрированном виде за пять минут. Представляете, какая экономия времени?

Проджект-менеджер много работает с документами:

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

Это необходимо и очень важно, но вряд ли понравилось бы тимлидам и разработчикам. Проджект-менеджер спасает их от этого.

Приём готовой задачи

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

Метод выбирается по согласованию с заказчиком и очень от него зависит. Например, для крупной корпорации, где нужно решить заранее согласованную задачу, больше подойдёт waterfall. А если проект отличается высокой степенью неопределённости (что часто встречается в разработке ПО), то чаще всего выбирают Agile.

Кто ещё помогает командам, облегчая жизнь тимлидам и разработчикам? Делимся опытом kt.team.

Наставник по качеству

Нас иногда спрашивают: «Почему у вас так мало тестировщиков?» Их у нас действительно нет, вместо них — двое наставников по качеству. Это соответствует парадигме Agile: работа идёт в «плоских» командах, где нет отдельной функции качества. Помним здесь и о TQM — за качество исполнения задачи отвечает каждый разработчик.

Отсутствует

Если в команде есть тестировщики, это меняет весь ход работ.

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

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

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

Присутствует

Поэтому наши наставники по качеству начинают тестировать проект, только когда команда не может сама обеспечить высокое качество. Причина одна — это слишком жёсткие сроки, настолько сжатые, что нужна дополнительная помощь (например, запуск интернет-магазина с нуля за три месяца, как было у нас в «ТВОЁ», и мы буквально жили в офисе у клиента; это было несколько лет назад, и больше мы не делаем проекты с такими экстремальными сроками).

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

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

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

Бизнес-аналитик

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

Бизнес-аналитик может также:

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

Системный аналитик

На некоторых проектах команде помогает системный аналитик. Часто его функции выполняет техлид (технический лидер).

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

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

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

Кроме менеджера проектов, вместе с разработчиком работают и поддерживают его другие участники команды. Это тимлид — руководитель рабочей группы; техлид, или системный аналитик, который может проработать техническую сторону задачи; наставник по качеству, который не только проконтролирует качество кода, но и проведёт анализ, почему задача была поставлена неверно; бизнес-аналитик (часто в одном лице с менеджером проектов), который декомпозирует задачу на мельчайшие подзадачи, а при необходимости поможет клиенту составить техническое задание.

У нас в компании пять проджект-менеджеров, каждый ведёт несколько проектов.

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

Понравилась статья?

Подпишись на нашу рассылку — стань первым, кто узнает о наборе
на обучающие курсы, митапах и новых открытых вакансиях!