IT2G

Forwarded from: Bash.im

Сегодня заключительная часть статьи о дорожных картах.

Проблема номер 7 - поддержка заказчика

Для успеха дорожной карты проекта необходимо получить от заказчика ее одобрение. Ситуация осложняется, когда на стороне заказчика задействованы несколько или множество участников, принимающих решения. Решение предыдущих проблем с дорожными картами могло быть под контролем руководителя проекта. В данном случае результат зависит от договоренности других заинтересованных лиц. Успешное согласование плана развития проекта наиболее вероятно если каждый заказчик (от конечных потребителей до инвесторов) внес свой небольшой вклад в этот план, и у него есть стремление увидеть реализацию своей части требований. Стремление выполнить свое собственное видение проекта без поддержки других похоже на толкание камня вверх по отвесной горе.

Как менеджер проекта вы не можете гарантировать абсолютную поддержку от всех заинтересованных лиц, но существуют способы повысить вероятность получения этой поддержки. Для того чтобы заказчик пришел с вами к компромиссу по приоритетам задач нужно показать ему все множество требований, полученное от всех участников. Затем представить в соотношении те функции, которые вы реально сможете реализовать за отведенное время. Такая картина должна образумить заказчика даже если некоторые из его собственных пожеланий были выброшены из плана.

Заключение

Если дорожная карта составлена правильно, то она послужит отличным проводником ваших идей и общего видения проекта, будет путеводным камнем как для команды разработки, так и заказчика. Если же это не так, то эта карта превратится в палку для битья разработчиков. Основной принцип, который можно извлечь из всех проблем выше - отсекайте лишнее. Уберите ограничивающие сроки и дедлайны, вынесите все детальные описания в отдельные документы требований и всегда будьте готовы к изменениям. В течение реализации проекта прислушивайтесь к заказчику, ведите обсуждения с командой, но не позволяйте им диктовать направление развития проекта. Следуя данным принципам, вы получите дорожную карту, которая поможет вам привести проект к успеху.

#четвергобразовательный

всем доброго утра! И с вами как всегда по пятницам #четвергобразовательный. Продолжаем наш разговор о дорожных картах.

Проблема номер 6 - адаптация к изменениям и следование отзывам

Залог успеха дорожной карты находится в ее гибкости. Если ваше планирование скрупулёзно до мелочей, то оно будет лишь вас ограничивать, лишит способности реагировать на неизбежные изменения. Проблемы с адаптацией проекта имеют несколько причин:
- психологически отклонение от "Плана" может рассматриваться как проявление слабости, признаком надвигающихся неудач;
- заказчик может сам быть не сторонником перемен и требовать следования начальному плану и жестко установленным срокам;
- простая нехватка времени на реализацию изменений.
Какими бы ни были причины, неспособность меняться и адаптироваться к отзывам пользователей приведет к созданию продукта, который никому не нужен или устарел уже при запуске.
Решение - выкиньте как можно больше деталей непосредственно из дорожной карты и поместите их в отдельные требования по проекту. Задачи, баги, сценарии и мокапы относятся к сущности требований, но не плана проекта.
В плане должно оставаться достаточно пространства. Так что при своем появлении изменения не перевернут всю вашу ежедневную работу с ног на голову и не шокируют заказчика.

Вы могли подумать, что мы вас покинули и сдались под натиском РКН, но это не так. Диджитал резистанс и все такое. Просто модератор канала был в отпуске и очень неплохо провел время, сажая капусту.

И мы продолжаем наш #четвергобразовательный статьей Кассандры Найджи в переработке нашего аналитика Николая Бебкова.

Проблема номер 4. Отсутствие понимания между менеджером и разработчиками.
Мысль о том, что разработчики и менеджеры непосредственно зависят друг от друга, кажется очевидной. Без менеджера проектов разработчики производили бы функционал без его осмысления в рамках бизнес целей или стратегии. В свою очередь, менеджеры могут применять свои стратегии сколько угодно, но без реального воплощения разработчиками они останутся только безжизненными теориями.
Несмотря на взаимную потребность друг в друге, бывает, что менеджеры и разработчики забывают общаться друг с другом, или же не хотят слышать друг друга. Это неудивительно, ведь они говорят на разных языках и смотрят на проблемы со своих позиций. Так или иначе, эффективное взаимодействие с разработчиками необходимо для построения дорожной карты. Чтобы ДК была реалистичной, в ее составление нужно участие непосредственных исполнителей.
Решение - не нужно считать, что разработчиков не волнуют или они не способны понять точку зрения бизнеса. Будьте прозрачными при постановке задач, привлекайте разработчиков к формированию видения проекта и направлению его развития. Возможно, нужно просто собраться с командой и создать примерные макеты в реальном времени, переосмыслить их и создать прототип. Учитывайте скрытые требования, которые могут выявить разработчики, ведь они также понадобятся для составления ДК.

Продолжаем наш #четвергобразовательный
И снами снова статья о дорожных картах.

Проблема номер 3. Каша из функций.
Каждый участник, вовлеченный в проект, может иметь собственное представление об идеальном продукте, как он должен функционировать и какие задачи решать. Задача проектного (или продуктового) менеджера собирать и записывать все поступающие требования и, при необходимости, включать их в дорожную карту. Проблема в том, что если пытаться учесть абсолютно все пожелания, то дорожная карта превратиться из слаженного путеводителя по проекту в кашу из разрозненных функций. Включение в ДК слишком проработанных или, наоборот, неосуществимых задач может привести к печальным последствиям.
На начальном этапе команда может чувствовать себя более уверенно из-за видимого горизонта работы. В дальнейшем, во время непосредственной реализации, поставленные задачи могут проявить себя с худшей стороны - причины их появления окажутся необоснованными, а реализация - невозможной. И тогда настанет момент разочарования о напрасно проделанной работе.
Для предотвращения подобной ситуации преодолейте соблазн наполнить проект функциями, как много бы различных требований на вас не сыпалось. Если заказчику трудно отказать, то составьте отдельный списков всех пожеланий, проведите его обзорный анализ. Включите в итоговый список только те требования, которые действительно необходимы для решения задач пользователей и могут быть реализованы в рамках отведенных сроков. Причины исключения требований из итогового списка предоставьте заказчику.
Также составление списков всех пожеланий — это не только способ умерить пыл заказчика, но и возможность рассмотреть видение проекта с различных сторон.

Комментировать можно в нашем ВК, куда статья будет продублирована. https://vk.com/it2g_moscow

Итак, мы обсудили способы саботажа, которые любят использовать незаинтересованные в успехе госзаказчики. Поговорим немного о том, как с этим жить и идти к успеху через тернии.
1.Неуловимый руководитель. Ситуация, когда ответственный за проект вечно занят, а решения принимают его замы и замы замов, весьма часты. Общая рекомендация борьбы с этим, к сожалению, одна – нужно готовить руководителя к совещанию сильно загодя. Посылаем ему письма, настаиваем на необходимости его присутствия, начиная за неделю до совещания.
2.Перетягивание экспертизы на сторону заказчика. Очень важно помнить, что эксперт вы и ваша команда. Если вам не удастся доказать и показать это заказчику, велика вероятность, что заказчик перетянет экспертизу на себя, что влечет за собой риск падения в бесконечные правки и затягивания сроков.
3.Отсутствие взаимопонимания. Практически всегда в этом виноват не заказчик. Злоупотребление процессами и нотациями, сложными терминами, в которых заказчик не разбирается, но не признается в этом, заводит нас в ситуацию, когда представления о результате у исполнителя и заказчика расходятся. Рецепт простой – продвижение должно быть пошаговым, иллюстрации и презентации максимально понятными. Все вопросы к заказчику лучше сводить к закрытым, требующим определенного ответа «да» или «нет».
#работасгосзаказчиками
Оставайтесь на линии. Если у вас нет технической возможности, статьи дублируются в ВК https://vk.com/it2g_moscow

Всем доброго конца четверга! Умиротворяющее и познавательное чтение на ночь от нашего аналитика Николая Бебкова и Кассандры Найджи. Поскольку наша любимая тележенька сегодня долго запрягалась, мы немного опоздали с познавательным. Просим понять и простить!

При планировании проекта легко попасть в ловушку своих амбиций. Вариантов развития проекта может быть множество, и возникает желание реализовать идеальный продукт. Проект, который решит задачи пользователя на 10 шагов вперед, и избавит от проблем, о которых пользователь в настоящий момент даже и не задумывается.
В этом и заключается вторая проблема - команда фокусируется на грандиозных решениях без понимания реальных проблем конечного пользователя. Заканчивается это ситуацией, когда разработка идет полным ходом и ресурсов на разворот проекта к исходной проблеме уже не остается.
Для реализации эффективного решения необходимо понимать причину, по которой возникла потребность в создании продукта. Понимание проблем пользователя должно быть в основе составления дорожной карты. Иными словами, мы составляем дорожную карту проблем, а не решений.
Процесс разделяется на этапы:
1. Команда исследует и выявляет основную проблему в работе пользователя. По итогам создается минимально жизнеспособный продукт (MVP).
2. Далее процесс может уйти в привычное состояние. Новые решения внедряются и испытываются на пользователе.
Поскольку основная головная боль заказчика уже в прошлом, проект может позволить некоторые инновации. #четвергобразовательный