UWAGA: Menedżer ma niewielkie doświadczenie techniczne lub nie ma go wcale.

Prawdopodobnie ten menedżer miał czas na przygotowanie zaplecza technicznego, ale tego nie zrobił. Czemu? Albo jest niezainteresowany, albo niezdolny. Pamiętaj o tym idąc naprzód.

„Potrzebuję systemu floty za 14 dni”.

Przepraszam szefie, ale zajmie to 28 dni. To najszybciej, jak mogę to dostarczyć.

Nie ma potrzeby, a wyjaśnienie takiemu menedżerowi procesu tworzenia oprogramowania jest samokontrolą. Twoje prognozy będą musiały uwzględniać „podatek” dotyczący testowania, wdrażania i poprawek błędów. Po prostu uwzględnij to w swoim czasie tworzenia.

Kiedy skończysz kodować taki system, ale nadal nie został on przetestowany, powiedz mu, że nie jest zrobiony.

Jednak lepszym podejściem byłoby bardziej zwinne podejście, w którym zaimplementujesz i przetestujesz niektóre funkcje, a następnie przedstawisz to mu. W ten sposób coś widzi.

Możesz dokładniej podzielić harmonogram, na przykład:

• Pierwsza aplikacja: 8 dni
• Funkcja obsługi administracyjnej: 3 dni
• Funkcja śledzenia: 5 dni
• Funkcja automatycznego odnawiania: 7 dni

Robiąc coś takiego, prawdopodobnie możesz uciec ze znacznie dłuższym harmonogramem niż gdybyś po prostu cytując cały projekt. Menedżer jest zadowolony, ponieważ zobaczy coś za 8 dni zamiast za 14, których chciał. Nie ma znaczenia, że ​​nie ma prawdziwych funkcji. Nie myśl, że początkowa aplikacja będzie musiała mieć zbudowaną aplikację internetową, zaprojektowaną bazę danych itp ... po prostu go to nie obchodzi.

Z krótkich informacji w Twoim pytaniu wydaje się, że jest to wspaniałe okazja. Będziesz prowadzić swój projekt i nie możesz pracować nad swoimi umiejętnościami inżyniera projektu. Będziesz także rozwijać swoje umiejętności negocjowania pomysłów technicznych na nietechniczne. To wszystko jest bardzo cenne doświadczenie. Powodzenia.

Mówisz „Nigdy wcześniej nie zostawiałem niedokończonego projektu”. Czas zacząć.

Każdy specjalista rzuci pracę w którymś momencie, gdy klient jest nierozsądny. Są szefowie i klienci, których nie da się zadowolić i trzeba ich zwolnić. Kiedy jestem gotów rzucić palenie i wyjść za drzwi, jestem znacznie silniejszy we wszelkich spotkaniach lub negocjacjach.

Pracując nad systemem zarządzania flotą, nie ma absolutnie żadnego sposobu, aby go dostarczyć w 14 dni. Zdefiniowanie problemu w 14 dni, a co dopiero jego rozwiązanie, jest prawie niemożliwe.

To nie jest ogólna rada dla * każdego * projektu informatycznego; jest to specjalnie dla tej sytuacji, w której pozornie niemożliwe zadanie jest postawione przez kierownictwo, które nie chce słuchać (lub nie może), także wtedy, gdy po prostu nie chcesz od razu rezygnować. Oczywiście pracuj dalej nad „interpersonalnymi” kątami, aby znaleźć właściwe rozwiązanie podstawowych problemów.

Byłem w takich sytuacjach. Na poziomie technicznym ścieżka jest jasna: solidne, nowoczesne praktyki programistyczne - agile, BDD / TDD, automatyzacja. To znaczy:

• Testy są pisane przed kodem, przeplatając pojedynczy test i kod, aby ten test był zielony. Zachęcamy do rozpoczęcia od testów integracyjnych zamiast testów jednostkowych. W pewnym momencie staną się uciążliwe (z powodu wolniejszego wykonywania całego zestawu testów), ale świetnie nadają się do szybkiego rozpoczęcia.
• Żaden kod nie jest zapisywany z wyjątkiem minimum, które zmienia kolor na zielony test.
• Test jest Twoją specyfikacją. Jeśli chcesz wbić go do domu, użyj ogórka. Rzeczy, które nie są testowane, nie są określane, a rzeczy, które nie są określone, są niezdefiniowanym zachowaniem.
• Zawsze, gdy istnieje jakikolwiek rodzaj pracy „narzędziowej”, dokonaj jej natychmiastowej zautomatyzowania. Np. Twoje wdrożenie. Na początku zachowaj podstawowe zasady, nawet jeśli są to tylko zapisane na stałe nazwy serwerów itp., Ale zrób to automatycznie. Oszczędności czasu naprawdę szybko rosną.
• Pracujesz w zwinnym środowisku, takim jak Scrum lub Kanban. Jeśli twoje kierownictwo i firma i tak nie są techniczni, strzelałbym dla Kanbana - co po prostu oznacza, że ​​kroisz swoją pracę na małe, dobrze widoczne wycinki i unikasz WIP jako najwyższego priorytetu.
• Jak najszybciej dostarcz pierwszą działającą wersję. Zarządzanie całą flotą to za dużo na 14 dni, ale możesz wydobyć coś w 14 dni. Cokolwiek . Nawet jeśli jest to zwykła strona internetowa chroniona podstawowym uwierzytelnianiem, wyświetlająca listę samochodów w puli. Następnie idź dalej. Nie traktuj tego jako „prototypu” czy czegoś podobnego, nigdy nie będziesz miał czasu, aby zacząć od zera; traktuj to jako kod produkcyjny od pierwszego dnia.
• Nie podawaj ogólnych szacunków. Zamiast „Potrzebuję 28 dni zamiast 14” (co i tak jest bezsensowne, Twoje wymagania z pewnością nie są wystarczająco jasne, aby nawet obliczyć 28 dni) powiedz „Jasny szefie, natychmiast zacznę pracę. Zobacz, oto zaległości / Tablica Kanban, czy masz wpływ na kolejność rzeczy? ” itd. Gdy zapytają „kiedy skończysz”, odpowiedzą „Nie mogę powiedzieć, ale widzisz, jak podzieliłem zadania na porównywalne części, zobaczymy w ciągu najbliższych kilku dni, jak szybko przebiegają procesy pracy, OK?” .
• Przyzwyczaj ich do myśli, że nie robisz wielkich planów projektów lub że oprogramowanie po 14 dniach wydaje się pełnoprawne. Poinformuj ich, jak działa tablica Kanban, może dawaj im 15-minutowy raport każdego dnia, aby wprowadzić ich „do łodzi”. Twoja prędkość będzie dość oczywista, nie będziesz musiał się tłumaczyć, o ile pokażesz im kilka małych stopniowych kroków wychodzących każdego dnia.
• Jeśli przyjdą do ciebie z terminami, dowiedz się, jak zmniejszyć praca do minimum, niezbędnego minimum; podziel to na tak małe, jak to możliwe jednostki (które, miejmy nadzieję, mogą być dostarczone do produkcji indywidualnie) i po prostu idź do chrupania. Nie , powtarzam, nie poddawaj się presji, by robić 18 godzin dziennie czy coś w tym rodzaju. To nie działa. Twoja produktywność i tak spada po normalnym dniu pracy. Wypalenie niesamowicie zmniejsza prędkość.
• Zapomnij o idei „skończonego”. Oprogramowanie kończy się po wyłączeniu ostatniego serwera. Nigdy nie będziesz miał pustego rejestru. Ważne jest, abyś utrzymywał swoje własne standardy (ponieważ wiesz , że bez nich odniesiesz porażkę w połowie okresu) i utrzymujesz odpowiednią prędkość, która możesz nadążyć w nieskończoność. Tak, to są modne słowa, ale tak naprawdę mają znaczenie.

Na poziomie osobistym / IPS / ludzkim zachowaj spokój i hakuj. Unikaj wszelkich nietechnicznych dyskusji. Nie narzekaj, ale powiedz, czy potrzebujesz więcej zasobów (szybszy komputer, więcej węzłów po stronie serwera / pamięci RAM / HDD itp.), Aby przyspieszyć rozwój. Daj im rozwiązania dla indywidualnych problemów; bądź odważny i zdecyduj, jak wdrożyć pewne rzeczy lub gdzie podzielić zadania na mniejsze jednostki, które można dostarczyć. Niech tablica Kanban powie im, że nie działa tak szybko, jak chcą, nie rób tego sam.

Powodzenia!

Masz tutaj dwie podstawowe możliwości.

1. Zakodowujesz swój tyłek i dostarczasz nieprzetestowany wynik w określonym czasie. Potwierdź fakt, że jest w dużej mierze niesprawdzony i dlatego istnieje ryzyko, że zepsuje się lub nie będzie w pełni dostosowany do wymagań, ponieważ w planie zasobów / projektu nie było czasu na zrobienie tego. li>

   Kodujesz to poprawnie i testujesz w trakcie. To oczywiście potrwa dłużej, ale da lepsze rezultaty.

Zaproponuj to swojemu kierownikowi jako wybór.

Bez ogródek:

Czy chcesz to zrobić teraz, czy chcesz zrobić to dobrze?

I bądź przygotowany na poparcie tych wyborów szacunkami czasowymi (zarówno na potrzeby programowania, jak i kontroli jakości ) i powtórz, że nie możesz zmieścić obu w tym samym szacowanym czasie.

„Obie” nie są opcją w prawdziwym świecie. Nie, chyba że dostaniesz więcej ciał do przeprowadzenia analizy / testów / kontroli jakości.

Widzę kilka problemów w komunikacji i porozumieniu między tobą a tobą, menedżerem.

Po co w ogóle testować?

Wygląda na to, że przedstawiłeś testowanie jako dodatkowy pakiet roboczy. To nie jest (lub nie powinna być ) praca dodatkowa, ale integralna część Twojej pracy. Tak jak pracownik budowlany nie może zbudować budynku bez upewnienia się, że wszystkie ściany są proste, tak nie możesz stworzyć niezawodnego oprogramowania bez testów.

Nie wspominaj o testowaniu jako osobnym pakiecie roboczym, ale oblicz czas wdrożenia, w tym testowanie. Nie ma jednego bez drugiego.

Pstryknij palcami i gotowe!

Twój kierownik oczywiście nie ma pojęcia, jak działa tworzenie oprogramowania. Naprawiając wiele problemów w krótkim czasie, utwierdziłeś go w przekonaniu, że jesteś magiem, który wyciąga oprogramowanie z kapeluszy.

Spróbuj mu wytłumaczyć, że nie tworzysz kolorowych okien / stron, ale kod . Skomplikowany kod porównywalny ze skomplikowanymi instrukcjami obsługi komputerów. Nie bez powodu nazywa się to językiem programowania .

Jak żaden pisarz nie jest w stanie stworzyć rozbudowanej instrukcji obsługi, tak nie możesz stworzyć skomplikowanej funkcji w kilka dni.

System floty samochodowej nie jest prostym akapitem w instrukcji; jest to zupełnie nowa instrukcja. Jeśli twój menedżer ci nie wierzy, poproś go, aby opisał ci system floty, każdy szczegół, aż do miejsca, w którym przechowywane są kluczyki do każdego samochodu.

A bystry facet, taki jak ty, może robić to szybciej

Odmawiaj akceptacji nierealistycznych terminów. Wypisz pakiety pracy, które musisz wykonać i ile czasu szacujesz dla każdego pakietu, podsumuj czasy i ustal własny termin.

Może to zepsuć nastrój twojego menedżera, zwłaszcza że magicznie pracowałeś tak szybko na początku. Uzupełnij swoje szacunki i terminy faktami i listami; uczynić je bardziej realnymi niż wyobraźnia twojego menedżera.

Wszystko jest najważniejsze

Utwórz priorytetowy ranking wszystkich funkcji, takich jak przyklejanie karteczek samoprzylepnych na tablicy. Każda funkcja ma rangę i wdrażasz ją w kolejności ich rangi.Jeśli (a raczej kiedy) Twój menedżer zażąda nowych funkcji, pozwól mu posortować je na tej liście rankingowej. To jasno pokazuje, że niektóre rzeczy muszą poczekać, aż inne się zakończą.

Nadal nie skończone ???

To moja najszczersza rada: z miłości do siebie, nie nie daj się wypalić! Jesteś człowiekiem i możesz pracować tylko tyle i tak ciężko, zanim się zjesz. Pracuj tak dobrze i tak szybko, jak rozsądnie możesz wytrzymać przez dłuższy czas. Rzeczy, które nie są zrobione na czas, muszą poczekać. Wyjaśnij swojemu przełożonemu, że robisz wszystko, co w Twojej mocy, ale w żaden sposób nie spełnisz jego nierealistycznych oczekiwań.

Niestety, nie ma dobrego sposobu na poradzenie sobie z tym, który nie sprawi Ci bólu.

Najpierw zakryj się. Upewnij się, że wysyłasz do swojego szefa e-maile wyjaśniające, że terminy są nierealne i że nawet próbując je spełnić, będziesz musiał pominąć odpowiednie testy. Powiedz, że czujesz się z tym nieswojo i czujesz, że spowoduje to różne problemy, takie jak niska jakość produktów i dług techniczny. Zachowaj również kopie wszystkich e-maili, które szef wysłał Ci z prośbą o nowe funkcje.

Następnie zacznij szukać lepszej pracy. Niestety w takiej sytuacji albo będziesz musiał odejść, albo twój szef będzie musiał odejść i nie możesz tak naprawdę ryzykować, że to nie ty.

Wreszcie zrób wszystko, co możesz, aby dotrzymać terminów . Jeśli zostaniesz oskarżony o cokolwiek, powiedz, że ostrzegałeś swojego szefa o tych problemach i że jest on odpowiedzialny za to, aby ich nie rozwiązać.

Praca w ten sposób jest niezdrowa. Jako specjaliści IT możemy (i robimy) pracować przez długie godziny czasami. Jeśli regularnie pracujesz 60-70 (lub więcej) godzin, jest ogromny problem i to Ty cierpieć z tego powodu.

Mój obecny pracodawca rozumie równowagę między życiem zawodowym a prywatnym. Większość tygodni to 40 godzin, a potem kończę.

U mojego poprzedniego pracodawcy nie tak było.

Obsługiwaliśmy, uzyskując konkretne wymagania, które zostały zatwierdzone przez wszystkich interesariuszy (wewnętrznych i / lub zewnętrznych) przed wykonaniem jakiejkolwiek pracy. Harmonogram projektu był przechowywany w MS Project (lub innym narzędziu do planowania projektów). Wszelkie zmiany w stosunku do pierwotnego planu zostały wprowadzone do projektu w celu określenia ich wpływu na harmonogram. Zmiany wymagały również podpisania zgody interesariuszy. Gdyby to była mała zmiana, wystarczyłaby wiadomość e-mail. Cokolwiek ważnego (takie jak dodanie systemu zarządzania flotą) wymagałoby zmian w dokumentacji (wymagania biznesowe, wymagania projektowe, specyfikacje techniczne itp.) Przed wprowadzeniem zmiany.

Mówisz, że Twój menedżer nie ma doświadczenia w programowaniu. Zatem programiści są dla niego czarną skrzynką. Mówi im różne rzeczy i widzi, ile czasu zajmuje im wymyślenie czegoś. Odkrywa, że ​​jeśli zlekceważy ich zbyt pesymistyczne przewidywania, dostarczą więcej w krótszym czasie.

Rozwiązaniem jest dostarczenie właściwej informacji zwrotnej. Nie ma dla niego proporcjonalnego kosztu spowodowania przez ciebie cierpienia i wyciśnięcia jego pracowników do sucha.

Więc najpierw upewnij się, że masz papierowy ślad. Otrzymuj każde zadanie na piśmie. Pozwól mu wypisać się co godzinę, kiedy musisz pracować po godzinach. Niech podpisze twoje oświadczenia, że ​​kod jest nieprzetestowany. Musisz zakryć swój tyłek, ponieważ gówno uderzy w ścianę i musisz zakryć swój tyłek, aby jasno powiedzieć, że to nie jest twoje gówno.

Ja Zalecałbym również sprawdzenie opcji związkowych. W zależności od tego, jak rozsądna okaże się hierarchia firmy, może to nie być konieczne, ale może się przydać, gdy kierownictwo na piętrze jest apatyczne lub niekompetentne.

Albo to, albo wyjdź, gdy ty możesz i dostać się w miejsce, w którym jesteś ceniony jako zrównoważone źródło pracy, a nie drewno na opał.

Oprócz innych dobrych odpowiedzi, jako programista, mam jeszcze jedno narzędzie do Twojej torby z narzędziami.

Wyjaśnij swojemu kierownikowi następujący trójkąt:

Pomysł polega na tym, że Ty / Twój menedżer wybieracie tylko 2 opcje. Nie ma opcji „pobierz wszystkie opcje”, ponieważ tak się po prostu nie dzieje. Nawet małe projekty wymagają czasu, aby być dobrze, a twój projekt nie jest mały.

Pracuję samotnie nad koszmarem związanym z 20-letnią aplikacją Frankensteina w pracy. Mam „wszystko naprawić” i jednocześnie nadążać za żądaniami klientów. Na szczęście: mój przełożony, szef i szef szefowie wiedzą, że nie jest to możliwe w ramach czasowych wyznaczonych przez jeszcze wyższe autorytety, więc nie dam się za to ciągnąć po błocie. Nadal mogę znaleźć rozwiązanie tego problemu, ale mam kilka osób wspierających mnie, które rozumieją powyższy trójkąt.

Wygląda na to, że nie masz tej kopii zapasowej, więc ustaw sprawę prosto. Jak powiedziały inne odpowiedzi, kiedy zostaniesz „oskarżony” o bycie „mądrym facetem, takim jak ty”, odpal z:

Inteligentny facet, taki jak ja, wie, co jest możliwe w danym przedziale czasowym. proszą, a to nie jest możliwe.

Upewnij się, że mówisz to śmiertelnie poważnie. Nie uśmiechaj się, po prostu potraktuj to śmiertelnie poważnie. Jeśli nie skapitulujesz lub nie będziesz negocjować w inny sposób, możesz okazać się uparty, ale menedżer nie może cię nakłonić do spróbowania tego, o czym wiesz, że jest niemożliwe, a potem obwiniaj cię za swoje błędy. Zrobiłem wszystko z różnymi innymi taktykami i wydaje się, że jest to jedyna, która nie przynosi skutków odwrotnych.

Negocjowałem, skapitulowałem, „po prostu wykonałem pracę” i różne kombinacje z tych trzech i zawsze wraca, by ugryźć mnie w tyłek. Każdy błąd lub brakująca funkcja staje się moją winą. Mogą minąć dwa lub więcej lat, a to nadal „twój bałagan, napraw go”.

Przy okazji, nie jestem osobą, która często używa słowa „niemożliwe”, ale wydaje się, że jest to jeden z tych niezbędnych razy.

Powinieneś użyć współczynnika Scotty'ego: za każdym razem, gdy Twój menedżer zażąda funkcji, najpierw podaj szacowany czas trwania, zanim będzie miał czas, aby powiedzieć Ci o swoich oczekiwaniach. Ten szacowany czas pomnożenia przez 4, a następnie pozwalasz mu negocjować w dół.

Przykład

Menedżer: Potrzebujemy gotowego do produkcji systemu zarządzania flotą. ..

Ty [Przerwanie]: Jasne, mogę to stworzyć w 4 miesiące.

Menedżer: Och, myślałem o dwóch tygodniach.

Ty: Haha, świetny żart! Wiesz, że XYZ pracuje nad swoim systemem zarządzania flotą od 10 lat i właśnie opublikowali swoją pierwszą stabilną wersję?

Menedżer: Cóż, mamy najwyżej dwa miesiące ...

Ty: Widzę, co mogę zrobić.

PS: Ta sztuczka jest potrzebna tylko w takim stopniu (pomnożenie przez 4) w środowisku pracy, takim jak Twoje. Ale nie zaszkodzi zawsze planować trochę czasu buforowego w każdym projekcie, ponieważ my, ludzie, zwykle planujemy rzeczy, o których wiemy, że się dzieją, ale nie możemy wyjaśnić rzeczy, które zdarzają się niespodziewanie.

Istnieje powszechnie cytowana i dobrze znana zależność trzech czynników: Wynik

Jakość, czas trwania i cena

Można osiągnąć tylko dwa z nich . Jest tak dobrze przetestowany w informatyce, że możemy po prostu założyć, że to prawda. (Daj mi znać, jeśli tego nie zrobisz).

To jest faktyczny fakt , a nie coś, co możesz negocjować, jeśli spróbuje go wyegzekwować, nawet przy użyciu broni. >

Szef tego nie wie lub nie rozumie: pokazuje to za pomocą

Użytkownik końcowy nie widzi testów , o ile to działa i wygląda dobrze w porządku, ważniejszy jest czas wprowadzenia produktu na rynek

Chce wszystkie trzy : brak wyników testów w niskiej jakości, a użytkownik końcowy wyraźnie widzi, że „to nie działa (w częściach - to wystarczy, aby było bezużyteczne)”.