Dziwna sytuacja w nowej pracy i stres

@katakrowa: masz rację, ale czy czytałeś pierwszego posta w tym wątku?

Używając analogii do budowlańców - idzie taki do klienta, pokazuje zdjęcia, wizualizacje, proponuje rozwiązania, a w odpowiedzi dostaje "weź Pan zrób, żeby było ładnie, nie mam czasu, zresztą zapytaj kogoś innego, ja nic nie powiem".

O ile fachowiec powinien wyjść z inicjatywą - czy to w stosunku do klienta, czy przełożonego, ale jak kilka razy się odbija od ściany, to lepiej sobie dać spokój, szkoda energii na kopanie się z koniem.

Wazna jest zasada wzajemności - można/powinieneś się angażować tam, gdzie to jest potrzebne, docenione, gdzie druga strona też się stara. Jeśli inni mają wywalone (a tak wygląda sytuacja opisana przez OP) to nie ma sensu wychodzić przed szereg. Jak to się mówi - nadgorliwość jest gorsza od faszyzmu.

@katakrowa: ale przecież my mówimy o robolu - programista to robol. Nie wiem dlaczego dorabia się splendor do najbardziej podstawowego stanowiska w firmie .. Dopiero z czasem może od kogoś się nauczyć lepszego fachu. No i tez pytanie kogo chcemy i co robimy. Remontując salon jak weźmiesz Wieśka ze zdjęciami w telefonie to może walnie ci regipsy i halogeny ... Ale jak robisz hotel to masz architekta, projektanta wnętrz, kierownika budowy, roboli...

No i teraz strach robotę zmienić, bo trafisz z jednego bagna gdzie wszyscy olewają do jakiejś następnej toksycznej jaskini, gdzie każdy chce pokazać, że to on jest najbardziej zaangażowany, najambitniejszy, zrobi najwięcej i najlepiej.

Tylko teraz nie wiem, która strona jest bardziej toksyczna. Chyba mimo wszystko ta z podejściem niewolniczym. Nie wierzę, że takie rzeczy co tu czytam może mówić ktoś kto nie zatrudnia innych osób. Wtedy nakręcanie na zapierdzielanie za "dobre słowo" bym zrozumiał. Jeśli nie to tylko się można złapać za głowę.

@katakrowa: Nie w każdej firmie każdy pracownik ma dostęp do całej dokumentacji i wgl do całego produktu np ja u siebie u jednego klienta pomimo próśb od 4 lat nie dostałem (przypominam się tak co pare miesięcy). I tak w sumie to nie wiem dla czego coś ustawiam albo z czym dokładnie się łączę czasami.
Proaktywnym da się być i proponować rozwiązania jeśli wiemy co chcemy osiągnąć tzn co ma być wynikiem końcowym. To tak jakbym ci teraz powiedział napisz wrapper na zawory do wody który będzie odczytywał ich stan zamknięty/otwarty ale nie powiedział po jakim protokole się komunikują, ani nie dał żadnej dokumentacji abyś był w stanie domyśleć się nawet co tam może być oraz jaka zwrotka oznacza, że zawór otwarty. I takie sytuacje w cale nie są rzadkością. I teraz mogę jedynie agresywnie czekać i pingować gości którzy i tak mnie zleją albo "udawać", że pracuję.

cerrato napisał(a):

@katakrowa: masz rację, ale czy czytałeś pierwszego posta w tym wątku?

O ile fachowiec powinien wyjść z inicjatywą - czy to w stosunku do klienta, czy przełożonego, ale jak kilka razy się odbija od ściany, to lepiej sobie dać spokój, szkoda energii na kopanie się z koniem.

ale jak kilka razy się odbija od ściany - z tego co OP pisze to jeszcze nie miał okazji się kilka razy odbić od ściany bo dopiero zaczął tam pracować cytuję: Od listopada dołączyłem do nowego projekt zatem jest całkiem nowy. Do tego dołączył w okresie przedświątecznym a to zwykle dość trudny okres dla menadżerów więc można sobie wyobrazić, że mogli nie mieć dla niego czasu. Co ciekawsze sam napisał, że mu o tym powiedzieli: Po callu z Product Ownerem dowiedziałem się, że to on ma być moim "analitykiem", ale aktualnie jest bardzo zajęty bo ma pod sobą 5 zespołów.

Wazna jest zasada wzajemności - można/powinieneś się angażować tam, gdzie to jest potrzebne, docenione, gdzie druga strona też się stara. Jeśli inni mają wywalone (a tak wygląda sytuacja opisana przez OP) to nie ma sensu wychodzić przed szereg. Jak to się mówi - nadgorliwość jest gorsza od faszyzmu.

O zasadzie wzajemności pisałem tu: Dziwna sytuacja w nowej pracy i stres
Natomiast wracając do tematu. Kolega przepracował nieco ponad miesiąc, nie rozeznał się jeszcze w sytuacji ale:

• już wie, że ProductOwner zły;
• już wie, że Scrum Master zły;
• do tego zwraca uwagę Hindusowi, który zaczął coś robić, i który moim zdaniem bardzo słusznie przestał z nim gadać: teraz się do mnie nawet nie odzywa;
• oburza się o to , że ktoś go poprosił o odrobinę samodzielności: Opowiedziałem mu sytuację, a on zaczął do mnie korpomową mówić, że muszę być pro-aktywny, że muszę zacząć szukać, pytać.

Niby chłopina doświadczony bo Programuję już zawodowo od 4 lat w Javie i pierwszy raz z czymś takim się spotykam ale wygląda na to, że jednak jeszcze mało widział.
Brzydko podsumowując, chu...a zobaczył i go...no wie ale już chce się zwalniać i szukać nowej pracy: Doradźcie mi co robić w takiej nowej sytuacji? Jak rekruterzy patrzą na takie przerwy w CV?

@cerrato - sam nie wiem może jestem zbyt surowy w ocenie jegomościa ale nie sądzę.

Jeżeli masz chociaz minimalne możliwości, możesz spróbować zrozumieć o co chodzi o dopytać już konkretnymi pytaniami "to my mamy płacić, czy nam mają płacić", "kwota z wartości zakupu, czy każdy po 2zł?". Koniecznie mailem, koniecznie z twoim pryncypałem w CC, żeby nikt ci później nie powiedział, że "no może zadanie nie było w 100% zdefiniowane, ale co zrobiłeś, żeby uzyskać taką informację?". W dodatku masz sekretarkę, to deleguj zadanie pingowania PO na nią.

ScrumMastera możesz ochrzanić, że wziął zadanie Heisenberga na sprint, na przyszłość wspólnie z zespołem odmawiać szacowania takich zadań, aż będzie w nich chociaż tyle informacji, żeby było wiadomo czy da się to zrobić w tydzień, rok, czy wcale. Jeżeli się opiera i dalej chrzani głupoty, to na daily mówisz to, co chce usłyszeć.
Jeżeli to co wyżej nie pomoże, a dobrze płacą, robisz tak, żeby zamknąć zadanie np. piszesz taki kawałek kodu"

return 2;

Dajesz do testowania, a sobie w tym czasie douczasz się z tego co jest chociaż trochę przydatne, wymyślasz co powiesz na daily i szukasz nowej roboty, bo jednak po 2-3 latach się zorientują, ze niewiele jest zrobione.

@katakrowa Rozumiem twoje podejście i w części sytuacji faktycznie to się sprawdza. Ale żeby coś zaproponować, musisz mieć chociaż minimalne wymagania. Jak nie powiesz temu budowlańcowi, że chcesz mieć dom, a nie płot, to będziecie tak tymi zdjęciami żonglować dość długo wykluczając altankę na śmietnik, wychodek, garaż itp. OP ma z tego co widzę raczej skromne doświadczenie i wygląda to na dość niestety częstą sytuację, gdzie zatrudnia się programistów po taniości, klient ma projekt w d... (PO w 5 zespołach na raz, naprawdę ma co robić), a kontraktornia jest zadowolona tak długo, jak długo jest prowizja z faktur. Czyli klient ma wyrąbane, kontraktornia ma wyrąbane, osoby odpowiedzialne za prowadzenie projektu mają wyrąbane, a jakiś świeżak na samym dole łańcucha pokarmowego ma się przejmować i stawać na rzęsach, żeby uzupłenić to czego nie zrobili ludzie odpowiedzialni za kształt projektu, a na koniec zostać winnym tego spektakularnego sukcesu? Sam jestem przeciwnikiem "będę kopać od tego kołka aż do wieczora, a jak ktoś mi nie dał łopaty, to będę robić to wolniej, zamiast powiedzieć, że potrzebuję łopaty", ale jednak są granice. Sam miałem parę takich projektów/zadań w życiu:

• Zaprojektuj uniwersalny system do analizy finansowej w banku. Pomimo licznych pytań nie udało się wydobyć nic więcej. Ostatecznie zrobił to jakiś "hindus" w sposób opisany wyżej w poście. Firma padła jakiś czas później, bo okazało się, że na rynku jednak trzeba robić coś więcej niż podpisywać umowy i próbować wystawiać za nie faktury.
• Zaimplementuj 5 warstwę danych. PO nawet nie wiedział co to jest ta 5 warstwa. Udało się dokopać do tej tajemnej wiedzy u pana "jestem niezastąpiony w tym projekcie". Ale praktycznie wszystkie zadania były tak robione, że PM coś opowiadał (nie wiedząc co), PO zapisywał to w backlogu, jak przyszło co do czego, to programista biegał i szukał podstawowych informacji "o co chodzi". Na szczęście udało się zmienić projekt.
• Zrób coś. Tutaj to "coś" zrobiłem, zacząłem się dopytywać o więcej zadań i nagle się okazało, że klient ich nie zdefiniował (poza maleńkimi, kosmetycznymi zmianami). Po miesiącu zamknęli cały projekt. Trochę wtedy żałowałem, bo chodziło o niszową technologię, specjalistę na wczoraj i stawka była powiedzmy lvl. Cobol (ale bez Cobol'a).

Piszesz, że programiści mają zapewnione warunki pracy jak arystokracja, a zachowują się jak przygłupi pomocnicy murarza, którym trzeba ciągle mówić skąd dokąd mają zanieść cegły i czasami faktycznie tak jest. Ale nie dostrzegasz drugiej strony - większość z nas spokojnie olałaby te owocowe czwartki, piłkarzyki, fify i inne duperele w zamian za dobrze zdefiniowaną pracę, porządne narzędzia i komfort w postaci poświęcania 80% czasu pracy na to, na czym się naprawdę znamy.

piotrpo napisał(a):

@katakrowa Rozumiem twoje podejście i w części sytuacji faktycznie to się sprawdza. Ale żeby coś zaproponować, musisz mieć chociaż minimalne wymagania. Jak nie powiesz temu budowlańcowi, że chcesz mieć dom, a nie płot, to będziecie tak tymi zdjęciami żonglować dość długo wykluczając altankę na śmietnik, wychodek, garaż itp.

OP dostał zadanie - API płatności dla systemu XYZ - to nie jest całkowity brak informacji. Niestety OP nie pochwalił się tym jakie pytania zadawał i czy w ogóle włożył choć odrobinę energii w zdobycie jakiś danych (w co bardzo wątpię). Przypuszczam, że tylko pisał e-maile o zbyt ogólnikowym tickecie i tyle... Podejrzewam też, że z własnej inicjatywy nawet nie dowiedział o jaki system XYZ chodzi ani o jakie płatności.

OP ma z tego co widzę raczej skromne doświadczenie i wygląda to na dość niestety częstą sytuację, gdzie zatru>dnia się programistów po taniości, klient ma projekt w d... (PO w 5 zespołach na raz, naprawdę ma co robić), a kontraktornia jest zadowolona tak długo, jak długo jest prowizja z faktur. Czyli klient ma wyrąbane, kontraktornia ma wyrąbane, osoby odpowiedzialne za prowadzenie projektu mają wyrąbane, a jakiś świeżak na samym dole łańcucha pokarmowego ma się przejmować i stawać na rzęsach, żeby uzupłenić to czego nie zrobili ludzie odpowiedzialni za kształt projektu, a na koniec zostać winnym tego spektakularnego sukcesu?

Uważam, że w pierwszym miesiącu pracy dla samej przyzwoitości wypada się choć odrobinę wykazać samodzielnością.

Sam jestem przeciwnikiem "będę kopać od tego kołka aż do wieczora, a jak ktoś mi nie dał łopaty, to będę robić to wolniej, zamiast powiedzieć, że potrzebuję łopaty", ale jednak są granice.

Niestety takiego podejścia nie pochwalam, jednak każdy ma swoją filozofię i sprawdzone sposoby na życie:-)

Sam miałem parę takich projektów/zadań w życiu:

• Zaprojektuj uniwersalny system do analizy finansowej w banku. Pomimo licznych pytań nie udało się wydobyć nic więcej. Ostatecznie zrobił to jakiś "hindus" w sposób opisany wyżej w poście. Firma padła jakiś czas później, bo okazało się, że na rynku jednak trzeba robić coś więcej niż podpisywać umowy i próbować wystawiać za nie faktury.
• Zaimplementuj 5 warstwę danych. PO nawet nie wiedział co to jest ta 5 warstwa. Udało się dokopać do tej tajemnej wiedzy u pana "jestem niezastąpiony w tym projekcie". Ale praktycznie wszystkie zadania były tak robione, że PM coś opowiadał (nie wiedząc co), PO zapisywał to w backlogu, jak przyszło co do czego, to programista biegał i szukał podstawowych informacji "o co chodzi". Na szczęście udało się zmienić projekt.
• Zrób coś. Tutaj to "coś" zrobiłem, zacząłem się dopytywać o więcej zadań i nagle się okazało, że klient ich nie zdefiniował (poza maleńkimi, kosmetycznymi zmianami). Po miesiącu zamknęli cały projekt. Trochę wtedy żałowałem, bo chodziło o niszową technologię, specjalistę na wczoraj i stawka była powiedzmy lvl. Cobol (ale bez Cobol'a).

No właśnie...

Piszesz, że programiści mają zapewnione warunki pracy jak arystokracja, a zachowują się jak przygłupi pomocnicy murarza, którym trzeba ciągle mówić skąd dokąd mają zanieść cegły i czasami faktycznie tak jest. Ale nie dostrzegasz drugiej strony - większość z nas spokojnie olałaby te owocowe czwartki, piłkarzyki, fify i inne duperele w zamian za dobrze zdefiniowaną pracę, porządne narzędzia i komfort w postaci poświęcania 80% czasu pracy na to, na czym się naprawdę znamy.

Obawiam się, że niestety mniejszość a nie większość.

@katakrowa: no ale tutaj sobie chyba sam zaprzeczasz: z jednej strony piszesz że koleś jest od listopada (czyli w domyśle - jest nowy, nic nie wie, niczego nie umie, nie został wdrożony), a potem oczekujesz od niego, że ma wykazać inicjatywę i samodzielnie pchać temat na przód. To chyba tak nie działa. Inicjatywę możesz wykazać jak już znasz firmę, znasz projekt, znasz wymagania, procedury i całą otoczkę. A tutaj OP stara się wdrożyć, tylko jest spławiany. Nie dostał konkretnych wymagań, a na prośby kontaktu nie dostaje sensownych odpowiedzi. Stąd przekonanie że ProductOwner zły i tak samo SM ;)

A najśmieszniejsze jest to, że ogólnie się zgadzamy i mamy takie samo podejście - można być szeregowym pracownikiem przy taśmie (nieważne, czy tao taśma w fabryce czy taśmowe klepanie kodu pod wytyczne przełożonego), ale lepiej jest byś osobą aktywną, zaangażowaną i samodzielną. Jedynie chyba mamy zgrzyt w ocenie tej konkretnej sytuacji.

Niestety OP nie pochwalił się tym jakie pytania zadawał i czy w ogóle włożył choć odrobinę energii w zdobycie jakiś danych (w co bardzo wątpię). Przypuszczam, że tylko pisał e-maile o zbyt ogólnikowym tickecie i tyle... Podejrzewam też, że z własnej inicjatywy nawet nie dowiedział o jaki system XYZ chodzi ani o jakie płatności.

Jest taka możliwość, ale równie dobrze to Ty teraz dopowiadasz. Jeśli jednak masz rację i tak było, to rzeczywiście: duża część winy jest po stronie autora wątku, który trochę czeka na konkretne wytyczne jak królewna w wieży na konia z białym rycerzem ;)

w pierwszym miesiącu pracy dla samej przyzwoitości wypada się choć odrobinę wykazać samodzielnością.

W pierwszym miesiącu pracy, jeśli nie jest to praca polegająca na obsłudze wyważarki do opon, to ogarniesz kto jest szefem, gdzie jest ekspres, o której jest przerwa na obiad i z której strony budynku pracują pracownicy, a gdzie klienci ;) Serio - wdrożenie się w coś skomplikowanego (a jednak praca w jakimś korpo i pisanie czegoś bardziej skomplikowanego niż pasjans) to nie jest kwestia 3 dni. A w szczególności, gdy (bez wnikanina z czyjej winy) za bardzo na wsparcie z góry nie można liczyć.

cerrato napisał(a):

@katakrowa: no ale tutaj sobie chyba sam zaprzeczasz: z jednej strony piszesz że koleś jest od listopada (czyli w domyśle - jest nowy, nic nie wie, niczego nie umie, nie został wdrożony), a potem oczekujesz od niego, że ma wykazać inicjatywę i samodzielnie pchać temat na przód.

Gdzie tu sprzeczność? Nic nie uczy lepiej niż próba samodzielnego zdobycia wiedzy i rozeznania się w sytuacji. Jak chłop będzie czekał aż duch święty go wdroży w tajniki projektu to kiepsko to widzę.

To chyba tak nie działa. Inicjatywę możesz wykazać jak już znasz firmę, znasz projekt, znasz wymagania, procedury i całą otoczkę. A tutaj OP stara się wdrożyć, tylko jest spławiany. Nie dostał konkretnych wymagań, a na prośby kontaktu nie dostaje sensownych odpowiedzi. Stąd przekonanie że ProductOwner zły i tak samo SM ;)

Nieprawda, sam miałeś lub wciąż masz firmę i wiesz, że każdy nowy klient to jak nowy projekt i nowe wdrożenie. Nowi ludzie, nowe systemy... wszystko nowe.
W takiej sytuacji brak inicjatywy z Twojej strony równa się brak zlecenia. Zatem nie zgadzam się z Twoją opinią że trzeba znać projekt aby wykazać inicjatywę.
Owszem jakąś ogólną wiedzę trzeba mieć bo jeśli tej zabraknie to faktycznie pozostaje błądzić jak we mgle...
Co do spławiania... to odpowiedzią jest jego zaledwie miesięczny staż w tej firmie i okres świąteczny. Wg mnie nic nadzwyczajnego większość firm ma pod koniec roku dużo pracy.

A najśmieszniejsze jest to, że ogólnie się zgadzamy i mamy takie samo podejście - można być szeregowym pracownikiem przy taśmie (nieważne, czy tao taśma w fabryce czy taśmowe klepanie kodu pod wytyczne przełożonego), ale lepiej jest byś osobą aktywną, zaangażowaną i samodzielną. Jedynie chyba mamy zgrzyt w ocenie tej konkretnej sytuacji.

Właśnie o to chodzi. Niestety mój świadomie wybrany zawód, który kiedyś był kojarzony z ludźmi samodzielnie uczącymi się, kreatywnymi (być może wówczas jeszcze klepiącymi kod w piwnicy) i potrafiącymi zrobić cuda, dziś coraz częściej zastępowany jest obrazkami które stoją z tym w niemal całkowitej sprzeczności.

Niestety OP nie pochwalił się tym jakie pytania zadawał i czy w ogóle włożył choć odrobinę energii w zdobycie jakiś danych (w co bardzo wątpię). Przypuszczam, że tylko pisał e-maile o zbyt ogólnikowym tickecie i tyle... Podejrzewam też, że z własnej inicjatywy nawet nie dowiedział o jaki system XYZ chodzi ani o jakie płatności.

Jest taka możliwość, ale równie dobrze to Ty teraz dopowiadasz. Jeśli jednak masz rację i tak było, to rzeczywiście: duża część winy jest po stronie autora wątku, który trochę czeka na konkretne wytyczne jak królewna w wieży na konia z białym rycerzem ;)

Wg mnie dokładnie taki obraz wyłania się z tytułowego postu.

w pierwszym miesiącu pracy dla samej przyzwoitości wypada się choć odrobinę wykazać samodzielnością.
W pierwszym miesiącu pracy, jeśli nie jest to praca polegająca na obsłudze wyważarki do opon, to ogarniesz kto jest szefem, gdzie jest ekspres, o której jest przerwa na obiad i z której strony budynku pracują pracownicy, a gdzie klienci ;) Serio - wdrożenie się w coś skomplikowanego (a jednak praca w jakimś korpo i pisanie czegoś bardziej skomplikowanego niż pasjans) to nie jest kwestia 3 dni. A w szczególności, gdy (bez wnikanina z czyjej winy) za bardzo na wsparcie z góry nie można liczyć.

Przez miesiąc nie dowiedzieć się zupełnie nic na temat "API płatności do konkretnego systemu"?
Nie rozumiem tej niemocy. Wg mnie to przejaw niechęci i lenistwa.

@katakrowa:

katakrowa napisał(a):

Przez miesiąc nie dowiedzieć się zupełnie nic na temat "API płatności do konkretnego systemu"?
Nie rozumiem tej niemocy. Wg mnie to przejaw niechęci i lenistwa.

I tu dochodzimy do sedna :) Mało widziałeś.
Jak już tak hipotytezujemy a co jeżeli API jest własnościowe a dostęp do niego mają licencjonowani użytkownicy ? A OP nie ma tej licencji ?

Mówisz o tym wszystkim jakby to wyglądało "wpiszę sobie w google api do systemu XYZ i dostanę odpowiedź" sorry ale to mało kiedy tak działa.
Jak do czegoś nie ma otwartego dostępu tylko zależy to od osoby X i Y a oni cie zlewają to chociaż by skały srały to nic nie ruszysz z tematem.

Gdzie tu sprzeczność? Nic nie uczy lepiej niż próba samodzielnego zdobycia wiedzy i rozeznania się w sytuacji. Jak chłop będzie czekał aż duch święty go wdroży w tajniki projektu to kiepsko to widzę.

4 dni temu zdałeś prawko, więc masz tu klucze od magazynu. Znajdź adres naszej filii w Hiszpanii, weź 4 agregaty (na magazynie jest ich prawie 500, ale na pewno będziesz wiedział o które chodz), wynajmij jakiegoś przedłużonego Transita (nie mamy konkretnej firmy od wynajmu, improwizuj) i zawieź je do Pedro w Madrycie :P

wiesz, że każdy nowy klient to jak nowy projekt i nowe wdrożenie. Nowi ludzie, nowe systemy... wszystko nowe.

Tak, ale to jestem ja (czy ktokolwiek inny) kto jest stary (chodzi o staż w firmie, nie PESEL), kto zna procedury, firmę, wie co i jak robimy, co można zaoferować, ile potrwa realizacja zamówienia, co może wyskoczyć podczas pracy. Wiemy, jaki jest wzór umowy z klientem, wiemy kto może na niego nanieść zmiany, wiem jak mogę podziałać z ceną, ile osób temat ogarnie itp. Czyli - to wszystko się opiera na latach doświadczenia, które firma posiada. Celowo piszę "firma" a nie "ja" albo kolega - bo tutaj chodzi głównie o procedury, zrealizowane tematy służące jako baza do działania, posiadane doświadczenie itp. Czyli to wszystko, czego OP nie posiada w kontekście tej nowej firmy. Wiadomo, że jakby był wymiataczem z 20-letnim doświadczeniem to pewnie by część rzeczy wziął na intuicję, część wymarudził telefonami co pół godziny itp. Ale jednak weź pod uwagę, że OP jest raczej na początku swojej przygody.

Właśnie o to chodzi. Niestety mój świadomie wybrany zawód, który kiedyś był kojarzony z ludźmi samodzielnie uczącymi się, kreatywnymi (być może wówczas jeszcze klepiącymi kod w piwnicy) i potrafiącymi zrobić cuda, dziś coraz częściej zastępowany jest obrazkami które stoją z tym w niemal całkowitej sprzeczności.

Wiesz... jak my zaczynaliśmy to nie było w ogóle czegoś takiego jak internet. Korzystało się z książek w stylu "Turbo Basic" albo "Delphi 2 - kompendium", analizowało się gotowe kody (kto dzisiaj jeszcze wie, czym jest/był SWAG? http://www.retroarchive.org/swag/index.html), korzystało z helpów dostępnych po wciśnięciu F1. Teraz wszystko jest inne - jak nie umiesz samodzielnie określić czy dana liczba jest parzysta to ściągasz bibliotekę isOdd (albo even, nie pamiętam). Na wszystko jest gotowe rozwiązanie w necie, trzeba tylko wiedzieć skąd skopiować i gdzie wkleić. I nawet nie chcę powiedzieć, że teraz jest gorzej. Bo po prostu - jest inaczej: zamiast kreatywnego drążenia tematu, liczy się szybkie dostarczenie gotowego produktu. To, w połączeniu z coraz więszą ciapowatością młodego pokolenia - wychowanego bezstresowo, politycznie poprawnie, w poczuciu że każdy z nich jest pępkiem świata powoduje, że takie dinozaury jak Ty czy ja coraz trudniej się odnajdują w obecnych realiach :(

Wg mnie dokładnie taki obraz wyłania się z tytułowego postu.

Ja akurat inaczej go odebrałem. Zresztą - jakby OP miał wywalone to by nie zakładał tego watku. A jednak ten brak feedbacku jakoś go boli, co sugeruje, że może jednak jest w nim jakiś potencjał ;)

Przez miesiąc nie dowiedzieć się zupełnie nic na temat "API płatności do konkretnego systemu"?
Nie rozumiem tej niemocy. Wg mnie to przejaw niechęci i lenistwa.

Tutaj chciałem napisać to samo co @Schadoow, więc po prostu napiszę +1 ;)
Po prostu - nie znamy konkretów, więc może ta sytuacja równie dobrze wynikać z podejścia OP, który wysłał parę maili i uznał, że jak nie odpisują to siedzę i dłubię w nosie (szkoda, że mam tylko 2 dziurki, bo tyle czasu że i 50 by się ogarnęło ;) ), ale być może temat jest trudy/jakieś API własnościowe które nie ma dokumentacji na GH, dane powinien dostarczyć ktoś z firmy, ale jeszcze nie znaleźli na to czasu/ochoty. Za mało wiemy, żeby oceniać. Wiem, że Ty (ja pewnie także) bym albo ich męczył aż bym dostał (albo zaczął robić coś innego), ale nie każdy jest tak totalnie zajebisty jak my :D

@swiezak_rek: pracujesz jako Java Software Engineer.

Ja też. Czytam też tu wszystkie wpisy i z roku na rok odnoszę coraz większe wrażenie, że w polskich warunkach Java i Software Engineer to taka świnka morska. Ani świnka, ani morska. To taka pozycja a'la złota rączka. Taki pan Stefan, którego znasz z dzieciństwa. Najlepiej po przebytych szkoleniach z DDD, event stormingu, komunikacji nieantagonizującej, bycia proaktywnym, sprzedaży marki osobistej, zegarków... Żeby na koniec udawać przed samym sobą, że ten CRUD, którego implementujesz w przerwie między kolejnymi spotkaniami, to nie CRUD :-)

Owszem, trzeba być proaktywnym, jednakże trzeba też szanować swoją pracę, czas, zdrowie psychiczne i znać granice swoich kompetencji. Czyli łączyć bycie proaktywnym z byciem asertywnym. Jeśli męczysz PO, a on nie jest zainteresowany rozwojem produktu, którego jest właścicielem, to wygląda na to, że biznes nie ma na to priorytetu albo ktoś kto był tym tematem zainteresowany już w tej firmie nie pracuje. Czytaj: palimy pieniędzmi w piecu mając zespół, który kiedyś był potrzebny, a teraz nie jest. Ewentualnie biegamy z niezaładowanymi taczkami, bo kto szybciej biega, jest bardziej zaangażowany.

Gdybym był waszym szefem to bym zwolnił:

• @swiezak_rek za to, że siedzi i nic nie robi zamiast robić research, commitować do jakiegoś repozytorium z przykładami, rozwijać dokumentację z propozycjami implementacji i porównaniem kilku rozwiązań oraz raportować o tym na publicznych kanałach i na spotkaniach,
• Hindusa za bycie pasywno agresywnym, gość wykonuje pracę, która nikomu nie jest potrzebna i ucieka od konfrontacji,
• Scrum Mastera za to, że mówi innym co mają robić w tonie managera zamiast skupić się na swojej pracy czyli usuwaniu blokerów, zbieraniu feedbacku i organizacji cyklicznych spotkań z Product Ownerem, żeby ogarnąć backlog, a także za to, że ignoruje pasywno agresywne zachowanie Hindusa,
• Product Ownera za to, że nie dopilnował, żeby stworzyć roadmapę i nie pracuje z developerami nad rozwijaniem backlogu,
• Product Managera za to, że nie zatrudnił Leada, który by wszystko sklejał do kupy, a zamiast tego zatrudnił czterech nikomu niepotrzebnych devów oraz SM, którzy przepalają pieniądze na najwidoczniej nikomu niepotrzebny produkt,
• @cerrato za to, że jest boomerem i nie widzi jak stary system edukacji był patologiczny i skupiał się tylko na eliminacji najsłabszych jednostek, a nie na tym, żeby maksymalizować ilość osób z przyzwoitym wykształceniem.

@katakrowa: dałem tam lajka bo się z kilkoma wpisami zgadzam, jednak jest też druga strona. Powiedzmy, że masz zespół: testerzy, programiści w tym architekt, analityk i PO. Serio myślisz, że powiesz np. Juniorowi z 6msc stażem weź się domyśl i improwizuj?

To po co jest Analityk? Rozumiem, że projekty różnie się toczą i czasami rozwiązanie wychodzi od programistów, bo np. klient nie ma wizji, jednak od tego powinien być analityk, który wyciąga takie pomysły od programistów, analizuje je i pokazuje klientowi. Tylko w tym przypadku analiza jest często z architektem.

Ogólnie programiści powinni móc się domyślić pewnych rzeczy i np. móc powiedzieć na daily - ale z nas debile, przecież to w tym i tym kontekście jebnie. Musimy to przemyśleć.. Jednak wymaganie też tego od osób zaczynających pracę czy w ogóle karierę nie zawsze jest dobrym pomysłem. Co z tego skoro go zapytasz jak on nie zna jeszcze dobrze np. domeny w której powstaje projekt?

@katakrowa: niezły z Ciebie naganiacz z jakiejś kontraktowni chyba. Jako klepacz kodu mnie interesuje by po groomingu i planowaniu sprintu wejść w Jirę i wybrać taska, który jest wolny. Klepacze kodu, jak to określasz, to nie menadżerowie, żeby coś samemu ustalać albo wychodzić z inicjatywami.
Chyba, że czuję się związany z produktem, który robię to wtedy mogę zacząć o nim myśleć więcej. Ale na pewno nie w takim środowisku jaki OP przedstawia.

Do OP: albo robisz szybki wylot już, albo przeciągasz tę sytuację jak się da i jednocześnie robisz jakiś inny projekt albo rozwijasz swoją biblioteczkę.

Pinek napisał(a):

swiezak_rek napisał(a):

Zwróciłem mu uwagę, że to zachowanie prowadzi tylko do jeszcze większego bałaganu, bo sam sobie merguje kod, w ogóle nie robi PR tylko wrzuca wszystko na Mastera, no to się obraził i teraz się do mnie nawet nie odzywa.

Tak trzeba żyć

@swiezak_rek, masz w zespole pozycję team leadera. Proces wytwarzania softu to jego odpowiedzialność. Może pozwala Hindusowi na takie praktyki, bo widzi, że jest w praktyce najsilniejszym devem.
Spytaj się o zdanie twojego TL. Bardzo możliwe, że to ma sens - mały zespół, eksperymentalny projekt, etc. Jeśli team leader nie ma zdania, albo nie wie, jak wymusić posłuszeństwo, to się pakuj.

1. Piszesz maila do analityka ze swoim managerem w CC z prośba o doprecyzowanie zadania - kontekst, DoD, wiadomo - podstawy.
2. Dajesz feedback 1-1 swojemu managerowi, co nie gra, co powinno zostać naprawione. Na pewno zabrakło co najmniej onboardingu i wsparcia analitycznego. Nie obwiniaj, pokaz fakty, czego brakuje zespołowi. Możesz się odwołać do faz formowania zespołu - do „performing” jeszcze daleko i to nie z Waszej winy.
3. Szukasz nowej pracy. Chyba, że (a) manager powie Ci, że liczył się z tym i przestawi swój plan na najbliższe miesiące (każdy manager musi mieć plan) oraz (b) chce Ci się w to wchodzić. Raczej mało prawdopodobne jednak, że nie rozpadnie Ci się zespół, bo koledzy sobie pójdą.

Jestem zwolennikiem podejścia „produktowego” i proaktywnej postawy inżynierskiej, ale z przysłowiowego g**** piany nie ubijesz ;)

TL;DR Wygląda na to że nie macie nie tylko team/tech leada ale również eksperta.
Możesz sam spróbować być takim ekspertem. Pewnie wyjdzie ujowo i będziesz się potem za to wstydził ale lepszy rydz niż nic.
W międzyczasie szukaj nowej pracy.
Ludzie w PHPie takie rzeczy ogarniają w pojedynkę, gdy trzeba zintegrować jakieś płatności ze sklepem.
Czasem z trudnych projektów wychodzą ciekawe doświadczenia.
A tego scrum mastera możesz traktować jako taki check-point - skoro udaje że nic nie widzi to przestań się nim stresować i zacznij go traktować jako taki mail proxy (bo tak się zachowuje) do którego wrzuca się komunikaty i nie oczekuje odpowiedzi.

Akurat niedawno byłem tech leadem w projekcie bramki do pewnego systemu płatności więc coś tam mogę podpowiedzieć.

1. Czy to jest API do systemu płatności zaimplementowanego wewnątrz firmy czy na zewnątrz?
2. Zakładając że to drugie:
   2.1 Zdobądź wszelką oficjalną dokumentację API systemu płatności
   2.2 Zaplanuj listę wspieranych operacji (jeśli nie masz od klienta to potem potwierdź z nim)
   2.3 Zdobądź wymagania wydajnościowe (100 transakcji na miesiąc to zupełnie inna architektura niż 100 tys. transakcji na godzinę).
   2.4 Zaplanuj testy
   2.4.1 Zaplanuj testy jednostkowe i integracyjne (happy path, błędy wejścia, błędy wykorzystywanych systemów, błędy storage itd)
   2.4.2 Zaplanuj testy wydajnościowe
   2.4.3 Dowiedz się czy będzie CI/CD
   2.5 Udostępnienie Swagger UI pomaga w testach osobom trzecim
   2.6 Wykorzystuj Swagger UI jako formę dokumentacji, powinno być stale aktualne, informuj wszystkich dookoła jak to wygląda i jak to można testować samemu
   2.7 Dbaj o monitoring błędów (np. Graylog) tak żeby szybko wychwycić nowe na środowisku testowym
   2.8 Dowiedz się czy dostawca systemu płatności umożliwia dostęp do kont testowych, jeśli tak to używaj ich tak wcześnie jak się da, to jedyna pewna forma testu e2e

katakrowa napisał(a):

Ludzie z innych branż bardzo źle mówią o programistach i spotykam się z tym coraz częściej ale całkowicie ich rozumiem. Choć sam jestem programistą to uważam, że postawy reprezentowane przez autora tematu, który przez 10 dni roboczych wysłał jedynie kilka e-maili oraz kolegi powyżej są pokazywaniem myślenia na poziomie pomocnika przy betoniarce - ale spoko nikt nie zabroni. Wygląda na to, że mnie jakoś inaczej wychowano i każde wyzwanie warto podejmować, spróbować samemu, przy okazji zdobyć jakąś wiedzę lub doświadczenie... Ale oczywiście można też mieć "wywalone" bo najwyżej zmieni się pracę:-) Po ch... dawać coś od siebie skoro wypłata co miesiąc i tak taka sama.

Lol, dopóki to nie jest
a) moja firma albo
b) nie mam udziału w zyskach
(czytaj: właściciel pływa w pieniądzach a ja nie)

To pozwól mi jednak mieć wywalone. Oczywiście zachowując godność polskiego przedstawiciela elity narodu i klasy wyższej (czyli programisty).

Na marginesie, co mnie obchodzą ludzie z innych branż xd.

No ta, ludzie z innych branż coraz częściej bardzo źle mówią o programista.

I kurna vice versa. Coraz częściej w takich jamuszsoftach programiści są dręczeni przez półgłówkow, czy to POsow, którzy uważają że ich zadaniem jest tylko odbiór ficzerow, czy to analityków, którzy są w stanie tylko zredagować myśli biznesu, bez żadnej analizy systemu i obecnego flow, czy to biznesu bo myślą że jak pracujemy w sprintach edżajl, to oni mogą ciągle mówić, że nie wiedzą co chcą, bez nawet podstawowego zarysu. I potem dostaje programista taskiem na ryj z pustym opisem i ma odwalać copperfielda i jakieś czary z tego zrobić.

Zazwyczaj jak czytam posty katakrowy, to mi się nóż w kieszeni otwiera, bo przypomina mi się mój szef z pierwszego januszsoftu.

Płacić poniżej stawek rynkowych i wymagać od ludzi jakby robili na 2 etaty na różnych stanowiskach.
Niektórym się serio wydaje, że to lata 90 i o pracę trzeba walczyć?
Jak praca jest ujowa, nie ma porządku, a programista ma orać i dopraszać się o wszystko, to oczywiście że się zwolni.
Jak idę do PO, ten odsyła mnie do analityka, analityk do Leada, a Lead do PO, to uwierzcie że pracować się odechciewa każdemu.

To niech Janusz się męczy i ogarnie swój burdelik.

Zazwyczaj jak czytam posty katakrowy, to mi się nóż w kieszeni otwiera, bo przypomina mi się mój szef z pierwszego januszsoftu. Płacić poniżej stawek rynkowych i wymagać od ludzi jakby robili na 2 etaty na różnych stanowiskach.
Niektórym się serio wydaje, że to lata 90 i o pracę trzeba walczyć?

Powiedz mi, na jakiej podstawie uznałeś, że Krowa jest typowym Januszem, co tylko chce ciągnąć ile się da i płacić możliwe minimum, do tego każe się całować po stopach że w ogóle dał ci szansę pracowac?

Dlatego, że jest wymagający - zarówno od siebie, jak i pracowników? Bo oczekuje zaangażowania, samodzielności i inicjatywy? Bo nie popiera podejścia na zasadzie "jestem tylko bezmyślnym narzędziem w rękach mojego cudownego szefa, który ma mnie prowadzić za rączkę"?

Za mało sobie dopowiedziałeś, dej wincyj.

Prowadzeniem za rączkę jest powiedzenie komuś czym mniej więcej ma się zająć, to właśnie definicja januszostwa, to że ktoś tak myśli :D

Chyba że jesteście szkoły - zatrudnić studenta, posadzić przed kompem, liczyć na cuda :D

Bo widzę, że dla niektórych programista to czarodziej, co się go posadzi przed pustym opisem i sam będzie latał 8h i się pytał każdego (mimo że nawet nie wie kogo, bo tego też mu nikt nie powie - a niech się domyśli), a jak tego nie robi, to jest "bezmyślnym narzędziem w rękach swojego szefa".

Pomijając rzucane w siebie gównem; ja bym do tego podszedł w ten sposób:

W grudniu nigdy nic się nie dzieje (bo nikogo nie ma), ale jednocześnie dzieje się wszystko (bo trzeba kończyć rzeczy a nikt nie planował braku ludzi, mimo że każdy wie że w grudniu nikogo nie ma). Dopiero od jutra tak naprawdę zaczyna się praca po drugim tygodniu grudnia.

Zwykle wydevelopowanie jakiegoś API wynika z jakiejś potrzeby biznesowej, nie z widzimisię PO, więc niezależnie od jego wizji i priorytetów tak czy siak ktoś inny coś wie o tym problemie. Podejdźcie do PO na godzinę i spytajcie się skąd w ogóle ta idea i jakie są osoby kontaktowe w firmie które możecie męczyć. Maile, wiki, powerpointy, cokolwiek.

Jeśli osób kontaktowych nie ma i PO nie chce wam poświęcić czasu, to szukacie sponsorów tego projektu - ktoś wam za to płaci. W korpo na pewno poszedł jakiś mail z ładnymi slajdami i kluczowymi osobami w projekcie, jak to w korpo. Jak sponsor się dowie że PO ma wywalone na ten projekt i że palony jest jego budżet, to PO może nabrać motywacji, zwłaszcza przed typowym okresem oceny rocznej.

Jeśli osoby kontaktowe się znajdą, to możecie z nimi pogadać i wrzucić przynajmniej na jakieś wiki opis tego co oni sądzą że jest w scope tego projektu. Pewnie jak porozmawiacie z N osobami, to dostaniecie 2N pomysłów, ale to już jest start. Być może to API jest podobne do istniejących, albo je rozszerzające - o to też wypytać - PO/developerzy tamtego projektu może wiedzą o co chodzi. Z tego możecie skleić jakąś wizję tego kto tego używa, na cholerę, w jaki sposób, jaki macie ruch, jakie dane są wam potrzebne. Na 90% coś wam się popierniczy, ale nie szkodzi. Z tego robicie mocno wczesny draft rozwiązania (bez szczegółów - use casey i z grubsza zarys tego co ma robić i czego jeszcze nie wiecie)

Najlepszy sposób na poznanie dobrej odpowiedzi na pytanie, w tym "co my mamy robić", to publiczne podanie złej odpowiedzi - jak podejdziecie do PO z tym draftem to na 80% wytknie wam błędy zamiast olania was. Robicie od nowa taniec zgadywania wymagań (dopytujecie ludzików biznesowych o wymagania, dorzucacie albo wywalacie coś, zdobywacie kontakty do osób które mogą coś więcej wiedzieć) i wracacie do PO. Rinse and repeat dokąd nie macie czegoś co można potencjalnie zaimplementować (jako proof of concept).

W ten sposób poznacie trochę domenę i będziecie mieć coś. czy to jest idealna sytuacja? Nie. Czy jest lepsza niż siedzenie na dupie? Zdecydowanie tak, dla was, dla projektu i dla kontraktorni.

szczerze dostajac słabo (albo w ogole) opisanego taska, dodaje komentarz 'need more info' i przerzucam na product ownera - to jego rola
co sie mam stresowac ;)

a jak juz dochodzi do idiotycznych przepychanek, to poruszam temat np. 'user stories' - bo skoro ani jedna strona, ani druga strona nie wie o co biega - to moze czas na podszlifowanie obecnych metod/workflow

Ja Was spróbuję pogodzić - istotnie szeregowy dev nie musi wymyślać sobie zadań i ich specyfikacji. Ale może. Czasem coś z tego wymyślania ciekawego może wyjść, a na pewno można to potraktować jako swoisty rozwój i w ten sposób nauczyć się rzeczy, które pozwolą w przyszłości awansować na wyższy szczebel hierarchii, niż tylko przeklepywanie tego, co ktoś jasno i bez wątpliwości opisze. Ale rzeczony dev musi tego chcieć i widzieć w tym jakiś sens i korzyść dla siebie.

Jednocześnie w obecnej sytuacji na rynku żaden dev nie musi w takiej pracy tkwić i zgadzam się, że może lepiej, żeby nie tkwił na siłę, bo owszem - to ciągnie całość rynku w dół. Nic nie wyjdzie dobrego z tego, że robotnicy budowlani próbują zaprojektować dom za projektanta, mając w dodatku wytyczne pt. "dom ma być mieszkalny" i co do zasady takich sytuacji należy unikać.

@katakrowa - choć ogólnie wiem, co masz na myśli, to jednak nie oczekuj tego jako normy. Po pierwsze - w tym układzie i tak żadnego rezultatu z takiego oddolnego wymyślania projektu nie będzie. Po drugie - nie każdy szeregowy programista do tego się nadaje i nie należy tego na siłę wymagać.

abuwiktor napisał(a):

Jednocześnie w obecnej sytuacji na rynku żaden dev nie musi w takiej pracy tkwić i zgadzam się, że może lepiej, żeby nie tkwił na siłę, bo owszem - to ciągnie całość rynku w dół. Nic nie wyjdzie dobrego z tego, że robotnicy budowlani próbują zaprojektować dom za projektanta, mając w dodatku wytyczne pt. "dom ma być mieszkalny" i co do zasady takich sytuacji należy unikać.

@katakrowa - choć ogólnie wiem, co masz na myśli, to jednak nie oczekuj tego jako normy. Po pierwsze - w tym układzie i tak żadnego rezultatu z takiego oddolnego wymyślania projektu nie będzie. Po drugie - nie każdy szeregowy programista do tego się nadaje i nie należy tego na siłę wymagać.

Zaryzykowałbym stwierdzenie, że od poziomu senior takiej postawy powinniśmy już wymagać (proaktywność, ale również asertywność). Junior/mid może jeszcze nie, ale powinno mieć to przełożenie na stawki. W momencie, kiedy junior dev zarabia 3-4x tego co jego rodzice, mamy taką patologię, jaką mamy :) Podobnie jest przecież na rynku remontów wykończeniowych (chyba tak to się nazywa), gdzie nie ma dostępnych ekip.

Przy czym powtórzę, że jak jest w sytuacji OPa to dokładnie nie wiemy… dużo wskazuje tez na to, że środowisko jest mocno przeciętne. Także na nie wiem, czy w zespole brakuje kogoś z seniority, czy rzeczywiście tam jest tak słabo.

Widzę, że tu gruba dyskusja się zrobiła, więc pozwolę sobie przekleić moje dwa grosze

Jak odróżnić regulara od seniora [...] (lub też często jak odróżnić 20-latka od 30-latka)

OK, trafiliście do projektu gdzie, jak w bardzo wielu przypadkach w korpo, nie ma leada, BA ani PO (tzn. może gdzieś tam jest, ale jak zwykle nie ma na nic czasu), a wasz Scrum Master jak to zbyt często bywa nie wie, że to jest jego działka, żeby zadbać o to, aby team mógł pracować (czyli np. zdobyć wymagania lub znaleźć kogoś kto te wymagania znajdzie).

Co robi regular, który jeszcze nie ogarnia, że taka sytuacja jest mega częsta w dużym korpo, co oczywiście jest karygodne i nie powinno mieć miejsca, ale guess what - jest jak jest i wypadałoby coś z tym zrobić zamiast być kolejną osobą, która rozkłąda ręce:
-napisze maila i da kogoś w CC
-może ewentualnie do kogoś raz zadzwoni
-nie zwróci nikomu uwagi, że chyba SM powinien ruszyć dupę lub wprost powiedzieć, że nie jest SM-em dla tego teamu
-będzie siedział i się stresował, z jednej strony, że nic nie robi, z drugiej, że może jednak powinien coś zrobić, ale nie wie co
-będzie rozważał zmianę pracy po 2 miesiącach, zastanawiając się jak to będzie wyglądać w CV i zapominając, że za chwilę może trafić na taką samą sytuację
-pójdzie na wykop płakać jaki management jest słaby (bo jest) i jaka słaba to firma (kontynując słąbość tej firmy pod względem ogarniania się)

Co robi chad senior, który takich sytuacji miał już na pęczki i przyzwyczaił się, że korpo molocha nie zmieni:
-pisze maila
-dzwoni po 3h, bo go rozsierdza, że nikt nie odpowiedział
-dzwoni na następny dzień rano przypomnieć o swoim istnieniu
-przy braku reakcji pyta do kogo może uderzać bezpośrednio jeśli pseudo PO nie ma na to czasu
-na standupie politycznie poprawnie stara się wytłumaczyć SM, że to jednak jest jego działka, ale łaskawie robi za niego robotę; SM, który jest SM-em z definicji, a jest tak naprawdę managerem ogarniającym kilka zespołów na raz, nowych klientów i sprawy HR-owe jest zadwolony jak każdy manager, że palcem nie musi kiwnąć, za co oczywiście przeprasza, ale jednak zapamięta to na przyszłej rozmowie o kasie oraz przemyśli czy chad senior nie powinien w zasadzie być leadem zespołu
-kontynuuje uprzejme bombardowanie PO dwa razy na dzień, aż PO nie ma w końcu ochoty na zbywanie go i kieruje go w dobrą stronę
-dzieli się z regularami z zespołu tym czego się dowiedział i stawia się w pozycji ich leada, bo tak

Żeby nie było, byłem tam, miałem 27 lat, bałem się chwycić za telefon, chciałem dostać taska, nie miałem ochoty, żeby mi ktoś dupę zawracał... co ja mówię, nie miałem ochoty z kimkolwiek rozmawiać, bo rozmawianie z kimś, do tego może po angielsku, mnie stresowało

@WyjmijKija: Ale wiesz, że za "bombardowanie" kogoś mailami dorobisz się jedynie esklacji ze strony tego PO, że przeszkadzasz mu w pracy a jak dobry gracz to że go "napastujesz".
Założyłeś, że po drugiej stronie jest miekka faja która będzie tańczyć jak mu zagrasz a nie wytrawny gracz zaprawiony w takich bojach :).

Ten watek to teoria vs praktyka w duzym uogolnieniu. Juniorzy/midy masturbuja sie do cqrs ddd bdd mma na konferencjach, rozkminiaja cykle GC i algorytmy najoptymalniejsze, a pozniej plask na ryj od rzeczywistosci "intergrejt api" i elo :D. Podejrzewam ze integrejt api to wiekszosc rzeczywistosci korpo klepu, been there done that.

I faktycznie mozna roznica w tym ze komus placa 15k vs 30k jest taka ze ten za 30 tego integrejta zrobi?