Внедрение «больших» организаций как Проект

Автор: Наталья Владиславовна ОБРЯДИНА, руководитель проекта

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

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

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

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

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

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

Затем необходимо предложить организации Заказчик выделить одного сотрудника – это самый наилучший вариант - для связи с вами. Таких людей может быть и несколько, что также неплохо. Вам необходимо оговорить с ними способы связи: телефон, мессенджер – какой именно, электронная почта, иное: интернет-ссылки Google Chrome или Trello, Skype. Время и частота связи. Это очень важно. И вы всегда должны быть доступны для этих людей – это будут правила вашего хорошего тона.

2.    Затем вам необходимо узнать ожидания этих людей. 

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

3.    Под кейсы, что вы записали – вам уже можно\нужно подбирать команду!

«Кушать Слона – необходимо по частям»! Кейсы должны быть разделены максимально подробно, обычно указывают бухгалтерские участки, которые необходимо внедрять, и под каждый – необходим\мы сотрудник\сотрудники, который\ые смогут осуществить и реализовать задуманное. Члены команды – это сотрудники двух сторон. Их фамилии, имена, отчества, телефоны для связи также отражаем в документе Устав проекта внедрения. А так как команда у нас работает по методологиям Agile, состав может\должен быть максимально гибким, возможным к замене одного сотрудника другим. Менее опытные сотрудники подхватывают результат труда более опытных, разгружая их тем самым для более сложной работы. Одна из главных задач любого проекта – повышение квалификации собственных сотрудников от проекта к проекту, как hard skills, так и soft skills. Также необходимо обязательное использование смешанных вариантов работы – физическое присутствие в организации и работа удаленно. Происходит колоссальная экономия человеческих ресурсов собственных сотрудников.

4.    Кейсы\участки написаны, команда подобрана - необходимо определяться и закреплять договоренности!

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

5.    Основные продукты проекта, это тоже важно.

Вы четко должны понимать: ЧТО будет являться результатом ВАШЕЙ работы и результатом работы ВАШЕЙ команды в процессе выполнения и завершения проекта. Примеры возможного:

1.       Переход в модуль УБУ всех участков Заказчика. Т. е. основная цель достигается.

2.       Обратная связь от сотрудников Заказчика и Исполнителя. Т. е. у вас появляется новейший опыт в коммуникациях.

3.       Опыт работы по agile методологии. Т. е. у вас появляется более новый опыт работы несколько по-другому.

4.       Опыт использования интернет-ссылки Google Chrome или Trello, Viber, телефонной связи, эл. почты  для организации и управления запросами проекта. Здесь вообще множество различных «девайсов», которыми вы научились управлять.

5.       Накопление личного опыта при создании команды. Дополнительный и более новый Мега- опыт, больше добавить нечего.

Это все то, что можно будет «увидеть», «услышать», «потрогать», «ощутить», и …измерить.

6.    Мы незаметно подобрались и с самому важному и самому сложно-ощутимому. Критерии приёмки.

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

1.     Перенос остатков из предыдущей системы Заказчика в ПО «УБУ 8» в необходимом Заказчику объеме, с учетом технических возможностей Исполнителя.

2.     Подписание Положительного отзыва для участков «Заработная плата», «Бухгалтерия», переход на АО по этим модулям (для Заказчика).

3.     Завершение работы в стороннем ПО (для Заказчика) .

4.      Выполнение всех критически важных задач, записанных от Заказчика  в «ИСБ» ( CRM система Исполнителя).

После наступления таких вот событий и можно будет сообщать – работа по проекту выполнена в полном объеме!

7.    Предварительные требования к продуктам проекта – обязательное описание бизнес-требований организации Заказчик, которые вы собираетесь осуществлять.

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

8.    Самое интересное и, возможно творческое, – это этапы реализации проекта.

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

Какие этапы в текущем проекте на дату публикации у нас уже осуществились? Про «Слона» - мы узнали, поговорили со всеми заинтересованными лицами, определили средства коммуникаций, стали общаться, узнали их ожидания, предложили свои варианты реализации, оговорили планируемые сроки, разделили задачи на кейсы\участки, почти сформировали замечательную команду, определили ответственных за каждый из кейсов\участков, начали двигаться вперед.

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

Продолжу рассказывать о последних частях проекта внедрения.

9.    Допущения проекта. Это то, на что вы надеетесь и считаете вполне возможным для возникновения.

Примеры возможного:

1.     Работа в модуле УБУ будет положительно воспринят сотрудниками организации Заказчик.

2.     Сотрудники организации Заказчик будут стабильно работать в модуле УБУ. Незамедлительно давать обратную связь по использованию ПО.

3.     Опыт сотрудников обеих сторон будет постепенно накапливаться.

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

5.   Возможны некоторые доработки ПО или создание некоторого дополнительного\вспомогательного функционала, требующего продвижения проекта вперед, который не создаст конфликтов для работы текущего функционала, будет описан, согласован и выполнен.

10.    Ограничения проекта – это то, за рамки чего вы не можете\не должны выйти\выходить никогда.

Примеры возможного:

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

11.    Первичные риски и предложенные решения. Что такое «риск»?

У Тома ДеМарко очень хорошо выведено определение «риска», точнее «незапланированного задания». «Незапланированное задание, которое запустилось – это событие, о котором вы просто не знаете и не знаете, что делать в случае его наступления», - Том ДеМарко "Вальсируя с медведями" - книга об отношении к рискам.

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

"Избегать рисков - дело проигрышное. Раньше вы могли бы отнестись к проекту, свободному от рисков, как к неожиданному подарку судьбы и благодарили бы звезды за эту редкую удачу - легкий проект. Мы реагировали так же. Какими глупцами мы были! Проекты без риска - удел неудачников.

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

Я приведу ниже некоторые примеры, к чему, например, готова я при реализации подобного проекта:

1.       Переход в УБУ организация Заказчик считает невозможным (смена руководства, и др.). – Предусмотреть возможность мгновенного реагирования. Убеждать и договариваться с Заказчиком, напоминая об огромной проделанной работе, потраченных ресурсах (человеческих, денежных), договорных обязательствах сторон.

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

3.       Отказ сотрудников организации Заказчик от освоения новых навыков. – В этом случае срочный диалог с заинтересованным лицом организации Заказчик.

4.       Отказ собственных сотрудников от освоения новых навыков. – В этом случае срочный диалог с заинтересованным лицом собственной компании.

5.       «Истерики» у сотрудников о невозможности: вообще достигнуть поставленных целей, завершить начатое, получить хоть какой-нибудь результат, причем с обеих сторон, или подобное. – Личный пример и общение – уравновешенность и твердая убежденность в достижении заявленного, спокойствие, приветливость, улыбка на лице и, желательно, блеск глаз, спокойный голос, твердость духа и излучаемая доброта. Это еще называется «харизма».

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

12.    Критерии успешности проекта.

Если все пункты, описанные в разделе 6 данной статьи, записанные вами и согласованные с заинтересованными лицами, - стали реальностью, – можно смело сообщать: «Переход ПО всех заявленных участков организации Заказчик в УБУ состоялся без необоснованного роста бюджета, с выполнением указанных требований и в полном объеме!» Проект завершен успешно.