Comments 7
Иии...? Это все, что есть сказать по управлению проектами после 18 лет?
Чтобы управлять проектом, нужно понимать архитектуру, причем хорошо понимать. Помимо того нужно, чтобы эта архитектура была адекватной, понималась и принималась сотрудниками и не оспаривалась. У нас же проблемы и первая, и вторая. Билл Гейтс не писал винду сам, он понял её архитектуру и возглавил проект. Хотя это уже былое. Сегодня, наверное, хаос в этом деле.
Я разделил его на две части: как управляющий проектом видит и желает видеть программистов ("взгляд сверху") и наоборот - как подчинённые хотели бы, чтобы с ними взаимодействовал руководитель и что они от него ждут ("взгляд снизу").
Представление руководителя как надзирателя, который сидит высоко, глядит далеко — было оправдано пару веков назад. Тогда общество переходило от рабского натурального труда к индустриальному. Продуктивность всё еще можно и нужно было контролировать физически. Прораб-надзиратель должен был буквально палками гонять работников чтобы те делали рутину.
Позже, надзирателя узаконили, и он превратился в начальника — должностное лицо, которое вместо палки стал использовать нормативные акты и административные наказания для поддержания приемлемой продуктивности работников на заводах.
Сейчас руководитель в IT не начальник, а равноправный участник команды, он ни сверху и не снизу. Его задача организовать, руководить и управлять рабочим процессом. Никакого благородства тут нет, творческий процесс свободных людей физически невозможно и не нужно контролировать если вы хотите получить реальную продуктивность. Этот процесс нужно обеспечивать и развивать.
К сожалению, руководители "старой школы" всё еще пытаются работать в образе начальников. Ваша статья этому прекрасное подтверждение — в ней каждый пункт сквозит авторитарностью и должностной подчиненностью.
Ваш опыт я не оспариваю и не осуждаю, какой есть. Но мне кажется неправильно поддерживать устаревшие представления о роли руководителя в работе IT, даже если это ваша личная история. Молодой и неокрепший руководитель начитается у вас про то, кто и что ему должен и пойдёт на практике подчинять подчинённых. Поэтому поставил вам минус.
Вообще полностью с вами согласен и по факту я описываю ту же самую точку зрения. Я ни в коем случае не вкладываю негативный оттенок в понятие руководителя, просто имею ввиду, что в команде всегда есть человек, который и выступает от лица команды (руководитель). Обороты речи "взгляд сверху" и "взгляд снизу" взяты в кавычки, чтобы подчеркнуть их формальность. Это не означает, что руководитель - некий деспот из поднебесной. Это лишь означает, что с точки зрения иерархии, если смотреть на команду извне, мы видим руководителя именно как человека, представляющего команду. Остальные более инкапсулированы.
Необходимо различать результаты услуг и работ.
Если говорить в рамках ТК, то:
Наличие компетенций у работника никак не связано с его желанием, используя эти компетенции, выполнять функцию, которая не учтена в договоре и не оплачивается;
Наличие функции в договоре никак не даст компетенции для выполнения этой функции;
Я считаю, что руководитель проекта должен найти функцию которая необходима на текущем этапе для проекта и найти человека с компетенциями для выполнения этой функции и закрепления оплаты в доп. соглашении к договору. Разговоров о "команде" уже не потребуется.
Управление проектами. Взгляд сверху