Wasze metodyki pracy w agencjach internetowych

Cześć,

Mam do was pytanko na temat metodyk pracy w waszych firmach.

Moja firma to typowa agencja. Mamy dużo małych projektów ze znikomym ruchem i kilka takich z dziesiątkami tysięcy odsłon dziennie. Przy tych małych pracują mniej doświadczeni programiści a przy tych większych ci bardziej doświadczeni. W mojej pracy zarówno do tych małych jak i dużych projektów tworzonych przez początkujących i zaawansowanych programistów stosuje się taki sam workflow. Gdy chcemy zrobić deploy na produkcję to projekty wrzucamy na serwer testowy i zgłaszamy do działu QA. Dział QA sprawdza stronę i jak jest ok to wysyła to na produkcję. Taki standardowy, najprostszy z możliwych workflow.

Z pozoru taka metodyka wydaje się ok ale w praktyce rodzi to wiele problemów. Pierwszym z nich jest mizerna ilość deployów jakie możemy zrobić. Jest to 1 lub 2 na tydzień bo częściej nie wyrabia dział QA. Problem jest taki, że niezależnie od tego czy robimy nowy moduł w serwisie czy poprawiamy literówkę musi przejść to przez dział QA. Czasami uda się dogadać z nimi aby nie testowali całej strony przy drobnych poprawkach ale zwykle są niechętni bo odpowiedzialność za niedziałający projekt na produkcji spada na nich. Ja natomiast uważam, że to wyjątkowo nieprofesjonalne, że klient musi czekać od kilku godzin do kilkunastu na poprawkę literówki na stronie.

Drugim problemem jest kiepska współpraca z adminem. Jeśli chcemy zajrzeć do logów albo jest jakiś krytyczny błąd a nie ma admina nic nie możemy zrobić. Ostatnio wyłapaliśmy na jednej ze stron bardzo poważny błąd po godzinie 17. Żeby go zdebugować potrzebowałem dostępu do logów Symfony i musieliśmy z tym czekać do rana aż przyjdzie admin. Klient nie był zbyt szczęśliwy.

Osobiście uważam, że oba te problemy rozwiązało by kilka zmian, a przede wszystkim:

1. VPS per projekt (np. Docker) z dostępem dla programistów do sytuacji awaryjnych albo przynajmniej konta z dostępem do plików projektu na serwerze dla programistów którzy pracują nad projektem.

2. Możliwość pominięcia działu QA dla prostych przypadków pod warunkiem zaimplementowania do projektu testów automatycznych (Yahoo np. zrezygnowało całkiem z QA na rzecz testów automatycznych).

Mi się wydaje, że powyższe zmiany są bezpieczne i z tego co widzę całkiem popularne wśród firm IT. Wystarczyłoby tylko kontrolować, czy nikt nie nadużywa dostępów ale w mojej firmie osoby decyzyjne w IT są przeciwko bo: "kiedyś ktoś miał dostęp i popsuł". Mam wrażenie, że bardziej skupiają się na chronieniu swoich tyłków niż na pracy dla klientów.

Jestem ciekaw, czy może istnieją inne lepsze rozwiązania problemów o których pisze. Będę bardzo wdzięczny za wskazówki :)

Po pierwsze, to nie powinno być działu QA, tylko każdy zespół deweloperski powinien mieć swoich testerów, którzy rozumieją produkt i zmiany w nim zachodzące. No i testerów powinna być wystarczająca liczba, a nie jeden na dwudziestu programistów.

Po drugie, od naprawiania błędów na produkcji jest dział zwany supportem, a nie deweloperzy. Mają dostęp do logów, wjazd na serwery, potrafią programować, i biorą za wszystko odpowiedzialność. Łaska adminów nie jest wtedy do szczęścia potrzebna.

somekind napisał(a):

Po pierwsze, to nie powinno być działu QA, tylko każdy zespół deweloperski powinien mieć swoich testerów, którzy rozumieją produkt i zmiany w nim zachodzące. No i testerów powinna być wystarczająca liczba, a nie jeden na dwudziestu programistów.

W teorii tak być powinno. W praktyce brakuje funduszy. Jakieś pomysł na rozwiązanie nie wymagające zatrudniania kolejnych ludzi?

somekind napisał(a):

Po drugie, od naprawiania błędów na produkcji jest dział zwany supportem, a nie deweloperzy. Mają dostęp do logów, wjazd na serwery, potrafią programować, i biorą za wszystko odpowiedzialność. Łaska adminów nie jest wtedy do szczęścia potrzebna.

Tego raczej nie widzę. To ma sens przy jednym produkcie. Przy wielu myślę, że developerzy projektu który zna go najlepiej najszybciej rozwiąże problem.

Ale taki system pracy działa i się sprawdza w różnych firmach. Supportowcy też znają produkty, którymi się opiekują i potrafią rozwiązywać problemy z nimi związane.

somekind napisał(a):

Ale taki system pracy działa i się sprawdza w różnych firmach. Supportowcy też znają produkty, którymi się opiekują i potrafią rozwiązywać problemy z nimi związane.

U nas jest 20 programistów, zespoły składają się z 2 programistów a więc firma tworzy na raz 10 projektów, jeden projekt jest tworzony przez 2-6 miesięcy a sama firma ma blisko 150 aktywnych projektów więc wątpię, by support ogarniał je wszystkie. Niestety jest to takie typowe hurtowe tworzenie stron.

Poza tym znowu wymaga to zatrudniania nowych ludzi. Dlaczego roli supportu nie mogą przejąc developerzy?

2. Możliwość pominięcia działu QA dla prostych przypadków pod warunkiem zaimplementowania do projektu testów automatycznych (Yahoo np. zrezygnowało całkiem z QA na rzecz testów automatycznych).

Powinniście mieć jakieś testy automatyczne, i to dużo. Nie mówię, że potrzebę przeklikania można wyeliminować zawsze i w 100%, ale jeśli nie macie testów automatycznych, albo macie ich mało, to potem nie dziwne, że firma traci czas (a co za tym idzie, można się domyślać, że i pieniądze bo przecież wolniej robicie niż moglibyście to robić z automatyką - i to jest btw dobry argument dla kierownictwa)

LukeJL napisał(a):

2. Możliwość pominięcia działu QA dla prostych przypadków pod warunkiem zaimplementowania do projektu testów automatycznych (Yahoo np. zrezygnowało całkiem z QA na rzecz testów automatycznych).

Powinniście mieć jakieś testy automatyczne, i to dużo. Nie mówię, że potrzebę przeklikania można wyeliminować zawsze i w 100%, ale jeśli nie macie testów automatycznych, albo macie ich mało, to potem nie dziwne, że firma traci czas (a co za tym idzie, można się domyślać, że i pieniądze bo przecież wolniej robicie niż moglibyście to robić z automatyką - i to jest btw dobry argument dla kierownictwa)

Wiem, że powinniśmy ale szefostwo czas testów wrzuca w koszty obsługi serwisu więc i tak płaci za to klient, A jak przyspieszymy prace to klient będzie więcej wymagał - a najlepiej aby płacił i nie wymagał. Więc dla ludzi excela testy automatyczne się... nie opłacają. Klient jak widać u nas nie jest ważny. Moja firma to beznadziejny przypadek.

Tym tematem po prostu chciałem otworzyć dyskusję na temat praktyk w waszych firmach i ciekaw jestem co sądzicie m.in. o moim pomyśle pominięcia QA w tych prostych przypadkach. Najbardziej ciekawią mnie praktyki pozwalające zmniejszyć czas wdrożenia na produkcję zmian bez zwiększania ryzyka.

Innymi słowy klient się rozlicza z firmą za czas a nie za rezultaty, więc w zasadzie opłaca sie wam troche pobumelować. Bo im dluzej to robicie, tym wiecej czasu to zajmie, wiec wiecej pieniazkow klient bedzie musial zaplacić. A im szybciej zrobicie, tym wiecej bedziecie musieli robić, wiec opłaca sie poudawać troche, ze sie pracuje.

Ale w takiej kulturze pracy (pomijając juz jej etykę) to w zasadzie jeśli są jakieś przestoje, to lepiej nawet. Jeśli np. poprawienie literówki trwa kilka dni, to lepiej dla was, bo przez ten czas możecie pić sobie kawę czy grać w piłkarzyki, oglądać koty, whatever, a i tak firma na was zarabia, skoro klient płaci za dupogodziny a nie za efekty.

Moja firma to beznadziejny przypadek.

mało rozwojowa na pewno. Ja bym zmienił.

MichaelThePlatypus napisał(a):

U nas jest 20 programistów, zespoły składają się z 2 programistów a więc firma tworzy na raz 10 projektów, jeden projekt jest tworzony przez 2-6 miesięcy a sama firma ma blisko 150 aktywnych projektów więc wątpię, by support ogarniał je wszystkie. Niestety jest to takie typowe hurtowe tworzenie stron.

Jak hurtowe i w krótkim czasie, to raczej nie są skomplikowane projekty. Macie jakąś spójną architekturę i konwencje? Bo jeśli tak, to co za problem ogarnąć wiele bliźniaczych projektów?

Poza tym znowu wymaga to zatrudniania nowych ludzi. Dlaczego roli supportu nie mogą przejąc developerzy?

Bo developerzy mają skończyć projekt, a potem zająć się następnym.

Tego raczej nie widzę. To ma sens przy jednym produkcie. Przy wielu myślę, że developerzy projektu który zna go najlepiej najszybciej rozwiąże problem.

No nie wiem. Ostatnio na przykład jedna z klientek (wybitnie nie-techniczna) miała następujące problemy:

• wchodzi na stronę a tam 404!!!! RATUNKU CO SIĘ DZIEJE!!! - zły adres wpisywała...
• maile z formularza na stronie jej nie docierają (jak w panelu wpisać jakikolwiek inny adres, to działają, na jej adresie nie działają),
• zapomniała hasła do panelu hostingu.

Po kiego grzyba w ogóle angażować programistę do tego typu problemów...? Czy ja po to studiowałam tyle lat, po to spędziłam tyle nocy nad kodem, żeby teraz szukać literówek na screenach od klienta...? No chyba nie...
No i jak bardzo dobrze trzeba znać produkt, żeby skonfigurować serwer SMTP?

Jest support i jest support.
Ja pracowałem jakiś czas w takim(przy czym nie było to sformalizowane przez większość czasu):

1. Od pierdół typu 404 jest pierwsza linia(telefonistka jak w orange)
2. Później kolejna linia to ktoś z dyżurem(programista z działu supportu bądź tester znający z grubsza kilka systemów, wie kogo odpytywać i o co, a jeżeli to programista to umie naprawić sporo błędów programistycznych o ile nie wymagają przeorania połowy systemu lub znajomości skompilowanej logiki biznesowej)
3. Jak i to nie pomaga to angażuje się tego kto napisał coś co nie działa(jak pół systemu przestaje działać, lub dopiero znaleziono poważny błąd po np kilku latach działania co niestety może się zdarzyć, ale wtedy taka osoba już pracuje gdzie indziej)
4. Jak to dalej nie syatarcza, a problem jest poważny to wszystkie(programiści wsparcia, programiści, analitycy, admini, architekci a nawet PM) ręce na pokład. To jest moment kiedy szansa na to, że g*wno wpadnie w wentylator jest bardzo poważne lub pewne wię trzeba minimalizować zniszczenia i negocjować z klientem.

aurel napisał(a):

Po kiego grzyba w ogóle angażować programistę do tego typu problemów...? Czy ja po to studiowałam tyle lat, po to spędziłam tyle nocy nad kodem, żeby teraz szukać literówek na screenach od klienta...? No chyba nie...

Ok, ale to ma się nijak do mojego pierwszego postu. Ja nigdzie nie pisałem o pierdołach zgłaszanych przez klientów. Dyskusja potoczyła się w tym kierunku i kompletnie nie mam pojęcia dlaczego bo w ogóle o tym nie pisałem ;)

U nas poza małymi stronkami mamy też kilkanaście kobył które nawet dla osób pracujących na co dzień z nimi są trudne do ogarnięcia. Mamy w firmie ogarniętych PM-ów którzy potrafią pomóc klientowi z pierdołami i odfiltrowują głupoty od poważnych problemów (raczej nie mamy aż tak masowych produktów w których użytkownicy zalewają nas swoimi problemami). Sytuacja komplikuje się wtedy, gdy rozwiązanie problemu wymaga zerknięcia do produkcyjnej bazy danych albo logów serwera produkcyjnego. Polityka mojej firmy wygląda tak, że tylko admin ma tam dostęp a do deploymentu kodu na produkcję tylko QA.

Gdy chcemy naprawić problem szybko to bieganie do admina z pytaniami: "a sprawdź to na serwerze..." cholernie spowalnia pracę. Gdy admin jest chory, zawalony robotą albo już poszedł do domu to dosłownie nie możemy pracować i możemy jedynie zgadywać co nie działa. A gdy skończymy poprawki później niż o 16:50 to możemy zapomnieć o deployu bo cały dział QA już jedzie do domu. Dla mnie są to patologiczne sytuacje i ciekaw jestem jak z tym sobie radzicie bez dawania roota każdemu w firmie i zatrudniania ludzi 24/7 :)

Wydaje mi się, że moje dwa pomysły z pierwszego postu byłyby całkiem ok.

MichaelThePlatypus napisał(a):

Gdy chcemy naprawić problem szybko to bieganie do admina z pytaniami: "a sprawdź to na serwerze..." cholernie spowalnia pracę. Gdy admin jest chory, zawalony robotą albo już poszedł do domu to dosłownie nie możemy pracować i możemy jedynie zgadywać co nie działa. A gdy skończymy poprawki później niż o 16:50 to możemy zapomnieć o deployu bo cały dział QA już jedzie do domu. Dla mnie są to patologiczne sytuacje i ciekaw jestem jak z tym sobie radzicie bez dawania roota każdemu w firmie i zatrudniania ludzi 24/7 :)

No i ja Ci dałem właśnie rozwiązanie tego problemu - dział supportu. Czyli doświadczeni programiści z prawami do produkcyjnych systemów i baz. Oni nie muszą biegać po adminach, więc nie tracą czasu, na dodatek są w stanie zrozumieć logi, albo domyśleć się, czemu w bazie pojawiły się jakieś dziwne wpisy, i znaleźć błąd w kodzie. Mogą też wrzucić poprawkę na produkcję i odpowiadają za nią i nie potrzebują testerów. (Testerzy są elementem ścieżki produkcji, a nie utrzymania systemu.)

Co do 24/7 - to już zależy, za co klient płaci. Generalnie normą jest praca w godzinach standardowych + ekstra płatny dyżur telefoniczny.

somekind napisał(a):

No i ja Ci dałem właśnie rozwiązanie tego problemu - dział supportu. Czyli doświadczeni programiści z prawami do produkcyjnych systemów i baz.

Co do 24/7 - to już zależy, za co klient płaci. Generalnie normą jest praca w godzinach standardowych + ekstra płatny dyżur telefoniczny.

Rozumiem Twoje stanowisko tylko ciekaw jestem, czemu takie rozwiązanie byłoby lepsze od stworzenia VPS per projekt i danie dostępu do deployu, bazy danych i stworzenia konta (nie root ale z dostępem do plików projektu i logów) na VPS dla programistów pracujących przy projekcie? Czemu oddzielni ludzie do supportu byliby lepsi od samych programistów pracujących przy tym konkretnym projekcie (z pominięciem juniorów i stażystów)? Jak wspomniałem, u nas per projekt pracuje góra 3 programistów wiec to nie jest tak, że nagle cała firma będzie miała dostępy do wszystkiego. My nie mamy tysięcy problemów które wymagałby zatrudnienia nowych osób a z drugiej strony serio nie wyobrażam sobie oddzielnego działu supportu który zna każdy z ponad 150 projektów zwłaszcza, że mamy też bardziej skomplikowane projekty lub jakieś bardzo przestarzałe które są trudne do zrozumienia.

VPS per projekt i tak dobrze mieć.
A czemu nie dawać programistom dostępu do produkcji? Żeby nie zepsuli. Nikt nie potrafi tak dobrze zepsuć jak programista. :)
No, ale jeśli faktycznie nie ma za bardzo co zepsuć, to być może w Twojej firmie by się sprawdziło Twoje podejście. Tylko jak szefostwo nie chce na to pozwolić, to co zrobisz?