ER появились лет за 15 до UML. Это предыдущий подход: структурный анализ и проектирование, конец 60-х и 70-е. Но там они не договорились об унифицированном языке, поэтому имеем штук 10 разных нотаций для указания кратностей связей...
Не, он же не про то пишет, что нужно с UML куда-то уходить. А наоборот - если вы считаете, что он мёртв, так он не мёртв, взять вот хотя бы диаграммы последовательности... Ну и в опросе у меня результаты гораздо более оптимистичные - почти все вполне UML пользуются, нет такого, чтобы совсем выбросили. На первом месте, с большим отрывом, да - диаграммы последовательности, как и пишет Кнут. Но и другими тоже пользуются. Если работает - зачем менять.
Смотря для чего, как тут и пишут. Но смысл статьи не в том, что нужно срочно отказываться от UML. Я тут читаю как раз наоборот - кто не использует, тому, может и не надо, но посмотрите хотя бы на sequence diagram. А если используете и работает - так и не надо отказываться.
Спасибо, очень интересно! Если можно, я бы потом (после НГ) в личку пришёл -- интересно посмотреть, какие были промпты и как можно улучшить результаты ИИ.
Это вы исходите из предположения, что в первом варианте мы заранее точно знаем, что именно хотим построить, и именно это у нас в итоге и получается. Но в случае разработки так почти никогда не получается — заказчику сложно заранее сказать, что в точности ему нужно. Вот когда он увидит что-то похожее — тогда скажет — то, или не то.
Обратите внимание, что в MVP по второму варианту мы полностью выкидываем работающую систему, и делаем вместо неё совсем другую. То есть, это скорее иллюстрация пивота, а не MVP. Далеко не все заказчики и разработчики к такому готовы.
Почему за пределами РФ в командах практически нет аналитиков? Если только это не SAP или какое-то похожее тяжелое решение? Как они там живут без аналитиков?
"Если для идентификации и аутентификации пользователя выбрано решение "пара логин/пароль", система должна предоставлять пользователю возможность восстановления забытого пароля" -- это описание системы как черного ящика, или устройства системы? Или её работы? Это требование или модель? Или это производное требование, появляющееся в результате выбора конструкции?
"В таблице со списком сделок должна быть возможность изменения ширины столбцов. Система должна автоматически сохранять установленную ширину столбцов и восстанавливать её для всех столбцов при последующем открытии таблицы сделок" -- это требования или модель? Они описывают систему как черный ящик, или описывают устройстово системы? Если это требования, то можно ли без них обойтись и заменить их моделью? Что это за модель? Если описание устройства системы даёт преимущества по сравнению с требованиями, то как должно выглядеть это описание применительно к данному случаю?
Пробовал, но есть ощущение, что у него лимит — как будто только первые два-абзаца подхватил, а остальное не прочел. Надо попробовать по частям скормить.
Вижу много комментариев примерно на одну тему, напишу сразу всем, на правах автора :) Остановитесь. Задумайтесь. Почему вы ждете, что эта штука должна работать без ошибок? Я 20 лет занимаюсь созданием ИТ-систем, 12 лет промышленно программировал, больше 10 лет учу и программированию, и анализу; и я _ни разу_ не видел ни новичка, который не делает глупых ошибок (а зачастую просто постоянно пишет полную чушь, будем откровенны), ни опытного программиста, который хотя бы иногда не совершает ошибок (и иногда довольно глупых). Я не понимаю, откуда такая требовательность к языковой модели? Почему вы её идеализируете? Потому что мы привыкли к тому, что машины выполняют всё точно? Но это машина другого рода, она больше похожа на человека, и поэтому не может не ошибаться.
Давайте спокойно относиться, это же просто инструмент. Он не заменяет человека, он усиливает его. Снимает рутину, чтобы оставалось время подумать над действительно важными вещами. Ну а уж у кого что есть -- у того то и усилит :) Кто-то качественный результат давал, и будет выдавать в разы быстрее, а кто чушь нес, тот наплодит чуши в количествах. Обязанности подумать никакая нейросеть не снимает.
Так революция не в том, что бот будет писать вместо аналитика. Про это вроде никто не говорит (я так уж точно). Пусть пишет быстро что-то относящееся к делу, а я его поправлю. Это как очень исполнительный сотрудник -- ты ему пару слов, а он, глядишь, уже полную спеку накатал. Ну, ошибся кое-где, но это от неопытности. Можно поправить снисходительно. Главное, эта штука очень позитивная, и не расстраивается, если у неё где-то ошибка, а берет и исправляет. В отличие от многих молодых сотрудников.
Неправильные ответы бывают, нужно проверять, но это не ощущается, как что-то сложное или удручающее — просто поправляешь в разговоре, это даже греет — я, всё-таки, пока лучше тебя разбираюсь в предмете, железка ты многопараметрическая! :)
Сложности начинаются, когда она тиражирует ошибку — например, неверно проставляет кратности сразу многим связям сущностей. Тогда зачастую исправлять приходится точечно, это муторно.
Контекст удерживает даже слишком хорошо, что в сочетании с ошибками иногда загоняет её в замкнутый круг, когда она повторяет упорно свои неправильные идеи с предыдущих шагов, и тогда её вывести бывает трудно, как бы зацикливается и упорствует.
Специального ввода не нужно, я всегда писал на естественном языке. Иногда она отказывается что-то делать, говорит, что просто общая языковая модель, а не специалист в базах данных или проектировании интерфейсов :) тут она мне как-то отказывалась DDL писать: идите, говорит, к вашему администртору БД. В таких случаях приходится уговаривать или немного хитрить.
Интересно, что ответы на один и тот же запрос не всегда повторяются (скорее даже чаще не повторяются), тут может быть сложность. Если разговор ушёл не туда, начать его с нуля заново и восстановить идентичный до какого-то момента вывод может быть неожиданно непросто. Вероятно, можно попросить её забыть несколько предыдущих ответов, надо попробовать.
В реальных проектах я уже немного попробовал, очень круто получается. Но нужно хорошо понимать, что хочешь получить и как должен выглядеть результат. Даже не знаю, с чем сравнить. Выглядит, как работа с очень умным, быстрым и исполнительным джуном. Ускоряет работу раз в 8-10, по моим прикидкам, но я всего пару дней развлекаюсь.
По поводу продолжения. Сейчас, во-первых, нужно пересмотреть саму концепцию обучения — чему и как учить человека, когда у него есть такой инструмент.
Во-вторых, можно использовать в процессе обучения — для генерации разнообразных примеров и заготовок.
Во-третьих, нужно думать — как должен идеальный инструмент выглядеть. ChatGPT — это же публичная бета, нужно промышленного API ждать.
Класс! Спасибо за статью. Очень рад, что лучшие практики работы сходятся, мы у себя в школе как раз именно такой последовательности учим на буткемпах для аналитиков, буду ссылаться теперь на подтверждение из индустрии :)
Вопрос: в самом начале инструменты друг друга не дублируют? CJM, Event Stormnig и User Story Map ведь очень похожи по назначению, оправданно ли их совместное применение? И что становится бэкбоном USM -- шаги из Event Storming'а или из CJM? То есть, кажется, что через Event Storming можно как раз вычленить этапы процесса, а их уже показать на CJM и выложить на USM, а не наоборот.
Привет, я автор. Комментарий по делу, но это уже на книгу потянет, статья и так огромная получилась :) Да и фокус был на требованиях, которые "изменились" или про которые забыли, а архитектура, легаси и тех. обеспечение редко меняются, от них тут подвоха не ждешь. Что про них просто забывают (неопытные аналитики) — это бывает. Но это другой вид ошибки — "не учли технические требования и особенности реализации".
Докину еще несколько ссылок: http://mechanicalmooc.org/ — обертка для курсов OCW, преобразующая их в подобие MOOCов — вам будут присылать письма и напоминать, что нужно посмотреть лекцию или пройти тест; http://www.coursebuffet.com/ — каталог более 700 онлайн-курсов; http://www.eclass.cc/ — мощный поисковик по курсам, в базе 8000+ онлайн-курсов, из них больше 700 — на русском.
https://habr.com/ru/articles/345320/
ER появились лет за 15 до UML. Это предыдущий подход: структурный анализ и проектирование, конец 60-х и 70-е. Но там они не договорились об унифицированном языке, поэтому имеем штук 10 разных нотаций для указания кратностей связей...
Не, он же не про то пишет, что нужно с UML куда-то уходить. А наоборот - если вы считаете, что он мёртв, так он не мёртв, взять вот хотя бы диаграммы последовательности... Ну и в опросе у меня результаты гораздо более оптимистичные - почти все вполне UML пользуются, нет такого, чтобы совсем выбросили. На первом месте, с большим отрывом, да - диаграммы последовательности, как и пишет Кнут. Но и другими тоже пользуются. Если работает - зачем менять.
Смотря для чего, как тут и пишут. Но смысл статьи не в том, что нужно срочно отказываться от UML. Я тут читаю как раз наоборот - кто не использует, тому, может и не надо, но посмотрите хотя бы на sequence diagram. А если используете и работает - так и не надо отказываться.
Спасибо, очень интересно! Если можно, я бы потом (после НГ) в личку пришёл -- интересно посмотреть, какие были промпты и как можно улучшить результаты ИИ.
Это вы исходите из предположения, что в первом варианте мы заранее точно знаем, что именно хотим построить, и именно это у нас в итоге и получается. Но в случае разработки так почти никогда не получается — заказчику сложно заранее сказать, что в точности ему нужно. Вот когда он увидит что-то похожее — тогда скажет — то, или не то.
Обратите внимание, что в MVP по второму варианту мы полностью выкидываем работающую систему, и делаем вместо неё совсем другую. То есть, это скорее иллюстрация пивота, а не MVP. Далеко не все заказчики и разработчики к такому готовы.
Почему за пределами РФ в командах практически нет аналитиков? Если только это не SAP или какое-то похожее тяжелое решение? Как они там живут без аналитиков?
То есть, модель не заменяет требования, и одной моделью обойтись невозможно? Я, наверное, неверно заголовок понял,слишком радикально.
"Если для идентификации и аутентификации пользователя выбрано решение "пара логин/пароль", система должна предоставлять пользователю возможность восстановления забытого пароля" -- это описание системы как черного ящика, или устройства системы? Или её работы? Это требование или модель? Или это производное требование, появляющееся в результате выбора конструкции?
"В таблице со списком сделок должна быть возможность изменения ширины столбцов. Система должна автоматически сохранять установленную ширину столбцов и восстанавливать её для всех столбцов при последующем открытии таблицы сделок" -- это требования или модель? Они описывают систему как черный ящик, или описывают устройстово системы? Если это требования, то можно ли без них обойтись и заменить их моделью? Что это за модель? Если описание устройства системы даёт преимущества по сравнению с требованиями, то как должно выглядеть это описание применительно к данному случаю?
Я так и не понял — что такое модель, и чем она отличается от требований...
Спасибо за наблюдение про разных "бизнес-аналитиков", очень точно! Название одно и то же, а хотят везде разного, в последнее время даже REST и SQL :)
Пробовал, но есть ощущение, что у него лимит — как будто только первые два-абзаца подхватил, а остальное не прочел. Надо попробовать по частям скормить.
Вижу много комментариев примерно на одну тему, напишу сразу всем, на правах автора :) Остановитесь. Задумайтесь. Почему вы ждете, что эта штука должна работать без ошибок? Я 20 лет занимаюсь созданием ИТ-систем, 12 лет промышленно программировал, больше 10 лет учу и программированию, и анализу; и я _ни разу_ не видел ни новичка, который не делает глупых ошибок (а зачастую просто постоянно пишет полную чушь, будем откровенны), ни опытного программиста, который хотя бы иногда не совершает ошибок (и иногда довольно глупых). Я не понимаю, откуда такая требовательность к языковой модели? Почему вы её идеализируете? Потому что мы привыкли к тому, что машины выполняют всё точно? Но это машина другого рода, она больше похожа на человека, и поэтому не может не ошибаться.
Давайте спокойно относиться, это же просто инструмент. Он не заменяет человека, он усиливает его. Снимает рутину, чтобы оставалось время подумать над действительно важными вещами. Ну а уж у кого что есть -- у того то и усилит :) Кто-то качественный результат давал, и будет выдавать в разы быстрее, а кто чушь нес, тот наплодит чуши в количествах. Обязанности подумать никакая нейросеть не снимает.
Так революция не в том, что бот будет писать вместо аналитика. Про это вроде никто не говорит (я так уж точно). Пусть пишет быстро что-то относящееся к делу, а я его поправлю. Это как очень исполнительный сотрудник -- ты ему пару слов, а он, глядишь, уже полную спеку накатал. Ну, ошибся кое-где, но это от неопытности. Можно поправить снисходительно. Главное, эта штука очень позитивная, и не расстраивается, если у неё где-то ошибка, а берет и исправляет. В отличие от многих молодых сотрудников.
Неправильные ответы бывают, нужно проверять, но это не ощущается, как что-то сложное или удручающее — просто поправляешь в разговоре, это даже греет — я, всё-таки, пока лучше тебя разбираюсь в предмете, железка ты многопараметрическая! :)
Сложности начинаются, когда она тиражирует ошибку — например, неверно проставляет кратности сразу многим связям сущностей. Тогда зачастую исправлять приходится точечно, это муторно.
Контекст удерживает даже слишком хорошо, что в сочетании с ошибками иногда загоняет её в замкнутый круг, когда она повторяет упорно свои неправильные идеи с предыдущих шагов, и тогда её вывести бывает трудно, как бы зацикливается и упорствует.
Специального ввода не нужно, я всегда писал на естественном языке. Иногда она отказывается что-то делать, говорит, что просто общая языковая модель, а не специалист в базах данных или проектировании интерфейсов :) тут она мне как-то отказывалась DDL писать: идите, говорит, к вашему администртору БД. В таких случаях приходится уговаривать или немного хитрить.
Интересно, что ответы на один и тот же запрос не всегда повторяются (скорее даже чаще не повторяются), тут может быть сложность. Если разговор ушёл не туда, начать его с нуля заново и восстановить идентичный до какого-то момента вывод может быть неожиданно непросто. Вероятно, можно попросить её забыть несколько предыдущих ответов, надо попробовать.
В реальных проектах я уже немного попробовал, очень круто получается. Но нужно хорошо понимать, что хочешь получить и как должен выглядеть результат. Даже не знаю, с чем сравнить. Выглядит, как работа с очень умным, быстрым и исполнительным джуном. Ускоряет работу раз в 8-10, по моим прикидкам, но я всего пару дней развлекаюсь.
По поводу продолжения. Сейчас, во-первых, нужно пересмотреть саму концепцию обучения — чему и как учить человека, когда у него есть такой инструмент.
Во-вторых, можно использовать в процессе обучения — для генерации разнообразных примеров и заготовок.
Во-третьих, нужно думать — как должен идеальный инструмент выглядеть. ChatGPT — это же публичная бета, нужно промышленного API ждать.
Класс! Спасибо за статью. Очень рад, что лучшие практики работы сходятся, мы у себя в школе как раз именно такой последовательности учим на буткемпах для аналитиков, буду ссылаться теперь на подтверждение из индустрии :)
Вопрос: в самом начале инструменты друг друга не дублируют? CJM, Event Stormnig и User Story Map ведь очень похожи по назначению, оправданно ли их совместное применение? И что становится бэкбоном USM -- шаги из Event Storming'а или из CJM? То есть, кажется, что через Event Storming можно как раз вычленить этапы процесса, а их уже показать на CJM и выложить на USM, а не наоборот.
Привет, я автор. Комментарий по делу, но это уже на книгу потянет, статья и так огромная получилась :) Да и фокус был на требованиях, которые "изменились" или про которые забыли, а архитектура, легаси и тех. обеспечение редко меняются, от них тут подвоха не ждешь. Что про них просто забывают (неопытные аналитики) — это бывает. Но это другой вид ошибки — "не учли технические требования и особенности реализации".