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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

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

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

Так и с проектами. У менеджера есть выбор: либо продемонстрировать клиентоориентированность и гибкость и сделать, что просит заказчик, либо напомнить про бюджет и пойти на потенциальный конфликт. Менеджеры не враги себе, они выбирают “простой” вариант. Особенно при подходе Time&Material, когда все дополнительные хотелки всё равно будут выполнены за счёт заказчика.

Но когда в парикмахерской клиенту выставляют счёт и он видит, что его шоколадка стоит так же, как и стрижка, конфликт гораздо острее, чем объявленная заранее цена. Бесплатного ничего нет. За всё кто-то в конце-концов заплатит.

То есть менеджеру, чтобы эффективно контролировать scope creep, нужно как чётко понимать, какие работы были запланированы изначально и что добавилось позже, так и иметь хорошие навыки в переговорах/продажах. Однако такая ситуация имеет и плюсы. Если вы имеете мощные переговорные навыки, то некоторые упущения в контроле объёма работ, могут не быть такими критичными. И наоборот, если вы очень хорошо умеете планировать и отслеживать, что делает ваша команда, это даст вам отличные аргументы в переговорах с заказчиком.

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

История про предугадывание желаний

Однажды я пришёл в новую парикмахерскую. Мне нравится пробовать разные образы, и мне интересно давать свободу мастеру, поэтому стрижку я заказал, как обычно: "На ваше усмотрение, но чем безумнее, тем лучше". Мастер позадавал наводящие вопросы и пообещал сделать стрижку, "как в Омске точно не стригут" и "за эту стрижку из соседнего барбершопа мастера выгнали". Результат мне понравился, но я был немного удивлён. Мастер не использовал длину моих волос, а сделал очень короткую стрижку. Она была довольно сложная в исполнении, но не “безумная”, как я формулировал, а скорее “практичная”. Спортсмены и военные что-то подобное носят.

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

И здесь мы видим очень важный момент, с которым менеджеры сталкиваются постоянно. Обратите внимание, что мастер не спросил меня, готов ли я укладывать волосы. Вместо этого он спросил меня, чем я занимаюсь, и сделал выводы. Хотя казалось бы спросить напрямую гораздо проще и безопасней. Можно просто спросить, получить ответ и не рисковать ошибиться. Зачем играть в “угадайку”?

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

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

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

Секреты успешных Fixed Price проектов Абсолютное большинство аутсорсных - фото 40

Секреты успешных Fixed Price проектов

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

Интервал:

Закладка:

Сделать

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

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


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

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

x