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

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.

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.

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

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.

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.

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.