Здравствуйте, Геннадий Васильев, Вы писали:

А>>>>Руководство проектами — это все же не совсем инженерная дисциплина.
ГВ>>>Ясное дело, поскольку это часть работы инженера.
А>>Там, где это так, там большие проблемы, либо мы понимаем под "управлением проектами" совсем разные вещи.

ГВ>Скорее мы под "инженером" понимаем совсем разные вещи.

Прочитал ветку. Вопреки своим правилам, перейду на личности.

Ты, Геннадий, все-таки, чрезвычайно строг . Но, при этом, — не побоюсь этого слова, — справедлив .

Интересно было бы с тобой поработать в каком-нибудь проекте.

Вот .

Здравствуйте, Аноним, Вы писали:

А>>>Руководство проектами — это все же не совсем инженерная дисциплина.
ГВ>>Ясное дело, поскольку это часть работы инженера.
А>Там, где это так, там большие проблемы, либо мы понимаем под "управлением проектами" совсем разные вещи.

Скорее мы под "инженером" понимаем совсем разные вещи.

Здравствуйте, Аноним, Вы писали:

ГВ>>Чаще всего, потому что никто не требует.
А>Еще чаще просто не понимают необходимости и делают как могут.

Что значит "не понимают необходимости"? Необходимость формулируется руководством. Неужели оно думает, что всё само по себе появится.

ГВ>>Это как раз можно решить даже технически. Начинаем с хранения документов в SVN...

А>Тулы не решают проблемы.
А>SVN — это хорошо, но далее возникают вопросы а о каких версиях оповещать (ну не оповещать же о каждом нестабильном чихе)
А>и возможно возникает понимание что не все физические версии являются стабильными
А>и прочее классические банальные проблемы CM.

Согласен, но как минимум, таким образом обеспечивается мониторинг текущего состояния. Конечно, хорошо, если есть ещё список рассылки по документу. Ещё лучше, если автор документа не ленится отправлять письма.

ГВ>>А потребовать, дать образцы, время на соответствующую работу не пробовали? Нередко помогает.
А>Естественно.
А>Только вот на осознание этого нужно время и семинары с банальными вещами тоже помогают осознать проблемы.

На осознание чего? На осознание банальностей? На осознание того простого факта, что лучше заранее записать ответ на вопрос, который непременно будет задан? Эдак мы докатимся до того, что печальный факт того, что булки не растут на деревьях тоже придётся "осознавать" на семинарах.

А>А вообще ты зря "экс CCCР".
А>Сложных распределенных проектов в то время по пальцам можно было пересчитать.
А>Проблем и там было выше крыши.
А>Нужда в грамотных управленцах сейчас гораздо выше
А>и проблемы с проектами существуют во всем мире.

Нет, не зря я про СССР вспомнил. Инженерная культура прививалась всё же получше, чем сейчас. Да и огромных распределённых проектов было выше крыши, только до руководства ими добирались не "молодые амбициозные", которые сначала становятся менеджерами в награду за послушание, а потом узнают, что электричество берётся не из розетки (подлость-то какая!), а вовсе другого класса специалисты.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Феерично, честно говоря. Запасаюсь попкорном, жду, когда на таких семинарах будут восторгаться откровению: "2x2=4".

Постоянно убеждаюсь, что самые банальные вещи, о которых типа все знают, частенько игнорируются.
Если вдуматься, то почти все разумные вещи, которые касаются управления проектами, — банальщина и здравый смысл.
Но проблем тем не менее более чем достаточно...

Здравствуйте, Аноним, Вы писали:

ГВ>>Нет, не зря я про СССР вспомнил. Инженерная культура прививалась всё же получше, чем сейчас. Да и огромных распределённых проектов было выше крыши, только до руководства ими добирались не "молодые амбициозные", которые сначала становятся менеджерами в награду за послушание, а потом узнают, что электричество берётся не из розетки (подлость-то какая!), а вовсе другого класса специалисты.

А>Руководство проектами — это все же не совсем инженерная дисциплина.

Ясное дело, поскольку это часть работы инженера.

Нашел интересное видео по управлению распределенными командами http://www.peoplemind.ru/?page=video&ouid=334019, да надо бы подчитать что-нить еще по этой теме, есть у кого мысли на этот счет?

лектор — какой то сопливый мальчик, который думает, что он что то умеет.

слабовато

слабовато

Здравствуйте, Dzintars, Вы писали:

D>Нашел интересное видео по управлению распределенными командами http://www.peoplemind.ru/?page=video&ouid=334019,

Феерично, честно говоря. Запасаюсь попкорном, жду, когда на таких семинарах будут восторгаться откровению: "2x2=4". Нет, я, конечно, в курсе, что СССР давно развалился, нормальное инженерное образование — это, скорее, досадная случайность, но чтобы так... Например, обсуждение необходимости документа-overview процессов — просто восхитительно. Вообще, меня иной раз в ступор вгоняет лихость, с которой продаются пребанальнейшие вещи под видом глубоких знаний.

D>да надо бы подчитать что-нить еще по этой теме, есть у кого мысли на этот счет?

Читай-не читай, всё сведётся к двум основным проблемам:

— поддержание лояльности команды (удалёнщики очень легко разбегаются);
— куче необходимых бумаг, которые "в офисе" заменяются разговорами.

Здравствуйте, Аноним, Вы писали:

ГВ>>Феерично, честно говоря. Запасаюсь попкорном, жду, когда на таких семинарах будут восторгаться откровению: "2x2=4".

А>Постоянно убеждаюсь, что самые банальные вещи, о которых типа все знают, частенько игнорируются.
А>Если вдуматься, то почти все разумные вещи, которые касаются управления проектами, — банальщина и здравый смысл.

Странное дело — почему ими нельзя пользоваться? Риторический вопрос, не правда ли.

А>Но проблем тем не менее более чем достаточно...

Дык, вот этот самый семинар как раз показывает, что банальному здравому смыслу почему-то места не находится.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Странное дело — почему ими нельзя пользоваться? Риторический вопрос, не правда ли.

Не нельзя, а не пользуются.
Почему — это другой вопрос и совсем не риторический.

Бог с ним с семинаром...
Но вот к примеру совсем банальнейшая вещь, что после внесения изменений в документ (или любой другой артефакт),
об этом изменении надо сообщить тем, кто в этом документе заинтересован.
Ну что может быть понятнее и проще?
Дак ведь нет...
Куча проектов где рады вообще, что есть док, а вести revision history и
вовремя оповещать всех заинтересованных — это недостижимый "рокет саенс"
И так почти со всей "мелочевкой", которая и определяет культуру ведения проектов.

Здравствуйте, Аноним, Вы писали:

ГВ>>Странное дело — почему ими нельзя пользоваться? Риторический вопрос, не правда ли.
А>Не нельзя, а не пользуются.
А>Почему — это другой вопрос и совсем не риторический.

Чаще всего, потому что никто не требует.

А>Бог с ним с семинаром...
А>Но вот к примеру совсем банальнейшая вещь, что после внесения изменений в документ (или любой другой артефакт),
А>об этом изменении надо сообщить тем, кто в этом документе заинтересован.
А>Ну что может быть понятнее и проще?
А>Дак ведь нет...

Это как раз можно решить даже технически. Начинаем с хранения документов в SVN...

А>Куча проектов где рады вообще, что есть док, а вести revision history и
А>вовремя оповещать всех заинтересованных — это недостижимый "рокет саенс"
А>И так почти со всей "мелочевкой", которая и определяет культуру ведения проектов.

А потребовать, дать образцы, время на соответствующую работу не пробовали? Нередко помогает.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Аноним, Вы писали:

ГВ>>>Странное дело — почему ими нельзя пользоваться? Риторический вопрос, не правда ли.
А>>Не нельзя, а не пользуются.
А>>Почему — это другой вопрос и совсем не риторический.

ГВ>Чаще всего, потому что никто не требует.

Еще чаще просто не понимают необходимости и делают как могут.

А>>Бог с ним с семинаром...
А>>Но вот к примеру совсем банальнейшая вещь, что после внесения изменений в документ (или любой другой артефакт),
А>>об этом изменении надо сообщить тем, кто в этом документе заинтересован.
А>>Ну что может быть понятнее и проще?
А>>Дак ведь нет...

ГВ>Это как раз можно решить даже технически. Начинаем с хранения документов в SVN...

Тулы не решают проблемы.
SVN — это хорошо, но далее возникают вопросы а о каких версиях оповещать (ну не оповещать же о каждом нестабильном чихе)
и возможно возникает понимание что не все физические версии являются стабильными
и прочее классические банальные проблемы CM.

А>>Куча проектов где рады вообще, что есть док, а вести revision history и
А>>вовремя оповещать всех заинтересованных — это недостижимый "рокет саенс"
А>>И так почти со всей "мелочевкой", которая и определяет культуру ведения проектов.

ГВ>А потребовать, дать образцы, время на соответствующую работу не пробовали? Нередко помогает.

Естественно.
Только вот на осознание этого нужно время и семинары с банальными вещами тоже помогают осознать проблемы.

А вообще ты зря "экс CCCР".
Сложных распределенных проектов в то время по пальцам можно было пересчитать.
Проблем и там было выше крыши.
Нужда в грамотных управленцах сейчас гораздо выше
и проблемы с проектами существуют во всем мире.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нет, не зря я про СССР вспомнил. Инженерная культура прививалась всё же получше, чем сейчас. Да и огромных распределённых проектов было выше крыши, только до руководства ими добирались не "молодые амбициозные", которые сначала становятся менеджерами в награду за послушание, а потом узнают, что электричество берётся не из розетки (подлость-то какая!), а вовсе другого класса специалисты.

Руководство проектами — это все же не совсем инженерная дисциплина.

Здравствуйте, Геннадий Васильев, Вы писали:

А>>Руководство проектами — это все же не совсем инженерная дисциплина.

ГВ>Ясное дело, поскольку это часть работы инженера.

Там, где это так, там большие проблемы, либо мы понимаем под "управлением проектами" совсем разные вещи.

Здравствуйте, Gaperton, Вы писали:

G>Прочитал ветку. Вопреки своим правилам, перейду на личности.
G>Ты, Геннадий, все-таки, чрезвычайно строг . Но, при этом, — не побоюсь этого слова, — справедлив .

Как эдипов папа (tm), я гарантирую это.

G>Интересно было бы с тобой поработать в каком-нибудь проекте.

Ну, может быть, свидимся.