​​Кто есть кто!?
Или определения профессий системный и бизнес-аналитик согласно справочнику профессий Минтруда.
#системный #бизнес #аналитик

Системный аналитик - Разрабатывает и сопровождает требования к отдельным функциям системы. Создает и сопровождает требования и технические задания на разработку и модернизацию систем и подсистем малого и среднего масштаба и сложности. Концептуально, функционально и логически проектирует системы среднего и крупного масштаба и сложности. Управляет аналитическими работами и подразделением. Подробнее

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

​​Продукт VS проект: отличия подходов
#продукт #проект

Продукт - результат
° состоит из проектов
° не ограничен во времени
° долговременная feature команда
° постоянные улучшения
° аналитика и поиск новых источников информации
° ориентирован на разных клиентов, сегмент рынка

Проект - процесс
° составляющая продукта
° ограничен во времени
° кратковременная команда на проект
° конечный набор задач для достижения определённой цели
° ограничения по ресурсам (стоимость)
° заданное количество источников информации
° конкретный заказчик


Исполнительный директор Factory5 делится в статье опытом работы проектных и продуктовых команд - описывая процессы работы, их структуру и цели.

Читать статью

​​​​"Проектирование веб-API" Арно Лоре
#литература #api

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

Посмотреть содержание книги и скачать электронную версию можно тут

​​Методы сбора требований
#сбортребований

Коллективные - участвуют заинтересованные лица (Стейкхолдеры):
° анкетирование
° интервью
° семинары, совещания
° мозговой штурм
° наблюдение (пассивное/интерактивное)
° представитель заказчика в компании разработчика

Независимые - самостоятельная работа:
° изучение существующей документации
° повторное использование спецификации
° анализ системных интерфейсов
° анализ пользовательского интерфейса

Наиболее эффективным при сборе требований будет комбинирование нескольких методов, как тех, что перечислены выше, так и тех, которые в список не попали (если знаете такие, поделитесь, пожалуйста, в комментариях)

​​Анкетирование как один из методов сбора требований
#сбортребований #анкетирование

Анкетирование заключается в составлении листа-опросника, который может состоять из двух видов вопросов:
• Открытые –  свободная форма
ответа;
• Закрытые – выбор варианта ответа из предложенных.

Плюсы анкетирования:
° высокая скорость получения результата;
° возможность опросить большое количество пользователей, в том числе и географически удаленных;
° небольшие материальные затраты

Минусы:
° невозможно учесть все вопросы
° невозможно понять все «проблемы» заказчика
° неправильно сформулированные вопросы ведут за собой неоднозначные ответы.

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

Рекомендации по составлению листа-опросника - Открыть

Примером листа-опросника может быть Бриф на создание сайта.

​​​​Мозговой штурм
#сбортребований #мш

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

Принципы и правила применения:
° определить цель
° генерировать как можно больше идей, даже самые нестандартные
° должен выступить каждый участник
° НЕТ - критики, плохих идей, споров

Организационные моменты
Этап генерации идей:
° озвучте участникам основные правила
° установите ограничение по времени
° записывайте все идеи (важнее количество, а не качество)
Этап отбора идей:
° объедините идеи, отбросьте лишние, структурируйте требования по значимости и приоритетности.

Пару статей по данной теме:
° Мозговой штурм и 10 правил его эффективного проведения

° 15 полезных техник мозгового штурма

​​Сбор требований: метод наблюдения.
#сбортребований #наблюдение

Метод наблюдения или работа " в поле" - заключается в наблюдении за тем, как работают пользователи.
Чаще применяется там, где необходимо отследить текущий процесс.

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

Данный метод позволяет:
° мгновенно выявить требования;
° наглядно увидеть проблему;
° сравнить реально выполняемый процесс с имеющимся регламентом;
° изучить процесс более детально, вплоть до отдельных операций;
° определить наиболее трудоемкие операции;
° избежать проблем, связанных с трудностями ЗЛ в описании и выражении своих потребностей.

Недостатки:
° могут быть упущены альтернативные ситуации;
° большие затраты по времени;
° трудно применим на секретных предприятиях или опасных (вредных) производствах;
° пользователь в отсутствие наблюдателя может работать иначе. (Т.о. собранная информация может быть недостоверной)

Пример применения метода Наблюдения на практике

​​Методы сбора требований: изучение существующей документации
#сбортребований #документация

Анализ документов позволяет:
°  быстро освоить текущую систему или новую предметную область;
° сократить время и ресурсы, затрачиваемые заказчиком на передачу знаний и информации;
° выявить возможные требования к ПО, например, при автоматизации устоявшихся в организации регламентированных бизнес-процессов;
° получить информацию,  которой люди не обладают;
° поможет при создании документации процесса as-is

Примеры документации: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты, инструкции, шаблоны документов, отчеты

Важно! перед анализом документации оценить ее релевантность - соответствует ли она действительности.

Недостатки:
° существует риск получить неактуальные,  устаревшие данные;
° в документах может быть описана функциональность, которая в будущей системе не нужна;
° данный метод не применим, если в организации имеются только базовые документы или они вовсе отсутствуют.

​​Методы сбора требований: Анализ системных интерфейсов.
#сбортребований #интерфейс

"Анализ интерфейсов — независимый метод выявления требований, который подразумевает анализ систем, с которыми взаимодействует ваша система. Анализ системных интерфейсов выявляет функциональные требования к сервисам и обмену данными между системами (IIBA, 2009). ..

Для каждой системы, которая взаимодействует с вашей, определите функциональность этой системы, которая может создавать требования к вашей системе. Эти требования могут описывать, какие данные передавать или получать из другой системы и каковы правила работы с этими данными, например критерии соответствия. Может также обнаружиться существующая функциональность, которую  не нужно  реализовывать в вашей системе. Представьте, что вам нужно реализовать правила проверки заказа в корзине интернет-магазина до начала оплаты. Проанализировав системные интерфейсы, вы сможете обнаружить, что в систему управления заказами поступают заказы из других систем, которые сами их проверяют, поэтому такую функциональность реализовывать не нужно."

Источник:  К. Вигерс "Разработка требований к программному обеспечению"

#собеседование #логическая #задача

На столе лежат девять монет. Одна из них — фаль­шивая. Как при помощи двух взвешиваний можно найти фальшивую монету? (Фальшивая монета легче настоящих.)

‐-------‐----------------------
Посмотреть ответ

​​Рекомендации по проведению интервью при сборе требований.
#сбортребований #интервью

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

Этапы и рекомендации по проведению интервью
Подготовка:
° Определите цели интервью
° Выберите для беседы "подходящего" человека
° Заранее подготовте вопросы, вспомогательные материалы
° Поделитесь повесткой с будущим собеседником

Проведение:
° Установите контакт с собеседником
° Больше спрашивайте, а не предлагайте
° Чередуйте открытые (для получения информации) и закрытые (для уточнения, подтверждения) вопросы.
° Проговаривайте альтернативные ситуации
° Используйте активное слушание
° Старайтесь выяснять "что" и "зачем" хочет получить заказчик, а не "как" это должно быть реализовано.
° Обращайте внимание на неявные/предполагаемые требования
° Придерживайтесь границ проекта
° Фиксируйте информацию
° Не затягивайте время

Завершение:
° Проговорите итоги встречи
° Договоритесь о дальнейших действиях
° Подготовте и разошлите протокол встречи всем заинтересованным лицам

Более подробно познакомиться  с тем, как провести интервью с заказчиком, можно в статье

​​Прототипирование как метод сбора требований.
#сбортребований #прототипирование

Прототипирование - метод,  заключающийся в создании макета/ скелета системы (прототипа), который позволяет предметно обсуждать с пользователем требования к системе, демонстрировать принятые решения, внешний вид системы и порядок работы.

Прототип может быть:
° Статическим - показывает положение элементов в интерфейсе или структуру данных.
° Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий.
° Интерактивным - позволяет пользователям и участникам заинтересованных сторон выполнять реальные действия так, как это будет работать в разрабатываемой системе.

Выделяют два основных типа (подхода) прототипирования:
° Быстрое (одноразовое) - прототип  используется на этапе сбора требований, после чего "выбрасывается". Чаще концентрируется на наименее понятных требованиях.
° Эволюционное - прототип сохраняется после выявления требований и используется для создания конечного программного продукта. Концентрируется на ясно изложенных требованиях
Подробнее о типах...

Использование метода прототипирования позволяет:
° лучше понять/уточнить требования;
° вовлечь заказчика в процесс разработки;
° минимизировать ошибки проектирования, обнаружить недостаточность или несоответствие требованиям на начальных этапах, за счёт чего сократить  время и стоимости разработки;
° уменьшить расхождения в представлении о программе между разработчиками и пользователями.

-------------
° Почему стоит включить в разработку прототипирование

° Инструменты для прототипирования

° Как использовать бумажные прототипы в интерфейсах: практическое руководство

​​Кто такие стейкхолдеры?
#стейкхолдер #теория

Стейкхолдеры (заинтересованные стороны) - лица или организации, которые:
° Заинтересованы в результате и/или особенностях процесса разработки и развития вашего проекта или продукта
° Могут оказывать влияние на процессы, цели и результаты вашей работы

Стейкхолдер - это носитель определённой роли, а не конкретный человек или организация.

Классифицировать стейкхолдеров можно:
1.По принципу взаимодействия
° Внутренние - все, кто непосредственно работает над результатом и финансирует проект (владельцы компании, основатели проекта, акционеры,  сотрудники..)
° Внешние - те, кто могут каким-то образом повлиять на компанию или на конкретный продукт (госорганы, банки, СМИ, конкуренты, посредники..)

2.По уровню влияния
° Первичные - активно влияют на деятельность организации или выполнение проекта (владельцы, команда проекта, партнёры, клиенты).
° Вторичные - воздействуют на компанию или проект опосредованно (инвесторы, конкуренты, органы власти, СМИ)

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

° Анализ стейкхолдеров проекта

° Кто такие стейкхолдеры: Таблица интересов стейкхолдеров, Карта заинтересованных сторон, Матрица стейкхолдеров

​​Видеокурс Погружение в SQL + VBA
#sql #excel #vba #видеоуроки

В данном видеокурсе рассматривается вариант взаимодействия SQL и Excel через vba на примере проекта "Магазинчик"

Содержание курса:
Введение
1. Хранимые процедуры
2. Соединяем SQL и Excel
3. Получаем данные в Recordset из БД
4. Получаем данные на форму Form в Excel из Recordset
5. Проектирует таблицы БД
6. Продолжаем получать данные
7. Хранимая процедура для Склада
8. Из формы Excel в БД
9. Рефакторинг кода VBA
10. OUTPUT и SCOPE_IDENTITY
11. IF - ELSE
12. Удаление товаров и функция REPLACE
13. Циклический оператор WHILE
14. Выгружаем данные из БД в Excel
15. SELECT CASE и OUTPUT
16. Права доступа для БД
17. Вызов хранимой процедуры из другой хранимой процедуры
18. Скалярные функции. Возврат значения из функции
19. Временные таблицы
20. Курсор CURSOR. Обработка таблицы циклом
21. MERGE оператор слияния таблиц

Перейти к видеоурокам

​​Уровни требований к ПО.
#требования #уровни #теория

Обычно выделяют три уровня требований.

1. Бизнес-требования - описывают цели, которых хочет достичь заказчик (организация) с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Зачем", "Для достижения каких целей" нужна система;
-- Источники требований: акционеры, покупатели системы, управляющий реальными пользователями, топ-менеджер или ответственный за концепцию продукта.
-- Данные требования можно отразить: в документе о концепции и границах, в уставе проекта, в положении о бизнес-задачах, в документе основных рыночных требований ..
-- Пример: авиакомпания хочет на 20% снизить затраты на сотрудников у стойки в аэропорту;

2. Пользовательские требования  - описывают задачи, которые пользователь сможет (должен иметь возможность) выполнять с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Что" пользователь должен иметь возможность делать с помощью системы;
-- Данные требования можно представить в виде: вариантов использования, пользовательских историй.
-- Источник требований: представители пользователей;
-- Пример: Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет

3. Функциональные требования (требования к реализации) - описывают поведение системы, при тех или иных условиях.
Т. е. что "должна" делать система, чтобы пользователи могли выполнить свои задачи в рамках установленных бизнес-требованиями.
-- ФТ отражают в спецификации требований к ПО.
-- Пример: • Система должна по электронной почте отправлять пользователю подтверждение о регистрации.
• У пользователя (пассажира) должна быть возможность распечатать посадочный талон на зарегистрированный рейс.
------------