Skłonienie nie-programistów do zrozumienia procesu programowania

Rozpoczynając projekt dla firmy, która nie jest przede wszystkim firmą programistyczną, jednym z oczekiwań jest to, że na końcu jest gotowy produkt wolny od wszelkich błędów i robi wszystko, co potrzebne. Jednak rzadko tak jest.

Jakie są sposoby zarządzania oczekiwaniami i wyjaśniania programistom, czym różni się tworzenie oprogramowania od innych rodzajów tworzenia produktów?

Prawie każdy z komputerem napotkał ostatnio pojęcie „błędów”, więc możesz zacząć od tego. „Jaki jest najbardziej irytujący sposób, w jaki aplikacja Cię nie zawiodła? Pomnóż to przez dziesięć, a będziesz mieć doświadczenie naszych użytkowników, jeśli nie poświęcimy wystarczających zasobów na testowanie i konserwację”.

I nie lekceważ wartości nawiązywania dobrych relacji roboczych z programistami. Jeśli uda ci się ustalić, że twojemu osądowi można zaufać, wezmą cię na poważnie, gdy włączysz alarm, że X spadnie spektakularnie, jeśli nie zrobisz Y pronto, nawet jeśli nie rozumieją całkowicie twojego rozumowania.

Jednym ze sposobów, które uważam za skuteczne, jest:

Wszyscy wiemy, że komputer robi tylko i dokładnie to, co mu polecono.

Programowanie to sposób, w jaki mówimy teraz komputerowi, co mamy robić później .

Oznacza to, że sposób, w jaki zachowujesz się teraz, wynika z połączonych intencji każdego, kto napisał dowolny kod działający na twoim komputerze. Biorąc pod uwagę złożoność systemu operacyjnego, sterowników, środowiska programistycznego, bibliotek itd., Łatwo zauważyć, że w większości systemów musi być zaangażowanych ponad 20 000 osób i że może być ich ponad 100 000.

Kod napisany przez każdą osobę odzwierciedla jej zrozumienie, motywację, intencję i możliwości. Biorąc pod uwagę, że bezbłędne działanie systemu wymaga, aby cały kod napisany przez te 20 tys. Osób wchodziło w interakcję bezbłędnie - że cały kod musi zgadzać się co do znaczenia i interpretacji wymaganego zachowania, zaskakujący fakt nie polega na tym, że mamy błędy, ale że mamy ich tak mało.

IMO, przekonałem się, że przejrzystość oferowana przez zwinne procesy (np. Scrum, Crystal itp.) Ma duże znaczenie dla pokazania, jak działa rozwój dla przeciętnego interesariusza.

Wyjaśnienie za pomocą metafory jest nieszczelną abstrakcją, ale oto kilka pomysłów, które często działają dla mnie:

Zauważ, że żadne z tych wyjaśnień nie usprawiedliwia niedbałej pracy.

Pomyśl o programie komputerowym jak o maszynie, gdzie każda zmienna jest częścią ruchomą. To sprawia, że ​​nawet prosty program jest maszyną złożoną z setek ruchomych części.

Kiedy to się nie powiedzie, powracam do faktu, że chociaż matematycznie możliwe jest udowodnienie, że program nie zawiera błędów, zajmuje dużo czasu i nie będzie wart wysiłku.

Na koniec pytam, czy Intel i Microsoft nie są w stanie uniknąć błędów. Jak tego oczekują?

Odpowiedziałem bardziej szczegółowo na podobne pytanie , ale sedno brzmi: „Programowanie jest jak budowanie fabryki lub linii montażowej”.

Tradycyjnym sposobem określenia tego jest Trójkąt Zarządzania Projektem: trzy konkurujące ze sobą kryteria zakresu, kosztów i harmonogramu; zazwyczaj wyrażany jako „tani, szybki, dobry - wybierz dwa”.

Pod koniec procesu projektowania, opracowywania i wdrażania oczekiwanie, że produkt jest względnie wolny od wad projektowych i działa z określoną funkcjonalnością, jest całkowicie uzasadnione. To samo oczekiwanie jest całkowicie nierozsądne w odniesieniu do projektu, procesu lub zawodu.

Jaki profesjonalista oparty na naukach, twardy czy miękki, nie przechodzi przez proces eksploracji, tworząc niedokładne i nieprecyzyjne konceptualizacje, stosując mniej niż optymalną (lub po prostu błędną) taktykę, odkrywając, co działa metodą prób i błędów, i powtarzając przetwarzać w kółko, aż wyczerpią się zasoby lub osiągnięty zostanie wystarczający poziom wydajności?

Żaden proces nigdy nie jest wolny od wad, chociaż może asymptotycznie zbliżyć się do wyższych poziomów jakości.

Dotyczy to zawodu lekarza, w którym taktyka często wymaga zgadywania i protokołów, a znaczna część tej działalności polega głównie na debugowaniu głównie oprogramowania typu wetware. Dotyczy to inżynierii lądowej i architektury, w których zastosowania nowatorskich materiałów inżynierskich muszą być poddane walidacji w terenie i mogą nagle zawieść po wielu latach eksploatacji, pomimo ścisłego przestrzegania norm. Dotyczy to branży motoryzacyjnej, w której wiek i zmiany warunków eksploatacji zwykle wpływają na osiągi do momentu awarii, bez winy zastosowanych usług inżynieryjnych lub naprawczych. Pod tym względem rozwój oprogramowania nie różni się zasadniczo od tych zawodów, po prostu większą część jego zainteresowania skupia się na tworzeniu nowatorskich, celowych maszyn.

Jeśli znasz się na tworzeniu oprogramowania hi-rel, na przykład do sterowania reaktorem jądrowym, komunikacji w kosmosie lub implantów medycznych (itp.), Możesz wyjaśnić, w jaki sposób struktura kosztów i czasu dostawy dla tego poziomu zarządzania projektami i kontroli jakości mogą być o wielkości większe niż typowe firmy mogą sobie pozwolić na projekty oprogramowania.

Możesz porównać to do tego, co widzą, i jeśli to możliwe, używaj codziennie.

Na przykład samochód. Samochody zaczęły tworzyć o wiele mniej wyrafinowane i niezawodne urządzenia niż obecnie. Chociaż samochody są produkowane od ponad 100 lat, oprogramowanie prawdopodobnie jest o połowę krótsze. Samochody są dostępne ze znacznym dostosowaniem, niektóre są wliczone w cenę (np. Wybór koloru), inne, takie jak rozmiar silnika, rodzaj skrzyni biegów, koło / opona, poziom wykończenia są kosztownymi kierowcami.

Istnieje wiele sterowników funkcji, jakości i kosztów dla samochodów i oprogramowania. Następnie możesz przedyskutować, w jaki sposób technologia oprogramowania, dostępność wiedzy specjalistycznej, a może nawet to, gdzie jest zbudowana, będzie miało duże znaczenie. Odpowiednie cykle rozwojowe (na przykład modele roczne z małymi zmianami, zmiany nadwozia / silnika / platformy co około trzy lata) są napędzane przez połączenie potrzeb klienta i złożonego procesu projektowania. Niektóre produkty zaczynają się od małych i obleśnych (pomyśl o Hondzie Accord), ale co roku są ulepszane, dopóki nie zostaną ocenione najwyżej.

Samochody mają wycofania (często znacznie droższe niż aktualizacje oprogramowania) i stopniowe ulepszenia w postaci bieżących zmian na swoich listach części (pomyśl poprawki błędów) i często potrzebują długoterminowego wsparcia (pomyśl zgodność z poprzednimi / następnymi wersjami). Znaczna część kosztów twojego samochodu powstaje po odwiezieniu go do domu. Znaczna część kosztów oprogramowania pojawia się po początkowej wersji produktu podczas aktualizacji i aktualizacji klientów.

W niektórych przypadkach możesz odwoływać się do dobrze znanych produktów, które obejmują oprogramowanie lub inne produkty. Na przykład telefony mają cykl wydawniczy oraz aktualizacje i metody dodawania funkcji po początkowej sprzedaży w celu zwiększenia przychodów. Telefony są doskonałą ilustracją kompatybilności do przodu / do tyłu. Za dużo, a ludzie nie zrzucą starego, żeby kupić nowy. Zbyt mało, a klienci desperacko mają telefon, którego nie nienawidzą, zanim nie wygaśnie jego umowa.

Produkty takie jak Windows, Microsoft Office, przeglądarki internetowe i strony internetowe to oprogramowanie, którego można używać w dyskusjach. Zostały one zaktualizowane w cyklach rocznych lub trzyletnich, ale mogą być częściej aktualizowane automatycznie. Mają błędy i dziury w bezpieczeństwie, które wpływają na klientów w różnym stopniu, ale są częścią krajobrazu, pomimo naszych najlepszych starań. Klienci mogą otrzymywać poprawki bezpłatnie, ale zazwyczaj płacą za ulepszenia, często jako pakiet, czasem jako pojedynczy moduł lub za pomocą klucza licencyjnego.

Liderzy branży, tacy jak Microsoft, Apple, Google i Amazon, dostarczają użytkownikom stosunkowo niedrogich klientów. Ale mają ogromne wydatki, które umożliwiły te produkty. Ich doświadczenie pokazuje, że oprogramowanie jest drogie, ale cenne i opłacalne. Często idą na kompromis między jakością, posiadaniem wszystkich potrzebnych funkcji i wejściem na rynki we właściwym czasie. Nie każdy produkt, który wytwarzają, jest sukcesem, a czasem zmieniają psy w zwycięzców poprzez zmianę nazwy, poprawę marketingu i sprzedaży lub ograniczenie strat i wykorzystanie tego, czego nauczyli się w późniejszych produktach.

Być może spróbuj je przejrzeć, najlepiej jeden na jednego lub w małych grupach, użyj przypadków oprogramowania, które musisz opracować. Opisując przypadki użycia, określ punkty w przypadku, gdy mogą się zdarzyć różne rzeczy (nieoczekiwane, ale nie bezzasadne przypadki). Zacznij je wyliczać, poproś o wyjaśnienia i zilustruj wszystkie decyzje i kierunki, które należy podjąć lub ustalić, oraz podejmowane w związku z tym kompromisy. Idź dalej, dopóki nie zostaną zakłopotani i nie będą w stanie udzielić ci odpowiedzi. Niech zrozumieją, że to, co robisz teraz z nimi, jest dokładnie tym, co robisz przez cały dzień, prawdopodobnie samodzielnie, prawdopodobnie w znacznie mniej wyraźnym kierunku, zarówno decydując o kursie, jak i pisząc kod, dla setek lub tysięcy przypadki użycia, które mogą, ale nie muszą być określone przez nikogo. A kiedy tam W przypadku, gdy nie pomyślałeś o sobie, nie możesz zagwarantować, co zrobi program. Może robi to „właściwą” rzecz, może zauważ. I taki jest błąd. I dlatego pisanie oprogramowania wymaga czasu. Im mniej czasu masz, tym mniej przypadków, które miałeś okazję rozważyć i uwzględnić, a tym bardziej prawdopodobne, że program nie zrobi „właściwej” rzeczy w nieznanych okolicznościach.

Koszt i czas.

Czas

Ustaw oczekiwania, że ​​dostarczysz X w czasie Y. Nie będzie miał nic więcej, nic mniej. Następnie powiedz im, co będzie miała następna wersja. Na początku mogą się dziwić, że budowanie X zajmuje Y czasu - tutaj wyjaśnisz czas i złożoność budowy oprogramowania. Jeśli nie są zdziwieni, albo szacujesz, że masz mniej czasu, albo wiedzieli lepiej niż myślisz o tworzeniu oprogramowania.

Koszt

Pochodzi z książki Code Compete Steve'a McConnela (cytowanie z pamięci, więc wybacz mi, gdybym nie mógł przekazać tego z takim samym efektem) - Klienci mogą łatwo poprosić o nowe funkcje. Jako menedżer produktu nie powinieneś odpowiadać na pytania klientów. Należy oszacować, ile wysiłku i kosztów wymaga zbudowanie tej nowej funkcji. Powoli zrozumieją, że nowa funkcja nie jest tak naprawdę warta pieniędzy / czasu, a może nawet jej nie wymagają. Nie sugeruję, że używasz tej broni, aby ich przestraszyć, ale używaj jej uczciwie, a to może pomóc w doprowadzeniu tego do domu.

Metafory są nieszczelnymi abstrakcjami, ale są małym krokiem, który przybliża cię do zrozumienia.

Moim ulubionym jest to, że oprogramowanie do budowania jest często procesem podobnym do projektowania domu. Jednak bardziej precyzyjnie jest myśleć o nim jako o systemie, który drukuje niestandardowy projekt oparty na niektórych parametrach i buduje inny dla każdego z użytkowników. W geekowych rozmowach, które są meta-architektingiem.

Odkryłem, że to może pomóc, kiedy pokażesz im, co to znaczy pisać kod. Pokaż interesariuszom bazę kodów, z którą pracujesz. Nawet jeśli wybierzesz dobre nazwy zmiennych i metod, większość ludzi pomyśli, że używasz jakiejś czarnej magii. Może zrozumieją, dlaczego potrzebujesz więcej niż „kilku dni”, aby wdrożyć nową funkcję dla ich oprogramowania.