Czy obiecujesz dostarczyć funkcję, której nie jesteś pewien, czy można ją wdrożyć?

W artykule z HN natrafiłem na następującą radę:

Zawsze mów klientowi / użytkownikowi „tak”, nawet jeśli nie masz pewności. W 90% przypadków znajdziesz sposób, aby to zrobić. W 10% przypadków wrócisz i przeprosisz. Niewielka cena za duży rozwój osobisty

Ale zawsze uważałem, że należy dokonać analizy wykonalności przed złożeniem jakichkolwiek obietnic klientowi / użytkownikowi, aby nie zostali wprowadzeni w błąd w żadnym momencie. W jakich okolicznościach powyższe porady powinny mieć zastosowanie?

To drugie pytanie w krótkim czasie wywołane przez ten artykuł.

• Dobry programista: optymalizuję kod. Lepszy programista: uporządkuję dane. Najlepszy programista: jaka jest różnica?
  Jest na to inna nazwa: przedwczesna optymalizacja.

• Nigdy nie używaj wcześniejszych wyjść.
  To zasada „pojedynczego punktu wejścia / pojedynczego punktu wyjścia”. Jest to poprawka nad prawdziwym problemem, który polega na tym, że wcześniejsze wyjście może pozostawić bałagan. Właściwą zasadą jest „posprzątaj swój bałagan”. Jeszcze lepszą zasadą jest stosowanie konstrukcji danych, które usuwają się po sobie, aby programista nie musiał się martwić o sprzątanie bałaganu.

• A teraz zawsze mów klientowi / użytkownikowi „tak”, nawet jeśli nie masz pewności. W 90% przypadków znajdziesz sposób, aby to zrobić.
  To też jest niesamowicie zła rada.

Czasami Twojemu klientowi należy powiedzieć „nie” lub „w którym tysiącleciu tego chcesz?” Nie obiecuj czegoś, co zniszczy Twoją architekturę, będzie kosztować znacznie więcej, niż klient jest skłonny wydać, lub że nie masz pojęcia, jak to osiągnąć. Znasz technologię, a nie klienta. Jeśli nie wiesz, jak to zrobić, nie mów, że możesz to zrobić. Jeśli nie jesteś pewien, powiedz, że potrzebujesz czasu na zbadanie, czy to możliwe. Lepiej być szczerym, a to pozwoli ci uniknąć kłopotów.

Klienci szybko stają się byłymi klientami, jeśli nie możesz dotrzymać obietnic. 10% wskaźnik awaryjności może wydawać się niewielki, ale to na 10%, na czym skupią się Twoi klienci. Czasami pozywają Cię, gdy nie dotrzymujesz obietnicy. Naprawdę tego nie chcesz. Innym razem, upewnienie się, że dotrzymasz obietnicy, może doprowadzić do bankructwa, szaleństwa lub utraty współmałżonka, ponieważ pracujesz przez 18 godzin. Ty też tego nie chcesz.

Pomyśl o tym w ten sposób: Jak myślisz, co stałoby się z branżą lotniczą, gdyby 90% wszystkich lądowań samolotów zakończyło się powodzeniem? Czy myślisz, że powrót i przeprosiny za 10%, które się rozbiły, naprawiłyby cokolwiek?

Lepiej byłoby powiedzieć „Myślę, że da się to zrobić”. lub „Sprawdzę i skontaktuję się z Tobą”. Miałem czasy, w których powiedziałem „nie” lub „kontr” zaproponowałem coś. Jeśli klient chce „aplikacji opartej na przeglądarce, która działa bez połączenia z Internetem i wykorzystuje dotykowe informacje zwrotne”, prawdopodobnie jest to możliwe. Jest to jednak kosztowne i bardziej przydatne byłoby omówienie rzeczywistych potrzeb.

Klient będzie cię szanował, jeśli będziesz szczery. W radzie w pytaniu osoba myli się przez 10% czasu. Jeśli pracuję z kimś, kto rutynowo się myli co dziesięć razy, wcale mu nie zaufam. To okropne doświadczenie.

Obiecanie księżycowi i dostarczenie skały jest rodzajem podejścia sprzedawców, którego nie należy tolerować. Jeśli nie wiesz, czy to możliwe, sprawdź to. Lub podaj im cytat, ile czasu zajmie Ci przyjrzenie się temu. W ten sposób nie obiecujesz niczego, czego nie możesz dostarczyć, ale zarabiasz za czas, który zajmie Ci zajrzenie.

To pytanie zostało zbadane formalnie i zostało rozwiązane przez wspólnie opracowany IEEE Computer Society / ACM Code of Ethics .

2.01 Świadczymy usługi w obszarach ich kompetencji, uczciwie i szczerze mówiąc o wszelkich ograniczeniach ich doświadczenia i wykształcenia.

3,04. Upewnij się, że kwalifikują się do każdego projektu, nad którym pracują lub proponują pracę, poprzez odpowiednią kombinację edukacji i szkolenia oraz doświadczenia.

3.09 Zapewnienie realistycznych szacunków ilościowych dotyczących kosztów, harmonogramu, personelu, jakości i wyników każdego projektu, nad którym pracują lub proponują pracę, oraz zapewnia ocenę niepewności tych szacunków.

5.05 Zapewnienie realistycznych szacunków ilościowych dotyczących kosztów, harmonogramu, personelu, jakości i wyników każdego projektu, nad którym pracują lub proponują pracę, oraz zapewnienie oceny niepewności tych szacunków.

Z pewnością obiecanie czegoś, czego nie możesz dostarczyć, ma konsekwencje biznesowe i prawne. Zazwyczaj pochodzą one od klienta, który udał się gdzie indziej, odmówił zapłaty lub pozwał firmę. Jeśli współpracujesz z innymi osobami, mogą oni domagać się odszkodowania, jeśli Twoja część nie zostanie dostarczona. Pozwy mogą pochodzić nawet od konkurentów.

Jest historia z wczesnych czasów superkomputerów, w której Seymour Cray i zespół Control Data Corporation byli bliscy wprowadzenia produktu, a inna bardzo duża firma komputerowa powiedziała swoim klientom, że wkrótce będzie na rynku. Kłamstwo kosztowało CDC dużo biznesu i zamieniło się w proces, w którym duża firma nie mogła przedstawić żadnych wiarygodnych dowodów na swoje roszczenia. Rezultatem było wówczas duże porozumienie o wartości 80 milionów dolarów z 1970 roku (około 223 milionów dolarów w 2012 r., Skorygowane o inflację). Możesz przeczytać o tym tutaj:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Przy wystarczającym czasie, zasobach i elastyczności wokół definicji sukcesu wszystko jest możliwe. Biały przykład masy X jest prosty, jeśli chcesz uzyskać dokładność większą niż 50%, a użytkownik ma położenie geograficzne użytkownika i trochę danych statystycznych.

Prawdziwe pierwsze pytanie w większości projektów nie brzmi, czy coś jest możliwe, ale czy jest uzasadnione, biorąc pod uwagę pewien zestaw okoliczności.

Czy funkcja dodaje wystarczającej wartości, aby uzasadnić koszt próby?

Nawet jeśli pomysł byłby niesamowity, gdyby wymagał długiego okresu programowania lub nabycia bardziej egzotycznego sprzętu, lepiej byłoby, aby klient wiedział o tym z góry, a następnie w większości przypadków skierował rozmowę z powrotem na bardziej rozsądne cele.

Jeśli ktoś jest wystarczająco szalony, aby dać ci czek in blanco i nie ma terminu, to zdecydowanie powiedz mu, że wszystko jest możliwe, po prostu daj mu znać, że musisz wymyślić i rozpowszechnić kilka technologii zaangażowanych w osiągnięcie celu po drodze.

Z drugiej strony, w kontaktach z rozsądnymi klientami z rozsądnymi zasobami czasami nie ma nic gorszego niż powiedzenie klientowi, że niektóre funkcje muszą zostać odcięte po wyrażeniu na to zgody, ponieważ mogą już uciekać i spędzili czas / pieniądze / zasoby na promocji lub udokumentowanie tego, a 10% mogło być tym, co sprawiło, że projekt stał się bardziej zielony. Wpadnij na te sytuacje, a właśnie straciłeś klienta i bardziej niż prawdopodobne zyskałeś bardzo słowne złe referencje na całym rynku.

Gra adwokata diabła

Będąc analitycznym sposobem myślenia, ludzie techniczni mogą zwykle zakładać, że ich wydajność będzie oceniana przede wszystkim na podstawie karty wyników wypełnionych i zatwierdzonych wniosków, ale w praktyce nie jest tak wycięta i wysuszona.

Zanim jeszcze rozpocznie się rozwój, klienci zaczynają formułować opinie na temat wyników zespołu na podstawie ich poziomu pewności siebie i gotowości do zaangażowania.

Wynika to częściowo z tego, że klienci mogą mieć trudności z oceną, czy wahanie się wykonawcy przed popełnieniem zobowiązania wynika z samej trudności żądania lub z braku zdolności wykonawcy.

Ponieważ nie ma bezwzględnych kryteriów pomiaru trudności żądania, często ważniejsze dla klienta jest zaufanie, że wykonawca dokłada 100% wysiłku, a nie spełnienie 90% lub 100% żądań.

Załóżmy, że klient musi wybrać jeden z dwóch scenariuszy:

Wykonawca A :

• Pewni, że mogą spełnić wszystkie żądania
• Wynik: 90% dostarczonych wniosków
• Klient jest zadowolony, że wykonawca włożył 100% wysiłku
• Klient uważa, że ​​niezrealizowane zamówienia były spowodowane nieprzewidzianymi problemami, które prawdopodobnie pozostają poza kontrolą wykonawców

Wykonawca B :

• Zobowiązuje się do dostarczenia 90% żądań. Nie jestem pewien, czy uda im się zrealizować pozostałe 10%
• Wynik: 90% dostarczonych wniosków
• Klient jest rozczarowany, że wykonawca nie próbował zrealizować pozostałych 10% swoich żądań
• Klient zakłada, że ​​niezakończone 10% wniosków wynikało z braku wysiłku lub zdolności wykonawcy

W obu scenariuszach dostarczono taką samą liczbę żądań; jednak klient uznał, że „nadmiernie zaangażowany” wykonawca A włożył 100% wysiłku i wykorzystał to do potwierdzenia, że ​​pozostałe żądania były naprawdę trudne, na uznanie kontrahenta A.

Z drugiej strony, klient miał wrażenie, że Wykonawca B nie daje 100% wysiłku, a jego niezdolność do spełnienia wszystkich żądań wynika z braku wysiłku lub zdolności Wykonawcy B.

Zastrzeżenie: Nie opowiadam się za nadmiernym zaangażowaniem jako strategii; jest to tylko obserwacja możliwej sytuacji w świecie rzeczywistym, w której nadmierne zaangażowanie może mieć pozytywne skutki.

Powinieneś powiedzieć im, aby dać ci czas na stworzenie „rozwiązania szczytowego” .

Rozwiązaniem szczytowym jest mały program, który, kodując go, pozwala dowiedzieć się, jak to zrobić, a nawet czy w ogóle jest to możliwe, co powoduje niepewność w projekcie.

Załóżmy na przykład, że nigdy nie wysłałeś SMS-a programowo, ale jakoś wiesz, że to możliwe. Rozwiązaniem szczytowym byłoby stworzenie małego programu, który wysyła SMS-y. W ten sposób nie jest już niepewność i można dokonać dalszych szacunków wykonalności.

Oto, co mówi o tym dokumentacja eXtreme Programming :

Twórz rozwiązania szczytowe, aby znaleźć odpowiedzi na trudne problemy techniczne lub projektowe. Rozwiązanie szczytowe jest bardzo prostym programem do poszukiwania potencjalnych rozwiązań. Zbuduj skok, aby rozwiązać tylko badany problem i zignoruj ​​wszystkie inne obawy. Większość kolców nie jest wystarczająco dobra, aby je utrzymać, więc spodziewaj się, że je wyrzucisz. Celem jest zmniejszenie ryzyka problemu technicznego lub zwiększenie wiarygodności oszacowania historii użytkownika. Gdy trudności techniczne grożą wstrzymaniem rozwoju systemu, umieść parę programistów na problemie przez tydzień lub dwa i zmniejsz potencjalne ryzyko.

Z mojego doświadczenia wynika, że ​​gdy użytkownik czegoś zażąda, należy zapytać go o szczegółową specyfikację tego, czego naprawdę chce lub potrzebuje. Najczęściej nigdy więcej nie usłyszysz o tej prośbie.