Artykuł

freeimages.com freeimages.com
kwi 27 2016
0

Interdyscyplinarność vs specjalizacja

W jednym z ostatnich tekstów, pisałem o tym, że może trudno być programistą aż do emerytury. Konkluzja tego tekstu była taka, że wielu programistów może z czasem odrobinę zmieniać wykonywane stanowisko. Na szczęście w branży IT mamy tutaj spore pole do popisu ponieważ okazuje się, że istnieje życie poza deweloperką;-)

Skoro już poruszyłem temat różnorodności stanowisk, to chciałbym się z Wami podzielić moimi przemyśleniami do trochę powiązanego tematu. Od jakiegoś czasu zastanawiam się, czy lepiej dokonywać specjalizacji stanowiskowej (nie mylić ze specjalizacją w obrębie stanowiska czyli np. programista backend .net, programista backend java itp.), czy też może posiadać cechy/umiejętności, które pozwolą łatwo przełączyć się na inne stanowisko. W skrócie pytanie jest proste - czy lepiej postawić na interdyscyplinarność, czy specjalizację?

Wielkość ma znaczenie

To prawda stara jak świat, ale w tym przypadku chodzi mi o wielkość zespołu/firmy IT. Jeśli firma jest większa, istnieje spora szansę na specjalizację. W takiej sytuacji możemy podzielić pracowników m.in. na takie stanowiska:

  • Analityk
  • Architekt
  • Developer
  • Project manager
  • Team Leader
  • Tech Leader
  • Tester

Oczywiście taki podział powinien przyjmować odpowiednie proporcje. Wiadomo, że więcej powinno być deweloperów niż np. project managerów - bardzo łatwo jest wpaść w pułapkę zbyt rozrośniętej struktury pionowej.

Po iluś latach pracy w IT, zaczynam dostrzegać zalety specjalizowanych stanowisk. W praktyce w małych firmach bardzo często spotykamy głównie deweloperów. Ale to nie jest tak, że praca pozostałych stanowisk nie jest potrzebna. Po prostu część takich funkcji wykonywana jest nieformalnie przez programistów. Niektóre zaś są zaniedbywane - np. bardzo często jeszcze niestety testowanie...

To Scrum or not to Scrum?

Scrum tu, scrum tam.. sporo się o nim mówi, ale dla dużej części osób jest to podejście znane bardziej ze słyszenia. W praktyce nie jest łatwo pracować z tą metodyką, ale w tytułowym temacie wymusza ona mocną interdyscyplinarność.

Przy założeniu że na czas sprintu, cały zespół wybrany do tej metodyki musi mieć pracę, szybko okaże się, że np. nie da się być przez 100% czasu testerem, analitykiem, backendowcem, frontendowcem itd. Takie podejście wymusza większą wiedzę oraz umiejętność dostosowywania się do obecnej sytuacji.

Oczywiście w teorii da się złożyć zespół w takich proporcjach, że każda osoba będzie miała mniej więcej tyle samo pracy. Np. tester na początku sprintu, może zacząć pisać scenariusze, lub kod testów jednostkowych. Możliwości jest wiele, choć jeśli każda z osób będzie miała po dwie specjalizacje, na pewno będzie dużo łatwiej.

Jakie jest moje zdanie?

Moje zdanie jest takie, że specjalizacja jest fajna, ale powinniśmy mieć ogólnie świadomość tego co się również dzieje poza naszą komórką. Jeśli jesteś backendowcem, warto żebyś znał trochę frontend, by lepiej wiedzieć jak spiąć obie technologie. To działa również w dwie strony. Jeśli korzystacie z ASP.NET MVC, to Ty jako frontendowiec, powinieneś wiedzieć jak użyć składni Razora, czy też wykonać prosty kod C# w widoku. Tester z kolei powinien umieć pisać testy jednostkowe/automatyczne. W niektórych firmach testy piszą też programiści. Nie zapominajmy również o architekturze i analitycznym myśleniu... W praktyce więc nie odcinajmy się od innych stanowisk - wykształcajmy je, a szybko dostrzeżemy ich zalety.

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus