PM decyduje się na zbyt skomplikowaną konfigurację, z którą nikt nie ma doświadczenia w [zamkniętym]

Niedawno rozpocząłem projekt, który nie wydawał się zbyt trudny do wykonania, koncepcja była dość prostą aplikacją, która musiała od czasu do czasu akceptować dane wejściowe (może 10 razy dziennie) i próbować wykonywać na nich pewne operacje i zbierać wszystkie wyniki na końcu. Ta aplikacja uzyskałaby wówczas front-portal internetowy, z którego klienci mogliby korzystać, aby zobaczyć wyniki, nie do końca rakietowe.

W tym celu początkowo korzystałem mądrze z wbudowanych bibliotek współbieżności Pythona ( ThreadPoolExecutor) i korzystałem z łatwej w obsłudze biblioteki dla interfejsu (wybrałem Flask, ponieważ jest łatwy dla początkujących oraz stosunkowo łatwy w utrzymaniu i testowaniu).

Gdy byliśmy w połowie projektu, szef rządu stwierdził, że zamiast wątków musieliśmy korzystać z możliwości kolejki wiadomości innych firm i wdrożyć równoważenie obciążenia, co ostatecznie się skończyło, że w końcu zaczęliśmy współpracować z Celery, Redis, RabbitMQ, Nginx, uWSGI oraz szereg innych dużych usług stron trzecich, z którymi nikt nie miał prawdziwego doświadczenia.

Ostatecznie doprowadziło to do powstania spaghetti kodu, nie dających się przetestować zadań (ze względu na złożoność bibliotek stron trzecich, łatanie kodu nawet nie działało) i wielu kłopotów, ponieważ nikt nawet nie wiedział, jaka jest wartość dodana tych usług .

Zanim powiesz „Tak, powinieneś korzystać z tych usług”, pamiętaj, że nikt nie wie, jak z nich korzystać, a nawet nie wie, co robią, oprócz wprowadzenia zaraźliwego kodu dotyczącego warunków rasowych.

Co mam z tym zrobić? W tym momencie powrót do tego, co mieliśmy, byłby po prostu zbyt kosztowny, a premier jest całkowicie uzależniony od korzystania z tych usług, nawet jeśli produkt końcowy jest obecnie gorszy niż na początku. Czy dyskusja z nim jest w ogóle przydatna? Czy proszę o więcej czasu? Lub trudna odpowiedź: czy jestem po prostu zbyt głupia dla mojej pracy?

Gdy byliśmy w połowie projektu, szef rządu stwierdził, że zamiast wątków musieliśmy korzystać z możliwości kolejki komunikatów innych firm i wdrożyć równoważenie obciążenia

To nie jest właściwe, aby premier „jednostronnie” stwierdził. Dwa powody:

1. Decyzje projektowe powinny być podejmowane przez zasoby techniczne i wyłącznie w odpowiedzi na NFR . Dlatego uprzejmie zapytaj swojego premiera, czy jest nowy NFR i czy możesz podać szczegółowe informacje.

2. Jeśli NFR jest wprowadzany w połowie projektu, prawdopodobnie należy to zrobić za pomocą kontroli zmian . Kontrola zmian jest bardzo ważna z punktu widzenia zarządzania; będzie to nie tylko wkład w twoje wymagania, ale także ważny wkład w przypadki testowe QA, podręcznik wdrażania i wsparcia operacji oraz (tutaj jest naprawdę ważna część) harmonogram PM . Jeśli nowy wymóg wprowadza więcej pracy, zespół programistów powinien mieć możliwość przekazania nowych prognoz rozwoju, a premier będzie musiał zdecydować, czy może żyć z nową datą, dodać więcej zasobów lub odeprzeć interesariusza, który wprowadził NFR.

Teraz, jeśli naprawdę istnieje naprawdę dobry NFR i nie można go obejść, może być również właściwe zażądanie nowych lub różnych zasobów, które są zaznajomione z wprowadzanymi technologiami, lub zażądanie budżetu szkoleniowego dla niektórych z istniejących zasoby. Jest więc także aspekt kosztowy .

Jeśli mówisz w języku PM - harmonogram i koszty - myślę, że uzyskasz większą przyczepność niż mówienie o tym, jak deweloperzy myślą o wynikowym projekcie. Te rzeczy mają realny wpływ.

Premier powinien wiedzieć lepiej niż wprowadzać takie rzeczy w locie bez zarządzania, kontroli i konsensusu. Jeśli po prostu tego nie rozumieją, może zaistnieć potrzeba eskalacji do zarządzania produktem lub zarządzania programem, ponieważ niepotrzebnie naraża jakość i harmonogram.

Głupotą byłoby pozwolić sobie na marsz śmierci .

Opisujesz, że straciłeś krytyczne odczucia. Nie ma poczucia kontroli i nie ma wyraźnego powrotu do niego.

Ostatnią rzeczą, którą powinieneś zrobić, to ciężko pracować, nie spuszczać głowy i spokojnie cierpieć, aż w końcu przyznają, że projekt jest skazany na niepowodzenie.

Powinieneś bardzo mocno przemyśleć to, czego masz prawo oczekiwać.

Jeśli chcą, abyś używał technologii, których nie rozumiesz, powinieneś spodziewać się czasu na ich naukę. Nie wstydź się tego, czego nie wiesz. Użyj swojej ignorancji jako pałki. Kiedy domagają się czegoś, zapytaj dlaczego. Nie akceptuj „ponieważ”. Nie akceptuj „nowoczesnych najlepszych praktyk”. Nie akceptuj „skalowalności” bez uzyskania rzeczywistych, sprawdzalnych oczekiwań.

Przez testowalne mam na myśli, że MUSZĄ powiedzieć, ile żądań dziennie / godzinę / minutę chcą, aby było w stanie wykonać. Wyjaśnij, że zamierzasz zbudować coś, aby ćwiczyć ten system zgodnie z tymi specyfikacjami.

W ten sposób możesz skorzystać z 30-dniowego bezpłatnego okresu próbnego, aby udowodnić, że najnowsza rzecz, którą chcą, jest tego warta lub jeśli lepiej trzymać się tego, co już wiesz.

Teraz pamiętaj. To nie są narzędzia, które wprowadziły plagi rasowe. Zrobiliście to. Musisz dowiedzieć się, JAK to zrobiłeś, aby móc to cofnąć.

I nie. Powrót do tego, co miałeś, nie jest zbyt kosztowny. Premier nie może mieć tego, czego chce, żądając tego. Musisz się wycofać, aż będziesz mógł efektywnie wykorzystać to, czego chce PM lub udowodnić, że nie jest to potrzebne projektowi.

Poważnie, samo poddanie się temu jest nieprofesjonalne i zabójcze dla projektu.

Byłem tu stary. Więcej niż raz. To sprawia, że ​​czujesz się głupio. To naprawdę nie to. Po prostu się zgubiłeś.

Porozmawiaj z premierem. Szczerze. Rozłóż to wszystko. Pokaż, że chcesz się uczyć, ale nie chcesz się zabierać na przejażdżkę. Nigdy nie projektuj ani nie koduj w oparciu o wiarę. Niech PM pokaże ci, jak robić, co chcą. Nie udawaj, że rozumiesz, kiedy tego nie rozumiesz. Nie mów, że to się skończy, kiedy to nie będzie. Jeśli chcesz wierzyć w coś, uwierz w siebie. Musisz być gotów powiedzieć NIE.

Jeśli to nie pomoże wypoleruj CV, ponieważ wkrótce będziesz go potrzebować. Tak, czy inaczej.

To naprawdę powinno być na miejscu pracy.stackexchange.com, ponieważ problemem nie jest tak naprawdę kwestia rozwoju oprogramowania, ale relacje w miejscu pracy.

Jeśli jesteś pewien, że twoje proste podejście zadziałałoby i przyniosło efekt pracy raczej szybko, to twój PM jest niszczącą siłą w twojej firmie, którą należy usunąć. Zastanów się, jak przenieść wiadomości na wyższy poziom: że Twój zespół ma proste, działające rozwiązanie, które poczyniło znaczne postępy, i z powodów, których nikt nie jest w stanie wyjaśnić swojemu PMowi, zmusił cię do próby rozwiązania bardziej złożonego, z wykorzystaniem wielu narzędzi, których nikt nie zna, nikt nie rozumie, nikt nie wie, czy są w ogóle przydatne, a ta niezgłębiona decyzja twojego premiera sprawiła ci wszystkie kłopoty i sprawiła, że ​​projekt się spóźniał i nie działał.

Nie znając kontekstu i strategii produktu realizowanej przez kierownictwo, trudno jest obiektywnie odpowiedzieć na twoje pytanie.

Oto kilka obiektywnych argumentów. Możliwe jednak, że nie jest to oczekiwane:

• „ Należy pamiętać, że nikt nie wie, jak korzystać z tych produktów jeszcze ”.
• Używanie tylko doskonale znanych narzędzi i technik zapewni wysoką wydajność. Ale znacznie ograniczy zdolność do innowacji. Na niektórych rynkach może to mieć fatalny wpływ na twój produkt. Na przykład prawie 30 lat temu zaproponowałem użycie systemu Windows 3.0 do opracowania nowej wersji produktu CAD, który odniósł sukces pod MS-DOS. Menedżer produktu sprzeciwił się temu, że nie było to sprawdzone środowisko, że byłoby zbyt skomplikowane i zbyt trudne do nauczenia dla zespołu, a zresztą „ Windows nigdy nie będzie głównym nurtem ” ... Pozwolę wam zgadnąć, że sukces jego produkt 2 lata później.
• To wszystko kwestia kosztów i korzyści. Koszt eksperymentów w porównaniu z korzyścią skalowalności i możliwości wdrożenia zapewnioną przez firmę zewnętrzną doświadczoną w przypadku dużych instalacji i dużego obciążenia pracą.
• Wady związane z dodaniem nowej technologii mogą zostać wygładzone dzięki odpowiedniemu szkoleniu lub wstępnemu wsparciu / coachingowi przez doświadczonego konsultanta.

Ostatecznie wybór ekonomiczny leży w gestii kierownika produktu. Omów z nim zalety i wady, aby upewnić się, że podejmie świadomą decyzję i nie lekceważy dodatkowej złożoności. A jeśli pozostanie na swoim torze, staraj się osiągnąć to, co najlepsze: nie masz nic do stracenia, aw najgorszym przypadku będziesz mieć nową technologię w swoim CV.

Istnieją dwa podejścia do bibliotek stron trzecich (i innych komponentów):

1. Użyj ich jak najwięcej
2. Użyj ich jak najmniej

Moje podejście to (2). Wygląda na to, że twoje podejście to (2), ale kierownik projektu lubi to podejście (1).

Istnieją trzy sposoby poradzenia sobie z tą sytuacją. Albo pozwalasz premierowi robić, co chce, próbujesz go przekonać, by zmienił podejście do bibliotek stron trzecich, albo głosujesz stopami i wybierasz inną pracę.

Jeśli chcesz przekonać premiera do zmiany podejścia, rozważ następujące argumenty:

• Czas na naukę. Każda zewnętrzna biblioteka wymaga czasu na naukę, w którym to czasie kompetentny programista może napisać pożądaną funkcjonalność, szczególnie jeśli wybrano ogromną bibliotekę tylko po to, aby zrobić bardzo prostą rzecz, którą można wykonać za pomocą kilkuset wierszy kodu.
• Wymienność.Jeśli masz bibliotekę zewnętrzną, jak zapewnić, że jeśli jej rozwój zostanie zatrzymany, możesz zastąpić ją inną podobną biblioteką? Moim rozwiązaniem jest unikanie bibliotek zewnętrznych, kiedy tylko mogę, i ilekroć nie jest to możliwe, piszę proste opakowanie, aby wyodrębnić część interfejsu programistycznego, którą chcę. Zwykle interfejs, który chcę jest znacznie prostszy niż interfejs oferowany przez bibliotekę. Następnie mój kod uzyskuje dostęp do biblioteki zewnętrznej tylko przez to opakowanie, co ułatwia wymianę. Budowanie całej aplikacji na jakimś frameworku jest dużym nie-nie. Serwlety? Tak, są tu od dłuższego czasu i nadal są w dającej się przewidzieć przyszłości. Silniki szablonów? Tak, chociaż nie można ich dokładnie wymienić (zwykle wybierasz jeden i pozostajesz przy tym), wartość, którą przynoszą, jest ogromna, więc wybieraj ostrożnie - pamiętaj, że przełączając silniki szablonów, możesz mieć dwa silniki szablonów w tej samej aplikacji, ale zwykle nie możesz mieć dwóch ram w tej samej aplikacji. Rozpórki Apache? Nie, frameworki stają się modne i szybko wychodzą z mody, a zwykle nie możesz mieć dwóch frameworków w tej samej aplikacji.
• Wersja piekła. Wybierając bibliotekę zewnętrzną, musisz ją zaktualizować, aby uniknąć luk w zabezpieczeniach, a jej aktualizacja może zepsuć wszystko. Dobrze zaprojektowane komponenty (takie jak Java JRE) są kompatybilne z różnymi wersjami, ale z mojego doświadczenia wynika, że ​​większość bibliotek jest badziewna z powodu narzucenia ogromnej wersji piekła. Ponadto komponent X może wymagać wersji Z w wersji 1, a komponent Y może wymagać wersji Z w wersji 2 i niekoniecznie może być możliwe połączenie wersji Z 1 i wersji Z 2 w tej samej aplikacji.
• Luki w zabezpieczeniach Wybierając bibliotekę zewnętrzną, zwiększa się liczba łatwych do wykorzystania luk w zabezpieczeniach aplikacji. Niektórzy mogą twierdzić, że opracowany przez siebie kod przypomina bezpieczeństwo poprzez zaciemnienie, ale z drugiej strony powiedziałbym, że nadal jest to forma bezpieczeństwa.
• Problemy z licencją. Każda biblioteka zewnętrzna nakłada własną licencję na części programu. Na przykład bibliotek GPL nie można używać w programach innych niż GPL, a biblioteki LGPL wymagają także dystrybucji kodu źródłowego wraz z plikami binarnymi, co może wymagać znacznej przepustowości.
• Czas uruchamiania aplikacji. Każda duża biblioteka zewnętrzna spowalnia czas uruchamiania aplikacji. Pisząc prostą, szczupłą bibliotekę wewnętrzną, możesz znacznie skrócić czas uruchamiania aplikacji.
• Ślad pamięci. Ponieważ X wymaga Y wymagającego Z wymagającego A wymagającego B, potrzebujesz jednocześnie X + Y + Z + A + B w pamięci. Implementując tylko ekwiwalent X, nazwijmy to X ', wewnętrznie potrzebujesz tylko X' w pamięci. I zwykle ślad pamięci X 'jest mniejszy niż ślad pamięci X.
• Ryzyko błędu Im więcej wierszy znajduje się w elemencie zewnętrznym, tym większe jest ryzyko, że napotkasz błąd, który będzie trudny do naprawienia z powodu ogromnej ilości kodu, który musisz zrozumieć. Jeśli robisz to wewnętrznie, zwykle robisz to z mniejszą liczbą wierszy kodu (aby zrobić to, czego potrzebujesz, nic więcej), a zatem z mniejszym ryzykiem błędów.
• Możliwość dostosowania Jeśli sam piszę zapytania SQL, wiem, jak wygląda zapytanie i jak dobrze działa na danym silniku bazy danych i danym zestawie indeksów. Z drugiej strony, jeśli zapytanie SQL jest napisane przez zewnętrzny komponent, nie wiem nic o jego wydajności. Pracowałem w firmie, której pobranie każdej strony zajęło kilka sekund. Podejrzewałem, że przyczyną była biblioteka Hibernacja, z której automatycznie pobierało zbyt dużo danych z bazy danych, gdy wszystko, czego potrzebowałeś, to jeden element, a nie wszystkie elementy związane z tym konkretnym elementem. Opuściłem firmę, zanim odkryłem prawdziwą przyczynę powolności, ponieważ nie podobało mi się podejście do korzystania z ogromnej liczby istniejących bibliotek.

Uważaj szczególnie, jeśli biblioteka nazywa się szkieletem . Oznacza to, że biblioteka wymaga zbudowania całej aplikacji wokół siebie. Zasadniczo nie można mieć dwóch ram w tej samej aplikacji; będą walczyć ze sobą bez pokojowego współistnienia. Biblioteka narzędzi programistycznych? Tak, proszę, jest ich za mało. Jeśli kiedykolwiek znajdę lepszą bibliotekę niż ta, z której teraz korzystam, mogę użyć nowo znalezionej biblioteki w nowym kodzie, nadal korzystając ze starej biblioteki w starym kodzie. Ramy rozwoju sieci? Wielki trąbienie NIE!

Myślę, że twój premier dąży do stworzenia trudnego do zarządzania systemu, który będzie generował wiele prac konserwacyjnych podczas jego pracy, więc zapewni ci dochód.

Osobiście wydajesz się, że utknąłeś w pythonie, po prostu zapomnij na chwilę o pythonie, nie koduj go w ciągu roku, ucz się nowych rzeczy, zobaczysz, że istnieją inne języki, które mogą zrobić to samo i prawdopodobnie lepiej.

Jak powiedzieli inni, poznaj narzędzia, zanim zaczniesz je kodować. Może zasugerować, że dobrze byłoby wspólnie ocenić niezbędny stos na podstawie badań różnych narzędzi, które wydają się odpowiednie do zadania. A może zapytać, jak wymyślił tę listę, mógł skorzystać z pomocy kogoś, kto jest na bieżąco.

Deweloperzy nie powinni bać się nauczyć się korzystać z nowych bibliotek, frameworków, technologii itp. Jest to podstawowa część opisu pracy programisty i jest całkowicie rozsądne, aby ktoś sugerował, że zespół pracuje z rzeczami stron trzecich, których nikt nie ma doświadczenie w pracy, a nawet wymaganie od zespołu, aby był w stanie podejmować wiarygodne decyzje techniczne dla zespołu.

Jednak nie można oczekiwać, że możesz po prostu pobrać nową technologię (nie mówiąc już o kilku nowych technologiach jednocześnie) do swojego stosu i rób postępy. Powinno się zaplanować sporo czasu, aby poznać tajniki nowego podejścia i opracować dobry projekt uwzględniający nowe elementy, podczas którego nie można oczekiwać żadnego rzeczywistego postępu w zakresie rzeczywistego produktu (od osób wykonujących tę pracę związaną z uczeniem się / projektowaniem) , który może, ale nie musi być całym zespołem, ale jeśli nie, prawdopodobnie będzie więcej czasu dla osób, które nauczyły się przekazywać wiedzę reszcie zespołu). Taki jest koszt wprowadzenia tego rodzaju poważnych zmian. Uczenie się nowych technologii jest częścią pracy programisty, ale nie dzieje się tak przy zerowym koszcie czasu.

Wygląda na to, że z pytania nie doszło. Ludzie robią wszystko, co w ich mocy, starając się stworzyć dobre wdrożenia oparte na technologiach, których sami nie rozumieli. Oczywiście wynikowy kod jest okropny.

Spróbuj przekonać swojego premiera, że ​​firma będzie musiała poświęcić na to więcej czasu. Albo przyjdzie w formie zatrzymania się, nauki i oceny nowych technologii, znalezienia dobrego projektu i uporządkowania obecnego bałaganu związanego z wdrażaniem. Lub przyjdzie w postaci więcej czasu zmarnowanego na błędy, konserwację, kosztowniejszy rozwój itp.

Nie można powiedzieć, czy techniczne opcje opisane w pytaniu (równoważenie obciążenia, kolejki komunikatów itp.) Są rzeczywiście odpowiednie. Nie sądzę, że „nikt w zespole ma doświadczenie w pracy z tym wcześniej” jest dobrym powodem, aby całkowicie wykluczyć decyzję, ale nie zwiększy krótkim okresie koszty podejmowania tej decyzji (która może zmienić " najlepsza decyzja w danym kontekście), a jeśli twój premier nie bierze tego pod uwagę i oczekuje, że zespół natychmiast stanie się tak produktywny, jak doświadczeni ludzie, powinieneś wycofać się z tych powodów; będą ustalać wysoce nierealistyczne harmonogramy projektów, co nie leży w interesie nikogo.