проектруки, делитесь опытом
наверняка здесь присутствуют руководители проектами. есть желание рассказать о трудностях, об успехах, об инструментах и т.д.
я тоже кое-что расскажу, если позволите, но мне не хотелось бы в этот раз играть первую скрипку, мне хотелось бы прочитать ваши вклады.
прошу 
нееееееее, слишком уж специфически. меня интересует сперва обширное введение, а именно, как вы ведете проекты, какими инструментами пользуетесь, как решаете вопросы кадров и способы коммуникации. я уверен, что в процессе публикации опыта, мы поднимем специфические вопросы. согласна?
Инновационные проекты. Проблемы, как у всех. Удержать бюджет в рамках; подписать JDA с клиентами; коммуникации со всеми заинтересованными сторонами; stakeholder management; отслеживать все, что касается Intellectual property (IP); временные рамки проектов; установка действительно важных майлштайнов.
Ну это как-то очень общо. Можно википедию скопировать 😀
У нас практически всегда классическое ведение проектов, водопад. Агильные проекты только внутренние. Пытаемся ввести агильные проекты у клиентов, но они сопротивляются 😂 Поэтому я скоро иду повышать квалификацию, как сочетать водопад и агильные проекты, чтобы не отпугнуть клиентов и вообще не сесть в лужу.
скажем там, нужно организовать проект. откуда появляется необходимость в проекте? наложение технических, финансовых и маркетинговых необходимостей, т.е. решение менеджмента с учетом уставного бюджета для проекта. пока еще ты не включена в механизм. как только уставной бюджет и рамки проекта более-менее вбиты в фундамент, появляешься ты, рукпроекта. теперь запрошены твои компетенции. с чего ты начинаешь?
правильный вопрос, глобальные процессы существуют не везде, грубо говоря. в сфере подрядчиков, к примеру, нет никаких глобальных процессов.
приведу пример производителя мясорубок Х. от решения менеджмента до конечного продукта откладываются 50 недель, и процесс предусматривает:
----------
1. грубый дизайн оболочки. задействование имеющегося опыта и дизайна от предыдущих моделей
2. облагороженный дизайн
3. проверка менеджментом
4. корректировка бюджета
5. дизайн ручки
6. проверка менеджментом и корректировка бюджета
7. закупка ножей, спирального вала, скрепляющего шурупа
8. проверка на совместимость закупленных частей и собственного дизайна оболочки
9. корректировка бюджета
10. испытания
11. корректировка совместимости
12. испытания
13. финальная корректировка бюджета
14. серийный выпуск
----------
тебя этот процесс касается, как вводная, ты ничего в глобальном процессе не изменишь и нет прав изменить. ты, как рукпроекта,, вклиниваешься где-то со своей ударной группой, выполняешь необходимый объем работ и выходишь из процесса. надеюсь, в грубых рамках все знакомо?
я начинаю с конкретизации задачи. Уставной бюджет и рамки это хорошо, но нужно конкретное описание цели, чего мы хотим этим проектом достигнуть, и как достижение цели повлияет на окружение. Когда все конкретно описано и согласовано, можно начинать планировать время, затраты и людей.
Нет, у меня именно проекты с моим бюджетом.
Начинается все с идеи. Потом идет проверка рынка, первый разговор с будующими клиентами, попытка понять, что конкретно их интересует. Потом составляется бизнес план, определяется величина финансовых вложений, колличество FTEs, необходимых для приведения проекта к целям, определяется величина CAPEX. Устанавливаються временные рамки: market launch, market entry. Продумываються маилштайны и к какому сроку они должны быть достигнуты. Потом ищутся партнеры для технической реализации проекта, как внутри концерна, так и за его пределами (все зависит от концерна). С партнерами заключается соглашение, с клиентами тоже (JDA). Потом необходимо получить соглашение top management, людей, которые распределяют финансы. После всего этого наступают проектные будни. Совещания по тех. прогрессу, планирование бюджета (на каждый год), строгий контроль за бюджетом, отслеживание
конкурентов, отслеживание, как проходят тех. испытания, написание патентов и пр.
сотрудники на этой стадии ещё не выбираются. Влияние на окружение: твоя мясорубка повысит имидж компании, как инновативного предприятия, но может создать фирме проблемы с зелёными, которые против переработки мяса. Нас интересует эта проблема? Нет? Отлично. Да? Тогда как будем решать? В другом проекте, меня это не касается? Отлично.
Это, конечно, очень грубый и за уши притянутый пример. Но в общем и целом в любом случае стоит потратить часок на обдумывание, кого на предприятии и вне него твой проект затронет, и может ли этот кто-то испортить тебе жизнь.
Что ты имеешь в виду? Для меня короткая проверка окружения точно такая же стандартная часть для начала, как и конкретизация задачи проекта. Ты считаешь, что это к проекту не относится? Ну... это вопрос философский. Можно и не делать.
Людей начинаем подбирать, когда задача ясна, окружение проверено на подводные камни и даже уже есть грубый план проекта. Потому что чтобы подобрать людей, мне надо сначала знать, что люди должны уметь, когда они мне понадобятся, на какой стадии, и в каком объёме.
У нас одна из проблем, что многим приходится говорить не на родных языках или в разных областях использование одного и того же термина слегка (а иногда и вовсе даже не слегка) отличается. И если сразу на берегу не договорится, кто что имеет ввиду, то потом такого накуролесить могут....
Например, как "сода", в разговорном немецком и русском
у тебя же прикладная область твоего софта логистика?
Если да, то никуда ты особо от водопада не уйдешь, потому что у них есть дата, когда построенна данная часть склада и в ней должны работать такие-то процессы. У них их процессы - водопад и никак ты против этого не попрешь. Имхо
Ты имеешь в виду, какой уровень нужен, или какой уровень у тех, из кого набирают? Какой уровень нужен, я примерно могу оценить. Если не могу, то ищу себе советника для той области, где знаний не хватает.
Набираем мы обычно из коллег, а их уровень я знаю. На фирме меньше 500 человек, я тут много лет, всех знаю и уже со всеми в какой-то мере была в контакте, даже когда ещё не работала в проектах. И память у меня очень хорошая. И подрядчиков, с которыми мы работаем, я тоже всех знаю.
Если тебе надо сначала найти новых сотрудников для проекта, с улицы, то тут ничего сказать не могу.
абсолютно банальная, но очень важная штука:
- на каждой встрече иметь кого-то, кто с твой стороны ведет протокол (ну или сам)
- обязательно рассылать всем участникам протокол сразу после встречи (макс через день)
- обязательно с перечислением присутствующих и датой
- next steps очень важны, а не только протоколирование сказанного! то есть в конце все должны быть aligned, о след действиях
- в мыле к протоколу спрашивать: не хватает ли чего
----
вот казалось бы такая банальщина, но каждый раз, когда не было протола -> были проблемы....
Ни разу не довелось подобного увидеть... А я, как фрилансер, побывал много где. С другой стороны, фриласнсеров обычно не зовут туда, где все классно поставлено. Мы обычно работаем пожарниками. Хотя мне в последнее время предлагали и свою команду набрать, но мне вообще уже не хочется работать на кого-то.
Вот самый классный (не просто классный - это был просто Эйнштейн проектруководства) проектрук, с которым мне доводилось работать, всё, абсолютно всё записывал, постоянно ходил с блокнотом. Не то что я - у меня все всегда в голове. Если я что-то записываю, то только для успокоения окружающих...
Фрилансеров ещё ни разу не видел в серьезных проектах. И вряд ли когда-нибудь увижу - не пускают посторонних туда, где пахнет большими рисками потерять все. Два раза видел, да, как аутсорсеров онсайт приводили: один раз кодеров, когда не хватало реально рук, второй раз девочек-припевочек со знанием уникальных языков а-ля тамильский, белорусский, монгольский и иже для локализации продукта и его адаптации для различных рынков.
Но пм - это в основном политика и выяснение отношения. Эти все протоколы нужны, чтобы потом друг друга лицом макать
А вот на эту компоненту мне всегда было глубоко наплевать. Я всегда прав, если я ошибся - я это всегда первым признаю. Если кто-то с этим несогласен - ему же хуже. Меня правда один раз из-за этого уволили, но уволившего меня через полгода уволили тоже - проект без меня не выжил.
1. Как правильно сказала Анна, для новых стратегических направлений обычно ресурсов нет. Полностью согласен, и тут фрилансеры играют свою роль. Именно для подобного меня звали создать свою команду и разивать это направление.
2. Фирмы бывают разные. Например в Дойче Банке постоянная нехватка персонала, а а регуляции не дают ждать (примут скажем какого-нибудь Франка-Додда и вынь и положь имплементацию заданных правил к нужному сроку), и для имплементации оных постоянно набирают фрилансеров.
Вчера читал, что как раз ДБ сокращения планируют из-за избытка персонала. Ок, я про индустрию говорил - там иногда отдельный NDA не только в рамках подразделения, а ещё и в рамках проекта. Не говоря об общем для всех сотрудников. Если со своими так без спиленной мушки, представьте, как охотно туда пустят классного парня с улицы. В сервисе все может быть, я не знаю просто.
Вот ни разу не работал в индустрии. Один раз почти пошел на поставщика Ауди (инфотейнмент), но не срослось.
это всё верно , потому что ты отстаиваешь только свою точку зрения и на этом баста. И если что, ну и выгнали тебя, ну ты дальше и пошёл.
А ПМ надо выяснять отношения со всеми участниками, таких как ты может быть несколько, а ещё поставщики и заказчики, к ним ещё какая-нибудь фирма монтёр к примеру.
так, как раз где увольняют, там фрилансеров ии гребут. Потому что во всех этих фирмах с профсоюзом, ты просто не имеешь права: справа увольнять, а слева набирать. Все эти предприятия, у которых официальный Einstellungsstopp, только на фрилансерах и живут.
Фандорины абсолютно везде подписывают NDA. Абсолютно. Даже близко не могу представить себе ситуацию, где мне было бы выгодно его нарушить.
Я бы на Вашем месте не было так категоричен насчёт вот прямо всех ☺ В DB - может быть, это сервисная компания. Крупные же производственные концерны и мировые игроки (а не фирмы) очень дорожат своими know-how, чтобы подпускать туда людей с улицы, не несущих никакой ответственности. Да и увольнять не обязательно, можно спилить ласково мушку так, что сам уйдёшь. Побежишь даже! Видел ее не раз и не два в действии.
производственные концерны, да ну. 🙄🙄🙄
А сколько инженеров трудится через лайку в ваших производственных концернах. 🙄🙄🙄😁😁
Обслуживание правительства IT - это тоже сервис?! Туда можно Фандориным?!
Сейчас автомобилестроение, до этого коммуникация и стандартизация коммуникационных протоколов. В последнем случае в принципе в силу специфики конгломерата представить человека со стороны в логове зверя крайне сложно, там со своими не церемонились - если нашли флешку на выходе или на телефон не была установлена аппликуха, которая лочит камеру на всей территории, телефон уплывал молча в мусорку. Я так когда-то чуть трёх прототипов не лишился по незнанию. Вот точно тогда вспомнил "наш" родной первый отдел и пятую приёмку 😀
У нас все не на столько секретно.
:) Но людей со стороны (фрилансеров) - нет. Есть практиканты (студенты) на 3-6 месяцев, они, как правило, изучают ситуацию на рынках. И их не допускают ни на какие совещания, планерки. Я точно знаю, что в других хим. и фарма концернах ситуация похожая. А с автомобильной и авиационной промышленностью все еще сложнее, там даже норм и спецификаций на определенные баутайлы или матерьялы в открытом доступе нет, только, если ты с ними договор (joint development agreement) заключаешь, то получаешь необходимые данные.
Про IT мне что-то сказать сложно. Слышала, что там много фрилансеров, а у нас вообще IT-это аутсорс через другие фирмы, в основном. И на сколько мне известно, если hardware еще можно
запатентовать, то software - сложнее, поэтому фрилансеры и получают допуск ко всему.
Не то что я - у меня все всегда в голове.
У меня тоже все в голове. Но работая в команде приходится все облачать в форму документов, схемок. Иначе сложно обсуждать с другими тему, которая у меня в голове полностью, а у остальных лишь только-что озвученные детали.
Не получают они доступа по всему. Спросите мужа с оказией про Trust Zone, он Вам куда лучше меня объяснит, кого туда, сколько раз и по какому месту пускают ☺ Вот как раз у нас на прошлой работе вот именно эти ребята под жесткими NDA сидели и даже вход к ним в лабу был только у этой могучей кучки.
Патентируют не программную реализацию, а идею. Именно sequence of actions. В прошлом месяце, кстати, вот первую заявку в Дойчландии оформил - процесс интеграции пошел 😁
Не то что я - у меня все всегда в голове.
Это понятно что все в голове, но а вдруг ты на больничном, а вдруг ещё что ( женился и в свадебное путешествие на полгода уехал))) и что?
Я тоже не любитель была все записывать, но после первых серьёзных разборок где почти все друг с другом пересраслись не нашли общего языка( а мы этого не говорили и про это мы не договаривались и сроки мы другие обещали)- как бабушка отшептала. У меня все всегда теперь записано и практически всегда или сама во время совещания веду протокол или настаиваю, чтобы тот кто ведет, договоренности в протокол сразу же по ходу пьесы вносил. А то знаем, плавали.
как ты определяешь уровень компетенции членов команды?
Вопрос был Насте, но могу внести свои пять копеек- если есть возможность набрать изнутри - все друг друга обычно хорошо знают, слышали, пересекались, у каждого своя карма репутация. Но самое интересное начинается тогда, когда хочешь кого-то конкретного, но его не дают. Как правило, имхо, "хороших" специалистов руководители очень неохотно отдают под другие проекты.
привет
не только можно, но и нужно. уже которое сообщение читаю и никак не пойму, почему снова и снова затрагиваются упорно эмоциональные стороны вопроса. ко всему еще и карма добавилась.
друзья, как вы работаете? как вы распределяете обязанности? как осуществляете контроль времени? какими инструментами пользуетесь? как мотивируете членов команды? как ходите на ковер и как приглашаете к себе на ковер?
ну что вы как дети, переходите к конкретному вопросу.
У тебя, извини, вопросы какие-то бессистемные. То ты в заглавном сообщении общо призываешь поделиться трудностями и успехами, теперь оказывается, что есть куча конкретных вопросов. ПМ может быть не очень умным и может даже не разбираться в сути происходящего (Аня, я на досуге поняла потом, что ты имела в виду), но ему нужно уметь работать структурированно. Иначе весь проект будет сплошным хаосом.
Протоколы и документация совершенно без эмоций на самом деле в проектах жизненно необходимы. По крайней мере если в проекте больше трёх человек задействовано. Не только из соображений доказательства чьей-то вины, но это и вопрос денег, если вдруг окажется, что клиент считает, что ему недодали, и вопрос передачи информации. Если у тебя все в голове, ты можешь это рассказать троим, но ты забодаешься рассказывать это 15-20-30 коллегам. Репортинг тоже относится к документации. Я могу навскидку перечислить пять проектов, где ПМ со стороны клиента слезно благодарили меня за мои регулярные письменные репорты, оказывается в ИТ даже при больших проектах это далеко не само собой разумеется.
Многие из твоих перечисленных вопросов решаются на кикоффе: сколько раз в неделю собираемся обсудить текучку. Обычно раз в неделю, но в напряженных фазах может быть и каждый день 15 мин. Как осуществляем коммуникацию с клиентом и между нами. Обязанности распределяются путём арбайтспакетов, которые формируются во время детального планирования. За каждый арбайтспакет назначается ответственный и сроки выполнения.
Мотивация вопрос сложный и относится скорее к теме эмоций. Я своих коллег никак не мотивирую, считаю, что кто немотивированный, тому мои общие завтраки не помогут. А другим долго быть просто достаточно нормального человеческого и рабочего общения.
об инструментах
к вопросу о системности инструментом может быть отвертка, компьютерная программа или громкий голос. никто не отреагировал. но ладно.
хорошо, по-моему, я был понят, как нуждающийся в лекции по общим вопросам руководства проектом. отнюдь! потому и не сдвигаемся с мертвой точки. сделаем проще, мы расскажем о конкретном проекте и заменим имена заказчиков и коллег на выдуманные. по ходу дела возникнут вопросы и древо обсуждения обрастет ветвями и листвой. согласны?
инструментов в ПМ миллион для разных целей. Для планирования одни, для контроля другие, для мотивации третьи и т д. Громкий голос условно подойдёт для мотиваций, но не подойдёт для планирования. Какие именно инструменты тебя интересуют?
Если тебе проще с условным проектом, можно с условным проектом.
к вопросу о системности инструментом может быть отвертка, компьютерная программа или громкий голос. никто не отреагировал. но ладно.
Репорты раз в неделю по тех. прогрессу, JourFix со всей командой раз в 2 недели. С топ менеджментом встречи каждые пол года для отчета. Контроллинг присылает бюджет раз в месяц. Если какие-то срочные вопросы: скайп, термины, тел. звонки, емайлы (предпочтительны). Встреча с клиентами где-то каждые полгода, обсуждение тех. прогресса, правильные ли поставлены задачи. С каждым нужно обсудить временные рамки, каждого ставить в известность, если что-то меняется. Дел хватает. :)
Мотивация. Для тарифных работников: личный пример, дружественный тон общения, заинтересованность в их работе, если надо, то можно надавить, но без криков. Для аусертарифных: цели в начале года, если они будут достигнуты, то
премия. Соответственно тоже: личное общение, иногда совместные обеды, объяснение, для чего именно проект важен. Контрактникам: оплата только за проделанную работу/достигнутые цели. Топ менеджменту интересны только факты, цифры. Но к плохим новостям их можно заранее подготовить за коротким митингом-апдэйтом, а не на "главном" собрании года. :)
Все очень индивидуально. К каждому нужно находить подход. У меня еще не было такого, чтобы приходилось на кого-то кричать, хотя есть определенные ситуации, когда люди выводят из себя своей тупостью/ленью.
скажи, где и как ты училась работе с персоналом?
пользуешься ли MS Project?
какую стратегию предпочетаешь в разговоре с менеджментом, если разговор состоит не толъко из отчета, но и из просьбы, на которую, как правило, реагируют раздраженно - об увеличении бюджета?
Признайся, это очередной психологический эксперимент?
Не может человек на полном серьезе задавать такой открытый вопрос и ждать подробных отчетов.
С таким же успехом можно было бы спросить "Физики, расскажите, как вы работаете? Какими пользуетесь инструментами, как решаете проблему невозможности проверить теории из-за технических несовершенств оборудования, как планируете эксперименты и ищете финансирование?"
скажи, где и как ты училась работе с персоналом?
Я - практик, курсы никакие не заканчивала.
пользуешься ли MS Project?
Редко.
какую стратегию предпочетаешь в разговоре с менеджментом, если разговор состоит не толъко из отчета, но и из просьбы, на которую, как правило, реагируют раздраженно - об увеличении бюджета?
Начинаю с хорошего. Как важен мой проект, что он принесёт фирме и пр. Потом перехожу к достигнутым результатам. Потом говорю, что по таким-то причинам нужно увеличить бюджет. Но я всегда заранее пытаюсь узнать, есть ли вообще свободные/лишние деньги.
случается, что сотрудник отказывается выполнять работу, мотивируя положением в семье, нехорошим самочувствием, а порой и просто блокирует подход. как ты приводишь в чувство тунеядца?
бывают ли неурядицы на почве конфликта сотрудников-мужчин с сотрудниками-женщинами?
мне нравится стратегия встречного предложения на случай отказа, но работает только при наличии информации. очень стараюсь дружить с секретаршами.
бывают ли неурядицы на почве конфликта сотрудников-мужчин с сотрудниками-женщинами?
Нет, не бывает. Кстати, на последнем термине с топ-менеджерами наш состав был такой: 11 мужчин и одна женщина, думаю, ко мне относились с несхождением. :)
случается, что сотрудник отказывается выполнять работу, мотивируя положением в семье, нехорошим самочувствием, а порой и просто блокирует подход. как ты приводишь в чувство тунеядца?
Сложно. Пытаюсь выслушать человека, понять в чем его проблема (выговариваться часто помагает). Потому что-то из подобного говорю: "да, ситуация сложная, но нам обязательно нужно еще сделать то и то, а иначе большие дяди будут ругать и достанется всем. Вот ты сейчас, бите, поработай, а завтра можешь пойти домой раньше". Как-то так. А ты?
то, что не бывает стычек между полами, просто счастье. не скажу, что у меня это часто, но было, точнее, один раз. я решил вопрос старым "советским" методом - добился перевода виновника бунта в соседнюю епархию с повышением.
теперь о мотивации. вопрос очень больной и разговорами уже не решается. начиная проект, я обрекаю себя на бесконечные разговоры о необходимости работать, о сроках, о штрафных санкциях... нет, с меня этой музыки довольно. потому понимаю мотивацию как финансовую, так и личностный рост. многие проекты можно представить в свете доклада на конференции, публикации SAE, битву за первенство в многочисленых состязаниях за приз ХХХХХХ и т.д.
малые по объему проекты стараюсь расположить в порядке очереди после одержанной победы или получения премии. гораздо проще с подрядчиками и ляйщиками. к сожалению, приходится прибегать к нечистоплотным методам "краткосрочного планирования" - попросту врать, что завтра небо покроется алмазами и я именно ему предложу контракт. другое не работает, в состязаниях участвовать не могут, публикации за счет своей фирмы, которая ни цента лишнего не истратит. вот примерно так.
ну тогда все люди разные и к каждому подход нужен....
но может касательно эскаляции у нас разные взгляды? можно просто сказать тим-лиду человека, что как бы не очень доволен выхлопом, нельзя ли что сделать. Если лид нормальный - он найдет, как поднажать без истерик.
Мне в конце на прошлой работе надо было привести в движение слишком много людей, и я просто физически не смогла бы, что-то с каждым отлынивающим предпринимать. Я звонила лидам и говорила: слушай, не могу, жизненные силы на пределе (тут конечно все знали, что оно так и есть), еще и твои чет не деливерят вообще.
Что за детский сад, штаны на лямках странная манера общения? Имхо, конечно, но как ты с такими нервами, которые не как канаты, проекты разруливать собираешься, точнее уже делаешь. Вопрос риторический впрочем. Мой совет - относиться проще и не взрываться там где это совершенно не требуется. ( как в случае с Настей).
это, как раз, совсем не вариант, потому что врагами останемся навсегда. в любом случае, эскалация должна быть во всех деталях продумана. я не сторонник.
Ты, во-первых, зря демонизируешь эскаляцию- в умелых руках это очень эффективный инструмент и при этом совершенно без последствий в виде :" враг навсегда". Как пример: даже если кого-то дали на полную единицу, часто бывает у него идут параллельно другие задачи. Чел при всем желании не может разорваться и оказывается в ситуации, когда он in die Bredouille kommen. В такой ситуации мы говорим с коллегой по душам и если коллега согласен, договариваемся- я звоню, пишу его шефу с просьбой приоризировать задания в пользу нашего дела. Пока не было случая чтобы это не сработало. Но. Но это с оговоркой что тебя уже знают и коллеги и их шеф и вы на одной волне. Если это не так или вы в первый раз сталкиваетесь и/или контакт не пошёл так как надо, то вариант 2, смотри ниже:
2) Во-вторых, а это действительно непросто, нужно чувствовать с кем просто можно поговорить и процесс пойдет или с кем нужно пободаться и сначала расставить все точки над "и". Буквально на прошлой неделе получилось так, что клиент ( концерн ) моего коллеги из нашей группы начал эскалировать не по детски. Сам ответственный коллега на больничном, его заместитель в отпуске, непосредственная начальница наша в отпуске, я её замещаю не по всем вопросам и поэтому делу запросы, точнее требования дошли до меня 2 дня спустя как водопадом: сначала к коллеге, т.к. он не ответил, пошло его заместителю, потом к ГЛ, потом к нашему биг боссу и параллельно с шефом каким то образом клиент вышел на меня ( по рекомендации ).
И хотя это для меня это был незнакомый продукт, клиент как и коллеги интерн - действовать нужно было быстро. На выбор мне оставались несколько вариантов для перераспределения заданий: только коллега из нашей группы, но у него такой принцип работы-что не напрямую мое- значит подождёт + до этого он уже получил срочные задания от меня по своему проекту с которыми его и так нужно было волшебными пинками подталкивать к получению результата.
и трэни: умный мальчик с амбициями, но он у нас только 4 месяца и ему пришлось бы дольше обь"яснять и при том большого опыта общения в требовательном тоне с интерн коллегами у него еще не было.
Короче, когда босс подошёл ко мне с вопросом по этой теме, я уже пару вопросов на тот момент разрулила и клиента успокоила, но оставалось самое главное- в темпе рок н ролла предоставить недостающие документы. И тут началось самое интересное, коллеги по этому проекту с других отделов и даже с другого Geschäftsbereich не были готовы к такому натиску и сначала попытались отморозиться. Итог, посредством кнута и пряника документы были представлены в срок, ну и с коллегами ближе познакомились.)))
все же, позволь мне напомнить, что мы постоянно отходим от темы - специфики проектменеджмента и не потому, что общие советы нехороши, они на данной стадии не являются предметом для обсуждения, на что я и указал. ну не нужна мне здесь болталка.
Для меня самые сложные для мотивации - это тарифные работники, которые уже на высшем тарифе и в концерне лет 20. Таких очень сложно мотивировать (финансово не возможно, премий у них нет, карьерный рост уже тоже не возможен), они к тому же все прекрасно знают и во всем разбираются, и бетрибсрад всегда на их стороне. С теми всегда говорю и стараюсь объяснить, что они очень важны для проекта.
Я не совсем понимаю, у тебя личностная ответственность за персонал и за проект или только за проект, а за персонал отвечают другие? Если второй вариант, то все вопросы через непосредственного шефа данного сотрудника, у него должны быть рычаги управления/мотивации своего сотрудника. Если он не может со своим сотрудником справиться, то просить замену.
Ха, там чаще проблема неспособности продуктивно работать, чем просто нежелание. Топовые работники по 20 лет на одном месте не сидят.
Топовые работники по 20 лет на одном месте не сидят.
В принципе "время жизни инженера" ограничено 3-мя годами на одном месте. Когда впервые услышал об этом, и не поверил. Сейчас же, анализируя свой тренд и тренды бывших/нынешних коллег, вижу, что ошибался - в основном через 3 - 4 года начинаются телодвижения в части изменения углов рыскания, крена и тангажа.
если только инженер лет 5-6 занимался термоменджментом и захотел узнать, как используется его подсистема в общей системе, он идет в общую интеграцию, чтобы заниматься системной инженерией, но хождения по параллельным путям мне не известны
Слышал, что среднестатистически инженер работает на одном месте от 3 до 4 лет. Это включает в себя и переходы в другую фирму с теми же самыми или сходными задачами за 10% надбавки. У конструкторов довольно часто такое бывает.
редчайший момент, как правило, наблюдается среди очень молодых специалистов, ищущих себя или среди опытных, но из соображений личного характера - переезд, развод с женой, даже болезнь. таковы мои наблюдения. переход на новую специфику без повышения мне знаком по двум случаям.
У нас в концерне есть правило мин. 2 года на одном месте, потом можешь искать другое место, и в основном многие ищут (как правило, стараются внутри концерна). Это касается всех сотрудников с в/о. Те, кто с аусбилдунгом, как правило, сидят всю жизнь на одном месте.
Работая на фирме-производилере СРМ-систем, я не веду большие проэкты, т.к. у меня не так много опыта. Как правило у меня проект реализуется следующим образом.
Клиент присылает Ластенхефт. Согласно которому оцениваю стоимость, не точно, а от .. и до ... по пунктам от написания пхлиштенхефта до окончания проэкта (примерно 10-20% от оцененного времени я докидываю на всакий случай). Если мы получаем зеленый свет, то тогда:
1. Тирминирование согласно моему оцениванию. (+Projektplan)
2. Воркшоп (консалтинг), возможно серия воркшопов 5-6 дней с руководителями разных департаментов. (1-2 сеньора). Во время воркшопов обязательно пишутся протоколы, которые потом станут основой для пфлиштенхефта.
3. Пилот-Инсталляция (джуниор) + стандартная демо-версия программы.
4. В зависимости от воркшопов: настройки в программе. После кастомайзинга, когда уже примерно ясно, что
к чему, передаю шефу программистов на дополнительное программирование. Он распределяем работу между своими людьми. Пока программисты пишут доп. программы (это может быть шниттштеллен ит.п.), клиент уже начинает тестировать первые модули, которые мы кастомизировали для него.
5. Программисты доделали -> клиент тестит дальШе.
6. Термин по доработке, исправить то что не нравится клиенту. -> клиент тестит дальШе (и так пока он не 100% доволен)
7. Как только получаю фрайгабе от клиента, устанавливаем программу лайф.
8. Тренинги (1-6 дней в зависимости от кол-ва сотрудников).
9. Абшлуссберихт.
Если допустим [не очень критичное] доп. программирование занимает много времени, то делаем фрайхгабе без него, а его подключаем уже в след. фазе.
Я не знаю, "правильно" ли я веду
проэкты, но работает. ... Самое тяжелое - это когда что-то идет не по плану. Потом у меня в пятницу нет терминов после 12:00 на случай, если вдруг в начале недели у клиента проблемы.
Но опять же мы говорим о СРМ, которые я внедряю в миттельштанде. Я уверена, что в крупных фирмах все намного сложнее.... особенно если речь идет о бухгалтерских программах...
А можно спросить?
Каковы твои обязанности в проекте? И какова роль продакт-менеджера? Или у вас их нет?
Я согласовываю с склиентом все требования, провожу воркшопы, составляю проэкт-план, скетч базы данных (какие поля, таблицы, дизайн), что и как. Обсуждаю что надо (до)купить, какой сервер и т.п. А дальше "раздаю" задания консультантам и/или программистам, часть возможно делаю сама, смотря что. И в дальнейшем большая часть коммуникации с клиентом идет через меня. Я не уверена, что другие так делают тоже, но у нас на фирме так. Опять же, речь идет о проэктах для миттельштанда либо для одного-двух-трех отдела(-лов) крупных предприятий.
Ну это и неправильно, имхо. Продакт-менеджер должен решать, что программировать, а не шеф разработчиков. Его дело - техническая реализация.
я думаю, что это не так однозначно как ты пишешь. Я уже писала, что проект менеджмент это в первую очередь координация проекта (и возможен полностью без знания технической стороны, но при наличии головы в принципе).
Куда меня звали в Сименс - это назвалось таки technischer Projektleiter. И эта должность как раз таки означала бы утверждение технической стороны.
Структуры могут быть разными, но если шеф разработчиков не принимает концепции продакт-менеджера - то по-моему это неправильно. Ведь продакт-менеджер развивает свой продукт, а разработчик решает, какова будет техническая реализация.
Она проект, а уходят от них продакты, потому что разработчики их не слушают.
Продакт-менеджер это же не дурак-заказчик, сам не знающий, чего хочет. Он должен fachliche часть своего продукта понимать лучше всех. А как технически это реализовать, пусть решают разработчики. Тогда им почти не о чем спорить
если продукт-менеджер просит реализовать ему пересекающиеся параллельные линии
В каждой шутке есть доля шутки. Дважды сталкивался сам с подобными гениями от управления. Никакие уравнения Максвелла и начала термодинамики в качестве аргументов не воспринимались - партия просто сказала: "Нужно!"
Вообще-то продакт-менеджер - это не управленец. Он занимается своим продуктом, и, прими он самодурские решения, ему не на кого было бы кивать. Этим мне и нравится эта роль, что вспахиваешь собственное поле
Ну понимаешь, это его продукт. Он страдает от неудачи, ему не повезло, а не разработчикам.
Каждый говорит о том, что что знает сам. Везде, где я работала, было так - продакт-менеджер больше всех болел за свой продукт. А где-то наверно иначе.
Видимо, так. И обычно вся эта "нагрузка" в виде проедателей бюджета различных специалистов разговорного жанра не характерна для индустрии, но тоже имеет место быть: обычно же этим усиленно "страдают" представители разного рода сервисов или, как на Украине (в меньшей степени Белоруссия и еще меньше РФ), те же самые "галеры" - формошлепы из аутсорса.
Какую должность вы называете проедателями бюджета и специалистами разговорного жанра? Я их ни в одном из типажей, о которых идет речь, не вижу
То есть надо только программировать, программировать и программировать? А что, что зачем и когда - неважно?
да, при условии, что обе стороны имееют более-менее один и тот же уровень знаний об объекте дискуссии, что есть большая редкость, когда начинаются cross-functional или cross-hierarchic беседы.
не на всех фирмах есть такие CEO каким был Steve Jobs. и даже он пользовался Power Point при презентации своих продуктов.