Kiedy można poświęcić „porządność” projektu, aby zrealizować projekt?

Kiedy pracujesz nad produktem, który należy wkrótce wykonać i działa dobrze, kiedy można poświęcić łatwość konserwacji i „porządek” projektu, aby szybko wykonać zadanie i wyjść z domu? I w jakim stopniu jest to w porządku, szczególnie gdy techniki zastosowane do „schludności” są dla mnie nowe?

Pamiętaj, że jesteś zatrudniony w celu wspierania biznesu. W pewien sposób twoje oprogramowanie wpływa na wynik końcowy firmy. Musisz znaleźć równowagę między technicznie idealnym rozwiązaniem, a czasem wprowadzenia produktu na rynek i korzyściami, jakie biznes z niego odniesie.

Z mojego doświadczenia wynika, że ​​programiści często martwią się o techniczną doskonałość. Istnieją jednak bardzo ważne powody, aby poświęcić atrybuty jakości, takie jak łatwość konserwacji lub wydajność, aby szybciej wydostać się z produktu. To zależy od firmy i produktu. Ale „zawsze dążyć do idealnego projektu” jest zbyt uproszczonym podejściem.

Ostatecznie najważniejsza jest wartość dla firmy. Dowiedz się, jak go zmaksymalizować w perspektywie krótko- i długoterminowej i zmierz się z tym celem.

Termin „dług techniczny” jest bardzo przydatny, aby pomóc w podejmowaniu takich decyzji biznesowych. Każda praca, której teraz nie wykonasz, spowoduje później trochę pracy. Podobnie jak w przypadku finansów, zaciąganie długów jest ryzykowne, ale warto je wykorzystać, jeśli będziesz w stanie spłacić dług później.

To powiedziawszy, dług techniczny nie jest współczynnikiem 1: 1 w czasie zwrotu. Błędy są droższe do naprawienia po wydaniu, a wpływ na produktywność w przyszłości przy tworzeniu bałaganu ze starszego systemu może być oburzający. Możesz patrzeć na spędzanie podwójnego czasu na naprawianiu błędów, a może 1000 razy więcej roboczogodzin i zasobów.

Twoim zadaniem w tej decyzji jest zrozumienie konsekwencji poszczególnych rozważanych cięć narożnych, a następnie przekazanie tych konsekwencji osobom podejmującym decyzję biznesową. Ta szczególna umiejętność szacowania może wymagać wielu badań i pracy z twojej strony, aby dobrze się teraz rozwijać, ale będzie nieoceniona podczas twojej kariery.

Kiedy jest akceptowany, a konsekwencje są rozumiane przez właściciela / klienta / użytkownika.

Hydraulik musi wyrzucić śmieci do naprawy. Chcę w międzyczasie korzystać ze zlewu, ale będzie musiał zapłacić mi za czas i materiały na tymczasowe włożenie rur za pomocą taśmy, która może się zepsuć. Opóźni to również przekazanie urządzenia do naprawy do warsztatu. Jeśli zaakceptuję dodatkowe faktury ze świadomością, że ryzykuję zatkanie. Naprawienie utylizacji zajmie dzień dłużej i jeszcze dłuższe opóźnienie, zanim będzie mógł je odłożyć, co jest dopuszczalne.

Możesz być teraz na czas i mieć budżet, ale w dłuższej perspektywie poświęć / zaryzykuj jeszcze wyższą opłatę. Może to być trudne do zrozumienia przez osoby nietechniczne, ale po to są pracownicy sprzedaży.

Wiele osób rezygnuje z szybkiego uczenia się czegoś nowego i po prostu rób to tak, jak zawsze. Jeśli jest to wzorzec, nie tylko ucierpi twój kod, ale również twoje umiejętności programistyczne pozostaną ograniczone.

Jednak pod koniec dnia jedynym udanym oprogramowaniem jest to, które jest dostarczane.

Po upływie miękkiego terminu. I nawet wtedy jest to bardzo niski stopień „OK”. Po upływie ciężkiego terminu jest oczywiście kwestia sporna. Ponieważ taka jest natura trudnych terminów.

Ponadto pociąga to za sobą dług techniczny. Za każdą godzinę / dzień spędzoną na wycinaniu zakrętów w mentalności wykonanej przez gitera, będzie to kosztować około dwa razy więcej czasu, kiedy będziesz musiał dotknąć tego projektu. Jeśli musisz, najlepiej spieszyć się, wysłać, a następnie natychmiast rozpocząć naprawianie całej taśmy z kaczką. Powrót lat po hackym projekcie to koszmar. Jeśli nigdy więcej go nie dotkniesz, niech tak będzie, nikogo to nie obchodzi. Ale jedyny raz, kiedy zostawiłem projekt na zawsze, to zmieniłem pracę.

Pamiętaj jednak, że synchronizacja tych rzeczy jest zadaniem kierownika projektu. Jeśli spieszysz się do terminu, to wina premiera. Zrób to dobrze, zrób to raz i zrób to spokojnie i poprawnie. Życie jest za krótkie na cokolwiek innego.

Wszystkie pozostałe odpowiedzi zamieszczone tutaj są dobre. Chciałbym jednak dodać, że jako programista projektu jesteś szafarzem (obrońcą) projektu.

Jeśli nie przeciwstawisz się właściwemu rozwiązaniu technicznemu, nikt ci nie obiecam. Zawsze powinieneś argumentować za robieniem rzeczy we właściwy sposób dla swojego szefa, a premier powinien zawsze argumentować na korzyść terminu.

Mamy nadzieję, że jeśli jesteś w rozsądnej organizacji, zostanie osiągnięty kompromis, który pomoże dotrzymać terminów, a jednocześnie nie odejdzie zbyt daleko od projektu w tym samym czasie.

Biorąc to pod uwagę, nie zakładaj, że jeśli termin premiera nie zostanie dotrzymany, świat się skończy, a projekt się nie powiedzie. Zwykle nie jest tak czarno-biały i przez większość czasu termin premiera jest miękki i ma miejsce na regulację.

Niemal każdy termin, w którym kiedykolwiek byłem na planie PM, był w większości sztuczny. Będą bronić go zębami i gwoździami i udają, że jednak inaczej, ponieważ jeśli PM przekroczy termin, wtedy PM SPOJRZA!

To, że PM wygląda źle, nie oznacza, że ​​projekt się nie powiódł. Jeśli to zrozumiesz, będziesz zaskoczony, jak bardzo możesz zgiąć PM.

Podaj klientowi zgrabny projekt. Jeśli ten cytat jest dla nich nie do przyjęcia, przejdź do podziału kosztu każdego komponentu (zwykle kosztuje == czas opracowania). Pozwól im zdjąć przedmioty z „a la carte”, jeśli zdecydują. Wielu skacze w czasie golenia na „bezużyteczne” rzeczy, takie jak testowanie i projektowanie. Wyjaśnij ryzyko związane z tym podejściem, ale jeśli zaakceptują ryzyko, postępuj zgodnie z zaleceniami. Jeśli mam tylko wystarczająco dużo pieniędzy na samochód klunker, to kupię samochód klunker, nawet jeśli wiem, że prawdopodobnie zepsuje się za 8 miesięcy. Twój klient ma obowiązek wyważyć ryzyko i zaakceptować konsekwencje.

Jedyną rzeczą, której nie chcesz robić, jest powiedzenie klientowi, że ma pięknie zaprojektowane oprogramowanie, gdy zapłacił tylko (i otrzymał) niepotrzebne śmieci. Jeśli coś pójdzie nie tak (co prawdopodobnie będzie), w pierwszym scenariuszu będą wyglądać źle, ale w drugim scenariuszu będzie wyglądać źle.

To nigdy nie jest w porządku, ale czasami trzeba iść na kompromis w celu ukończenia projektu. Smutna rzeczywistość jest taka, że ​​większość biznesmenów jest całkowicie ignorantami i jest więcej niż gotowa poświęcić łatwość utrzymania później za coś teraz. Sztuką jest wiedzieć, jak osiągnąć równowagę; być może projekt nie będzie tak schludny, jak mógłby być, ale dopóki nie jest to chlew, jest to godny kompromis.

Zależy to całkowicie od pytania „Czy Ty lub ktokolwiek inny będzie prawdopodobnie chciał go później zmodyfikować?” Jeśli tak, powinieneś spróbować mieć „schludny” projekt, w przeciwnym razie ryzykujesz wyrzuceniem wszystkiego i zaczniesz od nowa 6 miesięcy później.

Oczywiście, możesz posunąć się za daleko, ale ogólnie trochę schludności zaoszczędzi ci pracy później.