Pozwól, że zadam ci pytanie: Czy jako kierownik produktu lub szef scruma uważasz, że istnieje punkt krytyczny, w którym konsekwencja przeradza się w tyranię?

Pytanie to zadałem kilku biednym, niczego nie podejrzewającym ludziom podczas niedawnych spotkań produktowych i Agile Meetup w okolicach Raleigh. Moją nagrodą były liczne potwierdzenia, że takie głupie hobgobliny istnieją.

Ostatnio, po umieszczeniu mojego pytania w różnych kanałach mediów społecznościowych, jestem przekonany, że my, w branży dostarczania oprogramowania, czasami rzeczywiście zniewalamy się w imię spójności.

Więc rozpakujmy to trochę i zobaczmy, czy nie możemy się zgodzić co do tego, jak taki punkt krytyczny mógłby wyglądać …. poprzez zbadanie najpierw, czym on nie jest.

Mądra spójność

Jednym z przykładów korzystnej spójności dla menedżerów produktu jest sposób, w jaki tworzymy nasze historie użytkownika. Na przykład, lubię stosować zasadę INVEST – NIE jako gotową receptę, ale raczej jako przewodnik, aby upewnić się, że nie proszę moich zespołów o zjedzenie słonia w całości w jednej historyjce użytkownika.

Inny przykład dobrej konsekwencji pochodzi ze świata UX, a konkretnie z szóstego rozdziału książki Dona Normana „The Design of Everyday Things”. Norman twierdzi tam, że ci z nas, którzy mają doświadczenie w prowadzeniu samochodu, są w stanie poradzić sobie z marką i modelem, którego nigdy wcześniej nie obsługiwaliśmy, ze względu na konsekwentne rozmieszczenie takich elementów jak pedał gazu i lusterka boczne.

Steve Krug posługuje się tym przykładem w rozdziale „Billboards Design 101” w swojej zachwycającej książce „Don’t Make Me Think”. Krug czyni skuteczne argumenty w imieniu rozpoznawania nad zapamiętywaniem, zwłaszcza jeśli chodzi o zabiegi hierarchii wizualnych, hiperłączy i układu treści.

Jednakże Krug argumentuje również, że to, czego ostatecznie chcemy, to dążenie do jasności, z mądrym wykorzystaniem spójności jako skutecznego środka, aby się tam dostać. W tym samym rozdziale Krug ostrzega:

I na koniec słowo o spójności.

Często słyszy się, że spójność jest absolutnym dobrem. Ludzie wygrywają wiele argumentów projektowych po prostu mówiąc „Nie możemy tego zrobić. To nie byłoby spójne.”

Skonsekwencja jest zawsze dobrą rzeczą, do której należy dążyć na swojej stronie lub w aplikacji. Jeśli na przykład Twoja nawigacja jest zawsze w tym samym miejscu, nie muszę się nad tym zastanawiać ani tracić czasu na szukanie jej. Ale będą przypadki, w których rzeczy będą bardziej przejrzyste, jeśli sprawisz, że będą nieco niespójne.

Tyrańska spójność

Mój cytat otwierający pochodzi z książki Emersona pt.Reliance,”eseju, który stanowi przekonujący argument za tym, by ludzie myśleli samodzielnie, zamiast godzić się na los często kojarzony z urwiskami i lemingami.

Jak wspomniałam wcześniej, zadałam moje pytanie otwierające w różnych kanałach społecznościowych i na Meetupach. Poniżej przedstawiam zebrane przeze mnie przykłady, które moim zdaniem demonstrują głupią, jeśli nie despotyczną konsekwencję:

• Mistrz scrumowy wkurzający się, jeśli deweloper nie stworzy historii JIRA, aby poprawić literówkę w artefakcie README.md.
• Redaktor organizacji informacyjnej, który nalega, aby natywna aplikacja mobilna obsługiwała dokładnie te same 150 sekcji, co ich desktopowe rozwiązanie oparte na przeglądarce, aby nie dezorientować użytkowników.
• Kierownik projektu, który utrzymuje, że planowanie wydajności jest jedynym i prawdziwym sposobem na zapewnienie klientowi tego, za co zapłacił, ponieważ bardziej nowoczesne podejścia do dostarczania oprogramowania są zbyt niepewne.
• Ktoś z terenu pyta „Czy nie ma sposobu, aby wszystkie zespoły programistów zrównały się w sposobie wymiarowania historii?”
• Architekt argumentujący za Big Design Up-Front wszystkiego dla każdego scenariusza, ponieważ upiera się, że jest to jedyny sposób, aby wiedzieć, co budować, aby wspierać zestaw funkcji.
• Klient żądający, aby wyniki dostarczane przez nową infrastrukturę wyszukiwania pełnotekstowego opartą na Lucene były w 100% identyczne z tymi zwracanymi przez odchodzącą implementację bazy danych NoSQL.
• Menedżer produktu, który odmawia przyjęcia historii użytkownika od innych, chyba że są one bezbłędnie sformatowane i wyczerpująco wypełnione przy użyciu szablonu TPS i towarzyszącej mu okładki.

Wynikiem takich scenariuszy jest frustracja, którą nasze zespoły programistów znoszą jako niewolnicze przywiązanie do spójności … dobrze zamierzone, ale błędne ustalanie priorytetów, które znacznie utrudnia im zdolność do szybkiego i ciągłego odkrywania i dostarczania właściwych, wartościowych funkcji.

Dodatkowa mądrość

Inni mądrzejsi ode mnie również ostrzegali przed głupim podporządkowaniem się spójności; poniżej znajduje się kilka przydatnych adresów URL, które odwiedziłem w ramach przygotowań do tego wpisu.