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

Введение

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

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

Это вовсе не означает, что я считаю членов команды безответственными или неспособными на рациональные поступки. Это означает, что с точки зрения инкапсуляции элементам с более высокой абстракцией нет необходимости осуществлять прямой контроль элементов на нижних уровнях. Вряд ли Илон Маск сам лично выдаёт команды на работу для фрезеровщиков на своих заводах. Наверняка, он многих знает лично и является другом для каждого своего персонала, но у него нет необходимости лично напрямую контролировать работу каждого. И хоть и неправильно сравнивать людей и абстрактные конструкции, думаю, что это даст вам некоторое представление о моей точке зрения на работу команды.

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

1. Цель

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

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

2. Решения

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

В иерархии компании руководитель является лицом команды. А значит он является тем, кого видят и обычно ассоциируют с командой. И именно благодаря этой видимости руководитель становится тем, кто реально существует для всех остальных. Это не означает, что остальные члены команды - никто в общей структуре, вовсе нет. Но из-за особенностей работы и общения, руководитель чаще оказывается на виду и его быстрее распознают.

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

3. Проблемы

Программисты - достаточно умные и самостоятельные ребята. Но и у них случаются проблемы, с которыми не может помочь ни StackOverflow, ни Google. И в таких случаях, программист надеется получить помощь от своего руководителя. И в отличие от остальных пунктов, тут всё очень просто - руководитель, который откровенно не желает помогать подчинённым, становится персоной нон-грата.

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

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

Послесловие

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

Управление проектами. Взгляд снизу