Где найти и как выбрать тимлида +62



Предыстория


Привет! Меня зовут Виталий Шароватов, я уже 16 лет работаю в IT. Сейчас я руковожу направлением фронтенд в Badoo. В него входят две команды, которые занимаются разработкой и поддержкой десктопной версии сайта badoo.com, мобильной версии m.badoo.com и многими другими проектами. Да, десктопную и мобильную версии у нас делают отдельные команды. :)

Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом, когда было решено перевозить команду Desktop Web в Лондон, стал руководителем направления.

Прошлой осенью на Codemotion Milan я делал доклад о росте из разработчика в тимлида (и писал на Хабр статью об этом) и о том, с какими неожиданными моментами мне пришлось столкнуться, а теперь расскажу, как при переходе из лида в руководителя направления я справился с подбором и «выращиванием» тимлида в одной из команд (Mobile Web).

Зачем вообще нужны лиды и откуда их брать?


Мне тимлиды нужны были по очень простым причинам — для обеспечения управляемости командой из 25 человек и поддержания эффективности работы сотрудников при уменьшении количества «точек входа» в отделы.

Есть два классических варианта получения нового тимлида: нанять или назначить. Но мы выбираем третий — «вырастить». Во-первых, это часть культуры Badoo — всегда помогать развиваться своим людям; во-вторых, у каждого разработчика есть хорошая история его работы (о том, почему это важно, расскажу ниже).

Почему мы не идём по пути назначения? Ну, наверное, многие слышали или даже видели, как в тимлиды выбирают просто самого толкового инженера и чем это может обернуться. :)

Лайтовая версия такого сценария произошла в Badoo за некоторое время до моего прихода в компанию: одному очень грамотному инженеру предложили поруководить небольшой командой, и какое-то время он ею вполне неплохо руководил, вот только с каждым днём становилось всё труднее и труднее, и демотивация росла и росла. Проблема была простой: человек не хотел никого обидеть или показаться слишком резким. Поэтому в ситуациях, в которых требовалось применение директивного подхода, у него совсем не получалось жёстко требовать чего-то от сотрудников. В худшем случае такая ошибка с выбором может привести к серьёзной демотивации самого инженера (и хорошо, если у него получится вернуться к инженерной работе!) — ведь по мнению человека, ему доверили новую должность, а он не справился. К счастью, в той ситуации всё закончилось хорошо: разработчик был очень лоялен компании и честно вовремя сказал руководителю, что у него не получается, а руководитель, в свою очередь, прислушался и снял с него эту «непосильную ношу». Могло быть значительно хуже.

Я всегда считал, что лучше подходить к выбору тимлида и последующим шагам с другой стороны, минимизируя риски и последовательно предпринимая серию действий, которую я обозначил как «Подбор—Назначение—Поддержка и контроль».

Подбор: как?


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

Минимизируем риск провала — не влияем негативно на мотивацию людей (как кандидатов, так и других членов команды).

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

Подбор: когда?


Как только вы стали тимлидом, нужно начинать подбирать себе замену.

По моему опыту, это очень хороший принцип — как только стал тимлидом, начинать планировать развитие своих подчиненных, создавая себе таким образом временную «подушку безопасности» на будущее.

Но с заместителем-заменой история немного другая. Это вообще, как мне кажется, одна из первостепенных задач любого менеджера — поиск заместителя; работа отдела не должна останавливаться, если вдруг ты заболел, решил взять отпуск или уволиться.

Но для меня неожиданно приятным бонусом оказалось то, что, когда есть готовый «заместитель», можно на время поручить ему руководство отделом, а самому погрузиться в какой-то важный проект.

Ну и, конечно же, при «выращивании» заместителя-будущего тимлида появляется ещё один человек, с которым можно обыгрывать или обсуждать разные мысли.

Подбор: карточки


Что такое карточки для меня? Простой документ почти свободной (но единообразной для всех) формы, где описываются все ключевые для руководителя вещи про сотрудника. Естественно, никому нельзя давать доступ к ним.

Преимущества ведения карточек:

  1. Более глубокий анализ текущей ситуации и более чёткая её формализация.
  2. Уменьшение вероятности того, что какие-то моменты/ истории/ паттерны канут в лету.
  3. Упрощение анализа прогресса человека и мониторинг скорости его развития.
  4. «Объективация» процесса — более чёткое разделение своего личного отношения к человеку и его профессиональных качеств, истории его работы и развития.




Это сокращённая версия карточки, многое пришлось опустить, но, думаю, структура понятна: качества с оценками, мотивация, роли, цели.

Кратко опишу структуру карточки:

  • current level — текущая ступень развития сотрудника в компании. В Badoo действует система уровней, схожая с системой Google; в вашей компании может быть совсем другая «лестница» (например, на заводах приняты разряды);
  • plan — моё видение плана развития сотрудника;
  • qualities — произвольно оцениваемые (моя шкала — от одного до пяти) навыки и качества сотрудника (для наглядности я считаю крайне важным указывать подтверждающие оценку рабочие события);
  • motivation — мои представления о мотивации сотрудника. Каждый раз, когда я пересматриваю или обновляю карточки, я стараюсь заново оценивать мотивацию. На мой взгляд, это вообще один из самых важных пунктов карточки, потому что для выстраивания планов по развитию сотрудника просто необходимо оценивать его мотивацию;
  • roles — текущие или планируемые роли сотрудника в команде;
  • goals — поставленные перед сотрудником (или мной) цели, исходя из его мотивации, проблем/успехов и бизнес-целей команды.

Про оценки и скоринг я расскажу ниже.

Подбор: скоринг


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

  • Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
  • Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
  • Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
  • История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
  • Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.


Подбор: продажа


Выбирая тимлида, важно понять, кто как заинтересуется управлением. Я называю эту стадию подбора продажей.

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

Например, можно задать вопросы из серии «Сильвестр, а ты видишь, что у Марио проблемы со сроками? Как думаешь, почему так? Как помочь человеку?» и смотреть, как человек реагирует, интересно ли ему попытаться разобраться в проблеме.

Ответы бывают двух типов: «Чего ты мне менеджерские вопросы задаёшь?! Я сюда код писать пришёл. Можно я пойду дальше работать?», и «Ох, блин, как интересно! Наверное, Марио не смог у серверников истребовать сроки нормально. Может, нам придумать какой-то другой формат планёрок, чтобы эту проблему решить?» Сразу видно, что во втором случае у человека горят глаза, что он готов работать с людьми, и работа эта ему интересна.

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

Подбор: проекты


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

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

Что ещё удобно в проектной работе — легко подобрать необходимый для той или иной стадии проект: как с точки зрения команды (например, к эмпату можно поставить жёсткого человека и посмотреть, как он с ним будет работать), так и с точки зрения технической сложности (может быть, подкинуть проект-идею, где даже непонятно, в какую сторону «копать», а результат нужен уже через неделю).

Ещё одно преимущество проектного подхода — низкий риск неудачи. Даже если проект провалится, это не сильно отразится на мотивации кандидата. Для мотивации других сотрудников, участвовавших даже в провальном проекте, все тоже не очень плохо: «Ну вот Серёга затупил, провалили проект», а вовсе не «Блин, и с ним нам потом работать? Ну нет, лучше сейчас уволюсь».

Подбор: заместитель


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

  1. Чтобы оставить вместо себя заместителя, нужно ему передать свои рутинные функции, а для этого их нужно структурировать и задокументировать.
  2. Необязательно ждать своего отпуска — заместителю можно поручить свою работу на время (а самому заняться подготовкой доклада и одновременно мониторить работу зама :)).


Помимо стандартных метрик-качеств из карточки, о человеке становится понятно сразу очень многое:

  1. Насколько легко он адаптируется к совершенно незнакомому типу нагрузки (а гибкость и скорость адаптации — одни из ключевых навыков менеджера, как мне кажется), как организуется его личная работа, успевает ли он всё сделать, если не успевает, рассказывает ли руководителю о проблемах (есть ли прозрачность).
  2. Насколько тщательно он выполняет рутинную работу: достаточно ли у него въедливости и внимательности для этого, или придётся вкладывать ресурсы в коучинг и в этой области. Работа руководителя всегда подразумевает в том числе и рутинные действия. Но некоторым людям они даются очень трудно, приходится буквально себя заставлять. Если человек не может справляться с рутинными действиями даже в течение недолгого периода времени, возможно, это тоже негативный фактор, который стоит учитывать.
  3. Уровень неформального лидерства в команде: отличается ли то, как работает человек в роли заместителя, от того, как он работал на проектной работе. Видно, как воспринимают его другие сотрудники.


После подбора


Что делать после успешного применения инструментов подбора?

На этом этапе, как правило, остаётся какое-то число кандидатов, и путём сравнения их скоринга удаётся выделить одного (необходимо оценить риски, объём временных затрат). По сути, мы готовы назначать тимлида уже сейчас.

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

Назначение


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

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

Поддержка: развитие


После назначения новоиспечённому тимлиду будет необходима помощь.

Я считаю правильным применять классическое ситуационное управление на всех стадиях, подразумевая низкую профессиональную квалификацию (ведь человек до этого момента никогда не занимался руководящей работой на постоянной основе) и высокую мотивацию.

  1. Сначала тимлида придётся «вести за ручку», используя практически директивный подход, говорить ему: «Делай, как я» и объяснять, почему.
  2. Затем можно переходить к коучингу, спрашивая: «Как бы сделал ты и почему?» и консультировать по всем вопросам.
  3. После этого уже можно отпустить тимлида в свободное плавание и перейти на либеральный подход «Мне нужны вот такие результаты; делай, пожалуйста».

Конечно, всегда нужно держать руку на пульсе и регулярно помогать тимлиду.

Поддержка: контроль


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

Причём нужно чётко контролировать именно стратегию, а не каждый байт его работы.

Что делать?

  1. На встречах с тимлидом при обсуждении любых вопросов постоянно проверять его понимание сказанного: «Расскажи мне, как ты понял», «Объясни своими словами» и т. д.
  2. Постоянно «обнажать инструментарий»: «Смотри, я тебя подвёл к решению задачи наводящими вопросами, но решил её ты сам. Видишь, как мой коучинг работает на тебе — он так же сработает на ребятах». Хорошо бы добавить личный пример.
  3. Выделять больше времени на встречи с лидом, чем раньше тратилось на общение с каждым разработчиком. У меня на общение с тимлидами уходит как минимум полтора часа в неделю, плюс куча небольших синхронизационных обсуждений.

Поддержка: помощь


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

Необходим контроль выгорания: не требовать меньше, а просить делать анализ затрачиваемого времени. Я делал это так: в течение дня записывал 15—20-тиминутные слоты, «тегировал» их, а потом раз в неделю садился и анализировал, на что, собственно, уходит моё время.

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

Перед тимлидом необходимо ставить более стратегические цели, чем перед разработчиками, тем самым приучая его к более длинному горизонту планирования.

Цена неразумной траты времени командой в случае ошибочного решения тимлида довольно высока. По этой причине постоянно напоминаем тимлиду, что наше кредо — прагматизм, и любое решение должно отвечать на вопросы «Зачем?», «Сколько стоит?» и «Какие риски?»

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

Выводы и результаты


Так у меня в команде мобильного веба появился сильный тимлид. Возможно, моя стратегия «выращивания» тимлида кому-то покажется быстрой и чересчур гладкой. Но важно помнить: чтобы этот план сработал, придётся держать руку на пульсе и работать с тимлидом на всех этапах его становления. Нельзя назначить человека и забыть о нём.

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

  1. Не стоит тянуть с подбором тимлида: чем раньше начнёте, тем больше вероятность успеха.
  2. Карточки и скоринг — необходимые инструменты для объективного выбора.
  3. Подбор, назначение, поддержка и контроль — неизбежные и обязательные этапы, которые помогают достичь эффективного взаимодействия не только руководителя с тимлидом, но и тимлида и руководителя со всей командой.
  4. Работать с рисками и ожиданиями нужно регулярно, а не только когда что-то идёт не так. Это кажется очевидным, и всё же нужно постоянно напоминать себе об этом.

Спасибо за внимание! Всегда рад пообщаться на темы управления, мотивации и процессов — пишите в Хабрапочту или комментарии.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (25):

  1. PYXRU
    /#10633624

    Я так понял, это доклад был на HighLoad 2017 Moscow. Вот ссылка кому интересно на видео версию: https://youtu.be/Ygfwwd490mk?t=1h2m7s

  2. VolCh
    /#10633864

    Я правильно понял, что в итоге тимлид таки назначается, причём для него это неожиданно, даже если зам? Да, вы его готовили в лиды, да, со всеми вашими функциями справлялся, но согласен ли быть лидом постоянно вы забыли спросить или написать?

    • vsh
      /#10633920

      Спасибо за комментарий, действительно пропустил этот момент в докладе и в статье.
      Конечно же, в итоге тимлид назначается, и событие это вполне ожидаемо для сотрудника. Еще на этапе работы заместителем он четко понимает, что эта обязанность — испытание перед потенциальным назначением.

      • VolCh
        /#10633940

        И начинает подыскивать заместителя себе? )

        • vsh
          /#10633948

          После вступления в должность — безусловно :)

          • VolCh
            /#10634214

            Я имел в виду, что если человек понимает, что получение должности зама тимлида — это, по сути, лишь испытательный срок на тимлида, то заместителя себе он по вашим советам должен начать выбирать когда получает должность зама, а не когда тимлида :)

  3. velvetcat
    /#10633932

    Два с половиной года назад я пришел в Badoo разработчиком, со временем вырос до тимлида, а потом (skipped) стал руководителем направления

    Сорян, но несколько месяцев опыта на должности в одной-единственной компании — это очень мало, чтобы сделать выводы и начать раздавать советы. Ничего личного.

    • vsh
      /#10633944

      Я буду очень рад, если Вы поделитесь конкретными советами или покритикуете что-то предметно :)

      • velvetcat
        /#10639426

        Я, в общем, не хотел бы критиковать предложенный подход. В целом лично я со всем согласен и более того, мне это все близко по духу. Но имхо решение получилось слишком "переспецифицированным", а от этого — не универсальным и трудным в воплощении (а не легким, как может показаться).


        Правильных решений задачи — много. И других важных задач тоже много.


        Что же до, собственно, где найти и как выбрать тимлида. Мое мнение, тимлид — это первый человек в иерархии, который никогда ничего не оставляет на самотек. От этого и пляшем. Все остальное сильно варьируются от проекта к проекту и должно решаться индивидуально в конкретной точке пространства и времени. Принципы, конечно, есть, но исключений гораздо больше.

  4. africaunite
    /#10633982

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

    Надеюсь и уверен, что вы пропустили "паталогическая" перед словом "мягкость". Мягкость это хорошо, мягкость в отношениях — это когда не царапает и приятно. А вот реагировать на мягкость агрессией, или попытками сесть на шею — это глупость, которая должна превентивно наказываться, я так думаю ;)

    • VolCh
      /#10634216

      Как вы отличите попытку разработчика сесть на шею от попытки разработчика убрать с себя неинтересные обязанности?

      • africaunite
        /#10634248

        А если серьезно — разработчик — "тоже человек". Если это коллега — человек, с которымм каждую конкретную неделю я трачу на общение больше времени, чем могу провести со своей семьей (даже если это удаленная работа). Мотивы, желания, интонации, правда на правду, курилка, реакции других людей, мимика, глаза, но, самое главное — мое желание его узнать — все вместе сильно повышает прозрачность того, что собеседнику интересно, а что нет.


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

        • VolCh
          /#10634266

          Мой вопрос скорее был не в том, как выявить ситуацию когда человек сознательно хочет сесть на шею, а когда он пытается рационализировать свою деятельность, а вами это воспринимается как попытка сесть на шею. Ведь это понятие достаточно субъективное. Скажем, от топ менеджмента есть требование ежедневных отчётов по состоянию текущих задач, отменить его вы не можете. Сначала вы решаете, что разработчики будут делать свои отчёты сами, а вы, как тимлид, их агрегировать или даже просто контролировать, чтоб никто не забывал. Но тут вам поступает предложение "а давай ты будешь их писать, ты же и так в курсе кто чем занимается, ты и говоришь кому чем заниматься". Один человек воспримет это как попытку сесть на шею, а другой как рациональный ход — разработчики будут разрабатывать, а я, как менеджер, отчёты писать.

          • africaunite
            /#10634672

            Ну я могу судить только по себе.
            Реальность всегда сложнее абстрактных предположений, общий алгоритм такой:


            1. Постараюсь понять, не пытается ли мне сесть на шею топ менеджмент. Решаем ли мы реальную проблему, или начальство и так уже имеет инструмент, но не знает как им пользоваться. Постараюсь помочь в обоих случаях, безусловно.
            2. Постараюсь уловить момент, когда я сам пытаюсь сесть на шею. В первую очередь — оценить, принесет ли сбор отчетов пользу и мне и начальству и разработчикам одновременно.

            В данном конкретном случае — реальная задача "прозрачность" и польза ее решения очевидна. Сделать идеально (если совсем пусто) на раз не получится. Предложу для начала, действительно, писать отчеты, но не постфактум. А фиксировать шаги заранее и во время действий. Хорошая привычка, в любом случае. А отчет получается просто бонусом. Но этого мало, надо автоматизировать, чтобы ничто не отвлекало — это факт. Следующий шаг — настроить системы (ведения проекта, version control, CI, документации) так, чтобы по ним сразу получалась относительно ясная картина. Чтобы если и разговаривать (писать отчет) с руководством и командой — не по рутинным причинам, а именно для обсуждения конкретных и важных моментов.

      • timiskhakov
        /#10634622

        Простите, но это разве не одно и то же? Я имею ввиду, что если убирать с себя неинтересные обязанности (то есть дела, которые нужно делать именно этому сотруднику), они никуда не денутся, и их должен будет делать кто-то другой.

        • VolCh
          /#10635636

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

          • africaunite
            /#10635656

            все верно, а тимлид рационализирует деятельность команды, так?

            • VolCh
              /#10636274

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

              • africaunite
                /#10637762

                Отлично. Выводим, что Вы знали ответ на собственный вопрос в предыдущей ветке — тимлид — это тот, кто рационализирует деятельность команды, заботится о шее команды и помнит, что жопа командная, тоже — гораздо более впечатляющая...

  5. Durimar123
    /#10635358

    Забавно, что никто не пишет в чем состоят обязанности тимлида.

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

  6. jeka1202
    /#10635620

    У вас выбор города/страны немного неправильный. а конкретнее города Крыма. какой бы не был город, везде пишет <мой_город>/Украина. Просьба поправить.

  7. o_o__ermakov__0_0
    /#10635640

    vsh А можете раскрыть тему «текущая ступень развития сотрудника в компании». По каким критериям оцениваете и есть ли у вам маттерилаы где эта тема раскрыта?