Системный анализ

Достаточно часто продукт разрастается вместе с командой и наступает время разделиться.

Или нужно распилить большой монолит.

Или никак не удается договориться командами, кто за что отвечает.

Этот процесс часто характеризуют две противоположные картины:

1. Каждый хочет забрать себе все важные куски функциональности.

2. Никто не хочет забирать себе важную часть.

В рамках доклада я хочу поговорить о том, как превратить предметную область в нечто описанное структурировано. Как поделить функциональность между командами. И самое главное, почему аналитик - тот человек, который может это затащить. Или зафейлить.

Многие знают, что существует стек 1С, и представляют его себе как платформу для "тётечек из бухгалтерии", но это далеко не так.

Посмотрим, какие решения сейчас реализуются на стеке, разберем роль системного аналитика в разработке на 1С, а также чем он отличается (и отличается ли?) от системного аналитика в других стеках. Посмотрим различия в работе в зависимости от модели работы организации: интегратор, заказная или внутренняя разработка.

Узнаем и обсудим:

- Какие инструменты есть у системного аналитика 1С?

- Особенности проектирования решения, на сколько легче или сложнее проектировать, когда платформа диктует свои правила?

- Правда ли, что им не обязательно знать английский язык, и так ли страшно смотреть на код на русском языке?

- Можно ли найти с ним общий язык и взять в НЕ 1С команду?

- Сложно ли будет стороннему системному аналитику, который попал в 1С среду?

А также разберемся с мнением, что системных аналитиков 1С не существует.

Когда самые близкие по процессу люди не находят общего языка, проект обречен. И порой лучшие практики, инструменты и идеи оказываются бессильны.

Разберём разные алгоритмы поведения в таких ситуациях.

Проблема: Создание диаграмм является трудоемким процессом, отнимающим значительное время на рутинные задачи.

Целевая аудитория: Системные и бизнес-аналитики, использующие UML в своей работе.

В докладе будет рассмотрена возможность использования больших языковых моделей, таких как ChatGPT, для автоматизации создания UML-диаграмм, в частности, диаграмм последовательностей. Мы проанализируем существующие подходы, оценим применимость LLM на простых примерах и реальных задачах, а также обсудим преимущества и недостатки данного подхода

Краткий план доклада:

1. Анализ текущих сложностей и временных затрат на создание UML-диаграмм.

2. Формулирование гипотезы о возможности использования LLM для автоматизации этого процесса.

3. Обзор существующих методов и инструментов для создания UML-диаграмм.

4. Оценка применимости LLM к созданию UML на простых примерах

5. Оценка результатов работы ключевых представителей LLM на реальных задачах

6. Обсуждение плюсов и минусов использования LLM для автоматизации создания UML-диаграмм.

7. Оценка прикладной ценности данного подхода.

8. Обобщение результатов исследования.

9. Рекомендации по использованию LLM для автоматизации задач системных и бизнес-аналитиков..

Мастер-класс для системных аналитиков: "Как подготавливаться к оценке проектов командой и как корректно давать оценку".

Какие документы/артефакты/схемы нужны для такой оценки, с какими компетенциями нужно поговорить до начала оценки.

И разберем методы первичной оценки проектов.

В мастер классе сначала минут 10-15 будет теоретическая вводная. Потом следующие 30-40 минут будем разбирать кейсы из моей реальной практики.

В итоге у системных аналитиков будет алгоритм действий для оценки проекта при высокой неопределённости.

Расскажем про проектирование API с использованием подхода API first на провальных и не очень кейсах. Приведем примеры универсальных контрактов и расскажем про наш подход к анализу для учета всех перекрестных требований за минимальное количество встреч.

В рамках МК на примере пройдем цикл рефакторинга и ревью требований, чтобы найти баланс между идеальным артефактом и артефактом, который выдержит любые изменения требований, сроков и даже смену команды. Вместе на практике освоим инструменты и методы эффективного ревью, чтобы каждый в команде понимал, что нужно делать, а новичок смог разобраться в контексте.

Мы все очень хотим нанести непоправимую пользу нашим командам, сделать наши требования лучше.

Рецензирование требований - поможет сделать качество требований лучше, но всегда ли это нужно?

В рамках доклада я рассмотрю практики рецензирования требований и отвечу на следующие вопросы:

1. Когда рецензирование требований надо?

2. Когда оно вам точно не надо?

3. На что обращать внимание при рецензировании - на форму или на содержание?

4. Как организовать процесс рецензирования в зависимости от размера команды и процесса разработки.

Доклад будет полезен:

1. Тем, которые еще не сталкивались с процессом рецензирования требований;

2. Тем, кто пострадал от рецензирования требований и теперь не хочет про это слышать;

3. Тем, кто попробовал внедрить эту практику и она не взлетела.