W idealnym świecie lepiej jest dotrzymywać terminu przy mniejszej liczbie błędów. Ale z twojego doświadczenia, które jest bardziej preferowane / dopuszczalne:

1. Dotrzymać terminu, ale ma wiele błędów, ponieważ deweloper spieszy się do rzeczy
2. Mniej błędów, ale nie do końca dotrzymano terminu, ponieważ programista jest bardzo rygorystyczny w pisaniu kodu

Odpowiedź na to pytanie zależy w dużej mierze od celów biznesowych, a także od klienta.

Przedsiębiorstwo :

Jeśli prowadzisz interesy z klientem na poziomie przedsiębiorstwa, który ma ugruntowaną pozycję na rynku, są mniej elastyczni i nie mogą tak szybko dostosować się do zmian. Dlatego w większości przypadków stabilność jest absolutnym wymogiem. Istnieją wyjątki w zakresie badań i rozwoju oraz wprowadzania nowych branż. W niektórych przypadkach szybciej kończy się jako pierwszy.

Tego rodzaju klienci zazwyczaj rozumieją, że dobre oprogramowanie wymaga czasu i będą współpracować z Tobą, aby osiągnąć cele.

Startupy :

W przypadku nowego startupu zasady są drastycznie różne. Jako startup musisz od razu wiedzieć, czy produkt, który budujesz, rzeczywiście spełni zapotrzebowanie, zgodnie z przewidywaniami badań marketingowych. Na początek, jak najszybsze udostępnienie prototypu na rynku może zebrać wiele cennych opinii na temat kierunku, w którym powinien iść produkt.

Może także zapewnić Ci pozycję lidera na rynku, pomagając zdobyć cenny udział w rynku w nowej branży, zanim zostanie nasycona konkurencją.

Ponieważ startupy są małe, elastyczne i mogą szybko dostosowywać się do zmian, ten model działa najlepiej dla nich.

Podsumowując, należy wziąć pod uwagę inne czynniki, ale główną ideą jest to, że każdy projekt jest inny i będzie miał inną jakość i czas na osiągnięcie celów rynkowych. Określenie skutecznej strategii biznesowej, która obejmuje dokładną analizę kosztów alternatywnych wyboru jednej metody, zależy od kierownictwa wykonawczego.

lub ... 3. Wytnij niepotrzebne funkcje

Czasami, ze względu na techniczne cukierki lub funkcje cukierków wymagane przez klienta, terminy są trudne do dotrzymania i z natury powstaje większa liczba błędów. Stosowane są zasady KISS i YAGNI .

Cytując z tej książki „Rework”, niezbędne / kluczowe / epicentrum z twojego oprogramowania jest tym, co firma musi funkcjonować, podobnie jak stojak na hot dog może być stojak na hot dog bez żadnych dodatków, czego nie można wyciąć hot dogi.

Renegocjuj

Jedną z najtrudniejszych rzeczy do nauczenia jest to, jak zadowolić klientów. Z mojego doświadczenia wynika, że ​​można to łatwiej osiągnąć dzięki mniejszym iteracjom produktów.

Czasami terminy wymagają oprogramowania działającego na wysokim poziomie produkcji od pierwszego dnia. Menedżerowie / klienci nie zawsze wiedzą (co jest przez większość czasu), czego tak naprawdę potrzebują do oprogramowania. Spróbuj więc ograniczyć zbędne funkcje i zachować jakość. Ostatecznie zależy to od tego, jak krytyczne będzie środowisko produkcyjne, ale spróbuj wyciąć dodatkowe funkcje i zapewnić jakość. Cytując ponownie z „Rework”:

Robienie później oznacza także robienie lepiej

... a także dotrzymywanie terminów przy mniejszej liczbie błędów

Cóż, możesz to sformułować w ten sposób: czy chcesz zapłacić za jakość teraz czy później? Albo poświęć trochę czasu, aby zrobić to dobrze, albo spędź później, naprawiając wszystkie problemy. Twierdziłbym, że ta faza naprawy błędów po opracowaniu funkcji może być droższa, ponieważ może być również bardziej ryzykowna i podatna na zhackowane rozwiązania, ponieważ istniejący kod już istnieje i prawdopodobnie nie jest wystarczająco wysokiej jakości.

Dotrzymać terminu i przedstawić listę znanych problemów.

Ludzie NIENAWIDZĄ znajdowania błędów, ale jeśli powiedziano im to z góry, są znacznie łagodniejsi.

Zależy to całkowicie od sytuacji ....

Należy wziąć pod uwagę wiele czynników:

1. Jak łatwo jest wprowadzać łatki?
2. Czy można z czasem wydać podstawową, uproszczoną wersję, a następnie załatać nową funkcjonalność (Edge Case)?
3. Jaka jest ogólna kultura branży klienckiej dla takiego produktu? Czy oczekują jednorazowych doskonałych wydań, czy też są przyzwyczajeni do ewoluującego systemu, który może być wadliwy przy pierwszym wydaniu?
4. Jakie ryzyko dla firmy stanowi błędna wersja początkowa, a nie przekroczenie terminu?

Krótko mówiąc, nie ma na to czarno-białej odpowiedzi. Na przykład: w przypadku systemu wbudowanego, który jest trudny i kosztowny we wdrożeniu na urządzenia w terenie, najlepiej spróbować poczekać (w miarę możliwości renegocjować terminy) i wydobyć go tak, jak to możliwe, bez błędów. Z drugiej strony, dla czegoś takiego jak duży system portalu internetowego (napisany jako aplikacja internetowa), który można łatwo zaktualizować w dowolnym momencie, wprowadzając poprawki po ich opublikowaniu, bardziej sensowne może być wydanie początkowo podejrzanej wersji, i następnie łataj problemy (i funkcjonalność krawędzi), gdy do tego dojdziesz.

Ale na koniec z mojego doświadczenia wynika, że ​​była to raczej decyzja biznesowa niż decyzja technologiczna. Jeśli znajdujesz się w sytuacji, w której przekroczenie terminu to wielka sprawa, a posiadanie błędnej wersji początkowej nie jest (lub odwrotnie) - będziesz musiał rozważyć te rzeczy przy podejmowaniu decyzji.

UWAGA: Jako programista oczywiście wolę pomysł polerowania produktu w jak największym stopniu przed jego uwolnieniem (do cholery, wolałbym nigdy nie mieć żadnych terminów;)). Ale realistycznie nie jest to możliwe w prawdziwym życiu. Często uproszczona wersja początkowa jest dobrym rozwiązaniem na środku ziemi.

Widziałem wielu premierów, którzy bali się powiedzieć klientowi, że nie możemy dotrzymać harmonogramu i nalegać, aby wysyłać znane błędy. Mogę ci powiedzieć, że za każdym razem, gdy robią to klientowi, jest on zwykle bardziej zainteresowany mniejszymi błędami i przesuniętym terminem. Gwarantuję, że zapamiętają błędy bardziej niż przekroczony termin, chyba że termin ten jest absolutnie niemożliwy do przeniesienia (np. Początek sezonu podatkowego, gdy tworzysz oprogramowanie podatkowe) lub wpłynie na niektóre inne rzeczy, których przeniesienie będzie bardzo kosztowne (IMHO 98% wszystkich terminów nie spełnia tych kryteriów).

Myślę, że to zależy od błędu. Czy chcesz opóźnić wydanie, aby naprawić błąd, w wyniku którego aplikacja ulega awarii w momencie uruchomienia na dowolnym komputerze? Tak, zdecydowanie. Czy musisz naprawić błąd, który występuje tylko w systemie Windows ME, gdy jest pełnia księżyca? To prawdopodobnie może poczekać.

Jeśli jest to błąd krytyczny, najlepiej wykonać rozdanie numer 2. Powodem jest to, że naprawa kosztuje wykładniczo więcej, jeśli musisz wypchnąć tę poprawkę w aktualizacji.

W przypadku mniej krytycznych aktualizacji możesz wydać aktualizację pakietową, która do pewnego stopnia obniża ten koszt.

W razie wątpliwości mówię, że wybierasz numer 2, ale nie zdziwiłbym się, gdy otrzymam takie podejście od zarządzania. Podejrzewam, że menedżerowie są częściej oceniani na podstawie tego, jak dobrze są w dotrzymywaniu terminów, niż nie powodują niepotrzebnych aktualizacji krytycznych.

Ani. Dlaczego nie upiec jakości w swoim kodzie? Czy jesteś w stanie dotrzymać terminów dzięki kodowi jakości? Możesz wypchnąć mniej funkcji, ale jeśli jakość zostanie wprowadzona do procesu, możesz osiągnąć jedno i drugie.

To, co się teraz stanie, będzie wymagało upoważnionego kierownika zespołu lub menedżera deweloperów, który może odepchnąć firmę i przeprowadzić rozmowę na temat dwóch rzeczy:

1. Jakość zapisana w kodzie = 2 mniej funkcji na kompilację
2. Priorytetyzowanie najbardziej potrzebnych funkcji od interesariuszy, co NAPRAWDĘ potrzebują.

Następnie możesz skoncentrować się na funkcjach o najwyższej wartości i wypchnąć je z doskonałością.

Jeśli chodzi o testowanie, nigdy się nie kończy. jest skończony, ale nigdy nie skończony.

Idź na premierę z błędami z dotkliwością i większą ostrożnością.

Dotrzymanie terminu z wieloma błędami sprawia, że ​​jesteś biedny w branży, a klient nie przyjdzie ponownie. Możesz porozmawiać z klientem, aby uzyskać opóźnienie o dwa lub trzy dni.

Jeśli spojrzysz na to od końcowego użytkownika, byłbym bardzo odrażony, gdyby ktoś obiecał zrobić coś na poniedziałek, a kiedy spróbuję go użyć, to nie działa, lub wszystko jest wadliwe.

Ale jeśli spojrzysz na stronę „proceduralną”, oznacza to, że aplikacja wymaga więcej testów i jest częścią naturalnego życia oprogramowania.

Moim najlepszym podejściem jest próba sprawienia, aby rzeczy działały tak, jak powinny.

To pytanie, na które tylko ty możesz odpowiedzieć. Zależy to od rodzaju produktu, kim jest klient, czego wymaga klient itp. Nie ma sposobu, aby udzielić prostej odpowiedzi „a lub b”. To całkowicie zależy od sytuacji.

Ale przypomnę ci, że koszt naprawienia błędu po wydaniu jest znacznie wyższy niż naprawienie przed wydaniem. Więc weź to pod uwagę, podejmując decyzję, czy poczekać do momentu opublikowania, aby naprawić błąd, ponieważ poświęcisz na to więcej czasu / wysiłku / pieniędzy.