Ukryte koszty i rzeczywista elastyczność w procesie rozwoju produktu

Wu-Tang Clan miał rację

Gotówka rządzi wszystkim wokół mnie. Nawet najbardziej turkusowe organizacje nie mogą temu zaprzeczyć. Rozwój projekt Metody zarządzania, usprawnianie i optymalizacja procesów czy motywacja pracowników są zasadniczo wywoływane przez powszechną potrzebę pieniędzy. Zwinność projektowa wiąże się z pewnym ryzykiem.

Wszyscy chcemy być szczupli i zwinny aby wynik naszych działań, mierzony w liczbach, był jak najwyższy. Nawet jeśli większość naszej energii skupiamy na ograniczaniu strat, w ostatecznym rozrachunku bierzemy pod uwagę zysk, który wzrósł dzięki wygenerowanym oszczędnościom.

Oszczędności te wpadają do tej samej kieszeni co pozostałe czynniki i pozostają dostępne tylko dla najbardziej dociekliwych. W ten sposób tracimy koncentrację i nieumyślnie pomijamy wiele cennych danych, a ostatecznie inteligencję.

Wnioski wyciągnięte z niepowodzeń

Uczenie się na własnych błędach jest szczególnie przydatną (choć kosztowną) umiejętnością. kultura organizacyjna a dyplomacja wpisana w tę umiejętność nie zawsze pomaga. Często ukrywamy negatywny wpływ finansów za pomocą słów "zasłony dymnej". Kiedy inwestor krzyczy "Straciłem pieniądze!", menedżer przekazuje to do zespół Mówiąc "powinniśmy być bardziej efektywni", wszyscy domyślnie szukamy nowych rozwiązań i ulepszeń - zamiast oglądać się za siebie, nieustannie szukamy sposobów na pójście naprzód.

Tymczasem straty są często kluczem do wyciągnięcia właściwych wniosków. Jeśli przejdziemy przez pewne etapy przepływu w procesie bez odpowiedniego zastanowienia, kolejne rozwiązania będą najprawdopodobniej zainfekowane tymi samymi błędami.

Przykład: 

Niewielki zespół starszych programistów JS nie dostarcza funkcjonalności w oczekiwanym czasie. Inwestor, chcąc przyspieszyć rozwój, zleca zatrudnienie nowego programisty. Wprowadzenie nowej osoby do projektu rozprasza zespół, co jeszcze bardziej spowalnia postęp projektu.

Gdyby inwestor lepiej zrozumiał przyczyny nieefektywności zespołu, doszedłby do wniosku, że wykorzystuje on swój potencjał jedynie w 60-70%. Lepszy sprzęt i kilka dni roboczych poświęconych na automatyzację pracy rozwiązałoby problem.

Niestety teraz musi zapłacić za innego dewelopera, który będzie pracował na tym samym sprzęcie, a jego wydajność również będzie na poziomie 60-70%.

Rozwiązanie A:

• Zespół (2 x starszy programista JS): $20k / miesiąc
• Cloud usługi: 200$ / miesiąc
• Nowy sprzęt dla deweloperów: $10k

Od teraz projekt kosztuje $20,200 / miesiąc

Łączne wydatki w ciągu 12 miesięcy: 12 * 20 200 + 10 000 = $252 400

Rozwiązanie B:

• Zespół (2 x starszy programista JS): $20k / miesiąc
• Nowy programista (1 x starszy programista JS): $10k / miesiąc

Od teraz koszty projektu: $30,000 / miesiąc

Łączne wydatki w ciągu 12 miesięcy: 12 * 30 000 = $360 000

Dwóch deweloperów pracujących przy 100% robi mniej więcej to samo, co trzech deweloperów pracujących przy 60-70%. Inwestor zapłaci ponad $ 100 000 więcej za tę samą moc obliczeniową rocznie z powodu błędnej decyzji projektowej!

Tworzenie idealnego produktu jest jak pogoń za królikiem

Zwinność w procesie nie musi oznaczać dążenia do pokrycia testami 100% lub pobicia rekordu wydajności. Podczas gdy te metryki zapewniają przegląd stanu technicznego projektu, są one tak nieistotne z perspektywy klienta końcowego, że doprowadzenie ich do idealnego stanu w prawdziwie zwinnym procesie nie musi być osiągnięte, ponieważ nie przynoszą one rzeczywistych korzyści. rynek wartość.

Opracowanie doskonałych rozwiązań technicznych wymaga dużego zaangażowania zespołu i znacznie szerszej komunikacji. W rezultacie łatki działają wolniej, a projekt staje się ciężki z powodu nadmiernego rozwoju.

Programowanie zwinne polega na dostarczaniu działającego kod przy minimalnym wysiłku. Testowanie kodu jest niewątpliwie dobrą praktyką, a testy mówią wiele o działaniu kodu, ale nie powinny być wykonywane tylko dla samego ich wykonywania i chwalenia się tym - optymalna jakość techniczna rozwiązań leży gdzieś pomiędzy minimum określonym przez zespół deweloperów i maksimum, które jest ograniczone budżetem.

Ostatecznie perfekcja prowadzi donikąd. Co ciekawe, nawet kwestia bezpieczeństwa podlega tej regule - teoretycznie każdy system można zhakować. Wspomniane minimum deweloperskie musi być jednak odpowiednio wyższe i adekwatne do wagi, skali i kosztów potencjalnych konsekwencji błędów w kodzie. Często zamiast pisać moduł logowania od zera, co zawsze obarczone jest dużym ryzykiem błędu i wprowadzenia luk bezpieczeństwa, lepiej skorzystać np. z przycisku "Zaloguj się przez Google", którego poprawna implementacja jest stosunkowo szybka i bezpieczna.

Dopóki celem jest krótki czas wprowadzenia produktu na rynek, zbyt ambitne założenia przynoszą efekt przeciwny do zamierzonego. W pozornie doskonałym procesie nadmierny entuzjazm może być stratą zasobów.

Dobrze jest wiedzieć wszystko o czymś i coś o wszystkim

Projektowanie zorientowane na użytkownika jest fajne. Współpraca skoncentrowana na człowieku jest ważniejsza. Gdy zespół komunikuje się na tych samych falach, może spontanicznie zmniejszyć dalsze potencjalne straty.

Projektant UX, który jest na bieżąco z technologiami frontendowymi, nie zaproponuje rozwiązania od razu. MVP które pochłoną nieuzasadniony czas na etapie wdrożenia.

Programista frontendowy, który zna heurystykę użyteczności, będzie w stanie dostosować interfejs do danej rozdzielczości ekranu bez angażowania projektanta UX - szybka poprawka, podgląd, akceptacja.

Praca nad aplikacją wymaga synchronizacji działań osób o zupełnie różnych profilach kompetencji. Musisz znać rozkład umiejętności w swoim zespole, aby skutecznie dostarczać wartość swoim klientom.

Zaangażowany i zsynchronizowany zespół jest kluczowym generatorem oszczędności. Ten rodzaj zwinności wymaga optymalnego rozwoju produktu.

Dobra wydajność zespołu rozumiana w ten sposób jest niezwykle trudna do osiągnięcia, zwłaszcza w erze praca zdalna. Firmy, które od lat są "przyjazne zdalnie", mają na tym polu znaczną przewagę nad tymi, które zostały zmuszone do dostrojenia organizacji podczas lockdownu i dopiero teraz uczą się nowych metod i form komunikacji.

Mocny sprzęt przed wyruszeniem w drogę

W kontekście rosnących potrzeb komunikacyjnych, narzędzia takie jak Whimsical, Miro, Mural, Figma i Balsamiq odnotowują imponujący wzrost popularności.

Z pewnością lockdown i potrzeba pracy zdalnej odegrały swoją rolę w tej eksplozji użytkowników. Uważam, że wybór narzędzia powinien być dopasowany do indywidualnych preferencji, ale przyjrzyjmy się Miro:

Popularyzacja takich narzędzi w naturalny sposób napędza wzrost popularności samych metodyk. Ktoś, kto kupił Miro do pracy nad personami, otrzymuje dostęp do dziesiątek innych szablonów, które mogą okazać się interesujące i pozytywnie wpłynąć na codzienną pracę zespołu.

Zawsze warto wyposażyć się w narzędzia, które usprawnią przepływ informacji w projekcie. Otwartość na nowe narzędzia i metody to również jeden z fundamentów skutecznego działania. rozwój produktu.

Możesz (i powinieneś) być leniwy

Doświadczeni projektanci zarówno interfejsu, jak i architektury oprogramowania zazwyczaj już na początku współpracy dostrzegają kilka potencjalnych rozwiązań, które należy zweryfikować i sprawnie poszukują na rynku odpowiednich inspiracji lub nawet gotowych rozwiązań. Dobrym przykładem jest framework Material UI, który jest zwykle bezpiecznym rozwiązaniem na etapie prototypu.

Czasami wystarczy przejrzeć kilka wdrożeń na Behance lub Dribble i wykorzystać inspirację do stworzenia moodboardu, a następnie przekazać go deweloperowi. Osoba ta wykorzysta go do stworzenia klikalnego prototypu, który można zaprezentować wczesnym użytkownikom w celu zebrania opinii. To organiczne dążenie do skutecznego procesu u osób nastawionych na projektowanie i zaangażowanych jest naturalne.

Jeśli chcesz efektywnie dostarczać produkty cyfrowe, musisz pozwolić ludziom wykonywać ich pracę. Wiesz, jaką wartość/usługę chcesz dostarczyć swoim klientom - to wystarczy. Kompetentny i dobrze zarządzany zespół projektowy będzie wiedział najlepiej, jak dostarczyć tę wartość/usługę tak szybko, jak to możliwe, przy zachowaniu niezbędnej efektywności kosztowej.

Okaż swoje zaufanie, podziel się odpowiedzialnością i otwórz się na prawdziwą dwukierunkową komunikację, abyś mógł produkt będzie lepiej, a ciężar robienia wszystkiego samemu zejdzie z barków, co często okazuje się wyczerpującą jazdą dla założycieli i przedsiębiorców! Przy The CodestPrzekładamy tę zasadę nie tylko na projekty, ale także na procesy wewnętrzne - prawdopodobnie dlatego cieszymy się wysokim wskaźnikiem retencji zarówno wśród klientów, jak i pracowników (prawdziwa historia, oba> 90%).

Potraktuj siebie z odrobiną lenistwa, odważnie przenieś odpowiedzialność i odpuść sobie zbędną pracę, która nie jest niezbędna do posuwania się naprzód - funkcjonalności, które byłyby "miło mieć", zawsze mogą poczekać.

Skoncentruj się na znalezieniu poprawnych odpowiedzi

Proces tworzenia produktu cyfrowego to ciągła kolizja różnych perspektyw, doświadczeń i źródeł informacji - każda taka kolizja niesie ze sobą ryzyko podjęcia niewłaściwej decyzji projektowej.

Dobra komunikacja wewnętrzna zmniejsza to ryzyko, ale to tylko jedna strona medalu. Pytanie o to, jak pozostać w kontakcie z rynkiem, pozostaje jeszcze bez odpowiedzi.

Business Intelligence, wsparcie klienta, działy badań UX i wiele innych - podobnie jak zespół programistówPowinni oni dążyć do minimum niezbędnego do udzielenia konkretnych odpowiedzi na pytania zadawane przez właściciela produktu lub zespół UX.

Ważny jest również sam branding i strategia komunikacji marki. Służą one budowaniu jakościowej relacji z klientami, co następnie przekłada się na ich zaangażowanie. Jeśli chcesz zadawać klientom pytania, powinieneś upewnić się, że chętnie na nie odpowiedzą. Ton głosu ma znaczenie.

Pewne jest, że bycie w stałym kontakcie z rynkiem pozwala zdefiniować właściwe trajektorie dla projektu, aby mógł on wzbić się w powietrze. Mniej oczywisty jest fakt, że potrzebę tego kontaktu należy rozważyć na samym początku projektu, wokół przewidywania odpowiednich kompetencji w zespole (aby zadawać właściwe pytania i odpowiadać na nie) oraz budowania strategii produktu, która zaangażuje grupy docelowe.

Wnioski

Biorąc pod uwagę wszystkie powyższe kwestie, możemy zaobserwować kilka problemów, które regularnie pojawiają się w procesie projektowania:

- nadmierne nastawienie na zysk i unikanie patrzenia na porażki,

- niedokładność i nie prześwietlanie własnych błędów,

- Pogoń za idealnym produktem, który masz w głowie, ale który nie jest tym, czego potrzebuje rynek,

- nadgorliwe wdrażanie procesów podręcznikowych - nadmierny rozwój i nadmierne projektowanie,

- Nieelastyczność pracy zespołowej i zmuszanie pracowników do pozostawania wyłącznie w swoich obszarach specjalizacji,

- nieskuteczna komunikacja,

- tendencja do odkrywania koła na nowo.

Optymalizacja procesu w skali makro obejmuje sumę oszczędności. Aby właściwie stawić czoła wyżej wymienionym wyzwaniom, należy zaangażować współpracowników, aby otwarcie przedstawiali pomysły na usprawnienie procesu.

Czasami wystarczy mniej mówić i uważniej słuchać podwładnych, klientów, partnerów - zgodnie z rolą i odpowiedzialnością każdego z nich - aby osiągnąć sukces.

Jeśli nie jesteś wystarczający, najprawdopodobniej przeinwestowałeś. Czy masz za dużo pieniędzy?

Zamknij się i bierz swoje pieniądze! A poza tym:

1. Nie wprowadzaj Scrum tylko po to, aby ćwiczyć Scrum.
2. Zwracaj większą uwagę na luki w procesie.
3. Wyznaczaj mniejsze cele, które są osiągalne i mierzalne w krótkim okresie - ogólnie rzecz biorąc, trzymaj się minimum.
4. Czasami dobry mapa drogowa wystarczy, aby dać zespołowi poczucie wspólnego celu i zaangażować go w efektywną pracę tu i teraz.
5. Zbuduj dobry zespół, aby móc dać mu swobodę, której potrzebuje.
6. Zawsze kwestionuj obecny zestaw narzędzi - szukaj możliwych ulepszeń w swoim warsztacie.
7. Zaprojektuj proces z perspektywy leniwej osoby - tak, jakbyś chciał zrobić jak najmniej.

Czytaj więcej:

Wyzwania CTO - skalowanie i rozwój oprogramowania

Który DB wybrać dla określonego typu danych w projekcie oprogramowania?