Nie ma idealnego rozmiaru dla pętli sprzężenia zwrotnego

Im dłużej pisałem ten post, tym bardziej czułem, że powinienem pisać jakiś rodzaj TL;DR dla niektórych osób, które to czytają. Tak więc, aby zaoszczędzić czas, oto jest:

Piszę to dla tych, którzy są nowicjuszami w samozatrudnieniu, zarządzaniu projektami lub ogólnie mają mniejsze doświadczenie niż ci, którzy pytają „Dlaczego to piszesz?" Ostatecznie większość z nas uczy się tego w pewnym momencie ale jeśli możemy pomóc sobie nawzajem na skróty, prędzej czy później, wszyscy na tym skorzystamy.

Jeśli po przeczytaniu powyższej notatki nadal jesteś zainteresowany, zakładam, że chcesz poprawić ten aspekt komunikacji. Co jest dobre, ponieważ ja też jestem 😏, a użycie małej pętli sprzężenia zwrotnego jest jednym ze sposobów, w jaki udało mi się to zrobić.

---

Każda branża ma trochę własnego żargonu i wielu z nas się z tego śmieje, ale wszyscy nadal go używamy, gdy pracujemy w profesjonalnym otoczeniu. Jesteśmy zabawni w ten sposób.

W każdym razie w naszej branży jednym z wyrażeń, których często używamy – w tym ja – jest „pętla sprzężenia zwrotnego”. Po raz pierwszy zetknąłem się z tą frazą w odniesieniu do sprzężenia zwrotnego ze wzmacniaczy. Nie miało to nic wspólnego z oprogramowaniem. Niemniej jednak w tym, co robimy, na ogół używamy go w odniesieniu do tego jako:

• wysłanie prośby, komentarza lub ogólnej informacji do klienta,
• otrzymanie odpowiedzi od klienta dotyczącej wspomnianych informacji.

A dla tych, którzy nie są przyzwyczajeni do tego pomysłu (ponieważ są tacy, którzy robią „big bang release”, o którym opowiem za chwilę), pętle sprzężenia zwrotnego są zwykle uważane za małe lub duże.

Im dłużej pracuję w oprogramowaniu, tym bardziej zawsze dążę do małej pętli sprzężenia zwrotnego, bez względu na wszystko.

Idealna pętla sprzężenia zwrotnego

Mała pętla sprzężenia zwrotnego oznacza częstą komunikację między firmą a klientem (więc naturalnie duża pętla sprzężenia zwrotnego występuje wtedy, gdy komunikacja jest rzadsza).

Jeśli masz używać żargonu, przynajmniej pomyśl o tym w jakiś zabawny sposób, prawda?

Ale znasz ten cały żargon, o którym wspomniałem na początku artykułu? W normalnej konwersji powiedziałbym po prostu:

Jeśli chodzi o pracę nad projektem, preferuję częstszą komunikację.

A powodem, dla którego wolę to, a nawet domyślnie, jest to, że jeśli chodzi o budowanie rozwiązania, niezależnie od rozmiaru, dla kogoś innego, zawsze należy wziąć pod uwagę ruchome części.

Gdy projekt składa się z wielu części, istnieje wiele miejsc, w których coś może wymagać dopracowania lub zmiany (lub może mieć wpływ na cały system), a wykonanie tego we właściwym czasie, a nie później, oszczędza dużo czasu (a tym samym pieniędzy) i stres dla większości zaangażowanych stron.

Więc co?

Po co jednak o tym pisać? Dla mnie powodem jest to, że im dłużej prowadzę mały sklep, tym więcej słyszę od klientów o problemach związanych z brakiem przejrzystości, komunikacji i zarządzania projektami w poprzednich projektach.

Porażka. Nie chcę przeprowadzać tego typu operacji. Więc łatwo to naprawić, prawda?

Co więcej, branża deweloperska jest wypełniona ludźmi, którzy przyjmą wymagania projektu, założą, że rozumieją wszystko, co jest potrzebne, a potem wracają tylko po to, aby zbudować coś, co nie tylko nie spełnia celu, ale tylko wygląda trochę tak, jak zamierzał klient.

Niekoniecznie jest to pukanie do programistów, ale to całe „[brakowanie] celu” można naprawić, jeśli po prostu komunikujemy się z tymi, z którymi pracujemy nieco częściej niż nie.

Nie zakładaj, że wiesz, czego chcą.

Zamiast tego zadawaj pytania, wyjaśniaj wymagania, pracuj nad funkcją, a następnie przedstawiaj klientowi w środowisku pomostowym. Będą wiedzieć, czy zbudowałeś to, o co prosili. Jeśli tak, przejdź do następnej funkcji. Jeśli nie, jest jeszcze więcej do zrobienia. Działanie w ten sposób usprawnia tak wiele punktów napięć, które pojawiają się w projektach.

I tak, zadawanie wielu pytań może stać się nużące, a nawet denerwujące. Wielka rzecz. Wspomnij na początku, że będziesz zadawał wiele pytań, aby w pełni zrozumieć problem, zanim spróbujesz go rozwiązać. Podaj powód, dla którego robisz to, co robisz. To się opłaca.

Wielkie wydania

Wcześniej w poście wspomniałem o „wielkich wydaniach” i ogólnie odnosi się to do idei klienta, który dostarcza ci wymagania, wracasz do pracy nad tym tygodniami, a następnie pojawiasz się z powrotem i mówisz „Hej, ja skończone – spójrz!” tylko po to, by dowiedzieć się, że jest daleko.

Gdybym miał to kontekstualizować w rodzaju pętli sprzężenia zwrotnego, powiedziałbym, że nie ma takiej. Nie jest nawet duży, ponieważ nie uzyskano informacji zwrotnej. To po prostu:

• Oto wymagania dotyczące projektu,
• Skończyłem z projektem.

Często prowadzi to do tego, że programiści nie rozumieją wymagań, klienci nie wiedzą o postępach, a cały projekt idzie na południe. Mówiąc prosto, nie rób tego w ten sposób.

Idealny rozmiar?

Nie wiem, jaki jest idealny rozmiar pętli sprzężenia zwrotnego. Jest kilku klientów, z którymi pracowałem, gdzie są codzienne meldunki, są takie, które są cotygodniowe i są tacy, którzy powiedzieli „po prostu wypełnij to i daj mi znać, kiedy skończysz”.

Cotygodniowe check-iny, commity, wydania itp. są moimi ulubionymi, ale to ze względu na wielkość projektu i wielkość zespołu, z którym pracuję. Codzienny też nie jest zły w zależności od zadania.

Nigdy nie robię stylu Wielkiego Wybuchu, nawet jeśli klient mówi, że to w porządku. Nadal lubię mieć punkty kontrolne dla własnego zdrowia psychicznego. Niezależnie od rodzaju pętli sprzężenia zwrotnego, która najlepiej pasuje do Ciebie, Twojego zespołu i Twojego klienta, będzie to idealny rozmiar.