Во-первых, что это за название? Резюме — это краткая сводка. Т.е. я делаю вывод, что это приблизительный аналог Project Charter в PMI PMBoK. Подробное описание — это Устав Проекта (в российской практике) или Project Management Plan в PMI PMBoK. Судя по структуре документа, резюме у Вас это что-то среднее — первая половина — Project Charter, все вместе — фрагменты PM Plan'а.
Во-вторых, пункт в резюме «масштаб и границы проекта» и все что ниже (особенно, график проекта) — Вы готовы подписать у спонсора (покровителя в Вашей терминологии) все это без этапа планирования? Коли у Вас еще до планирования дело не дошло. Финализация и утверждение PM Plan'a и Project Schedule (графика проекта) — это самый последний шаг этапа планирования, непосредственно перед началом исполнения проекта.
Мой совет — возьмите PMBoK, хорошие книги типа Kerzner H. Project Management. A Systems Approach to Planning, Scheduling, and Controlling, 10e, изучите, получите опыт хороший в управлении проектом в позиции менеджера проекта (а не снизу-сбоку) с тем, чтобы описанные там вещи наполнились для Вас конкретным смыслом — и тогда Вашим размышлениям об управлении проектами цены не будет. Пока же это бессистемная обрывочная плохо затеоретизированная каша, ЛИНКу жирный минус. Вам спасибо за старания и интерес к теме.
Планировал написать, да забыл — где WBS и вообще schedule? Без этого вообще говорить не о чем на этапе планирования проекта. Где HR management — а это основная российская проблема и важная причина провала проектов (упомянуто вскользь).
За что важное на этапе планирования проекта ни хватись, этого в заметке либо нет, либо совсем уж только упомянуто.
Ну и наконец, что должно быть результатом работы МП? Какие документы и с какой структурой? Хороший, кстати, способ объяснения, что должен сделать МП — набор шаблонов документов по управлению проектами, и чтобы их правильно заполнить, МП вынужден будет ответить на все важные вопросы и провести соотв. работы.
Детально не знаком с подходом такой авторитетной организации в области управления проектами, как БШ МИМ ЛИНК, но вижу по этой заметке, что PMI PMBoK накроет ее методику как петух курицу.
С т.з. менеджера проектов (МП), инициация и планирование проекта (т.е. то, о чем заявлена заметка) — это примерно половина всего объема работ МП в проекте. У Вас же очень обще описана дай бог четвертая часть работ МП на этих этапах.
Примерно представляя себе, как стряпаются материалы по курсам (в данном случае, явно непрофильным для ЛИНК), рекомендую Вам все-таки черпать информацию и подходы в серьезных источниках.
Методология управления проектами, описанная в PMI PMBoK, представляет собой комплексный системный подход (рамочную методологию) к управлению крупными распределенными проектами с большими бюджетами и большими полномочиями/ответственностью менеджеров проектов. Предлагаемый там состав, содержание и последовательность процессов/активностей (а также устоявшаяся общепризнанная терминология) является своего рода лучшей практикой в управлении проектами, т.е. «большинство опытных менеджеров проектов считают их полезными в большинстве случаев для большинства проектов».
Вместе с тем, есть много хороших, достойных и интересных книг по управлению проектами, но в них описан частный субъективный взгляд автора на управление проектами особых типов (напр., айтишных или строительных, в зависимости от бэкграунда автора), и даются рекомендации применительно к конкретному контексту. В PMBoK же каждый шаг, этап, activity, структуры, показатели… обсасываются огромным количеством практикующих профессионалов из разных областей до тех пор, пока они не придут к консенсусу. По поводу концептуальных вещей проводятся огромные семинары и конференции.
Теперь конкретно о том, что Вы написали, несколько замечаний. По финансовым деталям. Менеджер проекта (по меньшей мере, в понимании PMI) НЕ ОТВЕЧАЕТ ЗА ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ПРОЕКТА (NPV, IRR, срок окупаемости и т.д.). За это отвечают люди, находящиеся выше МП и ставящие/инициирующие проектные задачи МП. МП, естественно, должен быть в курсе этих задач для правильной подготовки (НЕ ПРИНЯТИЯ) соотв. решений, но он отвечает ТОЛЬКО за сроки, бюджет, качество (удовлетворенность) и ряд других. Соответствующие метрики проекта (у Вас отсутствуют) — earned value, SPI (schedule performance index), CPI (cost performance index), соответствующие planned, actual, earned, variance, forecast/estimation и т.д. Либо тогда надо говорить, что МП выполняет в компании, так уж повелось, функции, связанные с инвестиционным и бизнес-планированием.
Поскольку в российских реалиях чаще всего МП не управляет бюджетом проекта (а, скажем так, является распорядителем некоей его части и готовит соотв. отчетность), имеет смысл осветить эти моменты — расчет костов (себестоимости для компании), соглашение о костах внутри компании (с сейлзом, если проект выполняется по закл. договору), работа с подрядчиками и т.д.
Т.к. это Ваша первая общая обзорная статья в цикле статей, особо дальше придираться не буду, хотя поводов огромное количество. Спасибо.
Здесь хотя бы из личного опыта человек сам написал, а не компиляшка западных новостей при почти полном непонимании сути из-за банального отсутствия опыта. Что нередко бывает, как вы понимаете.
Цель д.б. одна (абстрактно сформулированная), иначе это уже несколько проектов. Для достижения цели необх. решение нескольких задач. В данном конкретном случае, грубо говоря, цель — организация денежного потока для владельцев ресурса путем удовлетворения неких потребностей клиентов. И дальше начинается: какого потока? каких потребностей? каких клиентов? что значит удовлетворить? как у них появится/проявится эта потребность? как они нас найдут? как все это будет организовано? и т.д.
Слово «абстрактный» — это не ругательное, как многие думают (что-то типа эфемерное, пустое, не имеющее отношения к реальной жизни, пустая болтовня, вздорный вымысел, удел импотентных философов и т.д.). Это пирамида мышления, когда вышележащий слой определяет бытие (смысл, цели, требования, ограничения, контроль и обратная связь) нижележащих. Ошибки/недоработанность в верхних слоях фатальны. В проектном управлении есть даже эмпирическое правило, стоимость ошибки 100:10:1 (по мере убывания абстрактности — от концепции… и до спецификаций на разработку).
Меня тоже поразили низкоуровневые технические детали в концепции.
Концепция — высокоуровневый абстрактный документ, описывающий вИдение будущего продукта/сервиса. Если дополнить концепцию как следует цифрами и выкладками — получится классический бизнес-план. Планирование дальнейшей реализации — классическое управление проектами. И т.д. — венчурное финансирование, маркетинг..., — хорошо проработанные области знаний.
Короче, каша какая-то у Вас получилась. Вывод, конечно, правильный у Вас: если что-то собрались делать — надо подходить к этому серьезно, или вообще не браться.
Задумки хорошие, автор — молодец, но я про другое тут подумал.
Чтобы можно было такую автоматически управляемую машину выпустить на улицу с людьми, нужно чтобы уровень надежности был минимум на порядок выше необходимого. В данном случае — чтобы система полностью хавала сцену (с 3D-реконструкцией) и могла, грубо говоря, «время определить на часах у пешехода».
Вместо невнятных схем с задиранием контраста на специально подобранных «удобных» картинках. Вы ж подавите всех…
А почему 40 секунд на одну картинку в фотошопе? Почему так много? Фотошоп к тому же батчит неплохо.
180 * 1,5 = 270 Мб/с была скорость чтения картинок в течение 9 суток. Это не поражает воображение, обычный сильный домашний комп, напр., с какой-нибудь CUDA для аппаратного жмаканья.
Я не понял, если у них скорость обработки фотографий фактически равна скорости чтения этих фотографий из NFS, то зачем все эти описания мутков с перлами и GraphicMagick'ами? Ну придумали как быстро считать-записать, жмаканье-то не проблема сейчас.
Тогда форма подачи материала в статье называется «Начали за здравие, кончили за упокой».
Сначала рассказывается о ненужности компаний (все сидят вместе в душном офисе) как таковых — рулят проектно самоорганизующиеся распределенные команды профессионалов, «работа 2.0» и т.д.
Потом приводятся примеры обычных компаний, только обширно практикующих аутсорсинг нестратегических компетенций и непрофильных операций. Да огромное количество крупных компаний этим занимаются, даже примеры приводить не нужно. Та же Apple в этом плане от Aliph не отличается.
Мне кажется, что между этими двумя операционными моделями бизнеса огромная разница и, соответственно, иллюстрирующие примеры подобраны неудачно.
Ну, не Sony они (Aliph) бросают вызов, а, может, какому-то частному продукту Sony. Где Sony, и где Aliph.
По поводу мелочевки всякой и развлекательной ерунды — да, такое работает. Типа как такие партизаны.
А вот серьезное оборудование или нетривиальные услуги — вряд ли. Нужен соответствующий уровень интеграции, централизованности, ответственности и т.д — это уже организованная армия.
К примеру, взорвется не дай бог эта финтифлюшка, не дай бог пострадают дети — обращаться в китайский гараж к дядюшке Ляо или студентам на а/я (автоответчик, мейл) в техас? Где концы? Где обслуживание? Где гарантия? Кому морду лица бить? Наверное, такое тоже аутсорсится куда-нибудь в индию.
А я рекомендую всем как можно раньше заиметь отрицательную карму. Чем ниже, тем лучше.
Тогда можно писать то, что действительно думаешь. Не заботясь о восприятии твоих слов и мыслей коллективным бессознательным, архетипичными персонажами и прочим «интеллектуальным большинством».
Все четыре кейса — чистые управленческие ошибки (miscasting — возможно, неплохие люди поставлены не на свои должности/получили задачи не по адресу).
1) Анализ ситуации. Ошибки со стороны заказчика — недостаточный контроль/отсутствие оного, со стороны исполнителя — обычный исполнитель на позиции РП. Т.е. он и его руководство не понимают, кто такой РП и чем он должен заниматься (руководить людьми, отвечать за результаты, сроки, качество, результаты и ресурсы, планировать и готовить отчетность).
Что делать. Тут непонятно, на какой стороне находится тот, кому надо «что-то делать». Исполнителю — поставить на проект опытного РП, текущего сделать его формальным замом и фактически отстранить от управления проектом (по меньшей мере этот проект он будет дорабатывать как обычный исполнитель). Исполнителю и Заказчику провести встречи с целью пересмотра time\money\scope, попробовать прийти к компромиссу. На основе договоренного составить подробный график оставшихся работ, минимум раз в неделю совещание руководителей проектов и кураторов от Зак+Исп с анализом выполнения проекта и дальнейшими уточнениями плана и задач.
Если новый РП от исполнителя хороший переговорщик, то скорее всего будет вариант — проект будет сделан чуть дольше и чуть дороже для заказчика, исполнителю придется больше попотеть с меньшей маржой.
Если мы на стороне Заказчика, вполне вероятно, что хорошим вариантом будет банальное «пидарасить и дисконтировать» Исполнителя, за маржу Исполнителя доделать работу в максимально возможные сроки. Нужно больше информации о ситуации. Либо, опять же, компромисс, описанный выше.
3) Трудно сказать, нужно больше информации. Возможно, вы недостаточно «авторитетны» и не владеете ситуацией, а ваш руководитель счел (возможно, вполне резонно), что добавлять в горящий проект нового руководителя не надо, а данный человек лучше подойдет как тренер. Если это категорически не так и вашими интересами просто поступились, то, в зависимости от личности вашего руководителя, либо дипломатия, либо аккуратный скандал с привлечением вышестоящих арбитров и пересмотром схемы набора персонала, либо поиметь с этого «политические баллы».
Так если вы согласны, то по голове дать надо руководителю, который студенту такое задание дал. Я вообще не понимаю, что может полезного этот студент написать? Тем более, на сайт компании, т.е. влияющее на репутацию компании.
Такое писать должны ресурсные менеджеры (центры компетенции), директора (ответственные за направления бизнеса), руководители проектов (case studies, success stories, пресс-релизы), и т.д. Крайне желательно, чтобы еще и пиарщики/маркетологи или даже сейлзы глянули, расставили акценты для целевой аудитории.
Студент не справляется — задачу ставить более подробно (в данном случае, набросать структуру документа — ключевые мысли, которые д.б. освещены, обязательно сказать, что copy-paste неприемлем и будет проверяться — студент же, сразу полезет «за рефератами»), дать ментора, чаще контролировать. Если вообще не тянет (ему тема/работа неинтересна, звезда на торпедном катере, «клинический идиот» и т.д.) — тогда выгонять.
На высокооплачиваемую должность (руководящую) в серьезные компании типа Google, Microsoft, McKinsey & Company, Bain & Company, Boston Consulting Group и тому подобные наш с вами «истеричный нарцисс, встающий и уходящий чуть что» не попадет. По меньшей мере, по личностным качествам.
На техническую должность (кабель там тянуть и обжимать, линукс настраивать, CMS-ку клепать, быдлокодить новые функции и т.д.) — возможно.
На серьезных ответственных должностях, подразумевающих общение с подчиненными, коллегами, клиентами, партнерами и т.д., не нужны недотроги, которые чуть что не понравилось — встают и хлопают дверями. Как против шерсти погладили — сразу биться в истерическом припадке (хотя какая там шерсть — это же просто тест на способности)? Ну удачи…
Грамотный адекватный человек из любой ситуации может выйти победителем или по меньшей мере красиво и достойно. В данном случае — попытаться пройти сложный тест в меру возможностей. Если в компании проводят тестирование сложными вопросми — значит так надо. В конце концов, у каждой авторитетной компании бывают свои маленькие причуды, может, это была экспериментальная программа нового HR-руководителя, может, еще чего. В любой, даже самой замечательной компании всегда найдется что-то, что не нравится.
Вот вам пример: в хорошую компанию, являющуюся лидером в своем секторе, на вакансию предварительный отбор (жесткий скрининг + тел. интервью) прошли 3 специалиста — А, Б и В. Забегая вперед, все три они на технических собеседованиях были признаны примерно одинаково подходящими (±, паритет). Единственное, формально у специалиста А чуть меньше опыта.
Специалист А в целом спокоен, резко соображает и отлично прошел тесты на сообразительность, показав эрудицию, смекалку и даже просто чувство юмора (там где не смог решить).
Специалист Б, насупишвись, все-таки худо-бедно что-то там ответил, правда, больше половины — неправильно.
Специалист В отказался проходить тест, заявив, что не видит в этом смысла и необходимости [для примера допустим, что до вызова охраны не дошло — истерику он не устраивал, дверями не хлопал, мебель не бил].
Очевидно, возьмут специалиста А. Специалисту Б скажут «мы с вами свяжемся» и оставят на резерв (если А в последний момент откажется). Чувака В поблагодарят за интерес к компании и пожелают удачи.
Коллега, я с написанным вами абсолютно согласен. Единственное только уточню, что головоломки/тесты — это лишь один из оцениваемых компонентов, на руководящие позиции его вес в общем оценивании кандидата может уменьшаться (в т.ч. до нуля, т.е. вообще не проводится). Кроме того, в некоторых компаниях прохождение этих тестов является обязательным для вообще всех сотрудников (напр., CBOSS, не к ночи будет помянут).
Не совсем понял, с чем именно вы не согласились?
1. Молодняк: «Головоломки — один из компонентов «HR-фильтра», коэффициентами которого можно и нужно «играть» в зависимости от соотношения спрос-предложение». Т.е. однозначно надо давать, если есть возможность.
2. Профессионалы (технические): «Хорошему крепкому профи, туго знающему свое дело, можно простить эти тесты. Если именно такой (а не молодой, неопытный, но «перспективный») нужен, то даже смысла давать головоломки нет».
3. Руководители: «скорее нужны не тесты на логику-математику, а нетривиальные проф. кейсы, в т.ч. на поведенческий компонент, смекалку, быструю реакцию».
Я имел в виду на руководящие позиции. Хорошему крепкому профи, туго знающему свое дело, можно простить эти тесты. Если именно такой (а не молодой, неопытный, но «перспективный») нужен, то даже смысла давать головоломки нет.
Во-первых, что это за название? Резюме — это краткая сводка. Т.е. я делаю вывод, что это приблизительный аналог Project Charter в PMI PMBoK. Подробное описание — это Устав Проекта (в российской практике) или Project Management Plan в PMI PMBoK. Судя по структуре документа, резюме у Вас это что-то среднее — первая половина — Project Charter, все вместе — фрагменты PM Plan'а.
Во-вторых, пункт в резюме «масштаб и границы проекта» и все что ниже (особенно, график проекта) — Вы готовы подписать у спонсора (покровителя в Вашей терминологии) все это без этапа планирования? Коли у Вас еще до планирования дело не дошло. Финализация и утверждение PM Plan'a и Project Schedule (графика проекта) — это самый последний шаг этапа планирования, непосредственно перед началом исполнения проекта.
Мой совет — возьмите PMBoK, хорошие книги типа Kerzner H. Project Management. A Systems Approach to Planning, Scheduling, and Controlling, 10e, изучите, получите опыт хороший в управлении проектом в позиции менеджера проекта (а не снизу-сбоку) с тем, чтобы описанные там вещи наполнились для Вас конкретным смыслом — и тогда Вашим размышлениям об управлении проектами цены не будет. Пока же это бессистемная обрывочная плохо затеоретизированная каша, ЛИНКу жирный минус. Вам спасибо за старания и интерес к теме.
За что важное на этапе планирования проекта ни хватись, этого в заметке либо нет, либо совсем уж только упомянуто.
Ну и наконец, что должно быть результатом работы МП? Какие документы и с какой структурой? Хороший, кстати, способ объяснения, что должен сделать МП — набор шаблонов документов по управлению проектами, и чтобы их правильно заполнить, МП вынужден будет ответить на все важные вопросы и провести соотв. работы.
Пример PMBoK4-aligned шаблонов:
www.oregon.gov/DHS/admin/bpm/pmo/PPO_Tools_Templates.shtml
С т.з. менеджера проектов (МП), инициация и планирование проекта (т.е. то, о чем заявлена заметка) — это примерно половина всего объема работ МП в проекте. У Вас же очень обще описана дай бог четвертая часть работ МП на этих этапах.
Примерно представляя себе, как стряпаются материалы по курсам (в данном случае, явно непрофильным для ЛИНК), рекомендую Вам все-таки черпать информацию и подходы в серьезных источниках.
Методология управления проектами, описанная в PMI PMBoK, представляет собой комплексный системный подход (рамочную методологию) к управлению крупными распределенными проектами с большими бюджетами и большими полномочиями/ответственностью менеджеров проектов. Предлагаемый там состав, содержание и последовательность процессов/активностей (а также устоявшаяся общепризнанная терминология) является своего рода лучшей практикой в управлении проектами, т.е. «большинство опытных менеджеров проектов считают их полезными в большинстве случаев для большинства проектов».
Вместе с тем, есть много хороших, достойных и интересных книг по управлению проектами, но в них описан частный субъективный взгляд автора на управление проектами особых типов (напр., айтишных или строительных, в зависимости от бэкграунда автора), и даются рекомендации применительно к конкретному контексту. В PMBoK же каждый шаг, этап, activity, структуры, показатели… обсасываются огромным количеством практикующих профессионалов из разных областей до тех пор, пока они не придут к консенсусу. По поводу концептуальных вещей проводятся огромные семинары и конференции.
Теперь конкретно о том, что Вы написали, несколько замечаний. По финансовым деталям. Менеджер проекта (по меньшей мере, в понимании PMI) НЕ ОТВЕЧАЕТ ЗА ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ПРОЕКТА (NPV, IRR, срок окупаемости и т.д.). За это отвечают люди, находящиеся выше МП и ставящие/инициирующие проектные задачи МП. МП, естественно, должен быть в курсе этих задач для правильной подготовки (НЕ ПРИНЯТИЯ) соотв. решений, но он отвечает ТОЛЬКО за сроки, бюджет, качество (удовлетворенность) и ряд других. Соответствующие метрики проекта (у Вас отсутствуют) — earned value, SPI (schedule performance index), CPI (cost performance index), соответствующие planned, actual, earned, variance, forecast/estimation и т.д. Либо тогда надо говорить, что МП выполняет в компании, так уж повелось, функции, связанные с инвестиционным и бизнес-планированием.
Поскольку в российских реалиях чаще всего МП не управляет бюджетом проекта (а, скажем так, является распорядителем некоей его части и готовит соотв. отчетность), имеет смысл осветить эти моменты — расчет костов (себестоимости для компании), соглашение о костах внутри компании (с сейлзом, если проект выполняется по закл. договору), работа с подрядчиками и т.д.
Т.к. это Ваша первая общая обзорная статья в цикле статей, особо дальше придираться не буду, хотя поводов огромное количество. Спасибо.
Цель д.б. одна (абстрактно сформулированная), иначе это уже несколько проектов. Для достижения цели необх. решение нескольких задач. В данном конкретном случае, грубо говоря, цель — организация денежного потока для владельцев ресурса путем удовлетворения неких потребностей клиентов. И дальше начинается: какого потока? каких потребностей? каких клиентов? что значит удовлетворить? как у них появится/проявится эта потребность? как они нас найдут? как все это будет организовано? и т.д.
Слово «абстрактный» — это не ругательное, как многие думают (что-то типа эфемерное, пустое, не имеющее отношения к реальной жизни, пустая болтовня, вздорный вымысел, удел импотентных философов и т.д.). Это пирамида мышления, когда вышележащий слой определяет бытие (смысл, цели, требования, ограничения, контроль и обратная связь) нижележащих. Ошибки/недоработанность в верхних слоях фатальны. В проектном управлении есть даже эмпирическое правило, стоимость ошибки 100:10:1 (по мере убывания абстрактности — от концепции… и до спецификаций на разработку).
Концепция — высокоуровневый абстрактный документ, описывающий вИдение будущего продукта/сервиса. Если дополнить концепцию как следует цифрами и выкладками — получится классический бизнес-план. Планирование дальнейшей реализации — классическое управление проектами. И т.д. — венчурное финансирование, маркетинг..., — хорошо проработанные области знаний.
Короче, каша какая-то у Вас получилась. Вывод, конечно, правильный у Вас: если что-то собрались делать — надо подходить к этому серьезно, или вообще не браться.
Чтобы можно было такую автоматически управляемую машину выпустить на улицу с людьми, нужно чтобы уровень надежности был минимум на порядок выше необходимого. В данном случае — чтобы система полностью хавала сцену (с 3D-реконструкцией) и могла, грубо говоря, «время определить на часах у пешехода».
Вместо невнятных схем с задиранием контраста на специально подобранных «удобных» картинках. Вы ж подавите всех…
180 * 1,5 = 270 Мб/с была скорость чтения картинок в течение 9 суток. Это не поражает воображение, обычный сильный домашний комп, напр., с какой-нибудь CUDA для аппаратного жмаканья.
Я не понял, если у них скорость обработки фотографий фактически равна скорости чтения этих фотографий из NFS, то зачем все эти описания мутков с перлами и GraphicMagick'ами? Ну придумали как быстро считать-записать, жмаканье-то не проблема сейчас.
Мало что понял, мутная статья.
Сначала рассказывается о ненужности компаний (все сидят вместе в душном офисе) как таковых — рулят проектно самоорганизующиеся распределенные команды профессионалов, «работа 2.0» и т.д.
Потом приводятся примеры обычных компаний, только обширно практикующих аутсорсинг нестратегических компетенций и непрофильных операций. Да огромное количество крупных компаний этим занимаются, даже примеры приводить не нужно. Та же Apple в этом плане от Aliph не отличается.
Мне кажется, что между этими двумя операционными моделями бизнеса огромная разница и, соответственно, иллюстрирующие примеры подобраны неудачно.
По поводу мелочевки всякой и развлекательной ерунды — да, такое работает. Типа как такие партизаны.
А вот серьезное оборудование или нетривиальные услуги — вряд ли. Нужен соответствующий уровень интеграции, централизованности, ответственности и т.д — это уже организованная армия.
К примеру, взорвется не дай бог эта финтифлюшка, не дай бог пострадают дети — обращаться в китайский гараж к дядюшке Ляо или студентам на а/я (автоответчик, мейл) в техас? Где концы? Где обслуживание? Где гарантия? Кому морду лица бить? Наверное, такое тоже аутсорсится куда-нибудь в индию.
Тогда можно писать то, что действительно думаешь. Не заботясь о восприятии твоих слов и мыслей коллективным бессознательным, архетипичными персонажами и прочим «интеллектуальным большинством».
1) Анализ ситуации. Ошибки со стороны заказчика — недостаточный контроль/отсутствие оного, со стороны исполнителя — обычный исполнитель на позиции РП. Т.е. он и его руководство не понимают, кто такой РП и чем он должен заниматься (руководить людьми, отвечать за результаты, сроки, качество, результаты и ресурсы, планировать и готовить отчетность).
Что делать. Тут непонятно, на какой стороне находится тот, кому надо «что-то делать». Исполнителю — поставить на проект опытного РП, текущего сделать его формальным замом и фактически отстранить от управления проектом (по меньшей мере этот проект он будет дорабатывать как обычный исполнитель). Исполнителю и Заказчику провести встречи с целью пересмотра time\money\scope, попробовать прийти к компромиссу. На основе договоренного составить подробный график оставшихся работ, минимум раз в неделю совещание руководителей проектов и кураторов от Зак+Исп с анализом выполнения проекта и дальнейшими уточнениями плана и задач.
Если новый РП от исполнителя хороший переговорщик, то скорее всего будет вариант — проект будет сделан чуть дольше и чуть дороже для заказчика, исполнителю придется больше попотеть с меньшей маржой.
Если мы на стороне Заказчика, вполне вероятно, что хорошим вариантом будет банальное «пидарасить и дисконтировать» Исполнителя, за маржу Исполнителя доделать работу в максимально возможные сроки. Нужно больше информации о ситуации. Либо, опять же, компромисс, описанный выше.
2) написал здесь: habrahabr.ru/blogs/arbeit/96084/#comment_3020084
3) Трудно сказать, нужно больше информации. Возможно, вы недостаточно «авторитетны» и не владеете ситуацией, а ваш руководитель счел (возможно, вполне резонно), что добавлять в горящий проект нового руководителя не надо, а данный человек лучше подойдет как тренер. Если это категорически не так и вашими интересами просто поступились, то, в зависимости от личности вашего руководителя, либо дипломатия, либо аккуратный скандал с привлечением вышестоящих арбитров и пересмотром схемы набора персонала, либо поиметь с этого «политические баллы».
4) С вариантом автора в целом согласен.
Такое писать должны ресурсные менеджеры (центры компетенции), директора (ответственные за направления бизнеса), руководители проектов (case studies, success stories, пресс-релизы), и т.д. Крайне желательно, чтобы еще и пиарщики/маркетологи или даже сейлзы глянули, расставили акценты для целевой аудитории.
Студент не справляется — задачу ставить более подробно (в данном случае, набросать структуру документа — ключевые мысли, которые д.б. освещены, обязательно сказать, что copy-paste неприемлем и будет проверяться — студент же, сразу полезет «за рефератами»), дать ментора, чаще контролировать. Если вообще не тянет (ему тема/работа неинтересна, звезда на торпедном катере, «клинический идиот» и т.д.) — тогда выгонять.
На техническую должность (кабель там тянуть и обжимать, линукс настраивать, CMS-ку клепать, быдлокодить новые функции и т.д.) — возможно.
На серьезных ответственных должностях, подразумевающих общение с подчиненными, коллегами, клиентами, партнерами и т.д., не нужны недотроги, которые чуть что не понравилось — встают и хлопают дверями. Как против шерсти погладили — сразу биться в истерическом припадке (хотя какая там шерсть — это же просто тест на способности)? Ну удачи…
Грамотный адекватный человек из любой ситуации может выйти победителем или по меньшей мере красиво и достойно. В данном случае — попытаться пройти сложный тест в меру возможностей. Если в компании проводят тестирование сложными вопросми — значит так надо. В конце концов, у каждой авторитетной компании бывают свои маленькие причуды, может, это была экспериментальная программа нового HR-руководителя, может, еще чего. В любой, даже самой замечательной компании всегда найдется что-то, что не нравится.
Вот вам пример: в хорошую компанию, являющуюся лидером в своем секторе, на вакансию предварительный отбор (жесткий скрининг + тел. интервью) прошли 3 специалиста — А, Б и В. Забегая вперед, все три они на технических собеседованиях были признаны примерно одинаково подходящими (±, паритет). Единственное, формально у специалиста А чуть меньше опыта.
Специалист А в целом спокоен, резко соображает и отлично прошел тесты на сообразительность, показав эрудицию, смекалку и даже просто чувство юмора (там где не смог решить).
Специалист Б, насупишвись, все-таки худо-бедно что-то там ответил, правда, больше половины — неправильно.
Специалист В отказался проходить тест, заявив, что не видит в этом смысла и необходимости [для примера допустим, что до вызова охраны не дошло — истерику он не устраивал, дверями не хлопал, мебель не бил].
Очевидно, возьмут специалиста А. Специалисту Б скажут «мы с вами свяжемся» и оставят на резерв (если А в последний момент откажется). Чувака В поблагодарят за интерес к компании и пожелают удачи.
Так понятно?
Не совсем понял, с чем именно вы не согласились?
1. Молодняк: «Головоломки — один из компонентов «HR-фильтра», коэффициентами которого можно и нужно «играть» в зависимости от соотношения спрос-предложение». Т.е. однозначно надо давать, если есть возможность.
2. Профессионалы (технические): «Хорошему крепкому профи, туго знающему свое дело, можно простить эти тесты. Если именно такой (а не молодой, неопытный, но «перспективный») нужен, то даже смысла давать головоломки нет».
3. Руководители: «скорее нужны не тесты на логику-математику, а нетривиальные проф. кейсы, в т.ч. на поведенческий компонент, смекалку, быструю реакцию».