Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

611 views

Published on

Доклад Андрея Федорина на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург
www.analystdays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Семь правил создания убедительного технического задания Андрей Федорин
  2. 2. Проблемы 2 1. Закрытость и не предоставление информации 2. Незнание главного стейкхолдера усложняет сбор требований 3. Каждый понимает сокращения по своему и делает в итоге «не так» 4. Отрицательные формулировки срывают сроки проекта 5. Некоторые проблемы всплыли в конце, хотя подумать о них можно было заранее – риски и вопросы к проекту 6. Не все, что является очевидным Вам – является очевидным для других 7. Текст скучен и заказчик его не читает
  3. 3. 1. Открытость на всех уровнях разработки 3 Проблема:  Закрытость и отказ в предоставлении информации Решение:  Заручиться поддержкой главного авторитета – получить необходимый уровень полномочий  Неформальное общение с участниками проекта – установление личного контакта с каждым стейкхолдером
  4. 4. 2. Кто главный? 4 Проблема:  Если неправильно определяешь кто главный, то с тобой никто не делится информацией, возникают проблемы в реализации проекта Решение:  Изучение документов на инициацию проекта – кто ставит подпись в протоколе, тот скорее всего главный  Выйти за рамки стандартной процедуры анализа – поддерживать неформальное общение с ключевыми игроками . со стороны бизнеса
  5. 5. 3. Краткость – сестра таланта (1/2) 5 Проблема:  Все и так понятно  Неформальное общение приводит к тому, что хочется замять кучу понятных вещей  То, что вы понимаете между собой не будут понимать остальные участники проекта Решение:  Формализация понятийного аппарата  Создать раздел «Глоссарий» - наполнять его по окончанию описания каждого раздела ТЗ
  6. 6. 3. Краткость – сестра таланта (2/2) 6 Как делать не надо: Как надо:
  7. 7. 4. Позитивное мышление 7 Проблема:  Отрицательные формулировки приводят к неправильному результату Решение:  Формулировать требования в положительном контексте  Утверждать, а не отрицать Поле может принимать только следующие значения: «0..9», «А..Я», «а..я» Как делать не надо: Как надо: Поле не должно позволять вводить специальные символы
  8. 8. 5. Допущения и ограничения проекта 8 Проблема:  Некоторые проблемы всплыли в конце, хотя подумать о них можно было заранее – риски и вопросы к проекту Решение:  Завести пустой раздел и наполнять его по мере появления ограничений или допущений
  9. 9. 6. Внимание к деталям 9 Проблема:  Не все, что кажется очевидным Вам – кажется таким же очевидным другим Решение:  Правило 5-85
  10. 10. 7. Рисуйте диаграммы 10 Проблема:  Текстовое описание процесса не читают или не воспринимают Решение:  Дублируйте описание процесса картинками
  11. 11. Какие правила я использую 11 1. Заручиться поддержкой «больших начальников» 2. Знать кто является главным стейкхолдером 3. Надо вести Глоссарий проекта 4. Использовать положительные формулировки 5. Фиксировать все ограничения в проекте 6. Детализация по принципу 5-85 7. Дублировать описание процесса на двух языках – язык текста и язык картинок
  12. 12. Андрей Федорин AndreyFedorin@hotmail.com Спасибо за внимание 12

×