Здравствуйте, <Аноним>, Вы писали:
А>Может быть мне не повезло, не довелось работать в компании, где процесс разработки стремится к лучшему.
А>Мне интересно мнение окружающих.
А>Как построен процесс разработки компаниях, есть ли он вообще?
А>ЗЫ. Прошу прощения за оффтоп. Крик души.
А что тут кричать? Если в нашей стране вся история менеджмента — это какие-то пятнадцать лет. Методики, о которых с таким вкусом говорят западные коллеги, разработаны в окружении, где менджменту только IT проектов уже около полтинника, а сама наука управления в рыночных условиях значительно старше.

Именно поэтому у нас до сих пор существуют компании, где единственным способом управления проектами является овертайм.
Но я не вижу в этом ничего страшного — в начальных условиях любой практически бизнес в России мог себе позволить не задумываться об эффективности вообще. Теперь ситуация другая, почти во всех сферах конкуренция настолько жесткая, что выигрывать начинает не самый наглый/быстрый, а тот, кто лучше организован.
И руководство большинства компаний начинает это понимать. Правда, пока что практика применения этих технологий в наших условиях настолько мизерная, что язык не поворачивается делать какие-либо выводы.

Я наблюдал проблемы внедрения RUP в компании, которая не совсем была готова к восприятию управленческих технологий вообще. Поначалу это напоминало Петра I и картошку. Однако постепенно нововведения были переварены и частично усвоены.

Я думаю, что лет через 10 в рунете будет достаточное количество разработчиков и менеджеров, прошедших практику применения технологий производства софта (в противовес кустарному мастерству) на достаточном для эффективного внедрения уровне. Нужно понять, что если руководству компании (имеется в виду исполнительное руководство — т.е. CEO, CTO, а не владельцы контрольного пакета) до лампочки методологии, то даже сверхкомпетентные разработчики не смогут достаточно долго удерживать ее на плаву. Потому, что степень компетентности влияет тем сильнее на деятельность компании, чем на более высоком уровне проявляется. Так что компания с некомпетентным исполнительным имеет гораздо больше шансов затонуть, чем компания с некомпетентными кодерами.
"Жаль только жить в эту пору счастливую уж не придётся ни мне ни тебе..."

Алексей Закис.
Внедрение RUP
Диалоги с заказчиком в 7 частях

От автора:

Вот так примерно я представляю себе это мероприятие (внедрение РУПа,
разумеется).
Может быть, этот текстик поможет вам уговорить потенциального клиента. Или
убедит не связываться с этим делом. Короче, может быть, он будет вам
полезен.

http://shmakov.ru/news/text118.html

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

SS>Алексей Закис.
SS>Внедрение RUP
SS>Диалоги с заказчиком в 7 частях

Статья конечно же интересная. Реклама Rational.
Только вот на практике, наверное, 7 частями не ограничешься. Руководителям софтверных компаний, каких я помню, до лампочки любые методологии. Будь то "тяжеловес" РУП, будь то ХР. Главное — денег нарубить. О проектировании, моделировании, использовании методологий и речи не идет. Опять же — всем работать, а то не успеем. Скудные постановки, минимум анализа, а то и вообще ничего этого нет. Скупой платит дважды.
Может быть мне не повезло, не довелось работать в компании, где процесс разработки стремится к лучшему.
Мне интересно мнение окружающих.
Как построен процесс разработки компаниях, есть ли он вообще?
ЗЫ. Прошу прощения за оффтоп. Крик души.

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

S>Именно поэтому у нас до сих пор существуют компании, где единственным способом управления проектами является овертайм.

Такие компании есть и там, за бугром
Я бы сказал, что уже сейчас в России есть компании, которые имеют бОльший опыт в этом,
чем многие западные компании. Особенно там, где профессионально занимаются аутсорсом.

В этом случае без нормального процесса страдают и те, кто дает работу,
и те, кто ее выполняет. То, что в той же Индии много контор, которые аттестованы
на какой-нибудь уровень СММ, говорит о многом.
С одной стороны это помогает искать заказы (менеджмент может хвалиться полученным уровнем и это аргумент,
для заказчиков), а с другой стороны процесс действительно помогает выполнять проекты.
Это когда все сидят в одной комнате и у всех все в головах, то процесс не нужен.
А когда проект, даже не очень технически сложный, просто распределен
географически, то без нормального процесса очень несладко...

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

S>Именно поэтому у нас до сих пор существуют компании, где единственным способом управления проектами является овертайм.
S>Но я не вижу в этом ничего страшного — в начальных условиях любой практически бизнес в России мог себе позволить не задумываться об эффективности вообще. Теперь ситуация другая, почти во всех сферах конкуренция настолько жесткая, что выигрывать начинает не самый наглый/быстрый, а тот, кто лучше организован.
S>И руководство большинства компаний начинает это понимать. Правда, пока что практика применения этих технологий в наших условиях настолько мизерная, что язык не поворачивается делать какие-либо выводы.

S>Я наблюдал проблемы внедрения RUP в компании, которая не совсем была готова к восприятию управленческих технологий вообще. Поначалу это напоминало Петра I и картошку. Однако постепенно нововведения были переварены и частично усвоены.

Время лечит! Вообще, будучи разработчиком, приходилось очень долго убеждать менеджмент о применении какой — либо технологии, нововведении. Золотое слово — "стабильность" — приходилось ломать его. Нужно не терять настойчивости, упорства, навязывать свою точку зрения на вещи, процессы. Без этого нельзя. Стабильность может затянутся и превратится в застой. Я немного абстрактно выражаюсь, прошу прощения. Это все по поводу того, что любые нововведения в любом случае переварятся, главное — достичь понимая во время, пока вас не обскакал конкурент.

S>Я думаю, что лет через 10 в рунете будет достаточное количество разработчиков и менеджеров, прошедших практику применения технологий производства софта (в противовес кустарному мастерству) на достаточном для эффективного внедрения уровне. Нужно понять, что если руководству компании (имеется в виду исполнительное руководство — т.е. CEO, CTO, а не владельцы контрольного пакета) до лампочки методологии, то даже сверхкомпетентные разработчики не смогут достаточно долго удерживать ее на плаву. Потому, что степень компетентности влияет тем сильнее на деятельность компании, чем на более высоком уровне проявляется. Так что компания с некомпетентным исполнительным имеет гораздо больше шансов затонуть, чем компания с некомпетентными кодерами.

Супер. Слушай, последнюю фразу перепишу и запомню. Действительно так! Успех = компетентность * степень влияния. Представь, какого успеха можно добится при высоком уровне компетентности и влиянии на процессы внутри (+ за пределами) организации.

S>"Жаль только жить в эту пору счастливую уж не придётся ни мне ни тебе..."

Жаль ....

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

А>Такие компании есть и там, за бугром
А>Я бы сказал, что уже сейчас в России есть компании, которые имеют бОльший опыт в этом,
А>чем многие западные компании. Особенно там, где профессионально занимаются аутсорсом.

Согласен. Но возможно это не реальный опыт, а скорее меры принятые для получения определенного сертификата для участия в каких то проектах. И не всегда сертификат говорит о том, какие реальные технологии использует компания. Сертификат можно получить только для "фасада" (выражаясь терминами проектирования). Это мое мнение. Вероятно, я не прав.

А>В этом случае без нормального процесса страдают и те, кто дает работу,
А>и те, кто ее выполняет. То, что в той же Индии много контор, которые аттестованы
А>на какой-нибудь уровень СММ, говорит о многом.
А>С одной стороны это помогает искать заказы (менеджмент может хвалиться полученным уровнем и это аргумент,
А>для заказчиков), а с другой стороны процесс действительно помогает выполнять проекты.

Вот вот. Помогает искать заказы.

А>Это когда все сидят в одной комнате и у всех все в головах, то процесс не нужен.
А>А когда проект, даже не очень технически сложный, просто распределен
А>географически, то без нормального процесса очень несладко...

Все в голове не удержишь, даже сидя в одной комнате. Хотя, если уровень понимания внутрях команды разработчиков достиг ОЧЕНЬ высокого уровня, что даже communication не нужен, то да!

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

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

А>>Такие компании есть и там, за бугром
А>>Я бы сказал, что уже сейчас в России есть компании, которые имеют бОльший опыт в этом,
А>>чем многие западные компании. Особенно там, где профессионально занимаются аутсорсом.

А>Согласен. Но возможно это не реальный опыт, а скорее меры принятые для получения определенного сертификата для участия в каких то проектах. И не всегда сертификат говорит о том, какие реальные технологии использует компания. Сертификат можно получить только для "фасада" (выражаясь терминами проектирования). Это мое мнение. Вероятно, я не прав.

Это так же как и с дипломом.
Диплом полезен во многих смыслах.
И как бумажка, которая помогает найти работу,
и как свидетельство того, что человек что-то прослушал и пр...
В общем важна не сама бумажка как таковая, а путь, который пройден.
Подготовка к сертификации и сама сертификация
никогда не проходят бесследно для компании
Плюсы есть всегда. Но и минусы тоже могут быть.

S> Алексей Закис.
S> Внедрение RUP
S> Диалоги с заказчиком в 7 частях

S> http://shmakov.ru/news/text118.html

Добавлен эпилог с прикидками, сколько это может стоить, и насколько может
быть окупаемо. Вы можете подставить в расчет местные (российские) цены и
оценить затраты.