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

Я начал писать книгу под условным названием «Идеальное ТЗ: Для программы, информационной системы, веб-продукта».

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

Идеальное ТЗ

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

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

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

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

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

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

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

Read the rest of this entry »

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

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

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

Стандарты

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)

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

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

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

Грубо можно выделить 3 категории документации, окружающих обычную IT-систему/продукт:

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-продукт на массовом рынке и что требовать от маркетологов?

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

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

Участники дискуссии: Борис Тылевич, Яна Москвина, Алишер Хасанов, Александра Лаврентьева

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

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

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

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

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

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

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

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

Что знает?

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

Что умеет?

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

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

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

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

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

Большинство статей, которые встречаются в сети на тему структуры бизнес-планов, предлагают эту самую структуру, но никак не объясняют, в каком порядке и как именно она формируется. Я решил устранить эту досадную проблему, используя метод инженерного анализа (reverse engineering).Какие ключевые факты должен сообщать бизнес-план на выходе?

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 — качество П/У. Таким образом организовав мониторинг, можно заниматься систематическим развитием П/У в духе теории ограничений — начиная с самых востребованных, но наименее качественных П/У.

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

Результаты 1-й встречи на тему«Микрокомпании, малые рабочие группы»

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

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

Кто?

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

Почему?

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

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

Как уходят?

Read the rest of this entry »

Раздумываю над идеей организации штучной подготовки системных аналитиков из:

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

и прочих.

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

Чему я могу научить подходящих кандидатов? Read the rest of this entry »