>>> Programisty, zwłaszcza
>>> siedzącego głęboko w projekcie, nie da się "wymienić" z dnia na dzień,
>
>> Chyba, że się już na wstępie zorganizuje pracę w ten sposób, że każdy
>> programista będzie łatwy do wymiany.
>
> Nie wydaje mi się. Nie jest problemem pozbycie się starego. Problemem jest
> wdrażanie nowego. A wdrażanie nowego oznacza:
> - spowolnienie pracy
> - konieczność poświęcenia nowemu nieprzeciętnie dużo energii, by pokazać
> mu
> metodologię stosowaną w firmie
> - konieczność znacznie większej weryfikacji pracy nowego
>
> I przed tym nie uciekniesz. Nawet na inżynierii programowania uczą, że
> każdy
> nowy, dodatkowy programista w już trwającym projekcie spowoduje
> _spowolnienie_
> pracy zespołu, a nie jego przyspieszenie. :)

Toteż napisałem, że występuje w takich przypadkach duża redundancja
obowiązków...

Na inżynierii oprogramowania _nie_ uczą jednak, że czasami cele kierownika
projektu _nie_ pokrywają się z celami firmy jako całości, ale zmierzają do
uformowania sobie (oraz podwładnym i czasem równoległym) miejsca pracy w ten
sposób, aby zamaskować swoje "niedostatki" (w wykształceniu, sposobie
pojmowania, umiejętnościach, predyspozycjach, szybkości myślenia itp.),
nawet kosztem utraty zysków przez firmę.

Podobnie _nie_ uczą tego na finansach. A gdy celowo zacząłem na wykładzie
podpuszczać wykładowcę i dałem mu kilka konkretnych i przetestowanych
przykładów, oraz zadałem mu pytania, na które sam znalazłem odpowiedzi już
dawno, to nawet nie miał pojęcia, jak odpowiedzieć. _Doktor_ czegośtam
finansowego (nie pamiętam dokładnie).