Bez większego trudu znajdziemy materiały mówiące o tym jak wiele korzyści przyniosło zastosowanie metody Six Sigma w produkcji przemysłowej. Koncentracja na potrzebach klienta, efektywne zarządzanie procesami a przede wszystkim obniżenie kosztów produkcji przez minimalizację prawdopodobieństwa wystąpienia defektu w gotowym produkcie to hasła, które powtarzają się w opisach zastosowań SS i każą zastanowić się czy ta metodyka może być wykorzystana także w produkcji oprogramowania.

Szczególne zainteresowanie budzi kwestia orientacji działań na kliencie, który przecież definiuje każdy informatyczny produkt. Sprawne zarządzanie wymaganiami klienta jest warunkiem koniecznym do budowy długotrwałej relacji z rynkiem. Wprowadzanie kolejnych wersji, dosprzedaż dodatkowych modułów, czy też oferowanie usług abonamentowych możliwe są tylko wtedy gdy klient nie ma wątpliwości, że współpracuje z doświadczonym partnerem, który zna jego potrzeby i potrafi je zaspokoić. Sprawność w tym obszarze jest decydująca dla budowania przewagi konkurencyjnej dostawcy oprogramowania. Jak więc SS może nam pomóc w lepszym zarządzaniu wymaganiami klienta?

Przede wszystkim SS stawia na ciągły kontakt z klientem tak aby posiadany obraz jego potrzeb był stale aktualizowany i zrozumiały dla obu stron (wykonawcy i odbiorcy). Identyfikowane potrzeby muszą być uporządkowane hierarchicznie i opisane miarami określającymi ich znaczenie dla klienta. W ten sposób możemy wskazywać czynniki krytyczne dla sukcesu prac. Analizując potrzeby klienta nie możemy zapominać o elementach nieuświadomionych przez niego. Ustalając wymagania tego rodzaju pamiętać trzeba o uwzględnieniu specyfiki opracowywanego oprogramowania. W zależności o klasy produktu (oprogramowanie biurowe, gra komputerowa, system dla przemysłu, firmware, …) spełnienie innych warunków będzie decydowało o powodzeniu rynkowym (szybkość wprowadzenia na rynek, niezawodność, zgodność z przepisami prawa, wykorzystana technologia, …). Miary opisujące wymagania pozwalają śledzić zmiany w oczekiwaniach klienta oraz kontrolować na ile produkt finalny odpowiada potrzebom odbiorcy. W analizie potrzeb klienta i w zestawianiu ich z kompetencjami wykonawcy pomocna okazuje się macierz Quality Function Deployment.

Zarządzanie wymaganiami nie może ograniczyć się do klienta zewnętrznego. Budowa oprogramowania wiąże się z przygotowywaniem wielu przedmiotów dostaw na potrzeby klienta wewnętrznego (dokumenty, modele, kod, procedury, …). Wymagania klienta wewnętrznego SS traktuje na równi z oczekiwaniami końcowego nabywcy.

Potrzeby klienta zaspokajane są  przez realizowane w organizacji procesy. Ograniczenie błędów popełnianych w łańcuchu procesów jest głównym celem SS. Ciągle doskonalenie zidentyfikowanych procesów odbywa się między innymi przez zastosowanie pięciu etapów metody DMAIC. Podczas Define identyfikujemy problem i oczekiwania względem rozwiązania. Measure pozwala sparametryzować aktualny proces za pomocą miar. Miary pozwalające śledzić pracę procesów to clou SS. To statystyczna analiza wartości tych miar na etapie Analyze pozwala budować tezy na temat przyczyn błędów, generowanych przez proces. Zidentyfikowane problemy rozwiązywane są w fazie Improve. Proponowane rozwiązania muszą zawierać odwołania do miar opisujących proces. Dzięki temu w zamykającym cykl etapie Control, możemy zweryfikować skuteczność podjętych kroków. Ważne jest aby procesy, którymi zarządzamy poddawać stałej kontroli. W ten sposób śledzimy na ile utrzymywana jest wydajność procesów i czy nie wymaga ona powtórzenia prac optymalizacyjnych.

Przy stosowaniu SS w produkcji oprogramowania, pewną wątpliwość może budzić możliwość identyfikacji procesów, spełniających warunki metodyki. Trzeba pamiętać, że muszą być to procesy uruchamiane na tyle często aby dostarczać odpowiednio dużą próbką historycznych wartości miar oraz takich danych, które wykorzystamy do testowania proponowanych modyfikacji procesu a później do obserwacji zmian w realnym procesie. W przypadku klasycznego cyklu projektowo-programistycznego (wymagania, projekt, implementacja, testowanie, wdrożenie) uruchamianego 2-3 razy w roku, zdobycie danych potrzebnych do narzędzi SS, może trwać bardzo długo lub nawet okazać w ogóle niemożliwe. Wystarczy jednak przyjrzeć się projektom realizowanym przyrostowo a szczególnie w modnej ostatnio metodyce Scrum, aby wskazać procesy wywoływane wielokrotnie, nawet w ramach jednego projektu. Tak może być w przypadku analizy scrumowego sprintu (inicjacja nowego sprintu, weryfikacja wyników poprzednich sprintów, zarządzanie backlogiem). Właśnie optymalizacja takich procesów zgodnie z SS przynosi wyraźne efekty.

Znaczenie jakie mają miary w skutecznym stosowaniu SS oraz nakład pracy związany z ich monitorowaniem, wymusza bardzo staranny dobór śledzonych parametrów. Pamiętać trzeba, że kluczową rolę mają miary, które są wprost powiązane z klientem i wpływają na jego zadowolenie. Innym kryterium doboru miar jest możliwość ich śledzenia. Wartości muszą być pełne (dla każdego wywołania procesu) i wiarygodne – oddające stan rzeczywisty. Istotne jest też to aby monitorowanie miar nie było zbyt obciążające dla uczestników procesów. Dobrym rozwiązaniem jest wykorzystanie, jako źródła danych, systemów wykorzystywanych do komunikacji w procesach i składowania wyników prac. Systemy takie mogą informować o zaawansowaniu i terminowości prac o uwagach zgłaszanych przez klienta i liczbach błędów wykrywanych w testach wewnętrznych i zgłaszanych już po wdrożeniu.

Poznając możliwości oferowane przez SS trudno przejść obojętnie obok pomysłu wykorzystania tej metodyki w produkcji oprogramowania. Jeśli nawet można mieć wątpliwości co do kompleksowego wdrożenia całej filozofii SS, to nie sposób odmówić użyteczności wielu proponowanym przez nią narzędziom .