Защо искането ми за разработка е било отхвърлено?

"Подал съм искане за разработка. Спазил съм всички изисквания за правилно описване на искането. Въпреки това, то е било отхвърлено. Виждам, че и други искания са били отхвърлени.

Защо?"

Оценка ползи/разходи (Cost/Benefit)

Ние разполагаме с много лимитирани ресурси за извършване на нови разработки. В същото време, ежедневно получаваме повече искания за разработка, отколкото можем да реализираме. Налага се една голяма част от исканията да бъдат отхвърлени. За да можем да правим и изпипваме прекрасните нови функционалности, които пускаме всяка година, е необходимо да се фокусираме върху относително малко неща.

Повечето искания са доста разумни, и действително биха добавили стойност към софтуера. Да, понякога получаваме и искания, които (почти) нямат отношение към софтуера. Но всъщност повечето искания са наистина доста добри! Ние също така искаме да ги реализираме, точно както и нашите клиенти и партньори искат. 

Но, в крайна сметка, е необходимо да изберем да реализираме само част от тези искания.

Ние реализираме разработките, които имат най-добро съотношение ползи/разходи.

 

Какво влияе на ползите и на разходите?

Критериите, на база на които установяваме ползи/разходи за всяка разработка са много. Ето някои от тях:

• Сложност на разработката.
  От по-сложните разработки определено можем да разработваме много по-малко. В същото време, ако има вариант дадена функционалност да бъде по-универсално направена, често това ще е нашият избор, даже и това да я прави по-сложна. Поради тази причина, редица разработки, които могат да имат просто решение, се нареждат "отзад на опашката" просто защото те могат да бъдат направени по-универсално (но пък по-сложно).
  
  
• Дали разработката е близка до идеите за бъдещо развитие на софтуера?
  Разработките, които са "близко" до идеите за бъдещо развитие на софтуера винаги имат предимство. Подобни разработки имат много по-добър шанс да влезнат "в унисон" с досегашни развития.
  За съжаление, макар да се опитваме, не винаги успяваме да поддържаме абсолютно актуална пътна карта. Поради тази причина, понякога тези причини не могат да бъдат предварително оценени от пускащия искането.
  Отделно от това, трябва да се има предвид, че близост до идеите за развитие не прави една разработка автоматично приета. Често, особено в началото на развитие на нов модул/функционалност, създаваме само минимално необходимата функционалност (MVP - minimum viable product).
  
  
• Потенциалният кръг от клиенти, които ще могат да я ползват.
  Естествено, предпочитаме максимално широк кръг клиенти да могат да се възползват от разработката. Колкото повече клиенти имаме, които са със сходна дейност на вашата, толкова по-вероятно е исканията ви да са по-популярни.
  
  
• Дали ще е лесна за възприемане и употреба?
  Трудните за употреба разработки се ползват значително по-малко от лесните. Това е прост факт, който често не се осъзнава в началото. Разработките изискващи сериозни настройки или с много дълбоки абстрактни дефиниции имат значително по-ниска използваемост от тези, които могат да се ползват директно.
  И да, това донякъде е в противоречие на правилото по-горе, че предпочитаме да реализираме универсални решения. Но точно такъв е и процеса на взимане на решения за разработките - понякога има противоречащи си изисквания.

 

Добре, но защо отхвърлени, а не отложени?

"Добре, всичко това е разбираемо, но защо разработката не се остави за в бъдеще? След няколко версии може и да и дойде времето. Защо е директно отхвърлена?"

Истината е, че ние имаме също така и лимитирани ресурси за обхващане и осмисляне на пълния набор искания, които се отправят към нас. За да можем по-добре да се фокусираме върху исканията, които има шанс да бъдат реализирани в обзоримото бъдеще, е необходимо да премахнем от списъка тези, които нямат шанс скоро да бъдат реализирани.

 

Защо точно моето искане е било отхвърлено?

"Добре, това е разбираемо. Но защо точно моето искане е било отхвърлено? Може ли детайлна обосновка?"

Отново въпрос на лимитирани ресурси и фокус върху значимото за нас. Когато отхвърляме дадена разработка, ние не само спестяваме времето за нейното реализиране. Ние спестяваме и времето за бизнес анализ. Истината е, че бизнес анализът може да отнеме голяма част от цялостното време за разработка.

Често преценката как една разработка може да бъде "вмъкната" в рамките на останалата част от системата, без да противоречи на никакви други функционалности е МНОГО сериозна задача. Не можем да си позволим да отделим това време за всяка разработка, особено за тези, които са отхвърлени.

 

Наистина ли всичко е загубено?

"Толкова време писах това искане, и сега то е отхвърлено. Наистина ли всичко е загубено и не е имало смисъл?"

И да, и не. Да, (най-вероятно) няма да реализираме точно тази разработка. Историята познава случаи и на обрат, но те са редки.

Обаче, в същото време, ние взимаме предвид всички искания за разработки, даже и отхвърлените. Когато проектираме нови функционалности (което може да е години след това), ние взимаме предвид всички искания, и се опитваме да ги вложим в новите си проекти.

Така че, даже и отхвърлено, всяко искане "живее в нас" и рано или късно отново може да про-има шанс да бъде реализирано.

Всъщност, МНОГО, наистина много от най-добрите ни универсални функции са направени така, че да покриват МНОГО от старите, но неизпълнени искания. 

Исканията се трупат във времето, и в някакъв момент, ние осъзнаваме, че можем да направим някаква универсална система, която да покрие голям брой искания. Може да мине много време, но когато я реализираме, ползите могат да са наистина големи.

Примерите за подобни системи, реализирани (след много време) на база разнообразни клиентски искания, са много - възможностите за нагласяне на изгледите, калкулираните атрибути, бизнес правилата и т.н.

 

Мога ли да си платя, за да бъде моята разработка реализирана?

С много малки изключения, най-вероятно отговорът е "не".

Колкото и да ни се иска да ви вземем парите за дадената разработка, тук дългосрочните цели за развитие на софтуера често са по-важни. Нашият бизнес модел включва взимане на фиксирани абонаменти за софтуера, а не пренасочване на развитието му в зависимост от това кой плаща най-много. Има много софтуери, които са видимо осакатени от трескавата смяна на посоките на развитие. И ние сме допускали подобни грешки, но се стараем да ги минимизираме.

Отделно от това, цялата ни организация е ориентирана към постигане на максимална ефективност на отделните задачи, а не към "прогонване" докрай на определени клиентски проекти. Т.е., ние не сме проектно-ориентирана организация (за разлика от нашите партньори, които работят директно с клиентите). Тази ни организация ни помага да постигнем максимална ефективност в нашия agile процес.

В същото време, решение може и да има. Често партньорите ни могат да предложат създаването на специфични разработки за вашия бизнес модел.