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.

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

1.410 visualizaciones

Publicado el

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

Publicado en: Educación
  • Inicia sesión para ver los comentarios

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

  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

×