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

15

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?

Pan Jefferson
źródło
3
Tylko wtedy, gdy jest to absolutnie konieczne.
FrustratedWithFormsDesigner
1
W zasadzie pracuję. „Możesz zapłacić teraz lub później” nigdy nie było tak prawdziwe.
MetalMikester
Brzmi jak zbliżający się termin ...
1
Przyjmę pogląd przeciwny i zawsze powiem . Jeśli projekt nie jest skończony, nikogo nie obchodzi, czy jest porządny.
drxzcl
1
@MrJ, tak naprawdę myślałem o użytkownikach.
drxzcl

Odpowiedzi:

18

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.

RationalGeek
źródło
3
Zgadzam się z duchem twojej odpowiedzi, ale brakuje ci niektórych szczegółów. You need to strike a balance between a technically perfect solution, and the time to market of your productNie zgadzam się, to jest poza odpowiedzialnością programisty. Oni absolutnie musi pozostać świadomy, ale powinny one dać informację do kogoś odpowiedzialnego podjąć decyzję biznesową.
StuperUser
2
Spójrz na przykład na Blizzarda. Odnoszą duży sukces dzięki swoim grom i nie dbają o czas na sprzedaż, ponieważ uważają, że najwyższa jakość ostatecznie się opłaci. I tak jest, chociaż prawdopodobnie nie dla wszystkich rodzajów oprogramowania.
Falcon
1
Absolutnie zgodziłem się z @StuperUser i @Peter Rowell. Często to na deweloperze spoczywa obowiązek informowania o ryzyku technicznym, problemach z pokonywaniem zakrętów itp. Osobom znajdującym się wyżej w łańcuchu żywnościowym, które podejmują decyzję. Jeśli to twoja rola, powinieneś skupić się na komunikowaniu jej tak dokładnie, jak to możliwe. Im bardziej jednak rozumiesz, co napędza łańcuch wartości firmy, tym lepiej uzyskasz tę komunikację.
RationalGeek
1
@Falcon Blizzard może rzeczywiście poświęcić krótkoterminowy wzrost we wczesnej wersji dla długoterminowej gry w solidnej, stabilnej, przyjemnej grze. To może być dla nich odpowiednia równowaga. Ale nie we wszystkich przypadkach jest to odpowiednia równowaga.
RationalGeek
4
W rzeczywistości większość nowych produktów oprogramowania zawiedzie na rynku, nie z powodu problemów z jakością, ale dlatego, że klienci po prostu ich nie chcą. Tak więc poświęcenie dużej ilości czasu / wysiłku na stworzenie solidnej, zwrotnej architektury w wersji 1 produktu może nie być najlepszym wykorzystaniem zasobów. Biznesmeni, którzy pchają, by coś wyciągnąć za drzwi, nie są idiotami, jak wielu z was uważa; dostarczenie produktu w ręce klientów w celu ustalenia rentowności jest bardzo mądrym posunięciem.
Kristopher Johnson
12

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.

Ethel Evans
źródło
1
+1. Dług techniczny jest naprawdę najwyraźniejszym sposobem na opisanie tego.
crazy2be
8

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.

JeffO
źródło
5

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.

Jeremy
źródło
„Jednak pod koniec dnia jedynym udanym oprogramowaniem jest to, które jest dostarczane”. Dopóki nie rozbije się i nie spłonie kilka lat później, ponieważ nie został odpowiednio zaprojektowany. Krótkowzroczność w akcji.
Wayne Molina
1
Jeśli nigdy nie wyślesz, nigdy nie przeżyjesz kilku lat ...
Jeremy
Jeśli nie możesz wysłać czegoś, co nie spieszy cię z powodu krótkowzrocznego zarządzania, to przede wszystkim nie zasługujesz na biznes!
Wayne Molina
3

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.

Philip
źródło
2

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.

wałek klonowy
źródło
1

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.

Morgan Herlocker
źródło
1

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.

Wayne Molina
źródło
0

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.

Jo-Herman Haugholt
źródło
4
Nie ma czegoś takiego jak produkt, który nie wymaga konserwacji, bez względu na to, co mówi klient.
Edward Strange
@ crazy-eddie Prawie nie. To miało być obciążone pytanie; Naprawdę nie mogę wymyślić wielu przypadków, w których odpowiedziałbyś „nie” na to pytanie. Nawet szybki skrypt „trzydzieści jeden” przeznaczony tylko do jednej rzeczy, którego już nigdy nie można użyć, można go później edytować i odnawiać.
Jo-Herman Haugholt