Po pierwsze: witamy w tej małej rzeczy, którą lubię nazywać „prawdziwym życiem”.

Programiści zawsze powtarzają, że zanim zaczniemy projekt, wszystkie wymagania powinny być w pełni określone, począwszy od szczegółowych opisów algorytmów do wyświetlania makiet, a po rozpoczęciu prac rozwojowych nie należy zezwalać na żadne zmiany. Kiedy produkt zostanie dostarczony, oczywiście naprawimy wszelkie odstępstwa od pisemnych wymagań, ale żadne zmiany, które pociągają za sobą zmianę wymagań, są dozwolone.

Tak, to znacznie ułatwiłoby życie programistom . A to absurdalne żądanie.

Wyobraź sobie, że chcesz kupić samochód. Więc idziesz do sprzedawcy samochodów i okazuje się, że to tylko biuro z jednym facetem za biurkiem. Wręcza ci czystą kartkę papieru i mówi: „Zapisz tutaj dokładnie to, czego chcesz w samochodzie. Następnie znajdziemy samochód spełniający te wymagania i dostarczymy ci go. Gdy podpiszesz dokument, zaczniemy szukać dla samochodu, więc w tym momencie żadne zmiany nie są dozwolone ”. „Ale” - mówisz - „Mam ogólne pojęcie, czego chcę, ale z pewnością chciałbym wypróbować kilka różnych samochodów, zabrać je na jazdę próbną…” „Nie, przepraszam”, mówi: „To niemożliwe. Po prostu zapisz, co chcesz, a my kupimy Ci samochód spełniający te wymagania”.

A teraz przypuśćmy, że poza tym nigdy wcześniej nie prowadziłeś samochodu. Skąd możesz wiedzieć, czego chcesz, zanim spróbujesz? Rzeczy, które wydają się dobrym pomysłem na papierze, mogą nie działać tak dobrze w praktyce itp.

Nie martwiłbym się niejasnymi wymaganiami, POD warunkiem, że wszyscy zaangażowani rozumieją, że wymagania są niejasne, że Ty będą musieli wypełnić luki, a kiedy zobaczą podjęte przez Ciebie decyzje, będą pewne decyzje, które im się nie podobają i będą musiały zostać przerobione.

Jeśli jest to luźne i oparte na współpracy środowisko, nie powinno być problemu. Ty coś produkujesz, przynosisz do przeglądu, mówią ci, co im się podoba, a czego nie, wprowadzasz zmiany, może przechodzisz w wielu cyklach. Zrobiłem w życiu wiele, wiele takich projektów. Często użytkownik musi wypróbować oprogramowanie, aby zobaczyć, co działa w praktyce, a co nie.

Jeśli szef lub klient stawiają nieuzasadnione wymagania lub jeśli nie wiesz, jakie jest środowisko na przykład, musisz napisać coś na piśmie, aby się chronić. Zrobiłem w swoim życiu kilka projektów, w których szef lub klient mówi: „Nie wiem, jakie są wszystkie wymagania, po prostu coś wymyślasz”. Potem coś wymyślam, a kiedy to przywracam, krzyczą: „Co! Nie o to mi chodziło! Co z ciebie za kretyn? Z pewnością było oczywiste, że…”, a potem stawiają cały szereg wymagań nigdy wcześniej o tym nie wspominali i to wcale nie było dla mnie oczywiste. W tego rodzaju środowisku - nawet jeśli nie jest to krzyk i groźby zwolnienia cię lub anulowania umowy, może to po prostu wyraz poważnego rozczarowania i frustracji - w takim środowisku napisz artykuł opisujący, co zamierzasz zrobić oddaj im go do zatwierdzenia. Jeśli masz szczęście, doprowadzi to do dyskusji na temat rzeczywistych wymagań. W najgorszym przypadku mówią „tak, tak, cokolwiek” i odrzucają to. Ale przynajmniej w tym momencie, kiedy wrócisz z oprogramowaniem, jeśli powiedzą „Nie tego chcieliśmy”, możesz przynieść dokument i powiedzieć: „Och, przepraszam, to jest to, co uzgodniliśmy Powinienem to zrobić. Widzisz, jest napisane tutaj, a ty to zatwierdziłeś. " W przyjaznym środowisku mówisz to w przyjazny sposób; w nieprzyjaznym środowisku być może będziesz musiał wykazać się większą siłą. W każdym razie powiesz wtedy: „OK, więc jakie zmiany w wymaganiach chcesz wprowadzić?” Następnie zapisz je na piśmie i rozpocznij kolejny cykl.

Jeśli szef lub klient spodziewa się niemożliwych czasów zmiany i obwinia Cię, gdy niemożliwe wymagania nie zostaną spełnione, to szczerze mówiąc, czas zacząć szukać innej pracy lub innego klienta. Lub jeśli wystarczająco potrzebujesz tej pracy / klienta, wchłaniasz ją i znęcasz się. (Mam dobre wspomnienia z czasu, gdy mój szef zapytał mnie, ile czasu zajmie konwersja dużego, złożonego systemu, który nasza firma zbudowała lata temu, ze starego języka komputerowego na bardziej nowoczesny. Zacząłem się zastanawiać , wykonaliśmy takie tłumaczenie innego produktu, więc mieliśmy pewne doświadczenie, ale nikt w firmie nie znał dziś tego produktu, bla, bla, a potem powiedział: „Nie potrzebuję dokładnej odpowiedzi, tylko z grubsza : dwa dni? trzy dni? ”Byłem zdumiony.„ Umm, nie ”, powiedziałem,„ Pytanie brzmi, ile miesięcy ”. Odszedł, mamrocząc.)

Musisz się cofnąć. Uzyskaj czas w ich kalendarzach. Zadawać pytania. Zadawać dużo pytań. Zadawaj tyle pytań, że zmęczą się Tobą i podadzą szczegóły, których potrzebujesz.

Jeśli nie wiedzą, zaproponuj konkretne wymagania i poproś o potwierdzenie. Udokumentuj ich odpowiedzi i odeślij je z powrotem do potwierdzenia. To jasno pokazuje, że przyczyną zmian i opóźnień jest to, że zmieniają zdanie, a nie twój rozwój.

Kiedy mówią „zbuduj to po swojemu”, tak naprawdę mają na myśli „zrób coś, co mogę spójrz i zmień ”. O wiele łatwiej jest sprawdzić i zmienić wymagania przed ich wdrożeniem.

Ogólnie rzecz biorąc, gdy wymagania klienta są bardzo niejasne, powinieneś zapisać to, co zamierzasz zrobić (tj. specyfikacje techniczne i funkcjonalne) i poprosić ich o sprawdzenie dokumentu . W ten sposób, jeśli chcą coś zmienić w trakcie trwania projektu, można zaznaczyć, że nie jest to zgodne z ustaleniami i za to zapłacić. Co najmniej równie ważny jest fakt, że nie mogą cię winić za zrobienie tego „w niewłaściwy sposób”.

Jeśli twój projekt nie jest zbyt zaawansowany, nadal będę próbował to urzeczywistnić. Może się to wydawać stratą czasu na krótką metę, ale uchroni Cię przed wprowadzaniem zmian przez całe życie.

Jeśli prawie skończyłeś (oczywiście pomijając niekończącą się listę nadchodzących zmian), to jest to bardziej skomplikowane. Patrzysz tutaj na kontrolę uszkodzeń. Poproś swojego przełożonego, najlepiej pisemnie, aby to potwierdził. Nie chcesz być kozłem ofiarnym, jeśli projekt stanie się naprawdę chaotyczny.

Mówiąc wprost, wygląda to na słabe zarządzanie projektem. Chciałbym porozmawiać z menedżerem, aby uniknąć takiej sytuacji w przyszłości

Marv, myślę, że większość tych odpowiedzi to bzdury.

To nie jest rzeczywistość tworzenia oprogramowania. To efekt niewłaściwego zarządzania sklepem z oprogramowaniem.

Wymagania nie są odpowiedzią, ponieważ wymagania się zmieniają. Czy to dlatego, że ludzie, którzy się wylogowują, zmieniają zdanie, czy też nigdy nie mieli pojęcia, czego chcą w pierwszej kolejności, nie ma to znaczenia. Nawet sama firma może zmienić priorytety, zmuszając wymagania do zmiany.

Wydaje się, że tylko jedna osoba zasugerowała Agile. To dobry początek, ale Agile wymaga dużego zaangażowania wielu ludzi, ludzi, którzy muszą odrobić pracę domową. Najwyraźniej nie pracujesz z ludźmi, którzy nie chcą odrabiać lekcji.

Więc pożycz od Agile. Niech ci interesariusze uczestniczą w rozmowach, w których kierujesz tworzeniem historii ( http://www.mountaingoatsoftware.com/agile/user-stories). Zachowaj te definicje w ich języku, aby nie było niejasności co do tego, na co się zgodzili podczas przeglądu 3 miesiące później. Spodziewaj się rund tworzenia historii, początkowo utrzymując je na wysokim poziomie / szerokim i dzieląc je na mniejsze z czasem, gdy uznasz, że jest to konieczne. Mniejsze historie oznaczają dokładniejsze zakresy pracy i pomagają w rozwiązywaniu problemów.

Uzbrojeni w zestaw historii na tyle małych, aby umożliwić wygodne oszacowanie, możesz kierować harmonogramem i ustalaniem priorytetów w zakresie opracowywania projektu, niezależnie od ile interesariuszy pomaga lub nie. Upewnij się, że historie są przechowywane w przejrzysty sposób. A kiedy ludzie chcą, abyś odszedł od „pracy według historii”, wtedy odepchnij.

Makiety, propozycje, PoC, wszystko to jest w porządku, ale nawet one muszą pochodzić z zrozumienie tego, z czego będziesz zarabiać na życie. W przeciwnym razie po prostu kręci się w ciemności, wierząc, że pewnego dnia otrzymasz szczęśliwy traf. Weź problem za rogi i utwórz dla nich scenorys projektu, jeśli nie zrobią tego sami.

„Zawodzą wcześnie, często zawodzą.”

Kiedy masz minimalne wymagania, zbuduj minimalny system i pochwal się nim. Zademonstruj to i jego funkcje przez cały czas, a także poproś o informacje zwrotne, które zmienią Twoją trajektorię.

Tak, wielu programistów, takich jak Ty, chce nieskazitelnej specyfikacji, po czym przejdą do wieży, a niektórzy czas później pojawią się z poprawną implementacją, gotowe do przyjęcia następnego projektu.

Jednak dołączyłeś do firmy i zespołu, w którym zamiast tego oczekuje się, że będziesz działać przy minimalnym wkładzie, trochę pobiegać, wrócić z pytaniami i prezentacjami, i pobiegnij po trochę więcej.

Ten proces jest nieefektywny. Często jednak dyktują to wymagania biznesowe i potrzeby. Gdyby czekali na stworzenie doskonałej specyfikacji, projekt nie zostałby ukończony na czas, a mimo to i tak wymagałby modyfikacji, ponieważ nikt nie jest w stanie przewidzieć przyszłości.

Iteracyjny rozwój może nie być twoją filiżanką herbaty, ale jak się przekonasz, jest to o wiele, dużo bardziej powszechne niż doskonalenie specyfikacji.

Komunikacja, częste testy i opinie użytkowników / klientów / przełożonych oraz gotowość do walki z ciosami staną się świetnymi umiejętnościami mieć, jeśli je rozwiniesz.

Na początku projektu wiesz przynajmniej tyle, ile kiedykolwiek będziesz o nim wiedział. Konsumenci twojego projektu również wiedzą co najmniej, że kiedykolwiek o nim wiedzą.

Mogą dać ci placek z nieba ". Myślę, że powinien to zrobić, a oto jak chcę, żeby to zrobiło ”, ale istnieje prawdopodobieństwo, że będą się mylić, zwłaszcza w szczegółach.

Podobnie, jeśli weźmiesz projekt i przygotujesz ponad 2-miesięczny plan rozwoju, aby go wdrożyć, idź i pracuj nad tym, prawie na pewno nie będziesz postępować zgodnie z tym planem. Części będą trudniejsze lub łatwiejsze, niż myślisz, inne części okażą się bezcelowe, gdy do nich dojdziesz, a podczas pracy nad projektem zdobędziesz doświadczenie w tym projekcie.

A tygodnia będziesz miał lepsze pojęcie o planie i wiele poprawek. Po miesiącu prawdopodobnie pomyślisz, że Twój plan był głupi.

Twoi klienci / szefowie mają pojęcie, czego chcą. Nie są ekspertami w tym, co chcą zrobić: w najlepszym razie są ogólnikami, którzy wiedzą, jak rozwiązać podobne problemy, ale jedynym sposobem na zostanie ekspertem w tworzeniu oprogramowania jest jego stworzenie. Gdyby już stworzyli to oprogramowanie, nie potrzebowaliby cię.

Twoim zadaniem jest stać się ekspertem w tworzeniu tego oprogramowania. To, co na początku robi oprogramowanie, będzie niejasne. Oni tak naprawdę nie wiedzą, a ty tak naprawdę nie wiesz. Więc powtarzasz: ustalasz, czego Twoim zdaniem chcą, pytasz ich, czy wydaje się to rozsądne, wdrażasz i dostajesz coś przed nimi tak szybko, jak to możliwe. W zależności od tego, kim są, polerujesz różne części, a inne pozostawiasz niedokończone.

Następnie otrzymujesz opinię. Niektóre części przypadną im do gustu, inne będą uważać za śmieci, a inne za stratę czasu. Zaczynasz i zmieniasz oprogramowanie - może nawet wyrzucasz pracę i zaczynasz od nowa (ponieważ teraz twoja wiedza na temat pisania tej pierwszej części znacznie się poprawiła - właśnie to zrobiłeś i prawdopodobnie nauczyłeś się czegoś z tego) i otrzymujesz szybciej do tego samego punktu - a może po prostu go poprawiasz i dodajesz to, co im się podoba, i zmieniasz to, czego chcą.

Kiedy otrzymasz ich opinię, poproś ich, aby powiedzieli, czego chcą ulepszony. Zapisz to. Zapytaj o to, co jest ważniejsze (weź to na uporządkowanej liście). Powiedz, że wrócisz do nich z kosztorysami prototypów za dzień lub dwa. Zgadnij, ile czasu zajmie prototypowanie kilku najważniejszych funkcji, które chcą, zapytaj ich, czy zgadzają się z prototypem (NIE ukończoną wersją), który jest gotowy do pokazania im za X dni (dołącz bufor dla błędów) jednej z najlepszych Dwie rzeczy, których chcą.

Następnie pokaż im swój prototyp i zapytaj, czy chcą go ukończyć, czy usunąć z rozwiązania. W zależności od tego, kim są, możesz wyjaśnić, jak zachowuje się aplikacja, że ​​jest to prototyp. Do tego czasu powinieneś mieć już pojęcie, ile czasu zajmie wypolerowanie prototypu. Mogą poprosić o więcej zmian przed „wykończeniem” go lub o wypolerowanie. Jeśli proszą o więcej zmian, wróć do poprzedniej rzeczy, o priorytetach.

Jest to w zasadzie zwinność oparta na programistach, w której aktywnie angażujesz się w zawieranie umów z klientami / szefem. Często otrzymują prototypy i często są proszeni o przekazywanie informacji zwrotnych. Musisz się upewnić, że każdy prototyp może i zostanie usunięty, jeśli nie poprosi Cię o dopracowanie go, i że wiedzą, że Twoje prototypy nie są tak bliskie ukończonych funkcji.

W ten sposób Twoje doświadczenie w pisaniu aplikacji rośnie, a ich zrozumienie tego, czego naprawdę chcą, rośnie w miarę rozwoju aplikacji.

Jeśli z góry poprosisz o pełną specyfikację, decyzje zostaną podjęte zanim dowiesz się, co działa, a co nie.

Zespół oprogramowania potrzebuje nie tylko programistów, ale także inżynierów wymagań, testerów i kilku innych ról. Całkiem możliwe, że w małym zespole ta sama osoba nosi jednocześnie wiele czapek. Należy jednak pamiętać, że rola inżyniera wymagań wymaga innego zestawu umiejętności niż programisty. Jeśli spróbujesz stworzyć wymagania na ślepo, nie wiedząc, jak je wykonać, będziesz bardzo nieefektywny, zasadniczo kodując niewłaściwą aplikację przez większość czasu tworzenia, a następnie frustrując się, gdy będziesz musiał ją zeskrobać i zacząć od nowa.

Sugerowałbym, abyś zdobył część zestawu umiejętności potrzebnego inżynierowi wymagań. W swojej obecnej pracy będziesz lepszy w wykonywaniu zadań, z którymi zostałeś obarczony. W przyszłych zawodach, w których specyfikacja wymagań może być tworzona przez dedykowanego inżyniera wymagań lub w wyniku konsensusu w zespole lub wspólnie przez klienta, posiadanie tego zestawu umiejętności (który będzie współpracował z twoją czystszą rolą programisty) sprawi, że staniesz się bardziej wartościowy członka zespołu i pozwoli Twojemu zespołowi pracować wydajniej dzięki lepszej komunikacji z Tobą.

Najlepszym sposobem na rozpoczęcie jest obszerny podręcznik. Moim ulubionym jest Odkrywanie wymagań Iana Alexandra, bardzo praktyczny tekst, który jest łatwy do zrozumienia dla początkujących. Drugą lekturą na liście może być projekt interfejsu użytkownika Lauesena dla inżynierów. Tytuł może wydawać się przestarzały, ale to, czego się z niego dowiesz, jest teraz znane pod modnym hasłem UX, co jest obecnie zaletą w twoim CV. I nie, nie chodzi tylko o interfejs, ale obejmuje on wszystkie wymagania, które są dostrzegalne dla użytkownika (łącznie z pytaniem, jaką funkcjonalność uwzględnić).

Jednocześnie poinformuj swoich menedżerów, że to prawdziwa praca. Oznacza to, że 1) jeśli oczekują, że wykonasz pracę wymagającą 10 godzin analizy wymagań, masz tylko X-10 godzin na kodowanie. I 2) że, tak jak każdy inny proces, zamienia dane wejściowe w dane wyjściowe i musisz uzyskać dostęp do danych wejściowych, zanim będziesz mógł stworzyć specyfikację: w tym przypadku wszelkie informacje, które możesz uzyskać na temat przyszłego wykorzystania aplikacji z którym pracujesz. Nawet największy spec od RE nie może stworzyć dobrego pomysłu, jeśli nie ma dostępu do prawdziwych użytkowników. Książki powiedzą ci, do jakich źródeł potrzebujesz dostępu; postaraj się objąć jak najwięcej z nich.

Myślę, że sprowadza się to do edukacji klientów i kierownictwa.

Zmiany stają się droższe, im dalej przebiega projekt

Możesz zapoznać się z niemal każdym podręcznikiem inżynierii oprogramowania, aby uzyskać informacje o „względnych kosztach naprawy błędów na wykresie cyklu życia oprogramowania”. Zasadniczo mówi, że im dalej jesteś w projekcie, tym więcej kosztuje zmiana. Dlaczego więc nie naprawiałbyś problemów na etapie planowania, kiedy tylko możesz?

Code Complete wspomina, że ​​większość kosztów projektu jest w kodowaniu - więc jeśli potrzebujesz powtarzając to kilka razy, koszt twojego projektu może łatwo wymknąć się spod kontroli.

Zaplanuj wystarczająco, aby uwzględnić złożoność projektu

Istnieje kilka metafor właściwych dla inżynierii oprogramowania. Moim ulubionym jest budownictwo. W przeciwieństwie do budowania, ilość planowania nie musi być wyczerpująca - wystarczy, że wystarczy do złożoności produktu.

• Jeśli projekt jest banalny (jak budka dla psa ), możesz poprosić konstruktora, aby „po prostu go zbudował, możemy to zmienić później” i to jest w porządku. Zmiana jest łatwa.

• Jeśli budujesz dom, zwykle prosisz architekta, aby najpierw sporządził plany. Klient i architekt uzgadniają projekt przed budową domu. Po zaakceptowaniu planów konstruktor może rozpocząć. Nadal możesz poprosić konstruktora, aby po prostu to zrobił, ale przed rozpoczęciem będzie musiał naszkicować zgrubny plan, a naprawienie go będzie Cię kosztować znacznie więcej.

• Jeśli budujesz biurowiec, lepiej skorzystaj z usług architekta, bo inaczej się zawali. Jeśli niesamowicie wykwalifikowanemu budowniczym uda się stworzyć biurowiec bez planu, poproszenie go o dodanie piwnicy, ponieważ zapomniałeś o parkingu, jest albo bardzo drogie, albo całkowicie niemożliwe.

Nie potrzebujesz wyczerpującej i pełnej specyfikacji przed rozpoczęciem. Wystarczy, że wystarczy, aby sprawdzić, czy klient ma na myśli to, o czym myślisz.

Nie możesz budować szybciej niż planujesz

Klienci czasami sprzeciwiają się temu trwa zbyt długo. Moja odpowiedź na to brzmi: „Chcesz, żebyśmy zbudowali to szybciej, niż moglibyśmy to zaplanować? Planowanie jest szybsze, łatwiejsze i tańsze niż budowanie, więc jeśli nie sądzisz, że możemy to zaplanować w ciągu trzech miesięcy, to zdecydowanie możemy”. nie zbuduj go w trzy miesiące. ”

Jeśli planujesz wcześnie, błędne przekonania są tanie i łatwe do naprawienia. Jeśli tego nie zrobisz, późniejsze naprawianie problemów będzie trudniejsze.

Sposób zwinny

Agile ma zupełnie inne podejście.

• Zamiast jednorazowo zastosować metodę kaskadową, należy podzielić projekt na tygodniowe lub dwie iteracje.

• Nadal planujesz i wyjaśniasz wymagania , ale mniej i robisz to raz w każdej iteracji.

• Otrzymujesz wiele opinii użytkowników przy każdej iteracji

• Dokonujesz najprostszych zmian w oprogramowaniu, które obsługuje nowe wymagania przed przedstawieniem użytkownikowi

• Robisz dużo TDD, aby upewnić się, że nie zepsujesz rzeczy podczas ciągłej refaktoryzacji

Milion zmian śmierci

Jest taki użytkownik, który lubi wprowadzać mnóstwo drobnych poprawek. „Ta czcionka powinna być nieco większa”. „Ta czcionka powinna być nieco mniejsza”. „Zmień to na inny kolor”. „Zamiast tego, co mamy tutaj doskonale, może zmienimy go na coś nieco innego.”

W takim przypadku sugeruję, aby najpierw skupić się na podstawowych funkcjach klienta, skupić się najpierw na większych zmianach. Powinieneś także poprosić ich o sformułowanie wymogu, który spełnia mała zmiana.

Możliwe, że za żądaniem kryje się ważny wymóg, o którym po prostu nie wiesz. Jeśli tak jest, zrozum tę potrzebę i zobacz, czy możesz zasugerować coś, co lepiej spełnia to wymaganie.

Często wymaganiem jest „ogólna łatwość użycia”. Odpowiedzią na „ogólną łatwość użytkowania” jest prawie zawsze testowanie przez użytkowników. Należy pamiętać, że nie testy klientów, ale testy użytkowników przeprowadzane przez około sześć osób, które faktycznie będą korzystać z systemu.

Jeśli nie otrzymujesz wymagań potrzebnych do rozpoczęcia projektu, musisz zapisać każde wymaganie, którego potrzebujesz i jak najszybciej je określić. Poinformuj ich o dokładnych wymaganiach, których potrzebujesz, a co najważniejsze, które z nich powstrzymają Cię przed ukończeniem projektu.

Podczas wykonywania tego koduj tyle, ile możesz, za pomocą tego, co są podane na początku . Nie mogę tego wystarczająco podkreślić. Kontynuuj pracę nad tym, co otrzymałeś , aż nie będzie to już możliwe. Poinformuj ich, kiedy osiągniesz punkt, którego nie możesz ominąć, ponieważ wymagania nie zostały jeszcze określone.

Może istnieć uzasadniony powód, dla którego szef (-owie) nie przedstawili Ci specyfikacji, których potrzebujesz - mogą potrzebować makiety, aby najpierw zobaczyć, jak to działa, mogą nie mieć je, ponieważ Twoi użytkownicy / analitycy biznesowi ociągają się z dokładnymi wskaźnikami, których musisz przestrzegać. Niezależnie od tego, jaki mają powód, nawet jeśli jest to zły powód, nadal powinieneś wykonywać tyle pracy, ile możesz.

Czasami wymagania ulegną zmianie i nic nie możesz na to poradzić.

Witamy w branży oprogramowania.

Robienie takich rzeczy jest częścią Twojej pracy . Wiele odpowiedzi daje bardziej szczegółowe pomysły.

Elastyczność to część Twojej pracy . Aby kod był poprawiony, tak, ale przede wszystkim zrozumiały. I można je naprawić na bieżąco. Twoja praca

To część Twojej pracy polega na słuchaniu próśb o ciasto na niebie, kodowaniu, mówieniu komuś, że to nie jest sposób kodowania, koduj tak, jak chcą, co nie działa. Następnie wróć i zrób to tak, jak działa. Część Twojej pracy

Myślę, że jedyną bałaganiarską rzeczą, która nie jest naprawdę częścią Twojej pracy, jest złożenie skargi, że jest to nieefektywne. Myślę, że możesz o tym wspomnieć lub spróbować to powiązać, gdy sprawy przybierają coraz później i później, możesz zasugerować pewne rzeczy, ale to prawdopodobnie nie zadziała naprawdę.

Znowu radzenie sobie z bałaganem będzie częścią twojej pracy . I bądź miły. I powiedz, ok, szefie, kiedy cała sprawa zostanie wrzucona do śmietnika. I powiedz, ok szefie, kiedy to całość trzeba wyciągnąć ze śmietnika, wyrzucić do śmieci i przerobić.

Część pracy. Jeśli ci się to nie podoba, proponuję założyć własną firmę, zatrudnić grupę nieco aroganckich programistów i spróbować sprzedać ci usługi i produkty oraz zarobić na płacach, podczas gdy twoi jęczący pracownicy mówią, to załatany szef, to nie jest ładne kod szef. więc ...

Wydaje mi się, że jeszcze jedno jest to, że ludzie, którzy prowadzą interesy, często nie mają czasu na wiele spotkań z tobą. Jeśli potrafisz wykonywać swoją pracę, będziesz w stanie przewidzieć pewne rzeczy, naprawić rzeczy, których nie możesz, i zrobić to wszystko samodzielnie.

Jak już stwierdzono w innych odpowiedziach, Twoi „klienci” (ci, którzy poprosili o rozwiązanie, które tworzysz) potrzebują czegoś, co mogą porównać ze swoimi wymaganiami, aby w pełni zbadać i zrozumieć te wymagania (kupowanie samochodów analogia). Dlatego nie dostarczyli pełnych specyfikacji i zaczęli żądać zmian, gdy rozwiązanie zaczęło nabierać kształtu.

Gdy „klient” jest tego świadomy, może wprost poprosić o zbudowanie prototypu lub zezwolić na jego utworzenie i opracuj bardziej solidną specyfikację w oparciu o to, co ujawnił prototyp. Możesz jednak pójść tą samą drogą i nikt (Ty lub klient) nie będzie tego wyraźnie świadomy. Problem pojawia się, gdy podajesz cenę dostawy czegoś, co okazuje się prototypem, w którym klient oczekiwał, że Twoja wycena zostanie zastosowana do gotowego produktu.

W „Miesiącu mitycznego człowieka” jest omówienie system „pilotażowy”. Zasadniczo, zbudowanie systemu raz (który zostanie wyrzucony), aby nauczyć się wszystkiego, co jest potrzebne do zbudowania systemu od nowa, we właściwy sposób i jak często dzieje się to celowo lub nie. Być może zbliżasz się do ukończenia swojego „pilotażowego” systemu, a „prawdziwe” rozwiązanie jeszcze się nie rozpoczęło.

Być może najlepszym rozwiązaniem, jakie możesz teraz zrobić, jest udokumentowanie każdego żądania zmiany - dokładnie tak, jak rozumiesz wymagania i wycenę tego, co będzie potrzebne, aby je dostarczyć - i bądź szczery. Nie zaczynaj żadnej pracy trwającej dłużej niż kilka godzin na zwykłym ustnym uzgodnieniu. Zapisz to - nawet nieformalny e-mail jest lepszy niż nic. Być może będziesz musiał chronić się przed „nie o to prosiłem” i „nie powiedziałeś mi, że to zajmie tak długo”. Zwykłe powiedzenie szefowi, że powinien przestać prosić o zmiany, może być złe politycznie. Pozwól, aby rosnący ślad cytowanych opisów zmian przemówił za Ciebie o tym, jak sprawy dotarły do ​​miejsca, w którym się znajdują i jak dokładałeś wszelkich starań, aby spełnić prośby swoich „klientów”.

Możesz też sporządzić wykres lub schemat tego, czego Twoim zdaniem chcą klienci. Jeśli chcą programu, który ma rozwiązywanie równań, możesz sporządzić schemat (interfejs użytkownika i wszystkie elementy) programu, w którym użytkownik otrzyma menu, a następnie naciśnij przycisk, aby wybrać narzędzie do rozwiązywania równań. Równanie jest następnie wpisywane w pole tekstowe, a następnie użytkownik naciska kolejny przycisk, aby nakazać programowi rozwiązanie równania.

Ponadto zrób sobie przysługę i uzyskaj odpowiedź klienta na piśmie. Potraktuj to jako sposób na zakrycie swojego tyłka, jeśli klient powie później: „Nie chciałem tego”.

Komunikacja to najlepszy sposób rozwiązania problemu. Zadawaj pytania, które Cię znudzą i podają szczegóły, których potrzebujesz. Jeśli nie wiedzą, sam zaproponuj wymagania. Dokumentuj udzielone odpowiedzi i odeślij je z powrotem w celu potwierdzenia. W ten sposób jasno dajesz do zrozumienia, że ​​przyczyną opóźnienia lub zmiany jest zmiana ich zdania. Kiedy Mgt. powiedz „zbuduj to po swojemu”, co oznacza „zrób coś, na co mogę spojrzeć i zmienić”. Teoretycznie rozwój oprogramowania sugeruje, że przed rozpoczęciem projektu należy w pełni wyczyścić wszystkie wymagania, od szczegółowych opisów algorytmów po makiety ekranowe. Kiedy produkt zostanie dostarczony, oczywiście naprawimy wszelkie odstępstwa od pisemnych wymagań, ale żadne zmiany, które wiążą się ze zmianą wymagań, są niedozwolone. Tak, znacznie ułatwiłoby to życie twórcom oprogramowania. Nie martwiłbym się niejasnymi wymaganiami, pod warunkiem, że wszyscy zaangażowani rozumieją, że wymagania są niejasne, że będziesz musiał wypełnić luki, a kiedy zobaczą podjęte przez Ciebie decyzje, będą pewne decyzje których nie lubią i trzeba będzie przerobić. Żądania, które są nierozsądne i wysuwane przez szefa / kierownictwo lub klienta, musisz uzyskać pisemne informacje, aby się chronić. Jeśli szef / kierownictwo lub klient spodziewa się niemożliwych czasów zmiany i obwinia cię, gdy niemożliwe wymagania nie zostaną spełnione, to szczerze mówiąc, czas zacząć szukać innej pracy lub innego klienta.

Daj swojemu szefowi minimalną i najszybszą interpretację tych małych wymagań, które ci dał, i przedstaw je szybko jako sfinalizowaną transakcję.

Wszelkie przyszłe niejasne prośby o zmianę należy kwestionować, wyjaśniając, że zmiana pojawił się znikąd, skąd poproszono cię o napisanie własnej rzeczy, a teraz jest ona arbitralnie zmieniana. Zapytaj o bardziej konkretne powody każdej zmiany, abyś mógł odkryć własne wymagania i powiedzieć szefowi, że rezygnuje z pozwolenia na robienie własnych rzeczy i popycha to jako swoją porażkę.

Jeśli jednak masz dobre relacje z szefem, może on dać ci szansę zabłysnąć - poproś go o środki, aby odkryć własne wymagania, zastosować się i dostarczyć!