1. 1. Роль требований в IT-проектах
1.1. 1.1. Зачем уделять требованиям так много внимания?
1.2. 1.2. Типичные ошибки в подходах к работе с требованиями, неизбежно приводящие к проблемам.
1.2.1. Думать, что работа с требованиями это некий отдельный этап работы в проекте.
1.2.2. Вера в обученного руководителя проектов
1.2.3. Непонимание важности уровня требований
1.2.4. ERP-система сама все определит
1.2.5. Излишний бюрократизм
1.2.6. Воспринимание требований "Как услышали"
1.2.7. Привязка к ИТ-системе
1.2.8. Незнание специалистами специфики отрасли
1.2.9. "Да там разберемся"
1.2.10. "Я самый умный"
1.3. 1.3. На что могут влиять требования к системе?
1.3.1. Персонал и аутсорсеры (исполнители)
1.3.2. Границы проекта, сроки, планы, трудоемкость и бюджеты
1.3.3. Приемка-сдача работ
1.3.4. Типичные проблемы, связанные с неудачными требованиями
1.3.5. Ожидания Заказчика
1.3.6. Что делать проектной команде?
1.4. 1.4. Что такое эффективный проект?
2. 2. Философия бизнес-анализа в IT-проектах
2.1. Введение в бизнес анализ, или кто такие бизнес-аналитики
2.2. Что нужно знать о Babok
2.3. Почему важны хорошо организованные коммуникации?
2.4. Как стать хорошим бизнес-аналитиком
2.5. О разнообразии возможностей бизнес-аналитика.
2.6. О важности построении картины мира
2.7. Источники информации для работы с требованиями.
2.8. Практические рекомендации для развития навыков извлечения и анализа информации
2.8.1. Интервью с заинтересованными лицами
2.8.2. Проведение анкетирования
2.8.3. Устные опросы
2.8.3.1. О важности хорошо организованных опросов
2.8.3.2. Техники задавания вопросов
2.8.3.3. Как строить диалог, чтобы получился хороший результат
2.8.3.4. Как бороться с внутренним сопротивлением при опросе
2.8.4. Организация совещаний и рабочих встреч
2.8.5. О том, как работать с диктофоном.
2.8.6. О пользе видеоконференций
2.8.7. Разговор по телефону
2.8.8. Рекомендации по использованию электронной почты
2.8.9. Идите и смотрите! Наблюдаем за работой.
2.8.10. Нормативная и регламентирующая документация
2.8.11. Отчеты и первичные документы.
2.8.12. Существующие системы автоматизации.
2.8.13. Обсуждение прототипов.
2.8.14. Актуализация
2.8.15. Приоритезация
2.9. О правильном отношении к информации
2.9.1. Будьте открыты к информации
2.9.2. Вырабатывайте стиль ясного изложения мыслей
2.9.3. Непрерывный анализ информации
2.9.4. Практикуйте функциональное мышление
2.9.5. Используйте и развивайте технику активного слушания
2.9.6. Письменно подтверждайте правильность понятой информации
2.9.7. Что делать с вопросами конфиденциальности?
2.10. Что такое хорошо и что такое плохо.
2.10.1. Почему плохо продавливать решения
2.10.2. :white_check_mark: О том, как решать проблемы и о сокрытии проблем
2.10.3. Когда полезен мозговой штурм и как его проводить
2.10.4. О шантаже и торгах, или почему иногда не получается договориться
2.11. Что нужно знать о проектных психотипах представителей заказчика.
2.12. Типичные ошибки аналитиков, связанные с особенностями личности
2.13. Инструменты бизнес-аналитика для моделирования
2.14. Модель компетенций бизнес-аналитика
2.15. Как готовить консультантов.
2.16. За что отвечает бизнес-аналитик в ИТ-проекте
3. 3. Консалтинг в ИТ-проектах
3.1. О правильном понимании консалтинга в ИТ-проектах.
3.2. Бывают ли ИТ-проекты без консалтинга? Или когда вы начинаете заниматься консалтингом?
3.3. В чем отличие между внутренним и внешним консалтингом.
3.4. Почему консалтинг в ИТ-проектах не всегда получается эффективным.
3.5. Что будет, если потребность в консалтинге игнорировать?
3.6. Работа с персоналом заказчика.
4. 6. Управление жизненным циклом требований
4.1. О необходимости управлять требованиями
4.2. Детальные требования к системе
4.3. Согласование требований
4.4. Роли участников проекта
4.5. Управление изменениями требований
4.6. Разработка методики и порядка тестирования
4.7. Идентификация и прослеживаемость требований
4.8. Трассировка требований
4.9. Управление изменениями требований. Как бороться с раздуванием требований
4.10. Наличие базы знаний по реализованным ранее требованиям
4.11. Рецензирование требований
4.12. Точка входа в проект
5. 8.Подходы к управлению проектами и их влияния на работу с требованиями.
5.1. О гибких методологиях
5.2. Про управление по PMBok
5.3. О бессмысленности споров о подходах
5.4. Что полезнее, менеджмент или технологичность?
5.5. Замолвим слово о кейсах
5.6. Эволюция подходов
5.7. И какой подход выбрать?
6. Легенда
6.1. Отсутствует
6.2. Требует корректировки
6.3. Есть идеи
6.4. Готово к вычитке
6.5. Готово к печати
7. Общие разделы
7.1. Аннотация
7.2. Введение
7.3. Список литературы
8. 4. Разработка требований к системе
8.1. Что нужно знать о требованиях
8.2. Про бизнес-анализ и системный анализ
8.3. Уровни требований
8.4. Виды требований
8.4.1. Что надо знать о видах требований
8.4.2. Требования к функциональности
8.4.3. Требования к пользовательскому интерфейсу
8.4.4. Требования к производительности
8.4.5. Требования к техническому обеспечению
8.4.6. Требования к безопасности
8.4.7. Требования к документации
8.4.8. Прочие виды требований.
8.4.9. Особенности отдельных видов требований
8.4.9.1. Требования к НСИ (нормативно-справочной информации)
8.4.9.2. Требования к интеграции систем
8.4.9.3. Требования подготовке начальных данных
8.4.9.4. Требования к взаимодействию с третьими сторонами
8.4.9.5. Требования производительности системы или отдельных компонентов
8.4.9.6. Требования к пользовательским интерфейсам
8.4.9.7. Нефункциональные требования
8.4.9.8. Требования к персоналу
8.5. Каким должно быть удачно сформулированное требование?
8.6. Пример по улучшению требований
8.7. Организация работ по анализу и формализации требований
8.7.1. Почему процесс анализа требований должен быть организован и не получится взять «нахрапом».
8.7.2. Инструментарий.
8.7.3. Система контроля рамок.
8.7.4. Процесс бизнес-анализа
8.7.4.1. О подходах к бизнес-анализу.
8.7.4.2. Первое знакомство с бизнесом Заказчика
8.7.4.3. Формирование рабочей группы и подготовка к процессу анкетирования
8.7.4.4. Анкетирование
8.7.4.5. Предварительная обработка анкет и подготовка к опросам
8.7.4.5.1. Выделение участников и описание организационной структуры
8.7.4.5.2. Изучение управленческой документации
8.7.4.5.3. Выделение ключевых бизнес-процессов
8.7.4.5.4. Пользовательские сценарии и бизнес-процессы. Кто лишний?
8.7.4.6. Опросы и уточнение бизнес-функций
8.7.4.6.1. Организация устных опросов
8.7.4.6.2. Уточнение ключевых требований к автоматизации
8.7.4.6.3. Изучение системы документооборота и управленческой отчетности
8.7.4.6.4. Надо ли изучать существующие системы автоматизации?
8.8. Моделирование требований в информационной системе и создание прототипов
8.8.1. Что такое моделирование требований?
8.8.2. Как строить модели?
8.8.3. Проведение демонстрации модели и возможные результаты
8.8.4. Когда учить пользователей новой системе?
8.9. Согласование требований
9. 5. Трактат о проектной документации.
9.1. Азбука документирования
9.1.1. Что есть проектная документация?
9.1.2. О том, как связана проектная документация с управлением требованиями
9.1.3. О легитимизации информации в проекте
9.1.4. Внутренняя и внешняя документация в проекте
9.1.5. Репозиторий документов
9.1.6. Актуализация документации и донесение изменений до участников
9.1.7. Мифы, стереотипы и типичные проблемы
9.1.7.1. Можно обойтись и без документации
9.1.7.2. "У нас некому делать документацию"
9.1.7.3. Документацию должны писать специально обученные для это люди- технические писатели
9.1.7.4. "Мы об этом говорили!"
9.1.7.5. Документацию никто не читает
9.1.7.6. "В жизни все будет иначе"
9.1.7.7. Все должно быть согласовано
9.1.7.8. Нашу документацию пользователь не понимает
9.1.7.9. Создание документации очень дорого. Кто будет платить?
9.1.7.10. Пользовательские инструкции для меняющейся системы писать бесполезно - они быстро устареют.
9.1.7.11. Документацию нужно обязательно создавать по стандартам.
9.1.7.12. Документацию нужно обязательно создавать в каком-либо текстовом редакторе.
9.2. Как создавать полезные для проекта документы
9.2.1. О множестве целей документирования
9.2.1.1. сопровождение процессов проекта
9.2.2. Кому она нужна, проектная документация?
9.2.3. Как не плодить макулатуру из документов и не тратить на это ресурсы
9.2.4. Глубина детализации проектных документов
9.2.5. Кто должен создавать документацию?
9.2.6. Что делать, если реальная жизнь отличается от задокументированной?
9.2.7. Как управлять экономикой процесса разработки документов
9.3. О некоторых видах проектных документов.
9.3.1. Документы, регламентирующие коммуникации
9.3.2. Формулирование ключевых требований к системе, целей, критериев успешности
9.3.3. Что такое техническое задание?
9.3.4. Как писать инструкции пользователям
9.3.5. Структура Технического задания. ГОСТ или не ГОСТ?
9.3.6. А нужно ли вообще техническое задание? А Технический проект?
9.3.7. Контрактная документация
9.3.8. Сопроводительная документация
10. 7. Технический инструментарий в управлении требованиями
10.1. Введение в инструментарий
10.2. Как и где организовать хранение информации по проекту
10.3. Репозиторий материалов
10.4. Инструменты коммуникаций
10.5. Менеджер задач
10.6. Ментальные карты
10.7. Канбан-доски
10.8. Инструменты описания бизнес-процессов
10.9. О нотациях
10.9.1. Что нужно знать о нотациях
10.9.2. Блок-схемы
10.9.3. eEPC
10.9.4. IDEF
10.9.5. BPMN
10.9.6. SIPOK