Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

613 visualizaciones

Publicado el

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

Publicado en: Educación
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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

  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

×