Jestem programistą. Pół roku temu temu trafiłem do pewnej firmy z polecenia współpracownika, którego poznałem w jeszcze innej firmie. Pensja super, ale już po pierwszym większym projekcie wiem, że muszę spierdzielać stamtąd gdzie pieprz rośnie.
System, którym się zajmuję jest dość duży i wiekowy, jednak widać, że przeszedł po drodze kilka poważnych refaktoryzacji. W skrócie umiarkowane spaghetti, nie jest źle. Moim głównym zadaniem jest łatanie ewentualnych błędów i tworzenie importów danych. System zasilany jest danymi wykazywanymi przez kontrahentów najczęściej w postaci plików Excel. Największym problemem jest to, że podczas takiego importu muszę przetłumaczyć logikę danych zawartych w pliku, na logikę naszego systemu. Niestety logika wyjaśniana jest przez kontrahenta na spotkaniach z biznesem, na które nie jestem zapraszany. I tutaj pierwszy zgrzyt...
Zawsze po takim spotkaniu dostaję dwa maile. Pseudo podsumowanie i korespondencję z kontrahentem, co w większości daje mi jedno wielkie nic. No może prawie nic, bo zawsze staram się z tych wypocin wycisnąć jak najwięcej niezbędnych danych. Natomiast wydobycie jakichkolwiek informacji od biznesu to droga przez mękę. Na odpowiedź mailową muszę czekać nawet kilkanaście dni. Dlatego najczęściej latam po całym biurze i "irytuję" wszystkich moimi "zbędnymi" pytaniami. Czasami wydaję mi się, że w ich przeświadczeniu po pół roku pracy powinienem być specjalistą w dziedzinach, którymi zajmuje się wszystkie jedenaście działów i znać ich strategię jak amen w pacierzu. Najgorsze, że nie mogę nic z tym zrobić, bo dział IT nie ma kierownika, tylko podlegamy pod głównego managera i w hierarchii korpo jestem tylko zwykłym szaraczkiem i gdzie mi tam do wielkiego byznes majster kierownika... Co prawda główny majster już kilkukrotnie upominał biznes na operatywkach (na które swoją drogą również nie jestem zapraszany), że powinni dostarczyć nam wszelkich niezbędnych danych. Taka nagana działa przez trzy, cztery dni i wracamy do szarej rzeczywistości. A najgorsze jest to, że zwykle kilka dni po pierwszym imporcie wyszukują jakąś nieprawidłowość, która wynika z tego, że nie przekazali mi jakiegoś, wbrew pozorom, istotnego szczegółu. I kto wtedy musi naprawiać odprawiając istną fekalioplastykę na danych?
Pytacie o analityka biznesowego? A no był taki ktoś i zwolnił się jakieś dwa tygodnie po tym jak zacząłem pracę. Jako główny powód zwolnienia podał (i tutaj cytat): "Prościej wycisnę jakąkolwiek informację od ściany za tobą niż od biznesu". Miał chłop świętą rację... Ps. Nadal szukają.
Drugi zgrzyt. Czasami wydaje mi się, że spychologia stosowana to najbardziej popularny kierunek studiów kończony przez pracowników polskich korporacji. Jednak w tej firmie pracują chyba sami doktorzy rehabilitowani w tej dziedzinie. Poza tym pierwszy raz widzę sytuację, w której wszystkie działy zmówiły się przeciw jednemu, IT. I nie dziwiłbym się gdyby ten system działał jakoś tragicznie źle, no ale kur... nie. W trakcie mojej pracy zdarzyły się cztery błędy, które wynikały stricte z ułomności systemu i na dodatek były marginalne, dotyczące małych wyjątków, których ktoś nie przewidział (lub nie został o nich poinformowany przez biznes). Natomiast w większości wynikają z debilizmu użyszkodników... Zabrzmiałem trochę jak zły programista z wybujałym ego, ale oto przykład:
Kontrahent wysyła nam listownie pisma dotyczące różnych spraw, które są rozróżniane unikalną sygnaturą. Pisma zawierają kwotę, którą należy dobić na sprawę i co ważne może ona przyjąć trzy określone wartości (np. 50, 100, 150 zł). Jaka kwota zostanie wykazana jest zależne tylko i wyłącznie od kontrahenta, nie ma zasady. Kolega usiadł i w pełnej współpracy z osobą, która będzie odpowiedzialna za wprowadzanie tych danych stworzył formularz:
a) w którym należy w pierwszej kolejności wpisać unikalny numer, a jeśli jest błędny (nie ma takiej sprawy w systemie) wywala wielki czerwony komunikat "TAKA SPRAWA NIE ISTNIEJE, UPEWNIJ SIĘ, ŻE NUMER JEST PRAWIDŁOWY I WPROWADŹ KWOTĘ JESZCZE RAZ!"
b) należy wybrać z listy rozwijanej kwotę podaną w piśmie (przypominam: 50, 100, 150 zł), gdzie domyślna była wartość 50 zł (i to zgodnie z założeniami od osoby, z którą współpracował)
Po kilku miesiącach, gdy dział analiz w końcu zdołał stworzyć raport analizujący te w kwoty, wykrył, że wszystkie wprowadzone do systemu kwoty są równe 50 zł, a i kilkuset brakowało. Okazało się, że osoba odpowiedzialna za wprowadzanie danych za nic miała sobie wielki czerwony komunikat i nie wybierała kwoty z listy rozwijanej, bo myślała, że system sobie poradzi. Ostateczny werdykt biznesu to, źle zabezpieczony formularz przez IT, nasz pracownik nie jest niczemu winien. Na szczęście szefu nie jest debilem.
Prawda jest taka, że powyższe anegdotki powinny mnie skłonić do ucieczki w siną dal, ale nie jedno przeżyłem w polskich firmach i oceniam te historie jako zdatne do przeżycia (no i ta wypłata :D). Jednak dzisiejsza sytuacja sprawiła, że w przerwach od pisania tej historii aktualizuję CV. Od miesiąca w firmie wrzało jak w ulu rozjuszonych szerszeni. Oczywiście wiedzieli o tym wszyscy poza IT. Pojawił się kontrahent, który miał mocno specyficzne wymagania, ale proponował miliony monet. Umowa została podpisana, krótko przed wigilią i obsługa miała zacząć się pod koniec stycznia. Czas realny na wykonanie zadania gdybyśmy zostali o tym fakcie poinformowani w dniu podpisania umowy, a najlepiej wcześniej, bo pełna specyfikacja była już znana w październiku. Jak dowiedzieliśmy się o nowym kontrahencie? Przyszedł do nas szefu nad szefami i pyta jak nam idzie, bo w biznesie praca wre... A my świecimy oczami, bo nipanimaju.
Okazało się, że biznes stwierdził, że mają tyle pracy z nowym projektem, że nie mają czasu nas informować, tym bardziej, że zwykle wyrabialiśmy się z importem w około tydzień. Szkoda, że nie pomyśleli, że skoro w normalnych projektach muszą jedynie pamiętać, że jest nowy kontrahent i należy po prostu kliknąć w nową ikonkę w systemie przy obsłudze, a tutaj jednak muszą się troszkę pomęczyć to ile roboty musi mieć IT.
Miałem ochotę kogoś zabić, ale przełknąłem. Do końca stycznia zostało dużo czasu, zdążymy zrobić importer. Zanim zaczną się dziać na sprawach jakieś akcje wymagające użycia bardziej wymagających funkcji systemu minie kilka tygodni. W tym czasie damy radę ogarnąć resztę.
Dzisiaj przyszedł do nas główny manager i poinformował, że w operatywce (na którą ku... nadal nie jestem zapraszany) brał udział główny zarząd i biznes stwierdził, że są gotowi do obsługi nowego kontrahenta, na co zarząd rzekł to obsługujcie od poniedziałku, na co ja rzekłem i główny manager rzekł i dwie z sześciu osób z mojego zespołu rzekły a niech obsługują - i rzuciliśmy papierami.
Nie od dziś wiadomo że biznes to ameby. My w systemie mamy tak że jak komuś walnie zajefajny komunikat błędu że coś zrobił źle, to dostajemy na komunikatorze info kto i co zrobił źle. I to potrafi się zdarzyć 5 razy pod rząd w ciągu minuty. Wprowadza taka ameba EAN do pola opatrzonego etykietą "Numer wewnętrzny", dostaje komunikat "Helloł, wystąpił zajefajny wyjątek, dział IT został o tym powiadomiony". Więc cofa przeglądarkę i wprowadza to jeszcze raz, a nuż zadziała. A nuż IT rozwiąże problem że "Numer wewnętrzny nie łyka EAN". Czasami mam ochotę komuś zrobić krzywdę. Przestali mnie zapraszać na spotkania z biznesem, gdy zacząłem zadawać im niewygodne pytania i drążyć temat, kto poniesie odpowiedzialność finansową gdy zdarzy się coś nieprawdopodobnie oczywistego.
Odpowiedz@kojot_pedziwiatr: W większości systemów na jakich pracowałem również był taki ficzer, lecz tutaj niestety nie. A szkoda bo to świetna sprawa. I prawdę mówiąc pracowałem nad nim w przerwach od moich głównych zadań, ale roboty było tyle, że przez kilka miesięcy udało mi się napisać jedynie wstępny projekt klasy.
Odpowiedz@kojot_pedziwiatr: Ja wiem, że na styku biznes-IT zawsze iskrzyło, iskrzy i pewnie dalej będzie się rozgrzewało do czerwoności. Ale właśnie takie potem komentarze są przyczyną tych uprzedzeń. Użyszkodnicy, ameby, troglodycy z IT, informatycy we flaneli itd itp Historii wzajemnych nieporozumień też mam sporo :) Ale na początek - trzeba spróbować znaleźć wspólny język. To jest najtrudniejsze.
OdpowiedzPodobne sytuacje bywały i w mojej pracy, ale koledzy od razu mi zrobili szkolenie jak sobie z nimi radzić. Po pierwsze e-mail. Tylko taka forma jest możliwym zastępnikiem formalnego wniosku o zmianę. Żadne ustalenia na czacie, a najgorzej - ustalenia ustne. I w drugą stronę: zawsze wysyłam e-mail z zapytaniem. Jeśli nie otrzymam odpowiedzi, mam chroniony zad. Przyjdzie szef i zapyta czemu coś jest niezrobione? - dam mu maila z datą kiedy wysłałem. Wtedy szef robi jesień średniowiecza biznesowi. I stety-niestety taka jest przyszłość zawodu w biznesie: konsulting a nie programowanie. Już jest wiele programów które cały import danych (o ile korzysta ze standardowych form komunikacji) robi za Ciebie. Czasem trzeba tylko coś wyklikać, skonfigurować. Powodzenia!
OdpowiedzAha... Ale wiesz, że poza klasycznie piekielnymi elementami (użyszkodnicy, położenie IT w organizacji) to piekielni jesteście też wy nie mający odpowiednich kontaktów z resztą firmy, dzięki których wcześniej nieoficjalnie dowiedzielibyście się o nowym kontrahencie...
Odpowiedz@Zunrin: Że ja o tym nie pomyślałem... Wystarczyło raz w tygodniu latać po całej firmie i wypytywać czy aby nie pojawił się jakiś nowy kontrahent, które pliki odwrócą system do górny nogami. Świetny pomysł...
Odpowiedz@Satsu: Jaki zabawny... Siedźcie dalej w swojej wieży i narzekajcie, że nic nie wiecie... Co, wy żadnych znajomych w innych działach nie macie, żeby co jakiś czas zadzwonić czy zajść spytać się co słychać?
Odpowiedz@Satsu: to trochę jak mamy narzekające "nikt mi w tym domu nie pomaga!" gdy same o pomoc nie poproszą i oczekują, że dziecko przez ściany i podłogi widzieć będzie, że mama potrzebuje pomocy :D Tak samo biznes stwierdził, że IT ma się domyśleć, wywróżyć z kuli (albo raczej z plątaniny kabli, jak z fusów), że będzie nowy kontrahent. Ustaw automatycznego maila, który codziennie będzie się wysyłał z pytaniem czy nie ma nowego kontrahenta, którego pliki rozwalą system ;) jak będą narzekać na spam to przytocz tę sytuację :D Jako "dobry i pilny pracownik dbający o interesy firmy" możesz też nastawić by wysyłał się co godzinę.
Odpowiedz@Zunrin: Jak wszystko ma działać płynnie to ktoś musi nad tym czuwać. Jak informatyk się będzie kręcił z kawką po firmie, zamiast siedzieć i pracować to dojdzie do sytuacji, że będzie jakieś proste rzeczy naprawiał tygodniami. Przecież widać jak to działa w administracji, która zawsze ma na wszystko czas. Na głupią pieczątkę czeka się tygodniami, bo teraz to pani kawkę pije, a potem przyjdzie ktoś z nią pogadać i też nie ma czasu, a potem przyjdzie ktoś z czymś do załatwienia "na już" i ogólnie będą ważniejsze rzeczy. Więcej niż 8h nie będzie siedzieć, a to znaczy, że jak przyszła o 7 to o 15 już zdaje klucz portierowi, a sprawy można załatwiać do 14:30. Zresztą w ogóle nie pojmuję tej logiki, a obserwuję, że u mnie w pracy również tak jest. Jak mi ludzie o niczym nie mówią to siłą rzeczy tego nie wiem. Nie jest to coś prywatnego do podziału między psiapsiami z pracy, tylko np. wydarzenie, które uniemożliwia mi moją pracę. I na koniec czuję, że w sumie to po co ja tam w ogóle jestem, skoro ani się mojego czasu nie szanuje, ani najwyraźniej nie do końca uznaje się mnie za pracownika, skoro sprawy, które się dzieją w pracy nie są mi w żaden sposób przekazywane. I karuzela się kręci - nie chcę mieć z nimi żadnej styczności poza tą niezbędną do pracy, bo mnie nie szanują. I to nie ja jestem dziwna, bo w innych miejscach normalnie przychodził e-mail i każdy wiedział co się dzieje. Jak pytam czemu nie informują to zawsze "aaa no w sumie następnym razem poinformuję".
OdpowiedzKolego programisto, jeśli formularz dopuszcza wprowadzenie do systemu danych, które nie mają sensu (np. zły numer sprawy), to jest błąd systemu (czyli programisty), a nie użytkownika. Pomyśl, jak to wygląda z punktu widzenia użyszkodnika. Próbuję coś wprowadzić do systemu, wyskakuje mi jakiś czerwony komunikat. Albo go nie rozumiem, albo mam go gdzieś (bo jestem przecież przekonany, że JA wszystko robię dobrze, to ten głupi komputer się myli!), więc pomimo to nakazuję przesłanie danych do systemu. Skoro system mi na to pozwala, to problem już nie jest mój. Zresztą jaki problem, skoro dane przeszły? A bo to pierwszy raz zdarza się, że komputer uznał poprawne dane za błędne i jakiś tam komunikat pokazał? Dopiero brak możliwości wprowadzenia (błędnych) danych mógłby mnie skłonić do innej reakcji - np. do zgłoszenia sprawy szefowi (jacy to ci informatycy źli/głupi, że taki system nam dostarczyli), albo działowi IT. Głupie to, czy nie - ale jak tę zasadę zrozumiesz, to liczba problemów z użyszkodnikami zmaleje. (Przy okazji zmaleje liczba bzdurnych danych w samym systemie.)
Odpowiedz@tomekp2: Dokładnie o tym samym pomyslałam - jeżeli zostają wprowadzone błędne dane to blokujesz możliwość zapisu/wysłania i martw się użytkowniku. Jeżeli takie dane przyjmujesz to już niestety Twój, jako programisty, problem. Oczywiście może być też tak, że osoba odpowiedzialna za aplikację uparła się, że aplikacja ma łykać wszystko jak pelikan, nie ważne czy dane są ok czy nie - bo przecież tak też się zdarza...
Odpowiedz@tomekp2,Koralik: W treści historii jest wyraźnie napisane, że formularz działa w ten a nie inny sposób z powodu takich właśnie życzeń biznesu. Największą bolączką wszelkich programów są założenia zleceniodawców.
Odpowiedz@tomekp2: Nie pisałem tego w historii gdyż stwierdziłem, że ta informacja będzie zbędna, ale jak widać. Frontend aplikacji, który powstał lata temu, jest napisany w sposób mocno hermetyczny i jest silnie zintegrowany z backendem, dzięki czemu tworzenie nowych formularzy i CRUD wymaga jedynie kilku linii kodu. Niestety z tego samego powodu jego rozbudowa jest mocno utrudniona. Poza tym tempo pracy było dość duże, więc zamiast budować nieeleganckie rozwiązanie na gumkę i sznurek zdecydowaliśmy się na mniejsze zło i wykorzystanie istniejących możliwości. Czyli według mnie dość czytelnego komunikatu, który oczywiście został wyjaśniony osobie zainteresowanej w formie mailowej, słownie i wizualnie.
Odpowiedz@tomekp2: tak się nie da robić dużych projektów... Bo czasem jest to kwestia integracji z zewnętrznymi systemami (a wprowadzanie musi działać offline, żeby nie kłaść całej firmy, jak koparka urwie światłowód). Bo czasem jest to kwestia workflow - wpiszę takie dane, jakie mam teraz dostępne, a resztę uzupełnię później. Bo czasem jest to po prostu niemożliwe - jeżeli jest miejsce na nazwisko, to przecież nie masz dostępu do bazy PESEL, każdy jeden może być Kowalskim ...albo Koakdhadskim. A koniec końców - użytkownika nie można frustrować. Użytkownik ma mieć możliwość poprawienia swoich błędów. Później. Bo jak ma młyn, to ma wpisać co potrzebne, a uzupełnić w luźniejszej chwili.
OdpowiedzNo cóż zarządzanie wymaganiami się kłania. No i parę sztuczek. W mailach pisz będzie tak i tak jeżeli ma być inaczej to proszę o informacje do tego i tego dnia. Każde zlecenie musi być odebrane w sposób sformalizowany. Jak macie na piśmie , że jest kompletne, poprawne i spełnia wymagania to prosicie o naciśnięcie magicznego przycisku pod nazwą zarządzanie zmianą. Kto wam zleca prace? I jak? Jest sporo systemów do zarządzania tworzeniem. Wdrożcie któryś, będzie ślad co kto i kiedy chciał. Poważnie, to nie dostajecie odpowiedzi bo złe pytania zadajecie. Niestety zwykle biznes nie rozumie problemów technicznych. Jednak mam dobre doświadczenia z UML - chmurki i ludziki w diagramach były zrozumiałe dla biznesu. Zadawaj inne pytania: Jakie są kryteria odbioru? Co jest celem projektu? Czy tak będzie dobrze? Niestety wybacz kolego ale po komunikacie: "TAKA SPRAWA NIE ISTNIEJE, UPEWNIJ SIĘ, ŻE NUMER JEST PRAWIDŁOWY I WPROWADŹ KWOTĘ JESZCZE RAZ!" Popatrzyłbym na kartkę z danymi i ponownie próbował wpisać 50. 80% (albo więcej) kodu to walidacja danych wejściowych. Złe dane nie wchodzą.
Odpowiedz@vezdohan: Nigdzie w historii nie wspomniałem w jaki sposób formułowałem pytania. Pisałem za to, że na zadane pytanie ciężko mi było uzyskać odpowiedź, czy to w formie mailowej, czy nawet w ostateczności słownie. Zbieranie wymagań to dla mnie nie pierwszyzna a i kilkadziesiąt schematów UML w życiu udało mi się spłodzić. Jednak z takim oporem od strony biznesu przy zbieraniu wymagań nie spotkałem się nigdy. Poza tym prawdę mówiąc, w ogóle nie powinienem się tym zajmować, bo nie miałem tego w obowiązkach. Niestety tak jak wspomniałem w historii, analityk biznesowy odszedł kilka tygodni po rozpoczęciu przeze mnie pracy. Co do formularza to już wyżej odpisałem czemu zdecydowaliśmy się na taką formę powiadamiania o błędzie. Jednak widzę, że przyczepiłeś się do walidacji kwoty. A nie zauważyłeś kolego, że w historii wspomniałem, że wykazana kwota zależy tylko i wyłącznie od kontrahenta i nie istnieje algorytm według, którego moglibyśmy stwierdzić, że wprowadzana kwota jest błędna (przynajmniej na podstawie danych jakie otrzymywaliśmy od kontrahenta w imporcie)? Jedynym ograniczeniem było to, że istnieje pula dozwolonych kwot i ten problem rozwiązaliśmy polem rozwijanym. Nie moja wina, że nasza koleżanka żyła w absurdalnym przeświadczeniu, że nie musi wybierać tej kwoty mimo, że całość była jej dokładnie tłumaczona.
OdpowiedzDoskonale rozumiem kolegę. Na etapie założeń zawsze jest największy problem. Klient (w tym przypadku wewnętrzny - biznes) chce bolid formuły 1, a potem pretensje, że po lesie się nim nie da jeździć. IT zawsze obrywa jako ten chłopiec do bicia czy kozioł ofiarny. Dlatego pełna dokumentacja, wszystko na piśmie, nic ustnie, a jeśli ma być ustnie czy na czacie, to zachowywać logi z czata i nagrania z telefonu. Innymi słowy - zawsze mieć dupochron. W biznesie też zdarzają się ogarnięte osoby (pozdrowienia dla Mirka z bankowości), tak samo jak w IT nieogarnięte (mówię to jako osoba z IT). No i plagą jest nieodbieranie telefonów, nieodpisywanie na maile. U jednego z moich poprzednich pracodawców dochodziło nawet do takich absurdów, że zostałem wyznaczony do wykonania pewnego zadania, do którego miałem deadline (i uzależnioną od niego premię) na koniec maja, a dopiero w połowie lipca mogłem cokolwiek zacząć robić, bo tyle czasu czekałem na akceptację projektu przez prezesa.
OdpowiedzKomentarz do wszystkich. To nie pierwsze korpo, w którym pracuję i już dawno się nauczyłem by kategorycznie nic nie robić na gębę. Więc oczywiście przed wdrożeniem zawszę piszę maila podsumowującego, w którym opisuje wszystkie przekazane wymagania, załączam korespondencję i nie wrzucam na produkcje nic zanim nie zdobędę akceptacji od wszystkich zainteresowanych (co również zwykle trwa dość długo, a potem zdziwienie skąd opóźnienia). Mimo to i tak zawsze kończy się gównoburzą pod tytułem "IT znowu zebao", z której zwykle, dzięki w/w mailowi, wychodzimy obronną ręką. W tej historii bardziej chodziło mi o pokazanie lekceważącego stosunku biznesu i jak ciężko cokolwiek od nich wydobyć.
OdpowiedzPracowałem kiedyś na stanowisku, które dla ogólnie rozumianego biznesu (marketing, prawnicy itd) było już obszarem IT (bo SQL raportowe pisaliśmy), ale dla IT było wciąż obszarem biznesu (bo przychodziliśmy z wymaganiami do systemu, no i sami nie mieliśmy haseł do serwerów:). To była dopiero zabawa - z obu stron dostawaliśmy na raz :) A poważniej - nauczyło mnie to, że cholernie trudno jest znaleźć wspólny język dla obu stron. Jak zauważył @kartezjusz2009 w komentarzu - przyszłością jest konsulting w tym obszarze :) Żeby być żywym tłumaczem z jednego na drugi :) Z mojego doświadczenia wynika, że osoby z IT nie potrafią zrozumieć sposobu bycia tych z marketingu - i odwrotnie. IT żyje zadaniowo, konkretnie, technicznie. Marketing buja w obłokach, maniana, damy radę... Nie twierdzę, czy któreś z tych jest złe, które lepsze. Takie postawy są niejako premiowane, wymagane na tych konkretnie stanowiskach. Tylko teraz - jak przekonać inżyniera z IT, że ten wiecznie balujący gość z marketingu wie, czego chce? Jak przekonać człowieka, który bardziej interesuje się, jak będzie wyglądała kampania reklamowa na billboardzie, że te pytania z IT (tak przyziemne - i dla niego nudne), muszą być wyjaśnione, bo inaczej cała kampania pójdzie w piach? Ot, cała sztuka...
OdpowiedzŹle robicie projekty. Poprawnie działające korpo-UI powinno działać tak: 1. wszystkie formularze ostrzegają o potencjalnych błędach i wskazują wartości niezbędne do uważnego wprowadzenia czy przejżenia, ale niczego nie wymuszają - można wprowadzić dowolną bzdurę, 2. rejestruje się autorów wszystkich wprowadzanych zmian (oczywistość), 3. obok stoi system z planami weryfikacji, w którym dodajecie kolejne reguły łapiące to, co uznajecie za błąd oraz potencjalne nieprawidłowości. Razem z idiot-counterem. 4. w razie potrzeby przeczyszczenia powyższych raportów (bo one będą ostatecznie rosły w nieskończoność), albo gdy kierownictwo w swoich działach zrozumie już taką potrzebę, uprawnieni użytkownicy dostają prawo do oznaczania ostrzeżeń jako "OK" albo "wycofaj do szeregowca". Z licznikiem wycofań, dzięki którym kierownik będzie mógł dostać kolejny raport pt. "ranking do pośredniaka".
Odpowiedz@yfa: Gdyby tak się robiło projekty w korpo: - Wiele osób beknie za źle wprowadzone dane - Firma przestanie istnieć po 2 miesiącach - max 8 - dużo zależy od specyfiki - Dalej to już i tak nie ma sensu :)
Odpowiedz