Co zrobić, jeśli szef zawsze odkłada najważniejsze decyzje dotyczące wymagań i ogólnego projektu?

Rozpoczynając nowy projekt, mój szef zawsze unika ustalonych decyzji. Zwykle mówi: ok, po prostu zacznij coś pisać i bądź tak ogólny, jak to możliwe. Kiedy skończysz, sprawdzimy, jak będziemy kontynuować. Jego argumentem jest zasadniczo to, że nigdy nie wiesz i „zwinny rozwój”.

Aby pytanie było jak najbardziej ogólne: co robisz, jeśli twój szef nie lubi podejmować decyzji?

Po prostu trzymaj się tego i napisz kod, który może zostać poddany ciężkiej refaktoryzacji i częściowemu przepisaniu kilka tygodni później? Lub dyskutować dalej, aż szef podejmie przynajmniej kilka decyzji? To mniej więcej moja obecna strategia. Ponieważ to jest jak prawo fizyki, w pewnym momencie coś trzeba dostarczyć. Albo dlatego, że szef szefa chce zobaczyć wyniki, albo dlatego, że w pewnym momencie rzeczy stają się śmieszne.

Zauważam też, że mój szef krytykuje prawie wszystko. Nawet sugestie oparte na jego własnych ...

Twórz prototypy

Po prostu zacznij rysować ekrany, które na początku nic nie robią (przypuszczalnie masz na to dość?)

Powinieneś być w stanie sprawić, by częściowo działał powoli i ostatecznie zreformować część złego kodu, gdy stanie się bardziej jasne, co próbujesz zrobić.

Powszechnym problemem jest to, że nie wiedzą, czego chcą, dopóki czegoś nie zobaczą i nie uświadomią sobie, że nie tego chcą. Przekonałem się, że kiedy ktoś chce, abyś po prostu zaczął budować „strukturę” lub coś „ogólnego”, jak to, co ci mówi, po prostu wpadniesz w kłopoty, jeśli spróbujesz. Ramy są już napisane, nie musisz tego robić.

Jest kilka problemów, które zebrałem z twojej wiadomości: 0-Nie jest twoim zadaniem zarządzanie projektem i nie jest twoim zadaniem, aby zbierać wymagania użytkownika końcowego. 1-Szef nie zna dokładnych wymagań 2-Szef nie rozmawia z użytkownikami końcowymi na temat wymagań 3-Szef rzuca terminologię, której tak naprawdę nie rozumie zwinnie 4-Pracujesz nad rozwiązaniem, które dostaje ponownie napisane kilka razy i nie jesteście z tego zadowoleni

Jeśli chodzi o 1,2 i 3, niewiele można zrobić, jeśli nie jesteś osobą starszą. Można jednak wykonać następujące czynności:

Odp. - Poproś go, aby podzielił się z Tobą planem projektu. Może mieć jeden lub zbuduje taki, pokazujący zadania i terminy. Jednym z nich powinno być analizowanie i zbieranie wymagań. Jeśli nie, zasugeruj to.

B - Przygotuj odniesienia do znaczenia wymagań dla powodzenia projektu oprogramowania

C - Przygotuj mu 1 stronę tego, czym jest Agile, a czym nie.

D - Przygotuj mu listę typowych danych wejściowych do etapu projektowania i przekonaj go o wartości każdego z nich.

E - Zaproponuj dodanie do zespołu analityka biznesowego i / lub projektanta danych. Takie role będą musiały zasiąść z użytkownikiem końcowym i uzyskać wymagane informacje lub przynajmniej dobrą ich część.

F - Zobacz, jak inni programiści współpracowali z tym facetem.

Jeśli chodzi o # 4, możesz zasugerować mu użycie prototypowania lub generatora kodu, który pomógłby mu, tobie i użytkownikowi, podjąć decyzję na temat funkcjonalnych aspektów aplikacji. Większość narzędzi nie generuje doskonałego GUI, ale przynajmniej można uchwycić wymaganą funkcjonalność.

We wszystkich przypadkach upewnij się, że dokładnie udokumentowałeś każdą z iteracji i wyślij mu wiadomość e-mail o tym, co otrzymałeś, co zrobiłeś (szczegółowo) i jaki jest wynik. Upewnij się, że przypisujesz wyniki właściwej przyczynie, takiej jak (brak wymagań itp.).

Niestety niektórzy ludzie nie akceptują porad. Uważaj więc, jak się z nim komunikujesz.

To nie idzie dobrze!

Powodzenia.

Miałem takiego szefa - żartowałem, że jego motto brzmiało: „niezdecydowanie jest kluczem do elastyczności”.

Bez względu na to, jaką pracę wykonujesz, prawdopodobnie jesteś w stanie rozwiązać problem klienta niż szef. Jeśli nie wiesz, na czym polega problem, który próbuje rozwiązać klient (co nie jest tym samym co specyfikacja), oznacza to, że ktoś nie zbiera poprawnie wymagań.

Naszkicuj niektóre układy stron lub zbuduj niefunkcjonalny prototyp. Ale zrób coś. Z twojego postu nie wynika jasno, czy tworzysz pełne oprogramowanie klienckie czy aplikacje internetowe, ale piękno tego drugiego polega na tym, że możesz wydać wcześnie, często wydać. Zacznij od gołych kości i zacznij od tego miejsca. Fałszywy start nie zaszkodzi, jeśli zacznie przebiegać dialog i zostaną podjęte pewne decyzje.

Dla naszych klientów mamy powiedzenie wokół $ WORK (wewnętrzne aplikacje internetowe): „Dam ci coś, abyś mógł powiedzieć mi, czego chcesz”. Przygotuj się na wyrzucenie pierwszego szkicu, ale możesz być zaskoczony, jak rzadko trzeba.

Wskaż mu, że książki Agile sugerują odroczenie decyzji tak długo, jak możesz, ale nie więcej . Każda decyzja ma punkt, w którym musi być podjęta, a być może jesteś już teraz.

Z drugiej strony również zadaj sobie pytanie. Czy naprawdę musisz zdecydować, jakiej warstwy trwałości będziesz używać w tej aplikacji? A może zaczniesz pisać go do pliku CSV i utrzymywać go na tyle abstrakcyjnym, by później podjąć taką decyzję?

Napisz własny dokument specyfikacji i zrób recenzję, w której go wyjaśnisz, a on się na nim podpisuje. Następnie zostaniesz szefem, a twój szef przejdzie bardziej do problemów zarządzania interpersonalnego niż technicznych.

Zaangażuj się w „zarządzanie w górę”, rozmawiaj z szefem i klientami, znajdź kilka rozwiązań, wybierz najlepsze do wdrożenia przez zespół, znajdź wady w innych i „zarządzaj” swoim menedżerem, aby podejmował „właściwą” decyzję.

I oczywiście upewnij się, że myśli, że to był cały jego pomysł. (szczególnie gdy wszystko pójdzie nie tak!)

Musisz coś zaprojektować i wdrożyć. Ponieważ twój szef nie podejmie decyzji, podejmij je samodzielnie. Poświęć trochę czasu na udokumentowanie swoich decyzji i założeń przed ich wdrożeniem. Wyślij to do kogokolwiek może dotyczyć, w tym do swojego szefa. Mamy nadzieję, że ta lista obejmuje więcej niż twojego szefa, ponieważ wywrze na nim niewielką presję, aby podejmował pewne decyzje, ponieważ wie, że inni są świadomi, że jesteś gotowy, aby kontynuować. Zdziwisz się, jak szybko otrzymasz informację zwrotną, kiedy podejmujesz decyzje na piśmie, szczególnie jeśli podejmujesz decyzje, z którymi inni się nie zgadzają. W międzyczasie podejmowałbym decyzje, które podjąłeś, dopóki nie powiedziano inaczej.

Jeśli przestałeś marnować czas na wdrażanie tego, czego nie chciał twój szef, to to na nim, a nie na tobie, ponieważ był świadomy ścieżki, którą zamierzasz podążać.

Ponadto niektórzy ludzie mają trudności z rozpoczęciem, ale kiedy widzą coś namacalnego, wtedy ich umysł zaczyna działać. Może twój szef jest taki, a mówienie mu, co planujesz robić na piśmie, sprawi, że jego umysł zacznie działać.

Podejmuj decyzje samodzielnie i zacznij kodować. Oczywiście, elastyczny rozwój pomoże (przeczytaj Agile Patterns, Principles and Practice Roberta C. Martina, jeśli jeszcze tego nie zrobiłeś), ale cała elastyczność na świecie nie pomoże, jeśli nie zostaną podjęte żadne decyzje. Może się okazać, że musisz po prostu rozwinąć to , co myśliszjest potrzebne, a następnie zmodyfikowane zgodnie z wymaganiami. Często klienci / szefowie nie wiedzą, czego chcą, dopóki ich nie zobaczą lub dopóki nie zobaczą czegoś, czego nie chcą. Prawdopodobnie zabierze Cię to poza bycie programistą, ale takie jest życie. Często stwierdzam, że ja i moi koledzy skutecznie podejmujemy decyzje biznesowe. Czasami nie są one kwestionowane, a decyzje, które podejmowałem, zaczynają kierować biznesem, wyłącznie dlatego, że nikt inny nie podjąłby decyzji. Pamiętaj, aby wymienić WSZYSTKIE z was założenia i decyzje (bez wyjątków) i przedstawić je swojemu szefowi.