Блог

Всеволод Фролов
Начальник отдела управления проектами

Project-менеджер, смотри в БД

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

Фото — Федор Кобец

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

Предположим, что поступившая от заказчика доработка успешно проанализирована, прошла процесс согласования и уточнения, описана в задачах и реализована. Как менеджеру проверить, что она соответствует пожеланиям заказчика и по ней можно отчитаться? Казалось бы, правильный путь – положиться на тестировщика. Однако на практике все не так просто. Отвечать за косяки будет не тестировщик, краснеть на совещаниях тоже придется не ему, а менеджеру. Часто случается, что тестирование работает «в лоб» и методично проверяет задачи одну за другой, не выделяя среди них важные и второстепенные. Это процесс не быстрый. Менеджеру же необходимо понять, реализована ли задача по сути, даже если в реализации найдутся незначительные баги, нужно принять решение, сделана она или нет. Бывает, что незначительный на первый взгляд нюанс может вернуть задачу на доработку, и она будет признана несделанной.

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

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

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

Как еще можно проверить реализацию задачи? Можно посмотреть в код. Или поручить тимлиду сделать ревью. Но такие проверки – это проверки в середине пути, они не гарантируют результат. А проверка в базе – это уже финишная ленточка.

Почему смотреть результат в базе – это хорошо? Во-первых, базовые sql-запросы достаточно просты, они не требуют особого устройства мозга :) Во-вторых, это инструмент контроля, о котором знает разработчик. Кроме того, уменьшается количество лишних вопросов к разработчику, что позволяет ему заниматься задачами и не отвлекаться на ответы и нервничать. И наоборот, способность менеджера самостоятельно что-то делать вызывает уважение, а взаимное уважение – важная составляющая успешной команды. Тестировщики тоже понимают, что со стороны менеджера есть контроль и в некотором роде помощь.

Перефразируя афоризм «Зри в корень» для project-менеджера, скажу: «Смотри в БД».