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

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

Анализ и управление - Управление проектом

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать 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 в Москве.

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

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

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

См. также

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Управление проектом Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    3655    MariaTemchina    28    

18

На что похож ваш продукт: на Аквариум или на Муравейник? 

Управление проектом Бесплатно (free)

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

27.12.2022    1809    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    2173    user1576201    10    

16

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    9947    Evil Beaver    17    

99

Технология вялых проектов

Управление проектом Бесплатно (free)

Не все ж такие молодцы.

11.05.2022    4633    1c-intelligence    49    

41

1С-ники могут все, но они не могут все сразу. Рекомендации по внедрению Канбан-системы для проектов 1С

Внедрение ИТ-системы Управление проектом Бесплатно (free)

Директор по проектам Инфостарт Мария Темчина на конференции Infostart Event Post-Apocalypse делала большой доклад о внедрении Канбан-систем. В преддверии старта курсов Марии по управлению ИТ-проектами редакция Инфостарт решила поделиться с читателями докладом о работе ИТ-команд с Канбан. В статье вы узнаете, зачем внедрять такую систему работы, и как она помогает договариваться разработчикам и бизнесу.

22.04.2022    3209    MariaTemchina    1    

18

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

При формировании проектной документации под конкретного заказчика важно использовать в качестве основного источника информации автоматизируемые бизнес-процессы. О том, как такой подход позволяет соблюсти правило полноты и непротиворечивости информации на митапе «Бизнес-аналитик. Роль в команде, компетенции, инструментарий» рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

02.02.2022    9145    denisgalimoff    3    

23

7-ой PMBOK® Guide: Есть ли там что-то действительно полезное?..

Управление проектом Бесплатно (free)

Честно скажу, я всегда с некоторой настороженностью открываю разные "чересчур умные" книжки. Особенно их переиздания (в данном случае аж 7-ая версия). Ибо очень часто разрыв между высокими концепциями и реальностью оказывается чересчур огромным (особенно в этом плане меня позабавил катастрофический непонятный вебинар на тему понимания).

07.09.2021    9066    MariaTemchina    0    

20

Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

Управление проектом Бесплатно (free)

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    9097    MariaTemchina    13    

23

Как приручить драконов. История построения экосистемы на основе 1С

Управление проектом Бесплатно (free)

Многие задачи интеграции и мониторинга не имеют стандартных решений в среде 1С. О том, как команда 1С-ников смогла организовать успешный симбиоз учетной системы и системы тысяч внешних устройств, на INFOSTART MEETUP Новосибирск.Online рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.

14.05.2021    4544    G.Shatrov    6    

19

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

Управление проектом Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    7652    MariaTemchina    86    

27

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

Управление проектом Бесплатно (free)

Как знает большинство старожилов Инфостарта, я люблю устраивать разного рода онлайн-обсуждения. И эта статья написана как раз по итогам такого рода вебинара-дискуссии. 

16.02.2021    4526    MariaTemchina    45    

33

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

Управление проектом Бесплатно (free)

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    4896    MariaTemchina    17    

25

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

Управление проектом Бесплатно (free)

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

10.02.2021    6307    andironenko    17    

52

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

Управление проектом Бесплатно (free)

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

09.12.2020    3014    MariaTemchina    3    

30

Что почитать про Agile для чайников?

Управление проектом Бесплатно (free)

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    6287    MariaTemchina    9    

34

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

Управление проектом Бесплатно (free)

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    7820    MariaTemchina    9    

26

Как создать коробочный программный продукт

Управление проектом Бесплатно (free)

Создание коробочного продукта – процесс нелегкий и долгий. Помочь разработчикам, которые только начинают свой путь в этом направлении, решил Сергей Сорокин – основатель компании MoscowSoft, которая входит в топ-3 компаний-продавцов коммерческих продуктов на Инфостарте. Сергей рассказал, как выбрать и протестировать идею, объяснил, стоит ли бросать наемную работу ради собственной разработки, и поделился опытом, как Инфостарт помогает при продвижении продукта и в борьбе с пиратами.

05.10.2020    4447    primat    2    

25

Стыд и Скрам: взгляд глазами собственника из IT-шников

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    5720    IvanAT1981    5    

20

Советы начинающим РП: Подводим итоги шляпной вечеринки 

Управление проектом Бесплатно (free)

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

15.09.2020    3446    MariaTemchina    5    

23

Как стать исполнителем в проекте от Инфостарта

Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    4372    alexandr.blinov    17    

40

Как продвигать авторские конфигурации 1С

Управление проектом Бесплатно (free)

Конфигурации 1С продвигать на рынке самостоятельно нелегко. Мало того, что нужно развивать продукт, чтобы удовлетворять потребности клиентов и выгодно отличаться от конкурентов, нужно еще заниматься его популяризацией, продажами и поиском проектов для внедрений. Большую часть этой работы готов взять на себя Инфостарт. Авторам останется только разработка, развитие и внедрение. Чем именно готов помочь Инфостарт, рассказал руководитель корпоративного отдела компании Рамин Курбанов. 

07.09.2020    3322    RKurbanov    3    

22

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    5236    MariaTemchina    30    

44

Матрица СКГ как инструмент разработки деловой модели

Управление проектом 1С:Франчайзи, автоматизация бизнеса Россия Управленческий учет Бесплатно (free)

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

24.07.2020    3721    Soliton    10    

19

Видеозаписи открытых вебинаров Марии Темчиной

Управление проектом Бесплатно (free)

В этой публикации решила собрать здесь видеозаписи открытых вебинаров с моим участием. Чтобы были в одном месте, ибо их не всегда просто найти на Инфостарте. "Всё, что вы хотели узнать...", "Лучшие морковки проектов внедрения...", "Путь джедая в управлении проектами..." и так далее.

21.07.2020    4269    MariaTemchina    1    

33

Управление в стиле Догвилль

Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    5777    1c-intelligence    17    

56

Наиболее типичные ошибки при оценке работ в проектах 1С

Управление проектом Бесплатно (free)

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

13.06.2020    3531    Koder_Line    9    

26

Как воспитать в себе РП? Часть 2. Растим ведущего руководителя проектов

Управление проектом Бесплатно (free)

Теперь поговорим про роль ведущего руководителя проектов, задающего и формирующего политику управления проектами в компании.

08.06.2020    8609    MariaTemchina    0    

20

Как воспитать в себе РП? Часть 1

Управление проектом Бесплатно (free)

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

01.06.2020    9490    MariaTemchina    4    

23

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    7317    sapervodichka    1    

56

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

Управление проектом Бесплатно (free)

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

18.05.2020    13789    MariaTemchina    34    

45

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    8366    MariaTemchina    26    

33

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

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

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

21.03.2020    5137    oleynik.dv    7    

23

Как завершать проекты в срок

Управление проектом Бесплатно (free)

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

10.03.2020    5926    VLikhobabin    6    

27

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    10999    VLikhobabin    44    

67

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Бесплатно (free)

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

23.01.2020    48354    MariaTemchina    12    

36

Каждый охотник желает знать, где сидит фазан, или управление внутренними проектами, танцуем от печки...

Управление проектом Бесплатно (free)

Статья, продолжающая цикл публикаций по классификации внутренних проектов, а вернее сказать, их отправная точка. Ибо ведение проектов происходит не в вакууме, а во вполне конкретной организации, со своим уставом и иерархией отношений. А что будет с тем, кто сунется со своим укладом в чужой монастырь, нам напомнили как раз в предновогодний вечер: "Да на кол его посадят, всего и делов." Чтобы этого не произошло с вами - присмотритесь к предполагаемому месту работы, а я с вами поделюсь очень интересной классификацией организаций от признанных гуру в этой области. Из-за этого статья пригодится как HR-менеджерам, так и из соискателям. Прошу под кат...

04.01.2020    7565    capitan    52    

24

BDDSM-практики, или 50 оттенков желтого

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

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    13377    Mistress_A    28    

80

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    7731    1c-intelligence    33    

27