Rozumiem presję harmonogramu. Chcesz zadowolić swoich użytkowników, ponieważ są siłą napędową firmy. Prawdą jest jednak również to, że pewne zmiany ułatwią wszystko w drodze. Niestety, zarządzanie w mojej organizacji ma instynktowny opór wobec takich zmian, a ten opór jest tak silny, że przeszkadza w długoterminowej poprawie.

Na przykład firma Apple niedawno wprowadziła automatyczne zliczanie referencji dla programów na iOS. Jest to znacząca poprawa w stosunku do ręcznych wywołań zatrzymania / zwolnienia, z których wcześniej korzystano. Kod jest łatwiejszy do napisania i łatwiejszy w utrzymaniu. Sama wymiana prawdopodobnie spowoduje pewne awarie. Ale kiedy zostaną one opracowane, liczba przypadkowych dziwnych awarii prawdopodobnie spadnie.

Niedawno wspomniałem mojemu szefowi, że chcę przejść na automatyczne liczenie referencji. Jego odpowiedzią było to, że chciał skoncentrować się na widocznych ulepszeniach. Jest prawdopodobne, że ta reakcja była z kolei spowodowana presją, którą wywiera z góry - i prawdopodobnie bezpośrednio od CEO.

Istnieje wiele podobnych przykładów. Wspólnym wątkiem jest to, że coś musi zostać naprawione, ale krótkoterminowe koszty poprawki przeważają nad korzyściami krótkoterminowymi, gdzie „krótkoterminowy” jest definiowany jako „w ciągu najbliższych kilku tygodni”.

Jak mam poradzić sobie z sytuacją?

EDYCJA: Dziękuję za odpowiedzi. Nadal je nadchodzą. Ponieważ ma to związek z moją sytuacją, powinienem wyjaśnić, że zarówno mój menedżer, jak i CEO są programistami - chociaż CEO może już zapomniał, jak to jest. Najwyraźniej ich strony programistów zostały przytłoczone innymi naciskami.

Naprawdę mówisz o długu technicznym. Może metafora pomogłaby twoim menedżerom. Często porównuję efekt długu technicznego w oprogramowaniu do gotowania w brudnej kuchni. Jeśli zlew, blaty i piec są ułożone w brudnych naczyniach, a na podłodze znajdują się śmieci, przygotowanie posiłku trwa dłużej. Jednak najszybszym sposobem przygotowania następnego posiłku jest obejście bałaganu. Sprzątanie kuchni i utrzymywanie jej w czystości opóźni następny posiłek, ale poprawi dostarczanie wszystkich kolejnych posiłków. I tak jak głodna osoba w jadalni nie widzi brudnej kuchni i nie zrozumie, dlaczego chcesz posprzątać przed rozpoczęciem gotowania, twoje kierownictwo nie widzi bałaganu w kodzie. Musisz pokazać im bałagan lub pokazać problemy z jakością i opóźnienia spowodowane przez bałagan.

Być może możesz porozmawiać o pilnych zadaniach i ważnych zadaniach. Gdy ważne zadania nie są wykonywane, pilne zadania trwają dłużej i kosztują więcej.

Natknąłeś się na coś, co nęka programistów na całym świecie w pewnym momencie ich kariery: ten kod musi zostać odnowiony, są tam problemy architektoniczne, ten moduł staje się nie do utrzymania, itp. Jednak ze względu na obecną kulturę twojej organizacji, jesteś zmuszany do skupienia się na pracy, która przynosi jedynie bezpośrednio widoczne korzyści.

To znów klasyczny Iceberg Secret . Tajemnicą ma do czynienia z faktem, że tak jak góra lodowa jest 90% wodą, tak aby to większość dowolnego projektu rozwoju: 90% pracy będzie całkowicie niewidoczny dla użytkownika końcowego. Ten kod będzie miał wpływ na użytkownika końcowego, ale kierownictwo ma problem z ustaleniem, dlaczego spędziłeś sześć godzin na refaktoryzacji konserwacji / wydania i automatycznych odwołań, gdy nie widzą żadnej różnicy i wszystko działa dobrze.

Oto kilka faktów, które możesz zabrać ze sobą w tej sprawie.

• Kierownictwo, chyba że sami są programistami , nie zrozumie Sekretu Góry Lodowej.
• Jest to problem ignorancji, a nie złośliwości. Prezes chce dobrego produktu - po prostu nie rozumie wszystkiego, co wchodzi w dobry produkt.
• Dyrektor naczelny (i twój bezpośredni szef) nie są głupi - przestudiuj i przygotuj kilka faktów i konkretnych danych na temat tego , dlaczego powinieneś spędzać czas nad tym, a także na innych problemach Góry Lodowej.

Nie zapomnij - jesteś mężczyzną (lub kobietą) w firmie. Nie człowiek kodowy. Opracowujesz ten produkt dla firmy, która jest żywo zainteresowana jego sukcesem lub porażką - twoje projekty i propozycje projektów powinny to odzwierciedlać. Pokaż swoją pasję do firmy i produktu, pokaż swoją wiedzę i udowodnij swojemu szefowi i dyrektorowi generalnemu, że powinni ci zaufać, kiedy do nich przyjdziesz i powiedzieć, że coś wymaga pracy. Pokaż im, w jaki sposób wpłynie to na wynik końcowy - czy to poprzez zwiększenie wartości produktu (więcej osób kupuje kopie), czy oszczędność czasu w drodze (mniej gniewnych klientów, gdy twój produkt zawiedzie).

Ty nie.

Widzę to pytanie i wszystkie podobne pytania jako trochę ślepy zaułek. Nie możesz „przekonać” ludzi do niczego. Jeśli nie są jeszcze świadomi takich rzeczy lub nie badają tego, istnieje szansa, że ​​się nie wywrócą. Żadna ilość danych nie przekona ich inaczej. Zmiana musi nadejść od wewnątrz. Możesz doprowadzić konia do wody, ale nie możesz zmusić go do picia.

Mówię upiec pożądane zmiany w swoich następnych szacunkach technicznych. Bądźmy, hej, musimy „uaktualnić” ten nowy framework wprowadzony przez Apple. Nie pozwól, aby nie korzystasz z ARC na mapie drogowej. Brak opcji; migracja do ARC jest jedynym sposobem.

Odpowiedziałem już na podobne pytanie tutaj, więc można to uznać za duplikat. Zasadniczo nie zamierzasz się wypisać, aby wykonać „wysiłek refaktoryzacji”. Sposób, w jaki kod jest czyszczony, polega na przestrzeganiu zasady harcerstwa: zawsze zostawiaj kod czyszczący, kiedy go opuszczasz, niż kiedy przybyłeś.

Podobnie jak spłata realnego długu może wydawać się zadaniem nie do pokonania (lub sprzątaniem bałaganu). Sztuczka polega na tym, aby uczynić ją lepszą kawałek po kawałku, dopóki nie zobaczysz „wysp czystości”. Kiedy już osiągniesz znaczący impet, inni programiści w zespole zaczną zauważać i ostatecznie przyczyniać się do zadania.

Proponuję przeczytać „ Czysty koder ” autorstwa „Wujka” Boba Martina. Pisanie dobrego kodu jest częścią twojej pracy. Nie pytasz o pozwolenie na wykonywanie swojej pracy, po prostu to robisz.

Podobnie jak w przypadku innych tego rodzaju pytań, musisz podać liczby zrozumiałe dla kierownictwa. Liczby, które pokazują, ile czasu można zaoszczędzić dzięki wdrożeniu tych ulepszeń, ile mniej „przypadkowych dziwnych awarii” wystąpi itp. Przekonaj ich, że awarie są widoczne dla użytkownika końcowego i że wszystko, co można zrobić, aby temu zapobiec, jest dobre dla biznesu.

Możesz także spróbować wdrożyć te ulepszenia we własnym czasie (tj. Poza godzinami pracy), a następnie pokazać korzyści zarządowi. Zrobiłbym to tylko wtedy, gdy jest jasne, że kierownictwo nie rozumie, co próbujesz przekazać i / lub że nie chcą przeznaczyć Ci czasu na podjęcie próby.

Powodzenia!

Przedstaw uzasadnienie biznesowe

Istnieje wiele powodów, dla których rekomendacje inżynierów często są ignorowane. Najlepszym sposobem radzenia sobie z prawie wszystkimi przyczynami jest przedstawienie biznesowego uzasadnienia, dlaczego należy to zrobić. Klasyczna analiza kosztów i korzyści. Jest to nie tylko przekonujący argument, ale także daje szefom coś, co można zabrać do swoich przełożonych.

• Jaki jest koszt początkowy?
• Jaki jest bieżący koszt?
• Jakie są przewidywane oszczędności pieniędzy / czasu i skąd one pochodzą?
• Jak długo potrwa, zanim zobaczymy ROI?

W przypadku uzasadnienia biznesowego zawsze należy wykonać kopię zapasową argumentu przy użyciu danych.

• Ile czasu obecnie zajmuje rozwój oprogramowania na rozwiązywanie problemów, które to usunie lub złagodzi?
• Ile skarg użytkowników dotyczy problemów, które to usunie lub złagodzi?
• Jakie inne korzyści to przyniesie?

Wyrównaj liczby i zrób szorstkie, ale proste równanie. Będzie to kosztować X i przyniesie korzyść firmie Y.

Uwaga: nie zdziw się, jeśli wdrożenie naukowo dobrego pomysłu jest zbyt drogie.

Tego rodzaju zmiana należy do kategorii refaktoryzacji. Podejście zwinne polega na tym, że powinieneś uwzględniać czas refaktoryzacji AMPLE w każdej szacowanej historii i właśnie dlatego. Oprócz inżynierów nikt nie zrozumie, dlaczego chcesz to zrobić, i to w porządku, NIE ICH ustalenie, jak poprawnie kodować, to twoje.

Więc następnym razem, gdy będziesz mieć dużo pracy do zrobienia, upewnij się, że te zmiany są jej częścią. Jeśli podajesz szacunki, pamiętaj o dodaniu 30% do oszacowania w celu refaktoryzacji, jeśli nie podajesz szacunków, po prostu przeprowadź refaktoryzację w ramach swojej pracy.

Może spowolnić - cóż, nie, to nie jest tak na to patrzeć, sposób na to, że twoja obecna prędkość jest iluzją, w gruncie rzeczy kłamstwem, że omijasz łańcuch, właściwie powinieneś być trochę wolniej z powodu tej pracy, o której wiesz, że należy ją wykonać.

Prawdopodobnie mógłbyś budować domy szybciej, gdyby nie używał betonu jako fundamentu - i wyglądałyby tak dobrze dla klienta, ale - cóż - Nawet jeśli klient nie widzi potrzeby fundamentu, budowniczy musi. (Jest to w rzeczywistości interesująca paralela, ponieważ okazuje się, że twórcy nie zawsze robią to, co wiedzą, że powinni to zrobić, więc musimy uchwalić prawa, aby je zmusić - nie ma takich praw rządzących programowaniem, mimo że mamy do czynienia z tym samym decyzje i często podejmują niewłaściwe ...)

Wspominasz, że masz szczęście, że zarówno twój menedżer, jak i dyrektor generalny są programistami. Prawdopodobnie więc rozumieją, czym jest dług techniczny.

Trzeba poradzić sobie z sytuacją, starając się rozwiązać sytuację opartą na faktach, co oznacza, istnieje realna możliwość, że nie będzie skończyć dokonywania ulepszeń technicznych, które chcesz (fakty mogą być irytujące, że sposób).

Twoim zadaniem jest upewnienie się, że rozumieją koszty i korzyści spłaty jakiegokolwiek konkretnego długu technicznego, który zaciągniesz. Ich zadaniem jest decydowanie, czy najlepsze wykorzystanie zasobów polega na spłacaniu lub robieniu czegoś innego.

Tak jak może być trudne dla osób nieuczestniczących w kodzie, aby zobaczyć korzyści płynące z ulepszenia „ukrytych” rzeczy, tak samo może być ciężko programiście dostrzec korzyści z widocznych zmian w kodzie, gdy korzyści te w pewnym stopniu pojawią się w obszarach biznesowych ” ukryty ”przed programistami.

Fajnie, jeśli kierownictwo może wyjaśnić ci, dlaczego widoczne funkcje są bardziej warte twojego czasu niż spłacenie długu technicznego, ale tak naprawdę to nie twoja decyzja i tak jest. Więc wyjaśnienie tego nie robi wiele dla biznesu, poza tym, że cię uszczęśliwia. W pewnym sensie, naleganie, aby to zrobili, nie oznacza ufania im, że wykonają swoją pracę. Jeśli nie podoba ci się, gdy mikro-zarządzają tobą, powinieneś to zrozumieć.

Tak długo, jak będziesz informować ich o statusie całego długu technicznego oraz o kosztach i korzyściach zignorowania go w porównaniu do spłaty, wykonałeś swoją pracę. Chyba że tak naprawdę nie ufasz kierownictwu, że zrobi swoje, w takim przypadku masz znacznie większy problem, który byłby zupełnie innym pytaniem do rozwiązania.

Może to nie jest odpowiedź, ale odpowiedź na podstawie błędów, które popełniłem. Również brak zgody na niektóre z filozofii, które tu czytam.

• Nie daj się zwieść przekonaniu, że programista wie najlepiej.
• Bądź szczery. Ponownie uwzględniaj czynniki w miarę postępów, ale nie kłam i nie oceniaj szacunków dla własnych celów.
• Nie jesteś właścicielem kodu. Nie podejmuj pracy, która nie jest zatwierdzona przez prowadzącego.
• Możesz mieć rację w czymś; możesz się mylić ... ale powinieneś robić to, za co płacisz.

Ale z pewnością postępuj zgodnie ze wspaniałymi radami dotyczącymi poprawy.

Oczywiście pracujesz dla spiczastego włosa szefa (PHB). Nie programuje już, jeśli w ogóle, a jeśli to zrobił, prawdopodobnie nie byłby naprawdę dobry (chociaż lubi wpuszczać frazy takie jak „ciągła poprawność” i „błąd segmentacji”, aby faceci wiedzieli, że zasłużył na swoje paski. ) - tak został wyróżniony do zarządzania.

CEO (który praktycznie ma Mohawk) lubi PHB, ponieważ PHB zapewnia funkcje . Podczas każdego sprintu z dumą pokazuje nowe pole wyboru (nieco źle wyrównane, z niejednoznaczną etykietą), błyszczącą ikonę (jeszcze nie działającą w żadnym środowisku, ale 8-bitowym kolorze w stosunku do Citrix) i formę (która ma losowe awarie z powodu warunków wyścigowych w specjalnie opracowanym wariancie xml C zaimplementowała lokalną bazę danych, której nikt w zespole deweloperów nie odważył się dotknąć, ponieważ została napisana przez jedną ze starych legend deweloperów straży 10 lat temu i robi WSZYSTKO z makrami o 5 literach, bez względu na to, czy potrzebowały 5 liter nie).

Programiści, którzy rzeczywiście to jest „trochę pracy” (wiesz, że trochę tak się dzieje, niewygodnie przecież prawdziwej pracy jak rysowanie okręgów na tablicach, krzycząc i jedzenia miniaturowe Battenburgs odbywa) wie, że w sane systemu pracy, który właśnie wziął 10 facetów 10 dni żmudnego włamania się z nieobsługiwanej dżungli, prawdopodobnie wynosiłoby jeden lub dwa dni robocze, łącznie z testowaniem. Ale uzyskanie systemu z rozsądnego poziomu może zająć 6 miesięcy naprawdę ciężkiej pracy, przy niewielkim nakładzie oczywistej nagrody zewnętrznej.

PHB wie, że w ciągu 6 miesięcy, hakiem lub oszustem, może wprowadzić trzydzieści lub czterdzieści nowych funkcji do aplikacji, które mogą być używane przez sprzedawców (którzy muszą być magikami, biorąc pod uwagę to, co faktycznie sprzedają), aby kusić nowe zakupy i ulepszenia .

Jednak, aby przekazać PHB swoje zobowiązania: bez tych pól wyboru i formularzy sprzedaż może stagnować lub spadać, konkurent może zyskać udział w rynku, a to może być gorsze niż alternatywa.

Doszedłem do wniosku, że jedynym wyjściem z bagna jest praca w nowym przedsiębiorstwie z kilkoma osobami, które podzielają twoją wizję tego, jak należy tworzyć oprogramowanie, a następnie uparcie trzymają się tej filozofii (I Nadal pracuję nad tym, aby się tam dostać!)

Istnieje inny ukryty koszt, który nie został wymieniony w innych odpowiedziach. Mianowicie, że dobrzy inżynierowie zwykle odchodzą w opisywanym środowisku. W końcu każdy, kto ma ambicję lub zdolność do refaktoryzacji, opuścił firmę, a wtedy sytuacja będzie bardzo zła, prawdopodobnie niemożliwa do naprawienia. Niestety nie możesz powiedzieć o tym swojemu menedżerowi, nie będąc aroganckim („jestem jednym z twoich najlepszych programistów”) i natrętnym palantem („Odejdę, jeśli nie zrobisz tego, co chcę”). Pamiętaj jednak, aby wspomnieć o tym w wywiadzie wyjazdowym, aby mieć pewność, że nie uzyskasz statusu ponownego zatrudnienia.

Masz zarówno rację, jak i oboje się mylicie, dlatego te problemy długo się utrzymują i wywołują silne uczucia.

Powody, dla których wyraźnie podano powyżej: kierownictwo myśli w pieniądzu; a dokładniej: przychody. Dla nich coś, co ma koszt, ale nie jest widoczne bezpośrednio dla klienta, nie zwiększa przychodów, więc jest to zły plan.

Twoja wizja jest również właściwa: będzie dobra dla klientów, ale w dłuższej perspektywie. Twoje działania mogą w przyszłości wygenerować jeszcze większy przychód w porównaniu z planami krótkoterminowymi.

Nie jesteś menadżerem, nie jesteś bezpośrednio odpowiedzialny za przychody (zakładam oczywiście). Więc mieszasz (tak to czuje się z zarządzaniem) z ich problemami i nie koncentrujesz się na swojej pracy: dalsze rozszerzanie oprogramowania.

Wszystkie twarde, jasne słowa, ale tak powstaje większość problemów z powodu błędów w komunikacji. Oboje chcąście tego samego, ale wasze krótkoterminowe decyzje podejmowane są inaczej. Wszystko dlatego, że programista ma inne perspektywy niż menedżer.

Jak rozwiązać ten problem? Komunikujesz się i rozumiesz całkiem dobrze w wielu kwestiach. Najprawdopodobniej skupi się to na zaangażowaniu i satysfakcji klienta.

Aby rozwiązać ten problem w stabilnej i przyszłej metodzie sprawdzania, zgódź się na kilka rzeczy: zmierz koszt naprawy błędów w starym kodzie. Zmierz czas potrzebny dodatkowo na pracę ze starym oprogramowaniem i jak by to było z nową bazą kodu.

Aby to udowodnić, możesz na przykład zrobić to dość proste: rozgałęzić oprogramowanie w swojej wersji. Najpierw zrób to, czego chce zarząd, więc utwórz tę funkcję. Robisz to, ale zgadzasz się, że masz czas, aby pokazać inną drogę. Następnie zrób to samo w nowym oddziale, ale najpierw napraw problemy, które chcesz się pozbyć. Następnie opracuj rozwiązanie.

Teraz masz to samo rozwiązanie, ale całkowicie opracowane inaczej. Utwórz z niego skrzynkę, umieść obok siebie rozwiązania, w tym informacje zarządcze, takie jak stabilność, potrzebna ilość kodu i sam kod.

Teraz weźcie razem kawę i zacznijcie rozglądać się, nie zastanawiając się, kto ma rację, ale jaki wpływ będą miały obie strony dla firmy. To stworzy spotkanie, które będzie naprawdę przydatne, a nie gorszą dyskusję, ponieważ nie stworzy atmosfery, której oboje będziecie potrzebować. To nie poprawi twojego produktu.

Jeśli masz recenzję kodu, utwórz zgłoszenie techniczne stwierdzające, że kod powinien zostać ulepszony za pomocą ARC i przypisany do menedżera.

Przekonaj go. Wyjaśnij mu kilka małych przykładów podobnych ulepszeń technicznych, które zrobiłeś i jakie są korzyści dla projektów.

Musisz sprzedać te zmiany tylko w taki sposób, w jaki kierownictwo jest skłonne kupić:

Znajdź funkcję skierowaną do użytkownika, która jest tak atrakcyjna, że ​​musi ją mieć tylko zarząd, ale nie można jej obejść bez ulepszeń kodu na niskim poziomie.

Zadaniem szefa jest upewnienie się, że firma koncentruje rozwój na dostarczaniu tego, co klienci postrzegają jako wartość dodaną. Istnieją dwa czynniki, które mogą zmienić to postrzeganie:

1. Jak długo trwa realizacja zamówienia klienta?
2. Czy dostarczasz, kiedy mówisz, że to zrobisz?

Większość wolałaby raczej powiedzieć, że zajmie to 6 tygodni i dostarczy za 5, niż powie, że dostarczysz za 3, ale weź 4.

Posiadanie aktualnej bazy kodu, która jest łatwiejsza w zarządzaniu i ulepszaniu, pozwala szybciej dostarczać i zwiększać przewidywalność. Jeśli spędzasz zbyt dużo czasu na naprawianiu błędów, masz mniej dostępnych zasobów, aby dodać nowe funkcje. Oceń ilość zasobów wydanych na naprawę kodu i dokładność obietnic funkcji. To jeden ze sposobów ustalenia, czy Twój obecny kod (zgodnie z filozofią szefa) kosztuje zbyt wiele.

Pozwól, że powiem ci o możliwości 2 miliardów dolarów, która prawie wymknęła się nam z rąk z powodu bezwładności kierownictwa.

Niektórzy z nas słuchają głosu klienta, co oznacza zrozumienie tego, czego chce. Nie zawsze o to prosi, ale jeśli jesteś w stanie rozmawiać z klientem, w końcu dochodzi do wzajemnego zrozumienia tego, czego chce. (Wtedy może wyraźnie zacząć o to prosić).

Biorąc to pod uwagę, ważne jest, aby zrozumieć, kto powinien prowadzić tę rozmowę z klientem. Zazwyczaj robią to twoi ludzie zajmujący się rozwojem biznesu wraz z kilkoma głównymi projektantami. Jeśli masz jakąkolwiek konkurencję, możesz spodziewać się, że klient również z tobą rozmawia.

Jednocześnie ważne jest, aby programiści byli na bieżąco w swoich dziedzinach, ponieważ będzie konkurencja, która pokona cię, jeśli nie będziesz.

W naszej sytuacji mieliśmy istniejącego klienta i dość skuteczny produkt oparty na starej technologii, a klient potrzebował szybkich aktualizacji. To, czego naprawdę potrzebowali, to kompletny produkt zastępczy, ale myślenie w naszej firmie było takie, że natychmiast zmusiłoby nas to do uzyskania pozycji konkurencyjnej, podczas gdy modyfikacja istniejącego produktu pozwoliła naszemu klientowi na kontynuowanie współpracy z nami, nie będąc prawnie zobowiązanym do uczynienia go konkurencyjnym. Nasze kierownictwo myślało, że jest właścicielem tego rynku. Problem polegał na tym, że nie mogli nadążyć za żądaniami aktualizacji, ponieważ istniejąca struktura produktu nie była wystarczająco elastyczna, aby ją zaktualizować.

Klient stał się niecierpliwy i zaczął rozmawiać z konkurencyjnymi źródłami. Straciliśmy naszą „własność” tego rynku i kilka miliardów dolarów przychodów. Jednak gdy rynek zmusił nas do uzyskania pozycji konkurencyjnej, kierownictwo nie miało innego wyboru, jak wyjść z działalności lub konkurować. (Większość tych, którzy byli blokadami dróg, w końcu zostali zwolnieni). Wzięliśmy udział w rywalizacji i udało nam się odzyskać biznes najcieńszym wątkiem.

Na początku powiedziałem, że ta okazja prawie wymknęła się nam z rąk. Odzyskaliśmy biznes za wspomniane dochody. Gdybyśmy byli bardziej przygotowani do dostosowania się do obaw klienta na początku, nie byłoby prawdziwej konkurencji.

Oferowane przeze mnie jedzenie na wynos jest następujące: zawsze staraj się być liderem w swoich osobistych możliwościach. Zawsze opracowuj elastyczny produkt, który można szybko dostosować do potrzeb klienta. Jeśli pracujesz zbyt długo dla firmy, która nie myśli w ten sposób, uschnie, a twoja osobista motywacja zmniejszy się. Widziałem, jak to się dzieje.

Jeśli masz pomysł na ulepszenie produktu z jakiegokolwiek powodu, zadaj sobie następujące pytania: - Czy moim zdaniem tego właśnie chce klient? Czy mogę zweryfikować swoje przemyślenia na temat rozwoju produktu wbrew głosowi klienta? Czy moja firma jest w stanie zaspokoić potrzeby klientów? Jeśli tak to jak? - Powinieneś być w stanie przekonująco przedstawić swoje propozycje rozwoju produktu.

Wspólnym językiem biznesu we wszystkich dziedzinach i branżach są pieniądze. Opisany problem nie jest problemem programistycznym: jest to problem biznesowy. Jeśli chcesz uzyskać odpowiednią odpowiedź na propozycję biznesową, musisz sformułować ją w języku biznesowym. Oznacza to, że musisz być w stanie przedstawić alternatywny plan projektu obejmujący wszystkie koszty i korzyści.

Musisz dowiedzieć się o takich rzeczach, jak koszty alternatywne, ROI (zwrot z inwestycji) i NPV (wartość bieżąca netto). Nie potrzebujesz MBA, aby to zrobić, ale potrzebujesz dostępu do danych, które mogą być dla Ciebie niedostępne, takich jak koszty siły roboczej, koszty ogólne i potencjał przychodów. Jeśli potrafisz podać wyraźny argument, że jedna ścieżka zapewni większą wartość niż inna przy użyciu twardych liczb, uzyskasz pełną uwagę kierownictwa.

Kiedy byłem nowszym programistą w bardzo małym zespole, dużo poprawiłem w wolnym czasie. Podobało mi się; Logowałem się i testowałem ciekawe nowe techniki, siedząc w salonie z żoną w nocy. Gdy stałem się starszym programistą, a następnie kierownikiem większego zespołu, mój wolny czas zniknął. Pracowaliśmy dodatkowe godziny tylko po to, aby wykonać funkcje i poprawki krytyczne. Naprawdę trudno było usprawiedliwić spędzanie czasu na regularnych pracach domowych, chociaż wszyscy wiedzieliśmy, jak ważne jest to zadanie.

Twoi szefowie nie potrzebują wyjaśnienia, jak ważne jest utrzymanie kosztów utrzymania na niskim poziomie, zmniejszenie kosztów przyszłego wzrostu, utrzymanie zaangażowania utalentowanego zespołu programistów itp. Jeśli tak, masz duże problemy. Mogą jednak potrzebować planu. Ponieważ w tej chwili zgaduję, że mają oni wszelkiego rodzaju plany, harmonogramy, mapy drogowe, obietnice i presję po stronie „dodaj funkcjonalność”, które konkurują ze zwykłym pobożnym życzeniem i otwartymi prośbami zespołu programistów.

Jedną z rzeczy, które możesz wypróbować, jest stworzenie udokumentowanego planu. Sprawdź, czy możesz powiązać go z wydaniami lub wyjść z kryteriów nowej funkcjonalności. Prośba o „spędzenie czasu na ponownym liczeniu referencji” może być trudna do zaakceptowania przez szefa, ale zaplanowanie bloku na 5 dni za 4 tygodnie może być łatwiejsze. Zasadniczo jednak widzisz, że nowe funkcje są planowane i planowane, spróbuj naśladować to lub wstrzyknąć do niej część „pod maską”.

Zacznij od małego, prosząc o 5% czasu przeznaczonego na tego rodzaju rzeczy, a następnie stopniowo buduj własne priorytety planu technologicznego i staraj się usprawiedliwiać uzasadnienie biznesowe, ROI, poziomy ryzyka itp. Na każdym z nich. Już wkrótce poznasz wyzwania swoich szefów, ponieważ szybko znajdziesz o wiele więcej świetnych pomysłów niż masz czas.

Powodzenia!

Oto dlaczego twoja prośba o automatyczne zliczanie referencji jest odrzucana:

1. To nie jest poprawa . Gdy masz już coś większego niż witaj świecie, każda zmiana zmierza w złym kierunku. Żadna ilość refaktoryzacji nie zmieni faktu, że jeśli musisz wprowadzić zmiany, zawsze będzie to w złym kierunku. Sztuką jest wiedzieć, kiedy zmiany są na tyle znaczące, że nadal warto ryzykować spowodowanie nowych problemów. Twoje kierownictwo wyraźnie stwierdziło, że jeśli użytkownicy końcowi go nie widzą, nie warto ryzykować.
2. Liczenie referencji jest całkowicie szaloną funkcją. Zauważyłeś, że jakaś istniejąca duża znana firma wdraża jakąś funkcję i od razu pomyślałeś, że potrzebujesz tej samej funkcji. Cóż, jest bardzo prawdopodobne, że twoja baza kodu całkowicie różni się od tego, z czego korzysta jabłko. Prawdopodobnie liczenie referencji nie zadziała lub to tylko strata czasu. Powinieneś znaleźć inny sposób, który nie wymaga rozprzestrzeniania prymitywów liczenia referencji w całym kodzie. Prawdopodobnie Twój plan przeliczania wymaga tysięcy modyfikacji w bazie kodu, większość tych zmian nie jest konieczna. Po prostu strata czasu i pieniędzy.
3. Rozwiązujesz zły problem. Kierownictwo zazwyczaj wie, jakie problemy występują w systemie. Niektóre nieistotne problemy z wyciekiem pamięci, które rozwiązuje rozwiązanie zliczania, nie są jednym z nich. Skoncentruj się na prawdziwych problemach, a nie na wyimaginowanych problemach z obsługą pamięci przez komputery.
4. Jego wdrożenie zajmuje zbyt dużo czasu. Apple jest nieco większą firmą niż niewielki zespół z kilkoma programistami i niektórymi menedżerami. Mogą dokonać dużych zmian, płacąc tylko cenę. Jeśli wdrożenie czegoś zajmie kilka milionów, są to orzeszki ziemne. Jeśli małe firmy spróbują zrobić to samo, szybko zabraknie im pieniędzy. Tworzenie oprogramowania jest już bardzo kosztowne; dodanie niepotrzebnych kosztów nie pomoże ani trochę. Jedną z nieistotnych funkcji, takich jak zarządzanie pamięcią, jest otwarcie zalewu: po ich zatwierdzeniu połowa programistów chce, aby wdrożono własne „ulepszenie”. To niekończąca się historia, a firma może zamiast tego robić coś pożytecznego.

Oto kilka kroków, które możesz wykonać, aby rozwiązać problem:

1. Upuść funkcję
2. Dowiedz się, jaki jest prawdziwy problem
3. Zacznij robić coś pożytecznego
4. Starannie zaplanuj, jak wykorzystasz swój czas
5. Dowiedz się, jak Twoje ulepszenia przynoszą pieniądze
6. Wybierz tylko te funkcje, które przynoszą najwięcej pieniędzy
7. Uświadom sobie, że programistyczny aspekt tworzenia oprogramowania to tylko niewielka część całego systemu - ulepszenia nigdy nie będą warte czasu