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

13

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?

TCSGrad
źródło
20
W programowaniu wszystko jest możliwe. Pamiętaj tylko, że „Tak” nie jest odpowiedzią na „Ile to zajmie?”
Steven Evers,
9
@SnOrfus: Niektórych problemów po prostu nie da się rozwiązać. Jeśli uważasz inaczej, zaprogramuj prognozę pogody, która powie ci, czy będziemy mieli białe Boże Narodzenie.
Loren Pechtel,
5
@Ellz: zakładając, że wszechświat jest deterministyczny, co niekoniecznie jest prawdą.
whatsisname
4
Przepraszam, niemożliwe. Pogoda staje się chaotyczna po siedmiu do dziesięciu dniach. Istnieje bardzo znany artykuł na ten temat: „Przewidywalność: czy klapa skrzydeł motyla w Brazylii wywołuje tornado w Teksasie? autor: Edward Lorenz.
David Hammen
26
Jeśli programiści złożą obietnice, których nie będą w stanie dotrzymać, co zrobią sprzedawcy?
JeffO,

Odpowiedzi:

20

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?

David Hammen
źródło
2
+1 Nie obejrzałem wcześniej tej listy połączonej, dobra robota dla wskazania, że ​​jest tam naprawdę okropna rada. Facet może być dobrym programistą, nie mam pojęcia, ale jest pewien, że nie jest to dobry znak, a ta rada brzmi, jakby pochodziła z comiesięcznej szmaty IT-for-manager.
Jimmy Hoffa
+1 - Nigdy nie mówię „Nie” klientom (chyba że nie chcę ich więcej widzieć) - Zawsze jest to takie samo jak „Będzie kosztować X dolarów”, „Twój stos technologii nie obsługuje tego” itd. „Nie” zamyka problem martwy. użyj odpowiedzi, które ją otwierają, do dalszej dyskusji. np. „… ale mógłbym dać ci 90% tego, czego chcesz za 10% kosztów” lub „… Ale mógłbym to wdrożyć w ten sposób i dać ci rozwiązanie, które działa w ten sposób…”
mattnz
1
@mattnz - Trudno powiedzieć „Nie”, ale czasem jest to konieczne. „Czy zdołasz zrobić tę zmianę do jutra?” Więc nie. Ale mogę go zdobyć do końca tygodnia. „Czy mógłbyś przeprowadzić analizę Monte Carlo dla każdej z tych kilkuset zmiennych kontrolnych zmieniających się losowo na przebieg?” To właśnie przyniosło odpowiedź „w którym tysiącleciu chcesz rezultatu”. Omówiłem klątwę wymiarowości i zasugerowałem, aby ograniczyć tę listę do czegoś rozsądnego. To, jak mówisz „nie”, jest ważne, ale czasami musisz powiedzieć „nie”. Oczywiście dyplomatycznie.
David Hammen,
10% odsetek niepowodzeń stanowiłby MASYWNĄ poprawę w stosunku do obecnych średnich wskaźników sukcesu w dostarczaniu oprogramowania.
Graham
Odnośnie analogii lądowania samolotu - samoloty lądują bezpiecznie każdego dnia. Jeśli jestem pilotem i odpowiadam „pozwól, że do ciebie wrócę”, na pytanie, czy mogę bezpiecznie wylądować moim samolotem, to nie kupi mi żadnej karmy z pasażerami. Nawet jeśli wiem, że istnieje niewielka szansa na wpadkę przy lądowaniu, jest to dobry przykład tego, gdzie wykazanie zaufania do moich umiejętności pilota jest ważniejsze niż skupienie się na małej szansie na niepowodzenie.
Cliff
24

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.

Jeanne Boyarsky
źródło
17
Często lepiej jest upewnić się, że klient powie ci, jaki problem chce rozwiązać. Zamiast starać się rzucić okiem na rozwiązanie, którego chcą . Rozwiąż problem… i powiedz im rozwiązanie.
Simon Whitehead,
+1 i więcej - dwa bardzo dobre punkty, które robisz - nigdy nie mów „nie” i nie tracisz wiarygodności z klientem.
mattnz
+1 „Klient będzie cię szanował, jeśli jesteś uczciwy”. To stwierdzenie jest tak prawdziwe i warte złota. Przedstawiając opcje klientowi, bądź uczciwy. Po prostu powiedz im, że to, o co proszą, nie jest gotowym widgetem, który można kupić i podłączyć. Poinformuj ich, że proszą o niestandardowe rozwiązanie, a niestandardowe oprogramowanie jest bardzo drogie. Zwykle powoduje to jedną z dwóch rzeczy. 1.) Chcą efektywnej kosztowo alternatywy. 2.) Są gotowi zapłacić za niestandardowe rozwiązanie. Tak czy inaczej, jest to wygrana / wygrana.
Michael Riley - AKA Gunny
6

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.

Joshua Burns
źródło
6

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

DeveloperDon
źródło
+1 za odniesienie do kodeksu etycznego w celu udzielenia odpowiedzi na pytanie dotyczące etyki.
Jay Elston,
5

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.

Rachunek
źródło
4

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.

Klif
źródło
3

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.

Tulains Córdova
źródło
1

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.

ronin
źródło
1
to najlepszy sposób, aby ... sprawić, że użytkownicy będą niezadowoleni. Najczęściej doprowadzi to do zmniejszenia zysków
komara
3
Szczerze mówiąc, dla niektórych programistów In-House nie jest to okropny pomysł. Praca w domu zwykle nie jest rozliczana bezpośrednio (IT jest tylko częścią ogólnego budżetu) i możesz zostać przytłoczony żądaniami bzdur, ponieważ osoby żądające nie tracą pieniędzy, spamując cię pracą.
Graham