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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

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

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

Кейс "Замена команды"

В зарубежной международной компании работали менеджер проекта (американец) и тимлид (русский разработчик). Тимлид чем дальше, тем больше был недоволен своей командой. Эти люди были собраны случайным образом и они так и не стали командой. Их технический уровень был низок, а они не рвались желанием его повышать. Они раз за разом делали одни и те же ошибки в коде, и тимлид раз за разом делал им одни и те же комментарии после ревью. Код писался, но медленно и с большим трудом.

Когда менеджер и тимлид обсуждали очередной релиз и ожидаемые сроки, тимлид не выдержал и сказал: “Мы не сделаем этот релиз в срок этой командой. Каждый из них работает в два раза медленнее, чем это следовало бы. Даже хорошие junior-ы сразу после университета были бы лучше, чем это сборище лентяев!”

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

В результате тяжёлых размышлений тимлид так и не смог решиться уволить всю команду, которая ему так не нравилась. Релиз команда завалила.

Анализ

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

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

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

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

В-третьих, за нерешительность тимлида заплатила компания, так как релиз команда таки завалила. Эта цена дорогая и она уплачена из чужого кармана только для того, чтобы тимлид мог считать себя “добреньким”. Уклонение от какого-то решения – это тоже решение, которое имеет свои последствия.

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

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

Интервал:

Закладка:

Сделать

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

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


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

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

x