Апр. 15

Какая техническая экспертиза нужна проджект-менеджеру сегодня

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

За 5 лет в разработке я сталкивался как с чистыми гуманитариями в IT, так и с теми, кто перешел в PM’ы с технической позиции.

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

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

Еще минутка мотивации: почему технические знания важны для PM’а

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

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

Менеджер без технических знаний:

Не может понять эстимейт: отводит на задачу неоправданно много времени или, наоборот, эстимейтит слишком оптимистично — и команда срывает дедлайн.
Слабо различает зоны ответственности в команде, кто в чем виноват, кому адресовать задачу. Например, с кем говорить, если поплыл логотип на сайте? С дизайнером или веб-мастером?
Не может объяснить клиенту сложность или выгоду определенных решений. Часто 80% работы бэкенда абсолютно не очевидны для пользователей (например, оптимизация компонентов системы), но без этой технической части продукт не будет работать нормально.

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

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

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

Как распределяются роли в команде

Разобраться, кто за что отвечает, — это базовый уровень технических знаний для PM’а. Дальше посмотрим на практическом примере, кому адресовать разные задачи, если что-то пошло не так.

В создании любого приложения или сервиса задействованы 5 компонентов: Design, Backend, Frontend/Mobile, QA, SysAdmin/DevOps. За каждую составляющую в команде отвечают разные специалисты. Когда менеджер различает сферы ответственности, то не будет отвлекать фронтенда, если долго обрабатываются запросы.

Дизайнер (UX и UI Design) — создает дизайн и выделяет бизнес-требования, продумывает сценарий пользования. Несет ответственность за то, как будет выглядеть продукт и насколько удобно взаимодействовать с сайтом или приложением. Все должно быть продумано, расположение кнопок интуитивно понятно. От дизайна во многом зависят задачи фронтенда и бэкенда.
Backend — пишет логику и API (интерфейс приложения), чтобы с этим могли работать фронтенды или мобильные разработчики.
Frontend или Mobile — заботится о том, как работает видимая, клиентская часть сайта (Frontend) или приложения (Mobile).
QA (тестировщик) —тестирует продукт на соответствие оговоренным требованиям и стандартам качества. Самая важная цель тестировщика — это не количество выявленных багов на этапе тестирования, а чтобы пользователи не находили дефекты после релиза продукта.
SysAdmin/DevOps — следит за тем, чтобы все важные части приложения были доступны 24/7 и отлаженный процесс доставки кода происходил непрерывно. Это тихий наблюдатель, который работает параллельно со всеми процессами «в фоновом режиме». Чаще всего работу сисадминов или DevOps не замечают до тех пор, пока что-то не сломалось. Если все идет как надо, работа DevOps’а так и остается незаметной.

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

Игра: кому адресовать задачу

Давайте представим, что от заказчика поступает ТЗ: создать MVP сайта по сокращению ссылок, на котором пользователь сможет:

регистрироваться/логиниться;
создавать сокращенные ссылки;
смотреть статистику по ссылкам.

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

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

Рассмотрим на примерах:

График переходов по ссылке не рисуется в Safari. А в Chrome все происходит как положено. С такой ошибкой нужно подходить к фронтенду, потому что разбираться с отображением данных в браузере — это его работа.
Не собирается статистика переходов по ссылкам. Пользователи переходят по созданным ссылкам, но обновления статистики в консоли не видно. Здесь сможет помочь бэкенд, так как подсчет переходов — задача, не связанная с отображением данных, это исключительно внутренняя логика, которая живет на бэкенде.
Ссылки долго открываются для пользователей из Латинской Америки. В Европе ссылка открывается за 300 миллисекунд, а в Латинской Америке — 1,5 секунды. Вероятнее всего, это задача для DevOps: надо либо настроить DNS, либо продублировать сервер приложения где-то в регионе Латинской Америки.
При попытке открыть сайт появляется ошибка 500. Это один из случаев, когда не получится сразу идентифицировать, чья проблема. Скорее всего, решать будут бэкенд вместе с DevOps’ом.
Не работает создание новых ссылок. Есть какая-то форма на сайте, ее надо заполнить, ввести длинную ссылку, нажать «сохранить» — и получить сокращенный аналог. В какой-то момент эта форма перестала работать.

У такой ошибки может быть несколько причин:

бэкенд выдает 500 ошибку, и ссылка не формируется;
на фронтенде что-то сломали, поэтому не передается параметр, который показывает, что пользователь авторизован. Тогда ссылки не будут сокращаться, потому что бэкенд не считает пользователя авторизованным;
возможно, проблемы на стороне DevOps: упал один из серверов и сайт показывается, но вся логика заблокирована.

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

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

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

Понимание основ разработки — это базовый уровень технических знаний PM’а. Следующий этап — прокачивать навыки оценивания вместе с командой.

Понимание эстимейтов

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

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

Приведу такой пример. Бэкенд может быть написан на PHP, а может — на Java. PHP отрабатывает запросы быстро, а Java — это отдельное приложение, которое постоянно крутится в ожидании запросов. В зависимости от языка программирования, время на исправление ошибки будет разным. В случае с PHP, можно быстро запушить изменения с сервера, фактически незаметно для пользователя. В случае с Java, чтобы все заработало, надо пересобирать весь бэкенд сначала. Если РМ понимает разницу между языками, он не будет рассчитывать, что ошибку поправят быстро, не будет ругаться, что прошел уже целый час, а разработчик все еще не пофиксил проблему.

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

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

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

Сначала решаем, кто из команды понадобится:

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

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

Фронтенд оценил работу в 4 часа, включив туда верстку, логику запрос/ответ на бэкенд — и все.
Бэкенд оценил задачу в один месяц: написать новые таблицы в базе данных, логику запрос/ответ к серверам PayPal, API, с которыми будет работать фронтенд.

Оценка фронтенда выглядит реалистично. Когда есть задача, например написать «модалку», чтобы можно было платить через PayPal, то 4 часа кажутся вполне подходящим сроком.

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

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

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

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

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

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

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

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

Итоги

PM с технической экспертизой:

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

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

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