Комментарии 25
Я был с обоих сторон баррикад оутсорс разработки, сейчас например как разработчик
и я был, есть и буду, яростным противником оутсорса, потому что предубеждения - это не какойто миф, это реальная реальность, я ниразу еще не сталкивался с проектом где задействованы оутсорсеры и хотябы 50% из озвученных предубеждений не реализовывались
Главный ваш посыл в том "ну вы договоритесь с оутсорсером обовсём и всё будет чикипуки"... но факт в том что вы обовсём не договоритесь
Договора оутсорса заключает менеджмент в желании сэкономить бюджет на ИТ отделе, и зачастую у постановщиков задач не хватает квалификации это сделать.
Изза чего моментом выкидываются из проекта все разновидности тестов (юнит/интеграционные),
урезается в край поддержка (вы профессионалы, вы все сделаете отлично, ничего ломаться не будет)
совершенно не продумывается дальнейшее развитие (в ТЗ мы обговорили продукт - продукт был сделан, вы ни словом не обмолвились что разработка продолжится и вы захотите например обновлять версию фреймворков чтобы закрывать уязвимости)
можно очередной раз завести шарманку на тему "ну надо просто всё учитывать"
да блин НИКТО ничего не учитывает когда берутся за оутсорс, в эту сторону идут чтобы сэкономить, а не ввалить 100500 млн килобаксов в 24/7 поддержку оутсорсерами командой из 20 человек с зарплатами по 300тыщ каждый, когда у вас проект - форма опроса посетителей магазина или еще чёнить типа такое.
ну а ваша статья стандартное заклинание для менеджеров которые "вот наконец мы порежем косты и отдатим ИТ на оутсорс, получим золотой парашют и гори оно огнем потом"
я вот прям сейчас доделываю проект, с тяжелым легаси, со страшными костылями...и ухожу на другой проект...я хз как этот кошмар будут поддерживать.. но заказчик "мы за динамические команды, будут вопросы мы опять расширим команду"... я хз, я полгода вникал в эти отложения мамонта чтобы чтото адекватное делать, как они "быстренько расширят команду" я понятия не имею
можно сказать что это я типа на такой проект попал? так он у меня не один в карьере!! и каждый раз одно и тоже
Когда я был со стороны заказчика...я был в ужасе как нам отдали огромный монстроподобный проект который делали 10 человек только бекендов...а с нашей стороны был я, миддл который чото умеет писать на PHP для поддержки (у нас java была основным языком)...а вопросов там в жире в техдолге >50 тикетов.. но ленточку перерезали бутылку разбили о сервер...класс!! я тогда оч сильно прокачался и ушел на ЗП выше (правда в питон)
Всегда лично и очно заключаю договоры с лично директором/ответственным, всегда обговариваю все нюансы и точки развития, всегда всё прописываю в договоре без "это и так понятно". В результате всегда опережаю сроки, всегда все довольны, всегда получаю приглашение в штат после заказа. Разумеется, при изменении задач, заключается новый договор.
Видимо, вам не повезло. Вы попадались в проекты с "эффективными" менеджерами с обоих сторон. Ну или я слишком дёшево работаю...
Вы в одиночку работаете или с маленькой командой?
Я в данном случае просто тимлид в галере, у меня команда 10+ человек и около десятка проектов (в рамках одной инфраструктуры, очень тесно связанные друг с другом) и бывало по 2-4 релиза в месяц...и еще двое коллег тимлидов с такимиже командами.. и схожим набором проектов..которые тоже все в одном со мной окружении.
это всё отлично работает когда вы фрилансер, а когда у вас проект масштаба какогонить яндекса то это уже так не работает. ...я в таком работал, не в яндексе, в штатовской компании...но схожего масштаба...и работал там как аутстаффер..и это помоему единственное адекватное решние...потому что даже штатные департаменты с трудом тянут всякие TTM..а отдавать на аутсорс то вообще будет бардак без конца
Я понимаю, конечно, что статья рекламная. Но на самом деле все пункты верны. Заказывать проекты на аутсорсе можно в трех случаях:
1) Вы заказываете у конторы-профессионала в конкретной специфичной области работу в этой области. Например, какой-то расчетный софт для элетроэнергетики у компании который имеет опыт написания подобного софта в куче генерирующих компаний.
2) У вас маленькая фирма и вам нужен один айти проект и в ближайшее время не предвидится новых. Да, нанимать команду и выстраивать процессы это дорого и долго. Но если вам нужна разработка года на три, то тут уже намного выгоднее сделать свою команду.
3) Вы отмываете бабло. Вот тут конечно да, на своей инхаус разработке много не освоишь.
А так стандартный аутсорс (даже не аутстаф) это:
1) Дорого (Вам продадут джунов как мидлов, мидлов как синьоров, архитекторов посчитают на год когда работы на 3 месяца)
2) Долго (Вы будете бесконечно согласовывать приложения к ТЗ после работы аналитиков или получаете продукт непонятного качества)
3) Вы не контролируете процесс разработки (Нет никакой гарантии что разрабами с вашего проекта латают дыры на другом).
4) Вы не сможете это поддерживать сами (У вас нет разрабов? Готовьте бабки на любое изменение. У вас есть разрабы? А вот вам система на каком-то стремном фреймворке и 0 понимания как это работает)
Конечно возможна нормальная аутсорс разработка, но вам нужна:
1) Команда аналитиков которая напишет ТЗ так, что все предусмотренно
2) Команда юристов которая напишет договор так, что за срыв сроков, баги и кривые метрики просто не заплатят денег
3) Собственные архитекторы которые понимают как готовое решение будет встроено в ландшафт и как оно будет дорабатываться и поддерживаться.
Но вопрос, имея пункты 1-3, не проще ли взять несколько разрабов или хотя бы аутстаф?
Сколько работали с аутсорсом - все какая-то дичь происходила. Франчи под небольшой проект предлагали недостаточно квалифицированных товарищей. На одном проекте они параллельно внедрили разработанное внутренней командой решение у конкурентов. Стоят они в разы дороже, если это не фрилансер за тарелку супа. Если это фрилансер, то он будет весьма ограниченно доступен и пропадет в самое неудобное время. В общем, разработка своего продукта с привлечением аутсорса - это дополнительный фактор риска. Может быть смысла держать штатного дизайнера или копирайтера при небольшом фронте работ и нет, но если внутренний продукт активно развивается и постоянно требует внимания, то аутсорс - это такое...
Всё хорошо, но есть, как говорится, нюанс. Все перечисленные "предубеждения" - это не предубеждения, а риски, которые могут сыграть, а могут и нет, в зависимости от кучи условий.
В сторону аутсорса имеет смысл смотреть тогда, когда:
Нет смысла нанимать собственную команду. Собственная команда - это не только зарплата. Это затраты на поиск людей, их вхождение в проект, поиск замен, управление и много что ещё. При аутсорсе в нормального аутсорсера всем этим будет заниматься собственно компания-аутсорсер. И если проект относительно короткий (до пары лет), то аутсорс может выйти ощутимо дешевле.
Нет подходящих компетенций. Их освоение может быть долгим и дорогим, в то время как люди, которые делают похожие проекты пачками, уже в теме и начнут работать над проектом без долгой раскачки. Касается в том числе и навыков управления проектами и работы с "нежными айтишниками", которые почему-то не любят, когда с ними общаются матом, зажимают кофемашину и т.д. и могут спокойно свалить в другое место - мобильность у толковых спецов вполне на уровне.
Срочно нужно 1-2 человека в сработанную команду на относительно короткое время (до полугода). Тут аутсорс в той, или иной форме почти без вариантов: нанимать человека на несколько месяцев, а потом увольнять его - это куча геморроя, да и вряд ли получится быстро закрыть вакансию традиционными способами. А в сработанной команде свои профи приглядят, чтобы всё было хорошо.
Аутсорс настоятельно не рекомендуется, если:
Нет готовности платить. Есть куча способов пустить на ветер бюджет, но один из самых верных - это найти малоизвестную аутсорсинговую компанию, которая обещает сделать всё "подешевле". Просто потому, что сыграют все перечисленные в статье риски и вместо продукта вы получите поеденную кем-то тыкву. Если бюджет явно ниже рынка, то только сами - тогда есть ещё хоть какие-то шансы. В общем, надо садиться и считать.
Есть мнение, что "заплатим деньги и нам всё сделают". Нифига. Над проектом активно придётся работать: рассказывать специфику, погружать в предметную область, принимать работу и т.д.. Да, не самим писать код, не самим тестировать, не самим заниматься детальной аналитикой, но в грамотной работе над проектом есть куча действий на стороне заказчика и хорошего результата без них не будет.
Нет возможности оценить качество работ "в процессе". Тут куча способов есть, начиная от регулярных поставок и контроля работ на стороне заказчика и заканчивая перекрёстным аудитом, когда в договоре сразу прописывается независимый аудит сторонней компанией как обязательное условие выплат. Но да, будут затраты ещё и на этот аудит.
В общем, если есть своя нормальная постоянная команда с понятной загрузкой после окончания проекта - аутсорс однозначно не нужен. В остальных случаях надо крепко думать и считать все затраты. Но уж точно не попадаться на "дешёвый аутсорс". С "дорогим" тоже могут быть проблемы, но с "дешёвым" они будут гарантированно.
Может лучше не отвечать на вопросы (ответить можно по-разному), а собрать статистику работы своей команды vs. наемная команда?
Мой опыт не в пользу наемных.
У наемной команды задача денег взять и контракт не нарушить.
Будет интересно посмотреть на статистику, если кто-то когда-то этим займётся. А пока же хотелось сказать, что не стоит обобщать и говорить, что эти высказывания верны по отношению ко всему аутсорсу. Мы нигде в целом не писали, что это мифы, а обратили внимание, что всё это риски, которые следует учитывать начиная свой проект и выбирая формат работы, и которых можно избежать выбирая подходящую для задач аутсорс команду.
Во-первых, у аутсорсеров опасный майндсет "после нас хоть потоп". Аутсорсер пишет код, который ему поддерживать и развивать не придётся, поэтому он готов к удовлетворению самых диких запросов заказчика и использованию сомнительных решений в угоду скорости разработки.
Во-вторых, аутсорсер по определению не может так же хорошо разбираться в прикладной области и нюансах конкретного проекта, а это чаще всего является основными условиями разработки хорошего продукта.
В-третьих, аутсорсеры уходят и уносят экспертизу. Получается, что заказчик вместо развития своих сотрудников прокачивает чужих.
Не стоит говорить в целом про все компании данного типа. Для каких-то действительно это будет так, к сожалению. Но по каждому тезису могу ответить в рамках нашего опыта:
"после нас хоть потоп" – вероятно это может быть так в компаниях для которых не важна репутация, работают как конвейер, пытаются получать заказы за счёт заниженной стоимости, а не качества. Если же компания с хорошей репутацией как среди разработчиков, так и среди заказчиков, то она будет стараться эту репутацию подтверждать. И мы как раз за развитие проектов, а не сделать и слить побыстрее. Среднее время работы с клиентами более 3 лет. Разработчики понимают, что проект будут развивать они и дальше, или их коллеги, поэтому к качеству кода вопросов нет, и подключение к проекту или передача инхаус не вызывает проблем. Для нас приоритет это долгосрочные отношения с заказчиками, а не разовая реализация проекта.
"не может разбираться так же хорошо в прикладной области" – тут тоже всё зависит от кейса. Если мы рассматриваем какой-то начинающий бизнес, у которого опыт собственный небольшой, а у аутсорс компании есть в кейсах успешные примеры из сферы заказчика, то такое взаимодействие будет полезным для заказчика. В статье про выбор подрядчика мы как раз писали, что стоит обращать внимание на опыт в нужной сфере, так как он не будет лишним. Если говорим про сформированную команду продукта с хорошим опытом именно в продукте, то ничего не мешает объединить этот опыт с опытом команды в разработке, чтобы не тратить время на старте на формирование команды.
"аутсорсеры уходят и уносят экспертизу" – чтобы была возможность развития своих сотрудников нужно чтобы эта экспертиза в компании как-то появилась, в том числе у менеджмента, иначе существует риск создания внутренней некомпетентной команды, где на старте проекта будет стоять джун, который заложит такой фундамент, который в итоге не позволит проекту развиваться качественно. Для кейса, когда заказчик хочет всё-таки потенциально инхаус команду мы работали по следующей схеме: за этап документации и дизайна обеих платформ отвечали полностью мы, при этом у нас были регулярные созвоны с командой заказчика, где мы всё обсуждали; далее на этапе разработки мы сразу в инфраструктуре заказчика настроили проекты, но за разработку Android проекта отвечали мы, а за iOS проект отвечала уже внутренняя команда, которую начали формировать; Android опережал намеренно, чтобы задачи в первую очередь ставились нами, а для iOS обозначались какие-то кейсы, которые требовали дополнительной логики, если они были нужны. Таким образом была сформирована мобайл компетенция в команде заказчика, старт проекта был заложен разработчиками хорошего уровня, чтобы не было проблем с развитием. С наймом во внутренние команды заказчикам также помогаем, чтобы помочь в кейсе, когда у заказчика нет технической экспертизы для этого.
вероятно это может быть так в компаниях для которых не важна репутация
Даже у EPAM'овских такой майндсет, про галеры меньшего размера и говорить нечего.
Разработчики понимают, что проект будут развивать они и дальше, или их коллеги
Регулярно слышал от гребцов, что преимущество галеры - это возможность в любой момент свалить на другой проект, а как написанное будут сопровождать какие-то другие абстрактные коллеги всем глубоко пофиг.
за этап документации и дизайна обеих платформ отвечали полностью мы, при этом у нас были регулярные созвоны с командой заказчика, где мы всё обсуждали
Экспертиза - это не только знания, но и опыт. Можно сколько угодно обучать кого-либо, но 10 000 часов написания кода - это 10 000 часов вложенных в профессионализм. Так что если код пишет подрядчик вместо своих, то разработчики подрядчика совершенствуются, а свои нет.
поэтому он готов к удовлетворению самых диких запросов заказчика
А инхаус команда разве не готова удовлетворять самые дикие запросы своего руководства?
Аутсорсер пишет код, который ему поддерживать и развивать не придётся
Разработка ПО - это не батон колбасы, где купил и забыл. Не думаю, что хоть кто-то в здравом уме будет заказывать разработку серьёзного софта у стороннего исполнителя без дальнейшей перспективы сопровождения этого софта тем же исполнителем. Более того, в любой компании, занимающейся аутсорсинговой разработкой, большинство проектов - это именно сопровождение старых проектов, а не создание новых.
Не думаю, что хоть кто-то в здравом уме будет заказывать разработку
серьёзного софта у стороннего исполнителя без дальнейшей перспективы
сопровождения этого софта тем же исполнителем.
добро пожаловать в реальный мир ;)))
именно так подавляющее число проектов и реализуется оутсорсом
еще бывают вот так - тендер на разработку выигрывает одна контора, а на поддержку другая
еще...сумма на разработку одна, а на поддержку в 10 раз меньше, и оутсорсер естественно целиком меняет команду со схемы 3 сеньора, 10 миддлов, на 2 джунов и 1 мидла кторый пришел на работу когда сервис только что зарелизили. (это у меня прям ща так на проекте)
Аутсорсинг не может быть использован для критичных для компании проектов. Например Apple не будет аутсорсить проектирование ядра MacOS или системы на кристалле Айфона аутсорсерам. То есть все рассуждения поста - это про вещи некритичные, которые если сделают на отцепись, то компанию не повалят, особенно если это все сдублировано и в случае чего можно взять другого аусорсера.
Хуже аутсерса только аутстаф.
почему? аутстаффер такойже человек как и кадровый айтишник, только у него проблемы с фундаментальной мотивацией..но это не всем важно (когда я так работал в эпаме, из всей команды только я за это переживал)
а постановку задач и контроль - за этим уже местные следят и качество в разы выше в итоге
по аутстаффу у меня только один мой пример, по этому вполне вероятно и так может быть
как было у меня
1) сначала мы работали изолировано, потом нас присоединили к инхаус команде..и так работали около года, полная интеграция была, потом менеджмент начал опять отделять аутстафферов...(мне совершенно непонятно зачем) но только в рамках разработчиков, ПМ-ы, релизменеджеры и скраммастер были от заказчика
2) У нас не было учета часов, сугубо постановка задача в спринте - выполнение, ревью по результатам... никакого идиотизма с приписками работы.. вообще ненавижу эти чиселки "сколько сделано столько и заплачено" ...imho это всегда дорога в ад, что в оутсорсе что в оутстаффе что просто в обычной работе... это требует очень кропотливого менеджмента чтобы избегать перекосов..но в такое обычно никто не может.. на одном проекте доходило до маразма ...надо закрыть 160 часов разработки, даже если вы в этом месяце были на больничном, в отпуске, пришли на проект в 25 числа..а отчет 31 числа..., если ваша задача - текущая поддержка проекта а не разработка новых фич... убейся но напиши сам себе задач на 160 часов и так напиши чтобы заказчик их согласовал и не придрался.
Как там говорили либералы, если вас легко уволить, то легко и нанять :D
вот это точно, особенно это эпично смотрится на всяких корпоративных движняках, куда в т.ч. попадают оутстафферы.. "люди это самое важное, экспертиза это самое ценное в компании"...и хлоп увольняем половину департамента
Мы помнится пилили модуль который до нас писали другие оутстафферы и никто не знал из местных как и почему он работает..и нас также в конце сократили..крайне странное управление продуктом как по мне то...
в случае с аутстаффом я с ним согласен, так то, действительно главный их плюс в том что можно всех безболезненно сократить
другое дело что менеджмент зачастую не понимает где в данный момент находится ядро компетенций...и брать на аутстафф архитекторов это уже дурная затея..хотя очень лакомая...в стиле "зачем нам архитектор если мы глобальный релиз не делаем, а только поддерживаем текущий"?
он просто получает откат за "мертвые души".
лид откат получает? лид это менеджер низшего звена...какой он там откат может получать, он человек подневольный зачастую..максимум руководители департаментов могут такие махинации для управления бюджетом зарплатным делать и то все зависит от структуры компании
Немного юмора.
Когда встречаются человек с опытом и человек с деньгами - человек с опытом уходит с деньгами, а человек с деньгами уходит с опытом. )
Считаю важно учитывать контекст - квалификацию и обстоятельства Заказчика.
Если Заказчик не из ИТ отрасли и не имеет хорошего Продакта на своей стороне, то любой аутсорс окажется плохим. Не оправдает бизнес-ожидания.
Почему это может случиться? )
На начальном этапе не смогут собрать необходимые бизнес требования
ФТТ будет не полным и не точным. Из того вытекает неверное бюджетирование и сроки.
Аутсорс все сделает хорошо, но не то.
Предубеждения об IT-аутсорсе, с которыми пора покончить