Како да изберете тим за развој на софтвер
По неуспешен софтверски проект не е доволно да најдете друга фирма. Треба да разберете зошто првиот тим ја промашил целта и да изберете партнер што може да покаже како ќе ги избегне истите грешки. Проверете го неговото искуство со слични процеси, побарајте конкретен план, прецизирајте кој е одговорен и договорете како ќе го прифаќате секој дел од системот.
Што треба да разјасните по неуспешниот проект?
Започнете со кратка внатрешна анализа. Соберете ги договорот, понудата, техничката документација, пристапите, кодот, дизајните и списокот со ветените функции. Забележете што навистина функционира, што недостасува и што веќе не одговара на Вашите процеси.
Не претпоставувајте дека проблемот е само во програмирањето. Неуспешниот проект често започнува со нејасна задача, променливи барања, недостиг од лице од страна на клиентот или ветување за фиксен рок без доволно информации. Понекогаш кодот е добар, но нема интеграција со сметководството, магацинот не ја одразува реалната работа или вработените не можат да го користат системот.
Подгответе список со конкретни прашања: Што се промени за време на првиот проект? Кој ги одобруваше одлуките? Како се прифаќаа функциите? Кога сфативте дека рокот нема да биде испочитуван? Дали имавте пристап до кодот и податоците? Имаше ли тестна средина и резервни копии?
Кои прашања да му ги поставите на потенцијалниот тим?
Првата средба не треба да биде само презентација на портфолио. Таа треба да покаже како размислува тимот. Дајте му опис на процесот што сакате да го подобрите, а не само список со копчиња и екрани.
- Кои делови од процесот би ги истражиле пред да предложите технологија?
- Како ќе го поделите проектот на фази што можат да се тестираат и прифатат?
- Кои ризици ги гледате уште сега и како ќе ги проверите?
- Кој ќе биде мојот постојан контакт и кој ги носи техничките одлуки?
- Како ќе постапите ако за време на развојот се покаже дека одредена функција е посложена од очекуваното?
- Што добивам при предавањето: код, база на податоци, документација, пристапи и упатства?
- Како се обработуваат грешките по пуштањето на системот?
Добриот одговор не мора да биде најтехничкиот. Ако тимот зборува само за програмски јазик и дизајн, без да праша за улоги, одобрувања, фактури, магацин, API и реални корисници, веројатно сè уште не ја разбира задачата.
Како да ги проверите искуството и портфолиото?
Разгледајте го портфолиото, но не застанувајте кај убавите почетни страници. Барајте проекти со слична логика: управување со барања, улоги и права, тек на документи, мобилни тимови, плаќања, магацин, автоматско фактурирање или поврзување на повеќе системи.
На пример, LiftexPro — ERP за лифтовски компании комбинира планирање прегледи, управување со згради, мобилна апликација за техничари и автоматско фактурирање. Ова е посигурен показател за тим што треба да изгради деловен систем отколку општо ветување за „уникатна платформа“.
За процеси на терен разгледајте го и Ековат — ERP по нарачка, каде што се поврзани барања, работни налози, возен парк, магацин и документи. Прашањето не е дали проектот е од Вашата индустрија. Прашањето е дали тимот решавал проблеми со слична сложеност.
Побарајте да видите демонстрација на функционален систем, а не само слики. Во демото на ERP за меѓународен транспорт можат да се видат курсеви, возачи, возен парк, клиенти, фактури, трошоци и различни прикази за улогите во компанијата. Така ќе разберете дали добавувачот прикажува реална логика или само визуелен концепт.
Прашајте кој дел од прикажаното е готов производ, а кој дел е развиен специјално за конкретниот клиент. Побарајте објаснување за Вашата улога, користените интеграции и ограничувањата. Не прифаќајте туѓи резултати како доказ ако тимот не може да ја објасни својата работа на проектот.
Како да го оцените техничкиот пристап?
Техничкиот пристап треба да започне од процесот и податоците. За CRM, на пример, се опишуваат клиентите, зделките, понудите, задачите, историјата на комуникацијата и правата на вработените. За ERP се прецизираат магацинот, продажбите, фактурите, извештаите, улогите и врските со други системи.
Побарајте шема на главните модули и текот на податоците. Ако онлајн продавницата прими нарачка, како таа стигнува до магацинот? Кога се создава товарен лист? Како се евидентира плаќањето? Што гледа сметководителот? Ако нема јасен одговор, проблемот подоцна ќе се појави како рачна работа и грешки.
Проверете како се планираат интеграциите. API врска со курир, платежен оператор, телефонија или сметководствена програма не е само ставка во понудата. Треба да се прецизираат податоците, фреквенцијата на синхронизација, грешките, повторното испраќање и кој ќе ја следи врската.
Прашајте за тестна средина, резервни копии, логови, права за пристап и начинот на објавување на промените. Кај систем со лични податоци разговарајте кој има пристап, како се запишуваат дејствата и како се обновува работата при проблем.
Како да разберете дали комуникацијата ќе функционира?
Комуникацијата не се мери според тоа колку брзо тимот одговара пред потпишувањето. Проверете како ќе работите по започнувањето. Ќе има ли неделен состанок? Каде ќе се запишуваат задачите? Како ќе одобрувате дизајн, процес и завршена функција? Како ќе гледате што е планирано, а што е блокирано?
Назначете лице од Ваша страна што го познава бизнисот и може да носи одлуки. Ако секој вработен им дава различни упатства директно на програмерите, проектот ќе се распрсне. Новиот тим треба да има еден јасен канал за барања и промени.
Побарајте примерен извештај за работата. Добриот извештај покажува што е завршено, што следува, кои прашања чекаат решение и што влијае врз рокот. Тоа е покорисно од општа порака дека „проектот се одвива“.
Како да ги споредите роковите и буџетот?
Не споредувајте ги само крајните износи. Споредете што стои зад нив. Една понуда може да вклучува анализа, дизајн, развој, миграција на податоци, тестирање, обука, објавување и поддршка. Друга може да вклучува само програмирање.
| Што да споредите | Прашање до тимот | Ризик ако нема одговор |
|---|---|---|
| Опфат | Кои функции се вклучени, а кои се надвор од понудата? | Нови трошоци и спорови во текот на проектот |
| Фази | Што ќе добиеме и прифатиме во секоја фаза? | Чекате до крајот за да ги видите проблемите |
| Податоци | Кој ги префрла старите клиенти, производи и документи? | Губење информации или рачно внесување |
| Интеграции | Кои API врски се вклучени и како се тестираат? | Системот не разменува сигурно податоци |
| Поддршка | Како се пријавуваат грешки и што е надвор од месечната услуга? | Нема јасен одговор при итен проблем |
| Сопственост | Каде се чуваат кодот, податоците и пристапите? | Зависност од добавувачот |
За изработка на софтвер по нарачка, измерениот опсег на понудата е 3.000–29.300 €. Што ќе Ви понудат во овој опсег зависи од бројот на модули, сложеноста на улогите, миграцијата на податоци, мобилната апликација, интеграциите, тестирањето и потребата од непрекината поддршка. Не ја споредувајте долната граница на една понуда со целосниот опфат на друга.
Рокот исто така треба да биде поврзан со резултат. Наместо „готово за кратко време“, побарајте распоред со фази, зависности и услови за одобрување. Ако Вие го одложите пристапот, содржината или одлуката, рокот треба да се менува на транспарентен начин.
Како треба да изгледа работниот процес?
- 01Аудит на стариот проект
Ги прегледувате достапниот код, базата на податоци, пристапите, документацијата и недовршените функции. Новиот тим опишува кои делови може да се искористат, а кои е побезбедно да се преработат.
- 02Опис на реалниот процес
Раскажувате како функционираат продажбата, магацинот, сметководството, теренските вработени и управителот. Тимот го претвора овој процес во улоги, состојби, податоци, известувања и интеграции.
- 03Пилотен опфат
Избирате важен, но ограничен дел од системот. Тој треба да помине низ реално сценарио и да покаже дали решенијата се практични за луѓето што ќе ги користат.
- 04Прифаќање по фази
За секоја функција определувате што значи „готова“. Ја тестирате со конкретни податоци, ги запишувате забелешките и ги одделувате дефектите од новите идеи.
- 05Пуштање во употреба и обука
Ја планирате миграцијата, правата, резервните копии, обуката и периодот на следење. Не ја прекинувајте старата работа пред да знаете како ќе постапите при проблем.
- 06Поддршка и развој
Утврдувате канал за барања, приоритети, реакција при грешки, ажурирања и цена на дополнителните промени. Така следната фаза не започнува со ново барање добавувач.
Како да избегнете повторување на старите грешки?
Вклучете ги корисниците уште пред развојот. Вработениот во магацинот, диспечерот и сметководителот гледаат различни проблеми од управителот. Кратка демонстрација со нивно реално сценарио може да открие пропуст што долг список со барања не го покажува.
Не ја менувајте постојано целта без проценка на последиците. Новата функција може да влијае на базата на податоци, улогите, API врските и рокот. Секој проширен опфат треба да има опис, цена и влијание врз распоредот.
Не оставајте сè на усни разговори. Запишувајте ги одлуките, одобрувањата и одговорностите. Во договорот прецизирајте ја сопственоста врз кодот, пристапот до хостингот и базата на податоци, доверливоста, прифаќањето и условите за раскинување.
На крајот проверете како изгледа одржувањето по пуштањето. За постоечка веб-страница или систем тоа може да вклучува ажурирања, резервни копии, проверки и мали промени; кај посложен ERP или CRM систем ќе бидат потребни следење на интеграциите, управување со корисници и развој на функционалноста.
Кој е добриот избор по неуспешен проект?
Вистинскиот тим не е оној што ветува најбрзо и најевтино. Тој поставува прашања за вашата работа, покажува слични системи, ги објаснува ограничувањата и го дели големиот ризик на мали решенија што можат да се проверат.
Пред да потпишете, треба да знаете кој работи на проектот, што ќе добиете во секоја фаза, како се прифаќаат функциите, што се случува со кодот и податоците и кому да му се обратите при проблем. Ако овие одговори се јасни уште на почетокот, веројатноста да го повторите старото сценарио е значително помала.
Често поставувани прашања
- Како да разберам дали софтверската фирма има вистинско искуство?
- Побарајте слични проекти, демонстрација на функционален систем и објаснување како тимот решил конкретен деловен проблем. Портфолио само со слики од дизајни не докажува искуство со интеграции, улоги, податоци и одржување.
- Што да направам со кодот од неуспешниот проект?
- Направете технички аудит пред да одлучите дали кодот ќе се користи. Се проверуваат архитектурата, безбедноста, базата на податоци, документацијата, пристапите и можноста друг тим да го одржува системот.
- Како се одредува цената на софтвер по нарачка?
- Цената зависи од опфатот, бројот на модули, улогите, интеграциите, миграцијата на податоци, мобилните апликации, тестирањето и одржувањето. Споредувајте не само со крајната понуда, туку и со тоа што е вклучено во секоја фаза.
- Како да го контролирам рокот за развој?
- Договорете фази со конкретен резултат и критериуми за прифаќање. Следете ги зависностите, одложените одлуки и промените во опфатот, бидејќи тие директно влијаат врз распоредот.
- Кој треба да учествува од страна на клиентот?
- Определете едно лице што ги познава процесите и може да носи одлуки. Во клучните демонстрации вклучете ги и вработените што секојдневно ќе работат со системот.
