Pytanie:
Projekt, do którego zostałem zatrudniony, nie trafia w porę ze względu na ciągle zmieniające się wymagania, teraz jestem na miejscu
ajf-
2018-06-06 22:00:44 UTC
view on stackexchange narkive permalink

Zostałem zatrudniony jako programista frontendowy, aby opracować zaplecze administracyjne dla dobrze prosperującego europejskiego startupu. Wstępne oszacowanie, jakie mieli na myśli, to 6 miesięcy, co było właściwe. To 3-osobowy zespół składający się z CEO / Właściciela, programisty Backend i programisty Frontend.

Zaraz po tym, jak zostałem zatrudniony, poprosili mnie, abym zamiast tego skupił się na testowaniu ich aplikacji. Wymagało to znacznych zmian strukturalnych, aby wspierać ramy testowe i zajęło mi około 2 i pół miesiąca.

Platforma administracyjna, jak pierwotnie przewidywano, była typu „edycji na żywo”, więc w tym momencie stworzyłem komponenty, które znajdowały się we frameworku frontendowym, które miały obsługiwać tę funkcjonalność. Wraz ze zostaniem jedynym administratorem opracowanej przeze mnie uprzęży testowej zajęło mi to około 2 miesięcy.

Potem zakres się zmienił i stał się pełnowartościowym panelem administracyjnym. Pod względem struktury jest to zasadniczo inne i wymaga oddzielnej platformy. Opracowanie podstawy do tego i utrzymanie wcześniejszej pracy, którą wykonałem, zajęło mi około 1 miesiąca.

Przenieśmy się o 6 miesięcy do przodu, a nie jesteśmy nawet blisko ukończenia projektu, do którego zostałem zatrudniony. Mamy co najwyżej bazę, a oni bardzo się niepokoją. Stali się bardziej „praktyczni”, prosząc o codzienne spotkania na stojąco. Zaczęli też nie ufać moim zaleceniom, kierując projekt w kierunkach, które moim zdaniem nie powinny być przestrzegane, ale nic nie mówię. Poprosili mnie również o skrócenie godzin pracy i szybszą dostawę oraz zmniejszyli komunikację ze mną.

Ponieważ jestem wolnym strzelcem, który otrzymuje oceny i recenzje za pracę, wyraźnie widzę, że są sfrustrowani i staram się pomóc i współpracować, nawet jeśli biorąc pod uwagę moje doświadczenie, widzę, że projekt nie idzie w najlepszym kierunku, ale obawiam się, że biorąc pod uwagę ich złe doświadczenia ze mną, wystawią mi złą recenzję, a to obniży moją reputację, więc staram się przestrzegać. Czuję, że po prostu podążanie za ich wskazówkami bardziej zaszkodzi projektowi, co z kolei wpłynie na mnie jeszcze bardziej.

Czy jest sposób, aby zmienić tę sytuację?

Co mówi Twoja umowa o przypadku zmiany zakresu?Jeśli twój pierwotny teleskop był na 6 miesięcy, a teraz zakres jest znacznie większy, nie możesz winić.
Nie określiliśmy.To doraźny kontrakt i właśnie odbyliśmy spotkanie przed rozpoczęciem.Pracuję dla nich na godziny jako frontend developer, tyle mówi nasza umowa.Reszta to porozumienie werbalne.
Więc oprogramowanie NIE jest gotowe i NIE dlatego, że nie możesz go przetestować, ale z powodu ich prośby o usunięcie 1/2 programistów z rozwoju.Jak to jest twój problem?
Ciekawe, gdzie dadzą ci złą ocenę
Wygląda na to, że zostałeś zatrudniony jako programista, a nie menedżer, a to jest duży problem z zarządzaniem projektem.Chociaż zawsze powinieneś ujawniać potencjalne problemy (w końcu jesteś ekspertem), jeśli nie jesteś kierownikiem projektu, to błędy w zarządzaniu nie są twoją winą.
Czy „* skrócenie godzin pracy *” oznacza mniejszą liczbę godzin pracy lub mniejsze ładowanie w ciągu godziny?Wydaje mi się, że to pierwsze bardziej przypomina ten pierwszy, ale ten drugi wydaje się lepiej pasować do kontekstu.
Możliwy duplikat https://workplace.stackexchange.com/questions/112823/contractor-faced-with-scope-screep-should-i-fulfill-none-some-or-all-client-r
Ostatnie 2 bloki TLDR: _ «[G] Zważywszy na moje doświadczenie widzę, że projekt nie zmierza w najlepszym kierunku, [oni] zmierzają w kierunku, w którym uważam, że nie powinien być przestrzegany, po prostu ślepo podążając za ich kierunkiembardziej zaszkodzi projektowi, ale nic nie mówię.Ponieważ jestem freelancerem, który otrzymuje oceny i recenzje za pracę, obawiam się, że [...] wystawią mi złą recenzję, a to obniży moją reputację, więc staram się przestrzegać. »_ Widzisz problem?Jeśli hydraulik / organizator wesel / mechanik samochodowy zrobiłby to dla Ciebie, czy chciałbyś, aby byli „zgodni”, czy z góry?
@PeterTaylor Przeczytałbym tutaj: „* obniż moje godziny *” tutaj jako „* wykonaj tę samą pracę w mniej godzin *”.Co w dużym stopniu obejmuje poprzednie, ale ponieważ OP nie może tego zrobić, aby utrzymać jakość, skutecznie może to skutkować drugim.
* Zawsze * błędem jest zakładanie, że przewidywany czas potrzebny na zmianę oprogramowania jest niczym innym, jak tylko przypuszczeniem.Kiedy jest pisany, każdy program jest pisany po raz pierwszy (przynajmniej z perspektywy osoby, która go pisze).Szansa, że jakaś nieprzewidziana trudność opóźni ukończenie, wynosi * nigdy * zero.Wykonywanie „szacunków” realizacji czasu realizacji, które okazują się konsekwentnie optymistyczne, i myślenie, że można to naprawić „cięższą pracą”, jest cechą charakterystyczną głupiego zarządzania.
Osiem odpowiedzi:
Old_Lamplighter
2018-06-06 22:14:04 UTC
view on stackexchange narkive permalink

DOKUMENTUJ WSZYSTKO

Za każdym razem, gdy następuje zmiana zakresu, wykonaj następujące czynności:

  • Udokumentuj zmianę.
  • Pokaż wpływ, jaki będzie to miało na twoją pracę
  • Prześlij nową oś czasu
  • Poproś udziałowców o podpisanie kontraktu

Skala zakresu ale jedynym sposobem, aby uniknąć bycia tym, który ponosi winę, jest udokumentowanie wszystkiego, zademonstrowanie efektu, nakłonienie ludzi do podpisania się, aby mieć ślad na papierze

Rozumiem, jak to może mnie chronić w przyszłości, ale jak to będzie konstruktywne w obecnej sytuacji?Czy sugerujesz, abyśmy cofnęli się o krok i ponownie zarysowali projekt?W irracjonalnym stanie, nie spodoba im się widok, że projekt prawdopodobnie zajmie kolejne 6 miesięcy
@AlainJacomet To jedyna opcja.Będzie im się spodobał, że projekt będzie się ciągnął bez końca i bez powodów, dla których będzie o wiele mniej, niż gdyby mieli przed sobą szczegóły.To profesjonalna sprawa.
@Alain Jacomet za późno.Palce są już spiczaste.Możesz postarać się zrozumieć jak najwięcej i być elastycznym, ale powiedz jasno, że nie możesz pracować więcej, niż jesteś w stanie wytrzymać.
Poza tym, aby przedłużyć odpowiedź, ** nie rzucaj się w wir **.Nie zaczynaj opracowywać rzeczy, które nie zostały jeszcze sfinalizowane w dokumencie lub są niczym więcej niż pomysłem, który jest pływający.Nie pracuj nad dokumentem, który może zmienić się w trakcie opracowywania.Kiedy zaczynam zadanie, biorę ** lokalną ** kopię dokumentu, aby temu zapobiec.Wszelkie wprowadzone zmiany muszą być wyraźnie zgłoszone / udokumentowane, w przeciwnym razie nie odpowiem na nie.To skutecznie wymaga od innych dokumentowania rzeczy (które dotyczą ciebie), co rozszerza ideę dokumentowania wszystkiego samodzielnie.
@AlainJacomet: Najlepsze, co masz, to odtworzenie wydarzeń krok po kroku, aby wyjaśnić, dlaczego termin się wydłuża.Na przykład: (1) Chciałeś [tego].Miało to być zrobione do [wtedy].(2) Następnie powiedziałeś, że chciałeś [tego].To wydłuża termin [czas].(3) Następnie zmieniłeś rozwój w kierunku [tamtych].Zmiana istniejącego kodu, aby pasowała do tego, zajmie co najmniej [czasu] (i tak dalej ...).To wyraźnie pokazuje, że zmiana terminów wiąże się ze zmianą wymagań.Musisz wyjaśnić im to połączenie.
** Prześlij nową oś czasu ** To najważniejsza część, za każdym razem, gdy masz zadanie zrobić coś * inaczej * lub * nowego *, dostosuj oś czasu / terminy i wyjaśnij interesariuszom, jakie są konsekwencje.
Myślę, że tę odpowiedź można by poprawić, kładąc większy nacisk na to, dlaczego tak ważne jest dostarczanie nowych zaktualizowanych szacunków.Z mojego doświadczenia wynika, że kiedy ludzie proszą o zmiany, myślą, że będzie to zamiennik 1: 1 tego, o co prosili wcześniej.Rzadko zdają sobie sprawę, że to, o co proszą, będzie oznaczało więcej pracy.Musisz to od razu pokazać, aby nie mówili rzeczy typu * ', gdybyś mi powiedział, że za pierwszym razem nie prosiłbym cię o zmianę tego' *
+1 Dokładnie to, co chciałem powiedzieć.Projekty kończą się niepowodzeniem i nieufność wkrada się z powodu braku komunikacji.Dokumentując wszystko i dobrze komunikując, pełzanie zakresu nie byłoby tak nieoczekiwane.
@ajf- to nie skończy się dobrze dla Ciebie.Wolny strzelec nie może zrobić jednego i drugiego.Nie są w stanie podać klientowi oszacowania czasu, a także wystawić faktury godzinowej.Jeśli powiesz, że zadanie zajmuje 10 godzin.Jeśli skończysz za 9 godzin?Klient oszczędza 1 godzinę na kosztach.Zgodzili się zapłacić za 10, ale zapłacili tylko za 9. Jeśli powiesz, że zadanie zajmuje 10 godzin, a kończysz za 11 godzin.Klient skarży się, że przepłacił o 1 godzinę.W każdym razie masz przerąbane.Kiedy freelancer rozlicza się za godzinę.Powinno brzmieć „jestem tutaj, robię, co chcesz, i liczę na godzinę, ryzyko jest teraz Twoim problemem”.
Brythan
2018-06-07 11:43:10 UTC
view on stackexchange narkive permalink

Mea culpa

Myślę, że odpowiedź @ Neo jest na dobrej drodze, ale nie zgadzam się z implementacją. Rozważ

Odkąd tu jestem, popełniłem kilka błędów. Jednym z pierwszych dużych było to, że kiedy powiedziałeś mi, żebym opracował wiązkę testową dla tej aplikacji, nie nalegałem, abyśmy ustalili zakres tej zmiany. Wtedy po prostu zgodziłem się, że uprząż testowa to dobra rzecz i poszedłem dalej. Zajęło to dwa i pół miesiąca. Utrzymanie go również kosztowało X miesięcy.

Nie zdając sobie sprawy z tego błędu, kiedy kazałeś mi przejść z „edycji na żywo” do pełnego panelu administracyjnego, powtórzyłem to. Nie nalegałem na określenie zakresu zmiany. Spędziliśmy kolejny miesiąc na wprowadzaniu tej zmiany.

Nie mogę dalej popełniać tego samego błędu. Odtąd oczekuj aktualizacji osi czasu za każdym razem, gdy zostanie zaproponowana zmiana. Oto sytuacja w obecnym stanie rzeczy ...

Następnie wyjaśnij, ile czasu zajmie ukończenie bieżącego zestawu zadań zgodnie z aktualnymi wymaganiami. Jeśli proponują nowe zmiany, wyjaśnij, jak zmienią tę oś czasu. Wyjaśnij również, co się stanie, jeśli nie wprowadzisz tych zmian teraz, a zamiast tego dokonasz ich później. Możesz to zrobić nawet ze zmianami, o które prosili, ale których nie zaimplementowałeś.

Kontynuuję to, co tu powiedziałeś, więc być może brakuje mi części osi czasu. Jeśli tak, upewnij się, że wypisujesz im te części (tak naprawdę nie musimy ich widzieć, chyba że potrzebujesz pomocy, aby o nich mówić).

Zaletą tego podejścia jest to, że bierze na siebie winę. Prawdopodobnie zgadzają się, że popełniłeś błędy, więc zaczynasz od porozumienia. I nie wskazuje palcami poza tobą. Podkreśla problemy i ostatecznie prowadzi do rozwiązań.

Nie zapomnij uwzględnić w tym bieżącej konserwacji uprzęży testowej. Jeśli zajmuje to połowę czasu, powiedz im o tym. Mogą albo przenieść pracę z dala od ciebie (albo z przodu, albo z uprzęży testowej), albo żyć z dłuższym harmonogramem.

Jeśli nie powiesz im realiów sytuacji, nadal będziesz mieć ten sam problem.

Idąc dalej

Kiedy to czytam, naprawdę rzuca się na mnie uprząż testowa. To dwa i pół miesiąca z sześciomiesięcznego okresu, nawet przed konserwacją. Dlatego powiedziałem X. Nie wiem, co to jest X, ale wygląda na to, że był ważny. Jeśli od tego czasu spędziłeś na nim choćby pół miesiąca, stał się on większością twojego pierwszego półrocza i prawdopodobnie większością twojego czasu, jeśli było więcej. Naprawdę musisz to określić ilościowo.

Dowiedz się, ile czasu zajmie wykonanie oryginalnego projektu z tego miejsca. Może z dodatkowymi dzwonkami i gwizdkami, które już dodałeś. Nie musisz niczego wyjmować. Ale gdybyś nie dodał niczego innego, czego nie było w pierwotnych wymaganiach, jaki byłby twój harmonogram? Następnie pokaż im, jak nowsze wymagania wpływają na ten harmonogram. Następnie pokaż im, jak ich obecne sugestie wpłyną na harmonogram. Nigdy nie musisz mówić nie, ale powiedz im, ile czasu dodają.

Mogą mieć Agile lub Waterfall. Nie mogą mieszać i dopasowywać. Agile akceptuje zmieniające się wymagania, ponieważ system zawsze działa na jakimś poziomie. Więc wszystkie wymagania są albo w bieżącym sprincie, albo nie istnieją. Waterfall próbuje od razu zaplanować cały projekt. Oznacza to, że za każdym razem, gdy zmienią się wymagania czasowe, musisz zmienić cały harmonogram. Teoretycznie kierownik projektu powinien sobie z tym poradzić, ale w praktyce, jeśli tak się nie dzieje, jest to część Twoich obowiązków jako wykonawcy. Musisz zarządzać swoim harmonogramem.

Weź również pod uwagę możliwość, że część pracy, którą obecnie planujesz wykonać w interfejsie użytkownika, może być zamiast tego wykonana na zapleczu. Jeśli tak, powinieneś oszacować, ile czasu to zajmie. Pozwól programistom zaplecza oszacować, ile czasu zajmie kodowanie w zapleczu. Niech menedżer wybierze, gdzie lepiej to zrobić. Nawet jeśli zajmuje to więcej czasu na zapleczu, nadal może to mieć sens, jeśli jesteś dalej w tyle, a programista zaplecza obecnie na ciebie czeka.

Możliwe, że programista zaplecza powinien przejąć wiązkę testową. Jeśli jest tylko dwóch programistów i zajmuje to zbyt dużo czasu, nie ma wielu innych opcji. Byłoby znacznie lepiej, gdybyś mógł skupić się na swoim oryginalnym projekcie. Jeśli programista zaplecza czekał na Ciebie, w międzyczasie daje to pracę.

Ta odpowiedź daje mój głos.Inne odpowiedzi mówią wiele dobrych rzeczy o tym, jak zapobiec wystąpieniu scenariusza opisanego w pytaniu w przyszłości, ale ta znacznie więcej wyjaśnia, jak postępować * teraz *, aby przejść od obecnego scenariusza do tego, w którymmożna zastosować inne odpowiedzi.
Przy większej liczbie ofert (każda z niezależnym błędem oszacowania) jest bardziej prawdopodobne, że kupujący wybierze taką, która zaniża wymagany nakład pracy.Więcej ofert (czy to więcej niż jedna oferta na jeden problem lub oferty na zbiór problemów) oznacza wyższy współczynnik obciążenia, aby to uwzględnić.Ale +1, to dobrze zrobione.
Wraz z ponoszeniem odpowiedzialności za swoje czyny, uwalniasz się od domniemanej winy, której oni mogą nawet nie być świadomi.Ułatwiasz wzięcie odpowiedzialności za to, co zrobili;ma tendencję do zachęcania innych stron do „stracenia czujności”
To jest świetne.Jak powiedział anaksymander, nie tylko odnosi się do unikania go w przyszłości, ale daje natychmiastowe działanie w celu poprawy.Jedną z rzeczy, o których wspominasz, jest idea Waterfall vs. Agile.Dotykasz tego, ale myślę, że przejście na Agile (lub system podobny do Agile) byłoby dużym krokiem w kierunku poprawy obecnej sytuacji.Daje im większą kontrolę, przejrzystość i informacje zwrotne na temat statusu projektu.Dodałem odpowiedź, aby zagłębić się w to bardziej szczegółowo.
@Brythan OP powinien skonsultować się z prawnikiem przed przyjęciem jakiejkolwiek winy.w zależności od umowy i kraju może to mieć poważne konsekwencje w zakresie kar umownych i odpowiedzialności w przypadku utraty przez klientów zysku itp. z powodu przekroczenia terminu przez OP.Rozsądniej jest nie grać w grę polegającą na obwinianiu i zachować neutralność w określaniu okoliczności prowadzących do zaistniałej sytuacji oraz przedstawianiu natychmiastowych rozwiązań.
Neo
2018-06-06 22:13:47 UTC
view on stackexchange narkive permalink

Czy jest sposób, bym mógł zmienić tę sytuację?

Myślę, że masz tu trochę kłopotów, ponieważ nie wydaje mi się to ty poradzili sobie ze swoimi oczekiwaniami .

Najlepszą rzeczą, jaką możesz zrobić w późnej fazie gry, jest udokumentowanie całego scenariusza , w tym linia czasu , tak jak u nas. Czasami klienci mają krótkie wspomnienia i przypominają sobie tylko bezpośrednią (teraz) lub krótkoterminową przeszłość. Wątpię, czy pamiętają, o co prosili cię kilka miesięcy temu.

Przypomnij im

Upewnij się, że podczas przeliterowania pracy zanotowałeś każdą decyzję, która spowodowała, że ​​musiałeś radykalnie zmienić architekturę.

Poza tym nie jestem pewien, co jeszcze można zrobić.

Na przyszłość

Upewnij się, że dokumentujesz wszystko, co robisz , a jeśli masz prośbę o zmianę (zmianę w pierwotnym oświadczeniu o pracy), pamiętaj, aby udokumentować zmianę i wpływ na oś czasu .

Nikt nie lubi osoby, która zaczyna wskazywać palcami i mówić „to nie moja wina”, kiedy coś się pali.Jeśli już, chciałbym zrobić coś produktywnego.
@AlainJacomet W ogóle nie proponuję wskazywania palcem, a jedynie nakreślenie tego, co zostało uzgodnione i * wpływ * na zmiany, o które prosił klient.Jaką inną opcję masz w tym momencie.(Kontrola obrażeń, jeśli chcesz)
Kontrola uszkodzeń brzmi właściwie, być może w połączeniu z innymi punktami, które nakreśliłeś.
@AlainJacomet Byłem tam, zrobiłem to.W moim przypadku nie mogłem znaleźć innego sposobu na uratowanie tego.
@AlainJacomet Mała poprawka.Nikt nie lubi osoby, która twierdzi, że „to nie moja wina”, gdy coś się pali * ORAZ *, gdy ten argument jest * bezcelowy *.Na przykład, gdy jest oczywiste, kto jest winą lub wszyscy są winni.Ale jeśli argumentujesz, że „to nie moja wina” i jest to naprawdę istotne, nie ma znaczenia, że ktoś będzie temu przeciwstawiał się estetycznie.
agemO
2018-06-07 10:59:02 UTC
view on stackexchange narkive permalink

ale nic nie mówię

Czy to nie jest duża część pracy programisty, zwłaszcza freelancerów?

Twoi menedżerowie nie są deweloperzy, nie potrafią odróżnić dużych zmian wymagań od lżejszych ani dobrych (z punktu widzenia programisty) kierunków od złych kierunków (nadal mogą mieć dobre powody marketingowe, aby wypróbować te kierunki na przykład).

Za każdym razem, gdy omawiasz nowe rzeczy do zrobienia, musisz powiedzieć im, ile czasu to zajmie (lub jak nieprzewidywalny jest to czas), nawet jeśli nie pytają .

Dokładnie!Pytający wydaje się zaniepokojony harmonogramem i budżetem.Ktoś, kto ponosi jakąkolwiek odpowiedzialność za te tematy, nie może mieć nadziei na osiągnięcie w nich dobrych wyników bez udzielenia wskazówek.
Kilisi
2018-06-07 01:58:42 UTC
view on stackexchange narkive permalink

Musisz zrobić kontrolę uszkodzeń, ponieważ moim zdaniem wiele z tego jest twoją winą.

Powinieneś był zarządzać zmianami szybciej lub upewnić się, że było jasne, że 6 miesięcy nie będzie już obowiązywać, jeśli chcieli zrobić coś innego. Zamiast tego po prostu zebrałeś pieniądze, obserwując odlatujące ramy czasowe.

Czy jest sposób, aby zmienić tę sytuację?

Opcja 1: Wykonaj pracę i przestań się bawić.

Opcja 2: Poinformuj ich o ramach czasowych opartych na rzeczywistości, powodach, dla których oryginał nie zostanie spełniony i przejdź dalej. Inteligentni ludzie zrozumieją, mogą nie być szczęśliwi lub pod wrażeniem, ale zrozumieją.

Jako freelancer Twoja reputacja jest największym atutem, musisz być lepszy, lepiej zorganizowany, szybszy i bardziej profesjonalny niż zwykle aby zbudować reputację, czasami oznacza to pracę kilka dodatkowych godzin za darmo w sytuacjach presji.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/78646/discussion-on-answer-by-kilisi-project-i-was-hired-for-is-off-the-szyny-ze-do-c).
@Jon Komentarze zostały przeniesione, a nie usunięte.Nie mamy możliwości ich selektywnego przenoszenia.Rozszerzone dyskusje w komentarzach prawie zawsze prowadzą do przeniesienia całego zestawu.Moglibyśmy selektywnie cofnąć usunięcie niektórych z tych komentarzy, ale powinno być ku temu ważny powód.Ponadto nie należy oczekiwać, że komentarze pozostaną na zawsze.Wyskakujące okienko sugeruje pozostawienie komentarza w celu * ulepszenia postu *, a nie w celu wyjaśnienia głosów przeciw.PO wyraźnie zauważył sugestię i zdecydował się nie zmieniać odpowiedzi.Komentarz jest zatem nieaktualny.Nie jestem pewien, dlaczego chcesz, żeby się trzymał.
Artelius
2018-06-07 08:07:52 UTC
view on stackexchange narkive permalink

Mówiąc bez ogródek, jeśli to Twoja wina, w końcu albo uderzysz w swoją reputację, albo na swój portfel.

Jako profesjonalista jesteś na ogół oczekuje się, że będziesz w stanie podać rozsądne szacunki dotyczące czasu pracy i natychmiast powiadomić pracodawcę, jeśli harmonogram przestanie być realistyczny.

Nie twierdzę, że jesteś wyłącznie winny, ale jeśli tak coś, co naprawdę powinieneś był im powiedzieć 4 miesiące temu, a następnie Ty popełniłeś błąd, który kosztuje ich ich . A im dłużej milczysz, tym gorsza sytuacja.

To powiedziawszy, jak rozumiem, w zespole jest już programista Frontend i Backend, który również powinien mieć rozsądne pojęcie o wpływie zmian zakresu. Wygląda więc na to, że wszyscy panikują i uciskają innych, a może po prostu ufają sobie bardziej niż tobie, więc cię ściskają.

Należy pamiętać, że często, gdy wszyscy są Podkreślił, że ludzie całkowicie tracą synchronizację i całkowicie błędnie interpretują to, co robią inni. Na przykład, być może to, co postrzegasz jako „ręce”, to chęć szybkiego pokonania przeszkód, a to, co postrzegasz jako „osłabienie komunikacji”, to po prostu wszyscy w pośpiechu. Z tego samego powodu mogą przyjmować rzeczy, które robisz w niewłaściwy sposób. Rozwiązaniem tych problemów jest KOMUNIKACJA.

Co bym zrobił

Jest to oparte na szeregu założeń, które robię na temat sytuacji, więc dostosuj je w razie potrzeby.

Po pierwsze, szybko wymyśliłbym realistyczny harmonogram projektu na papierze i ustaliłbym maksymalny czas, w którym możesz pracować, i minimalne pieniądze, które zaakceptujesz, jeśli alternatywą będzie utrata pracy i bardzo zła recenzja. Potrzebujesz takich liczb w swojej głowie, ponieważ sprawy mogą szybko wybuchnąć w procesie negocjacji. I dowiedz się, czy bardziej martwią się o budżet, czy o harmonogram, jeśli możesz.

Następnie wejdź do środka i powiedz „Chłopaki, ten projekt oczywiście wszystkich stresuje. Czy możemy po prostu cofnąć się o krok i spokojnie o nim porozmawiać? . ”

Jeśli odmówią, powiedz im, że chociaż nadal będziesz dokładać wszelkich starań, nie możesz teraz spełnić ich oczekiwań, ponieważ jest za dużo pracy i za mało czas.

W przeciwnym razie możesz porozmawiać z nimi o projekcie. Nie bądź konfrontacyjny. Podkreśl, że rozumiesz , że istnieje złożona presja biznesowa i ostateczne decyzje należą do nich, ale przedstaw to, co Twoim zdaniem jest najlepszym sposobem działania z Twojego punktu widzenia. Jeśli rzucą Ci zakrzywioną piłkę (np. Funkcja, której nie masz pewności, ile czasu będzie to potrzebne), powiedz im, że będziesz musiał się jej przyjrzeć, zanim będziesz mógł potwierdzić, że jest realistyczna.

Co najważniejsze , przedstaw rozwiązania , a nie problemy. Zamiast „Nie powiedziano mi o bla”, powiedz „Czy mógłbyś poinformować mnie o bla w przyszłości?”

Reputacja byłaby uderzona, dokładnie w oczach ** kogo **?Wielu programistów widziało źle zarządzane projekty, więc rozpoznaliby jeden, gdyby nawet usłyszeli kilka pierwszych jego objawów.
@mathreadler "Och, nie zatrudniaj tego freelancera. Powiedział nam, że wykonanie naszego projektu zajmie 6 miesięcy, a naprawdę zajęło to 1,5 roku!".Większość freelancerów pracuje dla klientów, a nie bezpośrednio dla innych programistów.Pierwszą rzeczą, jaką powinien nauczyć się freelancer, jest to, że nie jest tylko programistą.
@Voo można łatwo odpowiedzieć na to pytanie, „cóż, wymagania były ciągle zmieniane, więc oczywiście szacowany czas zakończenia również się zmienił”
@mathreadler Oprócz tego, że deweloper nie poinformował klienta o zmianie ram czasowych * przed * jej wdrożeniem (błąd, który został szczegółowo omówiony, więc nie warto się nim zajmować), chodzi o to, że jako freelancer żyjesz z ust do ust.Gdyby potencjalny klient rozmawiał z Twoim byłym pracodawcą i słyszał powyższe zdanie, nigdy nie miałbyś szansy mu tego powiedzieć, ponieważ klient trafiłby do jednego z kilkudziesięciu bezpośrednich konkurentów.
@Voo czy klient po prostu zakłada, że zmiany w wymaganiach nie powodują zmian w szacowanym czasie zakończenia?Cóż, myślę, że wtedy to się zaczęło ...
@mathreadler Zanim to zrobiłem, nigdy nie pracowałeś bezpośrednio z żadnymi nietechnicznymi klientami.Jeśli firma cię zatrudnia, powinieneś być ekspertem.Zadaniem klienta nie jest zdobycie wystarczającej wiedzy technicznej i zrozumienia podstawy kodu (jak to w ogóle działa?), Aby móc oszacować, ile czasu powinno zająć wdrożenie nowych funkcji.[Jeśli spędzasz więcej czasu z nietechnicznymi użytkownikami, przekonasz się, że bardzo trudno jest im oszacować, co jest trudnym problemem, a co nie] (https://xkcd.com/1425/).
Ostatecznie to po prostu nie ma znaczenia.Jako wolny strzelec żyjesz i umierasz ustnie.Nie ma znaczenia, czy ta poczta pantoflowa jest dokładna, czy nie - biorąc pod uwagę, ile osób wykonuje tego rodzaju pracę, jeśli ktoś usłyszy o tobie złą opinię, wybierze jednego z dziesiątek twoich konkurentów.
Mogą mieć trudności z oszacowaniem trudności technicznych lub czasu realizacji rzeczy, @Voo,, ale w ich interesie powinno być również uzyskanie informacji o tym.Tak, powodzenia w znajdowaniu ludzi, którzy potrafią robić to samo.
Robert R.
2018-06-08 01:02:37 UTC
view on stackexchange narkive permalink

Napisałeś: „Nie sprecyzowaliśmy. To umowa ad hoc i właśnie odbyliśmy spotkanie przed rozpoczęciem”

To jest Twoja główna przyczyna. Jest wystarczająco dużo pracy, aby jakikolwiek hit z tego projektu spowodował tylko drobne problemy dla ciebie, IMO. Co więcej, wiele firm również rozumie, jak to się stało, i nie wini cię za to.

Pamiętaj, że chociaż mają wpływ na twoją reputację, masz wpływ na to, że wydali dużo pieniędzy i czasu na to i wydałby więcej na kogoś innego. Nauczyłeś się też lekcji planowania. 80% projektu powinno być w fazie planowania, a 20% w trakcie realizacji.

Nauczyłeś się, jak korzystać z dobrej umowy w pracy kontraktowej i dopóki spełniasz zobowiązania umowne, nie powinieneś martwić się o swoją reputację. Dopóki spełniasz swoje wymagania, grozi im niebezpieczeństwo, jeśli wystawią ci niskie oceny lub recenzje.

Krótko mówiąc, stwórz dobry kontrakt i zrób prawdziwe spotkania dotyczące planowania! Możesz się z tego odzyskać, ale teraz musisz zrobić to we właściwy sposób, czyli chronić siebie i swojego klienta, korzystając z umowy i prawdziwego planu krok po kroku, który obejmuje wszystko, od ogólny pomysł na dokładne rozmieszczenie elementów okna.

Mimo to z mojego doświadczenia uznałbym tę lekcję dobrą lekcją i poszukałbym nowego startu w innym miejscu, z pominięciem moich brył.

Lub zastosuj bardziej zwinną metodologię i unikaj etapu planowania, ale zastąp go stałymi cyklami komunikacji.
Jonathan
2018-06-07 23:37:07 UTC
view on stackexchange narkive permalink

Chciałbym trochę rozwinąć odpowiedź Brythana. Jednym z poruszonych punktów, ale przemilczonym, było użycie Waterfall lub Agile. Z twojego opisu poważnie wątpię, że używają Agile, az opisu ich firmy prawdopodobnie nawet nie wiedzą, co to jest. Mam zamiar napisać swoją odpowiedź, zakładając, że ktokolwiek ją czyta, nie jest zaznajomiony z Agile (lub Waterfall w tym przypadku). Przynajmniej może to być pomocne w wyjaśnianiu firmie, co chcesz zrobić, ponieważ Agile może być złożona, szczególnie jeśli są przyzwyczajeni do Waterfall. Co jeśli nie jesteś zaznajomiony z tym terminem, Wodospad to stary „zaplanuj wszystko na początku, daj całemu ramy czasowe i módl się, aby nic nie poszło źle i że zgadłeś dokładnie zajmie to „metoda zarządzania projektem.

Na przykładzie tego, co powiedzieć w odpowiedzi Brythana, zmieniłbym końcowy akapit na coś takiego:

W starając się uniknąć takiej sytuacji w przyszłości i aby zapewnić większą przejrzystość projektu, chciałbym zaproponować, co następuje:

Najpierw co dwa tygodnie mieliśmy spotkanie, aby zdecydować, co należy w ciągu następnych dwóch tygodni. Przedstawię listę zadań, które nadal wymagają wykonania, i wspólnie możemy zdecydować, jaki jest priorytet i co rozsądnie mogę osiągnąć w ciągu tych dwóch tygodni. Pod koniec dwóch tygodni mieliśmy mieć kolejne spotkanie, aby zademonstrować, co zostało ukończone, abyś mógł się podpisać.

Zazwyczaj proces dzielenia projektu na „zadania” (lub Historie użytkowników, jak nazywa je Agile) jest wykonywany przez Ciebie i kierownika projektu, ale być może będziesz musiał sobie z tym poradzić samodzielnie. Podziel je na części, które można ukończyć w ciągu dwóch tygodni lub krócej. Pod koniec tych dwóch tygodni każde zadanie powinno być czymś, co możesz zademonstrować firmie jako w pełni działający element. Czasami to, co tworzysz, nie jest czymś, co faktycznie możesz dostarczyć samodzielnie, ale nawet wtedy spróbuj znaleźć sposób na wyświetlenie tej funkcji. Chodzi o to, że widzą postęp.

Ponadto chciałbym mieć codzienne spotkanie, nie dłuższe niż 15 minut, w celu omówienia codziennych postępów. W ten sposób zawsze możesz dokładnie wiedzieć, jaki jest stan projektu, a jeśli pojawią się jakiekolwiek problemy, można je natychmiast rozwiązać.

Jest to bardzo podstawowa implementacja Agile, ale Znaczna poprawa w stosunku do Waterfall i zapewnia właścicielom projektu natychmiastową i ciągłą informację zwrotną na temat tego, gdzie jest projekt.

Wodospad byłby dla nich znacznie lepszy - wydaje się, że nie wiedzą dokładnie, czego chcą, a duże zmiany, nawet przy użyciu Agile, w ograniczonym czasie nigdy nie działają.Wodospad zmusiłby ich do przemyślenia, a tego naprawdę brakuje.
@gbjbaanb to źle.Zwinność byłaby znacznie lepsza do odkrywania i zrozumienia.Problemem OP jest to, że nie zaktualizował ich na czas, jaki zajęłoby wykonanie zadań, ponieważ zmienili oczekiwania.Waterfall po prostu zagwarantowałby, że ludzie, którzy go zatrudnili, byli niezadowoleni z produktu.Naprawdę jest to po prostu niefortunny błąd związany ze zwinnością.
@Steve na 6-miesięczny projekt, wiedząc, czego chcesz, jest ważniejsze niż umiejętność dostosowania się do zmian - nie masz wystarczająco dużo czasu na zmiany w tym czasie, biorąc pod uwagę to, co powiedział OP.Oczywiście, jeśli płacisz za dzień ... ale wydaje się, że projekt płaci więcej freelancerów.
@gbjbaanb chcieli, żeby zmniejszył swoje godziny pracy, więc wygląda na to, że płacą za godzinę.Problem z tym, co sugerujesz, polega na tym, że za 6 miesięcy zbudujesz klienta to, o co prosił, a nie to, czego chce lub potrzebuje.
Oba wymagają zdefiniowania zakresu na początku.W przypadku Agile wszystkie funkcje powinny być zbudowane od samego początku i na ich podstawie można tworzyć historie użytkowników.Więc ten argument jest nieistotny.Ale wodospad wymaga, abyś był w stanie przewidzieć przyszłość.Równie dobrze możesz oprzeć swoje szacunki na kartach tarota lub liściach herbaty, będą prawie tak samo dokładne.Nawet przy w pełni zdefiniowanym, niezmiennym zakresie trudno jest przewidzieć dokładny czas trwania tak dużej ilości pracy.Chociaż Agile może pomóc.Jeśli podzielisz wszystkie historie na historie nadające się do sprintu, znacznie łatwiej będzie to oszacować.
@Steve na pewno, ale jako freelancer Twoim zadaniem jest budowanie tego, o co proszą, za to Ci płacą, a jeśli zbudujesz coś innego, jest szansa, że nie dostaniesz zapłaty (nawet jeśli tego chcieli).To do nich należy ustalenie, czego potrzebują, i mogą ponownie zatrudnić Cię, aby zrobić to ponownie, jeśli zechcą.
@gbjbaanb Masz rację, ale to marnuje znaczne zasoby.Czuję, że agile to lepsze podejście.Myślę, że właśnie dlatego piszemy kod funkcjonalny i obiektowy.


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 4.0, w ramach której jest rozpowszechniana.
Loading...