Доброто задание за индивидуална уеб система описва процеса, който трябва да се обслужва: кой участва, какво прави, с какви данни и по какви правила. Клиентът не трябва да проектира архитектура или база данни. Неговата задача е да направи работата на бизнеса разбираема за техническия екип.
Можете да започнете с разговор, примерни документи и описание на конкретна работна ситуация. Списъкът с желани екрани ще дойде след това. „Искаме табло и клиентски профили“ не обяснява какъв проблем трябва да решат те.
Покажете проблема и работата днес
Опишете къде се губи информация, кое се въвежда повторно, какво чака одобрение или какво трудно се проверява. Покажете стъпките от началото до края, включително тези извън компютъра: телефонно уточнение, проверка в склада или подпис на документ.
Полезни са примерни таблици, формуляри и съобщения, но премахнете личните и поверителните данни преди споделяне. Кажете кое в сегашния начин на работа е правило и кое е заобиколен път, наложен от ограниченията на инструментите.
Разграничете текущия процес от желания. Ако още няма решение как трябва да се работи, отбележете го. Разработката не може сама да реши кой във фирмата има право да одобрява заявка.
Проследете една заявка през целия ѝ живот
Следващата ситуация е пример, а не описание на клиентски проект: служител подава заявка за закупуване на материал, ръководител я одобрява, а отговорникът по снабдяването отчита получаването.
За такъв процес трябва да стане ясно кой създава заявката, какво съдържа тя и кога може да премине към следващата стъпка. „Подадена“, „за уточнение“, „одобрена“ и „получена“ имат смисъл само ако е описано какво означават и кой може да ги променя.
Роли, действия и права
Опишете правата чрез работата: служителят вижда своите заявки, ръководителят одобрява тези на отдела, а снабдяването обработва одобрените. Посочете и кой може да коригира вече подадена информация.
Не е нужно да измисляте техническа система за права. Нужни са бизнес границите: кой вижда чужди данни, кой взема решение и кои действия трябва да оставят следа за последваща проверка. При чувствителна информация обсъдете ограниченията още преди разработката.
Данни и зависимости
За всяко действие посочете необходимата информация и откъде идва тя. Име на материал, количество и срок са различни данни от одобрение или потвърждение за доставка. Покажете връзките между тях с конкретен пример.
Обяснете дали следващата стъпка изисква резултат от друга. Може ли снабдяването да започне без одобрение? Може ли заявката да се приключи, ако е получена само част от количеството? Това са правила за работата, които екипът ще преведе в техническо решение.
Опишете какво става, когато процесът не върви по план
Заданието трябва да включва повече от успешния случай. Посочете какво правите при отказ, липсващи данни, грешно въведена стойност или отсъстващ отговорник. Кой може да върне процеса за корекция и кой получава известие?
За изключенията, които се решават индивидуално, опишете нуждата от човешка намеса. Не е необходимо всяка рядка ситуация да има собствен автоматичен сценарий. По-важно е системата да не оставя екипа без начин за коректно продължаване.
Уточнете връзките с другите инструменти
Ако системата ще работи с ERP, CRM, счетоводна програма или външна услуга, запишете каква информация трябва да получава и изпраща. Посочете коя система определя актуалната стойност и кой я поддържа.
Добавете наличната документация, ограниченията за достъп и технически контакт. Не обещавайте възможности от името на външен доставчик. Ако интеграцията още не е проверена, тя е зависимост за уточняване, а не сигурна част от готовия обхват.
Опишете и първоначалните данни. Какво трябва да се прехвърли от стария инструмент, какво е архив и кой ще провери информацията? Подготовката и миграцията имат собствена работа, дори новите екрани вече да са ясни.
Оставете място за по-просто решение
Наличието на специфичен процес не означава задължително нова уеб система. Понякога готов инструмент или ограничена разработка около съществуващата среда е достатъчна. Това трябва да се прецени спрямо нуждите, ограниченията и поддръжката.
При системата за продуктови вариации на Палисандър ООД работната среда е Google Sheets с допълнителна Apps Script логика. Проектът илюстрира решение около подготовката на продуктови данни, а не изграждане на отделна уеб система за всяка вътрешна задача.
Посочете кое е задължително за първата версия, какво може да остане ръчно и какво ще се оценява по-късно. Уточнете бюджет, срок, човек за решенията и отговорник за използването след старта.
Определете резултата чрез проверими ситуации
За примерната заявка успехът може да се провери така: служителят я подава, правилният ръководител я вижда, отказът връща ясна причина, а частичното получаване не я приключва погрешно. Това е по-конкретно от „системата да бъде удобна“.
Подгответе такива ситуации за основните процеси и ги уточнете с изпълнителя като критерии за приемане. Включете хората, които ще работят със системата, а не само този, който възлага проекта. Получава се основа за проектиране и проверка на решението, без бизнесът да пише техническата му спецификация предварително.
