Успех приходит не случайно, а благодаря проницательности и планированию.
За свою карьеру я руководил многими проектами, и многие из них закончились полным провалом. Некоторые из них обернулись катастрофой, несмотря на прекрасное планирование, но большинство моих неудач произошло из-за неправильного планирования. В этих проектах работали замечательные инженеры с большой мотивацией и талантом, но они все равно потерпели неудачу. Однако с каждой из этих неудач я узнавал что-то новое о планировании проектов. В этом посте рассматриваются следующие шесть методов, которые я сейчас использую в своих проектах.
- Идентификация заинтересованных сторон — Кого затронет этот проект?
- Показатели успеха проекта — как мы будем измерять влияние на бизнес?
- Вехи проекта — как мы разбиваем проект на контрольные точки?
- Определение готовности — что означает завершение для этого проекта?
- Диаграммы Ганта — кто над чем работает, когда и как долго?
- Pre-Mortems — какова наиболее вероятная причина неудачи?
Я усвоил каждую из этих техник на собственном горьком опыте, и, скорее всего, вам тоже придется учиться на собственном опыте. Если вы уже обожгли пальцы на пресловутой плите (т. е. провалили проект из-за плохого планирования), то один или несколько из этих приемов могут вам пригодиться. Я поместил все это (и многое другое) в шаблон планирования проекта, который вы можете скопировать/украсть/изменить.
Обратите внимание, что я не включаю управление задачами в этот список, потому что создание, назначение и выполнение задач — очень гибкий процесс, который сильно зависит от характера работы и задействованных инженеров. По моему опыту, лучшая система управления задачами — это та, в использовании которой больше всего заинтересована команда. Я настоятельно рекомендую вам использовать систему (в отличие от хаос-инжиниринга), но эта система должна быть той, которая ведет к наименьшему сопротивлению вашей команде.
Если этот пост полезен, пожалуйста, 👏, подпишитесь или свяжитесь со мной в LinkedIn. Я пишу для удовольствия, но приятно знать, что кто-то извлек из этого пользу.
1) Идентификация заинтересованных сторон: предотвращение худших сюрпризов
Определяя затронутые стороны и их мотивы, вы снижаете риск недопонимания или ложных предположений
Чтобы определить заинтересованные стороны, составьте список всех сторон, на которых повлияет результат вашего проекта. Довольно часто требования к проекту проходят через достаточное количество рук, чтобы видоизмениться (как в телефонной игре). В важном разговоре с кем-то обычная коммуникативная стратегия состоит в том, чтобы повторить то, что, как вам кажется, вы только что услышали. Это используется для уменьшения недопонимания и повышения шансов на успешный результат. Выявление стейкхолдеров — это то же самое, но между вами и людьми, которые хотят получить конечный продукт.
Большинство инженеров удивляются тому, как много разных сторон заинтересованы в игре. Вот составленный список для пользовательской функции:
- Клиенты. Они являются наиболее важными заинтересованными сторонами.
- Инженерная команда — они будут нести ответственность за поддержку функции.
- Команда платформы — они будут отвечать за запуск новой функции.
- Команда поддержки — им нужно будет ответить и направить заявки для этой функции.
- Команда дизайнеров. Их дизайн непропорционально повлияет на принятие клиентами.
- Команда безопасности — они отвечают за безопасность функции.
- Команды по продажам и маркетингу — им нужно знать, как говорить об этой функции и продавать ее.
- Лидерская команда — они платят вашей команде за предоставление функций и заботятся о том, чтобы их деньги были потрачены не зря.
Для каждой заинтересованной стороны необходимо определить следующее.
- Почему им интересен этот проект?
- Вам нужен их вклад?
- Должны ли они принять меры на основе вашего результата?
- Важна ли эта заинтересованная сторона больше, чем другие?
За свою карьеру я видел, как многие проекты терпели неудачу из-за простого отсутствия взаимодействия с нужными заинтересованными сторонами. Иногда это происходило из-за того, что инженерам не хватало важной информации. В других случаях это было из-за того, что они забыли предупредить нижестоящую команду об изменениях, которые они вносили (например, группу безопасности).
Я не могу не упомянуть этот шаг — очень важно определить заинтересованные стороны и то, что они хотят.
2) Метрики успеха проекта: определение того, насколько большой вы планируете выиграть
Первый шаг – определение успеха.
В идеале нужно уметь видеть, как успех этого проекта соотносится с целями команды и вплоть до целей компании. Большинство проектов основаны на идее, что они увеличат доходы, снизят затраты, приведут новых клиентов или повысят их лояльность. Четкое понимание того, как проект связан с бизнес-целями, необходимо для понимания приоритета и воздействия.
Как только вы узнаете, как должен выглядеть и ощущаться успех, важно перейти к тому, как вы будете измерять этот успех. Показатели успеха проекта — это конкретные измерения, подтверждающие тезис проекта. Часто прямое измерение дохода слишком сложно, и вместо этого необходимы прокси-метрики. Чем дальше ваши прокси-метрики от дохода, затрат или клиентов, тем больше вероятность, что вы сможете улучшить прокси-метрику, не оказывая положительного влияния на бизнес.
Используйте показатели, ориентированные на влияние на бизнес
Большинство новых инженеров склонны брать бизнес-требования и превращать их в технические требования. Затем они пишут, что цель их проекта — реализовать функцию. В подавляющем большинстве случаев предоставление функции без одобрения клиентом бесполезно. Возьмите следующие два варианта:
- Вариант (A): Фильтрация добавлена в таблицу Product.
- Вариант (B): параметры фильтрации используются ›5% клиентов, взаимодействующих с таблицей Product.
Подумайте, насколько мощнее Вариант (Б). Чтобы прийти к «5%», вам нужно было подумать о том, насколько полезна фильтрация для рабочего процесса вашего клиента. Это добавляет веса и ясности проекту, давая понять, «почему» инженеры работают над проектом. Возлагая на своих инженеров ответственность за результаты, вы даете им свободу выбора альтернативных путей. Возможно, вместо того, чтобы сосредоточиться на предоставлении наибольшего количества фильтров, они сосредоточатся на том, чтобы сделать два верхних фильтра очень простыми для обнаружения и применения.
Как выбрать лучшие показатели?
Представьте, что вы участвуете в оценке эффективности команды со своим начальником. Вы пытаетесь спорить, почему все члены вашей команды заслуживают повышения. Какой аргумент более веский?
- Вариант (A): Моя команда представила четыре функции.
- Вариант (Б): Моя команда реализовала функцию, которая увеличила доход на 30 %.
За исключением стартапов на ранней стадии, большинство генеральных директоров сосредоточены на максимизации доходов, минимизации затрат или снижении рисков, и все это ради увеличения денежного потока и прибыли. Чем дальше ваша метрика от одной из них, тем больше вероятность того, что ваша прокси-метрика может быть увеличена без достижения одной из этих бизнес-целей. В приведенной ниже таблице перечислены некоторые примеры, показывающие, как слабая прокси-метрика может быть перефразирована в более сильную метрику, которая лучше отражает цели компании.
3) Вехи проекта: разбивка сложных проблем на разумные части
Вехи проекта или контрольные точки дают возможность при необходимости изменить или скорректировать стратегии
Вехи проекта связаны со снижением риска. Когда вы начинаете новый проект, существует множество как известных, так и неизвестных рисков. Возможно, выбранная вами технология не работает на практике. Может быть, бизнес больше не может позволить себе поддерживать эту инициативу. Если ваш проект планируется как один большой кусок, то вы постоянно находитесь в состоянии частичного завершения. В оставшейся части этого раздела я собираюсь рассмотреть три различных метода разделения проектов:
- Разбейте проекты по контрольным точкам доверия
- Разбейте проекты по фазам принятия
- Разбейте проекты по точкам «ухода»
Разбивка проектов по контрольным точкам доверия
Этот метод лучше всего работает при развертывании новой технологии, чтобы свести к минимуму негативное воздействие, если новое решение не лучше старого. Исходя из моего опыта, слишком рискованно предполагать, что ваших исследований или должной осмотрительности было достаточно. Вместо этого я счел полезным разбивать проекты на следующие контрольные точки.
- Исследование, проверка концепции и создание прототипа. На этом этапе конечным результатом является живая демонстрация новой технологии в действии, которую можно показать заинтересованным сторонам.
- Подготовка. Интегрируйте технологию с бизнес-вариантом использования, но убедитесь, что никакая производственная среда не затронута. Это последний момент, когда можно или нельзя.
- Производство: полное слияние технологии с окружающей средой.
- Очистка и исправление ошибок. Предположим, что ошибки, очистка и запросы функций в последнюю минуту будут необходимы для достижения максимального эффекта.
Разбивка проектов по этапам внедрения
Для проектов, которые предполагают добавление функции, полезной стратегией является моделирование ваших контрольных точек на основе кривой принятия. Это также работает для рефакторинга технического долга.
- Новаторы: создайте MVP, необходимый для ваших первых одного или двух клиентов.
- Ранние пользователи: рефакторинг функции по мере необходимости, чтобы она стала более широко применимой, и подключите следующую группу пользователей.
- Раннее большинство: выполните всю работу, необходимую для масштабирования вашей функции для всей клиентской базы.
- Опоздавшее большинство. Определите и создайте оставшиеся функции, необходимые для привлечения опоздавших, планируя отказ от старых рабочих процессов.
- Отстающие: полностью отменить старый путь и принудительно перенести старые варианты использования.
Разбивка проектов по точкам отказа
Этот метод имеет решающее значение для команд / предприятий, которые часто прерываются. Идея состоит в том, что вы предполагаете, что в конечном итоге вас будут прерывать, поэтому вы разбиваете проект на контрольные точки, после которых вы можете безопасно уйти. Хорошим примером этого может быть полная реализация каждой функции при создании новой службы, прежде чем переходить к следующей. Вместо того, чтобы откладывать такие задачи, как документация, до конца проекта, выполняйте их параллельно с каждой функцией. Если вам когда-нибудь понадобится уйти с предупреждением всего за одну неделю, вы можете легко закончить там, где вы есть, и двигаться вперед.
В отличие от других методов разделения проектов, здесь я не могу привести пример вех, так как они очень зависят от проекта. Основная идея, однако, заключается в том, что каждая контрольная точка заканчивается в точке, где вы можете уйти, а результат все равно будет полезен и ремонтопригоден.
По моему опыту, описанная выше стратегия является одной из наиболее полезных для включения и может сочетаться с другими. Есть также дополнительные положительные побочные эффекты от этой техники, в том числе минимизация времени на первую доставку чего-то вашему клиенту и снижение риска несоответствия проекта.
4) Определение готовности: не споткнуться на финише.
Последние 5 % проекта могут решить все или разрушить его
По моему опыту, инженеры, как правило, объединяют множество задач в одну задачу «очистки» или веху, но часто работа в этой задаче очистки является наиболее важной для обеспечения успеха проекта. Инженеры, как правило, настолько сосредоточены на создании самой функции, что упускают мелкие детали. Это особенно верно, когда в конце проекта возникает что-то неожиданное (например, ошибки, обнаруженные первыми реальными пользователями). Довольно скоро началось планирование следующего цикла, и эти мелкие задачи теряются в этой мешанине.
Хотя этого нельзя полностью избежать, один из лучших способов избежать этой проблемы — задокументировать определение готово (популярное благодаря Agile). Определение готовности — это процесс, в котором вы документируете как функциональные, так и нефункциональные требования к проекту, чтобы всем было ясно, как должен выглядеть окончательный результат. Вот некоторые примеры:
- Вспомогательная документация пишется и проверяется командой, и как минимум 2 инженера знакомы с кодом.
- Маркетинг использует новую функцию как часть информационно-разъяснительной работы.
- Функция находится в разработке более недели, активно используется клиентами.
- Все критические пути имеют интеграционные тесты, и существует сквозной дымовой тест.
- Все журналы и метрики передаются на соответствующую платформу.
- Все ошибки P0 и P1, зарегистрированные в течение первых 2 недель после доставки, исправлены.
- Проведена ретроспектива проекта и завершены последующие действия.
Определение показателей готовности и успеха – не одно и то же.
Показатели успеха, как правило, жесткие и неизменные, поскольку они являются желаемым результатом проекта. Если вы меняете свое определение успеха, часто это плохой знак, так как это, вероятно, означает, что вы смещаете фокус проекта или уменьшаете ожидаемые результаты. Это противоположно определению «выполнено», которое имеет тенденцию расширяться по мере того, как над проектом выполняется больше работы и конечный результат становится более ясным. В большинстве случаев вы должны облегчить инженерам добавление элементов в определение, но требовать совместной работы группы для удаления элементов.
5) Диаграммы Ганта: ценный метод оценки времени
Диаграммы Ганта полезны, если вашей команде сложно оценить время проекта.
Каждый раз, когда вы сдаете свой проект с опозданием, вы подобны сантехнику, который появляется через четыре часа после назначенного времени, или дивану, который приходит через шесть месяцев после того, как вы его заказали. Это неуважительно.
Я руководил многими проектами и многими инженерами, и почти всегда они говорят: «Я плохо оцениваю время». Однако это похоже на отговорку. Люди ожидают разумных оценок для большинства других вещей в своей жизни, но инженеры почему-то хотят свободного прохода, когда дело доходит до разработки программного обеспечения. Представьте, если бы вы пошли к врачу, и вам сказали, что у них превышено расписание, и вам нужно будет вернуться завтра.
Отличные менеджеры проектов умеют задавать правильные вопросы, которые превращают приблизительные оценки в надежные сроки. По моему опыту, наиболее эффективной визуализацией задач я считаю диаграммы Ганта. Для тех, кто не знаком, диаграмма Ганта — это визуальное представление, показывающее задачи в виде временной шкалы. Идея состоит в том, чтобы приблизительно оценить единицы работы и сложить их в соответствии с тем, что можно сделать параллельно, исходя из доступных ресурсов и характера работы.
Диаграммы Ганта можно организовать по инженерам…
…или просто по вехе.
Обратите внимание, что в этой базовой визуализации используется только простая таблица (доступная во всех инструментах документирования). Многие диспетчеры задач имеют гораздо лучшую визуализацию диаграмм Ганта. Пример показан на скриншоте Asana ниже.
Наиболее распространенные ошибки при оценке задачи
Оценка задачи — это навык, который необходимо развивать, как и любой другой. Большинство инженеров, как правило, запутываются в следующих вопросах:
- Разбивка работы → Инженеры могут не разбивать проекты на дополнительные этапы и высокоуровневые задачи.
- Зависимости задач → Инженеры могут не учитывать последовательность задач в отношении зависимостей.
- Внешние зависимости → Инженеры могут не получить твердых обязательств от других команд. Результатом являются эскалации в последнюю минуту и задержки проекта.
- Задания по очистке → Инженеры могут запутаться в множестве окончательных задач, необходимых для завершения проекта (т. е. все задачи, которые инженеры заключают в «мы сделаем это в конце»).
Все, что обычно требуется, — это немного подтолкнуть в этом направлении, и инженеры, как правило, более чем способны заполнить пробелы.
6) Pre-Mortems: предотвращение неудач с помощью стратегии
Каждый проект должен иметь какой-либо механизм снижения рисков, а пре-мортемы – отличный способ заставить людей задуматься.
Большинство инженеров знакомы с вскрытиями, поскольку всем нам (к сожалению) приходилось их посещать. Большинство вскрытий сосредоточено вокруг неудач проекта и нашего желания исправить эти неудачи в следующем проекте. Хотя я согласен с тем, что команды должны проводить вскрытие (независимо от результатов проекта), часто кажется, что мы могли бы сделать больше, чтобы предсказать будущее. Вот где премортемы приходят на помощь.
Впервые я узнал о премортемах из книги Энни Дьюк Как принять решение и с тех пор пользуюсь ими. Pre-mortem — это когда вы выполняете post-mortem еще до того, как начнете свой проект. Этот метод похож на сфокусированную версию анализа рисков. Я использую следующие две подсказки, чтобы начать разговор:
- Кратковременный сбой. В конце цикла мы объявляем проект провальным. Почему?
- Долговременная неудача. Сначала мы заявляем, что проект был успешным, но через шесть месяцев мы задним числом объявляем проект неудачным. Почему?
Я разделил обсуждение на две подсказки по причине. Когда люди думают о рисках для проекта, они, как правило, сосредотачиваются на неудаче и упускают из виду тот факт, что реализация функций — это слабая форма успеха. Настоящий успех приходит от принятия/приобретения клиентов, которые часто невозможно полностью измерить, пока не пройдут месяцы. Поставив эти две преднамеренные подсказки, я получил значительно лучшее понимание.
Размышляя о риске, важно определить
- эффект — негативный результат, которого вы пытаетесь избежать,
- причина — корень проблемы, приводящий к негативному эффекту,
- impact — масштабы сбоя,
- вероятность — вероятность того, что это произойдет, если не уменьшить ее,
- снижение рисков — один или несколько подходов к смягчению проблемы, а также —
- владелец — лицо, ответственное за отслеживание и устранение последствий.
Ниже приведен пример таблицы, которую вы можете использовать.
Заворачивать
Хотя полностью исключить риски из проекта невозможно, вы, безусловно, увеличиваете свои шансы на успех при эффективном планировании. Проекты терпят неудачу, потому что люди забывают важные шаги, не разговаривают с нужными заинтересованными сторонами, ошибаются в предотвратимых рисках или неправильно распределяют последовательность задач. Потратив время на смягчение этих опасений, вы с большей вероятностью потерпите неудачу по неизбежным причинам (что лучше, чем неудача по предотвратимым причинам).
Существует множество методов определения масштаба проектов и снижения рисков, но в этой статье основное внимание уделяется шести из них.
- Идентификация заинтересованных сторон. Общение с заинтересованными сторонами снижает вероятность неудачи из-за отсутствия контекста.
- Показатели успеха проекта. Определение показателей успеха проекта обеспечивает гибкость его выполнения.
- Вехи проекта. Создание контрольных точек проекта снижает риск за счет определения опорных точек на ранних этапах проекта.
- Определение готовности. Согласование определения «выполнено» позволяет инженерам сосредоточиться до тех пор, пока работа не будет завершена.
- Диаграмма Ганта. Создание диаграмм Ганта улучшает оценку времени проекта.
- Предварительные анализы. Проведение предварительных анализов снижает риски, которых можно избежать.
У вас есть еще техники? Пишите мне в LinkedIn — буду рад пообщаться.
