Jestem klientem – jak zrobić brief?
dziś poruszę temat, kiedy to MY zlecamy pracę naszym wykonawcom.
Zlecając pracę interesuje nas kilka rzeczy:
- kiedy skończą?
- ile zapłacę?
żeby wykonawca wrócił do nas z tymi informacjami niezbędne jest napisanie tzw. briefu, (RFI – jak kto woli). RFI – request for information.
Dziś dam Ci kilka wskazówek, które pomogą Ci napisać wartościowy brief dla Twojego wykonawcy.
Po co pisać „brief”?
Tak jak wcześniej powiedziałem – głównie chcemy uzyskać informacje ZA ILE i NA KIEDY.
Ale według mnie powinniśmy skupić się na czymś innym podczas pisania.
Chodzi o zwrócenie uwagi wykonawcy, na potencjalne trudności projektowe, żeby mógł zadać odpowiednie pytania.
My jako zlecający często nie wiemy co jest problematyczne dla wykonawcy.
Dowiadujemy się o tym w e-mailu, gdzie wykonawca tłumaczy się dlaczego termin oddania się przesuwa – wtedy pisze co było trudne.
Wtedy już „mleko się rozlało” – minimalizujemy straty.
Cała sztuka polega na tym, aby na takie elementy zwrócić uwagę przed rozpoczęciem prac.
Dlaczego brief, a nie dokumentacja?
Chodzi o to, że wciąż niestety pojęcie dokumentacji jest zaczarowane negatywnie i kojarzy się z czymś długim i nieprzydatnym.
Natomiast brief, kojarzy się z czymś lekkim, co jest esencją wiedzy projektowej.
Według mnie to nie różni się niczym – bo dokumentacja to forma przekazywania wymagań (komunikacji). Stopień szczegółów nie jest wyznacznikiem co kwalifikujemy jako dokumentację, a co nie.
Dokumentacją można nazwać nawet zadania dla programistów. Bo często opisy zadań zebrane w jedno miejsce nazywamy dokumentacją.
Nie „fixuj” się więc czy tworzysz dokumentację, brief, czy RFI.
Chodzi aby skutecznie przekazać wykonawcy to, co ma być zrobione.
Dlatego dla ułatwienia w dalszej części e-maila będę używał pojęć brief, dokumentacja przemiennie.
Poznaj projekt w 10 sekund
W „brief” chodzi o to aby wykonawca mógł maksymalnie szybko poznać projekt do wyceny.
Nie ma chyba szybszego sposobu na przekazanie big picture projektu niż KARTA PROJEKTU.
Wzorów kart projektu w internecie możesz znaleźć wiele. Część z nich zawiera za dużo informacji – powinieneś wybrać te, które kluczowe z Twojego punktu widzenia.
Polecam Ci skorzystać, ze wzoru skróconej karty projektu z kursu Dokumentacja.Pro.
Jeśli nie jesteś kursantem, to skup się na elementach:
- nazwa projektu – nazwij projekt, może być nazwa robocza;
- powód inicjacji – dlaczego startujecie z przedsięwzięciem?
- cel – efekt jaki chcesz osiągąć po wykonaniu prac;
- założenia – na których bazowałeś inicjując projekt (WAŻNE: różnica pomiędzy powodem inicjacji, a założeniami jest subtelna, ale znacząca).
- czas / budżet / zakres projektu – ujęte w 3 – 6 zdaniach
Jeśli masz problem z określeniem powyższych elementów – nie konstruuj reszty dokumentacji.
Prawdopodobnie projekt nie jest odpowiednio przemyślany przez Ciebie.
Większość firm po przeczytaniu karty projektu powinny odpowiedzieć coś w stylu: podobne projekty realizujemy w czasie od X do Y miesięcy za kwotę od W do Z. – dokładnie o to Ci chodzi.
Zacznij więc od skróconej karty projektu.
Powiedz o skali projektu
Mam nadzieję, że odsłuchałeś mój odcinek podcastu o diagramach UML.
Mówię w nim o jednym z podstawowych diagramów – przypadków użycia.
Polecam Ci zacząć od niego, aby określić wykonawcy skalę projektu.
Diagram use case, jest według mnie niezbędnym minimum.
W kursie Dokumentacja.Pro wspominałem, jak ważne jest nadawanie identyfikatorów PU (przypadkom użycia).
Dobrze sprawdza się dodanie opisów do Twoich PU pod diagramem. Taki opis często powie więcej niż sama nazwa PU.
Wykonawca wyśle Ci za to bukiet kwiatów 😉
Według mnie diagram przypadków użycia jest niezbędny.
Inne diagramy
Diagram przypadków użycia jest ważny, ale nie opisze wszystkiego.
Często skomplikowanie danego PU nie wynika z jego nazwy i opisu. Można ją wywnioskować z interreakcji między innymi PU.
Ogólnie mówiąc – chodzi o procesy projektu (to skrót myślowy).
Sekwencja wykonania PU między sobą i zdefiniowanie ich „not happy path” mówi o skomplikowaniu.
FYI: not happy path to ścieżka wykonania procesu, kiedy coś się wysypuje. Not happy path to reakcja projektu na tą sytuację.
Idealnie obrazuje to diagram czynności – kolejny raz odsyłam Cię do mojego podcastu o diagramach.
Odbiegając od diagrami czynności i procesów…
Pewnie zdarzało Ci się dostać pytanie w stylu:
A jak ten element na stronie 2 ma działać dla innych użytkowników?
spoiler: na stronie drugiej masz 3 diagramy i 20 elementów w każdym. Zastanawiasz się czym jest „inny użytkownik”?
Po przeczytaniu pytania myślisz „WTF – oni totalnie nie czają mojego biznesu”.
Wykonawca zada tego typu pytania, gdy nie wie jak nazywają się poszczególne pojęcia w projekcie i nie rozumie zależności między nimi. (+ wtedy gdy w diagramie jest chaos).
Dlatego warto pochylić się nad diagramem klas, żeby pomóc zrozumieć całość projektu i wiedzieć co jest czym i co jest częścią czego – uwierz mi, że dostaniesz precyzyjniejsze pytania.
Rysowanie innych diagramów wpłynie na większe zrozumienie „big picture” przez wykonawcę, a to przełoży się na lepsze wykonanie projektu.
Lepsze tzn takie, które Ci się bardziej spodoba po wykonaniu.
Wiedza o Dokumentacji IT na twój adres e-mail?
Makieta is the king
Tak jak królem dżungli jest lew, tak królem dokumentacji bywają makiety.
Szczególnie gdy swój tekst kierujesz do osób biznesowych.
Często tak jest jeśli wysyłasz pierwszy brief – wyceniają to w pierwszej kolejności osoby z biznesu „tak na oko”.
Zrozumienie makiet często przyjdzie im szybciej niż zrozumienie np. diagramu czynności.
Makiety mają też dużą zaletę – rysując je zaczynasz komunikować się językiem rozwiązań, zamiast językiem wymagań.
Już tłumaczę o co chodzi…
Język rozwiązań (zamiast wymagań)
Gdy przekazujesz wykonawcy „aplikacja ma mieć zarządzanie budżetem” – to tak naprawdę można to wykonać na nieskończenie wiele sposobów i każdy będzie zgodny z definicją „zarządzania budżetem”.
Natomiast gdy pokażemy makietę widoku zarządzania budżetem to przestaje to być wymaganiem, a bardziej zaproponowanym rozwiązaniem, które oczekujemy.
Jeśli masz możliwość – zawsze mów językiem rozwiązań.
Język wymagań – mówisz jaki ma być efekt prac.
Język rozwiązań – mówisz jak chcesz żeby dana rzecz została wykonana .
Mówiąc językiem wymagań zostawiasz wykonawcy pole do zgadywania „co autor miał na myśli”.
Być może trafi i Ci się spodoba, a być może nie trafi i dasz feedback, żeby to poprawili.
Niestety zlecający pracę (czyli TY) często nie wie czego chce, ale wie czego nie chce.
Nie wie czego chce bo nie podsuwa rozwiązań.
Wie czego nie chce bo potrafi ocenić czy to co ktoś wykonał jest zgodne z tym co sobie wyobrażał.
Dużo prościej będzie skupić się na tym by zlecając pracę pisać językiem rozwiązań.
Jednak wiem, że pisanie językiem rozwiązań jest dużo trudniejsze bo:
- wymaga więcej projektowania
- często NIE WIEMY jakie są dobre praktyki rozwiązań danego problemu
- God damn… przecież po to płacimy wykonawcy żeby to zrobił, zamiast zastanawiać się jak rozwiąże nasze problemy 😉
Tak czy siak, polecam Ci pisać językiem rozwiązań tak często jak to możliwe 🙂
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Powiedz po czym Cię oceniają, a powiem Ci jak się będziesz zachowywał
Każdy wykonawca ma na celu zrobienie projektu, który się spodoba zlecającemu.
Sęk w tym, że często wykonawca nie wie jakie są czynniki sukcesu projektu. Jak będzie mierzone czy projekt jest zgodny z oczekiwaniami czy też nie?
Czy jeżeli projekt działa funkcjonalnie prawidłowo, ale jeden widok wczytuje się 30 sekund to jest to OK czy NIE OK?
Prawdopodobnie zależy od projektu 🙂
Dlatego niezmiernie ważne jest żeby określić kryteria akceptacji zadań (lub całego projektu).
Chodzi o określenie warunków (np do konkretnych wymagań) kiedy uznasz, że dany fragment jest wykonany zgodnie z Twoimi oczekiwaniami.
Często kryteria są ubierane w miary wydajnościowe . Np. „chcę aby widoki wczytywały się poniżej 0.2s dla X użytkowników równolegle”.
Takie zdanie da możliwość wykonawcy sprawdzenie przed oddaniem czy będzie PAN ZADOWOLONY 🙂
Anyway, każdy „szanujący się” wykonawca powinien wypisać ograniczenia projektowe – wspominałem o tym wielokrotnie w kursie Dokumentacja.Pro.
Jednak wychodzę z założenia, że nie można mieć nastawienia „niech się domyślą, albo dopytają”.
Powinniśmy opisać jak najwięcej istotnych rzeczy z naszego punktu widzenia.
Warto więc uwzględnić również plany rozwojowe projektu.
Pomoże to wykonawcy zaprojektować architekturę systemu tak aby późniejsze zmiany były możliwe i stosunkowo łatwe.
Jeśli wiesz, że dziś moduł aplikacji ma działać w sposób X, ale planujecie za rok przebudowę na sposób Y to napisz to.
Wykonawca za takie informacje „całuje rączki”.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
