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

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

Труд разработчиков и оценка его сложности

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

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

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

Факторы оценки должностей по методу Хэя:

1. Необходимые знания и опыт (know-how)

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

3. Решение задач (problem solving)

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

3. Уровень ответственности (accountability)

ответственность сотрудника (за личный и/или командный результат труда).

‍

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

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

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

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

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

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

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

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

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

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

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

Функции проджект-менеджера: качественная постановка задачи

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

Попробуем ответить на этот вопрос

Основополагающая философия в 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 отвечает владелец продукта, это уровень бизнес-требований, и это уровень качества владельца продукта (только он владеет нужными данными, и он будет принимать готовый результат). А прийти к нужным формулировкам ему помогает проджект-менеджер.

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

Функции проджект-менеджера: коммуникации

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

‍

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

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• контролирует корректность ведения ворклогов и отправляет детализацию клиентам;

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

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

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

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

Вывод

Может ли всё это делать тимлид? Ведь у него высокий уровень soft skills и он неплохо умеет общаться.

Тимлиды периодически общаются с клиентом даже при наличии проджект-менеджера. Но если бы менеджера проектов не было, тимлид был бы вынужден:

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

• дёргаться каждые пять минут от входящих сообщений в мессенджерах, email'ов, звонков;

• продумывать весь бизнес-функционал проекта;

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

• вести протоколы, отчёты, рассылать их всем участникам;

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

Мы стремимся к тому, чтобы тимлиды и другие разработчики обеспечивали только execution — выполнение задачи.

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

Функции проджект-менеджера: управление проектами

С точки зрения управления проектами есть две основные методологии:

• гибкая (Agile);
  
  
• разработка по требованиям (waterfall).

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

‍

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

‍

‍

‍

‍

‍

‍

‍

‍

Что делает проджект-менеджер каждый день для управления проектом:

• контролирует своевременный запуск и ход работ;
  
  
• проводит ежедневные совещания с командой (daily meeting);
  
  
• воздействует на команду (или руководителя команды), чтобы факт соответствовал плану и выполнял требования клиента;
  

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

• ведёт документацию по проекту (уставы проектов, интеллект-карты, отчёты и т. д.);

• участвует в демонстрациях функционала клиенту.

Вывод

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

Наставник по качеству, системный аналитик, бизнес-аналитик

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

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

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

Отсутствует

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

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

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

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

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

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

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

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

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

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

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

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

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

• составить техническое задание на разработку за клиента, если ему это нужно

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

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

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

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

Резюме: плюсы работы в большой команде

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

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

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

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

‍