Jak wygląda praca w firmach technologicznych?

Question

Tak się zastanawiam, mimo że troche lat już siedze w tym całym aj ti, jeszcze nigdy nie miałem okazji pracować w typowo "technologicznej firmie", zawsze to były zwykłe firmy... w których dział IT był podstawą przetrwania, ale zawsze produktem było coś innego

Przykładowo bankowość, handel itd

W korpo okazjonalnie zdarzało mi się tworzyć bardziej technologiczne rzeczy (bo był budżet na rozwijanie czegoś autorskiego), przykładowo pogrzebać troche przy autorskim ORM, pogrzebać troche przy autorskiej kolejce MQ, ale zawsze to były poboczne wewnętrzne mini projekty, które były traktowane przez firme jako jej istotny ale mały kawałek - taka ciekawostka która kosztowała miliony i bez której wszystko wybuchnie, ale 99% ludzi w firmie nawet nie wie że to istnieje.

Jestem ciekawy jak to wygląda w firmach, których główną działalnością jest rozwijanie tego typu produktów - firmy w których menadżerowie, albo nawet ludzie z działu sprzedaży, muszą ogarniać technologie, bo produkt jest mocno techniczny i cała firma "w tym siedzi"

Przykładowo bazy danych, chmury, kompilatory itd

Answer 1

Firmy technologiczne często pracują w scrumie. To dobra metodologia gdy zmieniają się wymagania. Codziennie jest daily(stand up). Każdy co wczoraj robił . Co dzisiaj będzie robić i jakie widzimy problemy. Kto może na pomoc. Jest taka osoba jak product owner który ma kontakt z klientem i zarządza backlogiem. Jest samo organizujący team składający z deweloperów i testerów. Są dwutygodniowe sprinty. W których dowozi się taski. Jest taka osoba jak scrum master to ktoś jak kierownik. Rozwiązuje problemy.

Comments

Tak działa prawie każdy dział IT obecnie, nie pytałem o to jak sie pracuje w praktycznie każdym korpo, chodziło mi o sam wycinek "firmy technologiczne", w Polsce rzadko spotykam to określenie, bo u nas takich firm jest dość mało, polskie IT to głównie tworzenie produktów które zmniejszają koszty biznesu z innej branży, lub automatyzują procesy w innej branży. Na zachodzie częściej się mówi o "tech companies"

Teraz pracuje w jednym z większych banków, większość naszej pracy to robienie procesów bankowych, tylko że w komputerze. Mamy kilka swoich rozwiązań technologicznych bo żaden z zaufanych dostawców nie był w stanie spełnić naszych wymagań, ale to są bardziej ciekawostki o których wiedzą nieliczni - są kluczowe, ale 99% pracowników nie musi sobie zdawać sprawy z tego, czy korzystamy z usługi od amazona, ibm, azure, czy to nasza autorska technologia, wzorowana na jednym z gotowców

Nawet programiści, w większości nie muszą wiedzieć że istnieją u nas takie rozwiązania

Ale są firmy, w których właśnie te rozwiązania, są podstawą firmy, bo głównym produktem nie są narzędzia dla innych branż, tylko technologie - przykładowo bazy danych, kompilatory, chmury obliczeniowe, narzędzia wokół continuous integration, observability itp

Jeśli głównym produktem firmy jest dajmy na to baza danych, to wiedzą biznesową jest IT, a nie inna branża, a co za tym idzie, programista w firmie technologicznej jest kimś takim, jak logistyk w firmie logistycznej. Cała firma kręci się wokół tego co jest jego specjalizacją, nawet nietechniczni ludzie z działu sprzedaży, muszą ogarniać specyfike przykładowo baz danych, żeby być w stanie je sprzedawać. Menadżerów "nietechnicznych" praktycznie nie ma, bo w zwykłych firmach menadżerem nietechnicznym jest ktoś, kto ogarnia techniczne aspekty, ale w dziedzinie firmy a nie IT, w banku menadżer nietechniczny to ktoś kto nie zna sie na programowaniu, ale rozumie sposób działania banku, jeśli tym obszarem jest IT, to musi ogarniać tematy

Problem w tym że w Polsce trudno trafić na takie firmy, bo większość to tak jak mówiłem, klepanie produktów dla innych branż, w wielu firmach nawet jest tak, że więcej energii idzie na nauke innej branży, niż robienie "swojej roboty" (stąd słynne DDD, czyli robienie sobie specjalizacji z rozmawiania o tematach z innych zawodów)

---

Co masz do DDD? 

---

Projekty w których DDD ma istotną role, opierają się bardziej na problemach komunikacyjnych, niż problemach technicznych. DDD z definicji jest narzędziem do lepszego rozumienia co trzeba zrobić, jeśli firma sięga po DDD, to znaczy że to taki typ projektu

Wiadomo, prawidłowo wykonane DDD powinno mocno obniżyć problemy komunikacyjne, ale osobiście zawsze widziałem to tylko w narzędziach do wspierania biznesu, z którym trudno jest się dogadać, klepie się crudy, które mają niepotrzebnie skomplikowaną logike, bo ktoś źle wytłumaczył swoje potrzeby... no i te wszystkie spotkania które mogłyby być mailem... najgorzej

W projektach w których rozmawianie od początku działało dobrze, a projekty były rozwijane z głową, nie zauważyłem żeby ktoś w ogóle rozważał wprowadzanie DDD, podobne skojarzenia mam ze scrumem, ale tym książkowym. W projektach które były zarządzane z głową, stosowało się różne techniki, które w jakimś stopniu były inspirowane pojedynczymi elementami scruma, ale nikt tak tego nie nazywał... a jak jakiś zespół nie potrafił ze sobą normalnie rozmawiać i ciągle były jakieś nieporozumienia, to wrzucało się tam oficjalnego scrum mastera, który miał zrobić książkowe ratowanie sytuacji, a zamiast tego nawrzucał spotkań. Najgorzej że zazwyczaj firmy nie robią "książkowego scruma" bo scrum masterzy naczytali sie że trzeba eksperymentować, a ten oryginalny to szkodliwa skrajność. Więc robią własne wersje, w których wszystko co jest ich pomysłem, jest dużo gorsze niż książkowa wersja. Po kilku tygodniach chodzenia na bezsensowne spotkania, zastanawiasz się dlaczego ktoś pomyślał że to spotkanie powinno być o A, przecież dużo mądrzej byłoby gdyby skupiało się na B... później sprawdzasz co autorzy chcieli osiągnąć i jest wyraźnie napisane, że to spotkanie ma być o B, ale scrum master tak bardzo nie chciał robić 1:1 z książki, że nawrzucał głupot. Do tej pory każdego scrum mastera tak wspominam, a zespoły które go nie potrzebowały, miały zazwyczaj bardziej "scrumowe" podejście (zgodne z ideą twórców, a nie z oficjalnymi nazwami spotkań), niż te "używające scruma"

---

W sumie już tutaj to wystarczająco opiasłem

Problem w tym że w Polsce trudno trafić na takie firmy, bo większość to tak jak mówiłem, klepanie produktów dla innych branż, w wielu firmach nawet jest tak, że więcej energii idzie na nauke innej branży, niż robienie "swojej roboty" (stąd słynne DDD, czyli robienie sobie specjalizacji z rozmawiania o tematach z innych zawodów)

Robisz produkt dla ludzi których nie rozumiesz, nie potraficie sie dogadać, firma wymyśla że zaczniecie używać technik DDD do opisywania problemów. Może wtedy w końcu zaczniecie normalnie współpracować

Jeśli była lub jest taka sytuacja, to jest zły znak, który jest typowy dla współpracy między ludźmi z "innych światów". Ale ciekawe jak to wszystko wygląda, jak w firmie tym "głównym światem" jest IT (w większości polskiego rynku wygląda to tak, że IT ma się dostosować do przewodniego tematu, np logistyki albo finansów, a nie odwrotnie - to u nas powstają koncepcje typu DDD)

---

w większości polskiego rynku wygląda to tak, że IT ma się dostosować do przewodniego tematu, np logistyki albo finansów, a nie odwrotnie

Bo jak masz firmę która robi finanse, albo logistykę to ciężko żeby oni słuchali się programistów pod kątem zarabiania pieniędzy.

to u nas powstają koncepcje typu DDD

Dobrze że podpytałem o to, bo z Twojego opisu wynika, że nigdy nie pracowałeś ani z DDD, ani w projekcie, w którym warto byłoby to stosować. Owszem wprowadza to pewne elementy, które wpływają na komunikację, ale głównie skupione jest na prawidłowym podziale systemu. A nie na tym czy manager z developerem są na prawidłowym spotkaniu.

DDD z definicji jest narzędziem do lepszego rozumienia co trzeba zrobić

Do tego co trzeba zrobić masz user storiesy, a DDD powie Ci jak, ale w kontekście szerszego spojrzenia na problem. Trochę mi się też nie spina to co piszesz - koncepcja została wymyślona przez Erica Evansa. 

Problem w tym że w Polsce trudno trafić na takie firmy, bo większość to tak jak mówiłem, klepanie produktów dla innych branż, w wielu firmach nawet jest tak, że więcej energii idzie na nauke innej branży, niż robienie "swojej roboty" 

Jak się obraziłeś na firmy produktowe to pamiętaj że z aplikowaniem do takich firm jak Datastax, AWS, czy Vmware, nie ogranicza Cię nikt oprócz Ciebie samego.

A jak uważasz że czysta wiedza stricte techniczna ma tak duży potencjał do monetyzacji, to zawsze możesz założyć startup.

---

ale głównie skupione jest na prawidłowym podziale systemu. A nie na tym czy manager z developerem są na prawidłowym spotkaniu

To jest polska wizja DDD, nazwiemy inaczej obiekty i będziemy udawać że jest lepiej, bo biznes twierdzi że gadamy głupoty i nie chce przychodzić na spotkania. DDD polega na projektowaniu projektu w oparciu o zrozumienie domeny, innymi słowami, wykonawca rozumie co ma zrobić i dlaczego, dodatkami do OOP sie tego nie osiągnie, mimo że w pewnym stopniu mogą poprawić sytuacje

Tak samo wspomniany scrum, który według polskiej wizji, często jest przeciwieństwem tego co autor miał na myśli

Jak się obraziłeś na firmy produktowe to pamiętaj że z aplikowaniem do takich firm jak Datastax, AWS, czy Vmware, nie ogranicza Cię nikt oprócz Ciebie samego.

Ja tylko zapytałem jak w rzeczywistości wygląda praca w firmach, w których IT jest główną branżą, a nie wsparciem. Jeśli wykonawcy robią coś co lepiej rozumieją, bo jest częścią ich specjalizacji, to nie potrzebują aż tylu dodatkowych technik wspomagających zrozumienie tematu