W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
> dodatkowy język wiąże się z dodatkowymi kosztami.

Jest też komplementarne pytanie, jakie są koszty nie-ogarnięcia.

Pasuje tu dowcip:

Dyrektor IT: Musimy przeszkolić naszych pracowników.
Księgowy: A co będzie, jak ich wyszkolimy a oni wtedy odejdą?
Dyrektor IT: A co będzie, jak ich nie wyszkolimy a oni nie odejdą?

> Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
> checkboksów?

Z refleksji wynika lista checkboksów a z tej listy konkretne rozwiązanie problemu.

Najpierw zastanawiamy się co jest źle, potem co powinniśmy zrobić, żeby było lepiej a
z tego wynika, jakim produktem/technologią/itd. należy się posłużyć, żeby to
wypełnić.

> Bo widzisz, w praktyce zawsze tworzący listę będzie też
> uważał, że niektóre checkboksy są ważniejsze od innych.

Tak.

> W praktyce w skali zespołu zawsze będziesz miał ograniczenie polegające
> na tym, że rekrutowani byli ludzie z określonymi umiejętnościami.

"Oczekujemy gotowości do zdobywania nowych umiejętności i poszerzania swoich
kwalifikacji."

Jeżeli masz ludzi, którzy nie chcą się rozwijać, to nie będą. Pomyśl o tym już w
czasie ich zatrudniania.

> > Konflikt wygląda tak:
>
> > "Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."
>
> U was w firmie programiści chcą, żeby bugi były?

Nie chcą. Ale one są. I to jest temat do refleksji - co możemy zrobić, żeby było
lepiej?

> > "Oferujemy możliwość pracy z najnowszymi technologiami."
>
> Być może, ale to przecież nie znaczy, że każdy dobór najnowszej czy
> dobrej technologii ma sens w każdym projekcie.

Niczego takiego nie pisałem.

> Tak więc teoretycznie
> może zaistnieć sytuacja, kiedy programista, któremu pozostawiono w tej
> kwestii wolną rękę,

To kto ma mieć wolną rękę? Sprzątaczka?

Indywidualny programista nie powinien mieć wolnej ręki, ale kilku programistom,
którzy wspólnie coś rozważą, już by można zaufać.

> > Tak. Dobry wybór technologii nie stoi w sprzeczności z tym celem.
>
> Zależy jak rozumie się "dobry".

Tak, żeby było "lepiej". Celem refleksji jest określenie, co to oznacza. Dla różnych
branż, firm i projektów to mogą być różne rzeczy.

> Oj, nie twierdzę przecież, że problem (metaforycznej) Scali jest taki,
> że kandydaci nie będą chętni. Problem jest taki, że:
>
> * Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
> znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie będą
> mniej produktywni.

Kandydaci i tak nie są produktywni przez początkowy okres czasu.

> * Jeśli chcesz zatrudnić kandydatów już znających Scalę,

Nie chcę. Nauczę ich.

> * Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani Scali,
> ani odpowiednich technik, to ryzykujesz, że się ich nie będą w stanie
> nauczyć.

Tak. Wtedy będą robić mniej ciekawe rzeczy w mniej wartościowym projekcie.
Nie widzę problemu.

> Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
> kumatych, ale wszystko jest kwestią skali (no pun intended).

Tak. Ale zależnie od skali inaczej będę też podchodził do rekrutacji. Masowy projekt
zwykle prowadzi do masowej rekrutacji - i masowych efektów.

> > "No chyba powinniście wiedzieć, co zrobić, żeby było dobrze."
>
> Niekiedy jest tak, że między programistą a pointy haired bossem niekiedy
> jest jeden lub więcej szczebli menedżerów technicznych,

Tak. Nie zawsze jest to problem. Wszystko zależy od ludzi. Jak już pisałem: jeżeli
ludzie nie chcą się rozwijać, to nie będą.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com