Вижу цель, не иду к ней: как приводить проекты к результату
Всем привет!
Меня зовут Екатерина Гроцкая, я прошла долгий путь в IT — от оператора call-центра до техлида продукта в МТС Диджитал. И чем бы я ни занималась — поддержкой пользователей, сопровождением и разработкой продуктов — я сталкивалась с одной и той же проблемой: мы часто закапываемся в детали реализации и забываем, ради чего вообще начинали всё делать, какова была наша цель. История выглядит знакомой? Набив шишек, я нашла решение — в статье делюсь своими кейсами и выводами из них.
Про проблему и причины появления статьи
Уверена, многие оказывались в ситуации, когда посреди срочной и важной задачи становится ясно, что вы занимаетесь не тем.
Ведь хотели улучшить определенные показатели, специально что-то для этого разрабатывали, но в итоге получаете совсем не то, что планировали. А для чего мы тогда всё делали?
Для примера расскажу одну историю.
Я руководила проектом внедрения CRM для отдела продаж. На одном из этапов нам нужно было добавить в CRM подсказки по общению с клиентом: что делать после разговора, где какие контракты искать, как завершить продажу — такого рода. Эти подсказки лежали в отдельной системе. Времени на этап было мало, но мы с энтузиазмом взялись за то, что назвали «Настройка интеграции с системой подсказок».
Проблема крылась, как оказалось, в слове «интеграция». Целый месяц мы крутили задачу и так и этак, она переходила из спринта в спринт, мы тратили ресурсы, но не получали результата. Обнаружились технические ограничения, которые мы не могли обойти: чтобы «подтянуть» подсказки, нужно было за пользователя авторизоваться в системе подсказок. Мы не могли этого сделать по соображениям безопасности данных пользователей.
История тянулась бы ещё дольше, если бы нам не задали вполне логичный вопрос:
«Процесс по продажам достаточно типовой. Вы не хотите просто вставить текстом инструкцию, что нужно делать, без интеграций?».
Мы подумали и поняли, что это идеальное решение для такого случая. Чуть позже изменилась задача: нас попросили сделать решение, которое будет работать только через интеграцию. Поэтому оптимальный для нас вариант с текстовыми подсказками мы не смогли использовать дальше.
Сейчас я понимаю, что если бы цель не изменилась и нам все еще было нужно решить вопрос в кратчайшие сроки, мы бы сделали этим простым способом.
Понимаете, о чём я?
Справедливости ради, у таких ситуаций могут быть разные причины: от технических ошибок до неверной гипотезы. Но, по моему опыту, истина часто где-то посередине: при раскрутке гипотезы мы слишком углублялись в детали реализации, что забывали о ценности, о цели.
Как мы забыли, что пользователю хорошо бы видеть эти подсказки как можно скорее? И ему совсем не важно, как именно это будет реализовано.
Другая история — из сопровождения продукта. Я была заместителем директора департамента внутреннего сервиса с опытом руководства всего в полгода.
В ведении департамента был почтовый сервис. Через него техподдержка получала обращения от пользователей, и ходила внутренняя почта. И вот ломается один из серверов — аппаратная неисправность, как выяснилось позже. Всё встаёт — техподдержка доступна только по телефону, документы между офисами и филиалами не отправляются, коллапс. Команда решила, что важнее всего — отремонтировать вот этот конкретный сервер. Бросились искать причину, решать проблему. Всё это заняло полтора часа. Целых полтора часа вся почтовая система не работала.
Уже после мой руководитель спросил о причинах, а вторым его вопросом был: «А почему вы просто не вывели его из почтовой системы?». Действительно, можно было вывести бунтаря из системы за 15 минут, восстановить работу и спокойно заняться ремонтом. Ведь на самом деле цель была в бесперебойной работе. Мы сделали из ситуации выводы и поменяли алгоритм работы на будущее.
Про знакомство с книгой «Цель»
Примерно через полгода после истории с почтовым сервером я стала руководителем большого проекта по внедрению CMDB и нового Service Desk.
Опыта с CMDB ни у кого в компании не было вообще, нужно было пройти весь путь с нуля. Как подступиться к нему — вообще неясно. Как вообще люди начинают проекты в таких случаях? Мой руководитель (да-да, тот, что в прошлой истории задал правильный вопрос) посоветовал книгу «Цель. Процесс непрерывного совершенствования» Элияху Голдратта.
В книге идет речь об убыточном заводе, которым руководит главный герой. Он ищет способы не допустить закрытия своего производства. А для этого ему нужно найти цель работы предприятия, понять, что на неё действительно влияет и как её достичь.
Я читала эту книгу дольше всех других в своей жизни. Иногда мне хватало одной строчки или страницы, чтобы уйти в рефлексию. События и поступки героя я перекладывала на свои.
Проект с CMDB мы завершили успешно. Набили, правда, при этом много шишек, выбросили часть трудов в корзину, упустили некоторые сроки. И это тоже был хороший опыт.
Урок 1. Эффективность и оптимизация
«Так дай мне столько людей, сколько надо», — говорит главный герой.
«У тебя достаточно людей. Посмотри на показатели эффективности, Бога ради. У тебя есть всё, чтобы добиться улучшений», —возражает руководитель.
И в этом моменте я узнаю себя. Например, когда я ещё только начинала строить отделы, я часто говорила, что мне не хватает людей. Ещё казалось, что мы не выполняем нужное количество задач, не достигаем показателей именно из-за этого. Я не пыталась вложиться в оптимизацию процессов: что-то убрать, упростить — нет. Вместо этого просто ходила и говорила: «Дайте людей». Не скажу, что тут есть однозначное решение, конечно. В некоторых ситуациях действительно проблема бы так и решилась, но у меня это был уже автоматизм.
Урок 2. Истинные цели
Я проживала вместе с героем поиск цели существования завода. Конечно, с поправкой на свою специфику. Например, когда я работала в сопровождении продуктов, я долго считала истинной целью обработку как можно большего числа обращений. Но на самом деле это не так.
Главный герой пишет: «Теперь мне всё стало ясно (после долгих размышлений). Цель производственного предприятия — делать деньги».
На самом деле это касается абсолютно любой деятельности. Да, мой отдел — поддержка— не приносит денег напрямую. Но тогда моя задача — оптимизировать работу так, чтобы снизить затраты и не нанимать новых людей, когда это не нужно.
Урок 3. Баланс
У главного героя на протяжении книги возникают проблемы в личной жизни, он отдаляется от семьи и уходит в работу, но дела идут только хуже.
Почему мне это близко? Я тоже сместила этот баланс.
Принято делить жизнь на две части: личное — семья, отношения — и работа. На самом деле сторон больше, тут и хобби, и здоровье, и множество других аспектов жизни. Я же целиком уходила в работу.
Это как колёса у машины. Если ты накачал до предела только одно из четырёх, а остальные сдуты, то никуда ты не поедешь.
Жизнь с целью
Благодаря опыту и, отчасти, книге, я постепенно научилась помнить об истинных целях того, что я делаю. Уже в половине случаев (и я думаю, это успех!) я помню, ради чего я работаю над чем-то.
Мне помогает принцип: «Подвергай сомнению всё, что делаешь». Например, сейчас, при работе над проектами уже в МТС я регулярно задаюсь вопросами: «Зачем это нужно сделать? Можем ли мы без этого обойтись?». Бывает, что временные решения — единственный вариант быстро разобраться с острой проблемой, сохранив ресурсы.
Но зачастую лучше сразу создавать постоянную функциональность, не размениваясь на то, что будет использоваться недолго и вскоре уйдёт в мусорку. Всегда важно оценивать полную ситуацию перед принятием решения.
Оформила принципы и уроки, полученные из личного опыта и книги в небольшой чек-лист. С его помощью можно понять, что вы двигаетесь в правильном направлении внутри своего проекта. При составлении чек-листа я добавила пункты из биографии Илона Маска, написанной Айзексоном Уолтером.
Чек-лист «Как понять, что работа на проекте выстроена оптимально»
Каждый член команды выполняет те задачи, которыми он должен заниматься. Нет ситуаций, когда все делают всё, и размыта зона ответственности;
Процессы, которые можно автоматизировать, убрать или упростить — автоматизированы, убраны или упрощены. Возможно, даже есть ТЗ на правильную постановку ТЗ;
Все поставленные задачи ведут к цели. Если смотрим на задачу и не понимаем, как она поможет получить нужный нам результат, отказываемся от неё или даём самый низкий приорите;
Не приходится постоянно тушить пожары. Минимум переработок и сидений над проектами в ночи. Помним об отдыхе и балансе рабочего и личного;
У вас есть четкие DOR и DOD — индикаторы того, что задача готова к взятию в работу, и того, что после исполнения задача соответствует поставленным требованиям;
У вас выстроен процесс мотивации сотрудников, им интересно работать в команде над проектом.
Мой опыт субъективен, но, думаю, что учиться лучше на чужих ошибках. Возможно, уже завтра вы вспомните эту статью и скажете команде: «Ребят, но мы же делаем совсем не то!», и ещё одна истинная цель не будет забыта.
