Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Аналитик как золотоискатель:работа с требованиями призаказной разработкеНаталия Григорашведущий аналитик,компания Custis
О компании
О чем поговорим сегодняТребования при заказной разработке:• Особенности• Цели• Сложности и как их обойти• Итеративный подход
Работа с требованиями
Требования и заказная разработкаОсновной вопрос :что нужнозаказчику?
Аналитик как золотоискатель
Грамотная работа с требованиями
Как работать с требованиями?
Сначала определим цели• заказчик получает то,что ему,действительно,необходимо(что еще?)• постановка задач дляразработчиков...
Проблемы при работе с требованиями
Проблемы при работе с требованиями• «расплывчатые» требования• излишняя детализация задач, поступающих отзаказчика• «как н...
Проблемы при работе с требованиямикак их обойти?
«Расплывчатые» требования• нет четкой формулировкизадачи• недостаточно ясно изложеныцели• много «белых пятен»• в формулиро...
«Расплывчатые» требования:как добиться четкости?
«Расплывчатые» требования:• добраться до непосредственныхпользователей будущего функционала,раскрыть предполагаемые сценар...
Избыточность информации:Излишняя детализация задач,поступающих от заказчика(«лишние детали вконструкторе»)
Избыточность информации:• много допустимых вариантов– какой выбрать?• детали, которые сказываютсяна сроках или сложносовме...
Избыточность информации:как отсеять лишнееи не потерять нужное?
Избыточность информации:как отсеять лишнееи не потерять нужное?понять, кем и для чего будетиспользоваться будущий функцион...
«Как не поломать то, что уже работает»
«Как не поломать то, что уже работает»• найти решение, которое минимально меняет ужеработающий функционал, надстройка вмес...
Неверные предположения«мы думали, аоказалось…» (((((
Неверные предположения: последствия• срок разработки превысил ожидаемый• сделали, как хотел заказчик, но в итоге оказалось...
Неверные предположения: причины• заказчик указал не все сценарии• функционал разработан с учетом того, что будетзапущен в ...
Неверные предположения: как избежать?• выяснить у заказчика, что может повлиять вбудущем (переход на новую систему и др.)•...
Противоречивые требованиявходящие требования• противоречат ужеработающему функционалу• противоречат друг другу• «ломают» у...
Противоречивые требования:• доработка уже работающегофункционала или корректировкабизнес-процесса под новыйфункционал (не ...
А что со сроками реализации?
А что со сроками реализации?заказчик: «хочуза такой срок»
А что со сроками реализации?• отсеивание не очень критичных доработок,которые «ударяют по срокам»• определение оптимальной...
Еще: итеративный походКакие преимущества длязаказной разработки?
Итеративный походбыстрые релизы (раз в 2 недели)быстрая обратная связь ,быстрая реакция на запросы заказчика
Итеративный походможно первую версию отдать раньше,доработки реализовать позжепользователи могут раньше начатьиспользовать...
Итеративный походуточнение требованийв процессе разработкигибкость при работе с требованиями,уменьшение риска того,что зак...
Итеративный походВывод:для заказной разработкиитеративность естественна
К чему стремимся в итоге?• исчерпывающая формулировказадач для разработчиков• точная оценка затрат,запланированных для реш...
Наталия Григорашngrigorash@custis.ru
Аналитик как золотоискатель: работа с требованиями при заказной разработке
Nächste SlideShare
Wird geladen in …5
×

Аналитик как золотоискатель: работа с требованиями при заказной разработке

1.399 Aufrufe

Veröffentlicht am

Доклад Григораш Натальи на конференции Analyst Days-2. 25 мая, Санкт-Петербург. www.analystdays.com

Veröffentlicht in: Bildung
  • Login to see the comments

Аналитик как золотоискатель: работа с требованиями при заказной разработке

  1. 1. Аналитик как золотоискатель:работа с требованиями призаказной разработкеНаталия Григорашведущий аналитик,компания Custis
  2. 2. О компании
  3. 3. О чем поговорим сегодняТребования при заказной разработке:• Особенности• Цели• Сложности и как их обойти• Итеративный подход
  4. 4. Работа с требованиями
  5. 5. Требования и заказная разработкаОсновной вопрос :что нужнозаказчику?
  6. 6. Аналитик как золотоискатель
  7. 7. Грамотная работа с требованиями
  8. 8. Как работать с требованиями?
  9. 9. Сначала определим цели• заказчик получает то,что ему,действительно,необходимо(что еще?)• постановка задач дляразработчиков• минимизацияколичества доработок• разумные срокиреализации
  10. 10. Проблемы при работе с требованиями
  11. 11. Проблемы при работе с требованиями• «расплывчатые» требования• излишняя детализация задач, поступающих отзаказчика• «как не поломать то, что уже работает хорошо»• неверные предположения, «мы думали, аоказалось…»• противоречивые требования• ожидаемые сроки разработки превышают те, чтонеобходимы заказчику
  12. 12. Проблемы при работе с требованиямикак их обойти?
  13. 13. «Расплывчатые» требования• нет четкой формулировкизадачи• недостаточно ясно изложеныцели• много «белых пятен»• в формулировке требованиймного сравнений («хотим кактам»), которые не даютполной картины того, чтонеобходимо
  14. 14. «Расплывчатые» требования:как добиться четкости?
  15. 15. «Расплывчатые» требования:• добраться до непосредственныхпользователей будущего функционала,раскрыть предполагаемые сценариииспользования• «заполнение пробелов» на основе знаний обизнес-процессах заказчика, на основе ужеработающего функционала• несколько «точек» обратной связи (первичныетребования, раннее тестирование,«макетный» вариант)как добиться четкости?
  16. 16. Избыточность информации:Излишняя детализация задач,поступающих от заказчика(«лишние детали вконструкторе»)
  17. 17. Избыточность информации:• много допустимых вариантов– какой выбрать?• детали, которые сказываютсяна сроках или сложносовместимы с ужереализованнымфункционалом
  18. 18. Избыточность информации:как отсеять лишнееи не потерять нужное?
  19. 19. Избыточность информации:как отсеять лишнееи не потерять нужное?понять, кем и для чего будетиспользоваться будущий функционалотделить наиболее важную частьфункционала от деталейотдать пользователями получить отзывыразобраться с деталями(доработать, отказаться от них,вынести в отдельный функционал)
  20. 20. «Как не поломать то, что уже работает»
  21. 21. «Как не поломать то, что уже работает»• найти решение, которое минимально меняет ужеработающий функционал, надстройка вместопеределки• анализ того, что может быть затронуто(в т. ч. подключение разработчиков, общение скомандами смежных систем)• раннее тестирование, в т. ч. пользователями• постепенный переход к новому (сначалареализуется сама возможность, затем поэтапнопереключаемся на новое и отказываемся отстарого) –> минимизация риска
  22. 22. Неверные предположения«мы думали, аоказалось…» (((((
  23. 23. Неверные предположения: последствия• срок разработки превысил ожидаемый• сделали, как хотел заказчик, но в итоге оказалось нето, что ему реально было нужно• заказчика не устраивают какие-либо параметры,которые изначально не предусмотрели (скоростьработы, связь с другими системами)• небольшая доработка выросла в переделкузначительной части системы• возникли срочные непредвиденные доработки длядоведения до рабочего состояния• пользователям недоступны все возможностифункционала или не предусмотрены все нужныесценарии
  24. 24. Неверные предположения: причины• заказчик указал не все сценарии• функционал разработан с учетом того, что будетзапущен в эксплуатацию другой функционал илистороннее ПО, а второе отложилось• предоставлены ошибочные данные об объемеданных
  25. 25. Неверные предположения: как избежать?• выяснить у заказчика, что может повлиять вбудущем (переход на новую систему и др.)• предварительное нагрузочное тестирование нараннем этапе разработки• ранний фидбэк, передать «макетный» вариантили минимальный рабочий вариант• найти «точки риска» и путь, при которомвозможные доработки будут минимальны
  26. 26. Противоречивые требованиявходящие требования• противоречат ужеработающему функционалу• противоречат друг другу• «ломают» устоявшийсябизнес-процесс
  27. 27. Противоречивые требования:• доработка уже работающегофункционала или корректировкабизнес-процесса под новыйфункционал (не всегдавозможно)• поиск альтернативного пути,который решит потребностизаказчика• компромиссное решение(выделить детали, от которыхможно отказаться)как найти выход?
  28. 28. А что со сроками реализации?
  29. 29. А что со сроками реализации?заказчик: «хочуза такой срок»
  30. 30. А что со сроками реализации?• отсеивание не очень критичных доработок,которые «ударяют по срокам»• определение оптимальной последовательностивыполнения задач• расстановка приоритетов• при необходимости реализовать альтернативныйбыстрый вариант, позже перейти на болееправильный вариант
  31. 31. Еще: итеративный походКакие преимущества длязаказной разработки?
  32. 32. Итеративный походбыстрые релизы (раз в 2 недели)быстрая обратная связь ,быстрая реакция на запросы заказчика
  33. 33. Итеративный походможно первую версию отдать раньше,доработки реализовать позжепользователи могут раньше начатьиспользовать функционал,выигрыш по срокам
  34. 34. Итеративный походуточнение требованийв процессе разработкигибкость при работе с требованиями,уменьшение риска того,что заказчик получит не то,что ему было реально необходимо
  35. 35. Итеративный походВывод:для заказной разработкиитеративность естественна
  36. 36. К чему стремимся в итоге?• исчерпывающая формулировказадач для разработчиков• точная оценка затрат,запланированных для решениякаждой задачи• минимизация возможныхдоработок после передачизаказчику реализованногофункционала• и, главное, оправдание ожиданийзаказчика в разумные сроки.
  37. 37. Наталия Григорашngrigorash@custis.ru

×