Lesson learned from ABE 2015

I gathered a killer idea from a ABE 2015 lecture. Ready??

So, the one is that listening carefully to an user voice you will come to conclusion that the thing which really matters are non-functional requirements.

Functional requirements are just only effects of decomposition, clarification and specification non functional reqs.

That's all for now. Need to think more about this concept :)

Listen to Your Product

This year at Agile 2014 I met Raje Kailasam who talked about very interesting approach which is Product Humanization (PH). As Raje claims, she's still searching for a good name. She also consider Product Persona as a name. As you'll see later on, Product Experience (PX) seems to be good name as well.

In short, PH/X is an idea to stand in your product's shoes and feel what it feels. Sounds awkward, huh? Let's take a deeper insight.

If I asked you about next features or a next sprint scope, you would start thinking about answers but in the same time this process would be biased by doubts related to: budget, velocity, technical dept or whatever. That is because your logical thinking tries to find 'the best' answer according to you current situation.

But when you identify yourself with your product, you may employ whole your body to this process and express what the product feels (if it could) and what it think as well.

Take a look on free-style examples we recorded at the conference.





During this short session we also draft two techniques employing Raje's approach.

Product Interview

Purpose of this technique is to grab some deeper knowledge about current state of a product. One of the Scrum Team members plays the product role, rest of the Team interview him or her.

We found the critical part is questions you ask the product. These seem to work well:

• What do you as an entity want to be?
• What do you want to do?
• Where do you want to go?
• How do you want to be served?
• Why do you want to exist?
• What do you want to see?
• With whom do you want to belong?
• Who are your friends?
• How do you feel now?
• How do you feel about your future/past?
• How do you feel about your body? Tell me more about it?
• Which of the part of your body you are aware the most now?
• What do you feel about your relationships? Which are difficult? Which are not?
• What is important to you?
• What do you want to say? To whom?

Use collected answers to improve Product Goal, Releases, Epics, Product Canvas or to identify places to introduce improvements to increase business value.

Product Advocate

It is about employing an advocate of the product during Scrum planning meeting.

The Advocate tells the Team and PO how s/he feels about new stories, sprint goal and scope. Use the answers to improve Sprint Goal, User Stories, scenarios.

These is early draft of Product Humanisation. Watch Raje's activity to stay up to date.

Conversation Patterns: Questions for Setting Priorities

This article is part of my work on Conversation Patterns for Software Professionals

---

Before we we'll talk about questions for setting priorities, we need to take a look at this issue from a stakeholder point of view. So, you are Stakeholder and I am Developer. Context is you want me to to deliver hot dogs to your team :) Here is our conversation:

You: Listen, we are waiting for hotdogs for four hours and we are starving. So, hurry up, pleeeease... Me: Ok, ok! We are doing our best. When do you want them delivered? You: When!? Four hours ago! Me: I have a solution for you. Let's talk about your priorities. What is the most important for you: bun, sausage, or ketchup? You: What? They are all equally important! Me: It's impossible. Choosing priorities allows you to have your wants at least partially done. It is for your own good to prioritize your requirements. Besides, there is no two things in the world being equally important. So, again: bun, sausage, or ketchup? You: But they ARE ALL important for us !^%@!#&!

Maybe the dialogue above sounds funny and you discovered a solution during a first reading. But it presents the structure of a typical conversation between a stakeholder and a developer.

The main issue is two points view. For most stakeholders their requirements are atomic. No matter how large they are: one LOC change or four-week long teamwork. For a stakeholder requirement is mostly atomic by design.

What Is The Need?

To set priorities the stakeholder need must be recognized first and this may be one of: an expected benefit or a problem to be solved.

To be clear, a human being is a really complicated object and the only things we have are models of its behaviour. All models are simplifications, but the may by useful or not. My model assumes that every requirement (functional, architectural or so on) of a stakeholder is driven by a need (an expected benefit or a problem to be solved or both). This model is extremely useful, so that I recommend it.

Questions for Discovering the Need (in the Priorities Context)

A stakeholder is mostly focused on the thing he wants, so it is good for your conversation to help him/her to name the need.

We'll use the Drilling Question Pattern. We'll ask a question with a presupposition there is a need back to the requirement. Because there are two types of a need (an expected benefit or a problem to be solved) you may ask two questions. One for presupposing an expected benefit and next one for presupposing a problem to be solved.

A structures for these questions are:

• If you would to start [a benefit presupposed] now, what it would be?
• If [a problem presupposed], which one you would give up first?

As you can see, assuming a benefit we asking for "achieving", but assuming a problem we asking for "avoiding". Some explanation of it you may find in article Don't Confuse a Need with a Feature.

You probably wondering: "Ok, but what kind of an expected benefit or a problem to be solved I should presuppose in my case"? Obviously it depends :) I'll give you a tip how to start.

There are two typical needs when you're asking for setting priorities in the business context:

• One wants to use a system feature - that is an expected benefit
• One is under pressure of time or money - that is a problem to be solved

So, now our questions for setting priorities might be:

• I you would to start using a feature now, what would you choose in the first place?
• Assuming you're lacking of money or time, which one of these features you would give up first?

I have mixed tenses intentionally, because benefits refers to the "future", but a pressure is being felt "now". So, if you are a native speaker, let me know how it sounds for you.

Let's Back to The Hot Dogs

You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? You: !^%@!#&! We are taking buns, but NOW!

:) The dialogue above might happen, but it's trivial, huh? Let's take a look on the more realistic one:

1| You: Listen, we are waiting for hot dogs for four hours and we are starving. So, hurry up, pleeeease... 2| Me: We are doing our best. I want to ask you something. If it takes next two hours to deliver all hot dogs, would you mind to give up bun, sausage or ketchup? 3| You: Are you crazy! We want hot dogs! 4| Me: I see you are starving and I know we're late. I need more details to deliver hot dogs faster. May I ask you something? 5| You: Hit me. 6| Me: What it will happen when we don't deliver hot dogs on time? 7| You: I am afraid my boss will kill me. 8| Me: Listen, I'll give you two hot dogs off-hand for you boss. Would you mind to convince your team to wait? We will try to deliver hot dogs in two or three hours. 9| You: Hmmm...sounds interesting...

Again I tried to find a need (I assumed it is a problem to be solved = a hunger). This was line [2]. But my presupposition didn't meet your real need. So, I tried one more time in the line [6]. Your boss was your problem, not a hunger :). Starting from the 'boss problem' we build an acceptable solution.

That's all for now. Watch the blog for more Conversation Patterns.

Photo Credits: Bun, sausage, ketchup :)

Conversation Patterns: A User Story Template Revisited

This article is part of my work on Conversation Patterns for Software Professionals

---

This is well known user story template:

As a [role]
I want [feature]
so that [benefit]

But I noticed that because of this template teams focus mostly on features. What is wrong with that? However, discovering the right features is the goal of user stories, but at the same time a benefit part is neglected.

Consider following (anti)stories:

• As a User I want to login, so that I use a system
• As a User I want to print report, so that I can do my job
• As a User I want to click RMB, so that I choose wanted option from the context menu

These are examples of stories where a benefit part was not clarified enough. Again, what is a big deal?

In general a benefit is a need and another type of a need is a problem to be solved. So, a role wants a feature because one requires a benefit or problem solution. This is natural feature - business need relation.

A feature is a way to satisfy business need by the software functionality. Having need clearly defined a team and PO are able to discover set of features satisfying business need and choose the best one.

But using a given user story template we start a conversation from a feature without talking about a business need first.

Then we want to fill a template so it is possible to put some general benefit instead of, you know, the "real" one.

My solution is: use a slightly different user story template:


In order to [benefit/problem to be solved]
I want [feature]
Being a [role]


---

UPDATED@10/03/2014
Upon further study I decided to redesign the given template as follows:

In order to avoid [problem to be solved]/In order to achieve [expected benefit]
As a [role]
I want [feature]

So now we have two US templates for each of stakeholder's need favour.

---

This template helps to focus on business need first. When the one is clearly defined you may start discovering possible features to satisfy the need.

Conversation Patterns: Słowa są ważne w User Stories

This article is part of my work on Conversation Patterns for Software Professionals

---

Wprowadzenie, którego nie trzeba czytać :)

Minął prawie rok od chwili wydania Oprogramowania szytego na miarę.... Prowadziłem sporo warsztatów w oparciu o tę książkę i mailowałem z czytelnikami. Z zadawanych pytań wnioskuję, że nie jest do końca jasne, w jaki sposób stosować techniki zadawania pytań w szczegółowych kontekstach. Opisane sposoby prowadzenia rozmowy z klientem są często widziane w izolacji od "reszty świata".

Rozmawiamy sobie, zadajemy pytania, konkretyzujemy, ale co dalej? My przecież posługujemy się: user stories, taskami, use cases, bounded contexts, architekturą itd. Jak to skleić z technikami zadawania pytań? Przecież w tych wszystkich wymienionych obszarach zadawanie pytań, konkretyzowanie, definiowanie problemu ma swoje zastosowanie. Albo inaczej: user stories, taski, use cases, bounded contexts, architekturą są efektem zadawania pytań. A zatem pytanie brzmi: jak zadawać pytania, aby otrzymać: USs, UCs, tasks, BCs, zdekomponowaną architekturę?

Tę umiejętność zadawania pytań prowadzących do w/w artefaktów nazywam conversation patterns. Termin ten ukuliśmy podczas iDDD Tour w Krakowie, kiedy Vaughn Vernon dał nam parę minut na przedstawienie paru spostrzeżeń nt. wyodrębniania modelu dziedzinowego podczas rozmowy z ekspertem. Tak powstała krótka prezentacja Conversation Patters for Ubiquitous Language (jeśli nie było Cię na iDDD Tour, musisz użyć wyobraźni, aby złapać o co chodzi:)).

Tyle tytułem wstępu. Zacznijmy od User Stories.

---

Literalne stosowanie szablonu

Krótki przegląd przez historię rozwoju US możesz przeczytać na stronie Scotta Amblera. W każdym razie popularną obecnie ich formą jest As a...I want...so that....
Ten bardzo sprytny schemat formułowania US ułatwia ekspertowi formułowanie myśli i oczekiwań. Jest bardzo prosty, lecz pod tą prostotą kryje się mnóstwo niuansów, bez zrozumienia których, powstają karykatury US. Zobaczmy do czego może doprowadzić literalne stosowanie tego szablonu:

1. Jako Użytkownik chcę się zalogować, aby się zalogować :)
2. Jako Użytkownik chcę się zalogować, aby skorzystać z systemu
3. Jako Użytkownik chcę kliknąć prawym przyciskiem myszy i zobaczyć menu kontekstowe po to, aby wybrać interesującą mnie opcję
4. Jako Likwidator chcę zwiększyć rezerwę szkodową, aby postępować zgodnie z wewnętrzną procedurą T-1000
5. Jako PO chcę dodać pracownika do bazy, aby mieć go w systemie

Kilka słów komentarza. (1,2) słabują jeśli chodzi o precyzyjne sformułowanie korzyści (frazy po so that...). Czy korzyścią dla użytkownika jest to, że się zaloguje? Wątpliwe. Że skorzysta z sytemu? Być może, ale możliwe, że użytkownikowi chodzi o to, aby dostać się do swojego konta?

Jeśli chodzi o (3) również jest kłopot z korzyścią. Jasne, że wybranie interesującej opcji ma sens, jeśli mówimy o tworzeniu menadżera okien, albo biblioteki GUI, lecz a aplikacji biznesowej wybranie interesującej opcji nie jest korzyścią lecz specyfikacją interfejsu użytkownika.

W (4) jest lepiej. Czy postępowanie zgodnie z procedurą T-1000 sprawi, że dzięki oprogramowaniu będziemy mogli odnosić więcej korzyści? pozyskać więcej klientów? zarabiać więcej pieniędzy? Bez szerszego kontekstu trudno jednoznacznie stwierdzić. Brzmi dobrze.

Nieco inaczej jest w (5). To, że PO wypowiada US, nie oznacza, że to on chce danej funkcjonalności, i że on odniesie z niej korzyść. Oczywiście warto używać US do opisywania potrzeb interesariuszy (brzydkie słowo:)) -@see Stakeholder Stories, lecz w tym przypadku rola nie została właściwie dopasowana do potrzeby i korzyści. PO może chcieć np. ładniejszy layout, poprawę bezpieczeństwa. Funkcjonalności raczej rzadko.

Słowa są ważne w US [@see rozdział: Co to znaczy myśleć biznesowo?]
Tak naprawdę US nie jest niczym innym niż parafrazą [@see Technika parafrazy] tego, co ekspert powiedział, spisaną w ustandaryzowany sposób. Posługując się strukturą rozmowy [@see rozdział Sztuka zadawania pytań], formułujesz pojedyncze wypowiedzi rozmówcy w jak najbardziej konkretny sposób.

Tak jak sugeruje tytuł posta i akapitu, słowa których używasz w spisywaniu US mają znaczenie. Zerknij na rysunek. To, co mówi Twój ekspert możesz zapisać co najmniej z użyciem słownictwa trojakiego rodzaju:

Biznesowego - słowa pochodzą z dziedziny biznesowej np.: Jako Klient chcę obejrzeć możliwe do założenia lokaty, aby wybrać najodpowiedniejszą do moich potrzeb
Rozwiązań - słowa dotyczą konkretnych rozwiązań i sugerują j a k coś ma działać, np.:Jako Klient, chcę wejść na zakładkę możliwych do złożenia lokat, aby zaznaczyć najodpowiedniejszą do moich potrzeb.
Technikaliów - słowa pochodzą z żargonu technicznego np.: Jako Klient, chcę wyświetlić listbox ofert, aby najlepszą dodać do mojego rachunku.

Oczywiście to tylko typologia. Więc Twoje parafrazy tego, co mówi rozmówca, mogą miksować słownictwo różnego rodzaju. W tym miejscu chcę Ci zasugerować, abyś używał przede wszystkim słownictwa bizensowego. Dlaczego?

Powód 1. Tak jak na rysunku między tymi grupami słów występuje relacja podrzędności. Najwyżej umieszczony jest biznes, najniżej technikalia. Zmiany również przebiegają z góry na dół. Daną potrzebę biznesową można zrealizować na kilka sposobów, które mogą się zmieniać. Jeśli więc klient stwierdzi, że woli nowe strony zamiast zakładek, to spowoduje to dużo zmian w wymaganiach. Jeśli będziesz trzymać się słownictwa biznesowego, to zmiany w konkretnych rozwiązaniach nie będą aż tak bolesne.

Powód 2. To zespół jest odpowiedzialny za proponowanie klientowi rozwiązań i za znalezienie najlepszego. Klient jest odpowiedzialny za swoje potrzeby. Pamiętaj: User Stories są efektem konwersacji.

Powód 3. Używając żargonu technicznego kastrujesz domenę. Gubisz ważne pojęcia biznesowe, reguły za nimi stojące. Jest duża szansa, że stworzysz architekturę nieadekwatną do wymagań (@see Jak zniszczyć swój kod?).

Zatem celem jest to, aby wejść na poziom biznesu, z jego perspektywy sformułować US i używając swojego doświadczenia technicznego, zaproponować konkretne rozwiązania.

Stakeholder Stories

User stories eksponują tę pracę do wykonania, która ma dawać business value dla sponsora. Zauważyłem że, zespołom, które posługują się US brakuje czasem szerszego kontekstu dookoła historyjek. Mam tu na myśli rzeczy takie jak:

• wymagania niefunkcjonalne - są dopisywane gdzieś na boku US, spisywane w SRSach albo są w głowach
• to, że nie wszystkie "wymagania" przekładają się na konkretne funkcjonalności
• epiki mogą dotyczyć rzeczy przekrojowych przez funkcjonalności (btw: dobra definicja epika "Since an epic becomes an epic if the team can’t commit to it")
• to, że wymagania mogą pochodzić z różnych źródeł i świadomość istnienia wszystkich interesariuszy wnosi lepsze zrozumienie pracy

Dla w/w rzeczy jakby nie było miejsca w backlogu, więc plątają się to tu to tam i każdy ma własny pomysł na ich przechowywanie. Brak jednolitego sposobu na przechowywanie wszystkich wymagań utrudnia ich komunikowanie, a zespołowi utrudnia złapanie szerszego kontekstu tego, co ma do zrobienia.

Format historyjki świetnie nadaje się do spisanie wszystkich punktów widzenia na tworzony produkt. Poniżej przykłady:

• Jako Klient chcę zamówić szkolenie, aby wziąć w nim udział
• Jako Zarząd chcemy dowiadywać się, jaki jest aktualny obrót, aby mieć informacje o aktualnych przychodach z portalu
• Jako Architekt chcę, aby system S czerpał informacje o klientach z naszego systemu V nadzorującego procesy biznesowe
• Jako Zespół chcemy pozbyć się ORMa, bo do tego typu projektu kompletnie się nie nadaje i spowalnia naszą pracę
• Jako Grafik, chcę aby używano Velocity zamiast JSP, abym mógł szybciej przygotowywać widoki

Jasne, że nie wszystkie wymienione historyjki idą na tablicę. Przynajmniej nie w pierwotnej postaci. Przede wszystkim:

• Zespołowi dają szerszy ogląd projektu
• Nie uciekają historyjki techniczne; niby powinny być podczepione pod US, ale zauważyłem, że jak coś nie jest wprost nazwane, to lubi się zagubić w mrokach niepamięci

Po za w/w wspomaganie się hisotryjową strukturą (Jako X, chcę Y, aby Z, bardzo pomaga w zbieraniu wymagań. Zazwyczaj jeśli, ktoś nie potrafi sformułować Z, czyli konkretnego powodu powiązanego z projektem, to sam z wymagania rezygnuje, bez większej przykrości.

Value Stream i zarządzanie wymaganiami w korporacji

Małe firmy często opracowują własne efektywne procesy. Programiści i analitycy z jednej z zaprzyjaźnionych firm sami wymyślili Scruma. Serio! Wpadli na dosłownie wszystkie scrumowe praktyki i przestrzegali ich z pedantyczną dokładnością. Co ciekawe, wcale nie uważali, że zrobili coś nadzwyczajnego. Ot, zwykłe zdroworozsądkowe podejście. Kompletnie inaczej jest w korporacjach.

Podczas warsztatów z zarządzania wymaganiami największy challenge mam z pracownikami departamentów IT w korporacjach. Złożoność organizacyjna rodzi kilka dodatkowych problemów.

Hipertraceability
Pisałem na ten temat tutaj. Nie dajmy się zwieść, że pragnienie hipertraceability jest potrzebą organizacji. Nie jest to potrzeba lecz rozwiązanie problemu związanego z bałaganem w wymaganiach. Rozwiązanie to daje złudzenie, że wszystko jest pod kontrolą. Zazwyczaj nie jest.

Wstrzymałbym się chwilowo ze skłanianiem się ku temu rozwiązaniu dopóki dokładnie nie zrozumiemy natury problemu. (tak tak wiem, focus on solutions, not on problems; ale czy można zaproponować rozwiązania nie rozumiejąc problemu? - moim zdaniem nie).

Niech nieco światła na problem zarządzania wymaganiami w korporacjach rzuci parę poniższych akapitów.

Time to market
To, że prace programistyczne rozpoczynają się rok po zebraniu wymagań, to norma. Niestety przez ten czas, konkurencja poszła do przodu, priorytety się zmieniły i zebrane wymagania są (delikatnie mówiąc) średnio przystające do rzeczywistość. Szkoda jednak tracić zabukowane mendejsy, więc parce wrą. Co prawda dzieje się co innego niż pierwotnie planowano, ale dzieje się!

Harmonogram wdrożeń i rezerwacja mendejsów
W organizacji systemów jest od groma i jakość trzeba nad nimi zapanować. Więc w trosce o jak najlepszą organizację prac definiuje się harmonogram wdrożeń. Harmonogram jak harmonogram musi być rygorystycznie przestrzegany, więc jeśli projekt nie wstrzeli się w swój termin, to czeka na następny termin (zatem ewentualna obsuwa nie jest ciągła lecz dość grubo skwantyfikowana).

Ponieważ projekty konkurują ze sobą o miejsce w harmonogramie wdrożeń, a Biznes ma wskaźniki do osiągnięcia, więc przezornie rezerwuje sobie miejsce dwa lata w przód na Jakiś Bardzo Ważny Projekt. Dla uzasadnienia rezerwacji, odbywa się nawet zbieranie wymagań. Jest to jednak sprytny wybieg taktyczny mający na celu zaalokowanie zasobów Departamentu IT "na wszelki wypadek".

Pigułka: Nowy System
Nowe potrzeby = nowy system. Rzesza programistów podejmuje trud stworzenia czegoś nowego, co powiela część funkcjonalności z już istniejących systemów. Jasne, że ktoś powinien pójść po rozum do głowy i wyłożyć co jest grane. Ale kto?: Główny Architekt, Enterprise Architect, Architekt Funkcjonalny, Architekt Systemowy, System Designer, Backend System Designer ???

Mimo szczegółowej procedury decyzyjnej oraz masy zebrań, komitetów, analiz i opinii, powstaje pięćset szósty system, który sprawia, że:

• potrzeba kolejnego etatu do jego utrzymania,
• SOA staje się naprawdę jedynym sensownym rozwiązaniem,
• skomplikowanie procedur organizacyjnych dąży do nieskończoności,
• końcowi użytkownicy ze starymi przyzwyczajeniami próbują korzystać ze starego systemu na nowy sposób i klną na czym świat stoi.

Paraliż decyzyjny
Wyobraźmy sobie następującą, powiedzmy, że hipotetyczną, sytuację:

• Komitet sterujący projektu IT składa się z: Prezesa oraz członków Zarządu
• Komitet spotyka się z Kierownikiem Projektu, aby podjąć decyzję o zmianie harmonogramu tworzenia projektu

Rozmowa przebiega następująco:

• Kierownik: Czy zmieniamy harmonogram?
• Prezes: Zmieniamy?
• Członkowie Zarządu: hmm...
• Prezes: Tak! Zmieniamy!
• Kierownik: A zatem wpisuję w protokole: "Komitet sterujący podjął decyzję o zmianie harmonogramu"
• Prezes: Zaraz, zaraz...Jaką decyzję? Proszę napisać: "Komitet sterujący rekomenduje zmianę harmonogramu". Niech zostanie to zatwierdzone na zebraniu Zarządu.

yyyyy????

Obosieczny miecz standardów
Buy, don't write Wiele kawałków systemu, można kupić taniej niż wykonać. Wiele kawałków do wykonania, można szybko napisać w konkretnych technologiach, bibliotekach, itp. Ale stop! W organizacji standardem jest technologia X i kropka. Z jednej strony ma to sens (na przykład finansowy), z drugiej jest pewnym marnotrawstwem zasobów.

Zmęczony Biznes znajduje drogę na skróty
Ponieważ biznes napotyka powyższe trudności w dogadaniu się z Departamentem IT, radzi sobie w sprytny sposób - zatrudnia jednego lub dwóch programistów we własnym dziale, na własny koszt.

W pewnej firmie jeden z takich "partyzanckich" programistów, w krótkiego czasu naskrobał w pehapie CRM, który zrobił sporą furorę w organizacji. Dostarczał dokładnie takich funkcjonalności jakich było potrzeba. Jak powiedział jeden z programistów z Departamentu IT: ktoś tam siedział, słuchał biznesu i zrobił. Oczywiście CRM był na bakier z: harmonoramem wdrożeń, bezpieczeństwem testami i stosem innych procedur, aczkolwiek miał podstawową zaletę: adresował wszystkie potrzeby Biznesu.

Problem z takim "kukułczym jajem" jest taki, że Departament IT nie chce go tknąć, bo: "nie mamy kontroli nad opensource'owymi bebechami i jak coś się stanie to będzie na nas". Dodatkowo między Biznesem a IT rośnie napięcie ponieważ estymacje Departamentu IT są kilkukrotnie większe niż programisty-partyzanta.

Value Stream
Ktoś kiedyś napisał bądź powiedział: "Informatyzacja efektywnego procesu zwielokrotnia jego efektywność. Optymalizacja procesu nieefektywnego zwielokrotnia jego nieefektywność".

W powyższych przykładach organizacja sterowana jest procedurami, brak jest zorientowania na wartość biznesową. Jasne, że są plany, wskaźniki itd. Ale czy opisane sytuacje nie wskazują, że wartość biznesowa zniknęła gdzieś między procedurami? Brakowało zdefiniowania strumienia wartości biznesowej, czyli zoptymalizowanego procesu zarabiania pieniędzy.

Tajemniczy Dział Optymalizacji Procesów
Organizacje mają świadomość opisanych sytuacji. Jednym ze sposobów jest powoływanie do życia Tajemniczego Działu Optymalizacji Procesów (ew. zatrudniania do tego kosztownych konsultantów). Dział ów to kilka osób, zamkniętych w malutkim pokoiku, które co jakiś czas
objawiają Organizacji nowe i ulepszone procedury. Nie tędy droga, ponieważ procedury procedurami, a ludzie ludźmi. Formalizowanie i standaryzowanie jest ok i przynosi wiele korzyści, ale zaangażowanie i orientacja na wartość biznesową przynosi ich więcej. Trudno mi w tej chwili podać konkretny przepis na to co z tym fantem zrobić. Temat w inkubacji.

Jako zajawkę w pokrewnej tematyce polecam prezentację. (nie wiem ile powisi, więc kiedyś link może się zdezaktualizować)