Rocksoft

Współpraca programistów z biznesem-klucz do sukcesu projektu.

Współpraca programistów z biznesem-klucz do sukcesu projektu.

Istnieje wiele metodyk zarządzania projektami. Każda z nich na swój sposób pomaga osiągnąć cele biznesowe. Często nie są one proste do ustalenia, szczególnie na początku projektu i formują się dopiero w trakcie realizacji. W odpowiedzi na ten problem powstały metodyki zwinne, u ich podstaw leży częsta wymiana informacji pomiędzy zespołem deweloperskim oraz przedstawicielami biznesu.

Jak to jednak wygląda w praktyce? Postaram się przedstawić kilka przykładów z życia, opisujących jak ważna jest dobra współpraca pomiędzy programistami i biznesem oraz jakich problemów pomaga ona uniknąć. Wiele z technicznych osób zapewne teraz pomyśli „w moim zespole jest product owner, nie chcę rozmawiać z biznesem”. W idealnym świecie mogłoby się to sprawdzić, jednak rzeczywistość wygląda nieco inaczej.

1) Ramy czasowe projektu

Zabrzmi to niewiarygodnie, lecz czasami zespół deweloperski nie zdaje sobie sprawy z ram czasowych, w których powinna zostać dowieziona funkcjonalność. Jest to jeden z ważniejszych driverów architektonicznych, który pozwala nam stwierdzić jaka architektura będzie odpowiednia do rozwiązania danego problemu. Tego typu niedopowiedzenia mogą się wziąć z kilku powodów:

  • Biznes uważa, że termin jest oczywisty, np. Black Friday
  • Biznes używa nazw świąt, np. Święto Dziękczynienia (w Kanadzie 11.10.2021 w USA 25.11.2021)
  • Biznes używając określenia Q2 ma na myśli początek drugiego kwartału, zespół deweloperski celuje w końcówkę Q2.

Ostatni przykład dosyć dobitnie pokazuje, że tak częste określenie jak Q2 sprawia, że mamy aż 90 dni rozbieżności w rozumieniu danego terminu. To całkiem sporo… Dlatego tak ważny jest wspólny język, można go usprawnić, zadając proste pytania:

  • „Do kiedy należy dowieźć daną funkcjonalność-jaka jest dokładna data?”
  • „Z czego wynika ta właśnie data?”
  • „Która z funkcjonalności projektu jest najbardziej krytyczna?”
  • „Co się stanie, jeśli danej funkcjonalności nie dowieziemy na czas?”

System, który ma obsłużyć wzmożony ruch w black friday dostarczony 2 dni po czasie jest już bezużyteczny, dlatego warto podczas tworzenia danego oprogramowania  znać jest ramy czasowe oraz następny punkt:

2) Cel projektu

Deweloperzy lubią „zamykać taski”. Dostają konkretne user-story, estymują, piszą kod, zamykają taska. Na pierwszy rzut oka wszystko wygląda ok, jednak zdarza się, że zadanie nie jest doprecyzowane lub „gryzie się” z innym zadaniem. Warto w takiej sytuacji zadać pytania:

  • „Jaki problem próbuje rozwiązać nasz projekt?”
  • „Jak dane zadanie przyczynia się do rozwiązania tego problemu?”
  • „Czy biznes jest świadomy niespójności pomiędzy taskami?”
  • „Czy dane rozwiązanie ma zadowolić biznes, czy użytkownika końcowego?”
  • „Czy znam lepszy sposób rozwiązania tego problemu?”

Wiele razy całym zespołem zadawaliśmy sobie pytanie „Jak to zadanie przyczyni się dla dobra całego projektu?” Często odkrywaliśmy zupełnie inne spojrzenie na problem od strony biznesowej i deweloperskiej, czego wcześniej nie byliśmy świadomi. Znając cel projektu, jako deweloperzy możemy też zaproponować lepsze rozwiązania:

Problem -> Biznes chce, by domyślnym językiem aplikacji był angielski, na każdym ekranie ma być wyświetlone menu zmiany języka.

Propozycja zespołu -> Możemy zaciągnąć język używany na urządzeniu użytkownika i w ten sposób ustawić język w aplikacji, który można zmienić w ustawieniach. Niewielka zmiana, jednak dla aplikacji, której warstwa wizualna była niezwykle istotna, schowanie menu z wyborem języka było znaczące.

Warto czasami przed podjęciem taska zadać sobie pytanie „Dlaczego?”. Być może dostrzeżemy niespójność z celami projektu i warto wrócić do biznesu ze swoim punktem widzenia. Dopytać o genezę zadania i czy to zadanie w obecnej formie pokrywa się z celem projektu. To tylko kilka minut rozmowy, a może zaoszczędzić wiele godzin programowania, a przy okazji przyczyni się do usprawnienia komunikacji z biznesem, która jest kolejnym punktem.

3) Komunikacja z biznesem

Mówi się, że dobra komunikacja to klucz do udanego projektu i zupełnie się z tym zgadzam. Kiedy słucham opowieści o „tragicznych projektach” bardzo często problemem, który się powtarza, jest słaba komunikacja z biznesem. Co to właściwie znaczy? Z własnego doświadczenia mogę wymienić kilka problemów, które miałem okazję napotykać:

  1. Biznes boi się rozmawiać z zespołem deweloperskim.
  2. Deweloperzy boją się rozmawiać z biznesem.
  3. Chaos w kanałach komunikacyjnych – nie wiadomo co robić.
  4. Wiele rodzajów biznesów – nie wiadomo, który jest ważniejszy.
  5. Biznes narzuca nierealne terminy.
  6. Biznes nie rozumie naszej technologii.

Odpowiedzią na punkty 1, 2, 3 jest ustalenie wspólnych kanałów komunikacji. Ważne jest to, by kanał był jeden i wspólny. Dobrze jest, by inni członkowie projektu mogli widzieć dyskusje i się w nich udzielać. Jeden kanał komunikacji sprawia, że bugi czy wrzutki nie giną w czeluściach spamu na prywatnej skrzynce, a jeśli ktoś chce zmienić kolor przycisków w całej aplikacji, to wszyscy mogą przeczytać dlaczego, by ewentualnie zaoponować coś w tej kwestii. Warto przyjąć zasadę, że gramy do jednej bramki i sukces projektu zależy od wspólnych starań.

Punkty 4, 5, 6 można rozwiązać za pomocą organizowania “demo” po zakończonym sprincie dla większej liczby interesariuszy / biznesów. Ważne jest też omawianie priorytetów na bieżący i następny sprint lub dostęp biznesu do Jiry (wystarczy read only). Jeśli występują jakieś trudności to można pokazać, z czym zmaga się obecnie zespół. Miałem okazję obserwować jak po wspólnym demo przedstawiciele względnie niezależnych biznesów między sobą ustalali czyja funkcjonalność jest ważniejsza, a czasami udaje się wyciągnąć z tego część wspólną i wszyscy są zadowoleni 🙂

Metryki techniczne w projekcie są bardzo ważne, dobrze jest mieć świadomość, jakie mamy pokrycie testami czy procent udanych wdrożeń. Jednak przez pryzmat czasu na projekty patrzę również, jak układała się współpraca z biznesem. Warto zrobić wspólne retro po zakończonym projekcie i stwierdzić co w komunikacji poszło dobrze, a co jeszcze można poprawić. Ostatecznie za projektami stoją ludzie, a nie tylko metryki, sprawmy, żeby ta współpraca była owocna i wzbudzała dobre emocje.

Tego wszystkim życzę, żeby współpraca pomiędzy zespołem deweloperskim a biznesem była gładka i naturalna. Budowanie murów i sztywnych podziałów w zwinnych metodykach przynosi niewiele pożytku-warto dodać, że wspólny lub wszechobecny język (ang. “Ubiquitous Language”) bardzo ułatwia wytwarzanie oprogramowania, o czym pisał Eric Evans w swojej książce o DDD.

Ps. Warto dodać, że to moje subiektywne przemyślenia, ile zespołów tyle problemów i rozwiązań. W zwinnych metodykach różne osoby przejmują inne obowiązki i całkiem możliwe, że w wielkich zespołach programista może nawet nie mieć dostępu do biznesu. Jednak myślę, że warto burzyć takie sztuczne ściany i prędzej czy później następuje skracanie dystansu pomiędzy programistami a biznesem-zazwyczaj wychodzi to dobre.

Miłego dnia! 🙂

Autor: Oskar Poprawski