Radzenie sobie z niedopasowaniem kultury klienta / programisty w zwinnym projekcie

Jednym z założeń zwinności jest ...

Współpraca z klientami w zakresie negocjacji umów

... innym jest ...

Osoby i interakcje dotyczące procesów i narzędzi

Ale z mojego punktu widzenia, przynajmniej jeśli chodzi o interakcję z klientem, istnieje podstawowy problem:

To, co myśli klient, różni się od tego, jak myśli inżynier oprogramowania

To może być trochę uogólnienie, tak. Prawdopodobnie nie są dziedzin biznesu, gdzie to niekoniecznie jest prawdą --- to są nieliczne chociaż. Jednak w wielu domenach typowym klientem jest:

1. Zainteresowany codziennymi problemami operacyjnymi - taktyka krótkiego zasięgu ... niekoniecznie strategia;
2. Zrozumiałe, że dotyczy tylko natychmiastowego rozwiązania;
3. Praktyczni myśliciele, a nie myśliciele abstrakcyjni;
4. O wiele bardziej zainteresowany „wykonaniem zadania” niż rozważeniem, w jaki sposób rozwiązanie będzie wspierać przyszłe obawy.

Z drugiej strony, w idealnym przypadku inżynierowie oprogramowania, którzy ćwiczą sprawność, to:

1. Ludzie, którzy dużo myślą o jakości;
2. Osoby, które doceniają, jak odrobina pracy z góry może zaoszczędzić mnóstwo wysiłku w dalszej kolejności;
3. Doświadczeni analityczni myśliciele.

Wydaje się więc, że istnieje rozbieżność kulturowa, która zwykle hamuje „współpracę z klientem”.

Jak najlepiej to rozwiązać?

Jednak w wielu domenach typowym klientem jest:

• Zainteresowany codziennymi problemami operacyjnymi - taktyka krótkiego zasięgu ... nie strategia;
• Dotyczy tylko natychmiastowego rozwiązania;
• Generalnie jednowymiarowi, nieabstrakcyjni myśliciele;
• Zainteresowany przede wszystkim „wykonaniem zadania”, a nie opracowaniem trwałego rozwiązania wysokiej jakości.

I szczerze mówiąc, zwykle mają dobre powody, aby tak myśleć. Przede wszystkim prowadzą oni biznes, który powinien generować przychody dziś i jutro, a nie w odległej przyszłości. Po drugie, nie są ekspertami technicznymi - nie wiedzą, co jest możliwe, a co nie, i jakie są konsekwencje konkretnych wyborów architektonicznych / projektowych / wdrożeniowych. To, co my wiemy.

Tak więc odpowiedzią jest - nie dziwi - komunikacja .

Musisz dużo komunikować się, edukować się nawzajem, aby nawzajem rozumieć punkt widzenia drugiej strony przynajmniej na poziomie podstawowym. Musisz wyjaśnić im krótko- i długoterminowe konsekwencje możliwych alternatyw. I musisz używać języka, który rozumieją .

• Jeśli powiesz „to byłby włamanie, które powoduje, że kod jest mniej czytelny i rozszerzalny” , mówią „tak, cokolwiek” .
• Jeśli powiesz „byłoby to krótkoterminowe rozwiązanie, które spowodowałoby, że długoterminowy rozwój i utrzymanie byłyby bardziej kosztowne i zwiększyłyby ryzyko wprowadzenia błędów” , mówią „ha, zastanówmy się” .
• A jeśli powiesz: „to rozwiązanie kosztuje teraz 100 USD, ale wprowadza 500 USD długu technicznego, który wcześniej czy później spłacisz wraz z odsetkami; OTOH to drugie rozwiązanie kosztuje teraz 400 USD i nie pozostawia długu technicznego; wybierz ten, który chcieć ” , mówią „ teraz rozmawiamy! ” .

OTOH mogą nauczyć nas kilku rzeczy na temat perspektywy biznesowej. Biznes chce użytecznych i wystarczająco dobrych - mało idealnych - rozwiązań. I wiedzą chyba lepiej niż ktokolwiek inny, że „doskonały jest wrogiem dobra”. Należy więc pamiętać, że naszym zadaniem jest dostarczanie rozwiązań problemów naszych klientów, a nie tworzenie oprogramowania doskonałego pod względem technicznym. Czasami te dwa zbiegają się w to samo, ale częściej nie. Dla wielu może to być smutne, ale jest to rzeczywistość biznesowa. Dla mnie, jeśli udało mi się rozwiązać problem mojego klienta i widzę, że dzięki temu jego życie było wyraźnie łatwiejsze, jestem równie szczęśliwy jak oni. OTOH, jeśli uda mi się wdrożyć idealny projekt, o którym myślę, ale w następnym tygodniu firma zbankrutuje, czyż nie jest to żadna wygrana, prawda?

Rozsądny właściciel firmy zrozumie - jeśli wyjaśnisz je własnym językiem - dlaczego ważne jest utrzymywanie oprogramowania w czystości, pisanie testów jednostkowych, refaktoryzacja itp. Mimo że wydaje się, że nie wnoszą one bezpośredniego wkładu w krótkim okresie, są niezbędne do długoterminowej konserwacji. Rozsądnym klientom zależy na długoterminowym utrzymaniu ich działalności, więc z pewnością chętnie w nie zainwestują, gdy zobaczą wartość, jaką generują ich inwestycje. Jednak zarówno ich zasoby, jak i czas są ograniczone, więc musisz ustalić priorytety i skoncentrować się na najważniejszych rzeczach. Ale jest to ważne tylko wtedy, gdy jest ważne dla was obojga .

Możesz zrefaktoryzować moduł A, ponieważ kod tam jest po prostu okropny, i masz niesamowity pomysł, jak refaktoryzować kod, aby był zwięzły, elegancki i czysty, używając wzorca projektowego, o którym właśnie przeczytałeś. Jeśli jednak ten moduł nie był dotykany przez lata i działa niezawodnie, prawdopodobnie lepiej skupić się na module B, który zostanie rozszerzony w przyszłym tygodniu o bardzo ważną nową funkcję i zawiera mnóstwo błędów już.

Jak postrzegają siebie klienci:

• Mam projekt, który muszę wykonać jak najszybciej
• Znam potrzeby mojej firmy
• Muszę rozwiązać problem w sposób, który nie będzie zakłócał obecnych praktyk biznesowych
• Mam ograniczony budżet, żeby to zrobić.

Z drugiej strony widzą Twoją grupę jako:

• Faceci, którzy nie rozumieją, że wysysają pieniądze z mojego budżetu.
• Nie rozumiem potrzeb naszej firmy
• Chcesz przeprojektować wszystko, nawet jeśli utrudni to wdrożenie w firmie.
• Chcesz mieć sprytne rozwiązanie, gdy wszystko, na co mam budżet, jest funkcjonalne i skuteczne.

Wydaje się, że twoim głównym problemem nie jest zrozumienie, czego potrzebują od drugiej strony.

Po pierwsze, Agile nie jest rozwiązaniem wszystkich problemów, które masz w swoim projekcie.

To, co myśli klient, różni się zasadniczo od tego, co myśli inżynier oprogramowania

Tak. Czasami to prawda. Zdarzają się nawet przypadki, gdy klienci nie wiedzą, czego chcą i jak chcą (tzn. Wymagania nie są jasne). Co więcej, jeśli jesteś zwinny, otrzymujesz wynik po każdym sprincie (powiedzmy 2 tygodnie) i masz okazję uzyskać opinie od klientów i upewnić się, że wszyscy są na tej samej stronie. Pomaga to w wczesnym wykryciu i naprawieniu problemów, co wewnętrznie pomoże zbudować zaufanie.

Jest też powiedzenie, że użytkownicy są jak szalone dzieci, więc kiedy proszą o broń i wiesz, że to nie jest bezpieczne, możesz rozważyć użycie pistoletu zabawkowego, aby je uspokoić .

Jak najlepiej to rozwiązać?

Jak już powiedziałem, nie ma magicznego kija, który mógłby rozwiązać wszystkie te problemy . Musisz bardziej angażować klientów, aby dobrze rozumieć, co robią inni. Promuj wizytę na stronie, otwieraj opinie itp.

Upewnij się, że właściciel produktu i udziałowcy biorą udział w pokazach sprintu i zawierają cenne sugestie dotyczące ulepszenia produktu .

Jeśli nie masz wpisowego od klienta, Agile może być prawie niemożliwe.

Przez wpisowe mam na myśli uzyskanie pewnej procentowej reprezentatywnej liczby przedstawicieli klienta na tydzień lub miesiąc. Odsetek ten będzie się różnić w zależności od projektu.

Oczywiście mają swoją codzienną pracę, więc nie jest to tylko kwestia przedstawiciela klienta, ale zarządzanie nimi zależy od czasu.

Tak więc uzyskanie zgody od kierownictwa po stronie klienta jest kluczem do tego problemu

Pamiętaj, że zwinność nie oznacza, że ​​klient bierze udział w codziennych awariach lub niektórych innych aspektach zwinności. Zwinny, z punktu widzenia klienta, dotyczy komunikacji. To nie znaczy, że komunikują się z inżynierami na temat szczegółów implementacji.

Klienci współpracują z właścicielem produktu, aby uzyskiwać i przekazywać ciągłe informacje zwrotne. Tematem są funkcje, ale nie sposób ich implementacji. Czy dostarczasz odpowiednie funkcje? Czy jesteś w porządku? Czy mają zmieniające się wymagania, do których musisz się dostosować?

Zwinny pomaga Tobie i Twojemu klientowi odpowiedzieć na te pytania.