Портфель ИТ-проектов: учимся управлять не формально, а эффективно
Поделюсь личным опытом работы в ИТ-компании, использующей проектное управление. Постараюсь выделить важные вещи в эффективной работе, которые, на первый взгляд, как будто не видны и с которыми пришлось столкнуться. Углубляться в project managment не имею цели. Для этого существуют стандарты PMI The Standard for Portfolio Management, ГОСТ Р 54870–2011 «Требования к управлению портфелем проектов». Хотелось бы отметить, что работаю в госсекторе, но возможно опыт будет полезен всем.
Немного о себе. Петряшова Оксана Николаевна — 5 лет руководитель отдела развития, с большим багажом опыта. Всё нижесказанное является личным опытом и субъективным мнением.
Глава первая. Без людей не проживешь. Кадры решают всё
Разделение ролей
Руководители проектов должны заниматься проектами! Если руководитель уходит в рутинные процессы, то корабль не плывет, процессы задерживаются, работа не распараллеливается, контроль теряется. Связь с командой должна быть установлена прочная, но сливаться с командой нельзя т.к. проблемы с рутиной не заканчиваются никогда. Что сделать? Мы отделили людей территориально. Добавили проектов, которые «терпят», чтоб держать в тонусе. Объединили руководителей в команду для обмена опытом и поддержкой.
Мотивация
Существуют разные методы определения мотивации. Например, гарвардская система. Финансовая мотивация является самой эффективной, но не для всех. Для идейных — нужен общий дух, для кого-то важны социальные проекты.
Избавляемся от токсичных людей
Токсичных людей в команде видно не сразу. Они умеют выстраивать с руководством хорошие отношения. В госструктурах уволить токсика еще нужно постараться, но можно отправить на исправительные работы, с которыми они будут хорошо справляться.
Прокачиваем умения и навыки. Не забываем про soft-skills
Курсов о проектном управлении на рынке достаточно. Мы выбрали известную образовательную организацию. Претензий к компании нет. Преподаватели компетентные, но, как оказалось, от преподавателя зависит % осевшего материала в голове. Так что выбираем преподавателя с опытом работы в ИТ сфере. Прочитать учебник и так все смогут.
Оценка компетенций в организации должна проводиться и проверяться, но это отдельная тема.
Системное мышление. Нужно ли развивать системное мышление у сотрудников внутри компании? — Конечно, нужно. После курсов люди меняются, риски оценивают под другим углом зрения. Меньше идут ложными путями. Да и с умными людьми работать приятно. Растешь сам — расти свои команды.
Презентации и публичные выступления. Данные скилы сотрудников повышают лицо компании.
Этика. Это либо у человека есть, либо нет. У ИТ специалистов частенько хромает. Закидайте тапками, но по моему опыту, высшее образование на престижном факультете = интеллект в глазах и этика в придачу.
P.S. На протяжении всего опыта работы могу сказать, что некомпетентные специалисты и хамство лишают компании миллионов, если есть конкуренция. Но об этом их руководство никогда не узнает.
Глава вторая. Инструменты работы для проектного подхода
Почему инструменты на втором месте? — Потому что хороший специалист отрисует схему, опишет процессы, оценит риски при помощи карандаша и бумаги. А «неострого» специалиста не спасет интеллектуальная система. И так наш опыт работы:
Одна из популярных Project систем. Мы весь функционал системы так и не использовали по ряду причин, в том числе импортность ПО. Отслеживать планы- графики и занятых в проекте помогало. Возможностей там гораздо больше.
CRM система. Использовали функционал для работы группами для задач, общих документов, чатов. Полезная вещь, много функционала и можно развивать под себя.
Был опыт внедрения своей системы управления проектами с попыткой сломать принципы управления проектами. Смешно звучит, правда? Но опыт был. Не делайте так. Вернитесь к п.3 и повышению компетенций сотрудников.
Что-то примитивно простое в виде таблиц на базе облачного решения с совместным редактированием документов.
Любые Project системы. Их на рынке стало много. Мы используем project систему внутри СЭД. Это супер выбор, когда у вас основная СЭД того же разработчика. Все в одном. И СЭД, и диаграммы Ганта, сроки, трудозатраты, задачи в едином окне, связь с официальными документами, Agile доска. Там фантазий для коллабораций много. Тоже тема отдельной статьи.
Глава третья. Документация
Из широкого спектра общения в ИТ среде. Реально в жизни оказалось, что существуют огромные системы, про которые вы бы никогда не могли подумать, не имеют документации.
Это очень-очень важно. Наколкой на лбу. Святое из святых. Документация. Да, ГОСТ 34 — вызывает много споров к избыточности оформления и излишнему составу документов, но без него совсем нельзя. Пройдусь по основным своим вехам объективно-субъективно.
Устав проекта (проблема, цель, задачи, оценка рисков, оценка ресурсов, анализ вариантов реализации). На всех этапах приходится возвращаться к цели. Возник спорный вопрос — вернись к цели и там найдешь ответ.
Сбор требований (под протокол).
Бизнес-требования в BPMN. Обязательно необходимо произвести реинжиниринг процессов.
Анализ вариантов.
Техническое задание.
Эскизный проект и технический проект. Опционально. зависит от сложности.
Программы и методики испытаний. Без них процесс очень затягивается и может превратиться в балаган. Потеря времени — потеря денег.
Протоколы испытаний. Аудио, видео протоколирование встреч с заказчиком на этапе обследования, тестирования, приемки. (очень-очень нужно в сложных проектах с большим числом заказчиков, спасало много раз).
Акты работ.
Программный код, если передается, то в Git.
Инструкции пользователя, администратора. Про последнее часто забывают. И что потом?!
Курсы для пользователей в форматах вашей системы обучения. Мы за Scorm.
Надеюсь, информация будет полезна, хоть и кратко. Желаю вам успехов и развития. Хоть жизненный цикл и закольцовывается, но движется вперед по спирали. Идите к цели и добивайтесь. Всем сил и энергии.
