Pytanie:
Mój pierwszy niezależny projekt zajął mi dwa razy więcej czasu niż szacowano - Jak mam postępować?
user20914
2014-06-04 01:48:56 UTC
view on stackexchange narkive permalink

Jako mój pierwszy niezależny projektant graficzny w & (mam 19 lat) zgodziłem się stworzyć aplikację internetową dla lokalnego agenta ubezpieczeniowego.

Praca zajęła mi 4 miesiące, podczas gdy szacowałem, że pierwotnie 1-2 miesiące. Każdego miesiąca pokazywałem swoje postępy, ale nadal szacowałem, jak szybko zakończę każde spotkanie, nie przewidując wielu problemów, na które napotkam w procesie tworzenia. Agent ubezpieczeniowy nie wyraził werbalnego niezadowolenia z czasu, jaki zajęła mu praca, ale jego odpowiedzi są krótkie i zwięzłe, a ja denerwuję się, co on myśli o tak długim czasie.

Nie jestem pewien, jak mam sobie poradzić z tą sytuacją po tak długim czasie pracy. Ten właściciel firmy jest dobrze znany w moim mieście i może potencjalnie prowadzić do znacznie większej liczby transakcji, jeśli będzie zadowolony z moich usług.

Chcę wiedzieć, jak mam postępować, aby zachować profesjonalizm i zrobić wszystko, co w mojej mocy, aby naprawić moje błędy i uzyskać dobrą ocenę od tego pracodawcy dla wszystkich potencjalnych pracodawców w przyszłości.

Oto szczegóły, które biorę pod uwagę:

  • Wyjaśniłem, że to moja pierwsza pełnowymiarowa aplikacja internetowa i nie jestem pewien ram czasowych. Szacowałem 1-2 miesiące.

  • Obliczyłem cenę aplikacji na podstawie czasu, który oszacowałem, że praca zajmie bardziej doświadczonemu programistowi, aby nie obciążać go wyższymi kosztami mój brak doświadczenia. Wyceniłem pracę na połowę kwoty, którą szacowałem, że inni niezależni programiści pobraliby łącznie 2000 USD za zaprojektowanie i rozwój aplikacji internetowej obsługującej Chrome.

  • Nie rozliczam się za faktycznie spędzony czas (nawet za blisko), ale za wcześniej określoną kwotę.

  • Ta umowa została zawarta w dobrej wierze, z brak warunków umownych. Właściciel firmy zna mojego ojca, który zapoznał mnie z tą możliwością rozwoju, więc było to odpowiednio bezpieczne.

  • Jestem niezłym projektantem, który przywiązuje ogromną wagę do innowacyjnej funkcjonalności interfejsu, wizualnej "perfekcji" i wydajnego kodu. Innymi słowy, aplikacja jest dobra. Naprawdę dobry. Zgodziłem się aktualizować i utrzymywać aplikację za darmo, z wyjątkiem tego, że hosting jest płatny.

  • Zaproponowałem bezpłatną dodatkową funkcję, klienta do przesyłania wiadomości, aby (miejmy nadzieję) utrzymać jego zadowolenie z mojego braku doświadczenia.

Jak mam postępować, na przykład przeprosić za opóźnienie, zignorować je itp.? Tak jak jest teraz, mogę otrzymać negatywną ocenę reputacji po 3-4 nieudanych szacunkach daty zakończenia (powinienem był zostawić otwartą datę mety, ale popełniłem błąd i nadal szacowałem datę zakończenia).

http://creativemornings.com/talks/mike-monteiro--2/1
** \ * komentarze usunięte \ *** Pamiętaj [do czego służą] (http://workplace.stackexchange.com/help/privileges/comment)
Uwaga dodatkowa: Twój klient prawdopodobnie nie zdawał sobie sprawy z konsekwencji „przyjazności dla Chrome” - może się to zmienić, gdy zda sobie sprawę, że IE nie działa ...
Wydaje się, że to pytanie nie dotyczy nawigacji w miejscu pracy. Zamiast tego brzmi to jak pytanie dla freelancera. W przyszłości mamy do czynienia z witryną [Freelancing SE] (http://freelancing.stackexchange.com) poświęconą problemom z freelancerami. Powodzenia i dziękujemy za udział.
@jmort253 Czy niezależny SE jest w tym momencie za młody na migrację?
Hej @jt0dd, Rozważałem to, ale 10 odpowiedzi zagłuszyłoby jakąkolwiek szansę, że członkowie tej raczkującej społeczności byliby w stanie wnieść znaczący wkład, zwłaszcza w obliczu wyniku +113 Wesleya Longa. Gdybyśmy to wcześniej zawiesili, prawdopodobnie rozważałbym migrację. Powinno być jednak bezpieczne, ponieważ generalnie nie usuwamy postów ocenionych pozytywnie, nawet jeśli są one niezwiązane z tematem. Jeśli uważasz, że coś jest bez odpowiedzi, co byłoby lepiej tam zaadresowane, możesz ponownie zapytać na Freelancing SE, ale pamiętaj, aby dostosować post do tej społeczności, bez wklejania kopii. :) Mam nadzieję że to pomoże!
Proszę również zwrócić uwagę na [Prawo Hofstadtera] (https://en.wikipedia.org/wiki/Hofstadter%27s_law).Chyba chodzi mi o to, że zdarza się to na tyle, nawet najlepszym, że ma swoją własną humorystyczną stronę wiki.Nie zniechęcaj się faktem, że trwało to dwa razy dłużej - w pewnym sensie już spełniasz standardy branżowe!
Dziesięć odpowiedzi:
Wesley Long
2014-06-04 02:06:19 UTC
view on stackexchange narkive permalink

Witamy w tworzeniu oprogramowania.

Zasada 1: Klienci nigdy nie wiedzą, czego chcą lub potrzebują w projekcie. Gdyby tak było, byliby kierownikami projektów. Wiedzą, jak wykonywać swoją pracę, a nie budować narzędzia do wykonywania swojej pracy. W większych projektach istnieje cała profesja znana jako „analityk biznesowy”, która to wymyśla.

Zasada 2: Klienci będą tworzyć nowe wymagania w trakcie całego projektu, głównie ze względu na zasadę 1 chcesz mieć jasno zdefiniowane i mierzalne wymagania i rezultaty na piśmie.

Zasada 3: Te zmieniające się wymagania są tym, co tworzy lub psuje większość projektów. Upewnij się, że masz jasno zdefiniowany proces zmiany wymagań, w tym dostosowanie ceny i harmonogramu dostaw jako warunek akceptacji żądań zmiany.

Zasada 4: Te kwestie dotyczą znacznie bardziej zarządzania projektami niż ich dotyczą Twoje umiejętności jako programisty. Właśnie dowiedziałeś się, jaka jest różnica.

Zasada 5: Nikt przy zdrowych zmysłach nie oczekuje, że 19-latek będzie w stanie zarządzać projektem, zwłaszcza pierwszym projektem, i mieć czas szacunki są prawidłowe. Fakt, że była to tylko dwukrotność początkowych szacunków, jest w rzeczywistości imponujący.

Powiedziałeś, że ukończyłeś projekt zgodnie z ustaleniami, bez zmiany ceny. To była dobra decyzja. Kredą to do doświadczenia.

Powiedz klientowi: „Zrobiłem kiepsko oszacowanie ilości pracy w tym projekcie, ale uważam, że wykonałem bardzo dobrą robotę przy rzeczywistym produkcie. Nie zmieniam naszych uzgodnionych - za cenę z powodu mojego błędu. Mam nadzieję, że jesteś zadowolony z gotowego produktu i mam nadzieję, że będę mógł Cię wykorzystać jako punkt odniesienia w przyszłości. ”

Jeśli chodzi o wizualną „perfekcję” - przy każdym projekcie musisz zdecydować, czy jest to praca „portfolio”, czy praca polegająca na opłacaniu rachunków. Na przykład: zacząłem karierę jako inżynier dźwięku. Pracowałem trochę za darmo dla kilku młodych zespołów, których nie wstydziłbym się przesłać do jakiejkolwiek wytwórni. Wykonałem płatną pracę przy reklamach dealerów samochodowych, które brzmiały mniej więcej tak: „Załóż mu mikrofon w toalecie, a ja przepuszczę go później przez kompresor”, ponieważ musiałem dokończyć robotę i otrzymać wynagrodzenie tego dnia. Wygląda na to, że zrobiłeś portfolio. Jeśli możesz tego używać jako takiego, zrób to i bądź szczęśliwy.

Pamiętaj - Twoim głównym celem jest poprawa. Masz 19 lat. Masz dziesięciolecia, aby być lepszym w pracy. Nie zniechęcaj się.

** \ * komentarze usunięte \ *** Pamiętaj [do czego służą] (http://workplace.stackexchange.com/help/privileges/comment)
Byłem pod wrażeniem tego, jak niesamowicie wnikliwe było to, biorąc pod uwagę, jak zwięzłe jest.Myślę, że powinna to być lektura obowiązkowa dla każdego początkującego programisty
Underdetermined
2014-06-04 02:52:52 UTC
view on stackexchange narkive permalink

Właśnie dodałem konto, aby dać Ci moje dwa centy. Krótko mówiąc, nie martw się zbytnio. Wesley Long dał ci bardzo dobrą radę / powody, dla których sytuacja, w której się znajdujesz, jest całkowicie akceptowalna.

Chcę dodać do tego inną perspektywę: Nie sprzedawaj się zbyt krótko!

Jeśli ukończenie zajmie Ci dwa razy więcej czasu, być może masz stworzyli coś o większej wartości. Nie da się dokładnie ocenić, ile taki rozwój jest wart, zwłaszcza dla klientów, którzy nie znają technologii stojącej za tym, co robisz. W takim samym stopniu polegają na twojej prezentacji, aby ocenić wartość pracy, jak na własnych doświadczeniach z przeszłości.

Twoje podejście do przedstawiania wyników ma znaczenie! Wiąże się z tym również dużo psychologii. Dla mnie czerwoną flagą była obietnica bezpłatnych funkcji dodatkowych . Moim zdaniem wszystko to obniża wartość Twojej ogólnej pracy.

Nie znam Twojej branży ani tego, co konkretnie zrobiłeś, ale widziałem, że znacznie większe projekty oferują znacznie mniej wyników, inne są o wiele większe niż wielokrotności pierwotnych szacunków.

Nie zalecam, abyś skupiał się wyłącznie na prezentacji i sprzedaży kawałków, zaniedbując swoje rzeczywiste umiejętności rdzenia, świat ma dość tych ludzi. Pamiętaj tylko, że przez całą karierę będziesz musiał się nieustannie sprzedawać. Jedna część to wytwarzanie najnowocześniejszego produktu, a druga sprawia, że ​​klient zdaje sobie z tego sprawę.

dyesdyes
2014-06-04 14:50:35 UTC
view on stackexchange narkive permalink

Byłem w takiej samej sytuacji kilka lat temu.

Oszacowałem projekt 3 miesiące na około 25 godzin tygodniowo, a po 5 miesiącach średnio 35 godzin tygodniowo.

Twoja decyzja była dobra. Nie powinieneś obciążać klienta opłatami za własny błąd.

Ponadto dodanie kilku funkcji za darmo jako rekompensaty jest właściwym sposobem prowadzenia działalności.

Nie t sprzedaj się tanio

Ale jedną rzeczą, na którą musisz uważać, jest niedopłacanie. Pierwszy duży projekt, który wykonujesz, jest zawsze trudny, a zatem niedopłacanie nie stanowi problemu. Ale 2000 $ za 2 miesiące pracy nie wydaje się po pierwsze sprawiedliwe (choć zależy to od tego, ile czasu w tygodniu planowałeś przeznaczyć na to).

Oszacowanie projektu to ciężka praca i to przyjdzie z czasem. Niektórzy mówią, że musisz pomnożyć przez Pi swoje oszacowanie, aby faktycznie uzyskać właściwy, ponieważ będziesz mieć wiele nieoczekiwanych problemów, trochę testów itp ...

Nie zrób długoterminowe zaangażowanie za darmo

Myślę, że Twoim jedynym prawdziwym błędem jest bezpłatne utrzymywanie strony internetowej. Konserwacja jest pełną częścią działalności i zaangażowanie się w jej bezpłatne utrzymanie prawdopodobnie stanie się później dla Ciebie kłopotem.

Re: Długoterminowa konserwacja, każdą ofertę wiecznie bezpłatnych aktualizacji i konserwacji postrzegałbym jako oznakę braku doświadczenia i nie miałbym zaufania do takiej oferty.
ero
2014-06-04 14:18:30 UTC
view on stackexchange narkive permalink

Właściwie Twoje pytanie w dużej mierze odpowiada samo sobie. Już postąpiłeś dobrze:

  1. Dostarczono produkt wysokiej jakości
  2. Nie naliczyłem nic za dodatkowy czas spędzony
  3. Dodano dodatkową funkcję jako rekompensatę

Ponieważ twój klient nie wyraził żadnego niezadowolenia, są szanse, że uważa, że ​​poradziłeś sobie z tym właściwie. Krótkie i zwięzłe odpowiedzi nie muszą oznaczać, że jest zły. Najprawdopodobniej oznacza to, że ma obowiązki, traktuje 3 tuziny e-maili dziennie, więc nie poświęca czasu na rozpoczęcie swoich wiadomości od „Hej stary, jak się masz? Miałeś miły weekend?”.

Jeden ostatnia rzecz: nie bądź dla siebie zbyt surowy. Szacowanie nakładu pracy nad projektem to umiejętność, którą można nabyć tylko z doświadczeniem. Nie jest to łatwe i jest pracą samą w sobie zwaną kierownikiem projektu. Będziesz w tym lepszy.

Giacomo1968
2014-06-06 03:04:16 UTC
view on stackexchange narkive permalink

Już wybrałeś odpowiedź, a niektórzy niejasno tego dotykają, ale sprowadza się to do czegoś naprawdę prostego:

Niezależnie od tego, jak prosty lub złożony może być projekt, musisz mieć kontrolę nad strukturą swojego projektu od samego początku.

Im mniej planujesz, tym bardziej wpadniesz w niekończący się cykl rozwoju. Musisz wyznaczyć jasne granice, aby klient otrzymał to, czego chce. &, a Ty dostaniesz to, czego chcesz.

W rzeczywistości, jeśli ta osoba cię nie zna, szanse na uzyskanie dodatkowych opłat w tym momencie są zerowe. To powiedziawszy, może to być przypadek, w którym po zakończeniu tego projektu można mówić: „Cóż, ten ostatni projekt miał problemy. Jeśli chcesz pracować ze mną nad nowym projektem, oto co musimy zrobić ”. To znaczy wykorzystać tę porażkę do przyszłych sukcesów!

To powiedziawszy, zajęło mi dziesięciolecia, zanim udoskonaliłem sposób radzenia sobie w takich sytuacjach. Ale logicznie rzecz biorąc, sam musisz podzielić sprawy w ten sposób.

  1. Jakie są Twoje mocne strony. Nie okłamuj się w tej kwestii. Pracuję głównie w światach administracji systemów Unix / Linux. & Cały czas spotykam programistów, którzy chwalą się, jak świetnie radzą sobie w tworzeniu pełnego stosu. Bujda. Większość programistów internetowych jest dobra w projektowaniu front-end, niektórzy bardziej w programowaniu front-end, niektórzy bardziej w tworzeniu backendu, inni w tworzeniu struktury DB, a niektórzy są dobrzy w administrowaniu systemami. Ale naprawdę nie możesz być mistrzem wszystkich tych umiejętności. Chodzi o to, że jeśli ktoś zwróci się do Ciebie w sprawie projektu, najprawdopodobniej będzie chciał, abyś był wszystkim powyższym plus kierownikiem projektu. Czy jesteś gotowy, aby wziąć na siebie tę odpowiedzialność? Od samego początku musisz po prostu powiedzieć: „Cóż, widziałeś, że zrobiłem X. I myślisz, że twój projekt to X. Ale w rzeczywistości jestem Y. Mogę ci pomóc, ale musisz zdać sobie sprawę z moich mocnych stron &.”
  2. Zanim cokolwiek innego utwórz papierkową robotę: podziel projekt na fragmenty. Punkty listy punktowanej. Na przykład projekt tworzenia stron internetowych można podzielić na: odkrywanie, architekturę informacji, makiety, projekt wizualny & projekt funkcjonalny. Wyraźnie zaznacz, że każdy punktor to odrębna sprawa. I bądź przygotowany na takie rzeczy, jak: „Musimy przedyskutować to na późniejszym etapie, być może w tym momencie…”
  3. Utwórz oś czasu. Zwykle podczas wykrywania można oszacować ogólny czas trwania projektu, w tym kamienie milowe, cele &. Wyjaśnij klientowi, że stanie się to wtedy, a to nastąpi później. Osobiście lubię ustalać minimalny okres na cokolwiek na tydzień. Więc dla prostych poprawek 1-2 tygodnie. W przypadku przeprojektowania witryny, 3-6 miesięcy.
  4. Czynnik konserwacyjny. Konserwacja powinna zawsze być oddzielną sprawą od głównego projektu & wynegocjowanego jako taki. Nie pozwól, aby Twój podstawowy cykl rozwoju kiedykolwiek przerodził się w utrzymanie kodu.
  5. Strategia wyjścia. Najbardziej podstawową istniejącą strategią jest klasyczny podział 50/50. Oznacza to, że gdy już jesteście zadowoleni ze siebie & na gole, poproście o 50% z góry. Wyjaśnij, że żadna praca nie zostanie wykonana, dopóki nie zostanie otrzymane 50%. Wyjaśnij również, że jeśli z jakiegoś powodu czujesz, że musisz zrezygnować z projektu, zatrzymaj pierwsze 50% &, a nie otrzymasz drugich 50%. Dzieje się to znacznie częściej, niż się spodziewasz. I nie powinieneś się wstydzić powiedzieć: „Słuchaj, to nie działa. Muszę to powstrzymać. ”
  6. Kto otrzymuje opiekę nad dziećmi (aka: kod): Zdefiniuj również, co może wiązać się z wyjściem z domu zgodnie z kodem. Czy masz na myśli niedopieczony kod? Czy też dajesz klientowi &, mówiąc: „To jest praca, którą wykonałem do tej pory. Przekaż to komuś innemu ”. To trudna decyzja. Generalnie nie uważaj się za zastrzeżone w stosunku do zakontraktowanego kodu.
  7. Miej sojuszników programujących. To kolejna wspaniała rzecz. Zasadniczo zawsze łącz się z innymi programistami. A jeśli zaczniesz męczyć się projektem, nie martw się, prosząc jednego z pozostałych programistów o przejęcie go za Ciebie. To powiedziawszy, wielu programistów nie chce przejmować cudzych bólów głowy. Ale z drugiej strony - wracając do mocnych stron - z tego, co wiesz, inny programista może mieć umiejętności, w których są mocne, a ty w tym słaby. Możesz więc stworzyć zespół, który będzie komplementował się nawzajem nawet w przypadku jednego prostego projektu.
  8. Nie bierz biznesu do siebie. Wszystkie powyższe punkty mają na celu uświadomienie, że jesteś zawarcie transakcji biznesowej, więc nie powinieneś podejmować żadnej z tych decyzji osobiście. Więc jeśli klient zachowuje się jak palant, & próbuje wyciągnąć z ciebie więcej, niż się zgodziłeś? Po prostu im to wskaż. Nie akceptują tego? Odchodzić. A jeśli jesteś zdenerwowany? Zgadnij co? Wszyscy jesteśmy zdenerwowani nieudanymi projektami. Wybierz się na spacer po bloku. Wyrzuć to ze swojego systemu. Ale odbij się. Ludzie chcą cię ze względu na twoje umiejętności &, powinieneś traktować swoje umiejętności jako towar.

Stwórz także realistyczne granice. Pracowałem jako wolny strzelec przez ponad 10 lat w &, ilekroć wspomniałem, że od niechcenia ludziom przychodzi mi do głowy każdy szalony pomysł, który ktoś mi rzucił, jakbym szukał pracy. Ogólnie społeczeństwo postrzega freelancerów jako sprawy charytatywne. Najlepszą rzeczą, jaką zrobiłem, aby zatrzymać ten niekończący się strumień „wspaniałych pomysłów”, było zagranie na pełny etat. Ale jeśli wrócę do pracy jako freelancer, moim podejściem jest po prostu powiedzieć na samym początku: „Słuchaj, muszę po prostu powiedzieć, że tak naprawdę nie szukam teraz pracy”.

pawel-kuznik
2014-06-06 17:46:52 UTC
view on stackexchange narkive permalink

Dobra rada. Nigdy nie mów klientowi, kiedy nadejdzie produkt końcowy. Zamiast tego narysuj im oś czasu, ile czasu zajmie każdy element. Podziel swój projekt na fazy lub moduły i prezentuj je za każdym razem, gdy osiągnie stabilny stan. Zbierz informacje na temat każdego etapu i modułu i bądź uczciwy wobec klienta w kwestii dodatkowych kosztów. Bądź elastyczny. Twoi klienci również to docenią, ponieważ chcą dopasowanego rozwiązania.

Również dobrze jest podać szacunkowy lub podstawowy koszt projektu na początku, ale także poinformować ich, że dodatkowe funkcje będą kosztować więcej i przedłużać projekt.

Taki przepływ pracy zapewni również bardziej stabilne relacje z klientami i zbuduje większe zaufanie w relacjach z nimi.

Ponadto:

  • Dlatego nie nie obciążaj ich za własne błędy. To jest bardzo złe i pozostawi po sobie zły smak po zakończeniu.
  • Zostaw dobrą dokumentację o swoim projekcie. Zarówno dla klientów, jak i dla przyszłych opiekunów (najprawdopodobniej to będziesz Ty, więc bądź dobry dla siebie).
  • Opuszczając projekt, możesz im zasugerować, jakie ulepszenia można by zastosować w projekcie. (bądź szczery)

PS. W przypadku pierwszego projektu nadal można podwoić potrzebny czas. Będziesz lepszy w szacowaniu kolejnych projektów, więc bądź na bieżąco.

Vidar S. Ramdal
2014-06-05 21:28:43 UTC
view on stackexchange narkive permalink

W przypadku pierwszego projektu nie sądzę, żebyś zrobił tak źle. Trudno to stwierdzić bez znajomości zaangażowanych osób, ale jeśli klient nie wyraził niezadowolenia i jest prawdopodobne, że jest zadowolony z efektu końcowego, myślę, że można założyć, że jest szczęśliwy.

Jeśli chodzi o to, jak należy postępować, inni odpowiadający udzielili dobrych rad, jak komunikować się z klientem. Teraz powinieneś pomyśleć o tym, jak możesz wykorzystać te doświadczenia w swoich następnych projektach.

  • Upewnij się, że Ty i klient jesteście po tej samej stronie, co do tego, jaka praca ma być wykonana - napisz jasna specyfikacja
  • Dowiedz się, jak zamknąć projekt - jak powiedzieć klientowi, że Twoja praca jest wykonana, a jeśli chce czegoś więcej, pobierasz za to opłatę.
  • Czasami, będziesz musiał odrzucić część swojego perfekcjonizmu. Tak, poświęciłeś trochę czasu na napisanie czystego i wydajnego kodu, ale czy klient naprawdę się tym przejmuje? Jeśli wchodzisz w zbyt wiele szczegółów, ponownie zawalisz swoje szacunki.
  • Nigdy nie oferuj ciągłej, bezpłatnej konserwacji - może to powrócić i Cię ugryźć, jeśli Ty i Twój klient nie nie mieć jasnego zrozumienia, co obejmuje „konserwacja”.
  • Jeśli w przyszłości zauważysz, że utrzymanie tego pierwszego projektu zajmie zbyt dużo czasu od innych prac, nie bój się powiedzieć klientowi, że musisz nadać priorytet innej (płatnej) pracy.

Powodzenia w karierze!

Kaz
2014-06-06 02:18:55 UTC
view on stackexchange narkive permalink

Klient nic nie powiedział o opóźnieniu, prawdopodobnie dlatego, że aplikacja jest bardzo dobra (jeśli wierzymy na słowo), stała cena była dobrą okazją, a upływ czasu był bezpłatny.

Jeśli denerwujesz się tym (lub czymkolwiek innym), dobrą strategią jest, abyś był osobą, która pierwsza o tym poruszy.

„Chociaż wydajesz się jestem zadowolony z projektu, a także czuję się dobrze z jakością, żałuję, że nie przewidziałem dokładnie czasu, jaki zajmie jego ukończenie. Szacowanie projektu oprogramowania jest szeroko rozumiane jako trudne; będę pracował nad doskonaleniem tej umiejętności z każdym nowe doświadczenie zawodowe. Mam nadzieję, że spóźniona dostawa nie wpłynęła negatywnie na Twoją firmę. ”

Jeśli najpierw poruszysz cokolwiek, zawsze zachowujesz lepszą pozycję, a nawet przewagę. Kiedy druga strona o tym wspomina, często pojawia się utrzymujący się sens, zarówno postrzegany, jak i rzeczywisty, tak jakby sprawa była wprowadzana, „wydaje się, że nie przywiązujesz dużej wagi do tego, co następuje, ale Chciałbym porozmawiać o… ”.

nie wydaje się to oferować niczego istotnego w porównaniu z punktami poruszonymi i wyjaśnionymi w poprzednich 5 odpowiedziach
@gnat oferuje mniej TL; DR.
Trudno mi zrozumieć, jak _less / tldr_ jest zgodny z ** [Back It Up and Don't Repeat Others] (http://meta.workplace.stackexchange.com/questions/255/faq-proposal-back-it -up-and-dont-repeat-others) **
Galadrius Krunthar
2014-06-06 04:32:18 UTC
view on stackexchange narkive permalink

Projekty IT są niezwykle trudne do oszacowania, wystarczy spojrzeć na wszystkie duże publiczne projekty informatyczne (zwłaszcza w Wielkiej Brytanii), które wielokrotnie przekroczyły swój harmonogram i budżety.

  1. Staraj się nie akceptować kolejnego projekt ze stałą ceną, dopóki nie zbadasz „punktów funkcyjnych” (to nie jest liczba funkcji w Twoim kodzie…) i jak pisać umowy o pracę w oparciu o punkty funkcyjne.
  2. Ponieważ dopiero zaczynasz, prawdopodobnie będzie musiał zaakceptować kilka projektów o stałej cenie. Praktyczna zasada, która przydała mi się do szybkich szacunków: jeśli uważasz, że zajmie to określoną ilość czasu, podwoj to i dodaj kolejne 10%. Prawdopodobnie nadal będziesz lekceważyć, ale nie tak źle. Inżynierowie zwykle zbyt wąsko koncentrują się na tym, jak rozwiązać problem i zawsze pomijają wszystkie rzeczy, które mogą się nie udać, i nie uwzględniają wszystkich pomocniczych elementów, które są również ważną częścią dostawy (np. Dokumentacja, konfiguracja systemu i konfiguracja, testowanie, szkolenie ...). Ponadto, jak już wspominali inni ludzie, projekt nigdy nie jest jasno określony na początku, niezależnie od tego, jak jasną wizję ma klient. Zawsze są stosy rzeczy, które nie są dobrze zdefiniowane i wymagają dalszej pracy, aby je opracować, i zawsze są dodatkowe funkcje, o których klient myśli później i naturalnie zakłada, że ​​zrobisz to za darmo w ramach umowy o stałej cenie (patrz punkt 1).
  3. Zaakceptuj, że stracisz pieniądze na tych początkowych projektach i potraktuj je jako doświadczenie edukacyjne.
  4. Zapoznaj się z prawem umów w jurysdykcjach, w których pracujesz. W niektórych miejscach, jeśli ktoś wykwalifikowany w danej dziedzinie dokonuje oszacowania, szacunek ten nie może być większy niż 20-30% od rzeczywistego czasu / kwoty, nawet jeśli dodatki do umowy zostały wynegocjowane i dodane do umowy na żądanie klienta. Jeśli te dodatki się nagromadzą, będziesz musiał renegocjować i podpisać całą umowę od podstaw, w przeciwnym razie klient będzie miał prawo odmówić zapłaty czegokolwiek powyżej kwoty początkowej + 30%.
  5. Upewnij się, że dokonujesz regularnych DOSTAW ( nie tylko pokazuj klientowi postępy), tak jakbyś nie zaakceptował dostaw po terminie, może odmówić Ci czegokolwiek.

I jak już wspomniano w kilku innych odpowiedziach, jest to NAPRAWDĘ zły: „Zgodziłem się aktualizować i utrzymywać aplikację za darmo, z wyjątkiem tego, że hosting jest odpłatny”.

NIGDY nie powinieneś obiecać nikomu wieczystej bezpłatnej, nieograniczonej i NIEZDEFINIOWANEJ usługi. Mam nadzieję, że nie zapisałeś tego na piśmie.

Vector
2014-06-06 13:36:49 UTC
view on stackexchange narkive permalink

Nie ma potrzeby „przepraszać”. IMO, który jest zdecydowanie nieprofesjonalny, chyba że klient wyraźnie popycha Cię do ściany w tej sprawie.

Jeśli tak się stanie, nie próbuj się z tego wykręcać, po prostu przeproś, że nadal jesteś początkującym i starałeś się jak najlepiej, ale nie masz jeszcze doświadczenia w dokonywaniu dokładnych szacunków czasu . Nie wdawaj się w długie wyjaśnienia i wymówki. Mów krótko, na temat i profesjonalnie.

Oferowanie „dodatków” jako rekompensaty za opóźnienie może nie być takim dobrym pomysłem, jak wspominali inni: To zwykle obniża cenę i sprawia, że ​​wydajesz się nieco zdesperowany (nigdy nie jest to dobra rzecz), skupia się z powodu braku doświadczenia i naraża Cię na niekończące się prośby o „wolne pszczoły” itp. Ale to, co zostało zrobione, zostało zrobione. Unikaj tego w przyszłości.

Nie naliczałeś opłat w oparciu o czas, byłeś z nimi szczery i uczciwy od samego początku, a cenę pracy ustalałeś na podstawie swojego doświadczenia. Więc myślę, że masz dobry początek. Jeśli dostarczyłeś solidnie działający produkt, nie sądzę, żebyś musiał się zbytnio przejmować. Klient może wydawać się niecierpliwy, ale jeśli wykonałeś dobrą robotę, wkrótce zostanie uspokojony, gdy będzie cieszyć się owocami twojej pracy.

Na przyszłość: dopóki nie będziesz naprawdę dobry w szacowaniu czasu dostawy (to zajmuje trochę czasu, a często nawet eksperci popełniają błędy w tej kwestii) trzykrotnie lub czterokrotnie (przynajmniej ...) liczba, która wydaje Ci się realna.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...