Комментарии 13
аналитики пишущие документацию и формализующие бизнес-требования, эта специальность, доживающая свой век
Мне кажется тут вопрос, прежде всего, о роли документации в современной Agile-разработке. Кажется, в моменте дока действительно не нужна, но если продукт все таки выстрелил, а документации нет, то через год другой команды поддержки начинают создавать документацию с нуля, все эти пользователи и юз-кейсы, потоки данных и их влияние. Есть такой опыт и он не очень простой.
Добрый вечер.
Документация в эджайл разработке строится из трех столпов - тикерт в jira, commit в гите и базы знаний в confluence. Документация теперь называется "артефактом". Важнейшим артефактом является тикет в джире. По нему можно найти ссылки и на мердж в gitи на diff в конфлюенце. Конфлюенц это база знаний, которую копит вся команда в момент разработки. И если её слаженно составляет вся продуктовая команда, то через год эксплуатации вся информация присутствует. Другой вопрос, что больше нет отдельной роли, которая эту базу знаний собирает. Работают над ней все вместе все роли.
Если в команде «важнейший» артефакт - Тикет, то она что-то.не то делает (возможно она делает тикеты?). В нормальной команде главный артефакт, все таки, - это продукт, который, в том числе состоит из документации, и таким командам, обычно, четко понятны задачи аналитика ?♂️
А вот заметка про отсутствие выделенной роли очень верная - в хорошей ажаль-команде вообще редко кто одну функцию выполняет, всегда все перемешано
Так. Артефактами называется любая информация об истории развития продукта и об истории принятия решений. Сам продукт артефактом не является. Хотя, вы знаете, в консалтинге часто возникает ситуация о "тикете ради тикета". Тогда аналитик садится и пилит тикеты.
Документация как часть продукта? Такой документацией является законченная база знаний в Confluence. Ну или если совсем хотите красиво сделать, то можно нанять технического писателя и на основе Confluence написать хорошую инструкцию.
Хотя технический писатель начнет опять свое видение вставлять. Также как и аналитик, который как технолог в древнюю эпоху. Он же являлся прослойкой между заказчиком и разработчиком. И вот так бывало - ему про Фому, а он пишет про Ерему. Ему про Ерему, а он опять про Фому. Постоянно приплеталось свое видение. Вот чтоб от этого уйти и пришли к эджайлу.
И вот в эджайле не нужна стала коммуникация и сбор требований. И бизнес-логику описывать не надо. Но возникла другая проблема. Модель данных и паттерны. И вот за создание модели данных никто из продуктовой команды, кроме аналитика не возьмется.
Ну как так-то? Ажаль, он прежде всего про коммуникацию, как же она не нужна-то? И про требования-архитектуры и про обратную связь от пользователей должно быть достаточно коммуникаций.
Ну так правильно. Если раньше все для коммуникации использовали аналитика, то теперь не нужно этого делать. Все и так находятся в едином информационном поле - продуктовой команде и в соответствии с ритуалами у них есть регулярная возможность обратиться непосредственно друг к другу, не задействуя дополнительное прокладочное звено. И после они все идут заполнять свой пласт документации.
А аналитик для коммуникации это узкое горлышко, с которым постоянные проблемы.
Для архитектуры в командах есть продукт овнер и платформ овнер. Они тоже части команды и можно к ним ходить.
Третий момент, когда аналитик попадает в подобную ситуацию, он вынужденно становится солюшн-архитектором или идет мести улицы... потому что не нужны больше писцы документации, сборщики и анализаторы бизнес-требований, а также мастера коммуникации, владеющие искусством ставить созвоны.
потому что не нужны больше писцы документации, сборщики и анализаторы бизнес-требований, а также мастера коммуникации, владеющие искусством ставить созвоны
Все зависит от команды и действительно не все из перечисленных людей нужны. К созвон-спецам у меня вообще отдельная любовь :-)
А вот грамотных техписов, а таковых без аналитического склада ума не представляю, очень и очень не хватает в командах. Такие люди похоже намного реже встречаются в нашем ИТ мире, а они очень нужны.
это и является моим основным посылом. Дело в том, что мы имеем сейчас "Золотую лихорадку в ИТ". Причем, если раньше после пулеметных курсов в интернете становились только разработчиками, то сейчас тоже самое происходит с аналитиками. Причем, есть устойчивое мнение, что если человек не освоил программирование, то его можно отправить в анализ и он там пригодится. Нет! Сыты по горло этими любителями анализировать бизнес-требования и разбавлять хотелки бизнеса "своим видением".
Ит - это техносфера. И тут надо быть инженером. И мыслить нужно начинать, как инженер. И хотя бы иметь представление, о том, что такое классы, таблицы БД и прочее.
И еще, про техписов. Есть на мой взгляд очень порочная практика SWAGER - культуры, когда документация порождается кодом. То есть документация, сгенерированная в недрах Swager - тсановится полноценным артефактом. Не исключено, что спустя какое-то время я напишу еще одну статью под названием "верните аналитиков!".
аналитик для коммуникации это узкое горлышко, с которым постоянные проблемы
Подумал, что проблема и «узкое горлышко», - это люди, которые только выполняют коммуникацию и не принимают каких-то решений. Вот они реально мешают, хотя чаще всего думают, чтотграмотно все делегируют :-(
Проблема "узкого горлышка" гораздо шире. Если бы они просто коммуницировали, они еще добавляют свое видение. То есть, мало того, что через аналитика проходят все информационные потоки, у него еще и начинает "пухнуть голова". Он начинает путать, забывать, психовать. И везде пытаться приделать какой-то паттерн, который у него единожды где-то получился, тем самым исказив исходную бизнес-суть.
Мне кажется, очень многое "в командах есть" тут принято за константу. В большинстве знакомых мне команд, где есть аналитики - нет ни продакт овнера, ни платформ овнера. Есть тимлиды, разработка-тестирование, бизнес-заказчики и архитекторы в объеме 1 штука на 5-10 команд. При этом, большинство бизнес-сценариев охватывает несколько команд, и требуют trade-off анализа, кросс-анализа с другими задачами других бизнес-заказчиков и т п. В таком кейсе аналитик становится неким представителем от архитектора + бизнеса на уровне задач конкретной команды, и при этом по совсем сложным задачам - идет к архитектору. И в этом слое (кросскомандное взаимодействие для реализации бизнес-сценариев) не очень понимаю, как эту роль заменять. Если постоянно бегать к архитектору - он станет сразу бутылочным горлышком. Ну и аналогично, если есть product owner на несколько команд в дополнение к тимлиду - да, скорее всего он будет носить шапку аналитика и выделенной роли не будет нужно. Какая конфигурация оптимальнее - скорее всего зависит от конкретной организации и процессов.
Я согласен с вами.
В одной из своих предыдущих работ, я сравнивал аналитика с врачом-терапевтом, который ничего не знает, но хорошо ориентируется в том, кто может знать точно и к кому больного нужно направить. Только проблема в том, что терапевт, как и медицина, в общем это специальность с тысячилетним бекграундом и солидным академическим обеспечением. Чтобы выявить болезнь и поставить диагноз нужно организовать систему линий решения проблемы и терапевт стоит на первой, а хирург на последней.
У нас же аналитик тоже должен по идее разбирать входящие потоки информации, классифицировать и мистематищировать их. И таких аналитиков я готов приветствовать. Но где они? Где академические подходы? Где методологии. Если вы посетите конференции типа Analyst days, то увидите что большинство докладов там про софт-скилс и лни водят хороврды вокруг анализа бизнес-требований. Это при завершенной-то диджитализации бизнеса.
Правы вы еще в том, что мало кто хочет брать на себя ответственность и что-то предлагать. Все же хотят получать много и писать документацию, которую в итоге никто не читает.
К вопросу о роли аналитика на современных банковских ИТ-проектах