Проект завершен, а результат не получен
Статья посвящена тому, что руководитель проекта может сделать не так. Почему у нас все может формально быть хорошо: вроде бы по ТЗ мы все сделали, акты уже готовы к подписанию, но в итоге продукт не получается? Что к этому приводит и как с этим бороться?
Для начала посмотрим на типовой цикл разработки. Сначала в проекте появляется какая-то идея. Либо есть что-то, что нас жмет, причем обычно не нас, а заказчика. Ему либо плохо, либо, наоборот, у него появляется представление прекрасного будущего: там все будет хорошо. И возникает решение: давайте пойдем и это сделаем.
После этого оказывается, что сделать все непросто и небыстро. Мы начинаем проект, организуем команду, подтягиваем ресурсы, делаем так, чтобы что-то создать. В итоге получается продукт проекта, который мы передаем заказчику, и, по идее, тут должен быть профит.
Но оказывается, что между этим продуктом – тем, что мы передали, – и профитом часто бывает огромная разница. Вроде бы мы все передали, а счастье не наступает. Посмотрим, за счет чего это происходит.
Различия руководителей проектов
Мы вроде бы все называемся руководителями проектов, но руководители проектов бывают разные и часто не очень хорошо понимают друг друга. Есть руководитель проекта внутри команды заказчика, а есть руководитель проекта со стороны подрядчика. Раньше я чаще всего выступал со стороны подрядчика, сейчас больше выступаю со стороны заказчика.
Руководитель проекта со стороны заказчика заинтересован в том, чтобы пройти большую внутреннюю процедуру согласования ресурсов и добиться, чтобы на проект кто-то выделил деньги. Такая ситуация встречается часто: вроде бы давно жмет, но все пока не до вас. А потом ресурсы наконец находятся – и можно двигаться вперед.
При этом руководитель со стороны заказчика понимает, как устроена вся внутренняя картина мира. У него есть прямой контакт с пользователями, какие-то отношения с ними. Они говорят: «Антон, пожалуйста, нам это очень надо. Без этой системы совсем никак. Поставь задачу, чтобы кто-то это сделал».
Но внутри команды заказчика руководитель обычно не занимается только одним проектом. У него есть этот проект, есть прошлогодний проект, который формально уже сдан, хотя все понимают, что там еще надо много чего доделать. Плюс еще три проекта в подвешенном состоянии: они вроде бы почти стартовали, но все ждут одобрения. В итоге фокуса на конкретном проекте мало. Человек вроде бы отвечает за него, информация у него есть, но внимания именно на этот проект постоянно не хватает.
С другой стороны, есть внешний подрядчик, и у него тоже есть руководитель проекта. Ему тоже интересны деньги, только с точки зрения контракта. При этом он не очень хорошо понимает, что происходит внутри компании заказчика, и может работать только с тем, что ему передали.
Поэтому он часто начинает выполнять задачу формально и спрашивает: «Хорошо, чего вы конкретно хотите, сколько вешать в граммах? Какая структура данных у вас должна быть?» А руководитель со стороны заказчика может не понимать, чего от него хотят. Он знает, что система должна делать то-то и то-то, говорит на языке бизнес-требований, а с ним потом разговаривают на языке технического задания.
Дальше подрядчик что-то делает с этими требованиями, и его задача – обеспечить маржинальность, то есть получить прибыль и обеспечить загрузку команды. Проекты то есть, то нет, а команда хочет кушать каждый день.
Из этого следует, что в начале проекта мы часто не понимаем, что именно должны сделать.
Политический старт
В такой ситуации возникает то, что называется политическим стартом. Политический старт – это не хорошо и не плохо, так бывает. Выглядит это примерно как у Петра Первого: «Здесь будет город заложен». Лучшее ли это место для Петербурга? Наверное, нет, можно было бы и южнее. Но это лучшее из доступных мест – начинаем.
В каких ситуациях это бывает? Во-первых, грант или конкурс, когда мы хотим очень быстро вписаться в эти деньги. Во-вторых, открывается целевое финансирование под какую-то программу, и мы тоже можем туда зайти. Третий частый вариант – чей-то успех в прессе: кто-то в аналогичной компании это сделал, а значит, нам теперь тоже надо. И мы идем делать.
Пример: уменьшение количества ошибок
Рассмотрим пример политического старта. Есть система, в которой пользователи вводят данные. В ней есть поле ввода: пользователь нажимает на это поле, может выделить все, скопировать и вставить куда-то в другое место.
Проблема в том, что пользователь может в случайный момент нажать на пробел. В этот момент поле ввода обнуляется, все сохраняется, потом данные приходится как-то восстанавливать. Это всегда неприятно, и люди не любят такую ошибку.
Решили сделать дополнительный контрол, который переводит поле ввода в режим редактирования. Сначала поле находится в режиме чтения: можно скопировать данные или сделать что-то еще, ничего не портится. Затем пользователь переходит в режим редактирования. В нем уже можно установить курсор, случайно нажать на пробел и потерять данные.
Решение сделали. Теперь поле случайно затереть нельзя, переход в режим редактирования вроде бы интуитивно понятен, все хорошо. Но у такого быстрого решения обнаружилась засада – лишнее действие.
Смена режимов занимает две секунды. Казалось бы, что такое две секунды? Но в высоконагруженной системе с 10–20 тысячами обращений ежедневно эти две секунды дают лишнюю ставку оператора поддержки. Команда поддержки перестает справляться и выполнять свои функции, ей нужны новые люди. Пользователь недоволен, решение приходится откатывать, а затем искать другие обходные пути. Затраты произведены, результат скорее отрицательный.
Законы, запреты, закупки
Следующий фактор, который нас держит, – законы, запреты, закупки и все, что связано с выполнением формальных процедур. Часто это информационная безопасность. Безопасность говорит: «Так нельзя. У нас все должно быть под контролем. На все должен быть лог, на все должна быть авторизация».
В итоге мы делаем мессенджер, в котором, чтобы получить сообщение, нужно ввести пароль, который приходит по SMS и на электронную почту. Два фактора аутентификации нужны, чтобы прочитать одно сообщение. Один раз таким мессенджером еще можно воспользоваться, но постоянно – вряд ли. Потом его улучшили: когда увидели, что это препятствие, запустили процесс и сделали так, чтобы подтверждение требовалось раз в 30 дней. Стало лучше.
Следующий момент, о котором думает руководитель проекта, – финансирование. Ему нужно найти источники и собрать все внутренние согласования. Если это внешний руководитель проекта, ему нужно долго договариваться и проходить процедуру контрактования. Приходится подстраивать программу: что делаем и чего не делаем, какой функционал будет внутри, какой снаружи, какой будет отчетность по расходованию средств, когда и в каком формате ее предоставлять. Все это забирает время.
В итоге мы упускаем важный момент: когда вообще мы задумываемся о ценности создаваемого продукта? Получается, сначала нам сказали: «Быстро побежали», потому что проект политический. Потом говорят: «Стоп, быстро не получается». Вот гирька безопасности, вот гирька внутренних документов, вот еще необходимость обосновать финансирование. А что в результате получится с точки зрения пользователей – уже большой вопрос.
Пример: автоматизация регистрации слушателей
Рассмотрим еще один пример – автоматизацию регистрации слушателей на мероприятие. Был классический процесс: люди расписывались в листе регистрации, потом администраторы вносили данные в базу. Все понятно.
Какие здесь затраты? Один лист бумаги и 10 секунд времени пользователя. Мы видим, кто пришел, а кто не пришел. В итоге получаем высокую надежность – примерно 99,9%. Чтобы пользователь не смог расписаться в листе присутствия, я пока не видел.
Но появилась альтернатива: цифровизация, надо сделать, чтобы данные сразу попадали в систему. Поэтому решили, что пользователи будут вводить QR-коды. Что могло пойти не так?
Во-первых, понадобилось 10 листов бумаги, потому что каждому пользователю нужно распечатать свой QR-код, чтобы он именно по нему вошел. Во-вторых, процесс занимает не 10 секунд, а три минуты. Пользователь не может просто войти: сначала ему нужно авторизоваться в Wi-Fi, потом навести смартфон на QR-код. Система то тормозит, то происходит что-то еще, и в итоге все занимает время.
Плюс непонятна визуализация: кто увидел и сфотографировал QR-код, а у кого не получилось? В итоге оказалось, что примерно 20% попыток неудачны. Каждый пятый пользователь не может зарегистрироваться и ставит свою подпись в исходном листе присутствия, потому что мы, как опытные проектные менеджеры, предусмотрели бэкап.
Получается, что было потрачено много всего, но решение не зашло.
Цели и ценности
Как сделать так, чтобы увидеть людей, которые будут пользоваться нашей системой? Наша задача – понять, каким будет позитивный результат продукта и о чем мы можем поговорить с пользователями.
Первое – удобство использования. Что изменится в их жизни, когда появится новая система? Может быть, пользователи не смогут сразу ответить на такой вопрос. Тогда с ними нужно говорить по-другому и спрашивать, что им неудобно. Так мы выйдем на сокращение трудозатрат. Где они тратят свое время? Какой вариант работы заставляет их тихо материться? Именно здесь можно что-то автоматизировать.
Когда мы это понимаем, следующая задача – определить, что будет превосходным результатом. Что станет той картинкой, которой пользователь захочет поделиться? Когда внедрялись «Аська» или WhatsApp, никто не заставлял людей регламентом ставить себе «Аську», WhatsApp или Telegram. Кто-то показывал, как это удобно, и после этого человек уже работал с системой постоянно.
В большой компании сделать это не всегда просто. Поэтому дальше будут и наши примеры, и примеры из моего прошлого опыта.
Чтобы увидеть пользователей, возникает идея найти их представителей. Сейчас введены две специальные роли. Одна называется «ответственный за эксплуатацию», другая – «ответственный за продажи». Это тот, кому мы передаем продукт и кто потом будет с ним возиться, жить, страдать или радоваться.
Следующая идея – прототипирование: сделать что-то, показать людям и посмотреть, будет ли у них отклик. В свое время меня поразил видеоролик «Мы строим самолеты на лету». Наша задача – сделать минимальный процесс, который взлетит. У нас это называется минимальным техническим решением. Пусть оно еще не вполне красивое, но взлетает.
Если в этот момент мы понимаем, что результат есть, идем дальше. Если понимаем, что результата нет, должны остановиться.
Позитивный пример – разработка программы обучения по управлению заинтересованными сторонами. Вообще тема заинтересованных сторон сильно недооценена. Все хотят узнать, как построить календарно-сетевой график, как выбить финансирование, а зачем все это надо – почему-то вне поля зрения.
Что мы сделали? Пошли к заказчику и спросили: «Что вам надо?» Выяснилось, что они не заполняют документы по заинтересованным сторонам. Решили научить их это делать.
Подготовили хорошую методическую программу, разобрали все документы, подготовили упражнения и показали пилотный прогон. Люди сказали: «У вас замечательное обучение, вы все прекрасно разобрали, но мы этого делать не будем». Как – не будете? Почему? И они говорят, что если эти документы не заполнять, финансирование все равно выделят. Да, они необязательные, хотя потом на финальном этапе проекта возникнут проблемы. Но финансирование выделят. А если документы заполнить, но заполнить неправильно, будет отказ в финансировании и придется идти на следующий круг согласования, который может занять достаточно много времени.
Пользователь оказывается в состоянии прапорщика из анекдота. Приходит проверка в часть и говорит: «У тебя лопата заржавела, не покрашена и с заусенцами. Три замечания, проверка не пройдена». Он берет, выбрасывает лопату и говорит: «Пиши: лопаты нет. Одно замечание».
Мы понимаем, что с таким подходом работать не надо. Нужен совершенно другой курс. В итоге мы сделали игровой курс, который показывает людям, что бывает, когда они не видят заинтересованных сторон. После этого он показывает документ, и у людей уже появляется мотивация, появляется желание что-то сделать.
«Путь героя»: кто и зачем пользуется системой
Следующий момент – попробовать сделать так, чтобы с пользователем было интересно общаться, чтобы увидеть в нем человека. Мы создали сценарий «Путь героя», чтобы всегда понимать, кто здесь герой, и сделали для себя чек-лист.
Первое – контекст возникновения. Когда возникла задача? Почему она возникла? Где это происходит, какая это компания, чем она занимается, сколько в ней работает людей, какое у нее место на рынке? Так мы описываем контекст.
Второе – кто наш герой? Кто эти люди? Почему у человека есть желание что-то поменять? Он может быть чем-то не удовлетворен, у него может возникнуть какое-то желание. В самом начале мы говорили об идее – здесь важно понять, кто является ее источником.
Следующий момент – какой вызов. В чем трудность? Какая задача стоит перед героем? Почему ему необходимо с ней справиться? Еще один очень важный вопрос – как он сейчас справляется с этим вызовом?
Даже если кажется, что в компании нет бизнес-процессов, какой-то бизнес-процесс все равно есть, люди все равно как-то работают. Как человек делает это сейчас? Например, тихо матерится, пишет одно письмо, второе, третье. После пятого письма ему отвечают, и он достигает результата. Хочется, чтобы он делал это быстрее.
Здесь мы берем на себя системную роль, которая должна перевести нас от пользователя к нашей системе: рассматриваем числа и метрики. Мы должны все оцифровать: насколько частый этот вызов, насколько он масштабный и длительный, сколько человеку нужно времени, сколько нужно места, чтобы сохранить результаты, если у него есть большие файлы.
В итоге пользователь оказывается оцифрован. С одной стороны, мы видим, какие параметры ему важны. С другой – понимаем, почему это важно. Тогда риск того, что мы упустим какой-то важный параметр, становится меньше: мы, скорее всего, его увидим.
Наблюдение после выслушивания
После выслушивания нужно переходить к наблюдению. Есть два момента: одно дело – спросить, другое – посмотреть. Если мы спрашиваем и смотрим, результаты бывают совершенно разными.
Если спросить детей, сколько они могут продержаться под водой без воздуха, что они ответят? Один скажет: минуту, другой – полчаса, третий – час. Потом проходит эксперимент: вода – и через 40 секунд дети уже выныривают.
Когда мы спрашиваем пользователей, то собираем ответы о том, что сложно, что раздражает, что должно быть и как все должно работать в идеале. Если начнем наблюдать, увидим много нового.
Первое, что мы увидим, – скрытая работа. Люди о ней не говорят: «Это же очевидно. Я всегда так делаю». Последовательность из семи нажатий в системе для них абсолютно очевидна. Как ее можно не знать? Каждый в компании это знает: все уже ошибались и теперь делают правильно.
Следующий момент – теневые участники. Оказывается, документ еще нужно отправить на согласование финансовому директору. Но это все время делают автоматически, поэтому никто об этом не говорит: «Раньше мы про это не упоминали, потому что это и так всем очевидно. Он всегда так делает».
По этому поводу была замечательная история. В Лондонском метро поезда стали сходить с рельсов. Выяснилось, что это произошло потому, что уволился человек, который смазывал рельсы. Там были специальные масленки, которые он заправлял. Он был один на все метро. Когда он ушел на пенсию, через некоторое время начались аварии.
Дальше – тайминги операций и то, как люди срезают углы. Это тоже важно, потому что одни операции длинные, другие короткие. Где-то человек говорит: «Здесь я всегда делаю не так, как вам описал. Все понятно, я уже знаю, какой будет результат, предсказываю его по данным и даже не запускаю эту проверку».
Наконец, мы понимаем, кто является бутылочным горлышком: у кого скапливается больше всего задач и на кого все начинают ругаться, когда что-то не происходит.
Именно в этот момент мы начинаем искать ценность. Мы понимаем, что важно для пользователей: убрать скрытую работу, улучшить тайминги, убрать бутылочное горлышко. Только с бутылочными горлышками нужно быть аккуратнее: одно убираем – появляются другие.
Ключевой вопрос звучит так: «Почему это для вас важно? Что вы хотите сделать, чтобы ваша жизнь стала лучше?» Этот вопрос нужно задавать все время, пока создается система, и постоянно понимать, что, кроме денег, вы получите от пользователей в виде благодарности.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
