Przygotuj brief z zadaniem, technologiami, wymiarem pracy, terminem startu i recenzentem. Daj kandydatowi kontekst potrzebny do oceny dopasowania.
Co powinien zawierać brief?
Należy opisać pracę, nie wszystkie technologie. Wskazać pierwszy rezultat, stos, ograniczenia i recenzenta. Podać tygodniowy wymiar, długość, wspólne godziny i start wraz z niewiadomymi.
Użytkownicy, systemy i dane przed listą funkcji
Pracę integracyjną i związaną z danymi łatwo niedoszacować, gdy partner jej nie widzi. Przed wypisaniem funkcji warto opisać, kto będzie korzystał z oprogramowania, z jakimi systemami musi współpracować i jakie dane przetwarza. Luki w tej części wracają później jako zgłoszenia zmian.
- Użytkownicy: kim są, mniej więcej ilu ich jest, gdzie i na jakich urządzeniach pracują.
- Istniejące systemy: jakie to systemy, kto jest ich właścicielem i czy mają udokumentowane API, czy tylko bazę danych i eksport plików.
- Dane: które są osobowe, poufne lub regulowane, gdzie znajdują się dziś i ile z nich trzeba zmigrować.
- Utrzymanie: kto będzie obsługiwał oprogramowanie po uruchomieniu i jakie zasady dotyczące hostingu lub chmury firma już ma.
- Ograniczenia: języki, wymagania dostępności, standardy bezpieczeństwa i każdy nieprzesuwalny termin, wraz z jego powodem.
Co udostępnić przed ustaleniem dostępu?
Należy używać zanonimizowanych przykładów bez haseł i danych klientów. Wyjaśnić dostęp bez udzielania go w briefie. Odróżnić wzmocnienie zespołu od projektu, audytu lub utrzymania pod odpowiedzialnością SDK.
Najważniejsze wnioski
- Należy opisać pracę, nie wszystkie technologie.
- Należy używać zanonimizowanych przykładów bez haseł i danych klientów.
- Należy opisać problem, użytkowników i to, jak wygląda sukces, a rozwiązanie zostawić otwarte.
FAQ
Co powinien zawierać brief?
Należy opisać pracę, nie wszystkie technologie. Wskazać pierwszy rezultat, stos, ograniczenia i recenzenta. Podać tygodniowy wymiar, długość, wspólne godziny i start wraz z niewiadomymi.
Co udostępnić przed ustaleniem dostępu?
Należy używać zanonimizowanych przykładów bez haseł i danych klientów. Wyjaśnić dostęp bez udzielania go w briefie. Odróżnić wzmocnienie zespołu od projektu, audytu lub utrzymania pod odpowiedzialnością SDK.
Nie wiemy dokładnie, kogo potrzebujemy. Czy SDK może pomóc?
Tak. Wystarczy opisać problem w zapytaniu lub podczas rozmowy, a pomożemy określić rolę. Jeśli okaże się, że zamiast tego potrzebny jest zrealizowany projekt, tym również możemy się zająć.