Русские документы
Ежедневные компьютерные новости RSS rusdoc.ru  Найти :
http://www.rusdoc.ru. Версия для печати.

Про бесполезность длительного проектирования

Раздел: Programming / Управление проектами @ 07.11.2010 | Ключевые слова:

Автор: s0rr0w
Источник: habrahabr

imageПорядка 95% компаний, а может даже больше, используют классическую схему разработки: обязательное проектирование, разработка, тестирование, внедрение. Оценить, хорошо это или плохо, можно только попробовав что-то другое. Я попробовал, и эта статья будет сугубо про мой практический опыт.

Сказка про то, как мы биллинг проектировали


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


Мы сели проектировать. Это было самой главной нашей ошибкой. Была взята реальная модель взаимоотношений и все объекты из этой модели: договора, дополнительные соглашения, счета на оплату, услуги, рабочие места. С этим мы определились довольно быстро, и перешли к описанию поведения системы в идеальных условиях. Вроде никаких проблем не возникло. Сложности начались при рассмотрении исключений из правил. С каждым новым исключением возникало все больше и больше проблем. Наша модель трещала по швам, и мы возвращались к некоторым местам вновь и вновь. Время шло, результат был, мягко скажем, не очень, поэтому решили реализовать то, что мы уже придумали. Теплилась надежда, что в процессе реализации мы найдем какой-то компромис.

А потом было тестирование на основателе компании. Его слова повергли меня в шок: «Это работать не будет и надо переделывать». Недоумение долго не покидало меня. Мы спроектировали неплохую систему, которая оперировала знакомыми продажникам объектами и терминами, но мы слишком ее идеализировали, упустив из виду тот факт, что в реальной жизни все будет невыносимо сложнее. Нужно было упрощать все настолько, насколько это можно было упростить.

Первая версия «биллинга» так и не увидела свет. Вторая была спроектирована примерно за день и работает до сих пор почти в неизменном виде. Вы можете возразить, что время на проектирование первой версии не учитывается во второй, а по идее должно. Но если бы вы могли увидеть реальный результат, то поняли, что проект первой версии можно было без зазрения совести выкинуть в мусорку. Это было время, которое потрачено почти впустую.

Затраты на проектирование


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

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


Прототипы решили большинство проблем с проектированием. Вы можете сделать 80% некого функционала и понять, что сделали всего 40%, что нужно переделывать и способ хранения данных, и интерфейс, и еще пару дополнительных модулей впридачу. Вы еще не приступили к финальной реализации, а уже знаете, что вектор разработки нужно менять. Вы бы смогли ответить на эти вопросы на стадии проектирования? Возможно, но скорее всего нет. Вы не поймете свою ошибку ровно до того момента, пока не реализуете то, что спроектировали. Только вот стоимость вашей ошибки будет неизменно дороже.

Прототип можно показывать заказчикам и смотреть на их реакцию. Его можно спокойно использовать в юзабилити тестировании. Можно много всякого делать имея прототип, чего не скажешь про результат проектирования.

В процессе прототипирования у нас накапливаются мутации интерфейса и кода. Самые успешные решения мы переносим на все остальные части продукта. Прототипы гораздо быстрее выявляют проблемы конечной реализации.

Финансовая выгода от прототипирования


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

Успешного вам бизнеса!


Вернуться в раздел: Programming / Управление проектами
© Copyright 1998-2012 Александр Томов. All rights reserved.