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

Про автора

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

Связаться с автором можно с помощью электронной почты borisovke@gmail.com.

Личный блог автора доступен по адресу https://bukov-ka.livejournal.com/ (https://bukov-ka.livejournal.com/)

Адреса в социальных сетях: ВКонтакте (https://vk.

com/bukov_ka), Facebook (https://www.facebook.com/konstantin.borisov.121)

Создание обложки: Иллюстратор Ксения Ерощенко artbylulutyan (https://www.instagram.com/artbylulutyan/)

Раздел 1. Общие вопросы менеджмента

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

Поэтому для начала давайте поговорим о менеджменте в IT в общем.

Особенности менеджмента в IT

Индустрия разработки программного обеспечения испытывает жуткую нехватку менеджерских кадров. Эта нехватка даже более выражена, чем нехватка разработчиков, тестировщиков, аналитиков и других исполнителей. Отчего так происходит? Дело в особенностях индустрии, которые требуют особенных (редких) менеджерских навыков и знаний.

Давайте рассмотрим эти особенности.

1. В IT работают высококлассные исполнители, которые должны принимать решения сами.

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

Описывается, как быстро надо ответить заказчику, но не описывается, что именно надо отвечать. Указывается процент покрытия юнит-тестами, но не описывается, как именно нужно реализовывать определённый функционал.

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