Семь раз отмерь, один раз отрежь
Предлагаю для простоты и юмора провести аналогию, и гиперболизировать сюжет. Представим, что IT-продукт - это дом и мы собираемся его строить.
В главных ролях:
- Предприимчивый Кеша
- Дизайнер-архитектор Глаша
- Бригада строителей «Безымянный труженикъ»
- и другие...
Итак, действие первое
Долго ли коротко Кеша думал о своем проекте, но в итоге определился:
«Буду ставить дом, многоквартирный, 4 парадных, 17 этажей. Обязательно в красно-желтых цветах, сейчас они в моде. И клумбу с геранью надо не забыть, жена просила. За два месяца управлюсь» ‒ подумал он и отправился на салфетках чертежи чертить, да ТЗ составлять.
Окончив труды, собрав в кучу салфетки и ТЗ он обращается к дизайнеру-архитектору Глаше. Три дня и три ночи они обсуждают (по e-mail естественно) проект и оговаривают все условия. Та уверяет, что справится за неделю. В итоге жмут друг другу виртуальные руки, ставят лайки и работа начинается.
Действие второе
Глаша изрядно уставшая приходит на презентацию проекта. Кеша естественно недоволен из-за затянувшихся сроков.
«Я не могла решить куда разместить герань. ‒ сказала оправдываясь Глаша ‒ Однако, я придумала весьма элегантное решение ‒ разместить ее в горшках на пожарной лестнице»
На том и порешали. Далее следует презентация проекта, Глаша показывает красивые рендеры и 3D-модели. Все круто, красиво, а также вроде бы ясно и понятно. Успех не за горами.
Действие третье
Посмотрев рендеры и модели, несмотря на множество неясных моментов, «Безымянный труженикъ» все же соглашаются на подряд. Проект выглядит типовым и понятным, сто раз так делали, да и в полтора месяца вроде бы уложиться получается.
Действие четвертое
Прибыв на участок оказалось, что он находится рядом с водоемом и перед началом строительства необходимо вбить сваи и решить проблему с небольшим озером посреди участка.
Смета начинает расти, а сроки поджимать. Знать бы где споткнешься, соломку бы подложил. Что же поделать, уже вписались, строим дальше.
Действие пятое
Фундамент заложен и даже построен первый этаж, но тут Кеша понимает: было бы круто сделать подземную парковку. Сейчас все так делают, к тому же это кратно увеличит прибыль. Без этого ну никак нельзя.
Неприятная новость для строителей - придется переделывать, но для Кеши еще неприятнее, это снова увеличит смету. Стройка продолжается.
Устал читатель? Не расслабляйся, экшОн еще впереди:)
Действие шестое
Вот он, стоит, многострадальный, но столь ожидаемый новострой... Все счастливы и довольны. А вот инспекция не разделяет оптимизма Кеши.
Выясняется, что домом должны иметь возможность пользоваться не только здоровые люди, но и люди с ограниченными возможностями. При обсуждении проекта был сделан расчет на среднестатистического жильца.
Также не спроектирована система оповещения и пожаротушения, а на пожарных лестницах размещено угадайте что?
Правильно! Большие горшки с геранью. «Безымянный труженикъ» вновь берется за работу.
Действие седьмое
Проект влетает в копеечку и уже не кажется таким прибыльным и успешным.
«Получилось бы отбить вложения» - думает Кеша.
Хорошо что в реальности так никто не строит дом, а почему тогда IT-проект ведется как попало? Если вы похожим образом работаете над своим IT-проектом, то у меня для вас плохие новости.
Перспектива раздутой сметы и сорванных сроков не за горами. Однако, избежать подобных ошибок и просчетов поможет предварительное проектирование.
Почему же я так уверенно это утверждаю? Приведу четыре простых аргумента:
1. Экономия на разработке
Результат достигается с помощью принципов «бережливого производства». Огромные затраты приходятся на постоянные переделки из-за обобщенного представления о проекте.
Корректировка кода на этапе разработки или дизайн-макета по трудоемкости значительно больше, чем доработка прототипа. Таким образом, разработав наглядный прототип возможно снять значительную часть рисков.
2. Возможность презентации продукта до его разработки
С помощью интерактивного прототипа и дизайн-макета можно наглядно продемонстрировать суть проекта, его функции, визуальный концепт и то, как он будет работать. Наглядность презентации увеличивает шанс получить инвестиции на этапе нулевого MVP, т.е. еще до первой работающей версии.
3. Экономия на поддержке
Снижение затрат на поддержку продукта после его запуска - это положительное следствие предварительного проектирования. Безболезненное внедрение новых функций и планомерная доработка юзабилити достигается за счет формирования «дорожной карты».
4. Повышение лояльности пользователей
Мы в первую очередь разрабатываем IT-продукт для пользователя. Чтобы пользователи продолжали его использовать, он должен им понравиться, должен быть удобным, и должен выполнять свои функции. Совокупность данных факторов и системный подход к проектированию позволяет сделать IT-продукт успешным.
Предварительное проектирование позволяет получить более качественный и удобный IT-продукт, а также сэкономить на его разработке и поддержке.