Kilka dni temu pisałem o tym, że trzeba mniej przy komputerze siedzieć, jeśli chcesz zrobić więcej. Dziś w poranną porcję RSSów wpadł post Rules of Productivity.

Danc, autor bloga Lost Garden jest autorem gier i przez kilka lat zbierał różne opracowania dotyczące wydajności pracy. Złożył to teraz w jedną prezentację, którą można pobrać w formacie PDF. Rzecz się odnosi głównie do pracy programistów, ale nie tylko.

Jakie wnioski?

Po pierwsze, oceniając produktywność należy oceniać całościowo rezultat - czyli to, jaką wartość dodaną (całokształt) tworzy zespół. Jeśli będziemy mierzyć np tylko liczbę linii kodu dodanych do repozytorium to łatwo przeoczyć fakt, że kod ten może nie posiadać przemyślanej architektury i za tydzień, miesiąc trzeba będzie wszystko przepisywać jeszcze raz. Czyli - produktywność może też być ujemna, gdy więcej się szkodzi niż tworzy pozytywnych cech.

Dla pojedynczych osób:

  • nie ma sensu pracować ponad 40 godzin tygodniowo. Krótkotrwały zysk na początku zostanie zjedzony w całości przez obniżoną wydajność później
    • Wydajność pracy przy sprincie ponad 40 h/tyd. Nie opłaca się

    Wydajność przy sprincie ponad 40 h/tyd. Nie opłaca się bo A << B

  • planuj czas tak aby mieć wystarczającą ilość snu (wypoczęty umysł ma zdecydowanie lepsze pomysły)
  • nie planuj pracy na 100% obciążenia - zostaw sobie 20% na eksperymenty, szukanie nowych rozwiązań
  • 40-sto godziny tydzień pracy jest optymalnym rozwiązaniem dla pracowników w przemyśle (12 lat badań Forda i innych na początku XX wieku). Przy pracy kreatywnej (rozwiązywanie problemów) ta granica pojawia się na poziomie 35 godzin tygodniowo. Rozważ skrócenie czasu pracy.
  • nie lekceważ ukrytych kosztów przepracowania (przegapionych okazji, naprawiania błędów i złych decyzji architektonicznych)

Kilka wniosków, które mogą pomóc stworzyć bardziej wydajne zespoły programistów:

  • produktywność małych zespołów (mniej niż 10 osób) jest zdecydowanie większa
  • zespoły powinny pracować razem (w jednym pomieszczeniu/grupie pomieszczeń) ale nie w tłoku (wydzielone miejsce na spotkania, komunikację)
  • mieszane zespoły (interdyscyplinarne) są znacznie wydajniejsze niż monolityczne grupy programistów czy designerów

Wszystkich zainteresowanych odsyłam do PDFu, są tam też materiały źródłowe.

Całość ma ręce i nogi :) ja się pod tym co jest w tym opracowaniu podpisuję. A wy macie jakieś votum separatum? Jeśli się nie zgadzacie lub coś chcecie dodać - zapraszam do komentarzy.

Lost Garden znalazłem przez Venture Hacks

Popularity: 9% [?]

Spodobało się? Podziel się z innymi: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Gwar
  • Ma.gnolia
  • Wykop

Hits: 706

Inne podobne wpisy: