Osiem zasad efektywnej produkcji oprogramowania

W trakcie mojej kariery brałem udział w wielu projektach oprogramowania z prawdziwego życia i obserwowałem, jak robi się rzeczy na wszystkich poziomach: podejmowanie decyzji, przyjmowanie praktyk, budowanie zespołu, rekrutacja, dystrybucja umiejętności itp. Oczywiście różne podejścia przyniosły różne wyniki . Będąc osobą zorientowaną na doskonalenie, zauważyłem i zebrałem najskuteczniejsze praktyki i najlepsze praktyczne triki, które pomogą mi w mojej pracy.

Uczenie się z obserwacji to trudny i długotrwały sposób. Byłbym niezmiernie szczęśliwy, gdybym wybrał tę wiedzę wcześniej z książek. Niestety nie znalazłem żadnego na ten temat. Postanowiłem więc podzielić się swoim doświadczeniem z innymi poszukiwaczami tego rodzaju wiedzy. Miejmy nadzieję, że zaoszczędzi im to kilku lat osobistych poszukiwań.

W tym artykule dowiesz się, jak pokonać średnią wydajność w branży, tworząc solidne i niezawodne oprogramowanie, które wymaga 5-10 razy mniej konserwacji. Mogę bez fałszywej skromności powiedzieć, że w ciągu ostatnich 10-15 lat ja (osobiście i moje zespoły) przekroczyłem wszelkie oczekiwania, zostawiając za sobą ślad sukcesów. Menedżerowie nie mogą być szczęśliwsi.

Kiedyś mój zespół zrealizował ważny projekt w niemożliwie krótkim czasie, za który otrzymaliśmy nagrodę „High Performance Team” od wyższej kadry kierowniczej. Wszystko to bez nocowania i weekendowego męczenia się. Po prostu normalna praca.

Widzisz, wiedza na temat efektywnego tworzenia oprogramowania sama w sobie jest potęgą. W rzeczywistości jest to rodzaj czarnej magii, której niewielu ludzi może pojąć, nawet jeśli wyjaśni się ją prostymi słowami. Dostaniesz to za darmo. Czytaj dalej, jeśli chcesz być postrzegany jako magik produkcji oprogramowania.

Dla kogo to jest?

Pozwólcie, że przedstawię tutaj ważne, ważne, ważne zastrzeżenie.

Kieruję to do osób potrzebujących zwiększenia produktywności. Nie wszystko w życiu dotyczy produktywności. Nie wszystkie projekty oprogramowania też. Zdarzają się przypadki, kiedy nie jesteś oceniany na podstawie wyników. Oczywiście te praktyki nie pomogłyby wtedy.

Techniki te będą najbardziej przydatne dla liderów zespołów, architektów i kierowników projektów, chociaż starsi programiści również mogą z nich skorzystać.

Zasada nr 1: Zrozum mentalność IT

Branża IT to mieszanka nauki, technologii, sztuki i biznesu. Trudno się tam poruszać bez zrozumienia tych aspektów na wystarczająco dobrym poziomie. Największym problemem jest to, że sama branża jest dość złożona; dlatego też najlepsze praktyki są również złożone. Aby odnieść sukces, musisz dużo się nauczyć i zweryfikować swoją wiedzę, dużo ćwicząc.

Niesamowita szybkość aktualizacji technologii sprawia, że ​​jest to podwójnie trudne. Nic, czego nauczyłeś się dziesięć lat temu, nie jest już potrzebne. Musisz więc uczyć się w przyspieszonym tempie.

Podsumowując powyższe, możemy powiedzieć, że sukces w branży IT nie opiera się na wrodzonych umiejętnościach czy uczuciach, ale na twardych praktycznych przykładach. Nigdy, przenigdy nie „kieruj się instynktem” ani nie wierz wyłącznie w oparciu o uczucia, w tym twoje.

Jeśli tak, to pomysł wart rozważenia. W przeciwnym razie zażądaj bardzo dobrego i bardzo szczegółowego wyjaśnienia, w jaki sposób wybranie tej ścieżki poprawi życie twojego zespołu. Jeśli pomyślnie przejdzie ten test, zaplanuj lekki projekt weryfikacji koncepcji, który eksperymentalnie udowodni, że pasuje do Twojego środowiska.

Ważne jest, aby zrozumieć, że nie ma dobrych i złych rozwiązań, ponieważ istnieje wiele sposobów rozwiązywania problemów z oprogramowaniem. Jednak istnieją dobre i złe rozumienie rozwiązania.

Jeśli dana osoba potrafi jasno i szczegółowo wyartykułować pomysł lub narysować związek między przyjęciem tego rozwiązania a sukcesem zespołu w celu przekonania innych członków zespołu, możemy polegać na wizji tej osoby i mieć nadzieję na dużą szansę na sukces.

Zasada nr 2: Nie mieszaj metod produkcji oprogramowania z metodologiami rozwoju oprogramowania

Produkcja oprogramowania opiera się na rozwoju oprogramowania. Jednak te dwa mają zupełnie inne cele, sposób myślenia i praktyki. Próba rozwiązania problemu z jednej z tych sfer metodami z innej przynosi śmieszne rezultaty. Ważne jest, aby zrozumieć różnicę i stosować odpowiednie metody dla każdego z tych światów.

Tworzenie oprogramowania to połączenie sztuki i rzemiosła. Komponent artystyczny będzie zawsze obecny, niezależnie od dostępnych narzędzi automatyzacji i metodologii tworzenia oprogramowania. Dlatego rozwiązywanie zadań programistycznych wymaga maksymalnej koncentracji i osłony przed wszystkimi innymi rozpraszającymi sygnałami.

Najlepszym sposobem na zmotywowanie doświadczonego programisty jest przedstawienie mu zadania w czystej formie technicznej, z wyłączeniem wszystkich czynników ludzkich. Wszystkie wymagania powinny być również wyrażone w języku technicznym. Powinny być łatwe do zweryfikowania, aby umożliwić im nawigację w kierunku celu podczas ich samodzielnej fazy badań.

W przeciwieństwie do tego, produkcja oprogramowania jest raczej domeną administracji biznesowej. Z jednej strony wiesz, czego potrzebuje Twój klient, az drugiej wiesz, jakimi zasobami zespołu dysponujesz. Więc teraz próbujesz pokierować wysiłkiem swojego zespołu, aby osiągnąć cel. W międzyczasie możesz również oszacować szybkość swoich postępów i przedstawić szefowi dobrze zorientowany plan. Ważnymi umiejętnościami są zrozumienie życzeń klienta, zrozumienie mocnych stron zespołu oraz przekazywanie formalnych planów i harmonogramów.

Mając to na uwadze, chciałbym podkreślić, że wiele ról w tworzeniu oprogramowania działa w obu tych światach — budując pomost między biznesem a technologią — takich jak liderzy zespołów, architekci, analitycy i kierownicy projektów. Osoby w tych rolach powinny bez problemu poruszać się między dwoma płaszczyznami rzeczywistości i rozumieć, kiedy nadszedł czas na rozmowy o interesach, a kiedy na sztukę.

Zasada nr 3: Używaj pamięci trwałej jako rozszerzenia ludzkiej pamięci

Pamięć ludzka, choć zdumiewająca w swojej pojemności, ma swoje ograniczenia. Zapamiętujesz rzeczy z nieprzewidywalną dokładnością i czasem trwania, a kiedy zapomnisz, nie ma możliwości przywołania ich do woli.

Dlatego używamy trwałej pamięci masowej, aby poruszać się z przewidywalną prędkością. Nie chodzi tu o formalną dokumentację, taką jak podręczniki użytkownika, które tworzysz długo po fakcie i do użytku innych osób. Chodzi o używanie dokumentów dosłownie jako zewnętrznego rozszerzenia pamięci podczas pracy, które pomaga przejść przez proces tworzenia oprogramowania.

Zalecam, abyś dokumentował swoje przemyślenia i plany po drodze, gdy masz do czynienia z nietrywialnymi zadaniami lub zadaniami, które angażują więcej niż jedną osobę. Postaraj się, aby było tak tanie, jak to tylko możliwe. Nie twórz formalnych dokumentów z logo firmy. Dobrym narzędziem byłaby firmowa wiki z miejscem na projekt. Twórz dedykowane strony dla zadań lub problemów (30 sekund). Następnie aktualizuj go za każdym razem, gdy masz pomysł lub chcesz omówić go z innymi.

Na spotkaniu powiedz „poczekaj, pozwól mi to odłożyć” i poświęć 10-30 sekund, aby wyrazić to na piśmie. Tekst nie powinien być obszerny, ale powinien być kompletny i spójny, tak jakbyś przenosił cały pomysł na papier. Później ty lub ktokolwiek inny czytający twój fragment powinien zrozumieć go tak jasno, jak rozumiesz go teraz. Ta sztuczka oszczędza dużo czasu, a jednocześnie pozwala na dokumentowanie w locie.

Ta technika służy dwóm celom.

Po pierwsze, blokuje twój postęp na drodze do sukcesu, mocno wciskając go w kamień. Koniec z ryzykiem, że ktoś o czymś zapomni, powtarza to samo raz za razem lub renegocjuje tę samą rzecz, która była już wynegocjowana.

Po drugie, oczyszczasz swój umysł, odrzucając problem, który cię dokuczał. Teraz twój umysł jest głodny kolejnego wyzwania. Co za wzrost produktywności!

Dotyczy to dowolnej wielkości projektu lub zadania. W przypadku większych będziesz mieć po prostu większe przestrzenie z hierarchią stron, która stopniowo rośnie wraz z rozwojem projektu. Ważną koncepcją jest tutaj przygotowanie przestrzeni i struktury dokumentacji przed rozpoczęciem zadania polegającego na ustanowieniu protokołu szybkiego zrzucania pamięci!

Dla osób preferujących analogie technologiczne porównałbym nasz umysł do procesora o ogromnej mocy obliczeniowej, ale ograniczonej pamięci operacyjnej. Zasadniczo możesz myśleć o jednej rzeczy na raz. W tej analogii twoja dokumentacja służy jako trwałe przechowywanie, podczas gdy twój umysł rozwiązuje złożone problemy w podejściu iteracyjnym. W pewnym momencie postanawiasz rozpocząć kolejną iterację, przeczytać poprzednią dokumentację i załadować bieżący stan do pamięci operacyjnej, myśląc o tym przez chwilę i aktualizując kod i dokumentację o nowe odkrycia. Krok po kroku, aż do zakończenia.

Biorąc powyższe pod uwagę, nie zachęcam ludzi do przetwarzania wielu zadań na raz. Wręcz przeciwnie, im mniej masz zadań, tym lepiej. Niewiele sytuacji w pracy jest jednak naprawdę zoptymalizowanych pod kątem ludzi, a wielozadaniowość może być wymagana i trzeba sobie z tym poradzić. Powyższa sztuczka pomaga lepiej sobie z tym poradzić.

Zasada nr 4: Przestań marnować czas na formalne oszacowanie czasu

Nie ma dwóch takich samych projektów. Następnym razem, gdy wykonasz podobny projekt, będziesz miał różnych klientów, różne cele, inny zespół; może nawet różne technologie. Nawet przy użyciu standardowych narzędzi i komponentów nadal będziesz musiał dostosować ich konfigurację i architekturę. Kiedy zajmujesz się projektami oprogramowania, pamiętaj, że obejmują one od 50% do 100% niestandardowej pracy. Wymagają badań, dyskusji, myślenia, prób i innych wysoce nieprzewidywalnych działań. W praktyce możesz doświadczyć ogromnej różnicy w tym, co wydaje się być dokładnie tym samym typem projektu i tym, co robiłeś wcześniej. Co za tym idzie, nowy typ projektu jest prawie niemożliwy do dokładnego oszacowania.

Skoro jest tak nieprzewidywalny, to w jaki sposób kierownicy projektów mają przedstawiać harmonogram projektu i się go trzymać?

W literaturze opisano jedną formalną metodę wykonania tego; mianowicie, aby podzielić cały projekt na mniejsze etapy, oszacuj czas trwania każdego etapu, a następnie oblicz całkowitą długość projektu, łącząc długość pracy poszczególnych elementów. Za tą metodą kryje się mnóstwo teorii nauczanych na kursach MBA.

Niestety, żadna ilość matematyki tego nie uratuje. Ta metoda jest notorycznie niedokładna, do tego stopnia, że ​​jest całkowicie bezużyteczna i niepraktyczna, nie wspominając o tym, jak niesamowicie czasochłonna jest. Nigdy nie spotkałem kierownika projektu, który używałby formalnych metod obliczeniowych bez żadnych poprawek, nawet wśród metodologicznych fanatyków. Nawet wtedy, gdy firma surowo narzucała stosowanie takiej metody! W rzeczywistości najlepsi menedżerowie stosują zupełnie inne alternatywne metody, jak opisano poniżej:

Dobry kierownik projektu zwraca uwagę na rodzaj projektu, środowisko, zaangażowane zasoby, rodzaj organizacji i wszystkie inne aspekty pracy mające wpływ na rzeczywisty czas trwania projektu. Oczywiście nikt nie musi uczyć się wyłącznie na własnych błędach. Takie obserwacje można prowadzić zarówno bezpośrednio, jak i pośrednio; na przykład poprzez książki lub studiując projekty wykonane przez innych ludzi, a nawet po prostu przekazując wiedzę osobie. Taka statystyczna wiedza na najwyższym poziomie usprawnia nawigację w osobistym harmonogramie projektu.

Chciałbym zwrócić uwagę na dwie ważne konsekwencje opisanej powyżej metody.

Po pierwsze, dokładność szacowania poprawia się wraz z doświadczeniem. Nie ma możliwości, aby niedoświadczona osoba uzbrojona w jakąkolwiek silną metodologię, jaką posiada, była w tym dobra. Po drugie, nawet najlepsze oszacowanie jest nadal dobre tylko pod względem statystycznym. To znaczy można powiedzieć, że pewien projekt może zająć od czterech do dwunastu miesięcy. Zakładając, że to prawda, należy zrozumieć, że istnieje 50% szans, że projekt będzie działał w średnim ośmiomiesięcznym czasie.

Zrozumienie prognozy statystycznej ma tak niesamowity efekt. Mądry menedżer po prostu oszacowałby ten projekt na dwanaście miesięcy, a potem zachwycił wszystkich, kończąc go wcześniej. Innymi słowy, nikt nie spodziewałby się, że zespół będzie postępował zgodnie z harmonogramem projektu do jednego dnia.

Ogólną radą dla kierowników projektów i ich szefów byłoby zaprzestanie marnowania czasu na formalne metodologie szacowania czasu. Zamiast tego zachęcaj do zbierania informacji statystycznych o czasie trwania projektu i dziel się tymi informacjami w całej firmie. Znam firmy, w których takie podejście zostało wdrożone w całej firmie, co zaowocowało cudowną precyzją predykcyjną.

Zasada nr 5: Zrozum koszt zmiany zadań i priorytetów żonglowania

Ludzki umysł jest zdumiewająco skonstruowany przez naturę. Choć jest niesamowity, ma swoje ograniczenia. Innymi słowy, został zaprojektowany, aby wyróżniać się w określonych obszarach i określonym typie zadania.

Umysł programisty jest zdecydowanie wielkim atutem w tworzeniu oprogramowania. Czy jako kierownik projektu byłbyś zainteresowany lepszym zrozumieniem tego i umieszczeniem go na stanowisku, na którym działa najlepiej?

Ujmijmy to w prosty sposób, unikając zbytniej teorii. Pamiętaj, że teoria zaprowadzi cię tylko tak daleko, że będziesz musiał uczyć się na własnych doświadczeniach lub od innych.

Ludzki umysł ma silny potencjał rozwiązywania problemów i generowania pomysłów. Niestety, nie zawsze można wykorzystać ten potencjał, głównie dlatego, że aby wesprzeć generowanie pomysłów, musisz jednocześnie przechowywać wszystkie elementy problemu w aktywnej pamięci. Dlatego rozwiązywanie złożonych problemów przechodzi przez etap uproszczenia, kiedy zadanie jest uogólniane lub przeformułowywane w celu wycięcia nieistotnych kawałków i zmniejszenia liczby elementów przechowywanych jednocześnie w pamięci. Innymi słowy, możemy rozwiązać jeden bardzo wąski złożony problem lub wiele prostych problemów.

Stosunek nie jest jednak liniowy. Zwiększenie liczby rzeczy, które robisz jednocześnie, drastycznie osłabia twoje umiejętności rozwiązywania problemów. Dlatego ludzkość zawsze stosowała i będzie stosować separację ról jako optymalizację życia. Dwie osoby pracujące oddzielnie nad dwoma zadaniami dokonają przełomu szybciej, niż gdyby obie pracowały nad obydwoma zadaniami jednocześnie.

Inną ważną cechą ludzkiego umysłu jest niezdolność do natychmiastowego przełączania się między zadaniami, tak jak robią to komputery. Rzeczywiście, nie można po prostu przestać myśleć o czymś do woli. Nie możesz też od razu zacząć myśleć o nowej koncepcji na pełnych obrotach. Ten rodzaj inercji psychicznej doskonale ilustrują operatorzy kontroli ruchu lotniczego. Mimo że patrzą na radar i widzą cały obraz, nadal muszą go załadować do swojej pamięci, aby działać szybko. Nowy operator potrzebuje dziesięciu minut, aby obejrzeć ekran, zanim będzie mógł wymienić starego na zmianę.

Co gorsza, nie możemy zapomnieć o rzeczach do woli. Wszystko, czego się nauczyliśmy, zostaje z nami i stopniowo zanika z czasem, zajmując przestrzeń, którą moglibyśmy wykorzystać na nową wiedzę. A co gorsza, efekt ten potęguje czasami poczucie „niedokończonych spraw”. O wiele łatwiej jest zapomnieć o czymś, co jest skończone i czego nigdy nie będziesz potrzebować w przyszłości. Podczas gdy odkładasz rzeczy na bok, aby dokończyć później, twój mózg naturalnie chwyta informacje oznaczone jako „do wykorzystania w przyszłości”, nie chcąc pozwolić, aby nowa wiedza zajęła jej miejsce.

Dobra. Teraz, gdy przedstawiliśmy już ideę przełączania zadań, zobaczmy, jak to działa w prawdziwym (że tak powiem) eksperymencie myślowym.

Wyobraź sobie, że masz dziesięciu stałych programistów pracujących nad dziesięcioma regularnymi zadaniami — jednym zadaniem na osobę. Zakładając, że potrafimy zamknąć je w idealnym, wolnym od rozpraszania środowisku, każde zadanie może zostać rozwiązane w określonym czasie przez jeden umysł. Całość zajmie tyle czasu, ile zajmie wykonanie najdłuższego pojedynczego zadania.

Teraz powtórzmy ten sam eksperyment umysłowy. Tym razem bez (ważnego) powodu będziemy stale zmieniać przydziały zadań między programistami. Każdego dnia każdy programista otrzymuje nowe zadanie do pracy. Co więcej, zmieniajmy to co godzinę. Jak szybko się skończą, myślisz? Może nigdy.

Kierownik projektu w pierwszym scenariuszu był w stanie skutecznie zrealizować projekt. Drugiemu udało się go „wykonać”, to na pewno… w tym sensie, że ułatwili jego śmierć. Gratulacje. Ta technika zabijania projektów jest wyjątkowo skuteczna, ponieważ oprócz marnowania czasu obniża również morale pracowników do zera.

Większość ludzi zgodziłaby się z powyższym przykładem, gdyby został im przedstawiony w sposób czysto akademicki. Jednak w prawdziwym życiu nagle zapominają o wszystkim pod najmniejszym naciskiem. Wielki szef żąda raportu z postępów lub klient pyta o termin wdrożenia określonej funkcji — prawie każde zewnętrzne wydarzenie może skłonić kierownika projektu do pośpieszenia do zespołu i wyrażenia jego zaniepokojenia, po czym następuje lawina zmian przydziału zadań i żonglowania priorytetami w próbować zdobyć trochę czasu tu i tam, co ostatecznie doprowadziło do jeszcze większego zepchnięcia projektu z toru.

To prawdziwy scenariusz, który niestety zdarza się dość często.

Dobry menedżer wstaje i chroni zespół przed takimi drobnymi zakłóceniami, absorbując emocjonalną falę uderzeniową i przekształcając ją w produktywne przyszłe elementy dyskusji. To zdecydowanie trudne emocjonalnie, ale to jedyny sposób, aby utrzymać zespół w dobrym rytmie pracy i pozwolić mu działać.

Zasada nr 6: Użyj recenzji architektury jako sposobu na ulepszenie projektu systemu

Branża IT operuje pojęciami nad- i niedoinżynierii . Kiedy pojawia się to w wywiadzie, wszyscy mówią, że nadmierna inżynieria jest zła. Na to pytanie łatwo odpowiedzieć, ponieważ samo pytanie niesie ze sobą negatywną konotację „nad”, co oznacza „za dużo”. Prawdziwym praktycznym know-how byłoby rozpoznanie, kiedy twoja architektura staje się przeprojektowana i unikanie tego na wczesnych etapach.

Pozwól, że dam ci kilka moich sprawdzonych wskazówek na ten temat.

Przede wszystkim rozwiązanie można uznać za przeprojektowane, jeśli istnieje inne prostsze rozwiązanie zapewniające wszystkie wymagane funkcje. Oznacza to, że jeśli nie znasz prostszego rozwiązania, to każde najprostsze rozwiązanie, jakie możesz zaoferować, jest w twoich oczach najlepsze, chyba że ktoś udowodni ci, że się mylisz.

Jeśli nasz wymyślony architekt naprawdę dąży do perfekcji rozwiązania, zwykły przegląd architektury gwarantuje, że jest on wystarczająco optymalny. Niestety przegląd architektury wymaga co najmniej kilku innych wykwalifikowanych architektów. W wielu przypadkach grozi to niedostępnością lub niepraktycznością. W przypadku braku recenzowania architekci są podatni na powszechne błędy. Przejrzyjmy je jeden po drugim i omówmy możliwe środki zaradcze dla każdego.

Jednym z najczęstszych błędów jest projektowanie bez celu biznesowego. Wydaje się oczywiste, że każda praca zawodowa powinna być powiązana z satysfakcją klienta końcowego, sukcesem firmy lub podobną potrzebą biznesową. Jednak często można zobaczyć architekturę zaprojektowaną w całości lub w części bez takiego celu. Rozumowanie jest albo nieobecne, albo sprowadza się do użycia jak największej liczby nowoczesnych dzwonków i gwizdków.

Architekt w tym przypadku nie robi tego, za co zapłacił konsument. Zamiast tego bawią się fajnymi zabawkami dla własnej zabawy i przyjemności. Jest to w żaden sposób nie do przyjęcia w branży formalnej. A jednak wydaje się, że i tak zdarza się to dość często.

Czasami problem tkwi w osobowości architekta i jego obsesji na punkcie określonych technologii czy narzędzi. Po prostu lubią z nich korzystać i nie potrafią spójnie wyjaśnić, jakie potrzeby biznesowe starają się rozwiązać. Blisko tego jest inny przypadek, w którym ludzie nie wiedzą nic poza budowaniem czegoś z małych kawałków. Z pewnością każde zewnętrzne wydarzenie wyzwala chęć zanurzenia się w świecie projektowania i nigdy nie wraca do prawdziwego klienta. Chociaż początkowy impuls może być ważnym wkładem biznesowym, ich przedłużające się oderwanie od rzeczywistości zmniejsza użyteczność ich dzieła.

Lekarstwo na to jest bardzo proste, ale wymaga samodyscypliny. Dobry architekt nie powinien nigdy dotykać pióra i papieru, dopóki nie będzie mógł jasno i szczerze odpowiedzieć sobie, dlaczego jest to potrzebne. Taka potrzeba może przybierać różne formy. Może to być wymóg formalny, domniemana potrzeba ulepszenia produktu lub pojawienie się nowych technologii, które sprawiają, że poprzedni projekt jest mniej skuteczny. W każdym razie nie powinno to być formalnym wyzwalaczem, o ile sami architekci rozumieją siłę napędową. Następnie mogą wykorzystać tę siłę jako ostateczną weryfikację jakości swojego projektu.

Inny trudniejszy do wykrycia problem jest związany z myśleniem o architekturze blokowej. Osoby z taką mentalnością wierzą, że na wszystko jest rozwiązanie i to rozwiązanie jest zawsze wdrażane jako budulec. Innymi słowy, przekładają funkcjonalność bezpośrednio na komponenty, bez oceny architektury jako całości. Mogą po prostu dołączyć do systemu komponent zapewniający pożądaną funkcjonalność, gdy zajdzie taka potrzeba. W większości przypadków spełnia to wymogi formalne, ale pozostawia system w niespójnym stanie. Nowy blok nie został wybrany na podstawie kompatybilności istniejącego systemu pod kątem rozwoju, wsparcia, a nawet modelu licencjonowania firmy. Dlatego zespół próbuje zmodyfikować istniejącą konfigurację lub wdrożyć tę funkcjonalność za pomocą istniejącej pojemności systemu. W rezultacie obsługa i konserwacja systemu stopniowo zamieniają się w zawiły koszmar, po którym następuje spadek wydajności.

Nie ma prostego rozwiązania tego problemu, ponieważ inżynieria systemu jest sztuką i nigdy nie można przewidzieć, czy należy dodać nowy komponent, czy można tego uniknąć. Najlepszą praktyką byłoby prawdopodobnie utrzymywanie zaległości związanych z konserwacją i problemami architektonicznymi narastającymi w czasie, a następnie okresowe przeglądy ogólnej architektury systemu. Ten okresowy przegląd może również uwzględniać pojawiające się technologie. Tak więc ogólnym celem przeglądów architektury nie powinno być naprawianie problemów, ale ocena potencjalnej wykonalności pożądanych ulepszeń i systemu jako całości w obliczu zbliżającej się nieuchronności przestarzałości.

Zasada nr 7: Wartość drużyny graczy

Większość specjalistów z branży IT została zapytana na rozmowie kwalifikacyjnej, czy są dobrymi graczami zespołowymi, czy też dobrze pracują w zespole. Jednak chyba nikt nigdy nie widział jasnej definicji tego w literaturze. Oczywiście taka osoba przyczyniłaby się do ogólnego sukcesu zespołu, ale niewiele osób potrafi określić charakterystyczne cechy osobiste zapewniające taki sukces.

Obserwowałem wiele osób pracujących na różnych poziomach i widziałem, jak ich cechy osobiste wpływają na postęp projektu. Chciałbym przedstawić poniższe wskazówki dotyczące cech osobistych, które są najbardziej pomocne w pracy zespołowej.

Przyległy

Pierwszą i najważniejszą cechą jest oczywiście umiejętność komunikowania się.

Wyobraź sobie osobę o zerowych zdolnościach komunikacyjnych. Z pewnością brak informacji zwrotnej od członków zespołu czyni ich całkowicie bezużytecznymi. Jest to tak oczywiste, że nikt tak naprawdę nie mierzy tej umiejętności podczas rozmowy kwalifikacyjnej, co oznacza, że ​​umiejętność jest na wystarczająco dobrym poziomie, o ile osoba potrafi dobrze mówić.

Komunikacja nie jest umiejętnością binarną tak/nie; jest to raczej okno przekazywania informacji. Im jest szerszy, tym szybsza i czystsza wymiana informacji.

Ponieważ zakres otwartości tego okna jest bardzo zróżnicowany w całej populacji, miara szerokości takiego okna jest ważną cechą gracza zespołowego. Pamiętaj, że mówimy o przekazywaniu informacji w tym kontekście, ale nie o płynnym mówieniu, zachęcaniu ludzi, motywowaniu ich lub organizowaniu ich poprzez rozmowę i komunikację.

Styl komunikacji również nie ma znaczenia. Informacje mogą być przekazywane ustnie, tekstowo, na zdjęciach lub w sposób mieszany. Osoba może mówić szybko lub wolno. Mogą być przyjazne, jak patrzenie Ci w oczy i uśmiechanie się przez cały czas, lub mogą odwrócić wzrok i mówić monotonnym głosem. Styl może wpływać na Twoje osobiste postrzeganie współpracownika, ale dopóki jasno rozumiesz, co mają na myśli, wystarczy każdy styl.

Przejdźmy do praktycznych przypadków wykrywania i mierzenia zdolności komunikacyjnych.

Ogólnie rzecz biorąc, istnieją dwa główne aspekty umiejętności komunikacyjnych. Pierwsza to chęć dzielenia się informacjami. Niektórzy ludzie są chętni do dzielenia się, ale inni starają się ukryć informacje. Ta skłonność jest mniej lub bardziej naturalna, ale można ją powoli zmieniać dzięki automotywacji i treningowi. Można bezpiecznie założyć, że osoba wykazująca jeden rodzaj chęci do dzielenia się informacjami również wykaże to w przyszłości. Dlatego ta cecha jest dobra do przewidywania przyszłego sukcesu kandydata w zespole.

W prawdziwym życiu osoby próbujące ukryć informacje są łatwo zauważalne. Zwykle starają się rozdawać celowo bezużyteczne informacje zamiast czegokolwiek, co jest rzeczywiście potrzebne. Lub zadają wstępne pytania, aby skierować przepływ informacji do wewnątrz i zminimalizować swoje odpowiedzi do sytuacji, w której trzeba wiedzieć. Bez względu na ich taktykę, w końcu poczujesz, że nie uzyskałeś od nich pożądanych informacji lub że zdobycie informacji wymagało zbytniego dodatkowego wysiłku.

Ważne jest, aby zrozumieć intencje, ponieważ niektóre typy osób otwartych mogą zadać ci wstępne pytania, aby lepiej zrozumieć twoje pytanie, a następnie udzielić ci odpowiedzi w najwygodniejszy sposób. Osoba, która zamierza ukryć informacje, zada dodatkowe pytania tylko po to, aby odciągnąć rozmowę i nigdy nie odpowiadać na pierwsze pytanie.

Kolejną częścią umiejętności komunikacyjnych jest umiejętność dostrojenia się do słuchacza.

Różni ludzie mają inny poziom zrozumienia tematu, inny styl komunikacji, a może nawet inne zainteresowanie określonymi szczegółami. Niektórzy inteligentni komunikatywni ludzie zróżnicowaliby przebieg konwersacji w zależności od zdolności słuchacza do jej zrozumienia i przygotowania odpowiedzi w celu dostarczenia konkretnych informacji. W takim przygotowaniu można zadać kilka pytań wstępnych, aby zawęzić zainteresowanie słuchaczy. Umiejętność „wypracowania” różnic komunikacyjnych jest naprawdę świetną umiejętnością, ponieważ pozwala osiągnąć zrozumienie w prawie wszystkich przypadkach. Z drugiej strony, elastyczni mówcy mogą czasami po prostu utknąć w nierozwiązywalnych ślepych zaułkach nieporozumień.

Zrozumienie mocnych i słabych stron

Skupmy się na innej osobistej jakości niezbędnej dla gracza zespołowego.

Większość ludzi zgodziłaby się, że środowisko zespołowe powinno być bardziej przyjazne niż przeciętny otaczający świat, aby wspierać współpracę i zwiększać produktywność. Dlatego ważne jest, aby zespół zrozumiał mocne i słabe strony każdego członka, aby właściwie rozdzielić zadania i pokryć słabe strony mocnymi stronami. Pierwszym krokiem na tej ścieżce jest uczciwe porównanie swoich umiejętności przez wszystkich członków. Z psychologicznego punktu widzenia może to być trudne, ponieważ naturalnie mamy tendencję do ukrywania naszych słabych punktów przed innymi, chroniąc siebie.

Tu z pomocą przychodzi miła atmosfera zespołu.

Oczekuje się więc, że nowy członek będzie grał zgodnie z zasadami zespołu. Niestety, niektórzy ludzie nie potrafią obniżyć czujności nawet w przyjaznym otoczeniu. Przez całe życie zachowują się jak samotne wilki. To jest silniejsze od nich. Niestety taka postawa nie sprzyja wysiłkom zespołu.

Jest prosta technika rozpoznania takich samotnych wilków podczas wywiadu. Nigdy nie przyznają, że czegoś nie wiedzą. Oczywiście ludzie lubią się pokazywać, pokazując wszystkie swoje umiejętności i próbując rozwiązać każdy trudny problem. Jednak dla każdego istnieje limit wiedzy. Nasze ograniczenia kształtują nasze umiejętności. Nie przyznawanie limitów oznacza, że ​​kandydaci prezentują się jako wszechstronni zawodnicy, równie dobrzy we wszystkim i niczym.

Zatrudniając specjalistę, prawdopodobnie chciałbyś uniknąć takich osób. Poza tym ta arogancka postawa często wiąże się z kolejną cechą, która jest czerwonawą flagą: niechęć do proszenia o pomoc. Umiejętność proszenia o pomoc jest absolutnie niezbędna w pracy zespołowej. Bez niej nie możemy się rozwijać i rozwijać tak szybko. Taka uparta osoba spalałaby zasoby i czas firmy, bez końca walcząc z trudnymi zadaniami, ale nigdy nie wzywając kolegów z drużyny o pomoc. Jest łatwy sposób na wykrycie takich kandydatów podczas rozmowy kwalifikacyjnej. Zadaj im pytanie, które nie ma sensu lub wspomnij o jakimś bezsensownym określeniu. Normalna, idealnie ciekawska osoba powiedziałaby po prostu, że nie wie, i zapytała, co to jest. Osoba broniąca nigdy by tego nie zrobiła, nawet jeśli podkreślisz, że nie ma dobrej lub złej odpowiedzi i że „nie wiem” nie dyskwalifikuje jej.

Zasada nr 8: Skup się na organizacji pracy zespołowej

Jest tak mało informacji na temat organizacji pracy zespołowej, jak w każdym poprzednim temacie powyżej. Wszyscy wiedzą, że praca zespołowa jest lepsza, ale jak zbudować i utrzymać zespół, pozostaje tajemnicą. Jednak nawet jeśli nie da się omówić wszystkich aspektów budowania zespołu, możemy tutaj przynajmniej zbadać kilka kluczowych technik budowania zespołu.

Ekspertyza budowlana

Każdy projekt IT jest wyjątkowy. Aby odnieść w nim sukces, trzeba poznać i opanować specyfikę projektu. Mogą obejmować zarówno wiedzę techniczną, jak i nietechniczną. Przykładem wiedzy nietechnicznej może być osobista sieć dla kierownictwa, klientów, zespołów wsparcia technicznego itp. Specjalna wiedza techniczna to dodatkowe szczegóły poza ogólnymi umiejętnościami informatycznymi.

Na przykład możesz potrzebować znajomości Mavena, aby zbudować projekt. Jednak dokładna struktura kompilacji, lokalizacja właściwości i filtrowanie nadal będą się różnić w zależności od projektu. Jak w przypadku każdego rodzaju wiedzy, opanowanie takich szczegółów wymaga czasu; im więcej czasu w to zainwestuje, tym lepsze wyniki. Czas to najcenniejszy zasób, jaki masz. Chcesz jak najdłużej koncentrować się na tym samym obszarze funkcjonalnym członka swojego zespołu, aby wykorzystać jego wiedzę fachową i jeszcze bardziej go rozwijać, a tym samym stale poprawiać wydajność zespołu.

Niestety nie można tego robić w nieskończoność. Z jednej strony ludzie mogą się po prostu nudzić. Z drugiej strony narażasz się na utratę ich wiedzy fachowej, nieoczekiwanie narażając swój projekt na ryzyko.

Zobaczmy, czy istnieją sposoby na poradzenie sobie z wadami bez znacznego ograniczania wydajności zespołu.

Rozdziel obszary zainteresowania między członków zespołu i pozwól im budować w nich swoją wiedzę. W pewnym momencie osiągają wystarczająco wysoki poziom, który ma sens w zakresie tego projektu. W tym momencie dodatkowy wysiłek związany z nauką nie poprawi go znacząco. Bez motywacji i wyzwań mądrzy ludzie się nudzą i zaczynają nienawidzić swojej pracy.

Zapobiec temu, otwierając dla nich możliwości uczenia się gdzie indziej. Informuj ich na bieżąco o projektach i stosie technologicznym firmy oraz otwieraj nowe wyzwania. Jeśli ich zainteresowanie leży w zakresie projektu, otrzymujesz podwójną nagrodę w postaci stawiania wyzwań Twojemu zespołowi i jednoczesnego poszerzania przydatnych umiejętności zespołowych. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!