„To tylko chwila”
Każdy, kto pracuje przy tworzeniu lub utrzymaniu strony internetowej, aplikacji czy systemu, zna ten komunikat.
„Możecie tylko zmienić ten przycisk?”
„To naprawdę drobna poprawka.”
„Proszę tylko przesunąć ten element.”
„Może da się to zrobić szybko?”
„To chyba 5 minut roboty?”
I czasami rzeczywiście jest.
Czasami zmiana koloru przycisku zajmuje kilka minut. Czasami poprawienie literówki wymaga jednego kliknięcia. Czasami developer otwiera kod, patrzy, zmienia jedną linijkę i po sprawie.
Problem polega na tym, że nie każda zmiana, która wygląda na małą z perspektywy użytkownika, jest mała z perspektywy systemu.
A jeszcze większy problem pojawia się wtedy, gdy takich „małych zmian” jest kilkanaście, kilkadziesiąt albo kilkaset w miesiącu. Wtedy zaczyna się dziać coś ciekawego.
Firma może mieć wrażenie, że właściwie nic dużego nie zamawia. A jednocześnie zespół IT spędza znaczną część czasu na realizacji właśnie tych drobnych zadań.
I tutaj pojawia się pytanie: Ile naprawdę kosztuje jeden przycisk „Poprawcie to szybko”?
Zacznijmy od prostego przykładu
Wyobraźmy sobie, że dział marketingu wysyła do software house'u wiadomość:
„Hej, potrzebujemy tylko zmienić tekst na przycisku. Zamiast „Sprawdź ofertę” powinno być „Poznaj ofertę”. To mała rzecz, proszę tylko zrobić szybko.”
Brzmi banalnie. Ale od strony zespołu technicznego może to wyglądać zupełnie inaczej.
Developer musi:
1. Przeanalizować zgłoszenie
Gdzie znajduje się ten przycisk?
Czy jest tylko w jednym miejscu?
Czy występuje w kilku wersjach strony?
Czy tekst jest wpisany bezpośrednio w kodzie?
Czy jest zarządzany przez CMS?
Czy zmiana dotyczy wersji desktopowej i mobilnej?
Czy przycisk jest częścią komponentu wykorzystywanego w innych miejscach?
2. Wprowadzić zmianę
Zmienić tekst.
Przebudować komponent.
Zaktualizować treść w CMS.
Albo zmodyfikować kod.
3. Sprawdzić efekt
Czy przycisk nadal wygląda poprawnie?
Czy tekst nie wychodzi poza jego obszar?
Czy na telefonie wszystko działa?
Czy zmiana nie wpłynęła na inne miejsca?
4. Przetestować
Czy można kliknąć?
Czy link prowadzi tam, gdzie powinien?
Czy nie pojawił się błąd?
5. Wdrożyć zmianę
Jeżeli zmiana wymaga deployu, trzeba ją umieścić na środowisku produkcyjnym.
I nagle okazuje się, że: „Tylko zmiana tekstu”
niekoniecznie oznacza: „Tylko 5 minut pracy”.
Ile może kosztować jedna drobna zmiana?
Załóżmy bardzo konserwatywny scenariusz.
Developer poświęca:
- 15 minut na analizę,
- 20 minut na wdrożenie,
- 15 minut na testy,
- 10 minut na przygotowanie i wdrożenie.
Razem: 60 minut pracy.
I tutaj dochodzimy do ważnego punktu. Jeżeli stawka godzinowa zespołu wynosi przykładowo 200 zł netto, jedna pozornie drobna zmiana kosztuje około: 200 zł netto.
Ale to jeszcze nie wszystko. Bo w rzeczywistym procesie może pojawić się:
- przekazanie zadania,
- doprecyzowanie zakresu,
- pytania do klienta,
- oczekiwanie na odpowiedź,
- sprawdzenie efektu przez osobę zgłaszającą,
- poprawka po feedbacku,
- ponowne wdrożenie.
Jedna godzina może więc bardzo łatwo zamienić się w dwie. A jedna mała zmiana w kilka godzin pracy całego zespołu.
Najdroższe nie jest wykonanie zmiany
To może wydawać się paradoksalne. Czasami samo wykonanie zadania zajmuje 10 minut. Ale przygotowanie się do niego zajmuje kolejne 20. A potem dochodzą testy, i wdrożenie, i komunikacja, i przełączenie kontekstu.
I właśnie ten ostatni element jest często najbardziej niedoceniany.
Context switching - ukryty koszt małych zadań
Developer pracuje nad dużą funkcją. Ma otwarty kod. Analizuje problem. Jest skupiony.
Nagle pojawia się wiadomość: „Hej, tylko mała rzecz. Możesz poprawić przycisk?”
Developer przerywa pracę. Otwiera zgłoszenie. Sprawdza stronę. Szuka miejsca w kodzie. Wprowadza zmianę. Testuje. Wdraża. Wraca do poprzedniego zadania...
I wtedy musi sobie przypomnieć: „Na czym ja właściwie byłem?”
To właśnie context switching, czyli przełączanie kontekstu. I może być bardzo kosztowne. Nie dlatego, że każda pojedyncza zmiana wymaga dużej ilości pracy. Dlatego, że każda zmiana przerywa proces myślowy.
Im bardziej złożone zadanie, tym większy koszt powrotu do pracy. Dlatego 10 mikro-zadań nie zawsze oznacza 10 × 10 minut. W praktyce może oznaczać znacznie więcej.
Jeden przycisk to nic. Sto przycisków to już proces.
Załóżmy, że firma wysyła do zespołu technicznego:
- 20 drobnych zmian miesięcznie,
- każda zajmuje średnio 45 minut.
To daje: 15 godzin pracy miesięcznie.
Przy stawce 200 zł netto: 3000 zł netto miesięcznie.
Rocznie: 36 000 zł netto.
I mówimy tylko o 20 drobnych zadaniach miesięcznie. Bez dużych funkcjonalności. Bez rozwoju produktu. Bez nowych modułów. Bez integracji. Bez projektowania.
Tylko: „zmieńcie”, „poprawcie”, „przesuńcie”, „dodajcie”, „usuńcie”.
A teraz wyobraźmy sobie organizację, w której takich zadań jest 50 miesięcznie. Albo 100.
Skala zaczyna wyglądać zupełnie inaczej...
Mikro-zadania mają jeszcze jeden koszt - blokują rozwój
To jeden z najważniejszych elementów całej układanki.
Jeżeli zespół programistyczny spędza 20% czasu na drobnych poprawkach, to nie może przeznaczyć tych 20% na rozwój produktu. Brzmi oczywiście. Ale w praktyce często tego nie widać.
Firma mówi: „Dlaczego nowa funkcja jeszcze nie jest gotowa?”
Developer odpowiada: „Bo mieliśmy dużo bieżących tematów.”
„Jakich?”
„Poprawki, drobne zmiany, aktualizacje, małe zadania.”
Każde z nich było małe. Ale razem stworzyły ogromny blok pracy. To trochę jak z powiadomieniami na telefonie. Jedno powiadomienie nie przeszkadza. Dziesięć już trochę. Sto?... Nagle okazuje się, że cały dzień spędziliśmy na reagowaniu.
Z mikro-zadaniami jest podobnie.
„Małe zadanie” nie zawsze jest małym zadaniem
Warto również zrozumieć, że nie każda zmiana jest taka sama. Zmiana tekstu w CMS może rzeczywiście zająć kilka minut.
Ale zmiana tekstu w aplikacji może wymagać:
- znalezienia komponentu,
- zmiany kodu,
- aktualizacji tłumaczeń,
- testów,
- przebudowania aplikacji,
- wdrożenia.
Zmiana jednego pola może wymagać modyfikacji:
- front-endu,
- back-endu,
- bazy danych,
- API.
Zmiana jednego elementu w systemie może wpłynąć na inne elementy.
Dlatego pytanie: „Ile zajmie zmiana tego przycisku?”
bez znajomości architektury systemu często nie ma sensownej odpowiedzi.
Najpierw trzeba sprawdzić. Dopiero potem można oszacować.
Dlaczego developer czasami mówi: „Muszę to sprawdzić”?
To nie jest unikanie odpowiedzi. To często oznaka profesjonalizmu.
Dobry developer nie powinien obiecywać: „Tak, jasne, pięć minut.”
jeżeli nie wie, co znajduje się pod spodem.
Powinien powiedzieć: „Sprawdzę, gdzie ten element jest wykorzystywany i dam znać.”
To może zająć 10 minut. Ale te 10 minut może zaoszczędzić kilka godzin problemów. Bo najdroższa zmiana to często nie ta, która zajmuje godzinę.
Najdroższa jest ta, która:
- psuje inną funkcję,
- powoduje błąd na produkcji,
- wymaga pilnego rollbacku,
- generuje kolejne zgłoszenia,
- wymaga interwencji kilku osób.
Dlatego analiza przed zmianą jest częścią pracy, a nie stratą czasu.
Jak klient może obniżyć koszty mikro-zadań?
Nie chodzi o to, żeby przestać zgłaszać małe zmiany. Małe zmiany są normalną częścią rozwoju produktu. Chodzi o to, żeby nimi dobrze zarządzać.
1. Grupuj drobne zadania
Zamiast wysyłać:
„Zmieńcie przycisk.”
„Jeszcze poprawcie nagłówek.”
„A przy okazji dodajcie ten link.”
„I jeszcze przesuńcie ten element.”
Lepiej zebrać je w jeden pakiet.
Zespół może wtedy wykonać kilka zmian podczas jednego cyklu pracy.
Mniej przełączania kontekstu.
Mniej komunikacji.
Mniej wdrożeń.
Mniejszy koszt.
2. Ustal priorytety
Nie wszystko jest pilne.
Jeżeli każda rzecz ma status:
URGENT
to żadna nie jest naprawdę pilna.
Warto podzielić zadania na:
- krytyczne,
- ważne,
- planowane,
- kosmetyczne.
Dzięki temu zespół może pracować efektywniej.
3. Zastanów się, czy potrzebujesz zmiany w kodzie
Jeżeli firma regularnie zmienia:
- teksty,
- zdjęcia,
- bannery,
- linki,
- komunikaty,
to być może problemem nie jest brak szybkości developera.
Być może problemem jest architektura.
Jeżeli każda zmiana treści wymaga programisty, warto zastanowić się nad CMS-em lub panelem administracyjnym.
Dobrze zaprojektowany system powinien pozwalać osobom biznesowym samodzielnie zarządzać tym, co rzeczywiście nie wymaga ingerencji programisty.
Dobry system powinien odpowiadać na pytanie: kto powinien wykonać tę zmianę?
To bardzo ważna zasada projektowa. Nie każda zmiana powinna trafiać do developera.
Jeżeli marketing może samodzielnie:
- zmienić tekst,
- podmienić zdjęcie,
- dodać artykuł,
- zmienić kolejność sekcji,
to nie ma sensu angażować programisty.
Developer powinien zajmować się tym, co wymaga jego kompetencji.
Czyli między innymi:
- tworzeniem nowych funkcji,
- rozwojem systemu,
- integracjami,
- optymalizacją,
- bezpieczeństwem,
- architekturą,
- rozwiązaniem problemów technicznych.
W przeciwnym razie firma zaczyna płacić programiście za pracę, którą mógłby wykonać użytkownik systemu.
To trochę tak, jakby zatrudnić mechanika samochodowego do tankowania samochodu. Owszem, potrafi. Ale czy naprawdę tego potrzebujemy?
Kiedy warto powiedzieć: „Zróbmy to inaczej”?
Jeżeli ta sama prośba pojawia się regularnie, warto zatrzymać się i zadać pytanie:
Dlaczego musimy za każdym razem robić to ręcznie?
Jeżeli co tydzień prosimy o zmianę tego samego elementu, być może powinniśmy stworzyć:
- ustawienie w CMS,
- konfigurację,
- panel administracyjny,
- automatyzację,
- mechanizm self-service.
Jednorazowy koszt stworzenia takiego rozwiązania może być większy. Ale później każda kolejna zmiana może kosztować kilka sekund zamiast godziny.
To jest właśnie różnica między: płaceniem za każdą zmianę a inwestowaniem w system, który pozwala zmiany wykonywać samodzielnie.
Mikro-zadania a model współpracy z software house'em
To również ważny temat dla klientów.
Jeżeli współpraca z software house'em opiera się wyłącznie na modelu: „zgłaszamy - wyceniacie - akceptujemy - wykonujecie”, każda drobna zmiana może generować dodatkowy narzut organizacyjny.
Dlatego przy stałej współpracy często lepiej sprawdzają się:
- pakiety godzinowe,
- abonament na utrzymanie,
- stały zespół,
- backlog zadań,
- regularne sprinty,
- ustalone okna wdrożeniowe.
Nie oznacza to, że każdy klient powinien wybrać ten sam model. Chodzi o dopasowanie sposobu współpracy do charakteru projektu.
Jeżeli firma potrzebuje jednej zmiany miesięcznie, rozbudowany proces może być niepotrzebny. Jeżeli firma wysyła 50 zadań miesięcznie, brak procesu może być bardzo kosztowny.
Czy każdą zmianę warto liczyć?
To zależy.
W niektórych projektach dokładne rozliczanie każdej minuty ma sens. W innych może generować więcej administracji niż oszczędności.
Dlatego warto patrzeć na współpracę szerzej.
Najważniejsze pytanie nie brzmi: „Ile kosztowała ta jedna zmiana?”
Lepsze pytanie brzmi: „Ile kosztuje nas sposób, w jaki zarządzamy wszystkimi zmianami?”
Jeżeli firma płaci 200 zł za jedną zmianę, ale dzięki temu unika błędów i ma pewność, że wszystko działa poprawnie, może to być rozsądny koszt.
Jeżeli natomiast każdego miesiąca płaci kilka tysięcy złotych za dziesiątki podobnych mikro-zadań, warto zastanowić się, czy problemu nie można rozwiązać systemowo.
Najdroższe słowa w IT?
Być może brzmią: „To tylko mała zmiana.”
Nie dlatego, że małe zmiany są złe. Są potrzebne.
Produkt cyfrowy żyje. Zmieniają się potrzeby klientów. Zmienia się rynek. Zmienia się marketing. Zmienia się technologia. Zmiany są naturalne.
Problem zaczyna się wtedy, gdy organizacja nie widzi ich skumulowanego kosztu.
Jedna mała zmiana? - Nic wielkiego.
Dziesięć? - Nadal niewiele.
Sto? - To już proces.
A jeśli takich procesów jest kilkanaście? Nagle okazuje się, że firma nie wydaje pieniędzy na rozwój produktu. Wydaje je na ciągłe poprawianie drobiazgów.
Zamiast liczyć przyciski, policzmy czas
Dobrze zarządzany rozwój cyfrowego produktu nie polega na tym, żeby zabraniać klientowi zgłaszania małych zmian.
Polega na tym, żeby wiedzieć:
- które zmiany naprawdę wymagają programisty,
- które można wykonać samodzielnie,
- które warto zautomatyzować,
- które należy grupować,
- które są naprawdę pilne,
- które można zaplanować,
- które warto rozwiązać systemowo.
Bo czasami najlepszą odpowiedzią na: „Poprawcie to szybko.”
nie jest: „Dobrze, zrobimy.”
Tylko: „Zastanówmy się, dlaczego za miesiąc znowu będziemy musieli to poprawiać.”
To właśnie tutaj software house przestaje być tylko wykonawcą zadań. A zaczyna być partnerem technologicznym. Bo dobry partner nie tylko realizuje kolejne zgłoszenia.
Pomaga również zobaczyć, że czasami najtańsza zmiana to nie ta, którą wykonamy szybciej. Najtańsza jest ta, której nie będziemy musieli wykonywać po raz setny.
I właśnie dlatego jeden przycisk „Poprawcie to szybko” może kosztować godzinę.
Ale dobrze zaprojektowany system może sprawić, że następne sto takich zmian wykonasz samodzielnie w kilka minut.
To nie jest oszczędność na programistach. To jest inwestycja w lepszy proces, lepszą architekturę i mądrzejsze wykorzystanie czasu całego zespołu.
