Конструктор альтернативной реальности
Мы меняем мир. А он меняет нас. Для меня этот процесс — вечный принцип единства и борьбы противоположностей, инь и ян. Обмен энергией и движение вперед.
Я расскажу несколько историй из жизни, так или иначе связанных с изменениями — себя, продукта, подхода. Истории вроде бы банальные и очевидные, но несущие определенный посыл. Их можно рассматривать как истории успеха или как источник опыта, а можно попытаться понять: А что было бы, если бы не произошли описанные изменения? К чему бы это привело? Словом, можно поработать этакими конструкторами альтернативной реальности...
История продажи одного проекта
Зачастую бывает так, что вещи остаются прежними. Но изменяемся мы и, уже с новой точки зрения глядя на окружающие нас предметы, меняем их. В качестве примера хочу рассказать историю одной продажи. Компания, где я когда-то трудился, продавала очень нестандартный проект. «Нестандартность» заключалась в том, что кроме заказной разработки ПО был предусмотрен совершенно необходимый блок консалтинга, потому что программное обеспечение должно было автоматизировать спроектированные процессы. Для описания процессов компания наняла внешних консультантов. Их деятельность представлялась всем сотрудникам чем-то эфемерным: пришел, помахал бумажками, нарисовал некие «типовые» процессы... а основной груз всё равно тянет команда разработки — у них-то «настоящее дело». К сожалению, эта позиция заразила даже менеджера по продажам, который на внутренних совещаниях стал придерживаться мнения «за что столько денег бездельникам». Переговоры между тем шли своим чередом, не приводя ни к какому результату, хотя заказчик был весьма заинтересован в продукте, а исполнитель — в контракте на проект. Наверное, так могло продолжаться долго. Но в один действительно прекрасный момент кто-то из руководителей исполнителя сначала пообщался с глазу на глаз с менеджером по продажам, а потом пошел на очередной тур переговоров. В отличие от многих коллег он был уверен, что хороший результат работы консультантов — залог общего успеха проекта, потому что невозможно автоматизировать то, чего нет (процессы у заказчика явно были не выделены). Исходя из этого, он и построил разговор с заказчиком. Неудивительно, что именно на той встрече договор был согласован принципиально, чуть позже — утвержден, подписан и принят в работу.
Что изменилось в ходе тех переговоров? По большому счету — ничего. Кроме одного: уверенности и взгляда с другой стороны (изменение переговорной позиции по отношению к исполнителю). Пришедший на встречу руководитель был уверен в том, как именно надо делать. Именно уверен, без альтернатив и сомнений. Менеджер же по продажам считал, что его задача продать «систему с обременением», не рассматривая консалтинг как существенную часть проекта. Словом, в данном случае от точки зрения зависело ни много ни мало, а судьба достаточно финансово привлекательного проекта. Кстати, в итоге он был успешно сделан, принят на поддержку, затем получил неожиданное развитие. А в «самом итоге» — довольный заказчик.
История разработки
Большая и хорошая компания, специализировавшаяся, в частности, на доработке редкого софта для клиента, традиционно использовала водопадную модель. Все было хорошо, пока компания не победила в тендере с достаточно абстрактным техническим заданием, ну а чтобы жизнь совсем не казалась медом — оно было еще и приложением к договору. В договоре же отмечалось, что ТЗ «спущено в производство», после чего стало очевидно: по «водопаду» работать не получится. Причем не получится совсем, при любых допущениях. Соответственно, было решено — сначала для этого проекта, а потом и для остальных — внедрить новую модель, некий гибрид «водопада» и гибких методик. То есть весь объем техзадания «нарезался» на несколько больших этапов, внутри которых устанавливались двухнедельные спринты. Было сформировано несколько команд — одна проработала ТЗ, другие обеспечивали выпуск четных и нечетных микрорелизов спринтов. Причем каждая из команд работала в тесном контакте с заказчиком. Итогом каждого микрорелиза становился законченный раздел функционала, который клиент мог посмотреть и протестировать.
Такая перестройка потребовала определенных реформ и в ландшафте разработки. В частности, была внедрена модель непрерывной интеграции (модный ныне DevOps), автоматизировано тестирование по основным операциям (доля ручного регресс-тестирования не превышала 20% их общего объема, причем тестировались нетривиальные ситуации). Вся новая функциональность, естественно, испытывалась вручную.
Что в итоге? В результате изменения получилась гибкая система, позволявшая, с одной стороны, обеспечить выполнение взятых на себя обязательств, а с другой — обеспечить высокий темп и приемлемое качество их исполнения.
История поддержки одного сервиса
Представьте компанию, которая профессионально занимается разработкой и поддержкой некого ИТ-сервиса. Сервис достаточно специфичен, соответственно, конкуренция невелика — на момент происходящих событий всего 5–7 компаний на Россию. Спрос устойчивый, но растущий медленно — именно в силу специфики бизнеса. Поддержка работала соответственно — чуть вальяжно: «А куда спешить? Они же и так наши, и идти особо некуда». Спрос значительно опережал предложение. Но в один момент изменилось если не все, то очень многое: на рынок пришел крупный игрок и для него данный сервис был второстепенным. С соответствующим ценником. Это был вызов. Без преувеличения. Бизнес, который еще вчера чувствовал себя практически по-царски, сегодня вдруг оказался под угрозой закрытия. Клиенты получили хорошую альтернативу и начали «голосование кошельком». За два месяца компания потеряла около 20% заказчиков. И это оказалось сильной и очень неприятной встряской. Фактически перед руководством возникла необходимость проведения срочных изменений. Проблема заключалась в том, что отсутствовало четкое понимание, что и в каком объеме менять и каковы гарантии. Примерно тогда же в компанию пришла команда, специализирующаяся на оперативных изменениях и антикризисном управлении. Был разработан план, где «мероприятием №1» значилось изменение отношения к клиенту. Это, наверное, оказалось самым сложным изменением из всех, в которых мне приходилось принимать участие. Сотрудников техподдержки пришлось переобучать, а частично — менять. На второй и третьей линии был организован институт «надзирающих» (официально они назывались иначе, но суть именно такова). Все это создавало достаточно нездоровую атмосферу в коллективе. Командообразующие мероприятия не работали. Сотрудники начали подходить к выполнению своих обязанностей формально. Была пересмотрена мотивация — введены поощрения за получение положительной обратной связи от клиентов и перераспределена функция ответственности, ответственным представителем клиента стал сотрудник первой линии. Благодарности от клиента при этом «пропорционально» делились между всеми задействованными сотрудникам. Аналогично «делились» и жалобы. Кстати, и благодарности, и жалобы рассматривались перед тем, как их «овеществить». Одновременно был пересмотрен подход к финансовому планированию, в частности, сформирована себестоимость как основной, так и дополнительных услуг, и на этой базе сформирована новая рыночная цена на сервис. Основные преобразования растянулись на полгода, а в целом проходили около полутора лет. За этот период компания обновила свой состав примерно на 60%, полностью изменила бизнес-процессы и подход. Чего это стоило руководству и собственникам — можно только догадываться.
Немного грустное про хантинг
Однажды я, завершив проект, искал чем заняться (лет 10 назад было дело). На меня вышли сотрудники одного кадрового агентства, предложившие работу... ну почти по специальности. В ключевых требованиях отмечалось хорошее знание некой АИС (на уровне логики и работы), которую я не знал. Собеседование — завтра. На мои резонные возражения о целесообразности подобной встречи — предложили выучить «по Интернету». Разумеется, так поступать я не стал, а, готовясь к встрече, постарался обозначить свою позицию: тут сильные стороны, это не знаю, но, судя по описанию вакансии, на мой взгляд оно и не надо. Интересно, что собеседование я прошел, более того — убедил представителей работодателя в правоте собственного видения. Затем состоялось еще одно собеседование, по итогам которого мне предложили работу, от которой я отказался, поскольку получил другое, более интересное предложение.
Почему я вспомнил об этом в общем-то банальном эпизоде? Потому что на его примере можно проследить несколько любопытных изменений. Первое: мне предложили провести экспресс-изменение навыков. Я отклонил это изменение: ни по срокам, ни по содержанию оно мне не подходило. Второе: я подготовил встречное, более интересное изменение — изменение контекста, для чего обратился к первоисточникам (требованиям вакансии) и сформировал стратегию переговоров (хотя тогда я еще не знал, что это так называется). То есть изменил условия задачи у себя в голове в сторону, как мне казалось, более правильную в текущей ситуации (да, пришлось принять на себя нелегкое бремя оценки реальности). Изменение собственной позиции и своей возможной роли по отношению к требованиям вакансии привело к тому, что у меня появилась внутренняя уверенность в собственной правоте. А «работать» на переговорах, придерживаясь такой позиции, значительно легче и эффективнее.
Напоследок: коротко и про свою волну
Важным условием успешности изменений является мотивация тех, кто их проводит и в них участвует, а также заранее определенные критерии успеха этих самых изменений. Помните Портоса с его бессмертным «я дерусь, просто потому что дерусь»? Так вот, «это не наш метод», по крайней мере в мире изменений — точно не наш. Изменение обычно достаточно структурировано: у него есть причина, побудительные мотивы, есть заинтересованные лица, «тело» (описательная часть того, что и на что меняем), есть финал и постмониторинг. У него есть и ограничения: время, бюджет, ресурсы (в этом смысле оно как проект, да, по сути, и является особым видом проекта). У изменения есть своя команда, и роли в ней. Есть драйвер, часто он же — РП проекта изменения, есть аналитики, тренеры, если изменение тесно связано с предметной областью, то и эксперты. Ну и «вишенка на торте» — у изменения есть определенное окружение. Все это надо учитывать, со всем этим работать (и жить). И потому так важно то, чтобы драйвер изменения был полностью в контексте как того, что меняем, так и самого изменения. Важно, чтобы эту уверенность он транслировал в мир, выступал одновременно евангелистом и проектным руководителем. Важно, чтобы он имел безусловный настрой на победу и решение всех сложностей. Словом, был на своей, особой волне, распространяя ее на окружающих, встраивая их в «рисунок» изменения, приводя всех заинтересованных к «общему знаменателю» и через это — реализуя задуманное.
Опубликовано 10.02.2017