Jak mogę popierać pół-ścisły harmonogram wydań w środowisku unikającym ryzyka?

Ostatnio coraz bardziej nęka mnie to, co musiałbym opisać jako jedno z moich najbardziej frustrujących i zabójczych morale doświadczeń w tym zawodzie: konieczność siedzenia w wersji , która została przetestowana, ponownie przetestowana, wystawiona i pod każdym względem i cele są gotowe do wysyłki / wdrożenia .

Jako wszechstronny facet od rozwiązań, a nie tylko hardkorowy programista, rozumiem, a nawet zalecałem odpowiednią kontrolę zmian. Ale ostatnio niepewna równowaga między pokrywaniem naszych baz a wysyłką na czas poszła na marne i nie miałem żadnego sukcesu w przywróceniu tego do rozsądnego stanu.

Szukam przekonujących argumentów, które pomogą przekonać kierownictwo niechętne ryzyku, że:

1. Zespół deweloperów powinien (lub musi) mieć możliwość ustalenia własnego harmonogramu wydań - oczywiście z tego powodu (1-3 miesiące powinny być wystarczająco konserwatywne dla wszystkich, z wyjątkiem największych firm z listy Fortune 500);

2. Wydania oprogramowania są ważnymi kamieniami milowymi i nie należy ich traktować kawalersko; innymi słowy, niepotrzebne opóźnienia / przestoje są bardzo uciążliwe i należy je traktować jedynie jako ostateczność w niektórych krytycznych kwestiach biznesowych; i

3. Podmioty zewnętrzne (inne niż deweloperów / inne niż IT), które chcą (lub żądają) zaangażowania, ponieważ interesariusze mają obowiązek współpracować z zespołem twórców w celu spełnienia harmonogramu wydań, szczególnie w ostatnim tygodniu przed planowanym statkiem data (tj. testowanie / testowanie przez użytkownika).

Powyższe są twierdzeniami, które wydają mi się prawdziwe w oparciu o doświadczenie, ale wygląda na to, że jestem teraz w stanie to udowodnić - więc proszę o coś nieco bardziej mięsnego, jeśli coś takiego istnieje.

Czy każdy, kto musiał „sprzedać” pomysł stałego (lub może częściowo elastycznego) cyklu wydawania kierownictwu, może wskazać, które argumenty / strategie są skuteczne lub przekonujące, a jakie nie? Czy oprócz oczywistych sporów dotyczących harmonogramu i kosztów utopionych istnieją jakieś twarde dane / dowody, które byłyby przydatne w uzasadnieniu, że wysyłka jest naprawdę ważna, nawet w środowisku „korporacyjnym”?

Alternatywnie, jestem otwarty na konstruktywne argumenty dotyczące tego, dlaczego elastyczność harmonogramu (nawet przez okres tygodni / miesięcy) jest ważniejsza niż wysyłka zgodnie z harmonogramem; trudno mi w to teraz uwierzyć, ale może wiedzą coś, czego ja nie wiem.

_{Zauważ, że wydaliśmy inscenizacje, które przeszły przez każdy etap oprócz produkcji. Problemy są śledzone przy użyciu komercyjnego narzędzia do śledzenia błędów, a każdy problem - 100% z nich - przypisany do tego wydania został zamknięty. Zdaję sobie sprawę, że trudno w to uwierzyć i to jest właśnie ten cel - nie ma sensu, aby w 100% kompletne, w pełni przetestowane, zatwierdzone przez interesariuszy wydanie zostało opóźnione przez kierownictwo z niewyjaśnionych powodów, ale tak się stało, tak się dzieje, to jest problem do rozwiązania.}

Joel Spolsky mówi, że zespół programistów to plan konwersji kapitału (pieniędzy) na działające oprogramowanie. Szczerze mówiąc, z twojego pytania wynika, że ​​twój zespół jest w tym dobry: dostajesz przyzwoite oprogramowanie za rozsądną kwotę zainwestowanych pieniędzy.

Teraz oczywiście następnym krokiem jest uruchomienie oprogramowania. Dopóki twoja firma tego nie zrobi, nie będzie w stanie uzyskać zwrotu z inwestycji kapitałowych. Oprogramowanie znajdujące się na półce i gotowe do wdrożenia przypomina rodzaj zapasów w magazynie: koszty są utopione, pieniądze kapitałowe firmy są już wydane. Istnieje również koszt alternatywny: twoja grupa postanowiła wykonać ten projekt, a nie coś innego.

Co więcej, wartość nowo opracowanego oprogramowania siedzącego na półce przypomina wartość skrzynki z serem siedzącej w lodówce w restauracji: powoli gnije. Jego wartość spada, ponieważ konkurencja dogania. Odmawia także, ponieważ coraz trudniej jest wdrożyć nowe oprogramowanie, ponieważ jego twórcy przechodzą do innych rzeczy. Po kilku latach na półce może to być faktycznie bezwartościowe. W takim przypadku Twoja firma postanowiła odrzucić kapitał, który zainwestował w jego rozwój. Możliwe, że właściciele firmy - akcjonariusze - będą niezadowoleni z tego powodu.

Jest jedna rzecz, którą ty, jako programista, musisz zrozumieć. Czy twoje oprogramowanie naprawdę jest gotowe do wdrożenia pod koniec proponowanego cyklu wydawniczego? Czy jest gotowy do pracy, czy jest jeszcze mnóstwo pracy do zrobienia i pieniędzy do wydania, gdy Twoja firma wprowadza go do produkcji? Czy Twoja firma posiada serwery i licencje na oprogramowanie potrzebne do wdrożenia oprogramowania? Czy Twój produkt roboczy zawiera plan wdrożenia? Czy przeszkolono użytkowników końcowych? Czy dane produkcyjne zostały przekonwertowane? Jeśli nowe oprogramowanie wymaga zmiany sposobu prowadzenia działalności przez firmę, czy firma jest gotowa dokonać tej zmiany? Czy opracowałeś schemat równoległego uruchamiania rzeczy, aby upewnić się, że nowe rzeczy działają tak samo, jak stare?

Wszystkie te koszty wdrożenia mogą z łatwością przewyższyć koszty samego oprogramowania. Mądry zespół zarządzający projektem dokłada wszelkich starań, aby planować, budżetować i planować wszystkie te rzeczy. Czy wykonałeś tę pracę? Czy wyjaśniłeś to zarządowi? Jeśli nie, możliwe, że rozsądnie jest spowolnić wdrażanie.

Możliwe, że nowoczesny harmonogram wdrażania zwinnego oprogramowania nie jest zsynchronizowany z tempem zmian oczekiwanym przez resztę firmy. Twoi użytkownicy końcowi - twoi interesariusze - mogą po prostu nie być w stanie wchłonąć zmian w tempie, w jakim może je wytworzyć zespół.

Możliwe jest również, że Twój zespół zarządzający jest dysfunkcyjny. Czy Twój zespół opracował coś, czego reszta firmy nie chce? Czy nowe rzeczy zagrażają cholernemu zespołowi sprzedaży lub produkcji? Jeśli tak, niektórzy członkowie kierownictwa mogą go storpedować, mówiąc, że wdrożenie go jest zbyt ryzykowne. Nic nie możesz na to poradzić, chyba że jesteś CEO.

Poprosiłeś o przekonujące argumenty za terminowym wdrażaniem oprogramowania. Jest jeden naprawdę przekonujący argument: zwrot z inwestycji. Firma zdecydowała się zainwestować w to oprogramowanie, a teraz marnuje inwestycję, ponieważ oprogramowanie powoli gnije na półce.

Drugim argumentem przemawiającym za terminowymi wdrożeniami jest morale twojego zespołu. Pośpiesz się i czekaj nie jest dobrym sposobem na motywowanie twórczych programistów do dobrej pracy. Możesz stracić swój zespół, jeśli nie będą mieli satysfakcji z oglądania ich pracy.

Najpierw obejrzyj ten film:

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

Streszczenie:

Sposób wysyłki na czas i budżet jest następujący: gdy zabraknie Ci czasu lub pieniędzy, wysyłasz. Otóż ​​to.

Powodem, dla którego większość projektów nie jest wysyłana na czas, jest to, że ktoś przychodzi wraz z „jeszcze jedną funkcją lub poprawką”, która ma zostać wstawiona do wydania, tuż przed przygotowaniem do wysyłki, w czasie cyklu programowania, gdy zasoby są najbardziej rzadkie, a teraz musisz się wspinać. Nazywa się to thrashingiem i dzieje się tak, ponieważ dopóki nie wysyłasz, nie musisz się martwić, że ludzie powiedzą ci, że twój produkt jest do bani.

Sposób, w jaki leczysz thrashowanie, polega na zmuszaniu ludzi do robienia tego na początku cyklu rozwoju produktu , a nie na końcu.

Wprowadzanie zmian w produktach na kilka tygodni przed datą premiery jest bardzo uciążliwe z oczywistych powodów. Dzieje się tak niezależnie od tego, czy zmiana jest nową funkcją, zmianą w procesie tworzenia oprogramowania, czy próbą naprawienia długotrwałego błędu, którego nie ma w harmonogramie rozwoju.

Gdy ktoś przychodzi do mnie w celu naprawy lub zmiany na późniejszym etapie cyklu programowania, zawsze pytam go: „Czego chcesz, abym nie zrobił, abym mógł wykonać twoje zadanie?”

Jeśli potrzebujesz motywatora do pieniędzy, to jest to: badania dowodzą, że im później poczekasz w cyklu życia oprogramowania na wdrożenie funkcji lub poprawki, tym droższe. Wykładniczo. Nietrudno to udowodnić.

Wyraźnie opisałeś problemy, z którymi się borykasz, jednak nie jestem pewien, dlaczego menedżerowie zachowują się w ten sposób. Możesz wyjaśnić? Na przykład uważasz, że jest gotowy do wdrożenia, czy ktoś się nie zgadza, jeśli tak, to kto i dlaczego? Czy są byłymi rządowymi beaurokratami?

Brzmi to bardzo podobnie do problemu wyrównania zdolności do pożądania, masz chęć uwolnienia, ale nie zdolności (autorytetu), ci z autorytetem nie mają takiej chęci.

Musisz dowiedzieć się, dlaczego brakuje im chęci - to jest powód marketingowy (zatrzymaj go na kolejny rok, a my będziemy doić trochę starszej wersji), czy to strach / pewność siebie (jeśli ma błędy, sprawi, że będziemy źle wyglądać , kosztuje nas pieniądze ..., brak zasobów (nie stać mnie na koszty wysyłki / pakowania / PR), czy to komercyjny, w którym twój niejasny zlew osiąga niskie zyski i nie chce, żebyś zarabiał ( Nie tak głupie, jak się wydaje).

Podejrzewam również, że istnieje niewielki szacunek między zaangażowanymi stronami, dlatego nie odbywają się uzasadnione dyskusje dla dorosłych.

Przepraszamy - nie jest to konkretna odpowiedź, o którą prosiłeś, ale mam nadzieję, że kilka rzeczy do przemyślenia.

Pierwszą rzeczą do rozważenia jest upewnienie się, że twoje wydania nie są obarczone wysokim ryzykiem .

W idealnym przypadku żądania zmiany powinny zawierać sekcję o nazwie Ograniczanie ryzyka , zawierającą instrukcje dotyczące przywracania poprzedniej wersji, jeśli coś pójdzie nie tak. Ze względu na ryzyko żadna ilość wcześniejszych testów nie może zastąpić prostej opcji wycofania zmiany.

• ^{W środowisku niechętnym do ryzyka nie wyobrażam sobie sposobu, aby nieodwracalne zmiany były bezbolesne.
  Jeśli wiele / większość wydań należy do tej kategorii, możesz ponownie rozważyć architekturę.}

Ryzyko nie zwalnia to być narażeni, jeśli chcesz dev harmonogram zespół należy traktować poważnie.

Jeśli Twoje wydania zawierają poprawki problemów związanych z produkcją / pomocą techniczną i przestojami, jest to dość łatwe, po prostu wymieniając je i wskazując, że produkcja może je powtórzyć, chyba że zostanie zaktualizowana.

Naprawdę skuteczny środek dostępny dla zespołu deweloperów w walce z poślizgnięciami wydania, aby upewnić się, że ryzyko braku uwolnienia wzrasta z czasem . Można to osiągnąć dzięki wewnętrznym wydaniom działającym według ustalonego harmonogramu, zapewniając „zbiorczą” listę rozwiązań problemów produkcyjnych.

• Mówiąc wprost, faceci blokujący wydanie XXmuszą mieć świadomość, że nie tylko ponoszą ryzyko Nproblemów z produkcją, ale pozostaną również w tym tygodniu (lub miesiącu) XX+1w kolejce do zatwierdzenia, blokując, co spowoduje ponieść ryzyko, że N+Mproblemy związane z produkcją pozostaną nierozwiązane - i tak też będzie w przypadku XX+2i kolejnych „wewnętrznych” wydań dostarczanych przez zespół programistów.

Sposób opisany powyżej zasadniczo zapewnia ściślejsze i bardziej wyraźne połączenie między aktualizacjami aplikacji i problemami z produkcją.

Z tego powodu możesz spodziewać się większego zaangażowania w eskalacje problemów produkcyjnych . Możesz wykorzystać je jako okazję do promowania swojej wizji bardziej rygorystycznych zaplanowanych aktualizacji. Możesz nawet uruchomić niektóre eskalacje, aby przyspieszyć proces przyjmowania pożądanego podejścia.

• ^{„... zalecamy rozważenie uaktualnienia aplikacji do nowszej wersji ( XXlub nowszej). Ta, która jest obecnie wdrażana w twoim środowisku ( XX-2), jest poważnie przestarzała - dwie główne wersje za obecną bazą kodu. W rezultacie szczegóły takich prostych awarii są głęboko ukryte w logach i nieczytelne śmieci są zgłaszane przez aplikację klientom zamiast jasnych opisów awarii - co powoduje, że użytkownicy i wsparcie tracą czas na badanie naprawdę bardzo prostych problemów. ”
   
  Powyżej jest komentarz, który dodałem jakiś czas temu w narzędziu do śledzenia problemów z biletem związane z konkretnym incydentem produkcyjnym. Wkrótce potem „interesariusze” skontaktowali się z zespołem programistów, pytając, jak śledzić nasze wydania i jak mogą pomóc we wdrożeniu w swoim środowisku. No i oni również szybko zaktualizowali zXX-2wersja też. :)}

Kiedy dojdzie do eskalacji produkcji, lepiej przygotuj się do szybkiego i wyraźnego przedstawienia swojej wizji.

Jedną z rzeczy, które mogą ci się przydać, jest wybranie i śledzenie, kto jest odpowiedzialny za konkretne poślizgnięcie się wydania. Zasadniczo musisz być w stanie szybko i jasno odpowiedzieć na pytanie typu „kto ponosi odpowiedzialność za to, że planowane wydanie nie nastąpiło?” Jeśli nie jesteś gotowy, mogą wybrać ścieżkę najmniejszego oporu i obciążyć cię winą. Jak wskazano w komentarzach do kolejnej odpowiedzi : „Możesz dostać się do gorącej wody, przed którą kierownictwo stara się cię chronić”.

Ostatni, ale nie najgorszy,

to zajmie trochę czasu

(prawdopodobnie już to wiesz, ale wygląda na to, że warto to wyraźnie powiedzieć)

To, czego szukasz, można opisać jako zmianę nastawienia, od „ryzykowne jest uwolnienie ” do „ryzykowne NIE uwolnienie ”. Zmiany postawy rzadko zdarzają się z dnia na dzień, może być potrzebna cierpliwość, aby dokończyć zmianę.

Nad twoim pytaniem znajduje się duży znak zapytania i dlatego twoja firma nie chce wydać oprogramowania. Nie zawsze jest to zwykły przypadek niechęci do ryzyka. Często istnieją inne przyczyny leżące u podstaw, które często nie są przekazywane z wysokich stanowisk kierowniczych. Więc moje pytanie brzmi: „Czy usiadłeś z szefem i zapytałeś go, dlaczego wstrzymuje się premiera produktu?”.

Istnieje duża różnica między zarządzaniem ryzykiem a jego unikaniem. Przyczyny opóźnienia wydania produktu mogą być uzasadnione prawnie lub marketingowo. Mogą to być problemy dotyczące zaufania między kierownictwem a zespołem programistów. Produkt może nie odpowiadać potrzebom klienta, nawet jeśli jest dokładnie tym, o co prosił klient kilka miesięcy temu. Może to być nawet przypadek kogoś z kierownictwa, który poważnie zakrywa tyłek podczas próby przeniesienia winy na opóźnienie w innym miejscu, lub nawet opóźnienie ze strony osoby trzeciej, która jest wymagana do ukończenia czegoś przed wysłaniem produktu. Mógłbym wymyślić dziesiątki scenariuszy. Dość często deweloper zakłada awersję do ryzyka, nie rozumiejąc drugiej strony równania, która nie została ujawniona. Z drugiej strony może to być po prostu samozadowolenie, konflikt między osobami w firmie,

We wszystkich przypadkach ważne jest, aby mieć więcej informacji na temat przyczyn opóźnień w wydaniu produktu i wykorzystać te informacje, aby stworzyć uzasadnienie wydania produktu tak szybko, jak to możliwe. Tak, może to być bardzo frustrujące, ale istnieją inne sposoby radzenia sobie z tymi sytuacjami bez ryzyka konfrontacji z bossami lub wypalenia zawodowego. W podobnych sytuacjach osobiście zebrałem informacje, udokumentowałem postęp, który zrobiłem, a jeśli gorzej się pogorszy, po prostu odłożyłem projekt na bok i przeszedłem na coś innego. To, gdzie udało mi się przywrócić projekt do realizacji, zwykle było wynikiem solidnego uzasadnienia biznesowego na podstawie informacji, które otrzymałem jako odpowiedź na zadane przeze mnie pytania. Tam, gdzie nie byłem w stanie przekonać kierownictwa, że ​​produkt powinien zostać wysłany, Udokumentowałem niechęć do wysyłania jako po prostu przypadku ukończonego projektu i oczekującego na zatwierdzenie wydania przez kierownictwo. Następnie upewniam się, że mój kierownik podpisuje mój dokument jako zaakceptowany i zrozumiany przez kierownictwo, tak aby mój tyłek został objęty, jeśli będą próbowali obwinić mnie później za brak wydania.

Zawsze musisz kropkować swoje I i krzyżować T, aby uniknąć późniejszego obwiniania opóźnień w wysyłce (bez względu na to, jak niesprawiedliwie), a także ważne jest, aby unikać zbytniego emocjonalnego przywiązania do takich problemów, chyba że podoba ci się pomysł dobrze zasłużonego wrzodu. Patrząc na swoją sytuację z pewnym zawodowym oddziałem, możesz znaleźć rozwiązanie, które przedstawia się samo, ponieważ skutecznie umieściłeś się w większej „odległości”, jak to było od problemu. Jeśli nie możesz przedstawić swojej sprawy, być może będziesz musiał pozwolić jej na chwilę się przesuwać, ale w pierwszej kolejności musisz wyglądać na profesjonalnie oderwanego i mieć argumenty oparte na informacjach, które są ściśle związane z Twoja firma i jej wewnętrzne funkcjonowanie.

Coś innego, o czym właśnie pomyślałem, a które może ci pomóc, to być może przeczytanie Lean Software Development i sprawdzenie, czy jest tam coś cennego, co może odnosić się do sytuacji Twojej firmy, szczególnie w kilku pierwszych rozdziałach. Myślę, że to rozdział 4 omawia kwestię dostawy tak szybko, jak to możliwe, i ma coś związanego z kosztami opóźnienia.

Powiedziałbym, że najłatwiejszym / najskuteczniejszym sposobem sprzedaży wydania jest wyłączenie narzędzi na jakiś czas, kiedy będzie gotowe. Zrób coś innego, rozpocznij nowy projekt, pracuj nad błędami dla istniejącego projektu. Nie rób nic więcej temu, dopóki nie zostanie wysłany przez drzwi - w końcu po co w ogóle robić to, jeśli nie pójdzie, gdy będzie gotowy.

ale w prawdziwym świecie faktyczne wydanie jest czyimś problemem, powinieneś je do niego wysłać, a następnie potraktować to jako wydanie. Gdy jest już poza twoimi drzwiami, jest wysyłany. Jeśli po prostu na nim usiądą, to nie jest twój problem (w rzeczywistości jest to świetne, nie zgłoszono żadnych błędów! W00t! Premie za wydanie wolne od błędów przez cały;))

Potrzebujesz systemu kontroli zmian i menedżera wydań. To wszystko jest łatwe (z wyjątkiem tego, że musisz zarządzać kontrolą zmian, więc kontrola źródła i kompilacje wdrażania są bardzo potrzebne. Wymaga organizacji, ale jeśli jesteś zorganizowany, to łatwe).

Nie mogę sobie wyobrazić, aby powierzenie zespołowi deweloperów kierowania biznesem w sposób, który opisujesz, jest „dobrą rzeczą”. Może to maskować prawdziwy problem, ale chyba że zespół deweloperów będzie w stanie zważyć dane wejściowe ze sprzedaży, marketingu itp. ryzykujesz zwolnienie z niewłaściwych (i potencjalnie złych) powodów.

Jeśli rozumiem twój problem - ukończyłeś projekt i masz produkt, którego nie możesz pokazać nikomu spoza firmy. (Mam nadzieję, że to podsumowuje, przeczytałem cały wątek i mam problem z umieszczeniem na nim palca)

Czy próbowałeś:

1. Poprosić kierownictwo o klienta lub grupę klientów, którzy będą działać jako interesariusze podczas rozwoju? Zazwyczaj można znaleźć jednego klienta, który weźmie pośrednie wersje i wyrazi opinię. Mogą być świetnymi orędownikami, gdy nadejdzie czas uwolnienia. Nawet „ograniczona wersja” dla jednego klienta może wystarczyć do zarządzania kołysaniem
2. Budowanie planu wydania, w tym wydania punktowego. Oznacza to, że możesz wypuścić wersję 3.4 już dziś, ponieważ wersja 3.4.1 jest planowana na dziś + 1 miesiąc. To wraz z dobrym pomysłem, o którym już wspomniałeś, że kadencja wydawnicza pomaga tej wiadomości.
3. Uzyskaj wsparcie, sprzedaż lub marketing po swojej stronie. Wbuduj poprawki, które rozwiążą 3 najczęstsze prośby o wsparcie, a możesz uzyskać sojusznika z innego działu. Jeśli nie możesz uzyskać interesariusza klienta jak w punkcie 1, wypróbuj go z kilkoma sprzedawcami. Oferta, która będzie dostępna na spotkania sprzedażowe i przyniesie produkt. Kiedy jesteś w drodze, pokaż sprzedawcy, że jesteś z produktem (niezależnie od tego, w jakim jest stanie).

Aby odpowiedzieć na inne pytanie dotyczące „dlaczego zarząd miałby siedzieć na wydaniu?” Firmy robią to cały czas w obszarach innych niż SW i nie sądzę, że jest to niespotykane. Na przykład masz nową wersję, która jest gotowa do użycia, wszystko przetestowane i gotowe. Ale stara wersja nie została jeszcze wyparta przez konkurencję. Gdy konkurencja wyda konkurencyjny produkt, stara wersja, kierownictwo wypuszcza wersję czekającą na półce i zakłóca rynek, wycofuje konkurencję i utrzymuje sprzedaż oraz reputację lidera rynku. Zbyt wczesne wypuszczenie napiwku daje rękę zawodnikom, którzy mogą mieć lepszy pomysł na mapę drogową i spróbować pokonać cię do finału.

Po tym wszystkim, co powiedział ... Maszynka do golenia Hanlona jest prawdopodobnie właściwą odpowiedzią :-)

Odejdź od tej firmy, nie rozumieją oprogramowania. Ale na poważnie, to oprogramowanie sprawia, że ​​system działa, wyobraź sobie, że jeśli produkujesz samochody, czy fabryki samochodów są wolne? czy czekają na premiery samochodów? Czy są one przyrostowe i biurokratyczne? Nie, starają się robić rzeczy w najszybszy i najczystszy możliwy sposób. Masz problem z zarządzaniem i powinieneś nad nim pracować jako konflikt zarządzania, spróbuj wyrazić je na ich warunkach. Zapytaj, co oznacza dla nich ryzyko, a następnie spróbuj je zminimalizować. Istotne są również odczucia twoich deweloperów, ponieważ muszą poradzić sobie z decyzjami, które zostaną podjęte przez twoją interwencję. Czy będą szczęśliwi, że wszystkie nocne statki wysyłają na czas? Jakie byłyby nagrody / kary? Itd. Teraz dam ci praktyczne podejście do tego problemu, nieco ekstremalne, ale poproś o audyt.