×

Хороший-плохой менеджер: небожители, тираны, нетехнари и другие типажи

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

Иллюстрации: Дарина Скульская

Унижай и властвуй

Начну, пожалуй, с «давным-давно». Так вот, давным-давно довелось мне устроиться на работу в свою первую IT-компанию и была у меня менеджер-женщина, 34+, пергидрольная блондинка, чуть полноватая и ругающаяся матом, как отпетый сапожник. Было у нее в подчинении 15 мужиков разных возрастов и 2 девочки-студентки. Такого порядка, четкости соблюдения сроков и практически 8-часовой продуктивной работы я не видела больше никогда на проекте.

Вы думаете, какая-то чудесная методология разработки или очень точное планирование помогали добиться такого эффекта? (13 лет назад там никто и не слышал таких слов.) Страх! Унижай и властвуй — вот кредо этой мадам, которая, к слову сказать, оказалась довольно неплохим психологом и знала больные места каждого. Даже взрослые дядьки боялись ее гнева, не говоря уж о тощих юнцах, для которых эта работа вообще была первой. Так вот, через несколько лет я случайно узнала, как директора компании нашли столь ценный кадр. В ресторане! Да-да, она работала официанткой в ресторане, куда они зашли пообедать и обсуждали, что не могут найти менеджера для проекта.

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

Небожители

Встречались мне и менеджеры-небожители, которым корона настолько давила голову, что они закрывались у себя в кабинете, общались с сотрудниками только через мессенджеры и быстро-быстро пробегали мимо по дороге из своего кабинета, чтобы «челядь» не успела пристать с вопросиками. Спускались они со своего Олимпа только тогда, когда проект начинал идти не по графику, который они презентовали начальству. Спускались только для того, чтобы найти виноватого и публично казнить. Больше, чем их отдельный кабинет, всех бесил их деловой вид, с которым они каждый день уходили по полдня на «совещание с заказчиком», хотя все всё понимали...

Технари

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

Нетехнари

Была в моем опыте и полная противоположность этим ребятам. Это был менеджер, который пришел в IT из крупнейшего мобильного оператора. В IT-технологиях не понимал абсолютно ничего, но более блестящего руководителя мне не доводилось встречать. Он умело общался с заказчиками; сглаживал углы, если команда не успевала или портачила; решал все вопросы по персоналу (от сломанного стула до конфликта между людьми) либо умело делегировал их решение; хоть и имел отдельный кабинет, пользовался им только для переговоров; заботился о каждом сотруднике и о команде в целом.

Но знаете, в чем была главная изюминка его успешного руководства? Доверие! Мне все-таки кажется, что это была вынужденная мера, а не лично его стратегия; тем не менее она круто работала. В силу того, что технически он был не подкован, ему приходилось полагаться на свою команду, на то, что они знают, что делают, и сделают, как надо. Это, в свою очередь, породило ответную реакцию у команды: есть наш менеджер, который о нас заботится, делает нам хорошо, как же мы можем его подвести? И никто не подводил! Нужно задержаться — окей, нужно найти решение поставленной задачи — найдем. И все это делалось не из-под палки, а на энтузиазме и в благодарность. Не знаю, хорошо это или плохо; уверена, что будет не одно мнение на этот счет, но это показательный пример.

Тираны

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

Главное кредо таких горе-менеджеров — «преступление и наказание». Их основная задача — найти виноватого и наказать, а еще лучше — публично. Для примера: была у меня менеджер, которая приходила на работу на час раньше (сидела она напротив входной двери), и каждый раз, когда открывалась дверь, приподнималась из-за монитора, чтобы посмотреть, кто пришел и в какое время. Если ты опаздывал хоть на минуту, она записывала это и на дейли-стендапе (ну так, чтобы при всех) спрашивала: «А почему ты опоздал?» Ответ был неважен, главное было потом сказать: «А вот я прихожу на час раньше на работу, чтобы успеть подготовить свое рабочее место, выпить кофе и все такое и начать работу ровно в 9:00, и ты должен».

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

Еще одна представительница такого менеджмента все время пыталась убедить подчиненных, что они должны работать эффективно все 8 часов, а если хотят повышения, то и больше (ну и, само собой, бесплатно), «вы же заинтересованы в проекте». У вас не должно быть никаких интересов и мыслей, кроме как о благе проекта и компании. Дети, семья, хобби? Всему этому нет места в жизни по-настоящему хорошего и ценного сотрудника. (На самом деле в ее жизни, но... об этом как-то умалчивалось.) А главный аргумент был тот, что, если не будет проекта, у вас же не будет работы и вы умрете с голоду. Нет! Люди просто перейдут в другую компанию, что, собственно, сделали практически все ключевые разработчики и тестировщики на этом проекте после такого «менеджмента», где, чтобы корова меньше ела и давала больше молока, ее нужно меньше кормить и больше доить.

Кто такой хороший менеджер

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

Человечность. Хороший менеджер (украду мысль из «Черной книги менеджеров») должен не только сидеть в своем кабинете и строить графики, но и всегда знать, чем живет каждый член его команды. И если у условного Васи дома рожает любимая кошечка, хороший менеджер должен чувствовать глубину его переживаний по этому поводу. Возможно, лучше Васю отпустить на несколько часов домой, чем он будет сидеть и бесполезно пялиться в монитор, думая, как там его кошка.

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

Неважно, из какой сферы он пришел. Тут долго распыляться не буду: человек либо умеет управлять людьми, либо нет, и сфера деятельности не играет никакой роли (если мы умеем читать, то мы одинаково хорошо прочтем книгу, вывеску или товарный чек).

Он не технарь. Тут я готова услышать holy war :) Просто оставлю это как мое субъективное мнение: из нетехнарей получаются лучшие менеджеры, чем из технарей. На вопрос программистов: «А к кому же мне идти, если у меня вопрос технического характера?» — отвечу так: у вас есть тимлид или старший коллега. Если вы сеньор, то это уже предполагает, что с большинством проблем и вопросов технического характера вы можете справиться сами.

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

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

Владеет best practices управления проектами. В частности, самое главное, чтобы он умел выполнять оценку проекта и правильно рассчитывать риски. Все остальное — как это лучше оформить, в какой программе и какие графики нарисовать — неважно.

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

Всегда в курсе. Хороший менеджер всегда держит руку на пульсе и всегда знает, «куда мы идем». Повторю свою мысль из предыдущего пункта: если это не так, то у вас проблема с процессами.

Вовремя реагирует. Руководитель должен моментально принять меры, когда что-то идет не так, а не ждать пока его «подданные» сами разрулят ситуацию. Если вам не сообщают вовремя о возникшей загвоздке, ваш процесс построен неверно.

Умеет строить процессы. Думаю, уже понятно, насколько это важно :)

В завершение

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

Всем остальным хочу дать совет, как избежать «плохих менеджеров». Если это возможно, старайтесь пообщаться с менеджером проекта еще на этапе собеседования, задайте ему пару вопросов о команде и проекте. Поверьте, в ходе его рассказа вам станет понятно, кто перед вами — «хороший» или «плохой». У меня были случаи, когда на собеседовании происходила просто какая-то магия и я «влюблялась» в моего будущего менеджера и принимала даже менее «вкусный» оффер, только потому что хотелось работать с таким человеком.

Желаю вам побольше хороших менеджеров в вашей карьере! Но не забывайте, что без плохих мы не сможем по-настоящему оценить хороших.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Схожі статті




38 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Більшість моїх ПМів були екс-девелоперами або екс-qa. Все було ок)

Менеджер как дирежер и его задача делать гармоничность.

Он всегда за свою команду.

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

Неважно, из какой сферы он пришел.

— Не совсем согласен. Где то отдаленно я понимаю что талантливый менеджер может быть применим в любом бизнес-домене...но если вчера он буквально вчера свитчнулся из какой то другой сферы, я не представляю как он без базы профильных знаний и технич. бекграунда, знаний специфики новой сферы — сможет эффективно работать и добиться успеха с первых дней. Да смена областей — не проблема, но нужно или время на новые знания, ну или первые его несколько — проекты в «новой» сфере — высоковероятностно будут зафейлены.
Все ИМХО.

Хороший, плохой, злой :) Мне кажется, самое большое зло менеджера — пускать процессы на самотек. Это не означает, что надо сваливаться в микроменеджмент или жарко дышать за спиной каждого разработчика.
Точнее, это самое большое зло, если исключить чистую клинику типа тирании.
По поводу технарь/не технарь. Вопрос стоит иначе. Технические знания — всегда плюс, даже в работе менеджера, но достаточно ли он хорош, чтобы просто не лезть не в свое дело? Не советовать, к примеру, что и как кодить. Если да, то лучше, чтобы он был технарем.
Впрочем, важно понимать, что менеджер — это не повышение для технаря. Это просто ВООБЩЕ ДРУГОЙ вид деятельности. Любой менеджер, даже чемпион мира по менеджменту, ничего не производит сам, но отвечает за работу других людей. Отсюда следует очень простой рецепт: надо создать условия для команды, не мешать ей создавать продукт, но по дороге решать проблемы, которые возникают и с которым команда не справится сама.
И держать руку на пульсе, естественно. Чтоб потом не было митинга с топ-менеджментом на тему: «Как же так?! Все было так хорошо, а потом стало так плохо!»

«Как же так?! Все было так хорошо, а потом стало так плохо!»

о это одна из самых интересных проблем все знают что так бывает но все думают что «уж точно не про нас» и все когда таки сталкиваются начинают думать строго в ключе «как же так!?» (к) (тм)

ну вот скажем покупаете вы туалетную бумагу в офис и тут тот сорт какой покупаете обычно исчезает и тут такие все «как же так!? было же ж!» или может просто купят пока туалетную бумагу другого сорта? ))

ЗЫ: из практического опыта на «решение вопроса как же так!?» в самом предельном (пока) случае ушло 6 (шесть) недель активной переписки и ежедневных митингов я даже успел пошутить «надо ввести трекинг этого процесса» но только на митинге со средним уровнем на высшем простите засцал имею опыт создания себе проблем потому предпочитаю стараться не создавать по возможности ))

Тут как в медицине. Есть профилактика, есть медикаментозное лечение, терапия, оперативное вмешательство и, наконец, вскрытие. Чем дальше по этой шкале уйдем, тем будет дольше, дороже и больнее.

да не фишка же ж в чем дальше тем дороже и больнее фишка же ж в том что умершему от рака лёгких не читают лекцию о вреде курения с преприрательствами между родственниками друзьями и просто знакомыми а просто закапывают и устраивают пышные похороны и на этом всё а если вдруг не успел умереть то просто берутся лечить исходя из конкретной стадии включая «доктор сказал в морг» а никак не «как же так!?» (к) (тм)

в этом же ж фишка

кончилась туалетная бумага в сортире повод просто пойти и взять новый рулон возможно придётся ехать в супермаркет а вовсе не повод разбирательств «как же так!?» (к) (тм)

ЗЫ: с другой стороны таки да были преценты «внезапных скачков расхода» и были и разбирательства но это таки уже совсем другая история тут надо различать таки намеренные активности (а бывают и такие) и таки просто общие процессы

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

это конечно да но это интересная фишка которую я заметил очень очень многие путают а именно то что описанное это непосредственно собственник компании на самый худой случай CEO

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

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

собственно для этого их и нанимают нет?

ЗЫ: и да тут ещё фишка того самого разделения ролей промышленного производства если от менеджера «условно ждут вот это всё» то ждут ли похожего «подхода» и от «простого программиста»? или да или нет и почему так?

Соррян, но отсутствие знаков препинания не дает возможности понять, что именно Вы пытаетесь донести :-)

Ну то есть гори оно все огнем, главное не замарать рук и не микроменеджить. Потому что микроменеджмент — это настолько абсолютное зло, что даже не нуждается в понимании :-)

P.S. такой дядя как Стив Джобс очень активно занимался микроменеджментом во многих вопросах. Хорошо, что он умер, а то на этом форуме ему бы быстро объяснили какой он дурак в лучшем случае.

Джобс не интеллектом выделялся...

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

можно я проверял

Все слышали? Расходимся... Алекс поставил окончательную точку в вопросах менеджмента. Нечего больше обсуждать.

Алекс не ставить розділових знаків. Принципово. :)

ещё раз вы путаете наёмного менеджера с владельцем основателем предпринимателем

Так расскажите чем хороший (т.е. тот, кто качественно делает все, что должен в Вашем понимании) наемный менеджер отличается от владельца/основателя/предпринимателя? По пунктам, если можно.

Мне кажется, самое большое зло менеджера — пускать процессы на самотек.

ref. to «Monitoring and Control»

технически он был не подкован, ему приходилось полагаться на свою команду, на то, что они знают, что делают, и сделают, как надо

Я всегда говорил своим командам — если я знаю и умею больше чем вы то зачем вы тогда нужны? Это нормально когда команда (не люблю слово подчиненные) знает больше чем один человек с менеджером включительно. Варианты когда лид технический гуру и все ему смотрят в рот чуть ли не более опасны чем менеджер-профан — бас фактор быстро устремляется к 1 без какой либо тенденции к к увеличению. Гуру-тимлид выгорает ярким пламенем с обоих концов -сверху от вросшей в лоб звезды, снизу от отдавленного постоянным сидением в работе зада. Команда чахнет, не развивается, скулит и разбегается.

Я всегда говорил своим командам — если я знаю и умею больше чем вы то зачем вы тогда нужны?

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

Варианты когда лид технический гуру и все ему смотрят в рот

это всё одни и те же ж варианты неумения неспособности и в т.ч. прямого отрицания принципов делегирования просто потому что это всегда работает в обе стороны (а в более общем случае оно ещё и многомерно) и соотв. нельзя делегировать что-то тому кто не умеет «быть делегированным» (в т.ч. и прямо отрицает это) равно как и нельзя делегировать что-то тому кто не умеет делегировать (в т.ч. непрямо отрицает это см. «гуру кому заглядывают в рот»)

Команда чахнет, не развивается, скулит и разбегается.

это так но не совсем чаще человеческая природа таки берёт вверх и команда просто начинает соотв. своему гуру лиду а «разбегаться» лишь те кто так или иначе не соотв. в т.ч. ситуативно что интересно это довольно интересно наблюдается на исторических разрезах команд на периодах порядка 10 лет если в команде обнаруживается стабильное ядро существующих в ней порядка 10 лет «игроков» это оно при этом конечно ещё интереснее посмотреть и на контингент «текучки» но это уже сложнее

по опыту из таких «команд» «вымывается» вообще всё что хоть сколь-либо может самостоятельно мыслить и действовать читай «уметь делегировать и быть делегированным»

ЗЫ: а это ещё надо учеть «горизонтальное делегирование» т.е. читай если вдруг «команда фулл-стек» плюс ещё «работающих на длительном периоде» то это уже совсем оно и тут мы возвращаемся к тому момент когда

Это нормально когда команда (не люблю слово подчиненные) знает больше чем один человек с менеджером включительно.

знает только никому не скажет ))

с менеджером включительно

Но лучшей классификации проектных менеджеров, чем у Нейла, я не встречал.

У автора за 13 лет один «нормальный» ПМ попался, насколько ч понял. У меня за 20 лет — один. Еще один был нормальным человеком, но насколько он был хорошим менеджером, не удалось определить (полгода до этого без ПМ справлялись, ему не пришлось напрягаться ))
И при таких показателях (1 к 10) не видно ни по зарплате, ни по конкурсу, что именно эти качества нужны бизнесу от ПМ.
Очевидно, картина мира сильно отличается на уровнях разработчиков и руководства компании. Наверное из-за того, что ретроспектива у директора раз в 100 реже, чем у дева.

А ви самі себе в яку категорію запишете?

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

Хороший менеджер всегда принимает сторону своей команды

нет

Он не технарь.

— бабка надвое сказала

Имеет чутье на людей

 — почему бы это не в конец текста, или в PS мелким серым шрифтом? Это ведь далеко не самое важное качество для человека который управляет людьми.

Владеет best practices управления проектами.

— спасибо, кэп! Достаточно просто погуглить best practices а не все эти скучные Waterfall,Scrum/RUP/ITIL.

остальные пункты не менее бесполезны.

О, подгорать у технаря начало ))

Да, сильно подгорает от захламления ресурса графоманством. Статья чуть больше чем бесполезная.

Нани, Вам, видимо просто повезло с менеджерами не-технарями и Вы пытаетесь абсолютизировать этот опыт. (А может Вы и сами не технарь по образованию?). Из моего опыта, хуже всего иметь дело с менеджерами с плохим техническим бэкграундом (а равно и без него), которые уже какое-то время в IT, а потому думают, что уже все понимают. Т.е. находятся на пике эффекта Даннинга-Крюгера. От этих людей можно услышать о необходимости написать автотесты, которые падают ТОЛЬКО в случае багов. Или автоматизировать в проекте все. Т.е. не только 100% тестов, но и их багфиксинг.

Так что сама «нетехничность» менеджера это все же минус. Хотя, конечно, лучше иметь хорошего и порядочного менеджера не-технаря, чем технаря любой ценой.

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

Хорошему менеджеру не нужно понимать эстимейты (ну только если какой-то уж совсем хайлевел). Про адекватность эстимейтов должна думать команда, которая под руководством хорошего менеджера работает хорошо.

Вытекли глаза из-за ваших ться.

зависит от размеров команды и, как следствие степени дифференциации ролей в ней.
Скажем, если в команде уже выделен тех/тим.лид, архитектор, ведущий разработчик, ..., то есть тот кто прекрасно понимает проект в целом, то, ввиду глубины своего понимания такой может объяснить менеджеру на пальцах, доходчиво о тех же рисках при реализации фичи Х

и второй момент — менеджер — НЕ лид. может быть, но не обязан
и конечно лидом технарей не может стать не технарь — у лида должен быть авторитет в профессии.
и опять же, с ростом размера команды вероятность что менеджер это и еще какой-то т.лид — уменьшается

знание структуры базы данных проекта

вот это менеджеру точно не нужно знать, потому что это знание никак не поможет в его работе

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

да, все от размеров команды зависит
например я сейчас на двух проектах именно та самая живая спецификация, и остальное что вы написали. плюс архитектор, плюс ведущий разработчик. хотя, писать уже удается только паблик api модулей, с // TODO вместо реализации :)

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

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

хотя, писать уже удается только паблик api модулей, с // TODO вместо реализации :)

надо же ж я всегда думал так и должно быть )) в отличие от реальной реальности практикуемой увы реальной практикой ))

и да в этом месте и возникает «гуру лид» который таки не может этого сделать без того чтобы не сделать всё ))

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

это самое выдающееся место в «отечественном понимании менеджера как насяльника» суть есть прямом отрицании чистой функции «менеджить промежуточные стыковки работы команды чисто технические» а вместо этого все «насяльника» стремятся «работать с людьми» а зачем с ними «работать»? и что «работать» больше нечего? а кто тогда всем тем «бумажки перекладывать» занимается? команда? а «менеджер» тогда зачем вообще? что делать? а если убрать совсем?

ЗЫ: неотечественном впрочем тоже см. классику youtu.be/m4OvQIGDg4I

Підписатись на коментарі