Как хорошему разработчику не стать плохим менеджером - Константин Борисов
- Категория: Книги / Домашняя
- Автор: Константин Борисов
- Издательство: ЛитРес: Самиздат
- Страниц: 32
- Добавлено: 2021-06-24 12:01:05
Как хорошему разработчику не стать плохим менеджером - Константин Борисов краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «Как хорошему разработчику не стать плохим менеджером - Константин Борисов» бесплатно полную версию:В этой книге автор, сам прошедший путь от разработчика до менеджера в сфере IT, рассказывает неочевидные моменты, которые являются критически важными для правильного управления. Почему разработчики увольняются после повышения зарплаты? Как делать FixedPrice проекты? Почему Scrum не упрощает менеджмент? Книга содержит ответ на эти и многие другие вопросы. В книге есть много баек, которые показывают тяжёлую, но интересную жизнь менеджера в разработке. Иллюстратор обложки: Ксения Ерощенко. Иллюстрации в тексте книги авторские.
Как хорошему разработчику не стать плохим менеджером - Константин Борисов читать онлайн бесплатно
За свою жизнь я встречал многих классных руководителей, от которых перенял бесценные знания. Но видел и многих менеджеров, которые допускали грубейшие ошибки, и работать с которыми было мукой для команды и для заказчика. Многие люди (как специалисты, так и менеджеры) не понимают, что вообще делает менеджер в IT, какие навыки он должен иметь, и какие ошибки он ни в коем случае не должен допускать.
Бизнес-литературы по менеджменту много, но этот “менеджмент” в области разработки программного обеспечения часто оказывается бесполезен или даже вреден.
Почему разработчики увольняются, хотя их зарплаты постоянно растут? Как делать Fixed Price проекты? Почему после внедрения Scrum’а управлять проектами не стало проще? Ответы на эти вопросы каждому приходится искать методом проб и дорогостоящих ошибок.
В этой книге я постарался дать самое главное, что нужно менеджеру – понимание происходящего. Я пишу про то, как нужно мотивировать команду, как по-разному могут работать деньги в разных ситуациях, как нужно смотреть на проект, чтобы видеть его проблемы. Я пишу именно про те вещи, которые понять мне самому оказалось труднее всего, и знание которых оказывалось критичным для меня самого.
Я часто слышал, что знания без опыта не работают, и в этой книге я передаю и свой опыт тоже. Около половины книги занимают истории из жизни 1 и кейсы с разборами. Эти истории содержат реальный опыт, и позволяют вам не делать ошибки самому, а наблюдать за ошибками других.
Автор этой книги, Константин Борисов, имеет двадцатилетний опыт работы в индустрии разработки программного обеспечения. Участвовав в десятках проектах в российских, зарубежных и международных компаниях в роли разработчика и менеджера, он накопил опыт, которым и делится в этой книге.
Связаться с автором можно с помощью электронной почты borisovke@gmail.com.
Личный блог автора доступен по адресу https://bukov-ka.livejournal.com/
Адреса в социальных сетях: ВКонтакте, Facebook
Создание обложки: Иллюстратор Ксения Ерощенко artbylulutyan
Менеджер взаимодействует с разными людьми: заказчиками, топ-менеджментом своей компании, своей командой, представителями других компаний. И часто все эти люди очень по-разному смотрят на процесс разработки. Чтобы выполнять свои задачи, менеджер должен обладать широким взглядом и видеть ситуацию не просто под разными углами, а в целом. Поэтому для начала давайте поговорим о менеджменте в IT в общем.
Индустрия разработки программного обеспечения испытывает жуткую нехватку менеджерских кадров. Эта нехватка даже более выражена, чем нехватка разработчиков, тестировщиков, аналитиков и других исполнителей. Отчего так происходит? Дело в особенностях индустрии, которые требуют особенных (редких) менеджерских навыков и знаний. Давайте рассмотрим эти особенности.
1. В IT работают высококлассные исполнители, которые должны принимать решения сами.
Специалисты высокого уровня встречаются много где, но, пожалуй, только IT не имеет никаких протоколов и инструкций, и полагается на экспертные решения. Технологии, методологии и бизнес-задачи слишком часто меняются, чтобы выработать какие-то реально работающие стандартные подходы. Да, многие компании имеют некоторые документы, но они описывают второстепенные вещи, а не основную работу. Описывается, как быстро надо ответить заказчику, но не описывается, что именно надо отвечать. Указывается процент покрытия юнит-тестами, но не описывается, как именно нужно реализовывать определённый функционал.
Наверное, сейчас такое описание и невозможно. В результате менеджер должен уметь работать в ситуации, когда решения разного уровня принимаются без его участия, но ему нужно не терять контроля над проектом. Делегирование менеджерских обязанностей используется необычайно широко. Настолько развитое делегирование характерно разве что для топ-менеджеров компаний, но они обычно гораздо дальше от конечной реализации продукта, чем менеджеры в IT.
2. Исполнители крайне своевольны, не терпят хоть сколько-нибудь жёсткого обращения и требуют очень аккуратного управления.
Следствием предыдущего пункта и ситуации на рынке труда является то, что работники в IT требуют очень нежного менеджмента притом, что сами они ведут себя часто весьма агрессивно.
Например, только в IT менеджер сталкивается с тем, что его прямой и простой приказ не только не исполняется, но и открыто оспаривается. Для менеджера из другой области это шок, а для IT-менеджера – обычная реальность. Бесполезно говорить опытному разработчику, как именно он должен реализовать конкретный код. Его можно убедить, но им нельзя командовать.
А если менеджер сорвётся и наорёт на разработчика, тот молча напишет заявление на увольнение. Опытный специалист найдёт работу в течение нескольких дней.
Взаимодействие менеджера и подчинённого в IT – это разговор на равных, когда договорённости и взаимное уважение используются очень широко, а прямые приказы не используются вовсе (ну, почти).
3. Высокий уровень рисков.
В IT менеджеру недостаточно разбираться с возникающими проблемами, ему необходимо проблемы предугадывать. Обязательно нужно вести реестр рисков и для каждого из рисков продумывать стратегию. Все проекты высокорисковые, так что всё равно срабатывает множество предвиденных и непредвиденных рисков, но если не вести реестр рисков, то проект непреодолимо скатывается в хаос.
4. Иностранные заказчики.
Знание английского языка является самым незначительным требованием при работе с иностранными заказчиками. Гораздо важнее, чтобы менеджер понимал культурные особенности и разницу в принципах ведения бизнеса.
Типичный российский менеджер не ожидает, что его слова в обычном ежедневном письме имеют вес, сравнимый с заключённым контрактом, а буквальное выполнение контракта не достаточно, если заказчик остался недовольным.
5. Техническая сложность проектов.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Comments