Jeremy Freeman
Jeremy Freeman rozpoczął pracę w branży oprogramowania dzięki studiom licencjackim z informatyki. Miał szczęście zaangażować się w niewielki program z zakresu przedsiębiorczości inżynieryjnej na Uniwersytecie Stanowym Karoliny Północnej. Podczas nauki w ramach tego programu poznał swojego obecnego współzałożyciela, Hersha Tapadię, a to spotkanie zmieniło bieg jego kariery.
Po jednej „prawdziwej” pracy i trzech startupach kieruje zespołem inżynieryjnym w firmie Allstacks i czerpie satysfakcję z wyzwań związanych nie tylko z projektowaniem świetnego produktu, lecz także z budowaniem świetnego zespołu i silnej firmy.
P: Czy masz mentora, który do tej pory inspirował Cię lub pomagał Ci w rozwoju kariery?
Jest ich tak wielu. Przynależność do społeczności startupowej w Raleigh w Karolinie Północnej była wspaniałym doświadczeniem i są dziesiątki osób, które pomogły mi w sposób, z którego mogą nawet nie zdawać sobie sprawy. Choć mógłbym wymienić konkretne nazwiska, to kilka ważnych historii ukształtowało moje spojrzenie na świat.
Jedna z tych historii pochodzi od lidera sprzedaży, który przemawiał na jednych z moich zajęć z przedsiębiorczości na studiach licencjackich. Jako student inżynierii skupiający się na pisaniu kodu i rozwijaniu umiejętności technicznych uważałem sprzedaż za coś obcego i nieinteresującego. Jednak ta osoba opowiedziała historię, która pomogła mi spojrzeć na sprawy inaczej.
Wspominał rozmowę z jednym ze swoich współpracowników technicznych. Współpracownik powiedział: „Nie rozumiem, jak możesz to robić”. Sprzedawca odpowiedział: „Co robić?”. Współpracownik odparł: „Realizować plan sprzedażowy. To musi być bardzo stresujące, kiedy jesteś zmuszony sprzedawać, żeby mieć za co żyć”. Przez chwilę się nad tym zastanawiał, po czym po prostu odpowiedział: „To prawda, ale jeśli ja nie sprzedaję, ty też nie masz za co jeść”.
Ta historia naprawdę pomogła mi spojrzeć na inżynierię we właściwym kontekście.
Możesz stworzyć najwspanialszy produkt lub usługę, ale jeśli nie potrafisz pokazać wartości osobom, którym to pomoże, po prostu zajmujesz się inżynierią w próżni.
Inną osobą, która mi pomogła, był mentor, który kierował firmami i działami inżynieryjnymi, a następnie zmienił ścieżkę kariery, aby pomagać ludziom rozwijać ich pomysły i znajdować stanowiska w różnych startupach. Pomagał mi przechodzić przez wiele wyzwań, ale jedną z najważniejszych rzeczy, jakie mi przekazał, było to, że większość liderów organizacji technicznych wyróżnia się w jednym z trzech obszarów:
„Główny geek”, menedżer będący gwiazdą zespołu albo kluczowa osoba ds. produktu. Kontynuował, mówiąc, że odnosząca sukcesy firma potrzebuje wszystkich trzech ról, a dobry lider musi rozpoznać, którą z nich sam reprezentuje, a następnie zatrudnić osoby posiadające pozostałe umiejętności. Pomogło mi to zrozumieć mój rozwój jako lidera zespołu inżynieryjnego oraz obszary, w które powinienem się bardziej lub mniej angażować.
P: Czy możesz wymienić trzy mocne strony lub umiejętności, które były ważne na Twojej drodze?
Jedno z haseł, którymi się kieruję, brzmi: „Najpierw się dopasuj, potem się wyróżnij”. Choć brzmi zgrabnie, przypomina mi, że kiedy zaczynam pracę z nowym zespołem, muszę najpierw poznać ten zespół. Zrozumienie, dlaczego rzeczy wyglądają tak, a nie inaczej, ma kluczowe znaczenie dla budowania zaufania.
Na przykład jeśli pierwszego dnia pojawię się w pracy i spróbuję wdrożyć lub promować dużą zmianę, domyślną reakcją będzie opór, a ja utrudnię sobie pracę na przyszłość. Zanim spróbujemy zakwestionować status quo lub wprowadzić duże zmiany, ważne jest, aby w nowym zespole szukać podobieństw i obszarów porozumienia. To podejście sprawdza się również przy budowaniu nowych relacji w każdej dziedzinie życia.
Inna maksyma, która pomaga mi się kierować, brzmi: „To, co ludzie mówią i robią, jest jedynie skorelowane z tym, co myślą i czują”. Choć może to brzmieć pesymistycznie, podoba mi się myśl, że ludzie często działają pod ogromną presją, aby zachowywać się lub mówić w określony sposób.
Na przykład kiedy pytasz kogoś, jak mija mu dzień, niemal zawsze odpowiada: „Dobrze”, zamiast otworzyć się i naprawdę porozmawiać o tym, jak się czuje. Podczas pracy z zespołami i grupami ważne jest, aby zwracać uwagę na te presje, żeby naprawdę zrozumieć innych i wczuć się w ich sytuację. Przykładowo, jeśli ktoś podlega Tobie służbowo, może mieć trudności z przyjęciem odpowiedzialności za błąd, jeśli obawia się konsekwencji.
Jako lider musimy tworzyć i stale oceniać nasze środowisko, aby sprzyjać otwartości. W przeciwnym razie możemy nieumyślnie stworzyć kulturę, w której problemy narastają w zespole i nie są rozwiązywane.
Jeśli chodzi o zarządzanie zespołami, ludzie muszą stale dokonywać autorefleksji i analizować minione działania, aby rozwijać silne umiejętności. Choć „spoglądanie w głąb siebie” sprawdza się w moim przypadku, nie musi działać równie dobrze u każdego, a dobry lider powinien rozpoznawać różne sposoby, w jakie poszczególne osoby uczą się i rozwijają.
Skuteczny lider koncentruje się na równoważeniu osiągnięć i empatii, nieustannie analizując własne mocne i słabe strony, a także mocne i słabe strony całego zespołu.
Have an account? Log In
P: Nad rozwijaniem jakich umiejętności nadal obecnie pracujesz?
Wracając do rady jednego z moich mentorów, nieustannie pracuję nad obszarem zarządzania, który jest jednym z trzech filarów roli lidera technicznego. Miałem szczęście pracować z osobą z zespołu, która jest w tym świetna i pokazała mi kilka kluczowych sposobów na rozwój i doskonalenie.
Jako współzałożyciel startupu technologicznego koncentrowałem się przede wszystkim na technologii i produktach oraz pracowałem z małymi zespołami. Teraz, gdy nasza organizacja się rozwija, muszę rozwijać się razem z nią. Sztuka zarządzania jest umiejętnością równie ważną jak tworzenie oprogramowania.
P: Porozmawiajmy o skutecznym zespole DevOps. Jakie kluczowe cele może wyznaczyć sobie zespół DevOps w ramach transformacji cyfrowej?
Jedną z najważniejszych rzeczy, o których słyszę od innych liderów, jest wspólne rozumienie tego, co DevOps oznacza dla danej organizacji. Spotkałem się z organizacjami, w których „DevOps” oznacza zatrudnienie inżyniera SRE, nazwanie go inżynierem DevOps i uznanie sprawy za zakończoną.
Dobrym punktem wyjścia jest przeanalizowanie kluczowych elementów cyklu DevOps i określenie, jak praca oraz pomysły przepływają przez proces wytwarzania oprogramowania. Wybierz pojedyncze zadanie programistyczne, prześledź je od momentu powstania aż do chwili, gdy prowadzi do utworzenia kolejnego zadania, a być może zidentyfikujesz istotne luki.
Możesz na przykład odkryć, że Twój zespół kontroli jakości jest odizolowany i że panuje u Was mentalność „przerzucania problemu przez mur”, która ogranicza zdolność do szybkiego działania. Gdy zaczniesz definiować przepływ tego procesu w swojej organizacji, możesz przyjrzeć się narzędziom, które mogą w tym pomóc.
Wiele organizacji zaczyna od narzędzi, a następnie powoli i boleśnie przeprowadza na ich podstawie zmianę organizacyjną. To niewłaściwy sposób na rozpoczęcie działań.
P: Czy istnieją jakieś wyzwania lub typowe pułapki, które zespoły DevOps powinny wziąć pod uwagę?
DevOps to sposób pracy. Pod wieloma względami jest to kontynuacja transformacji zwinnej, która przed kilkudziesięciu laty ogarnęła branżę tworzenia oprogramowania. Warto o tym pamiętać. Wiele organizacji miało trudności z transformacją zwinną z powodu braku zrozumienia i poparcia ze strony kadry kierowniczej. Liderzy sądzili, że zaczniemy organizować codzienne spotkania i zrealizujemy o 50 procent więcej zadań. Z perspektywy czasu było oczywiste, że to błędne założenie.
Podobnie dzisiejsi liderzy sądzą, że potrzebujemy jedynie potoku CI/CD, aby osiągać lepsze wyniki według metryk DORA, i że zobaczymy 50-procentowy wzrost produktywności. Zmiana sposobu myślenia ma kluczowe znaczenie. DevOps umożliwia przejęcie pełnej odpowiedzialności za cykl dostarczania oprogramowania, co pozwala zespołom tworzyć lepsze systemy. DevOps daje zespołom możliwość rozpoznawania sposobów doskonalenia pracy i wdrażania ich, dlatego liderzy muszą stworzyć przestrzeń i zapewnić wsparcie, aby rzeczywiście dostrzec wpływ na organizację.
P: W jaki sposób skuteczna współpraca i komunikacja między członkami zespołu mogą zwiększyć produktywność i skuteczność zespołu DevOps oraz jakie praktyki mogą to ułatwić?
Komunikacja ma kluczowe znaczenie w inżynierii. Niemal każdy problem sprowadza się do słabej komunikacji i DevOps nie jest tu wyjątkiem. Wracając do wspólnego rozumienia tego, co DevOps oznacza dla danej organizacji, trzeba naprawdę rozumieć, dokąd zmierzacie, i mieć wspólną wizję, aby mieć szansę na sukces.
Jedną z kluczowych praktyk, które obserwowałem, jest definiowanie prostych bramek etapów w procesie. Muszą one dotyczyć pracy, a nie osób, które ją wykonują. Zdefiniowanie procesów określających przepływ zadań i informacji przez zespół pozwala sprawnie przełączać się między zadaniami, szczególnie gdy pojawiają się przerwania pracy, a także niezależnie skalować różne części zespołu.
Każdy zespół i produkt ma nieco inne potrzeby, a zdefiniowanie tych bramek oraz określenie, co musi wydarzyć się na każdym etapie, pomoże Ci ustalić, gdzie występują nieefektywności.
Pytanie: Jaką rolę odgrywa CI/CD w DevOps i jakie są najlepsze praktyki wdrażania potoków CI/CD, aby zapewnić płynny i niezawodny proces wydawania oprogramowania?
Kluczowe jest jak najszybsze przeniesienie zmian w oprogramowaniu od pomysłu do środowiska produkcyjnego. Procesy manualne są niezwykle powolne i zależne od ludzi. Ludzie, choć świetnie radzą sobie z takimi zadaniami jak rozwiązywanie problemów i kreatywność, często nie są dobrzy w wyczerpującym przechodzeniu przez listy kontrolne setki razy dziennie. Automatyzacja żmudnych zadań naprawdę pozwala zespołowi skupić się na obszarach, w których jest najlepszy. Ponadto komputery są wyjątkowo szybkie i można je łatwo skalować. Utworzenie potoku wykorzystującego te możliwości jest główną zaletą przyjęcia procesu CI/CD.
Jedną z najważniejszych rzeczy, o których należy pamiętać podczas budowania takiego procesu, jest zachowanie równowagi między szybkością a bezpieczeństwem. Chociaż można w pełni zautomatyzować każde zatwierdzenie programisty, przekazywane bezpośrednio do środowiska produkcyjnego, nie zapewnia to żadnego bezpieczeństwa. Zbudowanie potoku umożliwiającego taki poziom szybkości i stopniowe dodawanie kontroli może pomóc w przyszłości. Być może początkowo wszystko musi zostać jawnie zatwierdzone przez inżyniera QA i inżyniera wydań, ale sam proces może sprowadzać się tylko do naciśnięcia przycisku.
Gdy zautomatyzowane testy będą już skonfigurowane, być może uda się wyeliminować zatwierdzenie QA.
Pytanie: W jaki sposób rozwijanie kultury i sposobu myślenia DevOps przyczynia się do ogólnego sukcesu zespołu DevOps oraz jakie strategie mogą stosować organizacje, aby promować tę kulturę wśród zespołów programistycznych i operacyjnych?
Główną trudnością w tej transformacji jest walka z mentalnością „przerzuć to przez mur“. Jeśli dopiero rozpoczynasz tę podróż, być może masz pięć lub sześć zespołów, które muszą zająć się każdym elementem pracy, zanim trafi on do środowiska produkcyjnego. W miarę przechodzenia na DevOps rozwijasz współodpowiedzialność za cały cykl życia tego produktu.
Może to wymagać znaczących zmian w sposobie projektowania, budowania i wdrażania rozwiązania. Chociaż wiele osób zna proces tworzenia oprogramowania, które można łatwiej testować, przyjęcie kultury DevOps wymaga budowania systemów i platform, za które małe zespoły będą odpowiedzialne od początku do końca.
Pytanie: Jakie jest „5 kluczowych elementów skutecznego zespołu DevOps”? Proszę podać historię lub przykład dla każdego z nich.
1. Wspólne rozumienie tego, co DevOps oznacza dla organizacji. – Jedną z najbardziej szkodliwych inicjatyw DevOps jest sytuacja, w której kierownictwo i zespół mają różne wizje rezultatów. DevOps to znacznie więcej niż samo zatrudnienie inżynierów „DevOps” i zakup narzędzia CI/CD. Gdy wszyscy zgadzają się, że chodzi o zmianę sposobu myślenia, zespoły zyskują możliwość przejęcia pełnej odpowiedzialności za dostarczanie wartości klientom
2. Przestrzeń i wsparcie umożliwiające identyfikowanie i wdrażanie zmian – Zespoły DevOps często identyfikują wiele sposobów na usprawnienie dostarczania i zwiększenie efektywności zespołu. Brak przestrzeni na taką eksplorację znacząco ogranicza wpływ, jaki zespół może mieć na wprowadzanie zmian.
3. Sposoby mierzenia i identyfikowania sukcesu za pomocą danych – Wszyscy znają wskaźniki DORA oraz cztery kluczowe miary służące do oceny dojrzałości DevOps organizacji programistycznej. Chociaż są one dobrym początkiem, musisz określić, co organizacja DevOps oznacza dla Twojej firmy — i należy zrobić to na podstawie danych.
4. Produkt zbudowany tak, aby wspierać odpowiedzialność i rozwój tej filozofii – DevOps to świetna filozofia dla wielu organizacji, ale firmy często nie są gotowe na przyjęcie tej transformacji. Musisz mieć pewność, że Twój produkt może być wspierany przez połączony zespół operacyjny i programistyczny. Produkty lokalne, produkty o sztywnych cyklach wydań oraz produkty, które nie osiągnęły jeszcze poziomu dojrzałości pozwalającego na wsparcie takiego zespołu, mogą nie być dobrym wyborem. Gdy zespół przyjmuje bardziej operacyjny sposób myślenia, można zauważyć pewne korzyści, ale ich wpływ jest ograniczony.
5. Automatyzacja i narzędzia - Zapewnij spójność i szybkość realizacji zadań oraz egzekwowanie uzgodnień roboczych. Jedną z podstawowych zmian w organizacji DevOps są uzgodnienia robocze ustanawiane z zespołem i między zespołami. Jeśli ustanawiasz proces testowania wymagający przetestowania regresyjnego całego kodu przed wdrożeniem, powinieneś go zautomatyzować. Należy ustanowić zautomatyzowane kontrole i bramki, aby to zapewnić. Po wdrożeniu tych narzędzi i praktyk często okazuje się, że ambitne cele, takie jak ciągłe wdrażanie, dzieli już tylko kilka dodatkowych kroków.
Upewnij się, że testowanie nie tylko się wykonuje, ale także spełnia Twoje standardy jakości.
More Articles
P: Jakie pojawiające się trendy dostrzegasz, które w przyszłości mogłyby znacząco wpłynąć na strategie transformacji cyfrowej?
Wiele wielkich obietnic związanych z takimi działaniami jak przejście na DevOps opiera się na danych wysokiego poziomu i ogólnych rezultatach. Często te nagłówkowe liczby, takie jak „Twoja organizacja jest o 50 procent bardziej efektywna”, są niemal niemożliwe do zmierzenia, a potwierdzenie osiągnięcia takich rezultatów może być trudne.
Spodziewam się, że przed rozpoczęciem wieloletniej transformacji cyfrowej organizacje będą podejmować bardziej ukierunkowane działania w celu określenia konkretnych rezultatów. Nie tylko odpowiada to na zwiększone zainteresowanie efektywnością biznesową w ostatnich kilku latach, ale także zapewnia sukces. Zamiast ogólnych celów, takich jak te wspomniane wcześniej, bardziej skoncentrowane są konkretne (ale mające istotny wpływ) cele, takie jak „Rozwiązujemy problemy klientów o 25 procent szybciej”.
Wspieranie rozwoju poprzez mentoring
Siła mentoringu i otwartej komunikacji jest widoczna na przykładzie kariery Jeremy’ego Freemana. Aktywnie ucząc się od innych i tworząc środowisko oparte na współpracy, liderzy mogą pomóc zespołom DevOps osiągać wspaniałe rezultaty.
Zapisz się do newslettera The CTO Club, aby otrzymywać więcej wywiadów, informacji na temat DevOps i wskazówek dotyczących mentoringu!
