Temat: A ja się dziwię programistom, przepraszam Was...
Jakub Wojt:
Poza tym, czy znajomość ‘warunków początkowych’ jest wystarczająca np. do rozwijania i utrzymania programu ?
Oczywiście że nie jest wystarczająca. Ale jest niezbędna.
Dlaczego ? Proszę o konkretną odpowiedź :)
>
Głównie po to, żeby wyjaśnić przyczyny, dla których na kolejnych etapach projektu podjęto takie, a nie inne decyzje.
Oczywiście warunki początkowe mogą ewoluować: czas idzie do przodu, technologie się zmieniają, koncepcja klienta co do wykorzystania naszego systemu również się zmienia - tak więc niektóre warunki początkowe mogą się dezaktualizować, "umierać". Ale nawet w takich sytuacjach wiedza o tym, dlaczego i kiedy dane warunki umarły stanowi dokumentację historii projektu.
Uczestniczyłem kilka razy w projektach, w których jakieś corowe wymagania umarły i przestały być rozwijane - po czym klient, zmuszony oczekiwaniami rynku, musiał do nich wrócić, i był zdziwiony, dlaczego to nie działa (a dwa lata temu działało).
Takie decyzje muszą być podejmowane odpowiedzialnie, a więc również muszą być udokumentowane (choćby jako CR).
>
Do niczego :) Przecież nie powinniśmy być samobójcami: jeśli klient chce, żeby ktoś inny (tańszy?) mu rozbudowywał projekt, zabierając nasze (potencjalnie) $$$, to chyba nie będziemy mu w tym pomagać zbytnio ?
Myślę, że najlepszym sposobem na utrzymanie klienta jest oferowanie wysokiej jakości w ‘dobrej’ cenie ;)
Oczywiście :)
Co nie znaczy, że trzeba ułatwiać konkurencji przejęcie naszego produktu
Produkt przejmuje klient bo jest jego właścicielem :)
Hm ... Właściwie to zależy od tego czy w umowie zapisano 'możliwość rozwoju systemu przez inny zespół'. Z drugiej strony istnieje coś takiego jak 'realizacja projektu zgodnie ze sztuką'...
Ja to widzę troszkę prościej: jeśli w warunkach kontraktu jest przekazanie kodów źródłowych i przeniesienie praw autorskich (za co klient musi zapłacić oczywiście) - wtedy proszę bardzo: dokumentacja kodu, diagramy klas itd itp.
Ale jeśli tworzymy produkt zamknięty (bo tak stanowi kontrakt) to nie jest absolutnie w naszym interesie przekazywanie jakiejkolwiek wiedzy, ułatwiającej klientowi/konkurencji rozwijanie produktu bez naszego udziału.
No i jest jeszcze ten Agile który formalnie jest metodyką (sztuką) a pozwala na dowolne skopanie projektu...
Co do Agile - nie wypowiem się tutaj, bo mógłbym się komuś narazić :) Mam swoje zdanie na ten temat ;)
- oczywiście jeśli mamy pole do manewru: jeśli klient zarządał szczegółowej dokumentacji
'dokładnej i kompletnej'
... kurcze, zawsze takiej chcą ;)
Ale nie zawsze im się należy :) Jak pisałem wyżej: nie dostanie dokumentacji dot. szczegółów implementacyjnych jesli nie kupił kodów źródłowych.
(włącznie z opisem 'flaków') i podjęta została decyzja, że mu ją dostarczamy, to mu ją dostarczamy i już :) Ale, jeśli nie musimy, to po co?
Dobre pytanie ...
Bo produkt z pewnością zawiera jakieś błędy które trzeba będzie usunąć...
Nie wiem, zgaduję. :)
>
Od tego jest umowa serwisowa, którą klient podpisuje Z NAMI! A jak nie chce, to niech się buja - będzie płacił za konkretne case-y.
Możesz :) A poważniej: jeśli liderzy zespołu, po zapoznaniu się z tym, co napisałeś stwierdzą, że im to wystarczy, to masz już odpowiedź.
No nie do końca bo oni też muszą mieć do tego jakieś podstawy.
Ależ tak. Dlatego napisałem 'liderzy', a nie 'kierownik projektu'.
Lider powiniem mieć kompetencje merytoryczne nie niższe (a przynajmniej nie niższe w sposób istotny), niż członkowie jego zespołu.
Powinien mieć takie które pozwolą mu na realizację zadań.
>
No i to jest przyczyna niepowodzenia wielu projektów - ktoś, kto zarządza MERYTORYCZNIE zespołem, nie rozumie, co ten zespół tak naprawde robi.
Lider zespołu (np. starszy programista) to stanowisko techniczne, a nie menadżerskie. On ma podejmować decyzje (być może z zespołem, to zależy), jak coś zrobić i ile to zajmie, a nie na kiedy i za ile $$$ - od tego jest project manager, product manager i cała kupa ludzi, którym bardzo często wydaje się, że kasa należy im się za funkcję, a nie za robotę :)
Jak rozumiem, na pytanie 'jak mierzyć jakość dokumentacji' znają odpowiedź tylko liderzy i jest to wiedza tajemna ;)
>
Nie. Ale: czy nie znając się na sztuce jesteś w stanie ocenić obraz, namalowany przez artystę? Jasne, mozesz powiedzieć, że fajny kolor tła, no i laska na obrazie niebrzydka - ale czy to jest ocena?
Z drugiej strony: spróbuj sformalizować sposób oceny takiego obrazu w takim stopniu, żeby dawało to się robić algorytmicznie.
Ja myślę, że tutaj winne jest coś innego: menadżerowie, którzy weszli w branżę IT z branż typu piekarnie, fabryki samochodów, zakłady tekstylne :) bardzo by chcieli 'produkować' oprogramowanie. I tu jest problem, bo akurat programowanie, podobnie jak sztuka, produkować się nie daje, bo jest w 100% pracą twórczą, a nie odtwórczą. Tak więc pojęcia i metodyki, stosowane w typowych zakładach produkcyjnych tutaj się bardzo słabo sprawdzają.
A co do automatycznej oceny jakości dokumentacji:
Ja wiem, że programiści, a ogólnie IT-mani (ci, którzy tworzą), chcieliby móc zaprogramować wszystko (łącznie z żoną - też bym chciał) i stąd biorą się próby tworzenia automatów oceniających jakość kodu czy jakość dokumentacji.
Ale tak naprawdę musimy przyznać: różne firmy stosują różne metody oceny kodu - ale każdą można wyśmiać. To samo się tyczy dokumentacji. Możesz policzyć ilość kartek, wierszy, liter, spacji. Możesz sprawdzić, czy nazwa każdego pola z tabel w bazie występuje minimum raz w dokumencie. Ale nie sprawdzisz automatem tego, czy dokumentacja napisana jest logicznie i czy da się z niej korzystać.
Przez słowo 'automatycznie', które użyłem powyżej, rozumiem nie tyle sprawdzanie przez specjalizowane oprogramowanie, ale również sprawdzanie przez zestaw reguł: począwszy od metodyki, poprzez zalecane layouty itd.
Czy ta wiedza jest tajemna? Nie. Wymaga przeczytania dokumentacji ZE ZROZUMIENIEM i jej oceny. Wiem, że to trudne i coraz mniej ludzi posiada taki dar :)
Piotr Głudkowski edytował(a) ten post dnia 11.08.11 o godzinie 13:35
пропозиції роботи
