Ustalanie realistycznych oczekiwań dotyczących terminów

Jestem liderem technologicznym w małym zespole. Jednym z głównych zadań na moim talerzu jest komunikacja z klientem. Jedną z rzeczy, które uważam za szczególnie trudne, jest dotrzymywanie terminów, ponieważ są one zlecane przez klienta i często nie jestem konsultowany.

Zwykle interakcja przebiega według następującego schematu. Klient oferuje funkcję, którą chce dodać, Funkcję X. Funkcja X będzie dobrze wyglądać w wydaniu aplikacji na następny tydzień, które będzie za około 6 dni roboczych. W tym momencie żądanie funkcji musi zostać zatwierdzone i często istnieją inne zależności, z którymi trzeba sobie poradzić. Ostatecznie, N dni później, prośba o dodanie funkcji spływa do mojego zespołu. Nawet jeśli pierwotny termin (ustalony przez menedżera niebędącego programistą) był możliwy do osiągnięcia, już go nie ma. Mój zespół jest obwiniany, czuje się zniechęcony i panuje ogólna atmosfera porażki , czuję się zniechęcony i pokonany.

Oczywiście cały proces jest zepsuty. Niestety niewiele mogę zrobić, ponieważ nie mam tutaj władzy. Moje obecne podejście polega na delikatnym przypominaniu klientowi o naszej dacie rozpoczęcia w porównaniu z terminem, zakresem funkcji itp. Wydaje mi się, że robię wymówki.

Czy byliście w podobnych sytuacjach? Co Ci się nie udało?

Naprawdę musisz porozmawiać o tym z szefem i ustalić kilka podstawowych zasad:

• Termin nie jest terminem, chyba że się do tego zobowiązasz.
• Szacunek nie jest szacunkiem, chyba że go podasz, a następnie jest to „szacunek”, a nie trudny termin.

Czysty koder Roberta Martina ma naprawdę dobry rozdział na temat tego, jak przekazać te rzeczy swojemu szefowi. To nie twoja wina, że ​​zespół sprzedaży podejmuje niemożliwe zobowiązania.

Po otrzymaniu nowej funkcji Oceniasz ją i używasz PERT, aby uzyskać rozkład prawdopodobieństwa. „Powinienem to zrobić w ciągu 4 dni, ale może to zająć nawet 8”. Postawić na swoim. NIGDY nie negocjuj wyceny ze sprzedawcą, w końcu zobowiązujesz się do niemożliwego.

Po kilku powtórzeniach tego sprzedawca, miejmy nadzieję, będzie miał dość, że będzie wyglądał na głupca i dostosuje zachowanie do „Sprawdzę z zespołem programistów i zobaczę, kiedy możemy to zrobić”, a nie obietnicę, że skończysz łamanie.

Czy byliście w podobnych sytuacjach? Co Ci się nie udało?

Przeważnie to, co działa, mówi prawdę władzy.

Zbierz fakty. Przedstaw fakty. Pozostaw klienta, aby uczył się (lub nie uczył się) we własnym tempie.

Moja drużyna jest obwiniana, czuje się zniechęcona i panuje ogólna atmosfera porażki.

Dlaczego twój zespół jest świadomy winy? Jeśli klient omija Cię i rozmawia bezpośrednio z zespołem, stajesz się nieskuteczny i musisz dowiedzieć się, dlaczego.

Twój zespół powinien być nieświadomy „winy” lub jej braku. Powinni po prostu zbudować oprogramowanie, a Ty powinieneś po prostu przekazać klientowi, co robisz i kiedy to robisz.

Klient powinien --- ostatecznie --- urosnąć, aby zrozumieć ten proces. Przełamanie złych nawyków wymaga wiele powtórzeń. Świetny interes.

Byłem w dokładnie takiej sytuacji i to nie było przyjemne. Jednak jednym z moich podejść było skrupulatne prowadzenie rejestru prac, które są obecnie w fazie rozwoju. Kiedy nadchodzą zadania, przypominasz klientowi, kierownictwu lub kierownikowi projektu, że inne prace będą spadać, ponieważ stało się to teraz ich priorytetem (czasami może to sprawić, że będą się zastanawiać, a następnie będziesz naciskał, aby wydłużyć termin).

W przeciwnym razie myślę, że musisz spróbować wbijać dłuto w kamienną ścianę, która jest kierownikiem projektu / klientem / zarządcą / sprzedawcą, który ma do czynienia z klientem i zgadza się na te terminy. Często kłóciłem się z faktem, że jeśli zgadzają się, że zrobienie czegoś zajmie 5 dni, to oczywiście mówią o 5-dniowym rozwoju, co oznacza, że ​​potrzeba 5 dni od momentu otrzymania (nie kiedy odłożą słuchawkę i spędzą razem następne dwa dni sporządzając fantazyjne słowo doc).

Ponieważ jednak jesteś kierownikiem ds. Rozwoju, każda taka decyzja jest nieistotna, jeśli nie zostanie z Tobą skonsultowana.

Musisz także starać się jak najlepiej chronić swój zespół przed tym. Chociaż jest to trudne, należy jak najdalej trzymać się polityki klienta / kierownictwa. Jeśli tak nie jest, wymagane jest więcej uderzeń głową.

Zasadniczo nie podobało mi się to i bez względu na to, jak mocno mnie zmiażdżyłem, proces nie stał się idealny. Udało mi się jednak trochę poprawić.

Jedyne, co prawdopodobnie możesz zrobić, to rozmawiać z klientem. Po prostu opisz, co się dzieje, jak to widzisz, opisz wszystkie ryzyka i tak dalej. Miałem podobną sytuację i byłem naprawdę zły. Nawet teraz, kiedy jestem odpowiedzialny za wszystkie oszacowania techniczne, często słyszę - chcemy, aby zrobiono to do poniedziałku. Mówię tylko - nie dostaniesz tego, przedyskutujmy, co dokładnie chciałbyś mieć do poniedziałku, a potem często wydaje się, że wszystkie kluczowe funkcje są dość łatwe do wdrożenia, a poniedziałek jest absolutnie w porządku. Wszystkie pozostałe funkcje są następnie planowane na późniejsze wydania.

Problem polega na tym, że klient w większości zna wartość biznesową tej funkcji, ale nie zdaje sobie sprawy z jej złożoności. Po prostu omów i wyjaśnij. Zawsze.

Dobrym początkiem jest przypomnienie klientowi, że data rozpoczęcia jest późniejsza niż data, w której poprosił o tę funkcję. Musisz także porozmawiać z kimkolwiek, kto przeprowadza pierwszą rozmowę z klientem, aby uzyskać szczegółowe informacje na temat funkcji, aby mógł powiedzieć klientowi w tym czasie, jaki byłby lepszy termin. Ponieważ już komunikujesz się z klientem, możesz po prostu powiedzieć „więc kto to był w Dziale Y, który zgodził się na ten termin?”

Jeśli nie pozwolą ci wziąć udziału w rozmowach lub powiedzą ci, abyś był cicho i dotrzymał terminów, na które się zgodzi, możesz przypomnieć im, że lepiej by wyglądało dla całej firmy, gdyby twój zespół był na czas i sposób aby to osiągnąć, otrzymujesz swój wkład w terminach.

Napraw przepływ informacji.

• Jeśli masz komunikować się z klientem, zmuś wszystkich interesariuszy projektu (w tym klienta) do bezpośredniego kontaktu z tobą, zawsze .

Niestety, moc jest przejęta raczej przez ciebie, niż przez innych.

Jednym z głównych zadań na moim talerzu jest komunikacja z klientem. Jedną z rzeczy, które uważam za szczególnie trudne, jest dotrzymywanie terminów, ponieważ są one zlecane przez klienta i często nie jestem konsultowany.

Jeśli masz ponosić odpowiedzialność za komunikację z klientem, dlaczego nie konsultowano Cię w sprawie planowania (i budżetowania), abyś mógł przekazywać te informacje między osobami odpowiedzialnymi za nie w Twojej organizacji a ich odpowiednikami po stronie klienta? Myślę, że naprawienie tego problemu będzie ogromną korzyścią dla ciebie, twojego zespołu i twojego projektu.

Klient oferuje funkcję, którą chce dodać, Funkcję X. Funkcja X będzie dobrze wyglądać w wydaniu aplikacji na następny tydzień, które będzie za około 6 dni roboczych. W tym momencie żądanie funkcji musi zostać zatwierdzone i często istnieją inne zależności, z którymi trzeba sobie poradzić. Ostatecznie, N dni później, prośba o dodanie funkcji spływa do mojego zespołu. Nawet jeśli pierwotny termin (ustalony przez menedżera niebędącego programistą) był możliwy do osiągnięcia, już go nie ma.

Ten system planowania wydaje się co najmniej dziwny.

Z moich doświadczeń wynika, że ​​klient rejestruje się w celu wydania określonej wersji. Mogą przesłać listę funkcji i zmian, których chcą i kiedy chcą, a następnie negocjować z zespołem tworzącym oprogramowanie. Mogą też podać priorytetową listę funkcji zespołowi programistycznemu, a zespół programistyczny podaje szacunkowe daty dostarczenia różnych zestawów funkcji. Istnieją również inne warianty.

Ale jedną rzeczą, na którą nigdy nie widziałem, jest to, że klient może zmienić wersję tak późno w grze, zwłaszcza że nie ma tygodnia od wydania. Wydaje się, że nie jest to odpowiednie obciążenie dla projektantów, programistów i testerów. Jeśli wykonujesz iteracyjne prace rozwojowe, jeśli jest to funkcja o wysokim priorytecie, po prostu dodaj ją do formy zaległości i weź jak najszybciej. Jeśli nie jest to funkcja o wysokim priorytecie, zdecydowanie nie potrzebują jej w tej wersji i mogą poczekać do następnej.

Zalecam ustanowienie pewnych podstawowych zasad, które uwzględniają zespoły zajmujące się projektowaniem, programowaniem, testowaniem i dostawą, a także klientem, dotyczące funkcji zawieszania się, zawieszania się kodu i dostaw. Umieść je na piśmie, uzyskaj zaangażowanie od wszystkich i trzymaj się tego. Jeśli poruszysz się raz, będziesz musiał zginać więcej i stracisz kontrolę nad procesem.

Niestety niewiele mogę zrobić, ponieważ nie mam tutaj władzy.

Możesz nie być sam. Ale wygląda na to, że twoi projektanci i / lub programiści i / lub testerzy są pod dużą presją, aby dotrzymywać harmonogramów. Powinieneś usiąść z przełożonymi jako zespół i wyjaśnić sytuację. Najpierw poproś organizację, aby zobowiązała się do udoskonalenia procesu, a następnie współpracuj z klientem, aby uzyskać akceptację tego, jak wszystko będzie działać.

Jednak wydaje mi się, że robię wymówki.

Kiedy zaczniesz szukać wymówek, może być czas na trudną rozmowę lub kluczową rozmowę . Poleciłbym jedną z tych dwóch książek. Ich czytanie pomogło poprawić moje umiejętności komunikacyjne, zwłaszcza gdy musisz stawić czoła trudnej sytuacji, w której napięcia są wysokie ze wszystkich stron.

Aby odpowiedzieć na niektóre inne odpowiedzi.

Niestety, moc jest przejęta raczej przez ciebie, niż przez innych.

Nie wiem dokąd zmierza Andrea . Tak, musisz naprawić przepływ informacji. Ale musisz współpracować z szefami i klientami, aby upewnić się, że wszyscy wiedzą, co (zakładam, w każdym razie) uzgodniono na początku projektu. Jeśli porozumienie z jakiegokolwiek powodu się nie powiedzie, odwiedź je ponownie i rozdziel pracę i role osobom lepiej do nich dopasowanym.

Nie bierzesz władzy ani nie walczysz z nią, ale pracujesz z nią, próbując ją oswoić i sprawić, by działała dla wszystkich.

Problem polega na tym, że klient w większości zna wartość biznesową tej funkcji, ale nie zdaje sobie sprawy z jej złożoności. Po prostu omów i wyjaśnij. Zawsze.

Ten cytat z loki2302 jest dość trafny . Jednym z twoich zadań jako inżyniera oprogramowania jest upewnienie się, że właściwi ludzie wiedzą, jak trudne jest to zadanie, jak długo to zajmie oraz jakie opcje i ryzyko istnieją przy robieniu czegoś. Jako główny komunikator Twojego zespołu, przekazywanie tych informacji z Twojej organizacji do klienta jest teoretycznie Twoim zadaniem.

Znajdź forum, na którym można się skontaktować z każdym, kto wyznacza te terminy. Poinformuj ich, że mogą skonsultować się z Tobą i przedstawić coś bardziej realistycznego. Alternatywy są następujące: możesz powiedzieć klientowi, że to się nie wydarzy lub on może powiedzieć klientowi.

Możesz to przedstawić tak, jak możesz to zrobić za X dni, kiedy Twój zespół zacznie nad tym pracować. Może to było zamieszanie? To uczciwy błąd, chyba że zdarza się raz po raz. To po prostu zaniedbanie.

Domyślam się, że twój zespół dotrzymał tych terminów w przeszłości.

Niestety, jest on powszechny w naszej branży, dlatego wiele agencji cyfrowych / oprogramowania nie wie nic o wewnętrznych działaniach ani wymaganiach ich firmy. Wielu dotyczy tylko szybkiej gotówki. Jak wielu już wcześniej powiedziało, jeśli nie podajesz prognoz ani terminów, poinformuj kierownictwo. W jaki sposób możliwe jest wykonanie technicznej pracy przez x czasu bez szacunku ze strony osoby technicznej znającej harmonogram zespołu programistów.

Jeśli wszystko inne zawiedzie, wyjdź.

Przekaż kierownikowi projektu / szefowi / klientowi swoje możliwe do oszacowania prognozy i harmonogramy, poproś go o potwierdzenie planu lub ustal, nad czym ma pracować, a następnie odejdź - nie angażuj go ani nie zabawiaj w żaden sposób.
Jeśli wróci z planem projektu, który nie odzwierciedla twoich szacunków, wyślij mu je z oświadczeniem: „Nie negocjuję szacunków”. i odejdź.

Upewnij się, że masz dużo dokumentacji CYA. Wyjaśnij wszystkim zaangażowanym, że przechowujesz te dokumenty. Przesłałem takie zapisy pocztą elektroniczną na mój osobisty adres e-mail i wysłałem do mojego szefa, co było bardzo udane.

Oto podejście, które powinno się wydawać konstruktywne zamiast wskazywania palcem. Nie oskarżam cię o to, po prostu mówię, że nie jest dobrze grać z wymówką z kimś winnym, niezależnie od prawdy oskarżenia.

Po tym zdarzeniu zrób sekcję zwłok, aby obliczyć, ile czasu faktycznie zajęło ukończenie projektu, lub ile by to zrobiło, gdybyś go zakończył. Następnie obliczyć liczbę godzin zasobów dostępnych od czasu, gdy posiadasz wystarczającą ilość informacji i zielone światło, aby nad nimi pracować. Przelicz te liczby na ilu dodatkowych programistów zajęłoby dotrzymanie terminu.

Teraz porozmawiaj z szefem w następujący sposób:

Mieliśmy X dostępnych roboczogodzin między datą rozpoczęcia projektu Y a terminem Z.
Projekt wymagał ukończenia X + roboczogodzin.
Podobne wymagania dotyczące realizacji były inne projekty.
Będziemy potrzebować Q dodatkowych programistów, aby osiągnąć wydajność potrzebną do spełnienia oczekiwań.
... oczywiście, jeśli budżety są napięte, być może moglibyśmy współpracować z Kierownikami Projektu, aby poświęcić więcej czasu na ich szacunki, abyśmy mogli nie obiecać i przekroczyć zbyt wiele (pamiętaj, aby używać banalnego zarządzania)