6 komentarzy

  1. Dawid pisze:

    Hej.
    Zgadzam się z tym co napisałeś. Według mnie obecnie programiści są za bardzo oderwani od klienta i jest to duży problem. Z drugiej strony, widziałem również takich purystów kodu, którzy mogliby ten przysłowiowy button pisać tydzień, bo znaleźli coś, co jest minimalnie lepsze i trzeba teraz już przepisać całą aplikację. We wszystkim należy mieć umiar.
    Bardzo dobry artykuł, będę tutaj wpadał częściej 🙂

    • Patryk pisze:

      Cześć. Dzięki! To takie moje luźne przemyślenia w tym temacie. To dobrze, że ktoś, choć po części, się ze mną zgadza. To oznacza, że nie wyssałem tego z palca i mi się nie ubzdurało :-).

      Co do tych purystów kodu – lubią się nazywać perfekcjonistami, choć i tacy też są.

  2. szarotka pisze:

    Aktualnie pracuję jako programista, rozwijając oprogramowanie dla firmy, dla której pracuję.
    W mojej firmie jest świadomość, że pracujemy po to, żeby automatyzować procesy w firmie, porządkować je i robić to dla użytkowników, którzy korzystają z systemu. Jesteśmy dość blisko tzw. biznesu. Mamy szereg spotkań, gdzie dyskutujemy pomysły i propozycje rozwiązań. Czasem przychodzi produkt owner z jakimś pomysłem i ja jako developer mówię, że ten sam efekt można osiągnąć używając gotowej funkcjonalności i tylko odpowiednio konfigurując, tym samym oszczędzając czas i pieniądze, znajomość systemu jest istotna.
    Generalnie takie podejście jest naprawdę fajne, bo to co robimy, robimy dla kogoś i ma to realną wartość dla firmy.

    Ma to też swoje minusy, dużo spotkań, czasem presja na szybką realizację kluczowej w danej chwili zmiany. Dlatego to też trzeba odpowiednio wyważyć.

    Oczywiście w firmie nie każdy programista ma takie podejście jak ja, są tacy co by chcieli tylko programować, a czego dotyczy funkcjonalność czy czego chcą odbiorcy, ich nie obchodzi (mówią to wprost). I generalnie widzę, że tacy programiści nieraz są mocni technicznie i tworzą dobry kod, ale często coś temu rozwiązaniu brakuje, przez to, że programiści są oderwani od rzeczywistości a rzeczywistość jest inna od idealnych rozwiązań (użytkownicy inaczej korzystają z funkcjonalności niż my zakładamy, dane w bazie są niekompletne itp). Rozwiązania powinny być projektowane z myślą o potrzebach i realiach w jakich działa system.

    Niemniej rynek nie ceni, na stanowisku developera, umiejętności szybkiego merytorycznego ogarniania systemu, analizy tego co się robi czy ma to sens i nie wpływa na n innych rzeczy itp. Są to wartości niepoliczalne. Stąd też nie dziwię się, że co mądrzejsi myślą o sobie i swoim rozwoju umiejętności technicznych zamiast o tym, by to co robią miało sens.

    • Patryk pisze:

      Przyznam, że trochę Ci zazdroszczę miejsca pracy :). Wszystko zależy od dojrzałości/dorosłości firmy (nie mówię o „wieku”). Co do ostatniego akapitu, uważam, że najbliższe lata zweryfikują to podejście. Na zachodzie widać trend odwrotny, rozwój AI, BigData, Cloud Computing’u sprawia, że najcenniejsi są ci którzy rozumieją dziedzinę (domenę). Programowania można się nauczyć raz-dwa. Dodatkowym argumentem za odwrotem tego trendu, jest wdrażanie przez organizacje modelu Turkusowego (tu odsyłam do podcastu Krzyśka Kempińskiego – https://porozmawiajmyoit.pl/poit-025-organizacje-turkusowe-i-self-management/)

  3. Kat pisze:

    Myślę, że ten tekst to tak naprawdę prztyczek w nos i „wake-up call” dla obu stron: dev teamu i tzw. biznesu.
    Tylko właśnie, czy to są dwie strony, czy przypadkiem nie powinien to być jeden wspólny front? 🙂

    Rozpisywali się na ten temat ludzie dużo mądrzejsi ode mnie, rozpoznawani w branży, nowość to to nie jest, ale jak widać temat wiecznie żywy 🙂 Z jednej strony Spolsky i jego koncepcja warstwy abstrakcji między programistami a klientami, a z drugiej Cagan, który twierdzi, że dev powinien być jak najbliżej użytkownika, a „wykorzystywanie” programistów tylko do kodowania to korzystanie z zaledwie połowy ich potencjału, bo jako eksperci od danego systemu, aplikacji, potrafią dać duży wkład w kierunek ich rozwoju. Co jest też moim osobistym przekonaniem 🙂

    Wydawać by się mogło, że w dobie agile’a i leana w każdym domu i zagrodzie, hype’u na Management 3.0 i „turkusowość”, to już są dylematy, które powinniśmy mieć dawno za sobą, ale posty i komentarze takie jak powyżej pokazują tylko, jak młoda jest „kultura” IT w Polsce i jak wciąż mało zwraca się uwagę na odpowiedni mindset i umiejętności miękkie, takie jak praca zespołowa, nastawienie na rozwiązywanie problemów, empatyzowanie z użytkownikiem itp. Wciąż jest deficyt programistów na rynku, więc patrzy się głównie na skille techniczne. Podczas gdy na świecie standardem staje się bazowanie na tzw. culture fit, bo firmy zdają sobie sprawę, że sposób myślenia trudniej zmienić, niż doszkolić kogoś technicznie.

    Jeśli chodzi „stronę” dev teamu, to dość jasne jest, że kod jako taki nie stanowi wartości dla użytkownika (poza baaaardzo specyficznymi przykładami, gdy to kod sam w sobie jest produktem), a produkt nie jest zbiorem ficzerów tylko rozwiązań problemów odpowiadających na potrzeby, braki i bolączki (i ew. zachcianki ;)) prawdziwych osób. Piękny kod, który nie będzie używany, nie jest nikomu potrzebny. Perfekcjonizm przydaje się w zespole – dobrze mieć taką perspektywę na podorędziu – ale nie odklejenie od rzeczywistości, czy to z własnego wyboru czy takie, na które jest się skazanym. Patrząc w ten sposób, product manager/owner, który uważa się za alfę i omegę i nie korzysta z wiedzy swojego zespołu tylko zleca im robotę, jest równie odklejony od rzeczywistości, co taki programista-Mickiewicz. To jest recepta na produkt mijający się z rzeczywistością, wiele rozczarowań i szukania winnych. To jest coś, co sensowny zespół powinien zdiagnozować sam u siebie zawczasu, jeśli ma choć odrobinę motywacji (to jest zupełnie inna dyskusja) – dev team powinien wyraźnie sygnalizować, że jeśli jest odcinany od informacji, to pisze coś dla wszystkich i dla nikogo, że robi dużo zbędnych założeń, że estymaty są na granicy sensowności (guesstimates :)) – jest po prostu nieefektywny. Product manager/owner powinien wciąż walidować swoje założenia dot. problemów, jakie produkt ma rozwiązywać (bo tak – to są niemal zawsze założenia, prawdy absolutnej nikt nie posiadł, trzeba empirycznie do tego podejść :)) i pozwolić dev teamowi proponować rozwiązania, a nie siedzieć jak w manufakturze i implementować ficzery od sztancy.

    Ficzer factory i projektoza, to wciąż żywe choroby software house’ów, nawet tych co chwalą się, jak bardzo są zwinne. Ale już za dużo gadam, mogę to pociągnąć w osobnym komentarzu 🙂

    Fajny post, daje do myślenia. Miło się czytało. Sukcesów w nowym roku!

    • Patryk pisze:

      Powiem tak, czytałem kilka razy aby zrozumieć i przyjąć Twój punkt widzenia. Widać, że rownież masz sprawę przemyślaną, ale co najważniejsze doświadczenie w tej kwestii. Tak się teraz zastanawiam… wychodzi na to, że TO jest po prostu trudne.
      To jest trudne rekrutować odpowiednich ludzi, biorąc pod uwagę nie tylko technical skill.
      To jest trudne wymagać od innych szerszej perspektywy, lub chęci ogarnięcia tej szerszej perspektywy, spojrzenia dalej niż czubek nosa. Zwłaszcza, że nie każdy chce.
      To wymaga czasu i cierpliwości, a efekty będą po latach. Niestety nie każdy widzi w tym wartość. Również jakość pracy, czy produktu nie u każdego stoi na podium.
      Jakby nie było, firmy ze sobą konkurują, niektóre jakością, inne ceną, jeszcze inne tempem dostarczania zmian. Wszystko ma swój koszt.
      Fajnie, że napisałaś. Zmuszasz do refleksji :-). Zaglądaj częściej!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *