Отзыв на конференцию Code’n’Coffee: IT Project Management

Как часто проджект менеджеры оказываются между молотом и наковальней, когда пытаются найти баланс между всеми требованиями и сроками заказчика и ментальным здоровьем всей команды? Сколько нюансов нужно учесть, чтобы по обе стороны ответственности был мир и порядок? Как понять хороший ты менеджер или тебе срочно стоит подтягиваться по всем фронтам? Как определить, в каких аспектах именно ты, как ПМ, отстаешь, а где ты молодец и умничка? Именно об этом была очередная конференция Code’n’Coffee.

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

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

• понятие интересного проекта: всегда нужно четко определять что, а главное ЗАЧЕМ вы разрабатываете. Не всегда то, что интересно реализовывать программисту, будет нужно заказчику в данном проекте. Не на каждый проект нужно внедрять новые технологии, поднимая риски проекта, иногда проще и быстрее — самый правильный вариант.
• постоянные дедлайны вредят качеству проекта и понижают мотивацию команды: частые дедлайны — это вечные компромиссы между тем, как правильно, но дольше и не совсем правильно, но быстрее. Любой хороший программист не любит делать свою работу «хоть как-нибудь» и даже если такие варианты согласовываются с заказчиком или даже исходят от заказчика, это всегда идет в минус мотивации разработчика. (Лучший тезис из конференции, который теперь висит у меня в качестве напоминалки!)
• только ПМ отвечает за качество проекта! Не программист и даже не тестировщик! Код может быть 100% покрыт тестами, выглядеть идеально, но делать совершенно не то, что нужно заказчику.
• желание программистов рефакторить код — это нормальное желание каждого программиста, но это вовсе не означает, что проект действительно требует рефакторинга. Никогда не имеет смысла рефакторить без задания. Для этого можно использовать правило «третьего раза» Мартина Фаулера (книга «Рефакторинг. Улучшение существующего кода»). А вот на необходимость оптимизаций стоит обращать внимание.
• поддержание скоупа и приоритетов зависит ТОЛЬКО от ПМ. Уменьшение или увеличение скоупа — ответственность проектного менеджера. Если скоуп оказался непомерным по срокам для программистов — это недочет ПМа. Резонный объем работ — основная задача ПМа в данном аспекте своих работ.
• оценки времени выполнения задач могут выдать ТОЛЬКО программисты, не ПМ и тем более не заказчик. Фраза от клиента: «Внесите эту фичу в скоуп, там всего 5 минут» — на ПМ должна останавливаться!

Мы получили от Сергея около 40 слайдов полезной информации и около 12 живых примеров из личного опыта и информации оставалось еще на 2 таких доклада. Было очень интересно.

Он напомнил о том, что ПМ в первую очередь всегда должен держать фокус на бизнес целях проекта. Т.е. вся деятельность ПМа должна быть направлена на то, чтобы ответ на вопрос «Решает ли данное действие, данная фича (и т.д.) проблему заказчика?» — был всегда «ДА». А значит, вы всегда должны держать в голове какую цель разработки вы преследуете в данном проекте.

Умение оценить масштаб и цену ошибки — бесценно. Сюда же в раздел можно включить работу с рисками. (Воркшоп по рискам с Анной Лавровой Km CNC проводил в мае).

Проджект менеджмент — это история постоянного развития и роста. В ключе данного аспекта Тарас вспомнил про такое течение японской культуры как Ikigai и тест DISC, на которые стоит обратить внимание.

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

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

Тарас придерживается мнения, что у каждого хорошего ПМ должен быть технический бекграунд. Расхожее мнение и точка спора ПМов с наличием и отсутствием технического опыта)) Многие ПМ доказали, что данный аспект необязателен, но тяжело оспорить тот факт, что понимание технической стороны разработки значительно облегчает жизнь любому проджект менеджеру.

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

Спасибо Code’n’Coffee за ивент и за возможность получить информацию для сравнения со своим опытом, пересмотреть некоторые подходы и задать себе необходимые вопросы!