Monthly Archive for 01.2007

Same konkursy

Styczeń przyniósł wiele możliwości otrzymania statusu gwiazdy. W tym konkursy na bloggera roku. Póki co, wiem o dwóch.

Polski Blogger

Najpierw zostałem zgłoszony do konkursu organizowanego przez Pawła Lipca.

Strona konkursu pozostawia, mówiąc oględnie, odrobinę do życzenia (podobnie jak i blog Pawła, ale nie o tym jest notka). O ile wygląd mogę zrozumieć, bo jest to najpopularniejszy — i bardzo zgrabny — temat graficzny dla Wordpressa, tak chaos informacyjny jest trudny do ogarnięcia.

W jury widać same sławy blogosfery. Od Igora Janke, znanego publicysty, aż do Krzysztofa Urbanowicza, którego znaleźć można nawet w konserwie, jeśli tylko etykieta zawiera gdziekolwiek napis 2.0.

Regulamin przeczytałem od deski do deski. Wynika z niego, co następuje:

  • wziąć udział mogą wszyscy i za darmo, nie trzeba mieć nawet bloga
  • zgłosić można nawet cudzego bloga, bo konkurs jest dla internautów, a oceniane są blogi
  • oceniane jest coś, co się nazywa ogólne wrażenie — cokolwiek by to nie było
  • nie muszę wyrażać zgody na przetwarzanie moich danych, bo mojego bloga zgłosił ktoś inny, czyli w rozumieniu regulaminu nie jestem uczestnikiem
  • zgłaszający mojego bloga nie musiał też zgodzić się na publikację informacji o Room 303, bo jest to wymagane tylko w przypadku zgłaszania swojej strony

wiadomosci24.pl

Drugi konkurs, tym razem na bloggera, organizują wiadomosci24.pl. Tutaj do zgłoszenia bloga zaprosił mnie email. Nie wiem, od kogo, bo był sformułowany na tyle ogólnie, że cudem uszedł z życiem po przebiciu się przez filtry antyspamowe.

W mailu znalazłem link do informacji opublikowanej w aktualnościach. Tam z kolei trafiłem na link do regulaminu. Jest lepszy niż ten wspomniany wcześniej.

Powiedziałem sobie cicho Jeronimo! i postanowiłem wziąć udział. I tak postanawiałem. Przez dobrych 20 minut. Przeczytałem regulamin kilka razy, od deski do deski. Wszędzie stało jak byk, że zgłosić można się na specjalnej stronie, ale odnośnika do tej specjalnej strony już nie było. Poirytowany zacząłem szukać w podglądzie źródła HTML i znalazłem. Okazało się, że za rejestrację odpowiada ten wielki czerwony banner graficzny w kolumnie nawigacyjnej, który moje oczy przez wspomnianych 20 minut skutecznie omijały. Brawo za użyteczność interfejsu.

Dziś dostałem za to potwierdzenie przyjęcia bloga do oceny. Z miejsca jednak znalazłem się na przegranej pozycji, bo dwa pierwsze miejsca z pewnością przypadną blogowi Riddle’a. Taką właśnie liczbę razy został on bowiem przyjęty. :)

A potem opanujemy świat

Skoro w pierwszym konkursie wygra za mnie ktoś inny (a drugi raz bloga zgłosić nie mogę), a w drugim padam pod przeważającą siłą konkurencji, to pozostało mi tylko jedno. Zorganizujemy sobie własny konkurs i wybierzemy bloga roku 10przykazan.

Oczywiścię żartuję, ale możecie się spodziewać, że niedługo opublikujemy statystyki dotyczące popularności poszczególnych blogów z tego właśnie serwisu (bo do innych serwisów nie mamy dostępu, haha).

Aby palec zwinny…

jpc poprosił, żebym się ustosunkował do notki Dobry zwinny, zły zwinny. Czytałem ją gdzieś w okolicach października i nie bardzo chcę się teraz przegryzać ponownie przez cały tekst, dlatego zamiast cytować, napiszę, co sam myślę o tak zwanych zwinnych metodach prowadzenia projektów.

Część z was pewnie miała już okazję przeczytać Kiedy pomysły umierają… na blogu nbw. Reszta powinna teraz zabrać się za lekturę. Pracujemy z Tomkiem w tej samej firmie, więc poniżej znajdziecie właściwie tylko uzupełnienie jego tekstu.

Projekt

Zanim zaczniesz stosować jakiekolwiek ekstremalne metodyki, musisz przede wszystkim zrozumieć, że nie nadają się do każdego projektu. To, co działa dla Google czy 37signals, nie musi działać dla twojego produktu.

Kiedy nie zadziała? Kiedy budujesz coś dla konkretnego klienta i kiedy to klient dostarcza specyfikację funkcjonalności. Dla niego nie jest ważne, żeby mieć jakikolwiek produkt (czy będzie to program, strona WWW, czy jakikolwiek inny projekt programistyczny). Kiedy jedziesz z samochodem do mechanika, też nie oczekujesz przecież, że dziś przykręci jedną śrubkę, a po tygodniu jazdy spyta, czy mocno stuka, bo nie jest pewien, czy najpierw przykręcić drugi koniec zderzaka, czy może wymienić płyn hamulcowy.

Firma

Metodyki agile mają to do siebie, że wywołują śmiech u dyrektorów dużych firm. Powód jest prosty — korporacje przez dekady dopieszczały błyszczące schematy hierarchii, wiszące w wielkich szklanych gablotach tuż obok recepcji. Proces decyzyjny wymaga przesłania tony makulatury w górę drzewka tylko po to, żeby propozycja trafiła do pracownika siedzącego w biurze koło ciebie, ale pracującego w innym pionie.

Agile z drugiej strony promuje czysto asekuracyjną rolę managerów. Nie ma miejsca na wielowarstwową strukturę zwierzchnictwa, managerowie to bardziej przywódcy niż szefowie. Mają ostatnie słowo przy podejmowaniu decyzji, ale z tego przywileju korzystają tylko w ostateczności. W związku z tym, najłatwiej metodyki takie wprowadzić w firmach małych, zatrudniających kilka-kilkanaście osób. Zwinność stawia na siłę zespołu, a nie precyzowanie każdego elementu w specyfikacji technicznej.

Zespół

Tu znów kontrast z borgiem. Jeśli projekt ma się powieść, zespół musi być mały, co zapewnia łatwość komunikacji. To pociąga za sobą dużo większe wymagania odnośnie predyspozycji każdego z członków zespołu.

Pracując przy aplikacjach klasy enterprise (na przykład systemy wspomagania prowadzenia przedsiębiorstw), miałem kilka razy okazję poznać sposób powstawania oprogramowania. Z boku wyglądało to tak, jakby Albert Einstein stał na cokole pośrodku sali i rzucał banany małpom klepiącym w klawiatury. Podejrzewam, że w niejednym zespole jedyną kompetentną osobą był właśnie manager, który doglądał całej bandy klepaczy.

Zwinność kładzie silny nacisk na zaangażowanie zespołu w życie projektu. Każdy z biorących udział w powstawaniu produktu musi kochać swoją pracę i potrafić podejmować decyzje działające na korzyść projektu, a nie oszczędzające pracę. Nie ma tu miejsca dla maszynistek, które potrafią szybko klepać kod, ale co chwilę trzeba im mówić, co mają robić dalej.

Podsumowując

Aby wdrożenie nowej polityki prowadzenia projektów się powiodło i miało sens, potrzeba pasji. Nie tylko ze strony zarządu, nie tylko ze strony programisty. Potrzeba chęci przejścia na nowy tryb ze strony wszystkich pracowników, którzy mają jakikolwiek udział w rozwoju projektów.

Żeby przerwać łańcuch, wystarczy jedno słabe ogniwo. Dlatego jedna osoba, która nie będzie myśleć tak, jak reszta, znacznie osłabi zespół (który i tak jest przecież mały), a w rezultacie może doprowadzić do zgonu całego projektu. Nie musi nic specjalnego robić, wystarczy, że swoją niechęcią do wszystkiego będzie wpływać na morale reszty grupy i zniknie pasja.