Павел Азгальдов – Проектное управление из первых рук. Как это на самом деле работает в крупном российском бизнесе (страница 3)

Что для меня важнее, задумался я: оставаться один на один с блестящей, но нереализованной идеей и считать себя непризнанным гением, или все-таки добиться результата, подойдя к воплощению идеи с другой стороны?

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

Лишь комплексный взгляд на проект позволяет найти ответы на важные вопросы. Где будет востребовано ваше изобретение? Кому оно полезно и какие проблемы решает? Что еще нужно, чтобы воплотить задуманное в жизнь? Я узнал, что такое календарное планирование проекта. Собственноручно созданный график стал моей первой значимой победой на новой стезе – и параллельно первым шагом к профессиональному управлению проектами.

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

Новая «оптика» – сквозь призму проектного управления – помогла мне иначе посмотреть на мир вокруг. В тот год в составе студенческого стройотряда я попал на площадку строительства Ростовской АЭС. И меня поразило, какой это грандиозный проект, сколько людей, процессов и дисциплин в нем задействовано. И мне захотелось самому заниматься реализацией таких проектов.

Однако попасть на работу в «Росатом» было непросто. Пропуском стала стипендия имени Эрика Николаевича Поздышева – легенды атомной отрасли, бывшего директора Чернобыльской атомной станции, взявшего на себя труднейшую задачу по управлению оставшимися энергоблоками после аварии 1986 года.

Я прошел конкурсный отбор и попал на базовую кафедру НГТУ имени Р. Е. Алексеева в АО «НИАЭП» (ныне – инжиниринговая компания АО «АСЭ»), где в течение года учился управлению жизненным циклом сложных инженерных объектов. Общение со специалистами базовой кафедры позволило структурировать знания в проектном управлении и вплотную заняться реализацией собственного проекта – организации производства дозиметров нового образца. Со многими экспертами кафедры мы дружим до сих пор, и их советы не раз помогали мне в профессиональных вопросах.

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

Я делал первые самостоятельные шаги в проектном управлении. Новый путь оказался, пожалуй, сложнее прежнего. Но мне он подошел.

Выводы:

1. Проектное управление способно принести плоды в любой отрасли, в любом деле. Не имеет значения, идет речь о строительстве АЭС или о внедрении небольшой научной разработки. Только оценивая инициативу с точки зрения проектного подхода, есть шанс успешно довести начатое до конца.

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

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

Приступаем к проекту: чего хотят стейкхолдеры?

Автор Станислав Кречетов

Когда я приехал в Екатеринбург из небольшого городка получать образование, я был уверен, что стану металлургом. Меня уже ждала работа на крупном предприятии и место на металлургическом факультете УПИ, нынешнего УрФУ. Но, как это часто бывает, проект «высшее образование» пошел не совсем так, как мне представлялось изначально: поступив в университет, я оказался на кафедре теплофизики и информатики в металлургии.

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

На одном языке

Стейкхолдер – это любой человек или группа, так или иначе заинтересованные в результатах проекта. Их интересы далеко не всегда одинаковы: одни видят ситуацию так же, как и вы, другие иначе. В любом случае проект стейкхолдерам небезразличен, они обладают правом голоса и, будьте уверены, в какой-то момент непременно им воспользуются.

Работа программиста в финансовой компании в то время была сложнее и ответственнее, чем сейчас. Не примите эту мысль за ностальгию по старым добрым временам. Все обстоит строго наоборот: если бы сегодня молодому и амбициозному айтишнику довелось очутиться в том времени, он бы по-братски проникся к нам сочувствием. На тот момент 95% программного обеспечения, которое использовалось в повседневной работе, было самописным: сотрудники компании создавали его под себя и свои нужды, руководствуясь исключительно личными представлениями о прекрасном.

Универсальное ПО только начинало появляться на рынке, стремительно его захватывая. Но, как любая высокотехнологичная новинка, оно было доступно не всем. Наша компания не стала исключением. На тот момент у нас была установлена старая система, разработанная прежней командой IT-отдела, и функционировала она по принципу «работает – не трогай». Работала она, увы, не лучшим образом. Но как мы ни старались, оптимизировать ее не получалось.

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

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

⠀

На одном языке

«Водопадная», или каскадная, модель обязывает разработчиков действовать строго по принятому плану, не возвращаясь назад. Работа в рамках каскадной модели состоит из пяти шагов: аналитика, проектирование, разработка, тестирование и поддержка. Пропускать этапы нельзя, как и возвращаться на предыдущие ступени, – точно так же, как вода в водопаде никогда не потечет в обратную сторону, вверх по скалам. Сегодня каскадная модель считается уже плохо применимой для разработки ПО.

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

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

Если будущие бенефициары нашего проекта не осознают своего счастья, придется вести их к нему самостоятельно – легкомысленно решили мы. Я стал разбираться в особенностях расчета налогов, работы депозитария и бэк-офиса, прикидывал, без каких функций нашему новому программному комплексу точно не обойтись, а какие, напротив, никому не понадобятся. Создав стройную картину грядущей удобной и быстродействующей программы, мы принялись воплощать ее в жизнь, а написав – с гордостью предъявили коллегам. И были просто в шоке, получив в ответ гигантскую волну недовольства.