Tim Lister - współautor książek

• "Czynnik ludzki. Udane projekty i zespoły” (oryginalna książka nosi tytuł „Peopleware”)
• „Walc z niedźwiedziami: zarządzanie ryzykiem w projektach programistycznych”
• „Oszalony adrenaliną i zombie wzorami. Wzorce zachowań zespołów projektowych”

Wszystkie te książki są klasykami w swojej dziedzinie i zostały napisane wspólnie z kolegami z firmy Gildia Systemów Atlantyckich. W Rosji jego koledzy są najbardziej znani - Tom DeMarco и Piotr Hruszka, który także napisał wiele znanych dzieł.

Tim ma 40-letnie doświadczenie w tworzeniu oprogramowania; w 1975 roku (żaden z autorów tego habrapostu nie urodził się w tym roku) Tim był już wiceprezesem wykonawczym Yourdon Inc. Obecnie spędza czas na konsultacjach, nauczaniu i pisaniu, okazjonalnie odwiedzając m.in z raportami konferencji na całym świecie.

Specjalnie dla Habr przeprowadziliśmy wywiad z Timem Listerem. Będzie otwierał konferencję DevOops 2019 i mamy wiele pytań dotyczących książek i nie tylko. Wywiad prowadzą Michaił Druzhinin i Oleg Chirukhin z komitetu programowego konferencji.

Michał: Czy możesz powiedzieć kilka słów o tym, czym się obecnie zajmujesz?

Tim: Jestem szefem Gildii Systemów Atlantyckich. W Gildii jest nas sześciu, nazywamy siebie dyrektorami. Trzech w USA i trzech w Europie – dlatego Gildia nazywa się Atlantic. Jesteśmy ze sobą tyle lat, że po prostu nie da się ich zliczyć. Wszyscy mamy swoje specjalności. Pracuję z klientami przez ostatnią dekadę lub dłużej. Moje projekty obejmują nie tylko zarządzanie, ale także ustalanie wymagań, planowanie projektu i ewaluację. Wygląda na to, że projekty, które źle się zaczynają, zwykle kończą się źle. Dlatego warto zadbać o to, aby wszystkie działania były naprawdę przemyślane i skoordynowane, aby pomysły twórców się połączyły. Warto zastanowić się co i dlaczego robisz. Jakie strategie zastosować, aby doprowadzić projekt do końca.

Od wielu lat doradzam klientom na różne sposoby. Ciekawym przykładem jest firma produkująca roboty do operacji kolana i biodra. Chirurg nie działa całkowicie samodzielnie, ale posługuje się robotem. Bezpieczeństwo tutaj, szczerze mówiąc, jest ważne. Ale kiedy spróbujesz omówić wymagania z ludźmi, którzy są skupieni na rozwiązywaniu problemów... Może to zabrzmi dziwnie, ale w USA tak jest FDA (Federalna Agencja ds. Leków), która udziela licencji na produkty takie jak te roboty. Zanim cokolwiek sprzedasz i użyjesz tego na żywych ludziach, musisz uzyskać licencję. Jednym z warunków jest pokazanie swoich wymagań, jakie są testy, jak je testowałeś, jakie są wyniki testów. Jeśli zmienisz wymagania, będziesz musiał wielokrotnie przechodzić cały ten ogromny proces testowania. Naszym klientom udało się uwzględnić w swoich wymaganiach projekt wizualny aplikacji. Mieli zrzuty ekranu bezpośrednio w ramach wymagań. Musimy je wyciągnąć i wyjaśnić, że w większości te programy nie wiedzą nic o kolanach i biodrach, o tych wszystkich rzeczach z kamerą itp. Musimy przepisać dokumenty wymagań, tak aby nigdy się nie zmieniały, chyba że ulegną zmianie naprawdę ważne podstawowe warunki. Jeśli w wymaganiach nie ma projektu wizualnego, aktualizacja produktu będzie znacznie szybsza. Naszym zadaniem jest znaleźć te elementy, które dotyczą operacji kolana, bioder, pleców, wyciągnąć je do osobnych dokumentów i powiedzieć, że będą to wymagania podstawowe. Stwórzmy izolowaną grupę wymagań dotyczących operacji kolana. Pozwoli nam to zbudować bardziej stabilny zestaw wymagań. Porozmawiamy o całej linii produktów, a nie o konkretnych robotach.

Wykonano dużo pracy, ale i tak dotarli do miejsc, w których wcześniej spędzali tygodnie i miesiące na powtarzanych testach bez sensu i potrzeby, ponieważ ich wymagania opisane na papierze nie pokrywały się z rzeczywistymi wymaganiami, dla których systemy zostały zbudowane. FDA za każdym razem im powtarzała: Twoje wymagania się zmieniły, teraz musisz sprawdzić wszystko od zera. Kompletne ponowne sprawdzenie całego produktu zabijało przedsiębiorstwo.

Są więc takie wspaniałe zadania, gdy znajdziesz się na samym początku czegoś interesującego, a już pierwsze działania wyznaczają dalsze zasady gry. Jeśli upewnisz się, że to wczesne działanie zacznie działać dobrze zarówno z zarządczego, jak i technicznego punktu widzenia, istnieje szansa, że ​​zakończysz się świetnym projektem. Ale jeśli ta część zboczyła z torów i poszła w złym kierunku, jeśli nie możesz znaleźć podstawowych ustaleń... nie, to nie jest tak, że Twój projekt koniecznie zakończy się niepowodzeniem. Ale nie będziesz już mógł powiedzieć: „Wyszło nam świetnie, wszystko zrobiliśmy naprawdę skutecznie”. Oto rzeczy, które robię, komunikując się z klientami.

Michał: To znaczy uruchamiasz projekty, robisz jakiś kickoff i sprawdzasz, czy szyny idą we właściwym kierunku?

Tim: Mamy też pomysły, jak poskładać wszystkie elementy układanki: jakich umiejętności potrzebujemy, kiedy dokładnie są potrzebne, jak wygląda trzon zespołu i inne takie fundamentalne rzeczy. Czy potrzebujemy pracowników na pełny etat, czy możemy zatrudnić kogoś na pół etatu? Planowanie, zarządzanie. Pytania typu: Co jest najważniejsze dla tego konkretnego projektu? Jak to osiągnąć? Co wiemy o tym produkcie lub projekcie, jakie jest ryzyko i gdzie leżą niewiadome, jak sobie z tym wszystkim poradzimy? Oczywiście w tym momencie ktoś zaczyna krzyczeć „A co ze zwinnością?!”. OK, wszyscy jesteście elastyczni, ale co z tego? Jak dokładnie wygląda projekt, jak go zrealizować, aby pasował do projektu? Nie można po prostu powiedzieć, że „nasze podejście rozciąga się na wszystko, jesteśmy zespołem Scrumowym!” To nonsens i nonsens. Dokąd pójdziesz dalej, dlaczego to powinno zadziałać, jaki jest tego sens? Uczę moich klientów, aby zastanawiali się nad wszystkimi tymi pytaniami.

19 lat zwinności

Michał: W Agile ludzie często starają się nie definiować niczego z góry, ale podejmować decyzje możliwie najpóźniej, mówiąc: jesteśmy za duzi, nie będę myśleć o ogólnej architekturze. Nie będę myśleć o wielu innych rzeczach; zamiast tego dostarczę klientowi coś, co zadziała już teraz.

Tim: Myślę, że metodyki zwinne, począwszy od Zwinny Manifest w 2001 roku otworzyło oczy branży. Ale z drugiej strony nic nie jest idealne. Jestem zwolennikiem iteracyjnego rozwoju. Iteracja ma sens w większości projektów. Ale pytanie, o którym musisz pomyśleć, brzmi: jak długo produkt będzie używany, gdy będzie już gotowy? Czy jest to produkt, który wytrzyma sześć miesięcy, zanim zostanie zastąpiony czymś innym? A może jest to produkt, który posłuży przez wiele, wiele lat? Oczywiście nie będę wymieniał nazwisk, ale... W Nowym Jorku i jego społeczności finansowej najbardziej podstawowe systemy są bardzo stare. To jest niesamowite. Patrzysz na nie i myślisz, gdyby tylko można było cofnąć się w czasie do roku 1994 i powiedzieć twórcom: „Przybyłem z przyszłości, z 2019 roku. Po prostu rozwijaj ten system tak długo, jak potrzebujesz. Daj możliwość rozbudowy, pomyśl o architekturze. Następnie będzie udoskonalany przez ponad dwadzieścia pięć lat. Jeśli opóźnisz rozwój trochę dłużej, w ogólnym rozrachunku nikt tego nie zauważy!” Kiedy szacujesz rzeczy w dłuższej perspektywie, musisz wziąć pod uwagę, ile to będzie kosztować ogółem. Czasami dobrze zaprojektowana architektura jest naprawdę tego warta, a czasami nie. Musimy się rozejrzeć i zadać sobie pytanie: czy jesteśmy w odpowiedniej sytuacji, aby podjąć taką decyzję?

Zatem pomysł w stylu „Jesteśmy za zwinnymi, klient sam nam powie, co chce uzyskać” – jest mega naiwny. Klienci nawet nie wiedzą, czego chcą, a tym bardziej, że nie wiedzą, co mogą dostać. Niektórzy ludzie zaczną przytaczać przykłady historyczne jako argumenty, już to widziałem. Ale ludzie zaawansowani technicznie zwykle tak nie mówią. Mówią: „Jest rok 2019, takie mamy możliwości i możemy całkowicie zmienić sposób, w jaki na te rzeczy patrzymy!” Zamiast naśladować istniejące rozwiązania, czyniąc je nieco ładniejszymi i bardziej uczesanymi, czasami trzeba wyjść i powiedzieć: „Wymyślmy na nowo to, co staramy się tutaj zrobić!”

I nie sądzę, żeby większość klientów mogła myśleć o problemie w ten sposób. Widzą tylko to, co już mają, to wszystko. Potem przychodzą z prośbami w rodzaju „uprościmy to trochę” lub cokolwiek innego, co zwykle mówią. Ale nie jesteśmy kelnerami ani kelnerkami, więc możemy przyjąć zamówienie niezależnie od tego, jak głupie się okaże, a następnie upiec je w kuchni. Jesteśmy ich przewodnikami. Musimy otworzyć im oczy i powiedzieć: hej, mamy tu nowe możliwości! Czy zdajesz sobie sprawę, że naprawdę możemy zmienić sposób prowadzenia tej części Twojego biznesu? Jednym z problemów Agile jest to, że usuwa świadomość tego, co jest szansą, co jest problemem, co w ogóle musimy zrobić, jakie dostępne technologie najlepiej nadają się do tej konkretnej sytuacji.

Być może jestem tutaj zbyt sceptyczny: w społeczności zwinnej dzieje się wiele wspaniałych rzeczy. Ale mam problem z tym, że zamiast zdefiniować projekt, ludzie zaczynają załamywać ręce. Zapytałbym tutaj – co my robimy, jak zamierzamy to zrobić? I jakimś magicznym sposobem zawsze okazuje się, że klient powinien wiedzieć lepiej niż ktokolwiek inny. Ale klient wie najlepiej tylko wtedy, gdy wybiera z rzeczy już przez kogoś zbudowanych. Jeśli chcę kupić samochód i znam wielkość budżetu rodzinnego, to szybko wybiorę samochód, który będzie odpowiadał mojemu trybowi życia. Tutaj wiem wszystko lepiej niż ktokolwiek inny! Ale proszę pamiętać, że ktoś już wyprodukował te samochody. Nie mam pojęcia, jak wymyślić nowy samochód, nie jestem ekspertem. Kiedy tworzymy produkty niestandardowe lub specjalne, trzeba brać pod uwagę głos klienta, ale nie jest to już głos jedyny.

Oleg: Wspomniałeś o Manifeście Agile. Czy trzeba to jakoś zaktualizować, zrewidować, biorąc pod uwagę współczesne rozumienie zagadnienia?

Tim: Nie dotknęłabym go. Uważam, że to wspaniały dokument historyczny. To znaczy, jest jaki jest. Ma 19 lat, jest stary, ale w swoim czasie dokonał rewolucji. Dobrze zrobił, że wywołał reakcję i ludzie zaczęli o nim szeptać. Najprawdopodobniej w 2001 roku nie pracowałeś jeszcze w branży, ale wtedy wszyscy pracowali zgodnie z procesami. Software Engineering Institute, pięć poziomów modelu kompletności oprogramowania (CMMI). Nie wiem, czy takie legendy głębokiej starożytności coś wam mówią, ale wtedy był to przełom. Początkowo ludzie wierzyli, że jeśli procesy zostaną skonfigurowane prawidłowo, problemy same znikną. I wtedy przychodzi Manifest i mówi: „Nie, nie, nie – będziemy opierać się na ludziach, a nie na procesach”. Jesteśmy mistrzami tworzenia oprogramowania. Rozumiemy, że idealny proces to miraż, który się nie zdarza. W projektach jest za dużo specyfiki, pomysł jednego, doskonałego procesu dla wszystkich projektów nie ma żadnego sensu. Problemy są zbyt złożone, aby twierdzić, że jest tylko jedno rozwiązanie wszystkiego (witaj, nirwanie).

Nie zakładam, że patrzę w przyszłość, ale powiem, że ludzie zaczęli teraz więcej myśleć o projektach. Myślę, że Manifest Agile jest bardzo dobry w wyskakiwaniu i mówieniu: „Hej! Jesteś na statku i sam nim kierujesz. Będziesz musiał podjąć decyzję – nie będziemy sugerować uniwersalnego przepisu na każdą sytuację. Jesteś załogą statku i jeśli jesteś wystarczająco dobry, możesz znaleźć drogę do celu. Przed tobą były inne statki i będą po tobie inne statki, ale w pewnym sensie twoja podróż jest wyjątkowa. Coś w tym stylu! To sposób myślenia. Dla mnie nie ma nic nowego pod słońcem, ludzie pływali już wcześniej i będą pływać ponownie, ale dla ciebie jest to twoja główna podróż i nie będę ci mówić, co dokładnie cię spotka. Trzeba mieć umiejętności skoordynowanej pracy w zespole, a jeśli je rzeczywiście posiadasz, wszystko się ułoży i dotrzesz tam, gdzie chciałeś.

Artykuły ludowe: 30 lat później

Oleg: Czy Peopleware było równie rewolucją jak Manifest?

Tim: Peopleware… Tom i ja napisaliśmy tę książkę, ale nie sądziliśmy, że to się wydarzy w ten sposób. W jakiś sposób odbiło się to na pomysłach wielu ludzi. To była pierwsza książka, w której napisano: tworzenie oprogramowania to działalność wymagająca dużego zaangażowania człowieka. Pomimo naszego technicznego charakteru, jesteśmy także społecznością ludzi budujących coś dużego, wręcz ogromnego, bardzo złożonego. Nikt nie jest w stanie stworzyć takich rzeczy sam, prawda? Dlatego idea „zespołu” stała się bardzo ważna. I to nie tylko z punktu widzenia zarządzania, ale także ludzi technicznych, którzy zebrali się, aby rozwiązać naprawdę złożone, głębokie problemy z mnóstwem niewiadomych. Dla mnie osobiście był to ogromny sprawdzian inteligencji w całej mojej karierze. I tutaj trzeba umieć powiedzieć: tak, tego problemu jest więcej, niż sam jestem w stanie sobie z nim poradzić, ale razem znajdziemy eleganckie rozwiązanie, z którego możemy być dumni. I myślę, że właśnie ten pomysł odbił się największym echem. Pomysł, że część czasu pracujemy sami, część czasu jako część grupy i często decyzję podejmuje grupa. Grupowe rozwiązywanie problemów szybko stało się ważną cechą złożonych projektów.

Pomimo tego, że Tim wygłosił ogromną liczbę przemówień, bardzo niewiele z nich jest publikowanych na YouTube. Można zapoznać się z raportem „Powrót Peopleware” z 2007 roku. Jakość oczywiście pozostawia wiele do życzenia.

Michał: Czy coś się zmieniło przez te 30 lat od wydania książki?

Tim: Można na to spojrzeć z wielu różnych punktów widzenia. Mówiąc socjologicznie... dawno, dawno temu, w prostszych czasach, ty i twój zespół siedzieliście w tym samym biurze. Można było być blisko każdego dnia, wypić razem kawę i porozmawiać o pracy. To, co naprawdę się zmieniło, to to, że zespoły mogą być teraz rozproszone geograficznie, w różnych krajach i strefach czasowych, ale nadal pracują nad tym samym problemem, co dodaje zupełnie nowy poziom złożoności. Może to zabrzmi staroświecko, ale nie ma nic lepszego niż komunikacja twarzą w twarz, podczas której wszyscy jesteście razem, pracujecie razem, a możecie podejść do kolegi i zapytać: spójrz, co odkryłem, jak ci się to podoba? Rozmowy twarzą w twarz umożliwiają szybkie przejście do nieformalnej komunikacji i myślę, że entuzjastom zwinności też powinno się to spodobać. I też się martwię, bo w rzeczywistości świat okazał się bardzo mały, a teraz wszystko jest zajęte rozproszonymi zespołami i wszystko jest bardzo skomplikowane.

Wszyscy żyjemy w DevOps

Michał: Nawet z punktu widzenia komitetu programowego konferencji mamy ludzi w Kalifornii, w Nowym Jorku, w Europie, w Rosji… w Singapurze nie ma jeszcze nikogo. Różnica geograficzna jest dość duża, a ludzie zaczynają się jeszcze bardziej rozprzestrzeniać. Jeśli mówimy o rozwoju, czy możesz nam powiedzieć więcej o devopsach i przełamywaniu barier między zespołami? Istnieje koncepcja, że ​​wszyscy siedzą w swoich bunkrach, a teraz bunkry się zawalają. Co sądzisz o tej analogii?

Tim: Wydaje mi się, że w świetle ostatnich przełomów technologicznych devops ma ogromne znaczenie. Wcześniej miałeś zespoły programistów i administratorów, pracowali, pracowali, pracowali i w pewnym momencie pojawiła się rzecz, z którą mogłeś przyjść do administratorów i wdrożyć to na produkcję. I tu zaczęła się rozmowa o bunkrze, bo admini to w pewnym sensie sojusznicy, a nie wrogowie, ale rozmawiało się z nimi dopiero wtedy, gdy wszystko było gotowe do rozpoczęcia produkcji. Czy poszedłeś do nich z czymś i powiedziałeś: spójrz, jaką mamy aplikację, ale czy mógłbyś tę aplikację wdrożyć? A teraz cała koncepcja dostawy zmieniła się na lepsze. To znaczy, pojawił się pomysł, że można szybko przeforsować zmiany. Produkty możemy aktualizować na bieżąco. Zawsze się uśmiecham, gdy pojawia się Firefox na moim laptopie i mówi: „Hej, zaktualizowaliśmy Twojego Firefoksa w tle. Czy mógłbyś, gdy tylko znajdziesz chwilę, kliknąć tutaj, a my udostępnimy Ci najnowszą wersję”. A ja na to: „O tak, kochanie!” Kiedy spałem, pracowali nad dostarczeniem mi nowej wersji bezpośrednio na mój komputer. To jest cudowne, niesamowite.

Ale tu jest trudność: masz tę funkcję z aktualizacją oprogramowania, ale integracja ludzi jest znacznie trudniejsza. Podczas przemówienia DevOops chcę powiedzieć, że mamy teraz o wiele więcej graczy niż kiedykolwiek wcześniej. Jeśli pomyślisz tylko o wszystkich zaangażowanych w tylko jeden zespół…. Myślałeś o tym jak o zespole, a to znacznie więcej niż tylko zespół programistów. Są to testerzy, kierownicy projektów i mnóstwo innych osób. I każdy ma swoje własne poglądy na świat. Menedżerowie produktu różnią się całkowicie od menedżerów projektów. Administratorzy mają swoje własne zadania. Koordynacja wszystkich uczestników tak, aby nadal być świadomi tego, co się dzieje i nie zwariować, staje się dość trudnym problemem. Konieczne jest oddzielenie zadań grupy od zadań, które dotyczą wszystkich. To bardzo trudne zadanie. Z drugiej strony uważam, że jest dużo lepiej niż wiele lat temu. To jest dokładnie droga, na której ludzie dorastają i uczą się prawidłowego zachowania. Kiedy robisz integrację, rozumiesz, że nie powinno być żadnego podziemnego rozwoju, aby w ostatniej chwili oprogramowanie nie wypełzało jak jack-in-the-box: na przykład, spójrz, co tutaj zrobiliśmy! Pomysł jest taki, że będziesz mógł przeprowadzić integrację i rozwój, a na koniec będziesz wdrażać w schludny i iteracyjny sposób. Wszystko to wiele dla mnie znaczy. Dzięki temu możesz stworzyć większą wartość dla użytkowników systemu i dla Twojego klienta.

Michał: Cała idea Devops polega na dostarczaniu znaczących rozwiązań tak wcześnie, jak to możliwe. Widzę, że świat zaczął coraz bardziej przyspieszać. Jak przystosować się do takich przyspieszeń? Dziesięć lat temu czegoś takiego nie było!

Tim: Oczywiście każdy chce coraz większej funkcjonalności. Nie musisz się ruszać, po prostu nałóż więcej. Czasami trzeba nawet zwolnić, aby kolejna aktualizacja przyrostowa wniosła coś przydatnego – i jest to całkowicie normalne.

Pomysł, że musisz biegać, biegać, biegać, nie jest najlepszy. Mało prawdopodobne, żeby ktokolwiek chciał tak żyć. Chciałbym, żeby rytm dostaw wyznaczał rytm projektu. Jeśli wytworzysz strumień małych, stosunkowo bezsensownych rzeczy, wszystko to nie będzie miało żadnego znaczenia. Zamiast bezmyślnie próbować wypuścić coś jak najwcześniej, warto omówić strategię z głównymi programistami oraz menedżerami produktów i projektów. Czy to w ogóle ma sens?

Wzory i antywzory

Oleg: Zwykle mówisz o wzorach i antywzorach i to jest różnica między życiem a śmiercią projektów. A teraz Devops wkracza w nasze życie. Czy ma jakieś swoje własne wzorce i antywzorce, które mogą od razu unicestwić projekt?

Tim: Wzory i anty-wzorce zdarzają się cały czas. Jest o czym rozmawiać. Cóż, jest coś, co nazywamy „błyszczącymi rzeczami”. Ludzie naprawdę lubią nowe technologie. Są po prostu zahipnotyzowani blaskiem wszystkiego, co wygląda fajnie i stylowo, i przestają zadawać pytania: czy to w ogóle konieczne? Co zamierzamy osiągnąć? Czy to jest pewne, czy ma to jakiś sens? Często widzę ludzi, że tak powiem, korzystających z najnowocześniejszej technologii. Są zahipnotyzowani tym, co dzieje się na świecie. Ale jeśli przyjrzysz się bliżej, jakie przydatne rzeczy robią, często po prostu nie ma nic przydatnego!

Właśnie rozmawialiśmy z naszymi towarzyszami, że w tym roku przypada rocznica pięćdziesiątej rocznicy lądowania ludzi na Księżycu. Miało to miejsce w 1969 r. Technologia, która pomogła ludziom się tam dostać, to nawet nie technologia z 1969 r., ale raczej z 1960 r. lub 62 r., ponieważ NASA chciała używać tylko tych, które mają dobre dowody niezawodności. A więc patrzysz na to i rozumiesz - tak, i były one prawdziwe! Nie, nie, ale pojawiają się problemy z technologią po prostu dlatego, że wszystko jest narzucane zbyt mocno i sprzedawane na chybił trafił. Zewsząd ludzie krzyczą: „Patrzcie, co za rzecz, to coś najnowszego, najpiękniejszego na świecie, pasującego absolutnie każdemu!” No cóż… zazwyczaj to wszystko okazuje się tylko przynętą i wtedy trzeba to wszystko wyrzucić. Być może to wszystko dlatego, że jestem już starym człowiekiem i patrzę na takie rzeczy z dużym sceptycyzmem, kiedy ludzie wybiegają i mówią, że znaleźli Jedyny, Najbardziej Właściwy Sposób na Tworzenie Najlepszych Technologii. W tym momencie budzi się we mnie głos, który mówi: „Co za bałagan!”

Michał: Rzeczywiście, jak często słyszeliśmy o kolejnej srebrnej kuli?

Tim: Dokładnie, i to jest normalna kolej rzeczy! Na przykład...wydaje się, że to już stał się żartem na całym świecie, a tutaj często mówi się o technologii blockchain. I rzeczywiście mają sens w pewnych sytuacjach! Kiedy naprawdę potrzebujesz wiarygodnych dowodów na zdarzenia, że ​​system działa i że nikt nas nie oszukał, gdy masz problemy z bezpieczeństwem i to wszystko pomieszane – blockchain ma sens. Ale kiedy mówią, że Blockchain ogarnie teraz cały świat, zmiatając wszystko na swojej drodze? Śnij więcej! Jest to bardzo droga i skomplikowana technologia. Technicznie skomplikowane i czasochłonne. W tym czysto algorytmicznie, za każdym razem trzeba przeliczyć obliczenia matematyczne, z najmniejszymi zmianami... i to jest świetny pomysł - ale tylko w niektórych przypadkach. Całe moje życie i kariera skupiały się na tym: ciekawych pomysłach w bardzo specyficznych sytuacjach. Bardzo ważne jest, aby dokładnie zrozumieć, jaka jest Twoja sytuacja.

Michał: Tak, główne „kwestia życia, wszechświata i wszystkiego”: czy ta technologia lub podejście jest odpowiednie w Twojej sytuacji, czy nie?

Tim: Tę kwestię można już omówić z grupą technologiczną. Może nawet sprowadzimy jakiegoś konsultanta. Przyjrzyj się projektowi i zrozum – czy zrobimy teraz coś dobrego i pożytecznego, lepszego niż wcześniej? Może będzie pasować, może nie. Ale co najważniejsze, nie podejmuj takiej decyzji z góry, tylko dlatego, że ktoś wypalił: „Desperacko potrzebujemy blockchain! Właśnie przeczytałam o nim w czasopiśmie w samolocie!” Poważnie? To nawet nie jest śmieszne.

Mityczny „inżynier Devops”

Oleg: Teraz wszyscy wdrażają devops. Ktoś czyta o devopsach w internecie, a jutro na portalu rekrutacyjnym pojawia się kolejne wakat. „inżynier Devops”. W tym miejscu chciałbym zwrócić Państwa uwagę: czy uważacie, że termin „inżynier Devops” ma prawo do życia? Istnieje opinia, że ​​devops to kultura i coś tu nie gra.

Tim: Tak sobie. Niech więc natychmiast podają pewne wyjaśnienie tego terminu. Coś, co sprawi, że będzie wyjątkowy. Dopóki nie udowodnią, że za takim stanowiskiem kryje się wyjątkowa kombinacja umiejętności, nie kupię go! To znaczy, cóż, mamy stanowisko „inżynier Devops”, ciekawy tytuł, tak, co dalej? Nazwy stanowisk są ogólnie bardzo interesującą rzeczą. Powiedzmy „programista” – co to właściwie jest? Różne organizacje oznaczają zupełnie różne rzeczy. W niektórych firmach wysokiej klasy programiści piszą testy, które mają większy sens niż testy pisane przez specjalnych profesjonalnych testerów w innych firmach. I co, są teraz programistami czy testerami?

Tak, mamy stanowiska, ale jeśli zadajemy pytania wystarczająco długo, w końcu okazuje się, że wszyscy potrafimy rozwiązywać problemy. Jesteśmy poszukiwaczami rozwiązań i niektórzy mają pewne umiejętności techniczne, a inni inne. Jeśli żyjesz w środowisku, w którym przeniknął DevOps, zajmujesz się integracją rozwoju i administracji, a działanie to ma jakiś dość ważny cel. Ale jeśli zapytasz, czym dokładnie się zajmujesz i za co jesteś odpowiedzialny, okazuje się, że ludzie robią to wszystko od niepamiętnych czasów. „Jestem odpowiedzialny za architekturę”, „Jestem odpowiedzialny za bazy danych” i tak dalej, nieważne, widzisz - to wszystko było przed „devops”.

Kiedy ktoś mówi mi, na czym polega jego stanowisko, nie słucham zbyt wiele. Lepiej pozwolić mu powiedzieć, za co właściwie jest odpowiedzialny, dzięki temu będziemy mogli znacznie lepiej zrozumieć sprawę. Mój ulubiony przykład to sytuacja, w której ktoś podaje się za „menedżera projektu”. Co? To nic nie znaczy, nadal nie wiem, co robisz. Kierownikiem projektu może być programista, lider czteroosobowego zespołu, piszący kod, wykonujący pracę, który stał się liderem zespołu, którego ludzie sami rozpoznają wśród siebie jako lidera. Ponadto kierownikiem projektu może być menedżer, który zarządza sześcioma setkami osób w projekcie, zarządza innymi menedżerami, jest odpowiedzialny za sporządzanie harmonogramów i planowanie budżetów, to wszystko. To dwa zupełnie różne światy! Ale ich stanowisko brzmi tak samo.

Odwróćmy to trochę inaczej. W czym jesteś naprawdę dobry, masz duże doświadczenie, do czego masz talent? Za co weźmiesz odpowiedzialność, bo uważasz, że podołasz temu zadaniu? I tu od razu ktoś zacznie zaprzeczać: nie, nie, nie, nie mam ochoty w ogóle zajmować się zasobami projektowymi, to nie moja sprawa, jestem techniczny koleś i rozumiem użyteczność i interfejsy użytkownika, nie chcę w ogóle kierować armią ludzi, niech lepiej pójdę do pracy.

A tak na marginesie, jestem wielkim zwolennikiem podejścia, w którym tego rodzaju rozdzielenie umiejętności sprawdza się dobrze. Gdzie technicy mogą rozwijać swoją karierę tak daleko, jak chcą. Jednak nadal widzę organizacje, w których technicy narzekają: będę musiał zająć się zarządzaniem projektami, ponieważ w tej firmie to jedyna droga. Czasami prowadzi to do strasznych skutków. Najlepsi technicy wcale nie są dobrymi menedżerami, a najlepsi menedżerowie nie radzą sobie z technologią. Bądźmy w tej kwestii szczerzy.

Widzę teraz duże zapotrzebowanie na to. Jeśli jesteś technikiem, Twoja firma może Ci pomóc, ale niezależnie od tego, czego potrzebujesz, naprawdę musisz znaleźć własną ścieżkę kariery, ponieważ technologia ciągle się zmienia i musisz wraz z nią odkrywać siebie na nowo! W ciągu zaledwie dwudziestu lat technologie mogą zmienić się co najmniej pięć razy. Technologia to dziwna rzecz...

„Eksperci od wszystkiego”

Michał: Jak ludzie mogą sobie poradzić z taką szybkością zmian technologicznych? Rośnie ich złożoność, rośnie ich liczba, rośnie także ogólny zakres komunikacji między ludźmi i okazuje się, że nie można stać się „ekspertem od wszystkiego”.

Tim: Prawidłowy! Jeśli pracujesz w technologii to tak, zdecydowanie musisz wybrać coś konkretnego i się w to zagłębić. Niektóre technologie, które Twoja organizacja uzna za przydatne (i być może faktycznie będą przydatne). A jeśli nie jesteś już tym zainteresowany – nigdy bym nie uwierzył, że to powiem – cóż, może powinieneś przenieść się do innej organizacji, w której technologia jest ciekawsza i wygodniejsza do studiowania.

Ale ogólnie tak, masz rację. Technologie rozwijają się we wszystkich kierunkach jednocześnie i nikt nie może powiedzieć: „Jestem ekspertem w dziedzinie technologii we wszystkich istniejących technologiach”. Z drugiej strony są ludzie-gąbki, którzy dosłownie chłoną wiedzę technologiczną i szaleją na jej punkcie. Widziałem kilka takich osób, dosłownie oddychają i żyją, rozmowa z nimi jest pożyteczna i interesująca. Badają nie tylko to, co dzieje się wewnątrz organizacji, ale w ogóle o tym mówią, są też naprawdę fajnymi technologami, są bardzo świadomi i celowi. Po prostu starają się utrzymać na szczycie fali, niezależnie od tego, jaka jest ich główna praca, ponieważ ich pasją jest ruch Technologii, promocja technologii. Jeśli nagle spotkasz taką osobę, powinieneś pójść z nią na lunch i podczas lunchu omówić różne fajne rzeczy. Myślę, że każda organizacja potrzebuje przynajmniej kilku takich osób.

Ryzyka i niepewność

Michał: Szanowni inżynierowie, tak. Poruszmy kwestię zarządzania ryzykiem, póki mamy czas. Rozpoczęliśmy ten wywiad od dyskusji na temat oprogramowania medycznego, w którym błędy mogą prowadzić do tragicznych konsekwencji. Następnie rozmawialiśmy o Programie Księżycowym, w którym koszt błędu to miliony dolarów i prawdopodobnie życie kilku osób. Ale teraz widzę w branży ruch odwrotny, ludzie nie myślą o zagrożeniach, nie próbują ich przewidywać, nawet ich nie zauważają.

Oleg: Poruszaj się szybko i niszcz rzeczy!

Michał: Tak, działaj szybko, niszcz rzeczy, coraz więcej rzeczy, aż od czegoś umrzesz. Jak z Twojego punktu widzenia powinien teraz podejść przeciętny programista do zarządzania ryzykiem związanym z uczeniem się?

Tim: Narysujmy tutaj granicę pomiędzy dwiema rzeczami: ryzykiem i niepewnością. To są różne rzeczy. Niepewność pojawia się, gdy w danym momencie nie masz wystarczającej ilości danych, aby uzyskać ostateczną odpowiedź. Na przykład, jeśli na bardzo wczesnym etapie projektu ktoś zapyta Cię „kiedy skończysz pracę”, jeśli jesteś osobą w miarę uczciwą, odpowiesz: „Nie mam pojęcia”. Po prostu nie wiesz i to jest w porządku. Nie przestudiowałeś jeszcze problemów i nie znasz zespołu, nie znasz jego umiejętności i tak dalej. To jest niepewność.

Ryzyko pojawia się, gdy można już zidentyfikować potencjalne problemy. Coś takiego może się zdarzyć, jego prawdopodobieństwo jest większe od zera, ale mniejsze niż sto procent, gdzieś pomiędzy. Przez to wszystko może się zdarzyć, od opóźnień i niepotrzebnej pracy, ale nawet do fatalnego wyniku dla projektu. Wynik, kiedy powiecie – chłopaki, złóżmy parasole i opuśćmy plażę, nigdy tego nie skończymy, to wszystko się skończy, kropka. Założyliśmy, że to zadziała, ale w ogóle nie działa, czas z tym skończyć. To są sytuacje.

Często problemy najłatwiej jest rozwiązać, gdy już się pojawiły, gdy problem występuje właśnie teraz. Ale kiedy problem jest tuż przed tobą, nie zajmujesz się zarządzaniem ryzykiem – zajmujesz się rozwiązywaniem problemów, zarządzaniem kryzysowym. Jeśli jesteś głównym programistą lub menadżerem, z pewnością zastanawiasz się, co może się wydarzyć, co doprowadzi do opóźnień, straty czasu, niepotrzebnych kosztów lub załamania się całego projektu? Co sprawi, że zatrzymamy się i zaczniemy od nowa? Kiedy to wszystko zacznie działać, co z nimi zrobimy? Istnieje prosta odpowiedź, która sprawdza się w większości sytuacji: nie uciekaj od zagrożeń, pracuj nad nimi. Zobacz, jak możesz rozwiązać ryzykowną sytuację, zredukować ją do zera, zmienić problem w coś innego. Zamiast mówić: cóż, problemy będziemy rozwiązywać w miarę ich pojawiania się.

Niepewność i ryzyko powinny być na pierwszym planie we wszystkim, z czym masz do czynienia. Możesz sporządzić plan projektu, spojrzeć z wyprzedzeniem na pewne krytyczne ryzyka i powiedzieć: musimy sobie z tym poradzić teraz, ponieważ jeśli coś pójdzie nie tak, nic innego nie będzie miało znaczenia. Nie powinieneś martwić się o piękno obrusu na stole, jeśli nie jest jasne, czy możesz ugotować obiad. Najpierw musisz zidentyfikować wszystkie zagrożenia związane z przygotowaniem pysznego obiadu, uporać się z nimi, a dopiero potem pomyśleć o wszystkich innych rzeczach, które nie stanowią realnego zagrożenia.

Powtórzę jeszcze raz: co czyni Twój projekt wyjątkowym? Zobaczmy, co może popsuć nasz projekt. Co możemy zrobić, aby zminimalizować prawdopodobieństwo wystąpienia takiej sytuacji? Zwykle nie można ich po prostu zneutralizować w 100% i z czystym sumieniem stwierdzić: „To koniec, to już nie jest problem, ryzyko minęło!” Dla mnie to oznaka dorosłego zachowania. Na tym polega różnica między dzieckiem a dorosłym – dzieci myślą, że są nieśmiertelne, że nic nie może pójść źle, wszystko będzie dobrze! W tym samym czasie dorośli obserwują, jak trzyletnie dzieci skaczą na placu zabaw, oczami śledzą ruchy i mówią sobie: „och-och, ooch-och”. Stoję w pobliżu i przygotowuję się do złapania dziecka, gdy upadnie.

Z drugiej strony powodem, dla którego tak bardzo lubię ten biznes, jest to, że jest ryzykowny. Robimy różne rzeczy i są one ryzykowne. Wymagają dorosłego podejścia. Sam entuzjazm nie rozwiąże Twoich problemów!

Myślenie inżynieryjne dla dorosłych

Michał: Przykład z dziećmi jest dobry. Jeśli jestem zwykłym inżynierem, to cieszę się, że jestem dzieckiem. Ale jak przejść do bardziej dorosłego myślenia?

Tim: Jednym z pomysłów, który sprawdza się równie dobrze zarówno u początkującego, jak i doświadczonego programisty, jest koncepcja kontekstu. Co robimy, co zamierzamy osiągnąć. Co jest naprawdę ważne w tym projekcie? Nie ma znaczenia, kim jesteś w tym projekcie, czy jesteś stażystą, czy głównym architektem, każdy potrzebuje kontekstu. Musimy skłonić wszystkich do myślenia w szerszej skali niż ich własne dzieła. „Robię swoje dzieło i dopóki działa, jestem szczęśliwy”. Nie i jeszcze raz nie. Zawsze warto (bez bycia niegrzecznym!) przypominać ludziom o kontekście, w jakim pracują. Co wszyscy razem staramy się osiągnąć. Pomysły, że możesz być dzieckiem, jeśli wszystko jest w porządku z twoją częścią projektu – proszę, nie rób tego. Jeśli w ogóle przekroczymy linię mety, to tylko razem. Nie jesteś sam, jesteśmy wszyscy razem. Gdyby wszyscy uczestnicy projektu, zarówno starzy, jak i młodzi, zaczęli rozmawiać o tym, co dokładnie jest ważne dla projektu i dlaczego firma inwestuje pieniądze w to, co wszyscy staramy się osiągnąć… większość z nich poczuje się znacznie lepiej, ponieważ zobaczą, jak ich praca koreluje z pracą wszystkich innych. Z jednej strony rozumiem dzieło, za które jestem osobiście odpowiedzialny. Ale aby dokończyć tę pracę, potrzebujemy też wszystkich innych ludzi. A jeśli naprawdę myślisz, że już skończyłeś, zawsze mamy nad czym pracować w projekcie!

Oleg: Relatywnie rzecz biorąc, jeśli pracujesz według Kanbana, kiedy trafisz na wąskie gardło w niektórych testach, możesz rzucić to, co tam robiłeś (na przykład programowanie) i pomóc testerom.

Tim: Dokładnie. Myślę, że najlepsi technicy, jeśli przyjrzysz się im bliżej, są w pewnym sensie swoimi własnymi menedżerami. Jak mogę to sformułować...

Oleg: Twoje życie jest Twoim projektem, którym zarządzasz.

Tim: Dokładnie! To znaczy, bierzesz na siebie odpowiedzialność, rozumiesz problem i kontaktujesz się z ludźmi, gdy widzisz, że twoje decyzje mogą mieć wpływ na ich pracę i tym podobne. Nie chodzi o to, żeby po prostu siedzieć przy biurku, wykonywać swoją pracę i nawet nie zdawać sobie sprawy z tego, co dzieje się wokół ciebie. Nie nie nie. Swoją drogą, jedną z najlepszych rzeczy w Agile jest to, że zaproponowali krótkie sprinty, bo w ten sposób stan rzeczy wszystkich uczestników jest wyraźnie widoczny, mogą zobaczyć to wszystko razem. Codziennie o sobie rozmawiamy.

Jak wejść w zarządzanie ryzykiem

Oleg: Czy istnieje jakaś formalna struktura wiedzy w tym obszarze? Na przykład jestem programistą Java i chcę zrozumieć zarządzanie ryzykiem, nie stając się z wykształcenia prawdziwym kierownikiem projektu. Prawdopodobnie najpierw przeczytam książkę McConnella „Ile kosztuje projekt oprogramowania”, a potem co? Jakie są pierwsze kroki?

Tim: Pierwszym z nich jest rozpoczęcie komunikacji z ludźmi w projekcie. Zapewnia to natychmiastową poprawę kultury komunikacji ze współpracownikami. Musimy zacząć od domyślnego otwarcia wszystkiego, zamiast to ukrywać. Powiedz: to są rzeczy, które mnie niepokoją, to są rzeczy, które nie pozwalają mi spać w nocy. Obudziłem się dzisiaj w nocy i pomyślałem: mój Boże, muszę o tym pomyśleć! Czy inni widzą to samo? Czy jako grupa powinniśmy zareagować na te potencjalne problemy? Musisz być w stanie wesprzeć dyskusję na te tematy. Nie ma z góry przygotowanej formuły, według której pracujemy. Nie chodzi o robienie hamburgerów, chodzi o ludzi. „Zrobiłem cheeseburgera, sprzedam cheeseburgera” to zupełnie nie nasza specjalność i dlatego tak bardzo kocham tę pracę. Lubię, gdy wszystko, co kiedyś robili menadżerowie, teraz staje się własnością zespołu.

Oleg: W książkach i wywiadach wspominałeś o tym, że ludziom bardziej zależy na szczęściu niż na liczbach na wykresie. Z drugiej strony, gdy powiesz zespołowi: przechodzimy na devops, a teraz programista musi stale się komunikować, może to być daleko poza jego strefą komfortu. I w tej chwili może, powiedzmy, być głęboko nieszczęśliwy. Co zrobić w tej sytuacji?

Tim: Nie jestem pewien, co dokładnie zrobić. Jeśli programista jest zbyt odizolowany, w ogóle nie widzi, dlaczego praca jest wykonywana, po prostu patrzy na swoją część pracy i musi dostać się do tego, co nazywam „kontekstem”. Musi dowiedzieć się, jak wszystko jest ze sobą powiązane. I oczywiście nie mam na myśli oficjalnych prezentacji ani nic w tym stylu. Mówię o tym, że ze współpracownikami trzeba rozmawiać o pracy jako o całości, a nie tylko o jej części, za którą jesteś odpowiedzialny. W tym miejscu możesz rozpocząć dyskusję na temat pomysłów, wspólnych ustaleń, które sprawią, że Twoja praca będzie dobrze ze sobą współgrać, oraz tego, jak wspólnie rozwiązać wspólny problem.

Aby pomóc im się zaadaptować, często chcą wysyłać techników na szkolenie i omawiają szkolenie. Mój przyjaciel lubi mawiać, że szkolenie jest dla psów. Jest szkolenie dla ludzi. Jedną z najlepszych rzeczy w nauce programisty jest interakcja z rówieśnikami. Jeśli ktoś jest w czymś naprawdę dobry, powinieneś obserwować go przy pracy lub rozmawiać z nim o jego pracy lub czymś podobnym. Jakiś konwencjonalny Kent Beck ciągle mówił o programowaniu ekstremalnym. To zabawne, bo XP to taki prosty pomysł, a powoduje tyle problemów. Dla niektórych zdobycie XP jest jak bycie zmuszonym do rozebrania się do naga przed przyjaciółmi. Zobaczą, co robię! To moi koledzy, nie tylko zobaczą, ale i zrozumieją! Straszny! Niektórzy ludzie zaczynają się poważnie denerwować. Ale kiedy zdasz sobie sprawę, że jest to najlepszy sposób nauki, wszystko się zmienia. Ściśle współpracujesz z ludźmi, a niektórzy ludzie rozumieją temat znacznie lepiej niż Ty.

Michał: Ale to wszystko zmusza Cię do wyjścia ze swojej strefy komfortu. Jako inżynier musisz wyjść ze swojej strefy komfortu i komunikować się. Jako osoba rozwiązująca problemy musisz stale stawiać się na słabej pozycji i myśleć o tym, co może pójść nie tak. Ten rodzaj pracy jest z natury uciążliwy. Świadomie narażasz się na stresujące sytuacje. Zwykle ludzie od nich uciekają, ludzie lubią być szczęśliwymi dziećmi.

Tim: Co można zrobić, można wyjść i otwarcie powiedzieć: „Wszystko w porządku, dam sobie radę! Nie tylko ja czuję się niekomfortowo. Porozmawiajmy o różnych niewygodnych rzeczach, wszyscy razem, jako zespół!” To są nasze wspólne problemy, musimy sobie z nimi poradzić, wiesz? Myślę, że specyficzni, genialni twórcy są jak mamuty: zniknęli. A ich znaczenie jest bardzo ograniczone. Jeśli nie potrafisz się komunikować, nie możesz dobrze uczestniczyć. Dlatego po prostu mów. Bądź szczery i otwarty. Bardzo mi przykro, że jest to dla kogoś nieprzyjemne. Czy możesz sobie wyobrazić, że wiele lat temu przeprowadzono badanie, według którego głównym strachem w Stanach Zjednoczonych nie jest śmierć, ale zgadnijcie co? Strach przed wystąpieniami publicznymi! Oznacza to, że gdzieś są ludzie, którzy woleliby umrzeć, niż powiedzieć głośno komplement. Myślę, że wystarczą Ci pewne podstawowe umiejętności, w zależności od tego, czym się zajmujesz. Umiejętność mówienia, umiejętność pisania – ale tylko tyle, ile jest naprawdę potrzebne w Twojej pracy. Jeśli pracujesz jako analityk, ale nie umiesz czytać, pisać ani mówić, to niestety nie będziesz miał nic do roboty w moich projektach!

Cena komunikacji

Oleg: Czy zatrudnianie takich odchodzących pracowników nie jest z różnych powodów droższe? W końcu ciągle rozmawiają, zamiast pracować!

Tim: Miałem na myśli trzon zespołu, a nie tylko wszystkich. Jeśli masz kogoś, kto jest naprawdę fajny w dostrajaniu baz danych, uwielbia dostrajać bazy danych i zamierza kontynuować dostrajanie baz danych przez resztę swojego życia i to wszystko, super, tak trzymaj. Ale mówię o ludziach, którzy chcą zamieszkać w samym projekcie. Trzon zespołu, którego celem jest rozwój projektu. Ci ludzie naprawdę muszą stale się ze sobą komunikować. A szczególnie na początku projektu, kiedy omawiasz ryzyko, sposoby osiągnięcia globalnych celów i tym podobne.

Michał: Dotyczy to wszystkich zaangażowanych w projekt, niezależnie od specjalizacji, umiejętności czy sposobu pracy. Wszyscy jesteście zainteresowani sukcesem projektu.

Tim: Tak, czujesz, że jesteś wystarczająco zanurzony w projekcie, że Twoim zadaniem jest pomóc w jego realizacji. Niezależnie od tego, czy jesteś programistą, analitykiem, projektantem interfejsów, kimkolwiek. To jest powód, dla którego przychodzę każdego ranka do pracy i tym właśnie się zajmujemy. Jesteśmy odpowiedzialni za tych wszystkich ludzi, niezależnie od ich umiejętności. To grupa osób, które prowadzą dorosłe rozmowy.

Oleg: Tak naprawdę mówiąc o gadatliwych pracownikach, starałem się symulować sprzeciw ludzi, zwłaszcza menedżerów, którzy są proszeni o przejście na devops, wobec tej zupełnie nowej wizji świata. A Ty, jako konsultanci, powinieneś zdawać sobie sprawę z tych zastrzeżeń znacznie lepiej niż ja, jako programista! Podziel się tym, co najbardziej martwi menedżerów?

Tim: Menedżerowie? Hm. Najczęściej menedżerowie znajdują się pod presją problemów, w obliczu konieczności pilnego wydania czegoś i dostarczenia dostawy i tym podobnych. Obserwują, jak ciągle o czymś dyskutujemy i spieramy się, i widzą to tak: rozmowy, rozmowy, rozmowy... Jakie jeszcze rozmowy? Wracaj do pracy! Ponieważ mówienie nie jest dla nich pracą. Nie piszesz kodu, nie testujesz oprogramowania, wydaje się, że nic nie robisz – dlaczego nie wysłać Cię do zrobienia czegoś? W końcu dostawa jest już za miesiąc!

Michał: Idź napisać jakiś kod!

Tim: Wydaje mi się, że nie martwią się pracą, a brakiem widoczności postępu. Aby sprawiać wrażenie, że jesteśmy coraz bliżej sukcesu, muszą zobaczyć, jak naciskamy przyciski na klawiaturze. Cały dzień od rana do wieczora. To jest problem numer jeden.

Oleg: Misza, myślisz o czymś.

Michał: Przepraszam, zamyśliłem się i przypomniało mi się. Wszystko to przypomniało mi o ciekawym wiecu, który odbył się wczoraj... Wczoraj było zbyt wiele wieców... I wszystko brzmi bardzo znajomo!

Życie bez pensji

Tim: Nawiasem mówiąc, organizowanie „wieców” w celu komunikacji wcale nie jest konieczne. Mam na myśli, że najbardziej przydatne dyskusje między programistami mają miejsce, gdy po prostu ze sobą rozmawiają. Wchodzisz rano z filiżanką kawy, a tam pięć osób zebrało się i wściekle dyskutują o czymś technicznym. Dla mnie, jeśli jestem menadżerem tego projektu, lepiej po prostu się uśmiechnąć i pójść gdzieś ze swoją sprawą, pozwolić im to przedyskutować. Zaangażowali się już tak bardzo, jak to możliwe. To dobry znak.

Oleg: Swoją drogą, w swojej książce masz mnóstwo notatek na temat tego, co jest dobre, a co złe. Czy sam używasz któregoś z nich? Relatywnie rzecz biorąc, teraz masz firmę, która ma bardzo niekonwencjonalną strukturę...

Tim: Niekonwencjonalne, ale to urządzenie nam pasuje idealnie. Znamy się od dawna. Ufamy sobie, ufaliśmy sobie bardzo, zanim zostaliśmy partnerami. I na przykład nie mamy w ogóle wynagrodzeń. Po prostu pracujemy i np. jeśli zarabiałem od swoich klientów, to wszystkie pieniądze trafiały do ​​mnie. Następnie płacimy składki członkowskie organizacji, a to wystarczy na utrzymanie samej firmy. Poza tym każdy z nas specjalizuje się w czymś innym. Ja na przykład współpracuję z księgowymi, wypełniam zeznania podatkowe, załatwiam różne sprawy administracyjne w firmie i nikt mi za to nie płaci. James i Tom pracują na naszej stronie internetowej i nikt im też nie płaci. Dopóki będziesz płacić swoje składki, nikt nie pomyśli o mówieniu Ci, co masz robić. Na przykład Tomek pracuje teraz znacznie mniej niż kiedyś. Teraz ma inne zainteresowania, pewne rzeczy robi nie dla Gildii. Ale dopóki będzie płacił składki, nikt nie podejdzie do niego i nie powie: „Hej, Tomek, idź do pracy!” Bardzo łatwo jest dogadać się ze współpracownikami, gdy nie ma między wami pieniędzy. A teraz nasza relacja jest jedną z podstawowych idei w odniesieniu do różnych specjalności. To działa i to bardzo dobrze.

Najlepsza rada

Michał: Wracając do „najlepszych rad”, czy jest coś, co ciągle powtarzasz swoim klientom? Istnieje koncepcja 80/20, a niektóre rady powtarzane są zapewne częściej.

Tim: Kiedyś myślałem, że gdybyś napisał książkę taką jak Walc z niedźwiedziami, zmieniłoby to bieg historii i ludzie przestaliby, ale… No cóż, firmy często udają, że z nimi wszystko jest w porządku. Gdy tylko dzieje się coś złego, jest to dla nich szok i niespodzianka. „Słuchaj, testowaliśmy system i nie przechodzi on żadnych testów systemowych, a to kolejne trzy miesiące nieplanowanej pracy, jak to się mogło stać? Kto wiedział? Co mogłoby pójść źle? Poważnie, wierzysz w to?

Próbuję Ci wytłumaczyć, że nie powinieneś się zbytnio złościć z powodu obecnej sytuacji. Musimy o tym porozmawiać, naprawdę zrozumieć, co mogło pójść nie tak i jak zapobiec takim wydarzeniom w przyszłości. Jeśli pojawi się problem, jak z nim walczyć, jak go powstrzymać?

Dla mnie to wszystko wygląda przerażająco. Ludzie radzą sobie ze złożonymi, irytującymi problemami i nadal udają, że jeśli tylko trzymają kciuki i mają nadzieję na najlepsze, „najlepsze” faktycznie się wydarzy. Nie, to nie działa w ten sposób.

Ćwicz zarządzanie ryzykiem!

Michał: Ile Twoim zdaniem organizacji angażuje się w zarządzanie ryzykiem?

Tim: Wkurza mnie to, że ludzie po prostu zapisują ryzyko, patrzą na powstałą listę i idą do pracy. W rzeczywistości identyfikacja ryzyka dla nich jest zarządzaniem ryzykiem. Ale dla mnie to brzmi jak powód, aby zapytać: OK, jest lista, co dokładnie zmienisz? Musisz zmienić swoje standardowe sekwencje działań, biorąc pod uwagę te ryzyka. Jeśli jest jakaś najtrudniejsza część pracy, musisz się z nią uporać, a dopiero potem przejść do czegoś prostszego. W pierwszych sprintach zacznij rozwiązywać złożone problemy. To już wygląda na zarządzanie ryzykiem. Zwykle jednak ludzie nie są w stanie powiedzieć, co zmienili po sporządzeniu listy zagrożeń.

Michał: A jednak ile z tych firm jest zaangażowanych w zarządzanie ryzykiem, pięć procent?

Tim: Niestety, przykro mi to mówić, ale jest to bardzo nieistotna część. Ale więcej niż pięć, bo są naprawdę duże projekty i po prostu nie mogą istnieć, jeśli chociaż czegoś nie zrobią. Powiedzmy, że będę bardzo zaskoczony, jeśli będzie to co najmniej 25%. Małe projekty zazwyczaj odpowiadają na takie pytania w ten sposób: jeśli problem nas dotyczy, to go rozwiążemy. Następnie skutecznie wpadają w kłopoty i angażują się w zarządzanie problemami i zarządzanie kryzysowe. Kiedy próbujesz rozwiązać problem, ale problem nie zostaje rozwiązany, witamy w zarządzaniu kryzysowym.

Tak, często słyszę: „rozwiążemy problemy, gdy się pojawią”. Na pewno to zrobimy? Czy naprawdę zdecydujemy?

Oleg: Można to zrobić naiwnie i po prostu wpisać ważne niezmienniki do karty projektu, a jeśli niezmienniki się zepsują, po prostu zrestartować projekt. Okazuje się bardzo piembucky.

Michał: Tak, zdarzyło mi się, że gdy pojawiało się ryzyko, projekt był po prostu redefiniowany. Fajnie, bingo, problem rozwiązany, nie martw się już!

Tim: Naciśnijmy przycisk resetowania! Nie, to nie działa w ten sposób.

Keynote na DevOops 2019

Michał: Dochodzimy do ostatniego pytania tego wywiadu. Przychodzisz na następne DevOops z przemówieniem. Czy mógłbyś podnieść kurtynę tajemnicy na temat tego, co zamierzasz powiedzieć?

Tim: Obecnie sześciu z nich pisze książkę o kulturze pracy, niepisanych zasadach organizacji. Kulturę wyznaczają podstawowe wartości organizacji. Zwykle ludzie tego nie zauważają, ale po wielu latach pracy w konsultingu jesteśmy przyzwyczajeni, że to zauważamy. Wchodzisz do firmy i dosłownie po kilku minutach zaczynasz czuć, co się dzieje. Nazywamy to „smakiem”. Czasami ten zapach jest naprawdę dobry, a czasami jest, cóż, ups. W przypadku różnych organizacji sytuacja wygląda bardzo różnie.

Michał: Ja również zajmuję się doradztwem od lat i dobrze rozumiem, o czym mówisz.

Tim: Właściwie jedną z rzeczy, o których warto wspomnieć podczas przemówienia jest to, że nie o wszystkim decyduje firma. Ty i Twój zespół jako społeczność macie własną kulturę zespołową. Może to być cała firma lub wydzielony dział, odrębny zespół. Ale zanim powiedziałeś, oto, w co wierzymy, oto, co jest ważne… Nie możesz zmienić kultury, zanim nie zostaną zrozumiane wartości i przekonania stojące za konkretnymi działaniami. Zachowanie jest łatwe do zaobserwowania, ale poszukiwanie przekonań jest trudne. DevOps to świetny przykład tego, jak sprawy stają się coraz bardziej złożone. Interakcje stają się coraz bardziej złożone, wcale nie stają się czystsze i wyraźniejsze, dlatego warto zastanowić się, w co wierzysz, a o czym wszyscy wokół ciebie milczą.

Jeśli zależy Ci na szybkich efektach, mamy dla Ciebie dobry temat: czy widziałeś firmy, w których nikt nie mówi „nie wiem”? Są miejsca, w których dosłownie torturuje się człowieka, dopóki nie przyzna, że ​​czegoś nie wie. Każdy wszystko wie, każdy jest niesamowitą erudytą. Podchodzisz do dowolnej osoby, a ona musi natychmiast odpowiedzieć na pytanie. Zamiast mówić „nie wiem”. Brawo, zatrudnili bandę erudytów! W niektórych kulturach mówienie „nie wiem” jest na ogół bardzo niebezpieczne i może być postrzegane jako oznaka słabości. Są też organizacje, w których wręcz przeciwnie, każdy może powiedzieć „nie wiem”. Tam jest to całkowicie legalne i jeśli ktoś w odpowiedzi na pytanie zacznie śmiecić, zupełnie normalną odpowiedzią jest odpowiedź: „Nie wiesz, o czym mówisz, prawda?” i obróć to wszystko w żart.

Idealnie byłoby, gdybyś miał pracę, w której będziesz stale szczęśliwy. Nie będzie łatwo, nie każdy dzień jest słoneczny i przyjemny, czasem trzeba się napracować, ale kiedy zaczniesz podsumowywać, okaże się: wow, to naprawdę cudowne miejsce, dobrze się tu czuję, zarówno emocjonalnie, jak i intelektualnie. Są też firmy, do których idziesz jako konsultant i od razu zdajesz sobie sprawę, że nie wytrzymasz trzech miesięcy i uciekniesz ze strachu. Właśnie o tym chcę powiedzieć w raporcie.

Tim Lister przybędzie z przemówieniem „Charaktery, społeczność i kultura: ważne czynniki dobrobytu”na konferencję DevOops 2019, która odbędzie się w dniach 29-30 października 2019 w St. Petersburgu. Można kupić bilety na oficjalnej stronie internetowej. Czekamy na Ciebie w DevOops!

Źródło: www.habr.com