Евгений Галактионов. Размышления о системных аналитиках

• Ведущий приветствует зрителей и представляет Евгения Галактионова, основателя канала "Системный подход".  

• Евгений делится своим опытом и знаниями в области системного анализа.  

• Он планирует обсудить роль системных аналитиков и их правильное использование.  

• Евгений рассказывает о своем опыте в системном анализе и обучении аналитиков.  

• Он подчеркивает важность понимания системного анализа и его применения.  

• Евгений делится своими мыслями о том, как правильно использовать аналитиков в проектах.  

• Евгений объясняет, что его цель - понять роль аналитика и его место в проектах.  

• Он обсуждает, как аналитики могут быть интегрированы в различные проекты и технологии.  

• Евгений предупреждает, что вебинар может негативно повлиять на мировоззрение и психическое здоровье участников.  

• Евгений предупреждает о возможных негативных аспектах вебинара и просит зрителей подумать, стоит ли участвовать.  

• Он объясняет, что в процессе вебинара могут демонстрироваться кадры насилия и непотребств.  

• Евгений начинает с определения общего понятия для обсуждения на общем языке.  

• Основные понятия: анализ, разработка требований, бизнес-анализ, системный анализ.  

• Понятие системного аналитика не существует.  

• Доклад не для любителей системной аналитики.  

• Начало с легендарных времен, когда появились драконы.  

• Драконы - первое поколение электронно-вычислительных машин ЭВМ.  

• Управлять драконами должны были маги-программисты.  

• Программисты определяли задачи, выявляли требования, проектировали решения.  

• ЭМ стали быстрее и умнее, что привело к разработке операционных систем и систем управления базами данных СУБД.  

• Первые пользователи ЭМ - военные и банки.  

• Ученые использовали ЭМ для расчетов траектории полета и создания атомной бомбы.  

• Возник кризис общения между программистами и заказчиками.  

• Появилась необходимость в специалисте, который бы общался с заказчиками.  

• Аналитик стал переводчиком между заказчиками и разработчиками.  

• Отрасль разработки программного обеспечения начала развиваться.  

• Увеличение мощности ЭМ и появление персональных компьютеров.  

• Разделение команд разработки на роли: руководители проектов, архитекторы ПО, тестировщики.  

• Сложность информационных систем возросла.  

• Аналитик передавал противоречивые требования от заказчиков.  

• Разработчики перестали вникать в совместимость требований.  

• Возникла необходимость в функциональном архитекторе систем.  

• Аналитик стал функциональным архитектором систем.  

• Основная функция аналитика - управление целостностью системы.  

• Аналитик выполняет две функции: переводчик и функциональный архитектор.  

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

• Инженер создает концепции, а чертежи - побочный продукт его работы.  

• Аналитик выполняет инженерные функции, создавая решения, а не только документацию.  

• Ошибки, обнаруженные на поздних этапах разработки, приводят к высокой стоимости исправления.  

• На ранних этапах ошибки можно исправить минимальными затратами.  

• Ошибки на этапе эксплуатации требуют полного пересмотра проекта и значительных затрат.  

• Исследования показывают, что 30-40% ошибок приводят к провалу проектов.  

• Аналитик помогает снизить риски и сократить путь поиска ошибок.  

• Аналитик создает модель требований, которая служит основой для принятия решений и выявления ошибок.  

• Аналитик определяет архитектуру и интерфейс системы.  

• Программист реализует решения, основанные на модели требований.  

• Аналитик минимизирует риски принятия неправильных решений и помогает выявить ошибки в требованиях.  

• Аналитик - это функциональный архитектор систем.  

• Модель требований - главный результат работы аналитика.  

• Вопрос о названии роли аналитика остается спорным.  

• Спецификатор - название, предложенное на Западе, но не прижившееся.  

• Постановщик задач - термин, который не четко определяет задачи аналитика.  

• Инженер по требованиям - наиболее точное определение, но не прижилось.  

• Бизнес-аналитик и системный аналитик - основные названия роли.  

• Системный анализ - проектирование и исследование систем, включая организационные.  

• Бизнес-анализ - исследование структурных срезов организационных систем.  

• Системный анализ включает создание информационных систем на основе исследований организационных систем.  

• Системный аналитик занимается определением требований к информационным системам.  

• Бизнес-аналитик изучает бизнес-проблемы и предлагает решения, но не всегда связан с созданием информационных систем.  

• Системный аналитик должен владеть инструментами бизнес-анализа для создания качественных моделей требований.  

• Вопрос о том, как аналитик должен быть встроен в команду разработки, зависит от вида разработки.  

• Заказная разработка характеризуется ограниченной организацией и стабильными процессами.  

• Разделение функций бизнес-анализа и системного анализа между разными специалистами может привести к проблемам.  

• Проблема "глухого телефона" возникает из-за ошибок при передаче информации между этапами анализа.  

• Решение проблемы требует высокого уровня квалификации обоих специалистов, что может быть дорого.  

• Продуктовая разработка предназначена для многих организаций или конечных пользователей.  

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

• Пример: бухгалтерия, которая должна работать одинаково в любой организации, но на практике может сильно различаться.  

• Процессы в бухгалтерии должны быть одинаковыми, но организации могут отличаться.  

• Продукт должен удовлетворять разные организации и процессы.  

• Исторически сложившиеся привычки описания объектов приводят к вариативности характеристик.  

• Продуктовая разработка требует системного аналитика, что приводит к перегрузке.  

• Системный аналитик не может качественно переварить информацию и систематизировать её.  

• Существуют два подхода: разделение функций бизнес-анализа и системного анализа или привлечение большего числа аналитиков.  

• Разделение функций бизнес-анализа и системного анализа помогает избежать перегрузки.  

• Владелец продукта отвечает за продукт и представляет заказчика перед системным аналитиком.  

• В продуктовой разработке закон больших чисел нивелирует ошибки передачи информации.  

• Программный продукт требует настройки и доработки после внедрения.  

• В заказной разработке разделение функций нецелесообразно, в продуктовой разработке это может быть полезно.  

• В продуктовых компаниях есть ответственный за продукт, что помогает в разработке.  

• Agile не предусматривает роль системного аналитика, что меняет процесс разработки.  

• Функции анализа распределяются между разными ролями, включая продуктовиков.  

• В реальности разработчики привыкли проектировать решения, а не требования, что может привести к проблемам.  

• Agile работает, когда система проста и не требует сложного функционала.  

• В сложных системах Agile может привести к каскадным ошибкам и дорогостоящим исправлениям.  

• В системах управления сложными объектами Agile может не работать из-за высокой стоимости исправления ошибок.  

• Agile позволяет быстрее разрабатывать системы, но не всегда подходит для сложных систем.  

• Идея: вернуть аналитика в команду для создания модели требований.  

• Аналитик должен работать в одном спринте с разработчиками, что может вызвать конфликты.  

• Аналитик должен работать за один-два спринта до текущего, чтобы обеспечить полноту модели.  

• Конфликты возникают, если аналитик работает в текущем спринте.  

• Важно понимать, что Agile — это организация процесса разработки, а не анализ.  

• Аналитики должны адаптировать методологии под свои задачи.  

• Важно не копировать подходы слепо, а адаптировать их под конкретные цели.  

• Аналитики должны применять свои профессиональные навыки для адаптации методологий.  

• В некоторых компаниях системные аналитики занимаются постановками задач, а не созданием моделей требований.  

• Это приводит к ошибкам и проблемам в реализации.  

• Системные аналитики должны создавать модели требований, а не просто ставить задачи.  

• Системный аналитик — это инженер по требованиям, создающий модель требований.  

• Постановки задач должны основываться на модели требований.  

• Важно правильно называть роли и понимать ценность системного аналитика для процесса разработки.  

• Вебинар не претендует на полезность, а скорее на развлечение.  

• Призыв подписаться на YouTube и Telegram-каналы.  

• Готовность ответить на вопросы.  

• Основная задача системного аналитика - создание модели требований к системе.  

• Роль системного аналитика определяется стандартом, а должность - работодателем.  

• Системный аналитик может выполнять различные задачи, включая тестирование и написание документации.  

• Понимание предметной области и процессный подход.  

• Умение общаться с людьми и системное мышление.  

• Проектирование информационных систем и понимание этапности разработки.  

• Бизнес-аналитик исследует организации и предлагает решения.  

• Системный аналитик проектирует модели систем.  

• В заказной разработке разделение ролей может быть не лучшим решением.  

• Евгений - действующий системный аналитик и преподаватель.  

• Организатор мероприятий для системных аналитиков.  

• Не занимается рекламой организаций.  

• Джуниор должен понимать разницу между уровнями требований.  

• Уметь выявлять и анализировать требования.  

• Обладать системным мышлением.  

• Джуниор знает теоретически, но не может делать практически.  

• Мидл знает теоретически и может делать практически.  

• Нет универсальной методологии для всех.  

• Евгений не комментирует системный подход через призму стратегического продакт-менеджмента.  

• Возможность проведения вебинара на эту тему.  

• Вопросы о разнице между бизнес-аналитиком и системным аналитиком и основных скилах системного аналитика.  

• Системный аналитик должен обладать системным мышлением.  

• Рекомендация книги "Прикладной системный анализ" Феликса Тарасенко.  

• Вопрос о необходимости знания языков программирования остается субъективным.  

• Системный аналитик должен понимать, как проектировать модель и предметную область.  

• Важно задавать требования к данным через артефакты, такие как модель требований.  

• Навыки программирования могут быть полезны, но не обязательны.  

• Навыки программирования редко используются в реальной работе системного аналитика.  

• Вопросы на собеседованиях часто не соответствуют реальной практике.  

• Разделение ролей в команде помогает лучше выполнять задачи.  

• Кроссфункциональность может быть как преимуществом, так и проблемой.  

• Важно разделять роли и обязанности, чтобы лучше выполнять задачи.  

• Системный аналитик должен создавать модели требований и использовать их в других ролях.  

• Модель требований — это совокупность непротиворечивых требований к системе.  

• Требования могут быть выражены в документах или артефактах моделей.  

• Важно понимать, что является требованием и что нет.  

• В новом профстандарте фокус сместился с разработки требований на проектирование дизайн-решений.  

• Это может привести к проблемам с качеством систем и необходимостью их переписывать.  

• Важно понимать, на основании чего делаются постановки и решения.  

• Потребности могут быть у бизнеса или заинтересованных лиц.  

• Требования относятся к информационной системе и должны воплощаться в функциях.  

• Системно-инженерный подход помогает различать потребности и требования.  

• Важно описывать требования на языке требований, будь то текстовое описание или диаграмма.  

• Невозможно однозначно определить, является ли бипман-диаграмма моделью или спецификацией на языке требований.  

• Формулировки требований требуют контекста и практики.  

• Курс по требованиям занимает 4-6 часов.  

• Требования не являются интерфейсами, а служат для сбора и валидации.  

• Описание системы на языке требований фиксирует, что система должна делать.  

• Важно избегать интерпретаций, чтобы избежать неправильных выводов.  

• Вопрос требует более глубокого обсуждения.  

• Требования могут быть выражены графически или текстово.  

• Существуют требования к функциям, данным, качеству и ограничениям.  

• Вопрос о формах и представлениях требует уточнения.  

• Требования являются моделью системы, валидированной на потребности пользователя.  

• Решения могут изменяться часто, в отличие от требований.  

• Архитектор принимает решения на основе требований.  

• Аналитик описывает то, что есть, а не придумывает из головы.  

• Важно понимать проблемы заказчика и его цели.  

• Аналитик проверяет валидность требований для заказчика и других заинтересованных лиц.  

• Искусственный интеллект работает с уже существующими данными.  

• Системы не могут разработать новые требования.  

• Вопрос о будущем роли системного аналитика остается открытым.