Какво определя цената на софтуера по поръчка и как да я държите под контрол

Две компании искат „прост портал за нашите клиенти“ и получават коренно различни оферти. В повечето случаи нито един от доставчиците не е нечестен. Те оценяват различни неща, защото заявката оставя отворени повечето реални решения: кой ще използва портала, с кои системи ще се свързва, какво се случва, когато нещо се обърка.

При софтуера по поръчка цената зависи не толкова от броя на екраните, колкото от броя на правилата, ролите и връзките зад тях. Проучване на McKinsey и Оксфордския университет на над 5400 ИТ проекта установява, че големите проекти средно надхвърлят бюджета си с 45 процента и същевременно носят с 56 процента по-малко стойност от прогнозираното. Голяма част от тази разлика идва от неща, които никой не е уточнил в началото.

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

Основните фактори за цената

Обхват и брой роли

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

Интеграции

Свързването със счетоводна система, ERP, банка, куриер, данъчна администрация или доставчик на плащания често е най-голямото отделно перо в проекта. Обемът на работата зависи от другата страна: има ли документиран API, тестова среда, стабилен формат на данните, човек, който отговаря на въпроси? Връзка с добре документирана услуга може да отнеме дни. Връзка със стара система, която експортира файлове само веднъж на нощ, може да отнеме седмици и ще изисква внимание при всяка промяна в тази система.

Миграция на данни

Прехвърлянето на данни от таблици или от стара система звучи като копиране и поставяне. На практика означава премахване на дубликати, попълване на липсващи полета, съпоставяне на стари кодове с нови и решение какво да се прави със записи, които не пасват никъде. Миграцията е и етапът, в който хората от бизнеса трябва да отделят най-много време, защото само те знаят дали „АБВ“ ООД и „А.Б.В.“ ООД са един и същ клиент.

Изисквания за качество и сигурност

Инструмент, който използват петима колеги, и система, която обработва плащания или лични данни, са различни продукти, дори екраните да изглеждат подобно. Изискванията за наличност, време за отговор, одитна следа, резервни копия, контрол на достъпа и защита на данните добавят работа по проектиране, тестване и документиране. Публикуваните стандарти помагат това да стане конкретно. ISO/IEC 25010 описва характеристики на качеството на продукта като надеждност, сигурност и поддържаемост, а OWASP Application Security Verification Standard дава списък с изисквания за сигурност на различни нива на строгост. Изборът на ниво, което отговаря на реалния ви риск, ви предпазва от това да платите за твърде малко или за твърде много.

Платформи

Уеб приложение, което работи добре в браузърите на компютър и мобилни устройства, е един продукт. Нативни приложения за iOS и Android, офлайн режим за служителите в склада или поддръжка на стари браузъри в мрежата на клиент: всяко от тях добавя работа по разработка, тестване и публикуване. Преди да се обвържете с магазините за приложения, проверете дали адаптивно уеб приложение не покрива вече реалната нужда.

Модел на екипа

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

Как да държите цената под контрол

Започнете с минимален жизнеспособен продукт

Определете най-малката версия, която носи реална стойност на реални потребители, и изградете първо нея. За клиентски портал това може да е вход, статус на поръчките и изтегляне на документи, без чат, анализи или мобилно приложение. MVP не е демонстрация: хората трябва да могат да го използват в ежедневната си работа. Задачата му е да потвърди кое е важно, преди да похарчите пари за това, което може би е важно.

Доставяйте на етапи

Разделете работата на кратки етапи, всеки от които завършва с работещ софтуер, който можете да изпробвате. Принципът от Agile манифеста все още важи: доставяйте работещ софтуер често, на интервал от няколко седмици до няколко месеца. Всеки етап е естествен момент да прегледате разходите, да смените приоритетите или да спрете. Дълъг проект с една-единствена доставка в края не ви дава нито една от тези възможности.

Напишете ясни критерии за приемане

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

Управлявайте промените съзнателно

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

Гледайте общата цена на притежание

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

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

Преките пътища, избрани, за да се спази ранен срок, също имат цена. Мартин Фаулър описва това като технически дълг: объркан вътрешен код прави всяка следваща промяна по-бавна, като лихва по заем. Известен дълг е разумен избор за MVP, стига да е съзнателно решение и да го изплащате в следващите етапи.

Списък за проверка, преди да поискате оферта

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

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

Как може да помогне MTV GROUP

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