Allegro Tech Meeting 2021

Two weeks ago, Allegro (the company I’m working at) for the first time hosted an open for public Allegro Tech Meeting (ATM). ATM are our annual conference, where all people working on the technology side of Allegro, meet and share knowledge. This year we decided to run an open-for-public edition of ATM. All product managers, developers, UX designers etc got a chance to listen and discuss our technology, experience and stories behind products.

The conference had several separate paths

  • Software
  • Infrastructure
  • UX & Product
  • Machine Learning & Big Data
  • Security
  • Leadership & Learning

I had an awesome opportunity to be a part of ATM and present in the UX&Product path on the second day of the conference. I shared experience and knowledge about the complexity of human decision making and how this affects product management and technology. You can view the recording of this presentation: ATM 2021, Day 2: UX & Product – Blask

All path recordings can be found at the Allegro Tech channel.

Reactivation … again

A long time ago, I had a blog. This blog. Posted some notes, some rants and thoughts. Summing up something about fifteen articles published. For some reason (life, new jobs, etc) I totally forgot about updating my blog. Almost exactly six years have passed, since the last publication. And a lot had happened. New industry (e-commerce) new job and role (sort of, but about this more in some next time). But that zombie state is no more. Here comes resurrection from dead and:

  • more review of books
  • more rants and new insights about the current state of the IT industry and especially that fuzzy border between the weird kingdom of technology and the outer world
  • new language. Yep, all my next posts will be in English

So, stay tuned. More to come.

Przypadki użycia – przykład

 

W jednym ze wcześniejszych wpisów 1, przedstawiłem moje uwagi dt. przypadków użycia. Na końcu obiecałem, że dodam jeszcze trochę praktycznych przykładów. I właśnie tym chciałbym się dziś zająć. Chciałem, aby przedstawione przykłady były „wzięte z życia”, dlatego są oparte na pewnym projekcie, który realizowałem. Przedstawię w skrócie problem, tak aby można było uchwycić o co w nim chodzi, a jednocześnie opis nie był zbyt angażujący. W oparciu o te informacje, przeprowadzę skróconą wersję analizy wymagań, efektem której będzie przypadek użycia, zapisany w formie szkicu Czytaj dalej Przypadki użycia – przykład

  1. Poniższy wpis przeleżał dłuższy czas w poczekalni na ostateczny szlif, dlatego pojawia się dopiero teraz. Spodziewajcie się dalszych wpisów wyciągniętych z archiwum. Trochę się tego zebrało. ↩

Lista życzeń

Projekty informatyczne, przynajmniej te prowadzone w naszym kraju, cierpią często na trudną przypadłość którą określam jako „lista życzeń”. Dotyczy to przede wszystkim projektów, które mają być realizowane przez zewnętrznych dostawców a przez to muszą mieć zdefiniowany w sposób formalny zakres. W założeniu – tego typu oficjalny opis powinien definiować przedmiot zamówienia w sposób ścisły i na tyle szczegółowy, że możliwe będzie oszacowanie pracochłonności i kosztów. To w teorii. Niestety w praktyce, często tego rodzaju dokumenty pt. Opis Przedmiotu Zamówienia nie są zbyt szczegółowe, a nawet więcej – ich forma i treść są problematyczne.

Czytaj dalej Lista życzeń

Ilustrowana instrukcja oddychania w 10 krokach

Znacie to? Dostajecie do zapoznania się Bardzo Ważną Dokumentację ver. 20 Kluczowego Systemu. Otwieracie dokument, patrzycie się na ilość stron jakie zostały wyprodukowane („no, no… 150 stron, to musi być masa informacji”) . Więc z zapałem zabieracie się do czytania. I..? I porażka – okazuje się, że dokument jest tak naprawdę pusty – połowa „treści” to rysunki, które nic nie wnoszą, reszta to wygenerowany z automatu opis tych rysunków, najczęściej całkowicie pusty lub też zaprezentowane diagramy są banalne, informacje się powtarzają. Nie dość że nie ma z nich żadnego pożytku to jeszcze wprowadzają chaos informacyjny: zaciemniają inne, potencjalnie ważne dane, powodują że w masie nieistotnych danych ginie to co jest kluczowe.

Czyli tym razem będzie o jakości dokumentacji. O tym co można zrobić źle pisząc dokumentację, ze wskazaniem na możliwe przegięcia – tak co za dużo to niezdrowo. I o tym jak sobie poradzić z tym tematem.

Czytaj dalej Ilustrowana instrukcja oddychania w 10 krokach

Nasz TLA jest dobry na wszystko

Dziś będzie o chorobie zwanej przeze mnie toolizmem informatycznym 12. Czyli o cudownych rozwiązaniach.

Czytaj dalej Nasz TLA jest dobry na wszystko

  1. od tool – czyli narzędzia; oczywiście inne branże nie są wolne od tej przypadłości, jednak to najbardziej u nas się objawia, bo w końcu wszystko w informatyce kręci się wokół narzędzi – robimy narzędzia, przy pomocy narzędzi, zrobionych innymi narzędziami ↩
  2. tak, tak, ten -izm dobrze się wam kojarzy ↩

Węgierski diagram

Zdarzyło mi się uczestniczyć ostatnio w dyskusji o kierunkach rozwoju zawodowego analityka. Dyskusja, jak to dyskusja na forum internetowym, nie doprowadziła do żadnych sensownych wniosków, tylko swobodnie odpłynęła. Jednym z kierunków, którym podążyli dyskutanci, były rozważania o wyższości BPMNa nad UML (a właściwie nad czymkolwiek innym). BPMN jest ostatnio w modzie, więc szybko ujawniła się grupa wiernych fanów i kibiców, rzucająca całą litanią zalet tego języka. Dziwnym trafiem prawie wszystkie brzmiały bardzo podobnie do marketingowych haseł, reklamujących BPMNa w różnego rodzaju whitepaperach. W szczególności spodobała mi się takie hasło:

BPMN jest łatwy, prosty i intuicyjny. Każdy go rozumie.

Czyli bierzemy pierwszego lepszego człowieka z ulicy (dobra, niech będzie – dowolnego klienta dla którego robimy system informatyczny), rzucamy mu dowolny diagram BPMNa z procesami, a on na to: „Aha – tak o to chodzi, ten proces idealnie obrazuje wszystkie niuanse naszego sposobu pracy”. BPMN odwalił za nas całą robotę – narysowaliśmy diagramik i wszystko już dla każdego jest jasne i oczywiste: doskonałe zrozumienie wymagań i oczekiwań klienta, doskonałe i pełne zrozumienie produktu który wykonawca dostarczy. Analityczna nirvana.

Czytaj dalej Węgierski diagram

Jaką metodykę pan woli?

Ostatnio, na pewnej rozmowie, w pewnej ważnej sprawie, dostałem takie właśnie pytanie: „A jaką metodykę pan woli, agile czy ciężką?”. Chyba jednak nie udzieliłem oczekiwanej odpowiedzi, bo powiedziałem mniej-więcej: „a taką, która działa”. Co prawda, moja wypowiedź była trochę dłuższa i trochę bardziej łagodna, ale sens był właśnie taki. Dziś więc będzie o tym co jest lepsze, agile czy ciężkie metodyki, a w zasadzie o tym, że takie porównanie nie ma sensu bez określenia kontekstu w którym działamy.

Czytaj dalej Jaką metodykę pan woli?

Reaktywacja

Nawet nie zauważyłem kiedy minęło 2,5 roku od ostatniej publikacji. Troszkę się ten blog przykurzył, jednak postaram się go odświeżyć, wrzucić materiały które siedzą od dawna w poczekalni i utrzymywać w miarę stabilne tempo publikacji. W najbliższym czasie będzie m.in o tym która metodyka prowadzenia projektów jest najlepsza, kontynuacja tematu przypadków użycia, BPMNie.

Biznesowe przypadki użycia

Przez książki, tutoriale, blogi dotyczące inżynierii oprogramowania przewijają się różne epitety 1, określające przypadki użycia. W szczególności dwa określenia pojawiają się często – systemowe lub biznesowe przypadki użycia. Przeważnie jednak, autorzy używający tych sformułowań nie wspominają co właściwie przez nie rozumieją. Niestety, podobnie jak w przypadku wielu innych pojęć IT, tak i tu każda osoba używająca tego określenia może mieć coś innego na myśli. Jak więc odróżnić systemowy od biznesowego i kiedy ma sens stosowanie takich określeń? Czytaj dalej Biznesowe przypadki użycia

  1. w znaczeniu przymiotnik opisujący cechę ↩