Как избира софтуерна компания един нетехнически изпълнителен директор

Изпълнителният директор не трябва да оценява редове код. Той трябва да прецени дали доставчикът разбира бизнес проблема, може да превърне неяснотата в ясен обхват и разполага със система за доставка, която намалява риска.

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

Започнете от бизнес резултата

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

Избягвайте да започвате с дълъг списък от функции. Функциите са възможни решения. Резултатът е причината, поради която инвестирате. Добрият партньор ще ви помогне да свържете всяка ключова функция с потребител, проблем и измерима цел. Ако въпросът е конкретно за CRM, вижте първо дали ви подхожда готово или персонализирано CRM.

Проверете как протича discovery фазата

Попитайте какво се случва преди началото на разработката. Кой участва? Как се документират процесите? Как се потвърждават изискванията? Какъв е крайният резултат от discovery фазата?

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

Поискайте да опознаете реалния екип

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

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

Оценявайте подобни проекти по правилния начин

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

Изображенията на едно приложение доказват дизайн. Те не доказват стабилност, приемане от потребителите, производителност или бизнес резултат.

Изисквайте ясен обхват и критерии за приемане

Всяка основна функция трябва да има критерий за приемане. Ако системата „се свързва с ERP“, трябва да е определено какви данни се прехвърлят, в каква посока, колко често, какво се случва при грешка и кой носи отговорност за API-то.

Офертата трябва ясно да разграничава какво се включва, какво не се включва, какви предположения са направени и коя част зависи от трети страни.

Разберете модела на ценообразуване

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

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

Проверете сигурността и непрекъснатостта

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

Отговорът „съответстваме на GDPR“ не е достатъчен. Необходими са конкретни мерки, роли и договорни текстове.

Оценете начина на комуникация

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

Прекомерната увереност е предупредителен знак. Зрелият партньор разграничава ясно какво знае, какво предполага и какво трябва да бъде тествано.

Десет въпроса преди възлагането

1. Какъв проблем смятате, че решаваме, и как ще измерим успеха?
2. Какъв е първият резултат и кога ще го видим да работи?
3. Кой отговаря за обхвата, техническите решения и комуникацията?
4. Какви предположения включва офертата?
5. Как се одобряват промени и как те влияят на цената и срока?
6. Кои данни и интеграции зависят от нас или от трети страни?
7. Какви са критериите за приемане?
8. Как се осигуряват сигурност, резервни копия, наблюдение и реакция при инциденти?
9. Какво се предава, ако сътрудничеството приключи?
10. Каква е общата оперативна себестойност след стартирането?

Argonstack започва персонализираните проекти с бизнес анализ и техническо проектиране. Целта е предложението да описва система, която може да бъде доставена, тествана и работеща, а не просто привлекателен списък от възможности.

Следваща стъпка

Оценете проекта, риска и очаквания резултат, преди да заделите бюджет.

Често задавани въпроси

Трябва ли да избера най-ниската оферта?

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

Нужен ли ми е собствен CTO?

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

Кой е най-важният предупредителен знак?

Неспособността на доставчика да опише ясно какво все още не знае и как ще го потвърди.