Page 32 - 4566

бажано захистити команду від зайвого зовнішнього впливу,
зокрема від впливу користувацьких потреб (див. принцип 1).
Керівник команди повинен видавати завдання
виходячи з системи реалізаційних понять, яка принципово
відрізняється від системи понять підсистеми в цілому,
відповідно до рівня використання. Цей рівень відстежує
проектувальник.
Розмежування ролей проектувальника і керівника
сприяє рівновазі точок зору користувача і розробника
підсистеми (див. принцип 2).
Якщо використовується перехресне поєднання ролей
керівника команди і проектувальника підсистеми, то виникає
ще одне протиріччя їх рольових інтересів: у керівника
можуть бути переваги на користь "свого" компонента і, як
наслідок, можливий дисбаланс проекту в цілому на користь
виділених його складових, який доведеться компенсувати
додатковими зусиллями менеджера.
З тих самих причин не припустиме поєднання ролей
менеджера і розробника. Тут заборона жорсткіша, оскільки
контрольні функції менеджера несумісні з виконавчими
завданнями розробника. Навіть у тих випадках, коли у
менеджера залишається вільний час після виконання своїх
прямих обов'язків, йому не слід "допомагати" розробникам.
Краще зайняти себе іншою справою, зокрема виступити в
ролі розробника іншого проекту.
У той самий час поєднання ролей різних розробників
– звичайна справа для великих проектів. Воно є частиною
розподілу робіт між виконавцями. Вирішують це завдання
спільно керівник команди і менеджер, коли основні
архітектурні положення затверджені. Способи рішення
залежать від того, як формується команда. Якщо розробка
доручається готовій команді, то зростає роль керівника, а
менеджер лише затверджує його пропозицію. Коли команда
створюється для проекту, росте питома вага менеджерських

32