Temat: Z przymrużeniem oka czyli "dam pracę analitykowi"
Jarek Żeliński:
Adrian Olszewski:
Jarek Żeliński:
w moich oczas tylko z powodu ograniczenia jakim jest skapstwo i brak kompetencji - wyobrazni kierownika projektu
A jednak funkcjonowało to bardzo dobrze w firmie, w której pracowałem. Było nas (na początku) dwóch programistów: dyrektor i ja.
Jakie (jak zlozone) to byly projekty?
Systemy "pod klucz" e-crf, systemy automatycznej analizy, analiza statystyczna (to już nie produkcja, aczkolwiek trzeba było ściśle z produkcją współpracować na etapie definiowania systemu), a dodatkowo rozwój oprogramowania "gabinetowego" (InfoMedica, mMedica). Nieduże, na pewno nieporównywalne z systemami korporacyjnymi, nawet nie próbowałbym takiego kitu wciskać :) Złożony (tak, wiem, operuję niemierzalnymi pojęciami :)) model dziedzinowy, system reguł (walidacja, raportowanie, wstępna obróbka). Dość elastyczne, w sensie rozszerzalne o nowe moduły silnie konfigurowalne pod użytkownika (np. zbiory reguł walidacyjnych, raportowanie), przy dość często zmieniających się wymaganiach klientów (pionierskie wówczas w kraju medyczne programy badawcze, nastawione bardziej na eksplorację, niż a. konfirmacyjną). Ponieważ nie było jeszcze funduszy ani czasu, korzystało się z różnych technologii i rozwiązań, co stanowiło "one more point of failure", a trzeba było zapewnić wysoką dostępność serwisu. Do tego nafaszerowane medyczną terminologią, przy jednocześnie dość rzadkich możliwościach konsultacji. Na szczęście programiści nie musieli czytać protokołów z badań, ja tak :)
co nie zmiania faktu, ze to tak zwany "one point of failure" czyli duze ryzyko.
Zgadzam się, że ryzyko było bardzo duże i spędzało sen z powiek (nie tylko szefom), zwłaszcza, jak się za to odpowiadało. Ale też celowo podałem ten przykład, bo jednak nie każda mała firma zabiera się za projekty dużego ryzyka, które oznacza nie tylko zwinięcie manatek i szukanie innej działalności. Na przykład są małe firmy (nawet jednoosobowe), które produkują niewielkich rozmiarów soft np. do gabinetów lekarskich (ale "for your own risk"), czy np. systemy BI małej skali pod klucz.
Po drugie kazda specjalizacja i programista i projekttant i analizytyk wymaga innych umiejetnosci, tak wiec wykonywanie pracy nalezy wspoldzielic z permanentna nauka, czlowiek orkiestra ma jeden problem: kiedy sie uczyc skoro nauka to czas niefakturowany? jezeli jedna osoba i programuje i projektuje i prowadzi rozmowy z kleintami to w dluzszej perspektywie cos zaczyna paprac i nawet sobie z tego sprawy nie zdaje... najczesciej broni swojej uniwersalnosci jak niepodleglosci a jak czasem w projektach pytalem ile dni w roku ktos taki poswieca na nauke i sledzenie rozwoju swojej specjalnosci to mowi o kilkunastu dniach bo jest zarobiony...
Dokładnie... Z tym, że po jakimś czasie, jeśli tylko człowiek obraca się w ramach konkretnej branży i dziedziny zagadnień, idzie to łatwiej. Nauka jest przyrostowa, ponadto wybiera się do nauki kwestie, które są w danej chwili przydatne, pewien procent zagadnień, które wydają się przydatne (załóżmy, że będą to kolejne (anty)wzorce projektowe czy arch., nieco nowej terminologii i "jak to robią inni") i ani grama więcej.
tu bede polemizowal :) obserwuja male (co by to nie mialo znaczyc) projekty i duzo lepsze efekty osiaga firma majaca jako stala obsade menedzerow i ewentualnie koderow zas projektowanie i analize, ktora nie przekracza 20% czasu projektu zleca na zewnatrz, niz firmy male ktory takze maja menedzerow i koderow ale analizy i projektu robia ci sami menedzerowie i koderzy bo na 20%
Oj, tutaj jeszcze nie mówmy o managerach i całym tym złożonym świecie :) To była... grupa ludzi, którzy mieli pomysł, intuicję, zdolności i odbiorcę, który chciał i mógł zaryzykować no i szczęście, że te cztery pozytywy zebrały się jednocześnie. Zamówienia i listy zmian spływały zbyt szybko, czasu było zbyt mało, a fundusze jeszcze były zbyt niskie, aby szukać odpowiednich podwykonawców (którzy wezmą dostateczną odpowiedzialność za to, co robią). A potem nie było już czasu na uczenie ich wszystkiego tego, co umieliśmy. Dopiero po magicznych 2 latach zaczęło się to zmieniać i faktycznie, część zagadnień (ale nie medycznych; firma robiła jeszcze kilka rzeczy) została "wyoutsorcowana", a firma zmieniła profil na bardziej konsultingowy, chociaż produkcji "pod klucz" nie zarzuciła. Dlatego powiedziałem, że to być może rodzynek, chociaż to nie jedyna firma, która w tej wielkości zespole, bez wyraźnych specjalizacji, poradziła sobie w wymagającym jednak środowisku IT w medycynie.
tylko wiedza o tym jaki zakres w jakim czasie zostal wykonany i jakim kosztem jest utrzymywany mowi cokolwiek o projekcie, listy referencyjne podobne do tych na tej stronie to wylacznie lista faktur bez kwot, nie krytykuje tej firmy ale zwracam uwage, ze na ich stronie nie ma niczego co pozwolilo by ocenic ich kompetencje.
Zdaję sobie sprawę, ale niestety, nie mam nic lepszego. Mówimy tutaj o kompetencjach w zakresie zdolności produkcyjnych i faktycznie nie mam tutaj żywych dowodów w postaci <kwota, liczba MD, alokowane zasoby, złożoność, dziedzina, wydajność>, bo takich nie mogę udzielić, zwłaszcza, że już tam nie pracuję. Natomiast kompetencje branżowe to już inna kwestia i ich ocenę pozostawiam klientom.
PS: pewnie, że wiele rzeczy można było zrobić lepiej, zgodnie z dobrymi wzorcami i dzisiaj można na ten temat długo debatować, ale to już post factum. A tu się wygenerował offtop, w sumie z mojej winy... Chociaż ja tam nie narzekam, bo Pan zawsze zmusza do głębszego zastanowienia :)
Adrian Olszewski edytował(a) ten post dnia 11.07.10 o godzinie 15:36