Działkę budowlaną kupię

Jesteśmy w momencie kupowania działki. W tym artykule opiszę, jak wygląda taki proces z perspektywy kupującego i na co zwrócić uwagę (a na co nie).
U nas sytuacja wygląda następująco:

• działkę będziemy kredytować
• działka wymaga wydzielenia z większej działki

Etapy kupowania działki

Kupując działkę, na którą bierzemy kredyt przechodzimy pięć etapów:

1. wybór działki (ustawność, usytuowanie) 
2. sprawdzenie podstawowych informacji o działce (MPZP, media) 
3. podpisanie Umowy Wstępnej wraz z odebraniem od Właściciela w dniu podpisania Umowy koniecznych do udzielenia kredytu dokumentów
4. uzyskanie kredytu (pozytywna decyzja kredytowa z banku)
5. Umowa Przyrzeczona i uruchomienie kredytu (wypłacenie pieniędzy sprzedającemu działkę)

Etap 1: wybór działki

Jest to najprzyjemniejszy etap, ciesz się oglądaniem działek. Ponieważ my nie wiemy, co podczas kupowania działki sprawdzić i gdzie, i nie mamy czasu jeździć po urzędach, kupujemy działkę przez pośrednika - jest wygodnie - pośrednik nam działki proponuje a my jedynie wsiadamy do samochodu i jeździmy z nim po wioskach. 

Przeglądając strony z poradami przeraziła mnie liczba rzeczy, na które według publikujących muszę zwróć uwagę kupując działkę. Było tam wszystko, łącznie ze sprawdzeniem rodzaju gruntu. Sprawdź na początek dwie rzeczy:

• czy działka jest ustawna (osobiście uważam, że powinna mieć kształt prostokąta o szerokości minimum 25metrów - przeglądałam projekty domów i taka działka pozwoli zbudować niemal każdy dom jednorodzinny, nieco węższa już mogłaby być dla niektórych projektów za ciasna)
• jak działka jest położona względem stron świata - chodzi tu o odpowiednie naświetlenie salonu przyszłego domu (obrazowy artykuł na stronie: http://www.budujemydom.pl/component/option,com_content/task,specialblogcategory/act,view/id,540/Itemid,31/)

I najważniejsze - czy działka zwyczajnie Cię urzekła. 

Dla nas dodatkowe znaczenie miała odległość gruntu od miasta. Szukaliśmy działek dość blisko, ponieważ zestawiając koszt działek z kosztem benzyny, jaką musielibyśmy zużyć dojeżdżając z niej do granic miasta okazało się, że nie było bezpośredniego przełożenia na zmniejszenie ceny działki wraz ze zwiększeniem jej odległości od miasta do 50 kilometrów. Cena malała znacząco dopiero po 50 kilometrach. A 50 kilometrów to już godzina dojazdu i 30zł w jedną stronę przy dzisiejszym koszcie benzyny. Jest to 1200zł miesięcznie na dojazdy do pracy, więc zdecydowanie za dużo. Z tych rachunków wyszło, że należy kupić działkę jak najbliżej miasta skoro nie ma znaczących różnic w cenie a benzyna kosztuje. 

Kupując działkę zrób te same przeliczenia - sprawdź kiedy wyższa cena działki zaczęłaby Ci się zwracać w porównaniu z tańszą działką, ale dalej od miejsca, gdzie musisz codziennie dojeżdżać.  

Jak już upatrzysz sobie działkę, kolej na sprawdzenie podstawowych informacji o niej.

Etap 2: Podstawowe informacje o działce

Jeśli już znalazłeś działkę czeka Cię trochę kolejny research: 

• przeczytaj Miejscowy Plan Zagospodarowania Przestrzennego (działka bez takiego planu to kłopot przy budowie domu - wymagane dużo formalności z Urzędu Gminy, nie polecam takiej). MPZP to dokument i dołączona do niego mapa. Z reguły można je znaleźć na internecie - aktualnie Urzędu Gminy tam je umieszczają. Z niego dowiesz się, czy działka jest oznaczona jako budowlana (!), czy nie jest zaplanowana w przyszłości  w pobliżu Twojej działki budowa autostrady (wtedy w MPZP powinny być oznaczone grunty wykupione i zarezerwowane przez gminę) czy supermarketów (grunty oznaczone jako tereny zabudowy usługowej), na mapie zobaczysz, gdzie przebiega nieprzekraczalna linia zabudowy czy sieci wodociągowe, dowiesz się, jaka jest minimalna powierzchnia działki, żeby móc budować dom. Całkiem ciekawy dokument. 
• jeśli na planie MPZP nie znajdziesz doprowadzonej do Twojej działki kanalizacji udaj się do Urząd Gminy, żeby zapytać ich o plany w tej kwestii (gminie zależy na tym, żeby jak najwięcej działek miało doprowadzoną kanalizację, ale może się zdarzyć, że owszem planują, ale za dwa lata)
• poproś właściciela o dostarczenie odpowiednich dokumentów z Zakładu Gazowniczego i Zakładu Energetycznego potwierdzających możliwość i warunki przyłącza gazu i prądu

Koniec. Resztą niech zajmie się właściciel (np. wydzieleniem działki i zdobyciem odpowiednich dokumentów, o których za chwilkę) i pośrednik (który ma np. sprawdzić, czy stan prawny pozwala na jej sprzedaż). Nie bierz na siebie ich obowiązków. Twoim zadaniem jest zabezpieczenie własnych interesów i sprawdzając powyższe dokumenty to zrobisz.

Jeśli sprawdzenie wszystkiego powyższego nie dostarczyło niespodzianek lub są do zaakceptowania i nadal jesteś zainteresowany wybraną działką kolej na podpisanie Umowy Wstępnej i odebranie dokumentów od właściciela.

Etap 3: Podpisania Umowy Wstępnej i odebrania dokumentów od właściciela

Kiedy już wiesz, że chcesz kupić działkę dowiedz się jakich dokumentów potrzebujesz, żeby móc starać się o kredyt. W naszym przypadku działka jest dopiero wydzielana z innej działki i tu pojawił się problem - nie ma dla niej jeszcze Ostatecznego Projekt Podziału. Tutaj parę słów o tym kluczowym dokumencie.

Ostateczny Projekt Podziału działki to potwierdzenie gminę Wstępnego Projekt Podziału, natomiast Wstępny Projekt Podziału jest przygotowywany przez geodetę od strony właściciela. Problem w tym, że banki nie przyjmą Wstępnego  Projektu Podziału jako dokumentu wiążącego i wystarczającego do udzielania kredytu - potrzebują Ostateczny Projekt Podziału, z pieczątką gminy. I mają rację, ponieważ Urząd Gminy może nie zaakceptować Wstępnego Projekt Podziału (będzie np. żądał  korekt), wtedy kredyt by był udzielony na nieruchomość, która w rzeczywistości wygląda inaczej.

Jeszcze jedna ważna informacja o Wstępnym Projekt Podziału - do kredytu będziesz potrzebować operat szacunkowy nieruchomości, który kosztuje 1000zł. Jeśli gmina nie zaakceptuje planu wtedy będziesz musiał robić operat szacunkowy raz jeszcze.

Jak rozwiązać taki problem: my poprosiliśmy doradcę kredytowego o rozeznanie się w sytuacji i ostatecznie banki zgodziły się na przyjęcie Wstępnego  Projektu Podziału ALE z tzw. pozytywną opinią Wstępnego Projektu Podziału działki wydanego przez Urząd Gminy. W takim przypadku i banki i my jesteśmy pewni, że projekt nie ulegnie zmianie i już, bez czekania dwa miesiące, można przystąpić do podpisywania Umowy Wstępnej (zatwierdzenie przez Urząd Gminy Wstępnego Projektu Podziału trwa właśnie około dwóch miesięcy).

Jeśli Twoja działka będzie kredytowana warto odebrać od właściciela działki te dokument, o które będzie prosił bank do kredytu, od razu podczas podpisywania Umowy Wstępnej (żeby skrócić czas oczekiwania na nie i ograniczyć ryzyko, że właściciel będzie przedłużał później ich dostarczenie). Są to (wszystkie dotyczą działki):

• Odpis księgi wieczystej
• Wypis z rejestru gruntów
• Wstępny projekt podziału
• Kopia Mapy Ewidencyjnej
• Akt Notarialny właściciela działki lub inne poświadczenie własności działki
• Pozytywna opinia wstępnego projektu podziału nieruchomości
• Zaświadczenie z miejscowego planu zagospodarowania przestrzennego Gminy

Wraz z Umową Wstępną zapłacisz zadatek, w wysokości 10-15% wartości nieruchomości, ale mogą od tych procentów być odstępstwa - my zapłaciliśmy wyższy.

Kolejne etapy

Ponieważ my jesteśmy teraz dokładnie jeden dzień po podpisaniu Umowy Wstępnej nie będę pisać jeszcze nic o kredycie ani Umowie Przyrzeczonej, dopóki nie dowiem się konkretów. Na ten moment wiemy, że powyższe dokumenty uzupełnione o dokumenty potwierdzające naszą zdolność kredytową, czyli:

• dokumenty tożsamości, 
• zaświadczenie o zatrudnieniu na druku bankowym (ważne 1 miesiąc)
• wyciąg z rachunku osobistego (na które wpływa wynagrodzenie) za ostatnie 6 miesięcy, 
• PIT11, 
• Ew. potwierdzenie posiadania wkładu własnego

wystarczą do rozpoczęcia przez bank procedury opiniowania o tym, czy dać nam kredyt (pozytywna decyzja kredytowa). Wiemy też, że Ostateczny Plan Podziału będzie potrzebny do uruchomienia kredytu, czyli w momencie podpisywania Umowy Przyrzeczonej, ale do tego jeszcze daleko (nasza Umowa Wstępna mówi o tym, że Umowa Przyrzeczona zostanie podpisana najpóźniej do 3 miesięcy po Umowie Wstępnej, lub wcześniej, jeśli zostanie wcześniej przyznana decyzja kredytowa i gmina zaopiniuje Ostateczny Plan Podziału).
W miarę postępów będę informować o dwóch kolejnych i zarazem ostatnich etapach kupna działki.

Moja rola w zespole to...

W środowisku projektowym konieczne jest wyznaczenie konkretnych osób do wykonywania konkretnych czynności i wzięcia za nie odpowiedzialności. Zapewne krzyk teraz podniosą agilowcy: "a gdzie zespoły cross - funkcyjne, zespoły w scrum nie powinny mieć ról". Nie ma tu jeszcze mowy o rolach i nie należy mylić ról z obowiązkami. Ale trzeba mieć świadomość, że projekt bez wskazania osób odpowiedzialnych za określone obszary jest skazany na niepowodzenie. Bez echa pozostaje wtedy pytanie rzucone zespołowi: "kiedy wersja będzie naprawdę gotowa do eksportu na produkcję?" - kto ma odpowiedzieć, jeśli zespół to bezkształtna masa bez osoby odpowiedzialnej za wydanie decyzji o gotowości kodu do takiego eksportu. 

Pojęcie roli

Rola to pojęcie nierozerwalnie związane z obowiązkami: ktoś o danej roli ma szereg określonych obowiązków z danego obszaru specjalistycznego. Ale ktoś kto ma określony obowiązek niekoniecznie musi mieć od razu daną rolę. Rola wskazuje niejawnie na specjalizację, pojęcie specjalizacji ma tu kluczowe znaczenie, nawet jeśli pracujesz w Scrum.

Teoria Scrum a praktyka Scrum

Przy okazji poruszenia tematu Scrum - dla zespołów praktykujących Scrum polecam publikację ze strony: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches. Publikacja ma podtytuł "How do we do scrum" i jest wciągającą  "war story" osadzającą oszlifowaną, wychuchaną i nienaganną teorię w twarde i nieubłagane realia projektowe. Ogólnie przestrzegam przed ślepym realizowaniem założeń teoretycznych bez wcześniejszego osadzenia ich w kontekście rzeczywistej sytuacji projektowej - korzystajmy z metodyk i dobrych praktyk, ale niech tłem do naszych decyzji projektowych będą doświadczenie, rozsądek i fakty. Możesz walczyć z realiami stojącymi w sprzeczności z teorią, ale z marnym skutkiem, mądrzej jest te realia zrozumieć i metodykę do nich dostosować niż obrażać się na rzeczywistość i powtarzać puste "powinno być". Ta publikacja pokaże Ci jak prowadzić rzeczywisty a nie wyimaginowany projekt w Scrum.

Rola a obowiązek

Nikt nie jest dobry we wszystkim. Dotyczy to rzecz jasna również programistów. Oznacza to, że nie ma co liczyć na to, że programista świetny w zarządzaniu bazami danych usiądzie i narysuje piękną grafikę, programista lubiący programować na poziomie warstwy biznesowej okaże się świetnym analitykiem a inżynier systemowy zostanie niezrównanym testerem. W projekcie potrzebny jest programista, webdeveloper, analityk, projektant, tester i każda z tych ról powinna znać zakres swoich obowiązków.
Dlatego też rola ma przewagę nad pojedynczym obowiązkiem. Analityk będzie wiedział jakie są jego obowiązki w zakresie analizy. Jeśli nie mamy analityka mamy problem, bo kto jest odpowiedzialny za ustalenia z klientem, kto za zarządzanie wymaganiami tego klienta na poziomie procesu biznesowego, kto za napisanie analizy, kto za uzgadnianie zmian wyglądu z webdeveloperem i sposobu działania aplikacji z projektantem. Bez analityka musimy wskazać osoby, które wezmą na siebie te obowiązki, potem rozrysować tabelę obowiązków, żeby zapamiętać te zobowiązania a następnie nosić ze sobą tą tabelę, żeby wiedzieć do kogo się udać, jeśli opóźnia się dokument analizy a do kogo chcąc się dowiedzieć jaka wygląda sytuacja z realizacją wymagań. Hmm.. Jakże łatwiej byłoby po prostu mieć analityka.

Zespoły o bezkształtej masie

 Pracowałam kiedyś z zespołem składającym się niemal w całości z nowicjuszy. Nie byli to jeszcze nawet dobrzy programiści, więc pytanie w czym każdy z nich się specjalizował w ogóle nie miało tu racji bytu. Projekt, który miał być przez nich zrealizowany miał znaczenie strategiczne dla komórki organizacyjnej (o doborze "specjalistów" do zespołu pisałam w topiku Kulisy formowania zespołu w IT). Będąc kierownikiem projektu wzięłam na siebie dodatkowo, chcąc nie chcąc, obowiązki analityka i testera. Nie popełniaj tego błędu! Nie będziesz miał czasu kierować zespołem, reagować na zagrożenia, planować, będziesz ciągle zatopiony w pracach codziennych na poziomie programowania i co najważniejsze - stracisz perspektywę, zaczniesz myśleć jak programiści - w kategoriach technologii i problemów z nią związanych oraz rozwiązań na te problemy proponowanych, nie jak kierownik - w kategoriach planów, fakturowania, spełnienia wymagań Umowy, nadzoru i koordynacji. Jeśli masz czas możesz naturalnie aplikację testować, ale jako odcięty od całego zespołu projektowego Użytkownik, a nie tester na pełny wymiar czasu pracy.

Jak pracować z zespołem niewyspecjalizowanych programistów

A więc co, jeśli nie mamy osób wyspecjalizowanych, którym możemy nadać poszczególne role w zespole projektowym?
Musimy sobie radzić i sukcesywnie przekazywać programistom obowiązki dotyczące obszarów specjalistycznych, wydobyć z organu zajmującego się wyłącznie programowaniem te komórki, które będą się specjalizować i przejmą funkcje w innych dziedzinach procesu produkcji oprogramowania. Rób spotkania, obserwuj, kto jest daną dziedziną zainteresowany, pytaj zespół, jak rozwiązać problem braków w obszarach specjalistycznych, przedstawiaj skutki tych braków. Pozwól zespołowi samemu podzielić się obowiązkami, ale nie zostawiaj ich z tym samych, w przeciwnym razie podział jakiego dokonają będzie rozmyty, chwilowy i poszatkowany. I nie wskazuj kogoś arbitralnie do danej roli chyba, że już faktycznie nie będzie innego rozwiązania.
Nie jest to szybki i łatwy proces, ale zwraca się z nawiązką - zespół zaczyna być samoorganizujący się i nie wymaga ciągłego nadzoru Kierownika Projektu.  

Rola dla spokoju

Role w zespole istnieją dla spokoju Kierownika Projektu i całego zespołu. Zespół z rolami ma strukturę, pracuje stabilnie i dojrzale, radzi sobie z problemami i nie wpada w panikę, gdy dzieje się coś złego. Role porządkują całe środowisko projektowe. Nie zgadzam się z tezą, że można prowadzić projekt zespołem bez wskazanych ról, czy choćby obowiązków, np. zespołem bez testera. Chyba, że chodzi o małe, półroczne projekty lub o projekty prowadzone przez zespoły lubiące pracować w chaosie, po nocach, na podwyższonym poziomie adrenaliny.

Trójkąt współpracy: produkcja, wdrożenie i sędzia (lub kat)

Nierzadki podczas realizacji projektów jest podział na zespół produkcyjny, czyli programiści zajmujący się aplikacją jako taką, oraz zespół wdrożeniowy, czyli wdrożeniowcy zajmujący się konfiguracją aplikacji na środowisku klienta.

Co złego to nie ja

Podczas jednego z tak prowadzonych projektów byłam kierownikiem od strony produkcji. Tak się bardzo nieszczęśliwie złożyło, że kierownikiem wdrożenia był mój przełożony. Nie życzę nikomu takiego rozłożenia projektów w jego komórce organizacyjnej. Z sytuacji, w której dwa zespoły powinny ze sobą współpracować celem osiągnięcia końcowego efektu rodzi się model zespół przełożony - zespół podwładny. Każda czynność do wykonania, łącznie z wszelkimi konfiguracjami, za które powinien być odpowiedzialny zespół wdrożeniowy, jest przerzucana na coraz to bardziej obciążony zespół produkcyjny a wszelkie problemy istniejące u klienta mają z założenia swoje źródło w zespole produkcyjnym.

U nas zaczęła się pewnego rodzaju nagonka na zespół produkcyjny, nagonka zupełnie niekontrolowana przez kierownika wdrożenia, czyli jednocześnie mojego przełożonego, a wręcz przez niego wzmacniana. Programiści zespołu produkcyjnego byli obwiniani notorycznie za błędy nieogarniętego zespołu wdrożeniowego.

Kat zamiast sędziego

Ponieważ nie ma w takiej sytuacji osoby obiektywnej, mogącej bez emocji ocenić sytuację między dwoma zespołami, przełożony, który w teorii powinien być sędzią i pomagać w sytuacjach konfliktowych, zamienia się w kata: każdy konflikt między wdrożeniem a produkcją przegra naturalnie podwładny (tu: kierownik zespołu produkcyjnego i zespół produkcyjny).

Kierownik produkcji w takim rozłożeniu projektów jest na przegranej pozycji - nie ma się do kogo zwrócić o pomoc. Co więcej - w przypadku, kiedy kierownik produkcji widzi, że część wdrożeniowa projektu przerasta kierownika wdrożenia, co wpływa negatywnie na cały projekt, nie może udać się do przełożonego w celu poinformowania o zagrożeniu, ponieważ właśnie przełożony, jak pamiętamy, jest tym właśnie kierownikiem wdrożenia. Istny absurd.

Konfliktową sytuację zaognił u nas fakt, że kierownik wdrożenia był kompletnie niezaangażowany w projekt, przerzucając całość prac i odpowiedzialność na produkcję, był zbyt optymistyczny i pewny siebie i w momencie, kiedy został przez klienta oczekującego postępów, jak i swojego przełożonego przyparty do ściany przebudził się z letargu i nie do końca jeszcze z tego letargu wybudzony, ale już na tyle, żeby się przestraszyć, jak zaspany człowiek, w popłochu i chaotycznie, zaczął szukać winnego poza sobą.

Programistę batem

Z czasem doszło do patowej sytuacji, kiedy zespół produkcyjny był obarczany błędami zespołu wdrożeniowego, a kierownik zespołu wdrożeniowego będący zarazem przełożonym kierownika produkcji zaczął, zamiast naprawiać własną sytuację projektową we wdrożeniu, proponować szalone pomysły, które miały de facto na celu szukanie winnych wśród produkcji i wytykanie ich palcem.

Pod pretekstem podsumowania dotychczasowych prac, podczas których każdy programista zespołu produkcyjnego miał opisać działanie danej funkcjonalności odbyło się biczowanie programistów, zostali oni zamknięci w psychicznej pułapce przełożonego i smagani batem bezsensownych pytań i bezpodstawnych oskarżeń o niedokładność i brak zaangażowania, ośmieszane były ich mniejsze lub większe decyzje, padały sformułowania, że coś jest "zrealizowane bez sensu" a nawet, że to jest "ch...we". Małe przedstawienie kierownika wdrożenia czyli mojego przełożonego przed jego przełożonym.

Było to bardzo irytujące dla mnie spotkanie (irytujące jest delikatnym słowem - nie byłam zirytowana, byłam wściekła) wiedząc, jak bardzo ci zrugani programiści starali się realizując projekt, ile serca włożyli w swoją pracę, jak chętnie zabierali się za kolejne zadania, wiedząc, że te oskarżenia są zupełnie nieuzasadnione. Po takim spotkaniu musiałam włożyć wiele energii, żeby ponownie zmotywować zespół, wcześniej jednak pooddychać kilkanaście razu licząc do stu, żeby ochłonąć, zarówno po spotkaniu jak i po nastałej po nim awanturze z przełożonym.

Wyjście z sytuacji

Najważniejsze jest uświadomić przełożonemu to, jak sytuacja wygląda z Twojej perspektywy. Jeśli rozmowa nie pomoże radykalnym wyjściem jest poszukanie pomocy u przełożonych wyżej (jest to oczywiście trudne, ale dla dobra projektów i zespołu konieczne) i nagłośnienie problemu tak, żeby ujrzał on światło dzienne. W mojej sytuacji ciśnienie urosło do takich rozmiarów a jednocześnie przełożony zdawał się nadal nie dostrzegać problemu (mimo jednoznacznych przesłanek od klienta, który z czasem poprosił o zmianę kierownika wdrożenia), że z racji braku wyjścia musiałam zacząć szukać pomocy u wyższego przełożonego, który ostatecznie został "sędzią", stawiając dwa zespołu na tym samym poziomie. Prace zaczęły płynąć swoim prawidłowym rytmem w atmosferze współpracy, aż do szczęśliwego odebrania projektu przez klienta. Jeśli u Ciebie dojdzie do takiej konieczności jak u mnie pamiętaj o bardzo ostrożnym rozegraniu tej sytuacji - koniec końców mamy do czynienia z naszym przełożonym. 

Kulisy formowania zespołu IT w korporacji

Ciężko jest zrobić coś z niczego - projekt informatyczny zespołu potrzebuje a im lepsi profesjonaliści wchodzący w jego skład tym lepiej. Bez zespołu nie ma projektu. Oczywiste? Nie dla wszystkich.

Kto ma wpływ na skład zespołu w korporacjach?

W firmach zatrudniających powyżej określonej liczby pracowników, zwanych pejoratywnie korporacjami, często spotyka się hierarchiczny model zarządzania firmą. Nie jest to zły model pod pewnymi warunkami. Jednym z tych warunków jest doświadczony, rozsądny kierownik komórki organizacyjnej, w której ma być realizowany projekt. Jego decyzje przekładają się bezpośrednio na to, jakim zespołem kierownik projektu dysponuje i będzie kierował, ponieważ to kierownik komórki organizacyjnej, jako przełożony kierownika projektu, przydziela mu zasoby.

Problem 1: Brak wykwalifikowanych zasobów

Jak powiedziane zostało wyżej, zespół jest formowany w korporacjach przez kierownika projektu i kierownika komórki organizacyjnej.

Może się zdarzyć, że  kierownik komórki organizacyjnej nie będzie w stanie ("co ja mogę?") lub nie będzie chciał ("są ważniejsze projekty") zaspokoić wymagań kierownika projektu co do zespołu, jaki jest konieczny do realizacji projektu. Może się zdarzyć tak, że nie będzie on w stanie zadziałać tak, by pozyskać odpowiednie zasoby z firmy. Lub tak, że będzie on przydzielał kierownikowi projektu ludzi dostępnych akurat w tym momencie, niekoniecznie osoby, które przez swoje doświadczenie i umiejętności odpowiadają na zapotrzebowanie wyspecyfikowane przez kierownika projektu, zarówno jeśli chodzi o liczebność zespołu jak i znajomość konkretnych technologii. Będą to po prostu dostępne w tym momencie osoby, nierzadko stażyści lub początkujący programiści, którzy na pieniądzach klientów uczą się dopiero technologii. Jako rezultat tych czy innych przyczyn dostaniesz do realizacji projektu zespół niewykwalifikowany.

Rozwiązanie:

• przy takim rozłożeniu sił, kiedy  kierownik komórki organizacyjnej przydziela zasoby do projektu a dostałeś mniej wykwalifikowane zasoby niż byś mógł należy już użyć nieco polityki, 
• jeśli faktycznie nie ma możliwości uformowania bardziej doświadczonego zespołu uświadom kierownika komórki o poziomie wiedzy tego zespołu i o tym, jak niski poziom jego wiedzy przekłada się na jego wydajność a z tym na przewidywaną datę końcową projektu. Ja w takich sytuacjach zwykłam używać jednostki mandays - programistę na poziomie średnio zaawansowanym liczyłam jako zasób o "wartości" 1MD, programistę-nowicjusza, zależnie od jego umiejętności, w przedziale 0,25-0,5 MD, wydajność zespołu była sumą takich mandaysów. Takie przedstawienie wydajności zespołu uzmysławia kierownikowi komórki, że zespół 5 nowicjuszy jest wart w rzeczywistości około dwóch (1,25 - 2,5) średnio doświadczonych programistów (a czasem nawet i mniej)
• poinformuj kierownika komórki, że realizacja projektu z takim zespołem jest demotywująca - masz prawo mieć szansę projekt zrealizować w terminie i kosztach a z niedoświadczonym zespołem ta szansa jest bliska zeru

Problem 2: Zespół z odzysku

Nie trzeba się silić, żeby wyobrazić sobie wartość zespołu składającego się z przypadkowo dobranych stażystów, wymienianych co chwila na innych stażystów czy nowych, niedoświadczonych pracowników.

Pracowałam kiedyś z zespołem "z odzysku" -  osoby przydzielane były przez kierownika komórki organizacyjnej do projektu na chwilę. Taki zespół nie ma struktury, nie można wyznaczyć konkretnych ról, wszystko pływa. Większość czasu kierownik projektu poświęca w takim przypadku na wdrożenia nowych osób do projektu zamiast na samą realizację celów projektowych. Jest to de facto ciągłe szkolenie nowo przybyłych do projektu osób bez zwrotu kosztów tego szkolenia - całkowity koszt takiego projektu rośnie niewspółmiernie do efektów, a projekt mający na celu spełnienie wymagań klienta zamienia się w centrum szkoleniowe.

U nas, przez takie roszady serwowane kierownikowi projektu przez kierownika komórki organizacyjnej, ani zespół ani kierownik nie byli w stanie pracować i realizować projektu.

Rozwiązanie:

• kiedy kierownik komórki będzie chciał kolejny raz przekazać Ci nowicjusza do projektu odmów z wyjaśnieniem przyczyn tej odmowy - nie masz czasu na ciągłe doszkalanie nowych członków zespołu a każde szkolenie to dodatkowy koszt,
• kiedy kierownik komórki obiecuje Ci pracownika, którego chcesz przyjąć do zespołu, żądaj od  kierownika gwarancji na dostępność tego pracownika na minimum dwa, trzy miesiące - nawet najlepsi potrzebują czasu, żeby się wdrożyć

Problem 3: Współdzielenie zasobów z przełożonym

W korporacjach współdzielenie zasobów w wielu projektach jest normą i nie ma w tym nic wyjątkowego ani niepożądanego. Jeśli w jednym okresie realizowanych jest wiele projektów, które nie wymagają ciągłej obecności osoby o danej rol (dobrym przykładem jest inżynier) można go oddelegować do innych projektów w razie potrzeby.

Jednak okropnym jest współdzielenie zasobów z przełożonym. Kierownik komórki stoi na drabinie organizacyjnej wyżej niż kierownik projektu i zapomina o podstawowych zasadach współpracy i współdzielenia dostępnych zasobów, podbierając kierownikowi projektu bez uprzedzenia i "na jedno zadanie" tych członków zespołu, których mu wcześniej przydzielił (niejednokrotnie tych, których kierownik projektu musiał sam wyszkolić i którzy w końcu zaczynają być wartościowymi, w kontekście zdobytej wiedzy technicznej, członkami zespołu, wnosząc do projektu mierzalny wkład).

W takiej sytuacji każde planowanie kierownika projektu jest bezcelowe, nie wiedząc czy jego przełożony nie zabierze mu za chwilę kluczowej osoby nie jest w stanie określić w harmonogramie ani dat, ani pracochłonności, nie jest też w stanie rozliczać zespołu z powierzonych zadań (bo jak rozliczyć programistę, który nie zrobił nic w projekcie przez ostatni tydzień, ponieważ przełożony kierownika projektu wyrwał go do zupełnie innego zadania nie informując go przy tym, już nie mówiąc, że nie pytał czy nie wpłynie to negatywnie na projekt). W takich okolicznościach kierownik projektu zwyczajnie nie jest w stanie projektu prowadzić.

Rozwiązanie:

• jeśli współdzielisz zasoby z przełożonym powiedz zespołowi, kto jest osobą autoryzowaną do zlecania im zadań, poinformuj o tej decyzji przełożonego i poproś go o zgaszanie zadań do realizacji bezpośrednio do Ciebie (lub kogoś, kogo wyznaczyłeś). Ty najlepiej wiesz, jak skoordynować prace, żeby zdążyć na czas. Jeśli ktoś będzie z pominięciem Ciebie wrzucał zespołowi nowe zadania Twój harmonogram rozsynchronizuje się i najprawdopodobniej za chwilę uwidocznią się opóźnienia),
• naucz zespół, żeby nie przyjmowali zadań od nieautoryzowanych osób. W przypadku, gdy nieautoryzowana osoba będzie chciała zlecić im jakieś zadanie, uczul ich, żeby odsyłali te osoby do Ciebie (nawet jeśli tą nieautoryzowaną osobą będzie ich wyższy przełożony!),
• ustal z przełożonym, jak będziecie się informować, kiedy będziecie chcieli wypożyczyć od siebie kogoś do swojego projektu, niech to będzie uzgodnione na waszym poziomie, programiści niech będą zwolnieni z tego, żeby rozważać, dla kogo dane zadanie wykonać

Zespół a sukces

Słaby kierownik jest w stanie z pomocą mocnego zespołu zrealizować projekt z sukcesem (w terminie, w ramach ustalonych kosztów czy spełniając inne Uzasadnienie Biznesowe). Nawet najlepszy kierownik nie jest w stanie osiągnąć tego sukcesu z kiepskim zespołem. 

Jako kierownik projektu masz prawo mieć własne wymagania odnośnie zespołu, którym zarządzasz. Pomyśl - gdyby trener nie miał wpływu na osoby, które szkoli do mistrzostw, jak można by go rozliczać z postępów? Niestety w korporacjach kierownik projektu nie ma jawnie wpływu na zespół, którym zarządza (dlatego wspomniałam, że czasem należy się uciec do polityki) a mimo to jest rozliczany z rezultatów. 

Jeśli jednak dostaniesz niewykwalifikowany zespół jasno zaznacz przełożonemu, gdzie jest tego zespołu granica, na ile można liczyć mając go do dyspozycji, nie zgadzaj się na cele, których nie będziesz w stanie z ich pomocą osiągnąć.