Успешно разработване на софтуерни продукти Няколко съвета
Успешно разработване на софтуерни продукти: Няколко съвета
Пазарът на софтуерни услуги като внедряване, персонализирано програмиране и поддръжка се измества все повече в областта на софтуерните продукти. Така че решения, които трябва да инсталирате само и за които не се изисква сериозно развитие.
Най-добрият пример са решенията за софтуер като услуга, за които можете да се абонирате ежемесечно.
Предимствата на такива решения са очевидни, по-ниски разходи за поддръжка, тъй като актуализациите се импортират автоматично, а също и по-малко грешки, тъй като те са фиксирани от доставчика. И разбира се по-малко разходи за скъпи програмисти.
Как обаче може да се разработи такъв софтуер за в бъдеще, който да замести предишните ИТ услуги? Няколко съвета за това в публикацията.
Не бързайте
За съжаление повечето проекти започват с изявлението „Това е много голям проект. Но не бързайте. Нямаме нужда от завършената версия за два месеца ".
Реалността обаче е, че особено при сложни софтуерни решения ни трябват няколко дни и седмици, само за да определим изискванията.
Тогава телените рамки и създаването на дизайни изискват допълнителни усилия.
Има и константа напред-назад. Било то между клиента и доставчика на услуги, или ако сте го програмирали вътрешно, то между ръководството и разработчиците. Изискванията трябва да бъдат сравнени, заявките за промяна да бъдат взети предвид и грешките (грешки в системата) да бъдат премахнати.
За да имате първа бета версия на софтуерен продукт, винаги са необходими поне 9 до 12 месеца.
След пускането на живо обикновено получавате първата обратна връзка, където забелязвате „О, пренебрегнахме тази важна функционалност“ или „О, още не я бяхме тествали в тази форма“. За тези по-малки до по-големи функционалности и тестването ви трябват 6 до 8 месеца.
Така че бързо се нуждаете от една до две години, за да създадете продукта.
Особеното обаче е, че ще имате решение, което предоставя на крайния клиент реална добавена стойност. И за това е цялото това упражнение. Предоставянето на ИТ решение, което може да добави стойност за клиента, което отнема само два месеца, е нереалистично.
Силна технологична база/правилният избор
Важен е и технологичният подход.
Някои технологии вече са зрели и след като сте програмирани, можете да ги използвате дълго време без промени или актуализации.
Един пример е PHP. Тази ИТ система съществува от 1995 г. и оттогава непрекъснато се подобрява.
Рамките, базирани на PHP, също са тествани и широко използвани. Програмистите са запознати с проблеми, предизвикателства и начини за отстраняване на грешки.
При другите подходи изглежда различно. Например, ако програмирате с Node.JS (също съкратено като N в тази статия), можете да предположите, че ще трябва да отделите допълнително време, за да разберете как да решите конкретна задача за програмиране с Node.JS.
В същото време, в сравнение с PHP, има само няколко специалисти и малко точки за контакт (форуми, блогове, платформи за въпроси и др.), Където можете да получите информация за Node и да получите отговори на въпроси.
Освен това продължават да излизат нови версии на Node, някои от които не са обратно съвместими, което основно означава, че някои от съществуващия софтуер трябва да бъдат препрограмирани от нулата.
Усилието е по-високо с N. Но можете да се възползвате от по-бързите приложения и по-добрата мащабируемост.
Така че в ИТ всичко има своите предимства и недостатъци. В крайна сметка зависи и от това какви са изискванията.
За средни проекти (например корпоративни решения, които са необходими на управляем брой потребители) PHP може да бъде правилното решение.
За големи проекти, при които много потребители имат достъп до едно и също решение по интернет едновременно, N може да е правилният подход.
ASP.NET, Java, Python, Android, iOS са други подходи, които могат да работят в някои случаи.
Съхранявайте документация
Едно от най-големите предизвикателства при софтуерните проекти е тяхната поддръжка и приемственост.
Често бъдещето не се разглежда. Въпроси като:
- Ами ако други разработчици трябва да работят по този продукт?
- Колко разбираема е логиката на разработката за външен доставчик на услуги?
- Как реагира програмирането на външни промени, които могат да се случат в бъдеще?
На всичко това може да се отговори положително, ако има коментар на код и документ с инструкции за бъдещи колеги, които ще работят по него.
В този подробен документ, който непрекъснато се актуализира от разработчиците, в бъдеще могат да се правят и допълнителни промени със снимки на екрани, код за програмиране на редове, описания, обяснение на логиката зад определен модул.
Реалността в наши дни обаче все още изглежда така, че просто "програмирането продължава" и програмистите или новите членове на екипа, които се присъединят, вече не са в настроение да продължат да работят по старото решение и след това автоматично да предлагат нова платформа от нулата.
По този начин подробната и добра документация на предишната работа е от решаващо значение за поддържане, мащабируемост и добри софтуерни продукти.
Плащане на клиенти още от самото начало
Също така е важно проектът да не се превърне в бездънна яма. Поне разходите трябва да бъдат покрити.
Тук трябва да намерите клиенти, които извършват плащанията за програмирането.
Това има много предимства:
- Ако външно лице или компания наистина са готови да вземат парите, вече знаете, че сте на правилната лодка. Тъй като външна компания вдига бюджет само ако вижда предимство в дългосрочен план (повишена ефективност, спестяване на време в процесите, намаляване на разходите и т.н.).
- Получавате обратна връзка от самото начало и знаете дали това са полезни функционалности, които разработвате. Тази постоянна обратна връзка по-специално гарантира, че софтуерният продукт приема правилната форма и че не се разработвате въз основа на предположения.
Алтернатива 1: ангелски инвеститори/инвеститори
Другата алтернатива е да се работи с инвеститори.
През повечето време трябва да платите поне прототипа от собствения си джоб.
За да имате достъпна версия, може да се създаде само най-важната функционалност, а останалите могат да бъдат фиктивни фиктивни функционалности.
След това можете да представите това на инвеститорите.
Това също е доказателство за концепцията: Ако намерите хора, които са готови да вземат пари в ръцете си за подкрепа, това е първа индикация, че сте на прав път.
Алтернатива 2: от съществуващите доходи
Много компании и услуги вече генерират излишък. Това може да се използва и за финансиране на софтуерните разходи.
Алтернатива 3: собствени пари
Това е може би най-лошата идея, която някой може да има. Използването на спестени пари за развитие обикновено не е добър подход.
Тъй като бюджетът се изразходва твърде бързо и вие също ще се колебаете да правите по-големи разходи наведнъж.
И ако целият проект не е успешен, тогава парите са изразходвани.
Затова по-скоро разчитайте на алтернативите, споменати в началото.
За да го закръглите: Система за поддръжка
Система за поддръжка завършва цялото нещо. Тъй като потребителите искат да дадат отзивите си и да решат проблемите и въпросите си със системата.
В същото време тази поддръжка може също така да ви даде знания за това как да подобрите софтуерния продукт.
И тогава е фактът, че можете да изградите своеобразен отдел продажби за тези, които питат, които все още не плащат на клиенти.
Заключение
Основните области за успешен софтуер са:
- вдигнете необходимото време
- използвайте правилната технология
- Съхранявайте документация
- Намерете плащащите клиенти още от самото начало или разчитайте на инвеститори (алтернативно, финансирайте от съществуващи приходи от друг бизнес)
- Вградете система за поддръжка и предварителни продажби
Какви други точки виждате в разработването на софтуерни продукти?
Flickr.com/ GDC/Jeremy/thetreesisters
Авторът: Саша Татил работи в YUHIRO и помага на предприемачите и компаниите лесно да създадат екипи по програмиране в Индия. YUHIRO е германско-индийска компания, която предоставя на ИТ компании, агенции и ИТ отдели разработчици на софтуер.