Выработка единого понимания будущей системы
Моя задача – помочь заказчику и исполнителю прийти к единому понимаю системы, что кардинально сокращает возникновение споров и взаимного недовольства на более поздних этапах. Описанная выше проблема различного трактования требований документации, к сожалению, обычно выявляется только на этапе сдачи заказчику уже разработанной системы, что не позволяет вносить большие изменения в практически готовую систему, которая в текущем виде может не представлять ожидавшейся ценности для заказчика. Такие проблемы обычно происходят при использовании классической «водопадной» модели проекта, когда этапы обследования, написания ТЗ и разработки следуют последовательно один за другим и занимают достаточно длительное время. Это приводит к тому, что после подписания сторонами «расплывчатого» ТЗ исполнитель уходит в разработку и потом приносит заказчику готовый (на его взгляд) результат, который неприятно удивляет заказчика. Поэтому самым важным этапом проекта является выработка единого понимания у заказчика и исполнителя, какие именно функции будут реализованы и как именно они будут работать. Для этого уже давно придуманы методологии гибкой разработки (например, Agile) и различные приемы совместного обсуждения функций системы в стиле «Пользователь в роли X хочет сделать Y чтобы получить Z. Для этого ему нужно выполнить действия A, B, C» (принципы User story mapping, Customer journey и т.д.). При таком подходе обе стороны будут иметь единое понимание того, что именно делает пользователь в системе, для чего и как. Наборы этих пользовательских историй должны быть отсортированы по приоритетам, и демонстрировать заказчику сразу после завершения и до перехода к разработке следующей истории.