Како да изаберете тим за развој софтвера

Шта треба да разјасните након неуспешног пројекта?

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

Немојте претпоставити да је проблем само у програмирању. Неуспешан пројекат често почиње нејасним захтевом, променљивим захтевима, недостатком особе на страни клијента или обећањем фиксног рока без довољно информација. Понекад је код добар, али нема интеграције са рачуноводством, магацин не одражава стварни рад или запослени не могу да користе систем.

Припремите списак конкретних питања: Шта се променило током првог пројекта? Ко је одобравао одлуке? Како су функције прихватане? Када сте схватили да рок неће бити испоштован? Да ли сте имали приступ коду и подацима? Да ли су постојали тестно окружење и резервне копије?

Која питања да поставите потенцијалном тиму?

Први састанак не треба да буде само презентација портфолија. Треба да покаже како тим размишља. Дајте му опис процеса који желите да побољшате, а не само списак дугмади и екрана.

• Које делове процеса бисте истражили пре него што предложите технологију?
• Како ћете поделити пројекат на фазе које могу да се тестирају и прихвате?
• Које ризике видите већ сада и како ћете их проверити?
• Ко ће бити моја стална контакт особа и ко доноси техничке одлуке?
• Како ћете поступити ако се током развоја испостави да је одређена функција сложенија него што се очекивало?
• Шта добијам приликом предаје: код, базу података, документацију, приступе и упутства?
• Како се обрађују грешке након пуштања система у рад?

Добар одговор није нужно најтехничкији. Ако тим говори само о програмском језику и дизајну, а не пита за улоге, одобрења, фактуре, магацин, API и стварне кориснике, вероватно још не разуме задатак.

Како да проверите искуство и портфолио?

Погледајте портфолио, али се немојте задржати на лепим почетним страницама. Тражите пројекте са сличном логиком: управљање захтевима, улоге и дозволе, управљање документима, мобилни тимови, плаћања, магацин, аутоматско фактурисање или повезивање више система.

На пример, LiftexPro — ERP за компаније за лифтове обједињује планирање прегледа, управљање зградама, мобилну апликацију за техничаре и аутоматско фактурисање. То више говори о тиму који треба да изгради пословни систем него опште обећање о „јединственој платформи“.

За процесе на терену погледајте и Ековат — ERP по поруџбини, где су повезани захтеви, радни налози, возни парк, магацин и документи. Питање није да ли је пројекат из Ваше делатности. Питање је да ли је тим решавао проблеме сличне сложености.

Затражите демонстрацију функционалног система, а не само слике. У демонстрацији ERP-а за међународни транспорт могу се видети туре, возачи, возни парк, клијенти, фактуре, трошкови и различити прикази за улоге у компанији. Тако можете да процените да ли добављач приказује стварну логику или само визуелни концепт.

Питајте који део приказаног представља готов производ, а који је развијен посебно за конкретног клијента. Затражите објашњење Ваше улоге, коришћених интеграција и ограничења. Немојте туђе резултате прихватати као доказ ако тим не може да објасни свој рад на пројекту.

Како да процените технички приступ?

Технички приступ треба да полази од процеса и података. За CRM се, на пример, описују клијенти, послови, понуде, задаци, историја комуникације и дозволе запослених. За ERP се прецизирају магацин, продаја, фактуре, извештаји, улоге и везе са другим системима.

Затражите шему главних модула и тока података. Ако онлајн продавница прими поруџбину, како она стиже до магацина? Када се креира товарни лист? Како се евидентира плаћање? Шта види рачуновођа? Ако нема јасног одговора, проблем ће се касније појавити као ручни рад и грешке.

Проверите како се планирају интеграције. API веза са куриром, платним оператором, телефонијом или рачуноводственим програмом није само ставка у понуди. Треба прецизирати податке, учесталост синхронизације, грешке, поновно слање и ко ће надзирати везу.

Питајте за тестно окружење, резервне копије, логове, права приступа и начин објављивања измена. Код система са личним подацима размотрите ко има приступ, како се бележе радње и како се рад обнавља у случају проблема.

Како да сазнате да ли ће комуникација функционисати?

Комуникација се не мери тиме колико брзо тим одговара пре потписивања. Проверите како ћете радити након почетка пројекта. Да ли ће бити недељног састанка? Где ће се бележити задаци? Како ћете одобравати дизајн, процес и готову функцију? Како ћете видети шта је планирано, а шта блокирано?

Одредите особу са Ваше стране која познаје пословање и може да доноси одлуке. Ако сваки запослени програмерима директно даје различита упутства, пројекат ће се распасти на више страна. Нови тим треба да има један јасан канал за захтеве и измене.

Затражите пример извештаја о раду. Добар извештај показује шта је завршено, шта предстоји, која питања чекају на решење и шта утиче на рок. То је корисније од опште поруке да „пројекат напредује“.

Како да упоредите рокове и буџет?

Не упоређујте само коначне износе. Упоредите шта стоји иза њих. Једна понуда може да обухвата анализу, дизајн, развој, миграцију података, тестирање, обуку, објављивање и одржавање. Друга може да обухвата само програмирање.

За израду софтвера по наруџбини измерени оквир понуде износи 3.000–29.300 €. Оно што ће Вам понудити у овом оквиру зависи од броја модула, сложености улога, миграције података, мобилне апликације, интеграција, тестирања и потребе за сталним одржавањем. Не упоређујте доњу границу једне понуде са пуним обимом друге.

Рок такође треба да буде повезан са резултатом. Уместо „готово за кратко време“, затражите план са фазама, зависностима и условима за одобрење. Ако Ви одложите приступ, садржај или доношење одлуке, рок треба да се мења на транспарентан начин.

Како треба да изгледа процес рада?

1. 01
   Ревизија старог пројекта

   Прегледате постојећи код, базу података, приступе, документацију и функције које нису реализоване. Нови тим описује који делови могу да се користе, а које је безбедније прерадити.

2. 02
   Опис стварног процеса

   Објашњавате како раде продаја, магацин, рачуноводство, теренски радници и управник. Тим тај процес преводи у улоге, стања, податке, обавештења и интеграције.

3. 03
   Пилотни обим

   Бирате важан, али ограничен део система. Он треба да прође кроз стварни сценарио и покаже да ли су решења практична за људе који ће их користити.

4. 04
   Прихватање по фазама

   За сваку функцију одређујете шта значи да је „готова“. Тестирате је са конкретним подацима, бележите запажања и раздвајате грешке од нових идеја.

5. 05
   Пуштање у рад и обука

   Планирате миграцију, права приступа, резервне копије, обуку и период надгледања. Не заустављајте стари начин рада пре него што знате како ћете поступити у случају проблема.

6. 06
   Одржавање и развој

   Договарате канал за захтеве, приоритете, реакцију у случају грешака, ажурирања и цену додатних измена. Тако следећа фаза не почиње новом потрагом за добављачем.

Како да избегнете понављање старих грешака?

Укључите кориснике још пре почетка развоја. Запослени у складишту, диспечер и рачуновођа виде другачије проблеме од управника. Кратка демонстрација са њиховим стварним сценаријем може открити пропуст који дугачак списак захтева не показује.

Не мењајте стално циљ без процене последица. Нова функција може да утиче на базу података, улоге, API везе и рок. Сваки проширени обухват мора да има опис, цену и утицај на распоред.

Не остављајте све на усменим разговорима. Записујте одлуке, одобрења и одговорности. Уговором прецизирајте власништво над кодом, приступ хостингу и бази података, поверљивост, прихватање и услове раскида.

На крају проверите како изгледа одржавање након пуштања у рад. За постојећи сајт или систем оно може да обухвата ажурирања, резервне копије, провере и мање измене; код сложенијег ERP или CRM система биће потребни надзор интеграција, управљање корисницима и развој функционалности.

Који је добар избор након неуспешног пројекта?

Прави тим није онај који обећава најбрже и најјефтиније. Он поставља питања о вашем пословању, показује сличне системе, објашњава ограничења и дели велики ризик на мала решења која се могу проверити.

Пре него што потпишете, треба да знате ко ради на пројекту, шта ћете добити у свакој фази, како се функције прихватају, шта се дешава са кодом и подацима и коме се обраћате у случају проблема. Ако су ови одговори јасни од самог почетка, вероватноћа да поновите стари сценарио знатно је мања.