В этом году исполняется 18 лет моей работе в IT. Волей судьбы (и немного моими собственными усилиями) я умудрился побывать на разных концах пищевой цепочки производства продукта. Это и просто программист и фрилансер, успел поплавать на галерах и в жёстких стартапах. Был (а кое-где остаюсь) и менеджером, и владельцем, и инвестором. И каждый раз, в каждой новой ипостаси я продолжал анализировать процессы в ИТ и в работе в целом, постоянно находя улучшения и делая дебаг тех мест, которые не работают так, как хотелось бы. Поэтому весь нижеследующий текст - исключительно мой опыт работы. Я разделил его на две части: как управляющий проектом видит и желает видеть программистов ("взгляд сверху") и наоборот - как подчинённые хотели бы, чтобы с ними взаимодействовал руководитель и что они от него ждут ("взгляд снизу").

Однако, важно помнить, что это - мой собственный опыт и наблюдения. Я ни к чему вас не призываю и не обязываю, поэтому если хотите высказать своё видение - я всецело вас поддерживаю в этом (даже если в чём-то буду не согласен). Ну и если вы всё ещё читаете этот текст, значит, я писал его не зря ????

Общие замечания

Работа команды - это не кучка отдельных людей, делающих каждый своё дело. С незапамятных времён человек осознал, что в группе он сможет сделать больше. Разделение обязанностей приносит много пользы, однако зачастую люди, находящиеся на более низких ступенях иерархии склонны обесценивать себя и свой вклад в работу команды. Они не видят, как важна их работа и насколько они ценны. Присмотритесь внимательно: ни одна машина не сможет нормально поехать, даже если хотя бы один винтик выйдет из строя. Возможно, она сможет продолжить движение, но водитель либо будет чрезмерно осторожничать, либо существующий недостаток постепенно спровоцирует разрушение всего автомобиля.

Каждый человек в команде важен. Возможно, если организация не производит никакого продукта, в ней есть позиции, которые не особо используются. Но если команда работает на получение результата - в ней нет ни одного "ненужного" человека. Отталкиваясь от этого данного, я сформулировал для себя некоторые правила.

1. Цель

Руководителю нужен продукт. Его задача - добиваться продукта во что бы то ни стало. Хороший руководитель почти никогда не думает о себе, а в основном занят тем, что делает всё возможное, чтобы получить нужный результат в ожидаемый срок. Поэтому самое главное, что ему хочется видеть в подчинённых - такое же желание поддержать его цель. И когда подчинённые относятся к своей работе с меньшим энтузиазмом, чем он сам, ему хочется злится на команду. Хотя на самом деле здесь нет никакого непонимания (потому что подчинённые зачастую не видят той же картины, которая есть у руководителя), всё же лучшее средство для того, чтобы поддержать своего руководителя - всегда оставаться верным общей цели команды. Если подчинённый не знает цели, не знает, какой вклад он вносит в общий результат - ему будет достаточно сложно понять, чего от него хотят и почему на него срываются при малейшем промахе.

А значит самое простое, что вы можете сделать, чтобы помочь своему руководителю - понять, какой вклад вы вносите в общий продукт и изо всех сил делать этот вклад, параллельно совершенствуя свои навыки и добиваясь лучших результатов.

2. Задачи

В IT из-за масштабности работ зачастую возникает ситуация, когда оценка задач постепенно сдвигается и проект, который изначально должен был занять 1 месяц, в итоге может находится в разработке несколько лет. Конечно, руководитель, получая от своих подчинённых всё увеличивающиеся сроки может впасть в уныние и потерять всё желание и энергичность в достижении своих целей. И поверьте на слово, нет ничего хуже, чем руководитель с потухшим взглядом, которого уже не интересует продукт. Уже лучше пусть он гоняет всех <censored> тряпками, чем сидит с пустым лицом, пялясь в пыльный монитор.

С другой стороны - у него нет той информации, которой располагают программисты. Даже если он делает код-ревью с командой и сам отслеживает код, то всё равно, программист, работающий непосредственно с задачей, всегда лучше знает, что там внутри и почему это долго. И весь секрет в том, что именно эту информацию и ждёт руководитель. И если он достаточно умный, он смекнёт, что его подчинённый не пытается скрыть что-то, а наоборот, старается объяснить ему, в чём собственно, проблема. Да, конечно, сроки поджимают и нужно постоянно двигаться вперёд, но если программист на самом деле продолжает оставаться верным цели и пробиваться сквозь трудности, то умный руководитель не будет унижать его за то, что у него что-то не получается, а выслушает и постарается помочь (ведь его цель - получить продукт, а без программиста это просто невозможно).

Поэтому лучшее, что вы можете сделать для руководителя, когда застреваете в задаче, это найти всевозможные решения и обосновать их временные затраты, чтобы у руководителя была возможность просто посмотреть на ваши предложения и выбрать то из них, которое он посчитает лучшим. Помните, что у руководителя зачастую нет такой же возможности, как у вас - тщательно изучить код, понять и разобраться в проблеме и если вы предоставите ему возможность изучить вашу подготовленную оценку ситуации и принять решение - он будет счастлив, что вы оба выполняете свою работу.

3. Проблемы

Оба вышеописанных сценария - это идеальная работа людей, начисто отрезанных от основной жизни. Но, к сожалению, мы живём в мире, где нет ничего идеального (ну кроме, может, Анджелины Джоли). И часто по нашей или не по нашей вине случаются проблемы, которые оказывают некоторый эффект на рабочий процесс. Ребёнок заболел, прорвало трубу или ещё что-то более масштабное - каждая из этих проблем отвлекает от работы и не даёт выполнять её быстро и вовремя.

Однако, у руководителя другой взгляд на вещи. Ему нужен продукт и даже если вы не можете что-то сделать - ему всё равно нужен продукт. Если сотрудник не может прийти даже по самым объективным причинам - ему всё равно нужен продукт. На своём опыте я убедился, что это - самая частая причина расстройств и выгорания. Программист по действительно объективным причинам не может выполнить задачу в срок. А руководитель понимает, что её выполнение жизненно необходимо. Что делать?

Единственное решение, которое я нашёл и которое для меня всегда работало безотказно - это понимание. Подчинённый может не видеть своей важности и вклада, который он вносит, поэтому считает своё отсутствие незначительным. Руководитель же наоборот, понимает важность каждого подчинённого и старается, чтобы каждый из них вносил 100% вклад. Однако, если колесо на машине прохудилось, выйти и просто начать его пинать - это не принесёт успеха и колесо не восстановится. И с другой стороны, если постоянно закрывать глаза на прореху в сидении - когда-нибудь водитель в неё провалится. Здесь важно понимать, что с точки зрения руководителя - каждый подчинённый вносит свой вклад и без него работа всей системы невозможна. Поэтому когда подчинённый только приносит проблемы, не предлагая их решения, к нему относятся как к дырке в сидении - либо зашьют, либо заменят.

Но человек - не ткань. И каждый человек может придумать, как решить даже самую сложную проблему. Поэтому то, что ждёт от вас руководитель в критических ситуациях - не просто плаксивую историю, о том, как вам плохо, а решение, которое вы можете предложить, чтобы ваше отсутствие не повредило всей команде. Принцип тот же, как и в пункте 2: вы лучше знаете, что происходит (потому что вы, в отличие от руководителя, - непосредственный участник). А значит, вам легче придумать решение или решения, чтобы руководитель сумел выбрать наиболее подходящее из них. И все снова будут довольны.

Послесловие

Возможно, мои идеи покажутся кому-то утопичными или слишком размытыми - я не пытался охватить всевозможные ситуации, а просто хотел поделится своим опытом разрешения ситуации с разных точек зрения. Частных случаев может быть очень много и все они будут по-своему уникальны, я лишь хотел наметить некоторые тенденции из того, что сам обнаружил за время своей работы. Если вы считаете так же или по-другому - выскажите это в комментариях.

Комментарии (6)


  1. acordell
    29.06.2022 16:14
    +2

    Иии...? Это все, что есть сказать по управлению проектами после 18 лет?


    1. jfkz Автор
      29.06.2022 18:03

      Конечно же нет. Просто я предпочёл разбить на несколько частей, чтобы не превращать одну запись в огромное полотно информации.


  1. CoffinNail
    29.06.2022 16:20

    Чтобы управлять проектом, нужно понимать архитектуру, причем хорошо понимать. Помимо того нужно, чтобы эта архитектура была адекватной, понималась и принималась сотрудниками и не оспаривалась. У нас же проблемы и первая, и вторая. Билл Гейтс не писал винду сам, он понял её архитектуру и возглавил проект. Хотя это уже былое. Сегодня, наверное, хаос в этом деле.


    1. jfkz Автор
      29.06.2022 18:04
      -2

      Верно. Как правило, хороший руководитель знает и умеет чуть больше чем его подчинённые. Но в этом-то то и кроется подводный камень - в одиночку невозможно построить здание и кому-то приходится отказываться от своих безупречных умений в пользу команды.


  1. lebedec
    30.06.2022 09:50

    Я разделил его на две части: как управляющий проектом видит и желает видеть программистов ("взгляд сверху") и наоборот - как подчинённые хотели бы, чтобы с ними взаимодействовал руководитель и что они от него ждут ("взгляд снизу").

    Представление руководителя как надзирателя, который сидит высоко, глядит далеко — было оправдано пару веков назад. Тогда общество переходило от рабского натурального труда к индустриальному. Продуктивность всё еще можно и нужно было контролировать физически. Прораб-надзиратель должен был буквально палками гонять работников чтобы те делали рутину. 

    Позже, надзирателя узаконили, и он превратился в начальника — должностное лицо, которое вместо палки стал использовать нормативные акты и административные наказания для поддержания приемлемой продуктивности работников на заводах.

    Сейчас руководитель в IT не начальник, а равноправный участник команды, он ни сверху и не снизу. Его задача организовать, руководить и управлять рабочим процессом. Никакого благородства тут нет, творческий процесс свободных людей физически невозможно и не нужно контролировать если вы хотите получить реальную продуктивность. Этот процесс нужно обеспечивать и развивать.

    К сожалению, руководители "старой школы" всё еще пытаются работать в образе начальников. Ваша статья этому прекрасное подтверждение — в ней каждый пункт сквозит авторитарностью и должностной подчиненностью.

    Ваш опыт я не оспариваю и не осуждаю, какой есть. Но мне кажется неправильно поддерживать устаревшие представления о роли руководителя в работе IT, даже если это ваша личная история. Молодой и неокрепший руководитель начитается у вас про то, кто и что ему должен и пойдёт на практике подчинять подчинённых. Поэтому поставил вам минус.


  1. kalvas
    30.06.2022 10:09

    1. Необходимо различать результаты услуг и работ.

    Если говорить в рамках ТК, то:

    1. Наличие компетенций у работника никак не связано с его желанием, используя эти компетенции, выполнять функцию, которая не учтена в договоре и не оплачивается;

    2. Наличие функции в договоре никак не даст компетенции для выполнения этой функции;

    3. Я считаю, что руководитель проекта должен найти функцию которая необходима на текущем этапе для проекта и найти человека с компетенциями для выполнения этой функции и закрепления оплаты в доп. соглашении к договору. Разговоров о "команде" уже не потребуется.