Reklama.
Reklama.
Reklama.
7 wskazówek które oszczędzą Ci czas, nerwy i pieniądze. Jak współpracować z dostawcą IT?
11 marca 2019, 21:39·4 minuty czytania
Publikacja artykułu: 11 marca 2019, 21:39Jeśli zlecasz oprogramowanie firmie zewnętrznej, to pewnie drżysz o jego powodzenie. Wszakże 1/3 projektów nigdy się nie kończy, a większość z pozostałej części ma przekroczony budżet i termin. Wynika to z kilku zaniedbań i bardzo trudnego styku biznesu i IT, które często mają odmienny stan wiedzy, priorytety, sposób zarządzania. Poniższe wskazówki pozwolą Ci oszczędzić czas i pieniądze przy zlecaniu projektów firmie zewnętrznej
Reklama.
1. Określ co chcesz zrobić?
Jedną z podstawowych przyczyn niepowodzeń w projektach informatycznych jest brak jasno sprecyzowanych wymagań. Niezależnie, czy Twój projekt ma charakter rozwojowy (produkt dla startupu), czy listy ustalonych wymagań (wdrożenie znanego systemu CRM/ERP), powinieneś posiadać trzy dokumenty:
1. BRD (Business Requirement Document). W tym dokumencie określasz jakie cele biznesowe realizuje aplikacja. Bez nich może się okazać, że dostaniesz dobry technicznie i funkcjonalny produkt, ale na którym nie zrealizujesz swoich celów.
2. FRD (Functional Requirement Document). W drugim kroku określasz funkcjonalności jakie ma posiadać aplikacja „co ma robić?”, w tym pomogą Ci Persony (dla kogo) Historie użytkownika, Przypadki użycia itp. – warto zorganizować warsztaty, które pomogą dookreślić
3. TRD (Technical Requirement Document) to zbiór wymagań technicznych. Dopiero trzecim kroku przystępujemy do spisania jakiego języka programowania użyjemy, jakiego frameworka, jakich bibliotek. Dopiero do napisania TRD często będziesz potrzebował osoby z wiedzą techniczną.
Jedną z podstawowych przyczyn niepowodzeń w projektach informatycznych jest brak jasno sprecyzowanych wymagań. Niezależnie, czy Twój projekt ma charakter rozwojowy (produkt dla startupu), czy listy ustalonych wymagań (wdrożenie znanego systemu CRM/ERP), powinieneś posiadać trzy dokumenty:
1. BRD (Business Requirement Document). W tym dokumencie określasz jakie cele biznesowe realizuje aplikacja. Bez nich może się okazać, że dostaniesz dobry technicznie i funkcjonalny produkt, ale na którym nie zrealizujesz swoich celów.
2. FRD (Functional Requirement Document). W drugim kroku określasz funkcjonalności jakie ma posiadać aplikacja „co ma robić?”, w tym pomogą Ci Persony (dla kogo) Historie użytkownika, Przypadki użycia itp. – warto zorganizować warsztaty, które pomogą dookreślić
3. TRD (Technical Requirement Document) to zbiór wymagań technicznych. Dopiero trzecim kroku przystępujemy do spisania jakiego języka programowania użyjemy, jakiego frameworka, jakich bibliotek. Dopiero do napisania TRD często będziesz potrzebował osoby z wiedzą techniczną.
2. Czy chcesz pracować na podstawie godzin czy za ustaloną stawkę?
Coraz częstszą formą pracy z firmami developerskimi jest praca na podstawie faktycznie przepracowanych godzin (time&material). Źródłem tego jest trudność w dookreśleniu szczegółowych zakresów prac. Jeśli nawet umawiasz się na stałą stawkę (fixed), to podziel projekt na etapy. Beta – pierwszą prezentację produktu, MVP – pierwszy produkt, który ma wartość dla klientów, tak by się zarejestrowali/zalogowali lub zapłacili, faza MUST – co musi być zrealizowane, faza SHOULD – co planujecie w kolejnym kroku. Gwarantuję, że nie pożałujesz tej decyzji. Gdyby prace nie szły zgodnie z planem – możecie renegocjować zakres i czas. A w trakcie prac, na pewno też pojawią się nowe pomysły, które przeniesienie do kolejnych faz rozwoju produktu.
Coraz częstszą formą pracy z firmami developerskimi jest praca na podstawie faktycznie przepracowanych godzin (time&material). Źródłem tego jest trudność w dookreśleniu szczegółowych zakresów prac. Jeśli nawet umawiasz się na stałą stawkę (fixed), to podziel projekt na etapy. Beta – pierwszą prezentację produktu, MVP – pierwszy produkt, który ma wartość dla klientów, tak by się zarejestrowali/zalogowali lub zapłacili, faza MUST – co musi być zrealizowane, faza SHOULD – co planujecie w kolejnym kroku. Gwarantuję, że nie pożałujesz tej decyzji. Gdyby prace nie szły zgodnie z planem – możecie renegocjować zakres i czas. A w trakcie prac, na pewno też pojawią się nowe pomysły, które przeniesienie do kolejnych faz rozwoju produktu.
3. Określ budżet i harmonogram
Średnio w projektach informatycznych czas i budżet przekroczone są dwukrotnie – Paulo Coelho.
Bez realnego budżetu i harmonogramu, ciężko o sukces projektu. Określenie go z góry też może być świetnym sposobem na weryfikację projektu. Jeśli planujesz zrobić drugi Google Maps, a Twój budżet to 100.000 złotych, to mądry Dostawca, uświadomi Ci, że masz duże szanse stracić bezpowrotnie pieniądze i nie otrzymać konkurencyjnego produktu. Jeśli planujesz to zrobić w czasie krótszym niż 3 miesiące, to także jest okazja na weryfikację założeń lub rezygnację na samym początku.
Tutaj dodam osobiste spostrzeżenie – prawie zawsze obie strony zakładają czas „bez poślizgów”, a Zlecający często wywiera presję „czy da się taniej lub szybciej?”. Oczywiście wszystko jest możliwe, ale trzeba pamiętać o zasadzie równowagi między cena-jakość-czas.
Średnio w projektach informatycznych czas i budżet przekroczone są dwukrotnie – Paulo Coelho.
Bez realnego budżetu i harmonogramu, ciężko o sukces projektu. Określenie go z góry też może być świetnym sposobem na weryfikację projektu. Jeśli planujesz zrobić drugi Google Maps, a Twój budżet to 100.000 złotych, to mądry Dostawca, uświadomi Ci, że masz duże szanse stracić bezpowrotnie pieniądze i nie otrzymać konkurencyjnego produktu. Jeśli planujesz to zrobić w czasie krótszym niż 3 miesiące, to także jest okazja na weryfikację założeń lub rezygnację na samym początku.
Tutaj dodam osobiste spostrzeżenie – prawie zawsze obie strony zakładają czas „bez poślizgów”, a Zlecający często wywiera presję „czy da się taniej lub szybciej?”. Oczywiście wszystko jest możliwe, ale trzeba pamiętać o zasadzie równowagi między cena-jakość-czas.
4. Ustal osoby odpowiedzialne za kontakt i kontrole nad postępami
Po pierwsze – musi być jasne, kto podejmuje wiążące decyzje, a kto jedynie ma głos doradczy. Inaczej masz zapewnioną blame-game po etapie projektu, gdy przyjdzie do odbioru rezultatu. Po drugie, tylko nie tylko osoby techniczne nadają się do nadzorowania projektów IT.
Ja to nazywam „metodą na babcię”. Babcia bowiem nie pomaga w programowaniu, nawet nie wie co się tam dzieje, ale badania potwierdzają, że sama obecność „babci” i co jakiś czas zadawane pytania, sprawiają, że zespół ma poczucie, że przed kimś odpowiada oraz że ktoś faktycznie interesuje się ich postępami prac. Oczywiście im więcej wiedzy technicznej posiadasz i znasz standardy rozwoju oprogramowania, tym lepiej, ale naprawdę nie jest to konieczne by co tydzień odpytać zespół lub wyznaczoną osobę o zaprezentowanie wyników prac. Nigdy nie żałuj czasu na takie działania.
Po pierwsze – musi być jasne, kto podejmuje wiążące decyzje, a kto jedynie ma głos doradczy. Inaczej masz zapewnioną blame-game po etapie projektu, gdy przyjdzie do odbioru rezultatu. Po drugie, tylko nie tylko osoby techniczne nadają się do nadzorowania projektów IT.
Ja to nazywam „metodą na babcię”. Babcia bowiem nie pomaga w programowaniu, nawet nie wie co się tam dzieje, ale badania potwierdzają, że sama obecność „babci” i co jakiś czas zadawane pytania, sprawiają, że zespół ma poczucie, że przed kimś odpowiada oraz że ktoś faktycznie interesuje się ich postępami prac. Oczywiście im więcej wiedzy technicznej posiadasz i znasz standardy rozwoju oprogramowania, tym lepiej, ale naprawdę nie jest to konieczne by co tydzień odpytać zespół lub wyznaczoną osobę o zaprezentowanie wyników prac. Nigdy nie żałuj czasu na takie działania.
5. Z góry ustal jaka jest definicja wykonania zadania lub zamknięcia etapu
Definition of Done, to jedno z podstawowych kryteriów, które zmitygują przyszłe konflikty. Bardzo często Wykonawca twierdzi, że zrobił i działa. Ale w opinii Zamawiającego jest zupełnie inaczej. Klient może poprosić o „zmianę przycisku” w widoku aplikacji (frontend). Jego zmiana to chwila dla programist, ale taka akcja pociąga za sobą zmiany pod spodem aplikacji (backend). Dlatego zamawiając każde zadanie warto określić w jakim przypadku uznajemy to zadanie za faktycznie zakończone / wykonane.
Definition of Done, to jedno z podstawowych kryteriów, które zmitygują przyszłe konflikty. Bardzo często Wykonawca twierdzi, że zrobił i działa. Ale w opinii Zamawiającego jest zupełnie inaczej. Klient może poprosić o „zmianę przycisku” w widoku aplikacji (frontend). Jego zmiana to chwila dla programist, ale taka akcja pociąga za sobą zmiany pod spodem aplikacji (backend). Dlatego zamawiając każde zadanie warto określić w jakim przypadku uznajemy to zadanie za faktycznie zakończone / wykonane.
6. Zadbaj o dokumentację
Gdy prowadzę audyty dla dużych klientów, pierwsze pytanie jakie zadaje to: „gdzie jest dokumentacja”. Zamawiający bardzo często nie wie, nie ma wglądu lub zakłada, że sporządza ją Wykonawca. Owszem, często wykonawca zapisuje komentarze w kodzie oprogramowania, ale znacznie rzadziej niż bym się tego spodziewał, tworzy ją na bieżąco. To duży błąd. Dziś wiele programów pozwala na półautomatyczne generowanie dokumentacji. Jej brak dodatkowo uzależnia nas od danego dostawcy, a nawet osób które pracują w projekcie z ramienia danego zamawiającego.
Gdy prowadzę audyty dla dużych klientów, pierwsze pytanie jakie zadaje to: „gdzie jest dokumentacja”. Zamawiający bardzo często nie wie, nie ma wglądu lub zakłada, że sporządza ją Wykonawca. Owszem, często wykonawca zapisuje komentarze w kodzie oprogramowania, ale znacznie rzadziej niż bym się tego spodziewał, tworzy ją na bieżąco. To duży błąd. Dziś wiele programów pozwala na półautomatyczne generowanie dokumentacji. Jej brak dodatkowo uzależnia nas od danego dostawcy, a nawet osób które pracują w projekcie z ramienia danego zamawiającego.
7. Bądź elastyczny
Zarówno zlecający jak i dostawcy oprogramowania, skarżą się, że mają związane ręce dokumentacją, zamówieniem, wymaganiami. Wymagania są niezbędne, by precyzyjnie określić co algorytm ma wykonać i tego nie da się uniknąć. Natomiast często zawodzi komunikacja między stronami i realizowane jest zadanie, które niczemu nie służy. Dlatego niezbędna jest okresowa weryfikacja wymagań – najlepiej z użytkownikami docelowymi. Warto też pomyśleć o zleceniu audytu firmie zewnętrznej, który pozwoli wychwycić punkty, w których obie strony zapętliły się i nie widzą innego wyjścia z sytuacji. Koszt takiego audytu jest wielokrotnie tańszy, niż czas i pieniądze poświęcone na błędy, jakie mogą wyniknąć z błędnych decyzji.
Zarówno zlecający jak i dostawcy oprogramowania, skarżą się, że mają związane ręce dokumentacją, zamówieniem, wymaganiami. Wymagania są niezbędne, by precyzyjnie określić co algorytm ma wykonać i tego nie da się uniknąć. Natomiast często zawodzi komunikacja między stronami i realizowane jest zadanie, które niczemu nie służy. Dlatego niezbędna jest okresowa weryfikacja wymagań – najlepiej z użytkownikami docelowymi. Warto też pomyśleć o zleceniu audytu firmie zewnętrznej, który pozwoli wychwycić punkty, w których obie strony zapętliły się i nie widzą innego wyjścia z sytuacji. Koszt takiego audytu jest wielokrotnie tańszy, niż czas i pieniądze poświęcone na błędy, jakie mogą wyniknąć z błędnych decyzji.
Podsumowując, określ wymagania w stosunku do oprogramowania, który tworzysz, pilnuj każdego etapu domagając się dokumentacji oraz dzieląc projekt na etapy. Nie zapomnij, że warto być skrupulatnym, ale i elastycznym, a co najważniejsze, że wcale nie musisz być programistą, by nadzorować projekt informatyczny.
Powodzenia!
masz pytania: pisz na krzysztof.wojewodzic(at)escola.pl
Reklama.