Вы, как менеджер проекта, можете многое сделать для того, чтобы ваша команда успешно реализовала продукт, над которым вы работаете.
Взять на себя полную ответственность за сроки, бюджет, риски и подход к консультированию — вот лишь некоторые из идей, которыми я хочу поделиться с вами. Вы можете быть уверены, что роль менеджера проекта — может быть столь же важна для успеха проекта, как и квалифицированные разработчики и проницательные QAs. В этой статье я поделюсь с вами советами, которые помогли нам успешно создать работающий MVP для одного из наших клиентов. Наслаждайтесь!
1. Будьте в курсе рисков
Некоторое время назад у нас была внутренняя презентация о различных подходах к управлению рисками. Одно из упражнений, о котором я узнал, полностью изменило мой взгляд на риски - я говорю о Предсмертном вскрытии. Для тех из вас, кто не слышал об этом, это в основном упражнение, во время которого (вместе с вашим клиентом) вы пытаетесь визуализировать все возможные сценарии конца света для вашего проекта еще до того, как он начнется. Исходя из этого, вы перечисляете наиболее важные из них и разрабатываете планы по смягчению последствий, чтобы либо избежать их, либо лучше управлять ими. После того, как все сделано хорошо, вам на самом деле не нужны какие-либо причудливые и сложные инструменты или процессы отслеживания рисков - когда вы с самого начала знаете, что может пойти не так, вы просто придумываете способы ежедневного мониторинга этих областей и делаете это частью ритуалов жизненного цикла вашего проекта. Не игнорируйте названные вами риски - они произойдут, примите их и справьтесь с ними. Убедитесь, что вы как можно более готовы заняться ими, когда они всплывут на поверхность.
В проекте, который я имею в виду, мы перечислили 4 наиболее важных риска:
- Фиксированный бюджет
- Соответственно, неизбежен крайний срок, когда закончатся деньги;
- Технические проблемы (функция, ранее не создававшаяся никем из нашей команды);
- Широкий охват.
2. Важность отслеживания бюджета
В каждом проекте, нравится вам это или нет, вы должны знать о каждом долларе или евро, которые может потратить ваш клиент. Это еще более важно в проекте с фиксированным бюджетом. Что я настоятельно рекомендую, так что постарайтесь думать об этом как о своих собственных деньгах и заставьте свою команду относиться к этому так же. Это поможет вам принимать осознанные решения - вы знаете, каковы ваши цели, теперь вы должны уметь рассчитать, сколько вы можете потратить, чтобы эти цели осуществились. Что я сделал, так это подготовил очень простую таблицу отслеживания бюджета, основанную на наших обычных ставках, и с первых дней нашего проекта я знал, на какой срок мы действительно можем планировать любую работу. Вы сразу знаете, когда у вас кончатся деньги, и это сразу же поможет вам лучше расставить приоритеты и сократить объем, который не является абсолютно необходимым для достижения целей MVP, который вы создаете. К сожалению, у вас не может быть всего этого - широкий охват и ограниченный бюджет не работают вместе. Никогда. Поэтому сделайте расчеты, убедитесь, что ваш клиент осведомлен о них, убедитесь, что команда знает, сколько денег мы можем позволить себе тратить каждый месяц и как их лучше потратить. Самым ярким моментом для меня стало то, что команда начала спрашивать меня во время сессий планирования или уточнения: “Ага, сколько у нас еще денег?” - опять же, относитесь к этому как к своему собственному бюджету, и это будет иметь огромное значение.
Основываясь на конкретном проекте, который я имею в виду, я сосредоточился на сценарии с фиксированным бюджетом, но, конечно, этот подход также полезен, если вы работаете в режиме времени и материалов. Всегда полезно знать, сколько денег на самом деле тратят наши клиенты и как мы можем посоветовать им хорошо потратить эти деньги.
3. Технические проблемы - работа с POCs
Один из рисков, который мы оценили как наиболее вероятный, связан с основной особенностью MVP, которая казалась немного сложной, сложной и совершенно новой в портфеле нашей компании. Мы чуть не поскользнулись на этом, так как он вернулся к нам в самом начале этапа разработки проекта. Что я могу настоятельно рекомендовать вам сделать сразу после того, как вы согласитесь, что это один из пунктов с высоким риском в вашем списке, так это договориться с вашим клиентом о том, чтобы выделить время команде разработчиков на подготовку технического подтверждения концепции, чтобы определить направление, в котором вы хотите разработать данную функцию, и посмотреть, можно ли и как подойти к ней, чтобы сделать ее жизнеспособной. Это можно считать мини-проектом в рамках проекта. Как только вы получите результаты, также оцените риски - уверены ли мы, что сможем это сделать? Если существует высокий риск, мы не можем этого сделать - готов ли клиент пойти на это в любом случае? PoC дает вам огромное преимущество и снимает некоторый стресс, связанный с неопределенностью. Нам не удалось провести серьезный PoC прямо перед началом проекта, но мы сделали это в начале фазы разработки, и это было одно из первых действий, которые мы планировали для второго этапа проекта - учиться на своих ошибках в лучшем виде.
4. Управление временной шкалой - отслеживание прогресса по целям спринта, управляемым пользователем
Как PMs, мы несем ответственность за контроль за ходом проекта и следим за тем, чтобы действовать, если что-то кажется неправильным. То, что я сделал в этом конкретном проекте, было немного больше, чем это. Вместе с командой мы подготовили график, основанный на целях спринта, которых мы хотели достичь к концу данного спринта. Они были ориентированы на пользователя, не очень строгие (поэтому это давало нам некоторую гибкость, когда мы планировали конкретные функции, которые должны были войти в спринт), и они были для нас руководством на протяжении всего периода, вплоть до выпуска MVP. Это было довольно просто: мы сели и подготовили график, основанный на приращениях рабочих функций, которые мы планировали предоставлять каждые 2 недели (именно такой длины были наши спринты). Это действительно помогает вам визуализировать, сколько вы на самом деле можете сделать за оставшееся время. Это была основа для многих переговоров и дискуссий с нашим клиентом. Как я уже упоминал, у вас не может быть ограниченного бюджета и неограниченных возможностей (я никогда не видел, чтобы это работало). Поэтому вам нужно сосредоточиться на целях MVP и ваших пользователях - все, что не соответствует этому, должно быть удалено. Держите этот план простым для выполнения и постоянно обновляйте его вместе с командой и вашим клиентом, чтобы все были на одной странице. Это действительно помогает понять, что к 5 - му спринту вы хотите, чтобы пользователи могли выполнять XYZ в приложении-поэтому после каждого спринта вы уверены, что для них появится новая ценность, и вы не получите 5 запущенных функций, но не получите видимой пользовательской ценности.
5. Постоянные переоценки
Никому это не нравится, но если вы находитесь в такой же ситуации, как та, которую я описываю здесь, вам нужно убедиться, что вы довольно часто собираете команду, чтобы провести переоценку объема, который у вас еще впереди, до истечения крайнего срока. В постоянно меняющейся среде, в которой мы работаем, существует так много факторов, что оценка, сделанная 3 недели назад, может легко оказаться устаревшей и неправильной сейчас. Мы позаботились о том, чтобы это был один из ритуалов, которому мы следовали регулярно, точно так же, как ежедневным стендапам, сеансам планирования и обзорам с нашим клиентом. В какой-то момент команда напомнила мне, что, например, учитывая некоторые недавние изменения в графике, мы определенно должны снова погрузиться в оценки. Я считаю это большим успехом, когда команда еще больше, чем вы, стремится следить за прогрессом - в конце концов, это командные усилия, и мы все в этом вместе. Убедитесь, что ваша команда понимает огромную ценность отслеживания прогресса и улучшения оценки усилий, необходимых для разработки продукта. Однажды они будут вам благодарны.
6. Установите свой собственный крайний срок, даже если у вас его нет
Мы знали, что у нас было ограниченное время (учитывая, как долго продлится бюджет), но на самом деле у нас никогда не было строгих сроков от нашего клиента. Кажется милым, да? Ну, и да, и нет. В какой-то момент мы пришли к выводу, что должны сами установить крайний срок, раньше, чем закончится весь бюджет. Это сделало нас еще более сосредоточенными и дисциплинированными. Сложно уделять себе меньше времени, чем у вас есть на самом деле, но создание аналогичного временного (и денежного) буфера-действительно хороший шаг в случае некоторых неожиданных элементов риска, которые вы не смогли обнаружить. Наихудший сценарий - вам нужно больше времени для доставки MVP (но вы уверены, что у вас есть), лучший сценарий - вы доставляете MVP пользователям раньше, и вы уже можете начать планировать этап 2 и что делать с деньгами, которые вы сэкономили своему клиенту. К счастью для нас, второй сценарий воплотился в жизнь.
7. Полное право собственности на стороне команды
Что вы можете сделать как премьер-министр, так это убедиться вместе с командой, что вы берете на себя как можно больше ответственности за продукт. Помните, что вы являетесь экспертами и знаете, что делаете, - убедитесь, что вы используете любую возможность, чтобы показать это своему клиенту. Консультируйтесь и консультируйте ежедневно - используйте свой личный опыт, чтобы советовать против идей, которые, как вы знаете, скорее всего, потерпят неудачу, обсуждайте и корректируйте приоритеты в соответствии с текущей ситуацией, и не бойтесь бросать вызов своим клиентам - много раз им может понадобиться второе мнение и кто-то, кто с ними не согласен, для общей пользы их продукта.
Одним из основных столпов здесь будет активная и прозрачная коммуникация, как внутри команды, так и с вашим клиентом. Сообщайте о своем прогрессе и препятствиях, с которыми вы сталкиваетесь ежедневно, будьте прозрачны и не ограничивайтесь официальными мероприятиями scrum для обсуждения важных вопросов. Когда вам удастся сделать это приоритетом для всех, вся команда будет работать как супер бесперебойно работающая машина, позволяющая всем знать, что происходит именно тогда, когда это необходимо.
Вывод
Все приведенные выше примеры показывают, как много вы, как руководитель проекта, можете сделать, чтобы положительно повлиять на свою команду, своего клиента и их продукт. Позвольте мне подытожить их для вас в коротком списке:
- Сделайте шаг вперед и задействуйте как можно больше - на этот раз инвестиции окупятся, так как вы будете в курсе всего, что происходит с продуктом.
- Всегда называйте риски, убедитесь, что все о них знают, и убедитесь, что вы готовы смягчить их наилучшим возможным способом.
- Считайте проект своим личным делом - следите за бюджетом, как если бы вы тратили свои собственные деньги, следите за прогрессом и решайте, остаются ли в силе следующие приоритеты с учетом текущих обстоятельств.
- Ищите улучшения вместе с командой и, по возможности, договаривайтесь с вашим клиентом о необходимых корректировках. Масштабы и приоритеты изменятся - найдите лучший способ охватить это.
- Будьте настойчивы, рассказывайте всем вокруг о передовой практике и помогайте им принимать правильные решения.
- Облегчайте до тех пор, пока вышеуказанные процессы и обычаи не станут хлебом насущным для вашего проекта. Достаточно скоро люди спросят себя, как они могли бы жить без них в своих предыдущих проектах.
Это часто бывает непросто, особенно когда что-то идет не так или когда ваш клиент упрям и не желает прислушиваться к хорошим советам с вашей стороны. Тем не менее, не останавливайтесь и ежедневно работайте над улучшением управления проектами. Как вы можете видеть, вы можете многое сделать, что повлияет на успех проекта. Проявите творческий подход и начните совершенствоваться!
