“Oferujemy znakomite warunki pracy w środowisku open-space“ – w ten sposób niektóre, zwłaszcza większe firmy kuszą potencjalnych pracowników. Szczególnie ma to być atrakcyjne dla fanów filmu "Office Space" sprzed dekady i mają w pamięci farmy pracowników upakowanych w niewielkie pudełka (cubicles). W porównaniu do tej rzeczywistości open-space ma być wyśnioną krainą wolnej przestrzeni, nie ograniczonej szarymi ściankami.

Często zdarzają się sytuacje, w których wiele dostępnych opcji wydaje się podobnych i trudno wybrać jedną. Łatwo wówczas popaść w manię analizy, zastanawiając się bez końca jakie konsekwencje będzie miała każda z decyzji. Wystarczy je tymczasem kolejno wypróbować, żeby niewielkim kosztem znaleźć tą najlepiej odpowiadającą potrzebom.

Najlepszą motywacją do pracy, dla programistów i nie tylko, nie są pieniądze, premie ani prywatne ubezpieczenie zdrowotne – jest nią wizja – odpowiedź na pytanie “dlaczego“ siedzimy i piszemy to oprogramowanie. Od ustalenia takiej wizji na piśmie należy zacząć każdy nowy projekt, jeszcze zanim napiszemy pierwszą historyjkę użytkownika.

A dlaczego miałbym pisać w Javie? To tylko jedna z dostępnych technologii, może najpopularniejsza, ale nie koniecznie najlepsza. Na ogół opieram się o inne platformy, a zawsze wybór języka programowania traktuję jako wtórny, podczas gdy na pierwszym miejscu musi stać funkcjonalność aplikacji.

Zakładając firmę musimy się liczyć z konkurencją na wybranym rynku. Nie należy nią sobie jednak nadmiernie zawracać głowy, ponieważ na ogół wcale nie jest taka groźna jak się wydaje. Na ogół wystarczy zadbać o jakość swoich towarów i usług, a już znajdziemy się lata świetlne przed innymi.

Warunkiem sukcesu dowolnego projektu informatycznego jest dobra jakość komunikacji między wszystkimi jego uczestnikami. Tymczasem stosunki między programistami a przedstawicielami biznesu przypominają raczej “przyjaźń” Toma i Jerry’ego. Można jednak i trzeba z takim stanem rzeczy walczyć.

Rozmowy z klientami bywają żmudne, trudne i prawie zawsze kończą się frustracją ze stwierdzeniem, że użytkownik nie wie czego chce. Stąd ważne jest aby rozmawiać z klientami ich językiem. Tylko jaki jest ten ich język?

Zbieranie wymagań to trudny i żmudny proces, od którego później zależy przebieg całego projektu. Długie spotkania, męczące rozmowy, marudni klienci. Nazbyt łatwo jest jakiś aspekt przeoczyć, który później w najgorszym możliwym momencie o sobie przypomni. Jest sposób, żeby sobie w tym procesie pomóc.

W interesie całego zespołu produkującego oprogramowanie jest informować klientów na bieżąco o postępach i problemach, które się pojawią. Im rzadsza komunikacja, tym więcej pola oddajemy ich wyobraźni, podsycanej obawami o losy projektu. Im dłużej zwlekamy z informacją o trudnościach, tym silniejsze będzie uderzenie, kiedy wyjdą na jaw. Warto postawić na przejrzystość.

Im większa firma tym chętniej wydaje się oddawać wszystko co popadnie w “outsourcing”. I tak korporacje, a ostatnimi czasy również mniejsze przedsiębiorstwa, oddają w ręce “zawodowych rekruterów” trudne i czasochłonne zadanie pozyskiwania nowych pracowników. Niewątpliwie oszczędza to czas i pieniądze, obawiam się jednak, że odcina również od potencjalnie najbardziej wartościowych kandydatów.

Wszyscy wiemy jak prowadzić projekt Agile, ale kiedy przychodzi co do czego pojawiają się problemy, których żaden “coach” nie wytłumaczył wcześniej. Jak poukładać repozytorium kodu? Jak zapewnić, że w chwili wydania iteracji kod nie będzie zawierał niedokończonych historyjek?