W roku 2014 dołączyłem do zespołu organizującego wydarzenie WUD Silesia 2014. Naszym zadaniem było sprawienie, żeby osoby obecne na WUD mogły nie tylko się uczyć, ale i dobrze bawić. Mieli być oczarowani i czerpać z tego zabawę. To był nasz cel - wszystko to dostaliśmy. Sposób, w jaki to osiągnęliśmy, zależał tylko i wyłącznie od naszej inwencji twórczej i możliwości.

Dla mnie – czyli kogoś, kto od czterech lat zajmował się wytwarzaniem oprogramowania – było to spełnienie marzeń. Greenfield. Możliwość rozpoczęcia od zera,  i zrobienie czego tylko dusza zapragnie – pod jednym warunkiem: wynik musi być zgodny z celem.

Zdecydowaliśmy się zbudować maszynę Rube Goldberga, czyli przesadnie rozbudowanego urządzenia lub serii mechanizmów działających na zasadzie domina, które w złożony sposób wykonują bardzo proste czynności. [Wikipedia]

Cel projektu

  • zbudowanie maszyny Rube Goldberga, składającej się z minimum 6 segmentów oraz kolejki elektrycznej
  • maszyna miała być odpowiednia dla przestrzeni, do której wchodzą ludzie w przerwie między wykładami w dniu 21 listopada 2014
  • miała działać i być efektowna

Jakie były ukryte cele i ograniczenia:

  • projekt będzie się często zmieniał
  • przy tworzeniu maszyny będzie uczestniczyło około 10 osób w różnych terminach, z różnym poziomem zaangażowania i z różnym poziomem umiejętności
  • maszyna musi być odporna na ludzi, którzy będą koło niej przechodzić i coś mogą przypadkiem zrzucić czy zniszczyć
  • projekt musi być trwały
  • projekt musi być mobilny (łatwy do przeniesienia)
  • projekt musi być odporny na zmienne warunki atmosferyczne; ktoś może otworzyć drzwi i lepiej, by wiatr nie dokonał destrukcji

Nie brzmi to jakoś przesadnie skomplikowanie, prawda? Początkowym pomysłem było stworzenie czegoś idealnego, jak z reklamy Intela.

Plusem był fakt, że zaczynamy od pustej kartki i mamy pełną dowolność, co już samo przez siebie jest sporym ograniczeniem – jak wybrać coś z nieskończonej ilości możliwości?

Jak podeszliśmy do tego projektu?

Jak zacząć

Rozpoczęliśmy od poszukiwania ideału, który ładnie wygląda, dobrze się prezentuje i jeszcze do tego działa, może trwać w nieskończoność. Zdecydowaliśmy, że najpierw sprawdzimy, czy jesteśmy w stanie wykonać przenośny, działający, odporny i szybko ustawialny projekt.

Zdecydowaliśmy się wykonać coś wystarczająco dobrego, ale spełniającego wyżej wymienione kryteria; coś, co teoretycznie mogło się rozpaść po wykonaniu zadania. Celem tego było pokazać, że coś jest wykonalne, że jest w zasięgu naszych możliwości.

Znamy domenę, czyli wiemy, jak działają prawa fizyki i chemii.

Umówiliśmy się, że spotkamy się w sobotę na terenie firmy Future Processing, w sali szkoleniowej. Każdy miał przynieść, co miał pod ręką: klocki, strzykawki, kule, kolejki elektryczne, drewniane tory, etc.

Autor Wojciech Wójcik Autor Wojciech Wójcik

Stwierdziliśmy, że jeśli w ciągu 6 godzin zbudujemy kilkusegmentową maszynę, która będzie działać i jeśli będziemy w stanie odtworzyć ją w innym miejscu, to uznamy to za sukces.

Przystąpiliśmy więc do budowy Proof of Concept (czyli prototypu).

Prototyp

Cały projekt polegał na tym, że albo uda nam się w ciągu 6h zbudować działającą maszynę zgodną z wcześniej wymienionymi wymaganiami, albo nie będziemy budować większej maszyny.

Dlaczego tak zrobiliśmy?

[caption id=“attachment_367” align=“aligncenter” width=“586”]Autor Wojciech Wójcik Autor Wojciech Wójcik[/caption]

Chcieliśmy wiedzieć, czy jest sens bardziej zaangażować się w budowę większego rozwiązania, które wymagałoby od nas dużo więcej energii. Jeśli nie jesteśmy w stanie zbudować czegoś takiego, nie zdążymy na WUD.

6-osobowa ekipa, 6 godzin na zbudowanie maszyny.

Rano jeszcze poszukiwaliśmy w firmie elementów, które moglibyśmy w szybki sposób zaadaptować do naszych potrzeb: zrobić równię pochyłą, czy jakieś proto-szyny.

Po zebraniu materiałów przystąpiliśmy do realizacji. Podzieliliśmy maszynę na mniejsze segmenty. Dlaczego tak? Ano, chcieliśmy, by możliwa była jednoczesna praca całego zespołu – chcieliśmy, aby możliwe było podzielenie całej ekipy, by zwiększyć prędkość pracy.

Dla każdego segmentu zdefiniowaliśmy, czego oczekujemy na wejściu i wyjściu poszczególnych segmentów. Przykładowo, niech pierwszy segment uruchomi klamka od drzwi, a drugi ma na wejściu bilę, która stoi nieruchomo na kijach bilardowych, ustawionych pod kątem 30 stopni.

Mieliśmy ograniczony zakres zasobów: to, co przynieśliśmy sami lub zebraliśmy w firmie. Dodatkowym utrudnieniem było to, że żadne dwa segmenty nie powinny korzystać z podobnych mechanik.

Jak wyglądała praca nad prototypem?

Próby, dużo prób.

Próbowaliśmy różnych podejść do budowy maszyny. Częste testowanie działania poszczególnych segmentów ujawniały wady, z istnienia których nie zdawaliśmy sobie sprawy.

Dla przykładu: zbudowaliśmy szyny z kijów bilardowych, po których toczyła się bila, mająca uderzyć we włącznik prądu. Po wykonaniu 20-krotnie tej czynności zauważyliśmy, że ustawienie początkowe przesunęło się na tyle znacząco, że bila nieprecyzyjnie uderzała w wyłącznik. My chcieliśmy, by mechanizmy gwarantowały powtarzalność, więc w tym wypadku musieliśmy ustabilizować całość mechanizmu.

Tworzyliśmy dużą ilość prototypów z elementów, które mieliśmy pod ręką, tylko po to, by sprawdzić, czy odpowiedni kąt nachylenia zadziała, czy bila porusza się z odpowiednią prędkością po torach kolejki elektrycznej. Chcieliśmy w miarę szybko zweryfikować pewną hipotezę, zanim sięgniemy po lepsze lub bardziej trwałe elementy. Dla przykładu: wycinaliśmy fragment z tektury przyklejonej szkotem, a po sprawdzeniu, że bila odbija się pod odpowiednim kątem, wycinaliśmy taki sam z drewna.

Po 6h mieliśmy w pełni sprawny prototyp, składający się z 5 segmentów. Maszyna ruszała, gdy ktoś naciskał klamkę, a kończyła swoją pracę efektownym uruchomieniem filmu reklamowego WUD Silesia 2014 poprzez wciśnięcie przez resoraka spacji.

Podejście zwinne do realizacji w oparciu o prototypy okazało się bardzo skuteczne.

See. Learn. Adapt. Act.

U nas wyglądało to następująco: Stwórz prototypy -> Zaobserwuj jak działa -> Dostosuj go, wprowadzając zmianę -> Działaj

A oto film prezentujący nasze działania:

https://www.youtube.com/watch?v=XaVjr43oaJ8

Dalsze kroki

Już wiedzieliśmy, że skonstruowanie maszyny jest możliwe przy udziale 6 osób.

Był to jednak Proof Of Concept, działający prototyp, na podstawie którego należało zbudować maszynę końcową.

Ustaliliśmy, że maszynę uruchamia plastikowa kula, a zwieńczeniem będzie wypadnięcie badgy z tekturowego, podwieszonego pod sufit pudełka.

Na bazie tego konceptu udało nam się zbudować gotowy produkt. Niektóre elementy wymieniliśmy na bardziej stabilne, np. użyliśmy rur odpływowych oraz wieszaków.

Dlaczego tak zrobiliśmy? Zastosowane wcześniej elementy miały działać tylko w hermetycznych i kontrolowanych warunkach. W momencie, w którym ktoś przez przypadek popchnąłby lub kopnął pierwszy fragment machiny, musielibyśmy budować wszystko od zera. Zastąpienie fragmentów konstrukcji, tymi mniej podatnymi na działanie sił trzecich, wpłynęło na bezpieczeństwo całej konstrukcji.

[caption id=“attachment_363” align=“aligncenter” width=“417”]Autor Wojciech Wójcik Autor Wojciech Wójcik[/caption]

Zaplanowaliśmy, jak to wszystko przetransportować. Zabezpieczyliśmy elementy, które w trakcie podróży mogły ulec zniszczeniu.

W trakcie rozkładania maszyny okazało się, że miejsce, w którym to wdrażamy, ma pewne ograniczenia, z których nie zdawaliśmy sobie sprawy. Trzeba zaadaptować projekt do nowych realiów za pomocą taśmy klejącej pewne rzeczy dopasować do siebie.

Czy wszystko poszło tak, jak planowaliśmy?

Oczywiście, że nie. W trakcie prezentacji jeden z elementów –wiatrak, który miał otworzyć za pomocą wstążki pudełko z niespodzianką, nie zadziałał, lecz sprawna ręka Kasjana zręcznie ukryła tę niedoskonałość, dzięki czemu efekt końcowy zaparł dech w piersi.

[caption id=“attachment_366” align=“aligncenter” width=“520”]Prototyp mechianizmu - Autor Wojciech Wójcik Autor Wojciech Wójcik[/caption]

Wnioski

Oto kilka użytecznych rad i wniosków, które pojawiły się w trakcie i po zakończeniu projektu:

1. Szukaj rozwiązania pod kątem czegoś

Nie szukamy ideału, a wystarczająco dobrego produktu, który spełnia oczekiwania. Cele powinny trzymać Cię w ryzach. Zauważ, że mogliśmy projektować w nieskończoność, wymieniać moduły na lepsze, bardziej widowiskowe, ale wyznaczone cele skutecznie ograniczały nasze nieograniczone możliwości kreatywne.

2. Zaplanuj ->Buduj -> Weryfikuj -> Popraw

Buduj prototypy, by zweryfikować, czy to, co zaprojektowałeś ma racje bytu i działa jak powinno. Nie spędzaj zbyt dużo czasu przy desce projektowej. W projekcie wszystko wygląda idealnie i działa. Dopiero, gdy zaczniesz coś budować, zaczynasz widzieć problemy. Prototyp skutecznie weryfikuje założenia. Zjawiska, które zachodziły na styku segmentów, czasami pokazywały, jak bardzo rozjeżdżaliśmy się z pierwotnymi założeniami.

3. Zdefiniuj, czym jest sukces

To jest ważny krok, by określić, jakie są kryteria sukcesu na różnych poziomach:

  • całej maszyny
  • na styku modułów
  • dla poszczególnych modułów

Nasze założenie dla Proof of concept brzmiały: jeśli uda się w ciągu 6 godzin, w ekipie 6 osobowej i z dostępnych przedmiotów, zbudować maszynę Rube Goldberga, to kontynuujemy projekt. Jeśli by się nie udało, to porzucilibyśmy ten projekt, bo nie miałby sensu.

Zdefiniowanie kryteriów na styku modułu pozwoliło nam pracować w osobnych grupach. Każda grupa wiedziała, co musi zrobić, by uruchomić kolejny segment i od czego zacząć.

4. Nie komplikuj sobie przesadnie pracy

Segmenty powinny być proste, powinny skupiać się wokół jednej mechaniki, mieć pojedynczą odpowiedzialność. Dzięki temu mniej rzeczy może nie zadziałać.

5. Mierz trzy razy zanim potniesz

Papier wybacza pomyłki. Stworzenie tańszego prototypu też. Jak już zaczniesz ciąć deskę, to trudno potem przykleić odcięty raz kawałek drewna.

6. Testuj wszystko

Serio - przygotuj się na to, że wszystko może pójść nie tak, jak zaplanowałeś i bądź przygotowany na to :) Teoretycznie moglibyśmy zbudować wszystko w muzeum i liczyć na łut szczęścia. Prawa Murphy’ego są w tym zakresie bezwzględne. Jak coś może się spi… to się spi….

7. Testuj każdy moduł z osobna

Przygotuj sobie testy dla poszczególnych modułów. Masz informacje, co ma być na wejściu i wyjściu danego modułu. Wiesz, jakie są akceptowalne zachowania. Jeśli rozłożysz pojedynczy moduł, bądź w stanie udowodnić, że działa on zgodnie z przewidywaniami. Przygotuj testy, które pokażą, że na wstępnym etapie montażu(na wdrożeniu) coś nie działa lub coś poszło nie tak.

8. Przygotuj testy na poziomie integracji poszczególnych modułów

Nawet nie jestem w stanie policzyć ilości momentów potencjalnej spektakularnej porażki gdybyśmy nie byli przygotowani, gdybyśmy nie mieli testów modularnych i integracyjnych. Jeden z modułów, dla którego nie mieliśmy testu, nad którym pracowaliśmy najmniej –  zawiódł. Nasza wina. Musimy być pewni, że wszystko będzie cały czas działać na każdym etapie budowy. Jaka była rola testów w trakcie pracy nad prototypem oraz nad finalną maszyną? Dorzucając kolejną rzecz, zmieniając kolejną rzecz, musieliśmy się upewnić, że nadal wszystko działa.

9. Gdy upewnisz się, że prototyp działa jak powinien, buduj stałe elementy

Tak – najpierw upewnij się, że prototyp robi to, co powinien. Potem możesz ulepszać, jeśli jest czas. Ważne jest, że musi istnieć logiczny powód, by to zmienić, a nie “bo tak”.

10. Nie bój się niewiedzy

Na początku było sporo wątpliwości, niepewności i niewiedzy. Dzięki temu, że budowaliśmy kolejne segmenty, w przerwach jeździliśmy do sklepów, aptek po dodatkowe rzeczy, niwelowaliśmy niepewność i poczucie niewiedzy.

11. Poznaj kontekst wdrożenia i użycia

Można żyć w przeświadczeniu, że stworzenie produktu w hermetycznym, wyizolowanym środowisku jest wystarczające, ale dopiero zderzenie produktu z rzeczywistym sposobem użycia i użytkownikiem zweryfikuje, czy mieliśmy rację. Należy poznać warunki, jakie tam będą panowały i co będą robić użytkownicy. Ogólnie rzecz biorąc, trzeba zrozumieć wszystkie źródła wpływu, które mogą oddziaływać negatywnie. Stworzyć testy, które pokażą nam, że jesteśmy odporni. Nikt chyba nie chce naprawiać czegoś na produkcji na szybko. :)

Podsumowanie

Budowa maszyny Rube Goldberga w 2014 r. pozwoliła mi zrozumieć, że sporo z tego, czego uczyłem się w trakcie wytwarzania oprogramowania, znajduje zastosowanie w innych dziedzinach.

Działanie i budowanie prototypów jest bardzo naturalnym rozwiązaniem, gdy konstruujemy coś materialnego. Dla mnie, jako programisty, do tego czasu było to czymś, co kojarzyło mi się z marnotrawieniem czasu.

Warto tworzyć takie rozwiązanie, którego nie będziemy się panicznie bali modyfikować. Środowisko tworzenia powinno wspierać taką postawę.

Powinniśmy używać skutecznych dla nas rozwiązań, a odrzucać te, które się nie sprawdzają.

Jako inżynier powinieneś mieć dowód na to, że coś działa tak, jak zaprojektowałeś. Tutaj z pomocą mogą Ci przyjść między innymi testy.

Kontekst użycia jest istotnym czynnikiem, jaki powinniśmy wziąć pod uwagę przy projektowaniu. To, że coś działa w fazie developmentu oznacza tylko, że działa to w pewnych wyizolowanych warunkach.

Prototyp służy do tego, by pokazać, że jakaś hipoteza jest warta poświęcenia czasu. Potwierdzenie lub zaprzeczenie powinno pojawić się w miarę szybko, byśmy mogli podjąć decyzję, czy wprowadzać zmianę, czy jej zaniechać. Dlatego często budujemy prototypy z tańszych, mniej trwałych zastępników. Gdy potwierdzimy hipotezę, należy zbudować rozwiązanie, bazując na kontekście użycia tego, co projektujemy.