Przemyślenia

Teoretyzowanie oraz spekulacja w tworzeniu oprogramowania

Odkąd pamiętam, na biurku znajomego w pracy stał obiektyw.

Fotografia była jedną z jego pasji, więc bardzo często można było go zobaczyć z aparatem w ręku. Czasem fotografował osoby z zespołu, innym razem uwieczniał przedmioty dostępne w biurze. Raz używał lustrzanki z „rybim okiem”, kiedy indziej aparatu w telefonie.

Wielokrotnie zwracałem uwagę na wspomniany obiektyw, jednak nigdy tak naprawdę się mu nie przyglądnąłem. Wyglądał profesjonalnie, posiadał najróżniejsze przełączniki oraz pokrętła, które wprawdzie niewiele mi mówiły, ale upewniały mnie w przekonaniu, że to poważny sprzęt.

Zastanawiałem się czasem, po co tak właściwie trzyma ten obiektyw w pracy? Do głowy wpadały mimowolnie różne scenariusze.

Przecież sprzątaczka może o niego zahaczyć podczas sprzątania przestrzeni biurowej, spadnie i uszkodzi się. Nie martwi się o to?

Sądziłem, że tego typu sprzęt trzyma się w etui, tak aby nie osadzał się na nim kurz. Po co więc stoi i kurzy się na biurku?

Znajomy podczas luźnych rozmów bezmyślnie brali obiektyw do rąk, oglądali go z różnych stron i odkładali na miejsce. Przecież mógł im wypaść z rąk, nie pomyślał o tym?

Wielokrotnie w ciągu ostatnich kilkudziesięciu miesięcy zaprzątałem sobie głowie podobnymi analizami.

Wczoraj sam wziąłem wspomniany obiektyw do rąk. Okazało się, że nie był prawdziwy obiektyw, tylko plastikowy kubek, który wyglądał jak obiektyw.

Dlaczego o tym piszę?

Podobną analogię obserwuję w wytwarzaniu oprogramowania.

Dokładnie zgłębiamy wymagania biznesowe, które za chwilę mogą ulec zmianie. Wybiegamy daleko w przód, zastanawiając się, jakie problemy mogą nas spotkać za pół roku. Przygotowujemy szczegółowe makiety interfejsu graficznego na podstawie naszych wyobrażeń i wizji. Spekulujemy, czego potrzebują nasi użytkownicy. Spędzamy czas optymalizując kod, aby już dziś być gotowym na obciążenie, którego być może nigdy nie doświadczymy. Poświęcamy czas na teoretyczne rozważania, zamiast szybko oddawać mniejsze, gotowe funkcjonalności i przekazywać je do użytkowników w celu otrzymania informacji zwrotnej.

Często okazuje się, że rzeczywistość jest zupełnie inna, niż sobie wyobrażaliśmy. Nasze założenia okazują się błędne. Niepotrzebnie brnęliśmy w ślepe uliczki.

Czy naprawdę nie chcemy dowiedzieć się o tym wcześniej?

Photo by Jakob Owens on Unsplash

Moje najbliższe warsztaty

Warsztaty „Labirynty Scruma” — Warszawa — 26-27 marca 2020
Chcesz dowiedzieć się, jak usprawnić swojego Scruma i omijać najczęstsze pułapki?
Dołącz na 2-dniowe warsztaty i przepracuj ze mną na żywo, jak radzić sobie z pułapkami w Scrumie. 100% praktyki, zero teorii.

Zapisz się na warsztaty >>
Jacek Wieczorek
Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.
Mogą Cię zainteresować poniższe wpisy
Co zrobić, gdy zespoły pracują za wolno?
Czego uczę się od purpurowych pasów w brazylijskim jiu-jitsu?

Zostaw swój komentarz

Twój komentarz*

Twoje imię*
Twoja strona*

This site uses Akismet to reduce spam. Learn how your comment data is processed.