Що робити, якщо не вдається побудувати dream team: висновки із власного досвіду

Я Ігор Томич, СЕО ITOMYCH STUDIO. Ми розробляємо веб- та мобільні застосунки з 2011 року. Віддаємо перевагу цікавим челендж-проєктам для фінтеху. Маємо на меті диджиталізувати фінансові компанії, створюючи для них найінноваційніші рішення. Цього року нам виповнюється 10 років.

У 2004-му я розпочав кар’єру програміста в аутсорсі, пройшов шлях від розробки складних проєктів до менеджменту, а потім створив власний бізнес.

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

Будь-яка криза — привід запитати себе: «А що я взагалі роблю?». Тож я почав ставити запитання. Поділюся відповідями й висновками, яких дійшов.

Найперше — побудова процесів

Найголовніше, що я усвідомив: до весни 2020 року ITOMYCH STUDIO не була аутсорс-компанією в класичному розумінні. Так, у нас був офіс, команда, клієнти, але бракувало головного — системної управлінської роботи з розвитку бізнесу. Три роки тому нас було 60, і я не планував зростання: команда реалізовувала амбітні технологічні проєкти та досягала поставлених цілей.

Проте, як завжди, все змінює випадок. У 2018 році переді мною постав складний вибір: стартувати розробку банківського проєкту для ринку Британії, до розміру й складності якого ми не були готові, або продовжити працювати, як раніше, втративши клієнта. Я обрав досвід і протягом усього часу співпраці із замовником не був СЕО ITOMYCH STUDIO, а фактично обіймав посаду CTO продукту, який розробляли.

Ми були змушені стрімко рости. До того ж кількість проблем, що виникали в роботі, та потрібна швидкість ухвалення рішень не давали глибоко аналізувати й правильно вибудовувати взаємодію всередині команди. Страждав підбір, корпоративні цінності, а також якість процесу розробки програмного забезпечення.

Попри всі проблеми, ми зробили круте банківське рішення за 9 місяців і успішно ввели його в експлуатацію в жорсткі терміни від клієнта. Експертизу справді отримали, але не збудували dream team: люди, які прийшли працювати саме над цим проєктом, потроху залишили компанію.

Перший крок до одужання — визнати хворобу. З цього я й почав. Усвідомив проблеми внутрішньої взаємодії, відсутності злагоджених процесів, непрозорої комунікації та складнощів пошуку персоналу. Усі ці питання тісно взаємопов’язані, тому й вирішувати їх треба було комплексно.

HR — це про бізнес, а не про фрукти на кухні

З командою в 40–50 фахівців я не замислювався про HR-процеси. З ними не виникало проблем: люди рідко залишали компанію, панувала дружня й майже сімейна атмосфера, розширення колективу також було передбачуваним. У 2018 році компанія посіла перше місце у рейтингу найкращих роботодавців видання DOU і стала лідером у Харкові.

Загалом я розумів HR-питання, але у 2019 році випадково потрапив на курс до Катерини Остапчук — однієї з провідних експертів на HR-ринку. Там усвідомив, що HR — це про бізнес і цифри, а не про фрукти на кухні.

Тож першим кроком до якісних змін став опис посад у компанії та обов’язків на кожній з них. Я хотів чітко окреслити відповідальність і завдання, щоб грамотно розподіляти навантаження.

Відтак ми взялися за підбір. Одна з причин плинності — відсутність загальної системи цінностей і оцінки за нею під час рекрутингу. А коли цінності роботодавця та команди не збігаються, то продуктивної та довготривалої співпраці не побудувати. Рано чи пізно виникають проблеми через відмінності у поглядах і робочих підходах.

Тож у 2020 році ми ввели етап глибинного інтерв’ю. Навіщо? Усі рекрутери — це амбасадори нашого HR-бренду. Вони напам’ять знають критерії відповідності пошукача корпоративній культурі, що допомагає під час відбору: не тільки кандидат повинен влаштувати нас, але й ми його.

Щоб виявити ймовірні розбіжності, ми використовуємо метод структурованого інтерв’ю за компетенціями. Під час спілкування з кандидатом рекрутер оцінює набір навичок, знань і поведінкових характеристик, потрібних для певної посади. У нього є право вето: якщо він розуміє, що людина нам не підходить, може відмовити їй навіть без технічної співбесіди. Такий підхід значно підвищив якість пошукачів, що доходять до технічного інтерв’ю, та спростив адаптацію новачків. Фахівці почали краще розуміти, в яку компанію та команду приходять.

Крім рекрутингу, нам вдалося налагодити й інші HR-процеси. Наприклад, у середньому раз на місяць кожен учасник команди зустрічається віч-на-віч із HR-менеджером. Такий формат — це не просто розмова за чашкою кави, а важливий інструмент для розвитку команди.

Мета кожного спілкування — зрозуміти рівень взаємної задоволеності від спільної роботи. Зокрема, дізнатися, що саме зробить того чи іншого працівника щасливішим і продуктивнішим. Зустрічі допомагають ще й розкрити потенціал людини: поставивши правильні запитання (про процес роботи, задоволеність, результати, плани, мотивацію), можна зрозуміти, що фахівець виріс зі своєї посади та запропонувати підвищення.

Завдяки спілкуванню виявляємо свої сильні й слабкі сторони як роботодавця. Слабкі аналізуємо і, якщо можливо, виправляємо.

І, звісно, HR-аналітика — те, на що ми звернули увагу. Поділюся кількома ключовими показниками.

Плинність

Q1 2020 р.: 33%
Q1 2021 р.: 5,79%

Q2 2020 р.: 35,4%
Q2 2021 р.: 10,3%

Рейтинг DOU

  • Липень 2020 р.: 78,3%.
  • Липень 2021 р.: 95%.

Задоволеність персоналу

  • Січень 2020 р.: 68%.
  • Січень 2021 р.: 90%.

Об’єднувати людей за знаннями та звільняти від бюрократії

Підтримка всіх описаних процесів вимагає збалансованої та комплексної організаційної структури компанії.

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

Тому ми об’єднуємо людей за технологіями (наприклад, iOS, .NET тощо). Керують такими командами тимліди — це досвідчені розробники, які бажають розвиватися у сфері people management.

Розвиток — наша головна цінність. Вважаю, що колективи під керівництвом грамотного експерта-ментора розвиваються швидше. Чому? Хоча б тому, що до нього завжди можна звернутися по допомогу. Менеджер не змінюється від проєкту до проєкту, завдяки чому постійно вдосконалює та розвиває кожного учасника своєї команди як інженера.

Хоч така структура була давно, але бракувало прозорості в очікуваннях: виникали складнощі в комунікації, затримки у розв’язанні питань та робочих моментів. Щоб усунути проблему, протягом 2020 року ми:

  • описали зони відповідальності й обов’язки для всіх посад, щоб чітко окреслити коло завдань для кожного працівника;
  • усунули непотрібну бюрократію. Це дало можливість командам відчувати ще більшу відповідальність за результат і самостійно ухвалювати рішення;
  • найняли тимлідів на позиції, де їх не вистачало, а також поповнили структуру грамотними розробниками та менеджерами.

Інше запитання: а як усі ці менеджери-«технарі» керують людьми й до того ж досить успішно? Я зрозумів, що до 2020 року ми «виїжджали» суто на їхніх талантах і здобутому досвіді.

Однак якісні зміни повинні починатися зі структурованих знань, тому ми почали навчати менеджменту. Протягом трьох місяців у межах курсу «Свідомий керівник» від бізнес-тренера Галини Воропаєвої ми провели 10 тренінгів: пропрацювали всі управлінські компетенції — від планування до керування змінами. Курс закінчувався сертифікацією, тож тепер увесь наш менеджмент — сертифіковані фахівці.

Проєктами мають керувати менеджери, а не інженери

До 2020 року я вважав, що проєктами краще керують інженери, ніж відповідні менеджери. Адже саме розробники достеменно знають і розуміють технічний бік проєкту і можуть регулювати цей процес на будь-якому етапі.

Але це викликало додаткові проблеми у комунікації та загальну плутанину. Важко одночасно забезпечувати якісну розробку програмного забезпечення і спілкуватися з клієнтом про його потреби, розв’язувати нетехнічні питання. Це дві повноцінні ролі на проєкті з різними soft та hard навичками.

Тому в середині 2020 року ми виділили команду проджект-менеджерів, кожен з яких закріплений за конкретним проєктом. Саме ці фахівці відповідають за формування ціннісних стосунків між компанією та клієнтами. Зокрема, вони забезпечують необхідну якість сервісу, створюють плани розвитку проєктів і керують ризиками.

Завдяки цьому нам вдалося перейти до прозорішого виробництва: всі артефакти та інформація накопичується та поширюється у команді за допомогою таких інструментів, як Jira та Confluence. Це значно спрощує процес комунікації та допомагає швидко отримувати повну картину стану проєкту.

Зрештою ми сформували матричну структуру компанії: організаційні питання та питання персонального розвитку вирішують тимліди технологічних команд, а все, що стосується проєктів, — проджект-менеджери.

Прозора система розвитку та мотивації

Свого часу я помітив, що процес оцінки персоналу (Performance Review) не працює так, як хотілося б: ми не могли відстежувати аналітику й контролювати процес розвитку команди.

Вирішили все систематизувати. Ми виділили чотири цикли для проведення оцінки: січень, квітень, липень і жовтень. Усі працівники знають, коли відбувається Performance Review, тому можуть підготуватися заздалегідь, за потреби поставивши запитання своєму тимліду або HR-команді. Після кожної оцінки людина отримує особистий план розвитку (Personal Development Plan) із чіткими цілями та строками, який регулярно оновлюється. Це підвищує рівень мотивації та забезпечує кар’єрний розвиток кожному учаснику команди.

Завдяки значному й успішному досвіду виробництва у галузі фінансових технологій ми можемо якісно навчати та скеровувати нашу команду. Тому 2–3 рази на місяць почали проводити зовнішні та внутрішні лекції з різних тем — від загальних, потрібних усім розробникам, до вузькоспеціалізованих.

Навесні ми відродили традицію хакатонів. На них працівники можуть створювати продукти, якими користуватимуться всередині компанії (наприклад, бот для замовлення їжі в офіс).

Також цього року плануємо запустити профільний курс у галузі фінтеху, щоб розширити кругозір як нашої команди, так і фахівців, які потенційно можуть стати її частиною.

Зауважу, що досягти кардинальних змін неможливо одному. До цього варто йти разом. Всі повинні не тільки розуміти та виконувати задачі, а ще й мати спільні цінності та прагнути перетворень на краще. Крок за кроком у ITOMYCH STUDIO вибудовується саме така команда.

Головне — вчасно визнавати свої помилки

Озираючись у минуле, я з впевненістю можу сказати, що наша компанія пережила тотальну трансформацію. Шлях був непростим, і ми продовжуємо рухатися у цьому напрямку.

З власного досвіду додам, що помилятися — нормально, незалежно від того, якої сфери це стосується: бізнесу, навчання чи способу життя.

Головне вчасно визнати свої помилки та невдачі, оскільки це веде до самовдосконалення. Відтак провести самоаналіз і вибудувати чіткий план дій. Результати не змусять себе довго чекати, адже шлях змін — завжди на краще. Важливо на цьому етапі відстежувати прогрес, кількісні показники, порівнювати їх з попередніми та впевнено рухатися вперед.

А ще, які ситуації не траплялися б, важливо завжди підтримувати прозору комунікацію з командою, чітко формулювати цілі та завжди чесно говорити про власні потреби та про потреби компанії. Це — запорука довготривалої співпраці та пряма дорога до побудови dream team.

👍ПодобаєтьсяСподобалось29
До обраногоВ обраному17
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Вирішили все систематизувати.
2–3 рази на місяць почали проводити зовнішні та внутрішні лекції з різних тем
ми провели 10 тренінгів, тож тепер увесь наш менеджмент — сертифіковані фахівці

і все це назвали

усунули непотрібну бюрократію

Ніхто так «ефективно», наполегливо, безкінечно і на 136% успішно не бореться з бюрократією, як бюрократи. Ви ще з корупцією почніть боротися :)

Задоволеність персоналу
Січень 2020 р.: 68%.
Січень 2021 р.: 90%.

Сова — ефективний менеджер!

Вот честно скажу, с подозрением отношусь к компаниям, которые хотят от всех какого-то абстрактного саморазвития. Обычно это либо:

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

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

Если с вариантом «а» все понятно, валить надо из таких контор (главное, вовремя понять, куда ты попал), то с вариантом «б» есть много раздражающих моментов:

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

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

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

Оправданное исключение — внятная и обозримая цель: например, работаешь с фреймворком А, стало известно, что через месяц заходит проект с фреймворком Б и у тебя есть шанс и желание туда перейти, соответственно, учишь фреймворк Б.

Хорошие новости — часто всю эту канитель переводят в формальность.

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

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

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

тебя берут за наличие какой-то экспертизы и готовы платить оговоренные деньги, ты прошел испытательный срок, значит ты компанию устраиваешь. Зачем еще морочить голову?

За 5 лет в одной и той же компании у меня сменилось 3 проекта и на всех них нужна была слегка разная экспертиза. Проекты имеют тенденцию заканчиваться, урезать команды, закрываться итп. Сотрудник которого можно перевести с одного на другой проект (к примеру если это фронтендер то с Реакта на Ангуляр) с точки зрения бизнеса гораздо более выгоден, чем который сидит в одном фреймворке 5 лет и ничего больше не изучает влево-вправо, и не хочет. Потому что поиск нового человека на рынке занимает время и деньги, а новые заказчики часто хотят команду «на вчера».

Сотрудник которого можно перевести с одного на другой проект (к примеру если это фронтендер то с Реакта на Ангуляр) с точки зрения бизнеса гораздо более выгоден, чем который сидит в одном фреймворке 5 лет и ничего больше не изучает влево-вправо, и не хочет. Потому что поиск нового человека на рынке занимает время и деньги, а новые заказчики часто хотят команду «на вчера»

Именно так. Просто это подается под соусом заботы о сотруднике, а не экономии на найме, и часто узнаешь, что от тебя еще хотят саморазвития с экзаменами постфактум.

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

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

Я не считаю обучение игрой с нулевой суммой, это не яблоко — у тебя было, компания забрала. Мы не outstaff компания, где единожды пройдя критерии ты в одном проекте, а если он закончился — ты уволен. Я понимаю, почему многие персональные планы оторваны от реальности либо просто формальный процесс. Мы стараемся максимально приблизить их к потребностям на проектах. Небольшой пример:
imgur.com/a/enCCGWZ

При таком подходе, это технический менторинг, который помогает более гармонично и эффективней развиваться. Мы не ищем сотрудников на один проект на outstaff, мы делаем сложные fin tech решение, где нам важно обоюдно развиваться в паре «компания <-> сотрудник».

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

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

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

У вас была раньше текучка персонала в 140% за год ?
Может, это не совсем текучка по причине ухода персонала, а просто когда проект заканчивался — всю команду увольняли, а теперь у вас есть что-то типа бенча и человек после того как доделал свою работу помогает другим пока нового проекта для него нет ?

P.S. У вас сайт немного поломался и судя по кешу гугла в таком состоянии он уже давно www.site-shot.com/O9BlhuYWEeuF1AJCrBEABg

Спасибо, комментарий!
1. За непростой для нас 2020 год основная текучка была в первые пол года, что как раз и сравнивается в статье. В сумме годовая была примерно 80%.
2. Правила бенча не менялись, команды по окончанию проекта не увольняли. Мы всегда работаем с подходом, хороший специалист — всегда востребован и у нас довольно легкая миграция с проектов, которые заканчиваются в новые. Субъективно, cultural fit — то, что нам не хватало.
3. Спасибо за найденый баг на сайте, его уже подправили :)

1. За непростой для нас 2020 год основная текучка была в первые пол года, что как раз и сравнивается в статье. В сумме годовая была примерно 80%.

OMG. Так это действительно было 30% за квартал? Я сначал подумал что это было с пересчетом на год...

Интересно, а как вам вообще удалось с такой текучкой заканчивать свои проекты?

У вас была раньше текучка персонала в 140% за год ?

Гугли итальянский сайт :)

От про «систему розвитку та мотивації» хотілося б більше подробиць. Як ви проводите це Performance Review, це що саме? Впливає на зарплату, бонуси ...? План розвитку... також дуже цікаво — це у робочий час людина щось нове вивчає, або навпаки вдома, або як ...? Загальне супер-питання для усіх — «як оцінити роботу розробника», я розумію ви якось це для себе вирішили ?

Дякую за коментар.

Я б сказав, що неможливо вирішити усе, але ми дуже сильно систематизували свої подходи. Про систему розвитку і мотивації — звучить як тема для наступного топіка в цьому блозі :)

У нас в компанії видиляється час, для вивчення нових технологій, але ми очикуємо і використання персонального часу на отримання знань для підвищення компенсації.

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

Меня только смутили 1:1 с HR командой раз в месяц. Зачем они нужны если за развитие команды отвечает тимлид? Или это QC для лидов?

Дякую за коментар, так, це робота двох фахівців — TL та HR.
TL відповідає за технічний розвиток та мотивацію своєї команди. HR перевіряе мотивацію, та відповідає за розвиток soft skills.

адже шлях змін — завжди на краще

Очевидно, що це не завжди так.

Дякую за коментар.

Ми знаходимося у дуже динамічному світі. Треба постійно адаптуватися та змінюватися для того, щоб навіть залишатися на місці. Будь яке заморожування змін — завершиться зламом системи з вирогідністью 1. Будь які зміни, можуть привести як до поганих, так і до кращих результатів, але тількі вони можут вирішити проблему «зламу системи з вирогідністью 1».

Простий приклад с віддаленую роботою. Можно робити вигляд, що всі повернуться працювати в офіси. Але це вже не можливо у тому обсязі, як до ковіда. Якщо компанія не зміниться у своему ставленні до ремоут — це накопичення протирічь з працівниками, які за часом можуть привести до компанію до краху.

Крім рекрутингу, нам вдалося налагодити й інші HR-процеси. Наприклад, у середньому раз на місяць кожен учасник команди зустрічається віч-на-віч із HR-менеджером. Такий формат — це не просто розмова за чашкою кави, а важливий інструмент для розвитку команди.

«в середньому — раз на місяць» це мабуть не дуже хороша формальність. Мабуть краще це робити по аналогії з обкаткою нового транспортного засобу, тобто:
— перший тиждень
— перший місяць
— закінчення випробувального періоду
— перших пів року
— і т.д. в геометричній прогресії

Дякую за коментар.

У тексті наведено спілкування с HR після завершення trial періоду. При процессі «входу» у компанію, HR приділяють набагато більше часу спілкуванню с новачками. У компанії ми розділяємо 3 процесси:
— вхід у компанію
— вхід в команду
— вхід до проекту

Я вважаю, що якщо коллега, який пропраціював у компанії більше 5 років, все ж таки повинен мати 1-1 c HR (а не раз на 5 років). Це можливісь мати діалог про не технічні питання та взагалі про стан речей у компанії.

рекрутер оцінює набір навичок, знань і поведінкових характеристик, потрібних для певної посади. У нього є право вето: якщо він розуміє, що людина нам не підходить, може відмовити їй навіть без технічної співбесіди. Такий підхід значно підвищив якість пошукачів, що доходять до технічного інтерв’ю

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

Рекрутери не повинні мати права вето в тому, в чому вони не компетентні.

Костя, дякую за коментар. В нашому випадку це історія про баланс та співпадіння цінностей. Кандидат може бути неперевершенним профі та якщо ми розуміємо, що він не поділяє нашу культуру: неважливо інтроверт він, чи екстраверт: це червоне світло для наших рекрутерів. Ми не тестуємо на спілкування, ми перевіряємо навички. Такий кандидат банально не знайде спільну мову з рештою команди (не лише технічною).

Маю досвід рекрутінг процессу без тестування софт навичок — результати можно побачити у цифрах:

Плинність
Q1 2020 р.: 33%
Q1 2021 р.: 5,79%
Q2 2020 р.: 35,4%
Q2 2021 р.: 10,3%

Задоволеність персоналу
Січень 2020 р.: 68%.
Січень 2021 р.: 90%.

Підписатись на коментарі