Перевод статьи подготовлен в преддверии старта курса «Agile Project Manager в IT».
Когда я только начинал свою карьеру, программное обеспечение поставлялось в коробках. Если для вас это звучит странно, знайте, что, когда я был ребенком, мой отец приносил домой перфокарты, на которых программы записывались в 1970-х. У такого программного обеспечения было конечное состояние. Через 20 лет с того момента это уже казалось нелепым. Сегодня же мы создаем системы, которые можно совершенствовать бесконечно. Отсюда возникает вопрос: «Когда работа заканчивается?» — и на этот вопрос сложно дать ответ. Мы ищем ответ на этот вопрос, потому что он поможет нам дать ответ на другие, еще более важные вопросы. Получит команда свою премию или ее отчитают? Будет ли команда заниматься чем-то новым? Получит ли стейкхолдер свою выгоду?
Команды разработчиков, которые используют Scrum (или любую другую вариацию методологии Agile), имеют четкое представление о том, когда заканчивается разработка. Часто под этим подразумевается «набор минимальных критериев, которыми должен обладать продукт/услуга для удовлетворения потребностей бизнеса». В результате все сводится к списку функций, который утверждается стейкхолдером (или product owner’ом) и на момент завершения проекта должен быть полностью выполнен. Разработчики зовут это «работает, как было задумано».
Но «работает, как было задумано» значит лишь то, что программное обеспечение делает то, что от него хотят. К сожалению, порой этого недостаточно. На самом деле это только начало разговора, который мы ведем непрерывно с нашими пользователями и клиентами. Именно постоянное совершенствование наших систем для обеспечения более качественного опыта придает им реальную ценность.
Итак, как же мы можем определить «завершение работы» для команды? Когда команда начинает заниматься новым проектом? Отсутствие ROI – хорошее место для начала, но как мы узнаем, что окупаемости нет? Ответ нам дадут клиенты. Мы смотрим на их поведение. Мы прислушиваемся к их потребностям, оцениваем, отвечают ли наши системы этим потребностям и думаем, что мы можем сделать для удовлетворения этих постоянно меняющихся потребностей. Мы называем эти метрики результатами.
И эти результаты невозможно предугадать, как невозможно предугадать поведение человека. Хорошие результаты требуют от членов команды активного взаимодействия с клиентами, чтобы уловить изменения в их поведении, причины их возникновения и возможности для лучшего удовлетворения потребностей клиентов в будущем. Хорошая новость заключается в том, что в вашей компании, скорее всего, уже работают люди, которые особенно хороши в этих аспектах – дизайнеры. Несмотря на то, что сегодня дизайнеры присутствуют почти в каждой компании, большинство из них не занимают достаточно высоких должностей, чтобы влиять на принятие больших решений. На самом деле многие из них остаются за бортом процессов Agile-разработки, заточенной под программистов и Product-менеджеров.
Интеграция дизайнеров в процесс Agile-разработки является постоянной проблемой для многих организаций. Благодаря почти 20-летнему опыту проектирования, управления и консультации продуктовых команд, я выявил следующие 5 правил, которым должна следовать команда, если хочет убедиться, что проработка пользовательского опыта (UX) успешно интегрирована в их Agile-процесс:
1. Отдельный дизайнер для каждой команды
Здесь не может быть компромиссов. Без «собственного» дизайнера в Scrum-команде у вас есть просто команда разработчиков, которая без дизайнера не сможет обеспечить надлежащий уровень качества пользовательского опыта.
2. Командные часы работы с клиентами
Это правило я узнал от Джареда Спула, который провел исследование, доказывающее, что команды, проводящие по крайней мере 2 человеко-часа каждые 6 недель, общаются с клиентами (например, принимая звонки службы поддержки, разговаривая с пользователями, наблюдая за людьми и т.д.), разрабатывают более успешные продукты.
3. Работа дизайнера – первый пункт бэклога
Вкратце: ведите единый бэклог. Разработка, контроль качества, дизайн, исследовательская работа – все это должно лежать в одном бэклоге, приоритезированном всей командой, которая эту работу выполняет. Как только работа будет разделена на два бэклога, команда выберет один из них и решит относиться к нему как к «основному», а второй просто отложит в долгий ящик.
4. Результаты в качестве фильтров приоритизации для бэклога
Я много писал о результатах (а Джош Сейден написал об этом целую книгу), но единственное, что я хочу отметить в контексте сегодняшней темы, так это то, что каждый пункт бэклога должен пройти фильтр конечных целей команды. Задайтесь вопросом: «Поможет ли эта работа в достижении цели?». Если ответ будет отрицательным, то отбросьте этот пункт.
5. Кросс-функциональное обучение
Пользовательский опыт и дизайн несут в себе множество интересных вещей, которые стоит изучить. Такие мероприятия могут проводиться дизайнерами (или аналитиками), но они должны практиковаться и посещаться всей командой. Чем больше команда может учиться вместе, тем меньше времени тратится на то, чтобы делиться полученными знаниями, и больше на то, чтобы решить куда их применить (что является более продуктивным предметом разговора для команды).
Итеративная ретроспективная природа Scrum хорошо подойдет UX и дизайн-активностям. Интеграция инсайтов клиентов в процесс работы проистекает непосредственно из Agile Manifesto (работа с клиентами и т.д.). UX и дизайн приближают нас ближе к Agile-цели клиентоориентированности и более качественному удовлетворению потребностей пользователей. Следуйте этим 5 правилам, чтобы объединить дизайн и Agile-разработку.
Узнать подробнее о курсе.
Когда я только начинал свою карьеру, программное обеспечение поставлялось в коробках. Если для вас это звучит странно, знайте, что, когда я был ребенком, мой отец приносил домой перфокарты, на которых программы записывались в 1970-х. У такого программного обеспечения было конечное состояние. Через 20 лет с того момента это уже казалось нелепым. Сегодня же мы создаем системы, которые можно совершенствовать бесконечно. Отсюда возникает вопрос: «Когда работа заканчивается?» — и на этот вопрос сложно дать ответ. Мы ищем ответ на этот вопрос, потому что он поможет нам дать ответ на другие, еще более важные вопросы. Получит команда свою премию или ее отчитают? Будет ли команда заниматься чем-то новым? Получит ли стейкхолдер свою выгоду?
Команды разработчиков, которые используют Scrum (или любую другую вариацию методологии Agile), имеют четкое представление о том, когда заканчивается разработка. Часто под этим подразумевается «набор минимальных критериев, которыми должен обладать продукт/услуга для удовлетворения потребностей бизнеса». В результате все сводится к списку функций, который утверждается стейкхолдером (или product owner’ом) и на момент завершения проекта должен быть полностью выполнен. Разработчики зовут это «работает, как было задумано».
Но «работает, как было задумано» значит лишь то, что программное обеспечение делает то, что от него хотят. К сожалению, порой этого недостаточно. На самом деле это только начало разговора, который мы ведем непрерывно с нашими пользователями и клиентами. Именно постоянное совершенствование наших систем для обеспечения более качественного опыта придает им реальную ценность.
Итак, как же мы можем определить «завершение работы» для команды? Когда команда начинает заниматься новым проектом? Отсутствие ROI – хорошее место для начала, но как мы узнаем, что окупаемости нет? Ответ нам дадут клиенты. Мы смотрим на их поведение. Мы прислушиваемся к их потребностям, оцениваем, отвечают ли наши системы этим потребностям и думаем, что мы можем сделать для удовлетворения этих постоянно меняющихся потребностей. Мы называем эти метрики результатами.
И эти результаты невозможно предугадать, как невозможно предугадать поведение человека. Хорошие результаты требуют от членов команды активного взаимодействия с клиентами, чтобы уловить изменения в их поведении, причины их возникновения и возможности для лучшего удовлетворения потребностей клиентов в будущем. Хорошая новость заключается в том, что в вашей компании, скорее всего, уже работают люди, которые особенно хороши в этих аспектах – дизайнеры. Несмотря на то, что сегодня дизайнеры присутствуют почти в каждой компании, большинство из них не занимают достаточно высоких должностей, чтобы влиять на принятие больших решений. На самом деле многие из них остаются за бортом процессов Agile-разработки, заточенной под программистов и Product-менеджеров.
Интеграция дизайнеров в процесс Agile-разработки является постоянной проблемой для многих организаций. Благодаря почти 20-летнему опыту проектирования, управления и консультации продуктовых команд, я выявил следующие 5 правил, которым должна следовать команда, если хочет убедиться, что проработка пользовательского опыта (UX) успешно интегрирована в их Agile-процесс:
1. Отдельный дизайнер для каждой команды
Здесь не может быть компромиссов. Без «собственного» дизайнера в Scrum-команде у вас есть просто команда разработчиков, которая без дизайнера не сможет обеспечить надлежащий уровень качества пользовательского опыта.
2. Командные часы работы с клиентами
Это правило я узнал от Джареда Спула, который провел исследование, доказывающее, что команды, проводящие по крайней мере 2 человеко-часа каждые 6 недель, общаются с клиентами (например, принимая звонки службы поддержки, разговаривая с пользователями, наблюдая за людьми и т.д.), разрабатывают более успешные продукты.
3. Работа дизайнера – первый пункт бэклога
Вкратце: ведите единый бэклог. Разработка, контроль качества, дизайн, исследовательская работа – все это должно лежать в одном бэклоге, приоритезированном всей командой, которая эту работу выполняет. Как только работа будет разделена на два бэклога, команда выберет один из них и решит относиться к нему как к «основному», а второй просто отложит в долгий ящик.
4. Результаты в качестве фильтров приоритизации для бэклога
Я много писал о результатах (а Джош Сейден написал об этом целую книгу), но единственное, что я хочу отметить в контексте сегодняшней темы, так это то, что каждый пункт бэклога должен пройти фильтр конечных целей команды. Задайтесь вопросом: «Поможет ли эта работа в достижении цели?». Если ответ будет отрицательным, то отбросьте этот пункт.
5. Кросс-функциональное обучение
Пользовательский опыт и дизайн несут в себе множество интересных вещей, которые стоит изучить. Такие мероприятия могут проводиться дизайнерами (или аналитиками), но они должны практиковаться и посещаться всей командой. Чем больше команда может учиться вместе, тем меньше времени тратится на то, чтобы делиться полученными знаниями, и больше на то, чтобы решить куда их применить (что является более продуктивным предметом разговора для команды).
Итеративная ретроспективная природа Scrum хорошо подойдет UX и дизайн-активностям. Интеграция инсайтов клиентов в процесс работы проистекает непосредственно из Agile Manifesto (работа с клиентами и т.д.). UX и дизайн приближают нас ближе к Agile-цели клиентоориентированности и более качественному удовлетворению потребностей пользователей. Следуйте этим 5 правилам, чтобы объединить дизайн и Agile-разработку.
Узнать подробнее о курсе.