Określanie priorytetów

autorstwa Mitcha Laceya.Właściciel, Mitch Lacey & Associates, Inc. Firma specjalizuje się w przyjmowaniu i ulepszaniu Agile i Scrum.

Styczeń 2012

W tym artykule Mitch Lacey omawia trzy metody, które okazały się bardzo korzystne dla wielu zespołów stosujących metodykę zwinną: model Kano satysfakcji klienta, serię gier o innowacyjność (Innovation Games) autorstwa Luke'a Hohmanna oraz model względnych wag Karla Weigersa.Każdy z tych sposobów może pomóc przejść od zgrubnej priorytetyzacji zaległości do precyzyjnego zamawiania, które zadowalająco uwzględni wagi ryzyka, znaczenia i zadowolenia klienta.

Dotyczy

Zarządzanie cyklem eksploatacji aplikacji; Team Foundation Server

W tym artykule:

• Wprowadzenie

• Model Kano satysfakcji klienta

• Gry innowacji

  • Oczyść drzewo produktu

  • Kup funkcję

• Względe ważenie — Karl Weigers

• Wnioski

Aby zapewnić skuteczne funkcjonowanie zespołu, musisz uporządkować elementy zaległości produktu według priorytetu, a następnie aktualizować te priorytety w miarę postępu projektu.Wszystkie zaległości produktu muszą być spriorytetyzowane pod względem wartości biznesowej i ryzyka.Uznając tę kolejność priorytetów, zespół może lepiej skupić się na funkcjach, które najbardziej prawdopodobnie zadecydują o sukcesie produktu.Dobrze uporządkowane i spriorytetyzowane zaległości przynoszą korzyści nie tylko w postaci zadowolenia zespołu i klientów, ale również pod względem ekonomiczno-biznesowym dla firmy.Więcej informacji o zaległościach — zobacz Tworzenie i zarządzanie zaległości produktu, Tworzenie lub dodawanie informacji o zaległościach związanych z produktem i Optymalizacja i szacowanie zaległości.

Podczas zamawiania i nadawania priorytetów zaległości produktu, musisz wziąć pod uwagę wiele czynników jak również być w stanie uzasadnić swoje decyzje.W przypadku rozpoczęcia od surowej zaległości produktu może wydawać się, że proces sprawia ogromne trudności.Na szczęście nie trzeba doskonale uporządkować każdego elementu w swojej zaległości od razu.W temacie Szacowanie opisuję technikę o nazwie „Wielka ściana”, która jest skutecznym sposobem szybkiego oszacowania surowej zaległości produktu i pracy z zainteresowanymi stronami w celu uzyskania zgrubnej priorytetyzacji.

Ta zgrubna priorytetyzacja jest dobrym punktem wyjścia i może być wystarczająco dobra dla okoliczności.W niektórych przypadkach możesz jednak chcieć doprecyzować te priorytety lub uzyskać spriorytetyzowaną zaległość w sposób bardziej naukowy.Można to wykonać, korzystając z wielu technik.W następującym artykule omawiam trzy metody, które okazały się bardzo korzystne dla wielu zespołów stosujących metodykę zwinną: model Kano satysfakcji klienta, serię gier o innowacyjność (Innovation Games) autorstwa Luke'a Hohmanna oraz model względnych wag Karla Weigersa.Każdy z tych sposobów może pomóc przejść od zgrubnej priorytetyzacji zaległości do precyzyjnego zamawiania, które zadowalająco uwzględni wagi ryzyka, znaczenia i zadowolenia klienta.

Model Kano satysfakcji klienta

Model Kano zadowolenia klienta został opracowany w latach osiemdziesiątych przez profesora Noriaki Kano z uniwerystetu Rika w Tokio.Jego model zawiera prosty schemat klasyfikacji, który rozróżnia między atrybutami kluczowymi i różnicującymi.Wykorzystując podejście oparte na kwestionariuszu, model jest potężnym sposobem wizualizacji charakterystyki produktu oraz stymulowania debaty w zespole projektu.

W metodzie Kano zadajemy serię pytań w dwóch różnych formach: funkcjonalnej i dysfunkcjonalnej.Na przykład załóżmy, że pytamy klientów o systemy nawigacji GPS dla samochodów.Prosimy najpierw o funkcjonalną formę pytania:

• Jak być się czuł(a), gdyby ten samochód miał system nawigacji GPS?

Możemy ograniczyć odpowiedzi do następujących:

• Podoba mi się ten sposób

• Oczekuję, że tak właśnie będzie

• Jestem neutralny/-a

• Mogę z tym żyć

• Nie podoba mi się ten sposób

Dla tego przykładu załóżmy, że nasi fikcyjni klienci odpowiedzieli „Lubię to w ten sposób”.

Teraz zadamy dysfunkcjonalną formę pytania:

• Jak być się czuł(a), gdyby ten samochód nie miał systemu nawigacji GPS?

Nasi fikcyjni klienci mogą wybrać którąkolwiek z wymienionych odpowiedzi.Jednak odpowiedź może często być, i jest zwykle, różna.Na potrzeby tego przykładu załóżmy, że nasi fikcyjni klienci odpowiedzieli „Spodziewałem się, że tak to będzie wyglądać” na formę dysfunkcjonalną pytania.

Jeśli zrobimy to w rzeczywistym projekcie, możemy przekazać wykaz przeciwstawnych pytań do wielu grup odbiorców, czyli różnych zestawów osób, które reprezentują różne funkcje organizacji klienta.Może być grupa marketingowa, grupa rachunkowości, grupa produkcji itd.Jednak dla celów zrozumienia modelu wyobraźmy sobie, że zadajemy tylko jedno pytanie tylko do jednej grupy klientów.Po skompilowaniu naszej pary odpowiedzi (odpowiedzi dla formy funkcjonalnej i dysfunkcjonalnej) mapujemy ją na siatkę, jak pokazano w Tabeli 1.

Tabela 1 – Mapowanie Kano

Należy zauważyć, że w naszym przykładzie nasi fikcyjni klienci odpowiedzieli lubię na pytanie funkcjonalne i oczekuję na pytanie dysfunkcjonalne.Po mapowaniu tej pary na siatkę widzimy, że przecięciem tych dwóch atrybutów jest E, jak wskazuje żółty podświetlony kwadrat.Zbadajmy, co oznacza to dla naszego spriorytetyzowanej zaległości.

• E = stymulanci.Są to funkcje, których klient nie oczekiwał i które znacząco odróżniają produkt od konkurencji.Są one trudne do zidentyfikowania, szczególnie początkowo, ponieważ może byc trudno wymyślić zapytania, które wywołają pożyteczne funkcje.Z tego powodu stymulanci zwykle pojawiają się i zyskują na znaczeniu w miarę postępów projektu i nadchodzenie opinii od klientów.

  • Klienci są bardzo zadowoleni z tych funkcji i są skłonni zapłacić więcej za ich posiadanie.Na przykład urządzenie iPod od firmy Apple zachwyciło klientów intuicyjną możliwością obracania zawartości w celu dopasowania do orientacji ekranu.Brak takiej funkcji nie zmniejszyłby jednak zadowolenia klienta, który się jej nie spodziewa.

  • W naszym przykładzie posiadanie nawigacji GPS byłoby pożyteczną funkcją.Omówienie tej funkcji, co najmniej do punktu odbioru opinii od klientów, powinno mieć stosunkowo wysoki priorytet.

• B = bazowy.Funkcje te muszą być zawarte w produkcie.Są to niezbędne funkcje o wysokim priorytecie.

  • Niezależnie od tego, jak dobrze wykonywane są te atrybuty podstawowe, klient pozostanie neutralny wobec produktu.Edytor tekstów, na przykład, musi mieć funkcje „tworzenie dokumentu” i „zapisywanie dokumentu”.Są one ceny wejścia.

  • Jeśli zapytalibyśmy naszą grupę klientów o pasy bezpieczeństwa, większość ludzi odpowiedziałoby, że oczekują, że nowy samochód będzie miał pasy bezpieczeństwa, i że nie podobałoby im się, gdyby nie miał pasów.Jeśli zmapujemy te dwie odpowiedzi na siatkę, stwierdzimy, że pasy bezpieczeństwa są cechą bazową (B), tzn. konieczną.

• L = liniowy.Znane także jako „wymagania wydajnościowe”, funkcje liniowe są skorelowane bezpośrednio z zadowoleniem klientów.Ich priorytet spada nieco poniżej funkcji linii bazowej, ale musi być zrównoważony względem kosztów.

  • Zwiększona funkcjonalność lub jakość działania zwiększa zadowolenie klientów.Zmniejszona funkcjonalność zmniejsza zadowolenie.

  • Cena produktu jest często związana z tymi atrybutami.

• I = Obojętne.Funkcje te są najmniej ważne dla klienta i jako takie powinny być najmniej ważne w kontekście produktu.Prawdopodobnie będą zwracały niewielką wartość biznesową lub nie zwrócą żadnej.

Tabela 1 zawiera również Q i R.

• W: Wątpliwe — Pytanie jest prawdopodobnie nieprawidłowe lub odpowiedź jest podejrzana.

• O: Odwrotna — kombinacja odpowiedzi nie wykonuje obliczeń.Weźmy na przykład system nawigacji GPS — jeśli ktoś odpowie, że oczekuje jego obecności, ale jeśli go nie będzie, to też będzie dobrze – jest to odpowiedź R.

Jeśli para odpowiedzi jest sklasyfikowana jako Q lub R, należy sprawdzić pytanie lub parę odpowiedzi bardziej głęboko.

Gry innowacji

Gry o innowacyjność są narzędziami pomagającymi tworzyć podstawowe badania rynku.Za pomocą tych narzędzi klienci „grają” w celu generowania opinii i informacji dotyczących produktu lub usługi.Luke Hohmann opracował i opisał ponad 12 takich gier w swojej książce Innovation Games, który jest świetnym dodatkiem do każdej biblioteki.Moje ulubione dwie gry pozwalające spriorytetyzować zaległość to Przytnij drzewo produktu i Kupić funkcję, które Luke opisuje w swoim wyciągu z tej książki (ma na to zgodę):

Oczyść drzewo produktu

Ogrodnik przycina drzewa, aby ograniczyć ich wzrost.Czasami oczyszczanie daje efekty artystyczne, co powoduje, że powstają kształty zwierząt z krzewów lub interesujące abstrakcyjne kształty.Najważniejszym celem przycinania jest stworzenie zrównoważonego drzewa, które daje wysokiej jakości owoce.Proces nie polega na "obcinaniu", a na "kształtowaniu". Z tej metafory można korzystać, aby było łatwiej utworzyć produkt, którego żądają klienci.

Gra

Zacznij od narysowania dużego drzewa na tablicy lub grubym papierze bądź wydrukowania obrazka przedstawiającego drzewo (w dużym formacie w formie plakatu)Grube konary reprezentują główne obszary funkcjonalności w obrębie systemu.Krawędź drzewa — odgałęzień peryferyjnych — reprezentują funkcje dostępne w bieżącej wersji.Zapisz potencjalnie nowe funkcje na kilku kartach indeksu w kształcie liści.Poproś klientom, aby rozmieścili żądane funkcje na drzewie, definiując w ten sposób następną fazę jego rozwoju.Czy mają strukturę drzewa, który rozwija się w sposób zrównoważony?Czy większość rozwoju przypada na jedną gałąź, na przykład kluczową funkcję produktu?Czy wszystkie niedostatecznie wykorzystane aspekty drzewa ulegają wzmocnieniu?Wiemy, że korzenie drzewa (infrastruktura pomocy technicznej i wsparcia klienta) muszą sięgać przynajmniej na szerokość korony.A Twoje?

Drzewo produktu — Hohmann

Dlaczego działa

Ty i Twoi klientów wiecie, że funkcje mają różne znaczenie.Mamy zwyczaj wkładania wysiłku w naważniejsze aspekty — te, które są najcenniejsze dla klientów.Niestety czasami oznacza to, że nasz wysiłek był niewystarczający do utworzenia funkcji, które są potrzebne do ukończenia produktu.Przycięcie w grze Drzewo produktu zapewnia klientom możliwość wprowadzania danych do procesu podejmowania decyzji, patrząc na zestaw funkcji, które obejmują produkt w sposób całościowy.

Kup funkcję

Która funkcja nakłoni klientów do zakupu produktu?Która funkcja nakłoni klientów do uaktualnienia?Która funkcja spowoduje taki wzrost zadowolenia klientów, że zignorują lub będą tolerować funkcje, które chcieliby naprawić lub usunąć?

Planiści produktu prowadzą niekończące się rozmowy na temat tych i innych rodzajów pytań.Wybór poprawnego zestawu funkcji w celu dodania do wersji często decyduje o różnicy między szybkim niepowodzeniem a długoterminowym sukcesem.Niestety zbyt wielu planistów produktu dokonało tego wyboru bez angażowania osób najbardziej zainteresowanych — swoich klientów.Gra Kup funkcję poprawia jakość niniejszej decyzji, zadając klientom pytania z prośbą o pomoc.

Kup funkcję — Sterne

Gra

Utwórz listę potencjalnych funkcji i podaj dla każdej cenę.Podobnie jak w rzeczywistym produkcie, cena można być oparta na koszcie opracowania, wartość dla klienta lub czymś innym.Chociaż cena może być kosztem rzeczywistym, który zamierzasz pobierać za funkcję, zazwyczaj nie jest to wymagane.Klienci kupują funkcje, których chcą w następnej wersji produktu, za pomocą fikcyjnych pieniędzy, które im dajesz.Należy upewnić się, że niektóre funkcje są wycenione na tyle wysoko, że żaden nabywca ich nie kupi.Zachęcaj klientów do kumulowania pieniędzy w celu zakupu funkcji szczególnie ważnych lub kosztownych.Pomoże to stymulować negocjacje między klientami w sprawie najważniejszych funkcji.

Ta gra działa najlepiej, jeśli w grupie znajduje się czterech do siedmiu klientów, aby klienci mogli mieć więcej możliwości gromadzenia swoich pieniędzy poprzez negocjacje.W przeciwieństwie do gry Pudełko produktu, gra Kup funkcję opiera się na liście funkcji, które mogą być w przewodniku programowania.

Dlaczego działa

Często planiści produktu wpadają w pułapkę, myśląc, że klienci posiadają jasno zdefiniowane priorytety produktu.Niektóre tak.Większość nie.Gdy prezentowany jest zestaw opcji, wielu klientów po prostu powie "Chcę je wszystkie." i przerzuci na użytkownika odpowiedzialność za nadawanie priorytetów ich żądaniom.Alternatywnie menedżerowie produktów często zbierają informacje o priorytetach funkcji przez bezpośredni kontakt z klientami i w ten sposób, prawdopodobnie nawet nie zdając sobie sprawy, ponownie przejmują odpowiedzialność za ustalenie priorytetu funkcji.Przez zaangażowanie klientów jako grupy i przekazanie im ograniczonej ilości zasobów można dać im możliwość spriorytetyzowania oczekiwań w kontekście całej grupy.Ale nie tam kryje się magia.Magia polega na strukturyzacji rozmowy, dzięki czemu klienci negocjują ze sobą na temat konkretnych funkcji.To właśnie te negocjacje pozwalają lepiej zrozumieć, co klienci chcą naprawdę.

Względe ważenie — Karl Weigers

Inną doskonałą metodą priorytetyzowania jest względna waga, którą Karl Weigers wprowadził w 1999 r.Metoda ta nie tylko udostępnia mechanizm priorytetyzowania wymagań na podstawie danych wejściowych użytkownika i opinii, ale obejmuje również ocenę eksperta w zespole.Podobnie jak Kano i gry o innowacyjność, metoda względnej wagi umożliwia właścicielowi produktu lepsze mierzenie, które funkcje zaimplementować i w jakiej kolejności priorytetów.

Pierwszym krokiem jest przypisanie wagi do względnej korzyści z funkcji.Korzyść to zaleta dla użytkowników wynikająca z posiadania funkcji w produkcie końcowym.Następnie należy przypisać względną karę.Kara jest konsekwencją dla użytkowników nieposiadających funkcji w produkcie końcowym.(Ocena korzyści i kar pozwala osiągnąć to samo, co funkcjonalna i dysfunkcjonalna forma pytania w metodzie Kano). Wagi są arbitralnymi liczbami ukazującymi, jak dana firma traktuje korzyści i ryzyko związane z funkcjami.To bardzo podobne do sposobu, w jaki nauczyciel określa, jakie wagę nadać pracom domowym, uczestnictwu, sprawdzianom i testom w ustalaniu łącznej oceny; różni się to między nauczycielami.Jeśli zdecydujesz, że korzyści przeważają nad karami, wprowadź wagę wyższą niż dla kary o współczynnik, który uznasz za stosowny.Jeśli zdecydujesz, że kary przeważają nad korzyściami, odpowiednio dostosuj wagi.W przykładzie w tabeli 2 korzyści przypisujemy względną wagę 2, a karze względną wagę 1, co oznacza, że korzyść będzie miała większy współczynnik przy określaniu priorytetu końcowego.

W ten sam sposób określamy wagi procentu kosztów i procentu ryzyka.W poniższym przykładzie ryzyko nie było poważnym problemem w projekcie, dlatego procentowi kosztów przyznano wagę 1, a procentowi ryzyka wagę 0,5.(Należy zauważyć, że chociaż korzyści i kary są ważone przed obliczeniem wartość procentowej, koszt i ryzyko są ważone jako wartości procentowe.) Jeśli masz projekt o wysokim ryzyku, możesz nadać większą wagę ryzyku niż kosztowi.

Teraz gdy wagi są ustawione, prosimy użytkowników o określenie względnej korzyści i względnej kary każdej funkcji.Każda korzyść i kara jest sklasyfikowane na ustalonej skali — Weigers zaleca 1-9, ale można wybrać inną skalę, o ile jest ona spójna.Względna korzyść to wartość, którą będzie dostarczać funkcja; względna kara to potencjalny negatywny wpływ nie zaimplementowania funkcji.

Załóżmy na przykład, że jedna z możliwych funkcji to „Sprawić, aby widżet był zgodny z przepisami ustawy Sarbanesa-Oxleya”. Praktycznie nie ma tu względnych korzyści dla użytkowników, ale względna kara dla firmy jest duża — nie wprowadzenie tej funkcji mogłoby wyeliminować firmę z rynku.W związku z tym możemy zobaczyć wynik 1 lub 2 dla względnych korzyści i wynik 8 lub 9 dla względnej kary.

W poniższym przykładzie użytkownicy ocenili względną korzyść funkcji „Zapytanie o stan zamówienia do dostawcy” jako 5.Względna kara została oceniona na poziomie 3.Aby uzyskać całkowitą wartość tej funkcji, mnożymy dwie liczby przez ich względne wagi i dodajemy do siebie:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

W tym przypadku całkowita wartość dla funkcji wynosi 13 punktów.

Gdy uzyskamy całkowitą wartość względną i procentową wartość dla funkcji, możemy odejść od użytkowników, aby uzyskać wgląd od strony zespołu.Prosimy zespół o oszacowanie względnego kosztu w celu zaimplementowania każdej funkcji przy użyciu tej samej skali.Karl Weigers wyjaśnia: „Deweloperzy szacują koszty na podstawie czynników takich jak złożoność wymagań, zakres koniecznych prac z interfejsem użytkownika, potencjał wykorzystania już istniejących projektów lub kodu oraz wymagany poziom testowania i dokumentacji”.

Po oszacowanie względnego kosztu szacujemy względne ryzyko.Ponownie mówi Weigers: „Deweloperzy szacują względny stopień ryzyka technicznego i innego skojarzonego z każdą funkcją w skali od 1 do 9.Oszacowanie 1 oznacza, że można zaprogramować go z pełnym komfortem, podczas gdy 9 oznacza poważne obawy dotyczące wykonalności, dostępności personelu z potrzebnym doświadczeniem lub korzystania z niesprawdzonych lub nieznanych narzędzi i technologii.Arkusz kalkulacyjny obliczy procent całkowitego ryzyka dla każdej funkcji".

Po spisaniu wartości względnych korzyści, kary, kosztu i ryzyka podsumowujemy każdą kolumnę.Sumy te będą używane do obliczania wartości procentowych.

• Suma wartości procentowych: podziel wartość sumy względnych korzyści i kar przez sumę u dołu.W poniższym przykładzie jest to 13 / 154 = 8%.

• Względny procent kosztu: podziel względną wartości kosztów przez całkowitą względną sumę u dołu.W poniższym przykładzie jest to 2 / 42 = 4,8%.

• Względny procent ryzyka: podziel względną wartości ryzyka przez całkowitą względną sumę ryzyka u dołu.W poniższym przykładzie jest to 1 / 33 = 3%.

• Priorytet: Podzielić wartość procent (procent kosztów * waga kosztów) + (procent wartości * waga wartości).W poniższym przykładzie jest to 8,4% / ((4,8% * 1) + (3% * 0,5).Daje to wartość priorytetową (1.345).

Po otrzymaniu wartości priorytetów posortujemy kolumnę priorytetu w kolejności malejącej, tak aby elementy o najwyższym priorytecie były u góry.Wraz z dodawaniem elementów do listy zaległości produktu lub pojawianiem się kolejnych informacji o historyjce potrzebujemy ponownej ocenić priorytet.

Na koniec arkusz wygląda jak ta tabela:

Przyjmując takie podejście, można lepiej zrozumieć zakresy, które działają dla zespołu i zainteresowanych stron.Również pomaga sprowadzić dyskusje do przyziemnych aspektów, ponieważ może być trudne obiektywne uwzględnienie elementów takich jak korzyść, kara, koszt i ryzyko dla każdej funkcji.

Weigers objaśnia urzeczywistnienie modelu, który bardziej pasuje do realiów użytkownika:

„Umożliwia skalibrowanie tego modelu do własnego użytku z zestawem gotowych wymogów lub funkcji z poprzedniego produktu.Dopasowuj współczynniki wagowe, aż obliczona kolejność wg priorytetów będzie zgadzać się z ocenę po fakcie, jak ważne rzeczywiście były wymogi określone w zestawie testowym.Ten model może również ułatwić podjęcie decyzji kompromisowych, gdy oceniasz proponowane nowe wymagania.Oszacuj ich priorytety przy użyciu modelu, aby stwierdzić, jak pasują do istniejących wymogów, tak aby można było wybrać właściwą sekwencję wdrożenia.Wszelkie czynności, które można wykonać, aby przenieść priorytetyzację wymagań z kontekstu pozamerytorycznego na obiektywny i analityczny, zwiększą prawdopodobieństwo, że projekt dostarczy najważniejsze funkcje w najbardziej odpowiedniej kolejności.”

Karl Weigers napisał dwie książki w celu bardziej szczegółowo omówienia kwestii względności wag: Software Requirements, wydanie drugie i More About Software Requirements: Thorny Issues and Practical Advice.

Bez względu na to, czy używasz jednej z następujących metod, czy jakiejś innej techniki, musisz pamiętać, że zaległości produktu mają podstawowe znaczenie.Nie wystarczy raz nadać priorytetu i odłożyć na bok — ponowne priorytetyzowanie jest oczekiwaną częścią utrzymania zdrowych zaległości.Aby kontrolować projekt na bieżąco, użytkownik musi stale dokonywać ponownej oceny historii, ich znaczenia w projekcie i sposobu, w jaki nowe informacje wpływają na zaległości.Należy zadać sobie trud, aby utrzymać zainteresowanie udziałowców i klientów przez cały czas trwania projektu.Ponadto należy pamiętać, że oszacowanie elementu ma podstawowe znaczenie przy określaniu jego priorytetu.Nie pozwól, aby zaległości stały się przestarzałe i wygasły.Inwestuj czas i wysiłki w rozwijanie i porządkowanie zaległości — zobaczysz wyniki nie tylko w produkcie końcowym, ale także w rachunku ekonomicznym firmy.

Zobacz też

Koncepcje

Rozpoczynanie jako zespół

Planowanie Agile i iteracje

Żądanie i opinie zainteresowanych stron procesu przy użyciu programu Access w sieci Web zespołu

Śledzenie pracy i zarządzanie przepływem pracy

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   „Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, tom14, nr 2, październik 1984 r.Oryginalny artykuł z Kano.

2. http://www.processimpact.com/articles/prioritizing.html