Управление проектом Руководителем проекта со стороны Заказчика

Меня зовут Павел Громов, я работаю в компании Инфософт руководителем департамента консалтинга и проектных внедрений. Иными словами, я – РПО, руководитель проектного офиса. Мы занимаемся крупными корпоративными проектами внедрений, в основном в производственных предприятиях.

 

 

Когда я заявлял доклад, меня спросили: «А почему доклад про управление проектом от имени РП со стороны заказчика? Ты же работаешь со стороны исполнителя, как ты вообще можешь про это говорить?»

Дело в том, что бОльшую часть своей профессиональной карьеры я работал на проектах как раз со стороны заказчика – внедрял достаточно большое количество проектов. Самые значимые перечислены на слайде.

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

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

И тут-то я все понял: оказывается, РП со стороны исполнителя – это всего лишь «помогатор», который львиную долю времени просто помогает заказчику. А РП со стороны заказчика – это самый главный ответственный на любом проекте.

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

 

 

В докладе я расскажу:

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

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

• Немного вникнем в тему сбора рабочей группы – посмотрим, кого брать в команду, в какой момент имеет смысл кого-то поменять, и стоит ли вообще это делать.

• Поговорим про бюджет проекта.

• И про саботаж.

 

Кто такой РП от заказчика?

 

 

Представим, что мы – представители интегратора.

К нам пришел заказчик и говорит: «Внедрите нам корпоративную информационную систему 1С:ERP».

Мы первым делом спрашиваем: «А кто будет руководителем проекта?»

Заказчик удивляется: «Зачем вам наш РП? Вы же приводите своего руководителя. Вы профессионалы. Внедрите нам информационную систему. А мы вам чем-нибудь поможем».

 

 

Т.е. «У нас нет своего РП» – это классический ответ от заказчика.

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

Поэтому мы на этом этапе сразу говорим: «Ребят, ищите РП-шника. Точно кого-то выделяйте, кто будет ответственным с вашей стороны. Без этого мы с вами точно работать не будем».

 

 

Кого чаще всего определяют? Кто самый незагруженный на предприятии? ИТ-шники.

ИТ-шники никогда ничего не делают – они только сидят в компьютере и играют там, наверное, в свои игры.

 

 

Есть много удачных примеров внедрения, когда РП на проекте – ИТ-шники, потому что у них есть определенные плюсы:

• ИТ-шники классно знают информационную систему.

• Они классно знают процессы предприятия.

• Они – ярые сторонники автоматизации.

• Они быстро разбираются в ПО.

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

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

• У них нет опыта управления другими подразделениями. ИТ-шники могут классно управлять ИТ-шниками – интеллектуалами, которые работают в сфере умственного труда. А представьте, как ИТ-шник будет управлять производственниками? Он попробует с ними говорить точно так же на языке логики – скорее всего, что-то пойдет не так.

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

Это негативные моменты.

Но есть и позитивный опыт – недавно мы завершили проект внедрения ERP на предприятии, где полностью всю роль внедрения взял на себя ИТ-шник. Просто ИТ-шник, даже не директор, даже не начальник отдела. Просто ИТ-шник, который все сделал сам:

• Сам организовал рабочие группы;

• Сам организовал выверку процессов;

• Где-то пересогласовал изменения процессов, чтобы не дорабатывать ERP.

• Отлично отработал все заинтересованные стороны – со всеми договорился, провел переговоры, у него все было здорово.

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

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

Поэтому у руководителей проекта из числа ИТ-шников есть и плюсы, и минусы. Если вы хорошо понимаете, как вы будете преодолевать минусы, у вас все получится.

 

 

Но, допустим, ИТ-шник не может, или нет ИТ-шника – он занят, загружен. Следующим в качестве руководителей проекта со стороны заказчика выбирают главбухов, ЗГД по развитию, ЗГД по экономике, топ-менеджеров. У нас был опыт, когда руководителем проекта был заместитель генерального директора по производству.

 

 

С такими руководителями проект становится намного интереснее, потому что у них есть плюсы:

• Эти ребята хорошо знают процессы.

• У них опыт управления и влияние на проект гораздо выше.

• Они гарантированно знают, как преодолевать сопротивление сотрудников, делегировать задачи и контролировать выполняемые действия.

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

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

Правда здесь есть тонкие нюансы, которые написаны на слайде в части недостатков:

• Например, лоббирование своих интересов. Был опыт, когда заместитель генерального директора по производству в одном из проектов, внедряя информационную систему, весь упор делал на автоматизацию производства. На регламентированный учет ему смотреть было не очень интересно. Ему казалось, что это же всего лишь проводки по плану счетов, и ничего там сложного нет. Главный бухгалтер был против такой позиции. И возник достаточно серьезный конфликт. Ребята недовнедрились. Пришлось рег. учет перевнедрять. Стоимость проекта сильно выросла. Да, разобрались, внедрили. Но у нас получился не очень успешный проект. Поэтому, если вы поставите какого-то топа управлять проектом, скорее всего, он будет переоценивать значимость своего блока, за который он несет ответственность, и недооценивать значимость других блоков.

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

 

 

Следующая роль – это внешний наемный специалист.

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

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

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

 

 

Допустим, нам повезло.

• Мы нашли классного РП-шника с опытом внедрения.

• У него, естественно, не будет текущей оперативки.

• Он будет 100% замотивирован на внедрение проекта – это будет его основная цель внутри этой компании.

Но:

• Он не знает процессов компании – внимательные уже обратили внимание, что я это записал и в плюсы и в минусы. Сейчас объясню, почему.

• Он не знает людей,

• Его никто не знает. Т.е. он не знает, как работать с сопротивлением. И баланс сил он тоже не понимает.

Теперь давайте объясню, почему для внешнего специалиста процессы компании – это одновременно плюс:

• Нам, интеграторам, часто говорят: «Вы же, когда будете внедрять у нас систему, увидите у нас в процессах какие-то разрывы и скажете нам, как что поменять». В ответ мы говорим: «Мы, конечно, можем увидеть разрывы в целом и сказать, чем вам можно помочь, но по большому счету вам лучше самим смотреть на моменты разрывов именно на модели».

• А наемный специалист, выполняющий роль РП от заказчика, свежим взглядом взглянет на процессы изнутри компании и сможет предложить какие-то значимые изменения.

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

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

Еще раз повторюсь – РП может быть любой. Он может быть как ИТ-шником, так и ЗГД по экономике, так и главным бухгалтером, так и внешним специалистом. У нас большой опыт внедрения и взаимодействия – мы на разных предприятиях проверяли: РП может быть любой. Если вы хорошо знаете, как закрыть возможные минусы – у вас все получится. Точно, гарантированно, проверено много раз.

Главное понимать – РП со стороны заказчика несет главную ответственность за проект. Все остальные помогают. РП со стороны исполнителя много помогает – у него тоже большая ответственность. Но главный – РП от заказчика.

После того как мы определили РП, отработали минусы, все понимаем, знаем, на какие грабли можем наступить, нужно определить – что в первую очередь делать РП-шнику со стороны заказчика.

 

С чего начать? Заинтересованные стороны

 

 

Первое, что должен сделать на проекте РП со стороны заказчика – это определить заинтересованные стороны:

• всех, кому этот проект интересен;

• и тех, кому он не интересен;

• кто будет сопротивляться;

• кто будет вам помогать;

• а кто будет оплачивать все это дело.

 

 

Какие бывают заинтересованные стороны.

• Все мы знаем ЛПР – лица, принимающие решения. Кроме них еще бывают ЛДПР – лица, действительно принимающие решение – мы все любим эту шутку :)

• Еще есть ЛОР – лица, оплачивающие решения.

• ЛЛР – лица, лоббирующие решения.

• ЛПодР – лица, подписывающие решения.

• ЛИР – лица, исполняющие решения.

• ЛВР – лица, влияющие на решения.

• ЛИП – основные поставщики информации.

• И ЛНЗР – лица, которые не заинтересованы в принятии решения. Кстати, это очень важные ребята, на них есть смысл обращать внимание.

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

 

 

Что с ними дальше делать? Перечень заинтересованных лиц нужно хотя бы систематизировать. Для этого есть инструмент «Карта заинтересованных сторон». Я узнал о ней только у интегратора. Знал бы раньше – использовал бы, потому что не раз попадал на том, что кого-то не учитываю.

Карта заинтересованных сторон – документ из СМК, он прописан в системе менеджмента качества. Его форма может меняться, но самое главное – здесь зафиксировать:

• ФИО человека.

• Какая у него должность в компании.

• Его роль – там обычно прописаны возможные роли, плюс вы можете свои придумать. Например, на одном проекте у нас была роль «любимая жена генерального директора» – ровно потому, что данный сотрудник имел в проекте очень высокое влияние.

• Объективные потребности – что человеку нужно от проекта.

• Субъективные потребности – какие у человека могут быть потаённые интересы от проекта.

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

• И описание личности мы обычно делаем, чтобы лучше понимать личность.

Руководителю проекта со стороны заказчика можно не заполнять описание личности, ему достаточно заполнить три колонки – две колонки потребностей, и «Сомнения и опасения».

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

На слайде – небольшая карта заинтересованных сторон. Обычно они намного больше. Это карта с проекта внедрения ERP в крупной компании, которая оказывала сервисные функции для небольшого городка. В компании было очень много разных видов бизнеса – и электроподстанция, и ЖК-шки, и ассенизаторы. И там генеральный захотел внедрить информационную систему. Он был главным сподвижником проекта – и спонсор, и инициатор, и куратор в одном лице. А руководителем проекта назначили консультанта по юриспруденции.

Проект шел идеально – внедрили ERP и еще кучу сторонних программ. Все отлично запустилось и шло к завершению.

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

 

 

Поэтому, после того как вы карту заинтересованных сторон нарисовали, нужно представить проект в виде бочки и понять: кто вам проект помогает делать; а кто – мешает. Кто ваш сподвижник? А кто – противник?

 

 

И для этого есть классный инструмент «Анализ поля сил». Это табличка, сделанная в Excel, где написан небольшой макрос, который увеличивает эти стрелочки – их удобно оценивать для визуального восприятия. А остальное тут – это просто формулы.

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

В данном случае мы как раз зафиксировали итоговое состояние по проекту.

• Изначально тут было зелененькое – 2, 5, 7 в плюс.

• До тех пор, пока не появилась главбух, и мы не накосячили с обменами – сразу стало минус 2, и нам стало категорически сложно двигать проект дальше.

 

 

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

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

Вы всех действующих лиц фиксируете в этой табличке. Здесь есть колонки, которые характеризуют приверженность к проекту:

• Противодействует = -2;

• Сопротивляется = -1;

• Безразличен = 0;

• Участвует = 1;

• Привержен = 2;

• Вдохновляет и ведет за собой. = 3

И согласно этим значениям оцениваете влияние заинтересованных сторон в анализе поля сил.

 

Вам нужно проработать стратегию – что сделать, чтобы эти оценки сдвинулись вправо. Чтобы ваше поле сил изменилось на поле сил, которое ведет проект дальше, помогает вам его делать.

Этот документ тоже живой.

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

 

Кого взять в команду? Рабочая группа проекта со стороны заказчика

 

 

Про инструменты. Мы разработали план проекта и продумали стратегию работы с заинтересованными сторонами. Теперь поговорим про рабочую группу проекта. Кого брать в команду?

• Сначала нужно сформировать какую-то базу – набрать из структурных подразделений того, кого дают. Просто сформируйте первый список.

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

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

• Тут очень важно помнить про лояльных и заинтересованных. Любой токсик внутри проектной команды, будь он сто крат офигенным профессионалом, завалит весь проект. Он будет просто разрушать синергию внутри классной группы. И они не будут хотеть даже высказать свое мнение. Такое периодически происходит. У нас был опыт – мы внедрялись на предприятии, запускали производственный контур. И там один из начальников цехов – толковый молодой парень. Суперклассный. Его взяли в рабочую группу, но ему не нравилась новая система. Она заставляла его делать то, что нужно делать, а он любил делать детали, на которые тратил мало времени, но получал с этого большую зарплату. В итоге, когда провели инвентаризацию, выяснилось, что этих деталей сделано на 10 лет вперед. И когда он понял, к чему ведет новая система, то начал сопротивляться. Саботировал достаточно серьезно.

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

 

 

Дальше важный момент – что делать с командой, которую вы собрали, кого-то там заменили. Как поддерживать уровень заинтересованности в проекте внутри команды? Как двигаться дальше?

Разработайте систему мотивации и защитите. Разработать просто, сложно защитить систему мотивации.

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

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

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

• Завершили этап моделирования – небольшая премия.

• Этап проектирования – следующая премия,

• Этап разработки – следующая, и так далее.

И в момент, когда вы передали систему в промышленную эксплуатацию, вы выплачиваете оставшийся фонд – это половина от всей суммы премии.

• Во-первых, это мотивирует специалистов на успешное закрытие этапа – на незатягивание сдачи документов, на незатягивание проверки разработки.

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

Причем когда мы предлагаем коллегам систему мотивации, они на нее обычно накручивают какие-то свои KPI, показатели, коэффициенты, которые приняты у них в компании внутри. Но основная логика именно такая.

«Своевременно подавайте заявку на согласование премии». Мы сталкивались с тем, что коллеги защитили систему мотивации, защитили премии и забыли про это – вообще не подавали, не начисляли. Только когда уже в конце разработки спросили: «А где премия-то, когда ждать?» – осознали и доначислили с какими-то нюансами.

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

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

Допустим, внедрили ЗУП, наградили всех, кто там участвовал – расчетчиков, зарплатчиков, персональщиков, начальника отдела кадров.

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

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

Это очень важный момент – если вы не делаете это внутри компании, обратите на это внимание.

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

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

 

Как сэкономить бюджет проекта?

 

 

Теперь давайте поговорим про бюджет.

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

Но в какой-то момент мы начали сталкиваться с тем, что спецы хотят старую систему запилить в новой – УПП запилить в ERP. Или Oracle запилить в ERP. Прям сплошь и рядом. Всем это интересно.

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

У фирмы «1С» есть классная концепция прикладного решения. Обучите их этой концепции. Расскажите, что она вообще умеет, какая у нее логика работы, как в фирме «1С» решили те или иные проблемы в этом программном продукте.

Покажите, обучите. И желательно, чтобы они еще сами контрольный пример протыкали в 1С и поняли, как это все проходит целостно.

Результатом этого обучения вы увидите кардинальное сокращение требований. Прям значимое.

Конечно, вы не должны отказываться от разработки АРМ – удобных обработок, которые упрощают заполнение каких-то документов. Такие требования нельзя игнорить ни в коем случае.

Но благодаря обучению сокращаются доработки по созданию новых документов, аналогичных существующим документам ERP, о которых люди просто не знали.

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

 

 

Конечно, такие требования все равно будут. Это будет огромное количество требований.

 

 

И все эти требования нужно фиксировать. О них ни в коем случае нельзя забывать, откладывать, замалчивать.

Особенно нельзя замалчивать, потому что специалист, чьи требования начнут замалчивать, перестанет их озвучивать.

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

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

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

Какие будут колонки в этой табличке – сами решайте. Но обязательно должны быть колонки:

• Согласование.

• Стоимость доработки – суммы я здесь специально замазал, но такая колонка обязательно должна быть.

• Приоритет.

• Дата регистрации и Дата сдачи.

 

 

Как оценивать приоритет доработок? Во всех проектах приоритет любой доработки: «Максимально срочно», «Максимально важно», «Горит!», «В самую первую очередь», «Точно делаем».

Есть замечательный инструмент MoSCoW. Это матрица требований, которая помогает принять решения. Она делится на четыре слова:

1. Must – самое важное, то, что мы точно должны сделать.

2. Should – то, что нам стоит сделать. Тоже достаточно важные дела, но сначала делаем самое важное.

3. Could – то, что можно сделать, а можно в принципе и не делать.

4. Won’t – то, что делать точно не нужно.

Лайфхак здесь такой:

• Если вы думаете, что выбрать между 1 или 2, точно выбирайте 2.

• Думаете, что выбрать между 2 и 3, точно выбирайте 3.

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

А оценка стоимости доработки очень хорошо позволяет вам эти приоритеты выставить.

 

 

Что еще очень важно обязательно сделать на проекте?

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

• В разработке применяйте гибкие методологии. Не делайте разработку сразу всю. Делайте маленькими частями на основании приоритетов. Это позволит вам не работать «в стол». Потому что чаще всего требования в процессе приемки разработки меняются. Мы что-то разработали, пользователь посмотрел и понял, а он на самом деле хотел немного другого. И нам приходится перерабатывать. И чем меньше мы будем перерабатывать, тем меньше будет стоимость общей разработки, тем меньше мы наработаем «в стол».

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

Расскажу пример. Производственное предприятие, блок ОТК.

Когда ERP 2.5 только вышла, блока ОТК в ней не было вообще, а нам на проекте он был нужен. И мы начали разрабатывать его с нуля.

Через полгода фирма «1С» выпускает блок ОТК такой же, как придумали мы – видимо, на поверхности лежало. Наверное, нам не надо было тратить достаточно большое количество времени разработчиков и аналитиков, чтобы пилить этот блок. А лучше было бы узнать где-то о планах 1С и согласиться их подождать, а пока оформлять контроль какими-то другими документами. Потом мы бы просто применили этот блок в работе и сэкономили бы в проекте.

Но мы не проследили, и столкнулись с тем, что нам придется отменить наш блок ОТК и перейти работать в типовой блок ОТК ERP. Такой себе момент.

Пришлось очень долго объяснять заказчику, почему мы так не сделали. Объяснили, но, тем не менее, лучше на такие разговоры не попадать.

 

Саботаж. Работа с сопротивлением

 

 

Для работы с сопротивлением у нас есть матрица «Влияние – интерес».

Зависимость очень простая:

• Снизу вверх ось влияния на проект – чем выше позиция в матрице, тем влияние выше.

• А слева направо ось интереса к проекту – чем правее, тем выше интерес.

 

 

Накидываем сюда нашу карту заинтересованных сторон и смотрим – с кем нужно работать в первую очередь:

• У секретаря влияние на проект категорически маленькое, но интерес очень высокий. Нужно ли вообще тратить время на работу с секретарем? Скорее, да, но очень мало – его нужно просто держать в курсе. Ему нужно говорить, что проект двигается так, в нем будет такая функциональность.

• Львиную долю времени, порядка 60-70% нужно тратить на ребят, которые находятся в верхнем правом квадрате. Нужно очень внимательно следить за их интересами и требованиями, чтобы вовремя их удовлетворять.

• А те, кто находится в верхнем левом квадрате – у них интерес не очень высокий, им нужно просто поддерживать текущий уровень удовлетворенности. Но времени на них тратить нужно тоже не очень много – ребята просто должны быть удовлетворены.

 

 

При работе с сопротивлением:

• Ориентируйтесь на матрицу «Влияние – Интерес».

• Ни в коем случае не забывайте про сторонников. Это так называемый «принцип невесты» – когда, чтобы добиться девушку, парень тратит огромное количество сил, денег, эмоций, времени. А когда она становится его женой, он сразу расслабляется: «Она уже моя жена. Больше не надо вкладываться, она и так рядом». При работе с заинтересованными сторонами РП-шники очень часто совершают эту же ошибку: «Он уже на моей стороне, с ним уже все в порядке. Зачем мне на него тратить усилия – я пойду добиваться тех, кто находится в первом, втором, третьем квадратах». Это ошибка. Не стоит этого делать. Нужно поддерживать заинтересованность сторонников – тех, кто уже на вашей стороне.

• Помните о правиле 10-80-10. Это правило стандартного распределения: из 100%, 10% – всегда противники. 10% – всегда сторонники и 80% – всегда нейтралы. Конечно, не всегда, но в подавляющем большинстве случаев примерно так и происходит. Но эти 80% нейтралов, всегда придут на сторону тех, кого будет больше. Поэтому, если у вас вдруг станет 15% противников, эти 80% переедут в эти 15% противников, и у вас не получится критическую массу собрать, чтобы проект случился. Будет критическая масса, чтобы полностью противодействовать проекту. И это не только в проектной деятельности, это везде так.

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

 

Выводы

 

 

И в заключение – немного о розовых пони и единорогах.

• Доверяйте. На круглом столе по управлению корпоративными проектами один из участников спросил: «А как мне довериться интегратору? У нас очень много требований. Я не могу никому довериться, а вдруг они меня подставят?» Вы просто доверьтесь.

• Намного проще строить доверительные отношения изначально. Не сразу относиться к человеку, как будто он тебя обманет или подведет. А по умолчанию – доверять, строить доверительные отношения.

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

Может быть, я ошибаюсь, но это мое мнение.

 

 

И напоследок – очень важные слова, которые сказал замечательный человек со слайда, которого все знают, Чингисхан:

Боишься – не делай, делаешь – не бойся, не сделаешь – погибнешь!

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".