[V#10] 📐 Miarka, czyli jak pokażesz jakość klientom

Transkrypcja

[00:00:01.140] Cześć. To co, ruszamy.

[00:00:09.130] Tak jak codziennie - spacer w zielonym. Tak jak wczoraj, spacer na południu Krakowa. A dzisiaj porozmawiamy o jakości produktu, który tworzymy. O jakości tych rzeczy, które wyprodukujemy. Czy też o jakości usług, które oferujemy.

[00:00:27.050] A więc, czym jest jakość? Każdy z nas (w co drugiej firmie w zasadzie) słyszy o tym, że dana firma jest najlepsza na rynku, najlepsza w branży, prezentuje najwyższą jakość. Ale co to tak naprawdę oznacza?

[00:00:43.060] Dzisiaj trochę o tym pogadamy. W zasadzie każda firma, która mówi, że “mamy najwyższą jakość”, albo “jesteśmy najlepsi”, albo jakąś formułę w tym stylu, robi to źle.

[00:00:55.050] A dlaczego? Jakakolwiek dowolna firma może powiedzieć: “ok, my też jesteśmy najlepsi”. I jak porównać te dwie rzeczy? Jedna rzecz jest najlepsza. Druga rzecz jest najlepsza. To która jest lepsza? No nie potrafisz [porównać] dopóki nie spróbujesz. Tak naprawdę, żeby spróbować to musisz najczęściej zapłacić. I tu robi się problem. I takie formułki są łatwe do przyswojenia, łatwe do napisania, ale kompletnie nic nie znaczą. Nie warto ich pisać pod żadnym pozorem. Bo nie oznaczają nic konkretnego, tylko tym konceptem, rozmytą myślą, która może oznaczać wszystko i nic.

[00:01:39.480] I tu przechodzimy do pierwszej rzeczy, która jest związana z jakością. I podpatrzyłem ją w sumie u Pawła Tkaczyka w jednym z jego wystąpień na YouTubie. Ta rzecz jest też powiązana z brandingiem i ogólnie z marką i postrzeganiem danej firmy. O czym mowa? Chodzi o metryki. Czyli jak zmierzyć naszą jakość. Bo to, że powiemy, że “nasza jakość jest największa/najlepsza; jesteśmy super” to nic nie znaczy. A jak już wskażemy, że “mamy tysiące zadowolonych klientów”, albo “99 i pół procenta klientów nam ufa”; no to już to coś mówi, nie?

[00:02:26.190] Teraz metryki mogą być ilościowe, albo jakościowe. Metryki ilościowe to, że na przykład “99 i pół procenta produktów naszych się nie psuje. Pół procenta się psuje (tylko); pół procenta odrzucamy”. To jest przykład. A ilościowe to na przykład, że aplikacja działa. Aplikacja się włącza. Aplikacja spełnia swoje zadania.

[00:02:57.230] I obydwa typy tych metryk są jednakowo istotne. A to jak to określimy - to już zależy od nas. Od nas zależy co nasza aplikacja ma robić. Co nasz produkt ma robić.

[00:03:21.420] I właśnie od tych metryk (od tych wymagań) zależy, czy nasz produkt jest rzeczywiście dobrej jakości. Na przykład weźmy szczoteczkę do zębów. Jeśli się rozwali po dwóch dniach; jeśli zaśmierdnie po tygodniu no to też jest słabo.

[00:03:40.460] I to jest właśnie pierwsza rzecz, którą powinien spełniać produkt. Powinien mieścić się w ramach wyznaczonych przez nas. Powinien spełniać wymagania przez nas postawione. I w zasadzie to jest najważniejsza rzecz. Wszystkie procesy Quality Assurance w firmach na tym polegają. Dostajemy jakiś zestaw wymagań i QA sprawdzają, czy dany produkt, dana usługa mieści się w ramach wyznaczonych przez te wymagania. Tylko tyle i aż tyle. I w swojej firmie zamiast pisać takie rozmazane zdania typu “najwyższa jakość”, warto postawić właśnie według jakich kryteriów to jest najwyższa jakość. Jakie kryteria spełnia nasz produkt? Co robimy najlepiej.

[00:04:49.300] Idziemy dalej. Weźmy przykład. Chcesz zbudować dom i najpierw na działce stawiasz ruderę (na szybko zbitą) i pokazujesz klientowi. Może kupuje, może nie. A potem jeśli kupi to burzysz to i budujesz prawdziwy dom. No i co? 2 razy wykonana praca. Najpierw musisz zburzyć ten dom… Najpierw musisz postawić, potem zburzyć, potem znowu postawić. To nawet trzy razy wykonana praca.

[00:05:17.090] Według mnie lepiej najpierw postawić mniejszy dom, ale już w pełni zbudowany - z fundamentami, itd. A nie ruderę zbitą na szybko. Często, szczególnie w jakichś projektach IT, projekty są budowane tak, że pierwsza wersja jest “na odwal się”.

[00:05:34.640] Pierwsza wersja spełnia jakieś tam zadanie. Coś tam może działa, ale niekoniecznie. Kod pod spodem wygląda tragicznie. Tak, że każda zmiana w kodzie później wymaga dwa razy więcej pracy. Bo trzeba usunąć stary kod i dopiero wstawić nowy. Tzw. refaktoryzacja. Zamiast tego według mnie lepiej jest robić tak, że najpierw robisz małymi kroczkami (iteracyjne podejście), ale dobrze. Robisz od razu dobrze, żebyś nie musiał potem tego zmieniać. Tyle, że dostarczasz mniejszą funkcjonalność. Mniejszą, ale w pełni działającą, w pełni sprawdzoną, w pełni otestowaną funkcjonalność.

[00:06:22.380] Z takim podejściem mogłoby się wydawać, że dłużej musimy czekać na jakąś funkcjonalność, na jakąś rzecz. Ale z drugiej strony od razu mamy już zrobione coś dobrze, poprawnie i nie musimy tego poprawiać. Jak zostanie sprzedany klientowi to już działa i będzie działał.

[00:06:38.350] Dzięki temu zrobienie czegoś nie tylko wymaga mniej czasu i pieniędzy, ale też masz większą pewność, że coś możesz pokazać klientowi. Możesz sprzedać komuś. Że twój proces działa. W świecie IT - jak poświęcić czas na napisanie testów, na poprawne otestowanie, poprawne stworzenie modeli, itd. to już potem nie musisz tego poprawiać. Zostaje Ci czas i pewność, że coś działa.

[00:07:22.490] Następna rzecz - mamy takie podejście jak “kaizen”. Pewnie obiło ci się o uszy. A jeśli nie, to jest japońska sztuka ciągłego doskonalenia. Małymi kroczkami poprawiasz, żeby stać się coraz bardziej doskonałym.

[00:07:37.750] I tak jeśli jest jakaś fabryka, która wzoruje się na kaizen (działa w zgodzie z kaizen), to jeśli wystąpi jakiś błąd (jakaś usterka na linii produkcyjnej), cała linia jest zatrzymywana dopóki nie usunie się tej usterki. Żeby po prostu każda część wychodząca z tej fabryki nie była wadliwa. Tylko stwierdza się jakąś usterkę; cała linia staje; naprawia się; i dopiero potem rusza.

[00:08:09.680] Z jednej strony wydaje się, że to jest strata pieniędzy. Bo jak linia stoi to teoretycznie nie zarabia na sobie. Ale z drugiej strony, jeśli by szła z usterką to na sprzedaż poszło dziesiątki (jeśli nie tysiące) wadliwych produktów, które potem by musiały być zwracane, reklamowane, itd. To oznaczałoby większą stratę dla biznesu.

[00:08:35.910] Tak przechodząc do świata IT - żeby utrzymać dobrą jakość, warto tworzyć produkty w podejściu “test first”, albo “test driven development”. Na frontendzie rzadko kiedy stworzysz (w zasadzie bardzo ciężko stworzyć) “test driven development”.

[00:08:56.120] Ale jeśli działasz z testami. Jeśli najpierw opisujesz metryki “jak coś ma działać”, czyli testy, to później masz mniejszą szansę, że coś się sypie. W związku z czym szybciej rozwijać swój produkt. Nie musisz się męczyć nad bugami, nie musisz robić poprawek. Tylko robisz nowe ficzerki, a całość działa. Działa jak działała wcześniej. Bez zwiech. Przynajmniej taka jest teoria. W praktyce oczywiście coś się nie zepnie. Coś się wysypie. Ale to znacząco zmniejsza prawdopodobieństwo takich wysypek.

[00:09:34.880] Jeszcze a propos kaizen i tego vloga. Możliwe, że w tym tygodniu jeszcze poprawi się jakość dźwięku, bo przyjdzie mi mount (chwytak) do mikrofonu. Do mikrofonu zewnętrznego. W związku z czym powinna się poprawić jakość vloga, dźwięku.

[00:09:54.060] I tak właśnie kaizen nie tylko zakłada poprawę produktu, ale też samego procesu. Żeby szybciej i sprawniej coś dostarczać. Jakąś usługę, produkt cokolwiek oferujesz; cokolwiek oferuje twój biznes.

[00:10:09.880] Ja już będę powoli wychodził z lasu, a ty - opowiedz jakie podejście stosujesz, żeby zachować dobrą jakość i podziel się w komentarzu. Jeśli interesują cię też książki bardziej filozoficzne, to warto przeczytać coś takiego jak “Zen i sztuka obsługi motocykla” Roberta Pirisga. Naprawdę ciekawa książka. Niebiznesowa. Bardziej o jakości i o życiu trochę. O różnych rzeczach, o różnych ciekawych rzeczach. Przeczytaj.

[00:10:42.220] Jeszcze a propos jakości. Daj znać, jak mógłbym ulepszyć ten vlog. Co chciałbyś zobaczyć/chciałabyś zobaczyć? Czego ci brakuje. Oprócz oczywiście głośności, bo to wiem, że wychodzi za cicho. A tymczasem ja się żegnam. Wrzucam na słuchawki “Ego to twój wróg”. Do zobaczenia jutro. Trzymaj się! Cześć.