Системная аналитика

С чего начинается

Чаще всего к нам приходят не с вопросом, а с ответом: готовым техническим заданием, списком модулей и выбранным стеком. На первый взгляд — всё серьёзно. На второй — технологии конфликтуют, лишние функции раздувают смету, а на вопрос «что именно должна делать система» ответа в документе нет.

Это не плохо написанное ТЗ. Это отсутствие продуктовой идеи, которое ТЗ маскирует. Из трёх опубликованных на этом сайте разборов два начинались именно так.

Как разбираем

Не считаем разработку вслепую. Сначала задаём вопросы: в последнем проекте их было больше восьмидесяти по четырнадцати блокам — от того, кто и зачем пользуется продуктом, до того, что происходит, когда всё пошло не так.

Дальше проходим путь целиком: от первого действия человека до результата, ради которого он пришёл. Настоящая задача обычно находится не там, где её искали.

Что получается

Документ, по которому можно работать: что система делает, в каком порядке, при каких условиях и что считается готовым. Не список пожеланий, а правила.

Там, где правила уже существуют вне нас, мы берём их, а не выдумываем свои: для одного проекта пять ГОСТов на товарную категорию превратились в логику, по которой система спрашивает, проверяет и предупреждает.

Проект в цифрах

Типичный объём после разбора: шесть недельных спринтов до первой рабочей версии при модельной стоимости разработки 2,25 млн ₽.

Разбор при этом окупается дважды: он не только описывает, что строить, но и показывает, чего строить не надо, — в одном из проектов объём удалось пересобрать на треть дешевле без потери сути.

Когда это не нужно

Если задача понятна, описана и не вызывает споров внутри команды — аналитика вам не нужна, берите и делайте. Мы скажем об этом прямо: разбор существует не для того, чтобы продать разработку, а чтобы понять, стоит ли вообще что-то конструировать.