ИИ-модели изначально делали не для разработки сложных систем, а для разговоров. И когда вы что-то от нее просите. то надо задавать роль. Когда вы ее явно используете для написания кода и других разработческих задач, такая роль задана из коробки, там проблем нет. А вот когда обсуждаете какие-то свои проекты или новую для вас предметную область, она по умолчанию не понимает, кто вы - специалист или праздноинтересующийся блогер.
Что касается множества противоречивых терминологии, то Эванс в свое время придумал гениальное решение: делаем ограниченные контексты и их сшиваем, а то непорядок: софт уже модульный, а модели предметной области - монолитные. И Левенчук тоже методологически разбирался с этим в своих курсах, это уже давно там есть. И в FPF для ИИ это тоже перенесено - понятие языков разных предметных областей. А при переносе описаний системного подхода в FPF он много раз вставал на грабли, когда одно слово имеет 3-5-7 значений, например, под "map" подразумевается процесс, результат процесса и еще что-то. и разводил терминологию, иначе ИИ ошибался так же, как человек. ИИ с правилами - умеет выдерживать заданную терминологию.
Проблема в том, что он не знает вашей терминологии, ее надо выложить в виде правил, а это - непросто. Человек же не говорит языком конкретного ГОСТа, у каждого из нас - смесь разных терминов из разных учебников и методологий, в командах и проектах это как-то синхронизируется, но обычно не выкладывается. И новички из других проектов на такие грабли регулярно наступают.
Способность ошибаться или фантазировать ответы присуща ИИ не больше, чем студенту, отвечающему на экзамене на вопрос, который он знает смутно. При этом на работе многие продолжают вести себя так же, как на экзамене - выполняя задачу "как поняли", домысливая и фантазируя. ИИ уже лучше студента, ее знаний гораздо больше, при чем по площади. И большинство кейсов. когда "ИИ нафантазировала" делятся на две категории: ей смутно поставили задачу, не сказав важного или ее намеренно ввели в заблуждение, а она приучена доверять человеку, какой бы бред он не нес, потому что у нее цель - продолжать разговор, а не воспитывать. При этом ИИ способен проверять свои результаты - только для этого надо задать критерии что такое хорошо (или качественно). НА семинаре об этом много говорили, и во фреймворке есть готовые шаблоны для проверки, в том числе сложных решений.
С этим согласен. Есть большая проблема даже с объектным подходом - взгляд на мир через объекты и методы работы с ними, хотя, казалось бы в чем проблема, большинство современных языков как раз объектные. А системный подход - это следующий такт. Проблема начинается со сложными задачами, которые требуют учитывать много аспектов. НО их в современном ИТ много, почти все задачи масштабирования под нагрузкой с обеспечением устойчивости работы носят такой характер. И архитектурные решения алгоритмически не сделать...
Разница между Software Lifecycle и Software development lifecycle - очевидна. SDLC, как легко увидеть из аббревиатуры - это Software Development LifeCycle. Хотя да, они закрутили его вы цикл, предполагая то ли итерационную разработку, то ли вечное развитие - точно так же как PMBoK в 6 (по-моему) версии закрутил в цикл работу по проекту - тут уже явно говоря про итерации или этапы реализации.
Кто что написал в 80-х было бы совершенно не актуально, если бы в в многочисленных выступлениях на конференциях и статьях сейчас не ссылались на этот самый SDLC. Не определяя, что именно это такое, но неявно предполагая что столь почтенная и освященная традицией штука не может быть фигней. А вот на ГОСТы - не ссылаются, ни на 34, ни на 54. Впрочем они до сих пор преимущественно калька с западных стандартов.
SDLC расшифровывается как Software Development LifeCycle, так что статья вики как раз правильная. И там с каким-то качеством описано, что это такое. V-модель - предтеча стандарта ISO - она появилась намного раньше, и стандарт действительно от нее не отличается. А вот SDLC отличается от V-модели тем, что ПЕРЕД фазой Analysis воткнули фазу Planing. Что есть абсурд. И именно этому посвящена данная статья. Я не обещал объяснить, что такое SDLC и, увы, не могу отвечать за то, что поиск по запросу "SDLC" выводит на нее. А по факту из статьи следует, что SDLC - почтенный лейбл для неработающей схемы, которую люди как-то пытаются интерпретировать и применить, вместо того, чтобы выбросить без почтения.
Впрочем, буду рад прочесть вашу статью - любая интерпретация практического опыта интересна.
По меркам Китая они платят примерно вдвое выше рынка. Они называли конкретные цифры, и люди из принимающей стороны подтвердили, что это правда. В цифрах это выглядит так: зарплаты 500 тыс – 2 млн юаней в год, отпуска (10 дней в год, больничные, материнство - это в Китае хорошо), мед.страховка, питание в офисе, фитнес и медцентр в офисе, субсидия за аренду жилья (но небольшая, 2 тыс в месяц), служебное такси, компенсация за отношения на расстоянии (если муж в Пекине, а жена в Шанхае, то +3 тыс), развлечения (день питомцев, визит знаменитостей, клубы по интересам, ярмарки), другие социальные блага (все записано с голоса). 1 юань - около 12 рублей. Так что у компании нет проблем с наймом.
Да, сотрудник не владеет компанией. И он это понимает - и в Китае и везде.
Страх перед тем, что ИИ лишит всех работы приходит к нам с Запада. И фокус на проектах, которые позволят за счет ИИ сократить много рабочих мест - он тоже оттуда. То есть из тех мест, где рождаются (рождались?) самые современные модели. А доступ к моделям - он есть, с этим, по-моему, нет ни у кого проблемы.
Но, даже если принять вашу метафору, то пора детям становиться взрослыми. Не абы какими, а умными. Это само не происходит, а требует усилий. Статья - мой скромный вклад.
SDLC точно не описывает рост специалиста, это про проект, но картинка умозрительная, тут я согласен. И то, что нет правил и алгоритмов - тоже. Собственно, меня огорчает то, что многие верят в их существование и пытаются ими овладеть, вместо того, чтобы заниматься более полезными вещами. Поэтому и родилась статья, попытка объяснить.
А что касается вашего списка, то там до кода есть 1 - концептуальное описание. Которое должно убедить команду (если в разработке больше одного человека), а еще должно убедить владельца денег одобрить реализацию, если команда не будет делать это за свой счет в свободное время. И это - важная часть. Но потом - код, особенно если идея новая, тут я согласен.
Мне еще интересен пункт 3 про фиктивные требования. Он как-то наводит на мысли, что финансирование могут одобрить на одни цели, а фактически сделать другое, и надо закрыть разрыв. Или это обычные корпоративные игры, когда руководитель может санкционировать работу, но дальше ему нужны отчеты, что все было "по процессу"? Или имеется ввиду что-то другое?
Я о Domain Storytelling не знал, спасибо за наводку. Сейчас быстро посмотрел материалы - там две идеи. Первая - что вместо индивидуальных интервью спецов аналитиками с последующим сведением того, что они расскажут лучше собрать вместе экспертов и команду на workshop. Для беглого знакомства, наверное, лучше, и по астрономическому времени - быстрее, а вот по человеко-часам - больше, так что эффективность сильно зависит от организации встреч.
И вторая - визуальный язык для записи этих историй. Он повышает эффективность встреч. Но пригоден только для задач документооборота, историю о выверки отчетности или другие аналитические истории на нем не запишешь.
По сравнению с Event Storming отличается язык моделирования. В ES у нас события, в DS - workflow документооборота. События - более общий язык. F еще детальность, ES просто фиксирует наличие истории, детализация - вне сессии, а DS - углубляется в нее. Так что DS можно применять для тех областей, где его язык адекватен для детализации и погружения взамен обычной проработки user story через интервью.
Это - слабое место Agile-методов. Архитектура проектируется в нулевой итерации, которая готовит старт проекта. Но там речь идет, скорее, о выборе технологий и фреймворка: взяли и погнали делать истории. А в первых историях - всегда самые распространенные сценарии: заказ оплачивается и отгружается полностью, весь товар склад находит и отгружает и так далее. То есть вместо 1:n связь 1:1, что позволяет вообще объединить сущности, расширив атрибутный состав. А дальше, когда доходит до сложных историй, выясняется, что рефакторить надо не только хранение - весь интерфейс заточен на то, что оплата - одна, а отгрузка - полная, а не частичная. И рефакторинг - дорогой.
Впрочем, часто можно не рефакторить. Не нашел склад какой-то товар - так вместо фиксации неполной отгрузки взяли и разделили заказ на два, один - отгружен, второй - нет. И оплату тоже разделили на две. Там с выпиской не будет биться по документам, но это - локальное усложнение, можно на атрибутах отработать. Вот много оплат за 1 единицу дорого товара принять - да, тут надо как-то будет придумывать при единственной оплате...
Но это все равно про фрагменты, с архитектурой сложной системы в целом с развитием получается беда быстрее, чем при развитии после проектирования. Хотя при проектировании тоже можно не угадать.
Если бизнес-заказчикам объяснять, что "вот эти объекты у нас будут во всех системах одинаковы" или "мы не будем поддерживать структуру объектов старой legacy-системы, у нас будет другая структура, и мы будем делать преобразования при интеграции" - понимают. Но да, важны объяснения в понятных им терминах. Это проблема, такая же как с диаграммами классов - она очень богатая, чтобы бизнес-заказчики ее понимали - надо использовать разумное подмножество, ограничивать себя. Иначе ты что-то нарисовал, и думаешь что объяснил важное, а они думают "ну, здесь какие-то непонятные значки, наверное техническое и неважное".
ERwin да, предлагал. Но это - уже проектирование БД, этап дизайна, а не бизнес-модели. А вот что модель предметной области должна быть целостной и непротиворечивой - учебники писали.
Потому что макеты интерфейсов не раскрывают структуру системы. Ты добавил на заказ в интерфейсах магазина поле "комментарий для курьера как проехать" или даже возможность подгрузить туда рисунок - а этого мало, еще надо протянуть через интеграцию через все системы до мобильного рабочего места курьера и там показать. Или сделал признак на заказе "отгружать по предоплате" - тоже надо учесть в алгоритмах, чтобы если предоплаты нет - склад не начинал собирать заказ и, главное, не отгрузил его. Куча прецедентов, когда про все эти связи забывали, а просто дорисовывали интерфейс.
Смотри, тут слева - модель деятельности в виде бизнес-процессов, а дальше - ее поддержка через workflow бизнес-объектов, реализованных в системе. То есть единая модель включает и предметную область и систему.
Вот смотри: сначала делаем бизнес-модель, потом из нее - требования (черный ящик), потом на их основе - дизайн. При этом требования - граница между работой бизнес-аналитика и системного аналитика, именно они сшивают модели. И именно поэтому к ним внимание, чтобы обеспечить посыл: "система, удовлетворяющая требованиям будет решать бизнес-задачу". А так - не работает. И сила DDD в том, что он три разных процесса объединил в работу с одной моделью. Напрямую прослеживая на основе модели, как такой софт будет поддерживать бизнес-процессы на требуемом уровне.
Да, мы тоже строили объектную модель предметной области через диаграммы классов UML с середины нулевых. Книги по DDD переведены позднее. Но на английском книга Эванса вышла в 2003.
ИИ-модели изначально делали не для разработки сложных систем, а для разговоров. И когда вы что-то от нее просите. то надо задавать роль. Когда вы ее явно используете для написания кода и других разработческих задач, такая роль задана из коробки, там проблем нет. А вот когда обсуждаете какие-то свои проекты или новую для вас предметную область, она по умолчанию не понимает, кто вы - специалист или праздноинтересующийся блогер.
Что касается множества противоречивых терминологии, то Эванс в свое время придумал гениальное решение: делаем ограниченные контексты и их сшиваем, а то непорядок: софт уже модульный, а модели предметной области - монолитные. И Левенчук тоже методологически разбирался с этим в своих курсах, это уже давно там есть. И в FPF для ИИ это тоже перенесено - понятие языков разных предметных областей. А при переносе описаний системного подхода в FPF он много раз вставал на грабли, когда одно слово имеет 3-5-7 значений, например, под "map" подразумевается процесс, результат процесса и еще что-то. и разводил терминологию, иначе ИИ ошибался так же, как человек. ИИ с правилами - умеет выдерживать заданную терминологию.
Проблема в том, что он не знает вашей терминологии, ее надо выложить в виде правил, а это - непросто. Человек же не говорит языком конкретного ГОСТа, у каждого из нас - смесь разных терминов из разных учебников и методологий, в командах и проектах это как-то синхронизируется, но обычно не выкладывается. И новички из других проектов на такие грабли регулярно наступают.
Способность ошибаться или фантазировать ответы присуща ИИ не больше, чем студенту, отвечающему на экзамене на вопрос, который он знает смутно. При этом на работе многие продолжают вести себя так же, как на экзамене - выполняя задачу "как поняли", домысливая и фантазируя. ИИ уже лучше студента, ее знаний гораздо больше, при чем по площади. И большинство кейсов. когда "ИИ нафантазировала" делятся на две категории: ей смутно поставили задачу, не сказав важного или ее намеренно ввели в заблуждение, а она приучена доверять человеку, какой бы бред он не нес, потому что у нее цель - продолжать разговор, а не воспитывать. При этом ИИ способен проверять свои результаты - только для этого надо задать критерии что такое хорошо (или качественно). НА семинаре об этом много говорили, и во фреймворке есть готовые шаблоны для проверки, в том числе сложных решений.
С этим согласен. Есть большая проблема даже с объектным подходом - взгляд на мир через объекты и методы работы с ними, хотя, казалось бы в чем проблема, большинство современных языков как раз объектные. А системный подход - это следующий такт. Проблема начинается со сложными задачами, которые требуют учитывать много аспектов. НО их в современном ИТ много, почти все задачи масштабирования под нагрузкой с обеспечением устойчивости работы носят такой характер. И архитектурные решения алгоритмически не сделать...
Рад, что понравилось! Фестивалю уже 10 лет, он небольшой, но очень атмосферный и при этом вполне профессиональный.
Разница между Software Lifecycle и Software development lifecycle - очевидна. SDLC, как легко увидеть из аббревиатуры - это Software Development LifeCycle. Хотя да, они закрутили его вы цикл, предполагая то ли итерационную разработку, то ли вечное развитие - точно так же как PMBoK в 6 (по-моему) версии закрутил в цикл работу по проекту - тут уже явно говоря про итерации или этапы реализации.
Кто что написал в 80-х было бы совершенно не актуально, если бы в в многочисленных выступлениях на конференциях и статьях сейчас не ссылались на этот самый SDLC. Не определяя, что именно это такое, но неявно предполагая что столь почтенная и освященная традицией штука не может быть фигней. А вот на ГОСТы - не ссылаются, ни на 34, ни на 54. Впрочем они до сих пор преимущественно калька с западных стандартов.
И с ИТ-проектами есть такая засада. Современный PMBoK и связанные с ним стандарты выросли из RUP, попытки управления именно ИТ-проектами. Проблема в том, что эта попытка провалилась, еще в 90-х, именно поэтому в ИТ выросло семейство Agile-методов. А у нас по-прежнему пробуют это применять с соответствующими последствиями. У меня именно на эту тему было выступление Почему проектный подход не работает в IT и есть две статьи: Развитие и провал регулярного менеджмента в IT и Agile-методы и проектный подход - в чем разница?
SDLC расшифровывается как Software Development LifeCycle, так что статья вики как раз правильная. И там с каким-то качеством описано, что это такое. V-модель - предтеча стандарта ISO - она появилась намного раньше, и стандарт действительно от нее не отличается. А вот SDLC отличается от V-модели тем, что ПЕРЕД фазой Analysis воткнули фазу Planing. Что есть абсурд. И именно этому посвящена данная статья. Я не обещал объяснить, что такое SDLC и, увы, не могу отвечать за то, что поиск по запросу "SDLC" выводит на нее. А по факту из статьи следует, что SDLC - почтенный лейбл для неработающей схемы, которую люди как-то пытаются интерпретировать и применить, вместо того, чтобы выбросить без почтения.
Впрочем, буду рад прочесть вашу статью - любая интерпретация практического опыта интересна.
По меркам Китая они платят примерно вдвое выше рынка. Они называли конкретные цифры, и люди из принимающей стороны подтвердили, что это правда. В цифрах это выглядит так: зарплаты 500 тыс – 2 млн юаней в год, отпуска (10 дней в год, больничные, материнство - это в Китае хорошо), мед.страховка, питание в офисе, фитнес и медцентр в офисе, субсидия за аренду жилья (но небольшая, 2 тыс в месяц), служебное такси, компенсация за отношения на расстоянии (если муж в Пекине, а жена в Шанхае, то +3 тыс), развлечения (день питомцев, визит знаменитостей, клубы по интересам, ярмарки), другие социальные блага (все записано с голоса). 1 юань - около 12 рублей. Так что у компании нет проблем с наймом.
Да, сотрудник не владеет компанией. И он это понимает - и в Китае и везде.
Да, очень правильное замечание! Спасибо!
Страх перед тем, что ИИ лишит всех работы приходит к нам с Запада. И фокус на проектах, которые позволят за счет ИИ сократить много рабочих мест - он тоже оттуда. То есть из тех мест, где рождаются (рождались?) самые современные модели. А доступ к моделям - он есть, с этим, по-моему, нет ни у кого проблемы.
Но, даже если принять вашу метафору, то пора детям становиться взрослыми. Не абы какими, а умными. Это само не происходит, а требует усилий. Статья - мой скромный вклад.
SDLC точно не описывает рост специалиста, это про проект, но картинка умозрительная, тут я согласен. И то, что нет правил и алгоритмов - тоже. Собственно, меня огорчает то, что многие верят в их существование и пытаются ими овладеть, вместо того, чтобы заниматься более полезными вещами. Поэтому и родилась статья, попытка объяснить.
А что касается вашего списка, то там до кода есть 1 - концептуальное описание. Которое должно убедить команду (если в разработке больше одного человека), а еще должно убедить владельца денег одобрить реализацию, если команда не будет делать это за свой счет в свободное время. И это - важная часть. Но потом - код, особенно если идея новая, тут я согласен.
Мне еще интересен пункт 3 про фиктивные требования. Он как-то наводит на мысли, что финансирование могут одобрить на одни цели, а фактически сделать другое, и надо закрыть разрыв. Или это обычные корпоративные игры, когда руководитель может санкционировать работу, но дальше ему нужны отчеты, что все было "по процессу"? Или имеется ввиду что-то другое?
Я о Domain Storytelling не знал, спасибо за наводку. Сейчас быстро посмотрел материалы - там две идеи. Первая - что вместо индивидуальных интервью спецов аналитиками с последующим сведением того, что они расскажут лучше собрать вместе экспертов и команду на workshop. Для беглого знакомства, наверное, лучше, и по астрономическому времени - быстрее, а вот по человеко-часам - больше, так что эффективность сильно зависит от организации встреч.
И вторая - визуальный язык для записи этих историй. Он повышает эффективность встреч. Но пригоден только для задач документооборота, историю о выверки отчетности или другие аналитические истории на нем не запишешь.
По сравнению с Event Storming отличается язык моделирования. В ES у нас события, в DS - workflow документооборота. События - более общий язык. F еще детальность, ES просто фиксирует наличие истории, детализация - вне сессии, а DS - углубляется в нее. Так что DS можно применять для тех областей, где его язык адекватен для детализации и погружения взамен обычной проработки user story через интервью.
Это - слабое место Agile-методов. Архитектура проектируется в нулевой итерации, которая готовит старт проекта. Но там речь идет, скорее, о выборе технологий и фреймворка: взяли и погнали делать истории. А в первых историях - всегда самые распространенные сценарии: заказ оплачивается и отгружается полностью, весь товар склад находит и отгружает и так далее. То есть вместо 1:n связь 1:1, что позволяет вообще объединить сущности, расширив атрибутный состав. А дальше, когда доходит до сложных историй, выясняется, что рефакторить надо не только хранение - весь интерфейс заточен на то, что оплата - одна, а отгрузка - полная, а не частичная. И рефакторинг - дорогой.
Впрочем, часто можно не рефакторить. Не нашел склад какой-то товар - так вместо фиксации неполной отгрузки взяли и разделили заказ на два, один - отгружен, второй - нет. И оплату тоже разделили на две. Там с выпиской не будет биться по документам, но это - локальное усложнение, можно на атрибутах отработать. Вот много оплат за 1 единицу дорого товара принять - да, тут надо как-то будет придумывать при единственной оплате...
Но это все равно про фрагменты, с архитектурой сложной системы в целом с развитием получается беда быстрее, чем при развитии после проектирования. Хотя при проектировании тоже можно не угадать.
Большое спасибо за такие развернутые комментарии! Когда из этого буду делать доклады или другие материалы - обязательно учту наше обсуждение!
Если бизнес-заказчикам объяснять, что "вот эти объекты у нас будут во всех системах одинаковы" или "мы не будем поддерживать структуру объектов старой legacy-системы, у нас будет другая структура, и мы будем делать преобразования при интеграции" - понимают. Но да, важны объяснения в понятных им терминах. Это проблема, такая же как с диаграммами классов - она очень богатая, чтобы бизнес-заказчики ее понимали - надо использовать разумное подмножество, ограничивать себя. Иначе ты что-то нарисовал, и думаешь что объяснил важное, а они думают "ну, здесь какие-то непонятные значки, наверное техническое и неважное".
ERwin да, предлагал. Но это - уже проектирование БД, этап дизайна, а не бизнес-модели. А вот что модель предметной области должна быть целостной и непротиворечивой - учебники писали.
Потому что макеты интерфейсов не раскрывают структуру системы. Ты добавил на заказ в интерфейсах магазина поле "комментарий для курьера как проехать" или даже возможность подгрузить туда рисунок - а этого мало, еще надо протянуть через интеграцию через все системы до мобильного рабочего места курьера и там показать. Или сделал признак на заказе "отгружать по предоплате" - тоже надо учесть в алгоритмах, чтобы если предоплаты нет - склад не начинал собирать заказ и, главное, не отгрузил его. Куча прецедентов, когда про все эти связи забывали, а просто дорисовывали интерфейс.
Use case и user story - альтернативная история. В принципе это тоже требования - потому что система описывается как черный ящик.
Смотри, тут слева - модель деятельности в виде бизнес-процессов, а дальше - ее поддержка через workflow бизнес-объектов, реализованных в системе. То есть единая модель включает и предметную область и систему.
Вот смотри: сначала делаем бизнес-модель, потом из нее - требования (черный ящик), потом на их основе - дизайн. При этом требования - граница между работой бизнес-аналитика и системного аналитика, именно они сшивают модели. И именно поэтому к ним внимание, чтобы обеспечить посыл: "система, удовлетворяющая требованиям будет решать бизнес-задачу". А так - не работает. И сила DDD в том, что он три разных процесса объединил в работу с одной моделью. Напрямую прослеживая на основе модели, как такой софт будет поддерживать бизнес-процессы на требуемом уровне.
Да, мы тоже строили объектную модель предметной области через диаграммы классов UML с середины нулевых. Книги по DDD переведены позднее. Но на английском книга Эванса вышла в 2003.