Po dwóch tygodniach mam już pewne obserwacje jak to wszystko wygląda. Muszę przyznać, że google play (czyli dawny android market) trochę mnie zaskoczył. Widać w nim naprawdę ciekawe rzeczy choć nie zawsze można się w nich połapać.

Wyszukiwarka

Pierwsza rzecz, która naprawdę niemiło mnie zaskoczyła, to wyszukiwarka. Wydawałoby się, że co jak co, ale wyszukiwać google potrafi. To niestety okazało się nie być do końca prawdą. Po wrzuceniu mojej aplikacji odpaliłem stronę google play i wpisałem w okno wyszukiwania nazwę mojej aplikacji czyli Business cards organized. Niestety google nie znalazł nic poza slabo pasującymi aplikacjami, które z pewnością nie były moją.

Nie zraziłem się jednak i sprawdzałem codziennie. Po kilku dniach google się nauczył wyszukiwać po nazwie, ale nadal słabo wyszukuje po wpisach zbliżonych do mojej aplikacji. Niestety podejrzewam, że teraz to już nie jest kwestia umiejętności wyszukiwania przez google, tylko jakiś zmyślny algorytm, który dyskredytuje moją aplikację ;(

Ekran aplikacji w google play

Konsola programisty

Z drugiej strony, czyli od strony programisty, można obserwować swoje aplikacje za pomocą konsoli programisty. Na głównym ekranie jest lista aplikacji developera (w moim przypadku mój dumny Business cards organized).

Główny ekran konsoli programisty

Na głównym ekranie mamy podstawowe dane statystyczne, czyli:

• link do szczegółów o aplikacji
• liczba ocen danej aplikacji oraz link do komentarzy
• informacje o liczbie zainstalowanych aktualnie oraz zainstalowanych w ogóle instancji aplikacji wraz z linkiem do bardziej szczegółowych statystyk
• link do raportu z błędami zgłoszonymi przez użytkownika

O tym co znajduje się pod linkiem ze szczegółami aplikacji opowiem innym razem, dzisiaj chciałbym Ci pokazać co możemy znaleźć w statystykach.

Panel statystyk w ogólności wygląda tak:

Ekran statystyk

Na samej górze można wybrać statystykę z ośmiu dostępnych:

• Urządzenia z aktywnymi instalacjami – liczba unikalnych, aktywnych urządzeń, na których aplikacja jest aktualnie zainstalowana
• Instalacje w ciągu dnia (urządzenia) – liczba urządzeń, na których w ciągu ostatniego dnia zainstalowano aplikację po raz pierwszy
• Dezinstalacje w ciągu dnia (urządzenia) – liczba unikalnych urządzeń, z których w ciągu ostatniego dnia odinstalowano aplikację
• Uaktualnienia w ciągu dnia (urządzenia) – liczba urządzeń, na których w ciągu ostatniego dnia uaktualniono aplikację ze starczej wersji do najnowszej
• Użytkownicy z aktywnymi instalacjami – liczba unikalnych użytkowników, u których aplikacja jest obecnie zainstalowana na co najmniej jednym urządzeniu
• Całkowita liczba instalacji (użytkownicy) – całkowita liczba unikalnych użytkowników, którzy kiedykolwiek zainstalowali aplikację na co najmniej jednym urządzeniu
• Instalacje w ciągu dnia (użytkownicy) – liczba unikalnych użytkowników, którzy w ciągu ostatniego dnia po raz pierwszy zainstalowali aplikację na co najmniej jednym urządzeniu
• Dzienne odinstalowania (użytkownicy) – liczba unikalnych użytkowników, którzy w ciągu ostatniego dnia odinstalowali aplikację ze wszystkich swoich urządzeń

Na prawo od listy z wyborem statystyki są jeszcze: pole pokazujące okres za jaki jest wykonywana statystyka, przyciski umożliwiające odfiltrowanie statystyki za zadany okres (ostatni miesiąc, trzy miesiące, sześć miesięcy, rok oraz wszystkie).
Poniżej znajduje się wybór wymiarów w jakim chcemy zobaczyć statystyki. do wyboru mamy:

• Wersja androida
• Urządzenie
• Kraj
• Język
• Wersja
• Operator

Każdemu wymiarowi odpowiada osobna zakładka, a na każdej z zakładek mam sekcję z wykresem, spisem najczęstszych wartości z procentowym i liczbowym udziałem w całej statystyce oraz statystyki porównawcze z kategorii, do której należy nasza aplikacja.

Muszę przyznać, że bardzo interesujące okazały się właśnie te statystyki porównawcze, ale o tym już napiszę następnym razem.
Tymczasem zadam wam taką zagadkę, na którą odpowiem w następnym poście:

Jaki kraj ma największy udział w pobraniu aplikacji w całej kategorii Biznes. Zaznaczam, że chodzi o całą kategorię, a nie tylko moją aplikację.
Piszcie odpowiedzi poniżej, ciekaw jestem czy zgadniecie

Wreszcie się ukazała, a już myślałem, że się nie uda jej wydać na Święta.
Mowa o książce kolegi Szymona Drejewicza, z którym miałem okazję współpracować przez jakiś czas w jednej firmie. Znając Szymona, przyłożył się do roboty i choć jeszcze nie czytałem, pozycja na pewno znajdzie się w mojej biblioteczce, abym mógł ją mieć pod ręką w razie potrzeby.

Zrozumieć BPMN

Więcej o tytule pod linkiem wydawcy, można tam również ją kupić (i chyba tylko tam na razie).

Ponieważ narzędzie opisywane przeze mnie poprzednim razem yUML, choć fajnie wygląda, okazało się być niewystarczające dla bardziej skomplikowanych diagramów, a twórca tego narzędzia olał moją prośbę o pomoc, postanowiłem szukać dalej.
W końcu opisanie diagramu jest na prawdę fajnie, a ręce, szczególnie programistów, nie zwyczajne do klikania myszką.

Oto co znalazłem:

1. UML Graph
Można za jego pomocą narysować diagram klas i sekwencji. To narzędzie nawet trochę przegina w stronę programowania. Tekst definiujący diagram klas na pierwszy rzut oka wygląda jak kod w javie. Drugim przegięciem jest to, że autorom najwyraźniej składnia pseudo-javowa nie leżała w przypadku diagramu sekwencji, więc zastosowali zupełnie inne podejście. Takie trochę rozdwojenie jaźni.
Narzędzie jest w javie więc jest “niezależne-javowo” od platformy systemowej.

Strona domowa jest pod adresem http://www.umlgraph.org/.

2. TextUML Toolkit
Motto tego narzędzia brzmi “Model as fast as you can type”. Ciekawe motto ;).
Narzędzie jest środowiskiem tekstowej budowy modeli, a do ich wyświetlania używa EclipseGraphviz, które samo w sobie jest ciekawym narzędziem.
Mamy tutaj pełne wsparcie środowiska jak podświetlanie składni i inne bajery.

Strona domowa jest pod adresem http://sourceforge.net/apps/mediawiki/textuml/index.php?title=TextUML_Toolkit.

3. Meta UML
O, to wygląda ładnie. Nie dość, że można w tym narysować całkiem sporo (Diagramy klas, aktywności, przypadków użycia, maszyn stanów i pakietów). Można tu rysować niezłe bajery, łącznie z zaawansowanymi elementami diagramów, jak i kolorkami poszczególnych elementów.

Strona domowa jest pod adresem http://metauml.sourceforge.net/, a najnowsza instrukcja dla użytkownika, jaką znalazłem to http://sunet.dl.sourceforge.net/project/metauml/metauml_manual/0.2.5/metauml_manual_0.2.5.pdf.

4. Plant UML
To jest dopiero ciekawostka. Nie dość, że można to zintegrować z eclipsem, to jeszcze z WORDem ;). Piszesz sobie w wordzie tekst, po czym klikasz przycisk i się tekst zamienia na diagram UML, przecież to jest piękne ;).
Narzędzie umożliwia zrobienie diagramów klas, przypadków użycia, sekwencji, aktywności, komponentów, maszyn stanów, i obiektów. Jednym słowem ful wypas w wordzie.

Strona domowa: http://plantuml.sourceforge.net/

5. Stary dobry LaTEX
Jak ktoś nie lubi WORDa, to z pewnością lubi LaTEXa
I to jest właśnie narzędzie dla niego. Szkoda, że można liczyć jedynie na diagramy sekwencji (więcej nie znalazłem), sam bym chętnie z tego skorzystał szczególnie, że diagram sekwencji wygląda całkiem sensownie.

Strona: http://www.texample.net/tikz/examples/pgf-umlsd/.

Żadne z narzędzi, jakie znalazłem nie udostępnia serwisu, który po prostu generuje diagram, jak robi to yUML. Szkoda, że się wywala na diagramach z większa ilością elementów, ale może twórcy coś z tym zrobią. Wyglądają na zapracowanych, skoro nie odpowiadają na maile (w sumie ich trochę rozumiem ).
No nic, trzeba wierzyć, że narzędzie się będzie rozwijało, albo powstanie jakieś inne. Na razie wszystkie, które znalazłem wymagają niestety instalacji czegoś.

A tak apropos, szukam chętnych, do potestowania powyższych przykładów i opisania swoich doświadczeń w komentarzu pod spodem. Ja się na razie zatrzymałem na przeszukaniu sieci i poczytaniu dokumentacji.

Są ochotnicy?

W dyskusjach bliskich darmowemu kursowi uml, który można znaleźć tutaj,
często poruszanym tematem było narzędzie do modelowania, które byłoby proste i najlepiej darmowe.
Różne propozycje padały, ale na takie coś, jak znalazłem dzisiaj bym nie wpadł.
Znalazłem na prawdę “proste” narzędzie do rysowania na szybko diagramów UML. Narzędzie jest tekstowe (na stronie głównej nawet jest notka “I love UTF8!”) i trzeba się tylko nauczyć składni, ale diagramy rysuje na prawdę ładne
Weźmy jako przykład kawałek diagramu ze wspomnianego kursu.

# Diagram z przykładu z http://darmowy-kurs-uml.scire.pl
[Klient]^[Firma]
[Klient]^[Osoba]
[Faktura]*->1[Klient]
[Faktura]1->*[PozycjaFaktury]
[PozycjaFaktury]*->1[Towar]

W wyniku dostaniemy bardzo ładny obrazek w formacie png, który wygląda następująco:

Prawda, że ładne? A jeszcze ten tryb odręcznego rysowania …

Wspomniane narzędzie to yUML, które można znaleźć na http://yuml.me/.
Można rysować diagramy klas, diagramy aktywności i diagramy przypadków użycia.

Tekst można wprowadzać w wersji podstawowej przez formularz na stronie, ale są też dodatkowe narzędzia, z których najbardziej spodobało mi się to na Androida.

Ciekaw jestem do czego mogłoby się wam takie narzędzie przydać i czy się wam podoba. Bardzo proszę, napiszcie w komentarzach.

Trzeba dodać, że nie wydałem ani jednego grosza na jakąkolwiek reklamę.

Muszę się przyznać, że tworząc darmowy kurs UML robiłem to początkowo z myślą o studentach, bo UML się przydaje na moich zajęciach, które prowadzę na MIM UW. Potęga “marketingu szeptanego” przeszła jednak moje najśmielsze oczekiwania.

Początkowa motywacja.

Jak wspomniałem, prowadzę na wydziale Matematyki Informatyki i Mechaniki Uniwersytetu Warszawskiego, zajęcia z inżynierii oprogramowania. Są to konkretnie laboratoria z Inżynierii Oprogramowania i mają za zadanie przećwiczyć (z grubsza rzecz biorąc) proces tworzenia oprogramowania. Równolegle do laboratorium jest prowadzony wykład, który ma dać podstawę teoretyczną i to bogactwo wiedzy mogłoby być wykorzystane na laboratorium od strony praktycznej. Pojawia się jednak mały problem, bo jedno i drugie (wykład i laboratorium) jest prowadzone równolegle i wykład czasami nie nadąża.
Nauczony doświadczeniem z poprzedniego roku postanowiłem się wysilić i wrzucić trochę wiedzy, która mogłaby pomóc i przygotować zawczasu przynajmniej tych studentów, którzy chcą coś robić więcej poza tym co muszą.

Co było dalej

Ponieważ z natury jestem (zdrowo ) leniwy potrzebuję dodatkowych bodźców. Na szczęście potrafię sobie te bodźce sam zapewnić i w myśl zasady “jak chcesz coś zrobić powiedz o tym wszystkim, a to zrobisz”, zrobiłem stronę służącą do zapisywania się na kurs i pochwaliłem sie paru znajomym. Między innymi mój stary kolega Jacek Laskowski, którego bloga gorąco polecam wszystkim pasjonatom JAVA i nie tylko, napisał o moim kursie na tymże blogu. Wcześniej dałem jeszcze link na goldenline.pl i się zaczęło.

Forma kursu

Długo zastanawiałem się nad formą i nad tym jak zdopingować ludzi do systematycznej pracy. Ostatecznie stanęło na wideo w odcinkach ze zdrową porcją wiedzy. Odcinki są podzielone odstępami około 3 dni, co wydawało mi się dobrym czasem na przetrawienie materiału i zrobienie ćwiczeń. Jednak jak zrobić, aby każdy uczestnik szedł swoim trybem (przecież nie wszyscy się zapisali równocześnie). Z pomocą przyszło tu narzędzie, które pozwala na automatyczne wysyłanie maili w określonych odstępach czasu.
W każdym mailu, staram się zwracać do uczestników w dość osobisty sposób tak, aby zapanowała dość luźna atmosfera i aby nawiązać ciekawą relację, bo przecież po drugiej stronie jest wartościowy człowiek. To przyniosło ciekawe efekty, ale o tym za chwilę.

Co się dzieje teraz

Od czasu opublikowania kursu cały czas przybywają nowi subskrybenci. Nazbierało się ich do dziś dnia prawie sześciuset. Ale to nie wszystko. Z wieloma nawiązałem ciekawą relację. Ludzie odpisują mi na maile, dziękują, dają cenne wskazówki i czekają na więcej.

Nic nie wskazuje na to, aby liczba subskrybentów przestała kiedykolwiek rosnąć, codziennie zapisuje się kilkadziesiąt nowych osób i wypada tylko się cieszyć, że z niczego wyszło tak wiele.

Jeśli zatem Ty również chcesz skorzystać, zapraszam !!!

Słownikowa definicja analityka systemowego mówi, że jest to osoba, która potrafi analizować złożone problemy organizacji w celu opisania tych problemów i przedstawienia ich w formie możliwej do przetwarzania przez systemy informatyczne. No dobrze, ale co to tak naprawdę znaczy? Kto powinien być analitykiem systemowym, informatyk, czy znawca badanej dziedziny? Jaką uczelnię powinien skończyć, aby poprawnie wywiązywać się ze swoich zadań? Powinien reprezentować interesariuszy biznesowych, a może zespół informatyczny, który będzie wykonywał prace projektowe. Gdzie w ogóle uczą bycia analitykiem systemowym? Hm, sporo tych pytań i nie bardzo wiadomo jak na nie odpowiedzieć. Ja jednak spróbuje to zrobić w tym artykule.

Wróćmy na początek do definicji. Wygląda na to, że analityk systemowy powinien przynajmniej być w stanie zrozumieć daną dziedzinę biznesową, bo inaczej jak by miał analizować „złożone problemy organizacji”. Tę tezę potwierdza również fakt, że musi to wszystko później opisać ludziom, którzy będą implementować jego rozwiązania w systemie informatycznym. Musi to zrobić w taki sposób, aby nie powtórzyła się znana historyjka z huśtawką (gdzie huśtawka spełnia wszystkie wymagania, ale nie da się na niej huśtać).

A więc analityk systemowy nie tylko musi zebrać wymagania i przetłumaczyć je na język bardziej strawny przez informatyków, ale również dopilnować, aby jego intencje zostały zrealizowane we właściwy sposób przez zespół informatyczny.

Spójrzmy na sprawę z jeszcze innej perspektywy. Co będzie jeśli wymagania są zebrane, system w połowie zaimplementowany, a rząd wprowadzi nową ustawę, która całkowicie wywróci projekt do góry nogami? Albo co będzie jak sprawdzi się powszechna opinia, że użytkownicy biznesowi sami nie wiedzą czego chcą dopóki czegoś nie zobaczą? Kto wtedy będzie odpowiedzialny za wyprostowanie sprawy?

Kto powinien być analitykiem systemowym?

Najlepiej jakby była to osoba z doświadczeniem. Wynika to z tego, że rzadko uczy się na uczelniach analizy systemowej. Na informatyce jest to elementem inżynierii oprogramowania i uczą tego zwykle informatycy. Z kolei na uczelniach dziedzinowych gorzej jest z nauczaniem elementów „twardej” wiedzy informatycznej (oczywiście pewnie znajda się wyjątki). A tymczasem analityk powinien być dość zaawansowany technicznie, aby wiedział co się da zrobić, a czego nie. Z drugiej strony powinien umieć słuchać i nie bać się pytać, gdy czegoś nie rozumie. Parafrazując znaną maksymę „analityk ma dwoje uszu, a tylko jedne usta po to, aby dwa razy więcej słuchać niż mówić”. Jednak mówić powinien, szczególnie wypytać o wszystko czego nie rozumie, więc nieśmiałość i poczucie wstydu z byle powodu odpada.

Dodatkowo bardzo przydatne jest, jeśli analityk zna się na dziedzinie, której problemy analizuje. Analityk będzie dużo rozmawiał z biznesem i jeśli będzie ciągle zadawał pytania w stylu „co to jest prolongata” doprowadzi do irytacji swoich rozmówców. Ale i tak lepsze to niż udawać, że się wszystko rozumie.

Rola i odpowiedzialność w projekcie

Z grubsza rzecz biorąc, rolą analityka systemowego w projekcie jest zbieranie i zarządzanie wymaganiami. Aby tego dokonać analityk musi zadbać o to, aby znane mu były przynajmniej te procesy biznesowe, które mają jakąś interakcję z budowanym systemem.

Po zrozumieniu niezbędnych procesów biznesowych, analityk systemowy zajmuje się wydobywaniem wymagań na system. Musi zatem zlokalizować miejsca styku procesów biznesowych z systemem i opisać to, jak w poszczególnych procesach biznesowych wykorzystywany będzie system i kto z niego będzie w tych miejscach korzystał. Do opisywania tej części rzeczywistości, analityk na szczęście ma stosowne narzędzia, a na ich czele stoi UML (ang. Unified Modeling Language).

W następnym etapie, analityk musi opisać jak dana interakcja z systemem (przypadek użycia) będzie obsługiwana przez system.

Warsztat łącznika dwóch światów

Procesy biznesowe – niby nie jest niezbędne ich rozumienie, zawsze można skupić się na wymaganiach funkcjonalnych i zapomnieć o zrozumieniu merytoryki procesów biznesowych. Jednak użytkownicy, którzy opowiadają o swoich wymaganiach zwykli o czymś zapominać. Ponieważ lepiej żeby sobie przypomnieli już na samym początku, podczas rozmów o tym jak pracują i próby zrozumienia procesów biznesowych, można ograniczyć przeoczenia, czy niedociągnięcia. Trzeba też pamiętać, że ludzie biznesu nie robią tego złośliwie, raczej niektóre rzeczy wydają się tak oczywiste, że „nie warto o nich wspominać”. Do modelowania procesów biznesowych można wykorzystać diagramy aktywności w UML. Są też bardziej dedykowane notacje, jak BPMN (ang. Business Process Modeling Notation).

Funkcjonalność systemu – do modelowania funkcjonalności używa się zwykle diagramu przypadków użycia (ang. Use Case Diagram). Są na nim dwa główne artefakty. Pierwszy z nich – Aktor – obrazuje osobę lub urządzenie korzystające z systemu. Drugi artefakt, to Przypadek użycia (ang. Use Case) odzwierciedla on funkcję systemu, którą wykorzystuje Aktor. Należy zaznaczyć, że aktor jest zawsze na zewnątrz Systemu, a Przypadek użycia obrazuje to, co się dzieje wewnątrz.

Realizacja funkcji systemu – aby dowiedzieć się jak działa dana funkcja systemu niezbędny jest opis danego przypadku użycia. Służą do tego scenariusze. Można je opisywać za pomocą języka naturalnego, lub skorzystać z części UML jaką są diagramy aktywności.

Narzędzi informatycznych wspierających opisywanie systemów za pomocą języka UML jest mnóstwo. Niektóre próbują nawet (z lepszym lub gorszym skutkiem) z takiego opisu generować gotowy kod systemu lub przynajmniej szkielet kodu, który później programista może uzupełnić.

Ciekawa nisza

Z punktu widzenia planowania kariery zawodowej, niewątpliwie warto rozważyć karierę analityka systemowego. Jeśli już przepracujemy przed ekranem monitora wiele godzin i przejdzie nam ochota na poznawanie kolejnego rewolucyjnego języka programowania warto rozważyć pracę bliżej biznesu. Dzięki temu można poznać wielu ciekawych ludzi, a charakter tej pracy da nam również możliwość poznania wielu dziedzin biznesowych, bo przygotowując wymagania na system informatyczny można naprawdę dużo dowiedzieć się o tym jak działają nawet najbardziej złożone organizacje.

Jeśli więc lubisz technologię i nie chcesz się z nią całkowicie rozstawać, a jednocześnie chciałbyś poszerzać swoje horyzonty, polecam zajęcie analityka systemowego. Może się okazać, że z czasem zagniesz swoją wiedzą o bankowości niejednego bankowca, a o księgowości niejednego księgowego.

Kiedyś przeczytałem tę książkę i napisałem krótką zachętę do jej przeczytania. Postanowiłem to tu wrzucić, może się komuś przyda.

———————————-

No i stało się, postanowiłem napisać recenzję książki. W sumie to klasyka i na pewno wszyscy już czytali, ale gdyby się okazało, że nie, to może uda mi się zachęcić, bo naprawdę warto.

„Czynnik ludzki” opowiada o tej bardziej zaniedbywanej części zarządzania projektami. Wszyscy zazwyczaj, zachwycają się niezliczonymi metodykami zarządzania projektami, a tak często zapominają, że powodzenie przedsięwzięcia zależy w głównej mierze od ludzi biorących w nim udział.

Co jest powodem zaniedbywania tego, jakże ciekawego aspektu zarządzania? Myślę, że brak gotowej recepty na postępowanie gwarantujące sukces. Łatwo jest „klepać” harmonogramy, manipulować zasobami i przydzielać je do, z góry zaplanowanych zadań. Łatwo jest rysować za pomocą przyjaznego narzędzia sieci PERT czy diagramy GANTA. No, może nie łatwo, ale w każdym razie o wiele łatwiej się tego nauczyć niż sprawić, aby zespół miał do kierownika zaufanie, aby traktował go, jako swojego partnera, a nie krwiożerczego karierowicza realizującego po trupach swoje indywidualne cele.

Książka DeMarco i Listera jest jak głos wołającego na pustyni: kierowniku, nie skupiaj się na technicznych aspektach zarządzania, nie ograniczaj się do przesuwania pionków na szachownicy, pracujesz z żywymi ludźmi, którzy mają swoje rodziny, swoje złe i dobre dni, swoje ulubione dyscypliny sportu i czasami lubią w niedzielne popołudnie pójść do muzeum. Znajdziemy tu zbiór doświadczeń autorów, analiz skutków rutynowych działań kierownictwa, które przemykają niezauważone po korporacyjnych korytarzach, a okazują się być ważnym czynnikiem wpływającym, na jakość pracy specjalistów.

Książka podzielona jest na sześć części. Pięć pierwszych części, dotyczy wybranych zagadnień „miękkiego” zarządzania (opiszę je bardziej szczegółowo niżej). Szósta część pojawiła się w czytanym przeze mnie, drugim wydaniu i jest pewnego rodzaju uzupełnieniem pierwszego wydanie (nosi tytuł: Dalszy ciąg książki „Czynnik ludzki”).

W pierwszej części, o zarządzaniu zasobami ludzkimi, autorzy zauważają bardzo istotną, i wydawałoby się dość oczywistą rzecz. Pomimo powtarzalności działań związanych z przedsięwzięciami informatycznymi nadal całkiem często zdarzają się niepowodzenia. Mało tego, okazuje się, że prawie nigdy przyczyną niepowodzenia nie są sprawy techniczne. Prawie zawsze zawodzą ludzie.

Część o środowisku pracy wyjątkowo przypadła mi do gustu. Żaden z tematów przedstawionych w tej książce nie jest aż tak wyrazisty i powszechny jak ten. Dowiemy się tu czy otwarte przestrzenie biurowe, tak reklamowane w dzisiejszych czasach sprzyjają pracy twórczej. Czy telefon był tak wspaniałym wynalazkiem, jak nam się wydaje. Czy kierownik nie powinien czasem zabawić się w elektryka, aby zapewnić spokój swoim pracownikom, oraz jakie zalety ma krypta patronki jednego z amerykańskich uniwersytetów.

Jeśli przed nowym przedsięwzięciem zaprosiłeś swój zespół programistów na wspólnie przygotowywaną kolację, może się okazać, że to najlepsza rzecz, jaką zrobiłeś jako kierownik zespołu. Oprócz tego rodzaju ciekawostek, w trzeciej części znajdziemy również bardzo oryginalny przewodnik po efektywnych sposobach rekrutacji pracowników oraz dowiemy się, w jaki sposób (tym razem negatywnie) może wpłynąć na przedsięwzięcie metodologia przez wielkie „M”.

Choć tłumacze zatytułowali czwartą część „Hodowanie wydajnych zespołów”, ja bym był raczej za tytułem „Uprawianie wydajnych zespołów” (ang. „Growing Productive Teams”), bo autorom, o ile dobrze zrozumiałem, chodziło o analogię z uprawą roślin. Nie da się stworzyć wydajnego zżytego zespołu. Należy raczej stworzyć odpowiednie warunki, do jego powstania a potem mieć nadzieję, że zbierzemy obfity plon. Ciekawa analogia, a przedstawione sposoby tworzenia dobrych warunków do uprawy zgranych zespołów równie ciekawe, jak zaskakujące.

Czyż nie wpojono nam przez pokolenia, że praca z reguły jest ciężka, a przynajmniej powinna być ciężka? Co to za praca, która staje się przyjemnością, to żadna praca. Otóż nie, praca może być, a nawet powinna sprawiać przyjemność. To żadem grzech, że robimy to, co lubimy i w dodatku zapewnia nam to godziwe warunki życia. Jednak z reguły, kierownictwo firm pielęgnuje ten wpojony przez lata model. Pracownik musi dostać w kość, jeśli nie jest dostatecznie po pracy zmęczony oznacza to, że się obijał. Autorzy w ostatniej (poza uzupełniającą) części tłumaczą, dlaczego warto, a nawet należy cieszyć się, jeśli praca w firmie dostarcza pracownikom przyjemności oraz jak sprawiać, aby tak właśnie było.

Podsumowując, jest po pozycja obowiązkowa, dla każdego, kto bierze udział w przedsięwzięciach informatycznych. Czyta się lekko i przyjemnie, jest napisana z humorem, a treści w niej zawarte są poparte nieprzeciętnym doświadczeniem autorów i przytaczanymi przez nich przykładami wziętymi z ich życia zawodowego. Oczywiście trudno jest zmieniać wszystko w sposobie prowadzenia projektów w naszej firmie po przeczytaniu książki, jednak warto widzieć rzeczy, których zazwyczaj nikt nie dostrzega, a jak uda nam się zmienić jeden szczegół, który sprawi, że zespół przez nas kierowany, lub w którego pracach uczestniczymy, stanie się wyjątkowy, na efekty nie trzeba będzie długo czekać.