Как да изберете екип за разработка на софтуер

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

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

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

Подгответе списък с конкретни въпроси: Какво се промени по време на първия проект? Кой одобряваше решенията? Как се приемаха функциите? Кога разбрахте, че срокът няма да бъде спазен? Имахте ли достъп до кода и данните? Имаше ли тестова среда и резервни копия?

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

Първата среща не трябва да бъде презентация само на портфолио. Тя трябва да покаже как екипът мисли. Дайте му описание на процеса, който искате да подобрите, а не само списък с бутони и екрани.

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

Добрият отговор не е задължително най-техническият. Ако екипът говори само за език за програмиране и дизайн, без да пита за роли, одобрения, фактури, склад, 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 система ще са нужни наблюдение на интеграциите, управление на потребители и развитие на функционалността.

Какъв е добрият избор след неуспешен проект?

Правилният екип не е този, който обещава най-бързо и най-евтино. Той задава въпроси за Вашата работа, показва сходни системи, обяснява ограниченията и разделя големия риск на малки проверими решения.

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