У нас проект по разработке и внедрению новой ИТ-системы! И нужен ПМ…
Случалось? Куда ж без этого. И вроде бы рынок насыщен всевозможного рода руководителями проектов.
— Выбирай! У всех прекрасный богатый опыт. Есть ПМ-ы с опытом внедрения проектов в Строительстве и Оборонке. Есть ПМ-ы с опытом внедрения медицинских проектов. Есть даже в Авиастроительстве! Что тебе еще надо!? Уровень ответственности и требовательности в этих отраслях – полный отвал башки.
— А он знает ИТ?
— Зачем тебе это?! У него прекрасные знания методологии ведения проектов…это – главное!
И такое тоже случалось…
Давайте разбираться, нужны ли знания в области ИТ руководителю проектов, который должен прийти и организовать разработку и внедрение информационной системы.
Итак, для начала нужно разработать информационную систему!
— Давай, ПМ, что будешь делать сначала?Совсем недавно я столкнулся с подобной историей. С одной стороны, вроде бы все ровно. Действительно, программист знает, из каких этапов обычно состоит разработка. Но, давайте сделаем поправку. Уж чтобы совсем не промахнуться, пойдем к Архитектору! Уж он то должен наверняка знать.
— Определим потребность и цели!
— Хорошо. А потом?
— Нарисуем план проекта по разработке!
— Логично. А из каких этапов состоит разработка? Надо же задачи верхнего уровня для композиции определить!
— Зачем мне это? Спрошу кого-нибудь!
— А кто в ИТ владеет этой информацией?
— Кто-кто? Программист…наверное…
— Привет, Архитектор. Из чего состоит разработка? Нужны задачи в план.Вот так, примерно, происходит, когда ПМ не в курсе.
— Надо взять ТЗ и запилить по нему функционал!
— И все?! Так просто?
— Ну еще протестировать.
— А что, если ТЗ в процессе поменяется?
— Это я не знаю. Мое дело – работать по ТЗ
Сходили. Спросили. Получили 2 пункта: ТЗ и Разработка.
— Что будем делать, ПМ?
— Так все понятно! ТЗ попросим и отдадим Архитектору. Пусть оценит. Скажет срок. Определит точки готовности, а мы его в этих точках будем контролировать. И переодически покзывать пользователю результат.
И что бы мы его спросили, когда брали на работу? А уж если совсем далеко пойти, то Что из себя представляет жизненный цикл Информационной системы от ее рождения до смерти. Хотя, системы не умирают. Они «морально» устаревают.
Никогда не забуду «веселую» историю с системой канального кондиционирования, которая случилась у нас на производстве. Нашли, значит, систему. Хорошую, мощную. Должна был весь завод и прилежащие административные здания охлаждать. Ну купили. За, что-то около 200K американских рублей. Поставили. Ввели в эксплуатацию. После нескольких месяцев работы система загнулась. Почему? Да потому что никакая система не выживет без поддержки и регулярного технического сопровождения!
А ведь информационная система ничем не отличается. Также, как и другие системы, требует ввода в эксплуатацию. Также, как другие – инфраструктуры. И, порой, ошибки внедрения, случившиеся на каком-нибудь проекте по внедрению финансовой системы, обходятся гораздо дороже, чем поломка кондея.
Так как же ПМ, который пришел в ИТ-проект из Авиа или Строительной отрасли сможет нарисовать план, который должен содержать все эти этапы?
Получит консультацию Архитектора? Который фрагментарно видит свою задачу и не представляет, что «до» и что «после»? Увы. Такой проект заранее обречен.
Поэтому, понимание ПМ-а, из каких задач состоит проект, какие задачи являются связанными, а какие можно делать параллельно – архи важно на ИТ-проекте.
И как теперь нам понять, на сколько ПМ соответствует ожидаемому результату? Для этого существует ряд не сложных вопросов, на которые мы должны получить внятные ответы.
Вопрос 1: Из каких этапов состоит формирование технического задания на разработку?
Ответ:
- Из формирования функциональных требований заказчика
- Формирования задания на инфраструктуру, которая, в свою очередь является результатом разработки Контракта по отказоустойчивости и резервному копированию
- И из карты взаимодействия будущей системы с другими системами.
Фактически, мы с вами получаем 3 задания на выходе: функционально-техническое, ТЗ на инфраструктуру, ТЗ на разработку интерфейсов. Они же являются check-point-ами для контроля.
Вопрос 2: Из каких этапов состоит разработка?
Ответ:
- Из распределения задач по разработчикам
- Из формирования плана приемо-сдаточных работ
- Из комплексного тестирования (пилотирования)
- Из создания плана миграции, и разработки этого плана
Вопрос 3: Из каких этапов состоит ввод в эксплуатацию?
Ответ:
- Нагрузочное тестирование
- Формирование методических материалов
- Обучение пользователей
- Заполнение всех НСИ (Нормативно Справочная Информация + доступы пользователей)
- Миграция данных
- Сверка остатков
- Старт операционной работы (пилотирования)
- Hot-assist в период первого запуска
Вопрос 4: Как выглядит схема передачи системы на поддержку, после ввода в эксплуатацию?
Ответ:
Как минимум у системы присутствуют 3 уровня поддержки:
- Инфраструктурная поддержка и мониторинг нагрузки на сервера
- Функциональная поддержка и мониторинг потоков, в случае, если что-то пошло не так в системе.
- Методологическая поддержка, дающая ответы на вопросы, почему это работает так, а не иначе, а также собирающая потребности в эволюциях
И у каждого из этих этапов должен быть свой SLA. Вот тоже словцо, которое не всегда понятно людям вне ИТ.
Если ПМ-кандидат назвал не все этапы – не беда. Мог что-то подзабыть или переволноваться. По мере формирования плана он так или иначе столкнется с ними. Гораздо хуже, если он не будет себе представлять этого абсолютно. Ситуация усложнится, если он начнет проецировать свой предыдущий опыт из других бизнес-сфер на ИТ. В этом случае в команде начнутся конфликты и «падеж» разработчиков. Благо работу технарь себе сможет найти всегда и там, где грамотное управление ИТ-проектом будет его зоной комфорта.
Комментарии (54)
pewpew
20.11.2018 20:09+1В моём понимании грамотный и правильный ПМ — человек, понимающий проект и знающий, как и что работает. При этом в основном он ставит задачи и разговаривает с менеджментом.
А если ПМ только и занимается индексами производительности и эффективности, то стоит задуматься. Ну а если он при этом совершенно не понимает, как проект, который он ведёт работает или не может адекватно оценить трудозатраты на поставленные задачи, то хреновый он ПМ, и крокодила с ним не поймать, кокос не выростить. В шею его гнать надо.
Когда-то, лет 5 назад я работал в одной компании с директором самодуром и совершенно не понимающими в программировании менеджерами, которые часто ставили задачи программистам. Так вот, в нашей небольшой группе программистов был действительно грамотный ПМ, сглаживающий неровности недопонимания кодеров, работающих по ТЗ и менеджеров, которым лишь бы продать уже разработанный продукт под другим соусом, и пофигу что требуется учитывать специфику и гнаться за сроками. Главное заключить контракт и наобещать с три короба.
Вот кстати от последнего конторка и развалилась. Переобещали малость.AntonMalanov Автор
20.11.2018 20:12Спасибо за Ваш комментарий. Абсолютно согласен! Написал реальный жизненный кейс с которым столкнулся… пришлось доказывать отделу кадров, что просто ПМа не достаточно.
SUA
20.11.2018 20:42По верхам…
От «формирования функциональных требований заказчика» переходим сразу к «распределению задач по разработчикам»
Если честно — не увидел особой разницы с диалогом с ПМ-ом который вообще не в курсе
MMik
20.11.2018 20:58-5Начинаю с выкидывания резюме кандидатов, не имеющих PMI PMP (PRINCE2 Pactitioner) и не знакомых с CMMI. Оставшихся уже зовём на очное собеседование с кейсами. В РФ такая практика у меня приводит к минимуму кандидатов с максимумом эффекта: нанимал человека после собеседований максимумум 4-5-ти кандидатов. В Европе кандидатов приходит значительно больше, среди них больше неопытных (буквально сразу после вуза), но зато можно найти несколько относительно недорогих сотрудников с горящими глазами, которые будут хорошо вести проекты (под руководством наставника).
Никогда не пробовал, но можно взять в сервис PM'а из IT компании, которая специализируется на разработке ПО. Думаю, что это будет хорошим вариантом для небольших компаний с небольшими проектами.gleb_kudr
20.11.2018 23:12+1PMI, CMMI… Ну да, когда надо оставить 4-5 из 100 резюме, то любой метод подходит. Можно просто выкинуть случайные. А что, компании не нужны неудачники :)
Я вот нанимал вообще с одного вопроса/ответа кандидату, даже не смотря в резюме. И очень доволен. Но глубокомысленных выводов не делаю, слава богу.
AyratK
22.11.2018 12:33PMBok задает структуру знаниям об управлении проектами. Вводит язык. Этот корпус знаний формировался десятилетиями. Мне было бы странно, если бы человек серьезно подходящий к профессии ПМа игнорировал бы PMBok.
Знание PMBok позволит избежать недопонимания в ходе общения.
А вообще про вопросы. Адекватность ПМа проверяется одним вопросом: «С чего начинается проект?». Большая часть неадекватов будет выявлена на этом этапе.uzverkms
22.11.2018 13:52Просто у MMik в одном абзаце говориться про отсеивание не имеющих сертификат PMP (а имеющих сертификат PMP на всю Россию дай бог 1,5 тыщи человек), а дальше упоминаются «недорогие сотрудники». Сочетание требований забавное. Конкурс на должность суровый, наверное условия сказочные.
ILya63
20.11.2018 21:30+1Мне много раз приходилось работать с ПМ без ИТ знаний, и я почти всегда был доволен, при этом находился в разных ролях и в том числе как ПМ проекта в портфеле как раз такого ПМ без ИТ знании. После работы с опытными ПМ лично я для себя понял, управление проектами это не какой-то второстепенный скил и он не приходит с опытом просто потому что ты разработчик, архитектор и т.д. этому надо учиться.
AntonMalanov Автор
21.11.2018 19:54Я бы сказал, одно из основных качеств ПМа — работать с людьми. И прежде всего через позитивную коммуникацию. Никто не любит человека-проблему. Ну и шарить в области и специфики. Иначе швах
saipr
20.11.2018 22:14А разве главная задача ПМ-а не управление бюджетом?
ILya63
20.11.2018 22:28+1Управление ресурсами
AntonMalanov Автор
21.11.2018 19:55Разделяю! Основное качетво ПМ-а (см выше) — работа с людьми. С ресурсами, конечно, тоже. Но Key soft skill — с людьми! Коммуникация!
surkov_nsk
21.11.2018 11:28Нет. Задача ПМ обеспечить, чтобы проект был внутри треугольника: срок, бюджет, содержание (качество) + заказчик должен быть доволен.
saipr
21.11.2018 11:59Ага, бюджет все же присутствует. Осталось понять чем должен быть доволен Заказчик.
surkov_nsk
21.11.2018 14:04Результатом проекта. Ведь бывает, что и сделали по ТЗ и в срок, бюджет уложились. А просили-то совсем не то, что получилось)
AntonMalanov Автор
21.11.2018 19:57О! Заказчик должен быть доволен!!! А вот хрена там! Заказчик сам не понимает, от чего он будет доволен в финале. Порой, пока ты его не выпнешь за зону комфорта, он мозги включать не начнет…
fishca
20.11.2018 22:19Понасмотрелись уже на этих эффективных менеджеров. Зачем вообще браться за внедрение чего-либо о чем очень отдаленное представление имеешь, особенно в ИТ?
DrPass
21.11.2018 00:28Я, честно говоря, не вижу никаких причин, почему в ИТ не справился бы ПМ с опытом работы в другой отрасли. Вы так описали кейсы, как будто бы у вас не чувак с опытом управления людьми, а дитя неразумное. В реальной жизни ПМ, приходя в ИТ из строительства, логистики, станкостроения или любой другой отрасли, сядет и прочтет книгу «Методологии управления проектами в ИТ», и после этого он будет знать ответы на указанные вопросы, и сможет приступать к работе.
fishca
21.11.2018 09:40Вот такие, которые прочитали книжки, а руками ничего в своей жизни никогда не трогали из ИТ тематики (даже эникеями не работали) как раз и топят на дно ИТ проекты. Наличие профессионального фотоаппарата не делает человека профессиональным фотографом.
OnelaW
21.11.2018 16:20В чем принципиальное отличие в управлении проектами в различных отраслях?
Только в специфике производства и дистрибуции готового продукта?
Выпуск в продакшн готовой комплексной системы это тоже своего рода процесс дистрибуции. Да, вероятнее данный проект будет уникальным или будет иметь малое количество возможность к репликации.
А еще какие отличия? Всё те же этапы и все те же роли в команде. Называются просто по разному.
У меня огромная просьба к сообществу не придумываете себе искусственный мирок элитарности. И разработчики и эникейщики и хелпдескеры и девопсы и пмщики и маркетологи и прочие. Понимаете ваши знания специфики не является уникальным преимуществом. Ваше умение эффективно применять ваши знания о специфике является вашим уникальным преимуществом.fishca
21.11.2018 16:35Т.е. нет разницы в проектах создания Буратино и Модели Буратино, я правильно понял? Как строить Буратин изучали с того момента как люди спустились с деревьев, а вот строить модели каких-то несколько десятков лет, вот вам и специфика и пропасть различий между ними.
OnelaW
21.11.2018 17:06Построить пирамиду и построить жилой многоквартирный дом, кроме специфики применяемых технологий есть отличия?
Произвести программный межсетевой экран и тот же межсетевой экран накатанный на железку какие отличия?
Внедрение комплексной системы для торговли и внедрение комплексной системы для архивного дела?
Производство танкера для транспортировки газа и производство авианосца?
В чем технологические отличия кроме специфики производимых работ?
Архитектор как-то по особенному производит расчеты?
Конструктора делают расчеты по особым уникальным методикам? Какие-то особые таблицы по материалам? Особые законы природы на каждом квадратном метре планете? Скорость света в двух соседних и одинаковых по составах кубах морской воды будет отличаться?
Я к тому, что глобально отличий нет. Производство продукции в любых отраслях уникальное, но глобально управление производством продукции одинаковое. И разработчик программного обеспечения и тот кто занимается развитием и поддержанием комплексной информационной системы и телеком оператор это все производители «готового продукта».fishca
21.11.2018 17:10Построить пирамиду и построить жилой многоквартирный дом, кроме специфики применяемых технологий есть отличия?
Это один и тот же объект материального мира. А я сравниваю проектирование реального мира (Буратино) и виртуального (модель Буратино) и если вы не видите различий я не понимаю предмета вашего обсуждения.DrPass
21.11.2018 20:06Расскажите же, в чём отличие. Я в упор не понимаю, чем последовательность работ «составить модель БД», «разработать дизайн UI», «разработать такой-то API», «реализовать такой-то сервис», «разработать тесты» и т.д. в управлении отличается от последовательности работ «провести геодезическую разведку», «вырыть котлован», «вдавить сваи», «залить ростверки», «сварить арматуру нулевого этажа» и т.д.?
Тем, что во втором случае будет меньше правок по обратной связи? Ну так это просто фича, которую нужно иметь в виду, она на саму методику управления не влияет.
Вот такие, которые прочитали книжки, а руками ничего в своей жизни никогда не трогали из ИТ тематики (даже эникеями не работали) как раз и топят на дно ИТ проекты.
Нет, не топят. Есть плохие управленцы, есть хорошие. Плохой утопит, даже если он всю жизнь только в ИТ проработал. Хороший не утопит, даже если ему на компьютере секретарь тексты набирает. Тем более что ПМу навык из молодости обжимать витую пару и ставить винду примерно так же полезен, как навык плести макроме.ILya63
21.11.2018 20:56Согласен, макроме имеет такое же отношение, как и ИТ к ПМ. Очень жаль, что мало кто этого понимает. Эффективными менеджерами уже наелись, теперь очередь специализированных ПМ'ов. Внутри своей компании пусть хоть все по очереди ПМами будут и это иногда даже работает.
DrPass
21.11.2018 21:10Да, давайте ещё доказывать, что ИТ-проекты настолько исключительны и необычны, что ими надо управлять каким-то особенным, доступным лишь избранным, способом. Как будто инженер-архитектор или инженер-электронщик, или инженер, проектирующий лыжи, это люди какого-то иного сорта, который поддаётся традиционному управлению, а разработка софта — ни-ни.
fishca
21.11.2018 21:28В отличие от строительных и производственных проектов у ИТ-проектов нет нормативов затрат для типовых операций, да и сами типовые операции являются таковыми лишь очень укрупнённо и в рамках схожих проектов
DrPass
21.11.2018 21:48В отличие от строительных и производственных проектов у ИТ-проектов нет нормативов затрат для типовых операций
Это миф. Весьма распространённый. В софтверных ИТ-проектах планирование даже легче, чем, например, в строительстве. У нас основную долю затрат составляет всего один ресурс — человеческий. Непрогнозируемая творческая составляющая? Бывает. Иногда. В одном из десяти проектов в лучшем случае. Остальные 90% прекрасно нормируются. Вы разве не можете прикинуть, сколько времени нужно для написания десяти моделей по десять полей? А десяти форм к ним с известными правилами валидации?
Боитесь, что оценка будет неточной? А чего бояться? Это нормально, и это везде. Вы думаете, на стройке будет точная оценка? Да там всё то же самое. Вон, грунт в котловане поплыл, понадобились неучтённые работы по водоотводу и дополнительному укреплению стен котлована. На экскаваторе патрубок гидравлики лопнул — работы по замене, ожидание. Срыв поставок битума. Подорожал цемент. И т.д., этот самый «эджайл» под изменения на лету есть практически в любом проекте в любой индустрии. Мы ничуть не особенные.fishca
21.11.2018 23:47Вы разве не можете прикинуть, сколько времени нужно для написания десяти моделей по десять полей?
Если я не специалист в ИТ (разработке ПО), соответственно не смогу даже близко прикинуть. Также не смогу правильно выбрать технологии которые необходимо применить при разработке.DrPass
22.11.2018 05:02Если я не специалист в ИТ (разработке ПО), соответственно не смогу даже близко прикинуть. Также не смогу правильно выбрать технологии которые необходимо применить при разработке.
А, я понимаю, в чем ваше заблуждение. Вы просто считаете, что это должен уметь делать человек, который управляет проектом. Нет, вы ошибаетесь. Он это делать не должен, и не делает. Ни в разработке ПО, ни на стройке, ни в других сферах. В разработке ПО для него список задач с оценками готовят тимлиды/сеньоры, на стройке — технологи и сметчики.
Руководитель проекта физически не может быть достаточным экспертом в вопросах оценки сроков и стоимости, если проект не совсем крохотный. Поэтому его задача не в том, чтобы все оценить, а в том, чтобы собрать оценки у профильных экспертов. Согласитесь, не нужно быть гуру в ИТ, чтобы у архитектора БД попросить оценить, сколько ему нужно времени для проектирования БД по данному ТЗ?fishca
22.11.2018 08:45Согласитесь, не нужно быть гуру в ИТ, чтобы у архитектора БД попросить оценить, сколько ему нужно времени для проектирования БД по данному ТЗ?
Соглашусь что гуру не нужно быть.
Поэтому его задача не в том, чтобы все оценить, а в том, чтобы собрать оценки у профильных экспертов.
И как предлагается оценивать оценки профильных экспертов, соответствуют ли они истине без знаний в ИТ?uzverkms
22.11.2018 12:19Откройте PMBoK — там всё написано, не надо изобретать велосипед. Стандартные лучшие практики оценки длительности:
1. Экспертная оценка на основе исторической информации.
2. Оценка по аналогам.
3. Параметрическая оценка — на основе исторических данных с поправкой на данные проекта. Если в прошлый раз 25 метров кабеля прокладывали час, то 1000 метров скорее всего можно проложить за 40 часов.
4. Оценка по трём точкам — используется треугольное или бета-распределение по данным пессимистичной, наиболее вероятной и оптимистичной оценки длительности.
5. Групповые методы — мозговой штурм, метод Делфи, метод номинальных групп.
6. Анализ резервов — ко всему вышеперечисленному добавляем резерв. «резерв на возможные потери может выражаться в процентах от оценочной длительности операций, в фиксированном числе рабочих периодов или может быть рассчитан с помощью методов количественного анализа, например имитации методом Монте-Карло».
Или хотя бы вспомним про народную шутку: длительность, названную программистом, надо умножить на 2, так как программист забыл про тестирование. Если при этом программист собрался использовать новую технологию, то длительность надо умножить на 3.
pishet
22.11.2018 08:48Простите, а зачем нам нужен такой пиэм, который даже не может понять смысла слов, которые ему говорят работники и архитекторы. Похоже, Вы пали жертвой MBA :)
fishca
22.11.2018 09:55Простите, а зачем нам нужен такой пиэм, который даже не может понять смысла слов, которые ему говорят работники и архитекторы
В точку!
uzverkms
22.11.2018 11:55Вы видите смысл, которого нет в написанном. PM получает от экспертов список работ и их оценочную продолжительность/стоимость. И для этого достаточно обычного русского языка, конечно желательно с некоторой отраслевой специализацией, но без фанатизма. iSCSI там или FibreChannel, C# или Java — вообще без разницы, это заботы профильных специалистов.
pishet
22.11.2018 13:04Люди не уважают таких пиэмов, хотя, конечно, они иногда управляют, и некоторы иногда успешно, но это всегда конфликт.
uzverkms
22.11.2018 13:38Конфликт будет, если PM без очевидных причин будет диктовать архитектору/инженеру какие технологии применять, потому что «сам лучше знает».
DrPass
22.11.2018 14:31Простите, а зачем нам нужен такой пиэм, который даже не может понять смысла слов
Если он что-то не понимает, он может взять и спросить. Но если он умеет работать с людьми, если он может мотивировать, может организовывать работы, он проект будет двигать. А если он не умеет этого делать, то будь он трижды техническим экспертом, у него ничего не выйдет.
AntonMalanov Автор
21.11.2018 19:59Ага! И респект от команды будет собирать каждый день, как репей на штаны в терновнике
exehoo
21.11.2018 07:54Получит консультацию Архитектора? Который фрагментарно видит свою задачу и не представляет, что «до» и что «после»?
Извините, но чисто терминологически, такой фрагментарно видящий «архитектор» вообще профпригоден?Voltera
21.11.2018 10:49Конечно нет, тоже удивился с такой формулировки, она скорее всего сделана, для того чтобы выставить ПМ в плохом свете, что никто ему бедному не поможет.
Я бы не хотел быть таким РП, который шарит в технологиях, но всего лишь управляет разработкой и внедрением, хотелось бы быть продакт менеджером и рулить всеми аспектами продукта.
ruomserg
21.11.2018 11:09Тут есть тонкая разница между «проектом» и «проектом». Есть проекты, целью которых является нечто имеющее отношение к программированию: новый продукт, новые фичи, пилот новой технологии, и т.д. И руководя этим проектом, ПМ-у будет очень трудно без знания специфики отрасли. Тут нужен «программистский ПМ».
Есть проекты уровнем выше, когда задачи ставятся уже на уровне целого бизнеса. Этот ПМ будет руководить людьми, которые будут руководить людьми, которые будут решать (в том числе) задачи связанные с программированием. Ему уже можно и без особых знаний специфики отрасли жить.
Вообще, многие авторы отмечают, что чем ниже по управленческой лестнице, тем более важны прикладные навыки и особенности отрасли. Чем выше — тем более важно уметь управлять проектами, временем и «ресурсами вообще», и тем больше там управления людьми, чем отраслевых особенностей.
tuneyagodka
21.11.2018 11:29А зачем брать в область ИТ человека, который специализируется на других областях и дока именно в них? Особенно, если мы говорим про частный сектор и госсектор, где все принципиально работает по-другому?
И, честно говоря, если кандидат на должность вашего ПМ не знает ответов на ваши вопросы, он плох не как ПМ в ИТ, а как ПМ в целом. Люди, осилившие книжку и домашний видео-курс по Agile — еще не ПМ…
DrunkBear
21.11.2018 11:30Надеялся, что будет статья «какие вопросы нужно задать PM, когда сидишь на собеседовании» ( чтоб убедиться, что перед тобой PM а не "
деэффективный менеджер" )
А по сути — не уверен, что команда останется под управлением человека, который не знает и не хочет знать о налаженных бизнес-процессах в команде, а хочет всех рассадить как ему удобно ( потому что я так хочу), пойдёт расскажет в отделе кадров и бухгалтерии, что теперь ОН ТУТ ГЛАВНЫЙ ( чем угробит работу по сокращениям сроков приёма и проверки нового сотрудника для отдела с 2-3 месяцев до недели в госконторе) и организует работу по методологии DDD ( Deadline-driven development).
boblenin
21.11.2018 15:22- Во-первых не понятно какой из PM-ов имеется ввиду. Project Manager, Product Manager, Program Manager? У каждого из них свои обязанности и свои задачи.
- Во-вторых если все-таки предположить, что Project Manager, то в рамках, например, того же SCRUM такой роли не существует.
Я не считаю подход с вопрос-ответом, способом отбора хороших кандидатов. Как на технические должности, так и на любые другие. Вопросы-ответы можно заучить и то, что человек ответит на собеседовании может никак быть не связанным с тем, как он будет себя вести в условиях реальной работы. Вопросы о том, что человек делал (Context, Action, Result) желательно перекрестно с коллегой, который(ая) расспросит слегка изменив акценты. При этом надо категорически воздерживаться от условного наклонение.
Если человек злоупотребляет спец. терминами — стоит проверить на знание и понимание оных. Если у человека есть опыт или навык, которого нет в нашей компании или наоборот есть, но требуется еще больше — стоит выяснить как он его получил и применил.
AntonMalanov Автор
21.11.2018 20:06Именно Project Manager. Про SCRUM согласен. Даже хотел сделать сноску, что Scrum не трогать :))) Но Project то Leader есть по-любому ;) И часто так бывает, что он же и ScrumMaster. И не будет он «master-ить», если про «стройку» разрабам будет вещать.
Вопросы-ответы можно заучить, конечно. Но ведь вы при этом в глаза ему смотрите. Фиксируете реакцию. Заученную программу видно. При этом обязательно 6е чувство подскажет копнуть. Тут он и зароется
pishet
21.11.2018 20:06А если (не дай бог) вы ведете проект по Аджайлу — тут и этапы будут другие, и PM будет другой? На мой взгляд — будущего руководителя проекта надо не техническими вопросами тестировать, а смотреть в глаза и оценивать адекватность. Человек с хорошей кармой, и адекватный ситуации — разберется, а что забудет — ему коллеги помогут. Это как в спорте — хорошие рефлексы, или плохие. А рефлексы у PM — это прежде всего хорошие отношения с людьми. Можно протестировать его управляемым конфликтом, сразу будет понятен шаблон поведения. В общем психология тут нужна а не технократия.
AntonMalanov Автор
21.11.2018 20:08Спасибо за комментарий. Посмотрите предыдущие мои ответы. Там про SCRUM написал. Про отношения с людьми 1000% согласен. Но это не hard-skill. А я про харды вещал.
chapter_one
Вы бы хоть почитали, что означает термин «зашквар»…
AntonMalanov Автор
Спасибо! Прочитал :)
chapter_one
Простите, надо было в личку. Теперь после исправления тут будет висеть никому не понятный комментарий.
Я буду слать исправления в личку!