Pull to refresh

Comments 35

Отличная статья! Сам — тоже постоянно задаю такие вопросы на собеседованиях.
Рекомендую эти же вопросы задавать рядовым инженерам — ответы очень хорошо могут показать «зрелость» кандитата.
Обычно нет четких критериев ни провала, ни успеха, и тот и другой определяются «на глазок» вышестоящим руководством, при этом сильно завися от положения дел в компании, настроения, погоды и прочих, казалось бы не относящихся к делу факторов.

Как бы то ни было, но это:
В компании нет ресурсов. Менеджеру говорят: вот тебе 3000 рублей, запусти рекламу в Директе, проведи смс-рассылку, а если останутся деньги, закажи ещё баннер (пример реальный).
а) не имеет отношения к управлению проектами;
б) исключительно самодурство начальства, если кто-то согласился на такое, то, извините, ССЗБ.
Уж не знаю к сожалению или к счастью, но управление проектами при ограниченных ресурсах все же остаётся управлением проектами. Но работать в таких условиях или нет, согласен, — выбор менеджера.
Безусловно, при ограниченных ресурсах проект остается проектом, я имел ввиду, что то определение поставленной перед менеджером задачи, которое вы дали, не является проектом.
В любом проекте обычно есть треугольник — Ресурсы-Качество-Время. И при старте проекта выбираются обычно два угла такого треугольника. Бывает что и один. И это должно быть четко обозначено при старте. Проект с ограниченным ресурсом — самая распространенная ситуация.
Обычно нет четких критериев ни провала, ни успеха
Вот с этим категорически не согласен. Да бывают проекты которые как оказывается никому особо не нужны. Но успех настоящего коммерческого проекта — это прибыль. Просто и ясно.

Все так, прибыль, как таковая, безусловно, успех.
Но «на глазок» обычно определяется насколько успешно или не успешно был этот успех достигнут.
По-хорошему при старте проекта определяются SMART-цели. По завершению сравнивается достигнутых результат с этими целями. Сравнивается расчетное время, ресурсы и качество. Правда это в теории, на практике это делается редко.
За одного битого двух небитых дают…
В нормальных компаниях это понимают, человек который в том числе заваливал проект знает как проекты валятся, а это ценно.
Это точно.
Читал как-то байку про то как один из менеджеров Рокфеллера провалил проект несколько миллионов долларов, гигантской суммы по тем временам.
И менеджер приходит увольняться, на что Рокфеллер говорит:
«Я не принимаю вашей отставки. Мы и так уже потратили несколько миллионов на ваше обучение. Вы у нас самый дорогой сотрудник, поэтому идите и работайте дальше.»

Правда не так уж часто руководство поступает так великодушно.
Скорее отправляет на рынок труда с волчьим билетом.
отправляет на рынок труда с волчьим билетом
Ну это врят ли, обычно пишут ПСЖ и всё. Уволить по несоответствию должности довольно сложно и геморойно для компании. Другое дело, что на новом месте могут позвонить предыдущему работодателю.
Запросто могут талантливого, опытного менеджера проекта подставить его коллеги и непосредственное руководство — как только запахнет жаренным. И сразу видно, что у людей за нутро — кто перевязывает раны, а кто выталкивает коллегу из окопа под пули, закрывая собственную задницу каской. Тут важно сделать выводы, объяснить для себя поведение коллег как проявление слабости — и не бояться описать выводы достойно на собеседовании.
Полностью согласен.
Не единожды побывав в таких ситуациях, могу сказать, что это, при должной рефлексии, неимоверно прокачивает профессиональные навыки.
Я разок взялся на одной из прошлых работ за заведомо провальный проект — ну было обидно за компанию, хотелось сделать все, чтобы вытащить коллег из болота, причем знал как и был серезный опыт марш-бросков в пустыне ночью зимой. В ходе разбора тонн говнокода и фактов отсутствия головного мозга у окружающих — поднялся такой смрад, что меня сделали ответственным за вскрывшуюся правду и начали прессовать :-) Естественно пришлось послать на… — проект в полускрытом состоянии до сих пор. И где тут ориентация компаний на результат? :-)
Видимо там был инициирован еще один проект, основной целью которого было скрыть провал. И, судя по комментарию, этот проект оказался успешным. Вот такая вот ориентация на результат.
Мне кажется всегда надо найти силы, чтобы сказать заказчику о том, что проект поехал «не туда», его надо закрыть, и начать новый.
Многие бояться этого и всеми силами пытаются закончить провальный проект.
Хорошая статья, правда наверно не полная. Есть ещё некоторые пункты, которые тоже могли бы показать кандидата с хорошей стороны.
1. Как проходил уход из проектов.
Был ли уход с обрубанием всех связей и контактов? Или кандидат поддерживает общение. Даже если кандидата подставило руководство, или вынудило уйти. Он может поддерживать хорошие отношения с сотрудниками. Следовательно знает как проект развивается без него, но по его «заготовкам». Может в будущем оценивать, как решения из его прошлого опыта, будут развиваться.

2. Поддерживает ли кандидат прошлый проект, с которого только что ушёл (если прошлое место работы было недавно).
Тоже не мало важную роль играет. Есть по сути два типа людей. Одни уволившись, игнорируют любые вопросы помощи, старого проекта, по тем вопросам где человек хорошо разбирался. Пока коллектив, не заткнёт все бреши, появившиеся с его уходом.
Второй тип, какое-то время помогает с решением возникающих проблем, на которые кандидат мог бы указать направление к быстрому их решению.
Потому что может быть так, что человек уйдёт от вас, а вам самим может понадобиться срочная помощь от человека. Не важно, подсказка на то чем поливать любимый фикус босса или на каком сервере хранятся бэкапы.
Иногда описанное поведение в пункте 2 вынужденное.

У меня был пример когда я отвечал за автоматизированную систему учета средств, и через 3 месяца должны были произойти изменения, в связи с которыми необходимо было менять систему расчетов, на что начальство говорило — это все фигня изменений не будет. Хотя я точно знал что будет слушать меня не желали и не хотели. Соответственно в приоритет ставили задачи из разряда красиво разрисовать отчеты. За полтора месяца собрал вещи и ушел, так как не хотелось потом отвечать зарплатой и прочим за недальновидность начальства.
Полтора месяца меня не трогали. А потом в силу «ВНЕЗАПНО» вступили изменения и вся система расчетов рухнула. 3 или 4 месяца компания была не в состоянии выставить счета клиентам. Мне звонили просили переделать систему расчетов — я отказался. Так как в момент когда я 2 месяца ходил и говорил что мне следует заниматься другими задачами, они хором кричали что я просто выдумываю себе работу, и вообще не хочу делать красивые и няшные отчеты что конечно намного важнее.
Был аналогичный случай. До сдачи проекта, альфа версии, оставалось два месяца, с запасом три. Давно утверждённые сроки сдачи этапов работы. Начальство в мечтах «быстрее выпустим продукт и будет много денег». Заставило сократить сроки до месяца. Вернее они хотели ещё быстрее, но я сказал, что месяц край. В итоге неделя не прошла, захотели запускать «прям сейчас». Как не отговаривал, не слушали. Ну ок, запустили сырость. Под начальственным заверением, что пока в массы оно не пойдёт (сайт-сервис), а его будут обживать контенщики и СЕОшники.
Естественно все плановые задачи были отброшены, так как личные тесты на продакшене, помогли заметить большую багу в логике. Фикс бы занял несколько дней. Но начальству уже было фиолетово на кодинг. Им срочно нужно было улучшать «дизайн», двигая элементы туда-сюда, по нескольку раз на дню, создавать «красивые» рекламные страницы. И «вообще мы уже рекламу запустили на ТВ, наружку и в инете». Весь отдел бросили не на то чтобы был сервис рабочий, а на то чтобы красивость наводить и клепать по 10 раз рекламную страницу… При этом в течении дня, было в порядке вещей поставить задачу с грифом «всё бросай, это срочно». Потом, через час подойти, отменить её и дать новую задачу с таким же посылом. И так несколько раз, а потом, через пару дней вспомнить что были задачи, правда забыть что их отменяли, и потребовать отчёт о их завершённости. Это вот уже и было финальной точкой к уходу.
:-)
При этом в течении дня, было в порядке вещей поставить задачу с грифом «всё бросай, это срочно». Потом, через час подойти, отменить её и дать новую задачу с таким же посылом. И так несколько раз, а потом, через пару дней вспомнить что были задачи, правда забыть что их отменяли, и потребовать отчёт о их завершённости. Это вот уже и было финальной точкой к уходу.
:-)
В таких случаях незаменимы системы управления задачами. Или даже простейший бумажный документооборот. Всегда можно сунуть начальству документ — вот вы сами отменили эту задачу, подвинули эту и вставили вот эту. И собственный зад прикрыт, и начальство начинает лучше понимать ситуацию.
ага в телекомах распространена «нарядная» система бумажного документооборота. Она работает если есть длинноногая делопроизводительница на ресепшене, которая следит за прохождением и выполнением нарядов. Как только бумажки начинают жить своей жизнью — все ломается. И заставить начальство на наряде завизировать — «перенести на чуть попозже» задача мягко говоря не тривиальная =)

хотя системы управления задачами конечно нужны
Статья именно про негативный опыт в проектах, который может оказаться не таким уж и негативным на новом месте. Ваши пункты конечно характеризуют человека, но они больше про ответственность и конфликтность, кстати тоже хорошая тема для статьи.
Я уверен, эти вопросы так же хороши и на собеседовании с разработчиками.
А много узнаете о разработчиках по ответам на такие вопросы?
Анализ ошибок, может быть плохим или хорошим. Делать правильные выводы тоже нужно уметь
Я думаю, постскриптум можно убрать. Я бы и без него плюсанул :-)
Правильная статья, что сказать =) Но мне в основном встречались «правильные» работодатели (ну, или те, кто умел задавать «правильные» вопросы =) )
Самое ценное, из ответов на эти вопросы можно выудить насколько человек ответственный. Если на вопрос о собственных ошибках он расскажет историю где все виноваты кроме него самого — это очень плохой звоночек. РП это та должность, где платят за ответственность. Ответственность за проект в целом. Большую часть внутренних рисков хороший РП должен предусмотреть или хотя бы честно признаться, что прохлопал.
Опыт провальных проектов — это самый дорогой опыт.
Фигня это все. Более-менее умный кандидат будет готов к таким вопросам и расскажет скорректированный вариант истории, в котором он замажет свои личные косяки. Либо сделает это на ходу, тут много ума не надо.

Поэтому нужно давать тестовое задание, которое человек будет писать прямо у вас на глазах. И не читать резюме про «успешно выполненные проекты» — потому что человек всегда заранее замажет все темные пятна и проект в резюме будет описан очень круто. Сначала нужно понять чего стоит человек, и только когда будет видно, что он честен — тогда можно смотреть на то, что он написал в резюме.
Хороший менеджер продукта — это хороший бизнесмен

Совсем не обязательное условие.

А в остальном хорошая статья, спасибо.
Интересно, станет ли когда-нибудь соискателем Марк Цукерберг (и если да, то будут ли у него на собеседовании подобные вопросы (и если да, то какие он сможет предоставить ответы).

Спасибо за тему, это актуально в начале одного из моих проектов и мысли на этот счёт как нельзя вовремя активизировались, благодаря именно этой теме.
Он дает много интервью, думаю, бывали и подобные вопросы, а значит, можно найти и ответы )
Рад, что статья оказалась полезной, спасибо за отзыв.
Only those users with full accounts are able to leave comments. Log in, please.