Вы не суеверный? Тогда хватит верить в мифы вокруг IT-аутсорсинга! Эти легенды рождаются стараниями адептов профессии и их заказчиков. Мешают объективно оценивать качество, сроки, стоимость и квалификацию. Разрушаем 7 мифов вокруг аутсорс-разработки вместе с Александром Боричевским, сооснователем компании Sonetico и резидентом коворкинга Imaguru.

Миф 1: Разработка на аутсорс – обезьянья работа. Это самое неинтересное, за что не хочет браться сам заказчик.

Что такое обезьянья работа? Ни в коем случае нельзя считать ею решение технических задач. Есть очень хорошие разработчики, которые не хотят вникать в бизнес-процессы, но отлично решают сложные технические проблемы.

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

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

На собеседованиях я всё реже задаю людям технические вопросы – портфолио говорит само за себя. Но я стараюсь понять, что это за человек, как он будет думать и работать в критичной ситуации. На Западе один из критериев оценки HR’ом соискателя на интервью – хотел ли бы я выпить с этим человеком пива? Могу ли я положиться на него? Именно таких – инициативных и надёжных разработчиков ищут под свои проекты наши клиенты.

Миф 2. Сегодня ты аутсорс-разработчик, и через 10 лет ты – аутсорс-разработчик. Никакого роста.

Рост из рядового IT-разработчика возможен. В сторону контрактника или технического консультанта. На месте того, кому нравится решать технические задачи, но при этом не копаться в рутине, я бы искал компании, в которых требуется глубокая технологическая экспертиза. Зачастую это продуктовые компании или стартапы. В таких структурах идёт борьба за оптимизацию всего, что можно измерить – от метрик качества кода до скорости загрузки стартовой страницы сайта.

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

А вообще, на профессиональный рост влияют не только технические компетенции программиста. Если он приходит в солидную компанию в шортах и грязной майке, ни о каких перспективных контрактах речи быть не может. Даже разработчиков от Бога встречают по одёжке.

Росту мешает и то, что часто даже классные специалисты не умеют себя продавать. В одной книге о правильном составлении резюме для американского рынка я прочитал «В школе вас учат тому, что не нужно хвастаться своими умениями. Если вы хотите, чтобы ваша мама всегда стирала ваше нижнее бельё, продолжайте думать так дальше».

Миф 3. Нужно быть очень крутым программистом, уровня Senior, чтобы тебе доверили работу на американского заказчика.

О, это один из самых распространённых мифов. Да, есть проекты, для решения которых нужно обладать особыми навыками, умением генерировать и реализовывать нестандартные решения. Но таких не больше 10% от общего количества.

В большинстве случаев заказчик ищет разработчиков уровня «good enough» («достаточно хорошо»), которые просто могут качественно выполнять стандартные задачи. Это может быть работа с движком сайта, кодом или юзабилити страниц. Простые задачи, которые нужно хорошо решать.

Не нужно бояться, что ваших компетенций недостаточно. С другой стороны, углубляться только в технические знания тоже неправильно. Разработчикам чаще нужно прокачивать уровень английского языка и то, что называется soft skills. В принципе, и без знания английского языка программист сможет заработать деньги на русскоязычном рынке. Но при этом ему придётся мириться с определёнными аспектами ментальности этого рынка.

Ментальность русскоязычного рынка хорошо иллюстрируется в анекдоте:

– Я не специалист. Вот вам деньги, скажите мне, как нужно делать.

– Нужно вот так.

– Я не согласен.

Аутсорс-компания или фрилансер, позиционируя себя как супер-мега-специалиста, этим только отпугивает заказчика. Такое позиционирование часто (и порой небезосновательно) воспринимается клиентами, как желание «срубить» лёгких денег.

Миф 4. Мне нужно максимально подробное ТЗ, и тогда я буду работать. Инициатива? Креатив? Варианты? Я пишу код.

Если вы хронически не хотите проявлять инициативу, ваша участь – обезьянья работа. Есть масса задач, которые требуют серьёзного технического бэкграунда, и никакая инициатива не поможет их решить, но речь не о них.

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

Это важно. Например, шведские заказчики в хорошем смысле более доверчивые. Они не будут думать, что ты пытаешься их обмануть, называя сроки и этапы работы. Но они попросят объяснить, из чего складывается твоя работа. Как правило, они соглашаются, потому что пришли к вам, как к эксперту. Такой подход снимает проблему овертаймов.

Миф 5. Работа стоит ровно столько, сколько я, заказчик, готов за неё заплатить. При этом немного.

На каждого заказчика свой разработчик. Заказывая самое дешёвое, торгуясь за копейки, заказчик получит соответствующий продукт. И так ведь всюду, не только в IT.

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

Изучите рынок и соответствуйте средней цене. Излишний демпинг – это аргумент для хороших заказчиков в пользу того, чтобы не работать с вами. Низкая цена отпугнёт тех, кто априори готов платить много.

Миф 6. 100500 правок – это нормально. Я плачу деньги – я правлю всё и всем.

Правки тесно связаны с подходом к оценке проектов: time&material и fixed price. Второй подход многие заслуженно не любят, с ним чаще соглашаются дешёвые разработчики. Если с ним приходится работать серьёзной компании, то она должна быть на 100% уверена, что получит прибыль с этого проекта, а условия договора не поменяются. При работе с адекватным заказчиком речи о fixed price, как правило, не идёт. Иногда простая работа с небольшими рисками допускает fixed price, но стоит обозначать, что это временно, а после – time&material.

Если заказчик не знает, чего хочет, но при этом адекватен, и платит за работу (даже если новые действия противоречат старым), то почему нет?

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

Миф 7. Мы пока не знаем, чего хотим – нам что-то нужно. Предложите нам 5 вариантов прототипов. А лучше 8. Потом попросим ещё.

Специалисты со стороны заказчика и исполнителя проводят серии встреч, на которых заказчик рассказывает о своей проблеме, а разработчики предлагают варианты её решения. Так стороны понимают, что им нужно сделать.

Редко, но бывают крайности, когда заказчик выставляет абсолютно нереальные требования, либо вообще не может определиться, чего хочет. Как в ролике про 7 красных перпендикулярных линий. В таком случае за заказ стоит браться, если команда очень хочет заработать денег. Обязательно подписывать договор на условиях time&material и стараться обозначать максимально конкретные задачи. Чем закончится такой проект часто неизвестно – этакий код Шрёдингера.