Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: AndriyankovDN от 22 Декабря 2007, 16:13:35
-
День добрый, вопрос уже избитый и задавал его не одному человеку, казалось бы ответ должен уже давно получить, но что-то пока не могу составить список шагов, которые приведут меня к цели "Стать успешным руководителем проектов".
Не много фактов:
- Я не был ни в роли тим-лида, ни уж тем более руководителем проектов
- Я разработчик с использованием Delphi
- У меня нет умения быстро решать поставленные передо мной задачи
- У меня нет умения оценить сколько займет времени решение поставленной передо мной задачи
- Стыдно, но иной раз не могу сказать, почему я долго занимаюсь той или иной задачей
- Нет опыта работы в команде
Какие шаги предпринял:
- Сейчас прохожу испытательный срок, в хорошей организации и в хорошем коллективе, но они умеют быстро решать свои задачи и оценивать их по времени, чего ждут и от меня. Тут ступор
- Открыл проект с исходным кодом, пока пытаюсь описать чего же я хочу и чего в итоге должно получится
- Прочитал Джоэла Спольски "Джоэл о программировании" и начал Фредерика Брукса про миффического человеко-месяца
В чем трудности?
- Как получить опыт руководителя проектов и соответственно стать им? Ведь без опыта меня никто поставит руководителем амбициозного проекта, т.к. это большой риск
- Как научиться тому, что мне не хватает
ЗЫ:
Несмотря на то, что основная цель поста это вопрос "Как стать Project Manager`ом ?", я буду рад любым замечаниям и советам и по другим моим проблемам.
ЗЫ2:
Просьба к тем, кто меня знает лично высказывать свои мысли обо мне тут, т.е. какой я по характеру и как я работаю. Это даст оценку куда более реальную и согласно этой оценке можно будет другим более сведущим, подсказать мне то, что поможет получить мне чего я желаю ;)
-
Коллега!
В начале осени мне посчастливилось участвовать в on-line тренинге , посвященныму Вашей теме.
Могу порекомендовать обратиться по этому адресу: http://www.happy-pm.com/
Возможно, Вы найдете ответ на часть Ваших вопросов.
Тем не менее, чтобы стать руководителем, нужно иметь задатки лидера, обладать определенной харизмой, и , конечно, желать быть таким человеком.
Посмотрите на себя, попробуйте ответить на вопрос: а Вы способны быть лидером?
Ну, а опыт - опыт приходит с опытом :)
To learn to swim swimming
-
Я думаю я бы смог быть лидером, единственное что меня беспокоит, так это моя вспыльчивость. Пример, написал просьбу в МойКруг.ру http://moikrug.ru/topics/428237318/ , казалось бы выложил все, проще не куда и просьба написать возможности и только! Но нет же нашлись ведь люди, которым надо написать "Не делай, это не интересно мне", а я ведь предусмотрел такие ответы и написал еще в самом начале. Вот в таких ситуциях я часто бешусь ( Но знаю это весьма не полезно для руководителя проектов
-
Дмитрий, извините за критику, но для начала все-таки надо научиться грамотно формулировать свои мысли и желания, а также постараться писать грамотно, т.е. по-русски.
То, что Вам не ответили, вероятно, есть следствие составленного описания. Мне кажется, следовало бы описать более детально свой опыт или свое видение этого вопроса, хотя бы подчерпнутого из книг. Волноваться, а тем более беситься из-за того, что Вас не поняли, простите, глупо.
Возможно, публикация своего вопроса в моем круге не сама удачная идея.
Советую обратиться в соответствующие сообщества. По ссылке, которую я Вам дал, можно попытаться присоединиться к сообществу ПМ, где и обсудить данный интригующий Вас вопрос.
Думаю, дискуссию можно поднять и на данном форуме. Суббота не самый удачный день для этого, да еще в канун Нового года. Подождите немного.
-
Давайте начнем с такого вопроса: Какими качествами должен облададать успешный ПМ? Не профессиоанльными, а общечеловеческими.
-
Думаю обо мне хоть какое-то мнение уже составлено, а потому я приму любую критику и любые советы.
2 bas:
Ты предложил, думаю ты должен быть первым. Жду от тебя мыслей. ;)
-
Можно сделать еще проще.
Поставьте задачу попроще -- для начала станьте хорошим разработчиком, а именно -- научитесь декомпозировать задачи и давать пессемистичекскую и оптимистическую оценку сроков выполнения декомпозированных задач. Можете для этого использовать практики Agilе (те эе user stories).
После этого можно двигаться на след. ступень - стать тим-лидоером.
А потом хорошенько подумайте, какую карьеру вы хотите делать -- быть менеджером или архитектором.
-
Добрый день !
К уже сказанным мудрым словам хочется добавить следующие. К сожалению указанной инфомации недостаточно, чтобы понять насколько вы действительно способны стать РП. Соответсвенно предлагаю ответить на два таких вопроса:
1. Почему Вы хотите стать РП , Что Вас привлекает в этой проффессии ? ( Аналогично вопросу Boatman )
2. Какие Ваши личные качества смогут Вам помочь в том что бы стать действительно хорошим РП.
________________
С уважением
Безуглый Дмитрий
-
1. Почему Вы хотите стать РП , Что Вас привлекает в этой проффессии ? ( Аналогично вопросу Boatman )
Мой Ответ:
- Мне нравится наблюдать как развивается программа в целом. Т.е. это не только написане кода, но и как видоизменяется интерфейс с пользователем, как появляются на некоторых местах иконки или изображения, как программа вдруг начинает показывать хинты. Мне приятно видеть, как она становится лучше
- Когда работал на прошлого работадателя, то иногда предлагал идеи по созданию некоторых механизмов и было видно, что часть из них были одобрены моим коллегой и он мне помогал их реализовать.
- Очень хочется предлагать идеи не только в плане развития функциональности, но и идеи связанные с развитием докуементации, т.е. то что мне не понятно или я часто забываю сразу же подсказать людям, что необходимо отразить это что-то в документации. Если мне кажется, что иконка не подходит, очень хотел бы чтобы со мной согласились и поменяли на ту из-за которой я понимаю с разу что эта кнопка на тулбаре делает
2. Какие Ваши личные качества смогут Вам помочь в том что бы стать действительно хорошим РП.
- Мне нравится структурировать, то что лежит или находится не "на своем месте" я стараюсь привести в тот вид, при котором это что-то сразу начинает лежать "на своем месте", по-моему мнению
- Если что-то нехватает, к примеру нет технической документации на тот или иной класс, а у людей нет времени мне пояснить как его использовать, то я растраиваюсь и при первой возможности страюсь создать пусть и плохую, но документацию. Это позволит другому человеку попавшему в подобную ситуацию, что и я пусть хоть на чуточку но побыстрее разобраться с применением класса
зы:
Чуть позже еще дополню, это то что сразу же пришло в голову ;)
-
Внесу свои 5 копеек.
1. По первому Вашему посту мне показалось, что вы не очень разбираетесь в себе, т.е. не очень хорошо владеете собой, не всегда можете проанализировать свои текущие действия, стратегически их выстроить и т.п. (Возможно, все это не так, это просто мои впечатления по первому посту в этой ветке). Такие вещи лежат на более глубоком уровне личности, чем профессиональная деятельность.
2. По посту Ответ №9. Имхо, то, что Вам нравится, может видеть не только МП, но и тестировщик и аналитик (которые находятся на проекте и смотрят на систему в целом, в отличие от программистов, решающих обычно частную задачу). А вносить предложения, которые будут приниматься, обычно может любой уважаемый профессионал. А уважение достигается хорошей работой и ответственным, неформальным отношением к делу. Т.е. для того, что вы хотите, не обязательно становиться МП. НО, если сначала стать вот таким уважаемым профессионалом, потом стать МП точно будет легче :-)
Если мое мнение очень далеко от реальной ситуации, прошу ногами не бить, сами хотели разных мнений :-)
-
Добрый день !
Судя по вашему ответу №9 Вы действительно находитесь в самом начале Вашего профессионального пути.
Описанные вами привлекательные стороны и способности не соответствуют роли РП . РП проекта не должен принимать технических решений, структурировать систему или заниматься ее дизайном. Возможно принятие решний в случае возникновения конфликта( в хорошем и плохом смысле этого слова) в команде, но и эти решения должны основываться на заслуженном авторитете и в конечном счете больше связаны с ограничениями проекта (бюджет сроки и т.д.) или человеческим фактором чем техническими аспектами системы.
На первый взгляд вы стремитесь к роли аналитика , попробуйте посмотреть книгу Дона Леффингуэла "Управление требованиями в ...". Но судя по описанным чертам характера возможно в Вас сильно стремление к доминированию, и роль РП для Вас привлекательна именно властью которая, как иногда кажется есть у этой роли. В этом случае для того чтобы достичь желаемого Вам нужно пройти весь путь от Junior Developer до Team Lead'а желательно в хорошей команде, наблюдая за поведением людей и действиями профессионалов.
p/s/ На 100% согласен со вторым замечанием Irr :-)
-
Спасибо, ваши №10 и 11 действительно содержат зерно истины:
1. Я дейстительно хочу власти
2. Дейстительно люблю доминировать
4. Действительно пока в себе не разобрался, как в специалисте. Почему?
Ответ:
- Я начинал свой путь программиста с языка программирования, с языка Ассемблера tasm(есть такой пакет). После недолгого программирования на этом языке где-то 1-2 года, я осознал, что мне он ничего не принесет :( После этого я начал разрабатывать используя MS Visual С++, но придя на ТЭЦ уведел, что и это нето. Я пришел к Delphi, т.к. он позовлил быстро разрабатывать приложения не задумываясь о многих вещах, а на ТЭЦ это приветствовалось и очень.
В итоге пришел к тому, что перестал быть уверен в своем выборе, а вдруг и этот язык не тот, что нужен? - На протяжении долгих школьных лет мне было трудновато, т.к. я из тех кто не проявляет инициативы в школе из этого вышло, что я не дрался, не хулиганил, не сбегал так часто с уроков, как это делали многие. Все поменялось во мне после того, как я начал работать на ТЭЦ, постоянное : "Когда будет закончено?" или "Почему так долго?" меня просто перевернули с ног на голову.
Как видно тут много сомнений и много личностных переживаний. Мне бы очень хотелось, чтобы умные люди подсказали путь моего развития, как они его видят, а я почитаю, оценю и возможно приму какую-либо точку зрения и советы.
ЗЫ:
Может это не важно, но рукопожатие предпочитаю крепкое.
-
Cчитаю, что лучше быть хорошим специалистом, чем плохим менеджером (на собственном примере).
Хотя, кроме как набивание шишек, ничего не поможет лучше в любом направлении. :)
-
Мне бы очень хотелось, чтобы умные люди подсказали путь моего развития, как они его видят, а я почитаю, оценю и возможно приму какую-либо точку зрения и советы.
Дмитрий, для того, чтобы что-то получить, нужно что-то и отдать. Т.е. обмен должен быть интересен с разных сторон
-
2 Galogen:
Вы(Ты) уверены в том, что такая проблема, как у меня это только у меня? Я вот не уверен и считаю, что надо в этом направлении что-то делать! Почему я должен стесняться и не просить помощь у знающих людей ?
Вы говорите об обмене, но разве подсказывая мне те или иные решения, то вы ничему не научитесь? Отнюдь! Когда-то Антон Григорьев мне сказал: "Пока я пишу статью для других ребят, новичков в деле - я сам учусь". Т.е. подсказывая мне, вы сами можете чему-то научиться или не так?
-
Дмитрий, путь развития выбирает каждый сам.
Для того, чтобы был взаимный интерес в общении, нужна подача с Вашей стороны. А то как-то странно получается: подскажите мне путь развития, а я посмотрю и решу какой лучше - вот я об чем.
Ваш товарищ, в целом прав, но примерьте это к себе, попробуйте сами "написать статью" :)
-
Дмитрий, попробуйте оценить привлекательность для Вас специализации системного аналитика или архитектора систем.
ИМХО:
1. для PM очень важно добиваться выполнения работ разработчиками системы, минимально стесняя их в принятии решении о способах и конкретных вариантах реализации. Конечно рамки сроков и стоимости всегда будут вынуждать вас ставить ограничения на конкретные варианты, но пристрастие к технологическим и архитетктурным аспектам реализации может послужить помехой и даже стать причиной конфликтов с разработчками.
2. существенной частью работы PM являются навыки "разруливания" конфликтных ситуаций с Заказчиком и даже внутри своей команды. Удовлетворение клиента является первоочередной задачей и бывает тяжело соглашаться на не очень технологически совершенные решения, но в силу различных обстоятельств Заказчика иногда приходится на это идти. Поэтому если для Вас совершенство программных решения очень Важно, Вам может оказаться (психологически прежде всего) тяжело искать приемлемые бизнес-решения...
-
Спасибо за ваш ответ №17, очень хорошие мысли!
-
Имхо, для МП еще очень важна хорошая скорость реагирования на изменение ситуации и большая широта обзора (чтоб заметить эти самые изменения ситуации). И если архитектору это не так обязательно - он может властвовать над дизайном, и все-таки время на обдумывание дизайна ему выделяется, то путь МП - это постоянная готовность к изменениям и принятию решений. Готовность быстро решать при недостатке или отсутствии информации и готовность принимать на себя ответственность за принятое решение. Я работала с медленным и нерешительным МП - это смерть проекту.
-
2 Irr:
Супер, согласен. Еще ? ;)
-
:-) вспоминается мультик:
- а вы и есть за меня будете?
- АГА!
-
Итак, у меня получилось так.
Я не знал, чего хочу знать и как мне спросить, но оказалось, что то что я хочу знать это ответ(ы) на вопросы:
1. Какие человеческие качества должны быть у Руководителя проекта?
2. Кто такой руководитель проекта, какие его должностные обязанности в России? (насколько я понимаю ИТ России во многом различна от запада)
Часть ответов я уже получил, это:
На в.1:
- Лидер по натуре
- Отвественный
- Пунктуальность
что еще?
-
хороший ПМ - практически не заметен. Это как здоровье, когда оно исчезает или ухудшается- его замечают, а пока оно хорошее даже не задумываешься.
ПМ - психолог, он должен вызывать у людей уважение. Он должен заботиться о людяй, об удобстве их работы и среды, в которой они работают
ПМ человек, которому приходится делать неприятные вещи. И он должен уметь их делать, не роняя своего и чужого достоинства.
ПМ - это благородный муж (благородная жена :) ) - в смысле, который в него вкладывает Конфуций.
ПМ - должен глубоко понимать жизненный цикл разработки, обладать как стратегическим, так и тактическим мышлением
Пм - должен четко представлять себе цель, уметь держать удар, быть стрессоустойчивым.
Короче ПМ - это папа-мама современных программеров :). Человек, который может делать то, о чем остальные только раздумывают. Об этом как-то высказался Денис "Майевтик". Золотые слова сказал.
-
Галогенчик, ты описал замечательного сферического коня в вакууме! О Боги, пошлите мне в следующем году такое чудо, я хочу хоть раз с таким поработать!
Очень неплохо про МП написано у Де Марко "Deadline.Роман об управлении проектами". Кстати, хорошая книжка для чтения на новогодних каникулах :-)
-
Де Марко придется ставить в планы, после прочтения Фаулера про рефакторинг )
-
Де Марко придется ставить в планы, после прочтения Фаулера про рефакторинг )
Ну и зря. Это художественная книжка как раз по этой теме, читается быстро и легко, а в голове застревает. А над Фаулером надо трудиться.
-
1. Почему Вы хотите стать РП , Что Вас привлекает в этой проффессии ? ( Аналогично вопросу Boatman )
Дима, а если ответ - деньги, ПМ можно элементарно больше зарабатывать, чем програмистом (возмем среднюю оценку). То человек не имеет право пойти в эту профессию? Другой вопрос есть ли у этого человека качества для ПМ и что человеку нужно узнать, чтобы стать ПМ?! И знает ли он чем придется заниматься там и сможет ли (опять же качества).
-
Вставлю и я свои две копейки.
Меня в работе ПМ раньше ничто не привлекало. Вообще. Когда оказалось, что дальнейшее развитие компании невозможно без выделения некоторой руководящей и организующей роли (это я сейчас так красиво выражаюсь, в то время я и слов таких не знал), эту роль возложили на меня. Не освободив при этом от собственно программистской деятельности.
Года два я пребывал в состоянии стресса, отстаивал свою позицию программиста, ругался с директором и серьёзно подумывал о смене работы (не ушёл только потому, что меня вовремя подсадили на крючок кредита на квартиру). Ни навыков, ни знаний, ни даже общего представления о руководстве проектами у меня не было (то есть были, конечно, дилетантско-технарские "представления", о которых смешно сейчас вспоминать). И вот только в последний год, после прочтения увесистой стопки книг, посещения семинаров (исключительно бесплатных ;) ), общения на форумах, среди которых этот занимает сейчас, пожалуй, первое место, я начал, наконец, понимать, что примерно нужно делать - и работать снова стало интересно.
Рецепт прост, хотя, наверное, и не универсален - много читать и пытаться сразу же применять знания на практике. Начать пришлось с литературы по организации тестирования (это и сейчас у нас слабое место), потом по общему обеспечению качества, потом созрел для литературы собственно по управлению проектами, и уже в самом конце ;) - по управлению требованиями и проектированию. Наверное, помог и внезапно проснувшийся интерес к психологии и социологии.
Сейчас я, фактически, начинающий проджект-менеджер, набивший шишек на хождении по граблям и только-только осваивающий основы теории управления программными проектами. Самое главное, что эта работа наконец начала мне нравиться, и из состояния стресса я вышел.
-
Ну и зря.
В данный момент, я читаю Фредерика Брукса, очень тяжело дается, иногда много раз главу перечитывать приходится, но интересно и занятно ;)
Я не давно создал проект по развитию программы с открытым исходным кодом, думаю мне лишним не будет попытки в его развитии, вот ссылка (http://code.google.com/p/ebookcollection/) . Может кому-то будет не лень дать рекомендации ;)
-
Дима, а если ответ - деньги
Ответ деньги - ИМХО это тупиковая ветвь.
В любой профессии чтобы действительно преуспеть нужно иметь искренний интерес к ней.
p/s/ Средний РП получает меньше Хорошего Senior девелопера ...
РП Сейчас много а разработчиков мало :-)
-
Ответ деньги - ИМХО это тупиковая ветвь.
В любой профессии чтобы действительно преуспеть нужно иметь искренний интерес к ней.
p/s/ Средний РП получает меньше Хорошего Senior девелопера ...
РП Сейчас много а разработчиков мало :-)
Подпишусь под каждым словом!!!
-
Что-то вы меня совсем запутали, сегодня на семинар "Lean и роль менеджера в Agile" пойду, может там удастся с кем-нибудь поболтать на эту тематику ;)
-
В данный момент, я читаю Фредерика Брукса, очень тяжело дается, иногда много раз главу перечитывать приходится, но интересно и занятно ;)
Мне кстати книга не очень понравилась. Дочитал больше чем до половину и бросил.
Я не давно создал проект по развитию программы с открытым исходным кодом, думаю мне лишним не будет попытки в его развитии, вот ссылка . Может кому-то будет не лень дать рекомендации Подмигивающий
Добавил туда 3 задачи, кот. мне были бы интересны в данном проекте. Еще рекомендую посмотреть аналоги, чтобы добавить фичи, кот. нет у них.
-
Ответ деньги - ИМХО это тупиковая ветвь.
В любой профессии чтобы действительно преуспеть нужно иметь искренний интерес к ней.
p/s/ Средний РП получает меньше Хорошего Senior девелопера ...
РП Сейчас много а разработчиков мало :-)
Никто не спорит, но:
1. Человеку не нравится программировать, значит он не станет "Хорошего Senior девелопера"
2. Пока не попробуешь, не поймешь. Или скорее даже так: если у человека есть качества, кот. должен обладать хор. МП, то ему это скорее всего понравится.
3. Естественно деньги не главное, но без этого никуда. Если человеку нравится заниматься научной работой, но за это не платят деньги, то ему приходится переквалифицироваться и, н-р, программировать. И кстати видел людей у кот. получилось хорошо переквалифицироваться, не потому что им это было тогда интересно, а п.ч. им надо было кушать, а потом и понравилось :)
-
Был сегодня на семинаре "Lean и роль менеджера в Agile" в Luxoft с 19:00 он был. Так вот, кажется все-таки мне удалось понять то, чего не мог понять раньше читая книги. Да, кажется мне все-таки удалось найти ответ на вопрос: "Кто такой руководитель проекта?". Поэтому хотелось бы выложить, то что понял сюда, а знающие меня проверят и поправят, если в чем-то у меня ошибка ;)
На мой взгляд руководитель проекта - это прежде всего лицо, который заинтерисован в успешном результате. А успехом, по моему скромному и сугубо личному мнению, можно назвать реализацию основного функционала какой-либо услуги из-за которой развивался проект и что не мало важно в срок. Раз лицо крайне заинтерисовано в успехе проекта, то оно и прикладывает максимум усилий для достижения успеха, а это как правило решение в срок и как можно качественней основных задач по функционалу проекта. Логично положить, что задачи эти кто-то должен решить, но если есть цель, достижение которой может занять много человеко-лет, то конечно нужно нанимать специалистов, т.к. нужно решить не за годы, а как можно быстрее, иначе теряется актуальность достижения цели. Всех этих специалистов, необходимо координировать, чтобы меж ними небыло существенных разногласий и чтобы каждый из них действительно трудился над решением возложенных на него задач. Думаю лицо, организовывающее коммуникацию специалистов для решения основных задач командой специалистов и есть руководитель проекта.
Если это так то такому человеку потребуется такие качества:
1. Умение слушать
2. Умение кратко и ясно выражать свою мысль
3. Умение анализировать, насколько действительно хорошо работает тот или иной специалист в команде
4. Умение быть своим для специалистов в команде этого проекта, т.е. в идеале это "свой в доску пацан" и если коллектив пьет по пятницам пиво, ему просто рекомендуетя пойти вместе с командой, т.к. это одно из тех, что сплачивает команду, а он ведь довольно важное звено в команде!
5. Все 4 качества выше подразумевают у него знаний азов психологии при общении прежде всего с человеком, т.к. ему часто придется общаться с глазу на глаз с конкретным человеком.
т.е. прожект-мэн это своего рода мост между целью и командой.
Прошу поправить, если я что-то понял не верно?
-
Мне понравилось определение "мост между целью и командой"
Имхо, в целом верно. Только упускается еще один аспект: а именно общение и ответственность перед спонсором проекта и заказчиком. Т.е. МП еще и слуга царю, а не только отец солдатам. А в верхах прессинг более сильный, чем от команды. Хочется все быстро, мощно и дешево! И дело МП убедить, что это честные сроки и цена. А если он прогнется, то тут и начнутся проблемы для команды: авралы, изменения функционала и т.д.
Категорически рекомендую оставить пока Брукса и взять ДеМарко. Там это в красках расписано.
-
Эх...может это и плохо, но у мну принцип: "Если полезно и нет срочной задачи, то нужно задачу до делать", ну и чисто "За двумя зайцами..." или банально не хочется бегать, то от одной, то к другой книге. Потому пока спешки нет, то дочитаю Брукса, а там и сделаю переоценку плана по прочтению книг ;)
2 Irr:
Какую из книг ДеМарко вы рекомендуете?
-
:-) Вот и проявилось в Вас отсутствие этой гибкости, присущей МП и позволяющей в рантайме менять приоритеты задачам :-) Постоянство и планомерность - прекрасные вещи, но не в быстроменяющемся мире проектов :-)
Брукс - это по-моему произведение про индустрию в целом.
А Де Марко "Deadline. Роман об управлении проектами" - это художественное произведение, основной сюжет которого крутится именно вокруг этой темы - кто такой руководитель проекта, как идет проект, как сделать идеальный проект. И в каждой главе в конце резюме: чему наш герой (МП) научился в этой главе.
Ложка-то хороша к обеду. Чем планомерно давиться Бруксом и параллельно читать/вести эту дискуссию, проще прерваться на неделю, которая уйдет на Де Марко, поймать озарение, и потом со свежими силами и новым пониманием вернуться к Бруксу.
Кстати, это дает нам еще одну характеристику хорошего МП - он всегда помнит о цели и границах проекта. Какая цель у Вас при чтении Брукса? Как эта цель соотносится с ведением этой дискуссии (а большая часть ответов, что здесь, лежит прекрасно сформулированная в книжке Де Марко)? А что важнее: достижение цели или принцип?
-
Ну Ира, ты ща запоешь :)
В принципе во всем согласен, только хотелось добавить что к команде надо относится как к самому себе, как будто команда - это живой организм и этот живой организм это ты, но этот организм надо еще сделать. Отсюда и вытекают все практики Агиле:
- цель
- сплоченность
- отвственность за результат
- и т.д.
З.Ы. ДеМарко рулит однозначно, прочел его один махом. Все что нам говорит Агиле, все (ну или почти все) у него есть. Последний раз читал так книгу "Код да Винчи". Вот как надо писать тех книжки.
-
А у кого есть книга в электронном виде?
-
А у кого есть книга в электронном виде?
Эд, ты не поверишь - у Гугла.
-
Эд, ты не поверишь - у Гугла.
Язва :P
-
День добрый, вопрос уже избитый и задавал его не одному человеку, казалось бы ответ должен уже давно получить, но что-то пока не могу составить список шагов, которые приведут меня к цели "Стать успешным руководителем проектов".
Не много фактов:
- Я не был ни в роли тим-лида, ни уж тем более руководителем проектов
- Я разработчик с использованием Delphi
- У меня нет умения быстро решать поставленные передо мной задачи
- У меня нет умения оценить сколько займет времени решение поставленной передо мной задачи
- Стыдно, но иной раз не могу сказать, почему я долго занимаюсь той или иной задачей
- Нет опыта работы в команде
Какие шаги предпринял:
- Сейчас прохожу испытательный срок, в хорошей организации и в хорошем коллективе, но они умеют быстро решать свои задачи и оценивать их по времени, чего ждут и от меня. Тут ступор
- Открыл проект с исходным кодом, пока пытаюсь описать чего же я хочу и чего в итоге должно получится
- Прочитал Джоэла Спольски "Джоэл о программировании" и начал Фредерика Брукса про миффического человеко-месяца
В чем трудности?
- Как получить опыт руководителя проектов и соответственно стать им? Ведь без опыта меня никто поставит руководителем амбициозного проекта, т.к. это большой риск
- Как научиться тому, что мне не хватает
ЗЫ:
Несмотря на то, что основная цель поста это вопрос "Как стать Project Manager`ом ?", я буду рад любым замечаниям и советам и по другим моим проблемам.
А может быть Вам нужно стать начальником отдела программистов? или замом. Для этого ничего менять не надо, работайте просто усердно и долго в одной фирме.
Просто в компаниях не все так легко, аналитики обычно в одном отделе, программеры в другом, ПМ в третьем. И спокойное перемещение между отделами возможно порой только в Японии...
Анализируя Вашу ситуацию даю совет не морочить себе голову, работать усердно пограммистом и становиться их начальником.
А менеджеры проектов, это порой люди,вообще далекие от ИТ. К тому же они не уважаемы теми же программистами, и платят им меньше чем хорошему программисту...
-
А менеджеры проектов, это порой люди,вообще далекие от ИТ. К тому же они не уважаемы теми же программистами, и платят им меньше чем хорошему программисту...
И вообще они так же вредны как и аналитики :)
-
Вот никто не написал, что чтобы научиться управлять, нужно сначала научиться подчиняться, а именно:
- выяснять, уточнять, разбивать, оценивать и выполнять собственные задачи;
- обсуждать свои задачи, отстаивать своё мнение, ОТКАЗЫВАТЬСЯ от задач, если они представляются невыполнимыми;
- понимать, от результатов каких задач других участников команды они зависят - и чьи задачи зависят от ваших результатов;
- "показывать лицом" результаты своей работы;
- передавать свои задачи, контролировать их выполнение, работать с "новичками";
- выстраивать отношения с другими участниками команды, не выходить из себя, использовать аргументы вместо чёрной риторики (повышенных тонов, перехода на личности, лишения собеседника возможности вставить слово и т.д.).
Но всему этому учиться просто ДОЛГО, а деньги хочется получать прямо сейчас (кстати, ни разу не видел ситуации, когда подчинённый, будь он хоть трижды ведущий разработчик, получал бы больше своего ПМа). Вот и получается, что ПМов много, а работать некому :) .
-
Начал читать Тома ДеМарко "Deadline. Роман об управлении проектами", чтото чересчур все мягко в начали идет, все этому Топкинсу предоставлено и толпа первоклассных программеров и условия и все, даже интересно,как автор дальше повернет ?! ;))
-
А дальше будут повороты, как раз такие, как бывают в обычном проекте.
-
Могу личными впечатлениями поделиться. Есть такая книга: Скотт Беркун, "Искусство управления IT проектами". Автор работал в Microsoft, в частности, над проектом Internet Explorer в эпоху "войны браузеров".
Первый раз прочитал эту книгу года полтора назад, когда меня только "перебросили" с программирования на управление проектами. Прошло мимо мозга - ничего в памяти не осталось. Часто ловил себя на мысли: прочитал главу, а о чём она - не помню. Я, как теперь понимаю, ожидал найти там описание конкретных методик, планов действий по пунктам - делай раз, делай два и т. п. А автор вместо этого растекается мыслями, о методиках говорит уклончиво, даёт какие-то расплывчатые советы типа "можно делать так, а можно и этак, это зависит от масштабов проекта и организации".
Сейчас, поднабравшись уже некоторого опыта, начал эту книгу перечитывать. И ловлю себя на другой мысли: после прочтения каждого абзаца нужно останавливаться. Потому что возникает сразу множество ассоциаций с тем, чем приходится заниматься на работе, мысль уходит в сторону, и следующий абзац прочитывается уже "на автомате", одними глазами.
Всё-таки опыт, даже небольшой, не идёт ни в какое сравнение с голой теорией. Я конечно, далеко не первый (и даже, наверное, далеко не в первом миллиарде) открываю для себя эту банальную мысль, что, собственно, её же лишний раз и подтверждает. :)
-
Всё-таки опыт, даже небольшой, не идёт ни в какое сравнение с голой теорией.
Не могу согласиться с этим утверждением.
Понимаете теория или она есть, или ее нет. Или она ошибочна либо истинна. Истинность теории постигается в эксперименте, в том самом опыте. Однако и опыт должен быть поставлен в рамках изучаемой теории. Однако мы часто ставим опыт вообще, не зная никаких теорий, либо как это часто действую по "интуиции". И если опыт негативный хаем теорию.
Классическая теория Ньютона например не ошибочная, просто она истинна в определенных допущениях.
-
Эд, в отношении управления людьми greesha совершенно прав. Что толку знать, как надо поступать, чтобы тебя слушали, доверяли, если ты не умеешь это делать? Я вот себе очень хорошо представляю, что такое лидер и руководитель, но таковые навыки у меня автоматически не появляются. Причём вживую такие вещи осваиваются гораздо лучше, т.к. управление людьми - это управление сложной системой, и как действовать и реагировать в той или иной из множества ситуаций можно понять (точнее, почувствовать) только за счёт интуитивной интерполяции своего жизненного опыта, в книгах все ситуации рассмотреть невозможно.
-
Не могу согласиться с этим утверждением.
Понимаете теория или она есть, или ее нет. Или она ошибочна либо истинна. Истинность теории постигается в эксперименте, в том самом опыте. Однако и опыт должен быть поставлен в рамках изучаемой теории. Однако мы часто ставим опыт вообще, не зная никаких теорий, либо как это часто действую по "интуиции". И если опыт негативный хаем теорию.
А кто хает? Я и на форум-то этот забрёл в поиске теоретических знаний. Потому что почувствовал их необходимость.
Но, во-первых, любая применимая на практике теория - это всё-таки обобщение накопленного опыта. ;)
Во-вторых, теория управления проектами - это никак не точная наука, а скорее, общественная. Можно по-разному классифицировать методики, подходы и инструменты, но дальше классификации дело всё равно не пойдёт. Пока главной движущей сила проекта являются люди, никакой мат. аппарат на эту теорию не натянешь.
-
Ребята, прошу прощение за слово "хаем". Вовсе не хотел никого обидеть. Совершенно не сомневаюсь в вашей компетенции и умениях.
Просто понятие теория наверное не совсем применима в данном случае, либо как заметил Денис, есть вопрос овладения этой самой теорией. К тому же врядли теорию человеческих отношений можно измерить математической гармонией. Потому наверное следует говорить об искусстве, а не теории :)
-
я когда-то очень сильно хотела быть руководителем проекта, представилась возможность на проекте иметь в подчинении несколько аналитиков (с ними все прошло на ура - они были мои друзья), а вот с тестировщиками не так.. Возник конфликт, когда я прочитала, что эти тестировщики обо мне пишут в личной переписке (типа Анна вообще себя возомнила бизнес вумен), и я поняла, что как ни старайся, тебя будут за спиной очернять, возможно только потому, что ты начальник над ними. А мне этого не хочется... Тут либо команду из "своих" людей набирай, которые понимают, что ты их не обидишь, а даже поможешь когда надо, либо не знаю что..
-
я поняла, что как ни старайся, тебя будут за спиной очернять, возможно только потому, что ты начальник над ними. А мне этого не хочется... Тут либо команду из "своих" людей набирай, которые понимают, что ты их не обидишь, а даже поможешь когда надо, либо не знаю что..
Вставлю свои злобные 5 рублей:
1. У каждого человека свой характер и мотивы, всем мил не будешь в любом случае.
2. Личная переписка и слухи несут субъективную информацию, использовать которую - достаточно рисково (уж не говоря об этической стороне дела).
3. Первые пару лет начиная быть начальником - гарантированно наделаешь ошибок, возомнишь себя кем-то (или так будет казаться со стороны и т.д.), будешь попадать в конфликты и т.д., из этих ошибок, стрессов и обид и появится тот опыт, про который говорит Greesha. Хотеть быть МП и уметь быть МП - это сильно разные вещи.
4. Аналитики тебя сразу уважали как минимум за твои квалификационные навыки, ты же тоже аналитик. А если у тебя такие навыки в тестировании? Вещи-то сильно разные. Поэтому тут уважение придется зарабатывать.
Отсюда выводы:
1. либо учиться управлять людьми, и уже не зависеть от того, свои они или чужие, либо пытаться собирать только таких, с которыми тебе удобно (но тут вполне может пострадать КПД вашей работы), или забить и не пытаться быть начальником - "их же никто не любит!"
2. Эмоции эмоциями, а работа работой. Если не можешь на работе без сильных эмоций, лучше не становись начальником, ибо от этого будет хуже и тебе, и подчиненным.
-
4. Аналитики тебя сразу уважали как минимум за твои квалификационные навыки, ты же тоже аналитик. А если у тебя такие навыки в тестировании? Вещи-то сильно разные. Поэтому тут уважение придется зарабатывать.
2. Эмоции эмоциями, а работа работой. Если не можешь на работе без сильных эмоций, лучше не становись начальником, ибо от этого будет хуже и тебе, и подчиненным.
Нет, тестеры обычные были - ручное тестирование, фактически новички.
Квалификация тут не при чем. Есть люди не с правильной моралью, которым по фигу до других, которым надо повыделываться... не учитывая при этом, что может оскорбить другого человека своим поведением / словами. Нет желания работать с такими людьми, но в фирмах их иногда берут на должности.
ПМ - это не начальник, это всего лишь менеджер ПРОЕКТА - не их отдела менеджер, а всего лишь проекта. То есть, он не знает, кто ему попадется из аналитиков, тестеров, кодеров на проект. ФАктически, он должен только следить за сроками и мотивировать команду.
Эмоции тут тоже не причем. Прежде всего надо быть людьми и вести себя по -человечески.
Не в начальниках дело. Менеджером проекта фактически бывает любой аналитик, который один работает на проекте - сам общается с бизнес-пользователями, при этом он не начальник, а аналитик - по совместительству менеджер проекта.
-
No comments
-
Irr, если нет комментариев, то просто не отвечаешь в тему :) Или ты хотела выразить своё негативное отношение к теме?
-
+ 1 за No comments
тут лучше лично разговаривать, в онлайне с такими поведенческими установками трудно разбираться
-
Сегодня на башорге шутка в тему :)
Родилась замечательная идея по отбору сотрудников в ИТ-компанию: нужно взять сложную головоломку, собрать ее наполовину и предлагать кандидатам собрать ее до конца. В зависимости от результата:
- кандидат собрал головоломку правильно и до конца - специалист идет в отдел разработки;
- кандидат сломал головоломку в процессе сборки - специалист идет в отдел тестирования;
- кандидат разобрал головоломку до нуля - специалист идет в отдел анализа;
- кандидат сказал, что наполовину собранная головоломка и так выглядит неплохо - специалист идет в отдел внедрения;
- кандидат не заметил просьбы собрать головоломку - метит в менеджеры проекта.
-
Читаю в DeadLine by Том ДеМарко место где идет разговор главного героя с Абдулой о создании моделей интутивного мышления и не вкуриваю, действительно ли кто-нибудь когда-нибудь пытался вытащить на свет божий свою интуицию ?
-
Хм, если вопрос в общем смысле, то таких людей по-моему много. Принятие решений при дефиците времени обычно так и производится.
-
<...>
Странный пост. Вообще-то ПМ - человек по определению жёсткий. Он заставляет работать, принимает неприятные прагматичные решения, "наступая на песню" турбулентного потока сознания аналитиков, технологических изысканий программистов, ленивой сказки про "ничего не работает" тестировщиков. В тяжёлых случаях - ставит на место. Это может показаться безразличием или оскорблением. Зачем по этому поводу переживать?
-
Думаю хороший руководитель проектов - это профессионал в своей области и "хороший политик" в одном лице. Причем больший акцент делаю на втором пункте.
-
Думаю хороший руководитель проектов - это профессионал в своей области
Эх, мои наблюдения не всегда это подтверждают. Как стать:
Путь 1, видел 4 раза:
1) Работать в любой области, или совсем не работать
2) Быть другом или родственником руководителя департамента R&D
Путь 2, видел 2 раза:
1) Быть весьма посредственным программистом
2) Много и громко говорить общие вещи, спихивать свои невыполненные задачи на других
3) Уметь закадычно общаться с начальством, говорить начальником только "да", "вы правы", "великолепное решение", далее GOTO Путь 1
Путь 3, видел 1 раз (проект - консалтинговый)
1) Уметь много, но не очень красиво и убедительно говорить общие слова, опыта не иметь
2) Быть первым, кого увидел ген. директор при разговоре о том, что проекту быть
и "хороший политик" в одном лице.
Причем больший акцент делаю на втором пункте.
Тоже не всегда.
Путь 4, видел 1 раз
1) Быть классным, опытным, вдумчивым программистом, порой говорить начальству "нет", и даже "вы некомпетентны"
2) Дождаться, пока действующий менеджер проекта уйдёт
3) Проект должен "гореть", так, чтобы руководитель R&D понимал: если всунуть "своего" незнайку, проект провалится, и уволят и его, и незнайку
4) Понять, что эта возня с хождениями "на ковёр", бумажками и подгонкой планов не по душе, и отвергнуть предложение стать PMом