Дорога к локальному счастью

Поднимая вопрос об ИТ-проектах, почти никто и никогда не говорит об одной очень важной составляющей, а именно о позиционировании проектов, причем проектов внутренних, касающихся внутреннего же потребителя. «А что тут говорить? И так все понятно — для вас же, потребителей, стараемся...» Но, к сожалению, не все так просто.

Для начала надо отметить, что почти никто, почти никогда, почти нигде (а особенно для внутреннего заказчика) не проводит никаких мероприятий по внутреннему пиару. Просто потому, что «проект и проект, что его пиарить, работу работать надо!» С одной стороны, это, конечно, так. И данная точка зрения весьма распространена среди айтишников. В лучшем случае проведут «по указке» презентацию для узкого круга избранных лиц — и все. Достаточно. То есть дальше, по идее, эти «избранные лица» должны донести до всех остальных крутизну, полезность и новизну предлагаемого решения... На деле же часто происходит так: айтишники устраивают чересчур «техническую» презентацию, в итоге получается, что те, кто что-то понял из представленного, начинают считать, будто «это все чересчур сложно», «это не для нас» или (в самом плохом случае) — «это не соответствует нашим процессам» (классическая фраза-отмазка, магически действующая на топ-менеджмент). Причем результат ИТ-проекта может быть сколь угодно хорош. И проблема тут не в результате, а в том, что «чистые» айтишники банально не умеют преподносить плоды своей работы. Потому что процесс порой интереснее результата, да и результат — вот он, на поверхности, смотрите, разбирайтесь... Знакомая ситуация?{PAID}

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

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

Тут надо сделать небольшое отступление. Я в некотором смысле сознательно сгущаю краски, поскольку, по моим наблюдениям, «хороший» сценарий реализуется примерно в 20% случаев; остальные 80% — именно те, о которых я говорил выше.

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

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

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

Что делать?

Что делать в ситуации, когда проект стартует, а вокруг — глухое неприятие? Для начала сказать, что уже поздно. И вернуться чуть назад. К той точке, когда была сформирована концепция и началась детальная проработка будущего решения. Потому что работать с «корпоративным бессознательным» надо уже как минимум в этот момент. Прежде всего надо получить поддержку ключевых пользователей, для чего их следует тем или иным образом ввести в рабочую группу. Кроме собственно «эффекта пиара» это позволит получить в проектной команде группу высокопрофессиональных экспертов, поскольку никто не знает лучше особенностей работы и процессов, чем ключевые бизнес-фигуры (и неважно, какую они занимают должность — основным критерием должен быть их кругозор и компетенции относительно работы и рабочих процессов). Далее, такое введение ключевых сотрудников в рабочую группу позволит обеспечить информационный эффект — система будет восприниматься ими не как «чужая», а как «своя». Со всеми вытекающими отсюда последствиями. В частности, о системе начнут рассказывать в ключе «что она может хорошего», а не «почему она плохая». Кроме того, если грамотно расставить акценты, то ключевые сотрудники (небезосновательно) могут почувствовать, что внедрение такого рода системы — это, вообще говоря, их заслуга и их шанс. Шанс выделиться, стать заметнее, научиться чему-то новому. В конце концов, просто шанс сделать карьеру. Или пройти еще одну ступеньку в карьерной лестнице. На самом деле такого рода стремление является нормальным и, будучи верно использованным, может принести свои плоды. В виде лояльно настроенных пользователей.

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

Вообще говоря, имидж проекта — это если не «наше все», то как минимум существенная часть. Дело в том, что, напрямую не относясь к решению, имидж способен творить чудеса. Приведу пример из собственной практики: внедрялось достаточно сырое решение, чьи перспективы оценивались как весьма туманные самой командой внедрения. Тем не менее на регулярных еженедельных планерках директор компании рассказывал, какую замечательную мы внедряем систему, что она даст и как поменяется качество работы каждого сотрудника с реализацией проекта. На планерках присутствовали начальники, которые доносили информацию о системе исполнителям (в большинстве не видя самой системы). Так вот, в конечном итоге после запуска системы она была принята пользователями настолько благосклонно, что на ошибки в ее работе просто не обращали внимания. Более того, система прижилась и благополучно работает уже около семи лет. За это время компания-разработчик вычистила баги, потеряла около 50% клиентской базы, нарастила ее вновь... Я все это к тому рассказываю, что грамотно поданная информация смогла сформировать верный настрой, который, в свою очередь, привел к тому, что система «пошла». А сколько хороших проектов оставалось в прототипе лишь из-за того, что по ним не было никакой информационной поддержки?

Возвратимся к вопросу о глухом неприятии. Казалось бы, нет хуже ситуации, когда проект не принимается абсолютно всеми, кроме, может быть, руководства. Но даже в этом, казалось бы, безвыходном случае, есть если не выход, то хотя бы определенный вектор движения. Я не большой сторонник применения административного ресурса, но это именно тот случай, когда его можно и нужно использовать. «Боржоми пить уже поздно, нужно хирургическое вмешательство». И таким вмешательством станет подключение «тяжелой артиллерии» в виде распоряжений, приказов, поручений и административной работы. Тут, как говорится, не до пиара — запуститься бы. Но в данном случае надо морально готовиться к тому, что запуск пройдет непросто.

Кто виноват?

Конечно же, руководитель проекта. Это такой штатный, универсальный ответ практически на любое происшествие на проекте. Тем не менее, строго говоря, не в компетенции и власти руководителя обеспечивать мощную пиар-компанию (да и вообще какую-либо пиар-компанию). На это есть отдельные, специально обученные люди. Потому что пиар и манипулирование общественным бессознательным, даже в рамках небольшого коллектива — это определенного рода искусство. Оно постигается не всеми и, к сожалению, в большинстве случаев недоступно «простым технарям», к которым, в большинстве своем, относятся руководители проектов.

На самом деле, если говорить о позиционировании ИТ-проекта, то виноваты, скорее всего, будут все понемногу. Руководитель проекта — в том, что игнорировал момент публичности проекта (в его силах акцентировать на этом внимание руководства с целью обеспечения информационной поддержки). Штатные пиарщики — в том, что не поддержали проект со своей стороны. Руководство — в том, что решило, что оно и так будет работать. В итоге получается некая цепочка, в которой каждый по отдельности вроде как и не виноват. А все вместе вроде как и виноваты, но виноваты потому, что каждый из действующих лиц «не осознал», «не понял», «не доглядел»... В итоге, как правило, не наказывают никого — потому что по большому счету наказывать не за что. Пиар проекта — это материя настолько тонкая, что слабо поддается как формализации, так и реализации. Как правильно пиарить внутренний проект? Кто это должен делать?

Как делать?

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

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

Во-вторых, информацию следует доносить всеми доступными методами (ну или теми, что не идут вразрез с корпоративной этикой).

В-третьих, в проектную команду всегда полезно включать представителей пользователей. Это поможет не только получению информации из «первых рук», но и быстрой обратной связи — как от членов рабочей группы, так и от их коллег. Кроме того, подобная группа создаст «информационное ядро», которое вольно или невольно будет проводить идеи проекта среди коллег.

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

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

В заключение...

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

Кстати, все сказанное выше следует отнести в первую очередь к проектам, которые так или иначе касаются конечных пользователей — например, проектов модернизации существующей системы, поставки новой системы и т. д. Все эти проекты относятся к внутренним — в том смысле, что они нацелены на конечного потребителя ИТ-услуг, вне зависимости от того, чьими усилиями (внутренними или внешнего подрядчика) реализуется проект. В противовес проектам для конечных пользователей, проекты сугубо внутренние, айтишные (типа модернизации сети передачи данных, переезда в новый ЦОД и т. д.), как правило, пиара среди пользователей не требуют — нет смысла пиарить то, что не видно большинству пользователей, то, что не на поверхности.

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