А это следствие того о чем я говорил выше — у большинства проджект ассоциируется (в жизни чаще всего так и есть) с техническим менеджером проекта который за катку релизов, декомпозицию тасок на компоненты, последовательность работ (надо понимать межкомпонентную архитектуру чтобы нарисовал сетевой график).
Есть такая мысль тоже. Хотя бывает и проще — разработчику всегда проще договориться с разработчиком. Слышал интересную идею — профессия больше сближает людей чем принадлежность к одной нации (хотя я за интернационал). К примеру россиянин-программист с высокой долей вероятности быстрее найдет общий язык с условным датчанином-программистов, чем к примеру с россиянкой, но другой профессии.
Но тут и обратная сторона медали: тру проджект по науке планирует и управляет коммуникацией, втч слушает экспертов и принимает решения а не погружается по уши во все нюансы. Кроме того по Бруксу написание кода это сколько там 30% от успеха продукта? Поэтому 70% времени проджект вообще не про тех бэкграунд. Вобщем про классический проджект менеджмент в разработке и его плюсы VS сложившаяся практика — таких статей ту пока не увидел. Дерзайте.
В точку. Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера. Неинтересно — что и нормально в целом. Хотя проект по сути всегда делается для кого-то, чтобы решить чью-то боль, на него дает кто-то деньги, кто-то проверяет, кто-то пользуется. Непосредственно разработка без этих вещей существовать не может, ну разве что в личных проектах, и то рано или поздно стают вопросы стартаповские, а для кого, а как лучше, где тут монетизация.
все больше компаний идут к структуре Яндекса или Гугла
У яндекса судя по их каналу на YouTube как раз есть продакты и прожекты, первый рулит продуктом и его стратегией, метриками, развитием, второй занимается операционкой. И в целом, даже при наборе в их Школу Менеджеров там про тех скиллы почти ничего не было, общие понятия которые нагуглить можно и очень много продуктовых вопросов.
Про гугл не скажу, но думаю это и не столь важно — там другие реалии абсолютно.
Ну и сравнение конверсии с hh.ru по 2м резюме (проджекта и проджекта+продакта, есть оба опыта) не в пользу первого.
Тут мне кажется все на поверхности — больше скиллов, отсюда больше интереса. Все таки все хотят экономить, при небольших бюджетах эт вполне нормально. Просто одно дело ситуация на рынке, и другое как оно было бы правильно и эффективно в той или иной ситуации.
Ну и еще я не питаю иллюзий по поводу понимания этих моментов владельцами и топ-менеджерами компаний. Да, есть очень толковые и опытные люди, но много тех кто управление в целом, проектное в частности — представляют себе очень смутно. Оно и за последние то 5 лет изменилось очень сильно.
Я так смотрю по рейтингу самой статьи и конкретно моих комментов про уровень технических скиллов у ПМ-а — людям не нравятся такие как я, кто не программировал, не учился в политехе и не обладает технической специальностью и при этом приходят в IT, пусть и на менеджерскую позицию. Притом что мало кто знаком со мной лично, и знает мой уровень. Скорее у всех резонирует личный опыт.
Мое мнение — наоборот. Атавизм — это совмещение.
Прогресс идет — и вместе с ним специализация. Когда есть достаточно бюджета и проекты большие — можно выделить отдельного бизнес-аналитика, можно на продукте держать прожекта и продакта, с разным функционалом.
Я не говорил что их вообще описывать не надо — так или иначе надо, таски, стори. Но полноценную документацию BRD, SRS и прочее лучше и качественней пишут специализированные бизнес-аналитики. Также и с продакт менеджментом, по хорошему это вообще другая специальность, для нее нужны другие знания, навыки и опыт.
Если совмещать — то все равно в чем то будет проседать менеджер, или это будет уникум который всеми навыками владеет одинаково, но таких единицы.
Менеджер мог погуглить что это значит или спросить напрямую. Это его конкретно менеджерский косяк, технический бэкграунд непричем.
В том то и дело — суть он понимать должен быть способен, просто для этого серьезного бэкграунда не требуется, достаточно грамотности.
Я скажу так — зависит.
В телекоммуникациях к примеру — да, без него делать особо нечего, в enterprise проектах тоже, хотя я к примеру такие веду сейчас.
Если речь об IT аутсорсинге — где разрабатывают пользовательский софт — вполне достаточно общей технической грамотности, базового понимания разработки, тестирования, сетей.
Менеджер — он 90% своего времени общается с людьми, его задача организовывать, договариваться, контролировать выполнение. Технические задачи — лежат на плечах технических специалистов, есть ведь разработчики техлиды, архитекторы. Больше скажу — плохо или очень плохо когда менеджер при наличии всех этих людей лезет в условно в код, потому как это не его епархия в целом. Да и нехорошо когда у него нет конкретно управленческого бэкграунда. Это отдельная профессия, которой надо учиться и в которой своя теория есть, исследования, практики, инструменты.
Вы в целом про какую сферу то говорите? Разработку под ключ? Продуктовая разработка? Что-то из этого?
Если речь про подразделение IT профиля на крупном предприятии — то все что я написал к нему совсем неприменимо и мы просто о разном говорим.
Прочтите определение проекта, PMBok. Про тапочки вы зря, серьезно без шуток, и про аджайл тоже. У меня складывается впечатление что вы его примеряете на подразделение и понятно — что там это нифига работать не будет, так никто особо и не сует туда его.
Подразделение — правильно оно ФУНКЦИОНАЛЬНОЕ. Оно не занимается проектами, оно выполняет функцию. Проект не подразумевает этого — читайте определение. Просто ознакомьтесь с терминологией в проектном управлении, и в менеджменте. Ну серьезно. Я ничуть не сомневаюсь что вы разбираетесь в том о чем говорите. Я прихожу к выводу что мы вообще о разном говорим, совсем. Только вы интерполируете ваше видение на аутсорс IT разработку, хотя не уверен что работали в ней и разбираетесь — поправьте если не прав. Я лишь отмечу что там общее это разве что наличие инженеров. В остальном это совсем другая история, другие цели там ставятся, другой формат работы, её организации.
С каких пор заказчик стал более компетентным в вопросе автоматизации процессов чем программисты?
Причем тут компетентен. Вы приходите в магазин — продавец вам должен сказать что вас надо, или может вы сами свои потребности знаете?
Программмисты компетенты в автоматизации, но они не компетентны в том что хочет заказчик, они не знаю его бизнес, они не знаю его боли. Они знают КАК, но они не знают ЧТО надо автоматизировать. Это знает тот кто обратился к ним.
Срам про разработку по фичам, что напрочь отрицает научно-обоснованный подход к разработке по сущностям предметной области.
Нет. Просто прочитайте гайд. И ниже коммент. Даже детализировать не буду.
Да ладно. Он хотя бы понимает что реально надо клиенту и как этого наиболее быстро и качественно достичь.
Да ладно? Отрицаете существование управления снова?) Ну серьезно почитайте Тейлора или вообще хоть что то про это.
И нет не понимает. Он понимает как можно сделать те или иные вещи. Чтобы понять что надо клиенту — с ним надо поговорить, общаться программист, особенно бизнес переговоры вести также не умеет, как и организовывать других.
Никаких. Команда делится на подгруппы соответственно разделению системы на подсистемы. Дальше рекурсивно. Соответственно у каждого четко определена его зона ответственности и т.д.
Кто ее делит? Сама? Вы хоть раз пробовали группу разделить хоть на пары, на тренировке к примеру? Кто назначает подсистемы. Кто собирает требования заказчика? Кто определяет как отчитываться о проделанной работе? Кто ставит сроки? Кто проверяет? Серьезно, хватит туннелировать.
Отдел АСУП — это ФУНКЦИЯ. Не проект. Проект подразумевает неопределенность. Это вообще другое. У них может быть тех руководитель, а знаете почему? Потому что остальное все у них прописано в регламентах, и обеспечивают их всем другие подразделения. Мы говорим про проекты тут, а не про отдел АСУП.
Дальше даже отвечать не буду — скрам не про фичи, про управление мало, выводы совсем без аргументов. Идея фикс про высер и прочее такое. Научно-обоснованный подход везде. На мои аргументы ответа нет. Больше время на ответы вам тратить не буду, уж простите.
Об этом собственно я писал — что менеджер он есть всегда. В скраме это распределено примерно так: продуктовые вопросы на продакт оунере, вопросы организации, фасилитации, решения проблем — на скрам-мастере, вопросы непосредственно принятия решений, как технических так и нетехнических по разработке — на всей команде, без выделения главного. ПМ по сути во всех.
И да это могут реализовать только оч крутые команды, с высоким скиллом.
«мы тут решили, что нам нужен девопс разработчик с экспертными знаниями в области девопс, провели собесы, нашли спеца — обеспечьте его рабочим местом и платите вот такую зарплату, ну и нам повысьте до его уровня, у нас же все равны»
Это и ПМ не решает. Это организация условий работы — не часть проекта, это решает по факту работодатель, владелец компании, или кто-то еще. ПМ формируя команду на проект — запрашивает ресурсы, ему их дают, он максимум может поучаствовать в их собеседовании и принятии решения, но это по сути подготовка к проекту, а не сам проект.
Организация подразумевается что работ непосредственно по разработке проекта. Все остальное другие люди делают зачастую, функциональные руководители компании.
Не соглашусь совсем.
То что вы описываете это техническая разработка в вакууме. Если убрать все остальное — то да, это так работает.
В реальном мире коммерческой разработки — где есть тот кто эту разработку спонсирует, тот для кого она ведется, и еще пользователи, все несколько сложнее.
Программисты которые это понимают, не считают менеджера никем и ничем. Потому что каждому свое — они разрабатывают, он управляет, общается с кем нужно, помогает создать условия.
Скрам не отрицает описанное вами, он вообще не про это. Он про то что надо спрашивать заказчика что ему надо, а потом мелкими итерациями это реализовывать создавая техническую возможность, а потом выстраивая порядок исходя из нее. Лучший программист он лучше все программирует а не организует других. Поэтому он не будет лучшим менеджером. Управление и программирование это абсолютно разные области.
Насчет в продакшн — нет, вообще нет. На практике это работает у фрилансера одиночки и то через раз. Возникает сразу куча вопросов, а что делать, а как, а как именно вот в этом месте, а то будет делать это, кто будет делать то — мы же командой работаем, а когда надо, а как пишем, а как отчитываемся, кому отчитываемся. И много еще.
Все это лучший программист организовать не сможет, и метод уяк-уяк — тоже не получится.
В целом — все что вы написали это просто отрицание того что управление в целом существует как наука, и работает. Почитайте про историю, про Тейлора что ли, про разделение труда и прочие азы. Просто попробуйте собрать горстку среднестатистических технарей в офисе-аквариуме и посмотрите как они будут проект выполнять, как будут разбираться, кому как и что делать. На практике, не обязательно мне верить — эмпирически просто проверьте.
Любой сотрудник может подойти к руководителю с вопросом, в силах руководителя отвечать или нет. Это его право, полномочия непричем.
Ситуация которую вы описываете — это когда ПМ-а вообще не должно быть. Руководитель сам руководит проектом. Если же он взял на это ПМ-а, то он ему должен делегировать полномочия.
Если взял координатора — то не делегирует полномочия, а прописывает ему координаторские обязанности, не буду углубляться.
А отвечать на вопросы, и всеми прочими способами руководить на своем уровне — это как раз то чем он занимается свои 24 часа. Не общаясь с подчиненными руководить невозможно.
Оставим подсиживание на совести тех кто это делает. В целом это реальный риск да — но он меньше той пачки рисков которые появляются когда не делегируешь. Один человек может сделать не очень много. 24 часа в сутках у него всего.
Отвлекать вопросами, которые мешают.
Когда у него нет полномочий — он отвлекает гораздо больше, решениями. Он ничего сам решить не уполномочен, он с каждым бегает к руководителю.
А вопросы — причем тут они вообще? Менеджер задает вопросы руководителю только тогда когда это уровень руководителя решать их, или когда информация ему недоступна, а руководителю доступна.
Да, это ровно так. Если ПМ не может оценить постоянно меняющуюся ситуацию и корректировать работу вверенного отдела, то фуфельный он ПМ. Где-то быть настойчивым и проявить характер, где-то поблагодарить и похвалить. А если разрабы ему ещё на момент начального виденья говорят — «Ваш план — *овно » а он не прислушивается, то как говориться — сам дурак. И не надо ждать хорошего результата.
Отлично все описали, только спустить с уровня схемы, на уровень схемоида. Это не работает на уровне да/нет. Это софт-скилл, он не поддается формуле. Нет в природе менеджеров которые не ошибаются. Как и людей которые не ошибаются. При этом я согласен что он должен все это уметь делать на отлично, и даже если местами ошибается — быстро разруливать ситуацию. Но статья вообще не про это.
Обычно люди упертый, когда считают что собеседник слабо ориентируется в том что говорит, и хочет навязать выполнение какой-то дичи.
Нет. Бывает человек уперт потому что ему просто не нравится твоя рубашка. Или тембр голоса. Даже если он считает что человек слабо ориентируется — он же его не тестировал зачастую, он может ошибаться. Вопрос в том что адекватный человек даже если видит что человек не шарит — объясняет ему, а не закрывается. Менеджер не должен шарить во всех языка программирования на которых пишет его команда.
Если у тебя нету машины, но тебе нужно общаться с водителем автомобиля (это твоя обязанность), иди и учи азы вождения и мат. часть по комплектации легкового автомобиля, можешь там пойти в гоночки поиграть (мы ведь не про вождения разумеется сейчас =) ) иначе на кой ты как собеседник вообще данному водителю, он и без тебя знает как данный автомобиль поедет.
Вы не поняли что сказал. Когда у тебя нет компьютера — навыки печатания те не пригодятся. Когда клиент не хочется встречать и не берет трубку — никакое ораторское мастерство не поможет. Точно также с командой бывают случаи — когда объяснить невозможно. Даже будучи отличным переговорщиком, и разбираясь в теме. Повторяю — переговоры и работа в команде это двухсторонний процесс. Если одна сторона напрочь отказывается — вторая сделать ничего не может. При любых скиллах.
Попробую еще проще — вам девушки отказывали когда нибудь? Ну вот сразу так нет и все. Что тут делать — пытаться дальше навязываться? Зачем? Ответ прозвучал, он отрицательный. Может вы отличный парень, и ей бы может понравились узнай она вас получше, но она не хочет узнавать, ни сейчас ни потом. В этом случае не надо ее дергать, не надо навязываться — надо просто уйти. Тем более если не уйти то это плавно перетекает в домогательства, Харви Вайнштейн вон доигрался.
ваш комментарий аналогично в таком случае, аргументы? Мне кажется нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
основываясь лишь на несовпадении ценностей и мифических «недочетах» характеризует глупо только Вас
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте. Это раз. Я вполне себе неплохо разбираюсь в том что говорю, и главное — аргументирую это. Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
в-третьих, вот это все «профессионалу с такими работать не захочется» — нафиг таких условных «профессионалов», за которых все сделать надо в организационном плане.
Не условных. Почему нафиг? Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами? Разработка софта и разработка бизнес-процессов это разное, нет?
И главное — чего ради профессионал будет приходить в компанию где условно нет четкой организации процесса, и пытать что-то изменить? Зачем? Почему ему не хотеть нормальных условий работы, с нормальными процессами, с нормальным начальством? У него как правило есть профессиональное самолюбие — потому что он потратил годы на то чтобы достичь этого уровня, а тут он по вашей логике должен приходить и тратить время не на свои непосредственные обязанности а на поиск того кто отвечает за какой-то вопрос, или на то чтобы отбивать от нападков коллег которые лезут в его работу. Чего ради?
Вы описали задачи, а я больше про иерархию и полномочия. То есть вы про функцию — достаточно внятно описали, но я говорил про структуру. Это просто разное.
На моем субъективном опыте, избавление от тисков легко было достигнуто, простым финтом ушами. PM не влияет на оценку трудов и результатов разработчиков. Они сразу привратились в партнеров а не в подчиненых и пришлось просто прозрачно с данными объяснять планы и решения, через несколько месяцев все уже знали что если к PM'у вопрос: «А почему здесь так» Он мог запросто запросик два написать и ответить либо 'Это увеличит X на 5%' либо 'А действительно, возможно мы не правы, ты как предлагаешь'
Способ весьма любопытный, но далек от универсальности. Менеджер без полномочий не менеджер, а координатор. Я же рассуждаю именно про менеджера.
Без менеджера-руководителя работать могут только очень продвинутые разработчики, которых можно убедить аргументом, который вы привели. Часто даже и его не надо — они сами знают зачем, знают как — и делают. С ними легко общаться, потому что вы конструктивны — они конструктивны, профессионалы между собой всегда договорятся. Но это топ-люди. Таких мало — и уверен каждая компания мечтает таких иметь, правда далеко не каждая может их потянуть как по деньгам так и культурно.
Задачи в бэклог заносит ПМ. ПО учавствует только в приоритезации.
Откуда ПМ в скраме?
Еще раз — я изначально говорил о проекте, и больше про аутсорс — когда проект выполняет подрядчик, и все что написано это про него. Речь не про продуктовую разработку.
Есть такая мысль тоже. Хотя бывает и проще — разработчику всегда проще договориться с разработчиком. Слышал интересную идею — профессия больше сближает людей чем принадлежность к одной нации (хотя я за интернационал). К примеру россиянин-программист с высокой долей вероятности быстрее найдет общий язык с условным датчанином-программистов, чем к примеру с россиянкой, но другой профессии.
В точку. Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера. Неинтересно — что и нормально в целом. Хотя проект по сути всегда делается для кого-то, чтобы решить чью-то боль, на него дает кто-то деньги, кто-то проверяет, кто-то пользуется. Непосредственно разработка без этих вещей существовать не может, ну разве что в личных проектах, и то рано или поздно стают вопросы стартаповские, а для кого, а как лучше, где тут монетизация.
В общем спасибо за мнение. Буду писать.
У яндекса судя по их каналу на YouTube как раз есть продакты и прожекты, первый рулит продуктом и его стратегией, метриками, развитием, второй занимается операционкой. И в целом, даже при наборе в их Школу Менеджеров там про тех скиллы почти ничего не было, общие понятия которые нагуглить можно и очень много продуктовых вопросов.
Про гугл не скажу, но думаю это и не столь важно — там другие реалии абсолютно.
Тут мне кажется все на поверхности — больше скиллов, отсюда больше интереса. Все таки все хотят экономить, при небольших бюджетах эт вполне нормально. Просто одно дело ситуация на рынке, и другое как оно было бы правильно и эффективно в той или иной ситуации.
Ну и еще я не питаю иллюзий по поводу понимания этих моментов владельцами и топ-менеджерами компаний. Да, есть очень толковые и опытные люди, но много тех кто управление в целом, проектное в частности — представляют себе очень смутно. Оно и за последние то 5 лет изменилось очень сильно.
Написать про это отдельную статью товарищи?
Прогресс идет — и вместе с ним специализация. Когда есть достаточно бюджета и проекты большие — можно выделить отдельного бизнес-аналитика, можно на продукте держать прожекта и продакта, с разным функционалом.
Я не говорил что их вообще описывать не надо — так или иначе надо, таски, стори. Но полноценную документацию BRD, SRS и прочее лучше и качественней пишут специализированные бизнес-аналитики. Также и с продакт менеджментом, по хорошему это вообще другая специальность, для нее нужны другие знания, навыки и опыт.
Если совмещать — то все равно в чем то будет проседать менеджер, или это будет уникум который всеми навыками владеет одинаково, но таких единицы.
В том то и дело — суть он понимать должен быть способен, просто для этого серьезного бэкграунда не требуется, достаточно грамотности.
В телекоммуникациях к примеру — да, без него делать особо нечего, в enterprise проектах тоже, хотя я к примеру такие веду сейчас.
Если речь об IT аутсорсинге — где разрабатывают пользовательский софт — вполне достаточно общей технической грамотности, базового понимания разработки, тестирования, сетей.
Менеджер — он 90% своего времени общается с людьми, его задача организовывать, договариваться, контролировать выполнение. Технические задачи — лежат на плечах технических специалистов, есть ведь разработчики техлиды, архитекторы. Больше скажу — плохо или очень плохо когда менеджер при наличии всех этих людей лезет в условно в код, потому как это не его епархия в целом. Да и нехорошо когда у него нет конкретно управленческого бэкграунда. Это отдельная профессия, которой надо учиться и в которой своя теория есть, исследования, практики, инструменты.
Если речь про подразделение IT профиля на крупном предприятии — то все что я написал к нему совсем неприменимо и мы просто о разном говорим.
Прочтите определение проекта, PMBok. Про тапочки вы зря, серьезно без шуток, и про аджайл тоже. У меня складывается впечатление что вы его примеряете на подразделение и понятно — что там это нифига работать не будет, так никто особо и не сует туда его.
Подразделение — правильно оно ФУНКЦИОНАЛЬНОЕ. Оно не занимается проектами, оно выполняет функцию. Проект не подразумевает этого — читайте определение. Просто ознакомьтесь с терминологией в проектном управлении, и в менеджменте. Ну серьезно. Я ничуть не сомневаюсь что вы разбираетесь в том о чем говорите. Я прихожу к выводу что мы вообще о разном говорим, совсем. Только вы интерполируете ваше видение на аутсорс IT разработку, хотя не уверен что работали в ней и разбираетесь — поправьте если не прав. Я лишь отмечу что там общее это разве что наличие инженеров. В остальном это совсем другая история, другие цели там ставятся, другой формат работы, её организации.
Это вместо пост скриптум.
Причем тут компетентен. Вы приходите в магазин — продавец вам должен сказать что вас надо, или может вы сами свои потребности знаете?
Программмисты компетенты в автоматизации, но они не компетентны в том что хочет заказчик, они не знаю его бизнес, они не знаю его боли. Они знают КАК, но они не знают ЧТО надо автоматизировать. Это знает тот кто обратился к ним.
Нет. Просто прочитайте гайд. И ниже коммент. Даже детализировать не буду.
Да ладно? Отрицаете существование управления снова?) Ну серьезно почитайте Тейлора или вообще хоть что то про это.
И нет не понимает. Он понимает как можно сделать те или иные вещи. Чтобы понять что надо клиенту — с ним надо поговорить, общаться программист, особенно бизнес переговоры вести также не умеет, как и организовывать других.
Кто ее делит? Сама? Вы хоть раз пробовали группу разделить хоть на пары, на тренировке к примеру? Кто назначает подсистемы. Кто собирает требования заказчика? Кто определяет как отчитываться о проделанной работе? Кто ставит сроки? Кто проверяет? Серьезно, хватит туннелировать.
Отдел АСУП — это ФУНКЦИЯ. Не проект. Проект подразумевает неопределенность. Это вообще другое. У них может быть тех руководитель, а знаете почему? Потому что остальное все у них прописано в регламентах, и обеспечивают их всем другие подразделения. Мы говорим про проекты тут, а не про отдел АСУП.
Дальше даже отвечать не буду — скрам не про фичи, про управление мало, выводы совсем без аргументов. Идея фикс про высер и прочее такое. Научно-обоснованный подход везде. На мои аргументы ответа нет. Больше время на ответы вам тратить не буду, уж простите.
И да это могут реализовать только оч крутые команды, с высоким скиллом.
Это и ПМ не решает. Это организация условий работы — не часть проекта, это решает по факту работодатель, владелец компании, или кто-то еще. ПМ формируя команду на проект — запрашивает ресурсы, ему их дают, он максимум может поучаствовать в их собеседовании и принятии решения, но это по сути подготовка к проекту, а не сам проект.
Организация подразумевается что работ непосредственно по разработке проекта. Все остальное другие люди делают зачастую, функциональные руководители компании.
ну так публикация моя ) и обсуждение ведется того что я написал, а я писал про проекты, про продукты вообще не заикался.
Скрам по ходу всплыл, даже и не помню когда именно. Но это разное — согласен, просто опыт у меня есть и в том и в том.
То что вы описываете это техническая разработка в вакууме. Если убрать все остальное — то да, это так работает.
В реальном мире коммерческой разработки — где есть тот кто эту разработку спонсирует, тот для кого она ведется, и еще пользователи, все несколько сложнее.
Программисты которые это понимают, не считают менеджера никем и ничем. Потому что каждому свое — они разрабатывают, он управляет, общается с кем нужно, помогает создать условия.
Скрам не отрицает описанное вами, он вообще не про это. Он про то что надо спрашивать заказчика что ему надо, а потом мелкими итерациями это реализовывать создавая техническую возможность, а потом выстраивая порядок исходя из нее. Лучший программист он лучше все программирует а не организует других. Поэтому он не будет лучшим менеджером. Управление и программирование это абсолютно разные области.
Насчет в продакшн — нет, вообще нет. На практике это работает у фрилансера одиночки и то через раз. Возникает сразу куча вопросов, а что делать, а как, а как именно вот в этом месте, а то будет делать это, кто будет делать то — мы же командой работаем, а когда надо, а как пишем, а как отчитываемся, кому отчитываемся. И много еще.
Все это лучший программист организовать не сможет, и метод уяк-уяк — тоже не получится.
В целом — все что вы написали это просто отрицание того что управление в целом существует как наука, и работает. Почитайте про историю, про Тейлора что ли, про разделение труда и прочие азы. Просто попробуйте собрать горстку среднестатистических технарей в офисе-аквариуме и посмотрите как они будут проект выполнять, как будут разбираться, кому как и что делать. На практике, не обязательно мне верить — эмпирически просто проверьте.
Ситуация которую вы описываете — это когда ПМ-а вообще не должно быть. Руководитель сам руководит проектом. Если же он взял на это ПМ-а, то он ему должен делегировать полномочия.
Если взял координатора — то не делегирует полномочия, а прописывает ему координаторские обязанности, не буду углубляться.
А отвечать на вопросы, и всеми прочими способами руководить на своем уровне — это как раз то чем он занимается свои 24 часа. Не общаясь с подчиненными руководить невозможно.
Когда у него нет полномочий — он отвлекает гораздо больше, решениями. Он ничего сам решить не уполномочен, он с каждым бегает к руководителю.
А вопросы — причем тут они вообще? Менеджер задает вопросы руководителю только тогда когда это уровень руководителя решать их, или когда информация ему недоступна, а руководителю доступна.
Отлично все описали, только спустить с уровня схемы, на уровень схемоида. Это не работает на уровне да/нет. Это софт-скилл, он не поддается формуле. Нет в природе менеджеров которые не ошибаются. Как и людей которые не ошибаются. При этом я согласен что он должен все это уметь делать на отлично, и даже если местами ошибается — быстро разруливать ситуацию. Но статья вообще не про это.
Нет. Бывает человек уперт потому что ему просто не нравится твоя рубашка. Или тембр голоса. Даже если он считает что человек слабо ориентируется — он же его не тестировал зачастую, он может ошибаться. Вопрос в том что адекватный человек даже если видит что человек не шарит — объясняет ему, а не закрывается. Менеджер не должен шарить во всех языка программирования на которых пишет его команда.
Вы не поняли что сказал. Когда у тебя нет компьютера — навыки печатания те не пригодятся. Когда клиент не хочется встречать и не берет трубку — никакое ораторское мастерство не поможет. Точно также с командой бывают случаи — когда объяснить невозможно. Даже будучи отличным переговорщиком, и разбираясь в теме. Повторяю — переговоры и работа в команде это двухсторонний процесс. Если одна сторона напрочь отказывается — вторая сделать ничего не может. При любых скиллах.
Попробую еще проще — вам девушки отказывали когда нибудь? Ну вот сразу так нет и все. Что тут делать — пытаться дальше навязываться? Зачем? Ответ прозвучал, он отрицательный. Может вы отличный парень, и ей бы может понравились узнай она вас получше, но она не хочет узнавать, ни сейчас ни потом. В этом случае не надо ее дергать, не надо навязываться — надо просто уйти. Тем более если не уйти то это плавно перетекает в домогательства, Харви Вайнштейн вон доигрался.
ваш комментарий аналогично в таком случае, аргументы? Мне кажется нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте. Это раз. Я вполне себе неплохо разбираюсь в том что говорю, и главное — аргументирую это. Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
Не условных. Почему нафиг? Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами? Разработка софта и разработка бизнес-процессов это разное, нет?
И главное — чего ради профессионал будет приходить в компанию где условно нет четкой организации процесса, и пытать что-то изменить? Зачем? Почему ему не хотеть нормальных условий работы, с нормальными процессами, с нормальным начальством? У него как правило есть профессиональное самолюбие — потому что он потратил годы на то чтобы достичь этого уровня, а тут он по вашей логике должен приходить и тратить время не на свои непосредственные обязанности а на поиск того кто отвечает за какой-то вопрос, или на то чтобы отбивать от нападков коллег которые лезут в его работу. Чего ради?
Вы описали задачи, а я больше про иерархию и полномочия. То есть вы про функцию — достаточно внятно описали, но я говорил про структуру. Это просто разное.
Способ весьма любопытный, но далек от универсальности. Менеджер без полномочий не менеджер, а координатор. Я же рассуждаю именно про менеджера.
Без менеджера-руководителя работать могут только очень продвинутые разработчики, которых можно убедить аргументом, который вы привели. Часто даже и его не надо — они сами знают зачем, знают как — и делают. С ними легко общаться, потому что вы конструктивны — они конструктивны, профессионалы между собой всегда договорятся. Но это топ-люди. Таких мало — и уверен каждая компания мечтает таких иметь, правда далеко не каждая может их потянуть как по деньгам так и культурно.
Насчет подсидеть — вы это серьезно?
Откуда ПМ в скраме?
Еще раз — я изначально говорил о проекте, и больше про аутсорс — когда проект выполняет подрядчик, и все что написано это про него. Речь не про продуктовую разработку.