Skip to content

13 причин не быть управленцем и 5 причин быть управленцем

Записки менеджера проектов.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

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

1. Это тупик

Как ни смешно, но одна из причин, по которой я в своё время перешёл от технической к управленческой работе – это как раз тот самый пресловутый «стеклянный потолок», то есть гласный или негласный предел финансово-карьерного роста, который рано или поздно начинает замечать каждый разработчик. Казалось, стоит только абстрагироваться от технологий, избавиться от необходимости каждые два года чуть ли не стопроцентно переходить на что-то совсем новое, как можно будет взять, да и довести одно конкретное умение – вот, скажем, менеджмент – до умопомрачительного совершенства, а там… меня ждут безграничные перспективы! Как же. Практика показывает, что перспективы безграничны именно у разработчиков: можно поменять технологию, попробовать разные роли в проекте, можно работать в штате или быть контрактником, фрилансером, шароварщиком — или стать архитектором, например. Единожды став менеджером, увы, остаёшься им навсегда. Пропустив очередную большую смену технологий, не становясь при этом моложе, обзаведясь семьёй, внезапно понимаешь, что вернуться в техническую/программистскую деятельность будет либо крайне тяжело, либо может и вообще невозможно – особенно учитывая, что это, в связи с потерей актуального на рынке опыта, не сможет произойти без существенного понижения в доходах. Так что чем дольше остаёшься на нетехнической должности, тем дальше уходит условный «поезд».

2. Стеклянный потолок возвращается

Да-да, есть и второй стеклянный потолок, эдакий невидимый ограничитель роста, который с позиции разработчика мне лично был не сильно заметен – наверное, его маскировали «отблески» на первом стеклянном потолке, кто знает. Если вкратце, то в относительно реалистичной ситуации – то есть без радикальной смены индустрии (например, из айтишного менеджера — в вице-президенты какого-нибудь сферического «Газпрома» в вакууме) и страны проживания – у управленцев в области разработки программного обеспечения есть довольно узкий финансовый и карьерный коридорчик, в котором можно «расти и развиваться». Потолок – это всевозможные директора и их замы, которые часто оказываются основателями и/или совладельцами компании, или же их ставленниками. Проще говоря, это те управленческие позиции, до которых не получается «дорасти», а можно только «попасть»; интересно, что это в равной степени относится и к большим транснациональным корпорациям, несмотря на то, что те активно пиарятся как лишённые таких досадных недостатков (см. слова вроде «transparency», «honesty», и т.п. в mission, vision, values – и тому подобных текстах).

3. Что делать?

Несмотря на всю пафосность подзаголовка, тут речь не о философских материях, а о вполне конкретном вопросе – чем следует заниматься управленцу с 9 до 18 часов в рабочий день? Для технических специальностей и должностей это более менее понятно и хорошо определено: люди анализируют требования, пишут программы, тестируют их – много всего разного. Переходя в менеджмент – особенно после довольно длительного существования в «инженерной» Вселенной, где всё относительно чётко определено – неизменно сталкиваешься с ошеломляющим непониманием того, а чем собственно следует заниматься весь день? Если на эту тему и бывает какая-то документация, должностная инструкция или описание, то она как правило крайне размыта, неконкретна и переполнена штампованными фразами и терминами, давно потерявшими всякий смысл из-за чрезмерного употребления, и годными теперь только для «bullshit bingo». Но обычно нет даже её! Более того, попытки выяснить хотя бы высокоуровневые цели своей менеджерской деятельности наталкиваются на тот же самый поток нерасшифровываемых пустых слов: обеспечить, наладить, поддержать, достичь, создать и т.п.

4. Цейтнот

Как только ты попадаешь на самую маленькую менеджерскую позицию, со всех сторон начинают сбегаться люди, которым ничего не нужно – кроме маленькой толики твоего времени. Спустя пару недель ты обнаруживаешь, что более 80% рабочего времени недели расписаны на различные совещания и телефонные звонки/конференции, и в итоге не остаётся совершенно никакого времени на то, чтобы к этим самым совещаниям хоть сколько-нибудь подготовиться. Это выматывает. Как ни крути, всегда оказываешься тем, кто либо не успел, либо не подготовился, либо и то, и другое… и выхода, наверное, нет – по крайней мере я видел людей, живущих в таком режиме годы, а они вряд ли выбрали такой стиль жизни сознательно. Зато они вырабатывают кучу разных приспособленческих механизмов: например, зная, что ни подготовиться к совещанию, ни поработать над каким-нибудь документом по его итогам не получится всё равно, они закладывают это время в само совещание. Так ты и проводишь потом весь день на двух, трёх, четырёхчасовых совещаниях, где присутствуют до дюжины человек, 90% которых там вообще ни к чему. Но только попробуй не поприсутствовать! И в один прекрасный день ты ловишь себя на том, что отмечаешь в аутлуке обеденное время как очередное совещание, иначе просто не получится пообедать, коллеги-управленцы сожрут весь день без остатка. Как вышло на прошлой неделе.

5. Рваный день

Не секрет, что для любого работника умственного труда – например, для программиста – для продуктивной работы необходимо «два f»: focus & flow. То есть – умение и возможность сконцентрироваться на работе, которую надо сделать, и окружающие условия, способствующие поддержанию этой концентрации в течение сколько-нибудь продолжительного промежутка времени. Не секрет, что каждый эпизод, когда что-то (телефонный звонок, разговор, просто громкий звук за окном) вырывает тебя из «потока» сконцентрированной работы, стоит примерно 15 минут времени – столько необходимо, чтобы в этот поток концентрации вернуться обратно. Именно потому разработчики и инженеры так не любят звонки, письма, «стуки» в скайпы/мессенджеры/аськи… а когда ты переходишь в стан управленцев, твой рабочий день внезапно начинает состоять на 80-90% из таких вот разрывов! Совещания, на которых украдкой пытаешься ответить на… дцать свежих писем, телефонные разговоры по пути с одного совещания на другое, а также коллеги, которым всегда чего-то надо срочно, вот прямо сейчас! И пока ты вникаешь в суть проблемы, в инбокс свалилось ещё три письма, на телефоне нарисовалось ещё два неотвеченных звонка, и ты осознаёшь, что только что окончилось то время, что ты себе отвёл на обед – и следующее совещание через четыре минуты. И если всё-таки (несмотря на пункт 3 этого списка) ты осознаёшь, что тебе необходимо сделать какую-то конкретную, осязаемую работу – ну, скажем, написать некий документ, слайды для презентации, или нарисовать диаграмму, то найти для этого сколько-нибудь продолжительный непрерывный период рабочего времени просто нереально!

6. Ненормированный день

Собственно, наличие совещаний, заполняющих весь рабочий день (см. пункт 4), входящей корреспонденции в количествах, достаточных для заполнения того же несчастного дня (см. пункт 7), а так же периодическая необходимость всё же что-то реальное поделать, приводит к тому, что регулярно обнаруживаешь себя работающим вечером из дома, задерживающимся в офисе. Интересно, что такое положение вещей считается вполне нормальным! Скажем, в одной компании, где мне довелось работать, техническим специалистам без вопросов оплачивали переработки в двойном размере, а менеджерам — нет. То есть все знали, что постоянные переработки имеют место и без них никак, за них просто не платили! Так вот и получается, что доход разработчика при определённых условиях может запросто превысить доход его непосредственного начальника. Другой пример: в одной компании было так, что нерабочее время разработчика – это святое, зато вот назначить совещание полдюжине управленцев на 20:00 – это была просто нормальная практика и регулярное явление. Резюме – внезапно, твоё личное нерабочее время перестаёт принадлежать тебе; поскольку вся окружающая менеджерская «тусовка» считает такую ситуацию нормальной, то каким-то безболезненным способом «соскочить» не получиться, только ценой перманентного помещения себя в список «нелояльных», «немотивированных» или просто ленивых негодяев…

7. Инбоксовое переполнение

В те времена, когда я тихо и спокойно занимался разработкой, за день ко мне в инбокс сваливалось с полдюжины электронных писем. Каждое из них немедленно получало моё безраздельное внимание, бывало тщательно прочитано и максимально быстро отвечено – так было правильно, хорошо, и так создавалось ощущение того, что я сделал всё, от меня зависящее, чтобы помочь другим успешно сделать их работу – ответил на вопросы, переслал какие-то материалы, и т.п. Но когда у тебя появляются подчинённые, количество ежедневно входящих писем начинает очень быстро расти. У меня оно месяцами держалось в районе сотни, что приводит к весьма неприятным последствиям: даже задействовав все возможные «примочки» почтового клиента – фильтры, папки, метки, и т.п., даже применяя все мудрые и не очень приёмы организации времени, даже пропадая в аутлуке по вечерам в ущерб семье и отдыху – всё равно нету никакой реальной возможности даже вдумчиво прочесть всю корреспонденцию, не говоря уже об осмысленных ответах всем. В сухом остатке имеем неуклонно растущее количество разнообразных «факапов» (письма не тем, не о том, или не так написанные, забытые приложения – и прочее в таком же духе), растущая за пределы даже теоретической «разгребаемости» куча низкоприоритетных и несрочных писем – выливающаяся в забытые дела, невыполненные обещания, ну и также зудящее ощущение того, что со своим потоком входящей корреспонденции ты не справляешься, а, скорее, он «справляется» с тобой. Пережёвывает и выплёвывает.

8. Чистая, незамутнённая ответственность

В менеджерских кругах очень любят раздавать ответственность за что-либо. Делается это как правило с огромным пафосом, преподносится как невероятный позитив и счастье для того, кто такую ответственность получает, однако есть парочка подводных камней. Во-первых, отказаться от такого счастья практически невозможно – ну то есть без попадания в список нелояльных, неблагодарных негодяев-саботажников. Во-вторых, практически никогда не сообщаются никакие детали о том, за что, собственно надо будет «ответить» (см. также пункт 3). Понятно, почему: ведь весь этот ритуал суть перекидывание головняка от вышестоящих менеджеров нижестоящим, причём таковое перекидывание происходит либо потому, что перекидываемое «попахивает», либо потому, что изначальный счастливый «ответственный» просто не поспел разобраться, что же это вообще такое. Ну руки не дошли, бывает, только ведь признаться в этом никак нельзя, правда? В-третьих, конечно же, ответственность раздаётся только в чистом виде, то есть без какой-либо власти или ресурсов, позволяющих реально повлиять на подотчётную ситуацию. По сути получается завуалированное назначение виновного за неминуемый будущий «факап», а назначенный должен рыдать от гордости, что выбрали именно его. Что в итоге? Привычное уже ощущение того, что успеть надо ещё больше, времени ещё меньше, смысла вообще уже никакого не осталось, а провал неминуем.

9. Никаких «not my job»

Что будет, если разработчика попросить, скажем, вымыть пол в офисе? Покрутит пальцем у виска и объяснит, что не его это работа, и, соответственно, делать её не будет – и это будет воспринято совершенно нормально, поскольку все понимают, в чём заключается работа программиста, и потому очень легко определить, что ею не является. Так вот огромным сюрпризом для меня было то, что в управленческих кругах это не так! Поскольку сам менеджмент (как специальность, профессия) – это есть что-то мутное, нечёткое, сильно зависящее от контекста организации, где всё происходит, каковой контекст как правило остаётся неопределённым (см. пункт 3), то у управленцев практически нету никакой возможности сказать, что это не входит в его обязанности – без (конечно же!) внеочередной записи себя любимого в список ненадёжных предателей, подрывающих сами устои компании. В итоге среднестатистический менеджер периодически обнаруживает себя занимающимся закупкой офисной мебели, поиском работников, написанием маркетинговых материалов и кучей разных других вещей, слабо поддающихся какой-либо внятной категоризации. Просто потому, что… ну не разработчиков же напрягать, верно?

10. Феерический контингент

В начале 1990-х, когда я учился в университете, нас, программистов, было 4 группы. А параллельно с нами вгрызались в гранит науки 19 групп экономистов-управленцев, и наивно было бы предполагать, что они исчезнут с лица планеты, только лишь получив свой диплом. Как ни странно, они все куда-то пошли работать, и какая-то их часть оказалась в итоге в организациях, занимающихся разработкой ПО – разумеется, не на позиции программистов! Эти ребята, они же по определению умнее и хитрее всех на свете – они сразу в менеджмент идут. Как и почему людей с нулевым опытом и образованием «ни о чём», но с заветными буковками «MBA» берут на сколько-нибудь руководящие должности – это так и осталось за гранью моего скромного понимания, но факт остаётся фактом: если среди разработчиков встретить случайного человека довольно сложно (ну как минимум интерфейс от абстрактного класса все же отличают), то среди менеджеров – запросто! Толпы народа со странным опытом работы и без каких-либо полезных навыков хаотично мигрируют от продаж стирального порошка к разработке программного обеспечения, при этом они искренне не видят разницы – не всё ли равно, чем руководить? Соответственно, и разбираться в тонкостях индустрии им некогда и неохота, они делают карьеру – что, собственно, и является их основной и, подчас, единственной истинной «специализацией», так что, внезапно оказавшись в этом милом кругу, за пару-тройку месяцев я лично насмотрелся на такое количество наглого вранья, подстав, истерик, хитрых планов захвата власти, «дружбы против» и разного рода альянсов – за предыдущие лет 10 неменеджерской работы и половины не набрать! То есть если говорить коротко – в менеджерской прослойке царит своя, особая, ни с чем не сравнимая атмосфера; кто-то будет в ней как рыба в воде, а кому-то может очень быстро сделаться очень и очень противно.

11. Пищевые цепочки отчётности

Один мой коллега изобрёл (или позаимствовал откуда-то) забавный термин – «reporting food chain». Это когда большой босс требует предоставить ему какой-нибудь отчёт, и даёт распоряжение нижестоящим менеджерам, которые начинают в свою очередь дёргать своих подчинённых и требовать с них какие-нибудь данные, а те – бегут к своим подчинённым… ну и так далее. Образуется цепочка (если точнее, то дерево) из людей и их действий, конечный результат которых – некий красочный отчёт для кого-то очень важного, и такая цепочка может насквозь пробивать все уровни иерархии организации, до самого низа. Излишне и говорить о том, что на 3-4 уровня ниже большого босса уже никто и не пытается понять, зачем изначально нужна была вся эта суета. Занятно другое: в больших организациях, где существует несколько уровней менеджмента, неизбежно заводятся эдакие паразитические элементы – менеджеры, которые только и делают, что участвуют в одной или нескольких таких цепочках. Формально они могут иметь какую-то весьма звучную должность, но по сути они находятся в спячке, покуда не бывают разбужены началом сбора данных для одного из тех отчётов, что традиционно проходят через них. В этот момент лучше не попадаться им на пути: понимая, что эти отчётики – единственное, что оправдывает их существование в организации, такие ребята сметут всё и всех на пути к заветным цифрам и графикам! Они остановят критические проекты, вырвут из команд важных людей, созовут десятки бессмысленных совещаний, устроят несколько скандалов – но добудут свои драгоценные циферки, а потом — обратно в спячку. Страшнее, чем попасться на пути такого сборщика данных, может быть только перманентная интеграция в отчётную цепочку на самом её последнем этапе – что зачастую и случается с новоиспечёнными, неопытными управленцами; того несчастного, кто попался, ожидают нескончаемые таблицы никому не нужных цифр, которые обязательно нужно раздобыть к такому-то сроку, а не то…

12. Тёплое человеческое общение

По мнению PMI (Project Management Institute), менеджер проектов примерно 90% своего рабочего времени обычно тратит на «коммуникацию», то есть – на общение; в живую, по телефону, по переписке в том или ином виде. Возможно, это прозвучит смешно и наивно, но мне кажется, что это очень и очень много. До начала своей активной карьеры в менеджменте я вёл обычную тихую жизнь среднего интраверта-программиста, которому куда больше «в кайф» пообщаться с компьютером, нежели с коллегами; и поэтому я и представить себе не мог, что могло бы лично для меня означать такое количество общения с разными людьми, без передышки, изо дня в день — это катастрофически выматывает. По-хорошему, ты можешь эффективно общаться примерно с дюжиной людей – удерживая в голове всю историю взаимоотношений с ними, помня о всех данных и полученых обещаниях, зная что кому интересно и что кем движет. Когда людей вокруг становится больше, качество общения предсказуемо падает: пара дюжин – неизбежно начинаешь терять что-то из полезной информации, полсотни – с трудом удержишь в голове хотя бы имена людей, их лица и кто чем занят на данный момент, а если их количество переваливает за сотню, то… не знаю, как у кого, а у меня не выходило даже запомнить имена всех своих подчинённых, и общение с ними превращалось в непрекращающуюся пытку, вереницу из неловкостей и натужных попыток вспомнить, этот ли чувак что-то спрашивал у меня на прошлой неделе, или он вообще здесь только с понедельника работает. Очень скоро я обнаружил, что стал попросту прятаться от коллег! В те редкие минуты, что оказывались свободны от совещаний, я предпочитал находится где угодно, но только не на своём рабочем месте, где меня могли бы найти подчинённые, и (о ужас!) завязать какой-нибудь ещё разговор, о работе или нет. Но есть тут и позитивный момент: я понял, отчего же в бытность мою разработчиком так нереально трудно всегда было «застать» где-то своего начальника, не говоря уже о том, чтобы обсудить с ним что-то животрепещущее!

13. Больше не свой

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

Вот и всё, что с ходу пришло в голову. А чёртова дюжина – наверное, самая подходящая длина для этого списка.

Источник:  сайт habrahabr

 

Пять причин быть управленцем

Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.

Прежде всего хочу заметить, что доктор биологических наук Сергей Савельев в книге «Изменчивость и гениальность» говорит, что мозг каждого человека под что-то создан. Кто-то имеет мозг программиста, кто-то управленца, кто-то обе сферы может осилить. Но обычно талант вынуждает человека делать то, что ему нравится. А к чему он не создан, его радовать не будет, и в это все дело.

Таким образом, к примеру, есть мозг художника, и он не будет математиком. А математик часто не может писать гениальные стихи, и так далее. Бывают гении, типа Леонардо да Винчи, но это исключение.

Весь вопрос в том, чтобы освоить азы профессии, и если она нравится — ей и нужно заниматься. Если нет — пробовать себя в чем-то другом.

Поэтому универсальных советов нет, каждому нужно искать свое дело.

Это было предисловие, а теперь про плюшки работы управленцем.

Итак, что в управлении проектами круто.

1. Масштабируемость

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

upd: прекрасная цитата Winter_mute, описывающая мое ощущение.

Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.

Это значит, если мы хотим создать автоматизацию договорного отдела, или технической поддержки для обслуживания 10,000 клиентов, то нужна работа команды. В одиночку сделать такое трудно. А делать масштабные проекты мне нравится больше, чем сделать один отчет или одну страничку самому, или даже большой модуль для highload, но пилить его полгода.

2. Неустареваемость

Написанная в 80-х годах книжка Дедлайн Демарко, а также книга Брукса 70-х актуальна и спустя 30-40 лет. Все те же проблемы, и те же решения. При этом едва ли книги по тем технологиям (где-то видел, к примеру, про программинг под Вакс или особенности MS DOS) могут быть актуальны спустя такой срок. То есть вы прокачиваете свои скиллы и они не устаревают. Как там писали классики, дома новы, а предрассудки стары.

Конечно, тут можно поспорить — освоив с++ в 90х, можно и спустя 20 лет кушать вкусно и с икрой. Но я за последние 7 лет сменил три языка прикладного программирования, три языка web-программинга и кучу мелких технологий. И у каждой свои нюансы, и мелочи, каждая для своих задач. Каждый раз сначала учить, и от этого устал. Хотя общие принципы часто работают везде (SPOT, KISS и тд), вся суть дела часто решается мелочами. А за ними нужно следить.

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

3. Интересность сложных задач

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

Я занимаюсь автоматизацией внутри компании. У нас проекты — как стартапы, в разных сферах. Автоматизация договоров, продаж, веб-проекты по апартаментам, аггрегатор всех скидок компании, биллинг, автоматизация отдела кадров, сайт по привлечению программистов, и так далее. Такого у меня не было, когда был программистом. Каждый раз новая предметная сфера, новый язык, новые пользователи, новые клиенты, новые сложности.

Плюс улучшение — раздел нужно сделать посещаемым, разработать метрики оценки эффективности, придумать, как эти метрики достичь… Миллион разных решений, каждый раз новое, и это challenge, который вызывает чувство драйва, кайф от работы.

4. Бесконечность развития проекта

Любой проект можно развивать бесконечно. Генерить идеи, делать их, доставлять пользователям, выкатывать новый функционал. Это творчество в чистом виде.

К примеру, сначала автоматизировали создание договоров — не руками, а генерится DOC и PDF. Затем улучшили систему ценообразования, создали систему тарифов, и уже в приложения договора цены со скидками попадают сами. Потом появилась задача сделать более удобным работы с интерфейсом создания договора. Есть задача создания биллинга. Также задача международных договоров, а это другая система цен, платежей и так далее, шаблонов договоров, реквизитов.

5. Риски и ответственность

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

Раньше я просто отвечал за проект, и немного за серверную часть. А теперь и обучение сотрудников, и набор, и ранжирование по профессионализму. И как кому перспективы дать, какие интересные задачи. Как посчитать бонусы, как повысить зарплату. Как учесть возможные болезни и отпуски, чтобы и результат был, и сотрудникам было удобно. И так далее.

То, что описано в исходном посте — бесконечные совещания, или так любые митинги и ретроспективы и тд в Agile методах, есть ИМХО в 90% случаев трата времени разработчиков. Поэтому менеджмент в этом и состоит, по сути дела — в создании для талантливых сотрудников условий для работы. Люди должны четко знать, что делать, и иметь под руками, все что нужно — план работ, перспективы роста, сложные задачи. А расчисткой пути в неизвестное будущее, доведение до конца и миллионом дел занимается проджект, управленец.

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

Хороших программистов мало, а управленцев — еще меньше.

Я управляю проектами два года, и только начинающий project manager, по сути дела. В отделе 15 человек, несколько проектных групп. Менеджер среднего звена — управляю теми, кто управляет программистами. При этом напрямую также веду программистов и ряд проектов. До этого три года был ведущим web-программистом, до этого стартапы, своя студия, фриланс и тд.

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

 

Источник:  сайт habrahabr

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *