Jak sprzedać programowanie Agile klientom (wodospadem)

Nasz sklep deweloperski naprawdę chciałby realizować bardziej zwinne projekty, ale mamy problem z zaangażowaniem klientów. Wielu klientów chce budżetu i terminu. Trudno sprzedać klienta w zwinnym projekcie, gdy nasi konkurenci wymyślają ustalone terminy i ceny na podstawie wodospadu. Wiemy, że ich ustalone numery są złe, ale klient tego nie wie. W rezultacie wyglądamy źle dla klienta, ponieważ nie jesteśmy w stanie ustalić ceny ani terminu, ale nasi konkurenci mogą.

Jak więc zdobyć siły sprzedażowe, które z powodzeniem sprzedają projekt wykorzystujący zwinne metody programistyczne lub produkt opracowany przy użyciu takich metod? Wszystkie informacje, które znalazłem, wydają się koncentrować na zarządzaniu projektami i programistach.

Kluczem do dobrego wykonania tej umowy jest skorzystanie z umowy wsparcia.

Zasadniczo, kiedy sprzedajesz klienta po raz pierwszy, sprzedajesz go na podstawie swojej wiedzy i robisz to jak wodospad. Oznacza to umowę określającą zakres i sztywny termin. Tego chce klient. Klient mniej więcej zna zakres. Wodospad działa bardzo dobrze, w środowisku o stałym i zdefiniowanym zakresie, powiedziałbym, że działa lepiej niż zwinny w takich środowiskach. I w tym przypadku daje to klientowi pewien komfort, kiedy ma tendencję do denerwowania się, ponieważ nigdy wcześniej z tobą nie pracował. To dobrze, Agile nie zawsze jest lepsze niż wodospad.

Masz więc umowę o stałej cenie na zakres X. Następnie powiesz klientowi: „ Spójrz, będziesz chciał wprowadzić zmiany i będziesz potrzebować nas do wsparcia postprodukcji, odłóżmy 20% twojego budżetu na wykorzystanie tych rzeczy w razie potrzeby przez środki umowy wsparcia . ”

Jeśli zmiana pojawi się w trakcie projektu, po prostu odłóż ją na kontakt pod wsparciem. (Zakładając, że ta zmiana spowodowałaby poważne zakłócenia w projekcie)

Warunki kontaktu z pomocą techniczną są następujące: „ Praca wykonywana co godzinę, zgodnie z życzeniem klienta, może być wykorzystana do żądania zmian lub ogólnej obsługi i konserwacji systemu .” BAM! Jesteś w zwinnym.

Następnie możesz nadal przedłużać kontakt z pomocą techniczną i po prostu użyć kontaktu z pomocą techniczną jako środka do uruchamiania nowych projektów. Dodatkowo, jeśli te godziny są zakupione i opłacone z góry , zwykle dajemy klientowi 15% zniżki. To Win-Win.

Zwinne nie wyklucza terminów i budżetów. Gdybym był klientem i poszedłem do programisty, a oni powiedzieli mi, że nie mogą dać mi terminu ani szacunkowych kosztów, kwestionowałbym ich zdrowie psychiczne. A powiedzenie im, że po prostu nie rozumieją, nie zadziała: muszą mieć możliwość budżetowania i planowania.

Nie muszą znać twojego procesu rozwoju. Muszą wiedzieć, ile czasu zajmie opracowanie funkcji i ile to będzie kosztowało. Podaj im liczbę opartą na (fałszywym) założeniu, że ich wymagania są w 100% dokładne, a kiedy ich wymagania się zmienią, zmień swoje szacunki.

Daje im to pozycje w budżecie i daty wdrożenia, których chcą, a gdy coś się zmienia, proces pozwala wyglądać elastycznie i przychylnie.

Wygląda na to, że twoi sprzedawcy tworzą warstwę nieporozumień między zespołami programistycznymi a klientami. Jeśli od dawna nie sprzedawali na rynku IT, mogą postrzegać swoją rolę jako „przenieść produkt”, co oznacza, że ​​otrzymają podpis na umowie „cokolwiek by to zrobiło”. Krótko mówiąc, są zmotywowani do zamknięcia, niezależnie od tego, co obiecują. W takich okolicznościach będą śledzić język klienta tak dokładnie, jak to możliwe.

Cytuję to jako pobity rekord, ale oto proszę: jesteś na stole operacyjnym, a gdy idziesz pod chirurgiem, mówi: „Zabierzemy cię stąd na czas i w ramach budżetu”. Wspaniały. Czy będę żył?

Jeśli pracujesz nad organami wewnętrznymi firmy, czy zatrzymujesz się w jakimś arbitralnym punkcie? Zazwyczaj na aplikację nie mają wpływu siły ani Ty, ani Twój klient - kontrola, regulacje, klimat biznesowy, zachowanie konkurencji, pojawienie się nowego paradygmatu itp. Jeśli powiesz po prostu „zrobimy” rzecz x za „cena y”, to klient wróci trzy miesiące później i powie „dobrze ...”. Ogólnie oznacza to, że wiedzą coś, o czym nie wiedzieli, kiedy zgodziłeś się na projekt wodospadu.

To, co może zadziałać w takiej sytuacji, pokazuje własnym sprzedawcom, jak wygląda jazda przez kanion. Na każdym kroku są niespodzianki. Nie można zobaczyć więcej niż około trzech miesięcy, więc jeśli klient prosi o 18-miesięczny projekt, nie będzie można go rozpoznać przed zakończeniem. Dlatego przedstawiciel handlowy musi zacząć od znalezienia finansowej korzyści projektu. Czy zwiększy to sprzedaż o 10 milionów USD? Jeśli tak, to czy warto zainwestować 2 000 000 USD, aby uzyskać dodatkowe 10 milionów USD? Jeśli klient i przedstawiciel handlowy skupiają się na zobowiązaniu w wysokości 500 000 USD, to może być coś nie tak i nikt nie może powiedzieć, co to jest - po prostu nie wydaje się właściwe. To, co „źle się czuje”, to zobowiązanie do zrobienia czegoś, co grozi bezużytecznością.

Dwa najnowsze modele samolotów odrzutowych miały już historię Snafus. Healthcare.gov nawet nie potrzebuje dyskusji. Jeśli możesz znaleźć książki lub artykuły prasowe na temat samolotów pasażerskich, możesz poruszyć, w jaki sposób poczyniono pewne założenia, które okazały się optymistyczne, i że projekty wielokrotnie przekraczały swoje terminy. Często było to spowodowane niedocenianiem złożoności. Jeśli nie możesz naprawdę zrozumieć, jak skomplikowany jest, dopóki nie zaczniesz go kodować, będziesz potrzebować „pierwszej rundy”, aby lepiej zrozumieć prawdziwe problemy. Odcięcie budżetu powinno stanowić ułamek całkowitych dodatkowych zysków (lub przychodów w niektórych przypadkach), a liczba ta musi być większa niż ktokolwiek uważa, że ​​obecny projekt będzie kosztował. Jeśli potrafisz pokazać, w jaki sposób można przejść ostatni kamień milowy bez przekraczania „limitu wypłat”,

Główną przeszkodą w osiągnięciu korzyści Agile-Scrum poza opracowywaniem oprogramowania jest integracja go z istniejącymi mechanizmami kontroli. Te mechanizmy kontrolne są określone ze względu na różne warunki organizacyjne i zwykle są aktualizowane za pomocą podejścia i metodologii Linear Waterfall.

Cztery z tych typowych wymagań organizacyjnych przedstawiono poniżej:

• Wielkie globalne korporacje - w tych hierarchicznych organizacjach matrycowych kontrola portfela odgórnego jest regułą dnia. Swobodne podejście zwinne ma ciężki czas na dostosowanie się do rygorystycznych kontroli. W szczególności nieodłączne koncepcje Agile bez planu sprawiają, że Agile-Scrum jest trudny do przełknięcia przez organizację.

• Wysoko uregulowane branże - niektóre branże wymagają od organów ds. Zgodności i zarządzania ścisłego, wiążącego mechanizmu kontroli. Mogą to być na przykład jednostki biznesowe zajmujące się badaniami sprzętu medycznego, samolotów i farmaceutyków oraz opracowywaniem produktów. Podczas gdy poszczególne zespoły mogą obsługiwać Agile-Scrum, proces rozwoju musi być zgodny ze sztywną metodą liniowego wodospadu w celu śledzenia i zarządzania.

• Złożone wstępnie zdefiniowane produkty - niektóre zintegrowane produkty, które obejmują zarówno sprzęt, oprogramowanie, wbudowane i inne, są opracowywane jako umowa z klientem końcowym na podstawie wstępnie określonego zestawu wymagań. W takich przypadkach stopień elastyczności wymagań jest niewielki, choć większy niż początkowo przewidywano. W tych przypadkach znacznie ucierpiała koncepcja w pełni elastycznego zaległości Agile-Scrum.

• Ogólne działy IT - większość codziennych i cotygodniowych działań w działach IT związanych z utrzymaniem odbywa się ad hoc. Zmiany w harmonogramach dziennych są liczne i natychmiastowe. Ciągłe ingerencje w pracę zespołów są normą. W takich sytuacjach koncepcja boksu czasowego i braku interferencji jest trudna do utrzymania.

Oczywiście - wiele razy cztery odrębne kategorie wyszczególnione powyżej faktycznie się mieszają; tak więc w globalnej dużej firmie często znajduje się złożony produkt, który musi przestrzegać obowiązujących przepisów.

Opierając się na praktycznych doświadczeniach, zalecaną metodą radzenia sobie z tymi scenariuszami i innymi jest umożliwienie zwinnemu PMO działania jako aktywatora, kierowcy i tłumacza między powstającymi zespołami Agile-Scrum a elementami Linear Waterfall.

Szczegółowe wytyczne znajdują się w tabeli poniżej

Źródło - Interfejs między liniowym wodospadem a zwinnym podejściem Michaela Nira

Organizujemy 2 lub 3 sesje szacunkowe z potencjalnym klientem i naszymi programistami, podczas których omawiamy bieżącą pracę i ustalamy kryteria akceptacji. Twórcy oceniają pracę w punktach fabularnych podczas spotkania.

Następnie sprzedajemy klientowi kilka punktów historii. Jest to możliwe, ponieważ ma dobre pojęcie o wartości punktów fabularnych. Mówimy mu, że ma możliwość dostrojenia swojego zaległości / zakresu w trakcie projektu i że będzie to łatwe dzięki wykorzystaniu punktów historii. Mówimy mu również, że będzie często dostarczane działające oprogramowanie, aby mógł monitorować postępy i uzyskiwać nowe informacje.

Uzgodnienie kilku punktów historii gwarantuje, że klient uzyska wartość za swoje pieniądze. Jeśli nie zmieni swojego zaległości, ma projekt stałej ceny / zakresu, ale z mojego doświadczenia wynika, że ​​dokona zmian. Dokonując oszacowań w obecności potencjalnego klienta, staramy się budować relacje oparte na otwartości i zaufaniu.

Udało nam się przekonać klientów takich jak Ty, którzy „chcą budżetu i terminu”, i byli zadowoleni, że naprawdę chcieliśmy zrozumieć, czego potrzebują, zamiast pracować z dokumentu. Pokazaliśmy, że chcemy zainwestować w te projekty.

Podczas sesji szacowania oszacowaliśmy cały ich zaległości. To dało x punktów historii. Sugerujemy dodanie 25% dla funkcji, które nie były jeszcze jasne lub znane w tym czasie. Dzięki szacunkowym zaległościom związanym z umową zapewniono ich, że dostaną wszystko za ustalony budżet.

Pierwotnie oferta dotyczyła czasu i materiału. Ponieważ chcieli mieć ustaloną ofertę cenową, zaproponowaliśmy pracę za podaną przez nas cenę i wykorzystanie dodatkowych 25% punktów opowieści na nieprzewidziane wydatki. Jeśli wszystko pójdzie dobrze, część 25%, która nie została wykorzystana na pokrycie napotkanych opóźnień, zostanie wykorzystana do zapewnienia większej funkcjonalności dla klienta.

To pobudziło ich na wiele sposobów: po pierwsze, zrobili wszystko, co mogli, aby umożliwić naszym programistom pracę tak szybko, jak to możliwe, ponieważ było to wyraźnie w ich interesie. Nigdy nie musieliśmy czekać na odpowiedzi na pytania. Po drugie, naprawdę rozumieli koncepcję punktów historii. Przed rozpoczęciem projektu usunęli już niektóre historie i poprosili nas o oszacowanie innych. Nie były do ​​tego potrzebne skomplikowane negocjacje kontraktowe.

Informowaliśmy ich o postępach i utrzymywaliśmy bardzo otwartą komunikację. Dostają raport z postępu co 2 tygodnie: x% punktów opowieści wykonanych w% szacowanego czasu pozostawia z% dostępnych dodatkowych punktów opowieści. Mieliśmy trochę trudnego początku, ale udało nam się dogonić szacunki do końca projektu, co pozostawiło 100% dodatkowych punktów historii dostępnych do dalszego rozwoju. Klient był zadowolony, ponieważ otrzymał wszystko, czego naprawdę potrzebował (a to trochę różniło się od jego początkowo żądanych funkcji, niektóre z nich usunął i dodał inne).

Klient był również zadowolony, ponieważ wszystko zostało dostarczone w przewidzianych ramach czasowych (gdzie zrobił również wszystko, co możliwe, aby pomóc nam w pogoni za biletami, natychmiastowym odpowiadaniu na pytania, angażowaniu użytkowników w cotygodniowe spotkania analityczne, a także angażowaniu ich w testy funkcjonalne).

Moja firma była szczęśliwa, ponieważ dostarczyliśmy na czas i zgodnie z budżetem. Moja firma była również szczęśliwa, ponieważ sukces tego projektu otworzył drzwi dla kolejnych projektów. Zostaliśmy nawet wspomniani w miesięcznym magazynie klienta, który został wysłany do ludzi na całym świecie.

Wykonanie dobrych oszacowań było najtrudniejszą częścią projektu, ale przygotowanie sesji szacunkowych z góry pomogło nam zrozumieć trudność i ryzyko. Umożliwiło nam to oszacowanie na podstawie faktów i usunęło wiele niewiadomych.

Próba użycia metod Agile w środowisku konsultingowym / licytacyjnym jest bardzo trudna, gdy klienta nie ma na pokładzie.

Jeśli są przyzwyczajeni do stylu Wodospadu „oto nasze wymagania, ile i ile to zajmie?” pisać projekty i ogłaszać je przetargami, tak naprawdę nie ma czasu, aby przekonać ich, że Agile lub jakikolwiek inny sposób jest lepszy.

Zwinność ma swoje zalety (i wady oczywiście), ale szczerze mówiąc klient często nie zna szczegółów za kulisami ani nie dba o szczegóły.

Chcą 2 rzeczy - kosztów i skali czasowej. A kiedy im to powiesz, chcą, żeby było to tańsze i wcześniej. I wiesz co, chcemy tego wszystkiego. Wszystkie wymagania. Nikt nie może czekać ani zostać posiekany.

I chociaż nie lubię sprzedawców w większości dziedzin, nie bądź zbyt surowy dla sprzedawców. To ciężka praca.

Nie budują oprogramowania, przeważnie nie mają pojęcia, jak to wszystko działa po ostatnich słowach.

Jednak muszą wymyślić skale czasowe i koszty w oparciu o niektóre wełniane wymagania spełniające. Może mają ze sobą kilku techników, którzy nimi rządzą, ale muszą zrobić wyprzedaż, żeby wszystko działało.

Jak więc zdobyć siły sprzedażowe, które z powodzeniem sprzedają projekt wykorzystujący zwinne metody programistyczne lub produkt opracowany przy użyciu takich metod?

Mając swoich sprzedawców, przyprowadź klienta do biura. Celem zwinnego jest natychmiastowe uzyskiwanie informacji zwrotnych od klienta, abyś mógł produkować to, czego chce (i nie więcej). Sprowadź ich, zapytaj, czego chcą. Dwa tygodnie później przynieś je i pokaż demo / prototyp. Sprzedaj je podczas tej interakcji. Pokaż im postępy i wyjaśnij, że tego rodzaju iteracja jest tym, co chcesz zrobić, aby uzyskać dokładnie to, czego chcą.

Podaj szacunkową ilość pracy (w końcu taki jest budżet), ale pozwól im mieć moc (czytaj: odpowiedzialność), aby uwzględnić to, co chcą zmieścić w swoim budżecie.

Myślę, że odpowiedź brzmi: w większości przypadków prawdopodobnie nie. Na początku postaram się to postrzegać jako małą część twojego biznesu - być może 20%, a resztę w tradycyjnym modelu. Z biegiem czasu starałem się bardziej skoncentrować na produktach Agile i klientach i starać się, aby ta część rosła bardziej.

Inną częścią rozwiązania tego problemu może być próba zastosowania obu podejść. Skorzystaj z podejścia typu „wodospad” z kadrą kierowniczą wyższego szczebla i osobami negocjującymi umowy. Na przykład „system umożliwiający klientom utrzymywanie portfeli i podejmowanie decyzji inwestycyjnych przy użyciu zarówno urządzeń przeglądarkowych, jak i telefonów komórkowych (Apple i Android)”. czy coś takiego. Następnie użyj Agile do rozwoju zespołu programistycznego przy bardziej szczegółowych funkcjach, np. Utwórz stronę główną, Utwórz stronę logowania, Utwórz historię zarządzania portfelem, Utwórz logowanie mobilne itp.

Innym pomysłem jest uczynienie Agile swoim wyróżnikiem. Wiem, że wiele, jeśli nie większość dużych organizacji, nie działa zwinnie. Jednak większość (zdecydowana większość z mojego doświadczenia) małych firm to. Myślę, że Agile szybko rośnie i tak będzie dalej. Zaletą tej trasy jest to, że przekazujesz to, co najbardziej chcesz zrobić klientom, którzy już ją rozpoznają. Podejście to będzie wymagać pracy z czasem bez gwarancji sukcesu.

Możesz również znaleźć przyczepność, jeśli Twoi klienci lubią testować. Posiadanie dobrze przetestowanych produktów może być łatwiejszym rozwiązaniem dla niektórych klientów. Pomocna w tej dziedzinie jest książka „Agile Testing” Adison Wesley Press.

Możesz również wykorzystać bieżące wydarzenia do wsparcia swojej sprawy. Na przykład obecna (pisząca to w październiku 2012 r.) Witryna opieki zdrowotnej stanowi doskonały argument na to, jak NIE radzić sobie ze zmianami, które były potrzebne 2 tygodnie przed uruchomieniem. Również pozorna nadmierna inżynieria prawdopodobnie byłaby lepiej rozwiązana w przypadku bardziej zwinnych metod.

Skontaktuj się z poprzednimi klientami, którzy są zadowoleni z Twojej pracy. Zwłaszcza jeśli są konwertami wodospadów na zwinne. Przynajmniej konwersje, które nie były Twoimi klientami.

Ich referencje (jako klienta) przeważą wszystko i wszystko, co możesz powiedzieć. Mogą rozwiać obawy i obawy nowego klienta bardziej niż kiedykolwiek.

Z punktu widzenia zarządzania budżet i termin są potrzebą biznesową projektu. Musisz upewnić się, że spełniasz te potrzeby, a jeśli spojrzysz na opinie firm na temat zmiany, zauważysz, że pojawia się to bezpośrednio. Jeśli spojrzysz na opinie programistów na temat zmiany, zauważysz, że często tak nie jest.