Придет владелец продукта и решит все вопросы бизнеса!

Публикация № 1269667

Методология - Методология управления разработкой - Agile (XP, SCRUM, Канбан)

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

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

 

О себе

 

 

Я партнер компании ScrumTrek, которая одна из первых в СНГ начала помогать компаниям применять Agile. Наша компания большая, и мы в основном помогаем бизнесу не внедрить Scrum, а стать более гибким, может быть, даже сильно гибким в современных условиях. Какие именно инструменты мы применяем, зависит от компании, от возможностей, от наличия определенных ресурсов и компетенций.

Очень много времени мы работали в основном с ИТ-индустрией, но в последнее время мы видим растущую популярность Agile, Scrum и подобных подходов – к их использованию переходят не только ИТ-компании, но и другие отрасли.

  •  лет 5-6 назад в этом направлении начали двигаться банки;
  •  последние 3-4 года туда двигаются телекомы и производственные компании;
  •  и совсем новые тренды – это ритейл-компании и строительство.

 

Владелец продукта (product owner) – это роль Scrum Framework

 

Начнем с роли владельца продукта. Это – роль, которая появилась во фреймворке Scrum. До этого были различные другие роли – продуктовик, продуктолог, продукт-менеджер. Но роль владельца продукта вошла в обиход, и сейчас от нее ждут очень разных вещей, иногда очень странных.

Об истоках появления этой роли я сейчас более детально расскажу и расскажу, какие ошибки допускает эта роль.

 

 

Я не буду рассказывать про отличия подходов Agile и Водопад, я только скажу, что мы теперь работаем не большими длительными циклами, а запускаем Agile для того, чтобы сократить Time-to-Market.

Основная цель этого – ускорить производство. Представьте, у вас есть производство. Это может быть ИТ-производство, может быть страховое производство, может быть строительное производство, и вы хотите быстрее делать продукт.

Чтобы делать продукт быстрее, мы все долгие этапы пытаемся сократить и в команду включаем все необходимые роли. Это получается дороже, но мы сокращаем время.

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

И пользователь потихоньку из несчастного человека превращается в счастливого. А иногда он остается где-то посередине.

 

Дам краткую характеристику Agile-команды. Она должна быть небольшая, самостоятельная, иметь общую цель. Причем, эта цель должна быть бизнесовая.

Команда должна быть стабильной. Чтобы собрать команду, нужно время. В среднем становление команды занимает 3-6 месяцев. Поэтому если вы делаете короткие проекты, какие-то быстрые с уникальными наборами компетенций возможно формировать стабильную команду не рационально.

 

Ошибка № 1

 

 

Когда мы собираем Agile-команду, мы сокращаем время производства за счет того, что собираем все эти компетенции вместе и вводим в команду уникальную роль Владельца продукта.

Владелец продукта - человек от бизнеса. Но бизнес привык работать по-старому и говорит: «Я заказчик, и вы делаете то, что я сказал». Команда соглашается – это же заказчик так сказал. В данном случае это антипаттерн. Владелец продукта – это не заказчик, это представитель заказчика внутри Scrum команды.

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

 

 

На слайде показан пример структуры кроссфункциональной команды.

Кроссфункциональная команда – это не все компетенции, еще нужен бизнес заказчик внутри команды.

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

Чтобы этого не было, мы помещаем внутрь команды представителя бизнеса.

 

 

Представьте: есть Product Owner, он посередине, но есть заинтересованные лица, есть пользователи и есть ваша кроссфункциональная команда.

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

 

 

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

Product Owner является балансировщиком между задачами пользователей и заинтересованных лиц. Ведь пользователи и заинтересованные лица – это всегда два лагеря.

Простой пример из жизни Facebook:

  •  акционеры (заказчики) хотят, чтобы в соцсети было много рекламы;
  •  а пользователи говорят: «Если будет много рекламы, мы этим пользоваться не будем».

И здесь нужно соблюсти баланс: и заказчиков удовлетворить, и пользователей.

Другой пример – про гостиницы.

  • Заказчики хотят много клиентов, много денег, поэтому строят большие гостиницы и делают большие комплексы, экономя на стенах и чем-то еще.
  • А потребитель хочет, чтобы в комнате у него было тихо, чтобы соседи не кричали, чтобы во время завтрака не надо было стоять в больших очередях.

В случае 1С пример, наверное, будет таким:

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

В продвинутых западных странах фокус владельца продукта последнее время смещается в сторону Customer Value (потребительская ценность): когда мы удовлетворяем больше ожиданий пользователей, пользователи довольны, они приносят больше денег. В российских реалиях, к сожалению, пока мы двигаемся в другую сторону: мы пытаемся сделать бизнесовые задачи, не задумываясь о пользователях. Но этот тренд, я думаю, со временем все-таки уйдет, а пока мы немножко отстаем.

 

Ошибка № 2

 

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

 

 

 

Но в этом случае создается не очень здоровая среда. Все заказчики понимают, что крик позволяет приоритизировать задачу и поднять ее выше, и через какое-то время все начинают кричать громче, и момент нагнетания обстановки растет. Роль Product Owner в том, что он должен эту проблему решить, у него должен быть инструмент, который позволит рассчитать, как получить максимальную ценность.

 

 

Я дам простой инструмент приоритизации задач, который сейчас на рынке используется очень часто.

  • Допустим, есть комбайны на разной степени готовности – в первом случае доделать комбайн стоит 1 день, во втором – 3 дня, а в последнем – 10 дней. Но стоимость доделки одинаковая. Какой комбайн мы первым возьмем в работу? Первый, конечно! Все логично: чем быстрее сделаем, тем быстрее деньги получим.
  • Другой пример. Представьте, что любая работа занимает три дня, но бизнес-эффект разный. Какой комбайн возьмем в первую очередь? Тоже первый, потому что все сделаем за 3 дня, но денег мы получим за работу больше.

Независимо от того, используете вы Agile или не используете, есть такой способ приоритизации работ, как WSJF — Weighted Shortest Job First, когда стоимость задержки делится на длительность и получается та задача, которую нужно делать в первую очередь. Это самое ценное, самое простое, то, что дает быструю отдачу.

Допустим, есть две однозначные работы: два заказчика прибежали, один просит сделать полную автоматизацию 1С, а другой – автоматизацию склада. Вроде бы, эффект получится большой, но как понять, какую работу взять первой, какую второй? В этом случае, как раз используя этот коэффициент, можете выстроить диалог с заказчиком таким образом, что мы всегда идем в сторону самых важных и самых коротких задач.

Если задача большая, длинная, но в ней есть какая-то очень большая важность, нам нужно эту работу декомпозировать – выделить ценность, а то, что не нужно, оставить где-нибудь в бэклоге умирать.

 

Ошибка № 3

 

Следующая ошибка, которую часто допускают владельцы продукта, – «они просили, мы сделали».

 

 

Ребята, а что является результатом вашей работы? Продукт? Достижение цели? А что значит достижение цели? На самом деле – получившийся результат приносит деньги.

Интересный момент. Обычно когда я спрашиваю аудиторию: «Что считается результатом вашей деятельности?» – они говорят: «Фичи, которые работают на проде». Но важно, что фичи не просто стоят на проде, ими еще и пользуются. Это важная цель. Потому что бывает так, что фичи поставили, но никто ими не пользуется.

У меня есть пример одного большого ритейла. Они как раз делают Big Data, BI и все, что с этим связано. Раньше они делали аналитические отчеты, и за последние 5 лет у них накопилось их очень много. Чтобы поддерживать это, у них работает целый отдел на 80 человек. Представляете, сколько отчетов! В итоге они поняли, что так жить нельзя, потому что на создание нового отчета уходит минимум полгода, из-за того, что, делая один, они ломают все остальные. Начали разбираться. Оказалось, 70% отчетов, которые они сделали, пользователи открывали всего 1 или 2 раза. Или вообще, тот заказчик, который заказывал этот отчет, в компании уже давно не работает.

Поэтому еще одна очень важная задача, которую должен делать Product Owner, – не допустить того, что работа, которую делает команда, будет лежать на складе. Он должен выпускать только самое важное и самое ценное.

Команда разработчиков занимается, по большому счету, производством, и это – самое узкое звено, если вы загружаете самое узкое звено ненужной работой, то вы, как бизнес, теряете деньги.

 

 

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

 

Ошибка №4

 

Следующий важный момент – бывает так, что заказчик хочет все и сразу.

 

 

Владелец продукта приходит и говорит: «Ребята, заказчик хочет сразу готовый лимузин. Мы ему предлагали сначала велосипед, а он говорит – нет, сразу лимузин, я вам дал денег на лимузин, поэтому дайте мне лимузин».

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

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

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

 

 

Причем, из большого продукта надо вытащить сначала самое-самое ценное. А в некотором случае нужно сначала проверить технические возможности, потому что не всегда можно сделать что-то сразу, иногда сначала нужно сделать ходячий скелет, прототип, а потом двигаться к Minimum Viable Product (минимальному ценностному продукту).

Очень важно понимать, что если заказчик просит сразу пончик с посыпкой, мы не будем строить фабрику, которая сначала производит посыпку, потом делает пончики. Иначе, когда мы начнем выпускать и продавать эти пончики, может оказаться, что на этом рынке уже 10 компаний, которые занимаются тем же самым, и уже нет ни одного потребителя, а мы построили завод. Все это как-то нелогично. Поэтому надо понять, есть ли спрос, и принесете ли вы ценность, выпустив такой продукт.

 

 

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

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

 

Ошибка № 5

 

Еще одна ошибка, которую Product Owner не должен допускать. Я слышу часто тезис: «мы не должны ошибаться». Да, мы приоритизировали, и то, что мы сделали – это очень важно, очень ценно. Но вдруг мы допустили ошибку?

 

 

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

 

 

Поэтому Product Owner должен уметь ошибаться. Но должен ошибаться очень правильно: чем быстрее и дешевле он ошибется, тем лучше. Если мы ошибаемся быстро, мы ошибаемся бесплатно. Не всегда так получается, но в любом случае мы экономим время производства. Кроме того, мы не попадем в сложные моменты в процессе сдачи и внедрения системы.

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

Некоторые компании доходят до того, что выделяют небольшой бюджет на ошибку. Делается это для того, чтобы команда научилась ошибаться, чтобы команда поработала чуть-чуть, поняла, что бежит не туда и не потратила много-много денег.

 

 

Кстати, есть такой инструмент – бережливый стартап (цикл Lean Startup). Наверное, многие о нем слышали. Он позволяет Product Owner научиться работать по-новому, ошибаться, проводить эксперименты. Потому что его эффективная работа заключается в том, чтобы за минимальное время проверить много гипотез, сэкономить много-много денег и не загрузить команду бесполезной работой.

За счет экспериментов Product Owner сможет найти самое ценное, самое важное и вырастить это до уровня хорошего полноценного продукта.

 

Выводы для владельцев продукта

 

 

Давайте резюмируем:

  • Product Owner – это специальная роль в Scrum-командах для того, чтобы объединить бизнес и айтишников (производство). Если вы настоящий Product Owner, вы часть команды, вы работаете с командой.
  • Product Owner должен быть не просто владельцем продукта, он должен уметь выстроить систему приоритизации, которая позволит бизнесу эффективно развиваться. Он должен учитывать интересы и заказчиков, и потребителей, но в то же время должен получать самую высокую ценность.
  • Надо фокусировать команду на самое-самое ценное и самое-самое важное.
  • Product Owner необходимо научиться декомпозировать работу вместе с командой. Я часто встречаюсь с ситуацией, когда команда не может декомпозировать большую задачу, они хотят выполнить ее полностью и получить результат. Но, по моему опыту, в 95 случаях работа декомпозируется. Есть много техник, которые позволяют это сделать.
  • И самое главное – научитесь ошибаться. Но научитесь ошибаться дешево. И чтобы научиться ошибаться дешево, иногда вам, как владельцу продукта, не получится это сделать. Поэтому в больших современных компаниях под Product Owner создается еще одна целая команда, так называемая Discovery Team, которая занимается тем, что помогает Product Owner ошибаться эффективно, выстраивать набор гипотез и валидировать их на рынке.

Вы считаете, что Product Owner нужен, чтобы запускать пилоты? Желательно, чтобы пилотов не было, лучше продать то, чего еще нет. Лучше сначала надо вытащить ценность для пользователя, понять, что ему нужно: может быть ему нужна не автоматизация, а сокращение каких-то процессов или что-то еще. Идеально, если вы можете выращивать пользователя под себя. Но это не всегда возможно.

У Product Owner есть 3 основных направления, где он может черпать идеи:

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

 

 

Интересный момент. Предыдущий докладчик говорил, что фреймворки Scrum тяжело использовать в 1С. Но я хотел бы вам сказать другой факт. У меня есть команды, работающие в 1С, и они более эффективно внедряют Scrum, чем другие команды. Потому что в командах, внедряющих 1С, нет выделенных ролей (например, как в банках, где человек может быть только аналитиком). В командах 1С-ников аналитик чаще всего раньше был программистом, он в этом больше понимает.

Поэтому если 1С-команды хотят двигаться в Scrum, то чаще всего у них получается. У меня есть порядка 10 эффективных Scrum-команд, которые работают на 1С. Есть даже один большой вендор, у которого 5 команд 1С-ников, самый большой ритейл на 1С. Все они работают по Scrum, и все хорошо.

Единственная проблема – одна из пяти команд так и не научилась оценивать в условных единицах, а остальные четыре работают нормально. И Product Owner там сильные.

Кстати, вырастить сильного Product Owner в большой компании – это проблема. Ее решают следующим образом: есть люди, которые понимают в бизнесе, и они хотели бы найти тех людей, которые могли бы работать с командой и доносили бы ценности бизнеса до команды. Такие люди есть. Но обычно проблема в том, что рынок пока только развивается в этом направлении, и людей, которые бы работали с командами, практически нет. Сейчас на эту роль обычно берут аналитиков, и это все печально.

 

Вопросы:

 

  • Какие конкретные приемы вы можете порекомендовать для формирования требований к MVP? Мои заказчики почему-то всегда хотят все и сразу. Возможно, только мне попадаются такие заказчики. Порекомендуйте, пожалуйста, конкретные приемы общения, выделения, категоризации и приоритизации.
  • Первый инструмент. Обычно, когда мы работаем с заказчиком, мы чаще работаем с тем человеком, кто будет принимать продукт. Как я уже раньше говорил, когда мы работаем в Agile-подходе или, как его сейчас называют продуктовом подходе, на старте Product Owner должен сформировать карту стейкхолдеров, понять, кто у него будет принимать продукт, кто у него потребитель и будет использовать продукт, кто заинтересован в создании ценности. Обычно мы идем от того заказчика, кто будет принимать продукт, а надо найти тех людей, кто будет заинтересован в создании этой ценности. Вот с ними можно работать. Среди тех пользователей, которые работают ниже, можно выделить две категории. Если вы делаете работу, которая спровоцирует их сокращение, они не заинтересованы в создании ценности. Но если это позволяет им достичь какого-то результата, то с этими пользователями можно работать. Это первый шаг, с чего можно начать. А потом уже проводить интервью с человеком, который заинтересован в создании ценности, с ним можно говорить о деталях.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Оставьте свое сообщение

См. также

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    10293    MariaTemchina    33    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    2704    oleynik.dv    7    

Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Некоторое время назад я публиковала статью, где начала разбираться, что следует из Agile-манифеста на практике, и каковы сильные и слабые стороны происходящего. В одну статью всё не поместилось, и сегодня попробую закончить эту тему. 

06.09.2019    5993    MariaTemchina    10    

Agile в ИТ-проектах: где-то между невозможно и неизбежно

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Приглашаем к дискуссии по мотивам прошедшего вебинара на тему "Agile и не Agile"

15.08.2019    6741    MariaTemchina    40    

Scrum: серебряной пули не существует

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по Scrum в условиях, когда нет проектов, рассказал на конференции Infostart Event 2018 Education ведущий разработчик 1С одной из крупнейших торговых сетей Дмитрий Кирилкин.

12.08.2019    5217    dumsik    7    

Стыд и Скрам, часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Крик души про иллюзию внедрения Agile. Продолжаем разговор про сложности, с которыми мы сталкиваемся, когда под видом гибких технологий используются "топорные" директивные методы. По сути, мы в очередной раз сталкиваемся с извечным конфликтом "сурового менеджмента" и "творческих разработчиков"

14.03.2019    11324    MariaTemchina    47    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    9836    MariaTemchina    20    

Подходы к управлению проектами: границы применимости гибких методологий в проектах внедрения

Управление проектом Waterflow Итеративный подход Agile (XP, SCRUM, Канбан) Бесплатно (free)

В своем докладе Мария Темчина подробно рассказала про то, какие подходы к управлению проектами вообще бывают с точки зрения Project Management Institute, и какие из них применимы при руководстве проектами внедрения 1С.

21.01.2019    7480    MariaTemchina    0    

Черная книга Скрам

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    8184    Selikhovkin    4    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    8427    leobrn    11    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    10048    MariaTemchina    16    

Приоритизировали, приоритизировали, да не выприоритизировали...

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

В ответ на классическое требование "сделать всё и сразу" Agile предлагает "сделать сразу, но не всё". В этой статье я хочу поговорить о разных методах приоритизации требований.

30.10.2018    8381    MariaTemchina    47    

Построение высокоэффективной Agile-команды

Управление проектом Управление командой Agile (XP, SCRUM, Канбан) Бесплатно (free)

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    7535    askhatu    15    

Канбан в условиях российской действительности

Управление бизнес-процессами (BPM) Управление проектом Agile (XP, SCRUM, Канбан) Россия Бесплатно (free)

Слово "Канбан" слышали все, кто работает в производстве, в поддержке и в ИТ-разработках. В этой статье я попробую рассказать про Канбан подробно, обобщить принципы и опыт (мой и ближайшего окружения) по внедрению на практике этой системы с упоминанием возникающих при этом "граблей" и рекомендаций по борьбе с ними.

08.08.2018    22544    MariaTemchina    64    

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    12919    MariaTemchina    20    

Можно ли объять необъятное или чем Agile отличается от водопада?

Управление проектом Waterflow Agile (XP, SCRUM, Канбан) Бесплатно (free)

Что общего между управлением парусной яхтой и проектом по внедрению ERP-системы на предприятии? В данной статье я постаралась понятным языком описать разные подходы к проектному управлению, и разобраться при каких условиях та или иная методология может быть полезной при реализации проектов.

23.07.2018    12237    MariaTemchina    42    

Применение Agile-технологий в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Agile – это одна из методик ведения проектов. О ее практическом применении в проектах 1С пойдет речь в статье.

25.07.2017    17680    kondrat230386    35    

Agile для внутренней разработки

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Речь пойдет о том, что такое гибкие методологии. Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года).

29.09.2015    15248    askhatu    14