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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать
Раздел 4 Контроль выполнения проекта Контроль выполнения проекта это прямая - фото 36

Раздел 4. Контроль выполнения проекта

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

Куда ползёт scope

Умение работать с разрастанием объёмов работ (scope creeping) является вторым важнейшим навыком (после работы с рисками), необходимым для менеджера проектов. Большинство срывов сроков и выходов за бюджет связано именно с проблемой роста объёма работ, который прошёл незамеченным.

Особенно эта проблема важна для Fixed Price проектов, когда бюджет жёстко определён заранее и любой выход за этот бюджет идёт за счёт исполнителя. Компании не могут работать с Fixed Price проектами, потому что не умеют работать со scope creeping.

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

Рассмотрим ситуацию. Заказчик ещё до старта проекта указывал, что ему нужен некий отчёт. Ещё до появления хоть сколь-нибудь детальных требований этот отчёт оценили и включили в бюджет. Потом заказчик предоставил требования. Требования не расходились с изначальными предположениями, отчёт реализовали в соответствии с ними.

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

Заказчик идёт навстречу команде и упрощает требования. Теперь не нужно выводить отчёт на экран, а можно просто обработать данные в фоне и выслать пользователю готовый отчёт в формате PDF. Да, отчёт будет выполняться по-прежнему долго, но приложение не будет выглядеть “зависшим” и им можно объяснить, что происходит. Генерация PDF уже реализована, добавить рассылку по почте можно быстро. Команда быстренько допиливает систему, баг закрыт, все счастливы. Ведь так?

Нет, совсем не так. Мы получили дополнительные требования и реализовали их. Объём работ вырос, бюджет не вырос. Мы проморгали scope creeping. И самое плохое тут, что заказчик не осознаёт, что добавились требования. Ведь он же наоборот, упростил задачу для команды. Как могла его помощь увеличить объём работ?

Ключевое здесь не то, что scope добавился, а то, когда он добавился. Многие, не задумываясь, скажут, что объём добавился, когда заказчик явно предложил заменить отчёт на рассылку PDF. Это не так. Заказчик в тот момент уменьшил объём работ, предложив упрощённое решение. А добавился scope тогда, когда команда начала работу над багом по производительности.

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

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

Гораздо правильней прозрачно и заранее объяснить заказчику, что происходит, чем через несколько месяцев сообщить ему, что деньги закончились и нужно ещё. Когда команда начинает несогласованную оптимизацию производительности, она тратит деньги заказчика (или своей компании, тут бывает по-разному). Возможно, эти траты не нужны. Возможно, отсутствие требований по производительности не является упущением, а является следствием продуманной политики заказчика.

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

Интервал:

Закладка:

Сделать

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

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


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

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

x