Про антикризисные меры
Расскажу вам один случай, о котором узнал совершенно случайно от одного знакомого, с которым вместе работали в старой конторе.
Команда делала проект для одного местного Заказчика. Целью проекта была миграция старого приложения на новую платформу. С точки зрения функциональности этого приложения стоит отметить два момента: оно лопатило кучу информации и генерило документы космических объемов. Ко всему этому функциональному многообразию надо было добавить передачу этих феерических объемов информации во внешнюю базу данных. Взаимодействие с внешней базой должно было строиться через ее хранимку, написанную фиг знает кем фиг знает когда.
Когда дело подошло поближе к сдаче приложения в эксплуатацию, то оказалось, что производительность его настолько низкая, что использовать его в производстве попросту невозможно. В этот момент пришел Самый Главный Менеджер, сменил руководителя проекта и взял управление в личные руки. Ведущего аналитика упрекли в том, что он не уделил внимания нефункциональным требованиям и заменили на нового ведущего аналитика. Дальше тема понеслась по классике: начали уточнять нефункциональные требования, новый лид решил переписать аналитическую документацию в новом формате, аналитиков, работавших на проекте с самого старта, повыводили. В общем, полный букет эффективных управленческих решений на финальной стадии проекта.
Но интересны не следствия, а причины. Мы их и попытались после длительного общения выяснить. Вот они:
Отсюда вырисовываются следующие выводы:
Команда делала проект для одного местного Заказчика. Целью проекта была миграция старого приложения на новую платформу. С точки зрения функциональности этого приложения стоит отметить два момента: оно лопатило кучу информации и генерило документы космических объемов. Ко всему этому функциональному многообразию надо было добавить передачу этих феерических объемов информации во внешнюю базу данных. Взаимодействие с внешней базой должно было строиться через ее хранимку, написанную фиг знает кем фиг знает когда.
Когда дело подошло поближе к сдаче приложения в эксплуатацию, то оказалось, что производительность его настолько низкая, что использовать его в производстве попросту невозможно. В этот момент пришел Самый Главный Менеджер, сменил руководителя проекта и взял управление в личные руки. Ведущего аналитика упрекли в том, что он не уделил внимания нефункциональным требованиям и заменили на нового ведущего аналитика. Дальше тема понеслась по классике: начали уточнять нефункциональные требования, новый лид решил переписать аналитическую документацию в новом формате, аналитиков, работавших на проекте с самого старта, повыводили. В общем, полный букет эффективных управленческих решений на финальной стадии проекта.
Но интересны не следствия, а причины. Мы их и попытались после длительного общения выяснить. Вот они:
- На начальной стадии анализа у Заказчика интересовались, есть ли требования к производительности приложения. Получив отрицательный ответ, команда (ни лид аналитик, ни лид девелопер) ни разу на протяжении проекта не пропарились про производительность. Т.е. вообще о ней не думали и внимания на нее не обращали.
- На начальной стадии проекта был проведен анализ контекста, из которого совершенно очевидно был сделан вывод о том, что слабым звеном является чужая хранимка. Но поскольку Заказчик сказал, что к производительности требований у него нет, то и техническую экспертизу смежных решений не провели. В итоге получилось, что смежные решения накладывают такие ограничения, в которых выполнить требования к проектируемому решению попросту невозможно.
Отсюда вырисовываются следующие выводы:
- Рисуйте контекст и анализируйте его. Подключайте к анализу девелоперов, которые понимают, что такое архитектура и как с этим пониманием жить. Таких не много, но они есть. Техническая экспертиза результатов не должна быть формальностью.
- Если честно, девелоперы, которые сперва сквозь пальцы смотрят на результаты аналитики, а потом в ходе разработки стонут про хреновую постановку задачи, реально раздражают. Так и хочется сказать – чувак, а где ты был, когда аналитик тебе все это показывал и рассказывал, когда принимались технические решения, которые аппрувились у Заказчика?
- Когда Заказчик говорит «нет», то это не означает абсолютное «нет». В части нефункциональных требований про производительность, масштабируемость, расширяемость, юзабилити это почти всегда означает «нет специальных или особенных требований». Но это не отменяет правила хорошего тона, как-то: комфортная работа пользователя с приложением, нотификации, отличающие процессинг от зависания и т.п.
