Андрій Мандріка «ДО та ПІСЛЯ першого продакшену. Або специфіка управління проектом під час етапу “раннього проду» KyivPMDay 2017s
•Download as PPTX, PDF•
0 likes•83 views
Kyiv Project Management Day 2017 Spring ------------------------- Андрій Мандріка «ДО та ПІСЛЯ першого продакшену. Або специфіка управління проектом під час етапу “раннього проду» ------------------------- Сайт конференції: http://pmday.org/ Спільнота в мережі Linkedin: http://bit.ly/PMDayLin Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB Twitter конференції: https://twitter.com/LvivPMDay
Recommended
Recommended
More Related Content
More from Lviv Startup Club
More from Lviv Startup Club (20)
Андрій Мандріка «ДО та ПІСЛЯ першого продакшену. Або специфіка управління проектом під час етапу “раннього проду» KyivPMDay 2017s
- 1. Мандрика Андрей Project manager, ДО и ПОСЛЕ первого “продакшена”. Или специфика управления проектом во время этапа Внедрения ПО.
- 2. Что такое «Этап внедрения ПО»? Внедрение программного обеспечения — процесс настройки программного обеспечения под определённые условия использования, а также обучения пользователей работе с программным продуктом. (с) Wikipedia
- 3. Ценность от внедрения нового ПО. Ценность Время Старое ПО Новое ПО Release t>0
- 4. Минимально рабочий продукт (MVP) • MVP - это версия продукта, позволяющая запустить цикл «создать-оценить-научиться» с минимальными усилиями, потратив как можно меньше времени на разработку. • Может не соответствует традиционным представлениям о качестве. • Если сомневаетесь – упрощайте.
- 5. Модель удовлетворенности потребителя «Модель КАНО» Пять типов эмоциональной реакции Кано: • Привлекательные характеристики • Одномерные характеристики • Обязательные характеристики • Неважные характеристики • Нежелательные характеристики http://marketnotes.ru/marketing-research/kano-method/ http://www.fdfgroup.ru/?id=281
- 6. Оценочная таблица КАНО Пропорция успешного продукта: 50% обязательные, 30% одномерные и 20% привлекательные
- 7. Диффузия инноваций Роджерса Шаги процесса принятия продукта пользователями • Осведомленность • Убеждение • Решение • Реализация • Подтверждение https://habrahabr.ru/post/250949/ https://habrahabr.ru/post/251237/
- 8. Организация ранних последователей • Используем ранних последователей для проведения Beta тестирования. • Мотивируем и ставим цели. • Даем понять причастность к разработке. • Ежедневно держим руку на пульсе.
- 9. Обучение пользователей • Разговариваем с пользователями на одном ИХ языке. • Используем подходящие методы обучения для разных групп пользователей: • Презентация • Пользовательская инструкция • Справка • Видео обзор • и т. д. • Задействуем ранних последователей для пропаганды.
- 10. Организация поддержки • Относимся к любым обращениям с уважением. • Готовимся к обращениям 24/7. • Если отсутствует поддержка уровня L0-L1, то ее обеспечивает ПМ. • Логируем любые действия пользователей. • Настраиваем инструменты работы с логами (Kibana). • Организовываем дежурства разработчиков на выходных. • Проговариваем, фиксируем и соблюдаем SLA.
- 11. Performance • Заранее выявляем и согласовываем нефункциональные требования. • Внедряем метрики и постоянно мониторим их (Grafana). • Не внедряем без нагрузочного тестирования: • Системы. • Железа. • Планируем тестирование производительности как любой другой вид проектной деятельности.
- 12. Особенности планирования во время этапа Внедрения • Квотируем задачи по типам. • Оставляем буфер на ошибки с прода (up to 100%). • Не разрабатываем новый функционал пока не стабилизируем текущее состояние. • Планируем маленькими поставками (lead time = min). • Учитываем риски при планировании. • Морально готовимся к изменению планов.
- 13. Варианты процесса • Скрам с «поправками на ветер». • Канбан – лучше всего подходит под операционную деятельность. • Скрамбан – совмещает возможность «операционки» и планируемой разработки. • Поставки по самой большой задаче. 8 sp 5 sp 3 sp 2 sp 3 sp 1 sp 1 sp 0.5 sp
- 14. Команда • Ничего не скрываем от команды. • По максимуму принимаем общекомандные решения. • Излишне не давим. • Культивируем командную ответственность за результат. • По возможности меньше переключаем контекст. • Хвалим публично, ругаем лично.
- 15. Как и когда сказать СТОП? • Фиксируем дату приемки конечного результата. • Двигаемся по согласованным приоритетам. • Не обещаем свыше своих сил. • Визуализируем цель (milestone) и считаем прогресс.
- 16. Спасибо за внимание! Andrii Mandrika Project manager Contacts: • andrii.mandrika@gmail.com • andrey.mandrika@betlab.com • linkedin.com/in/andrii-mandrika • Skype: mandrikaandrew «Нельзя вернуться в прошлое и изменить свой старт, но можно стартовать сейчас и изменить свой финиш» (с) Рой Джонс
Editor's Notes
- Всем добрый день. Меня зовут Мандрика Андрей Тема моего сегодняшнего доклада звучит как «ДО и ПОСЛЕ первого “продакшена”. Или специфика управления проектом во время этапа «Раннего Прода»». Вот так вот немножечко непонятно, но я сейчас постараюсь объяснить. Ранний прод – в классическом проджект менеджменте – это этап внедрения разработанного программного обеспечения. И как правило, ему не уделяют должного внимания. Многие думают, только о самом этапе разработки. А как потом внедрять созданное чудо – та это уже не моя ответственность. Но это огромная ошибка. Данным этапом надо управлять и его надо заранее планировать. Почему? Да потому что именно по завершении данного этапа судят, успешен ли проект или нет. И большинство проджект менеджеров только здесь по настоящему понимают, какой продукт стоило создать. Поэтому сегодня я хочу рассмотреть с вами, во первых, что же это за этап такой? как нам дойти до внедрения, и как сделать это как можно быстрее, а также что необходимо предпринять, чтобы он прошел быстро, бесболезненно и вам потом не снился вам в ночных кошмарах. Сразу скажу, что сегодня мы поговорим о по большей части продуктовой разработке, и соответственно и внедрять мы будем нашим конечным пользователям собственноручно разработанные с нуля программные продукты. Например, ситуация в моих проектах следующая. Есть работающий бизнес, который использует огромную монолитную платформу, что разрабатывалась последние 15 лет. За эти годы менялася и сам бизнес. И хотим мы этого или не хотим, но в определенный момент бизнес процессы в организации стали диктоваться именно этой платформой, которая на тот момент уже стала абсолютно не модифицируемой. А выживает в современном мире не самый сильный, а самый приспособленный. К сожалению, старая платформа не смогла приспособиться к современным условиям. И вот у нас встала амбициозная задача переписания и внедрения отдельных частей новой программы в уже существующий бизнес. То есть в нашем случае абсолютно недостаточно было только разработать новую программу. Какая бы плохая, по словам пользователей, не была старая программа, но они все же к ней приросли. Тем более что некоторые пользователи работали с этой программой все 15 лет и не видели ничего другого. И поэтому впереди нас ждала долгая эпопея вырубания этих крепких корней и посадку новых и зеленых ростков в благоприятную почву.
- Итак начнем. Так что же это за этап такой -Внедрение? Википедия нам предлагает следующую интерпретацию. Ключевыми же словами тут являются Настройка и Обучение. Существует конечно внедрение без какой-либо из этих составных частей. Но все же, как правило, даже в абсолютно идентичных бизнесах возникают абсолютно разные запросы. Да что уж тут говорить, даже люди все разные. Но этап внедрения разработанного по ни в коем случае не означает окончание активной фазы. А даже наоборот, именно внедрение по и начало его использования стимулирует разработку больше всего. И именно в аджайл методологиях отдача готового инкремента конечным пользователям запускает новый цикл разработки. Или же как в Лин стартапе – цикл Создать, Оценить, Научиться. Тут конечно же надо добавить Внедрить, Оценить – научиться. И именно этот цикл позволит в итоге отдать пользователям тот продукт, который сделает их счастливыми. А для чего же мы это все далем с вами? Но как же нам все таки дойти до этого внедрения? Как нам не зафейлить наш проект по разработке и внедрению? Давайте обратимся к статистике.
- Это всем известный МВП. Вроде все просто, делаем минимально рабочую версию – отдаем и внедряем ее пользователям и на основании полученного фидбека планируем следующую версию. И так до тех пор пока мы не добьемся наших финальных целей проекта. Но не так все просто. Я видел массу примеров или неправильной декомпозиции продукта на самостоятельные версии или включение в мвп слишком большого количества функционала. Да что тут говорить, в одном из первых моих проектов – мы разрабатывали мвп слишком долго и были в полной уверенности, что даже таким продуктом мы создадим фурор. А случилось, прям вот очень показательно, как в книге Эрика Риса. После столь желанного якобы релиза в прод – пользователи даже не обратили на него внимания. А как? Ну мы же все сделали?! После этого момента у меня остался яркий отпечаток и теперь у меня язык не поворачивается сказать, что мы в проде – если продукт никому не нужен. Но этот момент тоже не прошел зря – это опыт, который помог осознать какие действительно продукты необходимо разрабатывать, и что даже после разработки надо активно работать для внедрения вашего решения. Очень показательным является вот эта иллюстрация от Генриха Книберга, что такое МВП. Она присутствует практически во всех книгах по гибкой разработке ПО. Но насколько же точно она изображает произошедшее. Особенно показательна верхняя часть. В моей памяти была и есть одна знакомая команда, которая постулировала ценности аджайла, упорными силами делали мвп, версия за версией. НО! Каждая новая версия – была всего лишь новым модулем огромной платформы. А вся платформа могла полноценно работать только имея все необходимые модули. В этом случае надо было конечно использовать нижнюю стратегию разбить не в глубину а в ширину. В каждой версии сделать хотя бы самый минимальный функционал, но который бы позволил пройтись по всему бизнес флоу и в конце концов внедрить данное решение. Но есть и еще один кейс, когда вы вроде разбили все версии продукта на правильный функционал, разработали его, выдали, а он ничем ни лучше их старого решения. Вот вроде бы все есть, но у нового продукта нету фишки, нету конкурентного преимущества. А внедрить такой продукт можно только насильно приказом сверху. Поэтому я каждый раз когда необходимо сформировать композицию функционала для нового продукта пользуюсь отличным методом.
- Это так называемая модель КАНО, или модель удовлетворенности потребителя. Метод, используемый для оценки эмоциональной реакции потребителей на отдельные характеристики продукции. Полученные с его помощью результаты позволяют управлять удовлетворенностью и лояльностью потребителей. На самом деле все очень просто. С помощью данного метода можно любой функционал отнести к одному из 5 типов эмоциональной реакции человека. Привлекательные характеристики – розовый рог. Привлекательные характеристики (если они присутствуют в продукте) вызывают чувства удовлетворения и восторга. Однако если этих характеристик нет, то пользователи не испытывают неудовлетворения. Привлекательные характеристики являются неожиданными, они удовлетворяют ранее неудовлетворенные потребности. Вот именно они и формируют инновацию и конкурентное преимущество. Это про них говорят, ВАУ. Одномерные характеристики – желтая линия. Эти характеристики вызывают удовлетворение (если они есть) или неудовлетворение (если их нет). Например, и чем лучше реализована характеристика, тем больший эффект она принесет. К этой категории можно отнести простота использования, стоимость, ценность развлечения и безопасность. Обязательные характеристики – синяя линия. Эти характеристики, по мнению потребителей, относятся к группе тех качеств, которые обязательно должны присутствовать в продукте. Усиление обязательных характеристик постепенно приводит к замедлению роста эмоциональной реакции. Неважные характеристики - Наличие неважных характеристик вызывает неоднозначную реакцию пользователей, но, в целом, им все равно, присутствуют такие характеристики в продукте или нет. Отдача от вложений в такие характеристики – низкая. Нежелательные характеристики - Наличие в продукте нежелательных характеристик сводит на нет положительное влияние привлекательных и одномерных характеристик.
- А отнести весь функционал к той или иной характеристике можно с помощью вот такой простой таблички. Где по каждому функционалу задается 2 вопроса, один отрицательный, один положительный. Пересечение 2 ответов и позволит вам определить тип характеристики. В моей практике, та и в практике тех людей которые используют данный инструмент для отбора первоначального функционала для мвп, наилучшим успехом было включение функционала в версию в следующей пропорции 50% обязательные, 30% одномерные и 20% привлекательные. Но рекламировать и ставить акцент вы должны именно на привлекательных характеристиках. Ибо соотношение 20 на 80 еще никто не отменял.
- Но можно расширить данную классификацию пользователей использовав работу Эверетта Роджерса. Который проводил маркетинговые исследования вывода новых продуктов на рынок еще в середине 70х годов. Но полученные данные актуальны и до сих пор. Диффузия инноваций (diffusion of innovation) – это процесс распространения новшеств в обществе, закономерности распространения новых продуктов, технологий, идей среди потенциальных потребителей (пользователей) с момента их появления. Назван по аналогии с диффузией в физике — процессом взаимного перемешивания молекул различных веществ в смеси. В основе модели Э.Роджерса лежит сегментация потенциальных потребителей инновации по признаку индивидуальной предраположенности к восприятию инновации, в которой выделяется 5 сегментов. Нас тут больше всего интересует сегмент ранних последователей, которые могут стать двигательной силой при внедрении вашего продукта. Это конечно в том случае если вы их правильно организуете. Но вы можете спросить, а почему же не Инноваторы? Тут есть как минимум 2 причины: 1) То что инноваторы хоть и готовы хвататься за все новое, но им важен только сам факт новизны. А практическое применение данного инновационного продукта отходит на второй план. И 2е то что их всего 2.5 процента от общего количества пользователей. Ранние последователи же помимо привлекательности новизны видят в продукте непосредственно новую конкурентную возможность при использовании а практике. Поэтому такие люди – это именно то, что поможет распростронить знания об вашем продукте на остальные сегменты пользователей.
- В нашей работе мы сразу же распознаем таких пользователей и организовываем их в такой себе отдел для проведения бета тестирования новых продуктов или функций. Это обязательно должны быть люди которые заинтересованы в использовании вашего продукта в перспективе. В идеале, если мы пытаемся внедрить новое программое обеспечение в уже существующий отдел бизнеса. То таких людей надо находить именно из этого отдела. Конечно же такие решения стоит принимать через их руководителя, возможно даже как-то дополнительно их поощряя. Но не обязательно. Самое главное – это поставить им такую же цель как и вам – внедрить новый продукт в бизнес процесс. И к мнению этих людей стоит прислушиваться. Вам надо показать им, что у них не только есть конкурентное преимущество перед другими сотрудниками своего отдела, поскольку они используют новый софт с лучшими возможностями, но и то что они причастны к разработке. То что их мнение действительно влият на процесс принятия решений. Таким образом, когда вы соберете такую движущую силу наполненную энтузиазмом – они начнут по воле вести пропаганду среди остальных сотрудников. Типа, эй Вася, а я уже сделал свою работу с помощью нового софта, пока ты еще мучаешься в старом. У нас это именно так и работает. Вот из последнего, мы разрабатывали новое ПО для отдела из 15 операторов данных, которые работали на все той же 15летней платформе. И при инициации проекта мы сразу же провели опрос их всех с целью определения ранних последователей. Отдел состоял из очень разных людей. Некоторые все эти 15 лет работали на этом софте и очень скептически к нему относились. Но были и молодые ребята которые жаждали перемен. И как не странно, но именно они и оказались в числе ранних последователй. Сначала их было трое, потом присоеденилось еще 2. И в итоге через 2 месяца весь отдел загорелся новым софтом и таки перешел на него окончательно, отказавшись от старого. Но такого результата можно добиться только ведя постоянную работу с пользователями. И одной из основных работ является обучение
- Я не зря на этот слайд вставил картинку с детьми. Ибо все новые пользователи вашего ПО – они как эти дети. Любознательны но не всегда понимают казалось бы очевидные вещи. И работать с ними надо соответствующе. Не используем технические термины при общении с пользователями. «Почему мне не отображается тут вот эта информация? – Потому что она нам не пришла в фиде». Да среднестатистический оператор или кассир знать не знает что такое фид. И даже если пользователь спросил у вас несколько раз одно и тоже – это не значит, как правило, что он глупый. Это означает только лишь то, что вы не можете нормально объяснить. И вообще очень хорошо использовать ДДД практику в разработке. Которая говорит нам, что все термины из повседневной жизни ваших пользователей – или из их домена должны быть перенесены непосредственно в код. Таким образом вам не придется каждый раз переводить названия пользователей на название объектов в коде. И это тоже способствует улучшению взаимопонимания. Затем обязательно выбирайте нужный вид обучения. Это зависит от многих факторов. Есть пользователи, которым не надо выдавать подробную пользовательскую инструкцию, потому что в их команде уже есть наш засланный ранний последователь, который может ответить на все вопросы. Если же так получилось, что такого человека там нету – то поедьте сами туда и расскажите им это все. Или же на пару неделек пропишить у них там – заодно и лучше поймете их обыденные проблемы. Конечно не у всех это возможно в зависимости от специфики вашего продукт и териториального расположения ваших пользователей. В таком случае нужно пользоваться удаленными средствами обучения. Например, мануалы, видео обзоры, презентации и т.д. Но конечно эффект от них будет ниже чем при живом общении. Плюс при живом общении вы можете лучше подготовить пользователей к тому моменту, что на этапе вашего раннего прода будет огромное количество всевозможных дефектов. И какой бы у вас не был уровень автоматизации – все проверить поначалу просто невозможно. И это даже с учетом того, что новая программа содержала еще достаточное количество разнообразных дефектов и недоработок.