Przez projekt IT rozumiem zespół osób odpowiedzialnych za wytworzenie i dostarczenie oprogramowania realizującego wymagania biznesowe. Wśród nich mamy Interesariuszy, kadrę zarządzającą projektem po stronie dostawcy, developerów oraz zespół specjalistów: od UX, SEO, managerów e-commerce.
Interesariusze najczęściej są właścicielami biznesu rozumianymi jako Zarząd spółek handlowych. Ich rola to zatwierdzenie budżetu na projekt. Nie są techniczni, posługują się językiem nie informatycznym. Kolejna grupa interesariuszy to dyrektor i manager e-commerce, którzy potrzebują określonych funkcjonalności, dzięki którym sklep wyróżni się na tle konkurencji, odpowie na potrzeby swojej grupy docelowej (klientów) a także pozwoli rozwijać się w SEO.
Jak zatem koordynować współpracę osób na różnym poziomie kompetencji bez udziały/ aktywności których projekt nie miałby szans wystartować ? Jest to temat dzisiejszego artykułu.
Język komunikacji
Nie bez powodu w IT istnieją pojęcia story i task. W dużym uproszczeniu story to historyjka czyli cel jaki chcemy osiągnąć. Task to zadanie. Jedno z wielu, które razem tworzą story.
W tej całej “zabawie” chodzi o to aby prostym językiem określić potrzebę i rozpisać ją na pojedyncze zadania, które trzeba zrealizować aby tą potrzebę zaspokoić.
W języku komunikacji ważne jest to jak będziemy te historyjki i taski tworzyć. Powinniśmy określać kim jesteśmy, co chcemy i w jakim celu. Jeśli “orzeczeń” jest więcej to znaczy, że mamy do czynienia z historyjką i musimy ją rozpisać na zadania składowe.
Przykład:
Chcemy, aby nasze oprogramowanie (PrestaShop) było systemem PIM (Product information management). PIM ma pobierać zdjęcia z serwera FTP, wyświetlać inne opisy w zależności od kanału sprzedaży, pobierać gotowy content html od producentów i raportować postępy prac zespołu contentowego.
Jak to tego podejść ?
Tworzymy story: Jako e-commerce manager chcę aby PrestaShop był systemem PIM po to aby zarządzać dystrybucją treści w różnych kanałach z jednego systemu.
Na to story składają się taski:
jako administrator PrestaShop chcę aby zdjęcia pobierały się z serwera FTP do PrestaShop po to aby zautomatyzować ten proces
jako content manager chcę aby w PrestaShop były dodatkowe pola z opisami produktów po to aby dla każdego kanału sprzedaży nie duplikować treści
jako e-commerce manager chcę aby w PrestaShop był moduł raportowania pracy zespołu specjalistów ds. contentu po to abym widział postępy prac
Tworząc komunikację w taki sposób widzimy kto jest interesariuszem systemu, co konkretnie potrzebuje i w jakim celu. Oczywiście wprawa w dobrym opisywaniu tasków i tworzeniu historyjek przychodzi z czasem ale korzyści są ogromne, ponieważ już na samym etapie tworzenia tasków jesteśmy zmuszeni do określenia celu potrzeb jakie mamy w projekcie. To również naturalna selekcja niepotrzebnych funkcjonalności, ponieważ jeśli nie potrafimy podać celu/ korzyści tzn., że takie zadanie będzie przepalonym czasem programistów i project managera.
System do zarządzania projektem
Skoro potrafimy już opisywać historyjki i tworzyć dla nich taski to dobrze by było umieszczać je w miejscu widocznym dla wszystkich interesariuszy. W tym celu powstało takie oprogramowanie jak np. RedMine, ASANA czy JIRA. Osobiście preferuję ten ostatni system bo dla mnie jest najbardziej intuicyjny i wymaga mało “klikania”.
Korzyści płynące z stosowania systemu zarządzania projektami
Naturalna korzyść to jedno miejsce przechowywania naszych wymagań funkcjonalnych. Tworząc task możemy dodać do niego dodatkowy opis, kryteria akceptacji (zakres prac po wykonaniu których uznamy, że nasz task jest zgodny z oczekiwaniami), zdjęcia, załączniki, linki do innych zgłoszeń.
Inne korzyści to:
– przydzielania zadań do członków zespołu
– widok postępu prac (jeśli pracujemy w sprintach o których mowa za chwilę)
– backlog czyli zestaw historyjek/ tasków jakie jeszcze musimy wykonać w kolejnych sprintach
– dostęp z dowolnego miejsca na świecie oraz z urządzeń mobilnych
– powiadomienia e-mail gdy ktoś przydzieli nam zadanie/ doda komentarz/ oznaczy w tasku
Workflow pracy
W większych projektach można wyznaczyć rolę product ownera. Jest to osoba, która w projekcie ma najgorzej, ponieważ łączy interesy wszystkich interesarjuszy a ponad nimi stawia dobro projektu. Co to oznacza w praktyce ? Np. interesriusz zarząd chce projekt za 2 tygodnie a product owner widzi, że zespół projektowy nie jest w stanie dostarczyć MVP projektu w takim czasie dlatego odmawia intreariuszowi zarząd takiego deadline i na sprincie omawia z zespołem projektowym jakie zadania wejdą do kolejnego sprintu oraz czy któreś z zadań zostanie na backlog ponieważ product owner chce okroić zadania, które wchodziły w skład MVP ale z uwagami na oczekiwany szybszy czas wdrożenia ponownie ocenia jakie funkcjonalności nie są kluczowe jako minimalna wartość produktu (sklep internetowy) co pozwala uruchomić projekt produkcyjnie.
Działa to również w drugą stronę. Jeśli zespół projektowy (najczęściej programiści lub dev ops) twierdzi, że wyszły dodatkowe prace po stronie architektury systemu lub musi przenieść projekt na inną technologię to product owner podejmuje decyzję, że data projektu jest zagrożona i bez tych nieprzewidzianych zmian projekt albo zostanie oddany z opóźnieniem względem pierwotnej daty albo zespół musi powiększyć się o dodatkowe zasoby (np. programistów).
Spotkania zespołu
Jeśli pracujemy w sprintach (najczęściej tygodniowych) to mamy planowanie i podsumowanie sprintów. Każdy z członków zespołu na podsumowaniu omawia co wykonał, jakie napotkał problemy w projekcie oraz nad czym chce się skoncentrować w kolejnym sprincie. To dobry czas na ocenę czy projekt idzie zgodnie z harmonogramem i jakie zagrożenia pojawiają się w trakcie jego realizacji.
3 środowiska pracy
Najczęściej w projektach spotykamy 2 środowiska pracy: developerskie/ testowe i produkcyjne lub jeszcze jedno na tzw. hotfixy i wydania nowych wersji (takie testowe +). Po co tyle środowisk ? Celem środowiska testowego (często nazywanego pre-produkcyjnym) to utrzymanie “kopii” rozwiązania produkcyjnego po to aby ocenić jak system (sklep) zachowywałby się w warunkach produkcyjnych czyli tak jak używaliby to klienci i administratorzy. Środowisko produkcyjne to działający produkt (sklep) z którego korzystają klienci. Środowisko pre-produkcyjne to z kolei pierwsza wersja oprogramowania dostępna dla developerów po to aby wykonać na nie hotfix nowych funkcjonalności i bieżące poprawki. Ilość środowisk jest uzależniona od budżetu (3x koszt serwera) i wielkości projektu oraz specyfiki/ przyjętego standardu pracy zespołu projektowego.
Raportowanie
Z systemu np. JIRA da się generować raporty. Programiści a w zasadzie wszyscy użytkownicy systemu zarządzania projektem mogą logować czasy pracy, czyli do konkretnych zadań zgłaszać ile na nie czasu poświęcili. W drugą stronę możemy estymować potrzebny czas na realizację pojedynczego taska i w gotowym raporcie w JIRA sprawdzać jak skuteczne są nasze estymacje względem realizacji.
Podsumowanie
Mam nadzieję, że powyższy artykuł nieco przybliżył dobre praktyki stosowane w zarządzaniu projektami IT w e-commerce i skorzystasz z tej wiedzy w swoim projekcie. Ja nie wyobrażam sobie dzisiaj prowadzenia projektu bez systemu ciągle szukając plików na skrzynce pocztowej od wielu osób. Dobrze sprawdza mi się również dysk google w którym mam uporządkowane dane w poszczególnych folderach, którymi dzielę się z zespołem. Powodzenia !