Usługowy zespół programistyczny w firmie - planowanie prac

Podrzucam dziś problem, z którym spotkałem się kiedyś w swojej karierze, ale który myślę, że występuje w wielu miejscach i niejeden z Was miał okazję się z nim spotkać. Ciekaw jestem Waszych propozycji jego rozwiązania.

Załóżmy, że mamy następującą sytuację:

1. Firma dzieli się na kilka działów, z których każdy zajmuje się swoim nurtem działalności. Nie jest to działalność informatyczna, ale każdy z działów potrzebuje pewnych usług informatycznych (rozwoju aplikacji, stron intra i internetowych).

2. Oprócz tego w firmie jest dział IT, który wykonuje owe usługi na rzecz wspomnianych działów "produktowych".

3. Apetyty poszczególnych działów na usługi IT jest większy niż dział programistyczny jest w stanie dostarczyć. Oprócz zadań bieżących, każdy z działów deklaruje potrzebę przeprowadzenia dziesiątków prac, które nie są krytyczne, ale powinny być wykonane możliwie szybko.

Mamy więc sytuację ograniczonych zasobów i konfliktów o ich wykorzystanie. Szef każdego z działów uważa, że jego potrzeby są ważniejsze od innych i że jego prace powinny być wykonywane najpierw. Próby ustaleń wspólnych na spotkaniach przeradzają się często w awantury.

Chciałoby się wprowadzić system planowania prac, który:
1. nie wywołuje zbyt dużo negatywnych emocji :)
2. zapewnia, że najważniejsze prace są wykonywane najpierw
3. nie wymaga angażowania szefa wszystkich szefów

Jak w takiej sytuacji proponowalibyście planować prace? Z jakimi systemami planowania się spotkaliście? Jakie proponowalibyście procedury/narzędzia do zapanowania nad tym chaosem?

PS. Inny wariant tej sytuacji: różne zespoły w różnych działach korzystają z dużego systemu w firmie (np. CRM). Każdy zespół ma inne potrzeby i postulaty. System jest rozwijany przez firmę zewnętrzną, która wykonuje prace zgłaszane w ramach żądań zmian (change request). Firma ta jest w stanie wykonywać tylko ograniczoną liczbę CRów. W jaki sposób priorytetyzować CR? Jak rozstrzygać konflikty między zespołami?

Pozdrawiam,
Marek

Ciekawy problem i faktycznie pewnie czesto spotykany. Z moich doswiadczen wynika ze czesto korzystanie przez szefow dzialow z uslug dzialu IT wewnatrz firmy moze byc proba rozwiazywania problemow ktore faktycznie nie biora sie z brakow w oprogramowaniu lub ogolnie z problemow natury informatycznej. Nie zawsze napisanie jakiejs aplikacji intranetowej rozwiaze problem np. komunikacyjny wewnatrz dzialu czy wplynie na wzrost sprzedazy. Nalezaloby wiec doprowadzic do sytuacji w ktorej szefowie dzialow maja pelna swiadomosc tego ze zlecanie prac IT pociaga za soba wymierne koszty i to nie tylko wynikajace z czasu pracy osob zatrudnionych w dziale IT ale rowniez zwiazane z tym ze dany programista bedzie zajmowal sie pisaniem oprogramowania akurat wylacznie dla jego dzialu. Krotko mowiac wprowadzilbym system oszacowac i wyceny wewnetrznej zlecen i obciazal kosztem budzety dzialow tak zeby szefowie dobrze przemysleli kazde zlecenie wyslane do dzialu IT. Wycenie oczywiscie moglyby podlegac zarowno zlecenia napisania aplikacji jak i oddelegowanie programistow do rozwiazywania biezacych problemow dzialu. Co do praktycznej realizacji zlecen to dowolny system ticketow (mantis, fogbugz) pewnie wystarczy pod warunkiem ze kazde nawet najmniejsze zlecenie mialoby konkretnie opisany cel, spodziewany rezultat i przypisana osobe.

1. W małych firmach zazwyczaj nie ma tego problemu - dział IT jest mały, potrzeby adresowane do ekipy IT zazwyczaj sporadyczne i dające się szybko rzowiązać (założenie konta dla nowego pracownika itp), liczba działów w firmie dość mała. Problem zaczyna się pojawiać gdy organizacja rośnie.

2. W trochę większych firmach dobrym (i z mojego doświadczenia sprawdzającym się) rozwiązaniem jest funkcja oberdyrektora (dyrektora zarzadzającego, COO, jakkolwiek go znać) - osoby która jest na tyle blisko zespołów realizacyjnych że rozumie czym się zajmują, jakie mają potrzeby i jak to przekłada się na biznes i jest w stanie priorytetyzować grubsze zlecenia (drobne idą standardowym, bezpośrednim trybem). Niestety model ten się skaluje do jakichś 100 osób. Potem trzeba to zupełnie inaczej poukładać.

3. W dużych organizacjach mówiąc szczerze nie spotkałem się z modelem w którym wewnętrzny dział IT działałby sprawnie, wydajnie i realizował zadania zgodnie ze zdroworozsądkowymi priorytetami. Najskuteczniejszym rozwiązaniem jest posiadanie w każdym z działów firmy kawałka własnego, podlegającego dyrektorowi, zespołu IT działającego na potrzeby tegoż działu. W teorii, z punktu widzenia oszczedności kosztów na poziomie całej firmy to jest bez sensu, ale z drugiej strony straty jakie może prznieść olewanie potrzeb danego zespołu przez jeden duży, efektywny kosztowo, zespół IT mogą być nieporównywalnie większe. Wtedy również nie ma problemu nieobptymalnego wykorzystania zasobów IT, bo koszty automatycznie obciążają budżet zespołu. W takiej organizacji trudno jest ustandaryzować oprogramowanie na pewnych poziomach, ale mówiąc szczerze nie wierzę że firmy typu Prokom czy ComputerLand (a raczej Sygnity jak się ostatnio nazywają), które kupiły ileś mniejszych firm, mają to w jakikolwiek sposób ustandaryzowane na poziomie korporacji.

Pomysł może i kontrowersyjny, ale znam pewien zespół w jednej z firm z naszej polskiej czołówki, który w ciągu ostatnich 7 lat przeżył 7 przeprowadzek (w sensie zmiany miejsca biur w których pracują) i radzi sobie z każdym kolejnym przypadkiem świetnie tylko dlatego że jedyną nitką łączącą go z korporacyjnym IT jest mail. Zarządzanie wszelkiego typu serwerami developerskimi, siecią, systemami wewnętrznymi realizują własnymi siłami. I wszyscy nie mogą się nadziwić jak oni sobie tak sprawnie radzą z kolejnymi zmianami.

Witam. W mojej firmie jest jeszcze dział analiz, który analizuje zgłoszone 'zlecenia' pod różnymi kątami a dopiero po zaakceptowaniu zgłasza je do programistów i nadzoruje ich realizacje. Taki 'pośrednik' eliminuje też wszelkie kłótnie i spory, zlecenia zgłaszane są po kolei, i tak też są realizowane:) pozdrawiam!