SMARTER czyli definicja celu według Prince2

„Prince 2” pozwolił mi trochę inaczej spojrzeć na definiowanie i osiąganie celów. Metodyka ta w swojej definicji dokonuje jasnego rozróżnienia między CELEM, a KORZYŚCIAMI związanymi z osiąganiem danego celu.

Uważam, że wielu z nas często popełnia ten błąd, że zamiast wyznaczać sobie cel, który będziemy osiągać wyznaczamy sobie korzyść jaką chcemy mieć. Łatwo się domyśleć, że od samego chcenia jakiejś korzyści ona sama się nie pojawi. Należy najpierw osiągnąć cel, w wyniku, którego odetniemy kupony z korzyściami.

Continue reading →

Trzymaj się jednego sposobu osiągania danego celu

Zmieniając swoje zachowania, zasady, sposób postępowania, za każdym razem zaczynamy wszystko od nowa i nigdy nie osiągamy rezultatów. Wierz w to co robisz. Nigdy nie wolno Ci się zniechęcać. Nie szukaj wymówek. Wytrwałość w osiąganiu celu wybranym jednym sposobem jest kluczem do sukcesu.

Na przykład, gdy chcesz się nauczyć języka obcego. Rozpoczynasz starannie wybrany kurs. Gdy pojawiają się pierwsze trudności nie zmieniaj tego kursu na inny bo wtedy zaczynasz od nowa.

Trzymaj się wybranego sposobu rozwiązania, nie zmieniaj go co chwilę, nie wymyślaj nowych zasad.

Nie ważne ile kursów zaczniesz. Ważne ile skończysz. Trzymaj się jednego sposobu osiągania danego celu.

Scrum a błędy na produkcji

Klasyfikacja błędów

Bugi klasyfikujemy ze względu na DOLEGLIWOŚĆ oraz ZŁOŻONOŚĆ. Każda z tych klasyfikacji może osiągnąć poziom WYSOKI lub NISKI. Każdy bug możemy przyporządkować do jednej z czterech kombinacji tej klasyfikacji.

  • Wysoka złożoność i wysoka dolegliwość.
  • Niska złożoność i wysoka dolegliwość.
  • Wysoka złożoność i niska dolegliwość.
  • Niska dolegliwość i niska złożoność.

Continue reading →

Osiąganie najwyższych tonów & Odnajdywanie świetnych programistów

To czy firma programistyczna osiągnie sukces na rynku zależy od warunków pracy.

Najlepsze warunki pracy,

przyciąga najlepszych programistów,

którzy piszą najlepszy kod,

który przynosi zysk.

Nawet bardzo liczna grupa przeciętnych programistów, niezależnie od czasu jaki poświęci na tworzenie kodu zawsze napisze oprogramowanie, które jest tylko przeciętne podczas gdy zaledwie kilku bardzo dobrych programistów w krótkim czasie jest wstanie napisać bardzo dobre oprogramowanie.

Continue reading →

Szybciej, wolniej, wolniej

Poniższy fragment książki jest brutalną prawdą, esencją strasznej zarazy panującej w firmach, która z zimną krwią wyniszcza wszystko, co jej stanie na drodze.

Systematyczne lekceważenie planowania i projektowania prowadzi do rozwoju w cyklu „szybciej, wolniej, wolniej”.

Wygląda to mniej więcej tak:

  1. Błyskawicznie dostarczasz wersję 1.0, pisząc cały kod na kolanie.
  2. Budujesz wersję 2.0, na bieżąco rozwiązując problemy stwarzane przez uciążliwy bałagan w kodzie.
  3. Wraz z kolejnymi wersjami rozwiązywanie problemów ze starym kodem „na bieżąco” sprawia, że bałaganu przybywa, a praca staje się coraz wolniejsza. Wyrzyscy stopniowo tracą wiarę w system, programistów i całą sytuację, w której się znaleźli.
  4. Gdzieś w okolicach wersji 4.0 zdajesz sobie sprawę, że nie wygrasz. Zaczynasz rozważać opcję przepisania systemu od podstaw.

„Refaktoryzacja do wzorców projektowych” Joshua Kerievsky

Continue reading →

Rozmowa telefoniczna

Podczas rekrutowania programisty rozmowa telefoniczna pełni funkcję filtrującą. Jeśli podczas takiej rozmowy nie możemy się dogadać, to jest to wystarczający powód do tego aby już na tym etapie zdecydować, że danej osoby nie zatrudnimy. Przed zaproszeniem kandydata na właściwą rozmowę kwalifikacyjną zwykle dzwonimy do niego, aby się upewnić, że organizacja spotkania nie będzie zwykłą stratą czasu i pieniędzy.

Rozmowa telefoniczna jest tania. W krótkim czasie eliminujemy masę kandydatów, którzy na papierze sprawiali wrażenie na prawdę dobrych.

Rozmowa kwalifikacyjna powinna składać się z trzech etapów.

Continue reading →