Jak zrywać niestandardową aplikację bez pisania specyfikacji technicznej.

Brief rozwoju nie musi rozpoczynać się od diagramu bazy danych. Musi on wyjaśnić zadanie, które ktoś powinien być w stanie wykonać i wynik potrzeb biznesowych z niego.

Celem pierwszego podsumowania jest umożliwienie dyskusji nad projektem. Można pozostawić wybór techniczny otwarty, a jednocześnie być dokładnym co do pracy, którą aplikacja musi wspierać.

Zacznij od użytkownika i zadania

"Zbuduj portal" nazywa rodzaj oprogramowania. "Pozwól zatwierdzonemu klientowi złożyć wniosek o usługę i zobaczyć jej postęp" opisuje użyteczny pierwszy przepływ pracy.

Nazwa użytkownika, działanie i wynik. Następnie określić, kto zajmuje się drugą stroną procesu. W tym przykładzie, członek personelu musi przejrzeć wniosek i uaktualnić jego status. Oznacza to, że krótki zawiera już dwie różne role i wspólny rekord.

Unikaj rozpoczęcia od "aplikacji dla wszystkich". Różni użytkownicy mogą potrzebować różnych uprawnień, ekranów i informacji. Zdecyduj, która rola ma największe znaczenie w pierwszym wydaniu.

Wyjaśnij, co się dzisiaj stanie.

Opisz bieżące kroki w zwykłym języku. Być może klient e-mail informacji, pracownik kopiuje go do arkusza kalkulacyjnego i inna osoba wysyła aktualizację postępu. Stan, w którym dezorientacja lub powtarzający się wysiłek występuje, nie zakładając, że oprogramowanie rozwiąże każdy otaczający problem.

Redagowany przykład aktualnego formularza lub rekordu może być bardziej przydatny niż polerowana prezentacja. Usuwanie danych osobowych i poufnych informacji przed ich udostępnieniem.

Opisz jedną kompletną podróż

Podążaj za reprezentatywnym rekordem od początku do końca. Co go zaczyna? Jakie informacje są wymagane? Kto podejmuje kolejną decyzję? Co oznacza, że jest kompletny?

Dołącz jeden lub dwa ważne wyjątki. Wniosek może być niekompletny, recenzent może go odrzucić lub użytkownik może potrzebować skorygować błąd. Przypadki te pomagają odróżnić aplikację roboczą od demonstracji idealnej ścieżki.

Nie trzeba wymyślać każdego rzadkiego wydarzenia na tym etapie. Skoncentruj się na wyjątkach, które powstrzymałyby główny przepływ pracy od bycia użytecznym.

Nazwa danych i zależności

Lista ważnych zapisów: użytkownicy, wnioski, produkty, rezerwacje, pliki lub inny zestaw informacji. Wyjaśnij, skąd pochodzą i kto jest odpowiedzialny za ich utrzymanie.

Dla integracji, nazwa innej usługi i dostarczyć jej dokumentację, gdy jest dostępna. "Połącz się z naszym CRM" pozostawia główne pytania otwarte. Przydatnym szczegółem jest, który zapis powinien poruszać się, w którym kierunku i po którym zdarzeniu.

Określić, czy projekty, zawartość produktu, dostęp do konta lub zasady biznesowe są już dostępne. Brakujące materiały nie są automatycznie blokery, ale potrzebują właściciela i miejsce w planie.

Zdefiniuj pierwszą użyteczną wersję

Pierwszy portal może wspierać tworzenie wniosku, przeglądanie go i pokazywanie statusu. Komunikacja, zaawansowana sprawozdawczość i aplikacja mobilna mogą być późniejszymi dyskusjami, a nie niewypowiedzianymi wymaganiami pierwszej budowy.

Nie jest to instrukcja, aby zbudować coś niekompletnego. Wybrany przepływ pracy powinien działać od początku do końca. Granica jest między pełnym przepływem pracy, a nie między atrakcyjnym ekranem a logiką, której nadal potrzebuje.

Napisz przykład akceptacji

Spróbuj zdania, które ktoś mógłby przetestować:

Zatwierdzony klient może złożyć wniosek, zobaczyć jego status po zalogowaniu się i zobaczyć tylko własne wnioski. Upoważniony członek personelu może zaktualizować status, a klient widzi tę zmianę.

Jest to przykładowy wymóg, a nie opis istniejącego projektu klienta. To sprawia, że oczekiwane zachowanie znacznie jaśniejsze niż "nowoczesny, bezpieczny portal". Ostateczny zakres może poprawić uprawnienia i przypadki krawędzi.

Dodawanie ograniczeń praktycznych

Określ pożądany termin, czy jest to preferencja czy ustalona data zewnętrzna, oraz zakres budżetu, o ile jest znany. Podaj osobę, która może zatwierdzić decyzje i wyjaśnić, w jaki sposób zostaną dostarczone projekty lub informacje zwrotne.

Kto będzie właścicielem hostingu i kont? Czy inny deweloper musi otrzymać kod? Pytania te wpływają na dostawę, nawet jeśli nie pojawiają się na ekranie.

Brief, z którego możesz skorzystać

Chcemy budować: zastosowanie lub przepływ pracy. Głównymi użytkownikami są: ludzi i ról. Muszą: główne zadanie i ukończony wynik. Dziś dzieje się to poprzez: obecny proces. Pierwsza wersja musi zawierać: zasadniczy pełny przepływ pracy. Musi połączyć się z: znane systemy i dokumentacja. Mamy już: projekty, treści, rachunki lub przykładowe dane. Nadal niezdecydowany: pytania do rozwiązania. Czas, budżet i decydenci: ograniczenia praktyczne.

Użyj kilku jasnych zdań dla każdej części. Brief jest punktem wyjścia do określenia projektu, a nie test, który musisz przejść przed rozmową z deweloperem.

Dyskusja na temat własnej aplikacji web lub wyślij opis projektu.