Jak wyjaśnić, dlaczego wybór projektu jest dobry? [Zamknięte]

Ponieważ stałem się lepszym programistą, stwierdziłem, że większość moich umiejętności projektowych pochodzi bardziej z intuicji niż analizy mechanicznej. To jest świetne. Pozwala mi czytać kod i szybciej go wyczuć. To pozwala mi łatwiej tłumaczyć projekty między językami i abstrakcje. Pozwala mi to robić rzeczy szybciej.

Minusem jest to, że trudniej mi wytłumaczyć członkom drużyny (a co gorsza, kierownictwu), dlaczego dany projekt jest korzystny; szczególnie członkowie drużyny, którzy nie nadążają za najlepszymi praktykami. „Ten projekt jest bardziej testowalny!” lub „Powinieneś preferować kompozycję nad dziedziczeniem”. przejść nad ich głowami i poprowadzić mnie do króliczej nory, próbując nakłonić wszystkich do ostatniej dekady rozwoju inżynierii oprogramowania.

Oczywiście poprawię się dzięki praktyce, ale w międzyczasie wymaga to dużo straconego czasu i / lub złego projektu (co doprowadzi do zmarnowania czasu na jego późniejsze naprawienie). Jak mogę lepiej wyjaśnić, dlaczego dany projekt jest lepszy, skoro korzyści nie są całkowicie oczywiste dla odbiorców?

To może nie odpowiedzieć bezpośrednio na twoje pytanie, ale może poprowadzić cię w interesującym kierunku.

Myślę, że to, co musisz zrobić, jest bardziej związane ze sprzedażą ich według pomysłu niż z ich wyjaśnieniem . Sprzedaż polega na zrozumieniu, na czym polega problem klienta, a następnie pokazaniu, w jaki sposób Twój produkt (lub metoda rozwoju, cokolwiek) przyniesie im korzyści . Każda osoba ma inne potrzeby, więc rzeczy, które przynoszą korzyść jednej osobie i ją ekscytują, mogą sprawić, że inna osoba będzie zimna.

Dla twojego CEO czas na wprowadzenie na rynek może być kluczem, dla twojego menedżera może być bardziej przewidywalnym harmonogramem, dla twoich kolegów programistów może być szybszym kodowaniem (lub łatwiejszym testowaniem / dokumentacją / debugowaniem / czymkolwiek), a dla klientów twojej firmy to może być ... ?

Sprzedaż nie odbywa się automatycznie - musisz podjąć wspólny wysiłek, aby zrozumieć punkt widzenia drugiej osoby , a następnie wymyślić, jak zmapować swoje pomysły na ich Happy Place ™. Gdy wiedzą, w jaki sposób osobiście skorzystają z tej nowej rzeczy, często pytają: „Ile to będzie kosztowało i jak szybko możemy to zrobić?”. Kiedy usłyszysz te magiczne słowa, wiesz, że dobrze wykonałeś swoją sprzedaż.

Naprawdę nie mam rozwiązania twojego pytania, ale jakiś czas temu stanąłem przed tym samym dylematem i szukałem odpowiedzi na to samo pytanie.

Znalazłbym się po jednej stronie argumentu, a ktoś inny po drugiej stronie i mimo że każde włókno mojego ciała mówiło mi, że właściwy projekt to X, nie mogłem tego poprzeć słowami.

Jeszcze gorsze jest to, że czasami przyznaję punkt i pozwalam drugiej osobie wdrożyć go tak, aby jego projekt wysadził mi w twarz, a potem pomyślałem: „Tak, to doskonały przykład tego, dlaczego nie chciałem aby zrobić to w ten sposób. Gdybym tylko mógł im wtedy pokazać ten kod ”.

Cóż, tak naprawdę nigdy nie znalazłem odpowiedzi, ale kilka dni temu przeglądałem Lean Software Development: zwinny zestaw narzędzi, Natknąłem się na coś interesującego, co może sugerować, że odpowiedź nie istnieje. Część książki mówiła o liderach z innych dziedzin, szczególnie w jednostkach reagowania kryzysowego oraz o tym, jak ci liderzy podejmowali decyzje. Kiedy dochodzi do pożaru lub ktoś do ciebie strzela, ci liderzy nigdy nie siadają i nie dyskutują za / przeciw z kolegami z drużyny. Zamiast tego używają intuicji, która została opracowana poprzez szkolenie i doświadczenie, aby pomóc im w podejmowaniu decyzji. To samo dotyczy naszego zawodu: w jaki sposób możesz podjąć w pełni logiczną decyzję, mając do czynienia z mnóstwem niewiadomych i różnorodności, tak powszechnej w tworzeniu oprogramowania? Autorzy twierdzą, że zamiast próbować uzasadniać każdą decyzję, należy zachęcać programistów do trenowania i doskonalenia instynktów, aby w końcu „po prostu” wiedzieli, co robić.

Jedynym sposobem, w jaki udało mi się ominąć te argumenty, jest zbudowanie sprawdzonej historii mojej pracy. Aby pokazać kierownictwu i innym członkom mojego zespołu, że decyzje projektowe, które podejmuję w kodzie, powodują, że kod jest łatwiejszy w utrzymaniu, rozszerzaniu i bardziej niezawodny. Robisz to wielokrotnie, a ludzie cię zauważą. W tym momencie twoja opinia, która może opierać się wyłącznie na twoim instynkcie, będzie miała znacznie większą wagę niż obecnie. Ta strategia działała z 90% + mojego zespołu, w tym z moim szefem. Niestety, możesz znaleźć jednego lub dwóch facetów, którzy są całkowicie uparci i nie chcą widzieć niczego na swój sposób. W tym momencie masz kilka opcji:

1. Możesz spróbować podnieść rangę (skończyło się na tym, że poszedłem do mojego szefa i poprosiłem o rangę, ponieważ byłem zmęczony tymi ślepymi argumentami)
2. Możesz spróbować lobbować za większością zespołu, aby cię wspierać.
3. Jeśli na projekt można sobie pozwolić (tj. Niezbyt duża utrata produktywności), co Twoim zdaniem jest złą decyzją, pozwól drugiej osobie wygrać spór. Stanie się jedna z dwóch rzeczy:
   • W niektórych przypadkach (miejmy nadzieję, że bardzo mała część) intuicja będzie błędna i w końcu się czegoś nauczysz. Dobrze dla ciebie.
   • W większości przypadków (znowu ... mam nadzieję), ORAZ osoba, która opowiadała się za „złym” projektem, zrozumie dokładnie, dlaczego jest zły; mimo wszystko z perspektywy czasu jest zawsze 20/20. Mam nadzieję, że będzie to lekcja dla tej osoby, że być może wiesz, o czym mówisz, a następnym razem pomyśli dwa razy argumentując swoją sprawę.

Cóż, ta odpowiedź nie jest tak specyficzna dla programowania, jak mogłoby się wydawać. Musisz przywrócić to do rzeczy, które rozumieją.

Jeśli jest to coś w rodzaju kompozycji zamiast dziedziczenia, prawdopodobnie po prostu powinieneś powiedzieć, że obecnie może 90% programistów uznałoby to za najlepszą praktykę (zgadywanka, częściowo oparta na fakcie, że 100% programistów zgadza się prawie na niczym), a ty zgadzam się i chętnie podejmę decyzję.

Staram się być tak szczery, jak to tylko możliwe, co jest kontrowersyjne i jaki procent programistów zgodziłby się ze mną.

Zasadniczo działa to lepiej w przypadku zarządzania niż deweloperów, którzy prawdopodobnie sprawią, że zejdziesz do króliczej dziury, wyjaśniając, czy naprawdę popierasz dobry projekt i skąd go znasz. Jest w tym coś godnego pochwały, ale oznacza to, że musisz poświęcić dużo czasu. Chyba że ci zaufają na tyle, aby wierzyć na takie rzeczy, przynajmniej tymczasowo. Z drugiej strony, mogą cię przekonać, że się mylisz, co bije zimną, twardą rzeczywistość przekonującą cię na drodze.

Dla rzeczy takich jak projekt, który jest bardziej testowalny, jeśli nie zgadzają się, że jest bardziej testowalny, to jest prawie taki sam jak pierwszy przykład. Jeśli nie zgadzają się co do tego, że pożądane jest bycie bardziej testowalnym, musisz przywrócić je do rzeczy, które rozumieją. Najprawdopodobniej byłoby to zarządzanie i można mówić o niższych kosztach rozwoju w perspektywie długoterminowej, mniejszej ilości QA, bardziej przewidywalnych procesach (ponieważ trudno jest przewidzieć długość powtarzanych cykli QA) itp.

Myślę, że część problemu polega na tym, że nie doceniasz, jak trudno jest zespołowi zgodzić się z tobą w jakiejkolwiek kontrowersyjnej kwestii, nawet jeśli okazuje się, że masz rację (i oczywiście możesz nie być). Programowanie jest częściowo ćwiczeniem socjologicznym i może być konieczne zaplanowanie czasu, aby rzeczywiście zniszczyć niektóre z tych króliczych dziur, ponieważ świetny projekt, którego nikt nie rozumie ani nie opóźnia, rzadko jest świetnym projektem w praktyce. Nie traktuj więc tego czasu jako zmarnowanego, myśl o nim jako o niezbędnej części sukcesu twojego projektu. Chociaż byłoby o wiele łatwiej, gdybyś mógł to jakoś pominąć.

Bycie jedynym głosem zmian nigdy nie jest łatwe. Pierwszym wyzwaniem jest zazwyczaj zaangażowanie innych osób (mam nadzieję, że w Twojej firmie są tacy, którzy są bardziej otwarci niż reszta). Jeśli uda ci się przyciągnąć uwagę kilku innych starszych programistów / menedżerów, aby dołączyć do krucjaty, te połączone głosy będą coraz trudniejsze do zignorowania przez resztę.

Uważam, że dobrym sposobem na wyjaśnienie ludziom jest dostarczenie konkretnych przykładów błędów popełnionych w przeszłości w projektach, w które byli aktywnie zaangażowani (np. „Czy kiedykolwiek próbowałeś debugować tę rzecz? Tak było od lat i nikt nie wie jak napraw to.."). Co więcej, zastosowanie tych „nowych” pomysłów i zasad projektowych do małego / próbnego projektu i możliwość pokazania, jak zakończyło się to sukcesem.

W zależności od postaw innych osób w Twojej firmie zmiana może nastąpić szybko lub może to być próba przepłynięcia melasy. Niektórzy menedżerowie są całkowicie nieruchliwi, chyba że mają przed sobą solidne statystyki / dowody, podczas gdy inni chętnie nadążają za najnowszymi myślami.

Może być konieczne wypróbowanie różnych taktyk w zależności od tego, z kim masz do czynienia; Sugestia, że ​​można zaoszczędzić pieniądze / czas / wysiłek i poprawić jakość, jest dobrym sposobem na zwrócenie uwagi menedżerów nietechnicznych; a obietnica łatwych testów automatycznych przemawia do wielu programistów, którzy zwykle nie znoszą spędzania dni na przeglądaniu tych samych arkuszy testowych wielokrotnie.

Zależy od publiczności! Jako programiści opracowaliśmy intuicję dobrego i złego kodu i używamy niejasnych terminów emocjonalnych, takich jak „zapach kodu”, „brzydki kod”, „piękne rozwiązanie”. Działa to tylko podczas komunikacji z innymi programistami o tym samym sposobie myślenia. Spróbuj wyjaśnić swojemu nietechnicznemu dyrektorowi generalnemu, że powinieneś zainwestować x roboczogodzin w uczynienie kodu „piękniejszym”, co najprawdopodobniej zakończy się spektakularnym niepowodzeniem.

Musisz być w stanie wykazać, że poprawa każdego z tych rozwiązań również

• zaoszczędź pieniądze dla firmy
• zarabiać pieniądze dla firmy

Na przykład, co jest zgodne z zasadą jednej odpowiedzialności? Jeśli każda klasa ma jedną odpowiedzialność, znacznie ułatwia lokalizowanie i naprawianie błędów oraz ułatwia dodawanie funkcji i ulepszeń. Mniej czasu na naprawianie błędów i dodawanie funkcji = zaoszczędzone pieniądze.