А зачем вообще использовать тактический DDD? Он вообще крайне громоздкий и неэффективный и довольно плохо описанный.
Из чисто технических мелочей; 1) Вообще "саги" в современном понимании не обязательно предполагают компенсации. Да и "позвать человека, чтобы исправил" - это, формально, тоже компенсация. 2) Tempora лучше использовать проведения линейной транзакции, без откатов. Вообще нужно строить систему так, чтобы не было понятие "вызов компенсации" и "откат транзакции", только "повтор". Как ни странно, почти во всех случаях это возможно. 3) Как только у вас появляется распределенная система и требуется хоть какая-то целостность - нужно реализовывать механизмы реконсиляции. Для МСА по DDD - это особенно необходимо из-за огромного объема дублирования информации.
И да, в IT есть две настоящие проблемы. DDD помогает с одной за счет другой )
"Как система должна работать" - это и есть проектирование. И это может делать только человек, погруженный в реализацию системы (разработчик, архитектор, техлид и т.п.). Это не имеет никакого отношения к анализу.
Связующее звено между бизнесом и разработкой (на IT-службой, это вообще из другой оперы) называются продакт-менеджерами.
Опять проблемы с терминологией. То, что в статье называют бизнес-аналитиком - как раз функции системного аналитика в большинстве компаний. То, что назвали "системным аналитиком" - функции техлида или разработчика внедрения. Про функции бизнес-аналитика в статье вообще ни слова не сказано.
Хочу напомнить, что аналитик - не занимается проектированием и разработкой, это задачи для другой роли. В статье смешали задачи решения проблем заказчика, сбора требований, проектирования и реализации. Это разные активности, которые могут очень разными способами распределяться по команде, но "как" - это всегда задачи разработчика, а не аналитика.
А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек? Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция. Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы. Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.
Хм, смотря каких рынков. Есть рынок компактных среднеформатников, там Fuji и Хассель. Есть рынок пафосных дальномерок, там Leica и Fuji Есть рынок компактных камер, там Олимпус и Панасоник Есть рынок профессиональных полнокадровых камер и там Никон с Кэноном и Сони. Ну и так далее. Нет единого рынка фототехники, есть много разных рынков, с разными лидерами, разными стратегиями и так далее. И Никон с Кэноном далеко не на всех конкурируют и даже не на всех представлены.
Увы, но есть люди, которые не воспринимают критику, донесенную без использования эмоционально окрашенных слов. Часто они же не очень компетентны. И в этом случае иногда описать то, что они сделали в точных и эмоционально окрашенных терминах ("этот код - полное дерьмо") является единственным способом смотивировать на его переделку. Разумеется, добавив конструктивных причин подобной формулировки и рекомендаций по устранению. Уволить их можно, но это же надо ждать где-то год, а работу делать надо.
Так нанимают все больше в компанию, а не в команду. И уж кого наняли - того наняли (и да, это, конечно, проблема компании, но такой подход, увы, массовый).
Хм, проблемы представительности как раз не представляют особой проблемы. Достаточно просто собирать данные не в режиме "пришлите кто-нибудь", а через обращения в компании согласно статистическим данным (хотя бы по размеру и по отраслям), впрочем есть и куча других подходов. Верификацию-то уж точно стоило бы сделать. Как и глубинные интервью хотя бы с некоторыми компаниями (лучше с каким-то представительным количеством). Но ничего из этого не делалось, так как, кажется, цели сделать что-то обоснованное - не ставилось. Проверку каузации вполне можно сделать - например посмотреть, как меняется доходность в компаниях с резким изменением метрик (причем тоже с разным размерами и из разных отраслей). Скорее всего финансовые показатели при этом не изменятся. (Кстати, так как больше всего делилось данными люди из крупных компаний, где реально скорость доставки имеет смысл и легче обеспечиваются - то корреляция выглядит очевидной. Но понятно, что доставку 10 релизов в день в компании в 10 человек нет смысла делать. Впрочем, кажется, там и успех компаний считали абсолютные, а не в привязке на сотрудника, что уже совсем бессмысленно). И да, конечно индексы счастья или коррупции - бесполезны и не дают никакой полезной информации и не обладают никакой прогностической силы.
Про DORA. Там проблемы в сборе самих метрик (их присылали произвольные люди по собственной инициативе, без какой-то верификации данных, без определения представительности присланных данных, даже без соотношения данных с конкретными департаментами компаний), проблемы в отслеживании корреляций (не было анализа кластеризации по секторам, не оценивалась вообще важность для бизнеса метрик, некоторые метрики вообще не могут быть оценены для многих компаний). Ну и "корреляция не значит каузация". Так что говорить о какой-то большей обоснованности метрик DORA, нежели, например, натальной карты сервера - не приходится.
По поводу очевидности - тут как раз используемые решения были очевидно первыми, в том числе и для улучшения метрик. Но при этом же метрики никак с изменением подхода к бранчам не связаны, для улучшения метрик могли и еще десяток тестовых кластеров поставить, например.
Но вы правильно пишите, что метрики нужны для убеждения - да, в этом они помогают.
Хм, но DORA метрики, на самом деле, ни с чем не коррелируют (там исследование не может ничего доказать, так как сделано некорректно). Реально я вижу переход к относительно современной модели бранчевания, но этот подход очевиден уже при первом взгляде на старую модель. Зачем тут DORA?
P.S. Но да, DORA может использоваться для убеждение не слишком компетентного менеджмента для проведения достаточно очевидных изменений в пайплайне. Другой ценности в метриках нет.
Хм, TOGAF и прочее - это скорее про Enterprise Arch, а не про SolArch или SysArch. Да, эта роль возникает только в очень крупных компаниях. Но наличие корпоративного архитектора не значит, что на уровне отдельного продукта внутри департамента не используется DDD. Большие компании - большие, там много что внутри происходит )
Хм, вроде бы стратегические паттерны DDD - это как раз работа архитектора (как роли и, иногда, как позиции). Да и выявление UL/BC полезно в проекте любого размера.
Ну да, архитектор - это про правила взаимодействия разных команд в первую очередь. И никакой agile не убрал необходимости в архитекторе (как и не было необходимости в позиции архитектора в микропроектах на одну небольшую команду). Но в статье вообще путают активности, роли и позиции. Активности архитектора есть в любом проекте, роль - почти всегда, а позиция нужна уже только при нескольких командах.
Хм, он по производительности совсем в другой лиге, там и 50k сообщений в секунду - уже проблема, да и с надежностью и кластеризацией не очень хочется. Его можно разве что с Mosquito сравнивать, но будет примерно то же - сплошные "нет" и "умеренно".
На большинстве конференций предлагают свои шаблоны для презентаций, где большая часть этих пожеланий учтена (впрочем, я еще не видел ни одного действительно хорошего шаблона презентации от конференции, всюду какие-то огрехи, так как их придумывают дизайнеры). Если же конференция не присылает своего шаблона, то стоит использовать стандартный шаблон компании, а уж дизайнер обычно базовые вещи сможет сделать. Если нет стандартного шаблона в компании - то его полезно разработать, но не только дизайнеру.
Но, вообще, мне сложно представить презентацию, которой подошел бы дизайн из статьи. Очень много мелкого текста (не видно с дальних рядом), нет истории (много пунктов на одном слайде), нет номеров страниц, заголовок мало отделен от текста (впрочем, нужны ли заголовки на слайдах - вообще дискуссионный вопрос, мне как спикеру проще с ними, но слушателям они скорее мешают), текстовые блоки размещены в разных частях страниц.
А зачем вообще использовать тактический DDD? Он вообще крайне громоздкий и неэффективный и довольно плохо описанный.
Из чисто технических мелочей;
1) Вообще "саги" в современном понимании не обязательно предполагают компенсации. Да и "позвать человека, чтобы исправил" - это, формально, тоже компенсация.
2) Tempora лучше использовать проведения линейной транзакции, без откатов. Вообще нужно строить систему так, чтобы не было понятие "вызов компенсации" и "откат транзакции", только "повтор". Как ни странно, почти во всех случаях это возможно.
3) Как только у вас появляется распределенная система и требуется хоть какая-то целостность - нужно реализовывать механизмы реконсиляции. Для МСА по DDD - это особенно необходимо из-за огромного объема дублирования информации.
И да, в IT есть две настоящие проблемы. DDD помогает с одной за счет другой )
"Как система должна работать" - это и есть проектирование. И это может делать только человек, погруженный в реализацию системы (разработчик, архитектор, техлид и т.п.).
Это не имеет никакого отношения к анализу.
Связующее звено между бизнесом и разработкой (на IT-службой, это вообще из другой оперы) называются продакт-менеджерами.
Опять проблемы с терминологией. То, что в статье называют бизнес-аналитиком - как раз функции системного аналитика в большинстве компаний. То, что назвали "системным аналитиком" - функции техлида или разработчика внедрения. Про функции бизнес-аналитика в статье вообще ни слова не сказано.
Хочу напомнить, что аналитик - не занимается проектированием и разработкой, это задачи для другой роли.
В статье смешали задачи решения проблем заказчика, сбора требований, проектирования и реализации. Это разные активности, которые могут очень разными способами распределяться по команде, но "как" - это всегда задачи разработчика, а не аналитика.
Ой, да, ошибся, спасибо!
Нет, с 01.03.2022 временный порядок вывоза наличности, не больше 10k$ на человека.
Управление фокусом глазом, кстати, у Никона тоже было. Но выкинули, как неудобное.
Кто в 90х сделал первым - уже не помню...
А в чем разница рынка и ниши? Как формально отличить рынок профессиональных фотоаппаратов от рынка фотоаппаратов от рынка камер и фотоаппаратов от рынка устройств с камерой и даже от рынка техологичных игрушек?
Это все рынки, пересекающиеся, вложенные друг в друга - но рынки.
Ниша - это про часть рынка с низкой конкуренцией. Про указанные рынки нельзя сказать, что там низкая конкуренция.
Впрочем, разница между рынком, сегментом и нишей - весьма сомнительная и зависит от целей рассмотрения.
Хм, глубоко не нырял. Но в некоторых камерах шумодав работает даже на RAW, увы, особенно на высоких ISO. Хотя формально - да, просто значения, снятые с матрицы.
Производительность встроенного в камеру процессора - один из признаков, отличающих старшие камеры в линейке - и там довольно много работы. Хотя, конечно, в основном это про генерацию jpeg, но не только.
Постобработки там дофига, она сильно влияет на результат.
И она сильно разная на разных тушках, с фирменными особенностями и так далее.
Хм, смотря каких рынков.
Есть рынок компактных среднеформатников, там Fuji и Хассель.
Есть рынок пафосных дальномерок, там Leica и Fuji
Есть рынок компактных камер, там Олимпус и Панасоник
Есть рынок профессиональных полнокадровых камер и там Никон с Кэноном и Сони.
Ну и так далее.
Нет единого рынка фототехники, есть много разных рынков, с разными лидерами, разными стратегиями и так далее. И Никон с Кэноном далеко не на всех конкурируют и даже не на всех представлены.
Увы, но есть люди, которые не воспринимают критику, донесенную без использования эмоционально окрашенных слов. Часто они же не очень компетентны. И в этом случае иногда описать то, что они сделали в точных и эмоционально окрашенных терминах ("этот код - полное дерьмо") является единственным способом смотивировать на его переделку. Разумеется, добавив конструктивных причин подобной формулировки и рекомендаций по устранению.
Уволить их можно, но это же надо ждать где-то год, а работу делать надо.
Так нанимают все больше в компанию, а не в команду. И уж кого наняли - того наняли (и да, это, конечно, проблема компании, но такой подход, увы, массовый).
Хм, проблемы представительности как раз не представляют особой проблемы. Достаточно просто собирать данные не в режиме "пришлите кто-нибудь", а через обращения в компании согласно статистическим данным (хотя бы по размеру и по отраслям), впрочем есть и куча других подходов. Верификацию-то уж точно стоило бы сделать. Как и глубинные интервью хотя бы с некоторыми компаниями (лучше с каким-то представительным количеством). Но ничего из этого не делалось, так как, кажется, цели сделать что-то обоснованное - не ставилось.
Проверку каузации вполне можно сделать - например посмотреть, как меняется доходность в компаниях с резким изменением метрик (причем тоже с разным размерами и из разных отраслей). Скорее всего финансовые показатели при этом не изменятся.
(Кстати, так как больше всего делилось данными люди из крупных компаний, где реально скорость доставки имеет смысл и легче обеспечиваются - то корреляция выглядит очевидной. Но понятно, что доставку 10 релизов в день в компании в 10 человек нет смысла делать. Впрочем, кажется, там и успех компаний считали абсолютные, а не в привязке на сотрудника, что уже совсем бессмысленно).
И да, конечно индексы счастья или коррупции - бесполезны и не дают никакой полезной информации и не обладают никакой прогностической силы.
Опираться на свой опыт - да, есть смысл!
Про DORA. Там проблемы в сборе самих метрик (их присылали произвольные люди по собственной инициативе, без какой-то верификации данных, без определения представительности присланных данных, даже без соотношения данных с конкретными департаментами компаний), проблемы в отслеживании корреляций (не было анализа кластеризации по секторам, не оценивалась вообще важность для бизнеса метрик, некоторые метрики вообще не могут быть оценены для многих компаний). Ну и "корреляция не значит каузация".
Так что говорить о какой-то большей обоснованности метрик DORA, нежели, например, натальной карты сервера - не приходится.
По поводу очевидности - тут как раз используемые решения были очевидно первыми, в том числе и для улучшения метрик. Но при этом же метрики никак с изменением подхода к бранчам не связаны, для улучшения метрик могли и еще десяток тестовых кластеров поставить, например.
Но вы правильно пишите, что метрики нужны для убеждения - да, в этом они помогают.
Хм, но DORA метрики, на самом деле, ни с чем не коррелируют (там исследование не может ничего доказать, так как сделано некорректно).
Реально я вижу переход к относительно современной модели бранчевания, но этот подход очевиден уже при первом взгляде на старую модель. Зачем тут DORA?
P.S. Но да, DORA может использоваться для убеждение не слишком компетентного менеджмента для проведения достаточно очевидных изменений в пайплайне. Другой ценности в метриках нет.
Хм, TOGAF и прочее - это скорее про Enterprise Arch, а не про SolArch или SysArch. Да, эта роль возникает только в очень крупных компаниях. Но наличие корпоративного архитектора не значит, что на уровне отдельного продукта внутри департамента не используется DDD. Большие компании - большие, там много что внутри происходит )
Хм, вроде бы стратегические паттерны DDD - это как раз работа архитектора (как роли и, иногда, как позиции). Да и выявление UL/BC полезно в проекте любого размера.
Ну да, архитектор - это про правила взаимодействия разных команд в первую очередь. И никакой agile не убрал необходимости в архитекторе (как и не было необходимости в позиции архитектора в микропроектах на одну небольшую команду).
Но в статье вообще путают активности, роли и позиции. Активности архитектора есть в любом проекте, роль - почти всегда, а позиция нужна уже только при нескольких командах.
Хм, он по производительности совсем в другой лиге, там и 50k сообщений в секунду - уже проблема, да и с надежностью и кластеризацией не очень хочется. Его можно разве что с Mosquito сравнивать, но будет примерно то же - сплошные "нет" и "умеренно".
На большинстве конференций предлагают свои шаблоны для презентаций, где большая часть этих пожеланий учтена (впрочем, я еще не видел ни одного действительно хорошего шаблона презентации от конференции, всюду какие-то огрехи, так как их придумывают дизайнеры). Если же конференция не присылает своего шаблона, то стоит использовать стандартный шаблон компании, а уж дизайнер обычно базовые вещи сможет сделать. Если нет стандартного шаблона в компании - то его полезно разработать, но не только дизайнеру.
Но, вообще, мне сложно представить презентацию, которой подошел бы дизайн из статьи. Очень много мелкого текста (не видно с дальних рядом), нет истории (много пунктов на одном слайде), нет номеров страниц, заголовок мало отделен от текста (впрочем, нужны ли заголовки на слайдах - вообще дискуссионный вопрос, мне как спикеру проще с ними, но слушателям они скорее мешают), текстовые блоки размещены в разных частях страниц.