Czy oprogramowanie wzbudza w nas emocje, czyli jak się ma RTZ do IT

Czy jakość oprogramowania to tylko coś, co możemy zmierzyć, przetestować, wyliczyć wartość w pieniądzu? Czy może jakość to coś więcej - zadowolenie użytkownika, pozytywne emocje, jakie budzą się w nas podczas korzystania z rozwiązania?

Model ABCD emocji

W Racjonalnej Terapii Zachowania mamy opisany taki model:

A - aktywujące zdarzenie
B - myśli i przekonania na temat A
C - odczucia emocjonalne powiązane z B
D - działanie

Wyobrażam sobie taką sytuację:

A - użycie przez użytkownika jakiejś aplikacji funkcji wyświetlającej dane klienta - np. za długie nazwisko nie mieści się na ekranie
B - myśl: ta aplikacja nie jest dobra, producent jest kiepski
C - jestem zła, bo nie mogę dobrze obsłużyć klienta
D - przekażę przełożonemu, że aplikacja nie nadaje się do użytku.

Dalszego ciągu można się domyślić.

"Zachwycacze" zmieniające sposób myślenia

Sądzę, że można popracować nad zmianą sposobu myślenia użytkowników o tej aplikacji. Parę dni temu podawałam rzeczywisty przykład z treścią komunikatu o niedostępności serwisu.
Wcześniej pisałam o znaczeniu koloru w interfejsie użytkownika.

W rzeczywistości warto postarać się o "zachwycacze", które nie będę kosztownymi dodatkami, ale zdecydowanie spowodują uśmiech i zachwyt użytkownika. Może to być wesoły komunikat, może ciekawa kolorystyka, czy inny znak rozpoznawczy marki, który zaskarbi przychylność.

W wyniku takiego "zachwycacza" pozytywnie nastawiony użytkownik będzie miał inną myśl po takim samym zdarzeniu:

B - no cóż, tym razem coś im nie wyszło, ale są fajni i wiem, że jak im zgłoszę, to szybko poprawią
C - uśmiecham się do klienta
D - zgłaszam błąd na help desk, a w przyszłości przełożony może poleci dostawcę do realizacji kolejnych aplikacji (to zależy też od warunków SLA, w jakich są poprawiane błędy)

A morał z tej bajki ...

Zmieniając sposób myślenia o użytkowanych aplikacjach zmieniamy też emocje użytkowników. Zmieniajmy je zawsze na pozytywne, wtedy świat będzie piękniejszy i lepszy :)

Psychologia stosowana, to mi się podoba

Czy niedziałający serwis może być powodem do zadowolenia? TAK! Przed chwilą tego doświadczyłam :)

Pomimo tego, iż serwis był niedostępny, uśmiechnęłam się :) Bo przeczytałam fajny komunikat. To przykład na to, jak można dbać o użytkownika. Przykład godny naśladowania.

Bo technologia jest zawodna, ale można ten fakt zakomunikować przyjemnie i nawet wykorzystać, z korzyścią dla wszystkich :)

Pomóżmy Prezydentowi podjąć decyzję - wysyłajmy maile w sprawie JOW

Popieram Jednomandatowe Okręgi Wyborcze (JOW). Zebrałam trochę podpisów, a teraz jest kolejny etap akcji. Zachęcam do wysyłania maili.

http://zmieleni.pl/presja-obywatelska-piszemy-e-maile/

Dnia 30 kwietnia 2013 złożyliśmy w Kancelarii Prezydenta Petycję Obywatelską w sprawie zarządzenia referendum w sprawie  JOW. Prezydent ma możliwość wystąpienia do Senatu z wnioskiem o referendum. Senat taki wniosek może przegłosować zwykłą większością głosów. Zachęcamy do wysyłania maili, by pomóc Prezydentowi podjąć decyzję.

Mam możliwość zmienienia systemu wyborczego, więc nie siedzę z założonymi rękami.
W tej chwili akcję zmieleni.pl poparło 123,5 tys. osób.

Takie podejście byłoby nie do przyjęcia, czyli coś o analizie wymagań

Czytam przedmowę Toma DeMarco do książki "Pełna analiza systemowa" autorstwa Jamesa i Suzanne Robertsonów. Zdania napisane w 1993 roku są w dalszym ciągu aktualne dzisiaj.

"Zmienił się także charakter dialogu między analitykiem, a użytkownikiem. Dawniej (przyp.: w połowie lat 80-tych) mówiliśmy "Oto, co otrzymasz". Teraz pokazujemy model i pytamy "Co myślisz o takim rozwiązaniu?" Gdy razem pochylamy się nad modelem, proces tworzenia systemu ożywa. Użytkownicy kładą rękę na modelu i zaczynają go wyginać i przekształcać. "Prawie, prawie ..." mówią. "... gdyby tylko można było zmienić to na przykład na coś takiego ...". Gdy zaczyna się taki dialog, wiemy, że projekt jest na dobrej drodze.

Gdy po raz pierwszy pokazujemy użytkownikowi model, wiemy z góry, że jest on najwyżej zbliżony do tego, czego użytkownik oczekuje. Pokazujemy model właśnie po to, by sprowokować zmiany."

Dialog z użytkownikiem

Dla mnie dialog z użytkownikiem zawsze był podstawą dobrego zrozumienia wymagań wobec projektowanego rozwiązania. Jak jednak połączyć umiejętność prowadzenia dialogu z inżynierią? Mówi się o inżynierii oprogramowania, inżynierii wymagań, inżynierii systemów. I automatycznie zawęża to obszar kompetencji do ściśle inżynierskich, technicznych.

Też jestem z wykształcenia informatykiem, ale tylko magistrem po uniwersytecie. Nie jestem inżynierem, więc nigdy nie przyszło mi do głowy, żeby dialog z użytkownikiem sprowadzić do określenia "algorytm postępowania". Niestety, takie podejście do użytkownika, jako osoby, która nie rozumie, co się do niej mówi i nie wie, czego chce, spotyka się w pewnych zamkniętych środowiskach.

Z Forum Jakości SI 2013 wyniosłam spostrzeżenia, że coraz więcej mówi się o jakości w kontekście użytkownika, zadowolenia klienta. Wydaje się, że pomocne w takim podejściu są wszelkie metodyki Agile, które zakładają iteracyjne wytwarzanie oprogramowania, przy ścisłej współpracy z użytkownikiem. Wiele prelekcji dotyczyło właśnie tego typu podejścia, chociaż nie jest to panaceum na wszystkie bolączki i nie zawsze można je wdrożyć w organizacji.

Inżynieria wymagań

Zastanawiam się, czy określenie "inżynieria" nie ma konotacji zawężającej je wyłącznie do obszarów wiedzy technicznej. A inżynieria wymagań ma w sobie wiele aspektów "miękkich", począwszy od zbierania wymagań na etapie badania marketingowych, działań sprzedażowych, poprzez wszystkie etapy wytwarzania, ergonomii interfejsu i przekazania klientowi (rozbudowana wersja klasycznego rysunku http://www.projectcartoon.com/cartoon/2).

Warto się będzie nad tym zastanowić, także w kontekście organizowanej w październiku konferencji Dobre Wymagania 2013.

Skłoniła mnie do tej refleksji dyskusja na LinkedIn, a dotycząca inżynierii systemów - pojęcia także funkcjonującego w poprzek wielu branż, natomiast zazwyczaj znanego wyłącznie w perspektywy danej branży, w której funkcjonujemy. Jak się w tym nie pogubić ...? Może przydatny będzie dokument opisujący dwanaście zawodów-roli w ramach inżynierii systemów, przytoczony w tej dyskusji.

Konkluzja

Świat pędzi do przodu, powstają nowe zawody, uczelnie nie nadążają z dostosowywaniem edukacji do potrzeb rynku. Może więc system edukacji musi się jakoś zmienić? Należałoby może odróżnić kształcenie akademickie od kształcenia w kierunku jakiegoś zawodu. Gdzie można zdobyć kwalifikacje do przytoczonych w dokumencie 12 zawodów w ramach inżynierii systemów? Niektóre kompetencje wykraczają zdecydowanie poza stricte techniczne.

Forum Jakości SI - dzień drugi

Drugi dzień forum był dniem, kiedy wspólnie z Bogdanem Berezą prowadziłam warsztaty "Testowanie na podstawie ryzyka". Tematyka testowania i jakości spotkała się z dużym zainteresowaniem. Tak oceniam udział trzydziestu trzech osób w warsztatach.

Koszty jakości 

Wywiązała się ciekawa i owocna dyskusja nad tematami zaproponowanymi w formie warsztatów. Dyskutowaliśmy o kosztach zapewnienia jakości, jak też kosztach braku jakości i poszukiwaniu złotego środka. Wnioski z dyskusji mogą być zalążkiem dalszej dyskusji, forum lub grupy dyskusyjnej, która w najbliższych tygodniach powinna być zainicjowana.

Czynniki miękkie

Bardzo ciekawe było spojrzenie Bogdana na jakość przez pryzmat psychologii, czynników miękkich, czyli tak naprawdę subiektywnych i ulegających łatwo manipulacji i wpływom. Warto było zastanowić się nad tym i podyskutować.

Konkluzja

Wnioski, jakie można było wyciągnąć z dyskusji, a które są także zbieżne z moimi przemyśleniami są takie, że jakość jest złożonym zagadnieniem, rozumianym różnie, w zależności od kontekstu.

Z jednej strony oczekuje się być może wielkości mierzalnych w jakości, takie są. Ale zdecydowanie istotniejsze jest myślenie o jakości w kontekście użytkownika końcowego, w sposób subiektywny, a czasami nawet mocno zmanipulowany.

Warto szukać porozumienia pomiędzy IT a biznesem, szczególnie w temacie rozumienia jakości, bo ilu ludzi, każdy rozumie ją inaczej. Warto patrzeć na jakość przez pryzmat ludzi. Bo technologia jest dla ludzi, a nie na odwrót. I cieszę się, że nie jestem odosobniona w tym myśleniu :)

Rozbudowa lotniska Okęcie - widok po wyjściu z konferencji.

Forum Jakości SI - dzień pierwszy

Dzisiaj uczestniczyłam w pierwszym dniu konferencji organizowanej przez Computerworld - Jakość 2013. Podzielę się przemyśleniami, ale najpierw pochwalę świetne miejsce, organizację i jedzenie :)

Wymagania a jakość

Wysłuchując prelekcji plenarnych odniosłam wrażenie, że wszystkie poruszały kwestię ważności wymagań w kontekście mówienia o jakości systemów informatycznych. Temat ten jest mi szczególnie bliski, bo moje przemyślenia są dokładnie takie same. Jakość identyfikacji wymagań i zarządzania wymaganiami ma decydujący wpływ na jakość produktu końcowego. W szczególności zła jakość wymagań ma zgubne skutki dla projektu.

Scrum na topie

Kolejny temat jest też bliski memu sercu i dotyczy metodyk adaptacyjnych. W tej chwili na topie jest Scrum, czego doświadczałam także we własnej pracy. Ciekawe było spojrzenie z różnych punktów widzenia, z różnych wdrożeń, czy też prób wdrożenia tej metodyki. Szczególnie przypadły mi do gustu dwie prezentacje. Jedna Piotra Nabielca, który ma duże doświadczenie i wiedzę. I druga, z wdrożenia Agile w ING Banku. Zawsze z przyjemnością słucham o rzeczywistych wdrożeniach, a nie tylko o teorii. Zobaczyłam, że jest możliwe wdrożenie Scruma w instytucji finansowej, całkiem dużej.

Dyskusja o jakości

Przysłuchiwałam się też z zainteresowaniem dyskusji panelowej dotyczącej jakości. Ciekawe było spojrzenie z różnych perspektyw, różnych branż, z podkreśleniem rozumienia jakości zależnego od kontekstu. Temat szeroki jak rzeka, aż skończył się czas.

Jutro drugi dzień konferencji, gdzie mam także przyjemność współprowadzenia warsztatów dotyczących kosztów jakości i jakości, także w kontekście miękkich aspektów. Odbioru jakości przez ludzi i różnych ciekawych eksperymentach psychologicznych.

Ale o tym napiszę jutro, jak będę w pociągu do domu :)
Na zdjęciu z komórki wczorajsza burza gradowa nad Warszawą.

Forum Jakości Systemów Informatycznych, 21-22 maja 2013 Warszawa

Na co dzień mieszkam i pracuję w Krakowie. Jednak najbliższe trzy dni (20-22 maja) spędzę w Warszawie.

W dniach 21-22 maja będę uczestniczyła w konferencji organizowanej przez Computerworld - Forum Jakości Systemów Informatycznych. Wspólnie z Bogdanem Berezą będę prowadziła warsztaty Testowanie na podstawie ryzyka. W październiku organizujemy też wspólnie konferencję Dobre Wymagania 2013.

Zapraszam!

I mam nadzieję, że znajdę chwilę, żeby zobaczyć ciekawe miejsca w W-wie, bo to całkiem inne miasto niż Kraków :)

O dialogu, czyli sposobie identyfikacji wymagań raz jeszcze

Zastanawiam się, dlaczego w ostatnich latach tak dużo mówi się o dialogu, a właściwie o problemach związanych z brakiem umiejętności prowadzenia dialogu. Zmieniło się tempo życia i styl życia. Dialogu nie ćwiczy się na co dzień.

Dialog w inżynierii wymagań

Jakiś czas temu poznałam w sieci Kazimierza Grabskiego, który jest twórcą Openera. Tematyka dialogu bardzo mnie zainteresowała. Jednak z powodu dużej odległości pomiędzy Warszawą a Krakowem nie udaje mi się bywać na spotkaniach. Ale jestem wierną czytelniczką portalu i bloga.

Pewnego razu Kaz napisał do mnie bardzo mądrze o dialogu w kontekście inżynierii wymagań.

(...) dialog czyli: 

• definiowanie wymagań w języku zrozumiałym dla adresatów wymagań,
• słuchanie i słyszenie istoty i szczegółów dotyczących wymagań,
• umiejętność zadawania pytań zrozumiałych dla definiujących wymagania,
• gotowość do podważania oczywistych oczywistości definiowania wymagań, wejścia w buty drugiej osoby, uwzględniania różnorodnych konsekwencji,
• przestrzeń zrozumienia, zaufania i współpracy między wszystkimi stronami zaangażowanymi w definiowanie wymagań

mogą być niezwykle istotne dla inżynierii wymagań. (...)

Bardzo mi się spodobała ta definicja dialogu.

Morał

Dialog potrzebny jest wszędzie, w szczególności w inżynierii wymagań. A konsekwencje braku dialogu mogą być czasami bardzo kosztowne.

Wspólny język, czyli o podobieństwie między brydżem a inżynierią wymagań

Bardzo lubię grać w brydża, bo jest to dyscyplina sportowa, a jednocześnie przyjemna rozrywka towarzyska. Dostępna dla każdego, kto pozna zasady gry i stosuje je konsekwentnie w grze. Moim marzeniem jest, aby tak, jak w brydżu, istniał "Wspólny Język" w inżynierii wymagań, czyli system powszechnie znany i stosowany, zrozumiały dla większości graczy.

Demokratyczne zasady

W brydża grają wszyscy, młodzi i starzy, przedstawiciele różnych zawodów, brydż jest dla każdego, kto chce grać i nauczy się zasad. Zasady są zrozumiałe dla każdego i wszystkich obowiązują, chociaż tylko niektórzy są mistrzami - jak zmarły parę miesięcy temu arcymistrz światowy Andrzej Wilkosz, z którym miałam kiedyś przyjemność grać przy jednym stoliku w Turnieju o Świątecznego Karpia w Krakowie.

Tak samo jest z inżynierią wymagań, która według mnie ma być dostępna i zrozumiała dla każdego. Zarówno klienci, którzy mają wymagania, jak i dostawcy usług lub produktów, wszyscy powinni w podstawowym zakresie i posługując się "wspólnym językiem" osiągnąć wzajemne zrozumienie, ku zadowoleniu obu stron w dialogu zamawiający-dostawca.

Przeszkadzacze

Analogia do brydża jest dobra w każdym calu. Bo nawet, jak uda się parze wylicytować kontrakt - pomimo przeszkadzania przeciwników, którzy chcą wylicytować swój inny kontrakt - pozostaje jeszcze rozgrywka. I tu może też się wszystko zdarzyć. Tak samo jest w wielu przedsięwzięciach, przykładowo w realizacji kontraktu na dostarczenie systemu informatycznego. Na różnych etapach uzgadniania (negocjowania) i realizacji występują różni interesariusze. W parze "klient-dostawca" należy skupić się na wspólnych własnych celach i wzajemnym zrozumieniu, nie zapominając wszakże o przeszkodach i utrudnieniach ze strony innych graczy.

Zamienność ról

W życiu jest tak, że możemy znaleźć się w dowolnej roli, raz jako dostawca, raz zamawiający, a także jako przeciwnik innych (mający sprzeczne cele). Jednak jest coś, co się nie zmienia - jest to wspólny język, którym porozumiewamy się z partnerami i przeciwnikami podczas formułowania, dokumentowania i zarządzania wymaganiami. Bez względu na naszą rolę w danym momencie, język i zasady są zawsze takie same, powinny być takie same. I zawsze ważne są w tym relacje międzyludzkie, jak przy brydżowym stoliku.

Konkluzja

Tak, jak "Wspólny Język" w brydżu jest opracowywany w sposób demokratyczny (w oparciu o ankietę przygotowaną przez Krzysztofa Jassema dla czytelników pisma Brydż), tak jego odpowiednik w inżynierii wymagań także powinien być opracowany podobnie.

Dlatego też dołączyłam do organizatorów konferencji Dobre Wymagania 2013, która inicjuje działanie stowarzyszenia PARE. Wierzę, że jest możliwe stworzenie standardów i zasad powszechnie znanych i stosowanych w inżynierii wymagań. Tym samym nastąpi lepsze zrozumienie pomiędzy światem technologii i IT, a biznesem i użytkownikami tej technologii.

Podobnie jest z muzyką ... ale o tym innym razem.

Projekt kojarzy się bardziej z ogrodem francuskim

W ogrodnictwie można zauważyć dwa odmienne style - ogród francuski i ogród angielski. Dla mnie ogród francuski i styl francuski jest odpowiednikiem dobrego zarządzania projektem. Spróbuję to krótko uzasadnić.

Francuski porządek

Projekt powinien być uporządkowany, równo przystrzyżone żywopłoty, wyznaczone ścieżki, całość mająca swój porządek także z lotu ptaka. I takie miejsce, taka organizacja przestrzeni, sprzyja ludziom i ich relacjom, jest dokładnie im podporządkowana.

Tak samo, jak w projektach, gdzie najważniejszy jest człowiek i dobre relacje międzyludzkie. Cała organizacja projektu musi być tak bardzo przemyślana, żeby ludziom w projekcie było dobrze. Żadnego ryzyka pobłądzenia, żadnych ślepych ścieżek, wszystko pod kontrolą.

Angielska "swoboda"

A dlaczego angielski ogród nie przypomina mi dobrego projektu? Bo w nim człowiek stwarza jedynie pozory naturalności, wkłada to dużo wysiłku, żeby ogród wyglądał pięknie i naturalnie. I może nawet po pewnym czasie zostawia go samemu sobie. To przypomina mi projekt, gdzie bardzo dużo uwagi poświęca się formalnościom, przemyślanym procedurom, ideom i tym podobnym kwestiom.

W takim ogromie zasad człowiek jest zupełnie nieistotnym detalem. Wprawdzie bierze się pod uwagę perspektywę, z jakiej będzie patrzył na ogród teraz i w przyszłości, ale to jest takie mocno przemyślane, brak naturalności i spontaniczności, typowo angielskie. W efekcie powstają piękne ogrody, w których jednak bardzo łatwo się zagubić.

Morał z tej bajki ...

Jeżeli zależy nam na sukcesie projektu, zdecydowanie stawiałabym na relacje między ludzkie, na przestrzeń dla nich. Czyli dla mnie metaforą dobrze zarządzanego projektu będzie ogród francuski. Fakt, wymaga ciągłego utrzymania porządku, strzyżenia żywopłotów, ale jakże wygodnie po nim spacerować, czego wszystkim życzę :)

Małe jest piękne, czyli jak testować duże systemy

Osobiście uważam, że kluczem do sukcesu, czyli zapewnienia wysokiej jakości dużych systemów jest ich dekompozycja, rozumiana dwojako. Z jednej strony jest to dekompozycja funkcjonalna, na specjalizowane moduły lub usługi, z drugiej strony dekompozycja czasowa, czyli realizacja rozciągnięta w czasie. Jestem zdecydowaną zwolenniczką iteracyjnego podejścia. Jak w takim razie testować, zapewniać i kontrolować jakość?

Małe jest piękne

Przy projektowaniu rozwiązań warto zastanawiać się nad taką dekompozycją, która przede wszystkim umożliwi jak najszybsze uzyskanie korzyści biznesowych z wdrożenia. A idąc wstecz, umożliwi przetestowanie spójnego zakresu funkcjonalnego, łącznie z możliwością zintegrowania ze środowiskiem. Dlatego tak ważne jest uzgodnienie kolejnych etapów lub iteracji z klientem i wszystkimi dostawcami.

Optymalizacja kosztów testowania iteracyjnego

W przypadku iteracyjnego podejścia warto też zastanowić się nad kosztami przeprowadzania testów kolejnych iteracji. Dlatego warto zadbać o jak najlepszą izolacyjność pomiędzy kolejnymi iteracjami, aby nie było konieczności powtarzania i poszerzania zakresu testów. A nie jest to takie proste i oczywiste, bo o sposobie testowania nie zawsze myśli się w początkowych etapach realizacji projektu.

Refleksja

Współczesny świat, a w szczególności systemy informatyczne, robią się coraz bardziej skomplikowane i złożone, jak też są elementami złożonego otoczenia. I w zasadzie należy zaakceptować prawdę ze starego powiedzenia: "Nie ma dobrych rozwiązań, są tylko lepiej lub gorzej przetestowane". A to, jak dobrze, można coś przetestować, zależy od bardzo wielu czynników. Biorąc pod uwagę te czynniki, planuje się taki, a nie inny sposób testowania.

Niezaplanowane koszty testowania, czyli o czym warto pomyśleć na etapie umowy

Często bywa tak, że etap testów akceptacyjnych z różnych powodów przesuwa się w czasie, wydłuża, co generuje koszty zarówno po stronie dostawców, jak też odbiorcy produktu. Jak się przed tym zabezpieczyć i też jak podzielić się tymi niezaplanowanymi kosztami?

Konstruowanie umowy

Już na etapie definiowania zakresu realizacji umowy warto doprecyzować zasady, na jakich będą przeprowadzane testy integracyjne, akceptacyjne, ze szczególnym uwzględnieniem testowania komponentów zewnętrznych, usług.

W sytuacji, kiedy jest kilku dostawców, po stronie klienta spoczywa obowiązek zapewnienia wszystkich usług w terminie. A co, jeśli któryś z dostawców się spóźni i nie będzie możliwe przetestowanie użycia usługi w procesie? Kto wtedy ponosi koszt ziszczenia się tego ryzyka?

Warto też zabezpieczyć się przed sytuacją przedłużania testów z powodu niedostępności środowiska do testów, może błędnych danych do testów, niekompetentnych testerów itp. Istnieje bardzo dużo sytuacji, które powinny być doprecyzowane na etapie umowy, co pozwoli w przyszłości wyegzekwować działanie lub poniesienie kosztów braku działania. Wtedy sytuacja jest klarowna i chroni strony przed ponoszeniem dodatkowych kosztów generowanych przez strony trzecie.

Koszt wykonywania testów
 
Czy w prosty sposób można oszacować koszt planowanych testów? Na pewno warto wziąć pod uwagę wiele czynników, poza oczywistymi, m. in.:

1. Złożoność rozwiązania
2. Testowalność w kontekście czasu i zakresu danych do testowania
3. Udokumentowanie ścieżek testowych
4. Znajomość procesów biznesowych
5. Zależności od kontekstu, architektury i powiązania z innymi rozwiązaniami lub usługami
6. Kompetencje zespołu testerów
7. Umiejscowienie zespołu testerów w organizacji – zewnętrzni, wewnętrzni, rozproszeni, dedykowany zespół
8. Dostępność testerów i ich elastyczność
9. Narzędzia wspierające testowanie oraz obsługę zgłaszanych błędów
10. Współpraca z dostawcą/dostawcami

Takich czynników jest bardzo dużo. Czy zatem można w miarę dokładnie oszacować koszt testów? Czy można obniżyć koszt testowania? A może wyliczyć go - post factum - proporcjonalnie to kosztu napisania kodu? To jest jakaś metoda, jeżeli zespół deweloperów jest stały i mamy dane historyczne umożliwiające dobre szacowanie.

Konkluzja

Najłatwiej oszacować dobrze zerowe koszty testów, czyli takich, których nie trzeba przeprowadzać. To jedna z metod realizacji oprogramowania - całkowite koszty testowania przerzucane są na kogoś innego. Inna opcja, to pisanie bezbłędnego oprogramowania, które nie wymaga już testowania. Idee są piękne :)

Wspieram kulturę

Jeżeli masz ochotę wesprzeć kulturę, to podaję link do projektu

http://wspieramkulture.pl/projekt/239-GREGORIANUM-nagrywa-Nieznane-skarby-Kapeli-Rorantystow

Ja wsparłam :)

Ewa

Jak to jest z tą analizą wymagań, czyli dlaczego w informatyce jest tak źle

Od dawna zastanawia mnie, dlaczego w informatyce analiza wymagań jest tak skomplikowanym procesem i dlaczego często widuje się sytuacje, kiedy rozbieżność między oczekiwaniami klienta, a realizacją jest tak duża. Pokazuje to dobrze rysunek, który jest już klasyką

pobrane z http://webhosting.pl/files/groups/editors/programowanie/2009_06/realizacja_projektu.gif

Zabawa w głuchy telefon

Droga zbierania wymagań klienta jest często o wiele bardziej dłuższa i pokręcona. Bo wymagania mają wiele odmian, w szczególności, jak są realizowane z zachowaniem trybu postępowania ofertowego. 

Każdy z uczestników tej gry ma swoje własne interesy i tylko te widzi, przekazuje temat kolejnej osobie/zespołowi w łańcuszku i im więcej będzie tych osób, tym wynik końcowy będzie bardziej się różnił od początkowego. Jak w zabawie w głuchy telefon. Każdy też ma świadomość tego, że nie wiadomo, co dokładnie zamawia, nie wiadomo, co dostanie w efekcie końcowym. I tu należałoby szukać remedium na obniżenie tego poziomu niepewności z obu stron - dogłębnej znajomości tematu, o czym się mówi.

Analiza wymagań jako osobna umowa/projekt

 

Z doświadczenia wiem, że lepszym rozwiązaniem jest prowadzenie analizy wymagań jako osobnego kontraktu/projektu. Wtedy wynik tego projektu może być wsadem do realizacji.

Wszystko sprowadza się tak naprawdę do standaryzacji sposobu prowadzenia i zapisu analizy wymagań. Tak, aby wszyscy uczestnicy projektu  w sposób jednoznaczny rozumieli wymagania, a tym samym mogli je zapewnić, z zachowaniem najwyższego poziomu jakości. Czy to jest możliwe i przy jakich założeniach?

Konkluzja

Wierzę, że można doskonalić analizę wymagań i propagować taką wiedzę. Na pewno kolejne pokolenia powinny zdobywać dobre podstawy na uczelniach, ale to jest dopiero punkt wyjścia do budowania kompetencji w tym obszarze. Bo oprócz wiedzy czysto inżynierskiej, potrzebna jest też znajomość biznesu, reguł, procesów i przede wszystkim rozumienie ludzi, umiejętne ich słuchanie i prowadzenie dialogu.

Najważniejszy zawsze jest kolor, czyli o hierarchii wymagań i ich weryfikacji

Patrząc na inżynierię oprogramowania dochodzę do wniosku, że podobnie, jak w innych obszarach produkcji, najważniejszy jest kolor, efekt końcowy, widoczny dla końcowego użytkownika. Kolor, przyjemne dla oka wrażenie.

Hierarchia wymagań

Kiedy myślę o wymaganiach do systemu informatycznego, ich identyfikowaniu, od razu przychodzi mi do głowy pytanie, kto to będzie później weryfikował. Jest kilka poziomów i kilka możliwości.

Wymagania związane z samą inżynierią oprogramowania będą testowane jednostkowo, jak też w inny sposób, wewnątrz zespołu realizującego.

Testowanie automatyczne jest możliwe dla tych obszarów, które działają wg określonych algorytmów i często nie są widoczne dla oka. Jedynie wynik końcowy może być widoczny. I wtedy warto mieć testy automatyczne, które pokryją wszystkie możliwe dane lub klasy danych.

Wymagania techniczne, wydajnościowe, bezpieczeństwa itp. będą testowane w inny sposób i przez inne zespoły, które zgłosiły te wymagania. Podobnie jest z wymaganiami biznesowymi funkcjonalnymi, tutaj przydatne będą scenariusze testowe.

Jednak najważniejsze będą zawsze wymagania użytkownika końcowego, przysłowiowa wisienka na torcie. Bo to ten użytkownik na co dzień będzie korzystał z rozwiązania.

Wisienka na torcie, czyli kolor

Kiedy już zostaną zrealizowane wszystkie wymagania, na końcu należy zadbać o zadowolenie użytkownika końcowego.

W systemie informatycznym będzie to kolor czcionek, tła, przycisków, w budowanym domu będzie to kolor ścian, w kupowanym samochodzie będzie to kolor lakieru i tapicerki. Przykładów można przytaczać wiele.

Zawsze, jak już spełnione zostaną podstawowe wymagania, należy pomyśleć o kolorze. Tutaj znowu, weryfikację spełnienia wymagania należy zostawić osobom, które te wymagania zgłosiły. I może akurat w tym przypadku istotna jest płeć, bo postrzeganie kolorów od niej zależy. Piszę z własnej perspektywy :)

Konkluzja

Kolor to tak naprawdę symbol przyjaznego interfejsu dla użytkownika.

W mojej pralce, która jest koloru białego najważniejsza jest możliwość szybkiego indywidualnego zdefiniowania parametrów programu. Dlatego od 17 lat jestem wierna jednej marce, kupuję tylko nowszy model, jak poprzedni się wyeksploatuje. I wiem, że w przyszłości znowu kupię tę samą markę.

Czy są takie marki w branży IT, które wybieramy ponownie dlatego, że się sprawdziły i są przyjazne dla użytkownika? ...

Kwitną w majowym deszczu

Ważne jak się zaczyna, a nie tylko, jak się kończy

Ostatnio uświadomiłam sobie po raz kolejny, jak ważne jest zaczynanie nowego przedsięwzięcia, nowej relacji, nowego projektu, w szczególności w nowym środowisku. Dlatego tak dużą wagę przykłada się, czy też powinno się przykładać, do właściwego przygotowania projektu.

Wirtualna rzeczywistość i wirtualne zespoły

W pierwszym kroku najważniejsze jest nawiązanie dobrej relacji, komunikacji, kontaktu pomiędzy udziałowcami, stronami, uczestnikami projektu. W dobie zespołów wirtualnych praktykuje się, że pierwsze spotkanie powinno być tradycyjne, w realu, żeby wszyscy mieli okazję dobrze się poznać i nawiązać kontakt.

I takie mam doświadczenia. Po kilku spotkaniach projektowych w realu późniejsza współpraca układała się świetnie, nawet, jak był to tylko głos, czy mail. Mam też inne doświadczenie, kiedy czynione były próby nawiązania pierwszych relacji z wykorzystaniem Skype'a i maila, jednak daje to zupełnie inną jakość relacji. A tylko na dobrych relacjach można realizować dobre projekty, takie są moje przemyślenia.

Kick off projektu

Dochodzę do wniosku, że nie tylko przygotowanie projektu, zaplanowanie go i przedstawienie planu zespołowi jest celem spotkania inicjującego projekt, tzw. "kick off". Podstawowym celem jest poznanie się członków zespołu i nawiązanie relacji, dobrej współpracy. Z perspektywy mojego doświadczenia zawodowego stwierdzam, ze ludzie i relacje międzyludzkie są najważniejszym czynnikiem sukcesu projektu.

Relacje  w zespole

Kiedyś nie doceniałam znaczenia relacji międzyludzkich w zespole, ale też relacje te były dostępne "na zawołanie" - w tym samym pokoju, w tej samej firmie, czy u klienta, gdzie spotkania odbywały się regularnie, zazwyczaj w cyklu tygodniowym. W ostatnim okresie obserwuję, że pojawia się coraz więcej problemów z relacjami, problemów przy realizacji projektów w rozproszonych zespołach. Pojawiają się problemy w komunikacji, we wzajemnym zrozumieniu oczekiwań, czy też wymagań. Im więcej próbujemy pisać, tym mniej rozumiemy. Można zapisać fakty, dane, informacje, ale relacji, czy też wiedzy, nie da się zapisać, to jest integralną częścią człowieka.

Morał z tej bajki ...

Trzeba rozmawiać, spotykać się i rozmawiać, żeby się zrozumieć, dobrze zrozumieć. Dopiero na takiej bazie możliwa jest dobra i efektywna współpraca przy realizacji projektu.
I drugie przemyślenie jest takie, że praca w zespołach wirtualnych to duże wyzwanie i nowa rzeczywistość, rządząca się innymi prawami. Warto mieć tego świadomość.

Kwitną kasztany

Wiosna w pełni :)