Wsparcie dla gotowych stron internetowych

Przez ostatnie pół roku w Droptica  pracowaliśmy nad utworzeniem zorganizowanego i ustrukturyzowanego zespołu wsparcia. Jestem zadowolony, mogąc teraz napisać, że nasz support jest pierwszorzędny. W tym wpisie wyjaśnię pokrótce, dlaczego zdecydowaliśmy się utworzyć osobny zespół wsparcia.

Droptica zaczęła jak wiele innych zespołów deweloperskich, z grupą programistów pracujących nad bieżącymi zadaniami, takimi jak nowa strona dla klienta albo dodatkowy element na istniejącej. Podobnie jak inne małe agencje drupalowe, zarządzaliśmy zadaniami, najlepiej jak potrafiliśmy: zadania najpilniejsze, o najwyższym priorytecie, były wykonywane najpierw. Ten system z czasem jednak stał się niewystarczający. 

Rozwój i zmiany

W ciągu ostatnich dwóch lat nastąpiły duże zmiany, tak w Droptica, jak i w samym Drupalu.

Projekty na Drupalu stały się większe. Drupal przesuwa się zdecydowanie w kierunku rynku zastosowań korporacyjnych i bardziej złożonych projektów. Trzy lata temu ukończenie typowego projektu na Drupalu wymagało jednego lub dwóch programistów i kilku miesięcy pracy. Obecnie jest to 5-6 deweloperów pracujących w pełnym wymiarze godzin przez długi czas. Tworzone przez nas projekty są naprawdę ogromne, skomplikowane i wymagają wiele uwagi. 

Oczekiwania co do jakości i niezawodności kodu również wzrosły, kiedy zaczęliśmy świadczyć usługi większym klientom. Tam, gdzie serwisy obciążone są większym ruchem, a błędy skutkują poważnymi konsekwencjami, oczekuje się perfekcji działania. Dobra organizacja procesów jest niezbędna, aby utrzymać stale wysoki standard. 

Droptica się rozwinęła. Liczba pracowników zwiększyła się o 30% w ciągu ostatniego roku i o 100% w przeciągu ostatnich 2 lat. Obsługujemy dziś więcej klientów i wspieramy więcej stron internetowych niż kiedykolwiek. To bardzo ekscytujące, ponieważ pozwala nam na zdobywanie wiedzy szybciej i zajmowanie się naprawdę ciekawymi projektami. Jest też niestety źródłem pewnych trudności:

1. Jeśli zostanie wydana aktualizacja bezpieczeństwa dla Drupala, musimy ją wprowadzić na ponad 100 stronach, tak szybko, jak to jest możliwe.
2. Nie ma jednej osoby, która znałaby wszystkie projekty. Jest ich po prostu za wiele. 

Te powody sprawiły, że byliśmy zmuszeni przeorganizować naszą pracę.

Zaczęliśmy używać SCRUM

Podejścia Agile używaliśmy już wcześniej, ale w 2018 roku całkowicie przeszliśmy na metody zwinne. Możemy teraz śmiało stwierdzić, że jesteśmy agencją Agile. Używamy metody SCRUM na wszystkich projektach, którymi się zajmujemy. Większość naszych działań wewnętrznych również wykorzystuje podejście SCRUM.

SCRUM jest świetny. Pozwala nam zachować wysoką jakość, tempo prac i zorganizowanie, nawet kiedy działamy z dużymi projektami. Nasi klienci cenią sobie przewidywalność i kontrolę, jaką mają nad procesem dewelopmentu. Pisaliśmy już o korzyściach płynących z pracy w SCRUM i o komunikacji w zespole scrumowym. 

SCRUM nie radzi sobie ze wsparciem

Bardzo cenię sobie SCRUM, jednak, pomimo wszystkich zalet takiego podejścia, nie jest ono najlepsze dla wsparcia serwisów.

1. Zapytania supportowe często "wpadają" w ostatniech chwili i nie mogą poczekać "do następnego Sprintu" (np. następne trzy tygodnie).
2. Trudno przewidzieć, ile godzin pracy będzie trzeba przeznaczyć na wsparcie.
3. Debugowanie błędów niekiedy zajmuje więcej czasu niż sama naprawa. Ocena czasochłonności jest często skomplikowana. 

Zespół SCRUM nie może supportować stron "w międzyczasie"

Zespół pracujący nad rozwojem serwisu w metodzie SCRUM nie może w międzyczasie zajmować się wsparciem innych stron. Sprinty w SCRUM są relatywnie krótkie (zazwyczaj ok. 2 tygodni) i przypisane zadania powinny być w tym czasie ukończone. Jeśli zespół ma określoną prędkość (ilość zadań, które mogą ukończyć w Sprincie), dokładanie im dodatkowych zadań z zakresu wsparcia sprawi, że cel Sprintu nie zostanie osiągnięty. Nieukończone zadania uniemożliwią skuteczne przewidywanie dat wydań projektu.

Alternatywą jest pozostawienie zespołowi bufora czasu na nieplanowane zadania supportowe, jeśli jakieś pojawią się w trakcie Sprintu. Nasze próby pokazują jednak, że nie jest to zbyt skuteczny mechanizm. Zespół musi odrywać się od pracy nad jednym projektem i przenosić na drugi zbyt często i przez to niedomaga cały projekt.

Z naszego doświadczenia wynika, że system, w którym zespół deweloperski skutecznie supportuje projekt, działa wyłącznie, gdy jest to projekt, nad którym aktualnie pracują. Ukończone serwisy, które nie wymagają już działania pełnego zespołu, powinny być zarządzane w inny sposób. 

Wprowadzenie zespołu Drupal Support

Po wypróbowaniu różnych podejść do zagadnienia zdecydowaliśmy, że najlepszym rozwiązaniem jest dedykowany zespół supportujący Drupala. Zespół ten opiekuje się wszystkimi stronami i serwisami, które nie mają aktywnego zespołu deweloperskiego. To oznacza wszystkie strony, które wymagają mniej, niż wynosi jeden pełny etat pracy programisty. 
Jeśli wspierana strona nagle potrzebuje dostarczenia większej funkcjonalności lub więcej pracy, kompletujemy zespół programistów, którzy przejmują serwis. Po skończeniu prac strona wraca pod opiekę zespołu wsparcia.

Testowaliśmy takie podejście przez ostatnich sześć miesięcy i okazało się to być rozwiązaniem, na którym najbardziej można polegać. Jest tak dobre, że w tej chwili  oferujemy support jako osobny serwis. 

Sprawdź naszą ofertę wsparcia dla Drupala.