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

SE>Такая проблема действительно есть. Для этого пишут роадмапы на полгода, год и далее.

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

J>>Этого бы не было если бы разработка шла более традиционными методами с нормальным долгосрочным планированием.

SE>А вот это как раз миф Переделывать все равно придется, только позже и дороже.

Что-то переделывать приходится всегда. Но мне кажется, ваши утверждения не вполне согласуются друг с другом. СКРАМ сам по себе никаких даже полугодовых роадмапов не предусматривает, т.е. вводя роадмапы вы уже делаете уклон в сторону более традиционных схем, о которых я и говорил.

В любом случае, проблема близорукости становится актуальной именно для аутсорсинга, основанного на СКРАМе.

Вобще, еще одна из проблем аутсорсинга, на мой взгляд, то что обычно продается хед-каунт, а не собственно услуга. Заказчик сплошь и рядом занимается микро-менеджментом удаленной команды, а это не слишком эффективно. Короче, не всякому дано успешно вести удаленную команду со стороны заказчика.

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

SE>>Такая проблема действительно есть. Для этого пишут роадмапы на полгода, год и далее.

J>Зачастую разработчики на стороне аутсорсера не в курсе этих роадмапов,

Ну, значит надо держать в курсе.

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

Нет, все таки цель — продукт У нас так было. Если было нужно, и спринты перезапускали. И длительность меняли. Обычно в меньшую сторону — у нас это увеличило перформанс

J>>>Этого бы не было если бы разработка шла более традиционными методами с нормальным долгосрочным планированием.

SE>>А вот это как раз миф Переделывать все равно придется, только позже и дороже.

J>Что-то переделывать приходится всегда. Но мне кажется, ваши утверждения не вполне согласуются друг с другом. СКРАМ сам по себе никаких даже полугодовых роадмапов не предусматривает, т.е. вводя роадмапы вы уже делаете уклон в сторону более традиционных схем, о которых я и говорил.

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

J>В любом случае, проблема близорукости становится актуальной именно для аутсорсинга, основанного на СКРАМе.

Значит, опять-таки на это надо обратить больше внимания. Как заказчику, так и команде.

J>Вобще, еще одна из проблем аутсорсинга, на мой взгляд, то что обычно продается хед-каунт, а не собственно услуга. Заказчик сплошь и рядом занимается микро-менеджментом удаленной команды, а это не слишком эффективно. Короче, не всякому дано успешно вести удаленную команду со стороны заказчика.

+1

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

Почитал внимательнее ваш пост выше. Хе-хе, у моей нынешней китайской конторы и у ГлобалЛджика, где вы раньше работали, есть по крайней мере один общий американский клиент. Я даже в КлеарКвесте этого заказчика вижу много экаунтов, начинающихся на gl, что видимо и означает GlobalLogic.

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

Да сдадут тебе в аренду студиков с академии ШАГ как это делает наш местный аутстаффер Ciklum и всего то делов

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

UA>Здравствуйте, Ник, Вы писали:

UA>Да сдадут тебе в аренду студиков с академии ШАГ как это делает наш местный аутстаффер Ciklum и всего то делов

Фига се... правда что-ли?

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

UA>>Да сдадут тебе в аренду студиков с академии ШАГ как это делает наш местный аутстаффер Ciklum и всего то делов
SE>Фига се... правда что-ли?

Это бизнес, на любые деньги можна найти исполнителей — главное чела красиво обернуть и продать, а заказчик пусть сам дальше парится c ним — дело сделано как говорится

16.07.2010 9:11, murzik пишет:
>
> Тут надо учесть, что американцы не требуют "суперпрогера во всем" и "все
> сделать вчера и срочно", менеджмент ставит более чем вменяемые сроки и
> задачи, местная команда ищет не супергениев, а просто вменяемых людей, с
> которыми комфортно работать. ПОэтому все идет хорошо и все довольны. На
> зп тоже не жмутся.
Это такая редкость...

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

V>16.07.2010 9:11, murzik пишет:
>>
>> Тут надо учесть, что американцы не требуют "суперпрогера во всем" и "все
>> сделать вчера и срочно", менеджмент ставит более чем вменяемые сроки и
>> задачи, местная команда ищет не супергениев, а просто вменяемых людей, с
>> которыми комфортно работать. ПОэтому все идет хорошо и все довольны. На
>> зп тоже не жмутся.
V>Это такая редкость...

Да нет, все кроме зарплаты — правда. А вот про зарплату — да, жмутся, ибо они как раз ради экономии и аутстафят.
Но если человек приносит пользу, то постепенно жаться перестают.

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

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

V>>16.07.2010 9:11, murzik пишет:
>>>
>>> Тут надо учесть, что американцы не требуют "суперпрогера во всем" и "все
>>> сделать вчера и срочно", менеджмент ставит более чем вменяемые сроки и
>>> задачи, местная команда ищет не супергениев, а просто вменяемых людей, с
>>> которыми комфортно работать. ПОэтому все идет хорошо и все довольны. На
>>> зп тоже не жмутся.
V>>Это такая редкость...

SE>Да нет, все кроме зарплаты — правда. А вот про зарплату — да, жмутся, ибо они как раз ради экономии и аутстафят.
SE>Но если человек приносит пользу, то постепенно жаться перестают.

Ну не жмутся по местным меркам. Конечно, американские зп нам не платят, но зато не делают всех ошибок обычных начинающих удаленных работадателей: найти за 50 баксов суперменов, которых можно пинать в хвост и в гриву, ставить нереальные сроки и задачи, и визжать по телефону каждые 5 минут "фигли еще не сделано!!!!???"

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

M>Ну не жмутся по местным меркам. Конечно, американские зп нам не платят, но зато не делают всех ошибок обычных начинающих удаленных работадателей: найти за 50 баксов суперменов, которых можно пинать в хвост и в гриву, ставить нереальные сроки и задачи, и визжать по телефону каждые 5 минут "фигли еще не сделано!!!!???"

+1. К слову многие местные работодатели, особенно те, у которых софт не основной источник дохода тоже таким страдают. Один в один.
Мне за что американцы нравятся — у них здравый и реалистичный подход к разработке ПО. Они не ждут чуда.

Непонял: В офисе нет нужды четко ставить задачи? нет проблем с приемкой криво поставленных (и видимо также сделанных) задач? Всем плевать на сроки? И исполнители запросто переключаются между задачами по 8 раз в день?

Может просто у вас рабочее время офисных работников никто не считает, и поэтому всем плевать на расходы связанные с кривой постановкой и переключениями между задачами? А на удаленке — просчёты в управлении вылезают на свет.

18.07.2010 20:33, hlt пишет:
>
> Непонял: В офисе нет нужды четко ставить задачи? нет проблем с приемкой
> криво поставленных (и видимо также сделанных) задач? Всем плевать на
> сроки? И исполнители запросто переключаются между задачами по 8 раз в день?
Даже не знаю, что ответить. Ощущение, что вы живете не в реальном мире,
а вами выдуманном виртуальном.
По вопросам:
1. Нет, нет нужды, ибо очень легко уточнить и скорректировать в любой
момент.
2. Нет, ибо вытекает из 1
3. Отвечу вопросом на вопрос: А вас всегда или все или никто? Других
вариантов не бывает.
4. Если нужно, то переключаются.

>
> Может просто у вас рабочее время офисных работников никто не считает, и
> поэтому всем плевать на расходы связанные с кривой постановкой и
> переключениями между задачами?
Отвечу вопросом на вопрос: А вас всегда или все или никто? Других
вариантов не бывает.

> А на удаленке — просчёты в управлении
> вылезают на свет.
Поздравляю, вы поняли основную проблему удаленки.

17.07.2010 9:21, SE пишет:
>
>> > Тут надо учесть, что американцы не требуют "суперпрогера во всем" и "все
>> > сделать вчера и срочно", менеджмент ставит более чем вменяемые сроки и
>> > задачи, местная команда ищет не супергениев, а просто вменяемых людей, с
>> > которыми комфортно работать. ПОэтому все идет хорошо и все довольны. На
>> > зп тоже не жмутся.
> V>Это такая редкость...
>
> Да нет, все кроме зарплаты — правда. А вот про зарплату — да, жмутся,
> ибо они как раз ради экономии и аутстафят.
> Но если человек приносит пользу, то постепенно жаться перестают.
Да я не спорю, просто то, что вы описали — это действительно большая
редкость на просторах ExUSSR.
Чаще наблюдается все, что вы написали, но с точностью до наоборот
(особенно если работодатель не американский и не немецкий).

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


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


Вот точно, согласна на 100%. А вообще очень часто сейчас вижу ситуацию, когда за квалифицированный труд хотят заплатить 3 копейки — жаба-с.
А уж об аутстаффинге в этих условиях вообще страшно подумать, как пытаются на нем экономить

19.07.2010 17:04, KTerra пишет:
>
> V>Чаще наблюдается все, что вы написали, но с точностью до наоборот
> V>(особенно если работодатель не американский и не немецкий).
>
>
> Вот точно, согласна на 100%. А вообще очень часто сейчас вижу ситуацию,
> когда за квалифицированный труд хотят заплатить 3 копейки — жаба-с.
Не только жаба. Часто полная безграмотность русского манагерства. Оно-то
руками водит, но и близко не понимает, что подчиненные делают и сколько
ресурсов может потребовать та или иная задач. Отсюда часто, могут много
заплатить за элементарные вещи, но снаружи блестящие и не платить за
действительно сложные, но не видимые снаружи продукта.

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

Ник>В Москве разработчики хотят всё больше денег. Даже за 80 тыс. рублей не так легко найти более-менее опытного программера в самой обычной прикладной области (я не говорю ни о каких дата-майнингах или там mission-critical многопоточных системах и т.п.)
Ник>При этом периодически поступают предложения бодишопов из глубинки — купите у нас программера за 500 рублей в час! Он будет работать, не болея! Вы сможете контролировать его через Remote Desktop! Он не будет занимать место в офисе! Не надо оплачить отпуск! Если этот программер захочет уйти, мы заменим его другим!
Ник>Конечно, сразу приходят в голову риски, с которыми можно столкнуться при найме такого человека-фирмы. Но если этими рисками управлять, то возможно ли это всё-таки? Ну, к примеру, отдавать в удалённую разработку не весь объём работ, а только что-то рутинное и не содержащее особой коммерческой ценности. Следить за нормальным документированием и за тем, чтобы не оказаться "подсаженным" на эту фирму-исполнитель.

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

Ник>Сорри, если эту тему уже обсуждали, — тогда дайте ссылку. В поиске был.

Исходя из моего опыта со стороны покупателя услуг по разработке ПО:

1) В ИТ важно иметь нужные навыки и знания, так что голый демпинг не пройдет.
2) Посылать своих сотрудников в командировки к вендору недешево. Расходы на командировки могут проесть большую часть экономии.
3) Общаться через почту и по телефону не так эффективно, как в живую.
4) Штатные сотрудники, как правило, имеют выше мотивацию добиваться поставленных целей. Сотрудников вендора очень тяжело мотивировать работать хорошо, так как нет контроля над их карьерой и компенсацией.

Сорри, лень было читать камменты, да и некогда, но попробую от себя сказать!

1) Не помню в какой книге, толи в Буче, толи еще где, был график нарисован: почти линейная зависимость, чем дальше вы от работника, тем сложнее...
2) да, сам признаю, были косяки, задачу ставят одну, поговришь, всё пучком, в итоге сделаешь не то, а потом еще и виноват...
3) ну и ремотный конртакт вообще сложнее, для сильно ответственных людей

А так, вообще, да уже не для кого не секрет, уже лет 5 как назад из дефолт-сити стали выносить разработки в провинции... дешевле!

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

А>Следующий момент — собственно разработчики. Они будут несчастливы — ведь экономить то будут на них. ... что мы и видим в региональных офисах Люксофта в частности.

Эх, ты меня опередил! А то иду, смотрю — ОН! По описанию — ну точно ОН!

Ник>>Ну, к примеру, отдавать в удалённую разработку не весь объём работ, а только что-то рутинное и не содержащее особой коммерческой ценности. Следить за нормальным документированием и за тем, чтобы не оказаться "подсаженным" на эту фирму-исполнитель.

А>А тебе не кажется, что за соблюдение всех этих пунктов ты в результате потратишь больше, чем на зарплату нормального программиста в штате компании?

Здесь есть такая штука: если у них _действительно_ есть такая рутина, которую легко выделить из общего процесса, легко проконтролировать по результату, и в то же время она не требует постоянного к себе внимания — это и вправду довольно эффективно выделить "на сторону" в виде коротких или не очень подрядов-контрактов. Ведь держать у себя отдельного человека только из-за того, что его услуги — весьма, заметь, рутинные — понадобятся весьма эпизодически — это точно такой же риск, только с другой стороны. Ведь этот человек точно так же может "вырасти", найти себе более интересную работу, и т.д. и т.п. Что обычно и происходит, в результате чего такое "место" все равно "находится в постоянной вакансии". Ну и по мере необходимости уже достаточно острой "затыкается" другими имеющимися кадрам — которые тоже, поди, не в восторге от такой "непрофильной работы", за которую и заплатить-то нормально тоже нельзя. Ну чисто с точки зрения бизнеса заплатить за эту рутину по часовой ставке "ценного работника" неэффективно, поскольку на эти деньги вполне можно держать эту вакансию "постоянно открытой".

А>Вообще, если аутстаффинг это так здорово как расписывают некоторые граждане — почему вся разработка софта еще не переехала в Индию или Китай? Не задумывался?

Она переехала. Только не аутстаффингом — она целыми проектами переехала. С переменным успехом, но переехала. А "переехать аутстаффингом" она в принципе не может, поскольку в случае аутстаффинга "наружу" передаются не проекты и задачи — как в аутсорсинге — а именно "открытые вакансии". Т.е. в результате чел фактически пашет таки на контору где-нибудь в той же Швейцарии — Один Большой Банк не-будем-тыкать-пальцем — но формально как "юридическая единица" он числится за "конторой-провайдером". При этом он уже и жить может уже "там" — в смысле, вообще работать непосредственно уже географически в офисе заказчика — но "за одну зарплату", которая уже "наша", а не "ихняя". Всем ведь выгодно.

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

V>Что можно аутстаффить — тестирование.

Не факт: как раз это труднее всего аутстаффить на проектах даже "выше среднего простого десктопа".

V>Если есть хорошие тест-планы, которые надо просто честно пройти, нажимая на кнопочки, то такое вполне можно вынести. Естественное, удаленных тестеров придется контроллировать, например, вставляе в тест-планы заведомо непроходимые тесткейсы, требуя скрин-шотов в отчетах о проведенных тестарах и четко прописав в контракте штрафы за пропущенные баги (при условии, что они покрывались тест-планами).

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

Но даже без этого — веб-тестирование в целом "на отлично", а вот что-либо другое, которое требует "нетривиальных" усилий по настройке тестового окружения — с этим уже проблемы.

V>То есть придется иметь начальника отдела тестирования/автора всех тестпланов, паков и прочего он-сайт, и десять обезьян офф-сайт.

А вот тест-планы писать можно и проатстаффить. Только надо чтобы точно была уверенность, что с той стороны — человек знающий как это писать. Вообще передавать наружу удобнее всего то, что можно сделать именно а) разово; б) без привлечения ресурсов с нашей стороны. Иначе затраты на банальное администрирование систем этих самых "аутстафф-тестировщиков" быстро превысят всякую выгоду от. К тому же тестировщики — которые если "просто кнопко-нажимальщики по готовому плану" — они и на месте не сильно дороги должны быть, с одной стороны. А с другой — не так уж и просто найти людей, которые действительно мыслили бы "тупо правильно сделать как написанно и тупо проверить результат как написанно" — этого у нас, в России и на/в Украине очень мало водится. Особенно в "недорогих провинциях".

V>Еще можно прекрасно аутстаффить саппорт L1. Отвечать на письма, воспроизводить баги и регистрировать их в Джире, передавая результат выше.

На практике я не доверил бы не нанятому мной лично человеку отвечать на письма моих заказчиков. Чтобы какой-то Х. (хто-то) своим случайным плохим настроением попортил мне всю репутацию? А потом все рассказывают "какой тупой у нас (или у вас) саппорт!!!"

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

CC>А что там страшного то?
CC>В геймдеве подобные задачи редко, но попадаются: есть математика, надо разогнать до второй космической.

Угу. При этом есть всего несколько необходимых условий для решения таких задач:

а) знать математику на уровне, чтобы понять что именно написано на матлабе;
б) знать матлаб на уровне, чтобы понять что на нем написано;
в) знать матлаб в его сочленении с си++ на уровне, чтобы переписать уже готовое в более эффективное на си++;
г) знать си++ и его прикладную сторону в математике на уровне, чтобы написать эффективнее, чем это делает мат-лаб.

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