Вчера на собесе в одну хорошую (без иронии) компанию (работает с госами) рассказал старшему аналитику ровно это же. А от меня ждали перечень конкретных диаграм, которые я должен показать заказчику. К тому, что даже в опытных, казалось бы, компаниях есть какие-то детские болезни.
С другой стороны, специфика заказчика не должна отменять внутренние процессы описанного в статье анализа. Это надо для проекта/продукта
Мы все стремимся упростить рутину. Если включать мозг для каждого вдоха, то мозг загнётся. Автоматизировать проверку - очень хорошая идея. Паниковать по любому багу и призывать всех по любому чиху включать мозг - так себе идея
Статья полезная. Но, при всём уважении к автору, у аналитиков от определений и терминологий здесь должна идти кровь из глаз. Прям с самого начала:
процессные движки (BPMN)
или всё-таки
Business Process Model and Notation — нотация и модель бизнес-процессов
?
За что глаз сразу зацепился:
Ромб с Х
Почему бы не использовать общепринятые и понятные названия элементов?
Прямоугольник с шестеренками — некий скрытый процесс, логика которого реализуется в рамках кода
Что такое "некий"? Почему он "скрытый" и от кого? Значит, остальные процессы - открытые? А логика остальных процессов, которые без шестерёнки, реализуется вне кода?
И понятно, почему так случилось (болд мой):
«Колдовать» над ними должны квалифицированные разработчики
В этом же ответ, почему в статье явно не выделены, а размазаны по тексту требования, от чего же автор отталкивался и к чему стремился в своей работе
Вот кроме случая, когда команде разработке надо освоить деньги в виде интеграции, других вариантов на ум ничего не приходит, чтобы такой вопрос в принципе существовал. Т.е. рассматривать интеграцию как субъект - ну очень странно. Наверное, у бизнеса есть выявленная (BA, тут - PO) потребность, и способ решения её - интеграция, ведь так?
Возможно, тут я плохо понимаю, кто такой пресейл. В моём розовом мире: 1. У потенциального заказчика решения возникла потребность/задача 2. Выдвигается бизнес-аналитик, с заказчиком полностью понимает что надо по бизнесу 3. И только тут подключается SA. Прикидывает архитектуру для данной задачи.
Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA? В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так? Приведённые в тексте примеры меня не убедили
Описание как поставлена работа с заказчиком, про аккаунт-менеджеров и пресейлов, конечно, поразила. Удивительно читать такое странное про одну из крупнейших компаний в ИТ.
Язык статьи тяжёлый, в итоге кусками почитал. Много канцелярита, предложения никак не могут закончиться и начинаются повторы.
В статье получается, что SA, несмотря на название, ещё и бизнесовое решение придумывает. Хотя чего удивляться, см. как у них устроена продажа решений
Что делать, если у соседа получается, а у тебя нет? Правильно, гнобить успешных и драть с них деньги (шрафы) под всякими благовидными предлогами. И транжирить их на бюрократию (очередную рабочую группу) и подачки населению для поддержания лояльности. Но ни в коем случае не на развитие.
Интересно, что AIDA - имя андроида в Agents of S.H.I.E.L.D.
Смысл новости в том, что боты накручивают прослушивание ИИ-сгенерированных треков, поэтому Spotify удаляет эти треки? Т.е. если боты будут накручивать прослушивание "нормальных" треков, Spotify будет удалять "нормальные" треки?
Набор прямоугольников - это "бизнес-система"? Повыдёргивать пункты из давным-давно сформулированных проектных моделей, перетасовать (но не смешивать (с)), поместить их в прямоугольники - и получайте очередное ноу-хау в бизнесе? Пойду-ка, напишу пару книжек, раз так прокатывает.
"Ценностные предложения": "Простой и понятный интерфейс сайта..." - серьёзно? Вы уверены, что вы сейчас про ценность, а не про способы достижения ценности? Ну и так далее. Очень странная публикация
Немного перефразировал бы. Тут вполне можно применить классику - что есть и как должно быть, начиная сверху с бизнес потребностей и вниз. Сопоставить и дальше уже думать (оценивать), монолит или полмонолита, что менять, а что убивать и т.п.
... DESIGN FIRST. Главными героями здесь становятся дизайнеры.
Хм, интересно. Всегда считал, что в контексте разработки Design - это про проектирование системы/продукта, а не про UI/UX.
Так и не понял из статьи, откуда возникает конкуренция разработки UX/UI, API и code. Есть же классика. Сначала бизнесовый, затем системный анализ (дизайн). Дальше разработку этих трёх составляющих можно начинать параллельно ровно по проведённому анализу
Чек-листы, несомненно, очень полезны. Но есть вопросы. Можете указать конкретные вопросы, которые, как вы считаете, будут дублироваться между разработчиком и тестировщиком, разработчиком и системным аналитиком?
Вчера на собесе в одну хорошую (без иронии) компанию (работает с госами) рассказал старшему аналитику ровно это же. А от меня ждали перечень конкретных диаграм, которые я должен показать заказчику.
К тому, что даже в опытных, казалось бы, компаниях есть какие-то детские болезни.
С другой стороны, специфика заказчика не должна отменять внутренние процессы описанного в статье анализа. Это надо для проекта/продукта
Мы все стремимся упростить рутину. Если включать мозг для каждого вдоха, то мозг загнётся. Автоматизировать проверку - очень хорошая идея. Паниковать по любому багу и призывать всех по любому чиху включать мозг - так себе идея
Статья полезная.
Но, при всём уважении к автору, у аналитиков от определений и терминологий здесь должна идти кровь из глаз. Прям с самого начала:
или всё-таки
?
За что глаз сразу зацепился:
Почему бы не использовать общепринятые и понятные названия элементов?
Что такое "некий"? Почему он "скрытый" и от кого? Значит, остальные процессы - открытые? А логика остальных процессов, которые без шестерёнки, реализуется вне кода?
И понятно, почему так случилось (болд мой):
В этом же ответ, почему в статье явно не выделены, а размазаны по тексту требования, от чего же автор отталкивался и к чему стремился в своей работе
Вот кроме случая, когда команде разработке надо освоить деньги в виде интеграции, других вариантов на ум ничего не приходит, чтобы такой вопрос в принципе существовал. Т.е. рассматривать интеграцию как субъект - ну очень странно.
Наверное, у бизнеса есть выявленная (BA, тут - PO) потребность, и способ решения её - интеграция, ведь так?
У интеграции есть бизнес-цель? Очень интересно.
Интерграция - способ реализации требований, вытекающих из бизнес-цели.
Перепутаны причина и следствие
Все дружно считают проект (деньги, людей, ...) и пресейл(?) идёт к заказчику.
Дальше уже итерационно
Возможно, тут я плохо понимаю, кто такой пресейл.
В моём розовом мире:
1. У потенциального заказчика решения возникла потребность/задача
2. Выдвигается бизнес-аналитик, с заказчиком полностью понимает что надо по бизнесу
3. И только тут подключается SA. Прикидывает архитектуру для данной задачи.
Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA?
В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так?
Приведённые в тексте примеры меня не убедили
К сожалению, интерфейсы для накопителей не бесплатные и ограничены железом.
Надо сравнивать 1 HDD - 1 SSD
В Lightroom недавно встроили Denoise, который использует AI. Очень хороший результат, на мой взгляд
Описание как поставлена работа с заказчиком, про аккаунт-менеджеров и пресейлов, конечно, поразила. Удивительно читать такое странное про одну из крупнейших компаний в ИТ.
Язык статьи тяжёлый, в итоге кусками почитал. Много канцелярита, предложения никак не могут закончиться и начинаются повторы.
В статье получается, что SA, несмотря на название, ещё и бизнесовое решение придумывает. Хотя чего удивляться, см. как у них устроена продажа решений
Пользователями этих чипов являются дата-центры и т.п.
Что делать, если у соседа получается, а у тебя нет? Правильно, гнобить успешных и драть с них деньги (шрафы) под всякими благовидными предлогами. И транжирить их на бюрократию (очередную рабочую группу) и подачки населению для поддержания лояльности. Но ни в коем случае не на развитие.
Интересно, что AIDA - имя андроида в Agents of S.H.I.E.L.D.
Смысл новости в том, что боты накручивают прослушивание ИИ-сгенерированных треков, поэтому Spotify удаляет эти треки?
Т.е. если боты будут накручивать прослушивание "нормальных" треков, Spotify будет удалять "нормальные" треки?
Хотелось бы поподробнее узнать об этой необычной технологии подзарядки аккума
Набор прямоугольников - это "бизнес-система"? Повыдёргивать пункты из давным-давно сформулированных проектных моделей, перетасовать (но не смешивать (с)), поместить их в прямоугольники - и получайте очередное ноу-хау в бизнесе? Пойду-ка, напишу пару книжек, раз так прокатывает.
"Ценностные предложения": "Простой и понятный интерфейс сайта..." - серьёзно?
Вы уверены, что вы сейчас про ценность, а не про способы достижения ценности?
Ну и так далее. Очень странная публикация
Немного перефразировал бы.
Тут вполне можно применить классику - что есть и как должно быть, начиная сверху с бизнес потребностей и вниз. Сопоставить и дальше уже думать (оценивать), монолит или полмонолита, что менять, а что убивать и т.п.
Хм, интересно. Всегда считал, что в контексте разработки Design - это про проектирование системы/продукта, а не про UI/UX.
Так и не понял из статьи, откуда возникает конкуренция разработки UX/UI, API и code.
Есть же классика. Сначала бизнесовый, затем системный анализ (дизайн). Дальше разработку этих трёх составляющих можно начинать параллельно ровно по проведённому анализу
Чек-листы, несомненно, очень полезны.
Но есть вопросы. Можете указать конкретные вопросы, которые, как вы считаете, будут дублироваться между разработчиком и тестировщиком, разработчиком и системным аналитиком?
Какое отношение ваш пример имеет к данной ситуации, где речь ни про деньги, ни про конкуренцию?