Comments 71
Что делать, если начальство не наделяет полномочиями, однако спрашивает с ПМ за результат, который он должен безо всяких полномочий выжать из команды?
Выход есть всегда и везде. Если совсем не пошло — уволиться.
Но я видел немало примеров, когда менеджер проекта без особой власти на личной харизме организовывает команду. Да, это не совсем правильно. Но все люди делятся на два типа.
- Те, кто что-то делает.
- Те, кто ищут причины почему не получилось.
Я тоже видел, но это если команда адекватная — да вариант, на личных качествах вывозить.
Но когда команда токсична и в целом враждебна, а начальству все равно — я считаю что пустой номер пытаться головой пробить стенку. Ради чего?
Вопрос в том, что делать когда ПМ тоже токсичен для команды. Ведь не бывает дыма без огня, обычно люди проявляют негатив не просто так, а по делу, или как минимум имеют повод.
Спорю. Есть просто неприятие чужих — чужих, т.е. только пришедших в команду где люди вместе работают уже какое то время, чужих — представителей других профессий, с другим бэкграундом, просто выглядящих по другому.
Менеджер может быть токсичным — но такие в этой профессии долго не задерживаются, тут коммуникации ключ.
Да кстати
Это было серьезно сказано? Давайте не будем мемами из вк разговаривать.
Во-первых люди не делятся на 2 категории. Прежде чем что-то делать — надо для начала подумать. Потом делать. Думать почему не получилось (или получилось) тоже надо всегда — человек среди прочего, отличается от животных способностью прикидывать возможные последствия, а также учитывать собственный опыт.
У меня ощущение что вы просто увидели себя описанной команде, и пытаетесь всеми правдами защитить её, и найти повод все свалить на условного ПМ-а. Поправьте если я ошибаюсь.
Менеджер может быть токсичным — но такие в этой профессии долго не задерживаются, тут коммуникации ключ.
Да кстати
Но все люди делятся на два типа.
Те, кто что-то делает.
Те, кто ищут причины почему не получилось.
Это было серьезно сказано? Давайте не будем мемами из вк разговаривать.
Во-первых люди не делятся на 2 категории. Прежде чем что-то делать — надо для начала подумать. Потом делать. Думать почему не получилось (или получилось) тоже надо всегда — человек среди прочего, отличается от животных способностью прикидывать возможные последствия, а также учитывать собственный опыт.
У меня ощущение что вы просто увидели себя описанной команде, и пытаетесь всеми правдами защитить её, и найти повод все свалить на условного ПМ-а. Поправьте если я ошибаюсь.
Вот вы говорите — неприятие чужих. Но ведь задачи руководителя как раз: установить авторитет, установить правила, стать своим. Если он не может этого сделать "неформально" — зачастую формальные кнуты и пряники не помогут. Сколько не давай полномочий такому человеку — его мало кто будет воспринимать как главного.
Поддержу комментарий ниже. Если руководитель не может наладить контакт, то сколько полномочий не давай, это не помешает команде собатировать решения. Формально придраться не получится, а результата реального не будет. Либо придётся пару голов снести, что опять же может ещё больше враждебности вызвать, либо самому признать свою проф непригодность и уйти в отставку.
Повод известен: «Подождите до следующего полугодия, у нас своя работа есть».
Есть менеджеры-пилоты (КВС), а есть менеджеры-капитаны морских кораблей. Положение последних очень зависимо от авторитета в команде — если на корабле бунт — то сколько не дергай ручку машинного телеграфа — в машинном отделении и ухом не поведут. А именным пистолетом в трюм грозить чревато ;). Для КВСов все не так трагично — штурвал, педали и сектор газа всегда под его контролем, и в крайнем случае, задача будет выполнена и без команды. КВСы — это ПМы из техлидов, а капитаны морских кораблей — это ПМы, пришедшие в IT из других индустрий. Команда же обычно любит выходцев из своей профессии, или как минимум просто умных людей (например, физиков со стороны примет спокойно) поэтому глупый капитан «не из наших» 100% обречён на провал, независимо от ПМБОКов, скрамов, методик парирования рисков, CI/CD, TDD итд практик.
И ещё — команда должна понимать, что если что — ПМ их не сдаст, свалив всю вину перед клиентом или начальством. Лучший вариант — когда будут знать, что наоборот — прикроет, самортизировав реализовавшийся риск на себе. Если такое есть — то и в ответ будет не саботаж, а энтузиазм.
И ещё — команда должна понимать, что если что — ПМ их не сдаст, свалив всю вину перед клиентом или начальством. Лучший вариант — когда будут знать, что наоборот — прикроет, самортизировав реализовавшийся риск на себе. Если такое есть — то и в ответ будет не саботаж, а энтузиазм.
Интересная и чёткая концепция.
Прикрывать своих мне кажется обязательным условием. Любой руководитель который этого не делает — обречён на провал.
Прикрывать нужно тех, кто приносит пользу, которая не очевидна для вышестоящих. А остальных по ситуации — возможно, что нужно так же легко увольнять, как и прикрывать. Не стоит вести слишком много игр "кто на чьей стороне", больше нужно думать о том деле, которое делаем.
Частично соглашусь. Да, есть которых надо смело увольнять, и очевидно что нужно думать о деле — я этого не отрицал, мы обсуждаем другой сегмент работы менеджера, никто не говорит посвящать этому 100% времени и ресурсов. Без результата понятно это все имеет мало значения.
Прикрывать нужно всех имхо — а потом самому разбираться, подчиненных должен наказывать прямой руководитель, не тот кто выше. Иначе остальные будут думать что вот сейчас пока мы все делаем — он добрый и защищает, а как только косяк — отдаст на съедение высокому начальству.
И мудрый руководитель менеджера это знает — он не начинает разносить сам, а поручает это прямому начальнику провинившегося.
Прикрывать нужно всех имхо — а потом самому разбираться, подчиненных должен наказывать прямой руководитель, не тот кто выше. Иначе остальные будут думать что вот сейчас пока мы все делаем — он добрый и защищает, а как только косяк — отдаст на съедение высокому начальству.
И мудрый руководитель менеджера это знает — он не начинает разносить сам, а поручает это прямому начальнику провинившегося.
gleb_l Это действительно интересный феномен психологии разработчиков: люди, которые привыкли знать что-то одно глубоко часто либо чувствуют себя экспертами во всех областях сразу (к счастью, встречается крайне редко), либо игнорируют экспертизу в тех областях знаний, от которых далеки (часто). Как Вы лично предпочитаете доносить ценность?
Разработчики довольно часто думают, что руководитель не нужен, они все делают сами. Все потому, что его работа в основном не имеет "материального " результата. Однако, если правильно объяснить команде, в чем собственно состоят обязанности руководителя, и для чего он делает те или иные вещи — будет значительно проще.
Все так.
Только вот как раз моя статья о том — что будь ты хоть лучшим оратором и психологом — у объяснения две стороны, кто объясняет, и кто слушает (или не слушает). И бывают ситуации когда слушающим просто неинтересно это все. Они не сомневаются в своей правоте и не хотят никаких аргументов слышать. У человека два состояния когда его пытаются чему то научить (что-то объяснить) — либо он слушает и впитывает, либо он уходит в оборону и ничего не воспринимает. Я выше уже писал — когда люди адекватные, с ними можно работать даже если есть различия во мнениях, им можно объяснить, с ними можно наладить рабочий контакт. Когда настроены консервативно и закрыто — это почти невозможно, нельзя заткнувшему уши что-то объяснить, это его выбор тебя не слушать.
Вот как раз тут я не вижу смысла биться головой и пытаться пробить стенку.
Все вышесказанное относится ко всем в целом — я видел случае когда наоборот, команда что-то пытается донести менеджеру, а он ни в какую не слушает, и делает по своему и получается дичь. Послы статьи в том что команда находится в менее уязвимом положении — у нее только начальники, один плохой — идешь к следующему, эскалируешь. А у менеджера с двух сторон могут прилететь проблемы, и виноват будет он.
Только вот как раз моя статья о том — что будь ты хоть лучшим оратором и психологом — у объяснения две стороны, кто объясняет, и кто слушает (или не слушает). И бывают ситуации когда слушающим просто неинтересно это все. Они не сомневаются в своей правоте и не хотят никаких аргументов слышать. У человека два состояния когда его пытаются чему то научить (что-то объяснить) — либо он слушает и впитывает, либо он уходит в оборону и ничего не воспринимает. Я выше уже писал — когда люди адекватные, с ними можно работать даже если есть различия во мнениях, им можно объяснить, с ними можно наладить рабочий контакт. Когда настроены консервативно и закрыто — это почти невозможно, нельзя заткнувшему уши что-то объяснить, это его выбор тебя не слушать.
Вот как раз тут я не вижу смысла биться головой и пытаться пробить стенку.
Все вышесказанное относится ко всем в целом — я видел случае когда наоборот, команда что-то пытается донести менеджеру, а он ни в какую не слушает, и делает по своему и получается дичь. Послы статьи в том что команда находится в менее уязвимом положении — у нее только начальники, один плохой — идешь к следующему, эскалируешь. А у менеджера с двух сторон могут прилететь проблемы, и виноват будет он.
Понимаете, ведь так можно любую правильную ситуацию объяснить- команда неадекватная, токсичная и т.д. А ведь повсеместно именно управленческие просчёты и недоработки оборачиваются сверхурочными (по ночам перед релизом), конфликтами (делай быстрее, пусть даже лажу) и так далее. Не отрицая в полной мере посыла статьи, скажу — у руководителя работа такая, он ответственное лицо, валить все на команду нельзя.
правильную — читать провальную
Да, я согласен. Больше скажу — огромная часть провалов в бизнесе в целом — это плохое руководство. Но я не об этом сейчас.
Во-первых команде не следует быть наивной и полагать что все будет красиво и идеально, никаких переработок — все рады бы так, но это так не работает, всегда есть фактор неопределенности, есть неожиданные вещи. Вопрос лишь — заморачивается менеджер тем чтобы с этим бороться и защищать своих разработчиков от переработок и прочих негативных явлений, или ему плевать на людей — он думает о премии. Видел много таких.
Но статья не об этом — статья о том, что попробуйте стать на позицию этого менеджера который между двух огней находится, и попытаться разрулить такую ситуацию.
Во-первых команде не следует быть наивной и полагать что все будет красиво и идеально, никаких переработок — все рады бы так, но это так не работает, всегда есть фактор неопределенности, есть неожиданные вещи. Вопрос лишь — заморачивается менеджер тем чтобы с этим бороться и защищать своих разработчиков от переработок и прочих негативных явлений, или ему плевать на людей — он думает о премии. Видел много таких.
Но статья не об этом — статья о том, что попробуйте стать на позицию этого менеджера который между двух огней находится, и попытаться разрулить такую ситуацию.
Я в целом посыл статьи понимаю, и согласен что ПМу тяжело живётся. К сожалению, я в таких ситуациях бывал. Я — тот самый начальник, который через голову ПМ пытается решить проблему напрямую с командой(( И что в этот момент чувствует ПМ я прекрасно понимаю. Но у меня свои задачи и некоторые проблемы решаются только так.
Я же не отрицаю что такие случаи бывают — иногда нужно вмешиваться, но это исключительные случае. В целом имхо нужно строить иерархию — если есть ПМ, то его нужно подобрать хорошо и дать ему полномочия руководить. И команде объяснить что вот ваш новый ПМ, любить, жаловать и делать таски.
Если дать ему полномочия, он станет вас отвлекать, а потом вас подсидит.
А если не дать полномочий, от не будет вам мешать.
А если не дать полномочий, от не будет вам мешать.
Менеджер без полномочий это не менеджер, а координатор. Насчет отвлекать — чем?
Насчет подсидеть — вы это серьезно?
Насчет подсидеть — вы это серьезно?
Всё из жизни. Отвлекать вопросами, которые мешают.
Оставим подсиживание на совести тех кто это делает. В целом это реальный риск да — но он меньше той пачки рисков которые появляются когда не делегируешь. Один человек может сделать не очень много. 24 часа в сутках у него всего.
Когда у него нет полномочий — он отвлекает гораздо больше, решениями. Он ничего сам решить не уполномочен, он с каждым бегает к руководителю.
А вопросы — причем тут они вообще? Менеджер задает вопросы руководителю только тогда когда это уровень руководителя решать их, или когда информация ему недоступна, а руководителю доступна.
Отвлекать вопросами, которые мешают.
Когда у него нет полномочий — он отвлекает гораздо больше, решениями. Он ничего сам решить не уполномочен, он с каждым бегает к руководителю.
А вопросы — причем тут они вообще? Менеджер задает вопросы руководителю только тогда когда это уровень руководителя решать их, или когда информация ему недоступна, а руководителю доступна.
Когда у ПМ нет полномочий — он вообще не отвлекает, потому что не имеет полномочий бегать к руководителю.
Вопросы вот при чём: руководитель не будет тратить время на эти вопросы. Ему некогда, 24 часа в сутках у него всего.
Вопросы вот при чём: руководитель не будет тратить время на эти вопросы. Ему некогда, 24 часа в сутках у него всего.
Любой сотрудник может подойти к руководителю с вопросом, в силах руководителя отвечать или нет. Это его право, полномочия непричем.
Ситуация которую вы описываете — это когда ПМ-а вообще не должно быть. Руководитель сам руководит проектом. Если же он взял на это ПМ-а, то он ему должен делегировать полномочия.
Если взял координатора — то не делегирует полномочия, а прописывает ему координаторские обязанности, не буду углубляться.
А отвечать на вопросы, и всеми прочими способами руководить на своем уровне — это как раз то чем он занимается свои 24 часа. Не общаясь с подчиненными руководить невозможно.
Ситуация которую вы описываете — это когда ПМ-а вообще не должно быть. Руководитель сам руководит проектом. Если же он взял на это ПМ-а, то он ему должен делегировать полномочия.
Если взял координатора — то не делегирует полномочия, а прописывает ему координаторские обязанности, не буду углубляться.
А отвечать на вопросы, и всеми прочими способами руководить на своем уровне — это как раз то чем он занимается свои 24 часа. Не общаясь с подчиненными руководить невозможно.
Простите, наверное, я вас несколько запутал. Попробую объяснить.
Руководитель не руководит проектом, потому что не успевает. Он взял на этот проект ПМ, чтобы скинуть проблему. Руководитель не станет отвечать на вопросы, в том числе не станет делегировать полномочий.
Координаторские обязанности ПМ в том, чтобы исполнить проект. И первая обязанность ПМ — получить ресурсы для проекта так, чтобы не мешать руководителю (не задавая ему никаких вопросов) и не мешать сотрудникам (не обращаясь к ним никогда).
Руководитель не руководит проектом, потому что не успевает. Он взял на этот проект ПМ, чтобы скинуть проблему. Руководитель не станет отвечать на вопросы, в том числе не станет делегировать полномочий.
Координаторские обязанности ПМ в том, чтобы исполнить проект. И первая обязанность ПМ — получить ресурсы для проекта так, чтобы не мешать руководителю (не задавая ему никаких вопросов) и не мешать сотрудникам (не обращаясь к ним никогда).
От команды зависит. В принципе все не дураки и понимают зачем он делает те или иные вещи. Объяснять нужно что эти вещи в интересах команды в том числе.
Команда — всегда отражение руководителя. Иногда очевидное, иногда отраженное в кривом зеркале, но всегда относительно достоверно соответствующее. Под руководителем в данном контексте я понимаю не линейного менеджера, которого поставили руководить разработчиками, а то самое "начальство", которое задаёт тон рабочих процессов, то, которое имеет непосредственное влияние на климат в коллективе, которое имеет рычаг нематериальной мотивации. Поэтому дальше я буду говорить исключительно о руководителях ПМа/лида. Работа линейного менеджера всегда во многом будет состоять из необходимости усидеть на двух стульях — работа такая. Есть компании с собственниками и менеджерами, которые подойдут одному человеку, претендующему на позицию управленца низшего звена, но для другого будут казаться неадекватами, и это тоже нормально. Вопрос в базовых установках, целях, привычных способах их достижения. Стоит ли дальше искать "свое идеальное место" — вопрос, который каждый решает для себя сам и во многом зависит от конкретной ситуации, однако тянуть в мир менеджмента программистские установки "уволюсь, а после меня хоть потоп" — как минимум не профессионально. Потому что мы живём в социуме, идеальных мест нет, а даже работа начинающего менеджера — это принципиально другая степень ответственности.
Уточнить хочу
вы это в моей публикации увидели?
Если так — то во-первых я никогда не был программистом. Во-вторых вы видимо что-то не так поняли. Мой посыл был не про потоп, а про то что в описанных условиях, я считаю работать — разрушать себя, и впустую тратить время. И после ухода никакого потопа не произойдет явно — потому что в описанных условиях от этого менеджера особо ничего не зависит, ему как следует ничего не делегировали, и со стороны работодателя было ошибкой его нанимать, так как он явно не хочет ему ничего делегировать, соответственно этой позиции быть не должно.
Плюс — конкретно в примере из собственной практики — я сделал все от меня зависящее чтобы ситуацию решить, и с командой и с начальством. Не помогло.
И я не склонен идеализировать места — это как раз программистский подход правильно-неправильно, есть подходящие места, и подходящее начальство. Это завязано плотно и на личностях и на корпоративной культуре. Думаю не будете отрицать что все таки выбирать надо, и работать надо там где комфортно. А не терпеть стиснув зубы — чтоб потопы не оставлять.
Безусловно. Был и такой опыт, но мое личное наблюдение — что неадекватность эта часто граничит с непрофессионализмом этих самых собственников. При этом по моему мнению любому руководителю низшего звена — профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы, и не впечатляется его «харизмой». Но бывают и такие профессионалы-хариматики, которые и феерят и дело делают — с ними работать вполне себе можно, если абстрагироваться от их приколов.
однако тянуть в мир менеджмента программистские установки «уволюсь, а после меня хоть потоп» — как минимум не профессионально.
вы это в моей публикации увидели?
Если так — то во-первых я никогда не был программистом. Во-вторых вы видимо что-то не так поняли. Мой посыл был не про потоп, а про то что в описанных условиях, я считаю работать — разрушать себя, и впустую тратить время. И после ухода никакого потопа не произойдет явно — потому что в описанных условиях от этого менеджера особо ничего не зависит, ему как следует ничего не делегировали, и со стороны работодателя было ошибкой его нанимать, так как он явно не хочет ему ничего делегировать, соответственно этой позиции быть не должно.
Плюс — конкретно в примере из собственной практики — я сделал все от меня зависящее чтобы ситуацию решить, и с командой и с начальством. Не помогло.
И я не склонен идеализировать места — это как раз программистский подход правильно-неправильно, есть подходящие места, и подходящее начальство. Это завязано плотно и на личностях и на корпоративной культуре. Думаю не будете отрицать что все таки выбирать надо, и работать надо там где комфортно. А не терпеть стиснув зубы — чтоб потопы не оставлять.
Есть компании с собственниками и менеджерами которые подойдут одному человеку, претендующему на позицию управленца низшего звена, но для другого будут казаться неадекватами, и это тоже нормально.
Безусловно. Был и такой опыт, но мое личное наблюдение — что неадекватность эта часто граничит с непрофессионализмом этих самых собственников. При этом по моему мнению любому руководителю низшего звена — профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы, и не впечатляется его «харизмой». Но бывают и такие профессионалы-хариматики, которые и феерят и дело делают — с ними работать вполне себе можно, если абстрагироваться от их приколов.
Не буду утомлять Вас и читателей очередным длинным комментарием, поэтому отвечу кратко: первое, вся Ваша статья и есть бесконечное нытье о несправедливости мира; второе, считать людей дураками
основываясь лишь на несовпадении ценностей и мифических "недочетах" характеризует глупо только Вас; в-третьих, вот это все "профессионалу с такими работать не захочется" — нафиг таких условных "профессионалов", за которых все сделать надо в организационном плане.
Правильно ли я понял вашу реплику? Вы хотите сказать, что профессионал должен сам организовать свой труд, то есть арендовать рабочее место, купить оборудование, оплатить рабочее время своих коллег?
Нет, вероятно, Вы поняли меня ошибочно. Я имею в виду, что никому не нужен специалист, неспособный организовать работу и коммуникацию внутри/с собственной командой, а претендующий лишь на администрирование уже выстроенных процессов, при этом ещё желающий чтобы его собственный авторитет был навязан "сверху".
Ясно, спасибо.
Мне сперва показалось, что «организовать работу» и есть арендовать рабочие помещения, купить оборудование, платить за работу. Но если всё это уже сделано, если вся работа уже организована, процессы уже выстроены, — тогда остальные задачи решить легко.
Мне сперва показалось, что «организовать работу» и есть арендовать рабочие помещения, купить оборудование, платить за работу. Но если всё это уже сделано, если вся работа уже организована, процессы уже выстроены, — тогда остальные задачи решить легко.
Тоже коротко:
ваш комментарий аналогично в таком случае, аргументы? Мне кажется нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте. Это раз. Я вполне себе неплохо разбираюсь в том что говорю, и главное — аргументирую это. Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
Не условных. Почему нафиг? Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами? Разработка софта и разработка бизнес-процессов это разное, нет?
И главное — чего ради профессионал будет приходить в компанию где условно нет четкой организации процесса, и пытать что-то изменить? Зачем? Почему ему не хотеть нормальных условий работы, с нормальными процессами, с нормальным начальством? У него как правило есть профессиональное самолюбие — потому что он потратил годы на то чтобы достичь этого уровня, а тут он по вашей логике должен приходить и тратить время не на свои непосредственные обязанности а на поиск того кто отвечает за какой-то вопрос, или на то чтобы отбивать от нападков коллег которые лезут в его работу. Чего ради?
бесконечное нытье о несправедливости мира
ваш комментарий аналогично в таком случае, аргументы? Мне кажется нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
основываясь лишь на несовпадении ценностей и мифических «недочетах» характеризует глупо только Вас
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте. Это раз. Я вполне себе неплохо разбираюсь в том что говорю, и главное — аргументирую это. Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
в-третьих, вот это все «профессионалу с такими работать не захочется» — нафиг таких условных «профессионалов», за которых все сделать надо в организационном плане.
Не условных. Почему нафиг? Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами? Разработка софта и разработка бизнес-процессов это разное, нет?
И главное — чего ради профессионал будет приходить в компанию где условно нет четкой организации процесса, и пытать что-то изменить? Зачем? Почему ему не хотеть нормальных условий работы, с нормальными процессами, с нормальным начальством? У него как правило есть профессиональное самолюбие — потому что он потратил годы на то чтобы достичь этого уровня, а тут он по вашей логике должен приходить и тратить время не на свои непосредственные обязанности а на поиск того кто отвечает за какой-то вопрос, или на то чтобы отбивать от нападков коллег которые лезут в его работу. Чего ради?
ваш комментарий аналогично в таком случае, аргументы?
Вести спор на подобном уровне общения близком к киданию в оппонента собственными экскрементами смысла не вижу, Вы в очередной раз выставляете себя в невыгодном свете, не более. Впрочем, решать Вам. Что касается аргументации — я её привёл, это моё мнение, подкрепленное определённым опытом, не более, чем и Ваше.
нытье это все-таки что-то невнятно неаргументированное, и явно не на хабре.
Неплохая попытка воззвать к сообществу, обозначив свою принадлежность к "клубу", но нет.
Тут уж совсем — где я кого назвал дураками? Не перевирайте и не абсурдизируйте
Во-первых, я писал не "называете дураками", а "считать людей дураками", во-вторых все есть в Вашем тексте и комментариях.
профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы
огромная часть провалов в бизнесе в целом — это плохое руководство
когда команда токсична и в целом враждебна, а начальству все равно
И так далее. Но продолжим.
Насколько разбираетесь в материи вы — не знаю, то что вы пишете очень спорно.
Тонкий укол, не правда ли? Но правда в том, что на любую проблему есть несколько точек зрения, одна и та же ситуация будет по-разному восприниматься разными людьми. Я рад, что Вы считаете мою точку зрения спорной. Это означает, что я сумел донести именно то, что хотел, именно то, что вызывает у Вас несогласие.
Почему профессионал к примеру в IT должен приходить на позицию допустим разработчика софта и заниматься процессами?
Ваша статья же о менеджерах проектов, разве нет? И все обсуждение было об управлении. Не передергивайте, пожалуйста.
Не условных. Почему нафиг?
Потому что нечего делать на менеджерских позициях, которые предполагают управление, человеку, который хочет
В целом имхо нужно строить иерархию — если есть ПМ, то его нужно подобрать хорошо и дать ему полномочия руководить. И команде объяснить что вот ваш новый ПМ, любить, жаловать и делать таски.
На этом откланиваюсь, я сказал все, что хотел.
Иногда срабатывает разговор с начальством в тоне "или даёте мне полномочия, или всякую ответственность за результат я с себя снимаю, что-то будет делаться, но целей проекта мы вряд ли достигнем"
Примерно так я и сделал когда попал в такую ситуацию. И формулировки очень похожи — начальство такого поворота не ожидало, в той организации прямо говорили очень немногие. Не помогло — ушел, и рад. Ибо нашел и адекватное начальство, и нормальные команды, и перспективы и всё.
Ну собственно такие вещи и говорятся чтобы понять стоит оставаться или уходить. Ну если нет желания нести ответственность за то, чем управлять право тебе официально
не предоставлено.
Не, разные варианты бывают в жизни, мне, например, как-то ПМ платил из своего кармана за свехурочные, поскольку ему таких полномочий платить за счёт бюджета проекта не дали.
Не, разные варианты бывают в жизни, мне, например, как-то ПМ платил из своего кармана за свехурочные, поскольку ему таких полномочий платить за счёт бюджета проекта не дали.
На кризисных проектах и у меня возникает иногда такое желание, правда как правило разруливается все без таких методов. Но когда хочешь чтобы разработчики чувствовали себя нормально и получали за свой труд — это естественно.
ПМ — плохой если не умеет общаться и договариваться. Если думает что разрабы ему что-то должны, а сам по факту ничего не отстреливает в продукте, и не берет ответственность в конечном итоге за созданный продукт.
Как-то все просто у вас получается — умеет не умеет, делает не делает. Черно-белая картина. Общаться и договариваться это софт-скилл, он не работает безотказно как АК. Есть люди которые просто не слушают, и договориться с ними нельзя от слова совсем. Таких всегда есть определенный процент, и с ними проще просто не связываться чем тратить время.
И такие люди есть как среди начальства и подчиненных, плюс зависит очень сильно от среды — где как на каких ролях это все происходит. Именно про это я написал.
Команда лично ему ничего не должна — она должна компании на которую работает, выполнять обязательства по трудовому договору, в котором обычно написано что поставленные таски нужно делать, менеджеру подчиняться.
Если менеджер не выстреливает в продукте (хотя я говорил про проекты, не про продукты, это разное) — то ему там в целом нечего делать, про ответственность точно также.
И такие люди есть как среди начальства и подчиненных, плюс зависит очень сильно от среды — где как на каких ролях это все происходит. Именно про это я написал.
Команда лично ему ничего не должна — она должна компании на которую работает, выполнять обязательства по трудовому договору, в котором обычно написано что поставленные таски нужно делать, менеджеру подчиняться.
Если менеджер не выстреливает в продукте (хотя я говорил про проекты, не про продукты, это разное) — то ему там в целом нечего делать, про ответственность точно также.
Если ПМ не умеет (или не хочет) разговаривать с коллегами, то это лично его проблемы. Разрабы чувствуют, что менджер не тянет как лидер, и будет только хуже для всех, и да, такому менеджеру не место в этой команде, тут я с вами полностью согласен!
ПМ берет ответственность за всё — проект, продукт, и тд., или вы хотите так — эту часть задания делала моя команда мы молодцы, а этот соседний отдел — они козлы. Но по факту все плывут в одной лодке. Нет, это так не работает. Надо общаться! Не способны договариваться, идите ищите «иллюзорную компанию» с единорогами, но только вы там наверное не будете нужны, по той причине, что не способны общаться.
ПМ берет ответственность за всё — проект, продукт, и тд., или вы хотите так — эту часть задания делала моя команда мы молодцы, а этот соседний отдел — они козлы. Но по факту все плывут в одной лодке. Нет, это так не работает. Надо общаться! Не способны договариваться, идите ищите «иллюзорную компанию» с единорогами, но только вы там наверное не будете нужны, по той причине, что не способны общаться.
Еще раз проще: менеджер да, должен уметь общаться, это его ключевой навык. Он должен нести ответственность — это ключевое зачем он есть вообще. НО
Ответственность не за все. О чем вы вообще? Он несет ответственность за вверенный ему проект или продукт, если он лезет со своей ответственностью куда-то еще — его оттуда выпроводят, потому что занимайся своим делом. Да, он должен при этом взаимодействовать с другими, но взаимодействовать, не нести ответственность за их продукт, проект или функцию.
Дальше — прекращайте смотреть на все в формате черное-белое, мир несколько сложнее. Общаться уметь это не значит что в 100% случаев переговоры проходят успешно. Это утопия.
Что значит если не умеете договориться то идите ищите? Вы сами бизнес-переговоры вели? С командой в кризисной ситуации общались? У меня возникает ощущение что нет — вы слишком идеализируете. На подобии — ты либо попадаешь белке в глаз, либо вообще стрелять не умеешь.
У любого крутого коммуникатора бывают фейлы. Потому что он не может просчитать любого человека и с ходу воздействовать на его него так, чтобы тот его понял. Есть люди с которыми договориться в целом невозможно — потому что упертые и никого не слушают. Это раз.
Два — когда с тобой принципиально не хотят иметь дело по независящим от тебя причинам — навыки в общении не помогут. Потому что когда у тебя нет машины, навыки вождения не помогают.
Ответственность не за все. О чем вы вообще? Он несет ответственность за вверенный ему проект или продукт, если он лезет со своей ответственностью куда-то еще — его оттуда выпроводят, потому что занимайся своим делом. Да, он должен при этом взаимодействовать с другими, но взаимодействовать, не нести ответственность за их продукт, проект или функцию.
Дальше — прекращайте смотреть на все в формате черное-белое, мир несколько сложнее. Общаться уметь это не значит что в 100% случаев переговоры проходят успешно. Это утопия.
Что значит если не умеете договориться то идите ищите? Вы сами бизнес-переговоры вели? С командой в кризисной ситуации общались? У меня возникает ощущение что нет — вы слишком идеализируете. На подобии — ты либо попадаешь белке в глаз, либо вообще стрелять не умеешь.
У любого крутого коммуникатора бывают фейлы. Потому что он не может просчитать любого человека и с ходу воздействовать на его него так, чтобы тот его понял. Есть люди с которыми договориться в целом невозможно — потому что упертые и никого не слушают. Это раз.
Два — когда с тобой принципиально не хотят иметь дело по независящим от тебя причинам — навыки в общении не помогут. Потому что когда у тебя нет машины, навыки вождения не помогают.
У меня возникает ощущение что нет — вы слишком идеализируете. На подобии — ты либо попадаешь белке в глаз, либо вообще стрелять не умеешь.
Да, это ровно так. Если ПМ не может оценить постоянно меняющуюся ситуацию и корректировать работу вверенного отдела, то фуфельный он ПМ. Где-то быть настойчивым и проявить характер, где-то поблагодарить и похвалить. А если разрабы ему ещё на момент начального виденья говорят — «Ваш план — *овно » а он не прислушивается, то как говориться — сам дурак. И не надо ждать хорошего результата.
Есть люди с которыми договориться в целом невозможно — потому что упертые и никого не слушают. Это раз.Обычно люди упертый, когда считают что собеседник слабо ориентируется в том что говорит, и хочет навязать выполнение какой-то дичи.
Потому что когда у тебя нет машины, навыки вождения не помогают.Если у тебя нету машины, но тебе нужно общаться с водителем автомобиля (это твоя обязанность), иди и учи азы вождения и мат. часть по комплектации легкового автомобиля, можешь там пойти в гоночки поиграть (мы ведь не про вождения разумеется сейчас =) ) иначе на кой ты как собеседник вообще данному водителю, он и без тебя знает как данный автомобиль поедет.
Да, это ровно так. Если ПМ не может оценить постоянно меняющуюся ситуацию и корректировать работу вверенного отдела, то фуфельный он ПМ. Где-то быть настойчивым и проявить характер, где-то поблагодарить и похвалить. А если разрабы ему ещё на момент начального виденья говорят — «Ваш план — *овно » а он не прислушивается, то как говориться — сам дурак. И не надо ждать хорошего результата.
Отлично все описали, только спустить с уровня схемы, на уровень схемоида. Это не работает на уровне да/нет. Это софт-скилл, он не поддается формуле. Нет в природе менеджеров которые не ошибаются. Как и людей которые не ошибаются. При этом я согласен что он должен все это уметь делать на отлично, и даже если местами ошибается — быстро разруливать ситуацию. Но статья вообще не про это.
Обычно люди упертый, когда считают что собеседник слабо ориентируется в том что говорит, и хочет навязать выполнение какой-то дичи.
Нет. Бывает человек уперт потому что ему просто не нравится твоя рубашка. Или тембр голоса. Даже если он считает что человек слабо ориентируется — он же его не тестировал зачастую, он может ошибаться. Вопрос в том что адекватный человек даже если видит что человек не шарит — объясняет ему, а не закрывается. Менеджер не должен шарить во всех языка программирования на которых пишет его команда.
Если у тебя нету машины, но тебе нужно общаться с водителем автомобиля (это твоя обязанность), иди и учи азы вождения и мат. часть по комплектации легкового автомобиля, можешь там пойти в гоночки поиграть (мы ведь не про вождения разумеется сейчас =) ) иначе на кой ты как собеседник вообще данному водителю, он и без тебя знает как данный автомобиль поедет.
Вы не поняли что сказал. Когда у тебя нет компьютера — навыки печатания те не пригодятся. Когда клиент не хочется встречать и не берет трубку — никакое ораторское мастерство не поможет. Точно также с командой бывают случаи — когда объяснить невозможно. Даже будучи отличным переговорщиком, и разбираясь в теме. Повторяю — переговоры и работа в команде это двухсторонний процесс. Если одна сторона напрочь отказывается — вторая сделать ничего не может. При любых скиллах.
Попробую еще проще — вам девушки отказывали когда нибудь? Ну вот сразу так нет и все. Что тут делать — пытаться дальше навязываться? Зачем? Ответ прозвучал, он отрицательный. Может вы отличный парень, и ей бы может понравились узнай она вас получше, но она не хочет узнавать, ни сейчас ни потом. В этом случае не надо ее дергать, не надо навязываться — надо просто уйти. Тем более если не уйти то это плавно перетекает в домогательства, Харви Вайнштейн вон доигрался.
похоже на статью с cossa ру
В моем понимании задач PM'a нет там никаких 'тисков', а вполне ясное бизнес приложение
— Сократить врема «начальства» и «разработчиков» на коммуникацию.
У начальства физически нет времени донести задачи бизнесса до каждого разработчика в понятной форме, у разработчиков не останется времени что либо разрабатывать если они будут детально расписывать свой домен начальству. Итого если PM выполняет эту задачу, то все счастливы. Разрабы понимают что им не надо носится по куче митингов и PM все четко объяснит (что пытаемся делать, почему, какие данные указывают на это почему, как оценивается результат, с какими другими командами придется работать и как и почему) Начальство радо, потому что им не нужно углублятся супер в тех. детали, но если нужно что-то то он расскажет и обратит внимание (тут на не хватает либо инфраструктуры, либо инвестировать в рефакторинг, потому что иначе той и той бизнес цели не добится)
Где 'тиски' здесь я не вижу. Проверяется легко вопросом, если меня убрать придется ли разработчикам ходить по куче доп митингов и тратить время не на разработку.
— Определить приоритет задач, который максимизирует ROI для компании.
Почему сначало делаем 'С' потом 'D' потом 'A' потом 'B'. Причем приоритет должен быть не просто 'я так сказал'. А имеено с данными из БД, с ресерчем который начальству дает понять что будет выше прибыль и разработчикам что будет премия. Опять же никаких 'тисков', а почти математическая задача.
На моем субъективном опыте, избавление от тисков легко было достигнуто, простым финтом ушами. PM не влияет на оценку трудов и результатов разработчиков. Они сразу привратились в партнеров а не в подчиненых и пришлось просто прозрачно с данными объяснять планы и решения, через несколько месяцев все уже знали что если к PM'у вопрос: «А почему здесь так» Он мог запросто запросик два написать и ответить либо 'Это увеличит X на 5%' либо 'А действительно, возможно мы не правы, ты как предлагаешь'
— Сократить врема «начальства» и «разработчиков» на коммуникацию.
У начальства физически нет времени донести задачи бизнесса до каждого разработчика в понятной форме, у разработчиков не останется времени что либо разрабатывать если они будут детально расписывать свой домен начальству. Итого если PM выполняет эту задачу, то все счастливы. Разрабы понимают что им не надо носится по куче митингов и PM все четко объяснит (что пытаемся делать, почему, какие данные указывают на это почему, как оценивается результат, с какими другими командами придется работать и как и почему) Начальство радо, потому что им не нужно углублятся супер в тех. детали, но если нужно что-то то он расскажет и обратит внимание (тут на не хватает либо инфраструктуры, либо инвестировать в рефакторинг, потому что иначе той и той бизнес цели не добится)
Где 'тиски' здесь я не вижу. Проверяется легко вопросом, если меня убрать придется ли разработчикам ходить по куче доп митингов и тратить время не на разработку.
— Определить приоритет задач, который максимизирует ROI для компании.
Почему сначало делаем 'С' потом 'D' потом 'A' потом 'B'. Причем приоритет должен быть не просто 'я так сказал'. А имеено с данными из БД, с ресерчем который начальству дает понять что будет выше прибыль и разработчикам что будет премия. Опять же никаких 'тисков', а почти математическая задача.
На моем субъективном опыте, избавление от тисков легко было достигнуто, простым финтом ушами. PM не влияет на оценку трудов и результатов разработчиков. Они сразу привратились в партнеров а не в подчиненых и пришлось просто прозрачно с данными объяснять планы и решения, через несколько месяцев все уже знали что если к PM'у вопрос: «А почему здесь так» Он мог запросто запросик два написать и ответить либо 'Это увеличит X на 5%' либо 'А действительно, возможно мы не правы, ты как предлагаешь'
Где 'тиски' здесь я не вижу.
Вы описали задачи, а я больше про иерархию и полномочия. То есть вы про функцию — достаточно внятно описали, но я говорил про структуру. Это просто разное.
На моем субъективном опыте, избавление от тисков легко было достигнуто, простым финтом ушами. PM не влияет на оценку трудов и результатов разработчиков. Они сразу привратились в партнеров а не в подчиненых и пришлось просто прозрачно с данными объяснять планы и решения, через несколько месяцев все уже знали что если к PM'у вопрос: «А почему здесь так» Он мог запросто запросик два написать и ответить либо 'Это увеличит X на 5%' либо 'А действительно, возможно мы не правы, ты как предлагаешь'
Способ весьма любопытный, но далек от универсальности. Менеджер без полномочий не менеджер, а координатор. Я же рассуждаю именно про менеджера.
Без менеджера-руководителя работать могут только очень продвинутые разработчики, которых можно убедить аргументом, который вы привели. Часто даже и его не надо — они сами знают зачем, знают как — и делают. С ними легко общаться, потому что вы конструктивны — они конструктивны, профессионалы между собой всегда договорятся. Но это топ-люди. Таких мало — и уверен каждая компания мечтает таких иметь, правда далеко не каждая может их потянуть как по деньгам так и культурно.
Оптимизация любого процесса — чисто математическая задача, а соответственно для программиста не более чем техническая деталь. Ну и как результат — чисто манаджер некомпетентен в технических аспектах при этом в аспектах оптимизации по сравнению с программистами — ничто, пыль под ногами. Команда его всегда будет воспринимать исключительно как мешающего работе дармоеда, который не понимает что скока не назначай дедлайнов, но пока не появится техническая возможность реализовать то что надо может хоть головой об стену биться, но заниматься надо именно созданием этой технической возможности. Ну а тем более в случае всяких срамов и прочих облажайлов, напрочь ломающих научно-обоснованные методологии проектирования софта, основанной на реализации компонентов в порядке технической возможности и технической востребованности, что позволяет экспоненциально сократить сложность и время разработки попутно повысив качество.
Чтобы не было тисков менеджером нижнего звена должен быть самый опытный разраб команды. Ну такой себе играющий тренер. А методика управления — местный «уяк-уяк и в продакшин», кривыми попытками копирования которой и есть все эти высеры западного мэнеджмента. Причем абсолютно все, начиная с водопада и че бы там не придумали. От тогда все будет по уму. Так собственно всегда и было в этой стране.
Чтобы не было тисков менеджером нижнего звена должен быть самый опытный разраб команды. Ну такой себе играющий тренер. А методика управления — местный «уяк-уяк и в продакшин», кривыми попытками копирования которой и есть все эти высеры западного мэнеджмента. Причем абсолютно все, начиная с водопада и че бы там не придумали. От тогда все будет по уму. Так собственно всегда и было в этой стране.
Не соглашусь совсем.
То что вы описываете это техническая разработка в вакууме. Если убрать все остальное — то да, это так работает.
В реальном мире коммерческой разработки — где есть тот кто эту разработку спонсирует, тот для кого она ведется, и еще пользователи, все несколько сложнее.
Программисты которые это понимают, не считают менеджера никем и ничем. Потому что каждому свое — они разрабатывают, он управляет, общается с кем нужно, помогает создать условия.
Скрам не отрицает описанное вами, он вообще не про это. Он про то что надо спрашивать заказчика что ему надо, а потом мелкими итерациями это реализовывать создавая техническую возможность, а потом выстраивая порядок исходя из нее. Лучший программист он лучше все программирует а не организует других. Поэтому он не будет лучшим менеджером. Управление и программирование это абсолютно разные области.
Насчет в продакшн — нет, вообще нет. На практике это работает у фрилансера одиночки и то через раз. Возникает сразу куча вопросов, а что делать, а как, а как именно вот в этом месте, а то будет делать это, кто будет делать то — мы же командой работаем, а когда надо, а как пишем, а как отчитываемся, кому отчитываемся. И много еще.
Все это лучший программист организовать не сможет, и метод уяк-уяк — тоже не получится.
В целом — все что вы написали это просто отрицание того что управление в целом существует как наука, и работает. Почитайте про историю, про Тейлора что ли, про разделение труда и прочие азы. Просто попробуйте собрать горстку среднестатистических технарей в офисе-аквариуме и посмотрите как они будут проект выполнять, как будут разбираться, кому как и что делать. На практике, не обязательно мне верить — эмпирически просто проверьте.
То что вы описываете это техническая разработка в вакууме. Если убрать все остальное — то да, это так работает.
В реальном мире коммерческой разработки — где есть тот кто эту разработку спонсирует, тот для кого она ведется, и еще пользователи, все несколько сложнее.
Программисты которые это понимают, не считают менеджера никем и ничем. Потому что каждому свое — они разрабатывают, он управляет, общается с кем нужно, помогает создать условия.
Скрам не отрицает описанное вами, он вообще не про это. Он про то что надо спрашивать заказчика что ему надо, а потом мелкими итерациями это реализовывать создавая техническую возможность, а потом выстраивая порядок исходя из нее. Лучший программист он лучше все программирует а не организует других. Поэтому он не будет лучшим менеджером. Управление и программирование это абсолютно разные области.
Насчет в продакшн — нет, вообще нет. На практике это работает у фрилансера одиночки и то через раз. Возникает сразу куча вопросов, а что делать, а как, а как именно вот в этом месте, а то будет делать это, кто будет делать то — мы же командой работаем, а когда надо, а как пишем, а как отчитываемся, кому отчитываемся. И много еще.
Все это лучший программист организовать не сможет, и метод уяк-уяк — тоже не получится.
В целом — все что вы написали это просто отрицание того что управление в целом существует как наука, и работает. Почитайте про историю, про Тейлора что ли, про разделение труда и прочие азы. Просто попробуйте собрать горстку среднестатистических технарей в офисе-аквариуме и посмотрите как они будут проект выполнять, как будут разбираться, кому как и что делать. На практике, не обязательно мне верить — эмпирически просто проверьте.
Почитайте про историю, про Тейлора что ли, про разделение труда и прочие азы.Ну вот как раз срам и прочий облажал — вот это как раз про срыв эффективного разделения труда.
В инженерной деятельности эффективны абсолютно другие принципы разделения чем в «бери побольше — кидай подальше». Тут в по примитивным операциям разделять противопоказано. Нужно разделение по зонам ответственности.
В целом — все что вы написали это просто отрицание того что управление в целом существует как наука, и работает.На само деле написано что программисты понимают ее гораздо лучше любого менеджера. Не программисты такие, работа у них такая. Особенно это касается АСУТП. При этом в вопросах оптимизации, а так же распараллеливания и синхронизации задач менеджер по сравнению с программистом абсолютно некомпетентен по определению — у него абсолютно недостаточная для понимания всего этого математическая подготовка.
Он про то что надо спрашивать заказчика что ему надо, а потом мелкими итерациями это реализовывать создавая техническую возможность, а потом выстраивая порядок исходя из нее.С каких пор заказчик стал более компетентным в вопросе автоматизации процессов чем программисты?
Скрам не отрицает описанное вами, он вообще не про это.Срам про разработку по фичам, что напрочь отрицает научно-обоснованный подход к разработке по сущностям предметной области.
Все это лучший программист организовать не сможет, и метод уяк-уяк — тоже не получится.
Да ладно. Он хотя бы понимает что реально надо клиенту и как этого наиболее быстро и качественно достичь.
Возникает сразу куча вопросов, а что делать, а как, а как именно вот в этом месте, а то будет делать это, кто будет делать то — мы же командой работаем, а когда надо, а как пишем, а как отчитываемся, кому отчитываемся. И много еще.Никаких. Команда делится на подгруппы соответственно разделению системы на подсистемы. Дальше рекурсивно. Соответственно у каждого четко определена его зона ответственности и т.д.
Просто попробуйте собрать горстку среднестатистических технарей в офисе-аквариуме и посмотрите как они будут проект выполнять, как будут разбираться, кому как и что делать. На практике, не обязательно мне верить — эмпирически просто проверьте.Вы ей богу будто ни дня в отделе АСУП или АСУТП не работали. Все это десятилетиями проверено и дает как скорость и гибкость, так и качество, потому что способствует а не мешает вести разработку по научно-обоснованным методикам. Единственное что требует — квалифицированных разрабов.
Что говнопад что срамы с облажайлами — всего лишь кривая попытка это скопировать. При этом говнопад — это про финансовые интересы контор разработки работающих с крупными конторами. Причина того что список фич нельзя расширить исключительно в том чтобы мотивировать что его нельзя менять вообще, а соответственно и не было снижения законтрактованных объемов в процессе.
Срам и прочие облажайлы — это про некомпетентность горе-спецов и мелкого заказчика-нищеброда которого привлекают типа тем что платит тока за то что ему реально нужно.
В реальности же 95-99% процентов трудоемкости — это создание технологического базиса. И сократить его выбирая фичи нельзя — это набор моделей сущностей предметной области из которой собираются фичи. И он от списка фич независим от слова совсем и лишнего в нем ничего нет по определению (все отрезано до нас бритвой Оккама). Научно-обоснованные методики позволяют экспоненциально сократить сложность и как результат время разработки именно технологической базы. При этом когда для предметной области есть технологический базис, реализация фич занимает в разы меньше времени чем их выдумывание. Но именно это разработкой типа по фичам срам и прочие облажалы и ломают от слова совсем. А отсутсвие доки именно для того и нужно чтобы подсадить клиента на иглу — за расширениями пойтить в другое место будет проще с нуля все переделать.
Т.е. все эти высеры западного менеджмента — всего лишь способы распилить как можно больше бюджета клиента, адаптированные для конторок разного масштаба.
В отличии от «уяк-уяк и в продакшин», который сформировался в условиях того, что отдел разработки — часть конторы в интересах которой ведется разработка/расширение софта, а некомпетентные в вопросе выпускники околовсяческих курсов на должность разраба вообще не попадут в принципе. От тут реальные условия стимулирующие увеличение скорости разработки, качества и экономического эффекта софта. Причем с офигенным фидбеком — если заглючило, к примеру у бухглтерии, то пока не пофиксят и не разгребут последствия з/п не получат — ее просто посчитать не смогут.
Кстати ни в 80-е ни в 90-е ни в начале 0-ых ни даже в 10-х там где юзали «уяк-уяк и в продакшин» никаких вопросов с тем чтобы разработать и расширить что то в короткие сроки минимумом спецов никогда не существовало. Существовала проблема где взять технику и внутризаводские каналы связи для массового внедрения на предприятии того что разработали.
Скрам — научно обснованный подход к крупным проектам, где конечный результат не определён. Где ни разработчик, ни заказчик, никто в принципе не может сказать какой из множества возможных вариантов решения достигнет поставленных целей. Создание сначала технологического базиса, полной модели предметной области и т. п., противоречит цели быстрой реакции на запросы рынка. Пока вы с вашей командой будете создавать базис и модель для, например, программы учёта семейных финансов, проектируя всё по научным источникам с многотысячелетней историей, скрам-команда выпустит MVP и убъёт его с вердиктом "мы не знаем как на этом рынке зарабатывать — пользователям нравится, они требуют новые фичи, но платить не готовы — фиксируем убытки и закрываем проект". Скрам, имхо, заточен под быструю валидацию бизнес-гипотез о востребованности тех или иных идей рынком.
С каких пор заказчик стал более компетентным в вопросе автоматизации процессов чем программисты?
Причем тут компетентен. Вы приходите в магазин — продавец вам должен сказать что вас надо, или может вы сами свои потребности знаете?
Программмисты компетенты в автоматизации, но они не компетентны в том что хочет заказчик, они не знаю его бизнес, они не знаю его боли. Они знают КАК, но они не знают ЧТО надо автоматизировать. Это знает тот кто обратился к ним.
Срам про разработку по фичам, что напрочь отрицает научно-обоснованный подход к разработке по сущностям предметной области.
Нет. Просто прочитайте гайд. И ниже коммент. Даже детализировать не буду.
Да ладно. Он хотя бы понимает что реально надо клиенту и как этого наиболее быстро и качественно достичь.
Да ладно? Отрицаете существование управления снова?) Ну серьезно почитайте Тейлора или вообще хоть что то про это.
И нет не понимает. Он понимает как можно сделать те или иные вещи. Чтобы понять что надо клиенту — с ним надо поговорить, общаться программист, особенно бизнес переговоры вести также не умеет, как и организовывать других.
Никаких. Команда делится на подгруппы соответственно разделению системы на подсистемы. Дальше рекурсивно. Соответственно у каждого четко определена его зона ответственности и т.д.
Кто ее делит? Сама? Вы хоть раз пробовали группу разделить хоть на пары, на тренировке к примеру? Кто назначает подсистемы. Кто собирает требования заказчика? Кто определяет как отчитываться о проделанной работе? Кто ставит сроки? Кто проверяет? Серьезно, хватит туннелировать.
Отдел АСУП — это ФУНКЦИЯ. Не проект. Проект подразумевает неопределенность. Это вообще другое. У них может быть тех руководитель, а знаете почему? Потому что остальное все у них прописано в регламентах, и обеспечивают их всем другие подразделения. Мы говорим про проекты тут, а не про отдел АСУП.
Дальше даже отвечать не буду — скрам не про фичи, про управление мало, выводы совсем без аргументов. Идея фикс про высер и прочее такое. Научно-обоснованный подход везде. На мои аргументы ответа нет. Больше время на ответы вам тратить не буду, уж простите.
Причем тут компетентен. Вы приходите в магазин — продавец вам должен сказать что вас надо, или может вы сами свои потребности знаете?
Тут немного другой аналог уместен. Вы приходите к дохтору и говорите «дохтор у меня болит». А то и «дохтор посмотрите все ли со мной в порядке?». А самолечением заниматься как известно вредно — если дохтор сказал в морг значит в морг. И не важно что вы еще живы — вы же еще до морга еще не доехали.
Отдел АСУП — это ФУНКЦИЯ. Не проектОтдел АСУП — это ПОДРАЗДЕЛЕНИЕ, которое занимается разработкой сопровождением и поддержкой всех информационных и учетных систем предприятия — т.е. всех проектов, не касающихся управления оборудованием в реальном масштабе времени. Ими занимается другое подразделение — отдел АСУТП.
Программмисты компетенты в автоматизации, но они не компетентны в том что хочет заказчик, они не знаю его бизнес, они не знаю его боли. Они знают КАК, но они не знают ЧТО надо автоматизировать. Это знает тот кто обратился к ним.
Они знают как определить что именно можно автоматизировать и умеют это реализовать. Заказчик в этом по определению не компетентен. Иначе ему нет необходимости обращаться к программистам.
Кто назначает подсистемы. Кто собирает требования заказчика? Кто проверяет?Программисты. Никто другой ничему этому не обучен. Это все технические аспекты.
Кто ставит сроки?Опять же программисты. Более-менее объективно прикинуть трудоемкость а значит и эстимейт можно только по сетевому графику зависимостей. А его построение требует декомпозиции на гораздо более мелкие компоненты чем подсистема. Да кста, обычно для того чтобы застараховать себя от нежданчиков в этом вопросе сроки внедрения просто указываются не жесткие а от даты поставки необходимого оборудования. При этом в подавляющем большинстве случаев все идет с такими темпами, что для того чтобы подстраховаться в планы на месяц/квартал вносится то что полностью сделано в прошлом периоде. Отсюда и эта знаменитая фраза начальства «надо вчера» пошла — т.е. более высокий менеджмент обычно уже в курсе что в загашнике у разрабов что то есть, но без очень серьезной причины типа падения Луны на Землю в это предпочитают не влазить — разрабам виднее что лучше выкатить, а что пока что попридержать. От это и есть самоорганизация, гибкость, скорость, качество, доверие со стороны начальства команде и т.д. которыми в срамах и прочих облажайлах и не пахнет.
Кто ее делит? Сама? Вы хоть раз пробовали группу разделить хоть на пары, на тренировке к примеру?А вы когда нить тренировались вообще в парных видах спорта? Обычно тренер говорит — разбились на пары. И этого абсолютно достаточно чтобы группа это выполнила. Есть еще вариант — в две шеренги становись.
В распределении же по подсистемам и т.д. — всегда в любом бюро есть естественным путем сформировавшиеся подгруппы более опытные в том или ином профиле. От по этому принципу и идет разделение. При этом опять же все идет по принципу группировки менее опытных вокруг более опытного.
Проект подразумевает неопределенностьНе смешите мои тапочки. Проект подразумевает проектирование. А методология проектирования предписывает в первую очередь выделить предметную область/области в которых проект живет. А предметная область штука очень редко изменяемая. Набор сущностей в ней постоянен и лишних сущностей нет. Добавление же новых сущностей всегда идет путем надстройки над уже существующими. К примеру одна из наиболее быстро изменяемых предметных областей САПР. Крайняя минорная надстройка сущностей в ней произошла в конце 00-х. Предыдущая но крупная — в конце 80. Перед ней — в 60х. Т.е. технологическая база на которой работают фичи всегда неизменна в долгосрочной перспективе. А какой там список фич — для реализации технологической базы вообще не важно. Но именно наличие технологической базы определяет высокий темп реализации фич. О каком научном подходе со стороны менеджеров, которые не в курсе об азах методологии проектирования, может вообще идти речь?
А зачем менеджерам методологии проектирования? Вот это точно технический аспект, как программисты будут проектировать. Менеджеру нужны планы, оценки, календарные графики и т. п.
А зачем менеджерам методологии проектирования? Вот это точно технический аспект, как программисты будут проектировать. Менеджеру нужны планы, оценки, календарные графики и т. пЧтобы не ломать их имплементацию всякими
На самом деле программистам менеджмент не нужен так же как и другим инженерам. В вопросах оптимизации инженер по определению круче любого менеджера. А инженер-программист особенно. А соответственно и менеджмент нижнего звена оптимально поручать самому опытному инженеру группы, без отрыва от участия в процессе разработки.
Менеджеру нужны планы, оценки, календарные графики и т. п.Ну и как он может планировать и составлять графики без оценки технической возможности и технической востребованности компонентов, и хотя бы приближенных но главное объективных оценок трудоемкости? А их получение — кроме того что они технические аспекты, так еще и напрямую зависимые от методологии проектирования. Для всего этого нужен один график — а именно сетевой график зависимостей. Но его построение требует рекурсивной декомпозиции системы на компоненты до достаточно глубокого уровня. А это таки тоже как не крути а технический аспект.
Т.е. для того чтобы там что то календарить и т.д. нужен как минимум роадмап реализации проекта. А получение оного роадмапа — это таки самая что ни на есть инженерная задача, потому что строится он на порядке получения технических возможностей реализации той или иной функциональности.
Вот и получается что весь этот, некомпетентный ни в технических аспектах, ни в аспектах оптимизации, менеджмент методологию проектирования нафиг ломает, а как результат и отодвигает получение реального выхлопа на неопределенный срок.
А когда роадмап есть там планировать нечего — там надо реализовывать. Где можно распараллелить — распараллеливать. Т.е. нагрузка в этом плане на разраба-менеджера настолько незначительна, что ему от разработки особо отрываться не надо.
Если менеджер программистам не нужен, то зачем поручать менеджмент самому опытному? Пускай без менеджера. Собственно идеальный переход к скраму так выглядит: самоорганизованная группа профессионалов "выкидывает" менеджера и начинает работать со принтами, дэйли и т. п.
Ну о чем и речь — весь этот американский менеджмент — не более чем кривая попытка копирования местного «уяк-уяк и в продакшин» без понимания того, что он построен на определенной методологии проектирования, и с попыткой прикрутить к этому неквалифицированных разрабов — квалифицированных то дефицит жуткий и начался оный дефицит в омериках еще в 80-е. В европах же и совдепиях эту проблему c дефицитом квалифицированных разрабов решали совершенствованием методологий проектирования, которая при правильной имплементации позволяет экспоненциально снизить сложность а значит и ускорить разработку — глубина декомпозиции для каждой предметной области конечна, а значит и возможности распараллеливания, а соответственно увеличение количества разрабов профита не даст, значит способ есть только один — методология проектирования повышающая продуктивность квалифицированных разрабов.
Попытка обратного кривого копирования формы этой кривой американской копии сюда — ну это полный идиотизм, потому что именно эту методологию проектирования оно и ломает.
Кстати так о птичках в омериках оная методология проектирования тоже известна в кругах квалифицированных разрабов. Там она значится под именем OOD и относится к наиболее востребованным на сегодняшний день скилам. А дальше смотрите внимательно на любом забугорном сайте вакансий — везде где в списке требований OOD везде есть и требование в/о. Там же где указан срам и прочий облажайл — обычно требование к образованию — школа.
При этом набирать востребованность оный OOD начал лет 5-7 назад — т.е. по всей видимости в результате анализа причин фейла эффективности, к которому неизбежно приводило пропихивание срамо-обложайла в местные аутсорсинговые команды квалифицированных разрабов.
От и думайте стоит ли ломать то что здесь есть, а там в дефиците, и заменять на то, что там фактически отброс?
Попытка обратного кривого копирования формы этой кривой американской копии сюда — ну это полный идиотизм, потому что именно эту методологию проектирования оно и ломает.
Кстати так о птичках в омериках оная методология проектирования тоже известна в кругах квалифицированных разрабов. Там она значится под именем OOD и относится к наиболее востребованным на сегодняшний день скилам. А дальше смотрите внимательно на любом забугорном сайте вакансий — везде где в списке требований OOD везде есть и требование в/о. Там же где указан срам и прочий облажайл — обычно требование к образованию — школа.
При этом набирать востребованность оный OOD начал лет 5-7 назад — т.е. по всей видимости в результате анализа причин фейла эффективности, к которому неизбежно приводило пропихивание срамо-обложайла в местные аутсорсинговые команды квалифицированных разрабов.
От и думайте стоит ли ломать то что здесь есть, а там в дефиците, и заменять на то, что там фактически отброс?
Собственно идеальный переход к скраму так выглядит: самоорганизованная группа профессионалов «выкидывает» менеджераСобственно говоря для «уяк-уяк и в продакшин» — это маст хев опшин. И растет она как не странно из квалификации разрабов.
Квалифицированный разраб способен спроектировать и реалтизовать систему любой степени сложности в одиночку с белого листа — т.е. начиная со сбора требований и до полной программной реализации. Но поскольку ну на действительно сложные системы человекочасов ну надо довольно много они декомпозируются на компоненты. При этом задача реализации каждого компонента от задачи реализации всей системы отличается только объемом. Ну и такое разделение фрактально. И точно также все это надо уметь для реализации даже атомарной задачи — т.е. такой которая не позволяет дальнейшей декомпозиции а значит и распараллеливания и должна полностью решаться одним разрабом. Именно это — анализ и постановка — основное чему учат программистов в универе, а не только какому то одному языку как на околовсяческих курсах. Быстро освоить любой нужный язык для квалифицированного спеца вообще не проблема. Потому что проектирование подразумевает еще выбор языка реализации разрабами, вплоть до того что если подходящего языка нет, то в общем то знания достаточные чтобы его спроектировать ( так к примеру европеец, хорошо владеющий OOD, в для ускорения реализации серии задач, которыми его озадачили в америках, изобрел С++ — Bell Labs реально был в шоке от такого подхода). Т.е. все в этом плане решает квалификация разрабов. Банально у людей есть мысль (задача) и они знают как ее думать (проектировать и реализовывать). И никто кто не в курсе как это делается им для этого не нужен.
Теперь что происходит у неквалифицированных разрабов. Они кое как умеют держать в руках ручку (язык программирования), но они не знают че этой ручкой писать (т.е. спроектировать систему и найти решение задачи не в состоянии от слова совсем). Ну и в результате начинается перепихивание вопроса с одной больной головы на другую — на менеджера на заказчика и т.д.
Зачем копировать этот бред в команды квалифицированных разрабов? Может проще в универах порядок навести чтобы меньше липы выпускали и было проще отделить квалифицированных от околовсяческих?
Реально квалифицированными программистами что здесь что там становится не более 25-30% от поступивших на первый курс. Только там в отличии от здесь остальные 70-75% дипломов не получают.
то зачем поручать менеджмент самому опытному?Не менеджмент а руководство. Это две огромные разницы. А самый опытный всегда будет в вопросах разработки неформальным лидером — т.е. в случае чего члены команды за советом будут обращаться именно к нему. А соответственно когда у него есть еще и полномочия формального начальника — т.е. перекинуть задачу от одного разраба другому или разраба с одной подсистемы на другую — все это будет разруливаться гораздо оперативней и быстрее чем через ненужные согласования с выделенным некомпетентным менеджером. Т.е. банально — почему кокпит ресоур манаджментом занимается КВС (он же первый пилот) а не к примеру стажер из правой чашки или не стюардесса? А что случается когда в это вмешивается некомпетентный президент (он же верховный главнокомандующий) и главком ВВС как у поляков под Смоленском? От по той же причине. По большому счету можно рассматривать так что задачу решает от этот самый опытный, остальные — его помощники. При этом существуют еще и задачи синхронизации с другими командами. А соответственно для этого нужен человек способный хотя бы в общих чертах удержать детали всех решаемых командой задач по всем проектам.
Да при этом в «уяк-уяк и в продакшин» никаких ограничений на количество проектов в которые вовлечена команда нет. Это специально для того чтобы подсистемы похожего профиля, но из разных проектов можно было отдавать одному бюро — так реализация быстрее и качественнее. Любое бюро это по сути профильное подразделение отдела. Так же как и сопровождением того что они уже внедрили занимаются тоже они.
Т.е. менять это на срам в сферическом вакууме, у которого эффективного способа взаимодействия команд нет от слова совсем, вообще бессмысленно.
Не менеджмент а руководство. Это две огромные разницы.
Какая разница для вас? Перекинуть задачи или разраба — это и есть менеджмент.
Т.е. менять это на срам в сферическом вакууме, у которого эффективного способа взаимодействия команд нет от слова совсем, вообще бессмысленно.
Скрам в сферическом вакууме подразумевает работу одной команды. Если объективно нужно больше десятка людей, чтобы скорость разработки оставалась приемлемой, то это уже не совсем про скрам, может даже совсем не про скрам. Скрам про процессы, когда одна команда может сделать задачу от и до, не блокируясь из-за смежников.
Скрам в сферическом вакууме подразумевает работу одной команды.Срам в сферическом вакууме подразумевает перевод рабочего времени впустую.
Если объективно нужно больше десятка людей, чтобы скорость разработки оставалась приемлемой, то это уже не совсем про скрам, может даже совсем не про скрам.Естественно. При этом для срама такая объективная необходимость начинается там, где в «уяк-уяк и в продакшин» нужно или добавить второго разраба, или разгрузить одного от части проектов.
Скрам про процессы, когда одна команда может сделать задачу от и до, не блокируясь из-за смежников.В реалиях «уяк уяк и в продакшин» обычная причина блокировки — отсутствие списка фич. Т.е. при наличии технологического базиса, или хотя бы его расширяемого скелета, обычна ситуация, когда выдумывание фич занимает в несколько раз больше времени чем их реализация одним разрабом. При этом наибольшее время в реализации технологического базиса занимает неожиданно не разработка кода, а вхождение разрабов в предметную область — т.е. срам в этом вопросе в принципе не может быть быстрее, только медленнее. Хотя бы потому что отделение базиса от фич в большинстве случаев позволяет входить в предметную область постепенно в процессе реализации базиса, а в случае распараллеливания его реализации распараллелить и оное вхождение. Т.е. срам и прочий облажайл медленнее из-за того, что он полностью ломает принцип декомпозиции принятый в методике проектирования, как результат срывается экспоненциальное ускорение разработки технологической базы что в результате приводит к экспоненциальному замедлению реализации фич при росте их объема.
Т.е. ломается в первую очередь гибкость результата.
Какая разница для вас? Перекинуть задачи или разраба — это и есть менеджмент.Необходимость в подобной переброске возникает исключительно в результате технической необходимости. А соответственно гораздо оперативнее когда эти функции выполняет технический руководитель а не постороннее, некомпетентное в вопросе лицо. Точно так же в том же машинном отделении распределением работ почему то занимается стармех или второй механик, но ни как не капитан и тем более не суперкарго.
При этом кроме самого распределения работ есть еще функция согласования и утверждения именно технических решений. А соответственно если еще и менеджера выделенного присобачить получается дублирование функций.
Вы в целом про какую сферу то говорите? Разработку под ключ? Продуктовая разработка? Что-то из этого?
Если речь про подразделение IT профиля на крупном предприятии — то все что я написал к нему совсем неприменимо и мы просто о разном говорим.
Прочтите определение проекта, PMBok. Про тапочки вы зря, серьезно без шуток, и про аджайл тоже. У меня складывается впечатление что вы его примеряете на подразделение и понятно — что там это нифига работать не будет, так никто особо и не сует туда его.
Подразделение — правильно оно ФУНКЦИОНАЛЬНОЕ. Оно не занимается проектами, оно выполняет функцию. Проект не подразумевает этого — читайте определение. Просто ознакомьтесь с терминологией в проектном управлении, и в менеджменте. Ну серьезно. Я ничуть не сомневаюсь что вы разбираетесь в том о чем говорите. Я прихожу к выводу что мы вообще о разном говорим, совсем. Только вы интерполируете ваше видение на аутсорс IT разработку, хотя не уверен что работали в ней и разбираетесь — поправьте если не прав. Я лишь отмечу что там общее это разве что наличие инженеров. В остальном это совсем другая история, другие цели там ставятся, другой формат работы, её организации.
Это вместо пост скриптум.
Если речь про подразделение IT профиля на крупном предприятии — то все что я написал к нему совсем неприменимо и мы просто о разном говорим.
Прочтите определение проекта, PMBok. Про тапочки вы зря, серьезно без шуток, и про аджайл тоже. У меня складывается впечатление что вы его примеряете на подразделение и понятно — что там это нифига работать не будет, так никто особо и не сует туда его.
Подразделение — правильно оно ФУНКЦИОНАЛЬНОЕ. Оно не занимается проектами, оно выполняет функцию. Проект не подразумевает этого — читайте определение. Просто ознакомьтесь с терминологией в проектном управлении, и в менеджменте. Ну серьезно. Я ничуть не сомневаюсь что вы разбираетесь в том о чем говорите. Я прихожу к выводу что мы вообще о разном говорим, совсем. Только вы интерполируете ваше видение на аутсорс IT разработку, хотя не уверен что работали в ней и разбираетесь — поправьте если не прав. Я лишь отмечу что там общее это разве что наличие инженеров. В остальном это совсем другая история, другие цели там ставятся, другой формат работы, её организации.
Это вместо пост скриптум.
Вы в целом про какую сферу то говорите?Про разработку софта в целом.
Если речь про подразделение IT профиля на крупном предприятии — то все что я написал к нему совсем неприменимо и мы просто о разном говорим.Это такая же контора по разработке софта. Другие только финансовые отношения с заказчиком. Но они как бе методологии, скорости, качеству разработки и самоорганизации команды как то ортогональны.
Так что если оно не применимо для отдела то оно неприменимо для разработки софта вообще. В принципе не применимо.
Прочтите определение проекта, PMBok.Проект — это конкретно процесс создания конкретной системы. К примеру «Cистема централизованной подготовки данных» — то реализацией этого проекта от сбора требований до поддержки занимается отдел АСУП.
Или «Система численного моделирования естественной конвекции в кристаллизующемся слитке» — такой системе достаточно одного разраба. Вернее двое дня нее — это слишком много. Но делается она точно так же. По той же методологии. Собираются требования, выделяется неизменный технологический базис, реализуется, после чего навешиваются любые нужные фичи.
Если на PMBok говорят что либо другое — то это не более чем антинаучный высер.
Я лишь отмечу что там общее это разве что наличие инженеровЧто за бред? Каким боком методологии проектирования от финансовых отношения между заказчиком и исполнителем зависит?
Только вы интерполируете ваше видение на аутсорс IT разработку, хотя не уверен что работали в ней и разбираетесь — поправьте если не прав.
А ну в этой сфере я тоже кое чего повидал. К примеру как команды из 15 срамеров чи каких там еще облажайлеров вылетали с работы, потому что один человек по научно-обоснованной методологии за два дня делал то что они срамили пол года без результа. Эт еще 2004-ый год был примерно и облажайлеры оные были из омерик — так что срам у них был самый что не на есть правоверный.
А так же наблюдал кучу раз как клиент в результате использования насрамленного говнокода в продакшине влетал в финасовые убытки кратно превосходящие не то что стоимость разработки, а потенциальный выхлоп от использования софта. При этом при разруливании косяков в ответ на вопрос чем обусловленно то или иное техническое решение молчание ягнят.
Ну и главное — от когда этих срамеров спрашиваешь по поводу их костылей — если бы ты нес финансовую ответственность за последствия багов ты бы так разрабатывал? Обычный ответ — нет.
Ото и все про это былокодерство.
Sign up to leave a comment.
Менеджер проекта в тисках. Почему так и что с этим делать