50% Software Developer

Не съм писал отдавна, бла-бла-бла, да не продължавам.

Гледайте сега, имаме при нас един юноша бледен, той се казва Гошко (примерно) и като чудо е software developer. За незапознатите, това означава, че пие много кафе и постоянно се цъкли в монитора.
Гошко е типичен програмист и един ден му идва поредната гениална идея за невероятен продукт, който ще избие рибата и ще му донесе много пари. И понеже Гошко е същинското клише за програмист просто сяда и започва да пише.
Няма да говоря за това, че Гошко не сяда да си направи дизайна на приложението, че не предвижда време за тестване и документиране и т.н., дори ще пропусна 3 месеца упорит труд и гениални програмистки решениея.
След тези 60 дни работа, Гошко продължава да седи пред компютъра с все по-разтревожен поглед. В крайна сметка той има приложение, което е трябвало да бъде готово преди 2 месеца и от тогава е завършено на 99% докато не му дойде на ум поредната изключително важна функционалност, без която продукта му няма да е завършен и той се хвърля да пише и нея.

До тук е ясно. Стигне ли се до този етап значи вече си яко в гъбите и трудно ще излезеш от там. Аз лично така си изгубих наистина много време за да получа един продукт, който имаше основата на космически кораб, а се нуждаех от парапланер.
Може би това е резултат от това, че и аз и Гошко работим сами и измежду многото неща започваме да губим фокус.

От известно време чета блога на Джоел Сполски (въобще така трябва да му се пише името), та там споменава нещо много интересно (четох го отдавна и не ми се търси точен линк).
Той предлага следното решение. Сядаш и се правиш списък с всички необходими според теб компоненти. Да речем, че са общо 100. От тях внимателно избираш 50-те най-важни и ги имплементираш.
Какво се получава. Имаш продукт за много по-малко време, но с половината функционалност, та той на практика е незавършен.
Това, което казва Джоел е, че всъщност въобще не е така. Пускайки продукта с половината от предвидената функционалност, всъщност е много хитър план да си спестиш време и да разбереш от какво потребителите наистина имат нужда. Все пак нали идеята е, че всяка програма прави по едно нещо, дори да вградят в MS Office възможност да прави кафе, той пак ще си е офис пакет и потребителите му ще го купуват заради именно тази му функция, а не заради кафето.
Примера, който се даваше в поста беше за Apple и това, че пуснаха iPhone без copy/paste. На пръв поглед това е нещо, без което нито един "компютър" не би могъл да се пусне. Но Apple го пуснаха. При това телефона си стана доста успешен без дори да има copy/paste, представяте ли си.
Както и да е, потребителите ревнаха, че си нямат възможност да копират и залепят, от Apple казаха "No problem" и при следващия релийз на софтуера за телефона им пуснаха тази функционалност. Елементарно.
Идеята да пуснеш само 50% от функциите е много проста, пускаш основните неща и когато някой клиент ревне "Ама няма ми го това ..." просто си отваряш списъчето, поглеждаш и си казваш "Аха, това хубаво съм го мислил, добре, ще го напиша" или пък "Брей, не съм се сетил за това". Така в крайна сметка пишеш наистина необходимите 80% функции и като бонус получаваш едно разтегляне на нещата във времето, което ти дава възможност да обмислиш всичко по-добре.
Просто се оказва доста трудно да започнеш нещо голямо и да го завършиш "на един дъх"

Когато аз попаднах в ситуацията на Гошко, направих нещо подобно, нацепих проекта на много по-малки подпроекти, набелязах им основната функционалност и започнах да ги правя едно по едно. В началото първия release беше само с един работещ компонент, всичко останало седеше на "to be implemented", но клиента беше доволен защото основния компонент беше готов и работеше, плюс това му бях обяснил, че нещата ще стават постепенно, а той редовно виждаше някакъв прогрес.
Разбира се тогава не бях чел статията на Джоел и не знаех какво точно правя, но се получи.

Да кажем, че смислените ми проекти се броят на пръстите на ръцете ми, интересно е по-experienced програмистите да кажат какво мислят по-въпроса.