Menedżer oprogramowania, który zmusza programistów do zarządzania projektami

12

Jestem programistą pracującym w firmie zajmującej się systemami wbudowanymi. Mamy Project Managera, który zajmuje się ogólnym harmonogramem projektu (w tym elektrycznym, jakościowym, oprogramowania i produkcji), dlatego jego harmonogram oprogramowania jest bardzo krótki.

Mamy także Menedżera oprogramowania, który jest moim szefem. Zmusza mnie do pisania i utrzymywania harmonogramu oprogramowania, dokumentów projektowych (projektowanie wysokiego i niskiego poziomu), SRS, zarządzania zmianami, planów i raportów weryfikacji, zarządzania wydaniami, recenzji i oczywiście oprogramowania.

Mamy tylko jednego Inżyniera Testów dla całego zespołu oprogramowania (10 członków), a w danym momencie trwa kilka projektów.

80% czasu spędzam na tworzeniu tych dokumentów. Mój szef pochodzi z procesu i wierzy, że potrzebujemy lepszej dokumentacji do ulepszania oprogramowania:

  1. Uważa, że ​​projekt jest najważniejszy, kodowanie „po prostu zapisuje projekt”, nie powinno to zająć zbyt długo, a „cały kod powinien zostać napisany, zanim sprzęt będzie gotowy”.
  2. Nie rozumie różnicy między kontrolką wersji centralnej i rozproszonej, nawet jeśli powiedzieliśmy mu, że łatwiej jest współpracować z modelem rozproszonym.
  3. Nie rozumie kodu i chce zrozumieć każdy błąd i jego proponowane rozwiązanie.
  4. Uważa, że ​​weryfikacja powinna zostać wykonana przez programistę, a weryfikacja przez Testera. Chodzi o to, że nasza weryfikacja sprawdza tylko, czy implementacja jest poprawna (nie piszemy testów jednostkowych, nigdy nie jest uwzględniana w harmonogramie), a sprawdzanie poprawności jest testem czarnej skrzynki, więc testów jednostkowych brakuje.

Jestem bardzo zmieszany.

  1. Czy jestem odpowiedzialny za utrzymanie wszystkich tych dokumentów? Zasadniczo sprawia, że ​​czuję się, jakbym zarządzał projektami oprogramowania. Nie mam nic przeciwko dokumentacji technicznej, ale uważam, że programista nie powinien planować / planować.
  2. Nie bardzo lubię tworzyć dokumenty, chcę rozwiązywać problemy i pisać kod. Z mojego doświadczenia wynika, że ​​tworzenie dokumentów projektowych pomaga tylko w pewnym stopniu, nigdy nie jest rozwiązaniem na lepszy lub szybszy kod.
  3. Uważam, że szefowi tak naprawdę nie zależy na tworzeniu lepszych produktów, a jedynie na byciu dobrym menedżerem w oczach kierownictwa.

Co mogę zrobić? Przez cały rok zrobiłem 3 miesiące faktycznego kodowania, resztę spędziłem na tworzeniu dokumentów i czekaniu na zgłoszenia błędów od klientów.

komar
źródło
16
Jeśli on jest twoim szefem i mówi, że jesteś odpowiedzialny za te dokumenty, jesteś odpowiedzialny.
rig
1
Menedżer oprogramowania to kolejny termin dla właściciela produktu. Jest to zwykle nietechniczna rola, więc nie powinien też pisać dokumentacji technicznej. Zasadniczo współpracują z klientami i interesariuszami i podejmują decyzje o tym, jakie funkcje i zmiany należy wprowadzić w danym produkcie w poszczególnych wersjach. Ograniczają złożoność posiadania wielu interesariuszy o różnych konkurencyjnych potrzebach.
wałek klonowy
2
Próbowałem to poruszyć kilka razy. Problem w tym, że nie wiem, ile wysiłku w planowaniu powinien ponieść PM i jaką rolę odegra w tym moje SM. W tej chwili jestem tym, który tworzy wszystkie wykresy Gantta, alokację zasobów, specyfikację wymagań oprogramowania, macierz śledzenia itp.
1
@hdman Teraz jest trochę inaczej. PM powinien robić wykresy Gantta, alokację zasobów i macierz identyfikowalności. Co zatem robi premier?
wałek klonowy
1
@maple_shaft Jestem młodym facetem i chcę tworzyć, kodować i wypróbowywać nowe rzeczy. Tak naprawdę nie interesuje mnie zarządzanie projektami jako wybór kariery. Chyba nadszedł czas na zmianę.

Odpowiedzi:

19

Brzmisz jak inżynier oprogramowania.

Kierownik projektu jest bardziej skoncentrowany na statusie całego projektu i na efektywnym przydzielaniu zasobów, aby zapewnić osiągnięcie kamieni milowych we właściwym czasie. Usuwają również przeszkody i pomagają zasobom projektu skoncentrować się na ich konkretnych funkcjach.

Pisanie i utrzymywanie dokumentacji projektowej i technicznej jest ważną częścią bycia inżynierem oprogramowania i jest odpowiednie dla twojej roli. Jednak zbyt wiele dobrych rzeczy może być złych (patrz Analiza Paraylsis ).

Uważa projekt za najważniejszy, kodowanie „po prostu zapisuje projekt”

Jeśli kierownik projektu uważa, że ​​dokumenty projektowe są najważniejsze, wówczas oczekuje, że dokumenty te zostaną dostarczone w procesie. Nie jest to zmarnowany czas, jeśli uważasz, że są one wystarczająco ważne, aby przeznaczyć na nie 80% twojego czasu.

nie powinno to zająć zbyt długo i „cały kod powinien zostać napisany, zanim sprzęt będzie gotowy”.

Jest to pobożne życzenie i dość przestarzały widok stylu wodospadu na to, jak działa tworzenie oprogramowania. Niezmiennie nigdy nie jest tak czysty, bez względu na to, ile poświęcisz projektowi i przygotowaniu. W związku z tym powinieneś mieć jasne specyfikacje sprzętu i odpowiednie środowiska testowe oraz próbne symulacje sprzętowe, aby Twój kod mógł z nimi współpracować, ale prawdziwy świat jest bałaganiarski.

Zarządzanie projektami jest niezwykle łatwe w idealnym świecie. Świat nie jest doskonały, jednak bez względu na to, jak bardzo tego chcesz, tak więc zarządzanie prawdziwymi projektami jest niezwykle trudne. Dlatego płacą im duże pieniądze.

(2) Nie rozumie różnicy między kontrolką wersji centralnej i rozproszonej.

Dlaczego miałby się przejmować? Jak wpływa na kamienie milowe? Tak nie jest.

3) Nie rozumie kodu i chce zrozumieć każdy błąd i jego proponowane rozwiązanie

Jego celem jest działające oprogramowanie i twoje też powinno być. Nie musi rozumieć kodu, ale musi rozumieć problemy, które uniemożliwiają działanie oprogramowania. Kiedy oboje zobaczycie oko w oko na tym podstawowym poziomie, wtedy wasz wspólny cel pomoże wam efektywniej współpracować.

(4) Uważa, że ​​weryfikacja powinna zostać wykonana przez programistę, a weryfikacja przez Testera.

Co jest nie tak z tym sentymentem? Testerzy pełniący funkcję zapewnienia jakości powinni zajmować się sprawdzaniem poprawności funkcji i wymagań. Programiści powinni dołożyć wszelkich starań, aby zweryfikować i przetestować swoją pracę, zanim przejdzie ona do testowania.

Nie bardzo lubię tworzyć dokumenty, chcę rozwiązywać problemy i pisać kod.

Jeśli wolisz być prostym programistą, być może powinieneś porozmawiać o tym z szefem i sprawdzić, czy jest dla ciebie lepsza rola w projekcie. Ktoś musi napisać i prowadzić dokumentację techniczną, więc być może jeden z programistów może pomóc ci w niektórych z tych zadań, abyś nie spędzał 80% swojego czasu na pisaniu dokumentacji.

Z mojego doświadczenia wynika, że ​​tworzenie dokumentów projektowych pomaga tylko w pewnym stopniu, nigdy nie jest rozwiązaniem na lepszy lub szybszy kod.

Jest to głównie prawda ... ale tylko wtedy, gdy wszyscy dziesięciu programistów spędza 80% swojego czasu na pisaniu dokumentacji technicznej, której nikt nigdy nie przeczyta. To jest ogromny anty-wzorzec zarządzania, w którym żyłem wcześniej. Jeśli okaże się, że robisz większość dokumentacji dla zespołu, to nie wydaje się sprawiedliwe, że odmawiasz sobie prawa do wykonywania większej ilości prac programistycznych.

Faktem jest, że najlepszą dokumentacją techniczną jest sam kod.

Uważam, że szefowi tak naprawdę nie zależy na tworzeniu lepszych produktów, a jedynie na byciu dobrym menedżerem w oczach kierownictwa

Czuję, że nie ostrożność, ponieważ produkt jest jego podopieczny i czy projekty i funkcje nie są zakończone, a klienci nie są zadowoleni następnie górny zarządzanie nie będzie na nim zależy bardzo dużo. Problem polega na tym, że twoje spojrzenie na niezbędne ulepszenia jakości nie zgadza się z jego i wyższym kierownictwem, a postrzeganie przez klientów tego, co według nich jest ważne.

Spróbuj zrozumieć, co jest naprawdę ważne dla produktu, ponieważ chociaż możesz zwiększyć wydajność procesu trzykrotnie, jeśli spędzasz cały tydzień na tym, to kosztem kolejnej ważnej funkcji jest wymaganie klienta.

Wszyscy chcemy dobrze wyglądać w oczach naszego przełożonego. Nie ma w tym nic złego, ludzką naturą jest służenie sobie. To fakt z życia.

wałek klonowy
źródło
1
Dzięki za odpowiedź, zgadzam się w niektórych punktach. Jaka jest zatem rola Menedżera oprogramowania?
6

W pewnym stopniu zgadzam się z kierownikiem projektu. Rozwój oprogramowania wykracza daleko poza funkcje kodowania. :-)

Biorąc pod uwagę twoją sytuację, poszedłbym do niego i wyjaśniłem, że jego prośby zabierają 80% twojego czasu, i staram się zrozumieć, dlaczego jest dla niego ważne, aby spędzać ten czas na tworzeniu dokumentacji, a nie na rozwijaniu (co wykracza poza kodowanie).

FYI, Atlassion , firma programistyczna, ma stosunek 13 programistów dla jednej osoby odpowiedzialnej za kontrolę jakości, a większość testowania (planowania i wykonywania) jest wykonywana przez programistów. Nauczyłem się tego podczas jednej z ich prezentacji na Agile 2012, a nasze zespoły próbuję obecnie naśladować tę praktykę.

Porozmawiałbym jednak również z kierownikiem projektu, czy byłby otwarty na wypróbowanie Scrum jako metodyki, która pomogłaby przenieść cały zespół do przodu. Biorąc pod uwagę twój opis, nie sądzę, że używasz Scruma.

Podobnie jak ty byłem bardzo sfrustrowany utrzymywaniem planów, które ciągle się zmieniały, a lekkie podejście Scrum pomogło mi pokonać tę frustrację.

David Segonds
źródło
2
Dziękuję za odpowiedź. Próbowałem zasugerować Agile, ale chcą śledzić CMMI. Czy wspominałem również, że mam menedżera oprogramowania?
@hdman Cóż, bądźmy realistami tutaj. Musisz porozmawiać z nimi obojgiem i wyrazić, że zależy Ci na dużym obrazie: upewnienie się, że zespół jest tak produktywny, jak to możliwe, aby firma mogła zwiększyć przychody. Rozmowy te mogą się udać lub nie, ale to Ty jako profesjonalista odpowiadasz za przedstawienie ich na stole i od nich zależy, czy podejmiesz odpowiednie działania. Upewnij się, że przyniesienie jest pozytywne, a nie „narzekanie” na sytuację, ale chęć poprawy sytuacji dla wszystkich.
David Segonds
Zgadzam się, ale chodzi o to, że jestem najmłodszy w środowisku w średnim i starszym wieku. Przez większość czasu sprowadza się to do braku doświadczenia.
4

Najbardziej wydajne zespoły z mojego doświadczenia to te, które zmagały się z najmniejszą ilością procesów niezbędnych do wykonania swojej pracy. W pewnym momencie zaczyna się dodatkowy proces odbierania jakości produktu. Jeśli QA zaczyna omijać błędy, ponieważ są bardziej zainteresowane usunięciem formalności, a DEV nie koduje funkcji ani nie naprawia błędów, ponieważ piszą dokumentację, to masz problem. Jednak zastanawianie się, czy tak naprawdę jest w twojej firmie, jest wysoce zlokalizowanym pytaniem, na które mogą odpowiedzieć tylko ludzie z twojego zespołu (nie my).

Jest jedna rzecz, o której twój szef bardzo się myli, a mianowicie to, że masz tak mało kontroli jakości i żadnych testów jednostkowych. Błąd stworzony przez programistę jest z definicji nadzorem z ich strony. Oczekiwanie, że programiści zawsze będą testować własne funkcje, a poza tym niewiele testów stanowi problem procesowy. Kontrolę jakości można w pewnym stopniu zastąpić automatycznym testowaniem, w zależności od domeny, ale jeśli jej nie masz, prawdopodobnie przepuszczasz błędy (co zwykle kosztuje więcej niż wczesne ich znalezienie).

Ponadto, z ścisłej perspektywy biznesowej, zatrudnianie QA jest tańsze niż zatrudnianie programistów. Będziesz mógł zabezpieczyć więcej ziemi dla wydanych pieniędzy, jeśli zespoły mają dobry stosunek QA / DEV.

MrFox
źródło
QA can be replaced by automated testing depending on your domain-1 zdecydowanie się z tym nie zgadzam. Żadna liczba automatycznych testów nie jest realnym zamiennikiem kontroli jakości, szczególnie gdy w grę wchodzi specjalny sprzęt.
wałek klonowy
1
@maple_shaft Poprawiony. Miałem na myśli, że kontrolę jakości można zastąpić w stopniu zależnym od domeny. Na przykład, jeśli jest to sterownik dla niektórych maszyn, wiesz, że przy pewnych wejściach oczekujesz określonych mocy - można to automatycznie przetestować. Jednak jeśli jest to aplikacja GUI, nie ma mowy o tym, aby prawdziwi ludzie siedzieli i na nią szturchali.
MrFox
Niesamowite! to ma teraz większy sens. Odwróciłem mój głos negatywny, +1
wałek klonowy
Tak naprawdę nie mamy działu kontroli jakości. Mamy jednego testera i mamy dział kontroli jakości. która zapewnia ogólną kontrolę jakości dla mechaniki,
2

Wdrożenia CMMI, o których widziałem lub o których bezpośrednio słyszałem, były bardzo obciążone procesami i dokumentacją; przekonanie szefów, że dokumentacja powinna być wystarczająco szczegółowa, aby implementacja była trywialna, oznacza, że ​​jego oczekiwania są podobne.

Jeśli otrzymujesz nieproporcjonalny udział w pisaniu / utrzymywaniu dokumentacji, uzasadnione jest żądanie jej bardziej równomiernego rozpowszechnienia. Jeśli inni programiści mają dokumentację podobną do współczynników kodowania i chcesz spędzić większość czasu na pisaniu kodu; być może czas zastanowić się nad znalezieniem nowego pracodawcy.

Dan bawi się ogniem
źródło
Dokładnie. On jest całkowicie o CMMI. Teraz jesteśmy na poziomie 3, chce przejść na poziom 5. „Prowadzący” wykonuje większość prac związanych z planowaniem / harmonogramowaniem, które teraz wykonuję. Ale nasza struktura organizacyjna wyrównuje wszystkie SE, więc jedna osoba jest wybierana jako osoba wiodąca i biorąc pod uwagę całą tę pracę, nie ma stałej szansy jako takiej.
I poważnie myślę o twoim ostatnim zdaniu. Wygląda na to, że utknąłem w latach 70. wraz z resztą, gdzie złożoność kodu jest liczona przez liczbę wierszy. Wygląda na to, że ludzie tutaj nie chcą się zmieniać, nie ma kreatywności.
@hdman Nie ma w tym nic złego i niekoniecznie jest to twoja wina lub ich wina. Czasami ludzie po prostu nie pasują do otoczenia.
wałek klonowy
Tak, myślę, że to może być problem kulturowy.
Na poziomie 5 obciążenie związane z dokumentami będzie ogromne; brzmi jakby zdecydowanie nadszedł czas na ucieczkę.
Dan Is Fiddling By Firelight
2

Mówisz o systemach medycznych ... więc bezpieczeństwo jest najważniejsze - dlatego dokumentacja (szczególnie identyfikowalność) jest niezbędna.

Jeden tester wydaje się nieco lekki, ale poza tym tak - jesteś odpowiedzialny za upewnienie się, że dokumentacja jest na miejscu.

Moje doświadczenie w świecie medycznym jest ograniczone, ale w świecie lotniczym / obronnym mamy Do-178B (obecnie C), który określa model cyklu życia, który określa dokumentację i poziom niezbędnych testów (w zależności od krytyczności bezpieczeństwa [dokładniej poziom zapewnienia bezpieczeństwa] oprogramowania), a w świecie motoryzacyjnym mamy ISO26262, który również spełnia te wymagania.

Jeśli dokumentacja nie jest na miejscu, produkt nie uzyska certyfikatu.

Ale ważne jest, aby pracować z wymaganą dokumentacją, aby ulepszyć swój produkt ... nie próbuj przerabiać dokumentacji jako późniejszej refleksji, ponieważ wtedy nie służy ona rzeczywistemu celowi.

Andrzej
źródło