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

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

#Защо от заданието зависи точността на офертите

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

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

#Какво съдържа едно полезно задание

Целта и как ще разберете, че е постигната

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

Потребители и роли

Изброете всички видове хора, които ще работят с продукта: клиенти, служители, мениджъри, партньори, администратори. За всеки тип посочете приблизително колко са и какво могат да виждат или променят. Ролите и правата определят структурата на данните и администраторския панел, затова трябва да са в заданието от самото начало.

Основни сценарии

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

Интеграции и съществуващи системи

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

Ограничения

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

Срок и бюджетна рамка

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

Какво не влиза в проекта

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

#Какво да оставите на разработчика

Заданието описва проблема. Решението е това, за което плащате на разработчика. Ако няма бизнес причина, не фиксирайте предварително:

• Език за програмиране, framework и база данни. Ако вашият екип ще поддържа кода, напишете коя технология познава. Това е ограничение и то е напълно основателно.
• Архитектурата, например микроуслуги, serverless или едно цяло приложение.
• Детайлни екрани, ако наемате и дизайн. Скици и примери за продукти, които харесвате, са добре дошли; готовите макети са преждевременни.
• Точни часове за всяка функция. Поискайте ги в офертата.

Предписаното решение може да струва повече, отколкото спестява. Изискване като „всичко да се обновява в реално време“ може да удвои работата, когато обновяване на един екран веднъж в минута би свършило същата работа за потребителите. Опишете нуждата и оставете разработчика да предложи варианти с техните плюсове и минуси.

#Структура на задание, която можете да копирате

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

1. Фирма и контакт: кои сте, кой взема решенията, кой отговаря на въпроси по време на проекта.
2. Проблемът: какво се случва днес и защо трябва да се промени.
3. Целта: какво трябва да е вярно, след като продуктът заработи.
4. Потребители и роли: всеки тип потребител, приблизително колко са и какво може да вижда и прави всеки.
5. Основни сценарии: най-важните пътища, стъпка по стъпка.
6. Интеграции: всяка външна система, има ли API и има ли тестов достъп.
7. Съществуващи системи и данни: какво се заменя, кои данни се прехвърлят и в какво състояние са.
8. Платформи: уеб, iOS, Android, настолно приложение; важните браузъри и устройства.
9. Езици и региони: езици на интерфейса, валути, часови зони.
10. Ограничения: хостинг, сигурност, достъпност, технологии, бранд.
11. Срок: датата и причината за нея.
12. Бюджетна рамка: диапазон, в който се чувствате комфортно.
13. Извън обхвата: какво няма да има в първата версия.
14. След пускането: кой ще управлява продукта и очаквате ли по-нататъшна разработка и поддръжка.
15. Примери: продукти, които харесвате или не, и защо.

#Чести грешки, които отслабват заданието

• Функции без приоритети. Отбележете кое е задължително за старта и кое може да почака. Иначе всичко изглежда еднакво спешно и офертата расте.
• Копиране на конкурент. „Като Booking.com, но за зъболекари“ крие години работа. Посочете конкретните части, които наистина ви трябват.
• Пропуснат администраторски панел. Някой трябва да управлява потребители, съдържание, поръчки и възстановяване на плащания. Тези екрани са реална работа и често се забравят.
• Пренебрегнати стари данни. Прехвърлянето на записи с дублирани и липсващи полета може да отнеме повече време от функцията, която ги използва.
• Задание, писано от един човек. Дайте сценариите на хората, които ще работят с продукта всеки ден. Те ще открият пропуснатите стъпки за минути.

#Какво да очаквате, след като изпратите заданието

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

#Как може да помогне PN Scripts

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