Sprowadza się to do tego, co zacząłem myśleć o „Wiecznym konflikcie” (między biznesem a inżynierią). Nie mam rozwiązania, ponieważ jest to problem, który nigdy nie ustępuje, ale możesz robić rzeczy, które pomogą złagodzić.
Ludzie często nie zdają sobie sprawy, że jako inżynierowie zakładamy, że problem „udanego biznesu” jest zawsze podany. Chcemy, aby nasz kod był ładny, schludny i łatwy w utrzymaniu, abyśmy mogli szybko dodawać nowe funkcje i poprawiać istniejące, przy minimalnej liczbie klientów wykonujących dla nas kontrolę jakości, odkrywając dziwaczne przypadki, które zostałyby udaremnione przez lepszy kod. Utrzymywanie klientów i utrzymywanie przewagi konkurencyjnej dzięki funkcjom i finezji, których nikt inny nie jest w stanie wyprodukować wystarczająco szybko, to zarówno wygrane biznesowe, do których dobry kod bezpośrednio przyczynia się i informuje wiele z powodów, dla których chcemy przede wszystkim lepszego kodu.
Więc przeliteruj to. „Chcemy wykonać X w naszej bazie kodu, ponieważ jeśli tego nie zrobimy, wpłynie to negatywnie na biznes z powodu Y” lub „… ponieważ zwiększy naszą zdolność do pozostania konkurencyjnym poprzez poprawę naszej zdolności do szybszego wprowadzania nowych ulepszeń i funkcji . ”
I staraj się uzyskać namacalne dowody na to, że udoskonalenia działają. Jeśli ulepszenie jakiegoś podzbioru aplikacji spowodowało szybsze działanie / ulepszenie, sprawdź, jakie narzędzie zaległości, którego możesz użyć, jest tego dowodem i wskaż je na odpowiednich spotkaniach.
- Umieść zespół na tej samej przeklętej stronie
Ego są często problemem. Jedną rzeczą, której zespoły inżynierskie bardzo potrzebują, jest ustalenie wartości uzgodnionego spójnego podejścia do rozwiązywania określonych rodzajów problemów w stosunku do każdego, kto robi swój własny puchar Kool Aid d'jour, ponieważ wiedzą lepiej. Można wierzyć, że preferencje drugiego faceta są gorsze niż twoje, ale cenisz sobie konsekwencję w stosunku do bycia bardziej właściwym, jeśli jego podejście jest wykonalne i jest to argument, którego nie możesz wygrać. Kompromis ze względu na spójność jest kluczem. Kiedy rzeczy są spójne, trudniej jest je zrobić źle, ponieważ konsekwentnie ustalony sposób będzie zwykle najszybszy.
- Wybierz odpowiednie narzędzia
Istnieją dwie szkoły frameworków / zestawów narzędzi / bibliotek / cokolwiek innego. „Ustaw dla mnie 99%, więc muszę wiedzieć / robić bardzo mało” vs. stosować raczej na zasadzie marchewki niż na patyczku. ” Sprzyjaj drugiemu. Elastyczności i szczegółowej kontroli nigdy nie należy poświęcać przy ołtarzu szybkiego zwrotu, ponieważ dziwne: „nie możemy tego zrobić, ponieważ nasze własne narzędzia nam na to nie pozwolą”, nigdy nie jest akceptowalną odpowiedzią, a pytanie zawsze będzie wymyślić trywialna / jednorazowa inżynieria produktu. Z mojego doświadczenia wynika, że nieelastyczne narzędzia prawie zawsze są rozwalane na oścież lub pracują nieelegancko i robią wielkiego giganta, którego nie da się utrzymać. Częściej niż nie elastyczne / łatwiejsze do modyfikacji rozwiązania są tak samo lub bardzo szybkie w krótkim okresie, niezależnie od tego. Szybkie, elastyczne i łatwe w utrzymaniu są możliwe dzięki odpowiednim narzędziom.
- FFS, jeśli inżynierowie nie podejmują decyzji, przynajmniej uzyskaj wkład inżyniera w wybór narzędzi
Wydaje mi się, że jest to pytanie z perspektywy programisty, ale byłem w zbyt wielu sytuacjach, w których decyzje technologiczne były podejmowane przy zerowym wkładzie inżyniera. Co to do diabła jest? Tak, ktoś ostatecznie musi zadzwonić, ale uzyskać kwalifikowane opinie, jeśli jesteś nietechnicznym menedżerem, a nie to, co mówi sprzedawca lub strona demonstracyjna na temat własnych produktów. Wszystko, co obiecuje zaoszczędzić ci pieniądze, ponieważ ludzie nie muszą być tak mądrzy lub dlatego, że chroni programistów przed sobą, jest brudnym, brudnym kłamstwem. Zatrudnij talent, któremu możesz zaufać. Powiedz im, co chcesz ze stosu lub innego rozwiązania technologicznego, i poważnie podejmij ich uwagi, zanim zdecydujesz, na który modowy pas technologiczny wskoczyć.
- Skoncentruj się na projektowaniu a wdrażaniu
Narzędzia są do wdrożenia i jako takie mogą ci pomóc, ale priorytetem musi być architektura bez względu na zestaw zabawek, które masz do budowania tej architektury. Pod koniec dnia KISS i DRY oraz wszystkie doskonałe filozofie, które wywodzą się z tych kwestii, są ważniejsze niż to, czy jest to .NET czy Java, a może coś, co jest zarówno wolne, jak i nie jest do bani.
Kiedy strona dziwna nalega, abyś zrobił to źle, zapisz ten e-mail, szczególnie w tej części, w której powiedziałeś, dlaczego to cię kosztuje. Kiedy wszystkie twoje prognozy się sprawdzą i pojawią się poważne, szkodliwe dla biznesu problemy, wtedy masz mnóstwo argumentów za poważniejszym traktowaniem problemów inżynierów. Ale czas ostrożnie. W środku płonącego piekła jest zły czas na „tak ci powiedziałem” na temat przestrzegania kodu ogniowego. Wygaś ogień i przenieś swoją listę wcześniej ignorowanych obaw na retrospektywne spotkanie / rozmowę i staraj się skupiać na problemach technicznych wyrażonych i zignorowanych oraz rozumowaniu, które rozumiesz, dlaczego były ignorowane, a nie imiona i nazwiska rzeczywistych ludzi podejmowanie decyzji o zignorowaniu. Jesteś inżynierem Trzymaj się problemów, nie ludzi. „ Wyraziliśmy zaniepokojenie z powodu X, ponieważ baliśmy się, że doprowadzi to do problemów z Y. Powiedziano nam Z i żebyśmy się tym nie zajmowali. ”