Как определяется приоритет задач при работе над проектом по методике Scrum

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

Agency Design

Webflow template

30/5/2024

Design

Что такое Scrum и для чего он нужен?

Методика Scrum помогает мотивировать команду, ставя общие цели. Простым и действенным стимулом может стать годовой доход. Часто встречаются случаи, когда предприятие выпускает товар, пользующийся высоким спросом, имеет отличные идеи, но не зарабатывает деньги. Почему? По логике, предприятие должно стать успешным, занять позиции на рынке. Причина в том, что разработчики не знают, каким образом реализовать товар и заработать на этом.

Сравним деятельность двух предприятий: Zappos и Pets.com. Обе компании придумали услугу, пользующуюся спросом у потребителей, нашли быстрый и эффективный метод ее реализации (обе компании занимаются поставкой товаров посредством сети интернет). Но одна из них стала успешной, а вторая лишь зря спустила деньги на ветер, не добившись ничего. Такая существенная разница в положении дел возникла из-за важного аспекта. Руководители Pets.com не смогли верно распределить приоритеты.

Диаграмма Венна в бизнесе

Одним из лучших способов отразить подобную ситуацию является диаграмма Венна.

концепция продукта

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

Бэклог. Расстановка задач по приоритетам

Предварительно составленный бэклог проекта — одна из самых важных частей методики Сазерленда Scrum. В бэклоге размещается список задач, рассортированных по важности.

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

Суть создания бэклога — наглядная демонстрация полного перечня функций и характеристик создаваемого продукта. Не всегда реализуются все задачи из бэклога, но нужно видеть максимальный перечень возможных функций. Потом из них отбираются важные, они выполняются первыми.

Здесь есть важный аспект — сортировка задач по уровню значимости и важности. Для выполнения сортировки требуется определить:

  • что самое ценное и важное для создания проекта;
  • что необходимо заказчику или тому, кто в дальнейшем будет использовать продукт;
  • что даст самую большую прибыль;
  • что легче реализовать.

Методика Сазерленда базируется на поступательной системе производства, ее называют также инкрементальной. Начинается работа с функций, приносящих прибыль, что снижает риски. Рекомендуется в первую очередь реализовать главные возможности продукта. При этом начиная работать с главной по приоритету задачей, завершите ее выполнение до полной готовности, затем покажите результаты заказчику. Можно сделать небольшую часть общей работы и показать ее клиенту.

Особенность методики Сазерленда состоит в возможности обнаружить важные, ценные функций. Если сравнить Scrum и другую методику, будет видно, что при использовании других способов управления разработкой группа, создавая продукт, не знает, какие функции действительно нужны и полезны. Это обнаруживается, когда потребитель уже начинает использовать товар. Получается, что зря тратится рабочее время, 80% усилий оказываются бесполезными и ненужными.

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

Чтобы это осуществить, нужен работник, умеющий вывести общую концепцию проекта, выявить полезные и ценные функции, обработать и представить в виде историй пожелания заказчика. Те, кто работает по Scrum методике, называет этого сотрудника собственником (владельцем) товара.

Product owner

Методика Сазерленда отличает три вида сотрудников: скрам-команда, скрам-мастер и product owner. Первые занимаются процессом разработки, второй следит за процессом выполнения, третий решает, что конкретно требуется создать в соответствии с требованиями заказчика.

Product owner обязан составить список задач, рассортировать их по важности и ценности, он ответственен за итоговый продукт.

Во время начала работы в 1993 с методикой Scrum Джефф не ввел понятие product owner. Сазерленд занимался управлением процессом разработки, у него был широкий круг обязанностей. Он определял объем задач для каждого спринта, вел переговоры с заказчиками, занимался подготовкой плана проекта, организацией труда и маркетингом. На первом спринте Сазерленд понял, что нужно составить подробный бэклог с описанием историй и определением главных функциональных особенностей конечного продукта. Трудности появились на втором спринте, тогда были введены короткие собрания. Команда скрам продуктивно выполняла задуманный объем работ, перевыполняя первоначальный план на 400%. Ранее рассчитывалось, что на выполнение сделанных задачи понадобится месяц, но было сделано за первый спринт (1 неделя). Задачи, выполнением которого занималась команда, были составлены в бэклог Сазерлендом. Трудность состояла в том, что Джефф не думал, что так быстро группа справится с задачами. Он составил список с расчетом выполнения его за месяц. Теперь нужно было срочно составлять новый список. Тогда возникла идея назначить человека, несущего ответственность за составление бэклога, осталось определиться с перечнем обязанностей.

Во время размышлений о необходимости назначить ответственного за составление бэклога, Джефф решил обратиться к идеям компании Toyota, где подобный человек назывался главным инженером.

Главный инженер Toyota не может себе позволить беспричинно дать указание кому-либо выполнить задачу так, а не по-другому. Ему нужно донести сущность и незаменимость собственного мнения, привлекая не только руководителей, но и рядовых исполнителей, старательно объясняя, что выбранное направление – самое действенное.

Джефф думал, как внедрить в систему Scrum человека, которому было бы под силу исполнить такую непростую роль. Он понял, что отыскать такого работника слишком сложно. Поэтому Сазерленд решил разделить обязанности между двумя членами команды: скрам-мастером (ответственность за раздел проекта, отвечающей на вопрос «как делать»), и product owner(определяет что делать).

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

Подыскивая человека на роль обладателя продукта компании, следует искать того, кто в прямом смысле слова сможет озвучить потребности любого потребителя, проникнув в его мысли.

Владелец проекта несет прямую ответственность за сроки и результат продуктивной работы команды, дающей производственную прибыль. На протяжении многих лет Сазерленд «рисовал» собирательный действенный портрет владельца продукта, из которого вычленил все качественные и значимые обязанности, распределив их в четыре группы:

  1. Product ownerдолжен располагать полной информацией о работе. Имеется в виду следующее: во-первых, он должен быть полностью осведомлен обо всех процессах разработки, оперативно оценивать реальные возможности рабочей группы – собственно, что дается легко и исполняется быстро, а что вызывает затруднения и торможение рабочего процесса; во-вторых, необходимо прекрасно ориентироваться в назначении продукта и уметь предвидеть какими способами довести разработку проекта до результата, отражающего реальную стоимость. Помимо этого, владелец продукта должен прекрасно ориентироваться на рынке сбыта, чтобы прогнозировать его текущее и последующее состояние: какая продукция в тренде на сегодняшний день и чего можно ожидать в ближайшем будущем.
  2. Product owner обязан всегда быть в зоне доступа для членов группы. По большому счету, на владельца продукта возложена всесторонняя ответственность за выполнение бэклога. Владелец продукта должен придерживаться пунктуальности в работе с подчиненными, последовательности при корректировках выполнения заданий. При отсутствии связи с ним, даже кратковременной, команда может пойти по неверному пути, приняв ошибочное решение самостоятельно. Члены команды полностью рассчитывают на владельца продукта: на его опыт, знание продукта, оценку ситуации на рынке.
  3. Product owner должен иметь все необходимые полномочия для незамедлительного реагирования при принятии важных и срочных решений. Высшему руководству компании не рекомендуется вмешиваться в рабочие процессы владельца продукта (так же, как она не вмешивается в работу команды). Наоборот, руководству, несущему ответственность за проект, необходимо всячески содействовать владельцам продукта, особенно в моменты творческих поисков и принятия важных решений при создании ключевых фрагментов продукта. Группа должна сообща и продуктивно добиваться поставленной цели. Необходимо помнить о том, что владелец продукта отвечает за эффективность результата, вычленяет и консолидирует для группы все притязания для текущего спринта, при этом у него ограничены полномочия в раздаче новых заданий некоторым участникам команды и вмешательстве в принятие решений командой.
  4. Product owner должен возложить на собственные плечи ответственность за востребованность продукта. Когда речь идет о бизнес-структуре, в формате которой реализует цели скрам-команда, очевидно, что показателем эффективности выступает прибыль. Следовательно, деятельность непосредственного владельца продукта выходит из расчета, какой процент прибыли дает каждый выполненный пункт из списка задач.ite builder that empowers you to create visually captivating websites without needing to dive into the complexities of coding.