Если вы уже успели немного поруководить программистами, будучи менеджером, тим- или техлидом небольшой команды или даже директором компании по разработке ПО, то наверняка знаете, что это не такое уж простое дело. Почему непростое? Причин много.
Во-первых, менеджерами программистов часто становятся бывшие программисты. А руководить людьми — это совсем не то же самое, что управляться с компиляторами, дебаггерами и профиляторами. Если вы ловко применяли в работе шаблоны проектирования, то нет никакой гарантии, что ваши сотрудники сразу же станут продуктивной командой.
Во-вторых, во многих книжках по менеджменту даются модели сферического менеджера в вакууме. Вообще, большинство книг — про методологии, управление задачами, рисками, изменениями и чем угодно, но не людьми. А жизнь ведь гораздо красочней. Что делать, если ваш ведущий разработчик приходит к вам с просьбой поднять зарплату, аргументируя тем, что иначе он уйдет к конкурентам? Как быть к этому готовым и как это все предвидеть и предотвращать?
В-третьих, те материалы, которые есть про управление людьми, они часто не ориентированы именно на программистов. А это очень, очень необычные люди. Технические и творческие одновременно.
Наконец, вы вдруг обнаруживаете, что кроме ваших сотрудников есть еще ваш начальник и коллеги-менеджеры. Со своими амбициями, желаниями и пониманием, что такое хорошо и что такое плохо. Как с этим жить — тоже пока не очень понятно. А в книжках про это тоже не очень-то много и пишут…
Все это накладывается одно на другое и получается вот как. На работе случаются продвижения и сокращения. Первые обходят вас стороной, а вторые, наоборот, незаметно подкрадываются сзади. Как выжить в такой нервной обстановке?
Поскольку я руководил программистами достаточно долго, а последние 12 лет учу других это делать и, по отзывам окружающих людей, небезуспешно, то я решил написать небольшой гайд выживания для менеджеров программистов. Это мой опыт, а также опыт многих успешных менеджеров, с которыми мне посчастливилось встретиться и поработать, и у которых я многому научился.
Курс составлен достаточно прозрачно. Он весь про людей. Будем говорить про вещи, на которые стоит обращать внимание. А также про самые распространенные ошибки, которые совершают менеджеры. Это очень удивительно, но многие менеджеры совершают одни и те же ошибки.
Почему вы просто обязаны это знать? Во-первых, выжить самому — это не самая плохая цель. Во-вторых, уж простите за пафосность, но от вас зависит судьба ваших сотрудников. Их зарплата, количество свободного времени, а значит, их семьи, дети… Раз уж вы стали управлять людьми, то у вас просто нет другого выхода, кроме как научиться делать это хорошо. Легкого чтения и… успехов в управленческих джунглях!
Основа успеха любого менеджера в области разработки ПО — это его команда. Это не значит, что если команда хорошая, то дальше все получится само собой. Не получится. Почему именно — отдельная песня. Но с плохой командой выжить будет гораздо тяжелее.
Команда, как это ни странно прозвучит, состоит из людей. Вообще, многие большие и успешные менеджеры на вопрос, что же в управлении самое главное, всегда отвечают: люди.
Соответственно, задачи у менеджера простые:
Давайте посмотрим, что этому мешает.
Найм сотрудников — это, пожалуй, самая важная вещь. Потому что ошибки найма обычно оборачиваются всякими несчастьями типа разложения команды или тем, что вы вынуждены тратить свое время на воспитание неудачного сотрудника. И вообще, сил и нервов уходит страшно много. Без гарантии результата. И часто без самого результата.
Есть масса ошибок, которые менеджеры совершают при найме сотрудников.
Ошибка №1. Нанимают людей глупее себя. Происходит это обычно из-за простого самолюбия. Когда начальнику очень тяжело смириться с тем, что кто-то в его команде будет умнее. Кто-то в его команде — вы только подумайте — будет программировать лучше него! Этак он найдет код, написанный начальником, и — о боже! Он же его разнесет в пух и прах!
К чему это приводит — очевидно. Все сложные задачи начальнику придется решать самостоятельно. И их будет все больше и больше, а времени — все меньше и меньше.
Ошибка №2. Просят рекомендации на человека до собеседования. Есть такая статистика, что только 5-10% людей нанимают через объявления. Все остальные приходят на собеседования по знакомству. И действительно. По знакомству нанимать как-то понадежней будет.
Но есть одна ошибка, которую совершают многие — они запрашивают рекомендации на человека до собеседования. Рекомендации от знакомых обычно хорошие. В итоге в голове заранее складывается картинка, что вы этого человека хотите нанять. И что бы он не говорил потом на интервью, его ошибки воспринимаются как-то снисходительно, а правильные ответы, наоборот, подтверждают установку.
В результате человека вы нанимаете, а он оказывается не такой классный, как ожидалось.
Ошибка №3. Полагаются на симпатию. Во время собеседований некоторые менеджеры смотрят, насколько им симпатичен собеседуемый как человек. Если симпатичен, то нанимают. Ну, потому что, если человек симпатичный, то он, скорее всего, неконфликтный. То есть в команду впишется нормально. А знания — дело наживное. И нанимают. В итоге потом часто получают симпатичного человека, но слабого инженера. Со всеми вытекающими.
Ошибка №4. Проводят собеседование в одиночку. Менеджеры иногда любят проводить собеседование самостоятельно. Или с менеджерами других команд. Но почему-то не приглашают своих сотрудников. Тем самым подчеркивая, кто тут принимает решения. Или я уж не знаю, что этим подчеркивают. Но явно что-то ненужное. Следствием является то, что потом возникают проблемы с адаптацией человека в коллективе. Потому что, даже если вам лично он симпатичен, нет никакой гарантии, что команда его примет.
Ошибка №5. Не просят написать код. В жизни такое встречал очень часто. Когда человеку задают много теоретических вопросов или даже практических, но код написать не просят. Это очень смешно. Примерно как нанимать жонглера в цирк, но не попросить его пожонглировать.
Ошибка №6. Оценивают только текущие знания человека. Иногда на собеседовании задают очень много вопросов на текущие знания. Причем часто спрашивают то, что можно за пять секунд найти в хелпе или Гугле. Типа: перечислите наизусть все методы класса java.util.MegaClass. Оправдание очевидное — «нам нужно, чтобы человек сел и сразу начал работать». Однако программирование — такая область, где знания очень быстро устаревают. То, что человек знает сегодня, станет бесполезным через два года.
Если кандидат не может быстро овладевать новыми знаниями, то будет непросто.
Когда вы работаете программистом, то иметь дело приходится, в основном, с языками программирования, компиляторами, отладчиками, библиотеками и многими другими интересными вещами. То есть заниматься «технические задачами».
Многие программисты, став менеджерами, продолжают пытаться управлять задачами. А людей воспринимают сквозь призму задач. То есть ставим диагноз, наблюдается резкий крен больше в сторону task-orientation, нежели в сторону people-orientation. Вот наиболее распространенные симптомы.
Ошибка №7. Методологии — это все. Часто встречающееся заблуждение task-oriented менеджеров в том, что если следовать вот именно этой методологии, то все будет хорошо.
Проблемы начинаются сразу при попытке эту методологию внедрить. Будет публичное неприятие, потом якобы согласие и саботаж, много чего интересного будет… Но фокус в том, что ни одна методология не застрахует вас от, скажем, семейных проблем у программистов. Или того, что другая компания начнет агрессивно нанимать людей. А времени на то, чтобы подстраховать незаменимых людей, отдокументировать весь код, справиться со всеми рисками, не будет ни-ког-да. Решают не методологии, а люди.
Ошибка №8. Неправильное использование метрик. Люди творческие, к которым программисты относятся, вне всякого сомнения очень не любят, когда их измеряют. Потому что считают, что их творчество и полет мысли нельзя измерить.
Однако многие менеджеры все равно пытаются людей сравнивать. По количеству написанных строк кода, количеству дефектов на тысячу строк кода и многим другим интересным метрикам, на изучении которых ученые пишут диссертации, а консультанты зарабатывают много денег.
В итоге часто менеджеры начинают поощрять тех людей, у которых в смысле метрик все хорошо, и не поощрять тех, у кого плохо. Главный момент состоит в том, что исправить метрику очень легко. Что нужно сделать, чтобы строк кода было побольше? Почаще использовать copy-paste. Поменьше функций, побольше кода в функциях на десять экранов! В итоге по метрикам все становится хорошо, но если заглянуть внутрь, то — ужас, ужас…
Причем заметим, что метрика не всегда однозначна. Если взять какой-нибудь продукт, например, «Сапера» стандартного. Один инженер написал его в 1 тыс. строк кода. Другой в 20 тыс. строк кода. Кто молодец? Очевидно, что первый. Потому что второй наверняка не знает, что такое циклы, функции, какие есть библиотеки и пр.
С другой стороны, может быть, второй сделал какой-нибудь очень расширяемый дизайн, который легко позволит расширить минера до любого количества измерений. Сделал код переносимым и интернационализованным. Или он для того, чтобы улучшить производительность, заинлайнил несколько функций. В общем, непонятно. Надо разбираться. Метрика — это сигнал, что надо разобраться. Не более того.
Ошибка №9. Бюрократия. Любят ли творческие люди бюрократию? Не надо быть семи пядей во лбу, чтобы ответить на этот вопрос. Однако многие менеджеры любят отчеты. Поподробней, почаще. Понятно, что в отчетах иногда есть необходимость. Но еще чаще необходимости именно в том, чтобы присылать отчеты именно такой формы и раз в два часа, – нет.
В одном из проектов мы, помнится, заполняли отчеты строк на 70 со списком заданий и по часам: кто, что и сколько делал. Потом приводилась статистика, сколько у нас уходило на то, на се. Были ли люди счастливы от таких отчетов? Нет. Тратили ли они на заполнение отчета много времени? Да, тратили. Нужна ли была кому-то эта статистика? Практически, нет.. Достаточно было собрать данные за месяц, а не писать эти отчеты полгода.
Ошибка №10. Поощряется процесс, а не результат. Очень многие менеджеры любят установленный процесс. Процесс — это гораздо лучше, чем хаос. Но тут есть одна тонкость.
Любя процесс, они поощряют всеми силами его использование. Совершенно забывая про цель процесса — обеспечивать результаты. Считается, что если следовать процессу, то результат будет. А это не всегда так. Иногда для результатов нужно немного творчества и немного хаоса. Люди — они очень адаптивные. Поощряется процесс, а не результаты? Будет процесс, не будет результатов.
А заказчик, заметим, платит в итоге за результат, а не за процесс.
Ошибка №11. Одновременно несколько задач. Мы все с детства знаем верный способ не поймать ни одного зайца. И почему-то очень часто пытаемся повторить эксперимент на работе. Со своими сотрудниками. Человеку дается два задания, которые он должен делать одновременно. Или четыре задания, так еще надежней.
Чтобы эффективно начать делать задание, человеку нужно время на «включение». Если делать их одновременно, то на переключениях будет теряться куча времени.
В итоге задания будут выполняться медленней, чем если их делать друг за другом. Люди будут расстраиваться, что ничего не успевают. И от этого работать еще медленней. Еще расстраиваться. И так до печального конца.
Ошибка №12. Менеджер как отвлекающий фактор. Менеджеры — существа обычно очень общительные. Если они к тому же еще плохо самоорганизованные, то случается вот что.
Сотрудника вдруг просят «прямо сейчас» прислать детальный отчет, что он делал за последний месяц. Или посмотреть, что там с производительностью у конкурентов (ну это еще более-менее осмысленное задание, но нельзя ли было его заранее запланировать?). Или спросят, не помнит ли он телефон Джеймса. Или нет ли у него прошлонедельного письма от Майка.
И т.д. В итоге человек отвлекается от работы, потому что начальник же просит. И выполняет свои задачи в два раза медленней.
Ошибка №13. Мало разговаривают с людьми. Когда я стал менеджером, я, естественно, совершил не 29 ошибок, а гораздо больше. Одной из первых была именно эта — я мало разговаривал с подчиненными. С некоторыми встречался вообще раз в месяц на уровне «привет-пока». Ну, группа была достаточно большая, но это, конечно, не должно служить оправданием. В результате при разделе нашей компании со мной в новую компанию перешло два человека. Из 17. Причин было много, но одна из них — необщение.
Собственно, почему не общаться — плохо? Потому что вы вообще не представляете, что творится в голове и на душе у ваших сотрудников. А когда они сами к вам придут, это, скорее всего, будет означать, что уже поздно. Например, что хороший сотрудник уходит в другую компанию.
Ошибка №14. Интриги в команде. Тут есть две фазы. Первая — менеджер не препятствует интригам. Вторая — он их поощряет и создает.
Вторая фаза — это какая-то клиника, которая тем не менее иногда встречается. Форма паранойи, когда обычно менеджер боится, что его подсидят. В итоге вместо команды, которая работает как одно целое, получается группа индивидуумов, которые заняты борьбой друг с другом больше, нежели работой.
Первая фаза — гораздо более распространенная. Когда какой-то из сотрудников начинает жаловаться на другого, что тот пишет кривой и неправильный код, делает идиотскую архитектуру, «явно видно, что он некомпетентен» и пр., и пр. (Заметим, что обычно это говорится в оправдание собственного неуспеха, т.е. не успел что-то закончить вовремя, потому что чужой код весь в ошибках и т.д.). А менеджер все это слушает, но ничего не делает. Тем самым поощряя подобные некомандные проявления.
Ошибка №15. Публичная ругань. Речь идет не о «матом на людях». Речь идет о том, что если сотрудник совершает какую-то ошибку, то многие менеджеры выговаривают ему об этом прилюдно. Либо устно, либо письмом на всю команду. «Я уже много раз писал о важности прогона тестов перед заливкой изменений в пространство. Однако Вася, как обычно, моих писем не читал…».
Причем некоторые менеджеры делают это специально, находя в порицании какой-то воспитательный момент. Видимо, школьные практики дают о себе знать.
На самом деле, естественно, этот месседж говорит сотруднику только о том, что поддержки у менеджера он никогда не найдет. Причем это понимает не только «провинившийся», но и все остальные члены команды. При публичной ругани никакие доверительные отношения между менеджером и сотрудниками становятся невозможны.
Ошибка №16. Не хвалят и не говорят спасибо. Есть такая распространенная установка, что если сотрудник работает хорошо, то это само собой разумеется. А вот если плохо, то это требует внимания начальства.
Это, разумеется, неправильно. Тут как с детьми — нужно обязательно поощрять правильное поведение. Причем публично. Чтобы остальные дети видели, что такое правильно, и как оно нравится родителям. А спасибо… доброе слово оно и кошке приятно.
Ошибка №17. Не говорят плохих слов. Плохое поведение тоже нельзя оставлять безнаказанным. Однако многие менеджеры, которые хотят быть очень people-oriented, стесняются говорить «плохие» слова своим сотрудникам. Считая, что поощрения хорошего поведения должно хватить.
На самом деле, это, скорее всего, просто нежелание портить отношения с сотрудниками. Но проблема в том, что если не сказать сейчас, то оно усугубится. И портить отношения потом придется. Причем сильно. И самое интересное, что люди конструктивную обратную связь обычно воспринимают адекватно. Понимают, что немного заигрались.
Начальство — это, пожалуй, самый интересный участник игры. По крайней мере, от него зависит очень многое. Тем более странно, что очень часто люди совершают:
Ошибку №18. Не управляют своим начальником. Очень многие менеджеры занимают исключительно пассивную позицию по отношению к начальству. В чем это выражается?
«Нам говорят — мы делаем». Почему-то мало кто не хочет сам придумывать себе, что делать. Большинство уверены, что это задача начальства — говорить, что делать.
Второй симптом — уверенность, что мнение начальства изменить нельзя. Причем настолько нельзя, что некоторые даже не пытаются. (Заметим, что изменять мнение — это не обязательно вступать в открытую конфронтацию). Все остальные ошибки относительно начальства, по большому счету, являются следствием этой.
Ошибка №19. Не говорят начальству «Нет». То есть воспринимают слова своего менеджера как приказ к исполнению. Тем более, что сказать «нет» означает поставить под сомнение авторитет самого! Интересно, что чем больше начальник, тем обычно более адекватно он воспринимает мысли и возражения подчиненных. По крайней мере, мой опыт общения с большими менеджерами подтверждает это на все сто.
Еще одна причина невозражений в том, что часто менеджерами становятся достаточно бесконфликтные люди (мой случай), которым психологически проще согласиться. Но тут они рано или поздно совершают:
Ошибку №20. Боятся донести до начальства плохие новости. Потому что один раз не сказав «Нет», подписываются под нереальными сроками. После чего дела становятся все хуже и хуже. А доносить эту новость до начальства все страшнее и страшнее. И так по замкнутому кругу. Пока не происходит большой «упс». Слабые менеджеры пытаются выйти из ситуации, совершив:
Ошибку №21. Пытаются свалить вину на команду. Это может прокатить, только если вашим начальником является полный идиот или абсолютно беспринципный человек.
В противном случае, вам укажут, что за результат отвечаете вы. И где вы были все это время, пока жизнь настойчиво указывала вам на приближение неотвратимого финала?
Плюс, один раз свалив вину на команду, можно смело из нее уходить. Отношения с людьми уже не наладятся.
Второй по популярности попыткой выйти из безвыходной ситуации с нереальными сроками является:
Ошибка №22. Критика начальства. Это когда вы сваливаете вину на начальство. И вместе с командой переживаете, какое же оно, начальство, тупое.
Это, безусловно, даст вам некоторую краткосрочную популярность в команде, показав, что вы с ними по одну сторону баррикад. Но кроме этого это даст людям четкий месседж, что вы, как менеджер, ничего не решаете. Не умеете отстаивать свою точку зрения и точку зрения команды. Надо ли работать на такого менеджера или лучше поискать более успешного?
Рано или поздно многие замечают, что, став менеджером, меняются. Начинают думать немного по-другому, ощущать ответственность не только за себя, но и за проект, за других людей. Многие проблемы разработчиков, из-за которых раньше вы готовы были кого-нибудь отформатировать, теперь кажутся детским садом. Это нормально. Значит, вы на правильном пути. Но и на нем встречаются ошибки.
Ошибка №23. Переработки. Некоторые люди почему-то думают, что много работать это очень хорошо. Если менеджер не перерабатывает, то он плохой менеджер. Это очень странная точка зрения, потому что карьера не идет вверх от количества работы. Она идет вверх от ее качества. Переработки плохи по очень многим параметрам.
В первую очередь страдают семья и личная жизнь. Просто потому что на них остается меньше времени.
Есть такое мнение, что у каждого человека обязательно в жизни должно быть три вещи: работа, семья и хобби. Если все это есть, то все у него хорошо и гармонично развивается. Как только что-то одно начинает пожирать время за счет другого — счастья не жди.
Второй важный момент в том, что когда менеджер проводит много времени на работе, это плохой пример для подчиненных. У членов команды тоже есть семьи и различная личная жизнь, а уходить с работы раньше своего начальника — как-то неудобно. Причем даже если начальник не возражает, чтобы люди уходили раньше.
По себе помню, что когда сидел на работе допоздна и кто-то из моих людей уходил раньше, то умом-то я понимал, что это нормально, у людей какие-то свои дела. Но злобу затаивал. Причем совершенно подсознательно. Очень сложно не затаить. Я работаю, а он идет отдыхать!
Самое неприятное в переработках — это чувство, что ты все равно ничего не успеваешь. И в итоге становишься раздражительным, срываешься на близких людях, на своих же сотрудниках. Они демотивируются, уходят или перестают работать, и дальше все по замкнутому кругу.
Следующие несколько ошибок как раз являются причинами переработок.
Ошибка №24. Замыкание информационных потоков. Что это значит? Это значит, что менеджеры не делятся какой-то информацией, предпочитая быть ее единоличным обладателем. Опять же, по себе знаю, что это очень приятно — обладать каким-то знанием, которым мало кто обладает. Потом можно при случае его выгодно выложить. Это своеобразный личный бонус, да и как-то собственная важность повышается, но на самом деле такой подход отнимает очень много времени. Потому что без вас ничего решиться не может.
Типичная ситуация. Вы уходите в отпуск на две недели, оставляете формального заместителя. И он на любой вопрос говорит: ну, я тут принять решение не могу, давайте Сашу подождем. Вы возвращаетесь из отпуска. И тут на вас одновременно наваливаются и текущие дела, и то, что накопилось за две недели отсутствия.
Ошибка №25. Микроменеджмент. Микроменеджмент — это, на самом деле, такая форма недоверия человеку. Вы дали ему какое-то задание. Но не доверяете ему его выполнение. Поэтому вмешиваетесь как можно чаще и говорите ему, какие именно кнопки нажимать. Тут несколько негативных факторов:
Еще одной ошибкой, связанной с недоверием, является:
Ошибка №26. Отсутствие делегирования. Вы были хорошим программистом. Потом стали менеджером. И вот прилетает техническая задача, которую вы можете сделать за два дня. А можете делегировать ее сотруднику и он ее сделает за неделю, при этом три дня будет вас спрашивать, как и что делать. Конечно, делаете сами. В итоге сотрудники не учатся, и потом вы делаете сами все время (см. «Переработки»). Частным случаем этой ошибки является желание самому сделать работу интересной.
Ошибка №27. Сами пытаются сделать работу интересной. Программирование — это не всегда новые технологии, интересные алгоритмы и творческие задачи. Естественно, у менеджера возникает желание разнообразить работу, чтобы люди сразу не разбегались.
Сотрудникам это нравится. Но что плохо — так это то, что они начинают считать, что это задача менеджера — делать работу интересной. А на самом деле эта функция касается каждого сотрудника. «There is no boring job, there are boring people» ((c) Jim McCarthy).
Ошибка №28. Переделегирование. Но вот вы уже продвинутый менеджер и знаете, что задачи надо делегировать. И раздаете их направо и налево.
Может случиться вот какая проблема. Если человек не готов выполнить задачу, то ему нужен плотный контроль и поддержка с вашей стороны. Если же вы доверяете ему слишком много и не контролируете совсем, то он может и не прийти к вам, даже если видит, что сам не справляется. Он может все пытаться сделать сам, а потом расстроиться и все равно прийти. В итоге получится несделанная задача и демотивированный сотрудник.
Ошибка №29. Считают, что результаты — это все. Эта ошибка особенно часто встречается у менеджеров. Они почему-то уверены, что главное, чтобы команда производила результаты. А дальше их (менеджеров, не результаты) заметят и произведут в следующий чин.
А почему-то не замечают. А в табеле о рангах растут люди, у которых в командах вроде и с результатами как-то похуже… Почему так? Несправедливость? Нет, отсутствие работы над визибилити.
Ну, пока хватит. Можно было бы легко довести количество ошибок до 50, но пока не будем. Для выживания менеджера программистов вполне достаточно избегать этих базовых ошибок. А если вы их уже совершаете, то срочно исправить. Если вы исправите хотя бы три ошибки, которые вы у себя обнаружили, то эффект уже превзойдет все ваши ожидания. Главное — делать!
Удачи!
Весь 2021 год мы уже работали как компания, юридически расположенная в Евросоюзе, и планомерно переносили в эту юрисдикцию основные бизнес-процессы, включая прием платежей, основные расходы и уплату налогов.
Справившись с первым шоком и стабилизировав работу команды, 01.03.2022 мы заявили, что останавливаем коммерческие проекты и ближайший месяц перебрасываем все силы на проведение поддерживающих психологических семинаров для всех, кому нужна поддержка в это непростое время.
Понимая, что наш статус EU-компании и принятое решение остановить все коммерческие активности дают нам немного времени (наши налоги уже не работают против людей), следующие 10 дней мы уделили организации и запуску открытого бесплатного проекта поддержки для всех наших клиентов и подписчиков.
За это время стало окончательно понятно, что мы больше не можем поддерживать своими налогами путь, который выбрала РФ, поэтому мы прекращаем экономическую деятельность в России — наша компания не принимает платежи и не платит налоги на территории РФ.
Текущие, запущенные проекты мы доводим до конца, так как всегда выполняем все взятые на себя обязательства, как и все предыдущие 12 лет нашей бизнес-практики.
Мы — бизнес-школа, учебное заведение. В мировой истории было достаточно позорных моментов, когда образование было недоступно людям с определенным цветом кожи, определенной национальностью или в силу других дискриминационных признаков.
Мы не поддерживаем дискриминацию в любом ее проявлении, в том числе по цвету паспорта людей, которые к нам приходят.
Мы будем работать с теми студентами, кто готов при поступлении подтвердить свою позицию относительно дискриминации и согласиться с нашими правилами работы.
Мы всегда работали на русском языке, с момента основания Школы. Русский — 8-й язык по количеству носителей в мире и это язык, на котором мы думаем и работаем. Наша задача — оставаться лучшей школой для тимлидов и менеджеров, и мы можем это сделать, работая на русском.
С пониманием ко всем, кто придерживается другой точки зрения, мы оставляем за собой выбор принимать обоснованные и последовательные решения в интересах наших клиентов во всех уголках мира.
