Przejdź do treści
Outlier Labs

Oprogramowanie i automatyzacja

Jak zbriefować zespół programistów, gdy nie jesteś osobą techniczną

Nie musisz mówić technicznym językiem, żeby zbudować świetne oprogramowanie. Musisz dobrze wyjaśnić problem. Oto jak pewnie zbriefować zespół.

Outlier Labs · · 5 min czytania

Twoim zadaniem jest problem, nie rozwiązanie

Wielu klientom bez technicznego zaplecza wydaje się, że muszą przyjść z gotowym rozwiązaniem, z funkcjami, ekranami i technicznymi słowami, które w połowie rozumieją. Jest odwrotnie, a próba wykonania pracy zespołu zwykle pogarsza efekt, zamiast go poprawiać.

Dobry zespół nie potrzebuje, żebyś projektował odpowiedź. Potrzebuje, żebyś jasno i w całości wyjaśnił problem. Najbardziej przydatne zdanie, jakie możesz powiedzieć, to nie „zbudujcie mi dashboard z tymi konkretnymi przyciskami”. To: „oto co idzie źle w mojej firmie, oto ile mnie to kosztuje i oto jak wyglądałoby dobrze”.

Takie postawienie sprawy daje doświadczonym ludziom przestrzeń, by zaproponować właściwe rozwiązanie, zamiast wiernie budować chwiejny domysł. To Ty jesteś ekspertem od swojego biznesu i swojego problemu. Oni są ekspertami od tego, jak dobrze go rozwiązać. Dobry brief utrzymuje każdą ze stron w roli, w której jest naprawdę najlepsza.

Zacznij od historii, nie od ekranów

Opisz, jak wszystko działa dziś, krok po kroku, dokładnie tak, jakbyś szkolił nowego pracownika pierwszego dnia. Klient pyta tutaj, potem ta osoba robi to, potem to jest wpisywane tam, a tu zwykle coś idzie nie tak i ktoś musi to poprawić ręcznie.

Taka prosta historia to złoto dla zespołu programistów. Pokazuje, gdzie jest prawdziwy ból, który krok naprawdę ma znaczenie, a które tylko wyglądają na ważne. Ekrany, funkcje i technologia przychodzą później i są ich zadaniem. Historia sprawia, że w ogóle buduje się właściwą rzecz.

Bądź też konkretny co do skali i wyjątków. Jak często to się dzieje, jak wygląda typowy przypadek i jakie są chaotyczne przypadki, które psują zwykły przebieg. To w wyjątkach zwykle kryją się prawdziwe koszty i prawdziwe wyzwania projektowe.

Jasno określ, co oznacza sukces

Powiedz im konkretnie, po czym poznasz, że projekt się udał. Może zapytania przestaną ginąć. Może raport, który zajmuje cały dzień, będzie zajmował minuty. Może klienci będą mogli umówić się bez dzwonienia. Konkretne rezultaty po cichu kierują każdą mniejszą decyzją, którą zespół podejmie później.

Mgliste cele w rodzaju „niech będzie nowocześnie”, „niech będzie lepiej” czy „niech robi wrażenie” niezawodnie prowadzą do mglistych, rozczarowujących efektów, bo nikt nie może celować w cel, którego nikt nie zdefiniował. Jasna definicja sukcesu to najcenniejsza rzecz, jaką możesz wnieść, a jej przygotowanie kosztuje Cię tylko chwilę namysłu.

Jeśli możesz, dołącz do sukcesu przybliżoną liczbę albo stan przed i po. Nie musi być precyzyjna. Musi być na tyle konkretna, żeby wszyscy, łącznie z Tobą, mogli potem stwierdzić, czy to naprawdę zadziałało.

Powiedz, czego nie wiesz

Nie będziesz znać wszystkich odpowiedzi, a udawanie, że znasz, to jedna z najdroższych rzeczy, jakie możesz zrobić. Powiedzenie „nie jestem pewien, jak to powinno działać, co zwykle polecacie?” to siła, a nie słabość. Zaprasza prawdziwą ekspertyzę, zamiast utrwalać słaby wczesny domysł, którego odkręcenie będzie kosztowne.

Tak samo szczerze i wcześnie podziel się realnymi ograniczeniami. Przedziałem budżetu, prawdziwym terminem, tym, kto faktycznie musi zatwierdzać rzeczy, i tym, czego absolutnie nie można zmienić. Dobry zespół zdecydowanie woli wiedzieć o tym pierwszego dnia niż odkryć to w połowie, gdy uwzględnienie tego jest kosztowne lub niemożliwe.

Ukryte ograniczenia Cię nie chronią. Wychodzą później jako poprawki, przekroczone terminy i frustracja po obu stronach. Brief to najtańsze miejsce w całym projekcie, by być z nimi szczerym.

Prosty brief, który możesz napisać dziś

Mocny brief zmieścisz na jednej stronie. Opisz prosto pięć rzeczy. Czym zajmuje się firma. Konkretny problem, który chcesz rozwiązać. Jak ten proces działa dziś, krok po kroku. Jak konkretnie wyglądałby sukces. I wszelkie realne ograniczenia czasowe, finansowe i dotyczące akceptacji.

Nie przejmuj się poprawną terminologią techniczną. Jasny brief prostym językiem zawsze wygrywa z naszpikowanym żargonem, bo pozwala zespołowi zadawać trafne, przydatne pytania, zamiast po cichu zgadywać, co miałeś na myśli, i budować w złym kierunku.

Najlepsze projekty prawie nigdy nie zaczynają się od tego, że klient rozumie technologię. Zaczynają się od tego, że klient wyjaśnia problem tak jasno, że właściwi ludzie od razu widzą, jak go rozwiązać. Ta jasność, a nie biegłość techniczna, jest Twoim prawdziwym zadaniem i całkowicie zależy od Ciebie. Jeden ostatni nawyk sprawia, że wszystko powyższe działa jeszcze lepiej. Po przekazaniu briefu poproś zespół, żeby własnymi słowami opowiedział Ci problem, zanim ktokolwiek zacznie mówić o rozwiązaniach. Jeśli ich podsumowanie zgadza się z tym, co miałeś na myśli, macie zgodność i możecie pewnie działać szybko. Jeśli nie, właśnie wyłapałeś najdroższy rodzaj błędu, czyli nieporozumienie co do celu, w najtańszym możliwym momencie, zanim zaczęła się jakakolwiek praca. Ta pięciominutowa kontrola jest warta więcej niż strony szczegółowej specyfikacji, bo sprawdza zrozumienie, a nie tylko zapisuje słowa.

Zbudujmy coś, co się skaluje. Masz pomysł na projekt albo szukasz długoterminowego partnera do wzrostu? Chętnie Cię wysłuchamy.

Projektant szkicujący makiety strony w notesie
Miękkie dzienne światło i cień na minimalistycznym białym biurku