Роль аналитика в команде Agile

Недавно задумался о роли аналитика в 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.

Моё мнение что дизайн это объёмное, то что включает в себя помимо описанных выше элементов, много других элементов. Но это, моё мнение.

А как думаете вы?

Мысли в текст

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

Есть палка "инсайды", ей проверяем кочки, тонут они или нет. Если кочка не тонет, мы переходим на неё.

Включаются наши ощущения - "обратная связь", "метрики". Если кочка всё-таки тонет, то делаем шаг назад.

Если выдерживает нас, переходим к следующей итерации. Опять поиск пути и проверка правильности выбора.

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

Мысли в текст

Представьте есть холодильник, на холодильнике стикеры.
- почистить ковёр,
- помыть посуду,
- вынести мусор.

Пример 1. Проходя мимо холодильника вы видите стикер, например, "почистить ковёр". В голове мысли: "Я же умею чистить ковёр, пойду сделаю это." Снимаете стикер, идете чистить ковёр. Это правильный подход в agile.

Пример 2. Тот же самый холодильник, те же стикеры. Но кто-то берет стикер "почистить ковёр". Ищет кого-то ниже себя и говорит:
- "Иди чисть ковёр."
- "Но я же не умею." - в ответ.
- "Все равно иди и чисти."
Это не правильный подход.

Всем привет!
В моём блоге вышла новая публикация, первая из цикла "Войти в IT".
https://vc.ru/u/602304-mihail-fokeev/194724-voyti-v-it-cikl-statey-dlya-nachala-karery-v-it

Если у вас есть ощущение что вы тратите силы, бежите, но при этом остаётесь на том же самом месте, возможно так и есть.

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

С опережением графика, написал вторую часть серии Войти в IT
https://vc.ru/u/602304-mihail-fokeev/195366-voyti-v-it-cikl-publikaciy-dlya-nachala-karery-v-it-chast-2

Все об этом думают, но бояться говорить в слух. Или как попросить повышения заработной платы в новой публикации моего блога.
https://vc.ru/u/602304-mihail-fokeev/195771-kak-prosit-povyshenie-zarabotnoy-platy

За сегодня появилось несколько минут чтобы поделиться с вами мыслями.

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

Для PO и бизнес-аналитиков часто встаёт вопрос, как можно улучшить метрики продукта? Чтобы начать что-то предпринимать в кратчайшие сроки, можно использовать такую шпаргалку

Спешу поделиться очередной частью цикла публикации
https://vc.ru/u/602304-mihail-fokeev/201067-voyti-v-it-cikl-publikaciy-dlya-nachala-karery-v-it-chast-3-proforientaciya

Поговорим о карьерном застое

1. Как определить
Есть несколько симптомов. Первый, вы можете сказать ради чего сейчас работаете и какие изменения хотите в течении года.
Второй, длительный период, больше года, нет изменений в заработной плате.
Третий, безразличие коллегам, если нет желания равняться на кого-то или просто общаться.
Если у вас есть один из симптомов, то вы проваливаетесь в трясину застоя.

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

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

Дилемма менеджера проекта или проектный треугольник

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

Если чуть углубиться в тему, то на сам деле менеджер проектов управляет не треугольником, а пирамидой с вершинами: качество, объём работ, бюджет и сроки.

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

Объём работ. Если менеджер проекта ограничен в сроках, бюджете и качестве, остаётся управление только объёмом работ. Чтобы правильно сократить объём, надо:
1. Построить матрицу связей отдельных задач проекта, чтобы понять их влияние друг на друга.
2. Приоритизировать задачи проекта.
Так вы сможете найти задачи проекта от которых вы сможете отказаться чтобы вписаться в рамки проекта.


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

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

Теперь вы знаете мотивацию проектного менеджера и элемент проектного управления.

Находясь в отпуске, нашёл время закончить первое описание позиции в IT - специалиста технической поддержки. Более подробно по ссылке
https://vc.ru/hr/214611

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

1. https://www.specialist.ru/course/bkp24
2. https://www.youtube.com/watch?v=lHIHq0lHlxo&list=PL874KddjzYd_C3oIrP5Hajy5n-pfIEPt8&ab_channel=%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B9%D0%A1%D1%83%D1%85%D0%BE%D0%B2
3. https://www.specialist.ru/course/t-tor
4. https://www.specialist.ru/course/seti1-a
5. https://www.specialist.ru/track/t-stor-v
6. https://edu.cleverics.ru/itil4-foundation
7. https://geekbrains.ru/geek_university/customerservice