Projektowanie wad i radzenie sobie z poniżeniem [zamknięty]

Czy zawsze miałeś zasadniczo rację w projektach oprogramowania, które proponowałeś? Kiedy rozdajesz projekt, który był zasadniczo zły, tracisz szacunek innych członków zespołu. Bez względu na to, co zrobisz później, zostaniesz sprawdzony pod kątem wszystkiego, co zaproponujesz po tym incydencie. Jest to szczególnie gorsze, gdy jesteś nowym członkiem zespołu, który nie zna twojej przeszłości, w której miałeś dobre historie sukcesu.

Być może powodem, dla którego podałeś zły projekt, był brak doświadczenia lub wiedzy albo jedno i drugie w tej dziedzinie. Jak sobie z tym poradziliście? Czy to jakaś jednorazowa rzecz w twojej karierze, czy zdarza się to z przerwami? Czy można to opóźnić, czy też w takiej sytuacji trzeba szukać nowej linii pracy? Proszę o szczere opinie ...

Dziękuję Ci.

Kiedyś vp fortuny 500 kosztowało firmę 1 milion dolarów przy złej decyzji biznesowej. Kiedy złożył rezygnację z funkcji prezesa, otrzymał odpowiedź: „Właśnie zainwestowałem milion dolarów w twoją edukację, a teraz próbujesz odejść? Nie zgadzam się”.

Mam już dość kierowników i innych pracowników, którzy szybko obwiniają kogoś za to, że jest debiutantem lub zakłada, że ​​jest niekompetentny. Jest tylko jeden sposób, aby stać się dobrym projektantem, a mianowicie kilka razy więcej. Nie dbam o to, czy moi pracownicy popełniają błąd, dbam o to, czy popełnią to samo wiele razy. Pytanie brzmi: jak pokorny i jak można się uczyć? Kiedy ktoś przedstawi ci twój błąd, czy najpierw bronisz się, czy go wysłuchasz? Jeśli jesteś jednym z nielicznych facetów, którzy potrafią przełknąć swoją dumę i uczyć się na niej, to warto ją zatrzymać. Każdy, komu stracisz szacunek z powodu popełnienia błędu raz, nie jest kimś, kto zasługuje na twój szacunek.

Osobiście musiałem przepisać dwa pierwsze projekty, które zaprojektowałem co najmniej dwa razy, ale wiesz co? Nauczyłem się tony i chociaż moi pracodawcy byli w tym czasie zaniepokojeni, szybko to zrównoważyła wydajność, którą z czasem zyskałem, chętny do uczenia się na własnych błędach.

Jeśli chodzi o aspekt upokorzenia i jak dojść do siebie, mam dwie rady. Po pierwsze, ludzie zapominają z czasem. Ponadto, gdy ktoś inny ma na nich światło reflektorów, również się zepsują. Wtedy wszystko znów będzie równe. Po drugie, nie bądź dupkiem dla innych, którzy popełniają błędy, uczą się, uczą. W rzeczywistości powinieneś ich zachęcać, chyba że naprawdę potrzebują mocnego kopnięcia w tyłek. Z czasem możesz pomóc zmienić kulturę swojego zespołu, pamiętając, jak się czułeś, gdy popełniłeś szczery błąd. W końcu zainspirujesz ludzi do bycia lepszymi programistami, projektantami i ludźmi.

Robię to od dłuższego czasu (ponad 15 lat) i za pierwszym razem nadal nie mam racji. Najlepsze projekty powstają w wyniku iteracyjnego procesu współpracy. Kiedy pracujesz od jakiegoś czasu nad projektem, łatwo wpaść w pułapkę myślenia, że ​​jest to jedyny sposób, aby to zrobić. Świeża perspektywa pomaga zobaczyć rzeczy, za którymi tęsknisz.

Aby to zadziałało, zespół musi sobie ufać. Nie możesz bać się pokazywać ludziom projektu, który może być wadliwy, i musisz być w stanie zaakceptować krytykę tego projektu. Z kolei reszta zespołu musi zrozumieć, że wady projektu nie są odzwierciedleniem projektanta. Jest to oczekiwana część projektu. W ten sposób członkowie zespołu uczą się i doskonalą: na własnych błędach i błędach innych.

Jeśli jesteś w dysfunkcyjnym zespole, który tak nie działa, masz dwie opcje:

1. spróbuj naprawić zespół
2. znajdź nowy zespół (wewnętrznie lub u nowego pracodawcy).

O ile mi wiadomo, zawsze byłem zasadniczo do obrony . To nie całkiem to samo, co bycie zasadniczo poprawnym . Często okoliczności zmieniają się między momentem podjęcia decyzji „x” a momentem, gdy staje się jasne, że „x” było złą decyzją z perspektywy czasu .

To trochę jak przygotowanie amerykańskich podatków dochodowych. Wiele osób uważa, że ​​powinna być odpowiedź. Nie ma Masz swoją opinię; twój księgowy podatkowy ma jej opinię; IRS ma swoją opinię.

Kiedy popełniam błędy, nie tracę niczyjego szacunku. (O ile mi wiadomo.) Myślę, że dzieje się tak, ponieważ po części zawsze przyznam się do własnych błędów. (W rzeczywistości często znajduję własne błędy). Ponadto, prawie wszystkie znaczące decyzje projektowe powodują, że podpisuje się na nich więcej niż jedna osoba. Wszelkie błędy w tych decyzjach są własnością grupy, a nie w całości jednej osoby.

Jeśli chodzi o przyznawanie się do błędów, myślę, że staje się to łatwiejsze, gdy zdobywasz kompetencje i doświadczenie. Z mojego doświadczenia wynika, że ​​im nowszy projekt i rozwój, tym mniejsze prawdopodobieństwo, że popełnisz błąd.

Zdarza się to w kółko i nie powinno wykoleić twojej kariery. Nikt na znaczącej odpowiedzialności niezmiennie podejmuje właściwe decyzje. W rzeczywistości nikt, kto ponosi znaczną odpowiedzialność, niezmiennie podejmuje uzasadnione decyzje.

Ale przez większość czasu powinieneś być w stanie podejmować uzasadnione decyzje na podstawie niepełnych informacji. Jak powiedziała moja córka: „To po prostu bycie ludźmi”.

Czasami wszyscy coś robią źle. Błędy są nieuniknione. Przyznaj się swobodnie, gdy się mylisz, ucz się na swoich błędach i okazuj pokorę, zwłaszcza jeśli początkowo nie byłeś przekonany, że tak naprawdę się myliłeś.

„Upokorzenie” nigdy nie powinno się nigdy zdarzyć. Prawdopodobnie wcale nie poprawi to wydajności osoby.

Tutaj, w mojej firmie, rozwinęliśmy kulturę szacunku dla tych ludzi, którzy wciąż są gotowi trzymać się za szyję przy podejmowaniu trudnych decyzji, ale mogą przyznać się do błędu i dostosować swoje zachowanie w razie potrzeby.

Czy zawsze miałeś zasadniczo rację w projektach oprogramowania, które proponowałeś?

Tak, jestem nadludzki! Oczywiście, że nie.

Kiedy rozdajesz projekt, który był zasadniczo zły, tracisz szacunek innych członków zespołu.

Nie! Jeśli tak się stanie, coś jest nie tak z duchem zespołu.

Każdy popełnia błędy. Niektóre rozwiązania okazują się dobre, niektóre złe, większość pomiędzy. Zarówno sukcesy, jak i porażki powinny być traktowane jako lekcja przez ciebie i resztę zespołu.

Pierwsze błędy mogą wydawać się złe, ale po wykonaniu ich setek, jest to po prostu część pracy.

Zdarza się każdemu. Najważniejsze jest, aby uczyć się na własnych błędach i starać się, aby to się nie powtórzyło. Przyznaj się również, że to był błąd z twojej strony. Na przykład kiedyś popełniłem błąd przy użyciu gorszej warstwy dostępu do danych (SubSonic3). W momencie, gdy podejmowałem decyzję, chciałem po prostu uciec od ręcznie wykonanych zapytań SQL. Wybrałem więc coś, co wtedy wydawało się jednym z najłatwiejszych do rozpoczęcia. Nie miałem też zbyt dużego doświadczenia z DAL. Cóż, po rozwiązaniu kilku problemów zastanawiałem się, dlaczego niektóre zapytania trwały trochę za długo i stwierdziłem, że SubSonic ściąga całe tabele bez powodu.

Więc powiedziałem mojemu szefowi, wyjaśniłem, że popełniłem błąd, i dałem mu mój plan naprawy. Mój szef oczywiście nie był entuzjastycznie nastawiony do tego, że popełniłem dość duży błąd, wymagający kilku dni czystej migracji. Ale upewnił się również, że nie popełnię tego samego błędu. Zmusił mnie do stworzenia projektu sprawdzającego koncepcję dla następnej warstwy dostępu do danych, do której zaproponowałem migrację, i upewniliśmy się, że będzie działał zgodnie z naszymi wymaganiami i że nie zniszczyła całych tabel. Podsumowując, było to dla mnie dobre doświadczenie edukacyjne i teraz upewnię się, że kluczowa część projektu spełnia wymagania i nie ma wielkich problemów.

Więc w zasadzie to, co robisz, to:

1. Przyznaj się, że popełniłeś błąd
2. Zrób plan, aby to naprawić
3. Upewnij się, że Twój plan faktycznie zadziała
4. Upewnij się jeszcze raz.
5. Napraw to!

Jeśli nie jesteś pewien, jak to naprawić, nie bój się, aby zaangażować w to innych członków zespołu.

Ostatnia rzecz, zrelaksuj się! Wszyscy popełniają błędy. Bardzo niewiele osób po raz pierwszy robi to idealnie

To jest naukowy konkurs na sikanie i nie jest to dobra sytuacja. Nikt nie ma zawsze racji i nie ma się czego wstydzić, jeśli ktoś wymyśli lepszy sposób na zrobienie tego lub jeśli znajdzie problem z tak jak to zrobiłeś.

Musisz emocjonalnie oderwać się od swojego rozwiązania i spędzić czas na szukaniu najlepszego rozwiązania, wtedy możesz być zadowolony, gdy problem zostanie rozwiązany, nawet jeśli zostanie rozwiązany przez kogoś innego.

W swoim pytaniu wiele nie mówisz. Nie mogę powiedzieć, jakie jest twoje ustawienie do „wydawania projektu”. Czy jest to wstępna dyskusja z rówieśnikiem na temat twojego planowanego podejścia, czy też dostarczenie czegoś, co, jak masz nadzieję, jest ostatecznym kodem?

Jeśli to pierwsze, to nie ma powodu, aby czuć się źle i nie ma powodu, aby twoi rówieśnicy cię podejrzewali w przyszłości.

Jeśli czekasz na ostateczną dostawę, aby omówić swój projekt z kimś innym, nie winię ich za to, że są podejrzliwi w stosunku do twojej drugiej pracy.

Każdy musi omówić swój projekt z kimś innym. W zależności od złożoności lub krytyczności może być konieczne kilkakrotne omówienie tego problemu z wieloma osobami. Każdy może popełnić błąd, niezrozumieć wymaganie lub pominąć specjalny przypadek.

Błędy zidentyfikowane wcześnie są łatwiejsze i tańsze do naprawienia. Powinny być wybaczalne, chyba że ciągle powtarzasz te same błędy. Recenzje wzajemne ułatwiają wczesne wykrywanie błędów.

Jeśli próbujesz być samotnym programistą w środowisku zespołowym, popełniasz (prawie niewybaczalny) grzech, myśląc, że jesteś wystarczająco doskonały, aby nie potrzebować pomocy nikogo innego. Fakt, że jest to środowisko zespołowe, dowodzi, że problem jest na tyle duży, że nikt nie zrozumie wszystkiego. Ludzie muszą ze sobą rozmawiać, w przeciwnym razie błędy odwrócą swoje brzydkie głowy o wiele za blisko do uwolnienia (lub po uwolnieniu).

Zawsze dokonywałem rozróżnienia między, z jednej strony, dobrymi a złymi decyzjami; i na innych poprawnych i niepoprawnych decyzjach. Dobra decyzja to taka, która w tych samych okolicznościach, przy tych samych informacjach, podejmowałabyś w ten sam sposób; zła decyzja to taka, którą podjąłbyś inaczej. Prawidłowa decyzja to taka, która z perspektywy czasu i dodatkowych informacji okazuje się słuszna; i odwrotnie z nieprawidłowymi decyzjami.

Często mówi się, że osoba, która nie podejmuje niewłaściwych decyzji, nigdy niczego nie podejmuje. Nieprawidłowe decyzje są sposobem, w jaki się uczy. Złe decyzje są często zaostrzone, ponieważ decydent inwestuje się w decyzję i próbuje retrospektywnie uzasadnić decyzję lub udowodnić, że mimo wszystko była to dobra decyzja (ukrywanie jest zawsze bardziej szkodliwe niż pierwotna decyzja).

Większość podjętych przeze mnie decyzji projektowych okazała się słuszna, ale większość się nauczyłem i posunąłem się naprzód z decyzjami, które były niepoprawne. Mam nadzieję, że bardzo niewiele moich decyzji było złymi decyzjami, ale część problemu z własnymi złymi decyzjami polega na rozpoznaniu, że decyzja była zła, i zaakceptowaniu wynikających z nich często niesmacznych lekcji.

Dopóki nie są „rozgrywającym w poniedziałek rano ”. Nie mam pożytku z tego, że ktoś, kto bierze udział w rozmowach projektowych, nie mówi nic, tylko twierdząc, że wie, że to nie zadziała po tym fakcie. Musisz być w stanie przyjąć krytykę, nawet jeśli nie jest umieszczona w konstruktywnym kontekście.

Prawdopodobnie jedną z najlepszych cech witryny SO jest możliwość podjęcia ryzyka i zaproponowania niepewnego rozwiązania. Tak się uczysz. Przechodzenie przez życie z kupą gówna w głowie, które jest złe, ale nigdy nie powiedziano ci o zdradzie, jest prawdziwą ignorancją.

Mogą wiedzieć coś, czego ty nie wiesz, ale nie będą wiedzieć wszystkiego. Pokonaj go, zabierz się do roboty i zrób coś. Niech marnują czas, myśląc, że są tak cholernie mądrzy.

Czy zawsze zapewniałem dobry projekt? Nie! Staram się to robić, staram się być lepszy, ale z każdym kolejnym projektem wydaje mi się, że zawsze mogę spojrzeć wstecz na to, co zrobiłem wcześniej, i wzdrygać się, że w jakiś sposób przegapiłem znak.

Jeśli chodzi o kogoś, kto zaproponował projekt mniej gwiezdny, nie przeciwstawiłbym się tej osobie, gdyby ta osoba wykazała, że ​​chętnie uczy się na błędach i jest otwarta na krytykę. Jeśli widzę dowody na to, że osoba podobnie dąży do poprawy i ma taką możliwość, to zła propozycja projektu jest tylko okazją do nauki.

Zdarza się to każdemu od czasu do czasu, więc najlepiej jest dowiedzieć się, dlaczego projekt był zły i wyciągnąć z tego wnioski. Jeśli jest to brak wiedzy, wówczas niepowodzenie projektu da nadzieję, że da ci trochę nowej wiedzy, którą możesz wykorzystać następnym razem. Nie zniechęcaj się, wszyscy przechodzą przez to w pewnym momencie. To najlepszy sposób na zdobycie doświadczenia i złapanie nowego zespołu / środowiska.

To się często zdarza. Nasza branża zmienia się tak szybko, że szanse, aby nigdy się nie pomylić, są w rzeczywistości zerowe.

Czy jednak zepchnąłeś zły projekt na ich gardła nad ich obiekcje? Może dlatego przesadzają.

Jeśli błąd był poważny, oczywiście odzyskanie szacunku zajmie trochę czasu. Gdyby któryś z twoich współpracowników poprowadził cię w złym kierunku i stworzył problemy dla całego zespołu, czy nie potrzebowałbyś go, aby udowodnił, że w najbliższym czasie okaże się więcej?

Wszystko, co możesz zrobić, to przyznać się do błędu, przyznać, kto miał rację, i starać się lepiej słuchać i lepiej badać opcje w przyszłości.

Co według ciebie nie popełniło błędu w projekcie? (Nieprzypadkowy przykład - zaprojektuj proces importu, aby korzystać z istniejącej usługi internetowej, która działa wiersz po rzędzie (ponowne użycie kodu i tylko zmiana reguł biznesowych w jednym miejscu), nie zdając sobie sprawy, że niektóre importy będą miały miliony rekordów i zajmie to dni koniec.) Ucz się z niego i rozważ te rzeczy w przyszłości.

Tam będzie zawsze być błędy. Błędem jest bycie programistą. Ucz się od innych w Internecie, a zwłaszcza od współpracowników. Jedynym wstydem byłoby poddanie się lub zakopanie głowy w piasku, jeśli chodzi o takie problemy od teraz.

Połóż to za sobą, opuść głowę i daj z siebie wszystko. Jeśli jesteś dobrym programistą, przejrzysz swoje błędy.

Jeśli nie masz pewności, że Twój pomysł ma solidne podstawy, powinieneś omówić go z kilkoma zaufanymi współpracownikami, zanim zaproponujesz go całej firmie lub działowi. W rzeczywistości, nawet jeśli jesteś tego pewien, powinieneś omówić to z ludźmi, z którymi współpracujesz i którzy najprawdopodobniej cię znają najlepiej. Pomogą ci wcześnie wykryć problemy.

Zdarza się nam czasami. Użyj pierwszego projektu jako prototypu. Dowiedz się dokładnie, co zadziałało, a co nie i dlaczego. Następnie możesz napisać o wiele lepszy produkt końcowy.

Nie próbuj się usprawiedliwiać ani bronić. Przyznaj się do błędu i idź dalej.

Problem podstawowy nie wydaje się wyjaśniony: jest to problem społeczny . Możesz zobaczyć takie zachowanie w prawie każdym zawodzie: jeśli popełnisz błąd, a oni lubią „kategoryzować” cię w pewnych rzeczach, to na zawsze. To zachowanie społeczne. Nawet sprytni i mądrzy ludzie będą podążać za wszystkimi.

Dam wam przykład, który nie ma nic wspólnego z programowaniem: w mojej poprzedniej pracy zapomniałem umyć naczynia raz lub dwa. Od tego czasu wszyscy pracownicy myśleli, że jestem typem człowieka, który nigdy nie myje moich naczyń. A teraz, gdy tylko zlew znajdzie się w zlewie, to ja (kto inny mógłby to być).

Wszędzie jest tak samo: jest to zachowanie społeczne , bez względu na rodzaj problemu.

Mówisz mi, że chcesz uczciwej opinii? Jedynym rozwiązaniem jest rezygnacja z innej pracy. Jeśli wszyscy ludzie w zespole uważają, że nie jesteś dobry w swojej pracy, wkrótce się to nie zmieni, przepraszam, że to powiedziałeś. Poszukaj innej pracy, ponieważ nigdy nie zmienisz tego rodzaju (głupiego, muszę wyznać) zachowania społecznego .

Kluczem jest to, w jaki sposób określasz swoją sprawę i jakie zmiany wprowadzasz. Jeśli twierdzisz, że jesteś guru programowania, który nie robi nic złego i jest bardziej niesamowity niż Jon Skeet, jest całkiem prawdopodobne, że w pewnym momencie zostaniesz za to odrzucony. Kluczem jest to, w jaki sposób prezentujesz swoje rozwiązania, abyś mógł pokazać, że jest to rozsądne rozwiązanie problemu, a nie idealne rozwiązanie, którego nawet nie należy sprawdzać.

Moim najlepszym przykładem byłoby odkrycie skutków ubocznych posiadania klasy staticw aplikacji internetowej, w której kiedyś pracowałem. Nie wiedziałem, jak źle byłoby, gdyby ta jedna instancja trwała i była udostępniana wszystkim użytkownikom aplikacji, ale wyciągnąłem z niej wnioski i odzyskałem czas. Czasami może się zdarzyć, że coś zostanie znalezione i trzeba będzie dokonać poważnych korekt. Byłem także w tym obozie, w którym musiałem przeskanować kilka skryptów VBScript, aby zredukować konkatenacje ciągów, które powodowały problemy z pamięcią, w których kiedyś pracowałem. Pamiętam nawet pisanie kodu podatnego na zastrzyki SQL w 1998 r., Kiedy pisałem znaleziony fragment kodu klienta, który musiał dynamicznie generować SQL, ponieważ miałem około 20 opcjonalnych pól w tej części aplikacji.

Perfekcjonizm może być tutaj trochę obosiecznym mieczem, dlatego też widzę ten trzeci komentarz, a także sposób, w jaki czasami jestem. Złe jest widzenie, że są wszystkie te błędy i nic nigdy nie jest w porządku. Dobrą rzeczą jest to, że zdobywając to, co najlepsze, możesz spełnić, jeśli nie przekroczyć oczekiwań innych. Ciągłe doskonalenie może być sposobem na postrzeganie perfekcjonizmu na PC i jeśli jest utrzymywane z umiarem, uważam to za dobrą rzecz. Czy pomimo popełnionych błędów Twój kod wchodzi do produkcji? Czy wykona to zadanie? Są to kwestie do przemyślenia, a także to, czy ktoś zawsze coś naprawia, czy też dobrze, że chcesz być tak dobry, że wolisz nie robić nic innego, dopóki nie będzie to idealne? Praktyka może być przydatna, aby znaleźć wzorce do lepszego wykonywania pracy. Jednak,