Comments 61
как знакомо :-) только обычно это все еще хуже %-)
UFO just landed and posted this here
Вы знаете, большая разница заключается в размере проекта. Если проект 4,5, максимум 6 человек — тимлид и ПМ обычно одно лицо. Если более двадцати человек — они выполняют совершенно разные функции. Я писал про первый тип проектов, т.к. сам работаю в аутсорсинговой компании, вы же скорее всего работаете над большими проектами. В общем всё в мире относительно :)
5-6 человек — оптимальные размер команды. С трудом представляю, как можно эффективно управлять командой из 20 человек, не дробя ее.
Поддержу gvsmirnov. Описан все же тимплид, а не менеджер проекта. Исполнение/совмещение обязанностей по менеджменту не делают его менеджером проекта.
И да, 5-6 в команде это уже более чем достаточно. unix way, пусть у нас будет много маленьких сущностный, но каждая из них будет простой и более эффективной, чем в более укрупненном варианте.
И да, 5-6 в команде это уже более чем достаточно. unix way, пусть у нас будет много маленьких сущностный, но каждая из них будет простой и более эффективной, чем в более укрупненном варианте.
полностью согласен с gvsmirnov, у вас напутаны должности и обязаности. У нас были и большие дробные команды по 20 чел там был лид лидов и отдельный ПМ, на нормальных командах 2-6 человек ПМ и лид могли работать на несколько команд и проектов.
Если девелоперы не понимают важность ПМа, то есть два варианта, ПМ действительно плох или действительно хорошо. В последнем случае нужно просто слить немного говна на девелоперов которое идет сверху.
сам был лидом в командах и желание «вступать» в ПМ небыло никакого. То что делают ПМ сильно отличается от того, что нравится девелоперу.
Если девелоперы не понимают важность ПМа, то есть два варианта, ПМ действительно плох или действительно хорошо. В последнем случае нужно просто слить немного говна на девелоперов которое идет сверху.
сам был лидом в командах и желание «вступать» в ПМ небыло никакого. То что делают ПМ сильно отличается от того, что нравится девелоперу.
Менеджеры действительно разные бывают, но чтобы сроки и ТЗ продумывать, гуманитарного образования маловато будет.
"
Дев, 14:15
(думает) Ну и зачем ты спрашивал моё мнение, всё равно поступили как ты хочешь. (вслух) ну давай, мне всё равно.
Дев, 15:00
(после митинга) ещё один бесполезный митинг, сколько бы кода успел написать…
"
а в Дев не прав?
Да и в целом у вас ПМ весьма бесполезным выглядит, шуму много, толку ноль.
Дев, 14:15
(думает) Ну и зачем ты спрашивал моё мнение, всё равно поступили как ты хочешь. (вслух) ну давай, мне всё равно.
Дев, 15:00
(после митинга) ещё один бесполезный митинг, сколько бы кода успел написать…
"
а в Дев не прав?
Да и в целом у вас ПМ весьма бесполезным выглядит, шуму много, толку ноль.
Ваше мнение ещё раз доказывает, что я не зря написал эту статью. Или зря, если Вы не поняли сути…
Есть ещё вариант: статья выражает справедливую идею, но написана не очень удачно. Понятно, что выбранный приём хорошо иллюстрирует напряженную и сложную жизнь менеджера. Однако, в то же время, он очень однобоко изображает программиста.
Менеджер, как получается из текста, постоянно занят, работает на благо продукта, а программист только и делает что критикует руководство и «так уж и быть» выполняет указания.
Это опасный приём: мне, программисту, читать было не очень приятно. Думаю, если бы вы нарисовали деятельного разработчика, то такого ощущения не возникло бы. Боюсь, что этот приём может отвлечь существенную часть читателей от сути поста.
Менеджер, как получается из текста, постоянно занят, работает на благо продукта, а программист только и делает что критикует руководство и «так уж и быть» выполняет указания.
Это опасный приём: мне, программисту, читать было не очень приятно. Думаю, если бы вы нарисовали деятельного разработчика, то такого ощущения не возникло бы. Боюсь, что этот приём может отвлечь существенную часть читателей от сути поста.
Да бог с ним, с программистом, он и должен этаким туповатом болванчиком выглядеть, коль скоро статья ПМам адресована. Проблема в том, что количество поднятых вопросов по деятельности именно ПМа сильно превышает количество ответов и резюме автора далеко от того, с чего я бы сам начал.
Я вот менеджер-менеджером и код вообще писать не умею. Но мне тоже кажется, что ПМ у Вас какой-то эээ странный получился.
На мой взгляд (и небольшой опыт) очень важно, чтобы все участники процесса понимали про занятость другого. Как только участник начинает думать про другого, что тот бездельник, то все, привет проекту. И не важно ДЕВ так думает про ПМа или про другого ДЕВа или ПМ про кого-то из них. Как только появляется лентяй, остальные начинают тоже лениться: читать хабр, кодить налево, whatever.
В Вашем примере лентев нет, есть серьезная проблема в коммуникации и понимании. Ее обязан решать ПМ. Если он не может доднести до ДЕВов важность своей работы, то он плохой ПМ. А если он видит, что хороший ДЕВ что-то в печали, он должен с ним поговорить, а не списывать на неудачный сексуальный опыт. И хвалить его самого, а не только перед руководством.
На мой взгляд (и небольшой опыт) очень важно, чтобы все участники процесса понимали про занятость другого. Как только участник начинает думать про другого, что тот бездельник, то все, привет проекту. И не важно ДЕВ так думает про ПМа или про другого ДЕВа или ПМ про кого-то из них. Как только появляется лентяй, остальные начинают тоже лениться: читать хабр, кодить налево, whatever.
В Вашем примере лентев нет, есть серьезная проблема в коммуникации и понимании. Ее обязан решать ПМ. Если он не может доднести до ДЕВов важность своей работы, то он плохой ПМ. А если он видит, что хороший ДЕВ что-то в печали, он должен с ним поговорить, а не списывать на неудачный сексуальный опыт. И хвалить его самого, а не только перед руководством.
Это такая идиотская корпоративная этика — держать мысли при себе и пытаться казаться милым зайчиком? Особенно внутренний диалог на «митинге» порадовал. Причем в приведенном примере в этом плане оба «отличились».
И такой ПМ лично мне, действительно, кажется слабым. Не умеет организовать свое рабочее время, а, главное, не умеет общаться с разработчиками.
Хотя в примере в разработчик тоже не очень. Вместо того чтобы понять своего ПМа и помочь ему (хотя бы словами о том, что вся работа сделана), сидит и тупо обижается. Правда отсутствие обратной связи скорее тоже вина ПМа.
И такой ПМ лично мне, действительно, кажется слабым. Не умеет организовать свое рабочее время, а, главное, не умеет общаться с разработчиками.
Хотя в примере в разработчик тоже не очень. Вместо того чтобы понять своего ПМа и помочь ему (хотя бы словами о том, что вся работа сделана), сидит и тупо обижается. Правда отсутствие обратной связи скорее тоже вина ПМа.
Соглашусь в плане озвучивания мыслей при обсуждении. Конечно не в таком прямом ключе.
Можно было сказать: «давайте рассмотрим несколько вариантов — какой быстрый, но не очень правильный и долгий, но качественный». Разработчика бы вовлекли в обсуждение плюсов и минусов решения и подбросили на весы не только качество продукта, а еще сроки и стоимость разработки, риски потери заказчика. Тогда и решение бы принималось более открыто, и девелопер знал причины выбора.
Можно было сказать: «давайте рассмотрим несколько вариантов — какой быстрый, но не очень правильный и долгий, но качественный». Разработчика бы вовлекли в обсуждение плюсов и минусов решения и подбросили на весы не только качество продукта, а еще сроки и стоимость разработки, риски потери заказчика. Тогда и решение бы принималось более открыто, и девелопер знал причины выбора.
>И такой ПМ лично мне, действительно, кажется слабым.
На словах
А на деле:
На словах
привлекайте девелоперов к ответственности.
А на деле:
Не, знаешь что, давай просто по старинке сделаем.
Ну в наших реалия обычно, класть на готовую работу. Сделал работу — бери и делай другую, и никакого тебе отдыха мозгам. (если они конечно задействованы :) )
Автор зрит в корень ) Поддерживаю написанное.
Ну очень хреновый PM, говорю это как PM:
— вообще не сечет никакую информацию от разработчика, кроме явно высказанной, и сам так же не пытается донести свои же мысли — управляет императивно и манипулятивно;
— его задача — не горящие вещи улучшать, а выстраивать процесс и атмосферу, то есть что-то проактивно делать, а он только реагирует.
— не управляет самим собой и своим временем;
— не управляет никем другим, не только разработчиком — тем же заказчиком надо управлять
— вообще не сечет никакую информацию от разработчика, кроме явно высказанной, и сам так же не пытается донести свои же мысли — управляет императивно и манипулятивно;
— его задача — не горящие вещи улучшать, а выстраивать процесс и атмосферу, то есть что-то проактивно делать, а он только реагирует.
— не управляет самим собой и своим временем;
— не управляет никем другим, не только разработчиком — тем же заказчиком надо управлять
(думает) дааа, скажу фармацевту REST, WSDL и SOAP, он переведёт 5 дней в баксы, и можно забыть про проект… это как мне разницу между аспирином и парацетомолом. (вслух) Нет, давай всё же сделаем так, так быстрее.
Мне кажется что в таких случаях имеет смысл предоставлять заказчику выбор. То есть озвучить варианты, описать плюсы/минусы каждого решения и привести рекомендации. Например:
— Делаем с SOAP. Затраты 5 дней, из плюсов — простота интеграции с BPEL, из минусов — время
— Делаем REST + JSON. Затраты 2 дня, из плюсов — быстрота и простота реализации.
Принимать такого рода решения за заказчика не есть хорошо, так как Вы можете не знать всех последующих планов развития/использования системы и соотвественно принятое решение может быть не оптимальным. С другой стороны если Вы предлагаете заказчику варианты реализации на выбор, то особо ничем не рискуете. В том плане, что если его не устроит вариант за 5 дней, то он просто выберет более быстрый и все.
Зависит от заказчика и от проекта. Довольно часто бывают ситуации, в которых клиент делает заказ, один раз описывает свои требования и дальше уже не хочет об этом думать. И если ПМ может хорошо вникнуть в потребности клиента и самостоятельно решить, какой вариант будет оптимальным, это в большинстве случаев будет только плюсом. Конечно, только если заказчик не горит желанием принимать непосредственное участие во всех этапах разработки.
Эти два варианта заказчику не скажут ничего, только заберут его время.
Какое ему дело до SOAP, JSON, быстроты и простоты. Это все проблемы тех кому платят за разработку. А заказчику нужны не самые-самые решения, а чтобы бизнес работал и прибыль приносил.
Какое ему дело до SOAP, JSON, быстроты и простоты. Это все проблемы тех кому платят за разработку. А заказчику нужны не самые-самые решения, а чтобы бизнес работал и прибыль приносил.
Да контора сама по себе замечательная.
По-моему у всех что-то не то с мотивацией. И менеджеру и девелоперу всё безразлично.
По-моему у всех что-то не то с мотивацией. И менеджеру и девелоперу всё безразлично.
Ничего себе. Интересно, много таких контор? И как они все выживают?
Уф, фраза знакомая до боли в желудке… когда был ПМом:
Дев, 18:00
(думает) Фух, досидел, отчаливаю. Аривидерчи, пойду пить пиво с пацанами, в бильярд поиграем! Ну я и забожил кода сегодня, аж приятно, не впустую день прошёл!
Потом сидишь делаешь пересчет времени, смотришь а не укладываешься в сроки… Девы молодцы, мощные, не спорю, я тогда совсем зеленым ПМом был, на ребят смотрел чуть ли не как на божеств, сначала даже как-то не по себе было намекать, что пора бы как бы сдаваться… потом когда немного опыта набрался уже оставались у меня и на вечер если того необходимо было. Но при всем при этом они знали что исправляют свои косяки и свое разгильдяйство в рабочее время, сначала роптали, но так как отношения были теплыми достаточно, и зарплаты грели, то немного пообщавшись на этот счет — все остались довольны. Дальше ввелся плавающий график (9:00-17:00 или с 12:00-20:00), если ребятам надо был выходной посреди недели, то тоже ничего страшного — они успевали выполнить все в домашних условиях и на утро было все готово, но контроль велся четкий, и они понимали зачем. Так что тут все зависит от того какие люди, ну и как ПМ себя ведет, ну и не самое последнее мотивация людей, как в денежном эквиваленте, так и в моральном. Часто и на себя принимаешь все удары от руководства, лишь бы не по «рабочему классу».
Дев, 18:00
(думает) Фух, досидел, отчаливаю. Аривидерчи, пойду пить пиво с пацанами, в бильярд поиграем! Ну я и забожил кода сегодня, аж приятно, не впустую день прошёл!
Потом сидишь делаешь пересчет времени, смотришь а не укладываешься в сроки… Девы молодцы, мощные, не спорю, я тогда совсем зеленым ПМом был, на ребят смотрел чуть ли не как на божеств, сначала даже как-то не по себе было намекать, что пора бы как бы сдаваться… потом когда немного опыта набрался уже оставались у меня и на вечер если того необходимо было. Но при всем при этом они знали что исправляют свои косяки и свое разгильдяйство в рабочее время, сначала роптали, но так как отношения были теплыми достаточно, и зарплаты грели, то немного пообщавшись на этот счет — все остались довольны. Дальше ввелся плавающий график (9:00-17:00 или с 12:00-20:00), если ребятам надо был выходной посреди недели, то тоже ничего страшного — они успевали выполнить все в домашних условиях и на утро было все готово, но контроль велся четкий, и они понимали зачем. Так что тут все зависит от того какие люди, ну и как ПМ себя ведет, ну и не самое последнее мотивация людей, как в денежном эквиваленте, так и в моральном. Часто и на себя принимаешь все удары от руководства, лишь бы не по «рабочему классу».
В примере ПМ сам виноват, мне кажется. Думает одно, говорит другое. Девелопер ведь не машина для кодинга. Если ПМ потратит на 5-10 минут больше, объяснив и про Джона-фармацевта, и про архитектуру двухлетней давности, то отношения совсем другие в команде выстроятся
Какой то грусный и скучный рабочий день получается по рассказу. Неужели в большинстве компаний так проходят будни?
Таких кантор более чем много.
Узнаю себя. За исключением того, что я про себя редко говорю. Если уж и говорить, так чтобы все слышали :)
Вообще, реально, совмещать менеджмент и кодинг довольно проблематично, но в маленьких коллективах по-другому нельзя физически. Иной раз приходится весь рабочий день все разруливать, а потом уже глубокой ночью только кодить. Факт.
В принципе правильно.
Ещё стоит добавить зависть программиста: к ноутбуку, к навороченному телефону.
Ну и с точки зрения программера ПМ скорее больше бегает со своим ноутом по офису и вне.
Ещё стоит добавить зависть программиста: к ноутбуку, к навороченному телефону.
Ну и с точки зрения программера ПМ скорее больше бегает со своим ноутом по офису и вне.
Токарь вдумчиво протирает гаечный ключик тряпочкой. К нему подходит начальник и начинает грузить:
— Петров! Ты чего домой так рано собираешся??? Время всего 17:20!!!
— Понимаете, я пока ключик тряпочкой протру, пока станок железной щеточкой почищу, пока ручки мыльцем отмою, пока переоденусь… Вот как раз и конец рабочего дня наступит.
— Нет, Петров! Я считаю, что это не правильно! Вот я собираюсь с работы ровно в 18:00!
— А че тебе собираться-то? Е6aльнuк закрыл и пошёл.
— Петров! Ты чего домой так рано собираешся??? Время всего 17:20!!!
— Понимаете, я пока ключик тряпочкой протру, пока станок железной щеточкой почищу, пока ручки мыльцем отмою, пока переоденусь… Вот как раз и конец рабочего дня наступит.
— Нет, Петров! Я считаю, что это не правильно! Вот я собираюсь с работы ровно в 18:00!
— А че тебе собираться-то? Е6aльнuк закрыл и пошёл.
Извините, но описанный ПМ — это хреновый ПМ. Дело ПМа не про архитектуру думать — для этого есть архитектор, CTO и прочий народ — а следить, чтобы всё было в нужное время в нужном месте у нужных людей.
Позвольте не согласится — дев в этой ситуации тоже демонстрирует не верное отношение. Есть люди которые принимают решения — в этом состоит их работа, а есть люди которые должны воплощаться эти решения в жизнь.
Дев не должен знать о фармацевте и смете проекта и десятке других мелочей. То что думает дев про себя наглядно демонстрирует его однобокое отношение к работе старшего товарища что рано или поздно приведет к конфликту в коллективе. Резюмируя вышесказанное: надо побывать в шкуре другого прежде чем критиковать со своей высокой колокольни.
Дев не должен знать о фармацевте и смете проекта и десятке других мелочей. То что думает дев про себя наглядно демонстрирует его однобокое отношение к работе старшего товарища что рано или поздно приведет к конфликту в коллективе. Резюмируя вышесказанное: надо побывать в шкуре другого прежде чем критиковать со своей высокой колокольни.
Бывают команды без аналитиков, архитекторов и даже менеджеров :) Узкая специализация людей в команде — это больше минус, чем плюс.
По моему опыту работа ПМ и работа девелопера сравнимы. Только ПМ платят больше. А так ответственность одна и та же, головняка одинаково, мозг напрягать немного по-разному, но обоим приходится.
Какой-то странный у вас опыт. По-моему опыту, работы ПМа и девелопера — ну вообще разные и уровни ответственности — тоже.
Сам ПМ уже давно и иногда ловлю себя на мысли, что хочется вернутся в стан девелопмента. Когда в каждый момент времени у тебя имеется одна поставленная задача, когда не приходится каждые пять раз переключать фокус внимания между совершенно не связанными между собой задачами. Когда невозможность выполнить задачу в срок означает только выполнение задачи позже, или, максимум, овертайм и не нужно при этом судорожно оценивать, как задержка по конкретной задаче повлияет на работу остального десятка людей и проект в целом, что скажет заказчик, когда очередная демонстрация функционала будет сдвинута. И это не считая того, что вообще все проблемы идут через тебя — заказчик просит фичу, разработчик уперся в стену, аналитик нашел концептуальную проблему и т.д. и т.п. И для всего этого — оценить, спланировать, скоординировать, расставить приоритеты, поставить задачи, обозначить риски и отследить выполнение.
Сам ПМ уже давно и иногда ловлю себя на мысли, что хочется вернутся в стан девелопмента. Когда в каждый момент времени у тебя имеется одна поставленная задача, когда не приходится каждые пять раз переключать фокус внимания между совершенно не связанными между собой задачами. Когда невозможность выполнить задачу в срок означает только выполнение задачи позже, или, максимум, овертайм и не нужно при этом судорожно оценивать, как задержка по конкретной задаче повлияет на работу остального десятка людей и проект в целом, что скажет заказчик, когда очередная демонстрация функционала будет сдвинута. И это не считая того, что вообще все проблемы идут через тебя — заказчик просит фичу, разработчик уперся в стену, аналитик нашел концептуальную проблему и т.д. и т.п. И для всего этого — оценить, спланировать, скоординировать, расставить приоритеты, поставить задачи, обозначить риски и отследить выполнение.
Весёлая, яркая статья, хорошо иллюстрирующая ситуацию во многих командах.
Пишите ещё!
Пишите ещё!
Прежде чем сочувствовать ПМ — вспомните о том, что рейт этих самых ПМ, по крайней мере на Западе, обычно составляет от 20 до 60 американских долларов в час. Ну а что касается программистов, они спят по 6 часов в сутки, только за гораздо меньшие деньги.
Автор какой-то странный мир описал. Где девелоперы сваливают в 6, а работа с полдвенадцатого до полдесятого считается подвигом. Ну и вообще статья изначально предвзята. Я тимлид, у меня 100 писем в день, но это не очень то вообще то много. И еще — если ПМ свои технические навыки поддерживает чтением хабра — примерно полутора лет ему хватит, чтобы выпасть из технологического фронта.
Ну и вообще, странно, что ПМ позиционируется как конечная цель развития девелопера. Я вообще думаю, что ПМ-ами люди становятся, после того как устают держаться на гребне технологической волны:)
Ну и вообще, странно, что ПМ позиционируется как конечная цель развития девелопера. Я вообще думаю, что ПМ-ами люди становятся, после того как устают держаться на гребне технологической волны:)
Вай, это бомба =) Сам ПМ, раскидал всем своим коллегам, пусть читают… Завтра перед обедом xD
Внесу свою маленькую лепту.:)
ИМХО
Идеальных людей нет. И не будет. В канцелярии так и сказали. Например, умение приходить к 9 и уходить в 18 — обозначает лишь то, что вы умеете приходить к 9 и уходить к 18. Каких-то сверхсил это не дает. Если вы программер, то ваш код от этого лучше явно не станет (если вы конечно, не наиболее эффективны во временном промежутке от 10 до 14). Если вы ПМ, то с некоторыми клиентами могут даже возникнуть серьезные проблемы. Потому что они привыкли работать по другому графику, и их не очень сильно волнует ваш распорядок дня. А постоянно работать по 12 часов в день не просто плохо — это еще и серьезный износ здоровья как физического, так и духовного.
Если смотреть глазами программиста.
То данный ПМ — просто фуфло. Стабильности никакой. Обнадеживает попусту. Постоянно письма пишет и языком молотит. Никакого планирования (так чтобы до минут знать всю будущую неделю). Дисциплина вообще напрочь отсутствует. Вообщем негодяй первой степени.
Но по каким-то причинам ПМ остается ПМ-мом, а программист программистом.
С точки зрения ПМ.
Все выглядит несколько подругому. Мы не берем ПМ на проектах, где все хорошо получается. И заказчик дает собой управлять, и неожиданности укладываются в предполагаемый разброс, и имеющиеся ресурсы практически полностью покрывают необходимости, и вообще погода на улице хорошая. Сразу оговорюсь. Я не подразумеваю того, что описанная мной хорошая ситуация не требует усилий, умений и знаний.
Итак. Есть забугорный заказчик. И его явно не волнует, что исполнитель в россии. Скорее всего это даже по договору прописано. Видно, что его представители достаточно капризные. Плюс заказчик умеет считать деньги, и понимает их ценность. Но самое главное — он оплачивает труд всей команды. А это достаточно неплохая сумма.
Уже из общей ситуации видно, что график 9-18 «фтопку». Умеет считать деньги -> слова «концептуальность», «передовые технологии» и т.д. «фтопку» (потому что перевозить коробку с лекарствами можно и на обычной машине, без функций аля «массажного кресла водителя»). Капризные -> обвинять его в чем-то или идти на прямой конфликт нельзя (очень плохо, когда рассерженный капризный мальчик сидит за пультом управления полетами). Ненормированная ситуация (часто меняются требования, приоритеты и т.д.) -> какой план тут составишь? Только гибкий.
Если смотреть с этой точки зрения, то ПМ хоть и имеет недостатки (а кто без них), но справляется с задачей (сделать проект, если вы забыли).
С точки зрения владельца или директора компании исполнителя.
Почему он оставляет ПМ на месте, а разработчика оставляет разработчиком? Потому что ПМ умеет управлять ситуацией и людьми так как требует ситуация (в том или ином виде), а не так как он видит. Это очень большая разница. И делает он это в ущерб своей личной жизни. Остальное оставим за кадром (а то точно начнутся обиды).
С точки зрения клиента.
Он платит. И вообще-то, ну так между делом, этот проект нужен ему для решения его целей, а не целей кого-либо из исполнителей.
ИМХО
Идеальных людей нет. И не будет. В канцелярии так и сказали. Например, умение приходить к 9 и уходить в 18 — обозначает лишь то, что вы умеете приходить к 9 и уходить к 18. Каких-то сверхсил это не дает. Если вы программер, то ваш код от этого лучше явно не станет (если вы конечно, не наиболее эффективны во временном промежутке от 10 до 14). Если вы ПМ, то с некоторыми клиентами могут даже возникнуть серьезные проблемы. Потому что они привыкли работать по другому графику, и их не очень сильно волнует ваш распорядок дня. А постоянно работать по 12 часов в день не просто плохо — это еще и серьезный износ здоровья как физического, так и духовного.
Если смотреть глазами программиста.
То данный ПМ — просто фуфло. Стабильности никакой. Обнадеживает попусту. Постоянно письма пишет и языком молотит. Никакого планирования (так чтобы до минут знать всю будущую неделю). Дисциплина вообще напрочь отсутствует. Вообщем негодяй первой степени.
Но по каким-то причинам ПМ остается ПМ-мом, а программист программистом.
С точки зрения ПМ.
Все выглядит несколько подругому. Мы не берем ПМ на проектах, где все хорошо получается. И заказчик дает собой управлять, и неожиданности укладываются в предполагаемый разброс, и имеющиеся ресурсы практически полностью покрывают необходимости, и вообще погода на улице хорошая. Сразу оговорюсь. Я не подразумеваю того, что описанная мной хорошая ситуация не требует усилий, умений и знаний.
Итак. Есть забугорный заказчик. И его явно не волнует, что исполнитель в россии. Скорее всего это даже по договору прописано. Видно, что его представители достаточно капризные. Плюс заказчик умеет считать деньги, и понимает их ценность. Но самое главное — он оплачивает труд всей команды. А это достаточно неплохая сумма.
Уже из общей ситуации видно, что график 9-18 «фтопку». Умеет считать деньги -> слова «концептуальность», «передовые технологии» и т.д. «фтопку» (потому что перевозить коробку с лекарствами можно и на обычной машине, без функций аля «массажного кресла водителя»). Капризные -> обвинять его в чем-то или идти на прямой конфликт нельзя (очень плохо, когда рассерженный капризный мальчик сидит за пультом управления полетами). Ненормированная ситуация (часто меняются требования, приоритеты и т.д.) -> какой план тут составишь? Только гибкий.
Если смотреть с этой точки зрения, то ПМ хоть и имеет недостатки (а кто без них), но справляется с задачей (сделать проект, если вы забыли).
С точки зрения владельца или директора компании исполнителя.
Почему он оставляет ПМ на месте, а разработчика оставляет разработчиком? Потому что ПМ умеет управлять ситуацией и людьми так как требует ситуация (в том или ином виде), а не так как он видит. Это очень большая разница. И делает он это в ущерб своей личной жизни. Остальное оставим за кадром (а то точно начнутся обиды).
С точки зрения клиента.
Он платит. И вообще-то, ну так между делом, этот проект нужен ему для решения его целей, а не целей кого-либо из исполнителей.
Странно, но только сейчас заметил Ваш комментарий. Читаю верхнюю часть — не понимаю за что Вы меня обвиняете. Читаю нижнюю часть — так я со всем согласен…
Но ведь и правда бывает очень много девелоперов, особенно молодых, которые несогласны оставаться позже, а у ПМ-ов просто нет выбора. Я про них и писал.
Но ведь и правда бывает очень много девелоперов, особенно молодых, которые несогласны оставаться позже, а у ПМ-ов просто нет выбора. Я про них и писал.
Простите, видимо я не совсем корректно выразился. Я никого не обвинял. Честно! Наоборот оправдывал сторону ПМ.
Вспомнил как менялось моё мировоззрение. И решил накидать мыслей людям, которые еще не проходили через разные ситуации.
Хотя когда был чисто девелопером, наоборот боролся за свободу графика!)))
Вспомнил как менялось моё мировоззрение. И решил накидать мыслей людям, которые еще не проходили через разные ситуации.
Хотя когда был чисто девелопером, наоборот боролся за свободу графика!)))
Отличная статья. Плюсануть статью не успела — плюсану в карму.
Sign up to leave a comment.
Один день из жизни проджект менеджера глазами девелопера