R&D – jak przeprowadzić zmiany w projekcie?
Pisze do mnie wielu początkujących kierowników projektu z pytaniami na temat przeprowadzania zmian w projekcie – implementacji nowych funkcji. W tym wpisie opisałem jak podzielić ten proces na etapy, które pomogą nam przeprowadzenie udanych zmian na naszym projekcie. Zapraszam do lektury!
R&D – znaczy research and development. W IT przyjęło się określać tym mianem wdrażanie nowych funkcjonalności do produktu lub tworzenie nowych aplikacji, które w obu przypadkach są poprzedzone analizą przedwykonawczą.
Proces jaki zastosujesz zależy od klienta, twojego zespołu oraz organizacji, w której pracujesz – nie ma „jedynego słusznego” sposobu rozwój projektu. Ja opiszę ten, który najlepiej sprawdza się od dłuższego czasu we współpracy z pewnym klientem.
Cały proces R&D zaczyna się od przysłania zapytania od klienta z krótkim opisem co chciałby zmienić lub nowego wdrożyć. Warto zaznaczyć, że na tym etapie klient prawdopodobnie nie ma zielonego pojęcia na temat ceny jaką zapłaci za swój pomysł, więc pierwszym krokiem będzie wstępna wycena.
1. wstępna wycena z krótkim opisem
Moim zdaniem na ten etap trzeba poświęcić jak najmniej czasu – chodzi tylko o określenie rzędu wielkości wyceny konkretnego potencjalnego wdrożenia. Klient musi ocenić czy gra jest „warta świeczki”. Wstępne oszacowanie nie jest jedynym elementem, który musimy wykonać na tym etapie. Niezbędne jest też zdobycie wiedzy na temat tego czy pomysł jest możliwy do wykonania. W projektach zdarzają się sytuację, że wykonanie prostych zmian może nie być wykonalne, np w przypadku gdy nie przechowujemy konkretnych danych, które są kluczowe w pomyśle klienta.
Dodatkowym elementem tego etapu jest sporządzenie, krótkiej notatki, która sparafrazuje to co zamierzasz zmienić w systemie na podstawie opisu klienta oraz jak zrozumiałeś jego opis. Jest to istotne szczególnie na tym etapie, bo to właśnie w nim występuje najwięcej „rozjazdów” względem tego co opisane, a tym co siedzi nam w głowach. W tym wpisie opisałem jakie powinniśmy mieć podejście do wykonania analizy przedwykonawczej.
Przygotowany dokument wraz z wstępną wyceną wysyłamy do klienta i czekamy czy uzna, że warto implementować daną funkcję w sugerowanym budżecie. Ważne jest by klient zdawał sobie sprawę z tego, że jest to wstępna wycena – która może (ale nie musi) odbiegać kilka procent od finalnej wyceny.
Wskazówka: warto uwzględnić w wycenie również szacowany czas przeprowadzania analizy przedwykonawczej konkretnego wdrożenia.
2. Przygotowanie dokumentu analitycznego
Jeśli mamy zaakceptowane wstępne koszta realizacji, musimy przejść do wykonania analizy przedwykonawczej. Na tym etapie musimy już bardzo dokładnie opisać co zrozumieliśmy z opisu klienta – musimy mieć pewność, że mówimy dokładnie o tym samym. Według mnie dokument analityczny powinien opisywać projekt w negatywnym świetle. Oprócz analizy problemu, w dokumencie powinna znajdować się również synteza rozwiązania – czyli jego zaplanowanie. Finalna wersja dokumentu powinna odpowiedzieć klientowi na pytanie „co zyskam jak zrealizujecie tę funkcję?”, a programistom „jak zrealizować tę funkcję by była zgodna z oczekiwaniami?”.
Do dokumentu powinniśmy dołączyć bardzo szczegółową wycenę z precyzyjnie określonymi czasami realizacji. O tym jak dokładniej wyceniać zadania pisałem już na swoim blogu. Tak jak pisałem we wcześniejszym punkcie – wycena po analizie może odbiegać od wstępnej wyceny z tego względu, że po dokładniejszym przeanalizowaniu problemu wiemy o nim więcej i jesteśmy w stanie bardziej realnie ocenić jego skomplikowanie. Jeśli wycena się zwiększy, warto przygotować sobie odpowiedź dla klienta co było przyczyną – gwarantuję, że o to zapyta 😉
W dokumencie również powinna być informacja na temat tego, kiedy zaczniemy prace, kiedy je ukończymy oraz na kiedy zaplanowane są testy klienta. Jeśli termin zaczęcia prac jest odległy – będzie nam ciężko, ale warto żebyśmy określili zasoby, które będą wykonywały dane wdrożenie. Sytuację trzeba ocenić względem takich zależności jak urlopy, inne wdrożenia oraz inne czynniki, które są istotne w twojej organizacji.
Etap ten kończy się podpisanym dokumentem zlecenia na wykonanie wdrożenia.
3. Realizacja w środowisku developerskim
Wiemy co trzeba zrobić, wiemy jak – czas na realizację. W zależności od tego jak podzieliłeś pracę i jakie wyznaczyłeś mile stones – pilnujesz postępu prac. Programiści skończone fragmenty wdrażają na środowisko developerskie do którego klient nie ma dostępu. Możesz posiłkować się na tym etapie testerami – jeśli wdrożenie tego wymaga. Jeśli udało ci się sprawdzić poprawność działania zmian – czas na wdrożenie na kolejne środowisko – staging / pre production.
W tym etapie warto opracować sobie wstępny proces wdrożenia na produkcję – możesz w tym celu sporządzić dokument, w którym opiszesz jakie kroki trzeba podjąć do wdrożenia funkcji. Często zdarza się programistom zapomnieć o wrzuceniu plików trzymanych poza repozytorium, podmienienia schematu bazy danych czy wprowadzić zmiany w konfiguracji serwera. To jest dobry czas by pomyśleć o takich rzeczach, żebyśmy nie byli niczym zaskoczeni podczas wdrażania na produkcję.
4. Realizacja w środowisku staging / pre production
Ten etap jest analogiczny do realizacji na środowisku developerskim. Na stagingu dane powinny być bardziej zbliżone do tych na produkcji (ale oczywiście nie takie same ;)). Na środowisku developerskim często dane znacznie odbiegają sytuacji, która jest spotykana na produkcji, często programiści zmieniają ID „z palca” co powoduje występowanie dziwnych sytuacji, które mogą nie być powtórzone na produkcji. W związku z tym, że na stagingu mamy zbliżone dane – warto jeszcze raz przetestować całe wdrożenie przez testerów, żeby wdrożenie na produkcji było obarczone mniejszym ryzykiem.
W poprzednim etapie mieliśmy wstępnie opisany dokument wdrożenia – warto go zweryfikować po wdrożeniu na staging czy nie przyszło nam coś nowego do głowy oraz to co napisaliśmy wcześniej nie uległo zmianie 😉
5. Testy klienta na staging / pre production
Kiedy wewnętrznie potwierdziliście sobie, że macie zrealizowane funkcje według dokumentacji i produkt jest wolny od bugów – czas zaprosić klienta na testy. Warto ustalić z klientem czas jaki ma na testowanie produktów – żeby uniknąć sytuacji, gdy będziemy dostawać odpowiedź od klienta „przetestuję w przyszłym tygodniu” – przez miesiąc.
Po testach klienta, i naprawie ewentualnych zgłoszonych bugów jesteśmy gotowi do wdrożenia na produkcję. Na tym etapie często zdarza się, że klient uświadamia sobie, że jednak „XYZ powinna wyglądać/działać trochę inaczej” – warto być konsekwentnym i nie robić tych zmian na gorąco przed wdrożeniem tylko potraktować te zmiany jak osobny proces R&D. Oczywiście nie mówię tutaj o popadaniu w skrajność, że będziemy robić wyceny dla zmiany tekstu labela na stronie – mówię o zmianie w logice systemu. Czym jesteśmy bardziej asertywni tym lepiej dla nas – nie skracajmy naszego procesu testów i analizy. Natomiast jeśli taka sytuacja się zdarzy, że klient będzie chciał zmian przed wdrożeniem – bardzo często jest to sygnał dla nas, że analiza przedwykonawcza mogła zostać zrobiona lepiej bo nie udało nam się odkryć faktycznych potrzeb klienta.
Etap ten kończy się potwierdzeniem klienta, że zmiany są gotowe do wdrożenia na produkcję.
6. wdrożenie na produkcję
Etap, w którym poziom stresu jest najwyższy. Nie rób wdrożeń w piątek – najlepiej żeby były na początku tygodnia i zaczynały się na początku dnia. Chyba, że specyfika projektu wymaga wdrożeń nie przerywając działania systemu dla używających go – wtedy warto wykonać wdrożenie np w godzinach nocnych.
Wykorzystaj dokument, w którym spisywałeś wskazówki na temat wdrożenia i postępuj zgodnie z nim – korygując błędy popełnione podczas wdrożenia na dev i stagingu.
Mimo, że nowe funkcje są przetestowane – przygotuj się na wzmożoną aktywność zgłoszeń – mimo to zdarzają się błędy. Dużo użytkowników może zgłaszać zapytania na temat działania nowych funkcjonalność bo będą zdziwieni np nową zakładką. Warto poprosić klienta by wcześniej zakomunikował użytkownikom o nowych elementach systemu i uprzedził o ewentualnych pracach konserwacyjnych.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Podsumowanie
Tak jak mówiłem, nie ma jedynego słusznego sposobu na przeprowadzenie R&D – każda organizacja powinna go mieć dostosowanego do swoich potrzeb. Ja opisałem ten, który najlepiej sprawdza się w moim przypadku. Jestem ciekawy jak to wygląda u ciebie – opisz go proszę pokrótce w komentarzu.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
