Константин Евгеньевич Борисов Как хорошему разработчику не стать плохим менеджером скачать бесплатно fb2 и epub

Одной из лучших прочитанных мною книг в прошлом году стала относительно небольшая книга Константина Борисова по проведению интервью — “Брать или не брать? или Как собеседовать разработчика”. Теперь я её рекомендую всем, кто либо сам проводит интервью, либо готовиться проходить — так ты лучше понимаешь, что из себя представляет потенциальный работодатель, и стоит ли его рассматривать. Но Константин Борисов написал также и другую книгу — «Как хорошему разработчику не стать плохим менеджером». Тема, на самом деле, не такая странная, какой может показаться по названию. В IT широко известно, что сильных специалистов часто повышают, поскольку они хорошо справляются со своими задачами. Сегодня ты прекрасный программист, а завтра тебе дают в обучение парочку стажёров, послезавтра делают ведущим программистом, затем дают в подчинение команду, и вот ты уже менеджер. Да я сам прошёл похожий путь, разве что долго пытался усидеть на двух стульях, поскольку мне нравилось растить специалистов и команды, но я всё ещё хотел оставаться и обычным программистом. В какой-то момент я всё же понял, что так я начинаю хуже выполнять обе задачи, и окончательно принял решение стать менеджером. Но хотя у меня это было осознанное решение, не все приходят в менеджмент таким путём. Многие — как я описал выше. Однако перед всеми встаёт одна и та же задача: ты был неплохим разработчиком, но теперь тебе надо стать неплохим менеджером. А лучше — отличным. Книга «Как хорошему разработчику не стать плохим менеджером» — очередной очень концентрированный сборник великолепных советов, собранных воедино. Я помечал по ходу чтения множество фрагментов, а подписаться готов чуть ли не под каждым абзацем. До многого из описанного я доходил собственным умом, что-то пришлось выучить на собственных же грубых ошибках. Но если бы все менеджеры в IT следовали описанным Константином Борисовым подходам, я бы брал их к себе в команду не задумываясь. Да чего говорить, это главные критерии, по которым я оценивал руководителей в собственные команды. Да, не все были просты в работе, но практически с каждым я находил общий язык и ту сильную сторону, за счёт которой проекты двигались вперёд. На самом деле, далеко не каждый готов стать менеджером, и иногда даже не стоит пытаться делать отличного эксперта руководителем. Так можно и хорошего менеджера не получить, да ещё и великолепного специалиста потерять. Вот хорошая цитата из книги: Но если уж решение принято, то надо действовать корректно и разумно. Как в и прошлой книге, Константин Борисов разбивает повествование по разделам: * Поначалу он рассуждает об управлении вообще, и чем управление в сфере IT отличается от классического. Из интересных отличий тут я бы выделил:
--- Очень широкое применение делегирования полномочий
--- Крайне своевольные исполнители, требующие «очень аккуратного управления». «При том, что сами они ведут себя часто очень агрессивно»
--- Все проекты высокорисковые
* В следующем разделе (кажется, самом крупном в книге) он рассуждает о мотивации и ответственности. Вот уж где я маркером наотмечал почти каждую страницу!
* Третий раздел полностью посвящён вопросам финансовой мотивации, он так и называется — «Бабло». Основные вопросы тут — когда и почему стоит повышать оплату труда, а когда это не имеет смысла. Как премии могут работать против бизнеса, а то и привести к увольнению. И так далее. Ибо деньги — часто слишком переоцененный инструмент удержания сотрудников
* В четвёртом разделе автор рассуждает про подходы контроля проектов, разные модели (Time Material или Fixed Price), а также насколько Scrum как методология относится к менеджменту и помогает ему
* А заканчивает, что интересно, Константин Борисов небольшим разделом про становление молодого менеджера. Тут и набор типовых «подводных камней», и несколько примеров из жизни, и распространённые ошибки начинающего управленца. Больше всего мне понравились разделы про мотивацию и демотивацию. Возможно, потому что именно этими темами я больше всего интересуюсь последние лет пятнадцать. Ибо совершенно неважно, какие инструменты или методологии вы используете в команде, даже процессы — вторичны, если в команде не умеют работать с мотивацией сотрудников. Демотивированные сотрудники при любых процессах будут работать непродуктивно, да ещё и текучка будет бешеной. В то время как сверх-мотивированные сотрудники будут готовы перерабатывать (что вообще тоже плохо, и тут нужно быть аккуратным) и помочь команде просто за идею. По словам автора, тут важно многое, но я выделил следующие цитаты: * При проблемах в командах нельзя остановиться и перезапустить работу «с чистого листа». «…Люди слишком ценный ресурс и найти 20-30 незанятых человек просто невозможно. К тому же в “кризисных” проектах знания распределены по ключевым людям и без них нельзя продолжить работу. Да и заказчик не может терпеть задержку из-за “перезапуска” проектов«.
* «…Начать работу с мотивацией надо с того, чтобы исключить демотивацию. Дело в том, что мотивация – это очень хрупкий объект. Чтобы человек думал о всеобщем благе, стремился к самосовершенствованию и делал больше, чем необходимо, надо, чтобы у него было всё хорошо.
Демотивация же, обычно, наоборот штука грубая, больно “бьющая” по человеку и оставляющая след надолго. Если менеджер один раз вспылит, обзовёт разработчика бесполезным и пригрозит увольнением, то потом может расслабиться и больше не тратить время на мотивацию этого разработчика. Такой менеджер уже всё сломал и чтобы вывести мотивацию хотя бы в ноль, надо обладать специальными навыками и продуманно приложить значительные усилия«.
* Уметь признавать ошибки и брать ответственность за проблемы. Команда понимает, что так не ищут козла отпущения, благодарна и фокусируется на поиске решения вместо того, чтобы становиться в защитную позицию. Но тут важно ещё так взять ответственность на себя, чтобы показать, какие именно моменты «якобы вы» могли сделать лучше. Это даст правильный сигнал команде Отдельно также выделю одну цитату про доверие, поскольку для меня доверие — такой же важный навык руководителя, как и продуктивность. Без доверия нет партнёрских отношений. Так как вопрос доверия является ключевым и часто сложным для усвоения я хотел бы конспективно перечислить ключевые моменты: * Менеджер должен доверять своей команде, так как нет никакого практического смысла ей не доверять;
* Менеджер не должен работать с теми людьми, которых он считает недостойными доверия;
* Менеджер не должен путать доверие и гарантию от ошибок. Каждый может ошибиться;
* Проявление доверия – это не мягкая позиция менеджера, это концентрация на результате, а не на выяснении отношений и собственных комплексах. Короче, я могу ещё много цитировать эту книгу, но она и так довольно короткая. Лучше её просто прочитать. Тем более, что, как и первая, эта книга раздаётся на Литресе бесплатно!