Teraz, gdy każda firma jest firmą programistyczną, ostatnie dyskusje z ludźmi wokół mnie (w tym z osobami spoza branży oprogramowania) sprawiły, że ponownie odkryłem fatalny stan dostarczania oprogramowania w wielu miejscach.

W tym artykule podzielę się niektórymi moimi przemyśleniami na ten temat, a także pozwolę sobie przedstawić kilka nierozstrzygających porad na wysokim poziomie, które moim zdaniem mogą stworzyć solidną podstawę, wokół której takie problematyczne organizacje mogłyby zostać przekształcone w rzeczywiste organizacje zajmujące się oprogramowaniem.

Zwróć uwagę, że kiedy piszę o organizacjach i biznesach, nie będą to zatem firmy zajmujące się wyłącznie technologią, takie jak Meta, Google, Spotify itp. — raczej długi ogon organizacji (tj. dostosować się do oprogramowania będącego częścią ich produkcji i produktu.

Skąd to piszę

Najpierw trochę kontekstu. Mam doświadczenie i wiedzę z kilku „światów”, zarówno jako kierownik ds. standardów technicznych w Polestar , twórca open source , ogólnie zapalony czytelnik technologii, jak i założyciel maleńkiego, zupełnie nowego startupu technologicznego . Wreszcie, wraz z moim starym kolegą, aktywnie planuję założyć lokalną , bezpłatną ułamkową usługę CTO dla młodych organizacji kierujących się wartością.

Zacząłem kodować HTML i CSS w 1997 roku, od tego czasu zwiedziłem całkiem sporo obszarów, a mimo wielu wycieczek i objazdów w życiu, moja ścisła kariera zawodowa rozpoczęła się w 2016 roku. Już pierwsza pozycja była złożona i chaotyczna, a ja Uwielbiałem mieć stanowiska, na których muszę równoważyć twarde i miękkie strony, w górę iw dół od poziomu C do innych programistów. Prowadziłem dwie małe firmy zajmujące się projektowaniem i technologią, może niezbyt pomyślnie, ale mam doświadczenie we wszystkim, co się z tym wiąże. Moje doświadczenie z klientami rozciąga się od bardzo małych do największych firm w Szwecji, od towarów konsumpcyjnych codziennego użytku do najbardziej niszowych usług. Miałem szczęście i byłem bardzo szczęśliwy, mogąc pomóc we wprowadzaniu innowacji i platformach, w jaki sposób dostarczanie oprogramowania może lub przynajmniej powinno działać w wielu organizacjach, z różnymi potrzebami i głębokościami umiejętności w zakresie technologii w wielu domenach. Podsumowując, to dużo zdań zaczynających się od „ja…”.

OK, więc po co piszę powyższe? Szczególnie dlatego, że chcę być w pełni przejrzysty w tym, że to, co zaatakuję, wynika z doświadczenia bólu i często „nienaturalności” oprogramowania w wielu organizacjach — po prostu nie wydaje się żelować w większości miejsc! Istnieje tona metryczna czytania – wystarczająco dobrze, aby zająć całe życie i dłużej – jeśli chcesz zagłębić się w pomysły, koncepcje i filozofie oprogramowania, nawet zanim przejdziesz do strony biznesowej, jak obsługiwać startupy, jak tworzyć MVP , jak podejść do jakości oprogramowania i tak dalej. Szczerze mówiąc — nikt z nas nie ma czasu, aby to wszystko ogarnąć, a zarządzanie czasem nie byłoby zbyt dobrym zarządzaniem, gdybyśmy do pewnego stopnia nie ograniczyli źródeł inspiracji i nowych pomysłów.

Tak więc, pomijając to opowiadanie historii, napiszę w szczególności o trzech rzeczach:

• Że mamy problem z oprogramowaniem w organizacjach nieprogramowych.
• Dlaczego sami programiści nie mogą przekształcić Twojej organizacji w firmę programistyczną.
• Jak mogą wyglądać rzeczywiste, rzeczywiste zmiany, aby odbudować fundament wokół.

Inżynieria oprogramowania z perspektywy orbitalnej

Jesteśmy kosmicznym statkiem kosmicznym unoszącym się nad Ziemią, spoglądającym z góry na wszystkie niedoszłe (tj. IT) organizacje.

Niektóre fakty zebrane przez nasze instrumenty wraz z refleksjami naszego głównego naukowca-ludzi-obcych:

• Tech (zwłaszcza Big Tech) jest w dużej mierze nadmiernie zatrudniany . Wydaje się, że celem jest, nieco cynicznie, nie skierowanie ludzi do pracy, ale odsunięcie ich od produkcji produkcyjnej kogoś innego.
• Jest to naturalną konsekwencją tego, że wykonywanie wielu prac jednocześnie jest więcej niż możliwe . Ironiczne, ale prawdziwe, biorąc pod uwagę, że masz teraz dwie wypłaty za nic nie robienie.
• W skali firmy, jak pisze Victor Ronin, „ można zwolnić 80% programistów, a firma przetrwa ”. Nie jest to takie dziwne, biorąc pod uwagę, że nikt nie pracuje, lub że typowa organizacja IT ma tendencję do bycia grzęzawiskiem, nawet gdyby próbowała.
• Osobiste doświadczenie zawodowe wyraźnie mówi, że „inflacja tytułów” jest dotkliwa (przynajmniej w Szwecji, ale wydaje się, że jest to zjawisko globalne ) — nie mogę tego udowodnić, ale jeśli brałeś udział (lub pomagałeś) w rekrutacji lub zatrudnianiu najprawdopodobniej to widziałeś. W efekcie ludzie chcą więcej pieniędzy za czasami mniej wykwalifikowaną siłę roboczą .
• W skali kraju, w Szwecji, od pewnego czasu spada liczba wykwalifikowanych kandydatów na programy zorientowane na IT/CS. Wydaje się jednak, że niektóre programy kształcenia zawodowego nieteoretycznego zbierają niektórych kandydatów. Ergo, rynek nie wydaje się rosnąć w czasie — kurczy się , przynajmniej jeśli chodzi o najbardziej wykwalifikowanych juniorów.
• Możemy uogólnić i powiedzieć, że „kiedyś było łatwiej”, ponieważ IT było centrum kosztów i zasadniczo w wielu firmach zostało zdegradowane do sprzedaży licencji na oprogramowanie komercyjne (zbudowane przez kogoś innego) oraz zapewniania działania drukarki i poczty e-mail. Teraz trochę, niestety, każda firma jest firmą programistyczną . W rzeczywistości nie wyszło to zbyt dobrze, ponieważ wymaga restrukturyzacji i ponownego przemyślenia – najprawdopodobniej najtrudniejszego orzecha do zgryzienia dla zwykłych ludzi.
• IT jest przygnębiająco przeładowane i niedostatecznie wykwalifikowane. Najprawdopodobniej istnieje długa historia (lub wiele z nich) leżąca u podstaw tego stwierdzenia, ale jest całkiem jasne, że IT przyciąga wiele niewykwalifikowanych talentów i pomysłów, często (ale nie tylko) w obszarach (nie)zarządzania. Wydaje się, że role menedżerów eksplodują z winorośli wielkiego drzewa hierarchii, podczas gdy jest mniej (dobrych) wyników, którymi można faktycznie zarządzać. Potrzebujemy czegoś, co stawia produkt (i oczywiście ludzi!) na pierwszym miejscu, a nie zarządzanie lub przechowywane na półkach pomysły „skalowania” zarządzania produktem, które po prostu nie działają .
• Myślenie produktowe, myślenie lateralne i osoby w kształcie litery T są trudne do zdobycia. Powinniśmy zadbać o mechanizmy, które sprawiają, że nasi ludzie mają silniejsze takie umiejętności, zarówno w codziennym zanurzeniu, jak i podczas regularnych i oczekiwanych szkoleń . Ale przede wszystkim nie powinniśmy przyjmować tych, którym brakuje tego wszystkiego.
• Proces nie jest wrogiem, wbrew temu, w co chcieliby wierzyć fanatycy Agile. Proces jest świetny, jeśli w znaczący sposób utrzymuje efektywność i zadowolenie pracowników, jednocześnie utrzymując wydajność na konkurencyjnym poziomie, zarówno pod względem funkcjonalnym, jak i interdyscyplinarnym. Problem polega na tym, że tradycyjne organizacje nie dostosowują procesów do znacznie wyższej częstotliwości dostarczania oprogramowania.
• Co wydaje się zajmować czas inżynierów oprogramowania w wielu miejscach? Wydaje się, że dotyczy to stosunkowo niewielkich problemów związanych z integracją, automatyzacją procesów i utrzymaniem systemu. Prawie jak cyfrowy hydraulik … ciekawe…

— Użytkownik „denton-scratch”https://news.ycombinator.com/item?id=33961785

• Jakie to szczęście dla tych biednych menedżerów, że istnieje jakaś odpowiedź na ten scenariusz cyfrowego hydraulika: brak kodu/niski kod to podejście przewidujące, ponieważ uznaje, że nie ma wystarczającej liczby kompetentnych inżynierów oprogramowania, ani w trakcie szkolenia lub na rynku. Istnieje kilka niesamowitych produktów, takich jak Zapier , Autocode , AppSheet , AirTable , Webflow , Retool i Carrd . Do diabła, poziomy.fyi przeskalowano do milionów użytkowników, używając tylko Arkuszy Google jako zaplecza …
• …ale nie jest jeszcze dojrzały dla wszystkich obszarów biznesowych i nadal wymaga nieco inżynierskiego sposobu myślenia, aby dobrze działać . Wydaje się więc, że nadal potrzebujemy tych inżynierów/programistów do korzystania z narzędzia „bez kodu”, podczas gdy kierownictwo i reszta są przerażeni faktem, że nadal ma to związek z oprogramowaniem.

Tempo innowacji w sektorze oprogramowania i rozwoju jest teraz oszałamiające. Piszę to oświadczenie jako część przeprosin, a część listu miłosnego, aby odpowiedzieć na pytanie, jak łatwa i „zdemokratyzowana” technologia może być dla firm i organizacji, bez względu na ich dojrzałość techniczną lub kompetencje. Przepraszam, ponieważ w mojej rzeczywistości bardzo trudno jest skłonić duże firmy do czerpania korzyści z naszych czasów i listu miłosnego , ponieważ wiem i cenię sobie wpływ, jaki mogą mieć programiści i ludzie biznesu, jeśli weźmie się pod uwagę kontekst „właściwej” organizacji.

W przypadku nowego start-upu nigdy nie było to tak prawdziwe, jak jest dzisiaj, biorąc pod uwagę mnóstwo dobrze działających, dobrze działających narzędzi UX, które mogą tworzyć doświadczenia i aplikacje, które jeszcze nie tak dawno temu były tylko domeną mistrzów tajemnego.

Wydaje się, że w wielu organizacjach nie zapadło to jeszcze na tyle głęboko, że muszą zdefiniować (i odpowiednio rozwarstwić), czy są organizacją z ulepszeniami IT , czy też firmą programistyczną z nastawieniem na szybkie tworzenie produktów oprogramowanie front-and-centrum operacji. Kult cargo wokół oprogramowaniaa to, że wszyscy uważają, że bycie jednym z nich jest bardzo ważne, oznacza, że ​​zaprosiliśmy wilki i szarlatanów do organizacji z wielkimi wizjami. Wielkie wizje z niedoświadczonymi i nerwowymi liderami, w organizacjach, które nie zawsze mogą wypełnić wyniosłe zamki na niebie, biorąc pod uwagę nieodłączne lub zakorzenione ograniczenia i ograniczenia, które mogą zasadniczo uniemożliwić restrukturyzację wokół oprogramowania, a nie, powiedzmy, samochodów, statków, łożysk kulkowych , produkty medyczne lub co masz…

Nasz głód dostosowania się do czasów wyraźnie w wielu przypadkach doprowadził do podejmowania złych decyzji i źle funkcjonujących warunków, które nie pozwalają na dostarczanie wysokiej jakości, stabilnego i bezpiecznego oprogramowania… Dobrze jest być firmą nieprogramową ! Bycie pozerem jest znacznie gorsze.

Przypomnienie : Przetrwanie nie jest obowiązkowe . Ktoś zawsze będzie musiał odgrywać rolę dodo .

Kluczowym elementem oddzielającym tradycyjne organizacje od organizacji zajmujących się oprogramowaniem jest to, że oprogramowanie jest produktem . Tak. Stwierdzając to, zakłada się, że doszliśmy również do pewnych ustaleń:

• Oprogramowanie jako niezwykle plastyczne (zmienne, adaptowalne);
• Tempo zmian w oprogramowaniu jest znacznie wyższe niż w świecie materialnym;
• Konkurencja w oprogramowaniu jest z założenia globalna iz natury ultra-antagonistyczna;
• Oprogramowanie jest stale ulepszane, nie jest to artefakt dostarczalny z wybitą datą.

Problem polega na tym, że – nieuchronnie – gdzieś, kiedyś, twoje szczęście się skończy, jeśli nie możesz poprawić tej sytuacji. Twoja główna konkurencja nie pochodzi od dobrze znanych, zmapowanych starszych konkurentów — pochodzi od jakiegoś faceta lub dziewczyny, którzy piszą twój nekrolog w kodzie w swoim podnajmie w zupełnie innym kraju. I nie zobaczysz tego, zanim będzie za późno.

Organizacja skoncentrowana na oprogramowaniu uwzględnia takie fakty, dostosowuje się do nich i optymalizuje je pod kątem takich faktów — będąc wielofunkcyjną, mając krótkie pętle w cyklu rozwoju produktu, rozumiejąc resztę krajobrazu cyfrowego (od przepisów prawnych po wzorce użytkowników itp. ) i mając użytkownika jako interesariusza, a nie bezmyślną, abstrakcyjną torbę pieniędzy ukrytą poza zasięgiem wzroku. Firma programistyczna nie jest chroniona przed rzeczywistością, rynkiem ani niczym innym — ale dostosowuje się, mając blisko swoich klientów, co jest formą nieco niegodnej zaufania firmy Oracle of Delphi.

Deweloperzy nie uratują złej organizacji

Byłem znany z tego, że jestem kontrowersyjny, więc pójdę dalej i od razu pozwolę tej szatańskiej myśli urzeczywistnić, abyśmy mogli to razem rozpakować… Prawdopodobnie nie powinieneś zatrudniać żadnych (więcej) programistów, ponieważ :

1. Nie można zlecić biznesu i „znania planu” inżynierom . Nie dlatego, że są głupi, ale dlatego, że to kolejny instrument w wielkiej orkiestrze. Biorąc pod uwagę, że Twoja firma nie jest głęboko zakorzeniona w rozwoju, to nie tam znajdziesz tych, którzy napędzają biznes. Zacznij od ustalenia planu i wizji dla swojej organizacji i (ewentualnego) produktu. Zaproś jednak deweloperów!
2. Tajemnica i magia wokół programistów po prostu musi umrzeć . Deweloperzy nie są superbohaterami ani mitycznymi 10x . Ostateczną wartością tworzenia czegokolwiek — w kontekście biznesowym — jest wspieranie wartości postrzeganej przez klienta. Deweloperzy nie są idealnymi ludźmi, aby w pełni zrozumieć, czym jest ta wartość. Rozwój jest często napędzany reaktywnie i post factum , co bezpośrednio przekłada się na to, że kod jest jedynie miarą produkcji, a nie miarą wartości . Jeśli to właśnie robisz, to nie, więcej programistów nie jest właściwym sposobem prowadzenia biznesu.
3. Prawdopodobnie opierasz się na przekonaniu, że przekształcenie tego oprogramowania w coś namacalnego (w tym wszystkie procesy inne niż cyfrowe itp.) będzie dobrze działać w Twojej starszej hierarchii . Doświadczenie mówi, że rzadko tak jest, a LinkedIn jest pełen szakali, którzy nie mówią prawdy. Lub kiedy czytasz, że zwycięstwo było „z trudem wywalczone” (tj. pyrrusowe zwycięstwo ), zadaj sobie pytanie, czy chcesz dowiedzieć się, co to naprawdę oznaczało w rzeczywistości. Wiele razy prawdopodobnie przekłada się to na projekt całkowicie rozbity na kawałki przez marketing, projektowanie, rozwój, biznes i kierownictwo, którzy mieli całkowicie sprzeczne pomysły na to, jak postępować, a nawet o co w tym wszystkim chodziło. Ponadto duża organizacja nie spieszy się, aby przejść od pomysłu do realizacji, więc zdarza się to tylko raz na błękitny księżyc. A reszta świata być może już ruszyła naprzód, gdy światło dzienne zaświeci na ten projekt w kształcie ciężaru. O ile oprogramowanie nie jest zaprojektowane i zbudowane jako pionowy wycinek obejmujący wszystkich wymaganych ludzi i procesy, to jest prawie skazane na niepowodzenie lub słabe działanie, biorąc pod uwagę koszty i wysiłek.

Wiem, że to może zaboleć, ale tak naprawdę staram się być twoim przyjacielem.

Duża organizacja? Pewnie duże problemy. Jeśli problemem są ludzie, jakie jest rozwiązanie? Logicznie rzecz biorąc, odpowiedź brzmi: jest ich mniej i są lepiej wykwalifikowani . W związku z tym liczba pracowników to naprawdę kiepski sposób, a skala prawdopodobnie nie jest tak ważna, jak myślisz. Zamiast tego dąż do mniejszej liczby wysoko wykwalifikowanych i zmotywowanych programistów zaangażowanych w organizację, która ceni przejrzystość i interakcje międzyfunkcyjne.

Gwałtowny wzrost tego, co jeden kompetentny programista może zrobić ze współczesną ofertą technologiczną

Ulepszenia technologii oznaczają, że kompetentne osoby mogą znacznie więcej produkować niż programiści, którym brakuje najnowocześniejszych umiejętności . Od pojedynczych usług po chmurę publiczną, istnieją niezliczone opowieści o firmach działających na podstawie pracy zaledwie 1–5 programistów, w dużej mierze dzięki paradygmatowi bezserwerowemu i jego przodkom.

W przypadku firm bardziej zaawansowanych technologicznie widzę (i widziałem), jak jeden lub niewielka liczba programistów może tworzyć rzeczy, których nie można było zrobić bez zatrudniania najlepszych, jakie rynek miał do zaoferowania, i płacenia swoimi organami. Niemała część tego bierze się z wyścigu zbrojeń między wielkimi chmurami, ale także dlatego, że inne firmy technologiczne, często specjalizujące się we własnej dziedzinie, dolewają benzyny do ognia. Jako „konsumenci” usług jesteśmy zdecydowanymi zwycięzcami. Niewykorzystanie impetu bardzo szybko pozostawi Twoją organizację daleko w tyle.

Kiedy po prostu w ogóle nie zatrudniać programistów?

Jeśli prowadzisz małą firmę lub pracujesz w kontekście, na który technologia cyfrowa nie ma dużego wpływu. Myślę o restauracjach i tym podobnych. Jeśli marże są zbyt niskie i masz wystarczająco przyzwoite wyobrażenie o swoich wymaganiach biznesowych, to może być lepiej obsługiwane przez coś takiego jak Carrd, Webflow, Retool lub coś innego zorientowanego na niski kod / brak kodu i nikt nie może cię za to winić to, biorąc pod uwagę, że masz trochę talentu do myślenia w kategoriach programistycznych. Nie byłbyś pierwszym ani jedynym, który z powodzeniem prowadzi biznes dzięki tym dostępnym na rynku i przyjaznym dla użytkownika narzędziom.

Lepsze dostarczanie oprogramowania teraz

Widzieliśmy, że prawdziwy problem w organizacjach IT dotyczy w mniejszym stopniu technologii, a bardziej ludzi i procesów. Dlatego chociaż niektóre z poniższych będą dotyczyć technologii , całkiem sporo nie.

Nie chcę być surowy, ale to także wystarczający powód, aby zadać sobie pytanie: „Jeśli nie mogę wpłynąć na te aspekty lub je zmienić, jakie są realistyczne szanse, że moja firma będzie dobra w dostarczaniu oprogramowania?”. Postawiłbym nisko. Przepraszam, nie przepraszam.

Weźmy się za to.

Dbaj o klienta/użytkownika

To bez wątpienia numer 1 na Twojej liście.

Nigdy nie pracowałem w firmie (nie, nigdy; ani dzisiaj, ani wcześniej), w której firmie naprawdę zależało na kliencie lub użytkowniku. Nie bądź taki.

Bez perspektywy klienta ostatecznie masz wszystko w dupie. Taka jest prawda.

Brak bezpośredniego kontaktu organizacji produktu z użytkownikami (w stosownych przypadkach) to regres wykraczający poza głupotę. Upewnij się, że ma takie możliwości!

Etyka

Przeczytaj poniższe, niezależnie od swojego stanowiska:

• Forsgren, Humble i Kim's Accelerate: Nauka o Lean Software i DevOps: Budowanie i skalowanie wysokowydajnych organizacji technologicznych
• Czyste rzemiosło Roberta C. Martina : dyscypliny, standardy i etyka
• Nowoczesna inżynieria oprogramowania Dave'a Farleya : robienie tego, co działa, aby szybciej tworzyć lepsze oprogramowanie

Wiele słyszymy o upodmiotowieniu, takim jak nadanie zespołom pionowej odpowiedzialności w roli DevOps, ale z wolnością wiąże się odpowiedzialność — także od reszty organizacji w kierunku zespołów inżynierskich. DevOps nie będzie działać w fabryce funkcji . Pokrewną notatkę znajdziesz w artykule Product vs. Feature Teams .

Twoim celem numer 2 powinno być zwiększenie efektywności organizacji poprzez krótsze pętle od pomysłu do wdrożenia. Utrudniają to duże grupy lub struktury, sztywne procedury nie dodające wartości i brak zaufania mniejszych grup do samodzielnego wykonywania pracy. Im krótsza i bardziej intensywna jest ta pętla, tym lepiej.

Miej jasną i zakomunikowaną wizję swojego produktu, usługi lub czegokolwiek, czym zajmuje się Twoja organizacja . Wyjaśnij, co każdy może zrobić, aby się tam dostać. „Wyższa sprzedaż” nie liczy się jako wizja ani wskazówka osoby dorosłej, ale z pewnością jest dobra w kontekście kreskówki Sknerus McKwacz.

Przejrzystość celów oraz prawdziwa własność i podejmowanie decyzji: bez wizji, kierunku i własności możesz mieć tyle DevOps, na jakie tylko masz ochotę, ale będzie to dosłownie na nic . Posiadanie znaczącego, konkretnego udziału i odpowiedzialności za produkt zwiększa satysfakcję z pracy, poczucie celu i wiele innych czynników . W świecie programistów byłoby to coś w rodzaju dobrze naoliwionego DevOps, który również działa lepiej w mniejszych zespołach z węższymi, jaśniejszymi zakresami.

Nie buduj, nie wspieraj, nie inwestuj ani nie finansuj warstwy zarządzania . Każdy musi mieć udział w produkcie. Kierownictwo zazwyczaj nie ogranicza tego wymogu.

Mieć jasną koncepcję tego, jak działa rozliczalność i odpowiedzialność . Podczas gdy w wielu krajach surowe traktowanie pracowników jest powszechne, w krajach takich jak Szwecja jest odwrotnie — wywarcie wyraźnej presji, gdy oczekiwania nie są spełnione, może być niezwykle trudne. Nie traktuj mnie jako dominatrix lub nadzorcę, ale jeśli odwrócisz scenariusz i zainspirujesz się którąkolwiek z wielu dostępnych książek psychologicznych lub odkryciami na przykład DORA , zobaczysz, że wysokie inwestycje i troska są naturalnymi konsekwencjami dobrze funkcjonujący zespół, wykonujący swoją codzienną pracę. Tak więc paradoksalnie — zachowując przejrzystość, przejrzystość i współpracując (a nie tylko jako jednostki, tj. przeciwko sobie) — stworzysz warunki dla wysokowydajnych zespołówgdzie odpowiedzialność zwykle przychodzi automatycznie.

Zaangażuj się i inwestuj w pracę. Zezwalaj na pracę zdalną . Ludzie nie będą oszukiwać, jeśli będą dobrze dobrani, oddani i dumni ze swojej pracy.

Po pierwsze: zaufanie, oczekiwania i ambitne cele… następnie przychodzi wzmocnienie.

Zatrudnianie odpowiednich ludzi

Zdobądź kilku, ale bardzo entuzjastycznych programistów z doświadczeniem w realizacji własnych projektów (lub innych firm) w chmurze . Daj tym nowym inżynierom początkowe zadanie migracji lub zmiany platformy niektórych starszych aplikacji, które możesz mieć. Nie powinno zająć zbyt dużo czasu, zanim będziesz mógł zacząć korzystać z tych klauzul odejścia dla każdego pracownika, który nie jest na równi.

Nie zatrudniaj na LinkedIn osób z niejasnymi zadaniami lub tytułami przedszkolnymi, takimi jak „Keynote speaker” lub „Visionary”.

Nie zatrudniaj programistów „masowych”/„wolumenowych”, niezależnie od wielkości Twojej firmy.

Nie zatrudniaj nikogo przy kawie. Pozwól im zostać zweryfikowanym na wszystkich poziomach : Kompetencje techniczne, myślenie produktowe, boczne umiejętności rozwiązywania problemów, inteligencja emocjonalna, poprzednia zademonstrowana praca i jasność własnych celów. Co oboje zyskujecie dzięki wspólnej pracy? (nie „dla ciebie”!) Pozwól im spotkać się z zespołami i pracować razem przez godzinę lub dwie, zanim pociągniesz za spust i zaangażujesz się.

Nie prowadź szkoły. Zainwestuj w ludzi o solidnych podstawach lub ponieś konsekwencje . Opóźnienie koncepcyjne jest prawdopodobnie jednym z głównych powodów, dla których zespoły i organizacje nigdy nie stają się „wielkie”. Na przykład nauczanie ciągłej integracji w organizacji w 2023 roku nie gwarantuje sukcesu — takiej wiedzy powinniśmy się spodziewać jako podstawowej kluczowej kompetencji. To samo dotyczy organizacji zajmujących się innowacjami, gdzie dzieje się to samo, ale nowość koncepcji jest radykalnie wyższa. Krótko mówiąc — zbuduj organizację z ludzi, którzy są już dobrze ugruntowani w podstawach Twojej działalności, inaczej jest ona z całą pewnością skazana na porażkę.

Zachowaj zwinność i smukłość

Najpierw sprawdź, czy to z tobą rezonuje:

W każdym razie… Prawdopodobnie nie znasz Agile , ale możesz mieć wiele opinii na jego temat. Wydaje się, że wszyscy mają! Dla pewnego dostosowania polecam książkę Roberta C. Martina Clean Agile: Back to Basics lub przynajmniej poniższy film, w którym przedstawia on historię zwinności i pozwala, by ta wiedza zapadła jako pierwsza.

Planowanie? Śmiało i użyj czegoś takiego jak projekty GitHub ; cokolwiek jest bliskie kodowi. Unikaj Jira i zarządzania ze względu na zarządzanie, które odbywają się poza prawdziwym twórcą pieniędzy — kodem.

Skalowanie? Agile nie ma na celu skalowania — musisz odskalować problem i uczynić go bardziej namacalnym. Agile nie jest odpowiedzią na wszystko, ale jeśli przejrzysz podstawową literaturę i wyrzucisz wszystkie SAFe, które masz na półce, przynajmniej będziesz miał prawdziwy start. Sprawdź także prezentację Gojko Adzica na temat Descaling Agile . W razie potrzeby odkamieniaj swoją organizację .

Nie kupuj w frameworku . Zacznij dosłownie od niczego: żadnych spotkań, żadnych ceremonii, niczego. Następnie dodaj kilka kropel w razie potrzeby. Unikaj ceremonii, które nic nie wnoszą — na przykład, może zorganizuj krótką, 10-minutową poranną pogawędkę, aby uporządkować dzień (lub na koniec dnia!). Wyrzuć konsultantów SAFe, jeśli masz nieszczęście, że się kręcą. Przyjrzyj się także modelom operacyjnym, które mają większy sens w szybko zmieniającym się otoczeniu, takim jak topologie zespołu .

Organizuj spotkania, które „nie są spotkaniami” . Spotkania muszą być zorientowane na wyniki i dlatego powinny obejmować tylko jedną z poniższych czynności, ale nic poza tym:

• Zdecyduj lub zaplanuj : Musimy również wykonać pewne metadziałania. Tak długo, jak można z nich skorzystać i każdy ma kontekst, warto je mieć. Uważaj jednak na źle zaplanowane spotkania planistyczne! :)
• Praca : Tak! Praca. Ustanowienie nieprzerwanego bloku pracy pary/moba na kilka godzin to świetny sposób na wykorzystanie „spotkania, które nie jest spotkaniem”.
• Ucz się lub dziel się : partnerskie uczenie się, grupy kompetencji, retrospektywa…
• Towarzysko : strzelaj z wiatrem, poznawaj nowych kolegów, pomagaj ludziom znaleźć drogę…

Nie ufaj mi? Zapoznaj się z prezentacją Dave'a Farleya na temat Agile i Kanban.

Chociaż istnieje kilka modeli z odmianami powyżej, niektóre decydujące czynniki powinny wyeliminować wszystkie niepotrzebne plewy.

Dostarczaj w sposób ciągły

„Ciągłe dostarczanie poprawia zarówno wydajność, jak i jakość dostarczania, a także pomaga poprawić kulturę i zmniejszyć wypalenie i problemy związane z wdrażaniem”.

– Accelerate: The Science of Lean Software and DevOps: Budowanie i skalowanie wysokowydajnych organizacji technologicznych

Nieustanne dostarczanie oprogramowania. Model „ minimum viable ” wymaga:

• Rozwój oparty na pniu
• Praca integruje się z tułowiem przynajmniej codziennie
• Praca ma zautomatyzowane testy przed połączeniem z trunkiem
• Praca jest automatycznie testowana z inną pracą podczas scalania
• Cała praca nad funkcjami zatrzymuje się, gdy kompilacja jest czerwona
• Nowa praca nie przerywa pracy dostarczonej

I tak, używaj programowania opartego na pniu : jest to najłatwiejsza strategia rozgałęziania ze wszystkich, jest bezpośrednio powiązana z ciągłym dostarczaniem i pozwala uniknąć bezsensownych opinii na temat rozgałęzień. Jeśli uważasz, że potrzebujesz złożonego rozgałęzienia, problemem nie jest technologia, ale sposób, w jaki przedstawiasz sytuację. Piekło scalania nie stanowi rzeczywistego problemu podczas ciągłej integracji.

Nie wykonuj próśb o ściągnięcie, chyba że jest to logiczne — zamiast tego twórz pary lub mobbing, kiedy tylko jest to możliwe. Recenzje asynchroniczne przerywają przepływ i są zbudowane na nieufności. Upewnij się, że ludzie współpracują ze sobą i tworzą właściwe rzeczy.

Korzystaj z dobrej, wszechstronnej, gotowej platformy CI/CD, takiej jak GitHub, GitLab, Harness lub Azure DevOps. Nie uruchamiaj własnej konfiguracji Jenkinsa ani nie wymyślaj na nowo tego konkretnego koła. Naprawdę nie mogę wymyślić nic bardziej bezużytecznego, aby spędzać czas na budowaniu.

Bądź iteracyjny. Zbuduj coś, co dostarczysz w jakiś sposób lub formie już dziś. Mam nadzieję, że wiele razy dzisiaj, wiele razy jutro.

Używaj jednego środowiska produkcyjnego i tylko efemerycznych, krótkotrwałych środowisk testowych (jeśli kiedykolwiek ich potrzebujesz!). Nie rób rzeczy nadmiernie skomplikowanych, tak jak nauczyłeś się ich w poprzedniej karierze.

Domyślnie używaj technologii bezserwerowej , a także domyślnie korzystaj z opcji SaaS — nie inwestuj za dużo w to, co jest już łatwo i tanio dostępne. Jest to bezpieczniejsze, tańsze i łatwiejsze, jeśli masz ludzi, którzy znają chmurę. Zbyt wielu tego nie robi i będzie narzekać, że serverless jest zły. Nie ufaj im. Zamiast tego pozyskaj ludzi, którzy znają chmurę.

Użyj przełączania funkcji, gdy zaczniesz potrzebować segregować zestawy funkcji, takie jak niedokończone funkcje, grupy użytkowników, beta testerzy… Jak pisze Charity Majors, „ Wdrożenia to zły sposób na zmianę doświadczenia użytkownika ”.

Jakość

Moja teza jest taka, że ​​jeśli inżynierskie podejście do tworzenia oprogramowania nie pomaga nam szybciej tworzyć lepszego oprogramowania, to jest błędne i nie kwalifikuje się jako „Inżynieria”.

— Blog Dave'a Farleya, Czym jest nowoczesna inżynieria oprogramowania?

Pisz testy, wszystkie — skupiając się na testach jednostkowych i testach integracyjnych. Nie ma 100% pokrycia w pierwszym dniu, ale nie pozwól, aby ten dług wkradał się przez zbyt wiele dni.

Nie zatrudniaj inżynierów kontroli jakości, testerów ani nikogo podobnego. Oczekuj, że Twoi inżynierowie będą w stanie określić ilościowo swoją jakość za pomocą testów i upewnij się, że mają na to czas.

Naucz się korzystać z chmury publicznej. Nie zatrudniaj nikogo, kto nie ma doświadczenia w chmurze.

Ustaw zadania dla każdego ostatniego kawałka długu technicznego.

Nie zapomnij o wymaganiach prawnych, bezpieczeństwa i innych wymaganiach międzyfunkcyjnych. Powinny one pomóc w ustaleniu SDLC lub minimalnych wewnętrznych kryteriów definicji ukończenia.

W zamknięciu

Moja próba tutaj, bezskuteczna lub nie, polegała na tym, aby być tak szczerym, jak tylko mogłem, o problemach, które ty, jako tradycyjna organizacja wykorzystująca „IT”, masz, gdy próbujesz stać się firmą bardziej skoncentrowaną na oprogramowaniu. W żaden sposób nie powiedziano ani nie napisano ostatniego słowa, ale mam nadzieję, że wiesz, gdzie zalecałbym wprowadzenie pewnych zmian, jak one wyglądają i jakie są niektóre różnice kulturowe między organizacją IT a prawdziwym oprogramowaniem biznes.