Отличия и сходства в работе программистом в СНГ и Европе
Я проработал программистом в Казахстане 5 лет, пройдя за это время путь от Junior-программиста на почасовой ставке в уже не существующей платёжной системе, и заканчивая позицией ведущего программиста в Kaspi Bank — самом продвинутом банке страны.
В 2018 году я переехал в Ирландию, где попробовал себя в технологическом гиганте Microsoft. Мне не понравилось и спустя год я сменил работу, вернувшись в финтех — Stripe.
Сегодня я решил рассказать о всех самых важных организационных и социальных отличиях в работе программистом в СНГ и Европы — по крайней мере, по моему опыту. Учитывая мой опыт, это будет не очень справедливое сравнение работы в компаниях среднего размера в СНГ и работы в крупнейших мировых корпорациях в Европе.
Далее по тексту, “В СНГ” относится к моему опыту работы в небольших софтверных компаниях, финтехе и банках Казахстана. Скорее всего, это применимо к большинству компаний в пост-советских странах, кроме корпораций вроде Яндекс, ВКонтакте, EPAM.
Под “В Европе” я имею в виду работу в технологически продвинутых корпорациях — будь то в США, Европе, Японии, Новой Зеландии или любой другой стране.
Отличия
Software Engineer — не Developer
В СНГ: программист — это, в первую очередь, кодер. То есть, тот, кто большую часть своего рабочего дня пишет код. Возможно, еще настраивает окружение и сети, но это всегда техническая работа.
Когда же дело доходит до взаимодействия с другими людьми, аналитики, тестирования, принятия решений, то программистам редко приходится заниматься этим самим. Во многих компаниях есть заказчики, которые занимаются планированием; отделы аналитики, которые пишут технические задания для программистов; а также отделы тестирования, где тестировщики проверяют систему после написания кода. Таким образом, единственная обязанность разработчика — превращать строго сформулированные требования в код, а вокруг него бегает большое количество “вспомогательных” специалистов.
Программист может не общаться с другими людьми совсем или делать это по-минимуму. Обычно заказчики или начальники отдела общаются с менеджментом и другими командами, организуют порядок задач, выбирают исполнителей задач и несут ответственность за проекты.
Типичная задача в среднестатистическом банке Казахстана:
На главную страницу в верхнее меню добавить кнопку, которая будет отображать список с 25 последними платежами, вот тебе дизайн кнопки и текст.
Типичное решение:
Добавил кнопку согласно заданию, а тестировщики проверили, что всё на месте, и все забыли о задаче.
В Европе: программист — это инженер, полнофункциональный член команды. Его работа начинается с полного понимания стратегической миссии компании и целей команды, а заканчивается их достижением.
В большинстве крупных компаний нет отделов аналитики и тестирования, потому что инженеры должны быть способны самостоятельно выполнять всю работу, а также писать скрипты для автоматизации задач, писать техническую и проектную документацию. Таким образом, полнофункциональная команда разработки состоит только из инженеров и их менеджера.
Программист получает проекты и задачи, анализирует их, находит возможные решения, обсуждает их с командой и другими, принимает решения, реализует системы, тестирует и отвечает за них всё время после запуска. Очень часто приходится общаться не только с другими инженерами, но и с юристами, техническими писателями и переводчиками, специалистами по безопасности, пользователями.
Если информации для принятия решения недостаточно, то программист должен найти всех нужных специалистов, полноценно описать проблему и обсудить проблему. В конце концов, решение всё равно принимать самому, но обратная связь помогает убедиться в правильности решения.
Поэтому важно знать людей, знакомиться с другими командами, интересоваться их проектами и текущими заданиями, важно постоянно быть в курсе всего. Для этого есть огромное множество документации, но гораздо больше информации поступает из встреч или неформальных разговоров за кружкой кофе.
Типичная задача в технологическом гиганте Европы или США:
Пользователи нашего приложения испытывают сложности с загрузкой отчёта о сотрудниках в Excel, когда в компании работает больше 10000 сотрудников. Реши проблему.
Типичное решение:
Исследовал и воспроизвёл проблему, пообщался с пользователями. Сделал несколько запросов, узнал сколько людей бывает максимум в компании.
Провёл эксперименты — решить проблему простым способом не получится, потому что Excel не открывает такие большие файлы. Можно использовать другие технологии — SQL, Power BI, какие-то другие? Что будет удобно пользователю?
Исследовал рынок, снова пообщался с некоторыми пользователями, пообщался с командой.
Принял решение использовать SQL.Написал документ, описывающий предлагаемые изменения, цели и сроки проекта, представил команде, ответил всем на обратную связь. Написал код, написал тесты.
Написал документацию для функционала.
Провёл аудит на приватность и конфиденциальность данных (GDPR) с командой юристов.
Заказал и применил технический перевод для локализации.
Протестировал интерфейс на доступность людям с особыми потребностями.
Вместе с техническими писателями подготовил документацию для пользователей.
Опубликовал функционал и новость об обновлении.
Оценка личной производительности и карьерный рост зависят от того насколько эффективно и всесторонне программист подходит к решению проблем. Написанный код или новая функция никого не интересует, если это не помогает достичь тактических или стратегических целей.
Решения всегда принимают рядовые сотрудники
Из предыдущего пункта вытекает следующий очень важный пункт.
В СНГ: программист не принимает серьёзные решения и не несёт за них ответственность.
Серьёзные решения обычно принимаются начальником отдела или аналитиками, и в случае чего “попадать” тоже им. Ответственность программиста часто заканчивается там, где он сделал так, как ему сказали. Если решение очень серьёзное, например использование нового облачного провайдера, то оно выносится на еще более высокий уровень — какой-нибудь IT-комитет с участием высшего начальства. На таком комитете самое полезное, что может сделать рядовой программист — простыми словами объяснить что он хочет тем людям, которые принимают решения.
Это создаёт безопасную рабочую обстановку, но не мотивирует сотрудников принимать решения и добровольно брать ответственность. В результате это очень сильно ограничивает карьерный и личностный рост рядового сотрудника, поэтому ты очень быстро упираешься в потолок роста по пути разработчика.
Хочешь принимать решения — становись начальником.
Хочешь получать бонусы за успешные запуски — становись директором.
Стать начальником, затем директором, затем техническим директором — единственное естественное продолжение карьеры программиста. Мне это, например, никогда не нравилось, потому что я всегда хотел всю жизнь расти как инженер. Это была одна из причин, по которым я начал рассматривать работу за рубежом.
В Европе: рядовые сотрудники принимают все решения и личная ответственность является двигателем карьерного роста.
Для меня лично это было самое сложное изменение в работе.
У каждой задачи и у каждого проекта есть Directly Responsible Individual (DRI) — непосредственное ответственное лицо, и оно всегда одно. В начале своей карьеры, сотрудники обычно не получают DRI ни на одном проекте, а просто работают над проектами других людей. С карьерным ростом все специалисты разных направлений получают себе в ответственность более серьезные задачи, а затем и проекты.
Если ты получил такой проект, то только ты решаешь как он будет выполнен. Ты можешь просто сделать всё как считаешь нужным. Можешь посоветоваться с другими людьми и сделать как они говорят. Ты можешь даже не делать проект, а просто найти других людей, заинтересовать и убедить их взяться за это, организовать процесс и довести дело до успешного завершения. Это будет хорошая запись в резюме на позицию Engineering Manager (начальник отдела разработки), если появится такое желание.
Окончательное решение всё равно принимать тебе и отвечать за него тебе. Задача только одна — добиться поставленной цели. Если проект заимеет успех, то это будет твой успех. Если что-то пойдёт не так, то это будет только твоя вина.
Задачи поднимаются снизу, а не спускаются сверху
Мало того, что рядовые сотрудники решают как они делают работу.
Зачастую они решают что за работу они делают.
В СНГ: задачи спускаются с самого верха вниз. На каждом уровне иерархии начальство придумывает задачи и следит за качеством их исполнения, потому что им отвечать за результат.
Программисты обычно никогда не придумывают себе глобальные задачи. Конечно, они очень любят придумывать себе интересные задачки вроде “перейти на новую систему контроля версий”, но если начальство пришло с новыми срочными требованиями, то они не подлежат обсуждению и все другие задачи отодвигаются на задний план.
Например, вполне типичный кейс в казахстанской компании:
Топ-менеджмент банка решил, что банку нужен свой интернет-банкинг. Задача поставлена техническому директору.
Технический директор продумывает план и сроки работ, организовывает инфраструктуру, лицензии, оборудование и ставит задачи на начальника отдела разработки.
Начальник отдела разработки продумывает архитектуру, принимает решения по использованию программного обеспечения и раздаёт задачи подчинённым.
Отдел аналитики или продуктовые менеджеры пишут технические задания и, в конце концов, до программиста доходит задача вроде “добавить кнопку в меню”.
На каждом уровне люди отвечают за сроки проекта и защищают свои результаты перед своим начальством. Если топ-менеджмент внезапно решит сменить направление, то вся эта работа будет отменена.
В Европе: начальство ставит цели, но многие задачи придумываются рядовыми сотрудниками и поднимаются вверх.
И так происходит на каждом уровне и во всех сферах, не только в программировании:
- У высшего менеджмента есть видение будущего компании (vision), которое соответствует миссии компании. Они устанавливают и доносят стратегические (долгосрочные) цели — на год, на 5 лет
- Мид-менеджмент преобразует стратегические цели в тактические (краткосрочные) цели и доносит их до своих подразделений
- Начальники отделов доносят цели до сотрудников и помогают им организовать работу по достижению этих целей
- Рядовые сотрудники придумывают решения для достижения целей своей команды
- Начальники отделов доносят эти решения до мид-менеджмент в виде планов, а затем отчётов, и так далее вверх до самого верха
Хороший менеджмент не принимает никакие локальные решения, они только ставят чёткие и правильные цели.
Хорошие сотрудники не спрашивают что им делать, они сами знают что им делать для достижения этих целей.
Если команда не достигает установленных целей, то эту проблему будут решать, возможно путём замены команды. Но здесь есть очень большая разница — менеджмент не может сказать какую работу делать рядовым сотрудникам и не может сказать как её делать. Они не следят за исполнением работы, они следят за достижением целей.
К примеру, вполне реальный кейс в крупной компании по разработке ПО в США:
Высший менеджмент компании считает, что у компании вполне хорошая ситуацией на рынке, поэтому стратегически важной задачей на этот год является увеличение прибыли за счёт уменьшения операционных расходов на 10%.
Технический директор решил, что технические подразделения могут уменьшить расходы на содержание программного обеспечения. Команде IT-инфраструктуры поставили задачу на этот год: нужно уменьшить расходы на содержание ПО на 20%.Команда инфраструктуры села обсуждать возможные решения. Один из разработчиков предложил перейти с MSSQL и получил это в качестве задачи на текущее полугодие. Начальник отдела пишет в планах на 2020 год “Программисты такие-то будут в 2020 году мигрировать нашу базу данных с MSSQL для уменьшения расходов на лицензии”.
После анализа проблемы и поиска всех возможных решений, программист решил, что самым верным первым шагом будет перейти с SQL Server на PostgreSQL. Он описал и разослал всем проектную документацию для этого проекта, чтобы услышать мнение других членов команды и собрать несколько других заинтересованных людей на проект.
Через год команда опубликует отчёт о том, что они сэкономили X миллионов долларов, перейдя на новую базу данных, чем повысили финансовую эффективность компании.
Если в следующем году высший менеджмент посчитает, что для успеха компании нужно срочно расширить штат сотрудников, улучшить пользовательский опыт или разработать новый продукт — все команды переключатся на эти цели и будут думать, как их достичь.
При таком подходе важную роль в успехе проектов играют два важнейших фактора:
- Наличие четких и измеримых целей на каждом уровне иерархии. Например, делая определённую задачу, я часто принимаю решения на основе текущих целей, операционных принципов компании или её миссии
- Квалификация и мотивация всех сотрудников на всех уровнях иерархии
Ошибки — это хорошо
Свобода выбора и принятия решений не имела бы никакого смысла, если бы людей за ошибки наказывали.
В СНГ: ошибки считаются результатом некомпетентности или халатности. Хороший сотрудник — это тот, кто не допускает ошибки.
В случае серьёзных ошибок все ищут ответы на разные вопросы, один из которых “кто виноват”. Кто-то должен быть наказан ну или хотя бы публично признан “крайним”. Результат такого подхода очень неприятный — многие люди боятся ошибок, избегают риска, а случае чего пытаются скрыть свои оплошности.
В Европе: ошибки считаются неотъемлемой частью рабочего процесса и обязательной частью обучения. Если человек не делает ошибки — значит он ничего не делает. Хороший сотрудник должен допускать ошибки, но в рамках процессов, позволяющих устранить последствия и закрепить эти знания.
В случае ошибок все силы направляются на то, чтобы устранить последствия проблемы. Затем, находятся причины решения и делаются выводы, которые превращаются в задачи. Никто не наказывается. Чаще всего, никто даже не пытается выяснить кто виноват.
Если человек постоянно натыкается на новые проблемы, то, скорее всего, он делает то, что никто до этого раньше не делал. Он поделится своим опытом с другими, чтобы другие люди владели необходимой информацией, чтобы избежать этих проблем в будущем.
Этот подход создаёт атмосферу взаимодоверия и свободы принятия решений, которая благотворно сказывается на креативности, личном росте и развитии социальных навыков.
“Ошибки — это хорошо” является одной из основополагающих идей Growth Mindset (образ мышления на рост), в противовес Fixed Minset (фиксированный образ мышления). Помимо ошибок Growth Mindset поощряет конструктивные конфликты, конструктивную обратную связь \ критику, желание постоянно учиться и развиваться, открытость к новым людям и возможностям.
Согласно многим современным теориям, именно этот Growth Mindset отличает хороших потенциальных сотрудников от плохих, поэтому если вы планируете проходить интервью или работать в Европе, то стоит развивать в себе этот склад ума.
Engineering Manager — не начальник отдела
После предыдущих пунктов может появиться вопрос— а зачем тогда нужен начальник отдела разработки, если он не придумывает задачи, не принимает решения и не несёт за них ответственность.
Ответ простой — в западных компаниях нет начальника отдела разработки, есть Engineering Manager (далее просто “менеджер”). Его роль ощутимо отличается от роли начальника.
Задача менеджера — обеспечивать эффективное функционирование команды, каждого отдельного сотрудника и проекта.
Он решает личные, организационные и карьерные вопросы вроде:
- “В последнее время я слишком много работаю над front-end разработкой и мне надоело, хочу попробовать себя в back-end разработке. Поможешь найти мне проект?”
- “Я застрял на своём уровне, хочу стать старшим разработчиком, что мне нужно сделать для этого?”
- “Мне не комфортно работать с человеком (имя) над одним проектом, потому что (причина). Давай искать решение”
- Оформление документов, организация рабочего места, решение конфликтов, тимбилдинги и прочее
- Во многих компаниях каждую неделю у каждого сотрудника есть встречи 1 на 1 с менеджером, где можно просто поговорить по душам или высказать свои переживания или идеи
Engineering Manager занимается управлением командой, проектов и процессов, но не участвует в самих проектах. Он не занимается разработкой (хотя зачастую может) и, что самое главное, он не принимает на своём уровне технические решения. Он очень опытен, с ним всегда можно обсудить любой технический вопрос, он всегда рад подсказать что-то, но всегда заканчивает свои предложения словами “но решение в любом случае принимать тебе”.
Самое важное организационное отличие состоит в том, что специалист (Individual Contributor) и менеджер (Manager) — это две независимые карьерные лестницы. То есть, переход на позицию менеджера — это не обязательно повышение. Можно всю жизнь быть программистом и расти по карьерной лестнице. В то же время, если вам нравится организовывать процессы и управлять людьми, то с какого-то момента в карьере можно начать карьеру менеджера.
Менеджмент, а не микроменеджмент
Раз уж каждый делает что хочет и как хочет, то и процесс работы каждый организует по своему усмотрению.
В СНГ: процессы строятся на подчинении. Начальство строго следит за сотрудниками— вовремя приходить на работу, тратить 1 час на обед, не смотреть фильмы на работе, не спать на работе, и так далее.
Например, нередко можно услышать, что на работе в Казахстане ограничивают доступ к развлекательным интернет-ресурсам или социальным сетям.
Когда я работал в одном банке в Казахстане, представитель кадрового отдела иногда стояла на входе и записывала время прихода в журнал под роспись, а также делала замечания по поводу стиля одежды — ну детский сад же :)
Бездельничая на работе в СНГ, ты чаще всего нарушаешь правила внутреннего распорядка и получишь выговор. Если в команде и разрешено опаздывать и ходить в халате и тапочках по офису, то разрешено начальством.
В Европе: процессы строятся на личной мотивации и ответственности. Команды организуют свои внутренние процессы, распорядок дня, правила работы по своему усмотрению, чтобы сделать процесс максимально эффективным для всех.
Обычно во всех командах свободный график и достаточно простые правила:
- быть в офисе, хотя бы с 10–11 утра до 4 дня
- посещать обязательные встречи, хотя бы через видеосвязь
- предупреждать за день, если планируешь в этот день отсутствовать или работать из дома
Ты приходишь когда хочешь, делаешь что хочешь и уходишь когда хочешь. Если ты чувствуешь себя плохо или у тебя есть дела, то ты просто не приходишь на работу или работаешь из дома. Работать из дома, кстати, вообще стандартная практика — многие делают это каждую неделю, например в пятницу. Если приболел ребёнок, то можно неделю-две посидеть с ним дома.
Захотел поиграть в рабочее время теннис или бильярд — вперёд.
Решил сесть на диван, чтобы посмотреть YouTube с бокалом вина в руках в столовой — без проблем.
Бездельничая на работе, ты не нарушаешь никакие правила. Делая это периодически, ты подводишь команду и замедляешь карьерный рост.
Если все задачи эффективно выполняются в срок и всех в команде всё устраивает, то организационные детали не играют никакой роли.
При этом на практике все работают эффективнее и усерднее, чем по моему опыту в Казахстане, потому что цель и личная мотивация работают лучше, чем камеры наблюдения и начальник за дверью.
На этом основные отличия в работе заканчиваются. Естественно, что это всё очень сильно зависит от страны, компании и команды, в которой вы работаете, но по моему опыту именно эти отличия максимально сказались на моих рабочих процессах за последние годы.
Сходства
Есть несколько интересных моментов по поводу того, в чем работа в западных корпорациях и казахстанских компаниях не отличается.
Технический уровень и процессы в команде
Когда ты живёшь в Казахстане, тебе всегда кажется, что программист в Google в США — это какой-то сверхразум, который может писать гениальный код одной силой мысли и знает всё.
На практике уровень технической подготовки программистов не сильно отличается от казахстанских компаний. Это такие же люди, использующие те же языки программирования, те же технологии, те же “костыли” в коде и делающие такие же ошибки. В крупных компаниях есть процессы, позволяющие программистам предотвращать проблемы с кодом на раннем этапе, а также работать эффективнее, но сами люди ничем не отличаются.
Нет ничего сверхъестественного в работе в Microsoft, Amazon, Google. Зачастую работа даже проще в техническом плане, потому что есть намного больше ресурсов (в том числе программистов), лучше документация и все процессы внутри компании.
Процессы внутри команд и объем работ тоже особо не отличается. Размер компании тоже никак не сказывается на работе. Просто в казахстанском банке есть 5 команд разработки по 5–15 человек, а в Microsoft несколько тысяч команд по 5–15 человек. Я не знаю все эти команды, максимум 2–4. Для меня в техническом плане работа не меняется, учитывая, что большую часть времени я работаю над небольшим проектом и общаюсь только со своей командой.
Эта статья описывает отличия в работе с социальной точки зрения, так что я еще вернусь к теме технических отличий. Я напишу отдельный пост про отличия в процессах команды разработки, который может послужить неплохой инструкцией по улучшению процессов для казахстанских компаний.
“Связи”
В Казахстане принято считать, что “на Западе” легче найти работу и работать, потому что не нужно знать людей или иметь “связи”. На самом деле, это здесь намного важнее, только называется это покрасивее — нетворкинг (от англ. networking).
Концепция нетворкинга заключается в том, что тебе нужно строить вокруг себя сеть (англ. network) профессионалов, интересных людей, проектов, компаний, идей. Быть в курсе происходящего, делиться знаниями и идеями с другими, учиться новому и знакомиться с новыми людьми. В общем, быть активным участником профессионального сообщества.
Например, если вы живёте в Европе и ищете работу, то самый надёжный способ её найти — ходить по техническим сходкам, конференциям, знакомиться с людьми, обмениваться контактами. Никто не хочет брать незнакомцев в компанию, так что верный способ попасть в хорошую компанию — получить реферрал (рекомендацию) от действующего сотрудника. А для этого нужно знать людей.
Другой пример — даже когда ты уже работаешь, важно окружать себя правильными людьми. Все интересные проекты, задачи, повышения, бонусы, конференции, командировки и карьерный рост пройдут мимо, если ты сидишь себе тихо в углу и просто не интересуешься тем что происходит вокруг.
В конце концов, даже если забыть про профессиональный аспект, европейцы и американцы — такие же люди. Когда команде понадобится отправить кого-нибудь на конференцию — менеджер вспомнит человека, который каждый день ходит с ним пить кофе и рассказывает интересные технологические новости просто потому, что он первым придёт в голову. Так что здоровые и профессиональные “связи” — это нормально, так работает социальное общество, эволюционно поощряющее активных и общительных.
В целом, я считаю, что западный подход к работе программиста позволяет намного больше раскрыть возможности и таланты сотрудников. Он взращивает ответственных, общительных, открытых людей, которые могут эффективно работать в команде для достижения любых целей. Люди могут сами организоваться в команду, сами разрешить внутренние конфликты и сами принимать решения. Им не нужна постоянная опека или контроль. Это разгружает менеджмент, позволяя им сфокусироваться на более глобальных целях и оптимизации процессов.
Казахстанских программистов, в каком-то плане, можно назвать ленивыми и разбалованными. Они не любят вникать в проблемы, они не любят вникать в особенности бизнеса и будут делать работу согласно техническому заданию, “как попросили”. Им, скорее всего, даже не особо интересна компания, в которой они работают, им просто нравится программировать и хорошо платят. По крайней мере, так звучала мотивация большинства программистов, с которыми я общался в Казахстане.
У всех IT-шников в Казахстане очень часто репутация людей, которые общаются только друг с другом; и которых никто не понимает, когда они говорят, поэтому с ними можно общаться только через начальников отделов или других связующих людей.
Я тоже никогда не общался с другими людьми, потому что мне тоже не очень было интересно что происходит в компании. После переезда моё отношение сильно изменилось. Например, сейчас я могу позвать на обед сотрудника рискового отдела, потому что я хочу пообщаться и вникнуть в текущие планы их команды, и учесть это при планировании своих задач на следующий год. Или я могу участвовать в обсуждениях инцидентов других команд, потому что я могу перенять какой-то опыт. Я точно никогда не занимался бы этим в Казахстане.
С другой стороны, наши программисты славятся хорошими техническими знаниями и скоростью работы, на голову опережая европейских коллег именно потому, что большую часть своего рабочего времени они проводят за чистым инжинирингом.
Из наших программистов вырастают хорошие кодеры и сильнейшие алгоритмисты, но даже если они уже много лет живут в Европе, бросается в глаза недостаток soft skills (социальных навыков):
- коммуникации (и дело не в языковом барьере), позитивное мышление и открытость в общении
- принятие решений и ответственность
- нетворкинг
- управление своими знаниями и временем, ведение заметок и документации, управление проектами
- креативность, и так далее
Стоит отметить, что большинство людей из СНГ, проходящих интервью в западные корпорации, валят интервью именно на soft skills, даже если они блестяще проходят технические интервью. Многие люди фокусируются только на технических знаниях при подготовке и прохождении интервью и не догадываются, что технические знания — не самый главный объект исследования.
Я написал продолжение этой статьи, которое рассказывает отличия в процессе в СНГ и Европе, а также подскажет, на что обратить внимание при подготовке:
Для меня адаптация в европейские компании прошла тяжелее, чем я ожидал. Первые полгода я просидел практически без работы, потому что ждал пока менеджер даст мне задачи. Как выяснилось, инициатива должна была быть с моей стороны. Не просишь задачи – значит либо хватает работы, либо пока не готов.
Но самой сложной частью для меня было то, что я практически перестал писать код.
В Казахстане чистая разработка занимала 80–90% моего эффективного рабочего времени. В Ирландии бывает, что я могу две-три недели вообще не программировать, потому что в это время занят другой важной работой. Я очень люблю программирование, поэтому каждый день без кодинга нагонял на меня тоску. Все программисты в какой-то мере художники, которые хотят творить и рисовать красивые картины.
К тому же мне казалось, что если я не пишу код – значит я не работаю.
Только спустя год я чувствую, что привык и уверенно понимаю все аспекты, которые включает в себя работа разработчиком.
Надеюсь, что эта статья поможет другим людям раскрыть эти важные моменты заранее.
Спасибо за то, что дочитали до конца :)
Лирическое отступление:
Сугубо субъективное мнение-размышление на отвлечённую тему.
Основные моменты, которые я пытался описать:
- автократичная организационная иерархия
- коммуникационные барьеры и дефицит soft skills
- личная инициатива и конфликты не приветствуются, поэтому ответственность избегается
Они все никак не связаны с профессией программистов, просто специфика работы с неодушевлёнными предметами ярче это подчеркивает.
По-моему, эти подходы и проблемы, в принципе, типичны для людей из СНГ. И проблема не в людях, а в системе социальных отношений, а также в общем подходе к организации власти и управления. Эти подходы и вытекающие из них проблемы можно увидеть и в политическом устройстве наших стран, и в работе, и в быту, и в школе, и в университете.
В Европе или США очень редко можно встретить замкнутых или необщительных людей, потому что навыки общения культивируются с раннего детства. Детей учат строить отношения с другими и поддерживать других, быть ответственными. Люди гораздо более открытые, проще подходят к незнакомцам, заводят знакомства и легко внедряются в любые социальные группы, гораздо легче находят и принимают решения. В школе и университете большую часть внимания уделяют развитию социальных и образовательных навыков, а не самих знаний. Именно поэтому здесь сформировались такие социализированные подходы к работе.
У нас же не учат отстаивать свою позицию, принимать креативные и необычные решения ни в школе, ни в университете, зачастую даже подавляя эти социальные навыки. Затем в начале карьеры людям не дают развить эти навыки, потому что они попадают в среду, где им не доверяют серьёзную работу, а просто дают поручения. Все знают, что инициатива не очень хорошо расправляется с инициатором, так что работники просто перестают её проявлять. Со временем они привыкают, что все решения принимаются откуда-то сверху, даже если с ними кто-то не согласен, так что они просто ждут пока им скажут что делать. Попытки оспаривать решения обычно тоже не заканчиваются успехом, поэтому люди просто делают что им скажут, не задумываясь и не интересуясь оригинальными причинами и целями.
Подчинение и авторитарный контроль порождает безынициативных сотрудников, а безынициативные сотрудники вынуждают внедрять систему подчинения и контроль.
Конечно, это касается далеко не всех людей, это моё личное мнение и я вполне могу ошибаться, но это та общая тенденция, которую я вижу спустя год работы и общения с европейцами и американцами.
Не забудьте прочитать статью про отличия в процессе интервью, ссылка чуть ниже :)
Ссылки
- Добро пожаловать
Оглавление по всем статьям в этом блоге - Отличия в процессе интервью в СНГ и Европе
