Современный менеджмент: почему старые подходы не работают и что с этим делать

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

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

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

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

Дело в том, что часто именно в общении с руководителем проекта заказчик и “придумывает” какой-то новый функционал, развитие проекта, концепцию, согласовывает те или иные моменты. Поэтому руководитель проекта – это частично и продуктовый аналитик.

То, что современный руководитель проекта часто олицетворяет для клиента саму компанию — это уже факт. К нему часто возникает вопрос: вот все, что мы с вами сейчас придумаем, а сделать-то вы сможете?

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

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

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

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

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

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

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

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

Современный руководитель проекта никогда не идёт к заказчику, не проверив всё сам. Тестировщик — это прекрасно, тестировщик все тоже проверил, но когда руководитель идет к заказчику, он должен понимать, что показывать заказчику будет он сам, нажимать на кнопки тоже будет он сам. А следовательно, прежде чем что-то принять, либо что-то подтвердить, он должен в этом убедиться самостоятельно. Здесь как раз пригодится и опыт, и компетенция в выбранном направлении.

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

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

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

В следующей части поговорим про управление бюджетом, командой (как работать с разными командами и что делать, если команда хочет действовать иначе) и о том, почему современному руководителю важно разбираться в каждой детали проекта. А пока можно подумать вот над чем: что изменилось за последние 10 лет в проектах, что большинство старых знаний внезапно устарело? Если найдёте ответ, считайте, что вы перешли на новую ступень, как руководитель.

#менеджмент #управлениепроектами #руководителям #ИТ #IT #управлениекомандами #NOTскромность