Czasem wydaje się, że aby robić solidne, profesjonalne wrażenie, trzeba zajmować się sprawami skomplikowanymi, dla innych niezrozumiałymi, posługując się dość hermetyczną terminologią.
Branża IT ma tak wiele specjalności, że dla każdego znajdzie się obszar, gdzie można zajmować się swoimi – cytując Stanisława Lema [przypis 1] – „uczonymi ekspertyzami”, nie narażając się na konieczność zejścia z sacrum wiedzy wysokiej do profanum pytania, „A o co tak naprawdę nam chodzi?”.
Patrzenie wąskie, czy całościowe, interdyscyplinarne
Zastanawiałem się ostatnio, jakimi to tematami należałoby wzbogacić CV, aby móc skutecznie próbować podwyższyć pensję dwukrotnie – niezależnie od tego, co robi się dzisiaj. Oczywiście, nie chodzi o to, aby chwalić się swoją wszechstronnością, bo to nie popłaca. W IT nie ceni się raczej ludzie wszechstronnych, interdyscyplinarnych. Znam wiele osób, które z bardzo wąskiej fachowości uczyniły sobie stałe źródło dochodu, można ich spotkać na kolejnych konferencjach lub warsztatach, opowiadających wciąż o tym samym, i wciąż budzących zainteresowanie słuchaczy. Chodzi o to, aby w zapasie mieć szereg modnych pojęć i tematów, i zależnie od potrzeb, móc symulować fachowość w każdym z nich.
Artykuł pochodzi z 4 numeru magazynu ITwiz.Proszę mnie źle nie zrozumieć – nie neguję potrzeby i wagi każdej z tych wąskich dziedzin, a może nawet przemawia przeze mnie osobista zazdrość, że moja skłonność do patrzenia całościowego (ładniej: integralnego) nie zapewnia mi takiej popularności i dochodów, jakie mi się marzą? Rzecz w tym, że oprócz specjalizacji i związanego z nią spojrzenia analitycznego, konieczne jest spojrzenie syntetyczne, które wciąż jest zaniedbywane.
Czytelnik ma prawo spytać: „Konieczne? – a któż nam to nakazuje? W końcu umiemy robić biznes i widać wiemy, co jest ważne”. Przyjmuję tę uwagę – jest to konieczne, tylko, jeśli chcemy przyłączyć się, lub nadal aktywnie uczestniczyć w międzynarodowym rynku nowych technologii. Aby móc osiągnąć innowacyjność, zwiększać udział naszych firm na rynkach, gdzie dominują w tej chwili firmy z krajów od lat specjalizujących się w wysokich technologiach, musimy jeszcze lepiej niż dziś umieć patrzeć interdyscyplinarnie [2].
Co „powinniśmy” wiedzieć
Wracając do wątku, te tematy, o których zdecydowana większość interesariuszy i uczestników projektów IT/ICT, poza grupkami specjalistów, niewiele wie, a o których dobrze jest coś wiedzieć, lub umieć udawać, że się coś wie, to: modelowanie procesów biznesowych, BPMN, analiza biznesowa, architektura korporacyjna, Big Data, IT a biznes, zarządzanie projektami (PMI, PRINCE 2, IPMA), DevOps (ITIL), bezpieczeństwo (COBIT), agile plus lean, oraz programowanie metodami BDD / TDD / DDD.
Jeśli chcemy przyłączyć się, lub nadal aktywnie uczestniczyć w międzynarodowym rynku nowych technologii. Aby móc osiągnąć innowacyjność, zwiększać udział naszych firm na rynkach, gdzie dominują w tej chwili firmy z krajów od lat specjalizujących się w wysokich technologiach, musimy jeszcze lepiej niż dziś umieć patrzeć interdyscyplinarnie.
Teraz kluczowe pytanie: co łączy te pozornie różnorakie i różnorodne dziedziny? Odpowiedź: ukrywa się w nich, pod pseudonimem, INŻYNIERIA WYMAGAŃ. Tymczasem inżynieria wymagań, to dziś wciąż najczystsza egzotyka! Nie słyszeli Państwo o takiej gałęzi inżynierii oprogramowania? To dobrze, to znaczy, że jesteście na czasie i na bieżąco, bo mało kto o niej u nas słyszał, poza światem akademickim. A jednak, to dziedzina absolutnie kluczowa dla powodzenia wszelkich przedsięwzięć w IT: zajmuje się określaniem celu biznesowego przedsięwzięć, definiowaniem założeń projektów, precyzowaniem wymagań wobec budowanych systemów.
Wymagania biznesowe (wysokopoziomowe) umożliwiają oszacowanie opłacalności inwestycji IT, dzięki wymaganiom szczegółowym (zwanym też systemowymi) udaje się w miarę trafnie oszacować pracochłonność i koszty projektu, śledzić, czy nie grożą opóźnienia, a w końcu potwierdzić, czy założenia wdrożenia zostały zrealizowane, podpisać protokół odbioru, wystawić fakturę. Badania wykazują (tutaj mógłbym odwołać się do setek prac badawczych), że pierwotną przyczynę niepowodzeń projektów w ponad 50% można wywieść z błędów lub zaniechań tej pozornie nieistniejącej inżynierii wymagań.
Jak to możliwe, aby – parafrazując słowa Winstona Churchilla [3] – tak wiele zależało od czegoś tak nieznanego? Nie chcę snuć rozważań, z jakiego powodu inżynieria wymagań dotąd nie jest w przemyśle IT postrzegana jako odrębna dziedzina, bo to byłyby rozważania społeczno-historyczne. Że tak jest, pokażę krótko, bo już o tym pisałem wielokrotnie ( [4] [5]) i nie chcę się powtarzać. Na samym końcu postaram się jeszcze wykazać, na jakiej podstawie sądzę, że inwestycja w inżynierię wymagań jako w osobną, interdyscyplinarną dziedzinę wiedzy [6], opłaci się, owocując dramatycznym wzrostem wydajności.
Inżynieria wymagań schowała się w…
…jakże modnym zarządzaniu projektami – w istocie, sylabusy PRINCE 2 lub PMBOK, poświęcone są co najmniej w 30% tematyce określania i monitorowania stopnia realizacji celów projektu, czyli inżynierii wymagań. Odkryć ją można w pachnącym wyższymi sferami – równie mocno, jak tor wyścigowy w Ascot perfumami – modelowaniu i ulepszaniu procesów biznesowych (BPM). Zgoda, często zamiar wdrożenia systemu IT jest częścią szerszego zamiaru usprawnienia biznesu, a ulepszać biznes, to znaczy obcować z bogami. To ważna dziedzina, mająca się do inżynierii wymagań jak wierzchołek góry lodowej do jej znacznie większej, podwodnej części.
Analiza biznesowa, w skład której wchodzi BPM, to nieco większy czubek tej góry lodowej. Dla niektórych rodzajów projektów – przy tworzeniu systemów IT wspierających procesy biznesowe – bardzo ważna, dla innych – np. technicznych – nieistotna. Ciekawostka, to właśnie analiza biznesowa dała nam mylącą i wieloznaczną, szkodliwą i dominującą nazwę analityka dla inżyniera wymagań.
Kiedy wymagań brak, to programistom przypada w udziale wątpliwy zaszczyt ich wymyślania, czy domyślania się, i przywilej wysłuchiwania (trafnych!) zarzutów, że programiści nie rozumieją potrzeb użytkowników. Jasne, że nie rozumieją, zwłaszcza, jeśli użytkownicy chronicznie nie mają czasu i nie widzą potrzeby, aby to wyjaśniać.
Architektura korporacyjna to próba pójścia na skróty, wprost od celów organizacji, poprzez jej strukturę, która (zapewne), realizacji tych celów najbardziej sprzyja, aż do domniemanej najlepszej architektury systemów IT, stosownych dla takiej organizacji i jej procedur. Wymagania są w tym wszystkim rozsiane, niczym bakalie w keksie, ale nie mówi się o nich niestety wprost, tylko w kontekście wzorców realizacji, co jest – delikatnie mówiąc – ryzykowne, bo opuszcza potrzebne fragmenty rozumowania.
W przypadku metod zwinnych (agile, lean) – po odjęciu z nich całej ideologiczno-technicznej otoczki – można z dużym uzasadnieniem stwierdzić, że główna różnica między nimi a innymi podejściami polega właśnie na odmiennym traktowaniu wymagań. Agile głosi, że wymagania należy zdobywać iteracyjnie, a realizować przyrostowo, że nieskutecznym marnotrawstwem są próby określenia wymagań z góry i traktowania ich jako niezmiennych, „wykutych w kamieniu”, cechujące wiele metodyk nie-agile.
Inny przykład zastosowania inżynierii wymagań to programowanie. Kiedy wymagań brak, to programistom przypada w udziale wątpliwy zaszczyt ich wymyślania, czy domyślania się, i przywilej wysłuchiwania (trafnych!) zarzutów, że programiści nie rozumieją potrzeb użytkowników. Jasne, że nie rozumieją, zwłaszcza, jeśli użytkownicy chronicznie nie mają czasu i nie widzą potrzeby, aby to wyjaśniać.
Testowanie także korzysta z dobrodziejstw inżynierii wymagań. Kto decyduje, jakie są wymagania, kiedy wymagań brakuje? Aby zdecydować, czy coś działa poprawnie, czy nie, musi określić, co jest poprawne, czyli albo sięgnąć do wymagań, albo je w miarę potrzeby stwarzać, albo rekonstruować.
Badanie rynku – w typowej korporacji pracownicy działu marketingu i działu IT to dwa odmienne światy – siedzą osobno, jeżdżą innymi markami samochodów, różnią się nawet strojem. A przecież większość produktów IT nie jest dziś robiona na zamówienie, tylko sprzedawana na wolnym rynku, gdzie potrzeby klientów stara się, ze zmiennym szczęściem, określić dział marketingu właśnie. Czyli dla sukcesu firmy niezbędna jest ich ścisła współpraca [7].
Dlaczego warto więcej uwagi poświęcić inżynierii wymagań?
Sprawdźmy prosty przykład. Najpowszechniejszy w tej chwili na świecie certyfikat wiedzy inżynierii wymagań IBRE CPRE [8] ma w tej chwili na świecie ok. 17 000 osób, z tego w Polsce… 18 [9]. Tak, to tylko przykład, powierzchowny, ale bardzo znamienny. W Niemczech ma go 10 000 osób, w Szwajcarii – ponad 4 000. Aby więc móc osiągnąć innowacyjność, zwiększać udział naszych firm na rynkach, gdzie dominują w tej chwili firmy z krajów od lat specjalizujących się w wysokich technologiach, musimy jeszcze lepiej niż dziś umieć patrzeć interdyscyplinarnie.
Bogdan Bereza jest wiceprezesem Polskiego Stowarzyszenia Inżynierii Wymagań, inżynier jakości oprogramowania, właściciel firmy Victo.
Zapraszamy na Turniej Inżynierii Wymagań (RE Challenge), który odbędzie się 4-5 marca 2015 r. ITwiz został jego partnerem medialnym.Przypisy
1. „A któż to widział, żeby komissye i doktorzy hab. cich., i uczone ekspertyzy, i rewidenci, i kontrrewidenci, i mikroskopy na kopy, a nikt nic, ni pary z gęby, jeno w kucki a w kucki? To ja tu teraz powiadam Veto, Grólu Zbawnucy, i Veto, panowie bracia, i Veto, czyli nie masz zgody na ciebie, Kąciarzu Bezecny, i póki ciebie, tedy tu g… będzie, nie Harmonia Sfer!!!” – Stanisław Lem, „Opowieść drugiego odmrożeńca”.
2. „Do IT with Poland – sektor IT motorem napędowym polskiej gospodarki”, Agencja M Promotion, mpromotion.com.pl
3. http://en.wikipedia.org/wiki/Never_was_so_much_owed_by_so_many_to_so_few
4. ISO/IEC/IEEE 29148:2011, Requirements engineering (http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171)
5. MDRA – Market-Driven Requirements Engineering, mało znana jeszcze dziedzina, ale bardzo przyszłościowa.
6. Internationa Requirements Engineering Board, Certified Professional in Requirements Egineering: http://www.ireb.org/en/international/polski.html
7. http://www.ireb.org/en/service/statistics.html
