Menedżer ciągle zmienia specyfikację wymagań po każdym demo [zamknięty]

21

Tło mojego środowiska pracy

Mój kierownik nie ma żadnego doświadczenia ani wiedzy na temat komputerów ani oprogramowania. Jest wysoce prawdopodobne, że nie widział kodu w żadnej formie (nawet z odległości fizycznej 10 stóp lub mniej) w swoim życiu.

Nikt nie rozumie złożoności tego, o co jestem proszony. Do tego stopnia, że ​​gdybym częściowo zaszyfrował kod, nikt by się nie dowiedział.

W teście Joela oceniamy niewiarygodny wynik 0.

Problemy

  • Kierownik, a czasem inni „starszy”, ciągle zmieniają specyfikację wymagań. Zmiany, które, jeśli zostaną wykonane dobre prace inżynieryjne, a nie niejednolite „poprawki”, wymagają zmiany w projekcie podstawowym.
  • Jest absolutnie nikt , kto patrzy na kod (prawdopodobnie dlatego, że nikt nie wie, w jaki sposób, a nawet jeśli to powinno być zrobione) co oznacza, że nikt nigdy nie będzie w stanie:
    • Doceń złożoność problemu lub elegancję rozwiązania.
    • Zaproponuj ulepszenie tego podejścia.
    • Doceń jakość kodu.
    • Wskaż, gdzie można poprawić kod.
  • Używa się dużo żargonu, co ma sens gramatyczny, ale nie ma sensu w żaden inny sposób.
  • Nie czuje się, nie działa ani nie działa jak firma programistyczna.

Pytanie

Co powinno być zrobione? Zwłaszcza, że ​​nie ma nikogo, kto wskazałby ulepszenia w moim kodzie.

Aktualizacja

Aby odpowiedzieć na pytanie HLGEM (i ewentualnie inne) o to, co zrobiłem, aby spróbować to naprawić. Zaproponowałem, aby skonfigurować Redmine i wprowadzić kontrolę źródła u wszystkich. Powiedziałem, że zalecę dystrybucję (git lub mercurial), ale porozmawiam również o scentralizowanych i pozwolę zespołowi zdecydować. Odpowiedzią było, że rzeczy są robione i zostaną wykonane w ciągu kilku tygodni. Nie widziałem tego ani nie wiem, czy korzystają z niego inne części firmy.

Łowca dżungli
źródło
36
udzielić oczywistej odpowiedzi: URUCHOM !!
keppla
3
Chyba że jest coś ważnego, o czym nie mówisz, że zacznij szukać nowej pracy.
Zachary K
11
„Kierownik, a czasem inni„ starsi ”, ciągle zmieniają specyfikację wymagań.” Cóż, posiadanie specyfikacji dałoby ci 1 na teście Joela. : P
R. Martinho Fernandes
11
Żadna organizacja nie uzyskała mniej niż 2 punktów w teście Joela wyłącznie z powodu nietechnicznych menedżerów. Istnieje wiele rzeczy, które Ty i inni członkowie zespołu technicznego możecie zrobić bez wkładu nietechnicznych menedżerów, aby zwiększyć swój wynik. Nie masz wymówki, by obwiniać to wyłącznie na kierownika.
wałek klonowy
6
Wygląda na to, że masz zespół sprzedażowy również do zarządzania oprogramowaniem, rozumiem.
wildpeaks

Odpowiedzi:

30

Krótka wersja :

Biegać.


Nieco dłuższa wersja :

Jeśli menedżer nie wie, jak uruchomić projekt, a starszy senior zgadza się z nim, to nie ma prawie żadnej szansy na naprawę.

Aby zarządzać projektami oprogramowania, menedżer musi coś zrozumieć na temat oprogramowania. Jeśli menedżerowie tego nie zrobią, najpierw muszą się uczyć. Jakie są Twoje szanse na przekonanie kierownictwa i starszych osób, że popełniły błąd? Jakie są szanse, że czegoś ich nauczysz?

Byłem kiedyś w podobnej sytuacji (tylko nie było seniora). Rezygnowałem po okropnym roku i nigdy nie oglądałem się za siebie (z niesmakiem).

sbi
źródło
3
+1 za ten cytat: „Jeśli menedżer nie wie, jak uruchomić program, a jeśli senior zgodzi się z nim, to nie ma szans na naprawę”.
wałek klonowy
17

... ciągle zmieniaj specyfikację wymagań. Zmiany, które, jeśli zostaną wykonane dobre prace inżynieryjne, a nie niejednolite „poprawki”, wymagają zmiany w projekcie podstawowym.

Brzmi jak prawdziwy świat. Dzieje się tak przez cały czas, wszędzie. Tak, to do bani, ale jest to znośne z pewnym zwinnym podejściem. Poza tym jedną miarą dobroci oprogramowania jest jego plastyczność. Weź to za wyzwanie.

Używa się dużo żargonu, co ma sens gramatyczny, ale nie ma sensu w żaden inny sposób.

Znów nie brzmi tak obco ;-)

Nikt nie rozumie złożoności tego, o co jestem proszony.

Nawet ty? Jeśli to rozumiesz, to w lustrze jest jedna osoba, która to rozumie. Twoja odpowiedzialność za dobrobyt Twojej firmy jest prawdopodobnie większa niż sugeruje to formalny tytuł. Jeśli rozumiesz problemy, a twój menedżer nie, to Twoim obowiązkiem jest wyjaśnienie kierownictwu, aby mogli właściwie kierować firmą. Można założyć, że twoi najbliżsi menedżerowie powinni być technicznie kompetentni (niekoniecznie tak kompetentni jak ty - podczas gdy oni są menedżerami, ty jesteś ekspertem - ale przynajmniej odrobinę kompetentny), ale jeśli oczywiście nie są i możesz im pomóc, dlaczego nie?

Prostym rozwiązaniem escapist jest zmiana firmy. Ale jako kolejną opcję rozważ wdrożenie elementów testu Joela. Chociaż pozycje od 5 wymagają większej współpracy z zarządem, pozycje 1–4 są takie, że można je po prostu skonfigurować bez pytania nikogo.

To powiedziawszy, nikt tutaj w SE nie zna twojej dokładnej sytuacji. Możliwe, że jesteś w firmie przepełnionej niekompetentnymi kretynami, a zrobienie czegoś dobrego z takiego bałaganu może być dla każdego zbyt wielkim wyzwaniem. Musisz sam ocenić sytuację.

Joonas Pulakka
źródło
Co powiesz o tym, że ktoś popełnił moje błędy? Pomagając mi się doskonalić i uczyć.
Jungle Hunter
4
@Jungle Hunter: Oczywiście łatwiej byłoby być w firmie, w której wszystko jest gotowe, wszyscy już przestrzegają wszelkich możliwych najlepszych praktyk itp., Abyś mógł być tylko uczniem i naśladować innych. Ale możesz również poprawić i wiele się nauczyć, biorąc odpowiedzialność i będąc aktywnym w ulepszaniu swojej firmy. Ulepszanie i nauka są ostatecznie w twoich rękach. Inne osoby mogą pomóc, ale twój szef nie musi być jednym z nich.
Joonas Pulakka
Tak, masz rację. Staram się poprawić, ale moim wysiłkom wydaje się, że bardziej narzekają niż próbują ulepszyć. Szczerze mówiąc, moje wysiłki są obie, ale zobaczmy, czy uda mi się sprawić, by zobaczyli drugą połowę - spróbuj poprawić.
Jungle Hunter
@Jungle Hunter: Rozumiem, że granica między narzekaniem a ulepszaniem może być niewyraźna . Ale nigdy nie boli pochylać się w stronę konstruktywnej strony.
Joonas Pulakka
4
@Joonas: Byłem w firmach, w których przedstawiałem VCS, recenzje kodu, prowadziłem seminaria C ++ i tak dalej, aby poprawić jakość kodu. I byłem w firmie, tak jak opisuje OP. Jeśli jest to beznadziejny przypadek, musisz przyznać się do porażki i poszukać pracy, w której walka jest nagradzana, pozwalając ci odnieść sukces.
sbi
16

W jednym z komentarzy mówisz, że to twoja pierwsza praca. Menedżerowie często nie są nigdzie indziej techniczni, z wyjątkiem mojego dedykowanego sklepu z oprogramowaniem. To część życia, przyzwyczaj się do tego.

Płaczesz i jęczysz, ponieważ nie ma nikogo, kto docenia elegancję swoich rozwiązań. Prawdziwy problem nie polega na tym, że nie ma nikogo, kto docenia elegancję swoich rozwiązań, ale że nie ma nikogo, kto mógłby cię nauczyć, że twoje rozwiązania nie są tak dobre, jak myślisz, że są. Praktycznie wszyscy nowi programiści przeceniają swoje rzeczywiste umiejętności. Bez mentora nie ma nikogo, kto pomógłby ci w lepszych praktykach. Jeśli nie ma nikogo, kto mógłby cię mentorować, dołącz do lokalnych grup użytkowników, aktywnie uczestnicz i poproś kogoś, kto cię mentoruje. Co więcej, pomoże ci to ostatecznie znaleźć lepszą pracę.

Zdajesz zero w teście Joela? Jeśli jesteś jedynym programistą (i brzmi to tak, jak napisałeś, że jesteś), dlaczego nie używasz kontroli źródła? Co ci przeszkadza? Jeśli nie jesteś jedynym programistą, dlaczego nie ma nikogo, kto mógłby zrobić recenzje kodu? Wszyscy nasi deweloperzy robią przegląd kodu, nie jest to funkcja zarządzania, szczególnie gdy menedżerowie są nietechniczni.

Wymagania zmieniają się prawie we wszystkich miejscach. Potrzeby biznesowe nieustannie się zmieniają, a osoby niebędące programistami często nie są w stanie wyobrazić sobie, co zrobi program, dopóki czegoś nie zrobią. Wtedy zdają sobie sprawę, że to nie jest to, czego potrzebują. Dlatego naprawdę powstał Agile, ponieważ starsze metody nie radziły sobie dobrze z tą zmianą.

Skonfiguruj śledzenie błędów, nawet jeśli kierownictwo nie chce same wprowadzać danych. Odpowiadaj za wprowadzanie nowych błędów / funkcji, gdy ktoś o nich wspomina. Naprawdę pomaga to powiedzieć kierownikowi, kiedy chce zmiany, że przydzielono ci 27 innych rzeczy, a oto lista, którą chcesz, abym przesunął w dół listy priorytetów, aby uwzględnić tę nową zmianę. Pomoże to w czasie przeglądu, ponieważ będziesz mógł policzyć liczbę poprawek i wprowadzonych funkcji. Jeśli wszyscy go nie używają, przynajmniej możesz to zrobić dla własnej pracy. Jeśli nie pozwolą Ci zainstalować żadnego oprogramowania, skorzystaj z arkusza kalkulacyjnego Excel. Podejmij inicjatywę. Gdy będziesz mógł pokazać wyniki, inni będą bardziej zainteresowani. Jeśli uważasz, że dla jednej osoby jest zbyt dużo pracy, narzędzie do śledzenia błędów pomoże Ci to udowodnić.

Nie stwórz dopracowanych wersji demo! Dema powinny wyglądać tak, jakby były nabazgrane długopisem na kartce papieru. Im bardziej dopracowany interfejs, tym bardziej nietechniczna osoba myśli, że jest skończony.

Nawet jeśli nikt nie będzie wiedział, jeśli nie będziesz przestrzegać najlepszych praktyk i na przykład kodu semi_hard, będziesz wiedział i wpadniesz w niechlujne, złe nawyki. To nie będzie ci dobrze służyć w następnej pracy. Więc rób rzeczy tak blisko, jak to możliwe, w danych okolicznościach. Pamiętaj, aby napisać testy (po prostu weź to pod uwagę jako część czasu programowania i umieść czas na zrobienie tego we wszelkich szacunkach, które podajesz w zarządzaniu, nawet jeśli nie mówisz wyraźnie, że jest to część oszacowania) i użyj tych testów, aby się upewnić późniejsze zmiany nie psują czegoś innego.

Musisz postrzegać to jako bezcenną okazję do rozwoju i poprawy. Masz więcej swobody w kodowaniu niż wiele osób na tym etapie swojej kariery. Rozważ tę okazję, aby stworzyć portfolio udanych wdrożonych projektów. Kiedy zaczniesz szukać następnej pracy, będziesz w stanie wskazać takie osiągnięcia, jak zinstytucjonalizowana kontrola źródła, ustanowione śledzenie błędów, utworzona liczba X udanych wdrożeń projektu itp., Które wyróżnią Cię spośród innych.

Masz również świetną okazję, aby dowiedzieć się, jak zarządzać oczekiwaniami w górę. To jest kicz, który przyda się do końca twojej kariery. Nie masz nic do stracenia, próbując to zrobić tutaj, rzeczy już nie są dobre. Ale możesz nauczyć się umiejętności politycznych, które pomogą ci w lepszych miejscach później. Naucz się robić analizę kosztów i korzyści. Naucz się podkreślać domenę biznesową, abyś był przekonujący podczas rozmowy z nimi. Naucz się mówić o korzyściach dla firmy i zyskach. Dokonuj szacunków dla każdego przydzielonego zadania, a nawet jeśli nie zgadzają się z tym, jakie daje zarządzanie waht, przechowuj informacje o tym, co oszacowałeś i co faktycznie wziąłeś, aby poprawić swoją zdolność do oszacowania pracy. Gdy pokażesz, że historycznie twoje szacunki były dokładniejsze niż szacunki, będą bardziej skłonni słuchać, gdy powiesz im, że szacunek jest zbyt niski. Ale musisz zbudować doświadczenie zarówno na podstawie dokładniejszych szacunków, jak i przede wszystkim zdolności do dostarczania projektów i sprawiania, by działały. Ponownie, jest to dobra umiejętność, którą możesz mieć, gdy awansujesz w swojej karierze.

Przede wszystkim nie bądź pasywny i oczekuj poprawy z góry.

HLGEM
źródło
1
Ta odpowiedź ma bardzo przydatne części. I niektóre rzeczy, które uważam za błędne w zrozumieniu mojej sytuacji. Mówię o obu przypadkach, których nikt nie docenia, kiedy jest dobry. Nikt nie wskaże, kiedy się mylę. Używam kontroli źródła, ale w zespole 2-3 nikt inny tego nie robi. Kod, gdy jest współdzielony, jest współdzielony przy użyciu pendrivów i przy użyciu Airdrop. Jeśli czytasz ten komentarz, myślę, że wspomniałem również o konfiguracji Redmine na moim laptopie, która ostatecznie jest używana tylko przeze mnie. To samo z git. Próbowałem wdrożyć je dla wszystkich. Mój poziom, świeżo po studiach. Senior powinien kodować, ale nie robi tego.
Jungle Hunter
Poradzę sobie, jak zbudować historię. Będę pamiętać, że mam więcej swobody na scenie niż ogólnie mówiąc. Mogłem nauczyć się zarządzać oczekiwaniami i innymi umiejętnościami politycznymi i miękkimi.
Jungle Hunter
3
Przestań dawać im kod na pendrivach. Jeśli chcą twojego kodu, powiedz mu, że jest pod kontrolą źródła i pokaż, jak go używać.
Hugo,
1
@JungleHunter Gdy poprosą o Twój kod, powiedz im, że jesteś w połowie zmiany, która nie będzie działać, ale mogą uzyskać ostatnią stabilną wersję z kontroli źródła.
Kirk Broadhurst
1
@HLGEM „Płaczesz i skomlesz”? O wiele zbyt surowe, samo głosowanie w dół.
Ben H
6

Gdybym był tobą, spróbowałbym znaleźć inną pracę. Czemu? Myślę, że wiesz, że niestety, twój menedżer jest, no cóż, „niedobry”. Powinieneś jednak spróbować wypracować pewne rzeczy ze swoim menedżerem.

Jeśli nie chcesz odejść i / lub nie będziesz z nikim rozmawiać, będziesz musiał sam coś znaleźć. Jeśli nikt w firmie nie wie o twoim kodzie, skąd twój menedżer powinien wiedzieć, że spełniasz wymagania? Tylko mówię.

Dynamiczny
źródło
Patrzy tylko na demo. Mówimy, zmieńmy to w ten i inny sposób. A potem jest powódź żargonów.
Jungle Hunter
2
@ Dżungla, nie włożyłbym wtedy prawie żadnej pracy w wersje demo, ponieważ będą musiały się bardzo zmienić, kiedy je zobaczy. Przede wszystkim brzmi jak osoba wizualna. Próbowałeś dla niego tworzyć zrzuty ekranu z różnych przypadków użycia? To może być o wiele łatwiejsze do złożenia niż funkcjonalne prototypy.
wałek klonowy
@maple_shaft: Myślę, że to świetny pomysł.
Jungle Hunter
1
@maple_shaft: A może zamiast dostarczać dużo z wyprzedzeniem, dostawa zbliża się do końca. ;)
Łowca dżungli
1
Porady pracy od gimnazjalisty ...
4

Porozmawiaj na ten temat ze swoim menedżerem i seniorami. Wyjaśnij swoje problemy i zaproponuj rozwiązania. Przygotuj nieco rozmowę, aby poznać ogólną wiadomość, którą chcesz przekazać.

Po rozmowie daj trochę czasu . Sprawdź, czy coś się zmieni, czy nie. Jeśli nie, spróbuj samodzielnie wprowadzić zmiany i pokazać menedżerowi i seniorom pozytywne wyniki swoich zmian .

Jeśli rozmowa nie pomoże, a zmiany zostaną odrzucone, musisz sam ocenić, jak bardzo lubisz pracować w tym miejscu. Tak, praca może być zła, ale może wynagrodzenie jest dobre, a dojazd trwa tylko 5 minut? Czy pozytywne aspekty pracy przeważają nad negatywnymi? Ja nie, zacznę szukać nowej pracy.

Kristof Claes
źródło
1
Rozmawiałem. Zaproponowałem utworzenie systemu biletowego, wprowadzenie kontroli wersji, ale nie obchodzi go to. Lub rozumiem. Lub obydwa. Zapytałem go, czy ma wiarygodną specyfikację, a on się zgadza. Zmienia to jednak. Nie kieruje się danymi. (Och, usunąłem nacisk na tekst z mojego pytania.)
Łowca dżungli
2
@Jungle: Następnie uruchom ASAP.
sbi
1
Zgadzam się z sbi, jeśli nie poprosiłeś już o zestrzelenie, mógłbyś zgodnie z prawem po prostu wyjść i zrobić to sam. Już straciłeś pokój i gdybym był w twojej sytuacji, zacząłbym szukać.
wałek klonowy
3

Twoim problemem jest to, że systemy sprzedaży biletów i kontrola wersji są kwestiami TECHNICZNYMI i powinieneś to robić niezależnie od wkładu nietechnicznego kierownika. Należy to technicznie uznać za najlepszą praktykę, a jeśli nie mają takiej konfiguracji, powinieneś wziąć na siebie, aby tak się stało.

Nie można oczekiwać od nietechnicznego kierownika, że ​​zrozumie zalety śledzenia defektów, kontroli źródła i ciągłej integracji. Dlatego są nietechniczni, nie powinni o tym wiedzieć ani się tym przejmować, są ekspertami w dziedzinie dziedzin i wiedzy biznesowej. Jedyne, co powinni zapewnić, to wysoki poziom kierunków i wymagania.

Mam również menedżera nietechnicznego i mogłem zwiększyć wynik testu Joela z 4 do 8 tylko dlatego, że poszedłem i zrobiłem to i nie poprosiłem o pozwolenie.

Twoja grupa potrzebuje silnego lidera technicznego i nikt nie podszedł do tablicy.

Sprawdź http://community.rallydev.com/ , mają one wydanie społecznościowe, które doskonale wykonuje zwinne zarządzanie projektami i śledzenie błędów. Samo to podbije twój wynik Joela i nie będzie cię kosztować ŻADNEJ przestrzeni ani czasu na konfigurację serwera.

wałek klonowy
źródło
Tak! To chyba główny problem. Nie mamy silnego lidera technicznego.
Jungle Hunter
2

Jeśli jest to niewielki sklep, w którym ty i pozostali „starsi” w zasadzie jesteście jedynymi osobami, które kodują, to tak naprawdę Twoim obowiązkiem może być wskazanie kierownikowi, co należy zrobić, aby spełnić „test Joela”.

Zmiany wymagań zawsze będą istnieć, a Twoim zadaniem jest ich uwzględnienie, co jest jedną z podstawowych zasad zwinnego rozwoju :

Witamy zmieniające się wymagania, nawet w późnej fazie rozwoju. Zwinne procesy wykorzystują zmiany w celu uzyskania przewagi konkurencyjnej klienta.

Ale dostosowanie się do zmieniających się wymagań oznacza również przestrzeganie innych zwinnych zasad. Na poziomie zarządzania oznacza to, że menedżer musi być w stanie w sposób przejrzysty przedstawić klientowi, że wszystkie takie zmiany wiążą się z kosztami: albo zakres projektu musi zostać zmieniony, aby dotrzymać terminów, albo terminy muszą zostać przesunięte (ten ostatni nie jest zalecany).

Jeśli jest to coś w rodzaju projektu, w którym Twój kierownik spełnia wszystkie wymagania, powinieneś zachowywać się tak, jakby był on / ona sprawnym klientem i wyjaśniać im to samo (zakres <--> kompromisów w zakresie terminów) ).

Ale na poziomie programisty w małej firmie powiedziałbym, że Twoim obowiązkiem jest zapewnienie, aby część kodująca była zgodna z zwinnymi zaleceniami.

Oto kilka kroków, które absolutnie musisz zrobić i prawdopodobnie będziesz musiał wykonać je sam:

  • Państwo musi mieć system kontroli wersji (trwa jeden dzień, aby ustawić go na małym zespole)
  • Państwo musi mieć skryptów kompilacji, aby upewnić się, że można zrobić wersje często (dość szybko skonfigurować również)
  • Państwo musi używać automatycznych testów jednostkowych (jest to sposób kodowania, i to dyktuje całą konstrukcję radykalnie, więc może to być trudne, aby dodać je w środku ściśle sprzężona projektu)
  • możesz również skonfigurować system ciągłej integracji, aby zapewnić automatyczne kompilacje i testy, a także testy funkcjonalne i GUI (trudniejsze do napisania)

Pamiętaj, że możesz mieć repozytorium SVN lokalnie na własnym komputerze. Prosta lista rzeczy do zrobienia może służyć jako system śledzenia błędów biedaka (nieco ekstremalny, ale hej). Nie ma usprawiedliwienia dla braku skryptów kompilacji.

Ponadto przed wypowiedzeniem się na temat kompromisu dotyczącego zakresu / terminu, ktoś musi również przewidzieć, ile czasu zajmie dana funkcja. Zwykle odbywa się to w „idealnych dniach” w zwinnym świecie, co oznacza, że ​​powinieneś zrobić wszystko, aby przewidzieć względny wysiłek każdej funkcji, a następnie użyć swojej rzeczywistej prędkości kodowania, aby zobaczyć, jak dobrze przewidziałeś (i odpowiednio skalować „krzywą” ).

Groo
źródło
Kluczem jest „przewaga konkurencyjna klienta”. Później dzisiaj zapytałem go, dlaczego robi to, aby zaimponować klientowi. : |
Jungle Hunter
Mam dla siebie git / mercurial. Ale teraz przeprowadzam testy ręcznie. Powinienem przyjrzeć się automatycznym testom jednostkowym.
Jungle Hunter
1

Myślę, że w twoim zespole brakuje warstw odpowiedzialności. Powinien być kierownik projektu, analityk systemowy, analityk biznesowy i programiści. Rola Project Managera jest odpowiedzialna za definiowanie i egzekwowanie strategii komunikacji klient-projekt (między innymi zadaniami).

Menedżerowie nie muszą rozumieć kodu ani zawiłości. Potrzeba zrozumienia, zasobów, kosztów i ryzyka.

Wersje kodu źródłowego, jakość kodu, złożoność itp. Są obowiązkiem dyrektora zarządzającego lub starszego programisty.

Rozwiązaniem jest:

1-Zdefiniuj strukturę zespołu projektowego i ich obowiązki

2-Edukuj menedżera w przypadku awarii oprogramowania spowodowanych złym zarządzaniem - Unikaj szczegółów technicznych. Możesz znaleźć kilka przykładów, przeglądając google.

Bez szans
źródło
„Unikaj szczegółów technicznych”. Spróbuję się oprzeć. ;) Dzięki za zwrócenie na to uwagi.
Jungle Hunter
0

Zwłaszcza, że ​​nie ma nikogo, kto wskazałby ulepszenia w moim kodzie.

Czy nie możesz spróbować skonfigurować recenzji kodu, aby ludzie patrzyli na kod? Czy istnieją konwencje i standardy, które pomogłyby nadać kodowi pewną strukturę? Zakłada się, że oczywiście nie jesteś jedynym programistą.

Chociaż prawdopodobnie znajdujesz się w mniej niż doskonałym miejscu, czy wygląda na to, że w końcu działa? Czy projekty się kończą i sprawy idą do przodu? Czy rzeczy się robią? Programator taśm Duct byłby artykułem Joela, który warto przeczytać.

JB King
źródło
Myślałem o zmianie mojego zespołu na taki, który ma ludzi, którzy mogą patrzeć na mój kod. Lub spróbuj skontaktować się z tamtejszymi ludźmi, aby przejrzeć mój kod. Jak powiedziałem w pytaniach, w tej chwili nikt nie może tego zrobić.
Jungle Hunter
0

Opcja 1 - powiedz im „ze wszystkimi zmianami, które wprowadzasz w tym projekcie, do czasu jego wdrożenia system będzie działał bardzo wolno” lub „klient nie będzie w stanie go zrozumieć”. Twoi menedżerowie nie dbają o kod spaghetti, ale dbają o klienta. Przedstaw im problem pod względem tego, co rozumieją, a nie pod względem pisania kodu.

Opcja 2 - daj im to, czego chcą. Kiedy narzekają na coś, co mówisz „ale o to prosiłeś”

jqa
źródło
Zanim „ucieknę”, zrobię dokładnie to. Jeśli chcą zmiany, dam im znać, że nie jest to drobna zmiana tu i tam, więc zajmie to o wiele więcej czasu. Gdy klient nie będzie zadowolony, nie będzie miał na co narzekać, ponieważ dałem mu to, czego chcieli.
Jungle Hunter,
@ Hunter dżungli - Nie każdy ma możliwość odejścia z pracy, czasem trzeba przekroczyć sytuację. Znalazłem najlepszy sposób, aby poradzić sobie z szaleństwem, to odwrócić go od szalonych ludzi. Tylko bardzo szaleni mogą argumentować przeciwko własnemu szaleństwu. powodzenia.
jqa