Zakres obowiązków programisty

0

Witam,

Jaki jest Wasz zakres obowiązków poza samym tworzeniem/rozwijaniem oprogramowania ? Ostatnio nurtuje mnie taka kwestia. Pracuję w stosunkowo niedużej firmie przy utrzymaniu pewnego projektu. Na chwilę obecną w związku z pewnymi zawirowaniami kadrowymi wzrósł nieco mój zakres obowiązków - doszedł mi dodatkowo bezpośredni kontakt z klientem ws. zmian, poprawek. Osoba z którą się kontaktuję jest 'inżynierem procesu' za który odpowiada mój projekt. Wszytsko byłoby ok tyloko że ostatnimi czasy zakres zmian zaczął się wymykać spod kontroli. Pan inż. zaczyna mieć sporo dziwnych pomysłów na zmiany, modyfikacje itd, które niestety nie zawsze są sensowne. W praktyce ostatnio więcej czasu spędzam na wymianie mail ,wiszeniu na telefonie i wybijaniu mu z głowy zmian które z mojego punktu widzenia są bez sensu gdy ma się całościowy obraz aplikacji. Dodatkowo dochodzi analiza błędów które w większości wynikają z winy klienta tzn dane niezgodne z wytycznymi itd itp, albo ratowaniu im klientowi tyłka kiedy coś spieprzy. Ogólnie to zdarza mi się przez cały dzień konsultować jedną pierdołę której wykonanie zajmuje w porywach do 2h (tzn napisanie max 5 linijek , poprzedzone analizą kodu), albo analizować przez kilka godzin czemu nie wykonało się tak jakby klient tego chciał i udowadniauniu że błąd jest po jego stronie a nie po naszej.

Martwi mnie to trochę o tyle że nie mam dużego doświadczenia w tej branży (<1 roku) i sądzę że mój rozwój powinien się opierać bardziej na pisaniu czegoś nowego - siedzniu w jakimś nowym projekcie gdzie miałbym szansę się wykazać. Boję się że stoję trochę w miejscu bo tchnologie w nim wykorzystane nie są jakieś super nowoczesne (ale też nie kompletnie przestarzałe, jakość kodu też jakaś zła nie jest) a jak wiadomo kto stoi w miejscu ten się cofa. Z drugiej strony taka analiza projektu pozwoliła mi się sporo nauczyć zwłaszcza z obszarów w których dotychczas miałem braki

Chciałbym się dowiedzieć jak to wygląda z Waszej strony. Tzn czy sytuacja którą opisałem to coś normalnego w tej branży ? Czy do waszych obowiązków również należy kontakt z klientem i dyskusje z nim ?

Czy moje podejście i chęć pracy przy czymś zupełnie nowym nie jest zbyt "idealistyczne" tzn że nie często trafia się projekt od 0 i w większości wypadków utrzymuje się starszy kod. Czy programista na początku kariery powinien trafić do "starszego" projekty czy lepiej żeby pracował przy czymś kompletnie nowym ?

Ktoś się wypowie ? ;-)

0

Ja mam tak, że wsparcie aplikacji jak najbardziej, bo kto ją zna jak nie Ty.
Grzebanie w czyimś kodzie to też jest forma nauki, bo uczysz się czytać cudzy kod. Chyba że jest on dramatyczny to nie ma czego się uczyć.

A co do ustaleń z klientami czy coś należy zrobić czy nie to jest szef.

1

Osoba z którą się kontaktuję jest 'inżynierem procesu' za który odpowiada mój projekt. Wszytsko byłoby ok tyloko że ostatnimi czasy zakres zmian zaczął się wymykać spod kontroli. Pan inż. zaczyna mieć sporo dziwnych pomysłów na zmiany, modyfikacje itd, które niestety nie zawsze są sensowne. W praktyce ostatnio więcej czasu spędzam na wymianie mail ,wiszeniu na telefonie i wybijaniu mu z głowy zmian które z mojego punktu widzenia są bez sensu gdy ma się całościowy obraz aplikacji

Nie bardzo rozumiem. Ta osoba jest twoim "klientem" i ma swoje wymagania. Nie jest twoją rolą oceniać ich sensowność. To klient decyduje co by chciał mieć. Skoro chce X to jest jego sprawa. Niech da to na piśmie, założy taska w issue trackerze czy coś a ty zaklepiesz.
Wiele razy zdarza mi sie że z mojego punktu widzenia wymaganie klienta jest głupie, niemniej to nie jest moja sprawa żeby to oceniać. To klient wie jak korzysta z oprogramowania i co mu jest potrzebne. Jedyna kwestia w której powinieneś się wypowiadać to estymacje i ewentualne skutki. Tzn informować klienta o tym że dana zmiana może być bardzo czasochłonna, albo że jest ona w sprzeczności z czymś to już istnieje. Dlatego też warto mieć wszystko na piśmie, żeby potem nie tłumaczyć się skąd sie coś wzięło.

0

@Shalom: nie chcę wypowiadać się za Autora wątku, ale często pewne z punktu widzenia usera pierdoły wiążą się z koniecznością przestawienia 3/4 architektury, bo (przykład z mojego podwórka) korygowałeś fakturę, a masz korygować wartość odczytu na podst. której faktura jest generowana i dopiero wystawiać korektę. A najlepiej zrobić możliwość zrobienia jednego i drugiego. Przy czym klient niekoniecznie wie czego chce bo musiałby potestować na żywca jak to się sprawdzi. A appka jest już gotowa, oczywiście wszystko można zrobić, pytanie za ile i na kiedy. Ano najlepiej na wczoraj i jak najtaniej. A na końcu klient się rozmyśli :P

2

@alagner jasne i wtedy mówisz klientowi jak wygląda sytuacja, że zgodnie z pierwotnymi wymaganiami aplikacja działa tak i tak i wprowadzenie wspomnianej zmiany wymagałoby tyle i tyle czasu i pytanie brzmi czy faktycznie tego potrzebują. Ale kłócenie się z klientem że nie potrzebuje jakiejś funkcjonalności albo że jest głupia jest nie na miejscu ;)

0

To nie jest kłócenie się z klientem ;-) . Problem polega na tym że klient nie do końca zna i nie do końca rozumie system działa (zwłaszcza jego backendowe mechanizmy) a próbuje wprowadzać zmiany. I takie zmiany czasto trzeba mu wybijać z głowy i sugerować że to niezbyt dobry pomysł. Nie chodzi zresztą tylko o nowe funkcjonalności ale też utrzymywanie istniejącej aplikacji - klient potrafi sam uwalić aplikację ładują niewłaściwe dane ;-)

@alagner - tak to właśnie takie stanowisko kompleksowe.

Chodziło mi po prostu na ile sytuacja jw jest normalna w tej pracy ? ;-)

0

Z mojego małego doświadczenia - bywa to normalne. Wiem jak jest u nas firmie, z tym, że to raczej my (głównie księgowość) jesteśmy po drugiej stronie, a koderzy odbierają od nas bezpośrednio zgłoszenia. Ale - bez urazy oczywiście - często jojczenie klienta wynika też ze zwyczajnego niedoszacowania/niedopytania - bywa, że coś się spartoli bo nie dopytano o coś dla klienta oczywistego (tak oczywistego, że nie powiedział, bo to jasne) i wtedy jest klops, zwłaszcza jak autor softu nie zna branży.

Chyba zresztą @Koziołek o tym u siebie na blogu pisał - dobrze przynajmniej w ograniczonym zakresie wiedzieć co piszesz, bo zwyczajnie wiele to ułatwia.

0

Niejednokrotnie wprowadzałem do systemu zmiany, które z mojego punktu widzenia były głupie, a nawet szkodliwe. Z mojej strony przełożony dostawał informację jak bardzo jest to szkodliwe, czym grozi w przyszłości i ile zajmie wprowadzenie tego. Jeśli nadal z całą świadomością chce ją wprowadzić, to nie mnie to oceniać. W każdym razie dopóki mi za to płaci, mogę na zmianę wprowadzać zmiany i później usuwać je w koło Macieju :)

0

To nie jest kłócenie się z klientem. Problem polega na tym że klient nie do końca zna

o_O? Nie do końca sie zna na czym? Na dziedzinie w której używa systemu? Na tym co mu jest potrzebne? To kto sie niby ma znać? To sie zdarza, ale zwykle w sytuacji kiedy kim innym jest "klient" który płaci za soft a kim innym są użytkownicy. Bo czasem wtedy pojawiaja się idiotyczne żądania w stylu "przeróbmy naszą aplikację do clouda bo to teraz modne". Niemniej jeśli wymagania są wcześniej ustalone z użytkownikami to oni są jedynymi którzy się "znają".

i nie do końca rozumie system działa (zwłaszcza jego backendowe mechanizmy) a próbuje wprowadzać zmiany. I takie zmiany czasto trzeba mu wybijać z głowy i sugerować że to niezbyt dobry pomysł. Nie chodzi zresztą tylko o nowe funkcjonalności ale

Ale klient wcale nie ma rozumieć jak działa system. To jest dla niego nieistotne. Dla klienta system ma działać i produkować spodziewane wyniki i tyle.

Popełniasz tutaj klasyczny błąd programisty, tzn zakładasz że jak coś jest ciężko napisać bez hacków w systemie albo jak jakaś funkcjonalność nie bardzo jest możliwa do napisania przy aktualnej architekturze to znaczy że jest głupia i niepotrzebna. I że gdyby klient wiedział jak działa system to by rozumiał że ten pomysł jest do bani. Ale to jest zwyczajna bzdura. Wszystko da sie napisać. Należy tylko poinformować że ze względu na wymagania X, Y, Z o które prosił w tym i tym dniu, taka zmiana będzie czasochłonna i skomplikowana.

też utrzymywanie istniejącej aplikacji - klient potrafi sam uwalić aplikację ładują niewłaściwe dane

I co w tym dziwnego? Większość aplikacji ma coś takiego jak support L1 i L2 który obejmuje takie kwestie. Zwykle klient za to po prostu płaci...

0

Na moje zdrowsza relacja to klient <-> konsultant <-> programista. Klient i konsultant ustalą jak coś ma być zrobione a dev dostaje konkretnego taska.

1

Ten twój Konsultant to chyba Analityk Biznesowy ;) I oni wcale nie ustalają "jak" coś ma być zrobione, tylko "co" ma być zrobione, jak ma działać i jak sprawdzić czy działa poprawnie ;]

0

Jak zwał tak zwał, pewnie w zależności od firmy może być jedna i konsultant i analityk biznesowy, ludzi jak mrówków.
Ale mimo wszystko taki Analityk też może przecież cos zasugerować, jakieś lepsze rozwiązanie. Ale ogólnie jak klient płaci to jego sprawa.

Generalnie chodziło mi o to, żeby programista mógł się skupić wyłącznie na swojej działce.

0

Zgodzę się z tym iż nazewnictwo w firmach nijak nieraz się ma do powierzonej roli. Tak samo niekiedy analitycy sami podsuwają swoje rozwiązania, zależy od tego jak ich poniesie flow. Koniec końców, programista w takim rozrachunku ma święty spokój.

1

Należy tutaj rozróżnić o jakim projekcie mowa, jak to jest stary system używany przez X lat to jak najbardziej można powiedzieć że użytkownicy wiedzą czego chcą i ich wymagania pewnie mają sens i można zrzucić na programistę kontakt z klientem w celu zebrania wymagań i ich zaimplementowania, szczególnie jeśli programista Y już jakiś czas pracuje w danej części systemu/modułu i ma pojęcie na temat procesów biznesowych tam zachodzących.

Całkowicie inaczej ma się sprawa z nowymi systemami szczególnie tymi które nie zastępują istniejących, ale mają wspierać potrzeby biznesu które na przykład nabrały na znaczeniu w strukturach firmy lub na przestrzeni lat stały się wymogiem na rynku. Tutaj ważnym elementem jest posiadanie ludzi którzy potrafią powiedzieć nie i to uzasadnić, ponieważ klient biznesowy nie ma do końca pełnego obrazu jak coś ma działać ma tylko wyobrażenie. W takich przypadkach zrzucanie na programistę szczególnie nie obeznanego z daną branżą kontaktu z klientem jest bez sensu bo programiści mają takie podejście "klient nasz pan" jak chce tak dostanie, w takich przypadkach żaden zdrowo rozsądkowy menadżer, kierwonik jak zwał tak zwał, nie pozwoli dogadywać się programiście z klientem. Tutaj większe znaczenie mają konsultanci, analitycy biznesowy czy jakkolwiek ich nazywacie. :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1