О чём в ней пойдёт речь?

Идеальное ТЗ

на программу, информационную систему, веб-продукт

1. Для кого эта книга

2. Предисловие

Методы, методы, методы!

3. Каким бывает успех?

Проект, продукт, система

Бизнес, пользователь, разработчики

4. Выявляем интересы

Ожидания

Публичное

Скрытое

5. Формулируем проблему

Что сейчас?

Что потом?

Конфликты

6. Зри в корень!

Находим причины

7. Кладём цели

Деятельностный подход

Целевая ситуация

8. Исследования

Предметная область

Рынок

Деятельность бизнеса

Деятельность пользователей

9. Зачем нужна концепция

Ключевые свойства продукта

10. А теперь можно без ТЗ?

11. Хорошее ТЗ, плохое ТЗ

Контейнер

Свойства идеального документа

Почему идеального ТЗ не бывает

12. Всё понятно! Поехали! Типичные ошибки

Работа по шаблону

Скачки по уровням

ХЗ

Техпис

13. Как должны выглядеть требования?

Что и Как

Функции, функции и функции

Конец конвейера

Взаимодействия

Сценарии способов применения

Бизнес-правила

Атрибуты качества и ограничения

Иерархия требований и трассируемость

14. Шаблоны профилей качества

Категории систем

Аспекты качества

15. Моделирование системы

Белый ящик, чёрный ящик

Бизнес-архитектура, Техническая архитектура

16. Прототипирование

Модель навигации

Разработка макетов

17. Контроль реализации требований

Виды тестирования

Связь тестовых сценариев и сценариев способов применения

18. Изменения требований

Анализ влияния

Девалидация

19. Процесс

Принципы

Роли

Виды документов

Методы и лучшие практики

Цикл итерации

20. Проект

Где мы: Заказчик, Разработчик, Консультант

Выбор методов

Приложеньица

Профиль профессии «Бизнес-аналитик»

Профиль профессии «Системный аналитик»

Стандарты

Что читать

Инструменты

Словарь терминов

Ссылки

1. Разработка и управление требованиями

1. Химонин: Сбор и анализ требований к программному продукту [цифра] — MUSTREAD!
2. Леффингуэлл, Уидриг: Принципы работы с требованиями к ПО. Унифицированный подход (Managing Software Requirements: A Unified Approach) [цифра]
3. Коберн: Современные методы описания функциональных требований к системам (Writing Effective Use Cases) [бумага]
4. Вигерс: Разработка требований к программному обеспечению (Software Requirements) [цифра]
5. Халл, Джексон: Разработка и управление требованиями [цифра]

Стандарты

1. ГОСТ Р ИСО/МЭК 9126: Оценка программного продукта. Характеристики качества и руководство по их применению
2. IEEE 830: Recommended Practice for Software Requirements Specifications
3. ЕСПД. ГОСТ 19.201-78: Техническое задание, требования к содержанию и оформлению
4. ГОСТ 34.602-89: Техническое задание на создание системы

Своды знаний

• IIBA. Business Analysis Body of Knowledge (BABOK) [цифра]

2. Основы системного анализа

1. Оптнер. Системный анализ для решения деловых и промышленных проблем

3. Моделирование

1. О’Коннор, МакДермотт, Искусство системного мышления [бумага]
2. Фаулер, Основы UML [бумага]

4. Бизнес-моделирование

1. Рамбо, Блаха: UML 2.0. Объектно-ориентированное моделирование и разработка (Object-Oriented Modeling and Design with UML) [бумага]
2. Шеер: ARIS — Моделирование бизнес-процессов [бумага]

Стандарты

• Р 50.1.028-2001: Методология функционального моделирования

5. Проектирование интерфейсов

1. Константайн, Локвуд: Разработка программного обеспечения [бумага]
2. Розенфельд, Морвилл: Информационная архитектура в интернете [бумага]

6. Системное проектирование

1. Ларман: Применение UML и шаблонов проектирование [бумага]

Стандарты

• IEEE 1016-1998: Recommended Practice for Software Design Descriptions

7. Процессы разработки ПО

1. Коберн. Быстрая разработка программного обеспечения [бумага]
2. Соммервиль. Инженерия программного обеспечения [бумага]

Стандарты

• ГОСТ Р ИСО/МЭК 12207: Процессы жизненного цикла программных средств

Своды знаний

• Software Engineering Body of Knowledge (SWEBOK)

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

Бесков Денис — Состав документов требований

1. Предпроектная — создаётся на этапах, предшествующих детальному определению внешних свойств и внутреннего устройства системы.
2. Проектная — содержит основной пакет проектных решений
3. Эксплуатационная — используется для развёртывания, использования и модернизации системы

Какие документы можно отнести к этим категориям?

Предпроектная документация

1. Постановка проблемы
2. Отчёт об обследовании деятельности
3. Концепция системы
4. Бизнес-план
5. BRD / MRD / PRD / FSD
6. Пользовательские требования
7. Техническое задание
8. Технико-экономическое обоснование

Проектная документация

1. Функциональная спецификация
2. Эскизный проект
3. Документ архитектуры системы
4. Технический проект
5. Техническая спецификация

Эксплуатационная документация

1. Руководство администратора
2. Руководство пользователя
3. Руководство разработчика

Кто должен выступать основным автором этих документов при инженерном (а не халтурном) подходе к организации ведения проектов?

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

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

На самом деле это не так, технические писатели могут быть отличными ОФОРМИТЕЛЯМИ документации и могут достаточно неплохо почти самостоятельно справляться с 3-й — эксплуатационной категорией документации, но для того, чтобы создавать документы 1-й и 2-й категорий (а документы сами по себе не являются самоцелью, а являются лишь форматом коммуникации результатов работ), нужно обладать соответствующей квалификацией, согласно перечисленным выше ролям.

Что делать?
Если ваши маркетологи, аналитики, инженеры не справляются с созданием предпроектной и проектной документации (в объёме, когда затраты на создание документа меньше рисков и ущерба от работы от него) — значит им не хватает квалификации.

Если страдает оформление — наймите техписа.

Если страдает содержание — организуйте обучение или наймите профессионалов.

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

1. Нотации (в частности, UML) и инструменты — переоценены. Что действительно важно?
2. Аналитик часто вынужден проектировать интерфейсы. Как не сделать каку?
3. В каком порядке стоит внедрять RUP?
4. Как организовать обучение аналитика?
5. Зачем и как организовывать групповую работу аналитиков?
6. Базовые инструменты и методы аналитика
7. Специфика работы аналитика в разных классах ПО и ИС
8. Что такое успешный IT-продукт на массовом рынке и что требовать от маркетологов?

А также почти любые аналитико-проектировочные темы, которые интересуют вас.

Могу в Москве, могу в любом другом городе (с оплатой проезда).

На кого похож Менеджер Продукта?

• Менеджер проекта
• Бренд-менеджер
• Маркетолог
• Бизнес-аналитик

Зачем он нужен?

• Выделить ответственного
• Повышение конкурентоспособности продукта
• Разрешить конфликт интересов
• Единая точка принятия решения по продукту
• Сделать успешный продукт

Чем он занимается?

• Исследования
  • Изучает рынок
  • Изучает поведение аудитории
• Управление требованиями
  • Собирает требования
    • Бизнес- (внутренние)
    • Рынка
  • Разработка требований
    • Концепция продукта
    • Функциональные спец
  • Приоритезация
  • Согласование требований
  • Коррекция требований по результатам эксплуатации
• Планирование этапов (версий)
• Прототипирование продукта
• Сопровождение разработки
• Тестирование
• Организация выхода продукта на рынок
• Сбор и анализ обратной связи

Чем не занимается?

• Не отвечает за сроки
• Не занимается ценообразованием
• Не пишет ТЗ

Что знает?

• Предметную область
• Свой рынок
  • Конкуренты
  • Тенденции
• Аудиторию
  • Потребности
  • Характеристики
• Методы проведения исследований
• Особенности применяемых технологий
• Организацию производства

Что умеет?

• Умеет коммуницировать
• Умеет писать документы

Где его искать?

• Маркетинг
• Проджект-менеджеры
• Проектировщики

Оставшиеся вопросы:

• С кем он взаимодействует
• Чего от него требовать
• Как готовить

1. Первичный объём вложений
2. Срок окупаемости
3. Целевой уровень и процент доходности
4. Потенциал роста

Откуда эти цифры берутся? Они складываются из планов доходов и планов расходов.

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

Под планом я понимаю набор точек формата Время, Сумма, Назначение.Чем определяются эти финансовые планы? В основном — ходом процесса создания продукта или услуги и их предоставления клиентам, а именно:Производственные планы:

1. Планом исследований
2. Планом разработки продукта/услуги
3. Планом продвижения

Обеспечивающие планы:

1. Планом закупок
2. Планом аренды
3. Кадровым планом

Все эти планы достаточно взаимозависимы, но ключевым всё-таки следует признать план разработки — что именно и в каком порядке должно появляться определяет большинство затратных статей на обспечение деятельности и вывод продукта на рынок.Итого, собирая всё вместе, получаем следующую картину зависимостей и порядка разработки документа:Что забыл?Далее в программе — на основании чего и как именно формируется план разработки.

Можно ввести два показателя, характеризующих процесс использования П/У и его эффективность:

1. UA-factor — количество попыток (usage attempts) воспользоваться услугой/продуктом.
2. PF-factor — количество одобрительных отзывов (positive feedback) о продукт/услуге в процессе использования.

Пример применения:

Для веб-страниц в качестве UA-фактора выступает количество просмотров страницы и этот параметр считается стандартной статистикой. Чтобы организовать сбор PF-показателя, нужно создать функционал обратной связи, например в виде кнопки [LIKE] в зонах начала и завершения изучения содержимого страницы. Особенно полезно это может оказаться как контур обратной связи для автора в корпоративных и публичных вики-системах.

UA-фактор зависит от 1) востребованности П/У, 2) качества организации навигации (в широком смысле, findability) к П/У.

Таким образом, соотношение UA-фактора разных П/У в однородном поле характеризует их относительную востребованность, а отношение FB к UA — качество П/У. Таким образом организовав мониторинг, можно заниматься систематическим развитием П/У в духе теории ограничений — начиная с самых востребованных, но наименее качественных П/У.

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

Кто и почему устал или не хочет вести деятельность

в условиях типичной компании (10+ человек)

Кто?

• Фрилансеры
• Неудавшиеся предприниматели
• Профессионалы высокого класса
• Специалисты

Почему?

• Неэффективные процессы коммуникации и менеджмента
  • Большой компанией тяжело управлять
  • Хочется больше гибкости
• Конфликт профессиональных ценностей
  • Динамика роста компании не совпадает с динамикой ростой человека
• Конфликт личных и бизнес-ценностей, культура и политика компаниии противоречит человеку
  • Многие не приемлют внешние рамки
  • Хочется делать то, что нравится и хочется, а не то, что должно
  • Минус большой компании — чётко регламентированные функции, что мешает самореализации
• Смена обстановки
  • Возникает желание изменить жизнненную ситуацию
• Негативные изменения в компании
  • например, нежелание подчиняться тому, кого ты не выбирал

NB: Основные виды рабочих мотивов via FriendFeed (за что работаем?)

Как уходят?

Способы ухода

• Поодиночке
• Командами
  • Почкование

Куда уходят и ради чего?

Свойства больших и малых коллективов

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

Форматы оргструктур

Иерархии

Мотивация:

• Больше денег

Формат:

• Свой бизнес

Кто:

• Предприниматели

Цели, интересы:

• Вырасти в большую компанию
• Перераспределять прибыль
• Хотят расти

Сети

Основная мотивация:

• Самореализация

Формат:

• Малая рабочая группа

Кто:

• Специалисты

Цели, интересы:

• Не хотят расти
• Комфорт труда
• В поисках баланса между затрачиваемыми усилиями и личными ценностями
• Профессиональный рост
• Стереть грани

(В ходе дискуссии принято решение посвятить её именно рабочим группам и сетям как более интересному участникам формату)

Что такое малая рабочая группа?

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

Всё это в МРГ делается не ради дохода, а ради других ценностей. Но все они — профи высокого уровня! Условия: перегретый рынок вакансий
Типичные источники возникновения МРГ: Студенческие группы, первые студенческие проекты

Почему говорим о явлении новых форматов оргдеятельности как тенденции?

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

Чем отличается микрокомпания от МРГ?

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

Какие условия им необходимо обеспечить для выживания рабочей группы?

• Общие ценности
• Механизм принятия решения
• Согласование правил распределения прибыли
• Согласованное развитие интересов

NB: Выживание группы — это не самоценность!

Описание свойств рабочей группы

• Группа собирается из тех, кто друг другу симпатичен как человек и они совместно создают микроклимат и атмосферу.
• Должны быть оговорены правила входа и выхода — для поддержания связности группы.
• Должны быть выработаны общие правила игры.
• Такая группа меняется и развивается с положительной динамикой.
• Её развитие согласовано, но выживание не является самоцелью.
• Простая, эффективная коммуникация — свойство такой группы.
• Группа постоянно находится в процессе достижения своей цели.

Что может происходить с МГ?

1. Она может умереть
2. Она может разбиться на более мелкие
3. Может возникнуть иерархия — происходит вырастание компании

Какие условия им необходимо обеспечить для реализации собственных интересов

• Согласованность интересов

Что должны сделать участники для выживания такой группы:

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

Какие роли необходимы/возможны в такой компании

• Ref: См. Белбин

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

Какие устойчивые структуры компания может принимать эволюционирующая РГ?

• Переход сетевой — к иерархии
• Веполь (сеть с 2-мя равноправными центрами активности), Триполь и т.д.

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

• Придумать самим
• Взять опыт из think tanks

Механизмы принятия решений

• Универсальные
• Экспертный
• Большинством
• Консенсусный
• Заданные заранее
• Гибридные
• Стратегические
• Тактические

Если группа умеет принимать решения и есть для этого механизм, то она может всё.

Каковы перспективы у таких оргструктур?

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

Рекомендованное чтиво: «Алхимия корпораций»

Участники: Дмитрий Росляков, Роман Ефимов, Денис Бесков, Евгений Калинин, Дмитрий Кузин, Филипп Смирнов, Дмитрий Филёв, Алина Зотова, Алексей, Евгений Бойко. Всем спасибо за участие!

Ждём ваших дополнений, комментариев и предложений.

• тестировщиков
• техписов
• разработчиков

и прочих.

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

Чему я могу научить подходящих кандидатов?

• Проведению интервью
• Изучению проблемной ситуации
• Выявлению бизнес-требований
• Целеполаганию
• Моделированию предметной области (структурной и деятельностной)
• Анализу бизнес-требований
• Анализу пользовательских задач и деятельности
• Разработке ключевых свойств продукта/ключевых задач проекта
• Оформлению вышеперечисленного в концепцию продукта
• Разработке пользовательских требований
• Разработке технических требований
• Оформлению вышеперечисленного в ТЗ
• Эскизному моделированию системы
• Проектированию системы навигации

Также дать представление о типовых процессах разработки (RUP, MSF, Scrum), нотациях моделирования бизнес и технических систем (ARIS, UML), стандартах оформления проектной документации (ГОСТ, IEEE, RUP).

Как может выглядеть процесс подготовки и прохождения обучения:

1. Вы проявляете заинтересованность
2. Я вам рассказываю о работе системного аналитика
3. Я помогаю вам решить, насколько вам интересна работа в такой роли
4. Проводим тестирование на личностные качества и компетенции
5. Ставим достижимую профессиональную цель
6. Разрабатываем план подготовки
7. Реализуем план подготовки

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

Обучение платное, ориентировочная цена — порядка 1 тыс. рублей в час (плата появляется на этапе 5). Если получится набрать мини-группу в 3-5 человек — теоретическая часть будет дешевле.

Чем это лучше готовых тренингов Люксофта, Текамы и проч. — полнотой охвата, персональным подходом, боевыми задачами, раскрытием недокументированных особенностей работы в индустрии.