Управление ИТ программами

Докладчик: Андреас Каллен

Что делает программу программой? Ее масштаб, объем проекта. Качество, бесспорно, связано с этим. Если это IT-программы, то нужно поговорить об управлении релизами. Рассмотрим концепцию «треугольник ограничений» — обычно в центре треугольника находится масштаб проекта, иногда ограничения бывают бюджетные, ресурсные, временные. Размер, масштаб зависит от других параметров — это одна из вершин треугольника, на остальных — время, бюджет, и качество — в середине.

Что нам показывает данный треугольник? Когда вы увеличиваете объем, масштаб, это сразу же влияет на бюджет, на время и на качество. И наоборот, урезаете бюджет — значит, нужно урезать и объем, и границы проекта, в том числе и сроки. Поговорим о масштабе и объеме проекта, и об управлении им. Если вы хороший программный менеджер, вы умеете управлять границами, масштабом проекта. То есть, в каких границах мы должны выполнить полностью всю работу, и какие функции должны включить сюда? Реализовать это в жизнь довольно сложно. В известном комиксе клиент обозначил свои пожелания, но руководитель проекта понял их совершенно по‑другому, потом подключился аналитик и спроектировал это решение, исходя из слов руководителя проекта, затем программист по‑своему понял задачу, а бизнес-консультант описал и вовсе собственную, далекую от других точку зрения. А вот в проектной документации была полная пустота, ничего недоступно. Потом рабочие установили совсем не то, что клиент ожидал.

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

Методические рекомендации, которые помогут вам реализовать проект в его рамках и получить успешную сдачу проекта. Программы выводят нас на более высокий уровень. Но в сложной программе работают обычно 200‑300 коллег, которые пытаются с вами двигаться в одном направлении — невозможно их всех усадить за один стол и всем вместе начать работать. Поэтому неформальная отчетность в таком коллективе не сработает, это работает лишь в маленьких коллективах. Чем больше коллектив, тем более формальным должен становиться из‑за увеличения объема и масштаба проекта или программы.

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

Когда есть ценностное предложение, это одно дело. Но иногда нужно копнуть глубже, чтобы выявить все требования. За этим идут ожидания от программы: чот она, в конечном итоге, позволит сделать? Дело в том, что вы не знаете в самом начале, что вам предстоит сделать, — например, пятилетняя программа будет или более продолжительная. Вы не знаете, что вас ждет в будущем, какие итерации последуют за вашими нынешними действиями. Но вы должны иметь определенные ожидания того, что может произойти в ближайшее и в более далекой перспективе, и подготовиться к этому. Чем дольше реализуется программа, тем непонятнее будущее, тем больше таких ожиданий у вас должно быть.

Потом вы должны определить конечный результат ваших ожиданий и конкретные показатели в границах проекта. С ними вы уже идете к совету директоров или к руководящему комитету и показываете им этот scope-statement, то есть выписку масштаба проекта. Помните, что в границы, масштаб, объем проекта всегда что‑то вмешивается. Это итеративный, изменяющийся процесс, поэтому часто требуется вернуться на начальные шаги. К примеру, меняются члены совета директоров, которые отвечали за все решения вначале. Кто‑то уходит из компании, приходят новые люди. И новый член совета директоров совсем ничего и не знает о том, что было раньше, и у него свое видение ситуации. И только по такой причине вам приходится уже быть готовыми к изменениям, запросам на изменения.

Управление объемом и масштабом проекта и программы

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

То есть вы должны определить участников панельного обсуждения — представителей этих 60 тысяч ключевых пользователей, которые будут озвучивать их совокупное мнение. О чем их спрашивать, понять просто. Потому что, какие ожидания? Ожидания простые. «HR goes cloud», «HR — в облако» — каково ваше видение этого решения, ожидания, роль в этой программе? После этого важно задокументировать, категоризировать их для того, чтобы было проще эту информацию читать, усваивать и достичь определенного согласия, выработать реалистичные ожидания. Программа — это вещь сложная, масштабная, она подразумевает информирование большого количества стейкхолдеров, так что всю документацию нужно четко собирать и использовать при необходимости.

Как связывать группы заинтересованных лиц. Есть группа, которая отвечает за стратегию компании — например, те, кто продает решения SAP или консалтинговые услуги, а также само программное обеспечение. Дальше есть бизнес-стратегия. Бизнес — работа с кадрами, у которых тоже есть стратегия работы в компании, а именно — развивать кадры, продвигать лучших сотрудников. Сама программа должна учитывать эти два параметра стратегии: корпоративную стратегию в целом и бизнес-стратегию, это позволит определить, выполняете ли вы требования. Помимо таких стейкхолдеров, как совет директоров, руководство компании, ваша проектная командатоже является очень важным стейкхолдером. Ваши клиенты в компании — проектные менеджеры от IT и менеджер программы, это тоже стейкхолдеры, ожидания которых нужно учитывать.

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

Опять же, в нашем проекте «HR goes cloud», мы не включали финансовую составляющую, потому что это был отдельный проект. Важно выбрать те, которые действительно нужны: то, что вы включите в программу, будет полностью под вашей ответственностью. Кстати, программы дифференцируются по двум аспектам. Например, независимые друг от друга проекты реализуются в рамках портфеля проектов — у них может быть разная дата вывода в эксплуатацию. И тогда у вас каждые два месяца — вывод в эксплуатацию. Сложности здесь следующие: если проекты зависят друг от друга, например, последний проект зависит от результатов предыдущего, в этом случае могут возникнуть проблемы. Есть другая структура — когда каждый проект должен целиться на одни и те же даты, на общие цели. Поэтому управлять ими довольно сложно, но помнить об этом нужно с самого начала и уметь эти проекты правильно согласовывать друг с другом.

Программа — это всегда большой масштаб и продолжительность. Если совет директоров заявляет, что вам предстоит в течение 5 лет руководить программой с бюджетом в 100 миллионов евро — скорее всего, у вас не получится 5 лет работать скрытно, а потом вдруг огласить результат. Такой бюджет подразумевает результаты, которые вы будете получать в процессе работы. Так что лучше сюда включить проект, который, может быть, к программе не относится впрямую, но позволит показывать результаты, например, спустя год, по системе quick win, «быстрая победа». Это нужно, чтобы успокоить заинтересованных лиц. Такие проекты политически важны, потому как такие вопросы в крупных программах — это очень важная вещь.

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

Потом вы приступаете к третьему шагу — определяете требования достаточно подробно. Это важный шаг, так как ваша команда специалистов собирает требования о бизнесе, но при этом они часто забывают о том, как команда будет это решать средствами информационных технологий. Если об этом забыть, то вы собираете слишком много требований и не сможете в результате создать универсального решения — того, что мы называем «серебряной пулей». IT-консультанты, когда выслушивают требования клиента, должны всегда думать о конкретном решении, которое может получиться из этих требований. Это определенное требование в определенной последовательности должно быть реализовано, иначе вы не поймете действительных требований клиента, и не сможете понять, как эти требования превратить в практическое решение. Ведь требования клиента (01:45:00) часто функциональные: как он хочет функционально использовать эту систему, чем она будет наполнена, с каким контентом она будет работать, какие технические требования, требования по удобству пользования — они вообще выходят на первый план сейчас. Я вижу, что многие наши решения становятся все лучше в этом аспекте тоже, и мы переходим на мобильную платформу, создавая приложения для iOS и Android — вопрос usability является очень важным в таких программах.

Ожидания. Как я уже говорил, в начале реализации программы много вопросительных знаков. Их нужно постепенно превратить в знаки восклицания, то есть реализовать все требования, ответить на все вопросы. Спустя 2‑3 года реализации программы вы должны вернуться к этим ожиданиям, к этим вопросам и проверить, исполнились ли они. Если они исполнились, это очень хорошо, значит, вы правильно спрогнозировали свое будущее. Но не лгите себе, будьте перед собой откровенны. Если не исполнились эти вещи, их нужно изменить. Это неплохой опыт — если ожидания не оправдались, это нормально. Нельзя предугадать будущее в пятилетней перспективе, совсем ничего в этом зазорного нет — скорректировать ваши ожидания спустя какое‑то время. Если вы не превратите эти вопросы в ответы, вы так в конце и останетесь с вопросами. Ничего хорошего в этом нет.

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

Результаты, критерии приемки.

Из-за отсутствия этих критериев проекты часто проваливаются. Потому что сначала нужно, конечно же, определить границы проекта, но после того, как вы все сделали в этих границах, нужно сделать отмашку и зафиксировать полученный результат. А если нет критериев приемки полученного результата, начинается беготня, но слишком поздно. Для меня критерий приемлемости — это то, что система имеет хорошую производительность. Что это значит? Именно это и нужно определить в каждом конкретном проекте. Иногда и время реакции 5 секунд может быть хорошим, и 2 секунды — недостаточным. Определитесь, пожалуйста. Иначе специалисты по бизнесу скажут: «Плохо работает система, потому что у вас не расписаны количественные показатели эффективности. А если их не расписать, то вы не сможете измерить по ним качество работы». Если требования изменились — вы можете обсудить это с клиентом и найти решение, например, в увеличении сроков, изменении границ проекта или бюджета. Так что на какие‑то уступки вы можете пойти с клиентом, но в результате обсуждения, защиты проекта и, конечно, после полной фиксации всех новых договоренностей.

Что говорят клиенты в этот момент? Вот