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

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.

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).

... 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ę.

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.

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ę.

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.

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.

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ą” ).

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.

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ć.

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ś”