Jakie rodzaje kar powinny mieć firmy niezależne przy opracowywaniu oprogramowania, gdy przekroczą terminy? [Zamknięte]


12

Rozmawiałem ze współtwórcą.

Ma klienta, który chciał mieć pewność, że dotrze na czas. Klient chce mieć wpływ na niedotrzymanie terminów.

Chociaż nie pracuję na własny rachunek, nie mogłem udzielić odpowiedzi.

Moje pytanie brzmi:

Jakie konsekwencje zgadzasz się ze swoim klientem, jeśli nie dotrzymasz terminów dostawy (oprócz zwolnienia)?


2
Byłby głupcem, gdyby zaakceptował jakiekolwiek kary, przynajmniej bez klauzuli „wychodzącej” opartej na zmieniających się wymaganiach. Oszacowanie zadania jest w najlepszym razie ohydnie niedokładne, zanim weźmie się pod uwagę zarządzanie zmianami. Gruntownie. Uruchom
Matt D

4
Czy więc klient miałby interes finansowy, aby nie dotrzymać terminu? To nie brzmi jak naprawdę dobry pomysł. Będzie to miało sens tylko wtedy, gdy klient również poniesie ciężką stratę finansową, gdy się spóźnisz (jak w przykładzie MainMa).
Doc Brown,

2
Wydaje mi się to całkowicie do zaakceptowania. Jestem bardzo zaskoczony komentarzami. Oczekujesz, że ludzie zapłacą za pracę, bez terminu i bez zachęty do dotrzymania terminu? „Szacowanie zadań jest strasznie niedokładne” - nie musi tak być.
NimChimpsky

@DocBrown klient przypuszczalnie ma znacznie większy interes finansowy w dotrzymywaniu terminu, a zatem płaci za pracę w terminie. Uważam, że programiści nie lubią terminów i struktury są czasem niesamowite. Wyobraź sobie, że wyposażasz nową kuchnię, a sklep mówi: oooooo nie, nie możemy powiedzieć, kiedy będzie gotowa, po prostu obciążymy Cię opłatą za godzinę. Przebiegłbym od tego milę. Programowanie nie różni się jakościowo od żadnego innego projektu.
NimChimpsky

5
Jeśli instalujesz nową kuchnię, otrzymasz ofertę na wersję zgodnie ze specyfikacją. Jeśli zaczniesz zmieniać powierzchnię cięcia, płytki, krany i materiały zlewu, zostaniesz obciążony dodatkową opłatą zarówno za zmarnowane materiały, jak i za poświęcony czas. Łatwo jest zrozumieć, dlaczego jesteś obciążony w tym przypadku, istnieje związek fizyczny. Zmieniające się wymagania oprogramowania często nie przychodzą z takim samym zrozumieniem, a każda umowa, która wymaga dostarczenia X do Y, gdzie X nie jest dokładnie przybity, wymaga kłopotów. Wszystko się zmieni, niemożność wytłumaczenia tego jest głupotą.
Matt D

Odpowiedzi:


25

Jeden z najbardziej skutecznych: kara za dzień opóźnienia. Tak samo dzieje się w przypadku dużych projektów, których karą są czasem tysiące dolarów dziennie.

Jeśli liczy się dokładny termin (na przykład jeśli opracuje się na Igrzyska Olimpijskie aplikację internetową, która będzie obsługiwać transmisję z imprezy w 2014 r., Terminem będzie początek Igrzysk Olimpijskich w 2014 r.), Wówczas skutecznym środkiem może być: w przypadku, gdy projekt się opóźnia, firma w ogóle nie otrzymuje zapłaty i powinna również zapłacić karę.

Jeśli takie drastyczne środki nie są odpowiednie, jedyny fakt, że dobrze płatny klient odejdzie, jeśli projekt się opóźni, może załatwić sprawę.

Uwaga dla klienta:

  1. Wiele opóźnień jest winą samych klientów. Przyczyny mogą być liczne:

    • Brak SRS, ale zamiast tego dwa akapity opisujące luźno to, co klient wyobraża sobie jako swoje potrzeby (i oczywiście klient nie chce płacić za gromadzenie wymagań, uważając ten krok za stratę czasu).

    • Nadchodzi dwa tygodnie przed ostatecznym terminem i mówi, że nie ma znaczenia, że ​​projekt był do tej pory wykonany w Javie i używał Oracle: konieczne jest przepisanie go w Pythonie i użycie MySQL, ponieważ klient przeczytał wczoraj magazyn mówiąc, że te technologie są przyszłością.

    • Przyjście ze świeżym zestawem wymagań na każdym spotkaniu. Punkty bonusowe, gdy wymagania te są sprzeczne z prawie wszystkimi wymaganiami podanymi do tej pory.

  2. Dobra komunikacja jest niezbędna dla dobrego projektu.

    Wiele innych opóźnień wynika z braku komunikacji. Praktyki, w których klient od miesięcy nie komunikuje się z firmą i oczekuje się, że skontaktuje się z nim dopiero po zakończeniu produkcji i dopracowaniu produktu, zapraszają na katastrofę.

  3. Dostajesz to, za co płacisz.

    Istnieją specjalne procedury, które pomagają utrzymać organizację projektu, a programowanie powinno zająć tylko 10–15% czasu w przypadku dużych projektów i 15–20% czasu w przypadku średnich projektów. Te projekty powinny być również wykonywane przez osoby, które wiedzą, co robią.

    W praktyce klienci nie są skłonni płacić 800 USD dziennie analitykowi, który stworzy architekturę i oprogramowanie, i nie chcą płacić za inne kroki. Nowicjusz z Albanii, który chętnie pracuje za 50 USD dziennie wydaje się znacznie bardziej korzystny.

    Nie narzekaj, że projekt jest katastrofą, gdy jesteś gotowy zapłacić tylko za katastrofalne projekty.

  4. Nie negocjuj czasu potrzebnego do wykonania pracy.

    Często spotykam się z takimi dyskusjami:

    Deweloper: biorąc pod uwagę wymagania, mogę to dostarczyć w ciągu czterech miesięcy.
    Klient: to niemożliwe. Projekt powinien zostać ukończony za dwa miesiące.
    Deweloper: cóż, chyba że wyłączysz niektóre funkcje ...
    Klient: Nie mogę! Wszystkie funkcje są potrzebne. Dlaczego nie możesz wykonać pracy za dwa miesiące? Skontaktowałem się z indyjskim programistą, moim przyjacielem, który może dostarczyć to w ciągu półtora miesiąca i prosi tylko o połowę ceny!

    Czas negocjacji to przepis na katastrofę.

  5. Poznaj swoje priorytety.

    Weź pod uwagę zasadę 90% wykonania. Gdy projekt jest zarządzany nieprawidłowo, nie jest niczym niezwykłym, gdy programiści mówią, że wykonali 90% projektu miesiąc po jego rozpoczęciu. Miesiąc później jest to nadal 90%. A miesiąc później.

    Może to mieć dwie przyczyny:

    • Kiedy projekt nie jest wykonany poprawnie, tj. 100% czasu jest poświęcone programowaniu, co pozostawia 0% na zbieranie wymagań, architekturę, projektowanie i testowanie, dzieje się tak, że programiści nie mają pojęcia o pracy do wykonania i odkrywają nowe zadania przez cały czas trwania projektu. Przygotowanie projektu pomogłoby lepiej zrozumieć wszystkie zadania, które należy wykonać.

    • Kiedy klient się spieszy, niektóre firmy szybko dostarczają bzdury, a następnie spędzają ogromną ilość czasu na rozwiązywaniu problemów. Niektóre firmy działają tylko w ten sposób, co pomaga im pozostać konkurencyjnym i mówią, że zrealizowali dany projekt w ciągu trzech tygodni, nawet jeśli później spędzili trzy lata, rozwiązując bałagan.

    Proste określenie priorytetów i wymaganie prawidłowego wykonania projektu pomaga wyeliminować te firmy z listy kandydatów.


3
„Nie narzekaj, że projekt jest katastrofą, gdy jesteś gotowy zapłacić tylko za katastrofalne projekty”. Czy mogę tego użyć? Jest to świetny post btw i ładnie podsumowuje ryzyko z obu stron.
Matt D

+1 Bardzo dobre punkty. Również przyjemność przeczytać :)
Radu Murzea,

5
@MattD: odpowiedzi na Stack Exchange są licencjonowane na licencji Creative Commons Uznanie autorstwa-Na tych samych warunkach 3.0 Unported, więc tak, możesz. Przeczytaj też pokrewny post na moim blogu: Obliczanie czasu i kosztów: Dlaczego zawsze popełniamy błąd? , a także odpowiedzi na moje pytanie tutaj: programmers.stackexchange.com/q/158640/6605
Arseni Mourzenko

Dlaczego w tym wpisie na blogu nie ma części 4, 5, 6 itd.?
Radu Murzea,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.