Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

А нужны ли менеджеры?

В соседнем топике Нетроль Roman Bezzubtsev очень агресивно отреагировал на обсуждение темы нужности менеджеров в software проектах, поэтому подниму-ка тему отдельным топиком.
Мои тезисы:
— не нужны
— скрам шагает по планете
— менеджментом тасков должен заниматься тимлид, так как он намного ближе к телу, у него намного более адекватное представление о сроках и способностях людей
— сколько я не видел абстрактных проджект менеджеров, именно менеджить в программистских проектах у них получалось херово, они слишком оторваны от реалий, поэтому что-бы оправдать свое существование они перенимали функции individual contributors, кто-то тестил сам и ругал программеров за баги, кто-то писал доки, кто-то подрабатывал офис менеджером, а вот когда менеджер начинает внедрять процессы, которые модны в этом месяце, задалбывая программеров, это самый худший вариант.
— подавляющее большинство пытаются показать свою важность собирая безсмысленные митинги, делая ненужные питчи, навязывая странные процессы.

А какое мнение почтенной публики? Какие есть success и неsuccess stories?

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

Найкращі коментарі пропустити

для початку, як тут і написали, давайте визначимось, хто є хто. і опишемо не «я бачив 20 хєрових менеджерів тому роль менеджера — не потрібна» а саму роль. і давайте писати не про абстрактних класних програмістів, які і глибокотехнічні і в бізнес вимогах шарять, щей в потрібній кількості водяться і в одному офісі, і не про розумних багатих замовників. а про те, що на практиці.

менеджер — в першу чергу посередині між бізнесом (замовниками, інвесторами) і командою. в другу — комунікатор між членами команди, координатор — якщо вони а) в різних сферах/технологіях б) в різних офісах/компаніях/країнах. в третю — до певної міри відповідає за прийняті рішення і результат в цілому, якщо підлеглий все зробив так, як манагер сказав — брати на себе всі удари зовні.

комунікація — це прийняти всю переписку замовника, періодично відсіювати всі його бурхливі фантазії, спускати на команду в більш технічному вигляді і з чіткою розстановкою пріоритетів. перевіряти, чи всі розуміють, що мають робити, що пріоритетніше, що кого блокує, чи всі правильно зрозуміли, що мають зробити. не допускати тиску на девів з боку замовника чи керівництва, провіряти всі естімейти і множити на коефіцієнти.

тімліди — відповідають за рішення в своїх технологіях/підкомандах, частково зайняті кодінгом (дизайном/тестингом). в нюанси інших технологій, сфер і бізнес вимог можуть не вникати.

так, скрам це все може реалізувати. але, до речі, там є скрам менеджер. і замовника ще треба привчити не лізти в команду, а якщо він буйно активний — когось йому підсунути. а буйно (саме буйно, буває і просто бурхливо) активними може бути і власне керівництво. і скрам теж має хтось впроваджувати, моніторити ретроспективи і вирішувати проблеми, приймати рішення, коли щось перестало працювати. ато начитається якийсь власник автомеханічного бізнесу, що в айті можна рубати бабло, можна просто зібрати девів, зааплаїти скрам — і збирай баблос, назбирає джуніорів і майстрів-піздєтєлєй, і потім тільки розгрібай авгієві конюшні, а цей директор щей скаже всі монітори розвернути так, щоб він бачив, хто чим займається.

і не забуваємо — що ідеальних умов, замовників, девелоперів, тестерів і артовиків не буває. директорів і сейлсів — теж. бувають різної довбанутості і жмотності замовники зі своїм баченням бізнесу і навіть своїми 19річними розробниками, і пачки джуніорів, і розподілені команди, і проекти, початі в минулому столітті зі сотнями тисяч користувачів і тисячними збитками за годинний простій системи. і національні особливості що замовників, що розробників. бувають геніальні деви з нульовою комунікативністю чи хорошим заглибленням в деталі але поганим баченням інших потреб в іншій технології, поганим розумінням бізнесу. і різні підходи управління компанією керівництвом, і різний вплив на керівництво сейлів. можна 100500 раз кричати, що і як має бути, а можна брати що є і намагатись поставити процес під існуючі умови так, щоб все запрацювало.

в мене був досвід роботи напряму на замовницю без менеджера. мені просто іпали моск майже цілодобово. вона клепала баги, третина яких була або фічами або дублікатами або суперечили одне одному. вона кожному говорила щось своє, і якби ми не проговорювали це між собою, навалили б дров. я свої і іноді серверника баги щодня проходила і в мене зі 40 лишалось 25 на одного, це займало годину-півтори. були ще члени команди на її стороні, які тупо фіксили що бачили не звіряючись з багами у всій системі. все проговорювання віднімало дуже багато часу. проговорювання того ж з її девами викликало повне нерозуміння чого я лізу і командую, а вони тупо ламали зроблене. вона не давала нам зробити хоч щось, що не є фічею — навіть якщо це компонента, якою можна буде покрити половину фіч. на проекті код серверників не був включений в систему версій. взвалити всю цю комунікацію на тімлідів? нас всього було на нашій стороні 2 флешера, 1 пхп-іст, половина тестера, і ми не були авторитетом для неї. і навіть якщо припустити, що команди були б великі і на нашій стороні. тімліду тестерів вона плете одне, тімліда флешерів грузить новим дизайном, вже промальованим і не узгодженим з девами, тімліда серверників напрягає ще адмінкою і хостингом. характер в неї такий, що не лізти в справи розробників вона не могла — а гроші платить вона. керівництво взагалі в ІТ не рубає, і коли я при наборі нового дева наполягаю на тому кандидаті, якого знаю (бо мідл-сеніор кандидатів нема, а за джунів я буду відповідальна) — мене щей підставляють, що я зі всіх прекрасних кандидатів наполягла саме на цьому. і того 3 працівника сеніор рівня мають вбивати по пів дня на чат з замовницею, розбори міскомунікації директорів і замовниці, проговорення того між собою, бо один менеджер — це пльохо? тімлід серверників може уявлення не мати, що флешери задихаються без юіксера і чітких постановок, тімлід флешерів уявлення може не мати про проблеми масштабування сервера і потреби аналітики і т.п. і при тому їм всім і без комунікації зі замовницею є над чим голову ламати.
можна скільки завгодно говорити про те, як має бути поставлений в процесі скрам, як неправильно в нас взятий, стартанутий і взагалі проект, які деви неправильні — але вищеописані мною замовники існують в природі, платять не малі гроші, і простіше замість думати про сферичний ідеальний проект з ідеальною ж командою і замовником в вакуумі, поставити між командою і замовником хорошого технічного проблем-солвера, який може брати на себе всі удари як керівництва так і замовника і при тому координувати підлеглих.

я взагалі не розумію, як можна кидати на девів напряму замовника, не підстраховуючи манагером. на моїх очах стільки раз ставались різні хитрі наїзди замовників на девів через керівництво, чи провтиків керівництва в фінансових питаннях (до старту проекту чи після його здачі), що я не уявляю, скільки б гівна на девів вилилося, якби не пм-и.

інший приклад: прямо зараз мої директори-інвестори пориваються надавити на дева, який паралельно вчиться на грант в іншій країні — щоб він забив на навчання і кодив інтенсивніше. я їх від цього весь час відгороджую, бо знаю — він там кодить дуже багато, а навчання не кине взагалі. пушити його — просто відволікати, нервувати і він або вигорить або кине нас, а не навчання.

мені зараз якраз і приходиться займатись менеджментом, і не сказала б, що це обов’язки тім ліда. при тому мені ж доводиться кодити, і щоб зробити хоч якийсь кусок роботи — я на день-два йду додому і вирубую роутер. бо щодня дьоргають якраз мене, а не я «заважаю девам» — всі питають як саме буде зроблено та чи інша частина роботи, що саме зараз пріоритетніше, чому саме зараз ми робим якісь речі так. проект складається, дуже грубо кажучи, з 3 серверних підпроектів, 2 клієнтських і 2 редакторських, 2 артових. люди знаходяться в 5 країнах, один кусок роботи робить дев з іншої компанії-аутсорсера. при наявній документації і системах трекінга комунікація займає стільки, що під кінець дня в мене від ведення одночасно по 2-3 скайп-чатів, відбивання листів і моніторингу тікетів голова пухне. якщо на це кидати тімлідів — вони або перестануть бути кодерами і фактично стануть менеджерами, або будуть не до кінця синхронізованими і їх підкоманди видаватимуть не працюючий разом різнобій. при тому ж у нас є тімліди — у дизайнерів, у серверників. люди толкові, дуже толково продумали систему, склали тз, заклали гнучкість, розширюваність і масштабування, зробили свій редактор для гри. але чомусь до моєї появи фічі в грі не прив’язувались до можливості їх задавати в редакторі (а значить нефункціональні взагалі), автоматизація білдів не була першочерговим завданням і не включала в себе окремого сервера для геймдизайнерів, в коді було багато хардкоду, арт неможливо заливати через редактор (тобто без допомоги девів), розробник редактора не розумів пріоритетності задач, ізометрія напряму читає дані з файлів. і про яку частину моделі даних у різних девів я не питала — у кожного було своє розуміння, якщо взагалі було, про юіксера ніхто взагалі не задумувався... має бути хтось, хто знає весь проект — не в деталях, але достатньо глибоко, щоб бути впевненим, що всі рухаються в правильному напрямку і в нас не виникне блокерів чи люди не простоюють через те, що хтось відклав півгодинну задачу бо зараз затіяв рефакторинг. і хтось, хто буде пів дня вислуховувати інвесторів і не пускати їх напряму дьоргати девів, хто буде наочно їм показувати, нахрена ми вбили 2 тижні на автоматизацію і рефакторинг а по фічах все виглядає ще гірше, ніж було, а треба ще знайти двох девів і юіксера бо загинаємось.

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

коли пишеш код, займатись банальною комунікацією нереально, вникати одночасно і в бізнес і в деталі коду — дуже важко. а бізнес теж бачить проект по-своєму, і в нього є свої вимоги, незначущі для девів, і він дивиться на деякі девівські задачі як на нецінні для нього. і між ними обов’язково треба поставити перекладача, при чому який є авторитетом для обох сторін.

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

і ще приклад чому тімліди не можуть замінити менеджера: пишу тз аутсорсеру для експорта-імпорта в редакторі, стараюсь писати термінами, які вжиті в коді і моделі даних, прив’язуючись поки виключно до того, що реалізовано на сервері і клієнті, що нам потрібно для альфи. в розмову включаю геймдиза, який цією функцією буде користуватись (і він же лід всіх артовиків). з ним все теж проговорювала багато. здавалось би, для чого тут манагер, якщо от є досвідчений лід артовиків з глибоким розумінням всього проекту (це все — його задумка), і він же і буде користуватись цією функцією. а ні, він прочитав все по-своєму і накатав 2 сторінки поправок і повторів з загального тз проекту, бо не переключився на те,що це зараз тільки опис вікна експорту а не всієї структури редактора. ще добру годину вбила на те, щоб пояснити одному, щоб той не дуже звертав уваги на лист, але у вільний час почитав — бо класно розписано загальне тз. другому — що загальне тз ми розуміємо, пояснила, що таке експорт і пару прикладів, як хто покроково буде ним користуватись.

ще одна деталь — «національна особливість» слов’янських кодерів. і це я бачу вже з-за кордону, а не просто з чужих слів. тут взагалі мало хто вміє мислити бізнес вимогами, наші кодери часто люблять замість перепитати — зафігачити щось по-своєму, заглибитись далеко в технічну чистоту і красу рішення чи вигадування свого велосипеда, замість швидко зробити дрібничку, яка дуже критична для бізнесу. ще часто вірять в роботодавця як в санта-клауса, який просто не хоче побільше зарплати витягти з бездонного мішка — прямої залежності доходів компанії від результату своєї роботи не бачать в упор. тому в пост-срср дуже добре працює модель іноземний замовник-менеджер-команда, перевірено з обох сторін.

я не відстоюю однозначно позицію менеджера, я бачила і команди, які складались зі самодостатніх девів і успішно здавали проекти, і працюючий скрам. але і бачила, як піеми брали на себе важкий вогонь директорських інтриг, командами джуніорів здавали непрості проекти, як розвалювалась команда серйозних девів з повністю бездіяльним менеджером (призначений помилково з тестерів), як некомунікативний але технічно підкований піем теж привів до закриття проекту, як тімліди, перегружені і кодінгом і відповідальністю за результат (а без повноважень і важелів менеджера) вигорали і валили проекти. а от вже як іпали мені мозги замовники на пряму — наїлась далі не хочу. не всі девелопери в нас готові до роботи без менеджера, і не всі директори вміють правильно підібрати тімлідів, які б були більше організаторами, ніж талановитими кодерами. хоча з менеджером, до речі, така ж проблема.

зараз сама думаю, сунутись мені далі в менеджери, чи триматись девелопмента, і не впевнена, що добре справляюсь з цією роллю. але я просто бачу дофіга координаційної роботи, яку просто беру і роблю — і в результаті проект просувається, директори не дьоргають розробників, всі знають що і як робити. а значить ця роль в даному місці з даною командою потрібна.

Как pm, присоединяюсь к мысли, что проектные менеджеры не нужны:
— для небольших, сильных, кросс-функциональных команд;
— при работе над продуктом, либо с бизнесом, который умеет формулировать свои требования, нанял бизнес-аналитика и заинтересован в результатах проекта;
— при наличии тимлида с хорошими скиллами фасилитатора, и фасилитатора суперуровня, к примеру, руководителя группы разработки;
— при наличии артдиректора (либо очень хорошего дизайнера со скиллами фасилитации, опять же), если в продукте важен ui, который будет сводить воедино работу дизайнеров
— при очень хорошей и тщательной организации инфраструктуры, где каждый человек на своем месте и предельно профессионален.

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

Если в такую команду привели бестолкового менеджера с туманным должностными инструкциями, боритесь с этой тиранией. Поймите, зачем начальству нужен этот бесполезный человек, и почему оно не получает достаточно обратной связи от вас, что приняло решение о его найме. Докажите, что вы делаете это куда лучше и прекрасно справляетесь без pm-a (абсолютно без сарказма, мое искренне мнение, что pm как минимум ничего не привнесет в такую команду, если не навредит).

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

В аутсорсе же, зачастую, команда, в которой есть тимлид и аналитик — несбыточная мечта. Команда, в которой хотя бы один разработчик выше уровня mid’а — это очень и очень классно. И в условиях слабой или неопытной команды, которую удалось надергать на рынке , бизнесом принимается решение — нанять одного человека (стоящего в денежном выражении копейки по сравнению с профессиональной командой, в которой будет тимлид, аналитик, сильный qa и пара senior разработчиков).

Это, на самом деле, очень болезненное решение:) Человеку, которого наняли на такую должность, совсем несладко, и он слабо осознает, что теперь он и шнец, и жнец, и на дуде игрец — причем зачастую без нужных для этого навыков.
В плохом случае и при совсем грустной команде pm превращается в того самого ленивого подбрасывателя монеток и жалкого функционера. Тут все понятно, случай можно закрывать со штампом «вон из профессии».
В неплохом случае pm через полгода, может в проекте баг пофиксить, автоматизацию тестирования для приложения написал, стулья новые выбил для команды, режет макеты и верстает xml-ки, организовал для команды обучение и поездки на конференции.

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

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

В моем случае, в большой продуктовой компании, где малейшее движение в одном сервисе вызывает волну изменений в других, а у проекта может быть очень много stakeholder’ов (которые что-то хотят от проекта, но при этом не являются его product owner’ом), проектный менеджер (такой уж тайтл, хотя суть работы где-то между бизнес-анализом) нужен для минимума действий, которые опробованы на себе и отвергнуты руководством разработки:)

А именно:
— вынимать из головы продуктового менеджера гениальные идеи и планы, и вместе с UX-инженерами, превращать их спецификацию и дизайны, по которым можно стартовать разработку архитектуры ровно в день их получения.
— убирать блокеры и камни с пути команды (для решения среднего вопроса нужно вовлекаться в общение в среднем с 3-5 людьми/отделами, займись этим тимлид и он не сможет заниматься своими должностными обязанностями).
— сдерживать напор stakeholder’ов — людей, которые на благо сервиса хотят прикрутить к нему миллион бантиков, анализируя, приоритезируя и формируя человеческие требования к этим бантикам.
— держать в курсе прогресса проекта верховное руководство — и делается это на основе тесного взаимодействия с тимлидами. Если бы высшим руководителям пришлось общаться со всеми тимлидами (их число может достигать 20 человек в одной группе) и сводить их планы воедино, было бы очень напряжно по сравнению с общением с 4 менеджерами, которые все принесли в диаграммках Ганта и по скрам-досочка разложенное:).

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

P.S. Баснословные зарплаты pm’ов — хорошо разрекламированный миф:)

P.P.S. Дико прошу прощения за простыню, наболело после чтения комментариев как в защиту, так и в порицание роли pm-a.

А зачем оркестру дирижёр? Ведь скрам шагает по планете... У музыкантов что, нот нету? Договориться не могут?

А взять вас на работу кто решил? С кем вы зарплату и условия обсудили? Кто обосновал, что ваш проект вообще нужно делать и [о Боже!] тратить деньги на вашу зарплату? Кто расписал цели, бюджет, и финансовую отдачу — бухгалтер, программисты?

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

Можу сказати на своєму досвіді, що потрібні 100%.
Мабуть прийде з віком розуміння, що менеджер, це добрий товариш для програміста.

Роботу програміста можливо розбити на приблизні складові.
1. humanity skill
2. technical skill
3. team skill

Зверну увагу на 1 пункт. Навичка ведення переговорів з замовником, планування, ведення проекту, підрахунок потрібних ресурсів (не одні програмісти і їх печеньки) і доведення це до замовника.
Всі ці складові потребують навичок і досвіду. Програмісти, часто мають непогані навички по 2-ому і 3-му пункту, але 1 пункт може сильно хромати по здається, коли маєш інші то цей не такий важливий.

Насправді 1 пункт дуже важливий і він забирає дуже багато часу. Ось тут виходить на сцену PM. Він забирає на себе вcі труднощі 1 пункту і захищає команду від зовнішнього тиску.

В наших реаліях в 70% невдалого досвіду, ми говоримо, не про те що поганий менеджер, а про менеджера, як випадкову людину з вулиці, яка не розуміє, що таке PM.
По-суті про професійну некомпетентність.

Взагалі некомпетентність в нашій сфері і наглість плюс молода енергія, яка присутня породжує химеру виключності професії і її елітарності і ще якоїсь херні, але це просто
ремесло, як наприклад гончарство

А кого, собственно, обсуждаем?

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

Если мы обсуждаем сущность типа «средний ПМ в украинском аутсорсе», у которого ни реальных бизнес-целей проекта, ни бюджета от бизнес-спонсоров, ни реальной ответственности (кроме маржинальности и аттришена для менеджмента аутсорс-компании), то это, как бы, совсем другое.

С одной стороны, по проектной схеме (managed services или, тем более, solutions delivery) работает меньшинство аутсорсеров. В основном, это обычный T&M-ный staff augmentation, в котором нужен не менеджер (т.к. он сидит со стороны заказчика), а продвинутый секретарь в галстучке и с надутыми щечками, строчащий целыми днями отчеты и инвойсы, и дерущийся с другими секретарями за ценные ресурсы, подлежащие перепродаже (e.g. Sr. Java Dev).

Другое дело, если аутсорсятся более высокоуровневые активности, чем просто написание кода и прогон тест-кейсов (i.e. бизнес-анализ, управлением рисками, change management и т.д.) — менеджер проекта напрямую ими может не заниматься, но должен организовать такую структуру проектной команды, при которой эти активности выполняются эффективно и, в итоге, решают поставленные бизнес-цели.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Менеджеры, менеджерами, а я вот смотрю что бывает так, что и тим лиды «не нужны».

Необходимость менеджера напрямую зависит от заказчика.
Если у вас нет заказчика (свой продукт или стартап) и хорошая, «сыгранная» команда то менеджер может быть и не нужен.
Или же если хороший менеджер уже есть на стороне заказчика или у заказчика уже есть налаженный агильный процесс.
Но хороших заказчиков очень мало. А вот неудобных — масса. Многие ничего не соображают в ИТ, а некоторые «динозавры» даже Интернет только краем глаза видели. При этом у одного заказчика может быть куча тупых боссов, которые враждуют между собой и тянут проект в разные стороны. Другие просто напишут «хотелку» из 2 страниц, установят дедлайн и тупо уйдут в игнор на полгода. После релиза вылезут и скажут что все сделали не так. Понятие Product Owner и что это про них понимают единицы заказчиков. Третьи заводят по 2-3 системы для тасков (например Jira + Trello + TFS) и генерируют сотни реквестов в день на переделки, изменения, улучшения. Четвертые хотят 20 прототипов и вариантов дизайна на выбор и выбирают до самого релиза. Естественно, заплатить поменьше хотят все. Поэтому в зависимости от контракта или каждый день идет торговля за каждый час или часть работы тупо делается «за свой счет» (иногда в овертаймы). И все очень любят отчеты. Отчеты за каждый час, за каждый стори поинт, графики с постоянно возрастающим велосити, бодрые отчеты что «все успеваем» даже если вчера впихнули еще больше функционала. Разговор про риски заказчики не любят. Любые проблемы — это не его проблемы. Кто-то ушел в отпуск, заболел, уволился — пусть остальные за него пашут. Хреновый код рушится от любого изменения — так мне его писали такие-же бараны, как вы, только из Индии. Не работает что-то в 6 IE — так вы же специалисты, придумайте как сделать.
Поэтому цените своего менеджера — вы даже не представляете от какого потока Г он вас защищает. Бюрократия, политика, интриги, шантаж, жлобство, самодурство, упрямство, тупой идиотизм. Это его работа — фильтровать этот поток и выбирать в нем крупицы смысла, которые можно дать девелоперам на реализацию. И это менеджер «выгрызает» с заказчика деньги на вашу зарплату.

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

и 6 ие пофиксит
и сколько боли было в этих словах!

Я как только стал менеджером на ДОУ, сразу же выбросил IE6-код.

Поэтому цените своего менеджера — вы даже не представляете от какого потока Г он вас защищает. Бюрократия, политика, интриги, шантаж, жлобство, самодурство, упрямство, тупой идиотизм. Это его работа — фильтровать этот поток и выбирать в нем крупицы смысла, которые можно дать девелоперам на реализацию. И это менеджер «выгрызает» с заказчика деньги на вашу зарплату.
Отлично написано! Рядовой разработчик и близко представить себе не может, какой поток Г каждый день разгребает менеджер! Сам это понял, только когда поработал менеджером.

Да, есть люди склонные к разгребанию потоков гавна, но есть и такие кто его старается избегать.

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

Спеки пишет бизнес аналитик, а «репорты и т.д.» это хз.

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

Я не совсем понял, у тебя в конторе нету бизнес аналитика, поэтому прогеры пишут спеки, как именно в этой ситуации поможет появление менеджера?

1) большая просьба мне не тыкать 2) бизнес аналитика нету, спеки пишу либо я, либо проджект менеджер.

1) большая просьба мне не тыкать
А в чем проблема с тыканием?
бизнес аналитика нету, спеки пишу либо я, либо проджект менеджер.
Писать спеки это такая же нефункция проджект менеджера как и твоя

ок, кто пишет спеки в вашей обители?

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

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

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

А в чем проблема с тыканием?
мы с вами на брудершафт не пили :)

не оспаривая никаких набросов тезисов

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

из скрамов серебрянные пули лепить
из *oвна пули — никудышные.

Вот кстати товарищи из stripe пришли к тому же:


We found that combining project management and engineering into a role held by one person cuts down on a lot of communication overhead. It’s always the case that the person who understands exactly what we’re trying to build is someone who also understands all of the technical details of how exactly it’s built.

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

так что без них никак!

P.s. уважайте своих коллег!

Я сначала думал что у Автора нет четкого представления об основных задачах ПМ, его ответственности, его специфике работы, и его toolbox-е и пытался разложить это по полкам как умею. Но кажется что проблема в другом (просто есть негативный опыт работы с ПМ).

ИТОГО по ПМ:
1) ПМ нужны на определенных типах проектов (об этом много здесь говорили)
2) ПМ нужны если персонала в проекте слишком много, в качестве координатора взаимодействия рабочих групп
3) ПМ нужны при недостаточной мотивированности персонала
4) ПМ нужен, как инициатор повышения организационной эффективности (это все орг. технологии , такие же как Scrum или ... Он просто их применяет)
________________________
5) Во многих аутсорсинговых проектах ПМ не нужен. А так же:
Anna Mininkova
>... МП-ы не нужны:
> — для небольших, сильных, кросс-функциональных команд;
> — при работе над продуктом, либо с бизнесом, который умеет формулировать свои требования, нанял бизнес-аналитика и заинтересован в результатах проекта;
(в данном случае ПМ на стороне Бизнеса)

> — при наличии тимлида с хорошими скиллами фасилитатора, и фасилитатора суперуровня, к примеру, руководителя группы разработки;
(ТЛ все равно не может управлять больше чем 8-10-12 человек)

> — при наличии артдиректора (либо очень хорошего дизайнера со скиллами фасилитации, опять же), если в продукте важен ui, который будет сводить воедино работу дизайнеров
(специфический проект)

> — при очень хорошей и тщательной организации инфраструктуры, где каждый человек на своем месте и предельно профессионален.
> (ПМ настроил работу организации и ушел)
> Все это должно сойтись в одно время и в одном месте. Это вовсе не несбыточная мечта и многие продуктовые компании это успешно доказывают.
(Да. ПМ (по теории) — это носитель цели и координатор усилий по движению к цели. В продуктовом проекте носителем цели является БА или Вся команда понимает куда движемся)

Если Вы и дальше не видите ценность ПМ-а, то Ваш проект не соот. типа. или руководство компании его наняло для п. 2 — п. 4.

В подтверждение вышесказанного см.
jobs.dou.ua/...campaign=jooble
Требования к позиции дадут четкое представление о сути работы.

Необходимые навыки

• English level — advanced or fluent
• Experience with western clients in offshore model more than 5 years.
• Optional. Finance responsibility for the project results.
• Contract negotiation and estimation skills.

Работа с клиентом. Требуются навыки переговорщика и управление контрактом (задача взять с клиента больше, так чтобы том при этом был максимально доволен процессом)

• Excellent knowledge of software project management, Agile is preferable.
• Experience with management of several projects in parallel.
• Management of the team 20-100 people.
Координация рабочих групп

• Engineering/Technical background, preferable in Java stack
Надо понимать специфику производства.

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

Тимлид и станет менеджером. Уже в команде из 10 чел, у тимлида, задействованного в скраме, не будет времени самому писать код...

Он станет engineering/dev mamager, или архитектом или принципал инженером. Да он будет код поменьше писать, но тогда под сним стоит сделать парочку тимлидов которые будут поинтенсивнее код писать.

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

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

Тимлидство — это уже работа не с кодом, а с людьми. Скрам помогает формализовать процесс, но не превратит людей в роботов (соответственно, большинство проблем, с которыми сталкиваются ПМы останутся).

Та нет, тимлидерство это работа и с людьми и с кодом и с задачами.

Даешь на 1 разработчика — 7 ПМов.(Могут работать посменно).

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

За персональную ответственность за результат. :-)

В SD — ПМ должен нести персональную ответственность за то что результат будет таким, каким он его согласовал с Заказчиком, для этого ему и предоставлено максимум полномочий.

Высокие зарплаты руководителей управляющих людьми обусловлены тем что они несут персональную ответственность за выстроенный ими процесс производства ожидаемого результата.
Та нет, они получают большие ЗП не за пользу(процессы какие то) а за отсутствие урона. Но решение простое — нет людей — нет возможного урона.
При этом один раз отстроенный процесс (или бизнес процесс если хотите) в дальнейшем просто сопровождается и развивается этим менеджером. Говорят что менеджер сидит .на процессе, где по сути своей не работает активно, и лишь контролирует процесс (вмешивается по мере необходимости).
Ты бы поконкретнее — какие такие процессы?
В софтварной области процессы если и нужны, то давно уже выписаны и даже автоматизированы в тулзах.
В SD — ПМ должен нести персональную ответственность за то что результат будет таким, каким он его согласовал с Заказчиком, для этого ему и предоставлено максимум полномочий.
При всей странности роли козла отпущения в проекте, эта роль не должна быть оправданием наличия власти у человека. Еще раз, ПМ в программинге не шарит, он не может определить косячит програмист или задача сложная, как оценить риски от юзания опредленного солюшена, и сроки на его воплощение. Это все эфектицно делает тимлид, и странно наделять полномочиями человека который сбоку.

Читая Ваш коммент понимаю что для Вас проект это последовательное применение определенных инструментов (tools-ов) — чисто техногенный подход, притом весьма циничный.
Чувствуется что нет четкого представления что такое проект и что такое работа с заказчиком.
Чтобы продемонстрировать это см. — www.youtube.com/...h?v=m7hN6mYshD8
(длинный рассказ о проектах по ремонту квартиры, отражающих особенности проектного бизнеса)

Рассмотри ситуацию вот с какого угла: "Заказчик платит за проект — на протяжении всего проекта столько, сколько покрывает лишь половину твоих затрат по проекту.
И только в конце цикла — при достижении согласованного с тобой и им результата — он заплатит все оставшуюся часть контракта для данного этапа
Условия контракта именно таковы — ты несешь свои затраты по проекту, до четкого майлстоуна, где Заказчик тебе их компенсирует и заплатит твой интерес.
Например это случается раз в полгода.
Заказчик не дурак — он не хочет покупать кота в мешке. Он платит за результат.
Он переносит риски нереализации проекта на твою сторону.
При этом , если что-то пойдет не так — Заказчик оставляет за собой право разорвать контракт
и возможно штрафовать тебя (он же упустил прибыль)
Ты ввязываешься в проект — потому что он для тебя выгоден.
Но заработаешь ты, только если закроешь проект так как это согласовано в контракте.
Вот и крутись как можешь..
Нанимай людей на высоко-конкурентном рынке.
Контролируй их.
Ублажай их (если они свалят — будет больно).
Обеспечивай им условия не хуже рыночных.
Планируй проект.
Вешай на них работу, которую они раньше не делали.. Принимай на себя риски за не качественное выполнение этой работы.
Т.е.. думай о своих рисках.

Читая Ваш коммент понимаю что для Вас проект это последовательное применение определенных инструментов (tools-ов) — чисто техногенный подход, притом весьма циничный.
Чувствуется что нет четкого представления что такое проект и что такое работа с заказчиком.
Это конечно железный аргумент, у меня нету представления, но ты, о гуру, снизошел что бы меня осчастливить наличием представления.
Вот и крутись как можешь..
Нанимай людей на высоко-конкурентном рынке.
Контролируй их.
Ублажай их (если они свалят — будет больно).
Обеспечивай им условия не хуже рыночных.
Планируй проект.
Вешай на них работу, которую они раньше не делали.. Принимай на себя риски за не качественное выполнение этой работы.
Т.е.. думай о своих рисках.
Ну так вот контролировать и считать риски, искать шорткаты и много еще чего лучше получается у тимлида.
А ублажением и обеспечением условий не хуже рыночных ПМ обычно не занимается.

Ты ролик досмотри — он в тему..

Нехер мне делать как тратить час своей жизни на достаточно низкокачественный юмор.

Дальнейший диалог не имеет смысла.
Несколько авторов тебе разложили все по полкам. Особенно четко все разложено у Anna Mininkova
Ты просто не желаешь вникать в суть сказанного.
Что можно еще добавить, если ответы были неоднократно на этой странице.
Остается только резюмировать: «Учите мат часть». Возможно пробел в фундаментальных знаниях.

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

Вот здесь вся суть (нужно очень внимательно читать)
Anna Mininkova
... проектные менеджеры не нужны:
— для небольших, сильных, кросс-функциональных команд;
— при работе над продуктом, либо с бизнесом, который умеет формулировать свои требования, нанял бизнес-аналитика и заинтересован в результатах проекта;
— при наличии тимлида с хорошими скиллами фасилитатора, и фасилитатора суперуровня, к примеру, руководителя группы разработки;
— при наличии артдиректора (либо очень хорошего дизайнера со скиллами фасилитации, опять же), если в продукте важен ui, который будет сводить воедино работу дизайнеров
— при очень хорошей и тщательной организации инфраструктуры, где каждый человек на своем месте и предельно профессионален.

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

Во всех остальных случаях нужны

Я с Анной по этому поводу не согласен.
В условиях бардака, когда все врут, отлынивают от работы, ПМ становится еще более беспомощен, т.к. не понимает суть проблем и не знает как их разруливать, т.к. не технарь. А сильный тех/тим лид вполне может вытащить команду, находя узкие места и затыкая их правильными людьми.

Хм........(это эмоции)
Бардак то не в коде..
Он в организации работ.
Бардак всегда в головах«. (По-моему это из Булгакова «Собачье сердце»)
Да.. В этом вся суть.
Задача ПМ — структурировать это бардак, и тогда он перестанет быть бардаком.
Если бардак в коде — это просто не соответствие заявленной квалификации реальной.

>>> В условиях бардака, когда все врут, отлынивают от работы, ПМ становится еще более беспомощен, т.к. не понимает суть проблем и не знает как их разруливать, т.к. не технарь.

если в организации все врут и отлынивают от работы — задача «разруливания» бардака не может решатся ТЕХНИЧЕСКИ никак.

Если ее решать технически — то ОРГАНИЗАЦИЯ ВСЕГДА БУДЕТ ЖИТЬ В СОСТОЯНИИ БАРДАКА И ПОПЫТОК СПРАВИТЬСЯ С НИМ,
Есть массу примеров организация, которые только и живут тем что героически борются со своими проблемами..

Для реального изменения дел нужны чисто ОРГАНИЗАЦИОННЫЕ ИЗМЕНЕНИЯ, а нет РЕШЕНИЕ ТЕХНИЧЕСКИХ ВОПРОСОВ,

А ЭТО ИНЫЕ ОРГ. СТРУКТУРЫ.
МОТИВАЦИЯ
ЛЮДИ
ИХ СТИЛЬ РАБОТЫ
ИХ РЕЗУЛЬТАТИВНОСТЬ

если в организации все врут и отлынивают от работы — задача «разруливания» бардака не может решается ТЕХНИЧЕСКИ никак
Технически не может, но не может также решаться не технарем, т.к. он не разберется кто врет а кто нет, это же относится к оценке квалификации людей и уровня сложности задач. Организационными изменениями просто переставляя людей как шашки на доске делу не поможеш.

Знаете коллега, я в своей жизни работал с разными девелоперами. В подавляющем большинстве — это люди с ощущением некоторой собственной эксклюзивности. Человек ведет себя так — чтобы всегда себя выгоднее продать.
В этом случаем девелопер управляет только своей продажей.
Потом ему менять правила очень сложно.
Это есть результат того что для ТАКОГО наемного специалиста как правило не используют двухуровневую систему мотивации — т.е. зарплата и все. Нет бонусов, премий и т.д.
Т.е. наняли человека на зарплату и платят только ее.
А за поддержание эффективной загруженности девелопера отвечает ПМ, ТЛ, СМ

Вот если бы они мотивировались и от результата — «сделал быстрее, качественнее, эффективнее — получи бонус» — то и было бы больше желания работать не только на себя а на команду, ради более существенного результата.
В этом случае появляется желание быть более продуктивнее и ... СОТРУДНИЧАТЬ СО ВСЕМИ, и с МП в том числе.
Т.е. начинается реальная командная работа.

Сформировать у членов команды желание вести командную работу — это тоже компетенция ПМ-а, и этому специально учат (меня учили. А вот ТЛ — не знаю)..

Теперь о квалификации и компетенциях.
Я вас уверяю, что без должных коммуникативных способностей, знания специфики Заказчика, нельзя пускать просто человека к ЗАКАЗЧИКУ,
РАБОТА С ЗАКАЗЧИКОМ — это очень специфичная работа, которая требует определенной компетенции и квалификации, и чтобы ее результативно осуществлять нужны НАВЫКИ И ОПЫТ.

Потому что нужно разговаривать с Заказчиком языком Заказчика.

Потому что нужно демонстрировать Заказчику и определенный уровень технической компетенции и осуществлять управления этими отношениями (заинтересовывать его в Вас и в работе именно с Вами)
И кучу всякой другой фигни которая вызывает у него нужные ощущения ..
И поверьте — аниматоры здесь не решают ничего.
ПОТОМУ ЧТО
Если Заказчик перестанет Вас уважать — он будет искать возможность Вас обмануть (как минимум заплатить меньше чем собирался)
Аниматоров не уважают — над ними смеются. Они для этого и существуют.
......
Поэтому в правильной команде все ценят высокие навыки и ОПЫТ своих коллег. Потому что успех каждого зависит от результативности его самого и его коллег.

Если вспомнить манифест Аgile, в котором нет ПМ — то ключевым там является высоко мотивированная команда высоко квалифицированных людей.

>>> Ну так вот контролировать и считать риски, искать шорткаты и много еще чего лучше получается у тимлида. А ублажением и обеспечением условий не хуже рыночных ПМ обычно не занимается.
Нет. В этом твоем случае хвост начинает вилять собакой (а не собака хвостом).

В бизнесе — обеспечение удовлетворенности клиента всегда более приоритетно чем реализация еще более элегантного технического решения.
Тимлид отвечает за поставку технического решения (солюшена) прежде всего.
Если решение задачи «обеспечение удовлетворенности клиента» — достачно объемная задача — она должна быть выделена отдельному человеку с более властными полномочиями.
За кем-то же должно быть последнее слово — и оно всегда за тем кто несет ответственность за удовлетворенность клиента.

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

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

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

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

А для этого нужны четкие навыки оценки затрат , сроков, и потребности в ресурсах (людях и их квалификациях и возможности их находить)
Правильно, и ПМ тут не у дел, потому что не шарит в программировании, программистах и их задачах.

Ну если совсем не шарит — до да.. Но можно же не знать язык, но знать что такая функциональность имеет такую-то сложность и в прошлом приблизительно заняла столько времени у таки-то специалистов. Так что чтобы ее реализовать, ... хм. сейчас посмотрю их доступность, накину резервы и ... .. в общем можем сделать не за 3 мес. как вы просите а за 6.. Доступность ресурсов не высока..
Но зато можем еще ... можем взять на реализацию вот эту функциональность.
И стоить она будет столько -то.
При этом, в данном случае, ПМ отвечает за прибыльность клиента и старается ее максимизировать.
Ролик про строителя хоть и нудный но очень яркий (его автор специально сделал таковым, чтобы показать сложности менеджмента проектов. Я другого такого яркого и не знаю)
Взаимодействие с заказчиком по уточнению всех нюансов порой отнимает колоссальное кол-во времени, требует массы коммуникаций как с заказчиком, так и с коммандой проекта, и даже проведение коллективных митингов ..
Я бы ТимЛида освободил бы от большинства этих задач (как и писала об этом Анна) а сфокусировал бы его на управлении производством, потому что здесь ВСЕГДА НЕ ХВАТАЕТ ВРЕМЕНИ.

Но можно же не знать язык, но знать что такая функциональность имеет такую-то сложность и в прошлом приблизительно заняла столько времени у таки-то специалистов.
Ну если у конторки все показывают стабильную производительность, и все задачки однотипные то оценку действительно может делать ПМ, хотя постой, можно вообще уволить ПМ-а и сделать простенькую табличку на эту тему.
потому что здесь ВСЕГДА НЕ ХВАТАЕТ ВРЕМЕНИ.
А ты думаешь если ПМ будет задрачивать всех хотя обьяснений и разжевываний элементарных вещей играя в испорченный телефон то времени резко появится?

Я тут вспомнил еще, что чтобы работа ПМ была эффективной, он должен ввести некие стандарты работы команды и оценки работы команды.
Т.н. НОРМИРОВКУ работ.
Это все делается на основе истории выполнения работ.
Кстати в Agile — это все есть

Хороший ролик! Очень грамотный мужик!
Думаю, что такие менеджеры проектов — большая редкость!

Если отделить мухи от котлет, то вопрос топика можно перефразировать как
=А нафига он нужен — гoвноменеджмент?=
не так-ли?
поскольку с менеджментом вроде-б-то усё очевидно.

Не, наличие суперуспешных контор в которых менеджеров нету как вида(valve) говорит что не очевидно.

наличие суперуспешных контор
типа оракула, майкрософта и пр не наталкивает на сомнения?

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

во-во-во теплее.
т.е. it depends

сильная инженерная вертикаль
это тоже менеджмент.

вот например нашей бандой (пилим интэрэсный жирный душевный стартап) сейчас рулит vice president of engineering. он сразу ведёт и технические вопросы и вопросы выпаса котов (нас).
это капец. как он это выдерживает и когда отдыхает я не представляю.

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

Кілька сотень коментарів проглянув (не всі), а слова ВІДПОВІДАЛЬНІСТЬ не зустрів...
Яка відповідальність це вже інше питання (грошова, робочим місцем, репутаційна...), проте якщо питання Відповідальності за проект буде поставлене — негайно зявляється необхідність саме в Людині (а не ролі) — керівнику.
Якщо хтось каже, що є команда, без керівництва і успішно працює — висновок: низькі проектні ризики, відсутність необхідності з когось запитати і комусь відповідати. Це не є добре і не є погано, це існує, причому часто, в аутсорсі (Де «мозговий» центр на стороні замовника і відповідальність вся також зосереджена там)

Будь-яка групова ризикована робота вимагає наявності командира групи з правом прийняття рішення, і з обов’язком відповідати. Це і є головна роль керівника в моєму розумінні.

Кілька сотень коментарів проглянув (не всі), а слова ВІДПОВІДАЛЬНІСТЬ не зустрів...
большинство комментариев русскоязычные, потому и "ответственность"("отвечающий“, “отвечает”) вместо “відповідальності”

Т.е. программисты вообще никакой ответственности не несут и их никогда вообще не выгоняют?

Кілька сотень коментарів проглянув (не всі), а слова ВІДПОВІДАЛЬНІСТЬ не зустрів...
очень точно подмечено

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

Как pm, присоединяюсь к мысли, что проектные менеджеры не нужны:
— для небольших, сильных, кросс-функциональных команд;
— при работе над продуктом, либо с бизнесом, который умеет формулировать свои требования, нанял бизнес-аналитика и заинтересован в результатах проекта;
— при наличии тимлида с хорошими скиллами фасилитатора, и фасилитатора суперуровня, к примеру, руководителя группы разработки;
— при наличии артдиректора (либо очень хорошего дизайнера со скиллами фасилитации, опять же), если в продукте важен ui, который будет сводить воедино работу дизайнеров
— при очень хорошей и тщательной организации инфраструктуры, где каждый человек на своем месте и предельно профессионален.

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

Если в такую команду привели бестолкового менеджера с туманным должностными инструкциями, боритесь с этой тиранией. Поймите, зачем начальству нужен этот бесполезный человек, и почему оно не получает достаточно обратной связи от вас, что приняло решение о его найме. Докажите, что вы делаете это куда лучше и прекрасно справляетесь без pm-a (абсолютно без сарказма, мое искренне мнение, что pm как минимум ничего не привнесет в такую команду, если не навредит).

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

В аутсорсе же, зачастую, команда, в которой есть тимлид и аналитик — несбыточная мечта. Команда, в которой хотя бы один разработчик выше уровня mid’а — это очень и очень классно. И в условиях слабой или неопытной команды, которую удалось надергать на рынке , бизнесом принимается решение — нанять одного человека (стоящего в денежном выражении копейки по сравнению с профессиональной командой, в которой будет тимлид, аналитик, сильный qa и пара senior разработчиков).

Это, на самом деле, очень болезненное решение:) Человеку, которого наняли на такую должность, совсем несладко, и он слабо осознает, что теперь он и шнец, и жнец, и на дуде игрец — причем зачастую без нужных для этого навыков.
В плохом случае и при совсем грустной команде pm превращается в того самого ленивого подбрасывателя монеток и жалкого функционера. Тут все понятно, случай можно закрывать со штампом «вон из профессии».
В неплохом случае pm через полгода, может в проекте баг пофиксить, автоматизацию тестирования для приложения написал, стулья новые выбил для команды, режет макеты и верстает xml-ки, организовал для команды обучение и поездки на конференции.

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

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

В моем случае, в большой продуктовой компании, где малейшее движение в одном сервисе вызывает волну изменений в других, а у проекта может быть очень много stakeholder’ов (которые что-то хотят от проекта, но при этом не являются его product owner’ом), проектный менеджер (такой уж тайтл, хотя суть работы где-то между бизнес-анализом) нужен для минимума действий, которые опробованы на себе и отвергнуты руководством разработки:)

А именно:
— вынимать из головы продуктового менеджера гениальные идеи и планы, и вместе с UX-инженерами, превращать их спецификацию и дизайны, по которым можно стартовать разработку архитектуры ровно в день их получения.
— убирать блокеры и камни с пути команды (для решения среднего вопроса нужно вовлекаться в общение в среднем с 3-5 людьми/отделами, займись этим тимлид и он не сможет заниматься своими должностными обязанностями).
— сдерживать напор stakeholder’ов — людей, которые на благо сервиса хотят прикрутить к нему миллион бантиков, анализируя, приоритезируя и формируя человеческие требования к этим бантикам.
— держать в курсе прогресса проекта верховное руководство — и делается это на основе тесного взаимодействия с тимлидами. Если бы высшим руководителям пришлось общаться со всеми тимлидами (их число может достигать 20 человек в одной группе) и сводить их планы воедино, было бы очень напряжно по сравнению с общением с 4 менеджерами, которые все принесли в диаграммках Ганта и по скрам-досочка разложенное:).

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

P.S. Баснословные зарплаты pm’ов — хорошо разрекламированный миф:)

P.P.S. Дико прошу прощения за простыню, наболело после чтения комментариев как в защиту, так и в порицание роли pm-a.

В аутсорсе же, зачастую, команда, в которой есть тимлид и аналитик — несбыточная мечта. Команда, в которой хотя бы один разработчик выше уровня mid’а — это очень и очень классно. И в условиях слабой или неопытной команды, которую удалось надергать на рынке , бизнесом принимается решение — нанять одного человека (стоящего в денежном выражении копейки по сравнению с профессиональной командой, в которой будет тимлид, аналитик, сильный qa и пара senior разработчиков).
А в аутсорсе нельзя держать расшаренный пул хороших QA, бизнес аналистов, админов и т.д.?
Тогда бы отпала необходимость нанимать какого то человека который будет делать всю эту работу не обладая навыками при этом.

Вам приходилось работать в украинском аутсорсе:)? В большинстве случаев нельзя — это нерентабельно.

Грубая арифметика:
pm — 1500 $
2 джуниора — 1200 $ * 2
мид, который тянет весь проект — 2000 $
джуниор qa — 600 $ :)

Итого: 6400 $ только зп. А еще эти люди сидят в офисе, едят печеньки, работают за Apple Cinema дисплеями и хотят ездить на конференции, ах да — еще налоги. Суммарные затраты в месяц даже на такую команду могут легко составить 10 000 $. То есть бизнесу остается 14 000 $.

На проекте такая команда наработает за месяц порядка 800 часов. По рейту 30 $ (а такой просят средние аутсорсеры) получаем 24 000 $.
vs
аналитик — 2000 $
2 senior разработчика 3000 $ *2
тимлид — 3500 $
толковый qa — 1500 $

Итого 13000 $ (в 2 раза дороже предыдущей команды). Ну и там налоги, печеньки — бизнесу остается совсем мало денег по сравнению с первым вариантом. А ведь эти люди несут все риски и напряги, связанные с ведением бизнеса и возможными неприятностиями на проекте, и они по праву хотят получать за него хорошее вознаграждение.

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

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

Цель — действительно продавать часы и зарабатывать на этом деньги. Неужели где-то в аутсорсе может быть другая цель? Слабые команды тоже зачастую делают жизнеспособные проекты — потому что их скорость закладывается в оценочную стоимость проекта для заказчика.

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

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

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

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

И вторую команду нужно а) нанять, б) в принципе изначально вложить в нее большие деньги — на это идет далеко не каждый владелец бизнеса.
Причем тут владелец бизнеса, это задача аутсорсера держать пул таких людей и продавать их заказчику.
у и насчет легкости найма хороших разработчиков в принципе — у нас некоторые вакансии не закрываются по полгода — год, не можем найти людей нужной квалификации.
Попробуйте поднять ЗП на 50% ))

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

Этот вопрос нужно предметно обсуждать, только видя цифры можно понять «cильно выше рыночного» или нет, достаточна прибавка что бы срулить с насиженного места или нет. Про яндекс как раз противоположные слухи циркулируют.

Давай возьмем не Яндекс, а проект Х, в котором мне довелось работать на стороне, и в котором разглашение уровня зарплат не карается:). Проект искал iOS-тимлида в дополнение к сильной команде из 3 senior разработчиков. Ничего феерического в требованиях к этому человеку, кроме плотного знания obj-с и плюсов (стандартное требование в гейм-проекте), умения ужиться с дизайн-командой, желания координировать работу других людей и общей адекватности, не требовалось. Работодатель был готов платить за эти умения от 4000 до 6000 $ (больше года назад и не в столице). К этому прилагались всякие стандартные плюшки типа страховок, бесплатных обедов, няшного офиса и свободного рабочего графика. Ну и проект сам по себе был хороший.
Увы, такая зп почему-то не притягивала магнитом фантастических специалистов — даже при хорошей рекламе на профильных мероприятиях, и хорошей репутации компании. Хедхантинг тех людей, с которыми хотелось работать руководству и команде тоже особо ничего не дал — несмотря на то, что предложение по зп было иногда в 2 раза больше текущей зп кандидатов. Только спустя год ребята нашли крутейшего indie-девелопера, которому надоело работать самому, и которому приглянулся их проект. Еще раз повторюсь — высокая зп не может мгновенно увеличить на рынке количество людей, которые умеют создавать изящные архитектурные решения/рисовать превосходные дизайны/делать другую полезную и высококлассную работу.

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

ты чего-то не договариваешь
r_h ты лучше не тыкай, а шапочку из фольги сними перед автором сих комментов ))
нечасто сюда нынче ходят высказаться с таким знанием дела и от души.

О Нетроли подтянулись.
Ты правда считаешь что поднятие зп на 100% никак не влияет на шансы захайрить программиста?

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

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

Анна, спасибо!
Вы-шикарны!(:

вынимать из головы продуктового менеджера гениальные идеи и планы, и вместе с UX-инженерами, превращать их спецификацию и дизайны, по которым можно стартовать разработку архитектуры ровно в день их получения.
А как именно ПМ учавствует в процессе вынимания?
— убирать блокеры и камни с пути команды (для решения среднего вопроса нужно вовлекаться в общение в среднем с 3-5 людьми/отделами, займись этим тимлид и он не сможет заниматься своими должностными обязанностями).
Опять же, убирать блокеры поручают человеку без экспертизы. Т.е. он может эфективно устранить блокер только в крайнем случае когда кто-то нескрыто и нагло ленится, в противном случае(если блокеры это сложные технические проблемы, или кто-то вешает лапшу науши) блокеры должен убирать человек понимающий их суть, т.е. технарь или бизнес аналист, а не абстрактный менеджер.
сдерживать напор stakeholder’ов — людей, которые на благо сервиса хотят прикрутить к нему миллион бантиков, анализируя, приоритезируя и формируя человеческие требования к этим бантикам.
Это тоже задача не ПиЭм-а а продакт оунера/менеджера, это его работа выдумывать/собирать фичи и приоретизировать их беклог.
держать в курсе прогресса проекта верховное руководство — и делается это на основе тесного взаимодействия с тимлидами. Если бы высшим руководителям пришлось общаться со всеми тимлидами (их число может достигать 20 человек в одной группе) и сводить их планы воедино, было бы очень напряжно по сравнению с общением с 4 менеджерами, которые все принесли в диаграммках Ганта и по скрам-досочка разложенное:).
Эта задача очевидно автоматизируется, если в системе заведены тикеты по всем таскам с депенденсями и дедлайнами, то никакого менеджера не нужно, все видно на скрине в браузере, кто справляется а кто не успевает.

Не буду спорить, потому что мне вряд ли удастся изменить ваше представление о проектном менеджере, как о центре некомпетенции проекта, а также сломиь «четкое понимание» задач продакт менеджера в чужой компании и его разделения обязанностей с проектным менеджером:)
Аааа, про автоматизацию отчетности ужасно насмешило — посмотрите, как выглядит автоматизированная отчетность по проекту на 100 — 300 человек, к примеру в Microsoft Project’e (ну или во всяких приблудах для Jira — там все еще симпатичнее). Все вопросы про то, как все видно на скрине в браузере, и какие депенденси лежат между тикетами, сразу рассосутся:)

Не буду спорить, потому что мне вряд ли удастся изменить ваше представление о проектном менеджере, как о центре некомпетенции проекта, а также сломиь «четкое понимание» задач продакт менеджера в чужой компании и его разделения обязанностей с проектным менеджером:)
При чем здесь спорить. Я призываю к конструктивному обмену аргументами как отличному источнику новых идей, а выводы уже пусть каждый сам себе делает.
Аааа, про автоматизацию отчетности ужасно насмешило — посмотрите, как выглядит автоматизированная отчетность по проекту на 100 — 300 человек, к примеру в Microsoft Project’e (ну или во всяких приблудах для Jira — там все еще симпатичнее). Все вопросы про то, как все видно на скрине в браузере, и какие депенденси лежат между тикетами, сразу рассосутся:)
Закажите мне правильный тул, и я вам сэкономлю много миллионов на ЗП бездельников ))
Это тоже самое что сделал ОЛАП, раньше в компаниях было куча бюрократии, псевдоаналитиков, и т.д. а потом народ начал строить центральные data warehouse со всеми метриками, и ЦЕО компании на 100 тыс человек десятью drill-down-ами теперь может посмотреть куда уходят деньги, и кого нужно соптимизировать.
Здесь точно такая же ситуация, задача легко автоматизируется.

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

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

Если серьезно, то насчет экономии на зп бездельников вы очень неправы — зарплаты бездельников даже на протяжении 10 лет к ряду не составят сотой доли стоимости разработки своей olap-based системы аналитики. Btw, Microsoft и Oracle как раз вендоры таких систем, вам приходилось работать с чем-то из них? Если нет, то смотрите предыдущий пример с MS Project’ом.

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

Конструктивный обмен аргументами — это когда каждый участник обмена с легкостью относится к своей позиции и не связан NDA в отношении ряда своих аргументов (в духе разделения обязанностей и характера возникающих блокеров).
Не, ну если тебе НДА запрещает высказывать мысли по делу, то дискуссия конечно же застопорится.
ы, без обид, спорите так, как будто какой-то проектный менеджер убил и прислал вам в почте кусочками любимую болонку:)
Здесь место такое, иначе заклюют.
Я, вот, не призываю покарать и выгнать из профессии всех разработчиков без серьезной математической базы — хотя почти все, кто мне встречался без нее — были, скажем так, на любителя:) Это просто мой опыт и ничего больше, хотя я могу привести массу аргументов в защиту того, что разработчик должен быть великолепно подкован в высшей математике.
Если ты уверена в своей точке зрения, я не вижу абсолютно ничего плохого в высказывании идей которые могут сильно подвинуть мир в лучшую сторону. Кто-то прочитает, задумается, и может даже сделает какой то правильный шаг.
Если серьезно, то насчет экономии на зп бездельников вы очень неправы — зарплаты бездельников даже на протяжении 10 лет к ряду не составят сотой доли стоимости разработки своей olap-based системы аналитики.
Та нет, очень небольшая команда талантливых инженеров способна построить такую систему. Ну и ЗП это очень небольшая часть потерь. Основная соль в эфектовности принятия решений, и такие системы поднимают ее на сильно более высокий уровень. Там где раньше решения принимались в слепую, сейчас это зрячий процесс.
Btw, Microsoft и Oracle как раз вендоры таких систем, вам приходилось работать с чем-то из них?
Я не работал с каким нибудь peoplesoft или navision если ты об этом, но я учавствовал в разработке двух таких систем from scratch используя инструментарий oracle и ms.
И в итоге в письмах клиенту не делает орфографических и пунктуационных ошибок, без всякого спеллчекера определяя, как пишется, к примеру, слово «бессмысленный»:)
Когда я пишу клиенту, мне не впадлу запустить спелчекер ))
Если ты уверена в своей точке зрения, я не вижу абсолютно ничего плохого в высказывании идей которые могут сильно подвинуть мир в лучшую сторону. Кто-то прочитает, задумается, и может даже сделает какой то правильный шаг.

Для того, чтобы быть уверенной в своей точке зрения, нужно иметь не только собственные умозрительные заключения на этот счет. Мой опыт не ограничивает меня в суждениях — то, что я не видела слонопотама, не значит, что его не существует. Мне, честно, почти не приходилось сталкиваться с плохими pm-ами близко по работе. Но я знаю, что они есть:)

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

В продуктовой среде, напротив, pm нужен только в редких случаях и при специфическом устройстве компании и разделении обязанностей с другими ролям (продакт, бизнес-аналитик).

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

Для того, чтобы быть уверенной в своей точке зрения, нужно иметь не только собственные умозрительные заключения на этот счет. Мой опыт не ограничивает меня в суждениях — то, что я не видела слонопотама, не значит, что его не существует. Мне, честно, почти не приходилось сталкиваться с плохими pm-ами близко по работе. Но я знаю, что они есть:)
Плохие/неплохие ПиЭм-ы это отдельная тема для обсуждения. Здесь топик — нужны ли ПиЭм-ы вообще, не является ли их функция избыточной.
Реалии аутсорс разработки сейчас таковы — огромному количеству команд и заказчиков нужен проектный менеджер.
А может не нужны, а это самовнушение? Здесь же не раз мелькали аргументы вроде, ну у всех есть значит нужно.
но категоричный тон споров зачастую заставляет людей становиться в оборонительную позицию, а не впадать в рефлексию на тему «Возможно, мне стоит заняться чем-то другим, моя деятельность лишена смысла».
Во первых мой тон здесь не более(если не менее) категоричен чем тон других людей.
Во вторых, так это же замечательно, когда продуктивные идеи доходят только до эмоционально уравновешенных людей, которые способны переступить через снобизм «тон не тот», отсеять шелуху склок и гордыни и прийти к светлой мысли чистого разума. Нужно именно таких людей, и компании где такие люди преобладают делать более конкурентными, а более отсталые существа пусть опускаются в свою эволюционную нишу.

Че-то я не понимаю о чем дискуссия у Вас
Успешны проект — это много много выполненной работы различного профиля, в том числе:
аналитической
девелоперской
административной (планирование, контроль и т.д)
коммуникативной
др.
При средне-низком уровне зрелости команды, и квалификации участников проекта административно-коммуникативную работу должен кто-то выполнять — здесь возникает выделенная роль ПМ.
Наличие на проекте персоны — это задача планирования распределения работ по проекту.
Ведь одна персона может выступать в различных ролях, главное чтобы работа персоны оплачивалась адекватно квалификации и результату.
Т.о. ПМ может быть как выделен на проект целиком (если на проекте для него есть достаточный объем работ), так и играть на нескольких проектах, выполняя специфичную ему работу.
Когда уровень зрелости команды растет — задачи ПМ могут брать на себя другие участники проекта.
Вопрос — нужен ли сегодня ПМ на проекте лежит в плоскости: оценки квалификация и эффективности других стейкхолдеров проекта. Если без ПМ они в состоянии двигать проект — ПМ не нужен (но об этом должен знать не только ПМ а и овнер).
С ростом компетенции заказчика, и ростом зрелости проектной команды функцию ПМ может брать на себя команда.

Так а почему таки функции которые приписывают ПМу не может выполнять тим лид или другие люди(БА к примеру). Зачем доверять власть человеку который должен делать все нипонятно как и не так что бы разбирается в тех. особенностях проекта и имеет меньше возможностей принимать правильные решения. Какие именно функции ты предлагаешь навесить на ПМ(т.к. консенсуса в этом топике у моих опонентов не наблюдается).

В данном случае ПМ — должен быть интегратором (сложное слово, смысл которого в синтезе единого результата проекта опираясь на результаты специалистов членом команды)
ПМ несет Персональную ответственность за успешность проекта,
для этого ему и дают полномочия.
ПМ может не быть экспертом в определенных тех. областях, но он должен быть в состоянии организовать создания экспертного заключения опираясь на доступные ему ресурсы.
ПМ — это всегда Риск-менеджер
Если на проекте есть риск-менеджер — это просто помощник ПМ.
>>> Какие именно функции ты предлагаешь навесить на ПМ

Итак 3 ключевые функции ПМ — суть которых обеспечение персональной ответственности за проект:
1) координатор процесса производства
2) риск-менеджер
3) коммуникатор (обеспечивает движение информации среди всех стейкхолдеров проекта)

Если эти три функции возьмет на себя кто-то из членов команды (они не разрывны, поскольку не могут существовать друг без друга) — то он фактически и станет ПМ данного проекта (поскольку на нем в таком случае и будет персональная ответственность за проект.)
Хотя логически надо поменять причину и следствие..
Сначала речь идет об ответственности за проект, которая берется на себя членом команды, а это за собой несет осуществление этих 3-х функций.

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

Цели менеджера проекта — часто не только закончить успешно проект а и создать и развить в организации промышленный процесс-производства
см. ru.wikipedia.org/..._Maturity_Model
Для этого и существуют процессы.
Что же касается митингов и спитчей, см. дальше
Мотивация людей с точки зрения теоретиком менеджмента никогда не определяется их личным доходом, а зависит совершенно от других элементов, таких как:
социальный статус и его рост
условия труда (комфортность офиса и т.д.)
ваши желаемые коммуникации
и т.д.
Зарплата с точки зрения теоретиков менеджмента — это лишь компенсация за труд и квалификацию (в крупных компаниях менеджеры по зарплате назыв. менеджерами по компенсациям и льготам)
Зарплата никогда не служит мотивацией к действию

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

Да, где-то среди этих трех спрятан Change-Management

о, свежая кровь!)
отлично написано, так держать!

просьба вынести этот текст в раздел «колумнисты». чтоб он не затырился в куче срача.

Все зависит от размера проекта.

Для команды до 8 человек и простого проекта может тимлида и достаточно. Хотя даже в данной ситуации тимлиду будет достаточно сложно одновременно управлять командой, общаться с клиентами и искать новые возможности на рынке — нужен Product Manager, человек, который невсегда обременен глубокими техническими знаниями, но прекрасно знающий предметную область, рынок и цену работы инженеров. Я уже молчу о ситуациях, когда проект включает в себя работу нескольких таких команд, кто из тимлидов будет главным? А если никто из них не соображает в делах других команд (одни рисуют GUI, другие пишут драйвера, третьи — прошивку для процессоров на микросхемы, третьи — саму микросхему)? Кто будет координировать работу таких команд, анализировать возможность реализации тех или иных требований полученных от Product Manager и передавать ему сведения о степени готовности проекта? Кажется, его зовут Project Manager.

нужен Product Manager, человек, который невсегда обременен глубокими техническими знаниями, но прекрасно знающий предметную область, рынок и цену работы инженеров
Да, проджект менеджер, это такой тимлид у БА, и он имеет прекрассно очерченную область экспертизы в отличие от абстрактных менеджеров.
Я уже молчу о ситуациях, когда проект включает в себя работу нескольких таких команд, кто из тимлидов будет главным? А если никто из них не соображает в делах других команд (одни рисуют GUI, другие пишут драйвера, третьи — прошивку для процессоров на микросхемы, третьи — саму микросхему)? Кто будет координировать работу таких команд, анализировать возможность реализации тех или иных требований полученных от Product Manager и передавать ему сведения о степени готовности проекта? Кажется, его зовут Project Manager.
А тебе не кажется что если среди тимлидов есть какие то непонятки по нетривиальным вопросам которые они не могут решить, то как то глупо выглядит отдавать главенству человеку совершенно без экспертизы? Не логичнее ли что бы последнее слово было за каким то техническим челов? Архитектором/ЦТО/principal developer-ом?
А тебе не кажется что если среди тимлидов есть какие то непонятки по нетривиальным вопросам которые они не могут решить, то как то глупо выглядит отдавать главенству человеку совершенно без экспертизы? Не логичнее ли что бы последнее слово было за каким то техническим челов? Архитектором/ЦТО/principal developer-ом?
Отвечу за человека, которому этот вопрос адресовался — нет, не кажется. Как раз в плоскости чисто технических вопросов тимлиды должны сами разрулить неровности, не ввязывая управленческий ресурс. Задача ПМа принимать решение там, где проблема выходит за плоскость чисто техническую и как раз уже технари не имеют компетенции ее решать. Это касается ситуаций, когда то или иное решение будет удовлетворять Заказчика не полностью по скоупу, срокам или бюджету (треугольник прожект менеджмента, нутыпонел). Доверять такого рода вопросы человеку техническому, да еще и не участвующему в проекте — это смерть, ни архитектор, ни принципал девелопер (шо за зверь, кстате?) скорее всего не смогут принять решение беспристрастно. Про ЦТО вообще смешно. Ведь твои основные наезды на ПМа сводятся, как я понял, к тому, что он, во-первых, не имеет технических скиллов, во-вторых его хрен выловишь, так как он занят на тонне проектов. А ты не думал о том, что у ЦТО технический скилл будет еще меньше, так как его путь от девелопера начался намного раньше и педалить он, скорее всего, перестал еще раньше? И если у ПМа будет до 5 проектов, то у ЦТО будут все проекты в конторе. Его намного легче будет поймать? Кроме того, его же должность (принимать технические решения по всем проектам в конторе, грубо говоря) его будет обязывать знать наизусть все паттерны и авторитетно всем навязывать свою точку зрения, которая будет оторвана от реальности по всем пунктам — требований бизнеса он не понимает, т.к. в проекте не участвует, от тонкостей архитектуры он давно отошел. Так что ПМ, ИМХО, тут как раз то, что надо...
Это касается ситуаций, когда то или иное решение будет удовлетворять Заказчика не полностью по скоупу, срокам или бюджету (треугольник прожект менеджмента, нутыпонел).
В таких ситуациях решение принимает заказчик, как существо ужинающее и танцующее девушку, а совсем не ПМ, ПМ выступает просто передатчиком информации сомнительной нужности от тимлида к заказчику.
ты не думал о том, что у ЦТО технический скилл будет еще меньше, так как его путь от девелопера начался намного раньше и педалить он, скорее всего, перестал еще раньше?
Та нет, нормальные ЦТО полностью вовлечены в разработку и даже представь себе код пишут.

Увидел подпись у знакомого PM, которая немного проливает свет на нашу дискуссию:
«Если бардак нельзя остановить, то его нужно возглавить!» — в этот момент создается экземпляр менеджера.

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

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

спасибо, человеки
не планировал выяснять, но, читая комменты, основательно утряс для себя этот момент.
тезис 1. Менеджер проекта — не более, чем роль. Следовательно, выделять ли отдельного человека под эту роль или разбросать обязанности между остальными членами команды — всего лишь вопрос целесообразности.
так же, как, скажем, БА на маленьком внутреннем проекте просто ни к чем, что не отменяет необходимости выяснять детали и где-то их документировать. или выделенный тестер. или еще куча вариантов. как-то раньше не думал про команду с точки зрения «любая позиция — это роль». теперь
тезис 2. обязанности этой роли:
— управление коммуникациями
— принятие решений в патовых ситуациях(третейский судья в спорах, скажем, техлида и ЮА дизайнера)
— комуникация с клиентом
— управление ресурсами(приоритезация)
-------------------
т.о. вопрос ТС сводится «а нужен ли выделенный человек на данную роль или лучше разбросать обязанности между остальными?». абстрактный вопрос об абстрактной команде, которая работает над сферическим проектом в вакууме.

ну в целом правильно, да... вот, получается, что ТС считает, что ПМ как выделенный человек не нужен, а роль ПМа надо разбросать на всех, кто рядом... больше всего в его исполнении достается тим лиду... а интересно ли тим лиду руками водить и умеет ли он это делать — видимо, «проблемы индейцев шерифа не волнуют»

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

80% ПМ дев команд в Украине выросли из программистов, в чем отсутствие знаний?

Откуда инфа про 80%? Ну и я уже написал, технические навыки быстро теряются, где то за два года приходят в состояние негоднодти, зато дают ПМу повод думать что он еще на коне и напрягать программеров своими идиoтскими идеями.

Да не нужно ПМу быть в тренде самых последних технологий и знать, какие новые хелперы появились в ASP.NET MVC 4 по сравнению с MVC 3. У меня на .NET проектах были и ПМы из сишников, и из тестировщиков, и их знаний хватало и на то, чтоб команду менеджить, да еще и какие то несложные вещи самим делать в случае необходимости. С девочками с инъяза, слава Богу, работать не приходилось и зачастую такие ПМы действительно не нужны. А тебе, видимо, просто не повезло, т.к. тебе попадались исключительно ПМы без технического бекграунда.

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

Навык чего? Педалинга? Не нужен он ему для его задач. Опять же, сваливая задачи ПМа на техлида, ты также лишаешь его навыка педалинга. Ведь ему кроме того, чтоб архитектуру придумывать, надо еще и планированием заниматься, и конфликты приоритетов разруливать, и еще и с Заказчиком коммуницировать. И в чем разница будет, по-твоему?

Навык чего? Педалинга?
нет, не педалинга, а во многих других аспектах, вроде эстимейта тасков и сложности задач, оценки рисков при выборе того или друго-го решения, оценки рисков связанных с плохим состоянием кода и инфраструктуры, понимание продакшн проблем, понимание как правильно выстроить инфраструктуру для девелоперов, и кучу других вещей можно придумать.
пять же, сваливая задачи ПМа на техлида, ты также лишаешь его навыка педалинга.
Отчасти да, тимлид не должен педалить столько сколько простые тиммемберы, но посколько он вовлечен в принятие всех важных решений, ему нужно во всем разобраться и все понимать, то этот навык у него отлично поддерживается.
ланированием заниматься, и конфликты приоритетов разруливать, и еще и с Заказчиком коммуницировать
Это опять нагнетание драмы вокруг простых вещей не отнимающих много времени и/или не относящихся к менеджменту
нет, не педалинга, а во многих других аспектах, вроде эстимейта тасков и сложности задач, оценки рисков при выборе того или друго-го решения, оценки рисков связанных с плохим состоянием кода и инфраструктуры, понимание продакшн проблем, понимание как правильно выстроить инфраструктуру для девелоперов, и кучу других вещей можно придумать.
вот почти везде, где я был, с этим ПМы справлялись, изредка привлекая техлидов/синьоров, при этом все равно экономя тучу времени тех. спецам.
но посколько он вовлечен в принятие всех важных решений, ему нужно во всем разобраться и все понимать, то этот навык у него отлично поддерживается.
если ПМ делает это же изо дня в день, почему у него не будет этот скилл работать?
Это опять нагнетание драмы вокруг простых вещей не отнимающих много времени и/или не относящихся к менеджменту
ну вот капец, после таких заявлений вообще непонятно как с тобой дискутировать. «Простые вещи», «мало времени», «не относятся к менеджменту»... Не люблю аргументы в духе «сперва добейся», но тут похоже только это и остается. Насчет сложности я в принципе могу согласиться, обычно это несложно, да, но вот времени это может занимать ТУЧУ. А переключаться после этого на технические задачи, а потом снова на организационные и назад — это вообще капец, я такого врагу не пожелаю (говорю не голословно, потому как сам с таким сталкивался).
вот почти везде, где я был, с этим ПМы справлялись, <b>изредка</b> привлекая техлидов/синьоров, при этом все равно экономя тучу времени тех. спецам.
Здесь соль в слове «справлялись», для меня очевидно что тим лид справится лучше по описанным мной причинам, ПМ справится хуже и создаст оверхед команде, команда путем дополнительного труда конечно потом его вытянет, но ПМ зато всем говорит что он справился.
если ПМ делает это же изо дня в день, почему у него не будет этот скилл работать?
Это то о чем я говорю, из-за недостатка собственной функции ПМ-ы забирают работу у других специалистов не являясь экспертами в этой работе. У тебя ПМ принимает решение по всем тех вопросам, где какой фреймворк юзать, как лучше прорефакторить код, и какой аппсервер лучше юзать в продакшне?
Насчет сложности я в принципе могу согласиться, обычно это несложно, да, но вот времени это может занимать ТУЧУ.
Это все занимает кучу времени если в конторке нету хорошей культуры автоматизации таких задач, т.е. она остается в каменном веке. В настоящее время всякие тулы, энтерпрайз-вики, правильные багтрекеры и т.д. сильно снижают затраты на то что раньше делали менеджеры.
У тебя ПМ принимает решение по всем тех вопросам, где какой фреймворк юзать, как лучше прорефакторить код, и какой аппсервер лучше юзать в продакшне?
И да и нет. Если речь идет просто о том, чтобы скачать и заюзать какую то фришную либу — естественно, тут ПМ не нужен. К примеру, ПМ может либо выдолбить из заказчика лицензию на какую то тулзу, которая поможет сэкономить время команде и избавит от необходимости подставляния костылей, либо распишет ему все дроубэки использования бесплатной/более дешевой либы, чтобы в случае чего к команде не было претензий.
В настоящее время всякие тулы, энтерпрайз-вики, правильные багтрекеры и т.д. сильно снижают затраты на то что раньше делали менеджеры.
Я бы сказал, эти тулы просто немного облегчают ПМу работу. Если бы речь шла о том, что просто экспортнуть список тасков из джиры в эксель и кинуть заказчику — естественно ПМ не был бы нужен. Но это далеко не все.
либо распишет ему все дроубэки использования бесплатной/более дешевой либы
Опять же, технарь их распишет в 5 раз лучше.
просто экспортнуть список тасков из джиры в эксель и кинуть заказчику
Ну если у тебя фантазия в аспекте автоматизации дальше экспорта тасков из жири переступить не способна, то ничего конечно не поделаешь.
Опять же, технарь их распишет в 5 раз лучше.
технарь прям таки горит желанием этим заниматься вместо того, чтобы заниматься архитектурой и прочими техническими тасками
Ну если у тебя фантазия в аспекте автоматизации дальше экспорта тасков из жири переступить не способна, то ничего конечно не поделаешь.
А тебе дискутировать и при этом не переходить на личности образование не позволяет? Я прекрасно знаю про приоритеты, статусы и прочие прелести в джире... но никакой самый умный и прекрасный продукт не даст тебе ответ какой таск делать раньше — тот что нужен бизнесу «прямо вот вчера» или тот, без которого команда не сможет нормально выполнять все остальные свои таски (при этом бизнесу этот таск не нужен вообще). Отвечаю сразу на твой следующий вопрос — да, ПМ такое решение не примет сам, но он будет обсуждать это с заказчиком и доказывать почему тот или иной таск надо сделать раньше чем тот, который очень хотят юзеры. Все техлиды, которых я видел (которые действительно хотели расти и работать как тех. спецы) рано или поздно задалбываются участвовать в подобных заседаниях, которые могут продолжаться по несколько часов в день.
технарь прям таки горит желанием этим заниматься вместо того, чтобы заниматься архитектурой и прочими техническими тасками
А еу все равно прийдется, менеджер будет же к нему бегать с вопросами и непонятками.
А тебе дискутировать и при этом не переходить на личности образование не позволяет?
А тебе?
Перечитай свои коменты. И надеюсь мой эпитет тебя отрезвит, и ты больше не будешь пускаться в столь уж несуразные утрирования.
Я прекрасно знаю про приоритеты, статусы и прочие прелести в джире...
Понятно что кроме приоритетов и статусов есть и другие способы автоматизации, некоторые я тут уже описал.
Отвечаю сразу на твой следующий вопрос — да, ПМ такое решение не примет сам, но он будет обсуждать это с заказчиком и доказывать почему тот или иной таск надо сделать раньше чем тот, который очень хотят юзеры.
Его доказывание будет заключатся в том что он будет носится между тимлидом и заказчиком и пересказывать их слова друг-другу. Есть конечно вариант что он будет лапшу на уши заказчику вешать, но имхо это еще хуже.
Все техлиды, которых я видел (которые действительно хотели расти и работать как тех. спецы) рано или поздно задалбываются участвовать в подобных заседаниях, которые могут продолжаться по несколько часов в день.
Это такие техлиды были. Они может и на работу ходить задалбывались в результате. На моей практике такие заседания на пару часов не так что бы часты, с другой стороны тоже люди у которых забот хватает.

таку книгу (Эдвард Йордан — Смертельный Марш ), очевидно, ти не читав.

A good manager can make things marginally better, a bad one can really screw things up
The Times podcast

btw, AngelList работает без менеджеров. Но во-первых их там семеро (не считаю тех, кто deal flow занимается), а во-вторых там top .01% рынка труда.

Может быть разгадка в том, что менеджеры это информационные хабы?

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

Количество связей между нодами растет экспоненциально. Т.е. по мере роста команды эффективность коммуникаций между ее членами падает очень быстро. Тут и выходят на сцену мендежеры, которые «агрегируют» эти потоки информации и делают возможным дальнейший рост компании (команды).
А почему нельзя все таки напрямую общатся?
Вот есть конторка, в ней куча отделов, мне что-то нужно от какого то отдела, в чем конкретно проблема найти кого то из адресной книги и написать письмо? Или отослать в мейлинг лист, или наэсайнить тикет на проект в багтрекере? Зачем нужны какие то роутеры которые искажают информацию, частенько ленивы и склочны да еще и зп большую хотят.
Во всех областях где есть роутеры их пытаются автоматизировать, чем эта плоха?

Ну тут можна аналогию с спд отделом провести. Мол нафига нужен спд отдел, в чем проблема самому поехать в налоговою «порешать» ?

тут аналогию можно провести с местами где все налоги платятся через интернет за 20 мин без спд отделов и поездок куда либо

про отчеты и прочие прелести ты намеренно забыл?

А что отчеты и прочие прелести?

Написать не проблема. Хоть в мейл лист хоть в трекер. Просто по мере роста участников «переписки» ее количество растет по экспоненте и нужная информация начинает теряться в общем «шуме».

// это я так думаю, в больших проектах лично не работал. у тебя большой проект?

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

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

Разработчикам осталось только кодить, тестировщикам тестить, интеграторам — интегрировать.

ПМ(-мы) на данном проекте молодец(-ы) :)В данном случае это говорит лишь о том, что ПМ (ПМ-ами) были качественно проведены предпроектные работы, грамотно спланирован проект,

Ага, без божественного прикосновения ПМ-ов ну никак. Это уже религия какая то.
Та нет, такая картина результат грамотной архитектуры продукта, ПМ-ы тут не причем.

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

100 девелоперов были в одной команде? или в 10-15? если последнее, то вероятно в каждой из этих команд был менеджер? или как?

если последнее, то вероятно в каждой из этих команд был менеджер? или как?
тим лид

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

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

Мне проще договариватся с одним, платить одному, принимать отчеты от одного, дать доступ одному, и если какие-то бока требовать с одного, корректировка планов с одним.

Поэтому на моем проекте есть ПМ/тех.лид. Который какие-то работы выполняет сам, на какие-то привлекает специалистов. И мне абсолютно фиолетово, кого сколько кого и когда он привлекает. Для меня как для заказчика важно:
— выполнение работ в срок.
— качественное выполнение.
— устраивающая меня стоимость.

Для выпонения всех этих задач, нужны разные специалисты.
Ну так вот в типичном современном программистском проекте, особенно том который отдают на украинский аутсорс нету никаких разных спецов, инфраструктура унифицирована, все разговаривают приблизительно на одном языке, вроде java/spring/oracle, не нужно ни с кем договариваться, все знают свое дело, а кодящий тимлид вполне способен ответить на все вопросы.

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

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

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

Во первых, просьба не «тыкать», я с Вами не «кореша».
По ряду причин я здесь со всеми на ты, ничего менять не собираюсь, ничего личного.
Во вторых, если вы программиста считаете «пупом земли», Ваше право. Собственно фанатичным товарищам нет смысла ничего доказывать, просто потому что ими легко управлять :)
Ок, т.е. аргументы в стиле «организовывать деплоймент в прод» закончились?

А смысл спорить и доказывать человеку, который дальше тех.лида не видит. Кодит на аутсорсинговом проекте, где(про разжеванные спецификации уже писал)?

Ты еще забыл сообщить мне новость что мне 23 года.

ну если действительно 23 года....то со «студенческим» максимализмом тем более не имеет смысла спорить

Ок, а как на счет крови христианских младенцев?

Вот есть конторка, в ней куча отделов, мне что-то нужно от какого то отдела, в чем конкретно проблема найти кого то из адресной книги и написать письмо? Или отослать в мейлинг лист, или наэсайнить тикет на проект в багтрекере?
Ну вот взгляни на ситуацию немного шире. В конторе куча отделов,в каждом отделе куча народу. Каждому человеку из каждого отдела в любой момент времени может понадобиться что-то от другого отдела, каждый сел и написал письмо и/или настрочил тикет с High priority. Как разруливать? Как решать конфликты приоритетов? Для каждого человека его тикет, скорее всего, самый важный. Должны быть какие то «роутеры», которые будут принимать решение о том, что делать в первую очередь, а что потом. И не помогут тут техлиды, потому что они все равно видят ситуацию под ограниченным углом только своей компетенции.

Обычно в конторках где есть приоритеты на тикеты есть четкая политика как эти приоритеты определять, типа если это какой то баг который афектит ревенью, то это П0, если еще не афектит но может то П1, если просто доставляет неудобство и снижает продуктивность то это П2, если не снижает а что-то что просто нужно сделать то это П3, и т.д.

BTW, не экспоненциально. O(N²) или N×(N-1) / 2, если быть точным
но то буквоедство, с сутью согласен полностью

в качестве оффтопа можно припомнить почему у нас практически повсеместно принят фуллтайм — т.е.
while(true) {40 жoпочасов в неделю}
менеджеров жаба давит, ибо иначе ускользает смысл их кормления.

Кстати, да. Если брать на работу менеджеров по девелоперским скиллам, то так оно и получается, что

они перенимали функции individual contributors, кто-то тестил сам и ругал программеров за баги, кто-то писал доки

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

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

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

Да, да, чем меньше менеджер знает о разработке, тем он лучше! И вообще, чем меньше он знает, тем лучше.

лучше кому? если менеджер ничего не знает, то да, он не нужен

не во всех компаниях есть возможности расти в архитектуру, кроме того, не везде есть места для архитекторов, а менеджирующие ТЛ или ПМ нужны. И да, это не огромный город, где легко уйти в другую фирму

если только этот человек не индус или пакистанец. У тех быть менеджером — самое сокровенное желание :)

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

у меня на проектах монстры разработчики получали и получают больше... Но меня это абсолютно не парило, просто потому в области разработки они круче чем я. Более того разработчиком перехотелось быть года 4-е назад. Поэтому свое java разработку забросил и стал ПМ-ом :)

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

Конечно не нужны. И QA не нужны. И админы не нужны. И HR не нужны. Девелоперы всё сами будут делать, если «грамотно и с умом применять». Это доказано грамотными и умными компаниями вроде Google, Facebook, Microsoft. Хотя нет, подождите...

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

скрам шагает по планете

Этот ужасный идол забирает больше времени чем менеджеры. Причем мало кто не фокусируется на хорошей стороне — personal communication, team responsibility, crossfunctional team. Тысячи бы графиков начертить, 500 терминов новых придумать, тянуть карты и мячики бросать.

Но т все таки согласен, что если идеи грамотно и с умом применять, то менеджеры не нужны?

Я могу согласиться что dedicated managers могут быть и не нужны если команда не большая и инициативная. Если команда вместо работы лучше бы по сайтикам полазила, то дядька с кнутом «you, back to work» может понадобиться

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

А кто будет в бане с заказчиками уничтожать себе печень?

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

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

И как часто ПиЭмы сидят с серьезными лицами с заказчиками на митингах?
То ли дело девушка с красивой грудью, ей заказчики всегда рады, и сразу ясно зачем она.

Менеджеры абсолютно не нужны.

Лучше всех это сформулировал Давид Хейнемейер Ханссон:

There’s no room in a new small company for an idea guy. You have to do stuff. You have to have utility value. You have to be able to build stuff, design stuff, market stuff, something that has direct value to the business, not just idea. And that’s where I see a lot of this actually go wrong because people think they can get along just being idea guys or just being management.

There’s no management when we’re three people. There’s no management when we’re 15 people. We still don’t have any managers hired in 37signals. Every single one of us are producers. I’m still a producer. I still write code. Jason still designs. We still do all the stuff and management is sort of the offshoot of, “Oh, yeah. Sometimes we have to deal with issues that they come up.”

Problem is when you have actual managers, whose sole job it is just to manage, they make up [stuff] to manage because you’ve got to fill an eight-hour day. And in the beginning, there’s 40 minutes of management every three days. That’s what you need for management. You do not need eight hours of management, which is how you get policies and all this other bull that crops up when people don’t have anything to do.

Idle managers are absolutely the worst.

So, how do you make company decisions if there are no managers, or is it totally collaborative, or does one person just say, “Hey, we need to do this” and runs with it or? What’s the process? Oftentimes, somebody brings up a good idea and we say, “That sounds good. Let’s do that.”

Полное видео лекции: ecorner.stanford.edu/...o.html?mid=2351

We still don’t have any managers hired in 37signals.
может, они там все понемногу бла-бла менеджеры.

Есть возражения по сути текста или просто опять захотелось поумничать?

Вы хотите, чтобы я что-то доказывал человеку, который выдал фразу

Менеджеры абсолютно не нужны.
?
Почитайте ниже dou.ua/...ic/6953/#288942, я лучше не выскажусь.

В мене є запитання. у Вас чи в Вашій компанії менеджери є ? Хто Ваш босс ?

В группе, в которой я работаю, нет.

Начальник групи хто ? Група в який структурний підрозділ входить ? Хто його керівник ? Хто бігбос фірми ? І навіщо він, якщо він фізично роботи сам не робить ніякої ?
Чогось так життя влаштоване, що потрібні керівники, координатори, тобто менеджери. Часто, якщо підрозділ невеличкий, цими справами займається один з робочих, але це не означає, що в команді немає менеджерів. Просто посади суміщені.

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

В течение трех лет я работал тим лидом команды разработки в Киеве и мог бы без проблем наслаждаться ролью «менеджера». Дурное дело не хитрое. Но только в ущерб продукту. Поэтому моя работа по существу не особо отличалась от работы других членов команды — проектирование и написание кода.

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

ПМ для команды и особенно ТЛ сложного проекта, как продюссер для певца/артиста, вроде и не нужен и деньги забирает, а без него тебе и проекта не особо дадут, и «слоников» раздавать будут жестко, и требовать невозможное.

обычный ПМ в случае скрама может управлять 3-4 или больше ТЛями, выполняя где-то роль скрам-мастера самому, где-то просто проверяя все ли нормально, участвуя в переписке, если надо, и защищая команды от излишних нападок. В случае аутсорса ПМ нужен координировать работу и том числе и сейзлов, и админов, и QA команды, и вообще координировать работу нескольких команд и ТЛдов между собой, поскольку, вроде как они все взрослые, опытные и адекватные люди, и ПМ им не нужны, но согласовать порядок фич, интеграцию, даты деплоймента, и протоколы часто не умеют и вместо договариваться лишь обвиняют друг друга.

Заказчику в случае большого проекта с несколькими командами (например, классическими клиент, сервер, QA) сложно общаться с ними и проще общаться с одним человеком и он даже готов платит и билить ПМ позицию.

Руководителю/директору проще обсуждать промоушены, зарплаты, и успехи с проблемами с одним человеком, а не 3-4 тимлидами, которые очень часто думают, что раз есть вилка зарплат придумана лишь, чтобы экономить и надо давать всей команде максимальные зп сразу. Не изучая менеджемент, они не понимают, что они разрушают рынок, и такое поведение смотивировав команду на полгода, приведет к росту распальцованных 23 синьоров с мегазарплатами, с чувством ЧСВ под облака и не желающих больше работать.

Не изучая менеджемент, они не понимают, что они разрушают рынок
Лол просто лол.
«Не изучая небо, они не понимают, что они разрушают Вселенную»
но согласовать порядок фич, интеграцию, даты деплоймента, и протоколы часто не умеют и вместо договариваться лишь обвиняют друг друга.
Так в том то и фишка, что пиэм как человек не технический, не может адекватно оценить как нужно правильно, и фактически его решение — это подбрасывание монетки, или подыгртвание человеку с которым он пиво пьет.
Руководителю/директору проще обсуждать промоушены, зарплаты, и успехи с проблемами с одним человеком, а не 3-4 тимлидами, которые очень часто думают, что раз есть вилка зарплат придумана лишь, чтобы экономить и надо давать всей команде максимальные зп сразу.
Что за чушь, никто кроме тимлида не может лучше оценить перформенс человека, нет никакой проблемы обсудить промоушны с тремя людьми по очереди вместо одного который не в курсе, считать иначе — элементарное самодурство

для початку, як тут і написали, давайте визначимось, хто є хто. і опишемо не «я бачив 20 хєрових менеджерів тому роль менеджера — не потрібна» а саму роль. і давайте писати не про абстрактних класних програмістів, які і глибокотехнічні і в бізнес вимогах шарять, щей в потрібній кількості водяться і в одному офісі, і не про розумних багатих замовників. а про те, що на практиці.

менеджер — в першу чергу посередині між бізнесом (замовниками, інвесторами) і командою. в другу — комунікатор між членами команди, координатор — якщо вони а) в різних сферах/технологіях б) в різних офісах/компаніях/країнах. в третю — до певної міри відповідає за прийняті рішення і результат в цілому, якщо підлеглий все зробив так, як манагер сказав — брати на себе всі удари зовні.

комунікація — це прийняти всю переписку замовника, періодично відсіювати всі його бурхливі фантазії, спускати на команду в більш технічному вигляді і з чіткою розстановкою пріоритетів. перевіряти, чи всі розуміють, що мають робити, що пріоритетніше, що кого блокує, чи всі правильно зрозуміли, що мають зробити. не допускати тиску на девів з боку замовника чи керівництва, провіряти всі естімейти і множити на коефіцієнти.

тімліди — відповідають за рішення в своїх технологіях/підкомандах, частково зайняті кодінгом (дизайном/тестингом). в нюанси інших технологій, сфер і бізнес вимог можуть не вникати.

так, скрам це все може реалізувати. але, до речі, там є скрам менеджер. і замовника ще треба привчити не лізти в команду, а якщо він буйно активний — когось йому підсунути. а буйно (саме буйно, буває і просто бурхливо) активними може бути і власне керівництво. і скрам теж має хтось впроваджувати, моніторити ретроспективи і вирішувати проблеми, приймати рішення, коли щось перестало працювати. ато начитається якийсь власник автомеханічного бізнесу, що в айті можна рубати бабло, можна просто зібрати девів, зааплаїти скрам — і збирай баблос, назбирає джуніорів і майстрів-піздєтєлєй, і потім тільки розгрібай авгієві конюшні, а цей директор щей скаже всі монітори розвернути так, щоб він бачив, хто чим займається.

і не забуваємо — що ідеальних умов, замовників, девелоперів, тестерів і артовиків не буває. директорів і сейлсів — теж. бувають різної довбанутості і жмотності замовники зі своїм баченням бізнесу і навіть своїми 19річними розробниками, і пачки джуніорів, і розподілені команди, і проекти, початі в минулому столітті зі сотнями тисяч користувачів і тисячними збитками за годинний простій системи. і національні особливості що замовників, що розробників. бувають геніальні деви з нульовою комунікативністю чи хорошим заглибленням в деталі але поганим баченням інших потреб в іншій технології, поганим розумінням бізнесу. і різні підходи управління компанією керівництвом, і різний вплив на керівництво сейлів. можна 100500 раз кричати, що і як має бути, а можна брати що є і намагатись поставити процес під існуючі умови так, щоб все запрацювало.

в мене був досвід роботи напряму на замовницю без менеджера. мені просто іпали моск майже цілодобово. вона клепала баги, третина яких була або фічами або дублікатами або суперечили одне одному. вона кожному говорила щось своє, і якби ми не проговорювали це між собою, навалили б дров. я свої і іноді серверника баги щодня проходила і в мене зі 40 лишалось 25 на одного, це займало годину-півтори. були ще члени команди на її стороні, які тупо фіксили що бачили не звіряючись з багами у всій системі. все проговорювання віднімало дуже багато часу. проговорювання того ж з її девами викликало повне нерозуміння чого я лізу і командую, а вони тупо ламали зроблене. вона не давала нам зробити хоч щось, що не є фічею — навіть якщо це компонента, якою можна буде покрити половину фіч. на проекті код серверників не був включений в систему версій. взвалити всю цю комунікацію на тімлідів? нас всього було на нашій стороні 2 флешера, 1 пхп-іст, половина тестера, і ми не були авторитетом для неї. і навіть якщо припустити, що команди були б великі і на нашій стороні. тімліду тестерів вона плете одне, тімліда флешерів грузить новим дизайном, вже промальованим і не узгодженим з девами, тімліда серверників напрягає ще адмінкою і хостингом. характер в неї такий, що не лізти в справи розробників вона не могла — а гроші платить вона. керівництво взагалі в ІТ не рубає, і коли я при наборі нового дева наполягаю на тому кандидаті, якого знаю (бо мідл-сеніор кандидатів нема, а за джунів я буду відповідальна) — мене щей підставляють, що я зі всіх прекрасних кандидатів наполягла саме на цьому. і того 3 працівника сеніор рівня мають вбивати по пів дня на чат з замовницею, розбори міскомунікації директорів і замовниці, проговорення того між собою, бо один менеджер — це пльохо? тімлід серверників може уявлення не мати, що флешери задихаються без юіксера і чітких постановок, тімлід флешерів уявлення може не мати про проблеми масштабування сервера і потреби аналітики і т.п. і при тому їм всім і без комунікації зі замовницею є над чим голову ламати.
можна скільки завгодно говорити про те, як має бути поставлений в процесі скрам, як неправильно в нас взятий, стартанутий і взагалі проект, які деви неправильні — але вищеописані мною замовники існують в природі, платять не малі гроші, і простіше замість думати про сферичний ідеальний проект з ідеальною ж командою і замовником в вакуумі, поставити між командою і замовником хорошого технічного проблем-солвера, який може брати на себе всі удари як керівництва так і замовника і при тому координувати підлеглих.

я взагалі не розумію, як можна кидати на девів напряму замовника, не підстраховуючи манагером. на моїх очах стільки раз ставались різні хитрі наїзди замовників на девів через керівництво, чи провтиків керівництва в фінансових питаннях (до старту проекту чи після його здачі), що я не уявляю, скільки б гівна на девів вилилося, якби не пм-и.

інший приклад: прямо зараз мої директори-інвестори пориваються надавити на дева, який паралельно вчиться на грант в іншій країні — щоб він забив на навчання і кодив інтенсивніше. я їх від цього весь час відгороджую, бо знаю — він там кодить дуже багато, а навчання не кине взагалі. пушити його — просто відволікати, нервувати і він або вигорить або кине нас, а не навчання.

мені зараз якраз і приходиться займатись менеджментом, і не сказала б, що це обов’язки тім ліда. при тому мені ж доводиться кодити, і щоб зробити хоч якийсь кусок роботи — я на день-два йду додому і вирубую роутер. бо щодня дьоргають якраз мене, а не я «заважаю девам» — всі питають як саме буде зроблено та чи інша частина роботи, що саме зараз пріоритетніше, чому саме зараз ми робим якісь речі так. проект складається, дуже грубо кажучи, з 3 серверних підпроектів, 2 клієнтських і 2 редакторських, 2 артових. люди знаходяться в 5 країнах, один кусок роботи робить дев з іншої компанії-аутсорсера. при наявній документації і системах трекінга комунікація займає стільки, що під кінець дня в мене від ведення одночасно по 2-3 скайп-чатів, відбивання листів і моніторингу тікетів голова пухне. якщо на це кидати тімлідів — вони або перестануть бути кодерами і фактично стануть менеджерами, або будуть не до кінця синхронізованими і їх підкоманди видаватимуть не працюючий разом різнобій. при тому ж у нас є тімліди — у дизайнерів, у серверників. люди толкові, дуже толково продумали систему, склали тз, заклали гнучкість, розширюваність і масштабування, зробили свій редактор для гри. але чомусь до моєї появи фічі в грі не прив’язувались до можливості їх задавати в редакторі (а значить нефункціональні взагалі), автоматизація білдів не була першочерговим завданням і не включала в себе окремого сервера для геймдизайнерів, в коді було багато хардкоду, арт неможливо заливати через редактор (тобто без допомоги девів), розробник редактора не розумів пріоритетності задач, ізометрія напряму читає дані з файлів. і про яку частину моделі даних у різних девів я не питала — у кожного було своє розуміння, якщо взагалі було, про юіксера ніхто взагалі не задумувався... має бути хтось, хто знає весь проект — не в деталях, але достатньо глибоко, щоб бути впевненим, що всі рухаються в правильному напрямку і в нас не виникне блокерів чи люди не простоюють через те, що хтось відклав півгодинну задачу бо зараз затіяв рефакторинг. і хтось, хто буде пів дня вислуховувати інвесторів і не пускати їх напряму дьоргати девів, хто буде наочно їм показувати, нахрена ми вбили 2 тижні на автоматизацію і рефакторинг а по фічах все виглядає ще гірше, ніж було, а треба ще знайти двох девів і юіксера бо загинаємось.

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

коли пишеш код, займатись банальною комунікацією нереально, вникати одночасно і в бізнес і в деталі коду — дуже важко. а бізнес теж бачить проект по-своєму, і в нього є свої вимоги, незначущі для девів, і він дивиться на деякі девівські задачі як на нецінні для нього. і між ними обов’язково треба поставити перекладача, при чому який є авторитетом для обох сторін.

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

і ще приклад чому тімліди не можуть замінити менеджера: пишу тз аутсорсеру для експорта-імпорта в редакторі, стараюсь писати термінами, які вжиті в коді і моделі даних, прив’язуючись поки виключно до того, що реалізовано на сервері і клієнті, що нам потрібно для альфи. в розмову включаю геймдиза, який цією функцією буде користуватись (і він же лід всіх артовиків). з ним все теж проговорювала багато. здавалось би, для чого тут манагер, якщо от є досвідчений лід артовиків з глибоким розумінням всього проекту (це все — його задумка), і він же і буде користуватись цією функцією. а ні, він прочитав все по-своєму і накатав 2 сторінки поправок і повторів з загального тз проекту, бо не переключився на те,що це зараз тільки опис вікна експорту а не всієї структури редактора. ще добру годину вбила на те, щоб пояснити одному, щоб той не дуже звертав уваги на лист, але у вільний час почитав — бо класно розписано загальне тз. другому — що загальне тз ми розуміємо, пояснила, що таке експорт і пару прикладів, як хто покроково буде ним користуватись.

ще одна деталь — «національна особливість» слов’янських кодерів. і це я бачу вже з-за кордону, а не просто з чужих слів. тут взагалі мало хто вміє мислити бізнес вимогами, наші кодери часто люблять замість перепитати — зафігачити щось по-своєму, заглибитись далеко в технічну чистоту і красу рішення чи вигадування свого велосипеда, замість швидко зробити дрібничку, яка дуже критична для бізнесу. ще часто вірять в роботодавця як в санта-клауса, який просто не хоче побільше зарплати витягти з бездонного мішка — прямої залежності доходів компанії від результату своєї роботи не бачать в упор. тому в пост-срср дуже добре працює модель іноземний замовник-менеджер-команда, перевірено з обох сторін.

я не відстоюю однозначно позицію менеджера, я бачила і команди, які складались зі самодостатніх девів і успішно здавали проекти, і працюючий скрам. але і бачила, як піеми брали на себе важкий вогонь директорських інтриг, командами джуніорів здавали непрості проекти, як розвалювалась команда серйозних девів з повністю бездіяльним менеджером (призначений помилково з тестерів), як некомунікативний але технічно підкований піем теж привів до закриття проекту, як тімліди, перегружені і кодінгом і відповідальністю за результат (а без повноважень і важелів менеджера) вигорали і валили проекти. а от вже як іпали мені мозги замовники на пряму — наїлась далі не хочу. не всі девелопери в нас готові до роботи без менеджера, і не всі директори вміють правильно підібрати тімлідів, які б були більше організаторами, ніж талановитими кодерами. хоча з менеджером, до речі, така ж проблема.

зараз сама думаю, сунутись мені далі в менеджери, чи триматись девелопмента, і не впевнена, що добре справляюсь з цією роллю. але я просто бачу дофіга координаційної роботи, яку просто беру і роблю — і в результаті проект просувається, директори не дьоргають розробників, всі знають що і як робити. а значить ця роль в даному місці з даною командою потрібна.

Т.е. твой посыл, что ПиЭм-ы это чисто посредники между всеми, но не создают ли они испорченных телефонов? Почему твоим инвесторам не поговорить бы с вашим кодером напрямую? Зачем добавлять latency в процесс? Ты уверена что пересказывая слова кодера ты не вносишь испорченных телефонов.

перечитайте ще раз мій пост.

якщо я не вношу ясніть, а є поломаним телефоном, то чому

бо щодня дьоргають якраз мене, а не я «заважаю девам» — всі питають як саме буде зроблено та чи інша частина роботи, що саме зараз пріоритетніше, чому саме зараз ми робим якісь речі так

і якщо деви нормально можуть між собою і без мене порозумітись, то чому

до моєї появи фічі в грі не прив’язувались до можливості їх задавати в редакторі (а значить нефункціональні взагалі), автоматизація білдів не була першочерговим завданням і не включала в себе окремого сервера для геймдизайнерів, в коді було багато хардкоду, арт неможливо заливати через редактор (тобто без допомоги девів), розробник редактора не розумів пріоритетності задач, ізометрія напряму читає дані з файлів. і про яку частину моделі даних у різних девів я не питала — у кожного було своє розуміння, якщо взагалі було, про юіксера ніхто взагалі не задумувався..

і чому на простий опис наче всім зрозумілої фічі

він прочитав все по-своєму і накатав 2 сторінки поправок і повторів з загального тз проекту, бо не переключився на те,що це зараз тільки опис вікна експорту а не всієї структури редактора.
а після
ще добру годину вбила на те, щоб пояснити одному, щоб той не дуже звертав уваги на лист, але у вільний час почитав — бо класно розписано загальне тз. другому — що загальне тз ми розуміємо, пояснила, що таке експорт і пару прикладів, як хто покроково буде ним користуватись.
ні в кого вже не було проблем, фіча доробляється, від геймдиза пішли адекватні зауваження.

ви взагалі колись в процесі запари кодання з замовниками-інвесторами (не-технарями) спілкувались?

в мене був досвід роботи напряму на замовницю без менеджера. мені просто іпали моск майже цілодобово.

чому моїм інвесторам не поговорити з девом напряму? «слухай, вася, нам пох що ти там виграв грант і безплатно вчишся в одному з найкращих вузів планети, кидай все і кодь на нас денно і ночно!» — ось що скажуть інвестори умовному васі, який і так кодить денно і ночно в перервах між навчанням. а кодер інвестору такий «в мене тут ще айді ентіть треба запилити, а на сервері хардкод був, а потіонси на геймплей не впливали, тому я чекаю коли серверник запушить реордеринг і зробить глобальні ачівменти, які можна буде параметризувати» — і замовник зразу ж все пойме, ага.
а я бачу, що він кодить, що він постійно комунікує з девами на сервері, що інвестор тупо його буде відволікати від роботи і напрягати. ще я знаю, що цей кодер — джун, він ще не вміє нормально естімейтити і не вміє відбиватись від замовників. і дуже буде переживати, коли на нього давлять, і або тупо перегорить або пошле всіх нас нах.

для чого вони взагалі мають з ним говорити? вони знають, що він джун — самі прийняли рішення його наймати. вони знають, що він вчиться, де і на яких умовах. і що ніхто в 21 рік не кине заради якогось стартапа безкоштовне навчання в британії. вони самі приймали рішення починати проект джунами, і знають, які ризики цим заклали. вони зараз просто кіпішують, і намагаються хоч щось зробити з того, що вміють — тупо надавити на розробника. легше від того комусь стане? хтось нову інформацію отримає? хтось кодити почне активніше? — ні, бо вже і так всі на максимумі кодять.

ви з дизайнерами спілкувались колись? в них взагалі своє розуміння світу, їх весь час треба повертати до тз і пояснювати, що замовник заплатив тільки за ці фічі, а те, що вони намалювали — в 10-20 раз більше. дати дизайнеру поспілкуватись напряму зі замовником, щей після підписання договору? — та він розкочегариться на нові ідеї і буде розчарований результатом, за який заплатив, або почне вимагати зробити саме так в межах оплати — проект провалить бюджет. не вислухати дизайнера перед підписанням контракту — пропустити можливість підкинути замовнику класну ідею. не дати программеру оцінити імплементацію намальованого дизайнером — провалити бюджет. дати всім говорити зі всіма і не вести загальний облік — ніхто не буде в результаті нічого знати, всі щось будуть робити, викочувати якісь оцінки, підписувати контракт і кожен буде розуміти щось своє.

я не стаю стіною у спілкуванні. я відкриваю чат чи тікет, додаю в нього всіх зацікавлених і пишу все, що мені прийшло від них всіх окремо — і питаю, ви точно знаєте, що ви маєте зробити цю фічу до завтра хоч якось, бо інакше диз не буде мати що робити ще 2 тижні, серверники точно беруть дані з редактора, а не хардкоду? дизайнери точно малюють анімації для існуючих об’єктів в потрібному розмірі? і т.п. як я можу стати поломаним телефоном, якщо до мене весь час ідуть за інформацією і я тупо копіюю те, що написав мені інший член команди? я стаю стіною там, де інвестор хоче розвинути бурхливу діяльність і де дизайнери починають перевантажувати девів зовсім непотрібною їм інформацією.

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

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

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

і ще приклад чому тімліди не можуть замінити менеджера: пишу тз аутсорсеру для експорта-імпорта в редакторі, стараюсь писати термінами, які вжиті в коді і моделі даних, прив’язуючись поки виключно до того, що реалізовано на сервері і клієнті, що нам потрібно для альфи. в розмову включаю геймдиза, який цією функцією буде користуватись (і він же лід всіх артовиків). з ним все теж проговорювала багато. здавалось би, для чого тут манагер, якщо от є досвідчений лід артовиків з глибоким розумінням всього проекту (це все — його задумка), і він же і буде користуватись цією функцією. а ні, він прочитав все по-своєму і накатав 2 сторінки поправок і повторів з загального тз проекту, бо не переключився на те,що це зараз тільки опис вікна експорту а не всієї структури редактора. ще добру годину вбила на те, щоб пояснити одному, щоб той не дуже звертав уваги на лист, але у вільний час почитав — бо класно розписано загальне тз. другому — що загальне тз ми розуміємо, пояснила, що таке експорт і пару прикладів, як хто покроково буде ним користуватись.
Единственная мысль понятная из этого дампа мозга что лид идиoт, а девушка с непонятным именем на белом коне.

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

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

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

ну вот если бы ты не относился предвзято к людям, не поддерживающим твою точку зрения — можно было бы дискассить, а так... неинтересно в общем...
le-positive.ru/...BXIlGhIvpYw.jpg

А ты даже не допускаешь что это именно у тебя предвзятое отношение к чужой точке зрения + невосприимчивость к чему то отличному от того что папы аутсорсинга напели?

причем тут «папы аутсорсинга» и «напели»? Давай я еще раз повторю, если с первого раза непонятно было: я не исключаю, что бывают ситуации, когда менеджер не нужен (ИМХО такие случаи скорее исключение, чем правило, но все же)... но очень часто (практически всегда) ПМ нужен. Почему — да сколько можно повторять, примеров масса, основная мысль — людей нужно координировать, вести к одной общей цели

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

т.к. он не шарит в программинге
о, опять пошли повальные обобщения.
то есть, ты ни разу не встречал РМ с программистким бекграундом? о_0 че, правда?!

Встречал, но это такое дело которое нужно постоянно шлифовать, через 2 года навыки и понимание теряется.

Полностью согласен.

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

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

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

В остальных случаях это гремучая смесь инженерной несостоятельности и желания быть начальником.

когда вы выростите до ТЛ — вернемся к этому разговору ;)

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

просто должность сейчас у вас указана как Software Engineer в Agnitio A/S, неужели тимлидерство надоело?

Любопытно, откуда берется мнение, что ПМ принимает решение по техническим вопросам? Наоборот, это как раз — епархия архитектора / тех. лида, и ни один ПМ в здравом уме лезть туда не будет.

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

крім скрипок в оркестрі ще є ударні, духові, клавішні, іноді вокал. на скільки я знаю, «в скрипках» більшість диригентів не шарять так, як ти описуєш як піем має шарити в кодінгу.

Они намного лучше шарят чем сантехник.

ну да, пишеш зрозумілі загальні абстракції — звинуватять в тому, що нема конкретики. намагаєшся описати конкретні приклади (ну не можу я, блін, писати всі деталі реального проекту і реальних людей — намагаюсь узагальнювати) — дамп мозга.

я не гуманітарій, гарно розписувати і оформляти свої думки не можу — щей їбошачи по 9-11 годин в день на стартапі.

якщо тобі хочеться ділити світ на біле і чорне — ти і будеш навколо бачити то лідів ідіотів, то імена незрозумілі, то білих коней. а любий опис штатної життєвої ситуації, де ні винних ні неправих не буває — тупий незрозумілий дамп. тільки от називається таке мислення — бінарне, у нормальних людей перестає бути ведучою мозговою діяльністю у віці 4-6 років.

я не гуманітарій, гарно розписувати і оформляти свої думки не можу — щей їбошачи по 9-11 годин в день на стартапі.
Ты тут претендуешь на экспертное мнение в области управления проектами, и не умеешь хорошо расписывать свои мысли. Занавес.

бугага

експертна думка. в коменті на доу. бугага 3 раза.

тавариш, ти перечитай все, що ти тут написав, і все, що я. спокійно, вдумливо і зі сторони, хто тут з нас на що претендує. твої категоричні 80% — непотрібна прослойка, однозначні висновки і т.д. і мої «МОЖЕ вирішити, КРАЩЕ поставити, кожному проекту — СВІЙ комплект» і т.д.

і я тут комент написала, а не колонку — в колонку мене вже витягли адміни сайту бо їм він видався цікавим (і — о диво — зрозумілий). тобто я просто свою думку висловила і своїм досвідом поділилась, а не претендую на якусь там позицію і визнання. все визнання, яке мені потрібно — приходить мені щомісяця на рахунок.

я от, до речі, щойно спеціально порахувала: працюючи на девкомі, логіці, блстрімі, елексі, даксі, когніансі і зараз в ризі, і маючи друзів-однокурсників в софтсерві, епамі, глобалі, циклумі і т.д., я нарахувала мінімум 30 хороших толкових піемів, яких могла б назвати поіменно, а всього разом по відгуках і спостереженнях знаю про мінімум 60-80. при тому хєрових піемів сама бачила раз 3, чула ще 5, і була на проектах, де пездець як треба було піема — сама 2 рази і чула про такі ж ще пару раз. і при тому ніде не верещу, що «80% піемів, яких я зустрічала — хороші, а значить піеми — потрібні, а хто тут висловлює свою думку і описує свій досвід, відмінний від мого — сліпець, придурок, і ващє претендує на компетентність». не повіриш — мені цікаво почитати чийсь досвід і про хєрових піемів і про успішні проекти без піемів. і піемом сама я не хочу бути: в україні це слизька позиція і хз як знайти роботу. за кордоном (де я хочу лишатись якнайдовше) — це взагалі позиція, яка ніяк не зв’язана з девелоперським бекграундом.
я тут просто спокійно ділюсь своїм досвідом і думками. на стільки, на скільки в мене на це є час і дозволяє етика розкривати деталі моїх проектів. а ти тут прям хрестовим походом йдеш на менеджерів, бачиш в чужих постах те, чого нема і замість спокійно описати свої конкретні приклади, кидаєшся якимись категоричними узагальненнями. ти от напиши, на скількох проектах працював, скількох піемів бачив, як вони вели проекти, які були команди і як реагували на дії піема і що, ти вважаєш, було би, якби піема не було. мені буде цікаво почитати. а всякі катигоризми читати... вибачте, в мене тут ще вся рига не сходжена, є чим зайнятись

авариш, ти перечитай все, що ти тут написав, і все, що я. спокійно, вдумливо і зі сторони, хто тут з нас на що претендує. твої категоричні 80% — непотрібна прослойка, однозначні висновки і т.д. і мої “МОЖЕ вирішити, КРАЩЕ поставити, кожному проекту — СВІЙ комплект” і т.д.
Да, я претендую, и поэтому стараюсь выписывать мысли лаконично и понятно. Я так понял ты не претендуешь и твои мысли по поводу можно игнорировать? И ты сама часто используешь слова “возможно”, “лучше”, “свой комплект”?
я нарахувала мінімум 30 хороших толкових піемів, яких могла б назвати поіменно, а всього разом по відгуках і спостереженнях знаю про мінімум 60-80
А с чего ты взяла что они хорошие?

*заговорницьким тоном* мені приснився привид Паскаля і нашіптав їх імена.
як я, блін, ще можу відповісти на це питання? а звідки ти знаєш, що ті піеми, яких ти зустрічав — хєрові? шкалу хєровості піемів — в студію.
або можеш пройтись по вищезгаданих канторах і перезнайомитись з їх піемами і працівниками, поспілкуватись про життя, проекти, методології, замовників.

"

Я так понял ты не претендуешь и твои мысли по поводу можно игнорировать? И ты сама часто используешь слова «возможно», «лучше», «свой комплект»?
"
ти дорослий хлопчик, а такі дурниці питаєш. сам сядь, і порахуй в моїх коментах. і да, якщо ти маленький і досі не знаєш, що робиди: я тобі великодушно дозволяю ПОВНІСТЮ і ВЗАГАЛІ ігнорувати мої пости.

афігєть дайте два, блін.

як я, блін, ще можу відповісти на це питання? а звідки ти знаєш, що ті піеми, яких ти зустрічав — хєрові? шкалу хєровості піемів — в студію.
Наверное потому что с ПиЭмами о которых я высказываюсь я лично работал, а не говорю что он хороший-плохой, потому что он красивый мальчег, или как ты там еще узнала его хорошесть.
ти дорослий хлопчик, а такі дурниці питаєш. сам сядь, і порахуй в моїх коментах.
Ты пропустила “возможно лучше посчитай”
Ответ: нефиг мне делать как выискивать где же ты таки употребила эти волшебные слова в твоих простынях текста.
я тобі великодушно дозволяю ПОВНІСТЮ і ВЗАГАЛІ ігнорувати мої пости.
Спасибо тебе за это, я так долго ждал твоего разрешения, обещаю подумать над этим.
Наверное потому что с ПиЭмами о которых я высказываюсь я лично работал
хм... а цікаво, чому в мене не могло бути цієї ж причини? за 9 років в ІТ я не могла фізично побачити в роботі більше 3 піемів, точно!
нефиг мне делать как выискивать где же ты таки употребила эти волшебные слова в твоих простынях текста.
ну тебе цікавить — ти і рахуй. як я маю відповідати тобі на питання, на які вже по-факту раза 2 мінімум відповіла?
хм... а цікаво, чому в мене не могло бути цієї ж причини? за 9 років в ІТ я не могла фізично побачити в роботі більше 3 піемів, точно!
Больше 3 — Ок, но ты ж говоришь о 30-60-и?
ну тебе цікавить — ти і рахуй. як я маю відповідати тобі на питання, на які вже по-факту раза 2 мінімум відповіла?
Меня не интересует цифра, то что ты категорично дартаньян, а инвесторы, кодеры и тимлиды не могут без тебя решить проблем и так видно.

ну тобі видно — і класно. ти навіть елементарно прочитати те, що я написала не в стані.

А возможно так получилось что это как раз ты не в состоянии правильно прочитать то что ты сама написала? Ты такой вариант категорически исключаешь?

та ну, зачем так напрягаться?
товарищ, вон, не напрягается даже подгонять под пост оппонента мантру «менеджеры плохие, потому что плохие». и напрочь игнорирует утверждение, что «РМ — это роль, и выделен на это отдельный человек или роль разбросана на всех — зависит от кучи фактором».

впрочем, как троллинг — очень грамотно сделано, сколько вон люди постов набросали-то!

Вижу популяция Нетролей на доу растет и размножается.

та я уже не напрягаюсь, а просто тролю. хоча іноді на такі коменти варто відповідати, щоб ті, хто їх читає і ще не сильно розбираються, мали повнішу картину.

людина мене вгнала в ступор одним тільки «а чому не пустити інвестора, щоб він напряму поговорив з девом» і ігнорування половини написаного.

зато рекрутерам пожива для їх чорних списків ))))

людина мене вгнала в ступор одним тільки “а чому не пустити інвестора, щоб він напряму поговорив з девом” і ігнорування половини написаного.
Ну да, потоки мысли я обычно игнорирую, мне не так и безразлично куда я деваю свое время.
мне не так и безразлично куда я деваю свое время
...завявил reality_hacker и накатал очередную обличительную простыню... :D
«менеджеры плохие, потому что плохие».
Товарищ, во первых я не припомню что бы я говорил что менеджеры плохие.
РМ — это роль, и выделен на это отдельный человек или роль разбросана на всех — зависит от кучи фактором".
В зависимости от того как ты определишь эту роль, это может быть одна роль, может не поместится в одну роль, и прийдется выдумывать много ролей, кто-то может поссмотреть на этот аспект как на функцию, и сказать что ПМ это функция, или их много. Можно придумать еще 100500 аксиоматически-терминологических теорий на эту тему, но мне просто это не интересно. Надеюсь у тебя нету мнения что я обязан отвечать на кждый твой комент, даже если он мне не интересен?
Надеюсь у тебя нету мнения что я обязан отвечать на кждый твой комент, даже если он мне не интересен?
Нафига было топик создавать и спрашивать «мнение уважаемой публики» если (судя по всему) все мнения, несовпадающие с твоим, тебе неинтересны?

Почему, если есть правильная аргументация, то мне интересно.

а ты уверен что кодер может объяснить, что бы бизнес(заказчик) понял?

Не уверен, таких обьясняльщиков называют бизнес аналитиками.

а если не его?

Хотел настрочить много букв, но после этого коммента понимаю, что ничего я нового уже не скажу. Все просто супер, написано четко и отлично. Как жалко, что на ДОУ нельзя поддержать коммент больше, чем один раз. Спасибо.

Самое глупое желание человека — понравиться всем. Но есть и ещё глупее — таких людей найти, и построить из них цепочку посредников.

Я скажу из собственного опыта — исполнитель этой роли нужен, и нужен полюбому. Иначе задача умрёт. Другой вопрос, насколько нужен, сколько рабочего времени это занимает, сколько ему платить (и платить ли вообще), какая его зона ответсвеннности (может быть что и никакой — всё равно будет работать).

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

Опис косить під продакт менеджера, а не звичайного ПМа на аутсорсних галерах.

десь погоджуюсь, десь — ні. ну і в топіку описано просто менеджера — а продакт менеджер — це теж менеджер ))))

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

зараз я би дописала до того коменту ще таке: якщо описувати всі можливі ролі учасників всіх можливих ІТ-команд, вийде такий бестіарій, що будь-хто скаже, що половина цих ролей — не потрібна. треба розуміти, що проекти і умови бувають різними. є аутсорс, є стартап, є продуктова компанія; є керівництво місцеве і закордонне; є поставлений на рейки бізнес а є стартап, гроші якому може приносити фішка, якої і близько спочатку не задумували; є мережа розподілених офісів (які втиху конкурують між собою) і є набір фрілансерів; є команди, які застрягли в R&D а є ідеальний аджайл. і в житті трапляється весь спектор комбінацій цих і сотень інших умов. і в тому числі є деви, які не хочуть чи не вміють брати на себе тімлідівську чи менеджерську роль.
тому важливо правильно оцінити те, що є, і вибудувати з цього замкнену систему. тобто: оцінити всі задачі, які виникають в процесі, і покрити їх всі повністю людьми так, щоб кожна людина робила переважно те, що вміє найкраще і ніхто не був перевантажений.

іноді роль піема прекрасно можна перекрити навіть юіксером — він проговорює все, що замовник хоче побачити в проекті, малює це схематично так, що ні замовник потім не може вимагати чогось додаткового, ні дизайнер не може додати якусь «нєпанятную задумку інжинєра» (тм) і программерам все точно ясно, що і як має працювати. от і весь менеджмент )))
іноді простіше не заводити менеджера, якщо толкових не попадається, ніж призначити аби кого. але тоді треба переозвучити роль і відповідальність кожного працівника, щоб вони як можна більше відчували свою самостійність і відповідальність за продукт.
іноді навпаки — можна призначити будь-кого, аби замовнику/керівництву було з ким поговорити довгими зимовими вечорами, а программери спокійно програмили.

просто саме головне призначення менеджера — дати можливість працівникам працювати і забезпечувати їх всім для цього необхідним.
а працівники — їх відповідальність і мотивація повністю залежить від того, на скільки глибоко вони володіють інформацією (про потреби що своєї фірми що бізнес цінності кожної фічі проекту) і на скільки вони самі приймають рішення. це дуже класно сказано тут: youtu.be/1wwuBzKuVrc
і менеджером може бути що інструментом, як з працівників зліпити такий колектив, який потрібен для вирішення заданої проблеми, що компенсатором їх невідповідності, що затичкою, що блокером.

Менеджер від слова менеджити (провірочне слово «manage»), а не «руководить» (руками водить), або керувати (машиною теж керює, але не називають шовера — «кєровніком»).
Якщо персонаж не має бюджета — він проста прослойка на проекті, що маємо у 90%, як тут уже писали — «заводіла-аніматор».

так, а де в мене про керівника взагалі?

бюджет-не-бюджет — по ситуації треба дивитись. взагалі з бюджетами в україні все несказанно смішно, навіть не хочеться цю тему піднімати.

P.S. Менеджеры из числа описанных в комментах порождаются, в основном, частым восприятием менеджера как «более белого воротничка», чем специалиста (с соответствующей разницей в з/п). А дальше — принцип Питера в действии.

А кого, собственно, обсуждаем?

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

Если мы обсуждаем сущность типа «средний ПМ в украинском аутсорсе», у которого ни реальных бизнес-целей проекта, ни бюджета от бизнес-спонсоров, ни реальной ответственности (кроме маржинальности и аттришена для менеджмента аутсорс-компании), то это, как бы, совсем другое.

С одной стороны, по проектной схеме (managed services или, тем более, solutions delivery) работает меньшинство аутсорсеров. В основном, это обычный T&M-ный staff augmentation, в котором нужен не менеджер (т.к. он сидит со стороны заказчика), а продвинутый секретарь в галстучке и с надутыми щечками, строчащий целыми днями отчеты и инвойсы, и дерущийся с другими секретарями за ценные ресурсы, подлежащие перепродаже (e.g. Sr. Java Dev).

Другое дело, если аутсорсятся более высокоуровневые активности, чем просто написание кода и прогон тест-кейсов (i.e. бизнес-анализ, управлением рисками, change management и т.д.) — менеджер проекта напрямую ими может не заниматься, но должен организовать такую структуру проектной команды, при которой эти активности выполняются эффективно и, в итоге, решают поставленные бизнес-цели.

Если это человек, получающий на вход бизнес-задачу типа «хочу создать площадку для торговли ценными бумагами» и далее набирающий людей, трансформирующий рабочие группы в команды, отвечающий за мотивацию и пипл менеджмент, оценивающий бюджет, выбивающий и распределящий ресурсы и, в целом, отвечающий перед руководством за успешность выполнения поставленной задачи — то это одно. Хотел бы я посмотреть, как проект с описанной выше задачей можно сделать без менеджера.
Бутстрапинг несомненно важен, но он занимает очень маленький этап времени проекта. Нанимают людей по факту девелоперы, qa и тимлиды, а менеджер формально соглашается, остальное «трансформирующий рабочие группы в команды, отвечающий за мотивацию и пипл менеджмент, оценивающий бюджет, выбивающий и распределящий ресурсы и, в целом, отвечающий перед руководством за успешность выполнения поставленной задачи — то это одно», это типичный булшит в стиле интервью проджект менеджера из office space(надеюсь ты видел этот фильм).
Нанимают людей по факту девелоперы, qa и тимлиды
Ага, конечно. И бюджетом проекта они рулят, и их увольняют, если проект вместо запланированных 50 мио вылез в 60, и они договариваются с другими командами из смежных проектов о согласовании приемочного тестирования и графика релизов, и вообще они из страны эльфов.

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

Office Space я видел. Надеюсь, ты, в свою очередь, видел Pulp Fiction и помнишь Винстона Вулфа. Вот его-то я и представляю, когда речь идет о качественном менеджере (в ситуации с Бонни, конечно, кризис-менеджер, но сути это не меняет).

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

Пример Вульфа незащитан — не из той оперы извините =)

бюджетом проекта они рулят
Меня всегда поражала помпа этой фразы. А что там рулить то?
и их увольняют, если проект вместо запланированных 50 мио вылез в 60
А в чем проблема уволить?
они договариваются с другими командами из смежных проектов о согласовании приемочного тестирования и графика релизов
Как то не встречал таких ситуаций
Меня всегда поражала помпа этой фразы. А что там рулить то?
Бюджет, во-первых, где-то найти нужно, во-вторых, решить, как его оптимально потратить (соотношение синьоров-мидлов-джунов, затраты на автоматизацию и т.д.), в-третьих, отслеживать риски, влияющие на бюджет, сроки и качество и их вовремя митигировать (девелоперы, как правило, о рисках не думают, и не хотят брать за них ответственность).
А в чем проблема уволить?
Не проблема, только проект все равно нужно делать, а вздернуть козла отпущения нужно. Как правило, это менеджер, допустивший такую ситуацию (не заменедживший какие-то риски).
Как то не встречал таких ситуаций
Может, в этом все дело? Опишу вкратце очень простое бизнес-требование в инвестбанке: сейлзам нужен выход на новую торговую площадку, т.к. определенные инструменты торгуются только на ней, а отсутствие их в предложении банка не позволяет привлекать крупных портфельных инвесторов, желающих торговать всем портфелем через одного брокера.

Задача product owner — посчитать ROI этого мини-проекта, включить в бэклог при наличии бизнес-кейса (возможно, с тем объемом бизнеса, что мы привлечем, проще эти инструменты покупать у другого брокера), приоритизировать его (и объяснить стейкхолдерам менее приоритетных требований, почему их «хотелки» отодвигаются) и поставить задачу команде.

Вроде бы, все по Скраму, только вовлечен не один product owner, а, как минимум, шестеро, т.к. задействованы следующие системы: market order booking system, exchange execution interface, client order booking system, trade confirmations and allocations, AST trading robot, securities settlement system.

Их всех нужно скоординировать и следить за тем, чтобы задачи имели в их бэклоге одинаковый приоритет. А есть еще другие команды: network management должны подписать договор с биржей, legal & compliance проверить и заапрувить договор, IT support — завести необходимые данные в системах поддержки статики (instruments, accounts, SSI etc). Все эти ребята, как правило, работают не по скраму, их тоже нужно пинать и следить за ними. Иногда команда их может пинать, иногда нет. И тут нужна эскалация на уровень, от которого ты предлагаешь избавиться, и который должен решать коллизии и нестандартные ситуации.

И это я описал еще довольно простой проект.

Бюджет, во-первых, где-то найти нужно
И как, у вас ПМы находят бюджет? Это тоже какая то экзотика.
решить, как его оптимально потратить (соотношение синьоров-мидлов-джунов),
это ерунда какая то
затраты на автоматизацию и т.д.
это тоже не ПМ эстимирует и решает, а вполне тех человек
Не проблема, только проект все равно нужно делать, а вздернуть козла отпущения нужно. Как правило, это менеджер, допустивший такую ситуацию (не заменедживший какие-то риски).
Да херово менеджит менеджер риски, все потому же что у него нету четкой картинки от того что происходит и где затыки. Самая четкая картинка у тим лида, т.к. он работает с телом проекта, и в тоже время комуницирует напрямую с членами команды и разговаривает с ними на одном языке. И если тимлид плохой, то не вижу проблемы его поменять на хорошего.
Иногда команда их может пинать, иногда нет. И тут нужна эскалация на уровень, от которого ты предлагаешь избавиться, и который должен решать коллизии и нестандартные ситуации.
И это я описал еще довольно простой проект.
Так а в чем заключается координация и пинание? Помоему это все как то легко автоматизируется. Вначале проекта какой то (solution) architect расписал таски(менеджер их не распишет, т.к. не имеет соответствующей квалификации), завел на них тикеты в системе, установил депенденси между тикетами, выставил дедлайны(менеджер не может, потому что не технарь плохо эстимейтит таски) при возможности согласовав их с тимлидами, и все, вся координация происходит в баг трекере, картина кто успевает/неуспевает четко видна.
Задача product owner — посчитать ROI этого мини-проекта
Загадалось:
купив за 100 продав за 200, і за ці 2% я живу.
Де тут інвестиція?

PO ничего не покупает и не продает, его задача — оценить бизнес-кейс, как таковой.

Например, есть некая бизнес-задача, ее можно решить тремя способами: первый — полностью автоматизированное решение, убирающее необходимость ручного труда (оценено командой в 75 попугаев), второй — автоматизация main flow и небольшое допиливание существующего UI для обработки нестандартных ситуаций вручную (оценено командой в 40 попугаев), третий — сделать экспорт/импорт в/из Excel и обрабатывать все вручную за пределами системы (5 попугаев).

Допустим, команда стоит $20k в неделю, ее средняя velocity — 20 попугаев за двухнедельный спринт (т.е., один попугай — приблизительно $2k). При этом первое решение требует ручного труда в размере 0.1 FTE в Лондоне, второе — 2 FTE в Индии, третье — 5 FTE в Индии (со стоимостью, соответственно, $75k/год и $20k/год).

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

Так что считать работу PO тупым барыжничеством — это большая ошибка.

тим лид разберется, делов-то ;)

продакт оунер это не ПиЭм если я правильно понял твою иронию.

А какое мнение почтенной публики?
ПМ в большинстве случаев — секретарша на проекте, так сказать прокладка меж командой, начальством и заказчиком, которая всасывает всякие излишества, как тампон, и пропускает нужное, как фильтр.

Вы готовы заменить такую прокладку собой на должности ТЛ?

Это конкретное предложение или так, поговорить?

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

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

ну значит, заказчику нужен аниматор, а капризным командам — платочки слезки вытирать)

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

Это вопрос к руководству и его полиси, а не к команде.
А на моей памяти, в СофтСерве ходила пословица, что любая секретарша, которая знает анг. язык, может быть ПМом.
nuff said

знаю как минимум двух хороших и сильных ПМ, которые ушли в СС, наверное востребованы)

а так, руководству проще общаться с одним ПМ, чем с 4-5 тим-лидами

— менеджментом тасков должен заниматься тимлид, так как он намного ближе к телу, у него намного более адекватное представление о сроках и способностях людей
В моем понимании тимлид (тоже что и архитект) не должен заниматься менеджментом, его задача делать архитектуру и решать именно технические вопросы. Да в большинстве случаев и не нужно оно архитекту, ибо он человек технический, ему это нафиг не надо. А вопросы сроков, приоритетов, успеваем/не успеваем — чисто менеджерские вопросы и это и должен делать ПМ. По поводу конкретных примеров — работал в проекте несколько месяцев без менеджера, но с тимлидом. В какой то момент заказчика задолбало то, что он не понимает что и когда будет делаться, а тимлида — что его напрягают нетехническими вопросами. Наняли менеджера — успокоились заказчик и тимлид. Со стороны программиста ничего, по сути не поменялось. Ваша позиция «менеджер не нужен» мне видится очень узколобой, скажем так, Вы смотрите на нее только со стороны программиста. А есть еще заказчик, для которого такой человек бывает очень нужен. И на тимлида (если мы под ним понимаем именно _технического_ лидера) вешать обязанности ПМа глупо и неправильно.

тімлід, пм, менеджер — людина, що керує командою чи процесом. Синоніми. В нас РМів нема майже ніде, тімліди — менеджери.

если конкретно у вас их нет, это не означает, что нет нормальных взрослых фирм, где они есть

А если такие взрослые фирмы с пиэмами есть, это не означает что они там реально нужны

те менеджеры, которые зачастую работают в Украине, очень редко выполняют роль именно ПМ, чаще всего они выполняют роль ответственного delivery manager, отсюда и все недопонимания

Да, да, я уже поднял тему что такое Delivery Unit, расскажи пожалуйста wtf, а то помоему такое только в Украине есть.

обычно, на простом языке, это тот, кто «отгребает» шишки за все проколы команды) особенно с опозданием сроков или с плохим качеством, когда заказчик все время «давит» на команды

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

т.е. человека наняли, чтоб он отгребал за проколы команды? ))

В нас РМів нема майже ніде, тімліди — менеджери.
Какое странное (если не сказать глупое) обобщение... Что значит нигде? За свой опыт работы в 3х аутсорсовых компаниях на 7 (кажется проектах) могу сказать, что ВЕЗДЕ были ПМы и были тимлиды. И больше чем в 70% случаев ПМы не мешали проекту, а приносили пользу. Там же где они мешали, была проблема не в том, что ПМ не нужен в принципе, а в конкретном человеке — он либо не понимал что от него требуется, либо не хотел это делать, в итоге человек менялся и все становилось нормально.
Какое странное (если не сказать глупое) обобщение... Что значит нигде?
Ты видимо пропустил «в нас»

А я не понимаю, что это значит именно тут... Это может быть как «у нас в компании», так и «у нас в Украине»...

Ну может стоит поинтересоваться прежде чем писать простыни возмущений о обобщениях?

Да в большинстве случаев и не нужно оно архитекту, ибо он человек технический, ему это нафиг не надо.
архитект по любому должен иметь communication skills прокаченные, т.к. это его работа общатся с людьми, выяснять их проблемы и направлять в нужное русло.
А вопросы сроков, приоритетов, успеваем/не успеваем — чисто менеджерские вопросы и это и должен делать ПМ.
Та не менеджерские, а тимлидские, менеджер он не видит процесса разработки, и у него нет адекватного представления успеваем ли и если нет то почему и где подкрутить гайки.
Наняли менеджера — успокоились заказчик и тимлид. Со стороны программиста ничего, по сути не поменялось. Ваша позиция «менеджер не нужен» мне видится очень узколобой, скажем так, Вы смотрите на нее только со стороны программиста. А есть еще заказчик, для которого такой человек бывает очень нужен. И на тимлида (если мы под ним понимаем именно _технического_ лидера) вешать обязанности ПМа глупо и неправильно.
Все правильно, только это не менеджер, это аниматор, если попался капризный заказчик хотящий что бы его обхаживали то ему нужен такой человек, но этот человек ни в коей мере не должен менеджить тим.
т.к. это его работа общатся с людьми, выяснять их проблемы и направлять в нужное русло
следующей темой при таком подходе будет «зачем нужен бизнес-аналитик?»

Не, у бизнес аналитика очень четкая функция, полезность которой крайне очевидна, в отличие от ПиЭма.

кто в стартапах выполняет роль бизнес-аналитика?

Стартапы это отдельная тема, там и пиэмов иметь противопоказано.

ну да, только СЕО, ТЛ и команда дешевых полудохликов))

Где то так, с точностью до названий.

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

Не будь голословным, разбери должность программиста

А я не собираюсь это делать, мне это не надо. Меня просто уже малость раздражает твой подход «все ПМы, которых я видел, нетехнические идиоты и значит они не нужны, все что они делают — ерунда, вот это тимлиду отдадим, вот это сейлзу, а это ваще фигня и бред, тут аниматора наймем». А ты мне лучше скажи — вот тот вот идеальный тимлид, которого ты описываешь по всему треду — он где то существует кроме твоей фантазии? Покажи нормальную репрезентативную выборку по тимлидам, которые а) продумывают от и до архитектуру проекта б) выбирают технологии, которые будут юзаться на проекте в) пишут технические спеки г) продумывают и реализовывают на высоком уровне ядро системы д) объясняют и обсуждают с девами технические аспекты задачи. При этом этот же человек (внимание!) должен а) держать Заказчика в курсе того, как и куда движется проект б) выяснять у Заказчика бизнес требования, а также приоритеты и сроки в) общатьсяся абсолютно со всеми участниками процесса г) коммуницировать с руководством Компании д) составляют и контролируют планы работ е) координируют сотрудничество девов с тестерами, дизайнерами и пр и пр и при этом (самое главное) ж) этот человек еще не свалил в другую контору, в которой он занимается именно тем делом, на которое он изначально подписался (менеджмент чисто ТЕХНИЧЕСКОЙ стороны проекта — архитектура!). Покажи мне хотя бы 10 таких саксессфул сториз, а потом уже будет иметь смысл что-то обсуждать...

А я не собираюсь это делать, мне это не надо.
Даже если бы и надо было, ничего бы не получилось очевидно, т.к. программеры это люди делающие продукт, можно без всех обойтись, без начальства, КА и офис менеджеров, но без программеров не будет продукта никакого и никак.
Покажи мне хотя бы 10 таких саксессфул сториз, а потом уже будет иметь смысл что-то обсуждать...
Тебе как показать?

Примерами "

success stories
", разумеется

Я имена явки где я работал называть не хочу.

Если убедительно напишешь, я готов поверить тебе на слово

Ну я здесь уже много написал по этому поводу, вся эта модель с тимлидом, БА, и без ПиЭм замечательно работала в нескольких местах где я был. Какие именно детали тебя интересуют?

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

«ПМ тут все равно не нужен, потому что он все равно не нужен
Очевидно мои доводы были: «ПМ тут все равно не нужен, потому что [какая то причина]», если ты считаешь что причина неочевидна, можешь высказаться предметно.

Троллишь? :)

Девушке ты по сути не ответил. Не написал, почему ПМ не нужен, а просто сьехал на «а все равно ПМ может вносить latency и быть испорченым телефоном». ПМ может и геем оказаться и трахнуть тимлида, заказчика, директора и заставить команду переписать с Rails обратно на ASP.NET. И какое это имеет отношение к теме?

У девушки поток сознания, если хочется конструктивно общаться, нужно собраться с мыслями и лаконично и понятно изложить доводы, а не писать простыни текста. Я попытался вычленить основные моменты из ее текста, я так понял она решила что умнее инвесторов и девелопера, лучше знает что им всем нужно и решила назначить себя посредником. Может оно конечно и так, фиг проверишь, но есть подозрение что нет. Что тут отвечать?

ок. был бы на ДОУ литредактор — можно было бы из этой простыни сделать неплохой текст на 2000 знаков.

А смысл? ТС все равно не ответит. Либо просто проигнорит, сославшись на «поток сознания», либо выдерет из всего текста одну-единственную фразу, которая якобы «подтверждает его теорию» и опять же проигнорит все остальное. Спорить бессмысленно.

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

Человек не голословил, а привел конкретные примеры из жизни. Причем расписала все от и до, разжевала донельзя, и как бывает хорошо без ПМа, и как бывает плохо без него, привела примеры того , когда без ПМа было действительно плохо. Ты по сути не возражаешь, зато съезжаешь на поток сознания. Отличная позиция, что тут скажешь...

Я как раз возражаю по сути, а ты набрасываешь уже который пост без возражений по сути.

Я на практике видела две работающие модели:

  • сильный менеджмент + слабые скиллы у team’a
  • слабый менеджмент + сильные скиллы у team’a
В ситуациях, когда менеджеров убирали из проектов совсем, кому-то из команды приходилось брать на себя эту роль. И чем больше был проект / слабее team, тем больше времени это у него отнимало. Зато во многих случаях добавлялся скилл «Software Project Management» в LinkedIn :)

Саша, Слава?!

Менеджеры по сути не нужны! Посмотрите сколько на самом деле среди контор аутстаффа, и он себе живет и процветает. Собсно, такие команды вполне себе самодостаточны, и зачастую наличие отдельно менеджера им только мешает.

Не понимаю при чем тут аутстаффинг?! — это один из типов сотрудничества компании и сотрудника. На проектную деятельность тип сотрудничества не влияет :)
Нравится вам или нет — менеджер проекта есть всегда. Иногда он на стороне заказчика, в скраме эту роль делят scrum master и product owner... тогда да, конечно, зачем еще один «лишний» PM.
Так же, как говорил Макс Ищенко ниже, автор так и не объяснил о ком он говорит.
К слову, project management тоже разный бывает. А судя по комментариям автора, он говорит о каких-то странных людях, которые делают какие-то не нужные вещи, а это видимо вообще не о project manager-ах и management-е чего-либо в принципе.

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

Чепуху какую то щас сказал. Как от географического положения человека может меняться его роль?

Не географического, он на стороне заказчика, и никого не менеджит.

Если это аутстафф, то менеджер, сидя на стороне заказчика, как раз менеджит... и аналитики тут ни при чем

В аутстафе Ок, но там как бы заказчика нету, а есть телопокупатель.

угу, у меня на 3-х проектах 10+ человек аутстаффа из 2-х компаний. Действительно ПМ-ы не нужны. Только товарищи чего-то не хотят(в том числе и их тим лиды):
— у заказчиков уточнять требования,
— согласовать варианты реализации,
— нагибать заказчиков или прогибаться перед оными (в зависимости от ситуации, звезд на небе или магнитных бурь),
— согласовать доступы,
— решать вопросы инфраструктуры (выбивать железо, диски),
— организовать ЮАТ,
— координировать работу разработчиков разных систем (в проектах задействовано 11 систем),
— решать вопросы в случае каких сбоев (одни готовы приступить, другие не доделали или бока вылезли на тестировании по сути тоже не доделали),
— организовать тестовую среду, которая развернута на территории 3-х компаний (а здесь и свои и чужие админы),
— организовать установку в прод,
— передать на сопровождение,
— реагировать на изменения команды (один уволился, другой заболел, третий в отпуск, четвертый на сессию, у пятого жена родила)
— вести учет времени,
— получать пиндюлей (в зависимости),
— заботиться о душевном состоянии команды (в том числе делать что «пендели» до команды не доходили, а благодарности доходили в обязательном порядке),
— а также прочая административная хренотень (в том числе отчетность).

Просто потому что им за это тупо не платят (оплата то почасово).

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

Вопрос честно говоря вообще провокационный, потому как у каждого свои обязанности + каждый должен не мешать друг другу в одних вопросах, и
помогать. Собственно как в книжках пишут «модель win-win рулит». Тьфу-тьфу у меня проблем с программистами и тестировщиками никогда не было.
Хотя попадались программисты, которые поначалу старались саботировать работу. Но вопросы решал,без привлечения, каких-либо административных рычагов, более того подружились даже.

Отличное подтверждение моей теории, когда менеджер из-за ненужности начинает забирать работу у админов, салесов, офис менеджеров, и при этом еще навыдумывает кучу каких то мифических активностей, особенно порадовало про «согласовывать УАТ» и «организовывать установку в прод».

ну конечно порадовало....
про уат:
конечно бизнеса так и ждут и мечтают о том чтобы поучаствовать в уате. Им просто заняться боле нечем.

Про установка в прод:
Ну если проект аутсорс. где как правило окончание проекта заканчивается на этапе оттестили билд и отравили фиг знает куда, то

«организовывать установку в прод»
вызывает
особенно порадовало
и понятие ОПЭ отсутствует напрочь.
когда менеджер из-за ненужности начинает забирать работу у админов, салесов, офис менеджеров, и при этом еще навыдумывает кучу каких то мифических активностей
Делать ему больше нечего.
конечно админы же универсалы могут железо менять и настраивать на 2-х этажах, сопровождать десятка 3 систем на разных ОС.....

тут разработчик (ключевой) заболел или договорится о ресурсах или внести изменение в план, или перенести сроки......это полюбому работа офис-менеджера.

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

Еще раз повторюсь, если команде влетает «разжеванная» задача, которая является маленьким кусочком «хр@н» знает чего, и на выходе на чего-то оттестить «юнит тесты рулят» и «куда-то отправить», но могу согласиться хватит и лида.

ну конечно порадовало....
про уат:
конечно бизнеса так и ждут и мечтают о том чтобы поучаствовать в уате. Им просто заняться боле нечем.
Вообще обычно да, мечтает, если заинтересованы в результате.
Про установка в прод:
Ну если проект аутсорс. где как правило окончание проекта заканчивается на этапе оттестили билд и отравили фиг знает куда, то
Так а что все таки ты сам «организовываешь установку» в прод? Расскажи поподробнее? Я много раз учавствовал в этих делах по обе стороны барикад и как то не вижу где там ПиЭм фигурирует.
конечно админы же универсалы могут железо менять и настраивать на 2-х этажах, сопровождать десятка 3 систем на разных ОС.....
Так что, ПиЭм менеджит за админов серваки?
тут разработчик (ключевой) заболел или договорится о ресурсах или внести изменение в план, или перенести сроки......это полюбому работа офис-менеджера.
Меня вот это всегда поражало как ПиЭмы наводят важность и сложность вокруг процесса «изменения в план»
выяснить требования, когда заказчик как правило хочет «большую красную кнопку» и «шоб все работало» это полюбому сейл он елки маталки то же спец-универсал как админ и офис менеджер.
этот человек называется бизнес аналитиком а не пиэмом
Еще раз повторюсь, если команде влетает «разжеванная» задача, которая является маленьким кусочком «хр@н» знает чего, и на выходе на чего-то оттестить «юнит тесты рулят» и «куда-то отправить», но могу согласиться хватит и лида.
Так и так хватит, ПиЭм лишний, только сует свой нос где он не компетентен, отлично виднона твоем примере.

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

Не отмажешься, я уже в вашу GSK резюме отослал.

отлично, только меня там нет :)

А зачем оркестру дирижёр? Ведь скрам шагает по планете... У музыкантов что, нот нету? Договориться не могут?

А взять вас на работу кто решил? С кем вы зарплату и условия обсудили? Кто обосновал, что ваш проект вообще нужно делать и [о Боже!] тратить деньги на вашу зарплату? Кто расписал цели, бюджет, и финансовую отдачу — бухгалтер, программисты?

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

А зачем оркестру дирижёр? Ведь скрам шагает по планете... У музыкантов что, нот нету? Договориться не могут?
Ну да, вот тим лид и дерижирует обычно, потому что он в скрипках разбирается в отличие от ПиЭма
А взять вас на работу кто решил?
А ПиЭм тут тоже припарка, обычно программеры программеров собеседуют.
С кем вы зарплату и условия обсудили?
А у вас ПиЭмы ЗП программерам назначают?
Кто обосновал, что ваш проект вообще нужно делать и [о Боже!] тратить деньги на вашу зарплату?
Обычно такие люди sales называются
Кто расписал цели, бюджет, и финансовую отдачу — бухгалтер, программисты?
Наверное заказчик?
Когда людей становится несколько, их усилия уже нужно координировать (а для начала обосновать, что этот труд вообще кому нибудь нужен и определить откуда деньги возьмутся).
Ну вот и проблема что координирует обычно тим лид, потому что экспертиза и вовлеченность на порядок больше, а ПиЭм ненужная прослойка, которая обычно еще из-за большого количества свободного времени тратит много усилий на самопиар и мучение воды.

Давайте немного определимся.
Под словом менеджер чаще всего подразумевают позицию (место в орг. структуре), область ответственности в производственном процессе и право принимать решения по ресурсам компании (такие как деньги и время сотрудников — на что их тратить).
Менеджер Проекта — это обычно РОЛЬ, и для небольшого проекта времени на исполнение обязанностей по этой роли надо совсем немного (от часа в неделю до пары часов в день). Для полной загрузки ПМа нужно где-то 2-4 проекта и 12-18 человек, возможны вариации (это просто наблюдения, тут спорить не имеет смысла).
Судя по вашим комментариям — роль ПМ-а у вас выполняет ТехЛид (молодец, что тут скажешь), а ПМ у вас просто недозагружен работой (ну или вам так кажется :-)

Не принимайте близко к сердцу — проекты бывают большие, а менеджеры (ПМы?) бывают хорошие :-)

Насчет роли vs. должности я раньше спорил со всеми, т.к. вырос на Prince2, где команды создаются и распускаются под проект зачастую в матричной структуре, и PM — это всегда роль. Но потом просто понял, что бывает по-разному, и спорить тут не о чем. It depends.

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

Человек же написал

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

О какой координации Вы говорите?

define менеджера софтверного проекта, иначе непонятно что мы обсуждаем.

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

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

gantt charts, TPS reports, etc.

никогда не работал в большом аутсорсе, но там вроде все просто — есть «ресурсы» (так аутсорсеры людей называют) и их нужно эффективно «утилизировать» (так аутсорсеры называют billable work). это и есть задача проджект менеджера.
gantt charts, TPS reports, etc.
Вот именно что TPS reports, не кажется что эти задачи не сложнее набивания секретаршей текста?

хз. думаю проще всего призвать в топик ПМ-ов и у них выяснить.

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

Так, для зрілої команди менеджер можливо не потрібен, точніше його функції обмежені. Скажімо, спілкуванням з замовником. Давайте на прикладі. Ви робите ремонт, і робить його бригада з 10 майстрів. Вам, як замовнику, захочеться кожному з 10 пояснювати фронт робіт ? Аж ніяк. І автоматом серед них один стане менеджером, назвете Ви його так, чи ні.
Це перше, що спало на думку.
Але зрілих команд Ви багато бачили ? Я — мабуть жодної. Всім потрібен був менеджер, який скаже що робити, як робити, пріоритети, розрулить конфлікти, вирішить адмін-питання, і теде. Таке життя :)

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

в каких проектах есть бизнес-аналитики? может в стартапах, где денег на QA не хватает, зато скрам рулит миром?

Та везде где я работал были бизнес аналитики.

это не значит, что они есть везде, разве не так, великий и всемогущий наш ТЛ?)

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

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

ам где БА не было, его работа делилась между ПМ-ами с обоих сторон.
Это сразу эпик фейл, вопиющая некомпетентность и причина провала кучи проектов. Вместо того что бы бизнес аналитик написал четкую детальную доку с требованиями и моками интерфейсов, девелоперы получают знания через третьи руки.

у нас на проекте нет бизнес аналитика, так что они тоже не нужны

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

Интересно, а когда в интернетах ПиЭмы срут на девелоперов что они ленивые, разбалованные и их мир умещается в зеркалке и велике, этотоже личная обида?

да.
как и любое обобщение.
и это обобщение про обобщение — в том числе. моя личная обида на обобщения.

Т.е. кроме личной обиды других возможных мотиваций фантазия не подсказывает?

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

Извини, но на такое количество ерунды мне отвечать лень. Могу избирательно спросить например «ВА плачет, не ночует дома, но окромя нудного выяснения подробностей занимается убалтыванием и организацией клиента, который, как ни крути, не является идеалом заказчика» а что именно он убалтывает клиента?

ничего, не утруждай себя

+100500
так оно и есть, еще должны следить за тем, чтобы качественные «ресурсы» не уходили к другим аутсорсерам (или что еще хуже в «продуктовые» компании :) )

Можу сказати на своєму досвіді, що потрібні 100%.
Мабуть прийде з віком розуміння, що менеджер, це добрий товариш для програміста.

Роботу програміста можливо розбити на приблизні складові.
1. humanity skill
2. technical skill
3. team skill

Зверну увагу на 1 пункт. Навичка ведення переговорів з замовником, планування, ведення проекту, підрахунок потрібних ресурсів (не одні програмісти і їх печеньки) і доведення це до замовника.
Всі ці складові потребують навичок і досвіду. Програмісти, часто мають непогані навички по 2-ому і 3-му пункту, але 1 пункт може сильно хромати по здається, коли маєш інші то цей не такий важливий.

Насправді 1 пункт дуже важливий і він забирає дуже багато часу. Ось тут виходить на сцену PM. Він забирає на себе вcі труднощі 1 пункту і захищає команду від зовнішнього тиску.

В наших реаліях в 70% невдалого досвіду, ми говоримо, не про те що поганий менеджер, а про менеджера, як випадкову людину з вулиці, яка не розуміє, що таке PM.
По-суті про професійну некомпетентність.

Взагалі некомпетентність в нашій сфері і наглість плюс молода енергія, яка присутня породжує химеру виключності професії і її елітарності і ще якоїсь херні, але це просто
ремесло, як наприклад гончарство

Навичка ведення переговорів з замовником, планування, ведення проекту, підрахунок потрібних ресурсів (не одні програмісти і їх печеньки) і доведення це до замовника.
Планирование и ведение проекта — это тим лид справляется, ресурсы опять же считает тим лид, потому что он может намного лучше заэстимейтить, доведения до заказчика это как? Письмо отправить по электронной почте?
доведения до заказчика это как
Ось бачите ви погано розумієте як працювати по першому пункту. На мою думку спілкування з вами перетвориться в троллінг 23 сеньора...

Так що DIXI

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

Это у вас пока что нет ни одного аргумента против PM.
В Скраме да, можно жить и без ПМ-а, но не без scrum master-а в этом сллучае.

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

— есть имперический опыт и не только вроде как мой что ПМ-ы частенько не приносят пользу
Я уже отвечал вам ниже. Чтобы оценить пользу — попробуйте работать без ПМ-а вообще.
— есть некоторые обьяснения почему
— нет никаких очевидных аргументов с противоположной стороны кроме «ну-ну» и «да ты ничего не понимаешь»
Перечитайте мой пост ниже еще раз. Или два.
Я уже отвечал вам ниже. Чтобы оценить пользу — попробуйте работать без ПМ-а вообще.
Отлично получается!
Перечитайте мой пост ниже еще раз. Или два.
У него от этого смысл какой то появится?

ты решил экстраполировать свой местный несчастливый опыт плохого ПМ-ства на весь мир?)))))))

Нет, мой опыт это только один из аргументов.

У него от этого смысл какой то появится?
От этого он может быть до вас дойдёт, хотя, вижу, что не факт, но вы всё же попытайтесь!

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

Я без пма работаю уже на втором проекте. Отлично получается , на много ровнее все идет.

Планирование и ведение проекта — это тим лид справляется, ресурсы опять же считает тим лид,
ну-ну :D

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

за 12 лет карьеры видел полезных менеджеров ровно два раза
один умел не мешать работать и добывать ресурсы
второй давил все кишки из бизнес народа для получения вменяемых задачь
Если эти две функции выполняются слабо — то обычно от такого менеджера пользы 0 и в команде он приносит один вред.

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

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

что Вы подразумеваете под

получения вменяемых задачь

Начнём с того, что «менеджеры» бывают разные и... и очень разные. О каких вы именно я не совсем понял, но рискну предположить что о PM-ах, которые project manager-ы.

А какое мнение почтенной публики? Какие есть success и неsuccess stories?
Судя по тому что вы пишите — вы не видели хороших PM-ов и, видимо, вообще не понимаете этой роли.
Какие есть success и неsuccess stories?
Хватает как первых, так и вторых (и, кстати, без вторых прийти к первым почти невозможно, как и в любом другом деле). Рассказывать долго и лень.

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

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

ЗЫ:
Какая-то новая манера тем на ДОУ пошла, совсем по шаблону.

Как бы придраться не к чему, но и полезной инфы — круглый ноль.

Какого типа инфу вы ожидали? Историю как стать хорошим PM-ом и с десяток рассказов о совершенных подвигах?

Какого типа инфу вы ожидали?
Зачем нужны ПМ-ы, и какие функции они выполняют в твоей организации.
Историю как стать хорошим PM-ом и с десяток рассказов о совершенных подвигах?
Можешь как бонус добавить если есть желание.
Зачем нужны ПМ-ы, и какие функции они выполняют в твоей организации.
en.wikipedia.org/...Project_manager
Можешь как бонус добавить если есть желание.
Уже отвечал:
Рассказывать долго и лень.
Я не вижу никакого смысла писать две страницы текста чтобы объяснить человеку, который не понимает ни роли, ни фукнций, ни задач PM-а, что они крайне необходимы.
По этому я и предлагаю вам вариант:
Если вы считаете что конкретно у вас плохой и не эффетивный менеджмент, — поработайте без него. Вообще без него.
Если за месяц-два всё станет лучше, — значит вы были правы, менеджера на «рынок труда», а вы — молодцы, которые могут работать командой!
Если же нет, — ну вы поняли.
Тогда, возможно, вы поймете зачем они нужны, или не нужны, для вашего конкретного проекта.
Подумайте еще вот над чем: зачем практически каждая компания нанимает PM-ов, тратит деньги на их ЗП и другие costs, если они не нужны?! А так же, над тем почему PM-ы достаточно хорошо зарабатывают.
Уже отвечал:
Рассказывать долго и лень.
т.е. ты здесь так, набрасываешь?
Я не вижу никакого смысла писать две страницы текста чтобы объяснить человеку, который не понимает ни роли, ни фукнций, ни задач PM-а, что они крайне необходимы.
Да, уже хорошо зарекомендовавший себя тезис — «ты ничего не понимаешь», за то у тебя абсолютное понимание, а по факту здесь уже есть куча мнений о функциях ПиЭм-а при отсутствии единства.
одумайте еще вот над чем: зачем практически каждая компания нанимает PM-ов, тратит деньги на их ЗП и другие costs, если они не нужны?! А так же, над тем почему PM-ы достаточно хорошо зарабатывают.
Еще скажи что наши депутаты нужны, потому что они есть

Судя по твоим постам, вам не ПМ-ы не нужны, а такие программисты гениальные ;)

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

Зачем нужны ПМ-ы, и какие функции они выполняют в твоей организации.
Читайте PMBOK.
Вам не повезло. Люди, которые занимали должность PM, были непрофессиональны и дискредитировали профессию. Такое бывает. Но не нужно отсюда делать вывод, что такая профессия вообще не нужна.

пиэмы нужны

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

из раздела личных мемуаров — once upon a time — тридевятом царстве тридесятом госудрставе к нам зашло 2 нетехнических пиэма, которые были между сейлзом и техлидом, и сколько было борьбы за мир чтобы они начали адекватно реагировать на внешние раздражители — сейчас не описать — но в итоге, когда они от нас уходили — они накопили опыт, и ушли в более крупные компании и там стали уважаемыми людьми — один из них теперь со мной правда не здоровается по сей день, но именно мы, сейлзы, учили его что надо говорить заказчику из того массива данных, что ему хотели передать разработчики и т. д.

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

в идеале это просто тимлиды
Замечательная идея
у меня также был период работы без пиэмов вообще и с одной стороны — меньше звеньев, нужно меньше людей чтобы обкашлять все вопросы с другой стороны — ведение проектов занимало такое количество времени, что продажи тормозились, поскольку надо вычитывать было баг листы, по каждому багу надо было нежно подмигнуть девелоперу (или поцарапать бокс когтями, по ситуации, чтобы он был сделан ... ну тоже в общем не идеальная ситуация — в итоге сейчас я думаю — что да нужны, но их роль должна быть сугубо техническая
Это то о чем я говорил, пиэм берет на себя обязанности individual contributors(i.e. sales manager, team lead), но почему то по прежнему называется менеджером.

давайте определися с понятиями, если считать что
(ленивый хитрож*опый *овнюк в пинжаке) == (менеджер)
то да -> не нужны
а в целом конечно нужны, это ежу понятно.
зы: титул срачъ-мастера ты у Сергея не отнимешь, он уникален.
интересно услышать его мнение по теме, кстати.

ззы: очень годно в данном контексте звучит предложение Альберта
dou.ua/...ic/6941/#288153
программисты-в-законе vs менеджеры + административный актив типа «серых мышей» в тёплых уголках контор и пр.

а в целом конечно нужны, это ежу понятно.
Ну я конечно возможно не до рос до уровня ежа, но может ты как то предметно проаргументируешь свою позицию?
Ну я конечно возможно не до рос до уровня ежа, но может ты как то предметно проаргументируешь свою позицию?
та не прибедняйся.
1-менеджер даёт возможность разработчику абстрагироваться от суеты и забот связанных с решением организационных вопросов,
2- выдаёт освежающих *здюлей кому надо (т.к. девелопер девелопера обычно не клюнет).
но
зачастую пинжаки «не ловят мышей» ни по первому ни по второму пунктам, делегируя
п.1->разработчикам
п.2-> срам мастерам которые вместо прицельной клизмы полощут мозг всем подряд
1-менеджер даёт возможность разработчику абстрагироваться от суеты и забот связанных с решением организационных вопросов,
Да, да, то что я писал, работает офис менеджером.
ыдаёт освежающих *здюлей кому надо (т.к. девелопер девелопера обычно не клюнет).
Это кстати совковый подход, никто никаких здюлей не должен никогда выписывать. Нужно спокойно урезонить, обьяснить, сказать что чел не справляется и попытаться ему помочь. Такой подход сразу дает +20 к морали команды, увеличивая атаку по драконам. А конфликтных людей с психикой «раздать люлей» нужно устранять из команды.
Кстати отличительная черта украинских менеджеров — нахамить и показать власть. В топку таких сразу.
зы: титул срачъ-мастера ты у Сергея не отнимешь, он уникален.
интересно услышать его мнение по теме, кстати.
dou.ua/...ums/topic/6135

в том годном топике речь про Срам.
Сраммеры — это порода «серых мышей» в тёплых уголках контор.

— не нужны
В идеальном мире ни менеджеры, ни КуА как отдельные люди таки не нужны.
Но мы живем в реальном мире. И даже если отбросить появление стульев и новых компов, уход людей в отпуск (как это соотносится с релизами), есть еще и решение конфликтов между отделами (тимлид разработчиков не может указывать админу или КуА).
подавляющее большинство пытаются показать свою важность собирая безсмысленные митинги, делая ненужные питчи, навязывая странные процессы.
Качество (среднее по палате) менеджеров — это отдельная история.
есть еще и решение конфликтов между отделами (тимлид разработчиков не может указывать админу или КуА).
А как по твоему абстрактный менеджер будет разруливать конфликты между девелоперами и админами? Для этого нужен спец как минимум такого же технического уровня, а по уму это должен быть архитектор какой то, т.е. технарь, менеджерам здесь не место.
Качество (среднее по палате) менеджеров — это отдельная история.
Ну ты же сам решил не отрываться от реального мира. Может в нем в силу ряда физических законов невозможны хорошие менеджеры?
А как по твоему абстрактный менеджер будет разруливать конфликты между девелоперами и админами? Для этого нужен спец как минимум такого же технического уровня, а по уму это должен быть архитектор какой то, т.е. технарь, менеджерам здесь не место.
Нет. Для этого нужно чтобы его указания были восприняты обеими сторонами (грубо говоря власть).
А решение он может принять или же подбросив монетку, или имея технические навыки, или (самое правильное) сведя технические аргументы в ту плоскость где он ориентируется: как правило это что-то вроде сколько это может занять ресурсов сейчас и сколько в будущем и насколько это надо (бизнесу), и уже на основании этого принимать решение.
Может в нем в силу ряда физических законов невозможны хорошие менеджеры?
Ну по крайней мере я пару таких видел. Можно, конечное же, сослаться на ошибку эксперимента...
К слову, из тех что я видел, хорошие менеджеры как раз не лезли в техническую часть.
Нет. Для этого нужно чтобы его указания были восприняты обеими сторонами (грубо говоря власть).
Да, у архитектора есть полномочия быть последней инстанцией в принятии техцнических решений.
А решение он может принять или же подбросив монетку
что как бы и происходит и является абсолютным злом
или (самое правильное) сведя технические аргументы в ту плоскость где он ориентируется: как правило это что-то вроде сколько это может занять ресурсов сейчас и сколько в будущем и насколько это надо (бизнесу), и уже на основании этого принимать решение.
Это значит что весь процесс ограничен уровнем компетенции ПМ-а, что как бы суперглупо и неэфективно.
Зачастую такие случаи делятся на следующие группы:
— кто-то ленится, или не хочет брать на себя какие то риски и мутит воду пытаясь спихнуть проблемы на сторону, при этом этот кто-то конечно придумывает какие то причины обосновывая позицию. Здесь нужно разобраться что да как, для этого нужна техническая экспертиза и менеджер тут не у дел
— проблема нетривиальна для админа и тим лида, и они не могут ее решить из-за недостаточной квалификации, или потому-что не видят полного скоупа проекта/системы, здесь опять последнее слово должно быть за архитектом, и менеджер тут опять не удел
К слову, из тех что я видел, хорошие менеджеры как раз не лезли в техническую часть.
Ну а что эти менеджеры конкретно делали? Какие были их функции?
Да, у архитектора есть полномочия быть последней инстанцией в принятии техцнических решений.
Ну как бы странно, архитектор который может указывать что (и не мало важно когда)
должны делать админы или КуА. Помимо того архитектор — лицо заинтересованное.
Кстати, как вы будете решать проблемы между бизнесом и тем же архитектором?
Это значит что весь процесс ограничен уровнем компетенции ПМ-а, что как бы суперглупо и неэфективно.
Так или иначе все сведется к уровню компетенции тимлида, архитектора или ... СЕО.
кто-то ленится, или не хочет брать на себя какие то риски и мутит воду пытаясь спихнуть проблемы на сторону, при этом этот кто-то конечно придумывает какие то причины обосновывая позицию
Здесь нужно разобраться что да как, для этого нужна техническая экспертиза и менеджер тут не у дел
Нет. Тут надо просто понять есть ли риски и какие последствия они могут повлечь, а для этого не надо знать все, надо просто задавать правильные вопросы и внимательно слушать ответы (обеих сторон).
Надуманный пример: тимлид говорит — надо использовать линукс (приводит набор фич которые надо для разработки), админ говорит — надо использовать винду (приводит набор фич которые надо для внедрение, говорит что у них нет людей на линукс и тд). Все проблемы так или иначе решаются, но за разное время, то есть фичи линукса можно не использовать если переделать то-то, фичи винды можно реализовать таким-то способом, админов можно нанять.
Нужен человек который «подобьет баланс» и примет решение не забывая про то что есть троки и другие требования бизнеса.
Есть желание свалить это на архитектора — вперед, ведь он и так ничего не делает.
Аналогичную сказку могу придумать про КуА: когда они просто не успевают тестировать новое архитектурное решение, а архитектор считает что оно 100 пудов надо, хотя есть более кривое, но его можно сделать в срок.
Кто должен принимать решение? Архитектор?
проблема нетривиальна для админа и тим лида
Не «проблема», а конфликт. Оба человека имеют мнение и основания для этого мнения, зачастую оба правильные.
Ну а что эти менеджеры конкретно делали?
появление стульев и новых компов, уход людей в отпуск (как это соотносится с релизами), есть еще и решение конфликтов между отделами
Ну как бы странно, архитектор который может указывать что (и не мало важно когда)
должны делать админы или КуА.
Почему странно?
Так или иначе все сведется к уровню компетенции тимлида, архитектора или ... СЕО.
Ну да, только тимлид и архитектор как decision makers поднимают планку ограничений в технических вопросах на 100 пунктов в верх.
Нужен человек который «подобьет баланс» и примет решение не забывая про то что есть троки и другие требования бизнеса.
Ну в том то и дело, что ПМ послушает обоих, ничего не поймет, и подбросит монетку, или что еще хуже отдаст предпочтение тому с кем пиво по пятницам пьет. А архитект разрулит ситуацию более авторитетно и имеет больше возможностей урезонить сторону которая ошибается.
Аналогичную сказку могу придумать про КуА: когда они просто не успевают тестировать новое архитектурное решение, а архитектор считает что оно 100 пудов надо, хотя есть более кривое, но его можно сделать в срок.
Кто должен принимать решение? Архитектор?
Да, и нести ответственность за то что бы его решения были совместимы с жизненными реалиями.
Не «проблема», а конфликт. Оба человека имеют мнение и основания для этого мнения, зачастую оба правильные.
Конфликт я описал в первой группе случаев, во второй именно обьективные технические проблемы.
Кто должен принимать решение? Архитектор?
Да, и нести ответственность за то что бы его решения были совместимы с жизненными реалиями.
Ну так он и принял «все переделать нах». А проблемы бизнеса — это проблемы бизнеса. Задача архитектора качественная работающая система.
Ну в том то и дело, что ПМ послушает обоих, ничего не поймет
Это плохой ПМ. Хороший
или имея технические навыки, или (самое правильное) сведя технические аргументы в ту плоскость где он ориентируется
Ну так он и принял «все переделать нах». А проблемы бизнеса — это проблемы бизнеса. Задача архитектора качественная работающая система.
Ну это плохой архитектор витающий в облаках. Не нужны такие.
Это плохой ПМ. Хороший
или имея технические навыки,
Таких не бывает, слишком быстро устаревают знания и теряются навыки. А вот самодуры, думающие что они шарят, еще один бич индустрии.

или (самое правильное) сведя технические аргументы в ту плоскость где он ориентируется
Проблемы которые очевидны и можно перевести в плоскость понятную ПМ-у обычно настолько тривиальны что как бы не возникают.
Ну это плохой архитектор витающий в облаках. Не нужны такие.
Ок архитектор должен еще и планированием заниматься.
Добавляем жару:
Есть 2 задачи по 100 попугаев каждая. Ресурс 150 попугаев. Бизнес говорит что надо сделать обе (без вариантов).
Что решает архитектор? Или команда решает? Если команда то укажите это.

Планированием и распределением тасков как я уже писал занимается тимлид.
Формально задача конечно не имеет решения удовлетворяющего заказчика на 100%, а в жизни архитектор в силу своих скилов и опыта может захачить техническую часть задачи и вместе с тимлидом уложить ее решение в 150 попугаев.

Но отвлекаясь от высокоуровневых абстракций все же хотелось услышать твой опыт, твои хорошие нетехнические ПиЭмЫ делали что? Почему они хорошие?

а в жизни архитектор в силу своих скилов и опыта может захачить техническую часть задачи и вместе с тимлидом уложить ее решение в 150 попугаев.
А если получается 160? Ну не могут еще 10. Что делает тимлид (не архитектор, как выяснилось)?
Даю подсказку увеличивают мощности, то есть нанимают людей. И теперь у тимлида уже болит голова надо нанимать человека или брать фрилансера. А рабочее место как обеспечивать (банально решить какоу комп чуваку выделить)? Кто это решает тимлид или архитектор?
твои хорошие нетехнические ПиЭмЫ делали что? Почему они хорошие?
Они делали так чтобы все работало и их не было видно. Просто у тимлида не болела голова сколько людей надо нанять, куда их посадить, какое оборудование выделить, кому надо 32 Гб памяти, кому нет, кому надо мегакрутой монитор, а кому хватит просто хорошего дела (в 2-3 раза дешевле), когда и на какую сумму надо поднимать ЗП архитектору, на какую тамлиду, а на какую Раджешу которого год назад привезли Забухрынска, иногда как выбить кофе-машину и надо ли это для проекта.
Все что я перечислил, можно благополучно разбросать на 100500 разных человек. Вот только будет ли это эффективнее чем нанять ПМа?
А если получается 160? Ну не могут еще 10. Что делает тимлид (не архитектор, как выяснилось)?
Даю подсказку увеличивают мощности, то есть нанимают людей. И теперь у тимлида уже болит голова надо нанимать человека или брать фрилансера. А рабочее место как обеспечивать (банально решить какоу комп чуваку выделить)? Кто это решает тимлид или архитектор?
Башлянием бюджета на проект и регулирование пула людей, это глобальная таска, локальный ПиЭм тут тоже не причем.
Они делали так чтобы все работало и их не было видно. Просто у тимлида не болела голова сколько людей надо нанять, куда их посадить, какое оборудование выделить, кому надо 32 Гб памяти, кому нет, кому надо мегакрутой монитор, а кому хватит просто хорошего дела (в 2-3 раза дешевле), когда и на какую сумму надо поднимать ЗП архитектору, на какую тамлиду, а на какую Раджешу которого год назад привезли Забухрынска, иногда как выбить кофе-машину и надо ли это для проекта.
Все что я перечислил, можно благополучно разбросать на 100500 разных человек. Вот только будет ли это эффективнее чем нанять ПМа?
Эти все вопросы тоже эфективно решать в конторке централизовано и пиэм тут тоже в пролете, хотя как я уже говорил в попытке доказать свою полезность они пытаются перенять функции офис менеджера.
Башлянием бюджета на проект и регулирование пула людей, это глобальная таска, локальный ПиЭм тут тоже не причем.
А кто «при чем»? Кто пойдет выбивать еще бабла когда оно надо? Или кто предложит отдать переизбыток или раздать на премии? Лично ЦФО?
Эти все вопросы тоже эфективно решать в конторке централизовано и пиэм тут тоже в пролете, хотя как я уже говорил в попытке доказать свою полезность они пытаются перенять функции офис менеджера.
У меня 23-дюймовый ДЕЛЛ (16×9). Я хочу Эппл Синима (если они уже не производятся выберите другою дорогую модель). Аналогичная ситуация у моего соседа Васи.
От только я кодю серверсайд, а Вася дизайнер — офис-менеджер должна об этом знать? Она же должна решать кому давать кому не давать? Или ее работа заказать? Или надо нанять ЦентралДисплайОфицера?
С ЗП проще надо хорошо настроить отдел ХР (не тех которые рекрутеры) который помимо того чтобы вовремя еще и на «правильную» сумму поднимет ЗП всем кому надо, но это не всегда получается.
Иногда более эффективно иметь 1 ПМ на проект чем 100500 слаженно-работающих отделов.
Аналогичная ситуация, как я говорил ранее, с КуА: если разработка правильно поставлена, то КуА не нужны. Но это довольно сложно сделать.
в попытке доказать свою полезность
Я не отрицаю что часто ПМ не профессиональны, но это проблема конкретного случая или среднего уровня, а не института.

P.S. Кстати, в условиях аутсорса это еще один человек за которого можно получить бабло.

А кто «при чем»? Кто пойдет выбивать еще бабла когда оно надо? Или кто предложит отдать переизбыток или раздать на премии? Лично ЦФО?
Расскажи больше подробностей что означает выбивать, и у кого. У заказчика? У компании? Ответы могут варьироваться от ситуации к ситуации.
У меня 23-дюймовый ДЕЛЛ (16×9). Я хочу Эппл Синима (если они уже не производятся выберите другою дорогую модель). Аналогичная ситуация у моего соседа Васи.
От только я кодю серверсайд, а Вася дизайнер — офис-менеджер должна об этом знать?
Я не понимаю в чем проблема, в конторке у каждого есть какой то тайтл, кто программист а кто дизайнер, и ничто не мешает установить централизованную политику какое железо какому васе положено.
Аналогичная ситуация, как я говорил ранее, с КуА: если разработка правильно поставлена, то КуА не нужны. Но это довольно сложно сделать.
Куа это компромис между авотматизацией и временем разработчиков, и только.
Я не отрицаю что часто ПМ не профессиональны, но это проблема конкретного случая или среднего уровня, а не института.
Вот мой поинт что они всегда непрофессионалы, потому что нет такой профессии по сути, они ничем не занимаются.
Куа это компромис между авотматизацией и временем разработчиков, и только.
Аналогично и ПМ-ы, компромис между временем архитектора, тимлида, офис-менеджера, ХР, может еще кого-то.
Вот мой поинт что они всегда непрофессионалы, потому что нет такой профессии по сути, они ничем не занимаются.
Аналогично можно было бы сказать и про КуА. Но тут есть одна ошибка: нельзя так просто навешивать всеобщность.
Повторяю:
это проблема конкретного случая или среднего уровня, а не института.
Аналогично и ПМ-ы, компромис между временем архитектора, тимлида, офис-менеджера, ХР, может еще кого-то.
Ну да, только они делают работу хуже их всех(тех решения принимают хуже чем архитекты, за офисом следят хуже чем офис менеджеры, и дальше по списку), а ЗП хотят больше. Это типа как КУА экономят время программистов, но ЗП хотят больше программистов, в результате никакой экономии нету на самом деле.
Аналогично можно было бы сказать и про КуА. Но тут есть одна ошибка: нельзя так просто навешивать всеобщность.
Та нет, у КУА есть четкая роль и таски которые они должны делать, а ПиЭмы как то непохоже.
хуже
Не важно. Важно «достаточно хорошо» ли? И хороший Пм делает достаточно хорошо.
Это типа как КУА экономят время программистов, но ЗП хотят больше программистов, в результате никакой экономии нету на самом деле.
Так мало того что ЗП хотят как программисты (а то и больше), так не всегда экономят и еще и способствуют расхлябанности разработчиков.
Не важно. Важно «достаточно хорошо» ли? И хороший Пм делает достаточно хорошо.
Я вот возможно могу достаточно хорошо доску к потолку прибить. Но вряд ли это кому нибудь на самом деле нужно. Вот так и с менеджерами.

все верно все говорите (подбросил монетку, чтоб ответить).

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