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

Здесь есть возможность читать онлайн «Константин Борисов - Как хорошему разработчику не стать плохим менеджером» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Год выпуска: 2020, Издательство: Array SelfPub.ru, Жанр: Психология, Программирование, management, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Как хорошему разработчику не стать плохим менеджером: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Как хорошему разработчику не стать плохим менеджером»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

В этой книге автор, сам прошедший путь от разработчика до менеджера в сфере IT, рассказывает неочевидные моменты, которые являются критически важными для правильного управления. Почему разработчики увольняются после повышения зарплаты? Как делать FixedPrice проекты? Почему Scrum не упрощает менеджмент? Книга содержит ответ на эти и многие другие вопросы. В книге есть много баек, которые показывают тяжёлую, но интересную жизнь менеджера в разработке. Иллюстратор обложки: Ксения Ерощенко. Иллюстрации в тексте книги авторские.

Как хорошему разработчику не стать плохим менеджером — читать онлайн бесплатно полную книгу (весь текст) целиком

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

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Мне на такое возражают, что иногда разработчики явно говорят неправду. Например: “Мой разработчик вот говорит, что задача невыполнима, а её сделать можно. Явно врёт, зараза! Начинаешь его пытать и действительно оказывается, что решение есть. Значит, врал!”

В подобных ситуациях я начинаю с предположения, что разработчик честно попытался найти решение задачи, но не нашёл. И переформулирую её: “Слушай, если ты говоришь, что технически разумного решения задачи нет, то так и есть. Ты спец. Но если мы заказчику не предоставим хоть какой-нибудь вариант, то он придумает свой и нам придётся с ним спорить или, ещё хуже, его реализовывать. Давай лучше придумаем какой-нибудь свой, хоть и не очень разумный вариант. Пусть заказчик над ним подумает. Может, можно от каких-то требований отказаться? Или половину системы переписать? Или удесятерить количество серверов? Или купить готовое решение?”

Опять же, обратите внимание, в такой постановке вопроса нет никакой “мягкости”. Я тут прямо угрожаю разработчику: “Заказчик придумает своё решение и нам придётся его реализовывать”. Это страшная угроза и она реальна. Но говорить разработчику, что я ему не верю, очень неправильно. Я ему верю, решения задачи нет. Просто нам теперь нужно решить другую задачу: предложить что-то другое заказчику.

На самом деле, нет ни одного вменяемого примера, когда имеет смысл сказать человеку, что вы ему не верите. Человек врёт вам, вы ему об этом скажите, и он резко перестанет так делать? Это сумасшедшее предположение, так общение с людьми не работает. А если вы не можете сказать никому, что вы ему не доверяете, то зачем не доверять?

Подумайте над последним вопросом. Он таит за собой больше возможностей, чем кажется. Мне некоторые менеджеры говорили: “Я никак не могу поверить некоторым своим людям. Они явно работают недобросовестно”.

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

И ещё иногда менеджеры смешивают доверие и технический уровень: “Задача сложная, Вася никогда не работал над такими, он может не справиться”. Это не имеет никакого отношения к доверию. Доверие – это про то, что Вася будет стараться изо всех сил (может и невеликих), а не про гарантию, что Вася справится с задачей. Работа с рисками, по-прежнему, на менеджере. Даже, если вы доверяете Васе, вы можете и должны помогать ему, контролировать его, организовывать ревью его работы более опытными разработчиками и т.д. Потому что никто (и вы в том числе) не застрахован от ошибок. И наличие ошибок не должно влиять на доверие.

Разделять вопросы доверия и квалификации критически важно. Смешивание их подобно смешиванию бизнес-логики, UI и слоя данных. Это приносит хаос и делает проект неуправляемым.

Так как вопрос доверия является ключевым и часто сложным для усвоения я хотел бы конспективно перечислить ключевые моменты:

Менеджер должен доверять своей команде, так как нет никакого практического смысла ей не доверять;

Менеджер не должен работать с теми людьми, которых он считает недостойными доверия;

Менеджер не должен путать доверие и гарантию от ошибок. Каждый может ошибиться;

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

История про ненужные сложности Както устроился я менеджером в одну небольшую - фото 13

История про ненужные сложности

Как-то устроился я менеджером в одну небольшую разработческую контору. И мне почти сразу после выхода на работу сказали, что одного моего разработчика, Сергея, надо срочно уволить. Мол, от него проблемы уже много лет, и попробовали уже всё, и ничего не помогает, и надо увольнять. И владелец компании мне это говорил, и руководитель HR. Очень уверенно говорили.

Но когда я спросил, почему Сергея ещё не уволили, ответа я не получил. Так как я с Сергеем ещё не работал, то и увольнять мне его было не за чем. О чём я и сообщил. Я знал, что своих людей надо защищать, так что Сергей получил ещё один шанс.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Как хорошему разработчику не стать плохим менеджером»

Представляем Вашему вниманию похожие книги на «Как хорошему разработчику не стать плохим менеджером» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Как хорошему разработчику не стать плохим менеджером»

Обсуждение, отзывы о книге «Как хорошему разработчику не стать плохим менеджером» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x