WSTECZ
Utrzymanie projektu na właściwym torze jest powszechnym wyzwaniem dla wielu firm technologicznych, których głównym celem jest terminowe i wydajne opracowywanie produktów. Czytam to między wierszami regularnych rozmów z naszymi klientami i partnerami. Chcę podzielić się z wami ciekawą historią w nadziei, że zainspiruje ona również was i pomoże rozwiązać wasze typowe problemy związane z efektywnym zarządzaniem projektami rozwoju oprogramowania.
Oto kilka typowych powodów, które często słyszymy:
Jak widać, zarządzanie projekt przyprawia o ból głowy każdego menedżera technicznego. Często zadają sobie pytanie, jak zorganizować pracę deweloperów. zespół aby uniknąć opóźnień i upewnić się, że wszystkie zaplanowane produkt funkcje są płynnie i terminowo rozwijane. Nie trzeba dodawać, że potencjalna "luka" i stagnacja w rozwoju może mieć bolesne konsekwencje. Zbyt optymistyczne harmonogramy, brak deweloperów, źle zorganizowana praca itp. mogą sprawić, że projekt będzie opóźniony.
Zacznijmy od krótkiego wyjaśnienia, czym dokładnie jest metoda MOSCOW. Jest to specjalna technika ustalania priorytetów stosowana w zarządzaniu projektami i rozwój oprogramowania osiągnięcie porozumienia z interesariuszami (klientami lub członkami zaangażowanymi w projekt) w sprawie wagi, jaką przywiązują do spełnienia każdego z wymagań.
Myślę więc, że dobrym rozwiązaniem dla każdego menedżera technicznego jest zapoznanie się z metodą MOSCOW (z jej kategoriami, takimi jak "musi", "powinien", "może", "nie będzie"). Wdrożenie dwóch pierwszych kategorii - "musi" i "może" - jest zazwyczaj trudne. Liczba zadań do wykonania - czasami przy ograniczonych zasobach ludzkich, zbliżających się terminach lub innych przeszkodach - może być niewykonalna.
Zasadniczo firmy mają różne podejścia do radzenia sobie z tego rodzaju problemami. Dobre zarządzanie ryzykiem jest kluczem do przekształcenia zagrożeń w zwycięstwa. Pozwolę sobie przedstawić niedawny przykład związany z tym tematem. Kilka tygodni temu kierownik projektu z firmy zajmującej się produktami SaaS skontaktował się ze mną w sprawie możliwości outsourcing trzech inżynierów oprogramowania na czas określony od początku października do końca listopada. Zdarza się, że w niektórych okresach firmy potrzebują wsparcia większej liczby programistów ze względu na liczbę zadań do wykonania i utrzymanie pożądanego tempa rozwoju projektu.
Wspomniany kierownik projektu wpadł na pomysł zatrudnienia dedykowanego zespołu inżynierów backendu, wiedząc, że nasz stos technologiczny pasuje do ich podstawowego stosu produktów. Rozpoczęliśmy projekt w elastycznym i wygodnym modelu pay-as-you-go. Nie wymagało to wielu długich spotkań, rozmów ani podpisywania stosu skomplikowanych umów. Mieliśmy jasne pojęcie o naturze żądania, a wiedząc, że czas jest tutaj najważniejszy, zorganizowaliśmy konfigurację płynnie, dzięki czemu zespół ratunkowy jest gotowy do pracy.
Istnieje wiele innych zalet połączenia sił z partnerem technologicznym istotnym dla planów rozwoju. Zewnętrzne wsparcie jest przede wszystkim opłacalne (pozwala zaoszczędzić do 35% budżetu). Deweloperzy, którzy dołączają do wewnętrzny zespół często wnosi do realizowanego projektu dodatkową wiedzę i świeże spojrzenie. Dzięki takiej współpracy klient eliminuje ryzyka i wąskie gardła związane z terminami, spowolnieniami i długą listą zaległych zadań. Wracając do wspomnianej metody MOSCOW: czy tempo dostarczania zadań z kategorii "muszę" i "powinienem" jest warte kompromisu?
To jest nasz punkt widzenia na to, jak utrzymać projekty na właściwym torze. Jestem ciekawy, czy masz podobne doświadczenia z konfiguracją swojego zespołu inżynierów? Jak planujesz obciążenie pracą nad ważnymi funkcjami w pipeline w okresie wakacyjnym? Jakie inne metody stosujesz i polecasz innym menedżerom technicznym, aby mogli mieć wspaniałe lato nie tylko podczas wakacji, ale także podczas płynnej pracy? rozwój produktu? Daj mi znać w prywatnej wiadomości tutaj.
Szczęśliwego planowania!
Czytaj więcej:
Polish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean