Стань сильним Software Architect, впорядкуй знання та отримай нові навички. Реєстрація на тренінг!
×Закрыть

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

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

LinkedIn

38 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Благодарю, отличная статья!

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

2020 год, а у нас за команды по-прежнему должен эстимейтить ПМ. Однако.

Давным-давно, когда курс был даже не 8, а 5, в ПМы брали только достойнейших и опытнейших, прошедших через километры строчек говнокода, разгребших не один завал, переживших десятки рефакторингов. Время шло, и постепенно они стали разбавляться бывшими проджект-координаторами и QA-лидами, но уровень продолжал худо-бедно держаться

И тут бахнул Майдан, 2014й год, переходящий в 2015й и курс 25. В ИТ кого только не ломанулось, и пасти это стадо поставили вчерашних девочек-мальчиков студентов, свитчеров из телекома, бывших старших менеджеров по продажам, ассистентов руководителя и прочих. Прочих, чьи возможности сводились к пересыланию писем с фразой «посмотри и разберись» при абсолютном непонимании в чем проблема или задача. Посчитал часики, сделал эксельку — выслал таймшит на биллинг. Организовал тимбилдинг, если надо. Ах, да, скрамчики-дейлики.

И вот, в 2020м уже появляются статьи — нужен ли технический бэкграунд ПМу? Если нужен, то как отличить бэкенд от фронтенда.

Надо ли удивляться, что такое пробитие дна украинской ИТ-индустрией совпало с самым крупным кризисом в ИТ со времен Пузыря Доткомов?

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

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

ПМ, знающий элементарные вещи, куда хуже, чем ПМ, знающий, что он ничего не знает.

Тут дело не в знании, а в умении им пользоваться или не пользоваться. Знания != ум.
Это как в старой шутке — «когда ты умер, всем тяжело, но ты об этом не знаешь — то же самое, если ты тупой».

Бэкенд может быть написан на PHP, а может — на Java. PHP отрабатывает запросы быстро, а Java — это отдельное приложение, которое постоянно крутится в ожидании запросов.

головне щоб пм не почав розказувати на чому краще писати тому що десь він прочитав що від мови програмування запити по різному відробляють )))

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

Тут хочеться додати, що вміти в «управління» не означає бути компетентним, що може призвести до серйозних негативних наслідків. Я от не уявляю собі, щоб завідувачем кафедри прикладної математики став колишній завідувач кафедри філології незалежно від того, яким би хорошем управлінцем він міг бути на попередній посаді — йому банально не буде вистачати експертизи в прийнятті важливих рішень чи у вирішенні спірних ситуацій всередині команди.

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

меня одного коробит от использования слова «экспертиза» в значении «опыт»?

Точно также не могу понять, почему опыт был всю жизнь опытом, а буквально несколько лет назад стал экспертизой. Что стало не так со словом «опыт» ?

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

Экспертиза к опыту семантически имеет лишь косвенное отношение.

ИМХО в статье скорее описаны кейсы не «не технического ПМ», а скорее просто менеджера-джуна. И не важно это бывший технарь или «свитчер». Хороший технарь != хороший менеджер, как и наоборот 🤷😊

Абсолютно согласна с кейсом, что техническая база ПМ-у необходима.
Статья достаточно неплохо подчеркивает это.

Но вот скрытая реклама курсов немного оттолкнула.

QA (тестировщик) —тестирует продукт на соответствие оговоренным требованиям и стандартам качества.

Это не QA, а QC.

О, обожаю эту тему! Поговаривают, что тот кто разделяет термины QA и QC имеет шанс найти между ними не только разницу, но и Святой Грааль...

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

Простите, какие базовые вещи? :)

что есть quality assurance и что есть quality control, и как они соотносятся друг с другом.

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

Facepalm.jpg
Вот для таких людей и появляются статьи «нужны ли PM’у технические знания»

Благодарю за «адекватное» мнение с переходом на личности.

Позиция взрослого ПМа
Вместо того, чтобы попросить фидбек\спросить что же не так — обидеться, аки девочка-подросток.

Я не обиделся, я веду дискуссию и выражаю своё мнение, более того уважаю мнение других участников.

А Вы снисходительно пишете про фейспалм и считаете, что только Вы правы и я должен дать «заднюю» и что-то ещё попросить.

У Вас в скрам-команде, наверное, и QA есть, и QC?

QC — да, тестировщик в SCRUM-команде. QA — отдельное направление (набор департаментов). Но єто кровавій єнтерпрайз

А в том и дело, что QA, в отличие от QC — это деятельность далеко не только специалиста по тестированию, но и менеджера проекта, и архитектора, и тим лида.

Т.е. это не должность/роль отдельного, специально обученного специалиста в компании, а деятельность?

Может быть и ролью / должностью, но, как я говорил — как правило, на больших enterprise проектах, в основном, в какой-нибудь фармацевтике или авиакосмической отрасли.

Но, в первую голову, да — деятельность.

Т.е. скорее исключение из правил, всё верно.

Смотрите, даже не заходя в дебри знаний тестировщиков. ПМБоК 6, раздел 8 — Управление качеством на проекте. 8.2 «Управление качеством» и 8.3 «Контроль качества» очень четко описывают разницу в применяемых подходах и мероприятиях.

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

jobs.dou.ua/vacancies/?category=QA — 251 вакансия по Украине на сегодняшний день.
Открываю полный список, комбинацией Ctrl + F ищу по странице фразу «QC», в результатах нахожу 3 упоминания, 2 из которых звучат как QA/QC. Ладно, среди них 113 вакансий «Automation QA», поэтому остаётся 137 открытых вакансий, которые мы будем называть «QA Engineer».

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

То, что в украинском аутсорсе существует давнее заблуждение называть специалистов по тестированию QA — это правда.

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

То, что в украинском аутсорсе существует давнее заблуждение называть специалистов по тестированию QA — это правда.

Ну я к этому изначально и веду — к вопиющим фактам подмены и искажению понятий, терминов и формулировок. Назовём себя так, как будем звучать солиднее, не уборщица-техничка, а инженер клининговой компании, не тестировщик ПО и даже не QA Tester, а Quality Assurance Engineer/Specialist.

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

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

у Егора Бугаенко есть доклад на эту тему — www.youtube.com/watch?v=jZitXMQaXvE
(Егор часто весьма катигоричен, заходит далеко не всем, но часто заставляет задуматься над, вроде как, «привычными» вещами)

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

Подписаться на комментарии