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

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

СКАЧАТЬ на проваленных проектах). Потом вы видите, что эти прекрасно описанные требования всё равно меняются заказчиком на более поздних этапах. Вы начинаете это ему запрещать, а заказчик возмущается, так как его бизнес уже изменился за то время, пока вы писали свою аналитику. В результате вы понимаете, что для применения чистого “водопада”, вам нужно жёстко отфильтровывать заказчиков и их проекты. После разработки и применения этих фильтров вы понимаете, что на рынке нет достаточно заказчиков, которые готовы с вами работать по “водопаду”. Но вы не переживаете, так как ваша компания вряд ли дойдёт до этого этапа. Скорее всего, денежные потери будут неприлично высоки уже на этапе попыток совершенствования оценок. Вы либо прогорите, либо измените свои подходы к проектам.

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

      Виды проектного менеджмента

      Роль менеджера гораздо слабее определена, чем роль разработчика. В разных компаниях разные менеджеры занимаются очень разными видами деятельности. Но так же, как backend-разработчик отличается от frontend-разработчика, разные руководители проектов отличаются друг от друга по набору знаний и умений.

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

      Давайте пройдёмся по разным типам менеджмента. Но имейте в виду, что менеджеры, как и разработчики, бывают “fullstack” и на практике от вас наверняка потребуется знание нескольких перечисленных областей:

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

      Дело в том, что многие IT компании возникли как группа разработчиков, возглавляемых каким-нибудь молодым предпринимателем. Предпринимательский склад ума отличается от менеджерского, и разработческий менталитет тоже далёк от менеджерского. В результате компании живут фактически без проектного менеджмента до тех пор, пока не вырастут до размера 30-50 человек. На этом этапе уже появляется желание работать над проектами хотя бы среднего, а не мелкого размера. Владелец компании начинает понимать, что он не может выполнять функции менеджера проектов, так как у него не хватает времени. А ключевые разработчики начинают жаловаться, что 99% их времени занимают задачи, не имеющие отношения к разработке: написание писем, проведение совещаний, отчётность и т.д. Тогда решают “завести” менеджеров проектов.

      Но раз компания выросла без менеджеров, то и обязанности менеджеров определяются из соображения “то, чем разработчику не хочется заниматься”, забывая, что менеджеру для эффективной работы нужно иметь возможность влиять на принятие решений. В результате менеджеру СКАЧАТЬ