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
Facebook
Twitter
LinkedIn
Jacek Wieczorek

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.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.