Jak podejść do starego „to będzie tylko mała aplikacja”? Tak, jasne?

Ok, natknąłem się na to wiele razy, ale tutaj jest scenariusz z najgorszym przypadkiem, nieco przesadzony.

Klient mówi „hej, czy możesz zrobić z nas ten mały moduł do wykonania tego małego zadania”?
Ja: „Nie ma problemu”.

Opierając się na budżetach i ograniczeniach itp., Pomijam trochę architektury i nurkuję od razu i nie spocę się.

Następnie proszą o kolejny moduł. I kolejny. I kilka ulepszeń. A wszystko to dzieje się bardzo powoli, z biegiem lat. I zanim się zorientujesz, masz tę potworną aplikację, która jest okropnie zaprojektowana.

Co robisz, gdy zostaniesz poproszony o zrobienie czegoś małego? Nie wiesz, czy będzie rosło ... czy klient będzie ciągle prosił o dodatki (i nie zrobi tego).

Nie można przesadzić z architekturą, ponieważ jest to w końcu tylko niewielka aplikacja, a oni pójdą gdzie indziej, jeśli powiecie (w tym, że znam cały głos) „Na wszelki wypadek, zróbmy tę architekturę warstwami -O-line bezpieczeństwo i rozdzielanie obaw. W rzeczywistości chodźmy z narzędziem do wstrzykiwania zależności, które naprawdę sprawi, że będzie to fantastyczne bla bla bla ".

Powiedzą „tak, dobrze” i pójdą do kogoś innego.

Budżet, czas i postrzeganie są tak samo ważne jak architektura samej aplikacji.

Jak do tego podejść?

Sądzę, że pytanie naprawdę sprowadza się do: „Kiedy nie masz wszystkich informacji na temat ostatecznego wyniku czegoś, co wydaje się być małą aplikacją, jak możesz uniknąć (lub złagodzić) wczesne podejmowanie decyzji architektonicznych i projektowych, co będzie całkowicie innapropriate później?

Natknąłem się na kilka z nich i zwykle robię dokładnie to, co zrobiłeś. Zanurz się i zrób to.

Kiedy wrócą po więcej, oznacza to, że ich model biznesowy działa i że powinni być gotowi zainwestować trochę więcej. Wtedy usiadłem (zwykle trzeci moduł w zależności od złożoności) i przekazałem złe wieści.

Położę wszystko na stole, proponuję przerobić całą rzecz, w tym najnowszy moduł, i powiem mu, ile to będzie kosztowało. Zazwyczaj na początku doznają szoku z naklejkami, ale jeśli masz dobre relacje robocze i twoje rzeczy działają, nie powinno to być wielkim problemem.

Upewnij się, że rozumieją trzy rzeczy:

1. Jeśli naprawdę nie chcą zawracać sobie głowy całkowitym przepisaniem, nadal będziesz wykonywać trzeci moduł. Może to potrwać jeszcze kilka godzin, a ty za to zapłacisz. Przypomnij im, że naprawdę powinni pomyśleć o przepisaniu w przyszłości, ponieważ im dłużej będą czekać, tym więcej będzie to kosztowało.

2. Naprawdę będzie ich to kosztować więcej, aby skłonić kogoś innego do zrobienia tego. Nowa osoba musi przeprojektować wszystko przy minimalnym zrozumieniu ich potrzeb i dziwactw, co oznacza dodatkowy czas przepisywania i ryzyko, że nie wykona tak dobrej roboty.

3. Że nie próbujesz zarabiać szybko. Rzecz wymaga ponownego zaprojektowania.

BTW, jeśli Twój nawyk rozliczeniowy jest mniej więcej w połowie, a w połowie gotowy, możesz rozważyć zaoferowanie mu przedłużonych warunków płatności. Zmień go teraz na pół i podziel saldo na okres, nad którym będziesz pracował. To może zmniejszyć szczyptę, jeśli mają problemy z budżetem.

Po prostu zrób z niego małą aplikację i zarabiaj.

Z mojego doświadczenia wynika, że ​​inwestowanie na początku więcej czasu niż jest to naprawdę potrzebne, na wypadek, gdyby klient chciał więcej. Ale musisz zważyć efekt przy robieniu tego (czy dostaniesz za to wynagrodzenie) w porównaniu z możliwością, że wszystkie te dodatkowe zmiany naprawdę nastąpią. Cała aplikacja może zostać całkowicie wymieniona po roku.

Inwestując czas w początkową architekturę, możesz poczuć, że robisz sobie przysługę. Ale tak naprawdę wyświadczasz klientowi przysługę, czyniąc inne moduły tańszymi dla niego.

Wystarczy obciążyć klienta nieco więcej za każdy kolejny moduł i krok po kroku przefakturować początkowy projekt, ale zawsze tak, aby odpowiadał potrzebom klienta.

Poprzednie odpowiedzi są dobre i, szczerze mówiąc, co prawdopodobnie bym zrobił. To powiedziawszy, jestem nieco zaniepokojony tym podejściem, ponieważ podejmujesz decyzje, które właściwie należą do klienta, w oparciu o założenie, czego chcą (i chęć znalezienia pracy)

Nie mogę pomagać sobie uczucie należy zrobić, to należy być uczciwym wobec klienta i dać im wybór: 1. Mogę to zrobić szybko i (względnie) tanio teraz. Będzie świetnie - będzie działać - ale przyszłe ulepszenia będą kosztować nieco więcej 2. Mogę poświęcić temu więcej czasu z góry, co będzie kosztować nieco więcej i nie przyniesie żadnych rzeczywistych korzyści użytkownikom, ALE pozwoli Ci zaoszczędzić pieniądze na dłuższą metę, jeśli będziesz chciał dodać nowe funkcje.

Idealnie byłoby, gdybyś mógł podać im liczby czasu / kosztów - inaczej rozmowa mogłaby być zbyt akademicka - ale doceniam, że dotarcie do tych liczb może również wymagać wysiłku. Przynajmniej sformułowanie dyskusji pod kątem poprzednich projektów ułatwiłoby życie klientowi (a ułatwienie życia klienta powinno być najwyższym priorytetem :-))

Komentarze innych osób na temat dobrych relacji roboczych są na miejscu - ale możesz rozpocząć ten proces od bycia uczciwym. Jeśli klient jest osobą, z którą nie możesz nawet rozmawiać, teraz może być czas, aby zadać sobie pytanie, ile potrzebujesz tej pracy ...

Każdą z tych „iteracji” traktowałbym jako osobny projekt. Powinieneś zamknąć te projekty po zakończeniu każdego małego modułu lub dodania. Następnie, gdy chcą czegoś innego, zredaguj formalności. Z biegiem czasu oprogramowanie staje się droższe ... co oznacza, że ​​pobierasz więcej za każdy mały projekt.

To jeden sposób, aby na to spojrzeć, zamiast jednego ... projektu LONGGGGGG.

w jaki sposób unikasz (lub łagodzisz) wczesne podejmowanie decyzji architektonicznych i projektowych, które później będą całkowicie niewłaściwe?

Nie możesz . Programiści nie są medium. Chociaż możemy przewidzieć proste rzeczy lub zobaczyć ulepszenia interfejsu użytkownika, nie możemy tak naprawdę kodować poza tym, czego nie wiemy, że klient może chcieć później (czy widzisz tam szaleństwo?).

W twoim pytaniu wspomniano, że miały one procesy biznesowe, ale nie jestem pewien, czy są to dobre procesy. Oto kilka wskazówek:

• Wymagaj wszystkich zmian i uzupełnień podpisanych na piśmie z budżetem.
  • Ponieważ masz rachunki do zapłacenia
  • Część pisemna i podpisana upewniają się, że tego naprawdę chcą, i redukuje 90% błahych rzeczy, o których klienci zmieniają zdanie w połowie projektu

Twój przerośnięty produkt

To się przydarza każdemu z nas. Odbudowywanie od zera jest zwykle okropnym pomysłem, zwłaszcza biorąc pod uwagę, że zostanie to zrobione ponownie w przyszłości.

Zamiast tego zamówiłbym zmiany, o które prosił użytkownik. Dodaj dodatkowy czas dla każdej funkcji, wykorzystując oryginalny czas na pracę nad tą funkcją, oraz dodatkowy czas na ulepszenie ogólnej architektury, jedno małe ulepszenie na raz. Celem nie jest całkowite „poprawienie” architektury w jednym kontrakcie, ale raczej powolne z czasem jej modyfikowanie.

Powoli ulepszaj iterację kodu poprzez iterację, koncentrując się na częściach, które naprawdę mają znaczenie.