Ну это вопрос проведения грумминга. "Имеющий уши да услышит". Если заказчик хочет, он имеет сказать. Если сказать боится, то это проблема не в плоскости ИТ.
Статья хорошая. Самое главное в ней, это то что главное при проектировании это разметка предметногл поля. И как пример - микросервисы. Это авторское видение. Автор имеет право.
ну у нас много дальнейших планов на расширение функционала. В том числе и работа с электронной почтой. И в планах не только дать доступ к файлам на почтовом сервере, но и в соответствии с представленной методикой, определить в каком виде наиболее удобно представлять информацию в электронной почте, а также куда и как должны скачиваться файлы с почтового сервера. Работа на данный момент ведется.
С интересом прочитал. Действительно в текущей ситуации покупать новый сервер и масштабироваться горизонтально трудно из-за санкций.
Решения, которые вы предлагаете могут иметь место (наверное). Но они не должны становиться обьектом знания 2х человек в команде. Если мы говорим про энтерпрайз, и в команду заходит новый человек. Есть риск что он ни в чем не разберется. Как решали проблему с документацией?
В одной из своих предыдущих работ, я сравнивал аналитика с врачом-терапевтом, который ничего не знает, но хорошо ориентируется в том, кто может знать точно и к кому больного нужно направить. Только проблема в том, что терапевт, как и медицина, в общем это специальность с тысячилетним бекграундом и солидным академическим обеспечением. Чтобы выявить болезнь и поставить диагноз нужно организовать систему линий решения проблемы и терапевт стоит на первой, а хирург на последней.
У нас же аналитик тоже должен по идее разбирать входящие потоки информации, классифицировать и мистематищировать их. И таких аналитиков я готов приветствовать. Но где они? Где академические подходы? Где методологии. Если вы посетите конференции типа Analyst days, то увидите что большинство докладов там про софт-скилс и лни водят хороврды вокруг анализа бизнес-требований. Это при завершенной-то диджитализации бизнеса.
Правы вы еще в том, что мало кто хочет брать на себя ответственность и что-то предлагать. Все же хотят получать много и писать документацию, которую в итоге никто не читает.
Проблема "узкого горлышка" гораздо шире. Если бы они просто коммуницировали, они еще добавляют свое видение. То есть, мало того, что через аналитика проходят все информационные потоки, у него еще и начинает "пухнуть голова". Он начинает путать, забывать, психовать. И везде пытаться приделать какой-то паттерн, который у него единожды где-то получился, тем самым исказив исходную бизнес-суть.
это и является моим основным посылом. Дело в том, что мы имеем сейчас "Золотую лихорадку в ИТ". Причем, если раньше после пулеметных курсов в интернете становились только разработчиками, то сейчас тоже самое происходит с аналитиками. Причем, есть устойчивое мнение, что если человек не освоил программирование, то его можно отправить в анализ и он там пригодится. Нет! Сыты по горло этими любителями анализировать бизнес-требования и разбавлять хотелки бизнеса "своим видением".
Ит - это техносфера. И тут надо быть инженером. И мыслить нужно начинать, как инженер. И хотя бы иметь представление, о том, что такое классы, таблицы БД и прочее. И еще, про техписов. Есть на мой взгляд очень порочная практика SWAGER - культуры, когда документация порождается кодом. То есть документация, сгенерированная в недрах Swager - тсановится полноценным артефактом. Не исключено, что спустя какое-то время я напишу еще одну статью под названием "верните аналитиков!".
Ну так правильно. Если раньше все для коммуникации использовали аналитика, то теперь не нужно этого делать. Все и так находятся в едином информационном поле - продуктовой команде и в соответствии с ритуалами у них есть регулярная возможность обратиться непосредственно друг к другу, не задействуя дополнительное прокладочное звено. И после они все идут заполнять свой пласт документации.
А аналитик для коммуникации это узкое горлышко, с которым постоянные проблемы.
Для архитектуры в командах есть продукт овнер и платформ овнер. Они тоже части команды и можно к ним ходить.
Третий момент, когда аналитик попадает в подобную ситуацию, он вынужденно становится солюшн-архитектором или идет мести улицы... потому что не нужны больше писцы документации, сборщики и анализаторы бизнес-требований, а также мастера коммуникации, владеющие искусством ставить созвоны.
Так. Артефактами называется любая информация об истории развития продукта и об истории принятия решений. Сам продукт артефактом не является. Хотя, вы знаете, в консалтинге часто возникает ситуация о "тикете ради тикета". Тогда аналитик садится и пилит тикеты.
Документация как часть продукта? Такой документацией является законченная база знаний в Confluence. Ну или если совсем хотите красиво сделать, то можно нанять технического писателя и на основе Confluence написать хорошую инструкцию.
Хотя технический писатель начнет опять свое видение вставлять. Также как и аналитик, который как технолог в древнюю эпоху. Он же являлся прослойкой между заказчиком и разработчиком. И вот так бывало - ему про Фому, а он пишет про Ерему. Ему про Ерему, а он опять про Фому. Постоянно приплеталось свое видение. Вот чтоб от этого уйти и пришли к эджайлу.
И вот в эджайле не нужна стала коммуникация и сбор требований. И бизнес-логику описывать не надо. Но возникла другая проблема. Модель данных и паттерны. И вот за создание модели данных никто из продуктовой команды, кроме аналитика не возьмется.
Документация в эджайл разработке строится из трех столпов - тикерт в jira, commit в гите и базы знаний в confluence. Документация теперь называется "артефактом". Важнейшим артефактом является тикет в джире. По нему можно найти ссылки и на мердж в gitи на diff в конфлюенце. Конфлюенц это база знаний, которую копит вся команда в момент разработки. И если её слаженно составляет вся продуктовая команда, то через год эксплуатации вся информация присутствует. Другой вопрос, что больше нет отдельной роли, которая эту базу знаний собирает. Работают над ней все вместе все роли.
Спасибо за статью. Ранее с подобной концепцией сталкивалась в рамках известного фреймворка vaadin. И уже тогда сложилось впечатление, что она (концепция) хорошая для решений малого бизнеса, когда тмеет смысл экономить на веб-разработчиках. А вот для крупных проектов, таких как банки, хорошо бы разнести фронт и бек разратотки по разным точкам. Хотелось бы узнать мнение авторов, на сколько данная концепция применима в энтерпрайсе? На сколько хорошо она ложится под ci/cd ?
Системный аналитик -очень широкое понятие. Знания нужны обширные. Зачастую, огромная работа проводится по построению моделей данных. Почему то автор игнорирует altova, oxigen и тучу бесплатных сайтов для построения api. Где swager? Где sql?
При обосновании подхода "как не надо индексировать" прежде всего стоит сказать, что скорость select всегда достигается за счет ущерба в скорости update, insert и delete
Потому что есть такая теорема эмерджентности в бизнес-анализе. Довоз груза это не только доставка, но и размер колес, стоимость бензина и прочее, что составляет специфику бизнеса. Поэтому важно понимать специфику. И с учетом цифривизации бизнес должен, я бы даже сказал, обязан понимать ит-специфику. Вот кто не поймёт, тот не выживет. Вспомните, что стало с Kodak.
-"Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". - со странным бизнесом вы работаете. Я пишу сиптью, про бизнес, который уже прошел трансформацию, денежку считает и понимает, зачем ему та или иная информационная система. В Прочем, допускаю что описанное вами существует. И даже, более того, сталкивался с таким. Могу также сказать, что канул тот Бизнес в Лету)
Ну это вопрос проведения грумминга. "Имеющий уши да услышит". Если заказчик хочет, он имеет сказать. Если сказать боится, то это проблема не в плоскости ИТ.
Статья хорошая. Самое главное в ней, это то что главное при проектировании это разметка предметногл поля. И как пример - микросервисы. Это авторское видение. Автор имеет право.
ну у нас много дальнейших планов на расширение функционала. В том числе и работа с электронной почтой. И в планах не только дать доступ к файлам на почтовом сервере, но и в соответствии с представленной методикой, определить в каком виде наиболее удобно представлять информацию в электронной почте, а также куда и как должны скачиваться файлы с почтового сервера. Работа на данный момент ведется.
ООП и DDD объединили. Следующий пункт это api first.
С интересом прочитал. Действительно в текущей ситуации покупать новый сервер и масштабироваться горизонтально трудно из-за санкций.
Решения, которые вы предлагаете могут иметь место (наверное). Но они не должны становиться обьектом знания 2х человек в команде. Если мы говорим про энтерпрайз, и в команду заходит новый человек. Есть риск что он ни в чем не разберется. Как решали проблему с документацией?
Я согласен с вами.
В одной из своих предыдущих работ, я сравнивал аналитика с врачом-терапевтом, который ничего не знает, но хорошо ориентируется в том, кто может знать точно и к кому больного нужно направить. Только проблема в том, что терапевт, как и медицина, в общем это специальность с тысячилетним бекграундом и солидным академическим обеспечением. Чтобы выявить болезнь и поставить диагноз нужно организовать систему линий решения проблемы и терапевт стоит на первой, а хирург на последней.
У нас же аналитик тоже должен по идее разбирать входящие потоки информации, классифицировать и мистематищировать их. И таких аналитиков я готов приветствовать. Но где они? Где академические подходы? Где методологии. Если вы посетите конференции типа Analyst days, то увидите что большинство докладов там про софт-скилс и лни водят хороврды вокруг анализа бизнес-требований. Это при завершенной-то диджитализации бизнеса.
Правы вы еще в том, что мало кто хочет брать на себя ответственность и что-то предлагать. Все же хотят получать много и писать документацию, которую в итоге никто не читает.
Проблема "узкого горлышка" гораздо шире. Если бы они просто коммуницировали, они еще добавляют свое видение. То есть, мало того, что через аналитика проходят все информационные потоки, у него еще и начинает "пухнуть голова". Он начинает путать, забывать, психовать. И везде пытаться приделать какой-то паттерн, который у него единожды где-то получился, тем самым исказив исходную бизнес-суть.
это и является моим основным посылом. Дело в том, что мы имеем сейчас "Золотую лихорадку в ИТ". Причем, если раньше после пулеметных курсов в интернете становились только разработчиками, то сейчас тоже самое происходит с аналитиками. Причем, есть устойчивое мнение, что если человек не освоил программирование, то его можно отправить в анализ и он там пригодится. Нет! Сыты по горло этими любителями анализировать бизнес-требования и разбавлять хотелки бизнеса "своим видением".
Ит - это техносфера. И тут надо быть инженером. И мыслить нужно начинать, как инженер. И хотя бы иметь представление, о том, что такое классы, таблицы БД и прочее.
И еще, про техписов. Есть на мой взгляд очень порочная практика SWAGER - культуры, когда документация порождается кодом. То есть документация, сгенерированная в недрах Swager - тсановится полноценным артефактом. Не исключено, что спустя какое-то время я напишу еще одну статью под названием "верните аналитиков!".
Ну так правильно. Если раньше все для коммуникации использовали аналитика, то теперь не нужно этого делать. Все и так находятся в едином информационном поле - продуктовой команде и в соответствии с ритуалами у них есть регулярная возможность обратиться непосредственно друг к другу, не задействуя дополнительное прокладочное звено. И после они все идут заполнять свой пласт документации.
А аналитик для коммуникации это узкое горлышко, с которым постоянные проблемы.
Для архитектуры в командах есть продукт овнер и платформ овнер. Они тоже части команды и можно к ним ходить.
Третий момент, когда аналитик попадает в подобную ситуацию, он вынужденно становится солюшн-архитектором или идет мести улицы... потому что не нужны больше писцы документации, сборщики и анализаторы бизнес-требований, а также мастера коммуникации, владеющие искусством ставить созвоны.
Так. Артефактами называется любая информация об истории развития продукта и об истории принятия решений. Сам продукт артефактом не является. Хотя, вы знаете, в консалтинге часто возникает ситуация о "тикете ради тикета". Тогда аналитик садится и пилит тикеты.
Документация как часть продукта? Такой документацией является законченная база знаний в Confluence. Ну или если совсем хотите красиво сделать, то можно нанять технического писателя и на основе Confluence написать хорошую инструкцию.
Хотя технический писатель начнет опять свое видение вставлять. Также как и аналитик, который как технолог в древнюю эпоху. Он же являлся прослойкой между заказчиком и разработчиком. И вот так бывало - ему про Фому, а он пишет про Ерему. Ему про Ерему, а он опять про Фому. Постоянно приплеталось свое видение. Вот чтоб от этого уйти и пришли к эджайлу.
И вот в эджайле не нужна стала коммуникация и сбор требований. И бизнес-логику описывать не надо. Но возникла другая проблема. Модель данных и паттерны. И вот за создание модели данных никто из продуктовой команды, кроме аналитика не возьмется.
Добрый вечер.
Документация в эджайл разработке строится из трех столпов - тикерт в jira, commit в гите и базы знаний в confluence. Документация теперь называется "артефактом". Важнейшим артефактом является тикет в джире. По нему можно найти ссылки и на мердж в gitи на diff в конфлюенце. Конфлюенц это база знаний, которую копит вся команда в момент разработки. И если её слаженно составляет вся продуктовая команда, то через год эксплуатации вся информация присутствует. Другой вопрос, что больше нет отдельной роли, которая эту базу знаний собирает. Работают над ней все вместе все роли.
Спасибо за статью. Ранее с подобной концепцией сталкивалась в рамках известного фреймворка vaadin. И уже тогда сложилось впечатление, что она (концепция) хорошая для решений малого бизнеса, когда тмеет смысл экономить на веб-разработчиках. А вот для крупных проектов, таких как банки, хорошо бы разнести фронт и бек разратотки по разным точкам. Хотелось бы узнать мнение авторов, на сколько данная концепция применима в энтерпрайсе? На сколько хорошо она ложится под ci/cd ?
Системный аналитик -очень широкое понятие. Знания нужны обширные. Зачастую, огромная работа проводится по построению моделей данных. Почему то автор игнорирует altova, oxigen и тучу бесплатных сайтов для построения api. Где swager? Где sql?
Это точно, а аот зрелый человек со стороны бизнеса, дорогого стоит
При обосновании подхода "как не надо индексировать" прежде всего стоит сказать, что скорость select всегда достигается за счет ущерба в скорости update, insert и delete
Золотые слова
По моему мнению, вы также путаете бизнес и клиентов бизнеса.
В любом случае, все написанное тут это мое личное мнение и я могу быть не прав.
Вы путаете, по моему мнению, бизнес и клиентов бизнеса.
Потому что есть такая теорема эмерджентности в бизнес-анализе. Довоз груза это не только доставка, но и размер колес, стоимость бензина и прочее, что составляет специфику бизнеса. Поэтому важно понимать специфику. И с учетом цифривизации бизнес должен, я бы даже сказал, обязан понимать ит-специфику. Вот кто не поймёт, тот не выживет. Вспомните, что стало с Kodak.
-"Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". - со странным бизнесом вы работаете. Я пишу сиптью, про бизнес, который уже прошел трансформацию, денежку считает и понимает, зачем ему та или иная информационная система. В Прочем, допускаю что описанное вами существует. И даже, более того, сталкивался с таким. Могу также сказать, что канул тот Бизнес в Лету)