В един от последните проекти, по който работя, екипът ни се сблъска с проблема на непрекъснатите искания за промени от страна на клиента.
Самият проект като идея е съвсем прост – потребителите се регистрират онлайн, за да могат да ползват дадена услуга. След регистрацията могат да настройват самата услуга, която е съвсем проста и не дава възможност за кой знае какви настройки.
В началото на проекта имахме ясна визия за крайния резултат и всички се радваха, че не създаваме уеб базирано приложение за проектиране и изстрелване на ракети.
Преминахме през обичайните фази на събиране на изисквания и специфициране. Реших да използвам доста подробен HTML прототип, за да специфицирам на приложението тъй като ставаше въпрос за представяне на няколко интерактивни процеса.
Прототипът беше разглеждан последователно от нашия екип и от екипа на клиента. Всеки имаше препоръка за подобрение.
В този момент нещата започнаха да се объркват.
Не успяхме да стигнем до единодушие кога трябва да престанем да внасяме промени в прототипа. Появиха се нови изисквания към системата. Едновременно се правеха промени от различен мащаб – от запетайки в текстовете до основополагащи принципи на бизнес логиката. Престанах да броя итерациите след 8 или 9 версия на прототипа.
Т.е. не успяхме да приключим етапа на спецификация.
Започнахме разработка преди да имаме знание за това какво точно трябва да представлява сайтът в крайна сметка. Започнахме да тестваме преди да сме приключили с разработката. В крайна сметка се принудихме да пуснем сайта преди да сме разработили и тествали поне нещо в завършен вид.
Което е най-малко желания начин за старт на нов продукт ever – има го, изглежда готово, но не работи.
Причините за това положение са различни, но от моята гледна точка една е много решаваща. Липсата на спецификации и едновременно с това непрекъснато, издуващия се като балон обхват на работата.
Как можехме да се спасим от това положение?
За времето, което ни отне създаването на първата версия на една изпипана отвсякъде система, можехме да създадем няколко версии – по-малко функционални, но напълно работещи, тествани и пуснати на вода.
За да използвам метафората с балоните – вместо да имаме един огромен и надут до пръсване балон (който в нашия случай се пръсна), трябваше да имаме няколко малки, умерено надути балони, всеки от които е проверен за слаби места и е 100% сигурно, че няма да се поддаде. Пък и някой балон от групата да гръмне винаги можеш да разчиташ на останалите.
Пускайте малки, но работещи продукти вместо големи и неработещи.
Leave a Reply