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

Моя презентация с конференции PMDays 2008.

• Скачать презентацию в PPT
• Скачать пример концепции в PPT
• Видео выступления на PM Days

План рассказа

• Что такое Концепция
  • Зачем она нужна
  • Чем она отличается от ТЗ
  • Когда её стоит писать
  • Чем чреват пропуск Концепции
• Как она устроена
  • Инженерный документ VS художественный текст
  • Процесс создания и составляющие
  • Демонстрация примера

Концепция неформально

1. Кто чего хочет и почему
2. Почему сейчас этого не получается
3. Как должно быть устроено, чтобы всем нравилось
4. Что самое главное надо сделать, чтобы этого добиться

Назначение концепции

1. Инструмент выработки и согласования понимания:
   • Проблемы
   • Результата
   • Способа его достижения
     среди ключевых участников
2. Инструмент коммуникации, обеспечивающий:
   • Донесение понимания до всех участников процесса разработки
   • Мотивированность и чёткое видение цели и собственного вклада в результат
3. Основание для ТЗ и принятия решений
4. Фильтр для инициации проекта (лакмусовая бумажка)

Чем концепция отличается от ТЗ

• Фокус на причинах, целях проекта и ключевых свойствах продукта (а не детальных описаниях свойств)
• Краткость (3-10 страниц, против 30-80)
• Не меняется в ходе проекта

Почему её часто не пишут

1. «И так всё понятно»:
   недоосмыслена ценность фиксации и коммуникации
2. «Да вот же концепция — в письме Фёдора Ивановича!»:
   недоосмыслена ценность формализации
3. «Чего писать, работать надо!»:
   прокрастинация
   (предпочтение делать интересное, а не нужное).

Когда стоит делать концепцию?

ВСЕГДА

Если проект мал — полстраницы А4

Риски работы без концепции

• Goal Creep + Scope Creep
• Потеря мотивации
• Необоснованность ТЗ
• Конфликты
• Недостижение целей проекта!

Процесс создания концепции

1. Кто и чего хочет?
   • Выявление заинтересованных лиц
   • Выявление явных и скрытых интересов
2. Что сейчас? Описание текущей ситуации:
   • Формулировка проблем заинтересованными лицами
   • Выявление истинных причин проблем и их взаимосвязей
3. Что потом?
   • Построение вариантов целевой ситуации (как устойчивого равновесия интересов сторон)
   • Совместный выбор оптимального варианта
4. Как добиться?
   • Определение способа генерации путей достижения целей
   • Порождение необходимых для достижения целей верхнеуровневых работ и свойств системы

Свойства художественного текста

Коммуникационная задача — формирование, передача образа и ощущений:

• Свобода изложения (неструктурированность)
• Увлекательность
• Эмоциональная окрашенность

Свойства инженерного документа

Коммуникационная задача — создание чёткой обоснованной картины:

• Структурированность
• Взаимосвязанность
• Последовательность (от общего к частному)
• Трассируемость (прослеживаемость) утверждений

Структура концепции

Целеполагание

Разработка программы достижения целей

Источники

• RUP Vision Document
• ГОСТ РД 50
• PMBOK Project Charter

Не могу не поделиться выводами из вчерашней беседы с Сергеем Boatman’ом (см. его статью “Цели ИТ-проекта“).

Общий тезис — люди не любят ставить чёткие цели, т.к. они накладывают ответственность.

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

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

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

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

Разработчик не любит чётко поставленные цели, т.к. ему приходится работать на результат, а не в своё удовольствие (смотреть YouTube, читать bash.org, писать систематическую систематизированную систему) и разрыв между текущим состоянием работы и целевым формирует гнёт.

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

Решил зафиксировать общее место, которое, тем не менее, остаётся неозвученным.

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

Итак, типовые интересы, на мой взгляд, выглядят так:

Заказчик

• Получить продукт, приносящий деньги
• Повысить эффективность бизнеса

Компания-разработчик

• Заработать денег
• Пополнить портфолио успешных проектов

Разработчик

• Заработать денег
• Изучить новую технологию

Пользователь

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

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

Собственно, именно потому так плохо дело обстоит с госпроектами и проектами по автоматизации больших компаний — у первых достижение интересов Заказчика обычно очень мало связано с интересами Пользователя, а вторые ими часто пренебрегают, считая процессные характеристики бизнеса более важными, чем операционные («не нравится работать в этой программе? уволим, наймём на это место другого»).

Коллега прислал на рецензирование ТЗ на очередной поток доработок одного муниципального веб-ресурса.

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

Ну т.е. ладно я понимаю, что цели совсем не SMART, ну ладно, когда в качестве Целей пишут Задачи («автоматизация»), но писать в качестве оных ДЕЯТЕЛЬНОСТЬ («модернизация») — это имхо уже слишком

Люди! Умоляю вас, ТЗ не должно высасываться из пальца. ТЗ — это взвешенная качественная обоснованная постановка задачи, сделанная на основе АНЛИЗА ПРОБЛЕМЫ, а ПРОБЛЕМА выявляется в ходе ОБСЛЕДОВАНИЯ, либо как отдельного проекта, в случае новой системы, либо в ходе МОНИТОРИНГА, в случае существующей.

И цели проекта, поставленные в ТЗ, очень тесно связаны с целесообразностью, соответствием целям более высокого уровня. В этом смысле МОДЕРНИЗАЦИЯ отвечает цели более высокого уровня ПОТРАТИТЬ ДЕНЬГИ, СОЗДАВ ВИДИМОСТЬ РАБОТЫ, а цели типа ПОВЫСИТЬ ИНФОРМИРОВАННОСТЬ и УДОВЛЕТВОРЁННОСТЬ РЕСУРСОМ ЖИТЕЛЕЙ РЕГИОНА остаются вне фокуса, в пролёте.

А ведь казалось бы, что может быть проще — возьмите в качестве метрики показатель «Процент жителей региона, удовлетворённых качеством ресурса», далее составьте список потребностей-задач из 20-30 пунктов, согласуйте его и расширьте через механизм опроса на сайте, сделайте анализ удовлетворённости, получите цифру. Затем эту цифру увеличьте в N раз, получив абсолютную и относительную величину прироста удовлетворённости и постулируйте в качестве цели достижение этой величины в течении заданного времени. Тогда и проверить достижение целей проекта можно будет, и увидеть расход ИТ-бюджета на одного жителя, а следовательно — рост эффективности расходования тоже.

Тогда показатель «Процент жителей региона, удовлетворённых качеством ресурса» можно свести к произведению 2-х: а) Процент жителей региона, пользующихся интернетом прямо или опосредованно; б) Процент жителей региона, пользователей интернета, довольных качеством ресурса. И ставить задачи, исходя из целей увеличения на некоторую величину как первой так и второй составляющей. Потому что если всего в регионе интернетом пользуются 1-5% населения, то высокое качество ресурса не спасёт.

В проектах по разработке и внедрению ПО, а впрочем наверняка и в любой деятельности с участием нескольких лиц, иногда всплывает термин “Политика” – не применительно к предметной области или логике работы приложения, а на уровне выявления заинтересованных лиц, критически влияющих на ход проекта и их интересов и принятия разнообразных решений по ходу проекта.

Так вот, на мой взгляд, стоит преодолеть ту непроницаемую пелену сознания, которая-де должна возникать у слышащего это слово в контексте – “тут есть некоторые политические тонкости”, “подковёрная борьба”, “политически выгодная система” – типа это дело не твоего разумения, начальник сказал – а ты делай и т.д.

А именно, “Политика” в таком контексте – ничто иное, как опять же тот же старый-знакомый набор целей и интересов заинтересованных лиц, с единственной оговоркой – не озвучиваемый публично по различным причинам (в первую очередь из-за конфликта интересов с каким-то ещё ЗЛ). Так вот, “не озвучиваемый публично” – не означает “не поддающийся выявлению и фиксации”.

Моя рекомендация такая – старайтесь как можно раньше выявлять цели такой категории и фиксировать если не в своём сознании (что обычно просто, если проектов мало), то в личных (засекреченных) записях по проекту. Зачем это стоит делать – потому что эти цели точно также, если не более всего, влияют на требования к системе и проекту, с той тонкостью, что не имея возможности озвучивать их, вы вынуждены для придания системности подставлять вместо них другие. Но себя и коллег по проекту обманывать не стоит, даже если вы и ведёте в документации “двойную бухгалтерию” с точки зрения того, ради чего все делается.

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

Пока что вырисовывается вот что:

1. Проблема – это разница между желаемым и существующим (формулировка не моя, но мне нравится).

2. Желаемое можно описать как набор заинтересованных лиц и иерархии их потребностей, относящейся к сфере проекта. Скажем, с личностными потребностями по Маслоу мы активно работаем в проекте по личному психконсалтингу, в проекте по реорганизации бизнеса мы в основном работаем с профессиональными потребностями, в проекте по созданию массового сервиса – и с теми и с другими в равной степени, где профессиональные соотвествуют роли человека, использующего создаваемый продукт/систему, например, “студент”, “отец”. Причём в моём понимании иерахия потребностей отличается от Масловской – каждый уровень вытекает из вышестоящего, вешестоящий для данного отвечает на вопрос “ЗАЧЕМ?”, нижестоящий – “КАК?”.

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

4. Для каждого узла, потребности, строим дерево возможных решений – т.е. иерархия потребностей и целей переходит в иерархию целей и возможных задач для реализации этих целей.

5. Где-то тут или раньше мы производим ресурсную оценку способов реализации и сопоставляем с имеющимися у заказчика ресурсами.

6. На основании сопоставления ресурсов выбираем вариант построения решения, фиксируем таким образом ключевые задачи проекта и декомпозируем их план проекта.

Ещё у меня где-то проэтосамились критерии достижения целей.

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

xp-d2