ThinkStage Conference — 30+ speakers about BA, Product, UX. Regular price ends May, 24.
×Закрыть

Пре-требования (предварительные требования) в управлении проектами

Когда начинается процесс разработки? Со стадии бизнес-анализа и определения требований клиента? Или раньше? С формирования возможностей, которые могут быть реализованы?

Читайте перевод статьи Марка Смолли о том, что предшествует всем процессам IT-разработки и как этот процесс свести в единую систему для того, чтобы дальше на стадии создания продукта получить максимальный профит.

Марк Смолли, также известный как «The IT Paradigmologist», думает, пишет и много говорит об «парадигмах» IТ — другими словами, о наших изменяющихся взглядах на IТ. Марк является консультантом по управлению IT в Smalley.IT и партнером проекта Phoenix Project DevOps от GamingWorks. Он является глобальным послом в DevOps Agile Skills Association (DASA). Он участвует в таких областях знаний, как ASL, BiSL, BRM, COBIT, DevOps, IT4IT, ITIL и VeriSM. Марк читал лекции в различных университетах и выступал на сотнях мероприятий в более чем 20 странах!
Приходите знакомиться на конференцию для продакт менеджеров, бизнес аналитиков ThinkStage, где Марк выступит спикером.

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

Вы спросите, что же предшествует требованиям? С этого ли все начинается?

Скорее всего, для большинства людей в ИТ это так. Однако, нечто необычное предшествует старту инвестиций в ИТ. Этот период называется «ничего». Да-да, именно «ничего». В этот период часто существуют скрытые возможности, о которых никто не знает. Можно провести несколько лет в полном неведении, прежде чем их заметить. Ведь видеть возможность не всегда означает захотеть ею воспользоваться. «Это не сработает» — думаем мы. Люди могут так же долго пребывать в состоянии отрицания. Но через некоторое время возникает сомнение — «может быть, стоит рассмотреть этот вариант». И тогда, не без паники, нам удается распознать скрытые возможности и потенциальные инвестиции. Акцентирую на том, что инвестиции потенциальные, потому что они также должны быть обоcнованы спецификой бизнес-проекта.

С точки зрения ценности, этапы определения и обоснования являются наиболее важными. Именно на этих этапах устанавливается значение потенциальной значимости. Все, что происходит после, уменьшает потенциальные возможности, а не увеличивает их.

Это звучит немного удручающе, но целью всего креатива и прочих задач в ИТ-сфере является в перспективе потерять как можно меньше. Например, разрабатывая и внедряя все необходимое в кратчайшие сроки; путем безошибочного запуска требуемого функционала; избегая проблем во время выполнения работы. Проблемы, конечно, возникнут и уменьшат ценность потенциала. Задача ИТ — ограничить потери.

Ввиду глобальности задуманного, всегда есть моменты, которые заводят в тупик — невысказанные потребности, неоднозначные гипотезы. ИТ-специалистам это не нравится, им по душе нули и единицы. Их любимому скраму зачастую не совладать с решением неоднозначных задач, для этого необходимы другие методы.

Модели работы на этапе «Пре-требований»
Существует интересная модель под названием «три восьмерки» Дэйва Сноудена, автора модели «Кеневин». Небольшой команде разработчиков дают ограниченные требования и просят создать прототип за восемь часов. Затем другая команда из другого часового пояса получает задачу перенести прототип на следующий этап за восемь часов, но при этом не знает требований. На протяжении оставшихся в сутках 8 часов третья команда из другого часового пояса повторяет второе задание. Как и следует ожидать, конечный результат отличается от заявленных требований, но часто содержит новые идеи, о которых заказчики никогда бы не подумали при иных обстоятельствах. Другая версия данной модели заключается в том, чтобы сформировать три команды специалистов по вопросам гуманитарных, естественных и прикладных наук. Последняя рекомендация — помочь пользователю понять ИТ-технологии, что в наше время гораздо проще, чем заставить ИТ-специалистов понять бизнес.

Как только формулируется четкая гипотеза, срабатывают более привычные подходы в ИТ. Если еще не все приоритеты расставлены, можно использовать итеративные и линейные подходы с помощью Scrum и Lean.
Если требования и приоритеты четко установлены, а необходимые ресурсы и технические подходы предстоит определить, тогда лучше использовать тайм-боксинг. И, наконец, если известны и требования, и приоритеты, и ресурсы, и технические подходы известны, то лучше использовать модель Waterfall.

Мы привозим Марка в Украину уже в июне этого года. Марк выступит с докладом «If-then-maybe — the thinker’s nightmare!»
И расскажет, как мир действительно работает, какие есть подходы к работе с упорядоченными, сложными и хаотичными системами?

И проведет еще один мастер-класс: «The IT Renaissance — opportunity or threat?»
Как меняется бизнес-анализ, бизнес-аналитики? Кто такие Т-shaped people? Интерактивный мастер-класс, который исследует различные аспекты ИТ-мира.
До встречи на ThinkStage!

Оригинал статьи по ссылке

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Мы привозим Марка в Украину уже в июне этого года.

С удовольствием огромным мы приехали сюда
Отпустите нас отсюда — будем очень благода...
©

«The IT Paradigmologist» — эту фразу можно использовать как собеседование по английскому языку. Никаких других вопросов не нужно, просто произнести вслух. Попробуйте :)

ага) Это прямо тест на трезвость)

Подписаться на комментарии