Системный сдвиг

Опубликовали статью по мотивам выступления на Flow'2023:

Опубликовали статью Юрия Куприянова на тему «Скрытая работа аналитика по проектированию систем» В этой статье рассказано о том: — как системные аналитики незаметно для себя могут принять проектное решение при анализе требований — где проходит грань между требованиями и проектными решениями — что такое скрытая работа аналитика по проектированию — какие компетенции развивать системному аналитику, чтобы проектные решения были качественными. Статья будет полезна системным аналитикам уровня junior и middle Содержание: 1. Что такое системный анализ — Парадокс системного анализа — Требования вместо системы — Граница требований и проектных решений 2. Проблемы требований к ПО — Существуют ли требования? — Иллюзия требований к ПО — Рекомендации по работе с требованиями 3. Компетенции аналитика в проектировании — Проектирование взаимодействие пользователя с системой — Проектирование хранения данных — Проектирование интеграций, взаимодействия с внешними системами — Архитектура системы 4. Что делать системному аналитику? Переквалифицироваться в проектировщики или в архитекторы? Почитать можно тут

Я редко делаю репосты, но тут просто огненная тема! Ну и Киру в принципе рекомендую, если интересуетесь процессами найма и HR. Для аналитиков, о чем можно рассказать, помимо примеров в посте, и что меня бы, например, интересовало при собеседовании аналитиков (кстати, меня, если что, можно звать на собеседования, чтобы оценить кандидата): ⭐️ пример автоматизации бизнес-процесса или отдельной функции (сквозное описание: от выявления требований до технических решений и тестирования, если было); ⭐️ пример участия в проектировании технической архитектуры (или выбора способа реализации, выбора готового решения с учетом технических требований); ⭐️ пример задачи описания требований для проектирования интеграции систем или API; ⭐️ пример решения какой-то сложности в проекте — когда было непонятно, что делать, или заказчик не мог сформулировать требования, или когда требования были противоречивые; в общем — когда вы пришли и поправили всё, спасли бизнес и/или команду разработки; ⭐️ пример применения какой-то техники бизнес- или системного анализа (например, того же DDD или Impact Mapping) — с обязательным указанием, в чем была польза, в чем положительный эффект; ⭐️ пример организации управления требованиями: как фиксировали, как согласовывали, как управляли версиями, как передавали в работу, как принимали выполненную работу. В идеале, всё это нужно раскладывать по методу STAR: Ситуация — Задача — Действие — Результат, прямо так и рассказывать. Я рекомендую при подготовке к интервью составить себе несколько таких примеров, расписанных по STAR, заучить и при случае вставлять. Рекрутеры сами по этому STAR работают, им зайдет. (то есть, если вы нанимаете людей, вы из спрашивать можете в той же логике!) Как вариант, можно использовать метод PARLA: Проблема — Действие — Результат — Опыт — Применение. Последние два — это Learned и Applied: что вы вынесли из этой ситуации, чему научились, и как теперь это применяете. В принципе, даже без задачи подготовки к собеседованию это хорошие вопросы для ретроспективы любого проекта или его этапа.

Главное слово кандидата на собеседовании: «НАПРИМЕР» 📌 Никто не телепат. К сожалению, если вы не будете приводить примеры из своего опыта, нанимающий менеджер не сможет оценить, насколько вы действительно реализовывали те задачи, про которые говорите. Сравните: ❌ Я закрывала сложные вакансии быстро и качественно. ✅ Я закрывала сложные вакансии быстро и качественно. Например, однажды нам в компании срочно потребовался ещё один разработчик баз данных, а подходящих кандидатов на рынке не было, сроки поджимали. В итоге я лично опросила всех имеющихся в команде разработчиков баз данных и попросила рекомендаций на их бывших коллег, получила контакты 10 кандидатов, с каждым связалась и нашла троих, кто был готов не только рассмотреть нашу вакансию, но и выйти в короткие сроки. Всех трёх мы отсобеседовали за 2 дня, выбрали одного, который вышел сразу после согласования оффера. Весь процесс занял у меня неделю. 📌 Примеры нужны для иллюстрации каждой компетенции или ключевого тезиса, которую вы презентуете работодателю. Пример: ❌ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи. ✅ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи. Например, я вижу в вашей вакансии, вы решили внедрить Confluence в качестве единой базы знаний. У меня есть похожий опыт в предыдущей компании, где я, в качестве бизнес-аналитика, помогала внедрять эту систему в команду из 3000 человек. Я хорошо знаю плюсы и минусы этой системы, например, у Confluence есть проблемы с производительностью и я знаю, как их решать. 📌 Любое утверждение становится весомее и понятнее, если вы подкрепляете его примером. Например: ❌ Что я больше всего не люблю в работе? Когда внутренний заказчик возвращается с правками 🙁 ✅ Что я больше всего не люблю в работе? Расскажу пример: мы работали как внешний подрядчик и я, как проджект, очень много внимания уделил брифингу клиента, выявлению потребности и формированию полного ТЗ, которое полностью устроит клиента. Каждые 2 недели мы сверялись с клиентом по процессу, чтобы сразу же выявлять проблемные места. Всё шло гладко, мы резво двигались по плану, клиент вносил минорные правки и мы уже подошли к финалу проекта. И тут, когда до дедлайна оставался месяц, на стороне клиента поменялся руководитель, который остановил весь процесс, а потом кардинально поменял ТЗ и потребовал, чтобы мы уложились в изначальные сроки. Я очень не люблю такие ситуации. Хорошо, что я внимательно документировал каждый шаг и мы были документально защищены от такой ситуации. В итоге, я смог наладить контакт с новым руководителем, обсудить с ним его пожелания и наши возможности. Мы сформировали новый план действий и смогли реализовать то, что клиенту было необходимо. 👉 Быстрый совет: напишите на бумажке слово «НАПРИМЕР», приклейте возле экрана на время собеседования, чтобы почаще использовать это слово и подкреплять свои слова наглядными примерами 🙏

Новости для бизнеса и всех заинтересованных в ML: конференция ML2Business от Yandex Cloud отгремела! Рассказываем кратко о самом главном: 🔍 Компании смогут генерировать ответы на вопросы пользователей по их сайту с помощью нейросетей. Новая функция появилась в сервисе поисковых запросов Yandex Search API; 🔍 YandexGPT теперь лучше справляется с задачей классификации текстов. Можно использовать отдельную версию генеративной модели по API и при ее дообучении фильтровать неприемлемый контент и перенаправлять заявки в поддержке без длительных и сложных настроек модели; 🔍 В сервисе речевой аналитики Yandex SpeechSense теперь можно анализировать текстовые сообщения, а с данными из сервиса можно работать в своем интерфейсе; 🔍 Сервис для ML-разработки Yandex DataSphere автоматизирует обучение нейросетей, экономя время на повторных запусках заданий; 🔍 Все желающие смогут пройти новые бизнес-курсы по ML-технологиям. ➡️ Более развернутый отчет по конференции можно узнать тут.

Я изучаю довольно много информации, в основном статей: научных и постов на сайтах. Далеко не каждая статья становится поводом к посту, и даже наоборот — когда я пишу пост, сначала возникает идея, а потом я ищу материалы. Ну и просто вкидывать в канал ссылки мне не кажется правильным, тут в основном мои персональные мысли. Но если вам вдруг интересно, что мне интересно и что я читаю каждый день — я создал отдельный канал https://t.me/yksdailylinks. Там как раз наоборот — будут только ссылки с небольшими комментариями. Возможно, что-то их этих ссылок когда-нибудь превратится в отдельный пост. А какие-то ссылки будут дополнениями к посту в основном канале. В общем, если вам вдруг любопытны ссылки от меня — welcome!

А вот что меня натолкнуло на написание предыдущего поста. Это из таблицы с бизнес-требованиями, столбец с обоснованием требования. Фактически, ответ на вопрос "Зачем мне, как <роли> это нужно?". Это работа аналитика-стажера, но я видел такое и у штатных аналитиков. Это мощный сигнал! Если вы видите такое — это повод разобраться, что тут происходит. Простое повторение не несет новой информации. Если несколько требований нужны для одного и того же — может быть, это одно требование и оно зря разбито на несколько? А может быть, обоснование взято слишком высокоуровневое, пропущен уровень один рассмотрения. В любом случае, так быть не должно, это недоработка.

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном. Задача аналитика — снизить неопределенность при проектировании системы, чтобы выйти на ограниченный набор возможных решений. Важное слово здесь — "ограниченный", потому что чем больше неопределенность (непонятно, что нужно), тем больше вариантов решений. Фактически, речь идёт об энтропии — числе способов, которыми можно расположить и связать компоненты системы. А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное. Интересное нам нужно, чтобы можно было выбирать обосновано. Если все варианты решений одинаковы — энтропия максимальна, это хаос, ну или нормальное распределение — верно нечто среднее. Такую картину мы получим, если требования собраны случайным образом, бессистемно: будет средняя система, непойми что, информации мало. Если вариантов нет и всё очевидно — энтропия будет минимальной или нулевой, но и информации никакой нет — нечего решать. Мы обычно находимся в интересной промежуточной ситуации, когда расхождение между очевидным и хаотичным велико. А значит, нужно много информации для снятия неопределенности. Поэтому требования должны быть неожиданными! Если вы читаете требования, и всё выглядит усредненно-понятным, значит, требования не передают много информации. То ли система очень простая (нет), то ли работа аналитика выполненная так себе. Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид. А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка). Скольким требованиям в документе вы может поставить такие значки? Конечно, удалять все дубли опасно, тут сразу можно вспомнить про избыточность информации — ведь информацию специальную дублируют при передаче, да и естественный язык у нас крайне избыточен. Но это делают в случае зашумленных ненадежных каналов — когда мы знаем, что часть информации будет потеряна или воспринята неверно. Тут, конечно, нужно смотреть по фактическому положению дел — насколько часто у вас такие проблемы в принципе возникают, и какую степень избыточности вам требуется предусмотреть в требованиях, чтобы информация из них всё-таки дошла.

ХОЧЕШЬ ПОВЫШЕНИЕ В 2024 ГОДУ? 😎🔥 Тогда самое время разобраться в микросервисной архитектуре и стать более востребованным специалистом. 🚀 Стартуем 4 июня. Курс ведет действующий архитектор Кирилл Ветчинкин. Он успешно реализовал проекты для Мегафона, Теле2, ВСS Brокer. Постоянный спикер крупных IT-конференций. Какие скиллы прокачаем: 📌 Декомпозиция систем на микросервисы, отталкиваясь от бизнес-домена. 📌 Встройка микросервисов в оргструктуру компании. 📌Организация перехода от монолитной системы к микросервисной. Полная программа ТУТ 👉https://microarch.ru/?utm_source=posev&utm_medium=erid:2Vtzqvdojhd&utm_campaign=5 А самое главное — поддержка от спикера, чат с одногруппниками и полезные созвоны с разбором домашки. 📕 Сертификат об участии по итогам прохождения курса. Узнай больше о курсе 👉 https://microarch.ru/?utm_source=posev&utm_medium=erid:2Vtzqvdojhd&utm_campaign=5 Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2Vtzqvdojhd

Как правильно отмечают в комментариях к посту про  Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram. Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже. Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро. Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность: 1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов; 2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости; 3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов. Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь. Не знаю, как вас, а меня так ещё учили в институте, хотя в любой практической задаче было очевидно, что такой подход плохо работает. Якобсон одним из первых показал, что идти нужно от задач пользователя, а классы нужно делать такие, какие удобно, а не только как отражение сущностей реального мира. Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах. Вот, например, идея с разбиением архитектуры на элементы с разной скоростью изменения. Что-то может меняться, что-то остаётся. Это и обеспечивает устойчивость, робастность. Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросов, помех). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований! Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.