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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

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

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

История про самую распространенную причину провала проекта Както проходя - фото 37

История про самую распространенную причину провала проекта

Как-то, проходя мимо переговорки, я заметил большую толпу заходящего туда народа и коллегу-менеджера, Макса. Я остановился и спросил, что происходит.

– Да вот ретроспективу своего проекта проводить буду. Должно быть интересно. Мы проект завалили, в полтора раза дольше делали, чем это планировалось. Заказчик крайне недоволен да и наше руководство тоже.

– А почему завалили-то?

– Ты знаешь, Константин, я сам понять не могу. Вроде, всё по плану шло, ничего беды не предвещало. А в самом конце вдруг выяснилось, что не успеваем закончить вовремя и так вот и потянулось дальше: то одно, то другое, и все сроки откладываются и откладываются.

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

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

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

Так что же является новым скоупом?

Если вы внимательно читали предыдущую главу, то у вас в голове наверняка царит неразбериха: “Что же является расширением скоупа проекта? Какие просьбы заказчика нужно выполнять без вопросов, а за какие требовать дополнительный бюджет?”

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

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

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

Именно поэтому мы в бюджет проекта закладываем очень большой буфер на возможные изменения. Мы знаем, что заказчик захочет сделать эти изменения, и отказ будет воспринят как дешёвый сервис. А IT компании работают (или пытаются работать) в области дорогого, а следовательно, качественного сервиса.

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

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

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

Интервал:

Закладка:

Сделать

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

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


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

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

x