Co zrobić, gdy Twój „nieudany” projekt faktycznie „odnosi sukces”?

Co byś zrobił, gdybyś znalazł się w sytuacji, w której projekt, nad którym pracujesz, jest oczywiście źle zbudowany i będzie miał awarie w przyszłości i będzie koszmarem do utrzymania ... ale zarząd uważa go za „sukces”, ponieważ klienci Są szczęśliwi?

Czy nie powinno mnie to obchodzić? Czy to w porządku, że klienci nawet nie zdają sobie sprawy, że mogą mieć lepszą aplikację niż ta?

W którym momencie przestaję dbać o prawidłowe zbudowanie i po prostu iść z prądem?

Jeśli klienci są zadowoleni, robisz coś dobrze. Wiele osób lubi hot dogi, nie wiedząc, jak się je robi ...

Jeśli aplikacja jest dobrym rozwiązaniem problemu, ale martwisz się, że podstawa jest wadliwa, dowiedz się, jak stopniowo wprowadzać ulepszenia, i opracuj plan wdrożenia tych ulepszeń podczas aktualizacji produktu. Przyrostowy jest kluczowy: jeśli masz ochotę przepisać całe jego części, Twój menedżer słusznie powie, że to nieracjonalne. Ideał może być wrogiem dobra. Spójrz na historię jwz, w której Netscape pozwolił IE przejąć inicjatywę, ponieważ „musiał” przepisać Navigatora.

Jeśli interfejs aplikacji sam w sobie jest bałaganem, klienci mogą nadal być zadowoleni, ponieważ porównują go do „trudnej drogi”, a nawet błędny program może być o wiele lepszy. Porównujesz go do ideału, który możesz sobie wyobrazić ze względu na swoje pochodzenie i umiejętności. Ponownie zastanów się, w jaki sposób możesz ulepszyć rzeczy w sposób przyrostowy i rozłóż to w ramach planu.

Nie przestawaj się troszczyć: chcesz, aby Twoja praca była jak najlepsza. Pamiętaj jednak, że to klient płaci rachunki, a ty piszesz dla nich oprogramowanie, a nie ty.

To nie jest dla nich koszmar. Będzie to dla ciebie koszmar, a oni myślą, że wiesz, co robisz, więc zostanie naprawiony. Czy wolisz osoby, które nie podejmują się programowania, uważają, że Twoja aplikacja jest gorsza niż w rzeczywistości? To nie jest wyjątek. Ciesz się póki możesz. Lepiej, żeby klient przerósł tę aplikację. Mogą pójść tak daleko w innym kierunku jako firma, że ​​jest to absolutnie bezużyteczne. Możesz go przepisać z zupełnie innego powodu niż myślisz.

Nie sądzę, że powinieneś kiedykolwiek przestać się przejmować, nawet jeśli wydaje się, że przestało to być wyższe kierownictwo. Myślę, że najważniejszą rzeczą do wyciągnięcia z tego doświadczenia jest zapamiętanie i udokumentowanie wszystkich rzeczy, które według ciebie poszły nie tak. Unikanie tych błędów w przyszłości zostanie ostatecznie rozpoznane, jeśli nie ta obecna grupa menedżerów, być może kolejna grupa menedżerów, dla której pracujesz.

Zacznę przedstawiać pomysły na kolejne kroki rozwoju, które obejmują ponowne faktoring w celu poprawy jakości kodu. Nie wchodź zbyt głęboko w szczegóły techniczne, ale zwróć uwagę, w jaki sposób zaproponowane przez Ciebie poprawki będą oznaczać dalsze zadowolenie klienta. Przygotuj się na połączenie czyszczenia z nowymi funkcjami, ponieważ kierownictwo zawsze będzie szukało czegoś nowego do sprzedania.

Zasadniczo klienci nie będą dbać o utrzymanie, dopóki coś nie pójdzie źle. Idealnie byłoby, gdyby Twoja firma dbała o swoją reputację i chciała ją chronić poprzez utrzymanie kodu.

Jednak - jeśli ten produkt jest postrzegany jako bardzo krótkoterminowy, może nie być wartościowej wartości dodanej. W takim przypadku - poszukaj tanich poprawek - rzeczy przy niewielkim wysiłku, które mają dużą wartość dla zdrowia programistów.

Ty nie. Sukces wykorzystuje się do zabezpieczenia finansowania / pozwolenia / wpisowego w celu rozpoczęcia refaktoryzacji w kierunku technicznie poprawnego i łatwego w utrzymaniu. Albo wykorzystasz sukces, aby awansować z działu „I can keep the old codebase”.

Być może twój priorytet / punkt widzenia jest zły.

Najważniejsze w każdym projekcie oprogramowania jest to, że spełnia ono wymagania użytkowników.

Jest to czas gazillionów ważniejszy niż bycie „poprawnym” zgodnie z modą projektową C / S w tym miesiącu.

Tak, powinieneś używać prawidłowych wzorców projektowych, poprawnie korzystać z technologii itp. Itp. ale tylko w takim stopniu, w jakim ułatwia to wdrożenie wymagań użytkowników w solidny i łatwy do utrzymania sposób.

Naprawdę źle napisany system, który faktycznie spełnia potrzeby biznesowe, jest zawsze lepszy niż wspaniale napisany, pięknie udokumentowany fragment kodu, którego nikt nie chce ani nie ma powodu, aby go używać.

Staraj się komunikować z obecnymi użytkownikami i zapytaj ich, które ich zdaniem wymagają poprawy. Następnie możesz poprawić niektóre aspekty, które Twoim zdaniem wymagają ulepszenia, a także ulepszyć aspekty zaproponowane przez użytkowników. Możesz uzasadnić swoje ulepszenia jako „potrzebne do wdrożenia ulepszeń proponowanych przez użytkownika”

Na przykład: jeśli użytkownicy uważają, że funkcja wyszukiwania działa wolno. Możesz to poprawić, tworząc lepszą warstwę danych, która oczywiście służy więcej niż tylko wyszukiwaniu, ale możesz następnie uzasadnić spędzony czas.