Техлид+ПМ

Кесарю кесарево это называется

Ты бы хоть контекст какой-то дал.

поза плуга

Начальство бывает прямое и непосредственное, а руководство техническое и общее :) Под ПМом на большом проекте вполне может быть и несколько техлидов по разным направлениям и архитектор сбоку припека еще. «Дизаен-авторити» (ТМ)

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

69

и несколько техлидов по разным направлениям и архитектор

А если ПМ по совместительству пытается брать на себя часть функций архитектора, отодвигая немножко в сторону техлида, а архитектора грузить вопросами сертификации системы по ФСТЭК? Ну, чтобы быстрее сдать проект… Встречалось такое?

69

Тут рассматривается немного другая ситуация: 1+2.

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

Если ПМ в адеквате

Ну… скорее, в роли волка, вокруг которого расставлены флажки.

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

Под техлидом (Full-Stack Python Developer) - два верстальщика (один немного знает JS, другой - немного HTML).

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

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

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

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

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

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

А вы ПМ или техлид?

Двух капитанов на корабле не бывает, знаешь почему? А все игры в демократию и «матричная структура управления» размывают ответственность и приводят к борьбе за власть :)

«Матричные структуры управления - слабости:

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

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

Самый предельный пример сатиры над такой организацией — знаменитое совещание про «приклеить или прибить».

П — это продукт, проджект или пипл?

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

Ну вот смотри. Конкретная деталь.

ПМ видит, что всё хорошо. Стабильно работает, бенчмарки хорошие. Но есть требования ИБ - поставить Kaspersky Antivirus на прод-сервер. Причём, Kaspersky требует Debian’а определённой версии. А VipNet Java-plugin сертифицирован под Debian другой версии. Техлиду предлагается обновить прод до Debian более свежей версии и сделать apt-get upgrade. Техлид при этом выполнял основную часть по проектированию архитектуры системы, ИБ-шник чисто бумаги пишет. То есть, вроде как, подставляешься. В случае проблем - повесят на техлида, ПМ просто «попросил».

соответствия требованиям сертификации?

Если бы они ещё в явном виде были где-то написаны… Все т.з. такого рода - устные просьбы или мессаги в аське.

Он – Вася

Специалисты должны уметь идти на компромисс и иметь высокую квалификацию для решения возникших вопросов.

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

P.S. Надеюсь, было интересно.

Если бы они ещё в явном виде были где-то написаны… Все т.з. такого рода - устные просьбы или мессаги в аське.

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

решающим словом в этом конфликте должен быть как раз безопасник

В итоге, он как раз вышел сухим из воды.

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

Систему запустили в промышленную эксплуатацию, новое руководство получило диплом на всероссийском конкурсе.

А так вы там не дело делаете, а политизируете. Ну тогда и поделом, чё тут сказать то.

А так вы там не дело делаете, а политизируете.

Ну почему. Техлид от должности ПМ отказался, и просто сделал свою работу. После ПМ его уволил.

П — это продукт, проджект или пипл?

П - это самоназвание. Перспективный.

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

ПМа это вообще в основном роль медиатора

Да, в идеале - ПМ должен разруливать конфликты, принимать решения по приоритетам задач. В реальности же - верстальщик (JS+HTML) начинает выдвигать требования к REST API, которые рушат логику работы системы. ПМ дистанционируется от конфликта.

Да, эта частная проблема оказалась слишком политизированной. В нормальных компаниях всё спокойнее.

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

Я тебя что мозг не может отойти от парадигмы «хазяин-раб» ?

У тебя мозг не может в связное предложение, а ты про парадигмы вчехляешь. «Современные структуры» (ТМ) И про «хозяин-раб» точно так же — каша в голове и буззворды, а как принять решение так «надо воркшопы провести и мозговой штурм с экспертами в подкомитетах».

man матричная структура управления

а архитектора грузить вопросами сертификации системы по ФСТЭК?

Для сертификации по ФСТЭК нужно подготовить архитектурные документы: функциональную спецификацию, проект верхнего уровня, проект нижнего уровня. Кто должен это делать, если не архитектор?

если ПМ по совместительству пытается брать на себя часть функций архитектора

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

А если ПМ по совместительству пытается брать на себя часть функций архитектора, отодвигая немножко в сторону техлида, а архитектора грузить вопросами сертификации системы по ФСТЭК?

То очевидно их нужно поменять местами.

верстальщик (JS+HTML) начинает выдвигать требования к REST API, которые рушат логику работы системы

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

Собственно, как получилось, что техлид и архитектор это сглотнули?

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

Ну и крысятник у вас там.

Техлид от должности ПМ отказался, и просто сделал свою работу. После ПМ его уволил.

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

Он – Вася

Кстати, диаграмма Ганта получилась большая. Планировалась премия от главы региона.

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

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

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

Давайте, ткните мне в любую коммерчески успешную контору, и я покажу, почему их код — говно, и они могли сделать намного лучше. Первыми в списке идут Microsoft, Oracle, SAP, IBM, и так далее. «Google» — скажете вы мне, «там же собрали всех гиков с планет». Да, собрали. Будь их воля — они бы пердолили консольку и пилили бы бесконечные проекты сомнительной прикладной ценности. Чем, в общем-то, в большинстве своем они сейчас и занимаются. Но, надо заметить, им жестко бьют по рукам, их внимание фокусируют на C++/Java/Python, а теперь и Go — никаких там лиспов, окамлей, хаскелей, смолтока, и прочей лабуды. Правда, теперь есть Go. Почему же гугль не может тупо сделать ЯП под свои задачи? По каким-то загадочным причинам большинство пердоликов не понимают человеческую психологию, а потому не способны создать удобный инструмент человеку от пердоли. Пердоля создает инструмент для себя, то есть, сложный, много возможностей выстрелить себе в ногу, требующий обязательного долгого чтения документации и даже сорцов.

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

«Матричные структуры управления - слабости:
Фирмы, внедрившие матричные структуры управления часто сталкиваются с матричным конфликтом – недопонимание в обязанностях руководства

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

У меня есть пример одного банка, в котором встретились два сотрудника: одни год из года перекладывает свои бумажки и выполняет должностные инструкции, другой заметил однообразность работы и решил создать ПО для автоматизации задачи. Тогда первый сотрудник говорит второму «ты что, дурак? Зачем ты лишаешь себя работы?».

Я убежден в том, что грамотные кадровый подбор и решения на местах весят намного больше, чем грамотно принимаемые централизованные решения. Централизация нужна, бесспорно, она тоже отыгрывает свою роль, но если у тебя в оркестре всем сотрудникам медведь потоптался по ушам, то их бесполезно организовывать. А когда ты грамотно набрал сотрудников, то ты уже 80% организационных задач выполнил — осталось решить 20%.

Самый предельный пример сатиры над такой организацией — знаменитое совещание про «приклеить или прибить»

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

А при чем тут Агила?

То, что ты пишешь называется технологический шовинизм.

То, что ты пишешь называется технологический шовинизм

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

Как ты можешь оценить профпригодность менеджмента если ты не с той стороны?

Как ты можешь оценить профпригодность менеджмента если ты не с той стороны?

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

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

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

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