Nie mów mi co mam zrobić…

“Proszę o dodanie możliwości usuwania błędnie dodanego X do Z”.

Często zdarza mi się słyszeć lub czytać takie zgłoszenie. Sęk w tym, że dodane X spowodowało wiele procesów automatycznych w aplikacji, czyli dodanie A, usunięcie B i zmianę statusów w C i D. Tak wyglądają złożone systemy informatyczne, o czym wielu użytkowników zwyczajnie nie wie (po to ukrywamy tą logikę w aplikacji, abyś Ty mógł wydajnie pracować nie myśląc o tych wszystkich szczegółach).

Zatem tracimy czas, żeby przeanalizować potencjalne skutki usunięcia X oraz na szukanie sposobów na przywrócenie spójności systemu po tej operacji chirurgicznej. Aż w końcu okazuje się, że samo istnienie błędnego X w systemie w niczym nie przeszkadza – ma być zwyczajnie niewidoczny na wydruku Z, który idzie do klienta.

Gdybyś od razu powiedział szczerze czego potrzebujesz – dałbym Ci to w 5 minut!

No właśnie… gdybyś nie mówił mi co mam robić, a zamiast tego powiedział mi czego potrzebujesz. Umówmy się: Ty jesteś specjalistą od używania systemu, ja jestem specjalistą od mechaniki jego działania. Nie mówisz swojemu mechanikowi, którą śrubę ma dokręcić – mówisz mu, że tu stuka… a ma nie stukać.

Bądź precyzyjny w kwestii swoich potrzeb.

Wchodząc w szczegóły techniczne może się wydawać, że zyskujemy precyzję, ale tak naprawdę tracimy kontekst. Kontekst pozwala mi znaleźć takie rozwiązania Twoich rozterek, które będą współgrały z aktualnymi mechanizmami aplikacji, zamiast je rozrywać na kawałki.
Gdy go nie ma, musimy wyjść najpierw od szczegółu, do ogółu i z powrotem. To dłuższa i niepotrzebna droga.

Share Button

2 thoughts on “Nie mów mi co mam zrobić…

  1. Często tak jest, jak niektórzy zbyt osobiście podchodzą do tematów i tak na prawdę można by się dogadać o wiele wcześniej, no ale nie – bo ja tak chcę i mam podstawy by tego wymagać ;)!
    Wtedy odpowiedź – robienie tego w ten sposób nie ma sensu = dla takich osób – mówisz bez sensu, co jest ewidentnie sprzeczne.
    I wiele rzeczy się dzieje od tak, dla zasady.
    Ja na przykład dziś pół dnia straciłem na wykazanie błędu – który programista ciągle odbijał – jako, że było zgodnie ze specyfikacją. I to był jedyny argument, a co z logicznym myśleniem? :)
    Po zorganizowaniu spotkania z biznesem i analizą – wspólnie doszliśmy do wniosku, że jednak jest to błąd – zostanie poprawiona specyfikacja i aplikacja.
    Jak by programista nie mógł od razu poprzeć błędu i samemu go przekazać do analizy w celu szybszego rozwiązania.

    Przecież powinien przyświecać wspólny cel – szybkie i sprawne szukanie rozwiązań…

Leave a Reply

Your email address will not be published. Required fields are marked *