PRZED ROZMOWĄ O PROJEKCIE
Jak opisać pomysł na aplikację?
Nie potrzebujesz gotowej specyfikacji, żeby rozpocząć rozmowę z wykonawcą. Przydatny brief wyjaśnia, dla kogo powstaje produkt, jakie zadanie ma ułatwić i co jest potrzebne w pierwszej wersji. Poniżej znajdziesz pytania, przykład i szkic do uzupełnienia.
Przejdź do szablonu1. Opisz problem i oczekiwany rezultat
Zacznij od obecnej sytuacji. Co ludzie robią dziś przez telefon, w arkuszu albo w kilku systemach? Wskaż konkretną trudność i opisz, jak ma wyglądać wykonanie zadania po wdrożeniu. „Klient sam sprawdza status zgłoszenia” mówi więcej niż „chcemy nowoczesną aplikację”. Nie musisz obiecywać wzrostu sprzedaży ani określać wyniku, którego jeszcze nie da się zmierzyć.
2. Wskaż użytkowników i ich uprawnienia
Oddziel klienta, pracownika i administratora. Dla każdej roli zapisz, co może zobaczyć, dodać, zmienić lub zatwierdzić. Przykładowo klient widzi własne sprawy, pracownik obsługuje przypisane zgłoszenia, a administrator zarządza dostępami. Liczba ról i wyjątków wpływa na projekt, zaplecze oraz testy.
3. Wybierz jeden scenariusz na start
Opisz drogę użytkownika od początku do końca. Następnie oddziel funkcje niezbędne do wykonania tego zadania od pomysłów na później. Jeśli bez danej funkcji nadal można sprawdzić najważniejsze założenie produktu, warto rozważyć kolejny etap. Pierwsza wersja powinna mieć uzgodnione kryteria odbioru, a nie tylko listę ekranów.
4. Określ urządzenia i sposób korzystania
Napisz, czy użytkownik pracuje przy komputerze, regularnie wraca do produktu na telefonie, czy otwiera go tylko od czasu do czasu. Wymień potrzebę działania bez internetu, powiadomień lub użycia aparatu, jeśli dotyczy projektu. Nie wybieraj aplikacji sklepowej wyłącznie dlatego, że wygląda atrakcyjnie: część potrzeb może obsłużyć portal w przeglądarce.
5. Wymień dane, materiały i integracje
Wskaż systemy, które już działają, rodzaje dokumentów i źródła danych. Zaznacz, czy dostępne są API, dokumentacja i osoba odpowiedzialna po stronie dostawcy. Integrację trzeba ocenić przed przyjęciem zakresu. Do pierwszej rozmowy wystarczą nazwy narzędzi i opis przepływu; nie przesyłaj haseł, kluczy API ani prawdziwej bazy klientów.
6. Podaj ograniczenia i ustal elementy wyceny
Jeśli masz budżet lub docelową datę, wpisz je i wyjaśnij, z czego wynika termin. Jeśli ich nie znasz, napisz to wprost. Poproś o rozdzielenie prac nad produktem, zewnętrznych usług, hostingu i utrzymania. Przy istniejącej aplikacji potrzebna może być najpierw ocena kodu. Porównuj wyceny dla tego samego zakresu, z podanymi założeniami i wyłączeniami.
Przykład: portal obsługi zgłoszeń
To przykład poglądowy, nie opis realizacji klienta. Problem: statusy spraw są rozrzucone między e-maile i arkusz. Na start klient zakłada zgłoszenie i widzi jego status, pracownik dodaje odpowiedź, a administrator przydziela dostęp. Odbiór: klient nie widzi cudzych spraw; zmiana statusu jest widoczna po ponownym otwarciu zgłoszenia; odpowiedź pozostaje przypisana do właściwej sprawy. Czat na żywo, płatności i aplikacja mobilna zostają poza pierwszym etapem. Ich ewentualny rozwój wymaga osobnego ustalenia.
Uzupełnij szkic i przejdź do rozmowy
Możesz uzupełnić szkic tutaj i skopiować go do wiadomości. Treść pozostaje w tej karcie: nie zapisujemy jej ani nie wysyłamy automatycznie. Odświeżenie lub zamknięcie strony usuwa wpisane zmiany. Nie wpisuj haseł ani danych klientów.