Jestem liderem zespołu programistów (niedawno przejąłem kontrolę nad nowym zespołem) i ostatecznie jestem odpowiedzialny za utrzymanie wysokiej wydajności, dobrej jakości i zorganizowanych priorytetów.
Mam 6 starszych programistów w moim zespole, ale tutaj czuje się bałagan. Sytuacja polega na tym, że mam do czynienia z wnioskami JIRA z około 10 różnych punktów kontaktowych w naszej firmie i wszystkie one reprezentują różne jednostki biznesowe lub klientów.
Problem, który mam, polega na tym, że moja praca polega głównie na gaszeniu pożarów przez cały dzień i upewnianiu się, że wszystkie problemy są rozwiązywane. Niestety, kultura w naszej firmie była wysoka produktywność (szybkie wydania), ale niska jakość (błędy produkcyjne), a nasi klienci nie zaakceptują nagłego opóźnienia wyników.
Jakie są dobre sposoby radzenia sobie z tym? Mam mnóstwo teorii, ale szukam odpowiedzi od kogoś, kto faktycznie ma doświadczenie zawodowe w takiej sytuacji jak moja.
Oto krótka lista, jak to działa:
- Każdy programista jest odpowiedzialny za określoną aplikację i usługi wchodzące w jej interakcję;
- Wersje są zwykle testowane przez klienta na symulowanym serwerze produkcyjnym, a następnie wdrażane na serwerze na żywo;
- Z każdej aplikacji korzysta średnio 50–80 osób, w sumie 8 aplikacji.
Dzięki
źródło
Odpowiedzi:
Więc muszą zaakceptować słabą jakość, którą otrzymują.
Aby to zmienić , musisz skłonić swoich klientów do zaakceptowania rzeczywistości tworzenia oprogramowania (lub jakiejkolwiek innej produkcji!): Że pośpieszne rzeczy wpływają na jakość.
Stwórz dużą listę rzeczy, które się psują - rzeczy, które są zepsute, czasy, które mieli na co narzekać. Wyjaśnij im przyczynę tych problemów i powiedz im, co chcesz zrobić, aby to zmienić. Wyjaśnij im procent czasu, jaki Twój zespół spędza na wspieraniu i naprawianiu aplikacji na żywo. Jeśli nie zbierasz danych na ten temat, nadszedł czas, aby zacząć (i zbieraj je przez miesiąc, zanim przekażesz informacje klientom).
Znajdź kluczowych interesariuszy w pokoju i powiedz: „czy chcesz naprawić X, czy chcesz dostarczyć Y? Mamy czas tylko na jedno z dwóch”. Uczyń ich odpowiedzialnymi za ustalanie priorytetów i wyraź, że masz ograniczoną pojemność. Jeśli poprosą o coś nowego, zapytaj ich, co są gotowi poświęcić z obecnej mapy drogowej, aby to osiągnąć.
Zapytaj swój zespół, jaki czas i zasoby potrzebują, aby „naprawić problemy” (zarówno pod względem naprawiania podstawowych błędów, jak i pod względem rozwiązywania większych problemów w jakości kodu / architekturze itp.). Uwzględnij te elementy na liście rzeczy, które Twoi interesariusze muszą traktować priorytetowo.
Najlepszą rzeczą, jaką kiedykolwiek zrobiłem w mojej obecnej pracy, było umieszczenie 8 najlepszych interesariuszy w pokoju w tym samym czasie i ułożenie stosu 16 kart indeksowych reprezentujących nowe funkcje, o które poproszono. Odsunąłem się od stołu i powiedziałem: „Możemy dostarczyć jeden z nich na raz. W jakiej kolejności chcesz je?” Niech debatować siebie nawzajem nad priorytetem biznesowym zamiast ciebie tkwić w środku.
źródło
Zatrzymaj się, upuść i rzuć. Pożary potrzebują paliwa i często mają formę paniki. Poświęć czas na zarządzanie sobą i zespołem w porządku. Oceń swoich programistów i sprawdź, czy masz takich, którzy nie są wystarczająco wykwalifikowani i / lub nie pracują wystarczająco ciężko, aby uzyskać pożądane wyniki. Zdecyduj, kto zostanie (i postaraj się je zatrzymać), kto potrzebuje trochę nacisku, reszta musi odejść. Oceń wsparcie i narzędzia, które otrzymają programiści, aby upewnić się, że mogą wykonywać swoją pracę. Upewnij się, że testowanie dźwięku, przegląd, kontrola źródła i dokumentacja są przestrzegane. Dobrzy ludzie z dobrymi narzędziami muszą ponosić odpowiedzialność za dobrą pracę.
Musi istnieć system, który wie, co powinien zrobić Twój zespół, nad którym obecnie pracuje i kiedy oczekuje się, że zostanie ukończony. Wiele metod, teorii, oprogramowania, tablic suchościeralnych i karteczek, dokumentów i wiadomości e-mail, aby to zrobić. Spraw, by coś zadziałało, zmuszając wszystkich do tego. Jeśli każdy ma jakiś wkład w system, istnieje większa motywacja do jego przestrzegania.
Lepsze zrozumienie oczekiwań klientów. To może nie być częścią twojej pracy. Mogą istnieć inne osoby, które udają, że ich włosy płoną, ich klienci są niezadowoleni, a niebo spada. To, co robią, a niektórzy są w tym naprawdę dobrzy. Jeśli wszystko jest nagłym wypadkiem, to nic nie jest nagłym wypadkiem, ponieważ nie wszystko się da. Od czasu do czasu zaoferuj możliwość udziału w rozmowach z klientami. Przekonasz się, że wielu „miłych do zrobienia” zamienia się w „przełomowych”, zanim dotrą do zespołu deweloperów. Bądź technicznym liasonem lub inną wymówką, aby pomóc. Składanie obietnic, których nie możesz dotrzymać, jest gorsze niż mówienie im tego, czego nie chcą usłyszeć. Chcemy wykonać dobrą robotę, więc potrzebujemy 8 tygodni, a nie 5. W dłuższej perspektywie będą szczęśliwsi.
źródło
Ostatecznie musisz edukować swoich klientów w zakresie tworzenia oprogramowania i w jak największym stopniu angażować ich w ten proces. To, co teraz widzą, to szybkie dostarczanie nowych funkcji, ale także błędów w oprogramowaniu. Chociaż będą zadowoleni z pierwszego, nie będą (lub nie powinni) być zadowoleni z drugiego.
Musisz im wyjaśnić, że dzięki lepszym procesom, podczas gdy dostarczanie nowego oprogramowania będzie opóźnione o niewielką ilość, będzie mniej błędów (nigdy nie będzie zero). Jeśli zgodzisz się, że jest to droga do przodu, będziesz mógł zacząć wprowadzać procesy potrzebne do odzyskania kontroli nad swoim rozwojem.
Użycie procesu zwinnego może tutaj pomóc, ponieważ sugerują (i w niektórych mandatach wdrożeniowych), że klient jest częścią zespołu. Jeśli bardzo zaangażujesz klientów, zobaczą, co działa i co możesz wyprodukować z pierwszej ręki.
źródło
Moja opinia (z ograniczonym doświadczeniem): Myślę, że są dwa problemy do rozwiązania. Po pierwsze, proces jakości. Czy używasz scrum / waterfall / coś pomiędzy? W scrum możesz dodać dodatkowe zadania do każdej historii: 1, aby wymyślić skrypt testowy / plan, inny, aby go uruchomić, inny do przeglądu kodu itp. W wodospadzie, możesz po prostu dodać te kroki?
Innym problemem jest ogromny problem, który istnieje wszędzie w oprogramowaniu. Zarządzanie oczekiwaniami. To znaczy, że ktoś zaczyna krzyczeć, że potrzebuje przycisku, aby wykonać X, do dostarczenia go.
Jeśli możesz dodać dodatkowe kroki do procesu i ogłosić o nim wielkie fanfary [wdrażamy teraz ten proces jakości: co oznacza mniej czasu na naprawianie błędów! i lepszej jakości wyniki! duże e-maile / spotkania itp., aby dać im znać] i regularnie dostarczać wyniki (ala scrum), pomysł polega na tym, że ci, których dostarczasz, dowiedzą się i zobaczą wartość na dodatkowych etapach procesu, i kupią to. Mniej czasu na naprawianie błędów = więcej czasu na wdrażanie i testowanie funkcji.
Klienci nie zaakceptują nagłego opóźnienia wyników? Prawie muszą. Oczywiste jest, że nie można kontynuować tak, jak jest. Być może możesz dodać dodatkowe kroki kontroli jakości, a następnie w razie potrzeby dodać więcej członków zespołu? Ale kroki jakościowe są absolutnie wymagane.
Ponownie, jeśli używasz scrum lub podobnego, możesz dążyć do tygodniowego sprintu, aby regularnie dostarczać wyniki. To uspokoi ludzi tak samo jak szybki zwrot.
Mam nadzieję, że do pewnego stopnia pomaga… mam nadzieję, że nie przegapiłem sedna sprawy.
źródło
To, co opisałeś, brzmi bardzo normalnie i wcale nie jest niepokojące.
Nie ma się czym martwić. To powiedziawszy, możesz zaoszczędzić sobie dużo bólu, przenosząc jak najwięcej zadań zarządzania na płatnego klienta, angażując ich w proces opracowywania priorytetów, a także w technologię, automatyzując tyle rutyny, co możliwy.
źródło