С използването на сайта вие приемате, че използваме „бисквитки" за подобряване на преживяването, персонализиране на съдържанието и рекламите, и анализиране на трафика. Вижте нашата политика за бисквитките и декларацията за поверителност. ОK
Регистрация

Най-често допусканите грешки в създаването на софтуерен продукт

Имайте ги предвид и ги следете, защото те не само могат да забавят работата ви, но и да ви струват значителна част от бюджета
Share Tweet Share
Снимка

[Shutterstock] 

Тази седмица в специализирания Кариерен клуб: Информационни и комуникационни технологии ни гостува Маргарита Антонова. Тя има над 7 години опит в разработката на софтуер за българския и американския пазар, работила е и като ръководител на не малко проекти (повече за нея в края на текста). В момента е и преподавател в "СофтУни", с чието съдействие публикуваме практичните й съвети за създаване на софтуерен продукт. Текстът е от специалист за специалисти и се надяваме да бъде полезен, като ви даде практични съвети и идеи, които да можете веднага да приложите в работното си ежедневие. Пишете ни на редакционния мейл: karieri@karieri.bg с идеи за други професионални теми, на които да обърнем внимание, за да ви бъдем максимално полезни.

Много от софтуерните разработчици, които избират да развиват собствен проект, достигат до извода, че програмирането е само половината труд. Това се дължи главно на сложната мрежа от нужди, които те трябва да покрият, ако искат крайният резултат да бъде успешен. Дали ще предпочетете да се захванете лично с това или не, трябва да познавате процесa и да следите за често допусканите грешки, които могат да забавят работата ви или да струват по-голямата част от делегирания за продукта бюджет. Ето шестте на-често срещани сред тях:

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

Софтуерните инженери са специализирани и високо платени експерти, като добрите сред тях са безценни, защото са изключително продуктивни, а опитът и уменията им са трудни за репродуциране. Тогава защо някой би губил времето на похватния си ресурс с каквото и да било друго, освен дейност, носеща дивиденти?

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

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

#2 Инвестиране в перфектното техническо решение
Друго олицетворение на губенето на ценното инженерно време е инвестирането в решение за всяка една функционална възможност (edge case) и оправянето на всеки един проблем (бъг). Някои технически лидери смятат, че софтуерът без бъгове и неясноти е единственият допустим софтуер на пазара. Представете си обаче, че в чат програмата, която сте направили, докато потребителят Мишо си пише с гаджето, спира тока точно когато той е натиснал "Прати", а като си пусне пак компютъра вижда, че съобщението му "емотикон с целувка" не е пратено и обвинява вас, разработчиците, че гаджето му се сърди, и въобще как може! Тоест, за да избегнете такъв любовен проблем в чат програма за забавление, трябва да вдигнете инфраструктура за местна памет, която в случай на липса на ток запазва последното съобщение и да направите автоматизиран процес за изпращане на това съобщение при следваща връзка с интернет. Дали си струва? С бъговете не е по-различно.

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

#3 Непознаване на основната група потребители
Притеснително често ми се случва да отварям сайтове на телефона си, който не са пригодени за по-малките тъч екрани на мобилните устройства. По-лошото е, че това често ми се случва със страници именно за забавление, като сайтове за ресторанти, барове, escape стаи и други подобни места. Следователно, за да успея да стигна до страницата с телефонния номер или картата на местоположението, аз разширявам и намалявам и местя и нагласям страници по малкия си екран - не особено добро изживяване за мен като потребител. Това показва, че хората направили или одобрили тези сайтове не са запознати с потребителите си, с това, че в тяхната възрастова група и парични възможности е много по-вероятно да имат смартфон и самите те са много по-склонни да търсят забавления на смартфон, а не на компютър.

Как да се справим: Ясната маркетингова стратегия започва с уточняване на таргет пазара, така че ползвайте маркетингови и пазарни ресурси, за да разберете повече за хората, който ползват софтуера ви, за да можете адекватно да отговорите на техните нужди.

#4 Софтуерът трябва да прави всичко
Познавайки таргет пазара си би ви помогнало да се справите с друг голям проблем в софтуерното развитие - бомбардирането на потребителя с функционалост. Истината обаче е, че не е необходимо софтуерните продукти да имат функция за всяка възможна дейност. Приложения като Uber, най-високо оценения start-up в Силициевата долина, например, предоставя възможност на потребителите си да намерят транспорт, но не всякакъв транспорт. Те не могат да си наемат автобус, самолет или лодка с Uber, могат само да се качат в автомобила на друг потребител. Това, че Uber работи с автомобили, обаче не значи, че потребителите могат да си продават или да си купуват коли в апликацията. Функционалността е една и е проста: свали си апликацията, за да можеш да ползваш или предоставяш транспортна услуга със собствения си автомобил. Сравнете това с например функционалностите на дистанционното за телевизора - 100 копчета, от който знаете, че ползвате само 3: увеличи, намали и връзка с HDMI. За вас като потребител останалите 97 копчета са ненужни, което в очите на бизнеса значи изгубено време в правене на функционалност, която никой не ползва.

Как да се справим: Lean философията и концепцията за MVP (Minimum viable product минимално жизнеспособен/приложим продукт) са добър пътеводител за избягването от риска от това да се хвърлят ресурси в производството на продукт без необходимост или използваемост на пазара. Lean учи, че продуктът трябва да представлява ясна концепция, която да се предостави на пазара, за да се тества нейната популярност, разбираемост, необходимост и др. Тази концепция трябва да е минимална, за да може да позволи ясен тест и да не е изсмукала много ресурси, за да не претърпим големи загуби, ако резултатът изисква пренаправа.

#5 Интерфейсът на софтуера не ме води, а ме затруднява
Независимо дали софтуерът ни е комплексен (като например ERP, enterprise resource planning, системите или програмите за обработване на снимки, филми, музика, документи) или минималистично приложение като Uber, неговото използване трябва да е достатъчно ясно за потребителя, за да може той да го използва пълноценно. Всички сме виждали менюта, които крият най-важната за нас функционалност или мобилни приложения с толкова много бутони, че едвам се събират на екрана, но не виждаме достатъчно такива, които да ни посочват какво да направим. Объркващия софтуер кара потребителите да се откажат от ползването му или им отнема твърде много време, което създава негативни настроения у потребителя (само питайте хората, които още си плащат сметките на място, защото "не могат да се оправят" със сайта на мобилния си оператор, електроснабдителното или банката си). Ако софтуерът е основна част от вашия бизнес, това може да доведе до загуба на клиенти или невъзможност за ползването им за обратна връзка или за рекламни цели.

Как да се справим: Интерфейсът е средството за комуникация с потребителите. Следователно той трябва да е на език, който потребителите разбират. Инвестирайте в дизайнери на използваем интерфейс (UX) и не забравяйте, че понякога по-малкото и по-лесното е повече.

#6 Липса на експерти на входа и на изхода
Качеството на софтуерния продукт зависи освен от качествения код, и от ясните и добре разписани изисквания какво трябва този код да изпълнява, както и от пълноценната проверка, че написаният код отговаря на тези изисквания и е сработен в останалата част от софтуерната система. Професията бизнес анализатор, както понякога и продуктов ръководител (product manager, product owner), са отговорни за това да разберат бизнес нуждата и да я опишат в кратки и ясни изисквания, по които инженерите могат лесно да работят. Инженерите по качество (QA или QE) пък са хората, които правят пълната проверка на софтуера и създават една функционалност като завършена, ако качеството й спрямо изисквания и стабилност го позволяват. За съжаление все още има фирми, които мислят, че могат да са конкурентоспособни без обособени роли на бизнес анализатор и инженер по качеството. За съжаление тези икономии често водят до липса на ефективност и познания при изпълняването на софтуерни задачи.

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

Правенето на качествен софтуер има своите разнообразни трудности: от писането на бързи SQL заявки, до разбирането на маркетинговите данни и измислянето на интуитивен потребителски интерфейс. Лесно е да се направят грешки, но още по-лесно е да се подобрят софтуерните продукти и процеси благодарения на тези грешки, особено когато писането на код ни предоставя необятните си възможности да променяме света апликация по апликация.
Снимка

[Личен архив / Twitter] 

Маргарита Антонова е продуктов ръководител в стартъпа Taulia, базиран във Сан Франциско и специализиран в областта на финансовите технологии. Има над седем години опит в разработката на софтуер за българския и американския пазар. Работила е като продуктов ръководител в Telerik, сега Progress. В момента води и обучението "Business Skills for Developers" в СофтУни.


Share Tweet Share
още от тази рубрика:

Реклама

Реклама

© 2003-2019 Икономедиа АД съгласно Общи условия за ползване. Политика за бисквитките. Декларация за поверителност.
Общи условия за публикуване на обява ново.
Поставянето на връзки към материали в сайтовете на Икономедиа е свободно. Уеб разработка и дизайн на Икономедиа. Сайтът използва графични елементи от famfamfam + DryIcons. Някои снимки © 2019 Associated Press и Reuters. Всички права запазени.
Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов.
mobile Към мобилната версия на сайта

Бизнес: КапиталКариериБизнесРегалОдитFoton.bg

Новини: ДневникЕвропа

IT: IDG.BGComputerworldPC WorldCIONetworkworld

Развлечение: БакхусLIGHT

На английски: KQuarterly