Thursday, February 7, 2019

Krótkie oświadczenie

Oświadczam, że z bloggera znikają mi czasem komentarze i nie mam bladego pojęcia dlaczego.
Tak więc sorry, taki mamy klimat.

Lekcja architektury prosto z Castoramy

Odkryłem w Castoramie fakturomaty. Wow!

Zawodowa ciekawość zmusiła mnie do skorzystania, a zawodowy talent unieruchomił fakturomat już w trakcie pierwszego użycia.

Najpierw pojawił się komunikat "Archiwizowanie paragonu", a następnie "Błąd wystawiania faktury" czy coś w podobie.

Poprosiłem o pomoc, Pani otworzyła dolne drzwi fakturomatu i oto widok jak na zdjęciu:


Okazało się, że fizyczne ArchiwumParagonów, które chyba niechcący wyłożyłem, to kartonowe pudło do którego wpadają paragony po przeskanowaniu przez czytnik. Sama esencja KISS jak zgaduję.

Pani pogrzebała w archiwum, feralny paragon się znalazł (heurystyka "mniej więcej po kwocie") i po ponownym przetworzeniu fakturomat wypluł fakturę.

Wniosek praktyczny: Jeśli user zgłasza, że Twój soft ma kłopoty z działaniem, upewnij się, że pod pięknym interfejsem, nie śmigają aby kartonowe pudła :P (może to OK, a może nie)

Ogromny szacunek dla personelu Castoramy, który skutecznie uniemożliwiał mi zrobienie porządnej dokumentacji fotograficznej z miejsca zdarzenia :D

Wednesday, January 30, 2019

Programiści NIE mają problemu z komunikacją

Taka rozkminka.

Jakieś 17 lat temu dałem sobie wmówić, że programiści mają problem z komunikacją i powinni się szczególnie reformować w tym zakresie. Ostatnimi czasy pewne wydarzenie rzuciło mi nieco inne światło na tę kwestię, a było to tak...

Prowadziłem rozmowę z jednym programistą, który jak tylko mógł bronił się przed zesłaniem na szkolenie z komunikacji. Uparcie twierdził, że on nie potrafi się komunikować, nigdy nie potrafił, nie chce i nie będzie.

No, nie zmuszam - pomyślałem i już miałem zakończyć grilowanie biedaka, gdy moją uwagę przykuła pewna rzecz - obrączka na palcu.
- Masz żonę? - zapytałem
- Mam.
- Hmmm, ale to siłą ją zaciągnąłeś przed ołtarz? Porwałeś z domu?

Okazało się, że luba mojego rozmówcy dobrowolnie i bez żadnego przymusu dała się namówić na zamążpójście. Zdziwiło mnie to, po tym jak odmalował swoje kompetencje komunikacyjne.

- A macie dzieci, jeśli wolno spytać...?
- Mamy. Dwie córki.


I znów zdziwienie. Wyobraź sobie, że ten programista nie tylko rozmawia ze swoimi córkami, ale i bierze czynny i aktywny udział w ich wychowaniu.

Nie wiem jak Tobie, ale mnie po tym dialogu wszystko się przestało kleić. No, do cholery jeśli ktoś potrafi przekonać drugą osobę do zawarcia formalnego związku, to chyba potrafi się komunikować, nie?

Poza skończoną liczbą przypadków szczególnych, jeśli inżynier żyje w związku albo utrzymuje kontakty z rodziną, znajomymi, czy chociażby wspólnotą mieszkaniową, to spokojnie można założyć, że posiada podstawowy set kompetencji społecznych, które zapewniają mu przetrwanie.

Tak więc, ten cudowny kontrprzykład na zawsze pogrzebał tezę, że programiści nie potrafią się komunikować. O co więc chodzi z tą łatką, którą się nam przykleja? Otóż przyczyny leżą zupełnie gdzie indziej.

Uporządkowanie i praca głęboka

Programiści preferują pracę według określonego porządku. Wszystko to, co zaburza ten porządek jest postrzegane negatywnie.

Praca wykonywana przez inżynierów ma najczęściej charakter głęboki (chodzi o naturę rzeczy, nie o ocenę tej pracy). Oznacza to, że wymaga ona operowania dużą ilością szczegółów, dużego skupienia oraz skrupulatności.

Można zaryzykować stwierdzenie, że programowanie to nadawanie pewnego porządku danym, które są nieuporządkowane.

Odcięcie się od bodźców zewnętrznych sprzyja takiej pracy. Rozpraszacze i wrzutki z boku ją zaburzają. Łamanie porządku pracy jest odbierane jako bałagan. Powoduje też nieprzyjemne doznania w ciele. Serio!

Lejek sprzedażowy

Programiści są umiejscowieni niemal na samym końcu lejka sprzedażowego. Natomiast biznes jest niemal na samym początku tego lejka.

Aby do programistów trafił jeden temat do realizacji, po stronie biznesowej należy "obrobić" tych tematów z pięćset. Z tego powodu w biznesie czas upływa subiektywnie szybciej niż w IT - więcej się dzieje. W IT rozdłubujemy jedną rzecz do ziarnistości atomu, bo tak trzeba, aby ją porządnie zrobić.

Coś niespodziewanego

- O w mordeeeee! Nie przeczytaliśmy zapytania do końca! Zaoferowaliśmy coś, czego nie mamy!

Nie ma co się czarować, gdy się dużo dzieje, takie błędy się zdarzają. Będąc na górze lejka, biznes ma dużą ekspozycję na tego typu błędy. Niestety będąc na dole lejka, IT ma z takich błędów za***te koszty.

Bounded Context

Gdy pierwszy raz wybrałem się do mechanika z moim Suzuki Maruti '92, usłyszałem "bla, bla, blaa, osiemset trzydzieści", gdzie Maruti kosztował 1,3k.

Gdy grupa ludzi pracuje razem, zaczyna wykształcać się lokalna gwara branżowa. Upraszcza ona komunikację w grupie, utrudnia poza grupą.

Wnioski praktyczne

No, dzięks, że wytrwałeś aż do tego momentu, bo wnioski ww. refleksji są dość ciekawe:

  1. Trudności komunikacyjne na lini BIZ-IT nie wynikają z tego, że ktoś (IT) jest mniej usklilowany miękko. Wynikają przede wszystkim z "architektury organizacyjnej", w której ludzie zostali umieszczeni
  2. Analizowaną w poście "architekturę organizacyjną" można nazwać "klient-usługodawca". Jak długo będziemy ustawiać ludzi w relacji klient-usługodawca tak długo będą występować problemy komunikacyjne. I choćbyśmy ludzi przetrenowali miękko na wszystkie strony - nic to nie da. Problemy komunikacyjne są wpisane w relację klient-usługodawca, a nie w naturę poszczególnych ludzi
  3. Z programistami jest wszystko w porządku - ich umiejętności miękkie są w normie. Zapewniam, że gdy programista idzie do mechanika samochodowego doświadcza tych samych trudności komunikacyjnych co osoba z biznesu odwiedzająca programistę
  4. Należy zmienić priorytety. Zamiast wałkować 101 technikę udzielania feedbacku, należy reorganizować struktury współpracy tak, aby pozbyć się relacji klient-usługodawca
  5. work in progress