Случайные ответы на вопросы о работе в Австралии. Часть 1/x :IT Consultancy.

КДПВ от amalavida.tv под CC BY-SA 2.0

В последнее время я заметил, что разные люди мне задают очень похожие друг на друга вопросы на тему работы и жизни в Австралии. Что занятно — я никогда не позиционировал себя как эксперт в этом вопросе и мои ответы всегда опираются на мой индивидуальный опыт. У вас этот опыт будет точно другим, как тут любят говорить — YMMV = your mileage may vary.

Ладно с disclaimer’ом расправился, теперь зачем все это ? Во-первых, хочется структурировать эту область для себя самого и для тех кто задает вопросы, чтобы существовал пост, с которого можно начинать разговор, а не рассказывать одни и те же тезисы с чистого листа. Во-вторых, это очередная попытка начать писать, прежде всего — для себя. Потому что слишком много невысказанных мыслей приводят к тому, что я начинаю пространно рассказывать полу-философские истории собеседникам, вместо того чтобы добираться до сути и давать конкретный ответ на поставленный вопрос. Ну и как всегда — всех влечет слава мирская поэтому лайки, шеры и умные комментарии всегда приветствуются (последние особенно).


Для начала, что такое IT Consultancy в Австралии. До приезда сюда у меня было довольно предвзятое мнение на тему консультантов — что это, в общем, бездари в костюмах, продающие “презентации в поверпоинте”. Если описывать одним предложением — “Тот, кто не умеет работать руками и идет продавать фуфло”. Откуда такое мнение возникло — точно не знаю, да это и не важно. Из общения я не раз видел что похожее мнение на тему консультантов имеют и многие друзья в России. Мое мнение довольно сильно изменилось когда я сам начал работать в IT Consultancy.

Во-первых, IT консультанты тут — это программисты и админы, которые создают вполне конкретные продукты и решения, под нужды клиента, но они сами не состоят в штате компании-заказчика. 
Если быть очень циничным, то можно сказать Consultancy — это такой software body shop, с одним существенным отличием — мы привыкли считать, что бади шопы это потогонка с тоннами неквалифицированных быдлокодеров. Тут все наоборот — это довольно премиумный и профессиональный бодишоп.
Во-вторых, многие ваши коллеги имеют вполне приличные навыки не только программиста, но и обширный набор софт-скиллс, потому что на каждом проекте приходится лично общаться с заказчиками или как минимум участвовать в обсуждениях и презентациях работы клиенту (обычно каждые 2 недели, в конце Agile спринта). Всегда есть кто-то, у кого можно спросить и поучиться навыкам которых вам самим не хватает.
В-третьих, каждый может найти свой формат работы — кто-то фанат длиных проектов на 1–2 года, кто-то предпочитает 3–6–9 месячный проект и старается перейти на другой проект, попробовать новые технологии или новую область деятельности. Кто-то очень крут и может вести 2–3 проекта параллельно, участвуя в стратегических совещаниях и презентуя архитектуру. В общем, как говорится — скучно вам не будет.


Всех сотрудников IT consultancy можно условно разделить на 3 категории:

  • Исполнители — непосредственно программисты и сисадмины. Движущиеся части большого механизма компании и те, чью ежедневную работу клиенты оплачивают компании.
  • Сейлзы — те кто обладает сетью контактов и навыками ведения продаж: от первой фразы клиента за кофе а-ля “Вот у нас тут есть проблема, которую мы хотим решить” до полного согласования сроков и объема работ, выделения бюджета и исполнителей и подписания договора с клиентом. Основная задача — создавать условия для того чтобы клиенты подписывали жирные контракты, уходили довольные и приходили с другими проектами. Им платит компания в том числе проценты от заключенных контрактов, и они основная сила по смазыванию шестеренок всей компании кэшем.
  • Внутренние сотрудники — менеджмент, HR, юристы и подобные товарищи. Напрямую деньги компании они не приносят, но участвуют в организационной деятельности компании, планировании времени программистов на проектах, карьерном развитии всех сотрудников и т.д.

Работая в консалтанси, вы начнете понимать несколько ключевых принципов функционирования такой компании:

  1. Пока за время исполнителя платит клиент — все отлично и все счастливы. Это то, как компания зарабатывает деньги. Пофантазируем с цифрами — стоимость одного дня работы обычного консультанта обходится клиенту в $1500, из них на зарплату этому консультанту уходит грубо говоря $500 (налоги там, то се). Остальное — это оплата остальных двух категорий, всякие представительские расходы и “денежная подушка безопасности” в банке. Следствие: если консультант сидит без контракта — это общий факап. Это значит что его зарплата будет идти из кармана компании. Т.е. уменьшать подушку для всех.
  2. Если клиент доволен работой по проекту — он прийдет к компании еще раз. Обычно в контракты по проектам заложен и гарантийный период, в течении которого консультанты исправляют баги бесплатно. Так что делать продукты откровенно низкого качества чтобы клиент прибежал еще раз к вам — нет смысла. Это и подстава для ваших коллег и ухудшающаяся репутация, как ваша так и компании (а тут профессиональная репутация это довольно ценный и полезный ресурс). К тому же, клиент может найти кого-то со стороны, чтобы исправить ваши косяки и тогда следующий контракт с этим клиентом ваша компания вряд ли получит. Что на небольшом австралийском рынке может быть очень чувствительно. Следствие: Если клиент хочет чтобы вы все прыгали — все прыгают (или делают “плохую архитектуру”). Вы можете не любить, не хотеть и быть против, но в конце концов — если ваши действия или мнения приводят к тому что клиент недоволен — это факап, в этот раз уже ваш. Лучшее что можно сделать в такой ситуации — попытаться аккуратно объяснить это клиенту, если он сильно не прав и вы видите проблему его подхода. Не помогло — расскажите об этом своему сейлзу или principal consultant — пусть он попробует донести проблему своим авторитетом. Если все равно не помогло (что странно — вас наняли чтобы вы сделали хорошо и вашей экспертизе доверяют) — делайте как сказал клиент. Потом можете попроситься с этого проекта на другой, но пока вы там — клиент прав, даже если вы с этим не согласны.
  3. Agile everywhere — все стараются работать по Agile или agile-ish, где-то потому что это трендовый хайп, где-то потому что это действительно наиболее удобный формат работы по таким проектам: результат всегда видимый, если внезапно деньги кончились раньше чем работа — есть хоть какой-то рабочий output. Клиент чувствует результат и вовлеченность т.к. каждые две недели ему демонстрируют улучшенный результат. Следствие: для эффективности такой работы хорошо чтобы команда сидела вместе, часто — у клиента в офисе (консультантов могут позволить себе обычно средние и крупные компании, которые и место в офисе выделят и компы предоставят), или хотя бы в офисе самой компании, чтобы команда могла свободно и удобно общаться. Иногда это вырождается в бессмысленные agile-ритуалы, но все равно ежедневно есть возможность рассказать о некоторой проблеме или предложить нововведение.
  4. Communication and team are the kings — это скорее второе следствие из предыдущего пункта, достойное отдельного параграфа. Коммуникации и командная игра важнее чем ваша собственная “семипядность во лбу”. Команда должна быть согласована внутри и не выносить разборки перед клиентом, нужно уступать и уметь уточнять — не стесняться спросить если вам что-то не понятно и не раздражаться когда вас тиммейты спрашивают по 5 раз одно и то же — что-то очевидное для вас для них совсем не очевидно и наоборот. Следствия: в команде лучше играют “средние и стабильные” игроки чем “капризные рок-звезды 10х программирования” которые будут собачиться из-за каждого архитектурного паттерна. А также — много удаленки и работы из дома особо не получится. Все же, несмотря на достижения в современных коммуникациях, разговор за кофе или перед whiteboard во много раз эффективнее чем слак скайп и почта.

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

Ответ на вопрос “Стоит или не стоит” для меня довольно однозначный — стоит попробовать хотя бы раз. Это позволит вам понять все за и против такого формата работы, обзавестись большой сетью контактов (как коллег с проекта так и клиентов), поучаствовать в множестве разных проектов и очень широко расширить горизонтальную планку в вашей профессиональной T-shaped экспертизе. К тому же работа в таком формате неплохо правит извилины и отношение к тому, что создаете — уходит излишний перфекционизм и фанатизм вокруг кода и начинаете понимать ценность таких свойств проекта как предсказуемость и читаемость кода, своевременность выпуска фич и “good enough” качество.

Если что-то хочется добавить к этому списку — комментарии открыты и конструктивные дополнения приветствуются.