Aż czasami zabiera mi dech w piersiach kiedy czytam wymagania do projektu – to jest jak prawdziwe Si-Fi gdzie postacie są tak dobrze nakreślone, że aż się ma ochotę część przytulić, za częścią płakać a część… no właśnie. Od razu rodzą się pytania „po co?”, „dlaczego?”, „po jakiego grzyba?”, „kiedy takie coś może mieć miejsce?” i wiele wiele innych, które sprowadzić można do jednego mianownika: czy to ma prawo się kiedykolwiek wydarzyć? Kiedy to się może wydarzyć? Czy mamy przez to komplikować całe rozwiązanie?

Dla przykładu, użytkownik edytuje swoje dane (imię, nazwisko, dane adresowe itp.), dane te są automatycznie dostępne dla wszystkich systemów z których użytkownik korzysta w danej chwili, oprócz jednego z którego on nie korzysta, ale może korzystać osoba wewnętrznie. Dane które użytkownik edytuje są synchronizowane dwa razy dziennie do tego systemu z którego użytkownik nie korzysta i nie ma dostępu. Jedyną sytuacją kiedy może nastąpić konflikt tych dwóch danych jest sytuacja kiedy ktoś wewnętrznie z edytuje dane użytkownika w systemie, i do tego użytkownik sam sobie z edytuje dane.

Kiedy taka sytuacja ma prawo miejsce się wydarzyć? No właśnie kiedy? I to w przedziale czasu 6-12h. Jak często osoba może zmienić swoje stanowisko w firmie? Jak często osoba wewnętrznie będzie sobie ot tak modyfikowała danego użytkownika? Czy to w ogóle ma prawo się stać? A jak ma prawo (lol) to czy rozwiązaniem nie jest spowodowanie by synchronizacja do systemu wewnętrznego powinna być wykonywana częściej? Po co komplikować rozwiązanie, wprowadzać niemożliwe do zarządzania transakcje w systemie, tylko po to by jeden zapis szedł od razu do dwóch różnych systemów.

Czasami zdarza się tak, że zapędzamy się w pisanie wymagań, implementację i po prostu takich rzeczy nie widać, lub nie widzimy, że to nie ma sensu. Dlatego przez każdym możliwym określeniem wymagań, implementacją jakiegoś feature, oprócz „5 why” powinniśmy także zadać pytanie czy|kiedy.

Dla przykładu:

  • Muszę zapisać dane do dwóch źródeł danych jednocześnie
  • Dlaczego?
  • By mieć zsynchronizowane dane
  • Dlaczego?
  • Bo może nastąpić konflikt danych
  • Dlaczego?
  • Bo dwóch użytkowników może z edytować te same dane w dwóch różnych systemach
  • Dlaczego?
  • Gdyż jedne dane edytuje użytkownik którego te dane dotyczą, drugie dane użytkownik wewnętrzny, który wie, że coś się zmieniło
  • Dlaczego?
  • Gdyż dane są synchronizowane dwa razy dziennie i może nastąpić problem przy łączeniu dwóch rekordów przez co dane zmienione mogą zostać nadpisane przez dane nie zmienione ze względu na datę ostatniej modyfikacji

Ok to może nawet ma ręce nogi, jak tak popatrzeć jest nawet ok, ale już się nasuwa pytanie „kiedy i czy takie coś może się zdarzyć” i jak tak, to czy rozwiązaniem jest naprawdę implementacja tego czy zmienienie procesu synchronizacji danych – jak wprowadzenie częstszych synchronizacji?

  • Kiedy to może się zdarzyć?
  • Jak osoba wewnętrznie stwierdzi, że dane użytkownika mogły się zmienić, lub kiedy użytkownik zadzwoni i poinformuje o zmianie danych osobowych
  • Kiedy osoba może stwierdzić z pewnością, że dane osoby się zmieniły?
  • Wtedy kiedy ta osoba zadzwoni i poinformuje o tym, lub napisze maila
  • Czy wtedy osoba ta sama z edytuje dane w systemie i zadzwoni by poinformować by zmienić jej dane w systemie wewnętrznym o którym nic nie wie?
  • Eeee..

No właśnie. Czasami wystarczy kilka pytań by określić, że implementacja nowego wymagania nie ma sensu. Wystarczy, że albo wykorzystamy to co mamy z częstotliwością większą niż 2 razy dziennie, lub jeżeli opóźnienie naprawdę może wpłynąć na działanie całego procesu, to zastanowić się nad tym, czy nie lepiej by było zrobić synchronizację z wewnętrznego do zewnętrznego systemu tak by przez kilka minut zewnętrzne systemy miały nieaktualne dane – pytanie co jest ważniejsze.

Oczywiście mogą być dane które powinny być dostępne natychmiast – eee mogę pomyśleć tylko o kilku systemach gdzie takie coś jest niezbędne. W większości systemów, opóźnienie 5-10 minutowe przy synchronizacji systemów wewnętrznych i zewnętrznych nie ma znaczenia, w szczególności w procesach, które trwają miesiącami.

A wy macie podobne sytuacje? Jak sobie z nimi radzicie?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

6 KOMENTARZE

  2. Przed stworzeniem kazdego wiekszego ficzera organizujemy inception day. Polega to na tym ze spotykaja sie wszystkie zainteresowane strony, design, dev, pm, business i gramy w rozne gry wspolnie ktore maja nam przedstawic o co w ogole chodzi, co robimy, dlaczego robimy, jak wyglada rynek, co nas motywuje do tego by zaimplementowac te zmiane etc. Po takich ‘grach’ wychodzi wiele problemow, sugestii i akcjii. Proces ten jest bardzo pomocny w zbudowaniu fundamentow do zadawania pytan bardziej szczegolowych i wtedy uwazam ze kazdy dev musi wyksztalcic w sobie podejscie ‘meczy-dupy’ ^^. Nie ma miejsca na niejasnosci w zadaniu / zmianie. Kazde wymaganie musi byc wyraznie opisane.

    Robimy jeszce spike-y ( jesli sa potrzebne ) ktore sa 4h researchem danego zagadnienia i problemu + zawsze zadania obarczone najwieksza niewiadoma, ryzykiem sa priorytetem.

    Zadawanie wielu pytan moze czesto uratowac projekt / release lub zaoszczedzic kupe kasy.

  4. Takie konflikty zwykle wychodzą w rozmowach z działami biznesowymi w korpo. :) Kiedy tworzymy specyfikację projektu (staramy się wymuszać ten punkt współpracy, choć coraz częściej firmy same już tego chcą – co jest budujące), to odbywamy serię spotkań z poszczególnymi działami zainteresowanymi projektem i ustalamy, jakie są cele (zestawy wymagań), które każdy z nich chce osiągnąć oraz ich priorytety – to jest punkt wyjścia, oprócz analizy stanu zastanego (dostępnych zasobów, systemów, możliwości komunikacji, technologii, etc.).

    Dopiero potem robimy jedno lub kilka spotkań zbiorczych i projektujemy od ogółu do szczegółu i na bieżąco go debugujemy (zwykle już na przed rozpoczęciem tego spotkania powstaje lista konfliktów i problemów do rozwiązania i to od niej zaczynamy – pokazując klientowi, że różne departamenty chcą sprzecznych ze sobą celów).

    Ilustracja:

    – Tutaj zróbmy A.
    – A będzie wchodzić w konflikt z B i C5 oraz C7 w miejscach/scenariuszach X, Y, Z.
    – Y nie będzie występować w rzeczywistości, możemy się tym nie przejmować. W C5 zapytamy jeszcze u góry i damy panu znać na następnym spotkaniu. Jeśli chodzi o C7, to nie musimy w tym miejscu wykorzystywać A, możemy żyć bez tego. Natomiast co do B, nie mamy pomysłu – co pan proponuje?
    – Takie standardowe sposoby rozwiązania tego problemu to B1 lub B2, ale tutaj zaproponowałbym państwu B3, ponieważ…
    – Dobrze, decydujemy się na B3.

    :)

  6. @Michal

    no tak, jak masz mozliwosc brania udzialu w procecie tworzenia wymagan to jasne – wtedy to fajnie dziala. czasami jednak nie masz, dostajesz wymaganie przemyslane przez wszystkich, zatwierdzone przez kilka osob ale bez konsultacji z osobami implementujacymi, ot, bo taki feature chcemy :) wtedy az sie prosi ich spytac czy zadali sobe trud i odpowiedzieli na kilka podstawowych pytan – choc pewnie nie ;)

    ogolnie, grunt to rozmowa, zarowno z osobami odpowiedzialnymi za biznesowy aspekt aplikacji jak i z osobami technicznymi, po zebraniu juz wymagan. bez tego bedzie ciezko :) i jest :)

Comments are closed.