Роль аналитика в команде Agile
Недавно задумался о роли аналитика в Agile.
Так как сейчас 90% компаний говорят о том, что ведут разработку по Agile, используют Scram, рассмотрим этот случай.
Мысль подробнее разобраться в задачах аналитика в проектах Agile, первый раз меня посетила, когда только узнал о Scram.
Ценности
Начнем с манифеста Agile.
"Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану."
Во втором пункте, сразу говорится что проектная документация не так важна, как работающий продукт.
Это противопоставляется водопадной модели разработки, где большой % времени проекта составляет написание документации. Практически вся она пишется аналитиком, либо с помощью аналитика.
В гибкой методологии, детальная проработка задачи аналитиком, заменяется обсуждением user story командой. Команда и определяет каким образом задача будет реализована. Притом не составляется подробная спецификация.
Agile рекомендует избегать документацию, которую заведомо никто не прочитает, использовать больше визуальных образов, схем, графических нотаций.
Роли
Теперь перейдем состава ролей Scram.
1. Владелец продукта.
2. Scram мастер.
3. Команда разработки.
Как видно из состава ролей, команда не делится по функционалу. Идеальная команда разработки для скрама, кроссфункциональная, а разработчики имеют прямой доступ к бизнесу.
Так где же место аналитика?
Большинство разработчиков не любят общаться с бизнесом, и в общении с ним больше уделяют техническим аспектам. Для успешного продукта важны так же и бизнес характеристики. Так же, на уточнение требований разработчики будут тратить много времени. Это может зависеть от бюрократии, нетривиальных моментов, не желании принимать ответсвеных решений и т.п.
Тут и возникает идея в промежуточном слое, который позволит эффективно использовать разработчиков, но при этом не снижая качество общения с бизнесом.
Аналитик будет связующим звеном, скрам команды и безнес заказчиков. И будет особенно нужен в случае недостатка времени у стейкхолдеров, или отсутствия владельца продукта.
Также, аналитик будет центр накопления знаний о предметной области продукта, контролировать качество продукта, проводить review продукта, подготавливать данные для уточнения бэклога и т.п.
Из личного опыта. В данный момент, обучаюсь по специальности руководитель проекта (РП) (частично затрагиваем и задачи владельца продукта (ВП)), замечаю, что функционал аналитика сильно пересекается и с РП и с ВП.
Итог
Несмотря что гибкие методологии напрямую не указывают на наличие аналитика в команде, выведение аналитика в отдельную роль несомненно будет плюсом.
На небольших проектах, аналитик может совмещать роль с ВП. На больших проектах, аналитик является связующим звеном между бизнесом и командой.
Недавно задумался о роли аналитика в Agile.
Так как сейчас 90% компаний говорят о том, что ведут разработку по Agile, используют Scram, рассмотрим этот случай.
Мысль подробнее разобраться в задачах аналитика в проектах Agile, первый раз меня посетила, когда только узнал о Scram.
Ценности
Начнем с манифеста Agile.
"Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану."
Во втором пункте, сразу говорится что проектная документация не так важна, как работающий продукт.
Это противопоставляется водопадной модели разработки, где большой % времени проекта составляет написание документации. Практически вся она пишется аналитиком, либо с помощью аналитика.
В гибкой методологии, детальная проработка задачи аналитиком, заменяется обсуждением user story командой. Команда и определяет каким образом задача будет реализована. Притом не составляется подробная спецификация.
Agile рекомендует избегать документацию, которую заведомо никто не прочитает, использовать больше визуальных образов, схем, графических нотаций.
Роли
Теперь перейдем состава ролей Scram.
1. Владелец продукта.
2. Scram мастер.
3. Команда разработки.
Как видно из состава ролей, команда не делится по функционалу. Идеальная команда разработки для скрама, кроссфункциональная, а разработчики имеют прямой доступ к бизнесу.
Так где же место аналитика?
Большинство разработчиков не любят общаться с бизнесом, и в общении с ним больше уделяют техническим аспектам. Для успешного продукта важны так же и бизнес характеристики. Так же, на уточнение требований разработчики будут тратить много времени. Это может зависеть от бюрократии, нетривиальных моментов, не желании принимать ответсвеных решений и т.п.
Тут и возникает идея в промежуточном слое, который позволит эффективно использовать разработчиков, но при этом не снижая качество общения с бизнесом.
Аналитик будет связующим звеном, скрам команды и безнес заказчиков. И будет особенно нужен в случае недостатка времени у стейкхолдеров, или отсутствия владельца продукта.
Также, аналитик будет центр накопления знаний о предметной области продукта, контролировать качество продукта, проводить review продукта, подготавливать данные для уточнения бэклога и т.п.
Из личного опыта. В данный момент, обучаюсь по специальности руководитель проекта (РП) (частично затрагиваем и задачи владельца продукта (ВП)), замечаю, что функционал аналитика сильно пересекается и с РП и с ВП.
Итог
Несмотря что гибкие методологии напрямую не указывают на наличие аналитика в команде, выведение аналитика в отдельную роль несомненно будет плюсом.
На небольших проектах, аналитик может совмещать роль с ВП. На больших проектах, аналитик является связующим звеном между бизнесом и командой.
Дизайн это не о визуальной части, дизайн это о продукте
Предисловие
Внешняя форма сама по себе не стоит ничего, если она не будет отвечать технологическим и бизнес-требованиям, не будет до мелочей учитывать функциональную нагрузку и пользовательскую составляющую, то такое оформление является иллюстрацией, рисунком.
Дизайн без привязки к визуальной составляющей - это мёртвый никому не нужный интерфейс.
Дизайн
Если поискать в интернете информацию о дизайне, получается большой список:
- промышленный дизайн
- архитектурный дизайн
- ландшафтный дизайн
- световой дизайн
- звуковой дизайн
- дизайн интерьеров
- дизайн одежды
- (поли) графический дизайн
- информационный дизайн
- продуктовый дизайн
- технический дизайн
- дизайн данных
- дизайн баз данных
и т.д.
Почему так вышло, что нет определённого понятия “Дизайн”?
Ответ прост, советском союзе не было дизайна и дизайнеров.
Но в постсоветском пространстве, дизайном называют именно визуальную составляющую. В этом нет ничего страшного.
Виновата в этом “полиграфия” и 90е с их первоначальным накоплением капитала. В СССР не было дизайна, были конструкторы и технологи. Не было веба или мобайла. Но машиностроение было. Например, Калашников он дизайнер, восхитительный гениальный конструктор, и в СССР большинство дизайнеров именовалось конструкторами.
Но когда рухнул занавес, к нам ринулись иностранные “сникерсы” и “кола”, начали появляться зачатки бизнеса. А значит каждому ларьку и магазину, компании и фирме нужны были собственные логотипы, корпоративный стиль.
В то время, в уже постсоветском пространстве, были полиграфисты, художники оформители. Они начали выпускать в огромном количестве логотипы, стили. Они поднялись на этой волне. Но быть оформителями, полиграфистами, в мире импортных товаров, было не круто. Что это за компания по “оформлению”? А вот компания, создающая “дизайн вашего бизнеса”, совсем другое дело. По этой причине. слово “дизайн” приклеилось к визуальным составляющим.
Проектирование
Через некоторое время появился веб, и все эти компании перестроились на создание макетов. Когда появился UX/UI, понимание персонажей, слово “дизайн” было попросту занято. Но так как язык, это гибкая субстанция, вместо дизайна, он выдал слово “проектирование”. Так появилось разделение на дизайнеров и проектировщиков.
Что же такое проектирование?
Так получилось, что в России “проектирование” стало чем-то связанным с техническим воплощением, бизнесовым, техническим требованиям. А “Дизайн” - визуальное.
Если перевести дословно “проектирование”, то мы получим “design”, так как в английском нет слова “проектирование”.
Сейчас есть 3 основных направления. Первое, утверждает, что дизайн, это часть проектирования. Вторая, что проектирование, это часть дизайна. И третья, что проектирование равно дизайн.
Последняя руководствуется тем что, когда пришёл “дизайн”, слово было уже занято. Но дизайн, это не только про визуальную составляющую.
Возьмём, например, промышленный дизайн. Ни один промышленный дизайнер не сможет создать прототип, допустим, автомобиля, не знаю технических составляющих автомобиля, бизнесовой составляющий.
Не опираясь на бизнесовую составляющую, уровень достатка клиента, дизайнер не решит, нужен ли в автомобиле люк. Или не решит какой должен быть клиренс автомобиля, не понимая условий использования и технических особенностей подвески.
Чтобы решить эти вопросы, дизайнеры должны быть осведомлены во многих смежных областях. По этой же причине, дизайн не однозначен. В каждой компании под дизайном понимают различные вещи. И всё зависит от требований к конкретному продукту в конкретной компании.
Итог
Вернёмся к разделению на дизайнеров и проектировщиков.
Классическое понятие проектирование UI, пользовательский интерфейс. UI обычно не входит в работы по проектированию, но UI всегда входит в дизайн (наряду с проектированием), получается, что в “дизайн” входит и проектирование и UI.
Моё мнение что дизайн это объёмное, то что включает в себя помимо описанных выше элементов, много других элементов. Но это, моё мнение.
А как думаете вы?
Предисловие
Внешняя форма сама по себе не стоит ничего, если она не будет отвечать технологическим и бизнес-требованиям, не будет до мелочей учитывать функциональную нагрузку и пользовательскую составляющую, то такое оформление является иллюстрацией, рисунком.
Дизайн без привязки к визуальной составляющей - это мёртвый никому не нужный интерфейс.
Дизайн
Если поискать в интернете информацию о дизайне, получается большой список:
- промышленный дизайн
- архитектурный дизайн
- ландшафтный дизайн
- световой дизайн
- звуковой дизайн
- дизайн интерьеров
- дизайн одежды
- (поли) графический дизайн
- информационный дизайн
- продуктовый дизайн
- технический дизайн
- дизайн данных
- дизайн баз данных
и т.д.
Почему так вышло, что нет определённого понятия “Дизайн”?
Ответ прост, советском союзе не было дизайна и дизайнеров.
Но в постсоветском пространстве, дизайном называют именно визуальную составляющую. В этом нет ничего страшного.
Виновата в этом “полиграфия” и 90е с их первоначальным накоплением капитала. В СССР не было дизайна, были конструкторы и технологи. Не было веба или мобайла. Но машиностроение было. Например, Калашников он дизайнер, восхитительный гениальный конструктор, и в СССР большинство дизайнеров именовалось конструкторами.
Но когда рухнул занавес, к нам ринулись иностранные “сникерсы” и “кола”, начали появляться зачатки бизнеса. А значит каждому ларьку и магазину, компании и фирме нужны были собственные логотипы, корпоративный стиль.
В то время, в уже постсоветском пространстве, были полиграфисты, художники оформители. Они начали выпускать в огромном количестве логотипы, стили. Они поднялись на этой волне. Но быть оформителями, полиграфистами, в мире импортных товаров, было не круто. Что это за компания по “оформлению”? А вот компания, создающая “дизайн вашего бизнеса”, совсем другое дело. По этой причине. слово “дизайн” приклеилось к визуальным составляющим.
Проектирование
Через некоторое время появился веб, и все эти компании перестроились на создание макетов. Когда появился UX/UI, понимание персонажей, слово “дизайн” было попросту занято. Но так как язык, это гибкая субстанция, вместо дизайна, он выдал слово “проектирование”. Так появилось разделение на дизайнеров и проектировщиков.
Что же такое проектирование?
Так получилось, что в России “проектирование” стало чем-то связанным с техническим воплощением, бизнесовым, техническим требованиям. А “Дизайн” - визуальное.
Если перевести дословно “проектирование”, то мы получим “design”, так как в английском нет слова “проектирование”.
Сейчас есть 3 основных направления. Первое, утверждает, что дизайн, это часть проектирования. Вторая, что проектирование, это часть дизайна. И третья, что проектирование равно дизайн.
Последняя руководствуется тем что, когда пришёл “дизайн”, слово было уже занято. Но дизайн, это не только про визуальную составляющую.
Возьмём, например, промышленный дизайн. Ни один промышленный дизайнер не сможет создать прототип, допустим, автомобиля, не знаю технических составляющих автомобиля, бизнесовой составляющий.
Не опираясь на бизнесовую составляющую, уровень достатка клиента, дизайнер не решит, нужен ли в автомобиле люк. Или не решит какой должен быть клиренс автомобиля, не понимая условий использования и технических особенностей подвески.
Чтобы решить эти вопросы, дизайнеры должны быть осведомлены во многих смежных областях. По этой же причине, дизайн не однозначен. В каждой компании под дизайном понимают различные вещи. И всё зависит от требований к конкретному продукту в конкретной компании.
Итог
Вернёмся к разделению на дизайнеров и проектировщиков.
Классическое понятие проектирование UI, пользовательский интерфейс. UI обычно не входит в работы по проектированию, но UI всегда входит в дизайн (наряду с проектированием), получается, что в “дизайн” входит и проектирование и UI.
Моё мнение что дизайн это объёмное, то что включает в себя помимо описанных выше элементов, много других элементов. Но это, моё мнение.
А как думаете вы?
Мысли в текст
Итеративный подход к разработке похож на блуждание по болоту. Ты понимаешь что выйти из болота надо, но по какому пути неизвестно.
Есть палка "инсайды", ей проверяем кочки, тонут они или нет. Если кочка не тонет, мы переходим на неё.
Включаются наши ощущения - "обратная связь", "метрики". Если кочка всё-таки тонет, то делаем шаг назад.
Если выдерживает нас, переходим к следующей итерации. Опять поиск пути и проверка правильности выбора.
Так, рано или поздно мы выйдем из болота, если будем реагировать достаточно быстро и не останемся на тонущих кочках. Или не закончатся ресурсы чтобы могли двигаться дальше.
Итеративный подход к разработке похож на блуждание по болоту. Ты понимаешь что выйти из болота надо, но по какому пути неизвестно.
Есть палка "инсайды", ей проверяем кочки, тонут они или нет. Если кочка не тонет, мы переходим на неё.
Включаются наши ощущения - "обратная связь", "метрики". Если кочка всё-таки тонет, то делаем шаг назад.
Если выдерживает нас, переходим к следующей итерации. Опять поиск пути и проверка правильности выбора.
Так, рано или поздно мы выйдем из болота, если будем реагировать достаточно быстро и не останемся на тонущих кочках. Или не закончатся ресурсы чтобы могли двигаться дальше.
Мысли в текст
Представьте есть холодильник, на холодильнике стикеры.
- почистить ковёр,
- помыть посуду,
- вынести мусор.
Пример 1. Проходя мимо холодильника вы видите стикер, например, "почистить ковёр". В голове мысли: "Я же умею чистить ковёр, пойду сделаю это." Снимаете стикер, идете чистить ковёр. Это правильный подход в agile.
Пример 2. Тот же самый холодильник, те же стикеры. Но кто-то берет стикер "почистить ковёр". Ищет кого-то ниже себя и говорит:
- "Иди чисть ковёр."
- "Но я же не умею." - в ответ.
- "Все равно иди и чисти."
Это не правильный подход.
Представьте есть холодильник, на холодильнике стикеры.
- почистить ковёр,
- помыть посуду,
- вынести мусор.
Пример 1. Проходя мимо холодильника вы видите стикер, например, "почистить ковёр". В голове мысли: "Я же умею чистить ковёр, пойду сделаю это." Снимаете стикер, идете чистить ковёр. Это правильный подход в agile.
Пример 2. Тот же самый холодильник, те же стикеры. Но кто-то берет стикер "почистить ковёр". Ищет кого-то ниже себя и говорит:
- "Иди чисть ковёр."
- "Но я же не умею." - в ответ.
- "Все равно иди и чисти."
Это не правильный подход.