Books-Lib.com » Читать книги » Домашняя » Как хорошему разработчику не стать плохим менеджером - Константин Борисов

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

Как хорошему разработчику не стать плохим менеджером - Константин Борисов - Читать книги онлайн | Слушать аудиокниги онлайн | Электронная библиотека books-lib.com

Открой для себя врата в удивительный мир Читать книги / Домашняя книг на сайте books-lib.com! Здесь, в самой лучшей библиотеке мира, ты найдешь сокровища слова и истории, которые творят чудеса. Возьми свой любимый гаджет (Смартфоны, Планшеты, Ноутбуки, Компьютеры, Электронные книги (e-book readers), Другие поддерживаемые устройства) и погрузись в магию чтения книги 'Как хорошему разработчику не стать плохим менеджером - Константин Борисов' автора Константин Борисов прямо сейчас – дарим тебе возможность читать онлайн бесплатно и неограниченно!

220 0 12:01, 24-06-2021
Автор:Константин Борисов Жанр:Читать книги / Домашняя Год публикации:2020 Поделиться: Возрастные ограничения:(18+) Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних просмотр данного контента СТРОГО ЗАПРЕЩЕН! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту для удаления материала.
0 0

Аннотация к книге "Как хорошему разработчику не стать плохим менеджером - Константин Борисов", которую можно читать онлайн бесплатно без регистрации

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

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

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

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

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

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


Как хорошему разработчику не стать плохим менеджером
Почему проекты заканчиваются неудачей

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

1. Разработка ПО сейчас очень дёшева и заказчики хотят её такой оставить. Хотя разработчики имеют высокие зарплаты, а компании, разрабатывающие ПО, получают хорошую прибыль, но с каждым годом разработка ПО дешевеет. Один единственный самолёт Boeing 777 стоит больше $300 миллионов. Бюджет даже крупных проектов по разработке ПО составляет малую часть этой суммы. А самолётов серии Boeing 777 на данный момент выпущено более 1600. Стоимость ПО ничтожна по сравнению с общей ценой изделий.

В цифровых продуктах аналогично. Instagram в 2012м году был приобретён Facebook, и примерная стоимость сделки составила $1 млрд. Стоимость собственно разработки несравнима с этой суммой. Стоимость компьютерной графики фильма “Миссия невыполнима – 2” не идет ни в какое сравнение с гонорарами Тому Крузу. Хотя его можно было бы просто нарисовать.

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

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

Но деньги сами по себе не так важны, как следующий пункт.

2. У заказчика нет времени на уточнение требований. Изменение требований в процессе разработки ПО сейчас настолько распространено, что The Standish Group изменила критерии провала проекта для своего Chaos Report. Если клиент доволен, то считается, что проект успешен, несмотря на то, что сделали не то, что планировали.

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

Итак, заказчик не даёт денег на предварительный анализ системы, да ещё и меняет требования в процессе. Шансов, что более-менее сложный праехт2 проект пройдёт по плану абсолютно никаких.

Хорошая новость заключается в том, что заказчики это понимают (обычно). Большинство заказчиков имеет возможность увеличить бюджет или убрать часть функционала, чтобы проект таки принёс им какой-то осмысленный результат.

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

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


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

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

Чтобы выяснить, почему так, давайте вспомним, что такое водопад как методология разработки, и как связаны разные этапы разработки:


1 2 3 ... 32
Перейти на страницу:
Отзывы - 0

Прочитали книгу? Предлагаем вам поделится своим впечатлением! Ваш отзыв будет полезен читателям, которые еще только собираются познакомиться с произведением.


Новые отзывы

  1. Гость Елена Гость Елена12 июнь 19:12 Потрясающий роман , очень интересно. Обожаю Анну Джейн спасибо 💗 Поклонник - Анна Джейн
  2. Гость Гость24 май 20:12 Супер! Читайте, не пожалеете Правила нежных предательств - Инга Максимовская
  3. Гость Наталья Гость Наталья21 май 03:36 Талантливо и интересно написано. И сюжет не банальный, и слог отличный. А самое главное -любовная линия без слащавости и тошнотного романтизма. Вторая попытка леди Тейл 2 - Мстислава Черная
  4. Гость Владимир Гость Владимир23 март 20:08 Динамичный и захватывающий военный роман, который мастерски сочетает драматизм событий и напряжённые боевые сцены, погружая в атмосферу героизма и мужества. Боевой сплав - Сергей Иванович Зверев
Все комметарии: