Кількість спеціалістів у топ-50 за півроку виросла з 58 тисяч до майже 63 тисяч. Кількість технічних спеціалістів вже перевищує 50 тисяч. У рейтингу з’явилися нові обличчя, а EPAM і SoftServe перетнули позначку «7000 фахівців». На ці дві компанії припадає 37% росту липневого топ-50.

З січня по липень 2019 року кількість фахівців зросла на 3410 (7,5%) у топ-25 і 4453 (7,6%) у топ-50 порівняно з другим півріччям 2018-го.

Зростання загальної кількості спеціалістів в 25 найбільших ІТ-компаніях України

Відносні показники темпів зростання

Кількість технічних спеціалістів у топ-50 — вже понад 50 тисяч, із них майже 40 тисяч працює у 25 найбільших ІТ-компаніях. Якщо дивитися на динаміку, то за останні п’ять років кількість технічніх спеціалістів у топ-25 виросла майже вдвічі.

Щодо відносної кількості, то частка технічних фахівців за п’ять років збільшилася незначно — десь на 4 п.п.

Зростання загальної кількості технічних спеціалістів в 25 найбільших ІТ-компаніях України

Зростання «великої п’ятірки» за перше півріччя 2019-госклало 7% (1617 фахівців). Усього в топ-5 працює 25 482 спеціалісти, що складає 41% від загальної кількості топ-50.

Динаміка росту топ-5 компаній за період з серпня 2011 по січень 2019

Лідер рейтингу — EPAM — за перші 6 місяців 2019 року збільшився на рекордні 900 спеціалістів. І перетнув відмітку у «7000 фахівців». За інформацією компанії, запорукою росту є робота з освітнім сегментом. Сьогодні EPAM співпрацює з 20 університетами, має 15 лабораторій та до 3000 випускників щороку, частина з яких починає співпрацю з EPAM. Інвестиції компанії у цей сектор складають мільйони доларів на рік. Така активність є важливим джерелом нових кадрів для компанії. Зростання відбувалося в усіх українських локаціях, найбільшу динаміку продемонстрували Київ, Харків та Львів. Основні спеціальності фахівців, які почали співпрацю з EPAM: Java/Big Data, Front-end, Automated Testing, .NET, Cloud/DevOps.

Компанія SoftServe, що посідає друге місце рейтингу, також за підсумками першого півріччя подолала відмітку у «7000 фахівців». Компанія збільшилася на 749 спеціалістів, із них 711 — технічні. У першому півріччі 2019 року SoftServe також інвестувала у оновлення університетських програм ІТ-спеціальностей та відкрила низку нових форматів роботи зі студентами. Найбільш популярними напрямками серед нових спеціалістів були DevOps, WebUI, Python, Big data, Java та інші.

Третю сходинку впевнено займає GlobalLogic, яка продовжує активно зростати і в 2019 році (+214 спеціалістів). Нагадаємо, що компанія за підсумками 2018 року обігнала Luxoft і стала третьою найбільшою ІТ-компанією в Україні. У компанії ріст пов’язують із розвитком існуючих проектів та запуском нових у таких сферах, як телекомунікації, автомобільна промисловість, медицина, медіа, комерція тощо. Для підтримки росту GlobalLogic за минулий рік інвестувала $1,5 млн в професійний розвиток та підвищення кваліфікації фахівців у Центральній та Східній Європі. Значна частина цих вкладень припадає на українських інженерів.

Luxoftпосідає четверту сходинку і за перші 6 місяців 2019 року демонструє рекордну негативну динаміку. Кількість спеціалістів в компанії зменшилася на 250 спеціалістів, при цьому кількість технічних фахівців зменшилася лише на 35 осіб. В компанії зазначають, що в першому півріччі відбулося виведення операційних функцій на зовнішніх сервісних провайдерів. Нагадаємо, що в січні цього року DXC Technology купив Luxoft за $2 млрд, а також нещодавно стало відомо про зміну керівного директорав Luxoft Ukraine.

Ciklumзамикає п’ятірку лідерів. Після рекордного зростання у 2018 році, схоже, компанія скинула оберти: за перше півріччя лише +4 спеціалісти.

Окрім EPAM, SoftServe і GlobalLogic, за півроку на 100 спеціалістів збільшилися ще 8 компаній: NIX (301 спеціаліст), Intellias (301), DataArt (173), Intetics (169), ZONE3000 (159), Genesis (150), Lohika (138), AMC Bridge (109).

Лідери росту, січень — липень 2019 (топ-11)

Продовжує суттєво зростати Intellias. За підсумками 2018-гокомпанія збільшилася на 400 фахівців і вже за перші півроку 2019-гоще на 300. У компанії пов’язують це із запуском нових та розширенням існуючих проектів. Цього року Intellias відкрив нові центри розробки в Івано-Франківську та Кракові, при цьому далі активно розвивалися розробницькі офіси у Львові, Києві, Харкові та Одесі. За останні півроку серед нових спеціалістів компанії найчастіше можна зустріти фахівців з Java, C++, JavaScript, React Native, DevOps тощо.

У DataArt зростання майже на 200 спеціалістів також пов’язують з ростом проектів, розширенням офісів у Харкові, Києві, Львові та Дніпрі. В основному зросли флагманські технології Java, .NET, JavaScript, QA (Automation і Manual), також спостерігається сплеск попиту на DevOps, Node.js, Security Consultants і Business Analyst.

Активне зростання у першому півріччі дозволило Intetics повернутися до топ-50 одразу на 40 місце.

Динаміка зростання п’яти компаній-лідерів росту

Суттєве збільшення Onseo (+200 спеціалістів) пов’язане з уточненням даних: раніше компанія не подавала офіційну інформацію щодо кількості спеціалістів.

У рейтингу з’явилося дві нові компанії — Ubisoft (32 місце) і Autodoc (34 місце).

Окрім Luxoft, негативну динаміку продемонстрували Terrasoft, группа компаній «Парус», Tickets UA і Dev-Pro.net. В останній кількість фахівців зменшилася на 30%, через що компанія не потрапила до рейтингу. Це було пов’язано зі структурними змінами на стороні клієнтів і отриманням інвестицій з їхнього боку. Зараз Dev-Pro.net перебуває на етапі стабілізації, активізувалися біздев-активності, і компанія готова переходити у фазу поступового зростання.

Зменшення кількості спеціалістів у Terrasoft пов’язане з уточненням їх кількості саме в українському офісі компанії. З цієї ж причини до рейтингу не увійшла Provectus. В Tickets UA негативна динаміка сталася через проведення аудиту деяких процесів, після чого частину з них автоматизували, а частину — передали на аутсорс. Більшість співробітників, які покинули компанію за перше півріччя 2019 року, — це адміністративний персонал.

11 компаній з топ-50 відкрили нові офіси у першому півріччі

З січня по липень 2019 року 11 компаній відкрили нові офіси як в Україні, так і за її межами. Це на дві компанії менше, ніж за підсумками другого півріччя 2018 року. Щодо українських локацій — нові офіси з’явилися в Києві, Львові, Харкові, Івано-Франківську й Луцьку. За кордоном — у Польщі, Болгарії, Вірменії та США.

42 компанії з топ-50 мають офіси у Києві. У Львові на 4 компанії з топ-50 більше, ніж у Харкові (24 проти 20). В Одесі — 15 компаній, у Дніпрі — 12, у Вінниці — 10. В інших українськіх містах — представлено менше 5 компаній.

Плани щодо росту й релокації до кінця 2019-го

11% компаній не планують зростати до кінця року (у січні таких було лише 4%). Проте більшість все ж таки має на меті збільшення не менше ніж на 50 фахівців. Щодо релокації, то тут все без змін — більшість компаній не планує вивозити спеціалістів з країни.

Плани компаній щодо розширення персоналу на найближчі півроку

Графік побудовано на основі відповідей 45 компаній з топ-50

Плани щодо релокації спеціалістів за межі України в найближчі півроку

Графік побудовано на основі відповідей 45 компаній з топ-50

Повна версія топ-50 і дані минулих рейтингів доступні на сторінці jobs.dou.ua/top50.

Інфографіку підготував Ігор Яновський.

Підписуйтеся на Telegram-канал про українське IT «Редакція DOU», щоб не пропустити цікаві новини, статті, обговорення.

Всем привет! Меня зовут Саша Емельянов, я продакт-менеджер. Свой путь в менеджменте я начал с того, что открыл собственный стартап, привлек инвестиции от французского бизнес-ангела. Эта было диджитал-агентство, предоставляющее SMM и маркетинговое сопровождение для малого и среднего бизнеса в Украине. После кризиса 2013–2014годов небольшие компании, для которых, будем честными, SMM — не дело первой важности, начали отказываться от наших услуг; поэтому мы решили прекратить свою деятельность, оставшись с инвестором в очень хороших отношениях.

Дальше была стажировка в Гонконге, работа в продуктовых (и не очень) украинских компаниях, а затем MacPaw, где я провел последние полтора года до переезда. До сих пор всей душой люблю эту компанию и искренне считаю ее одной из лучших в украинском IT: таких людей, культуру, прозрачность, подходы нужно еще поискать. В MacPaw я с командой сделал с нуля приложение Gemini Photosи заскейлил его до $1M annual recurring revenue. Продукт получился успешным, и я почувствовал, что могу двигаться дальше.

В апреле в ленте Facebook промелькнула вакансия продакт-менеджера в лондонском офисе Badoo. И вот я уже почти год живу и работаю в Лондоне.

Собеседования

Badoo (несколько недель назад группа получила новое название — MagicLab) — большая компания с огромной пользовательской базой. Кроме самого Badoo, в структуру компании входят: Bumble — один из самых быстрорастущих дейтинг-стартапов мира, Lumen — дейтинг для тех, кому за 50, Chappy — гей-дейтинг. Суммарная аудитория продуктов составляет более 500 миллионов пользователей. О компании и продукте я слышал давно (Badoo довольно популярен в Украине). Когда-то сам зарегистрировался как пользователь и был очень воодушевлен возможностью поработать над продуктом «с другой стороны».

Собственно, во время работы в MacPaw я отправил лишь одно резюме — в Badoo. В начале мая 2018 года со мной связалась рекрутер посредством электронной почты. Она прислала список вопросов о текущей и желаемой заработной плате, готовности к переезду, необходимости спонсирования визы и периоде уведомления об увольнении. После согласования деталей мы договорились о скрининговом интервью. На скрининге общались о моем опыте, A/B-тестировании, готовности к релокейту. Наверное, первое интервью и было самым сложным: я чувствовал, что мой уровень английского слабоват. Возможно, рекрутер была в хорошем настроении или повлияло достаточно большое количество русскоязычных в компании, и я прошел на «продуктовые интервью».

Дальше было четыре интервью с продакт-менеджерами и продакт-лидами по Skype плюс тестовое задание.

Тестовое задание состояло из двух частей. Первая — предложить свои гипотезы по увеличению вовлечения/ретеншена пользователей, вторая — пропитчить приложение, которое я бы хотел создать. Самой сложной оказалась вторая часть, в которой я довольно долго просчитывал юнит-экономику и монетизацию приложения, создавал UI/UX, оформлял 9 страниц пита. Перед отправкой тестового перечитал письмо от рекрутера. Оказалось, рекомендуемый объем питча — 1 страница. Но ругать за подробную презентацию никто не стал.

Сами интервью были интересными, хоть и довольно сложными. Вопросы зачастую имели практическое направление, вроде «что бы ты сделал, если...». Например, «представь, что тебе нужно увеличить reply rate женщин на платформе на 5%, что бы ты предложил?» или «7-dayретеншен-пользователь в Бразилии упал на 4%. Твои действия?». Таким образом оценивали подход к решению задач, «продуктовое мышление». Видимо, мои подходы совпадали с видением компании, и меня пригласили на финальное (как оказалось, нет) интервью в Лондон. Был конец июня.

Компания оплатила подачу документов на срочную визу с премиум-аппойнтментом (около 450 евро), перелет, проживание в отеле, трансфер до отеля и обратно. После прилета был свободный день и вместе с тем — мой первый день в Лондоне. Я был во многих городах, но Лондон понравился с первого взгляда. И мне захотелось здесь жить.

Финальные интервью начинаются в 10:30 утра и длятся до 13:30 с перерывом на обед. В 9:45 я уже стоял у офиса и дрожащими руками держал горячий кофе в 30-градуснуюиюньскую жару.

Расписание финального дня

На финальном дне были интервью с тимлидами дизайна, мобильной разработки, продуктовой команды. Последними должны были быть интервью с VP Product и фаундером компании, но в тот день мы не смогли поговорить. Вернувшись в Киев без ответа, я уехал на конференцию и в отпуск в США. Уже оттуда, практически через месяц после финального лондонского интервью, мне удалось пообщаться с VP Product. Это было, наверное, самое жесткое интервью среди всех, которые я проходил, но чувствовалось, что мы нашли общий язык.

Однако снова фаундер компании был занят, и финальное интервью откладывалось. Я и пожаловался VP Product на то, что никак не получу ответ (а хотелось бы). Произошло чудо, и уже через десять минут — в свой выходной день — мне звонил Андрей Андреев, основатель Badoo. Тогда я впервые понял, что шансы есть. На следующий день я получил оффер.

Переезд

Для переезда в Великобританию вам понадобится спонсорство визы от компании, которая вас нанимает, зарплата от 30 000 фунтов стерлингов в год (фактически чем больше, тем лучше) и наличие вашей профессии в shortage occupation list. (Один английский фунт стерлингов ≈ 32 грн.) Также нужно сдать IELTS минимум на 4 балла (что очень мало, и если вы прошли хотя бы одно интервью на английском, то IELTS уже, считай, сдали), апостили сертификатов о женитьбе (если есть жена), сертификатов о рождении детей (если есть дети), пройти TB-скрининг (флюорографию), заполнить формы VAF9для себя и всех, кто едет с вами, сделать выписки из банков о движении средств, выписки по заработной плате за последний год.

Компания помогает на каждом этапе и полностью финансирует ваш переезд. Больше всего времени занимает запись на IELTS, мне удалось записаться на 3 недели вперед. После получения всех сертификатов мы с женой подали пакет документов для релокейта, 2 недели нервно ждали решения — и получили рабочие визы.

Всего компания выделяет 8000 фунтов стерлингов релокейт-бюджета. Их можно тратить на перелеты, съем временного жилья, долгосрочную аренду (обычно это первый месяц плюс 6 недель залога), покупку необходимой мебели и техники. Эмпирическим путем выяснилось, что PlayStation и Apple Watch не входят в список необходимой техники, а вот пара 55-дюймовыхтелевизоров для просмотра Netflix в нем могут быть.

В течение недели после прилета необходимо зарегистрироваться в OVRO, через две — забрать BRP.

Жилье

Badoo предлагает на выбор жилье в отеле, через AirBnb, в апартаментах, корпоративных квартирах. Мы поселились в апартаментах, так как корпоративные квартиры были заняты. Стоимость апартаментов — около 120 фунтов стерлингов в сутки с разницей ±50 фунтов, в зависимости от ваших желаний и района. Изначально мы арендовали временное жилье на 2 недели, рассчитывая найти постоянную квартиру за это время. В Лондоне это довольно сложно, так что нам пришлось продлевать срок проживания еще на 2 недели.

Ситуация с поиском жилья осложнилась еще тем, что через 2 недели после моего прилета у команды продакт-менеджеров был запланирован тимбилдинг в Барселоне. По очень несчастливой случайности и при загадочных обстоятельствах я там потерял свой паспорт. Благо в Лондоне был второй загранпаспорт, через двое суток я уже находился в Мадриде с паспортом, где мне предстояла подача документов на новую entry clearance visa. Потратив неделю и 500 евро, я снова оказался в Лондоне. Все это время жена искала постоянную квартиру, и я вернулся уже в постоянное жилье.

В нашем шорт-листе были две квартиры: одна поприличнее, подороже, но подальше, а вторая дешевая, неплохая, но без излишеств, квартира в центре. Мы сделали оффер по обеим квартирам, но в первой нам отказали, хотя мы согласились с ценой и не выдвигали требований лендлорду (например, перекрасить стену, сменить ковролин или поставить диван, хотя так можно). Оставался второй вариант, где нам ответили утвердительно. После подписания контракта, внесения депозита в 500 фунтов, проверки моего дохода, истории проживания и, наконец, полной оплаты мы поселились в ex-council-квартире в первой зоне (центр Лондона), в 5 минутах ходьбы до станции метро с 4 ветками и в 10 минутах ходьбы до Baker Street. От работы до дома и мне, и жене — 20 минут, все удобно.

За аренду платим 1352 фунта стерлингов в месяц, что по лондонским меркам мало. Как я уже заметил выше, это ex-council-дом (бывшее социальное жилье). Сейчас квартира принадлежит частным владельцам, несколько лет назад сделан ремонт, но все же контингент таких домов часто бывает специфичным. Скажем так, англичан в нашем доме я не замечал. Колорита району добавляет тот факт, что Edgware Road (наш район) называют маленьким Каиром: это самый арабский район Лондона. Первые несколько недель слегка шокирует то, что, зайдя в кофейню, можно не увидеть женщин без паранджей, но к этому быстро привыкаешь.

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

Из преимуществ — огромное количество вкуснейшей еды в радиусе 500 метров, порядка 20 различных продуктовых магазинов в пяти минутах ходьбы (довольно дешевые Tesco, Sainsbury’s, качественный Marks & Spencer и арабские магазины всех цветов и расцветок), большой рынок с вкуснейшими фруктами. За один фунт (32 гривны) можно купить на выбор:

• 1 большой ананас;
• 3 — 5 авокадо;
• 1 — 2 манго;
• 2 — 4 дыни;
• лоток клубники/винограда/черники/малины.

Отдельное место занимают вкуснейшие огромные арбузы (а не те мелкие, что в сетевых супермаркетах). Арбузы, судя по всему, предмет роскоши: цена за 15 кг будет равняться примерно 12 фунтам, или 384 грн. Сезона фруктов как такового нет, все они доступны зимой за ту же цену, но, стоит признать, летом качество лучше.

За коммунальные услуги мы платим около 180 фунтов в месяц, а именно:

• council tax (муниципальный налог) — 45 фунтов;
• интернет — 25 фунтов;
• вода — 22 фунта;
• газ и свет — 65 фунтов;
• TV license — 15 фунтов.

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

Council tax очень варьируется от района к району, мы живем в Westminster — районе с самым дешевым налогом. В Richmond, например, базовый налог в 2 раза выше. Недвижимость в Англии разделена на восемь ценовых диапазонов (A — H), в зависимости от цены, за которую она могла бы быть продана в апреле 1991 года. Чем дороже недвижимость на тот момент, тем больше council tax.

Как устроена работа

Всего в лондонском офисе компании работает около 600 человек, есть и другие офисы, но продуктовая команда целиком находится в Лондоне. Сейчас в продуктовой команде только 12 человек, которые занимаются всеми продуктами компании. С таким количество юзеров, фич и разработчиков работа продакт-менеджера здесь никогда не бывает скучной. В компании data-driven-культура: все решения принимаются на основе метрик и данных, продакт-менеджеры тесно взаимодействуют с продакт- и дата-аналитиками. Моя роль в компании — работа над ревенью и value proposition, но сейчас также занимаюсь переработкой механизма взаимодействия пользователей в Badoo.

Все довольно рано приходят в офис, хорошим тоном считается быть на рабочем месте до 10:00, но жестких ограничений по времени нет. Ухожу до 19:00, искренне верю, что героические овертаймы непродуктивны.

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

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

Пример тематического меню на день

На ужин приезжают доставки из различных заведений, опять же каждый день разные. Помимо основного питания, все холодильники под завязку забиты едой и напитками: роллы, сэндвичи, салаты, йогурты, софт-дринки. Есть автоматы для апельсинового фреша. Конечно же, все бесплатно. Я стараюсь не увлекаться бесплатной едой, о чем говорят весы (за время жизни в Лондоне удалось сбросить около 13 килограммов).

В список бенефитов компании входят: ежедневные массажи, стрижки и маникюр в офисном мини-салоне, медицинская и стоматологическая страховка, ваучеры для ухода за зрением, уроки английского и русского, tastecard (карта, которая дает 50% скидки или «2 for 1» в более чем 1000 заведениях Лондона), пенсионные накопления, туристические страховки и годовой транспортный проездной, который покупает компания, ежемесячно вычитая часть его стоимости из заработной платы (так получается дешевле, чем ежемесячные проездные).

Общие впечатления

Бытовая вежливость на порядок выше, чем в Украине. Через неделю автоматически начинаешь говорить «sorry», даже когда тебе наступили на ногу, несмотря на то, что я добираюсь домой со станции Oxford Circus — одной из самых загруженных станций лондонского метро в часы пик. Люди улыбчивы, более расслаблены. Несмотря на темп жизни мегаполиса, могу сказать, что Лондон ощущается как более спокойный, безопасный.

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

IT-рынок

Все крупные мировые компании — Amazon, Google, Facebook, Badoo, конечно же, Skyscanner, Spotify и другие — имеют офисы в Лондоне. Кембридж уже называют новой Кремниевой долиной, настолько активно развиваетсяотрасль. Лондон является лидером в Европе по количеству венчурных фондов, инвестиций, денег бизнес-ангелов. Здесь наибольшее количество стартапов в Европе, а также много продуктовой разработки. Это крупнейший IT-хаб континента. В общем, Лондон — одна из столиц мира, его финансовый и IT-центр.

К тому же на основе рассказов друзей, которые работают в Кремниевой долине, могу утверждать, что жизнь в Лондоне имеет ряд преимуществ. Я работаю в центре города, за 20 минут доезжаю в офис. Уже через 15 минут после выхода из офиса могу быть в одном из сотен пабов Сохо, в театре или просто кататься на кораблике по Темзе. В пешей доступности находится все, что можно себе представить. Не нужно, как в США, тратить час времени на транспорт. Тамошняя жизнь более заточена на работу, в Лондоне же удается соблюдать work-life balance.

С налогами ситуация немного иная. Здесь нет ФОП и пяти процентов налогов. Прогрессивный income tax достигает 45%, плюс я плачу около 500 фунтов в месяц взносов в национальную систему страхования (national insurance).

Таблица налогов

По лондонским меркам у меня высокая зарплата, по IT-меркам — не самая высокая. Средняя зарплата в Лондоне составляет около 35 000 фунтов стерлингов в год, судя по предложениям из LinkedIn, средняя зарплата Senior Product Manager — от 60 000 до 100 000 фунтов стерлингов в год (в диапазон которой попадает и моя). Конечно, Лондон не предлагает легких денег. Если вы senior и получаете в Украине 5000 долларов США в месяц «чистыми», в Лондоне у вас будет, грубо говоря, 5000 фунтов стерлингов, но по покупательной способности и в отношении стоимости жизни (cost of living) это совершенно разные деньги. Однако потолок зарплаты в Украине — 7000–8000долларов США в месяц, здесь его нет совершенно. Вариантов для развития масса, на худой конец средней руки контрактор может рассчитывать на 500 фунтов в день. В Лондоне высокий спрос на хороших специалистов, в месяц специалист получает от 20–30предложений в LinkedIn, но, по рассказам местных, конкуренция соответствует спросу.

Стоимость жизни

Мы с женой работаем, но живем не на одну зарплату: у нас есть крупнейший украинский Telegram-канал IT-вакансий Wanna Workс более чем 25 000 подписчиков, который приносит ощутимые, даже по меркам Лондона, деньги. Решаясь на переезд, мы сомневались, удастся ли нам в Лондоне поддерживать привычный для нас «киевский уровень жизни» с сырами по 500. В результате большой разницы между двумя столицами в уровне жизни мы не заметили.

Увеличилась основная статья расходов — аренда жилья, в Украине мы жили возле Крещатика, 500 долларов за однокомнатную квартиру с террасой. Здесь, как сказано выше, аренда дороже в 3 раза при сравнимом уровне заработной платы. Все остальное зависит только от ваших желаний, прелесть Лондона в его разнообразии. Подстричься можно как за 6, так и за 60 фунтов, покушать как за 5, так и за 200 фунтов с человека. В целом на 4–5тысяч фунтов в месяц в Лондоне можно жить, ни в чем себе не отказывая. Практически каждый день мы ходим в пабы и заведения, в театры, кино и на митапы.

Цены в супермаркетах не сильно отличаются от украинских, кроме дорогого алкоголя и софт-дринков. Стоимость собственно продуктов питания чаще всего ниже украинских.

Медицина

Полгода мы прокрастинировали перед тем, как записаться в клинику к GP. Недавно заболело горло, захотел пойти к врачу. Визит к терапевту назначили только через 13 дней. Можно прийти и без договоренности, но придется в порядке живой очереди ждать с 9 утра и пропускать рабочий день. Неудивительно, что в Англии приобретает стремительную популярность стартап Babylon Health, который сокращает время ожидания (в приложении можно зарегистрироваться на удобное время). Я зарегистрировался и через день (правда, в 12 ночи) созвонился по видеосвязи с GP. Все, что она посоветовала, это добавить к таблеткам, которые пил, еще и парацетамол.

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

Транспорт

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

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

Лондонское метро off-peak

Кроме подземного метро tube, есть overground — наземное метро. Другие виды транспорта: автобусы, трамваи (последние — экзотика, есть только на юге города и далеко от центра). Много такси-стартапов: Uber, Bolt, ViaVan, Kaptn и другие. Поездка по центру на такси будет стоить 10–15 фунтов,если шейрить — 5–7 фунтов.Есть и подписки на такси: 4 поездки в день в будни с 6 утра до 9 вечера за 179 фунтов стерлингов в месяц, на работу можно ездить с комфортом. Такси от украинских отличаются только в лучшую сторону: стандартные авто Toyota Prius, Toyota Avensis, полно Mercedes.

В Лондоне шесть аэропортов, можно найти дешевые билеты (к сожалению, в основном только в будни: от 20 фунтов в две стороны на Ryanair). В Париж можно добраться за 2 часа и от 29 фунтов на поезде Eurostar (опять же, за 29 фунтов будет выезд во вторник в 11 утра). По Великобритании ездят хоть и не очень скоростные, но комфортные поезда. С two together railcard мы экономим ^⅓на всех железнодорожных билетах.

Погода

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

Плюсы — теплая зима со средней дневной температурой +6 — +7 градусов, минусы — летом могло быть потеплее. Весь июль, кроме heat wave, когда мы прогрелись до +38, температура держалась в районе +20 — +23 градусов, еще один минус — переменчивость погоды.

Погода в феврале 2019

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

Один из дождливых летних дней в Лондоне

В заключение

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

Хотел бы здесь остаться. Моя первая виза действует три года, после этого можно начинать понемногу готовиться к получению ILR (indefinite leave to remain) и веселому тесту Life in the UK.

Живя здесь, чувствую себя близко к Украине. Благодаря дешевым перелетам раз в несколько месяцев летаем в Киев на Wizz Air (около 60–70фунтов на двоих). Родители также приезжали ко мне уже несколько раз, поэтому расстояние не проблема. Но в целом планирование более чем на полгода вперед — штука неблагодарная, так что посмотрим, что интересного ждет впереди.

Бонус-контент

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

1. Если приезжаете на выходные, подпишитесь на Staycation, они присылают отличные офферы на лондонские отели со скидками до 50%. В основном дорого, но скидки приличные.
   
2. Перед поездкой оформите триал TasteCard за 1 фунт. TasteCard дает 50% скидки или «2 for 1» во многих заведениях, включая рестораны отелей Hilton.
3. В приложениях Karmaи Too Good to Goскидки на еду от 50 до 80%. Оба приложения борются с фуд-вэйстом, но, помимо спасения мира, вы всегда получаете свежие блюда по цене менее 5 фунтов.
4. При средней ценепинты пива в 5,19 фунта (166 грн.) Лондон не назовешь доступным городом, но сеть Wetherspoonsпомогает вернуть веру в Бога с ценами от 1,89 фунта за пинту каскового IPA (если чуть отъехать от центра) в одном из 105 заведений в Лондоне.
5. Приложение Mappy Hoursпокажет все счастливые часы в городе с коктейлями по £3-£6.
6. С приложением DUSKу вас каждый день будет бесплатный коктейль или пинта Guinness в одном из сотен лондонских баров, say no more.

За помощь в подготовке статьи благодарим Ярославу Тимощук

У цьогорічному портреті IT-спеціалістами з’ясували, що більшість фахівців знають англійську на рівні Intermediate та Upper-intermediate (по 34% відповідно) і лише 13% на рівні Advanced. Ми звернулися до викладачів англійської в IT-компаніях з питаннями: в чому саме виникають проблеми з англійською в IT-спеціалістів, які типові помилки трапляються, як їх виправляти й уникати надалі. У цій статті зібрали поради викладачів з 20 IT-компаній.

Проблеми у вивченні англійської

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

При цьому до практики говоріння IT-спеціалісти часто просто не схильні. Катерина Галас, викладач в ЕРАМ, відзначає: «Люди, що працюють в IT-сфері, як на мене, здебільшого стримані й небалакучі. І зовсім не тому, що сором’язливі чи невпевнені (застарілий неправдивий стереотип). Справа в тому, що вони прагнуть висловлюватися тоді, коли дійсно є щось доречне до теми. З одного боку, це прекрасне вміння — говорити стисло і про головне. З іншого ж, це створює труднощі у вивченні мови». Отож, як би не хотілося говорити, щоб навчитися це робити, треба саме говорити.

Ще одна поширена проблема — застій на рівні В1-В2:

«ІТ-спеціаліст вже вміє вільно висловлювати думки, може впевнено підтримати бесіду і потрапляє в „зону комфорту“. На цьому етапі, так званому Intermediate Plateau, словниковий запас і набір граматичних часів і конструкцій ще мізерні, але говорити вже вдається вільно. І тут головне — не розслаблятися і продовжувати вчитися. Поповнювати словниковий запас і урізноманітнювати граматичні конструкції». (Азам Ахмедов, ЕРАМ)

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

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

Олександра Пармон, викладач в DMarket, відзначає, що вивчення англійської — «it’s not just about the language, it’s about people and their culture». Можна вивчити всі правила й винятки з них, але якщо не навчимося приймати манеру спілкування, правила поведінки іноземців, то почуватися комфортно в англомовному середовищі не зможемо:

«Коли на робочій зустрічі члени команди обговорюють свої ідеї російською або українською мовою, найчастіше відповіді будуть такими: „так“, „ні“, „ні, це погана ідея“, „можливо“. А тепер уявіть таку ж зустріч, тільки англійською. Ви там почуєте: ’It sounds good’, ’We can go this way’, ’Let’s do it’, ’I think it’s a great idea’, ’Absolutely’,’ That’s right’ etc. Те, як в англійській говорять „ні“, взагалі можна порівняти з мистецтвом: ’Well maybe, but’, ’I see your point, but’, ’it’s a great idea, but’, ’why do not we try to find another way’.Цей список можна продовжувати. І це дуже звично для англомовних людей на відміну від іноземців».

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

Типові помилки

Невміння підтримати розмову

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

Юлія Носаль та Катерина Огбаідзе з Cross Cultural Communication Center в SoftServe наводять як приклад такий діалог (трапляється не часто, але чітко показує важливість не тільки знання мови, але і вміння правильно і доречно комунікувати):

Client: Guys, will that be done for tomorrow?
(silence)
Client: Guys.... Will that be done for tomorrow?
Team: Maybe rain, maybe snow, maybe yes, maybe no.

«Часто клієнти кажуть, що ми такі серйозні і що наші команди їх не люблять. Після різноманітних тренінгів представники різних культур починають краще комунікувати і розуміти, що насправді люблять. Тут справа в так званому Power Distance Index (G. Hofstede, див. статтю), який у нашій культурі досить високий. Він вказує на чітко визначену ієрархію, де не зовсім виділене місце для особистого. Суспільства з низьким показником PDI натомість легко оскаржують повноваження та взаємодіють з авторитетними особами для прийняття рішень і, відповідно, можуть легко підтримати розмову про особисте, перед тим як почати технічну дискусію.

Типовий діалог, коли наша сторона не завжди підтримує small talk і демонструє, що ми серйозні, відповідальні і тільки „про роботу“:

• Hey, how was your weekend?
• I was thinking about the tasks we had to do. I heard there were some major issues.

У цьому прикладі йдеться про такі індекси, як Collectivism (пріоритизація завдань групи, а не своїх), Power Distance (ієрархія vs горизонтальна організація) and Indulgence (як ми розуміємо щастя)».

Вибір стилю

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

Крім того, прислухавшись до популярної поради — дивитися серіали англійською, — IT-спеціалісти можуть використовувати в діловому мовленні аж занадто розмовні конструкції. Пам’ятайте, що вислови з gonnaі wannaправильні доти, поки ви їх вживаєте в правильному контексті. А інакше: «Речення ’Dear sir or madam! I’m gonna kindly ask u to consider a possibility to... Sincerely yours, Vova’виглядає так, ніби я взув сандалі, надягнув шкарпетки, майку з принтом „Король и шут“ і пішов дивитися „Привид опери“ в паризькому театрі». (Микита Сітнов, Daxx)

Щоб уникнути таких ситуацій, для вивчення лексики радять брати максимально нейтральний контент — лекції TED, наприклад.

Вимова

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

Зверніть увагу на слова, з вимовою і наголошуванням яких часто бувають проблеми:

Хоча для покращення вимови часто радять слухати пісні, Євген Габ, Intellias, каже, що в цьому способі є деякі загрози:

«Ми всі чули хіт „Hotel California“,і навіть зараз ви, можливо, почали його співати, наголосивши hotelна першому складі. Але ж правильним є наголос на другому! У пісні неправильний наголос потрібен для збереження ритму, але люди, що вчать англійську через пісні, про це не знають. На щастя, у цьому випадку наголос не змінює значення слова, як от, наприклад, це відбувається у слові content. Залежно від наголосу маємо 2 значення: на першому складі — вміст, а на другому — задоволений».

Дослівний переклад

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

Поширені помилкові вислови у мовленні IT-спеціалістів:

Розрізняйте вислови in case and if:

«’In case you have any questions, do not hesitate to contact us’ - неправильно. Має бути ’if you have’ (навіть якщо українською було сформульовано „у разі (у тому випадку), якщо у вас виникнуть запитання“). ’In case’потрібне для превентивних дій: ’In case you have any questions, we have prepared a FAQ section’». (Олена Бердиченко, Sigma Software)

Деякі вислови ще й надають тому, що ви кажете, небажаний відтінок:

«Сумнозвісне ’I feel myself’перекладається як „обмацувати себе“, причому у всіх можливих сенсах. Якщо ви хочете сказати, що ви добре / комфортно себе відчуваєте, це буде звучати як ’I feel good’, ’I feel comfortable’. Фраза ’I work like a developer’означає „Я хтось на зразок розробника“. Якщо ви говорите про свою професію, правильним варіантом буде: ’I work as a developer’». (Оксана Нежинець, DataArt)

Слово «suggest»

Майже всі викладачі, яких ми опитали, зауважили, що використання вислову ’suggest to’ - одна з найпоширеніших помилок, які трапляються на щоденних стендапах та в переписці. Запам’ятайте, що після дієслова suggestне вживається частка to.

Катерина Галас, EPAM, наводить два правильні можливі варіанти:

а) якщо в реченні не вказується адресат, вживаємо герундій:

suggest + Verb + ing
I suggest focusing on core functionality.

б) якщо вказуємо адресата, використовуємо такий патерн:

suggest + that he/she/we/somebody/ should + Verb
I would suggest that he should discuss the situation with his manager first.

Цікаво, що цей варіант трапляється здебільшого в британській англійській. Американці його трішки «оптимізували», викинувши ‘that’та ‘should’:

suggest + he/she/we/somebody/ + Verb
I’d suggest he discuss the situation with his manager first.

Так, саме he discuss, а не discusses, це не віддруківка. Справа в тому, що сильне модальне дієслово ‘should’ випало, але його граматичний вплив залишився. Як зірка згасає, але її світло ще довгий час видиме :)

Схожі слова

«Часто плутають слова architecture (архітектура) і architect (архітектор). Нерідко можна почути фразу: ’I want to become an architecture’. Analyst (аналітик) і analysis (аналіз) також викликають труднощі. Наприклад, ’I communicated with our business analysis’ - теж досить поширений вислів». (Оксана Нежинець, DataArt)

У діловому листуванні розрізняйте слова adopt-adapt, access-excess, beside-besidesтощо.

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

Незлічувані іменники

Поширений приклад помилки — вживання у множині іменника advice:

«Уявіть, що ’advice’ - це тісто. Уявили? Запам’ятайте цю асоціацію! Давати поради в англійській можна, як тісто — шматочками (to give a piece of advice). Якщо не подобається слово ’piece’, скажіть ’some advice’». (Оксана Топорова, SMART business)

Ще один приклад незлічуваного іменника, з яким трапляються проблеми, — feedback. Оскільки це слово ми вже часто вживаємо в українській мові у множині (фідбеки), те саме починаємо робити і в англійській (feedbacks). Але правильно говорити ‘We would appreciate somefeedback’, ‘We’ve received a lot of positive feedback’.

Прийменники

Усі викладачі одностайно радять просто зазубрити правильні вислови з прийменниками і ніколи не вчити окремо без прийменників слова, які з ними вживаються.

Кілька прикладів поширених помилок:

Герундій

Часто трапляються помилки з герундієм (форми дієслів з -ing). Ось як правило його вживання пояснює Євген Габ, Intellias:

«Як відомо, герундій є свого роду об’єднанням дієслова та іменника, часто-густо це дія, яку ми описуємо як іменник: ’Sitting is bad for your back’. Для того, аби розставити певні логічні акценти, я спочатку кажу студентам ’Tell me!’ й продовжую казати це, допоки хтось не скаже ’what?’. Ось на цьому моменті можна класно пояснити те, що деякі слова фактично вимагають після себе іменника, бо на прохання ’Tell me!’мені говорять what, а не whenчи why. І це є ключовим, як на мене, для розуміння правильного вживання герундію:

Tell me (what?)
I hate (what?)
She suggested (what?)
He can’t stand (what?)»

Часи та умовний спосіб

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

Оксана Прокопенко, викладач англійської в Yukon Software, зазначає:

«Часто на обговореннях та мітингах колеги розповідають про майбутні плани, використовуючи при цьому Future Simple. Важливо пам’ятати, що для планів є конкретна конструкція be going to, яка виражає намір: ’Today I’m going to fix a few bugs’.

Future Simple вживається для передбачень та суб’єктивних думок: ’I suppose today I will fix a few bugs’».

Складнощі виникають і з Present Perfect. Тут головна порада така: якщо говорите про свою нинішню роботу, завдання, застосовуйте Present Perfect, якщо про попередню — Past Simple:

In my current job I’ve learned... — In my previous job I learned...
In our current sprint we’ve completed... — In our previous sprint we completed...

Ще кілька поширених помилок, пов’язаних з часами:

«Використання Present Continuous замість Present Simple на позначення звичайних, регулярних дій і навпаки, Simple (або форма -ing без допоміжного) для поточних. Наприклад: ’We usually discussing such things with the whole team’замість ’We usually discuss’.

Використання willпри будь-якій згадці майбутнього: ’Tomorrow at 5:30 we will meet our customers’. Така фраза виглядає як ні на чому не засноване передбачення. Має бути ’We are meeting’, тому що саме Present Continuous потрібен для позначення заздалегідь запланованих і підготовлених, arranged, дій». (Олена Бердиченко, Sigma Software)

Також часто використовуємо willпісля if/unless, порушуючи правила First Conditional (у прикладах нижче правильний другий варіант):

If I will do it today, I will be available tomorrow.— If I do it today, I will be available tomorrow.
I will call you if I will find appropriate information. — I will call you if I find appropriate information.

І не забувайте повторювати правила непрямої мовита узгодження часів у англійській. Якщо коротко, то Present Simple змінюється на Past Simple, Past Simple та Present Perfect — на Past Perfect, Future Simple — на would.

Правильні вислови:

He said: ’I will do it tomorrow’. — He said he would do it the next day.
My colleague informed me: ’I have done my part’. — My colleague informed me that he had done his part.

Артиклі

Артиклі — це загалом для нас складна тема, адже в українській мові немає артиклів.

«Якщо пояснювати артикль „на пальцях“, то ‘A/An’ — значить ‘one (of)’ — „один (із)“ або ‘any’ — „будь-який“. Артикль ‘The’є усіченою формою вказівних займенників ‘this, that, these, those’. Якщо сумніваємося, який артикль ставити, можна перевірити себе, підставивши ці значення. Наприклад, I’m an engineer — Я є один із інженерів; Could you give me a pen?— Можна мені одну будь-яку ручку? Could you give me the pen?— Можна мені цю ручку? Також дуже часто вживатимемо артикль ‘A/An’в структурах It is a..., This is a... , That was/is a..., He/She is a...і т. д, тому що в такому разі ми здебільшого говоримо про цей іменник вперше, називаємо, що це (Це один із..., Він один із... і т. д). Коли ж ми продовжуємо говорити про цей предмет, то вживаємо його з артиклем ‘The’, маючи на увазі „цей/ці“,про котрі я щойно говорив/говорила». (Катерина Галас, ЕРАМ)

Корисні ресурси

Для вдосконалення англійської викладачі порадили зокрема такі ресурси:

Онлайн-словники: Cambridge Dictionary, Merriam-Webster, Macmillan Dictionary, Oxford English Dictionary — дають можливість з’ясувати значення слова, знайти синоніми, приклади вживання в контексті та ін.

engVID — ресурс, де можна знайти відеоуроки для різних рівнів, на різні теми й навіть обрати вчителя за манерою викладання чи акцентом (канадця, британця чи американця).

Perfect English Grammar — сайт з поясненнями граматичних правил та вправами для закріплення.

English Grammar — сайт зі зрозумілими правилами, які зручно роздруковувати.

Englishpage — ще один сайт з граматичними правилами і вправами.

Do People Say — можна перевірити, чи вживається вислів у розмовному стилі і в якому контексті. Проте не застосовуйте його для офіційного листування. Більшість прикладів сайт бере з Reddit.

Free Collocation — допомагає знайти, які слова найчастіше вживаються разом із заданим вами словом. Таким чином ви побудуєте речення більш правильно, ніж дослівно його перекладаючи.

YouGlish — перевіряємо, як слова вимовляються у відео на YouTube. Є американський, британський, австралійський акценти.

Islcollective — матеріали як для викладання, так і для самостійного вивчення мови з ключами.

VOA news — відео, подкасти для тренування сприйняття мови на слух.

BBC Learning English — тематичні подкасти британською англійською, розбір поширених помилок та мовних нюансів.

British Council — навчальні відео, статті, подкасти.

Business English Pod — подкасти, що допоможуть збільшити запас бізнес-лексики і покращити її сприйняття на слух.

English with Jo — сформовані уроки для викладачів.

Hollywood Vocabulary — відеоуроки з уривками з фільмів. Хороша практика словникового запасу.

Ted Talks — можна вчитися розуміти вимову не носіїв англійської.

Quizlet — ігри для засвоєння лексики.

Kahoot — сайт з різноманітними тестами.

Toastmasters — хороший спосіб прокачати навичку говоріння, особливо public speaking. Підійде для більш досвідчених мовців.

NPR — ресурс для тих, хто вже гуру в англійській. Можна почитати і послухати виступи на різноманітні теми.

Підбірка книг Cambridge English Readers — підходять для різних рівнів, корисні для поповнення лексичного запасу та засвоєння граматики.

Інші книги для вивчення мови: «Round Up», «Upstream», «Aim High», «English Vocabulary in Use», «Objective First», «Compact First», «English Conversation & Writing», «Headway», «Total English».

Поради

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

«Якщо є проблеми з розумінням на слух, поліпшуйте словниковий запас і вимову. Тому що: а) ми з більшою ймовірністю зрозуміємо на слух слово, яке знаємо; б) ми з більшою ймовірністю „впізнаємо“ слово, яке самі вимовляємо правильно». (Оксана Топорова, SMART business)

Якщо вам складно вести розмову з нейтів спікерами, знадобляться поради Аліни Литвинчук, Forbytes:

1. Перепитуйте.Чомусь в українській мові у нас ніколи не виникає таких проблем. Не розчув — перепитав. Але в англійській ми відчуваємо мовний бар’єр, боїмося перепитати, через що може виникати серйозна дискомунікація. Найкращий варіант тут — вивчити прості фрази для перепитування, такі як ’Could you speak up?’, ’I’m struggling to hear you’,для онлайн-спілкування можуть знадобитися ’My line is bad’або ’Connection is bad, could you please repeat’.
2. Задавайте власний темп для розмови.Якщо відчуваєте, що розмова пішла занадто швидко для вас, спробуйте почати говорити повільніше або навіть попросіть про це. Зазвичай співрозмовники дуже відчувають зміну темпу під час спілкування і сповільнюються разом із вами.
3. Розпочинайте розмову зі small talk.Можливо, для нас це і незвично, але для англійського ділового спілкування абсолютно характерно поговорити спочатку про погоду або про те, як почався ранок. Лише кілька питань та відповідей, які створять приємну дружню атмосферу, а вже потім переходьте на робочі обговорення.

І наостанок кілька загальних порад Наталі Оленин, Vakoms:

• Зосереджуйтеся на чомусь одному.Якщо вчитель робить вам безліч зауважень на кожному занятті, то записуйте, переглядайте, але не зациклюйтесь на тому, щоб запам’ятати все й одразу. Оберіть найтиповіші помилки і працюйте з ними. Поступово переходьте до нових, не забуваючи про старі. Багатозадачність у вивченні мови така ж неефективна, як і на проекті.
• Пам’ятайте, що на підвищення рівня на один щабель потрібно в середньому близько року регулярних занять (двічі в тиждень). Якщо добре старатися, то можна і на більше, тому не гайте часу і вперед.
• Знайдіть викладача до душі.Вам має бути з ним/нею комфортно, і водночас маєте відчувати авторитет так, щоб повністю йому/їй довіряти. Багато людей бажають заощадити гроші і намагаються покращити рівень за допомогою колись дуже популярних аудіокурсів чи просто відвідуючи мовні клуби. На жаль, це не працює так, як нам би хотілось. Щоб прокачати рівень англійської чи іншої мови, треба працювати в комплексі над усіма мовними навичками (speaking, writing, listening and reading). Зосередившись лише на чомусь одному, прокачаєте конкретні навички, а не рівень мови в цілому.
• Не нехтуйте культурними розбіжностями.Навчіться правильно вітатись/прощатись, починати (т. зв. small talk) / закінчувати розмову, критикувати і сприймати критику, вносити пропозиції і т. д. Ну і, звісно, усміхатись (так-так, навіть по скайпу «чути», чи ви усміхаєтесь).
• Не ганяйтеся за бізнес-англійською,не засвоївши звичайної до комфортного рівня.
• І останнє. Пам’ятайте, що вивчення мови — це не лише запорука класної роботи, гарної зарплати та крутого проекту, а й добра профілактика деменції та супутніх хвороб у старшому віці :)

Дякуємо за участь у підготовці матеріалу викладачам англійської з IT-компаній Agilites, DataArt, Daxx, Dev-Pro, Dmarket, ЕPАМ, Forbytes, Infopulse, Intellias, Intetics, Playtika, RubyGarage, Sigma Software, Sitecore, SMART business, SoftServe, TEAM International, Uptech, Vakoms, Yukon Software.

Заканчивая обучение в бизнес-школе и выбирая тему для диссертации, я задался вопросом: почему отношения между сотрудниками и менеджментом в IT-компаниях зачастую так разнятся?

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

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

<Acknowledgements>
Данное исследование появилось благодаря помощи редакторской команды DOU, а также волонтерской помощи Николая Павлова (Data Scientist в People.ai) в обработке сырых данных. Отдельная благодарность — 245 пользователям DOU, заполнившим анонимные опросники. Исходный язык работы — английский, поэтому прошу прощения за местами корявую адаптацию.

Автор сохраняет за собой исключительные права на все найденные косяки :) Буду рад обратной связи на roman@promodo.com; если кого-то интересует сам датасет, пишите.
</Acknowledgements>

Минутка скучной теории

Одним из первых вопрос приверженности организации (organizational commitment) поднял в лохматом 1973 году тогда еще малоизвестный исследователь бизнеса Майкл Портер. Анализируя поведение медицинско-технического персонала психиатрических больниц, Портер обнаружил, что между удовлетворенностью работой, текучкой персонала и приверженностью организации есть определенная связь.Удовлетворенность работой оказалась неплохим «предсказателем» того, останется ли сотрудник на этом месте в ближайшем будущем, однако на длинной дистанции гораздо лучше это отражала приверженность организации. Команда исследователей установила, что, по крайней мере при определенных обстоятельствах, приверженность организации перевешивает существенное неудовольствие такими аспектами, как уровень оплаты труда или отношения с руководителем, удерживая таким образом сотрудника от ухода.

Мейер и Аллен, исследуя данный вопрос детальнее, выделили три компонента приверженности организации (three-component model of commitment):

1. Эмоциональная приверженность (affective commitment — AC) — состояние искренней эмоциональной привязанности и самоидентификации по отношению к компании. Если кратко — «я хочу».
2. Приверженность постоянству (continuance commitment — CC) — ощущение определенных потерь в случае ухода из организации (например, разрыв социальных связей). Если кратко — «мне нужно».
3. Нормативная приверженность (normative commitment — NC) — ощущаемая сотрудниками необходимость продолжать работу в компании (например, «не могу бросить мою команду в этот момент», «если и я скажу, что ухожу, будут косо смотреть»). Если кратко — «я обязан».

Проведенные Мейером (и впоследствии иными учеными) исследования показали сильную положительную корреляцию между эмоциональной приверженностью (AC) и успешностью сотрудников в своей роли (in-role performance). Например, исследование в 298 школах США продемонстрировало, что школьники показывают существенно лучшую успеваемость, посещаемость и общую удовлетворенность процессом обучения там, где преподаватели испытывали эмоциональную приверженность своей организации.

В то же время приверженность постоянству, даже имея подтвержденное положительное влияние на решение сотрудника остаться в компании, никак не коррелирует с in-role performance. Аналогичная история с нормативной приверженностью, которая никак не коррелирует с независимым образом оцененной in-role performance, несмотря на то что сотрудники с высокой нормативной приверженностью сами в среднем оценивают свои результаты выше.

Мы можем чувствовать приверженность на разных уровнях:

• локальном (приверженность непосредственному руководителю и своей рабочей группе);
• глобальном (приверженность топ-менеджменту и компании в целом).

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

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

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

• автономия (autonomy) — вера, что то, чем я тут занимаюсь, это мой искренний выбор, который соответствует моим ценностям;
• компетентность (competence) — ощущение, что у меня есть способности и возможности для данной работы;
• сопричастность (relatedness) — чувство, что меня здесь ценят.

Исследования подтверждают сильную положительную корреляцию между эмоциональной приверженностью и autonomy, competence & relatedness (ACR).

C точки зрения мотивированности сотрудников вопрос об инновациях достаточно запутан. В 2011 году Фернандес и Питс провели масштабное исследование линейных сотрудников в федеральных госструктурах США, пытаясь понять, как там появляются инновации: навязываются менеджментом или, наоборот, генерируются сотрудниками и постепенно проникают в организацию. Также ключевой вопрос — какие факторы положительно влияют на инновационное поведение персонала. Исследователи выделили следующие факторы:

• поощрение (rewards), в том числе extrinsic rewards (грубо говоря, деньги) и intrinsic rewards (нематериальное вознаграждение, например предоставление большей автономии, возможностей для развития компетенций и т. д.);
• расширение возможностей сотрудников (empowering) посредством снижения уровня контроля и наделения возможностями принятия более автономных решений;
  
• знание об относительно легкой доступности ресурсов;
• кросс-функциональный обмен информацией между подразделениями;
• вертикальная иерархическая коммуникация (между уровнями компании);
• обучение и развитие сотрудников;
• высокоуровневое лидерство (high-exchange leadership), в отличие от транзакционных отношений («я тебе — зарплату, ты мне — работу»).

Исследование Монтани (2017) также показало, что перегрузка и непрозрачность должностных обязанностей тоже влияют на инновационное поведение, при этом эмоциональная приверженность и высокоуровневое лидерство смягчают воздействие негативных факторов. Помимо этого, исследование установило положительную корреляцию между проактивной постановкой целей (proactive goal generation) и эмоциональной приверженностью, а также инновационным поведением.

Тан и Лау (2012) выделили важную роль процедурной справедливости (procedural fairness) по отношению к инновационному поведению. Процедурная справедливость подразумевает под собой справедливость процедур повышения оплаты труда, продвижения по карьерной лестнице в компании и т. п.

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

Исследование

Из перечня выше я выбрал 10 ключевых факторов для исследования.

1. Инновационное поведение (innovative behaviour).
2. Эмоциональная приверженность (affective commitment).
3. Автономия, компетентность и сопричастность (autonomy, competence & relatedness).
4. Высокоуровневое лидерство (high-exchange leadership).
5. Проактивная постановка целей (proactive goal generation).
6. Лидерская поддержка инноваций (leadership support for innovation).
7. Процедурная справедливость (procedural fairness).
8. Материальное поощрение (extrinsic rewards).
9. Нематериальное поощрение (intrinsic rewards).
10. Понятность и бесконфликтность роли (role clarity & conflict-free).

Методология

На базе вопросов из предыдущих исследований была собрана анкета (на русском языке), позволяющая измерить каждый из 10 факторов (шкала Ликерта от 5 («абсолютно согласен») до 1 («абсолютно не согласен»), вопрос 10.4 инвертирован):

Благодаря помощи редакторской команды DOU получилось собрать 245 заполненных анкет. Данные отдельных вопросов затем были сведены в соответствующие категории, анализ корреляций проводился в R-Studio (отображены только корреляции с вероятностью >99%).

Общие гипотезы

H1) Affective commitment (AC) is positively correlated with innovative behaviour (IB)
H2) Autonomy, competence & relatedness is positively correlated with AC
H3) High exchange leadership is positively correlated with AC
H4) Proactive goal generation is positively correlated with AC
H5) Leadership support for innovation is positively correlated with AC
H6) Procedural fairness is positively correlated with AC
H7) Extrinsic motivation is positively correlated with AC
H8) Intrinsic motivation is positively correlated with AC
H9) Role clarity & conflict-free is positively correlated with AC

Результаты исследования

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

• как все 10 факторов модели влияют друг на друга, какова сила этого влияния.
• влияние размера компании на эти факторы и их взаимосвязи.
• влияние стажа работы в компании.
• влияние сферы деятельности (Software Engineer vs QA).

Проверка гипотез

Figure 1 DOU category-level correlations

Из всех гипотез не подтвердилась только одна: не обнаружена корреляция между extrinsic rewards и affective commitment. Из важных наблюдений стоит отметить:

• Affective commitmentимеет наивысшую корреляцию с innovative behaviour (эмоционально приверженные компании люди с наибольшей вероятностью являются и наиболее вовлеченными в различные инновационные инициативы).
• Autonomy, competence & relatedness (ACR)имеет наивысшую корреляцию с affective commitment (автономия в работе является самым мощным драйвером к эмоциональной приверженности компании).
• High-exchange leadershipимеет сильную положительную корреляцию с affective commitment (непосредственный руководитель, понимающий проблемы сотрудников на работе и готовый сметать ради своей команды преграды вместо транзакционных отношений «я тебе — зарплату, ты мне — работу», вносит значительный вклад в уровень эмоциональной приверженности сотрудников компании).
• Proactive goal generationимеет положительную корреляцию с affective commitment и innovative behaviour (можно трактовать, что эмоциональная приверженность компании также побуждает сотрудников ставить цели проактивно, стремясь делать вещи иным, лучшим образом).
• Leadership support for innovation — второй по силе влияния фактор после ACR (участие непосредственного руководителя в инновациях, поддержка ресурсами и признание участвующих в таких инициативах сотрудников — фактор, очень сильно влияющий на искреннюю приверженность компании).
• Procedural fairness («насколько прозрачны процедуры повышения оплаты труда», «насколько прозрачны процедуры продвижения по карьерной лестнице») имеет сильную корреляцию с AC.
• Intrinsic motivation («я сделаю эту работу хорошо, иначе мне будет стыдно перед собой») имеет сильную положительную корреляцию с AC.
• Role clarity & conflict-freeимеет слабую положительную корреляцию с AC.

Методология исследования не позволяет однозначно установить, что является причиной, а что — следствием, но некоторые предположения сделать можно. Если убрать за скобки IB, то из восьми факторов семь положительно влияют на AC в IT-компаниях, лишь материальное поощрение никак не коррелирует с AC.

Было бы очень интересно взглянуть, как уровень эмоциональной приверженности коррелирует с реальным вознаграждением, чтобы понять, не теряют ли счастливые сотрудники деньги, работая в любимой компании, вместо того чтобы перейти на соседнюю нелюбимую «галеру» сугубо ради денег. Или, наоборот, счастливые сотрудники более продуктивны и зарабатывают больше? Как бы то ни было, данный датасет не дает ответов на эти вопросы, и скрестить его с зарплатным опросом DOU не представляется возможным 😊

Интересно также отметить высокую корреляцию оценки процедурной справедливости (procedural fairness), лидерской поддержки инноваций (leadership support for innovation) и высокоуровневого лидерства (high-exchange leadership). Руководитель, поддерживающий стремление сотрудников пробовать новые вещи, не исповедующий при этом транзакционного характера отношений, помогает сотрудникам ощущать себя счастливее и считать более справедливыми текущие процедуры повышения оплаты труда и продвижения по карьерной лестнице в компании. Или в компаниях с подобными лидерами такие процедуры реально справедливее...

Посмотрим теперь на другие взаимосвязи.

Размер компании

Figure 2 DOU overall: Categories by company size

Компании с количеством сотрудников в диапазоне 80–200имеют оценки существенно выше средних по ACR, также находятся в лидерах по affective commitment, procedural fairness, leadership support for innovation, high-exchange leadership, достигают высоких показателей по прочим категориям; при этом сотрудники данных компаний, по-видимому, в среднем чуть менее движимы материальным вознаграждением (получают ли они при этом реально меньше рынка для своей позиции?). Интересно также, что сотрудники крупных компаний (>1500) имеют существенно ниже средней оценку по affective commitment, proactive goal generation, autonomy, competence & relatedness и leadership support for innovation, а также ниже всех остальных компаний оценку по procedural fairness и достаточно низкую по high-exchange leadership.

Посмотрим чуть подробнее.

Figure 3 DOU data: <80 employees company size, Category-level correlations (n=105)

Figure 4 DOU data: 80-200 employees company size, Category-level correlations (n=46)

Ключевые отличия:

• <80 сотрудников. ACR — ключевой фактор для AC и IB, также high-exchange leadership сильно влияет на оценку сотрудниками показателя role clarity (для компаний такого уровня, по-видимому, софтовые скилы «выруливают» сырые процессы). Вероятно, high-exchange leadership для таких компаний является «универсальным средством».
• 80–200 сотрудников. High-exchange leadership уже меньше влияет на role clarity, ключевым фактором для affective commitment становится leadership support for innovations. Также появляется отрицательная корреляция на более низком уровне анализа: чем больше мы движимы в работе внешним давлением («этого требует ситуация, или я делаю эту работу, потому что мне за нее платят»), тем меньше мы испытываем чувства сопричастности и искреннего переживания за судьбу компании. Также сотрудники в такой ситуации готовы прилагать меньше экстраусилий. Вероятно, недостаток персонала на проектах для компаний такого размера является одним из существенных рисков для самой организации.

Figure 5 DOU data: 200–800 employees company size, Category-level correlations (n=37)

Figure 6 DOU data: 1500+ employees company size, Category-level correlations (n=37)

Ключевые отличия:

• 200–800 сотрудников. ACR является особо важным фактором для AC (впрочем, как и для компаний с >1500 сотрудников).
• >1500 сотрудников. High-exchange leadership имеет большее влияние на оценку procedural fairness; также, по-видимому, для крупных компаний leadership support for innovations является самым сильным фактором во всей модели. Интересно отметить, что high-exchange leadership имеет сильную положительную корреляцию с тем, как сотрудники оценивают достаточность выделяемых для работы человеческих ресурсов.

Продолжительность работы в компании

Figure 7 DOU overall: Categories by tenure

Сотрудники со стажем работы в компании 5–10лет имеют оценку по innovative behaviour и intrinsic motivation (движимы внутренними драйверами) чуть выше средней, при этом в данном сегменте существенно хуже оценка procedural fairness, а также affective commitment. Вероятно, именно этот период определяет профессиональное выгорание. Высокий уровень proactive goal generation и intrinsic motivation может сигнализировать, что сотрудники этой категории особо склонны к прокачке новых компетенций и их применению в работе, борясь с выгоранием.

Рассмотрим подробнее взаимосвязи по стажу работы в компании.

Figure 8 DOU data: Less than a year tenure, Category-level correlations (n=100)

Figure 9 DOU data: 1-2 years tenure, Category-level correlations (n=69)

Ключевые особенности сотрудников, проработавших в компании менее года и 1–2 года:

• <1 года. Procedural fairness и high-exchange leadership (вместе с leadership support for innovation и role clarity) имеют наивысшую корреляцию с affective commitment (вполне возможно, что один из данных факторов или их комбинация были причиной ухода из предыдущей компании, и мы (под)сознательно хотим избежать того же на новом месте работы).
• 1–2 года.На первый план для affective commitment выходит autonomy, competence & relatedness, при этом влияние high-exchange leadership снижается. Если заглянуть чуть дальше в подкатегории, то именно autonomy является ключевым драйвером желания осваивать инновации, преодолевать препятствия, когда что-то идет не так, и получать положительный результат в инновациях для данной категории сотрудников (полный список корреляций приведен в конце статьи). Чувство сопричастности и интересная работа для данной категории имеют наивысшую корреляцию с ответом на вопрос «Я искренне забочусь о судьбе данной компании?», в то время как для сотрудников с опытом работы менее 1 года это справедливая обратная связь и ощущение, что их работа важна.

Figure 10 DOU data: 2–5 years tenure, Category-level correlations (n=55)

Figure 11 DOU data: 10+ years tenure, Subcategory-level correlations (n=11)

Ключевые особенности сотрудников, проработавших в компании 2–5лет и >10 лет:

• 2–5 лет. Leadership support for innovation, proactive goal generation и innovative behaviour оказывают наибольшее влияние на affective commitment. Если лидеры поддерживают стремление пробовать новые технологии, стимулируют самостоятельную постановку целей в работе, это драйвит ACR и AC, позволяя таким сотрудникам чувствовать себя счастливее и, следовательно, продуктивнее.
• >10 лет. Данных для оценки полной картины недостаточно, однако некоторые корреляции все же видны. Autonomy, competence & relatedness является ключевым фактором в affective commitment, также возвращается high-exchange leadership, и именно данный фактор имеет сильную корреляцию с частью envisioning в proactive goal generation (ответ на вопрос «Я часто думаю о том, как снизить расходы компании и улучшить сервис для наших клиентов?»). Также высока корреляция high-exchange leadership и procedural fairness в части компонента оплаты труда («Наши процедуры повышения оплаты труда являются справедливыми»).

Вид деятельности

Figure 12 DOU overall: Categories by job role

Мы видим высокую оценку по innovative behaviour для Project/Product Manager и существенно ниже для Software Engineer, также Software Engineer имеет самую низкую среднюю в affective commitment, ACR, proactive goal generation и innovative behaviour.

Рассмотрим подробнее на примере Software Engineer и QA.

Figure 33 DOU data: Software Engineer Category-level correlations (n=104)

Figure 34 DOU data: QA Engineer Category-level correlations (n=32)

Ключевые особенности:

• Для обеих категорий ACR, high-exchange leadership, intrinsic motivation, procedural fairness и leadership support for innovations имеют самые сильные корреляции с affective commitment (так как для QA количество анкет меньше, удалось получить меньшее количество корреляций для условия 99%-ной достоверности).
• QA. Нет положительной корреляции между affective commitment и innovative behaviour, единственный фактор для данной группы, влияющий на IB, — proactive goal generation. Ключевым фактором для affective commitment является intrinsic motivation («Моя работа важна» и «Моя работа интересна»).
• Software Engineer. В отличие от QA, есть корреляция между role clarity и procedural fairness, причем в большей степени со справедливостью оценки работы и предоставления обратной связи, в меньшей — с оценкой справедливости оплаты труда и продвижения по карьерной лестнице. Также для разработчиков справедливость процедур повышения оплаты труда наиболее ярко коррелирует с ответом на вопрос «Я готов(а) приложить экстраусилие, чтобы помочь этой компании быть успешной?». Ключевым фактором для affective commitment является leadership support for innovations, особенно в части help («Мой руководитель помогает нам внедрять инновации в рабочей среде»). Также стоит отметить, что ощущение, что «работа важна», по-видимому, больше влияет на affective commitment, чем «работа интересна» (выполнение бессмысленной работы убивает приверженность компании быстрее, чем выполнение неинтересной :).

Ограничения исследования и будущее изучение

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

Также в условиях волатильных реалий украинского бизнеса выводы могут существенно измениться при курсовых колебаниях или новых «приколах» от нашего интересного северного соседа.

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

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

Бонус

Также привожу без купюр несколько наиболее характерных ответов на вопрос «Перечислите, пожалуйста, топ-3 вещи в компании, которые, по вашему мнению, мотивируют заниматься инновациями, и топ-3 вещи, которые отталкивают от этого»:

«Мотивашки: карьерный рост, обучение (компенсация обучения), заинтересованность руководства. Антимотивашки: безразличие руководства; непрофессиональный подход к процессам; низкая оплата труда».

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

«Мотивируют: перспектива релокейта; супердружеский коллектив; человеческий менеджмент. Отталкивают: отсутствие процессов; отвратительные проекты; недостаточное выделение человеческих ресурсов».

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

«Мотивируют: простота; честность (прозрачность); оценка за результат. Отталкивают: бюрократия; оплата за время; неумение признавать ошибки».

«Мотивируют: поощрение; азарт; стремление к комфорту; Отталкивают: отсутствие контакта с руководством (сугубо рыночные отношения); плохое планирование; отсутствие положительного подкрепления в результате».

«Мотивируют: полезность и юзабельность продукта; финансовая и не только помощь в обучении; открытость руководства. Отталкивают: эйджизм; гонка за быстрой, но непродолжительной прибылью; контроль сидения за рабочим местом».

«Мотивируют: расположение к инновациям и поощрение со стороны руководства; свобода в культуре компании; развернутая обратная связь по любому предложению. Отталкивают: бюрократия и принцип „только критиковать, а не предлагать“».

«Мотивируют: поддержка коллег; поддержка руководителя; финансовые возможности. Отталкивают: страх, что не получится; долгий период на раскачку тех, к кому изменения относятся; возможная неэффективность или возврат к старой модели».

«Мотивируют: поддержка; внимание; равность. Отталкивают: неуверенность; безразличие; отсутствие отклика (оценки работы)».

Спасибо всем, кто дочитал до конца, надеюсь, было интересно.

А какие у вас наблюдения по данной теме? Что, по вашим личным ощущениям, драйвит эмоциональную приверженность и подталкивает к тому, чтобы заниматься инновациями?

Я Product Owner / Product Manager в американском стартапе Atiim Inc. Два года назад я пришла в эту компанию в качестве QA Engineer. Всего через полгода работы тестировщиком перешла на должность PO. Об этом пути, его предпосылках и последствиях и пойдет речь дальше.

Как-то мы искали нового Product Owner’a в одну из команд, и у нас накопилось некоторое количество резюме. Пересмотрев их, сделали вывод, что каждый третий PO ранее был на позиции QA. Это означает, что моя история не уникальна, но, возможно, мой опыт поможет кому-то пройти этот путь легче и быстрее (но это не точно :)).

Бэкграунд

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

Некоторые мои убеждения и взгляды:

• Мечты сбываются, если становятся целями.
• Люди — самая большая ценность компании.
• Работа только по любви ❤

С чего все начиналось и что подтолкнуло к изменениям

Сейчас моя жизнь делится на до и после начала работы в IT. Если бы мне 3 года назад рассказали, как моя жизнь изменится за один год, я бы не сразу поверила... но очень бы на это надеялась :)

Тогда, 3 года назад, мне было 28 лет и я работала в интернет-магазине электроники в отделе закупок. Общалась с дистрибьюторами, оформляла у них заказы. Самым «айтишным» из всего, что меня тогда окружало, был IT-отдел в соседнем кабинете, база 1С и компьютерные комплектующие в счетах и накладных. У нас был хороший коллектив, и мне там нравилось работать. Но за три года работы на этой должности я ощутила недостаток развития в паре аспектов:

• Знания.Одна и та же информация каждый день, однообразная операционная работа. Даже самые сложные ситуации перестали казаться таковыми. И книги давали понять, что в мире еще столько всего интересного можно делать.
• Карьера.Бизнес не видел смысла создавать должность менеджера в моем отделе, а у меня уже поднакопилось знаний и опыта для этого.

Почему именно IT

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

В итоге был вариант переучиться и работать с текстами (например, корректором, редактором, копирайтером, журналистом и т. п.). В то же время мне на глаза попались видео о тестировании ПО на YouTube. Я пересмотрела десятки, а потом и сотни видео о тестировании: о том, кто такой тестировщик, чем он занимается, какие знания нужны, где их получить, каковы перспективы, какой был опыт обучения и трудоустройства у других людей и о многом другом.

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

Все это дало мне надежду, что я нашла ответ на свой вопрос.

Я начала действовать

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

По плану после курсов должна была быть практика (курсы сотрудничают с компаниями, где на реальных проектах дают выпускникам попрактиковаться в тестировании), но у меня до нее дело так и не дошло. Сразу после курсов можно было уже искать работу. Я сразу выложила резюме на несколько сайтов по поиску работы, подготовила в письменном виде на английском языке ответы на 10 самых популярных вопросов на собеседовании (мой уровень на тот момент был между pre-intermediate и intermediate). И буквально через неделю было первое собеседование. Кстати, подготовленный ответ на «Tell me about yourself» как раз пригодился. На следующий день меня приняли на работу на должность QA Engineer в американский стартап Atiim Inc. (произносится как A-Team).

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

Компания основана в Бостоне, работа удаленная, команда разработки распределенная, рабочий процесс напоминал Scrum с недельным спринтом, график работы гибкий, отпуск безлимитный.

Немного о нашем продукте

Как говорит Википедия (и я ничего против не имею), OKR (от англ. Objectives and Key Results — цели и ключевые результаты) — метод, используемый в современном менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль над реализацией поставленных задач.

Подход с OKR стали изначально использовать в Intel, а затем и во многих других компаниях — Google, Dropbox, LinkedIn, Oracle, Slack, Spotify, Twitter, BMW, Disney, Samsung и др. Метод OKR задает направление всей компании, помогает достигать целей и становиться лидерами в своей нише, расширять границы возможного.

Наш продукт B2B SaaS — это веб-приложение, использующее облачные вычисления. Он позволяет внедрить и применять подход OKR в бизнесе, масштабируя его на всю компанию. Ставить цели (чтохотим получить), определять ключевые результаты (метрики, которые дают понять, достигли ли мы цели), связывать цели с основными ценностями компании и ее миссией, обновлять прогресс по целям в процессе работы, получать результат в конце периода и анализировать его для последующих корректировок в новой итерации. При этом продукт также дает возможность поддерживать эффективную коммуникацию между менеджером и подчиненным, корректировать направление деятельности при необходимости, держать руку на пульсе коллектива, развивать культуру открытости и обратной связи.

В книге Джона Дорра «Измеряйте самое важное» («библия OKR») рассказывается обо всем на эту тему, и она будет полезна в первую очередь тем, кто хочет внедрить эффективный метод управления проектом/компанией или уже в процессе работы с OKR.

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

Как философия OKR коррелирует с моими взглядами на жизнь

Мечты сбываются, если становятся целями. Наивно думать, что можно получить все желаемое, не приложив усилий и не проявив ответственности на пути к цели. Мы в ответе перед собой за подавляющее большинство событий в своей жизни. Так почему бы не сделать эту череду событий приятной и полезной? Я хочу жить в удовольствие, наслаждаться жизнью и возможностями, а не стрессовать от того, что все идет не так, но лень двигаться для исправления ситуации, и потом ощущать угрызения совести и злость за свою лень. Крайне безответственно по отношению к себе проживать свою единственную жизнь не так, как хочется, и даже не попытаться что-то изменить.

Поэтому:

• что я могу сделать?
• как я могу это сделать?
• когда я могу это сделать?

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

К примеру:

Что:

1. Я хочу найти работу тестировщиком ПО, которая позволит мне развиваться и применять свои знания, навыки, таланты.

Как:

1. Пройти курсы по тестированию ПО.
2. Составить и выложить резюме.
3. Активно отправлять резюме на все подходящие вакансии (не менее 10 вакансий в день).
4. Подготовиться к собеседованию (найти топ-10/20/50 вопросов с собеседования для тестировщика, подготовить на них ответы в письменном виде, отрепетировать ответы устно вслух).
5. Успешно пройти собеседование.

Когда:

1. Сегодня найду курсы и запишусь на ближайший набор.
2. До окончания курсов составлю резюме и выложу его на ресурсы ***.ua, ***.com.
3. Ежедневно буду отправлять резюме на более чем 10 вакансий.
4. В первый день, когда выложу резюме, найду список вопросов и в течение одного-двух дней буду активно прорабатывать свои ответы, чтобы успешно пройти собеседование.
5. В оговоренный с работодателем день пройду собеседование.

Что мне запомнилось в начале работы

Беседы 1-on-1. У меня каждую неделю было полчаса на общение с менеджером (CTO) один на один на любую волнующую меня тему, где он также интересовался, все ли меня устраивает в работе, как я хочу развиваться и как он может мне помочь в этом, есть ли какие-то трудности, которые можно устранить, и т. д.

Впечатление об удаленной работе очень неоднозначное:

1. она учит фокусироваться на работе и самоорганизовываться, так как иногда сложно мысленно собраться и работать в том месте, где ты обычно расслабляешься и отдыхаешь, но, скорее, дело в желании и мотивации;
2. усиливает любовь к людям :) (это, конечно, не про интровертов). После двух месяцев работы из дома я соскучилась по людям, мне очень не хватало коллектива, даже пассажиров в транспорте я была невероятно рада видеть;
3. погода и времена года проходили мимо, где-то там, за окном;
4. подвижность намного уменьшилась.

Потребность в PO

На позиции QA я изучала продукт, писала тест-кейсы и участвовала в тестировании на разных этапах разработки продукта. Потом меня посвятили немного в автоматизированное тестирование. В общей сложности на позиции QA я проработала 6 месяцев.

После очередного раунда инвестиций команда начала расширяться, обновился состав, кто-то ушел, кто-то пришел, стали нанимать больше разработчиков в Киеве. И ребята захотели работать по Scrum’у, со всеми ролями, артефактами, блэкджеком и церемониями. Возникла потребность во Владельце Продукта (Product Owner). Наш CTO в тот момент уже с нами не работал (роль PO была ранее у него), искали нового, и пока те самые беседы 1-on-1 с нами проводил СЕО.

Так все же, где найти PO?

Нанять нового? Он продукта не знает, его долго искать и потом вводить в курс дел, а начать делать задачи нужно уже сейчас; и не факт, что он впишется в команду, потом заново искать нового PO.

Может, тогда назначить на эту должность кого-то из уже существующих сотрудников? А кто же тогда на его месте будет? И как он на новом месте вообще справится, он ведь практически ничего о владении продуктом может и не знать? Кто будет его обучать?

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

Вот как это произошло. У меня с СЕО был очередной созвон (1-on-1). Мы общались обо всем: о команде, о людях, о жизни, о странах и прочем. Было интересно и полезно, это расширяло кругозор. И как-то посреди разговора он у меня спросил, сколько я уже работаю в компании и хорошо ли я знаю продукт. И здесь я поняла, что у меня началось собеседование, хотя, скорее всего, оно началось даже раньше, чем я это осознала.

В итоге собеседование прошло успешно, мы договорились о том, что я перехожу на новую должность через месяц, что помогу найти команду новых QA (мне это было тоже интересно, тем более у нас есть QA-комьюнити после курсов) и что изучу основную информацию о роли PO. СЕО сразу дал некоторую информацию о конкурентах, чтоб я тоже заранее начала знакомиться. И через месяц, 1 января 2018-го,я проснулась Product Owner’ом :)

Что мне помогло занять эту должность

• знание продукта. Обычно QA знают продукт изнутри лучше всех в команде, все его тонкости и особенности, в любой части. Это меня и по сей день выручает;
• хорошие soft skills (коммуникация, позитивный настрой, лидерство, работа в команде и прочее). Я хорошо коммуницировала с СЕО, вместе с ребятами поддерживали его, когда ключевые люди на этапе командных изменений покидали компанию. Мы были уверены, что наш стартап не развалится, и всячески помогали ему выстоять (морально и трудом), и в итоге все обошлось хорошо;
• PO, который вырос внутри компании, выгоднее для компании;
• опыт и готовность к новому этапу, желание развиваться дальше;
• готовность брать на себя ответственность, помогать с нестандартными задачами и принимать вызовы. Глаза боятся, а руки делают;
• поддержка со стороны руководства. СЕО был лоялен ко мне, а я старалась не подвести его и оправдать ожидания;
• поддержка со стороны близких. У меня было понимание и поддержка, это мой дополнительный источник энергии и уверенности в своих силах.

Но что делать дальше?

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

Что я делала как QA:

1. Тестирование в полном объеме.
2. Набор новой команды QA (поиск, собеседования).
3. Обучение новых QA.

Что я делала как PO:

1. Изучение информации о конкурентах.
2. Сбор и изучение требований от CEO.
3. Постановка задач дизайнерам.
4. Постановка задач разработчикам.

Особенности и сложности адаптационного периода

1. Дизайнеры у нас были фрилансерами. Мне нужно было им донести, а им в свою очередь вникнуть в суть нашего продукта и создать то, что выглядело бы достойно и целостно.
2. Требования передаются, как фольклор, из уст в уста. Никаких описаний, пользовательских историй, критериев принятия — только звонки или чат, где мы обсуждали фичи и их дизайн.
3. Тяжело приоритизировать всю входящую информацию. У СЕО было много идей по улучшению продукта, которые он отправлял мне на почту практически без пауз; приходилось его тоже привлекать для прояснения ситуации и расстановки приоритетов.

К чему желательно быть готовым в адаптационный период?

Работа по 12 часов в день. Днем я QA и тестирую продукт, общаюсь с командой. Вечером — PO и общаюсь с СЕО, дизайнерами, планирую работу.

Большой объем новой информации как по самому продукту, конкурентам, так и по новым процессам в команде. Здесь пришлось вплотную знакомиться с понятием приоритизации и с ее инструментами. Как вариант, можно начать с личных задач (к примеру, по матрице Эйзенхауэра), а потом перейти к приоритизации фич и привлечь к этому вашего менеджера или того, кто пока что дает вам задачи в работу (делитесь своими действенными инструментами приоритизации в комментариях).

Важно понимать и принимать тот факт, что часть задач из списка никогда не будет сделана, так как всегда находится задача поважнее, и нужно иметь смелость задачи «nice to have» удалять, чтобы они не отнимали у вас внимание и время на обдумывание и повторную приоритизацию.

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

• курс по Agile and Scrum Fundamentals (именно этот курс уже не проводится, но есть много других);
• книга Джеффа Сазерленда «SCRUM. Революционный метод управления проектами»;
• книга Дэвида Андерсона «Канбан. Альтернативный путь в Agile»;
• а также различные тренинги по Agile, Scrum, лидерству, конференции, митапы, воркшопы, клубы для PO/PM. Кстати, нетворкинг на таких мероприятиях помогает понять, что ты не один со своей проблемой, такие же проблемы возникают и у других команд, и это нормальные этапы их эволюции. В таком общении чужой опыт помогает вам что-то осознать или посмотреть на это под другим углом; и наоборот, ваш опыт может оказаться для кого-то очень ценным, таким, который они как раз ищут для ответа на свои вопросы.

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

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

Наставник

Через 3 месяца после моего старта на должности PO мы нашли нового СТО, который со временем стал новым СЕО, позволив предыдущему взять первый за 4 года отпуск и остаться только в совете директоров (никакой операционной деятельности).

Эти изменения положили начало новому этапу развития нашей компании. Новый СТО, Кайл, стал для меня наставником и проводником в мире управления IT-продуктом.

Мы начали совместную работу с того, что он показал, как писать базовую документацию, пользовательские истории и критерии принятия задачи, находить баланс между их лаконичностью и детализацией; мы стали больше анализировать метрики и обратную связь от клиентов. Мы покончили с фольклором, задачи теперь все в письменном виде; и потом, благодаря обратной связи от команды, у меня была возможность их улучшить. Сейчас я пишу отличные задачи, которые на ретроспективах оказываются в столбце Good / Keep doing и, по словам ребят из команды, превосходят по качеству те задачи, что были у них ранее в других IT-компаниях. Мне приятно, что мои старания упростить команде работу не проходят зря.

Роли, навыки и знания

Поскольку зачастую в стартапах и маленьких компаниях один человек может исполнять несколько ролей, мне необходимо было изучить особенности работы в команде с точки зрения ролей Scrum-мастера, менеджера и PO. Да, это конфликтующие роли (PO и SM) — приходилось контролировать себя и стараться выдерживать баланс :) Но мне было интересно это все изучать и практиковать, я и сейчас продолжаю совершенствовать свои знания в этих областях с удовольствием.

Командные встречи поначалу вел Кайл. Потом я стала проводить все встречи самостоятельно. Помню, как у меня на первых порах перехватывало дыхание, когда нужно было делать демонстрацию текущего релиза для всей компании, да еще и на английском, адреналин зашкаливал. Со временем, конечно, я перестала так бурно реагировать, и сейчас уже все намного проще. Английский я подтягивала благодаря курсам и практике на работе. Встречи я тоже понемногу стала улучшать. Для получения знаний и навыков по эффективному проведению командных встреч я прошла двухдневный тренинг по фасилитации встреч (ICP-ATF). Это помогло мне структурировать имеющиеся знания и навыки, приобрести новые. Благодаря этому тренингу я начала фокусироваться на цели, тайминге, структуре встречи. И, как итог, наши встречи стали более эффективными, мы стали достигать целей встреч за более короткие промежутки времени, чем ранее.

Еще в Scrum-мастерстве мне импонирует понятие «лидер-слуга». Придя на должность PO, я хотела быть максимально полезной для команды, иначе я здесь просто не нужна. Моя цель была не менеджить, а помогать команде, повышать эффективность ее работы с помощью устранения препятствий на пути. И эта цель, как маяк, позволяет мне не сбиваться с маршрута, слушать и слышать обратную связь, улучшать то, что может быть улучшено, напоминать о ценностях и беречь то, что уже работает хорошо. Как инструмент в этом помогают встречи, в частности ретроспективы, и простое человеческое общение, интерес к людям, к их проблемам. Важно задавать вопросы, иначе велики шансы так никогда и не узнать, что не так, и не улучшить это на будущее.

Примеры, чем можно помогать команде даже на самых ранних этапах:

1. писать понятные структурированные задачи;
2. выявлять блокеры на стендапах и давать ребятам оперативно решать проблемы;
3. быть на связи всегда, когда возникают вопросы по задачам или процессам;
4. создать позитивную безопасную рабочую атмосферу, где есть коммуникация, взаимопомощь, поддержка, уважение, открытость;
5. защищать команду от давления руководства, если такое давление есть;
6. не завязывать все процессы на себе, чтобы в ваше отсутствие ничего не рушилось;
7. не оказывать давление на команду, вгоняя ее в стресс;
8. не менеджить и не микроменеджить;
9. и многое другое (делитесь своими примерами, как вам помогает / не помогает ваш менеджер).

Если говорить о hard skills для менеджера/PO, то того опыта, что я получила на позиции QA, мне было достаточно для общения с командой на одном языке и понимания сути процесса разработки продукта. Со временем этот спектр знаний расширяется, узнаются некоторые нюансы и тонкости разработки, но все же непосредственно в код я не влезаю, и большее значение имеет знание о продукте, видение продукта и soft skills.

Итоги и мысли вслух

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

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

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

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

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

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

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

Нам свойственно переоценивать то, что может произойти за 10 лет, и недооценивать то, что может произойти за один-два года.Изменения в моей жизни произошли достаточно быстро. Около 10 месяцев прошло с момента идеи сменить род деятельности до момента начала работы на позиции QA; и это я еще долго решалась, потому что всего за неделю после курсов я устроилась на работу. И еще 6 месяцев прошло до получения должности PO. Сейчас, оглядываясь назад, я понимаю, что смена профессии была моим наилучшим решением. Я рада всему, что сейчас происходит в моей жизни. Это не значит, что все, что происходило до этого, было зря. Это был тот бесценный опыт и знания, которые стали фундаментом для нынешней меня.

Я за обмен информацией. Некоторые специалисты думают, что их знания — это именно то, за что им платят, и если их тайна раскроется, то они обесценятся как специалисты. Почему тогда хорошие обучающие тренеры не теряют в цене, если они постоянно делятся информацией? Если вы в чем-то хороши и у вас есть опыт, то, поделившись всеми своими знаниями, вы останетесь все так же хороши и опытны и вас будут продолжать приглашать работать. Ценность в вас самих. А знания и так в книгах есть. Я с удовольствием готова делиться полезной информацией, своим опытом, позитивной энергией с окружающими меня людьми; и более всего приятно, когда все это вдохновляет людей и меняет их жизнь к лучшему. В то же время я открыта к новой интересной и полезной информации, которая сделает мою жизнь еще лучше.

Как сказал Владимир Железняк в своей статье на DOU, «айтишники как вампиры. Норовят укусить кого-то и сделать из него айтишника тоже». Да, я тоже так делаю, мне хочется помочь умным толковым людям самореализоваться. Особенно если они попадают в схожую с моей ситуацию, когда нет развития в компании, а их таланты там никому не нужны.

Как развиваться дальше

Будучи уже менеджером, стоит выбрать направление. Это, к примеру, может быть работа с людьми и процессами (Scrum Master, Agile-коуч) или продолжение работы с бОльшим вниманием к продукту/проекту (Product Owner, Product Manager, Project Manager). И дальше совершенствоваться, учиться. Мне, к примеру, на данном этапе интересен коучинг. Записала себе парочку книг для прочтения: Лисса Адкинс «Коучинг Agile-команд», Джон Уитмор «Внутренняя сила лидера. Коучинг как метод управления персоналом» (делитесь тоже своими полезными книгами в комментариях).

И последнее, но немаловажное: работайте только по любви❤ Когда живешь в балансе и в гармонии с собой (делаешь то, что тебе нравится), это превращается в перманентное состояние счастья и удовольствия. Поэтому очень важно выявить в работе факторы, которые определяют ваше счастье, и создавать их вокруг себя. Ищите работу по любви, а не только ради денег. Цифра со временем перестанет так восхищать, а вот ощущение от самой работы будет с вами каждый день. И только вам решать, каким будет это ощущение.

Привет, меня зовут Дмитрий, я занимаюсь разработкой кросс-платформенных решений, игр, веб-сервисов и мобильных приложений. В этом мне очень помогает язык Haxe, который позволяет шире взглянуть на понятие full stack.

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

Какое-то время назад я уже писал статьиоб этом языке: одна была вводной, теоретической, а вторая, небольшая, практической; в ней речь шла о том, как запустить один и тот же код на разных платформах. Если вы никогда не слышали о Haxe, то я рекомендовал бы для начала ознакомиться с предыдущими статьями.

Также имейте в виду, что я буду использовать язык Haxe версии 4, который на момент написания этой статьи находится в версии release candindate.

В качестве редактора я использую VS Codeс официальным плагином.

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

Практическое знакомство с Haxe мы начнем через одну из самых популярных целевых платформ — JavaScript. Дальше, разобравшись с языком, углубимся в специфику отдельно взятых таргетов, в частности C++, Java (и JVM), C# и других. А потом, возможно, если это будет интересно сообществу, напишем какой-нибудь реальный проект.

Вступление

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

Примечание. В большинстве случаев компилятор Haxe — это на самом деле транслятор (transpiler). Однако в официальной документации используется именно термин «компилятор», так что мы тоже будем употреблять его. В дальнейшем вы поймете, почему границы между этими понятиями в контексте Haxe размыты.

Итак, вернемся к теме статьи — JavaScript.

Сегодня существует тысяча и одна причина не писать на JavaScript. Однако мы не будем пытаться доказать, что с JavaScript что-то не так. Тем более что современный стандарт очень даже неплох. Мы просто будем рассматривать Haxe как его хорошую альтернативу.

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

Haxe научился компилироваться в JS еще в 2006 году, задолго до появления TypeScript и Dart. Но, к сожалению, он выпал из информационного пространства, и далеко не каждый в курсе, что такой язык вообще существует. Именно потому я и пишу эти статьи: чтобы рассказать вам об инструменте, который незаслуженно находится в тени.

Однако пусть малая известность вас не пугает. Haxe — взрослый инструмент, а не фреймворк-однодневка. И, в отличие от TS и Dart, Haxe справляется с некоторыми задачами лучше и быстрее. Поэтому давайте для начала взглянем на следующий бенчмарк (ссылка на GitHub — внизу статьи), в котором тестируется декодирование изображения.

Автор этого бенчмарка протестировал Haxe, TypeScript, Dart и Wasm на одной и той же задаче. Как видите, скорость компиляции Haxe в десятки раз выше, чем у конкурентов. Haxe компилирует выходной файл очень маленького размера, а по времени выполнения кода он один из лучших, проигрывая лишь Wasm в Firefox.

Конечно, скажете вы, это все «синтетика». Но, уверяю вас: на практике Haxe даст вам множество способов оптимизации вашего кода. Более того, в некоторых случаях код, написанный на Haxe и транслированный в JS, может выполняться быстрее, чем аналогичный код, написанный вручную на чистом JS. Все это возможно благодаря оптимизирующему компилятору, статическому анализатору и языковым конструкциям, которые позволяют писать код, максимально оптимизированный под каждую платформу.

О качестве генерации кода

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

Если вы захотите опробовать код самостоятельно, то вам понадобится установленный в системе Node.js. Итак, создайте файл модуля Main.hxи поместите в него следующий код:

class Main {
  // Точка входа
  // Тип возвращаемого значения функции писать необязательно. В Haxe есть выведение типов из выражения.
  // Возвращаемый тип функции будет Void, потому что мы ничего в ней не возвращаем.

  static function main() {
    // Создадим контейнер с пользователями.
    // Указывать тип переменной, как и в случае с функцией, необязательно.
    final users = new Users();
    for (i in 0…10) {
    // Добавим 10 пользователей со случайным возрастом:
    users.push(new User(inline Std.random(99)));
  }

    // Выведем только взрослых пользователей в консоль:
    users.printOnlyAdultUsers();
  }
}

// Класс нашего пользователя.
// Сделаем все поля класса публичными (вместо ключевого слова `public`, объявленного возле каждого поля отдельно):
@:publicFields
class User {
  final age:Int;
  function new(age:Int) {
    this.age = age;
  }

  inline function toString():String {
    return 'User(age = $age)';
  }
}

// Наш контейнер с пользователями (обратите внимание, что это абстрактный тип):
@:forward(push, length)
abstract Users(Array<User>) {
  // Обратите внимание на ключевое слово inline:
  static inline final ADULT_AGE_VALUE:Int = 18;
  // Если тело функции содержит 1 строчку, то указывать {} скобки необязательно:
  public inline function new() this = [];

  public inline function printOnlyAdultUsers():Void {
    for (user in this) {
      if (user.age >= ADULT_AGE_VALUE) {
        trace(user.toString());
      }
    }
  }
}

Обратите внимание на абстрактный тип Users. В Haxe это не совсем то, что вы обычно представляете себе в других языках программирования. Абстрактный тип Haxe — это тип, который в рантайме является каким-либо другим типом. Фактически это обертка какого-то типа, если хотите.

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

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

Вы можете скопировать приведенный выше Haxe-код и собрать его со следующими параметрами в файле build.hxmlдля достижения аналогичного результата:

# Класс с методом main
-m Main
# Выходной файл
-js ./main.js
# Флаг для удаления неиспользуемого кода
-dce full
# Флаг для генерации ES6-классов (по умолчанию ES5)
-D js-es=6
# Включение статического анализатора
-D analyzer-optimize

Убедитесь, что Main.hxи build.hxmlлежат в одной директории. Сочетание Ctrl+Shift+B в VS Code вызовет меню компиляции. Выберите в выпадающем списке ваш build.hxml для продолжения.

Подробнее об hxml-файлах и компиляции Haxe читайте в предыдущей статье.

Итак, скомпилировав проект, на выходе мы получим вот такой JavaScript-код (ES6 для более удобного чтения, по умолчанию Haxe генерирует ES5):

class Main {
  static main() {
    // Класс `Users` был упразднен до обычного массива:
    var users = [];
    // Цикл for был полностью развернут (так происходит не всегда, к слову, глубина развертывания может быть задана опционально,
    // а тело метода `Std.random()` было помещено в место его вызова (inline-вызов):
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));
    users.push(new User(Math.floor(Math.random() * 99)));

    // Метод `printOnlyAdultUsers` класса Users
    // был упразднен и помещен в место его вызова:
    var _g = 0;
    while(_g < users.length) {
      var user = users[_g];
      ++_g;
      // Константа ADULT_AGE_VALUE была упразднена.
      if (user.age >= 18) {
        // Метод toString класса User был упразднен и помещен в место вызова:
        console.log("Main.hx:32:", "User(age = " + user.age + ")");
      }
    }
  }
}
class User {
  constructor(age) {
    this.age = age;
  }
  // Метод toString() был убран из реализации, так как его содержимое генерируется прямо в место вызова и в рантайме, в классе User, он нам будет не нужен. Это позволяет уменьшить размер выходного файла.
}

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

Использование Haxe-классов в JavaScript

Представим ситуацию: вы решили написать некую библиотеку на Haxe и хотите иметь возможность использовать ее в JavaScript-проектах. Однако по умолчанию Haxe-классы скрыты извне, и получить доступ к ним у вас не получится. Для таких задач в Haxe есть специальная мета — expose.

Давайте заменим код класса Mainиз предыдущего примера следующим:

class Main {
  static function main() {

  }
  // Отмечаем функцию как видимую извне
  @:expose
  public static function printText(text:String):Void {
    trace(text);
  }
}

Скомпилируем его, а затем создадим в корне нашего проекта файл test.js. Импортируем туда наш сгенерированный Haxe’ом JavaScript:

const hx = require("./main.js").Main;
hx.printText("Hello!");

Запускаем: node./test.js

И в консоли видим: Main.hx:8: Hello!

Отлично! Обратите внимание, что метатег exposeвы можете использовать как на поле класса, так и на самом классе.

Давайте вернемся на пару шагов назад и снова взглянем на сгенерированный код в main.js:

class Main {
  static main() {
  }
  static printText(text) {
    console.log("Main.hx:8:",text);
  }
}
$hx_exports["Main"] = Main;
Main.main();

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

Однако если вы попробуете скомпилировать проект на этом этапе, то получите ошибку: Haxe не может найти точку входа в приложение. Чтобы обойти это, нам нужно изменить файл с инструкциями для компилятора (наш build.hxml) и убрать оттуда строчку -m Main, заменив ее просто Main. Так мы скажем компилятору, что хотим экспортировать класс Mainбез привязки к какому-то конкретному главному классу приложения, в котором содержится точка входа.

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

class Main {
  static printText(text) {
    console.log("Main.hx:4:",text);
  }
}

Ничего лишнего!

Примечание. Внимательный читатель, наверное, уже обратил внимание на всю мощь этого подхода. Ведь Haxe умеет компилироваться во множество языков, а не только в JS! Перед вами открывается мир кросс-платформенной разработки. Написав бизнес-логику один раз, без привязки к платформе, вы сможете импортировать ее в проекты на абсолютно разных платформах! Скажем, в front-end на JS, сервер на PHP или Java. Однако нюансы работы с другими языками будут описаны в будущих статьях.

Использование JavaScript-классов в Haxe

Естественно, современный JS — это бездонная папка с зависимостями :) И если вы решили писать проект на Haxe, то непременно захотите воспользоваться сторонними библиотеками.

Создайте файл api.js с таким содержимым:

class Api {
  static printText(text) {
    console.log("api.js : " + text);
  }
};
module.exports.Api = Api;

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

Замените модуль Main.hxследующим:

// Всем известный require в JS:
@:jsRequire("./api.js", "Api")
// Обратите внимание, что класс объявлен с ключевым словом extern (т. е. "внешний"):
extern class Api {
  // Объявляем биндинги к функции:
  public static function printText(text:String):Void;
}

class Main {
  static function main() {
  // Метод принимает только строку. Ошибки с типами, как в JS, исключены.
    Api.printText("This is a text");
  }
}

Скомпилируем и взглянем на сгенерированный main.js:

var Api = require("./api.js").Api;
class Main {
  static main() {
    Api.printText("This is a text");
  }
}
Main.main();

Запустим и увидим в консоли This is a text. Все выглядит так, как и планировалось, и теперь мы можем вызвать JavaScript-функцию из сторонней библиотеки.

Стоит сказать, что, помимо этого, Haxe может встроить JS-файл и на лету склеить его с вашим кодом. Просто добавьте --macro haxe.macro.Compiler.includeFile("api.js") в ваш hxml-файл, и содержимое api.jsбудет встроено сразу в main.js.

Вставки JavaScript-кода

Бывают случаи, когда вам нужно сделать вставки кода на JavaScript (или любого другого таргета Haxe) прямо в место вызова. И Haxe это позволяет!

В разрезе этой задачи мы рассмотрим еще один способ работы с внешними классами — без типизации и написания биндингов (в терминологии Haxe — экстернов). Для этого видоизмените модуль Main.hxдо следующего вида:

// Обратите внимание, что вы можете импортировать функцию.
import js.Syntax.code;
class Main {
  static function main() {
    // Просто вставляем JavaScript-код:
    code("require('./api.js').Api.printText('Test 1')");

    // То же самое с захватом переменной:
    code("require('./api.js').Api.printText({0})", "Test 2");

    // То же самое с привязкой к Haxe-переменной:
    final printText1 = code("require('./api.js').Api.printText");
    printText1("Test 3");

    // То же самое с привязкой к Haxe-переменной и ее последующей типизацией:
    final printText2:(String)->Void = code("require('./api.js').Api.printText");
    // Теперь мы защищены от ошибки, связанной с типами передаваемых аргументов:
    printText2("Test 4");
  }
}

Как и прежде, я оставил комментарии, описывающие, что именно происходит в коде. Для сравнения посмотрим на сгенерированный JS:

class Main {
  static main() {
    require('./api.js').Api.printText('Test 1');
    require('./api.js').Api.printText("Test 2");
    require('./api.js').Api.printText("Test 3");
    require('./api.js').Api.printText("Test 4");
  }
}
Main.main();

Результат работы кода:

api.js : Test 1
api.js : Test 2
api.js : Test 3
api.js : Test 4

Еще раз рассмотрим пример, где мы выводим строку «Test 3»:

final printText1 = code("require('./api.js').Api.printText");
printText1("Test 3")

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

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

Так, в следующей строке мы уже написали более безопасный код:

final printText:(String)->Void = code('require("./api.js").Api.printText');
printText("Test 4");

Мы явно указали тип, сообщив компилятору о том, что printText — функция, которая принимает строку и ничего не возвращает. Теперь мы можем избежать ошибок, связанных с типами, еще на этапе компиляции.

Отладка Haxe и JavaScript

Haxe умеет генерировать карты исходников (source maps) для JavaScript, а значит, может и отлаживаться. Подробнее — здесь.

Если вкратце, у вас в арсенале есть два флага:

• —debug — для формирования debug-сборки и автоматической генерации source maps;
• —D js-source-map — для генерации source maps в релизной сборке.

Для отладки Node.js достаточно воспользоваться встроенным Node-отладчиком в VS Code. Добавьте -debugв ваш hxml-файл .

Добавьте задачу в tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "haxe",
      "args": "active configuration",
    "group": {
      "kind": "build",
      "isDefault": true
      },
      "label": "haxe-build"
    }
  ]
}

Подробнее про задачи в VSCode.

Добавьте конфигурацию в launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/main.js",
      "preLaunchTask": "haxe-build"
    }
  ]
}

Подробнее про конфигурации запуска в VSCode .

В конфигурации launch.jsonмы указали нашу задачу из tasks.json, которая будет компилировать Haxe-код перед запуском отладки сгенерированного main.js.

Готово! Ставьте брейкпоинт и жмите F5!

Макросы

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

Давайте опробуем их на самом простом примере. Создайте модуль Config.hxс таким кодом:

import haxe.Json;
import haxe.macro.Expr;
import haxe.macro.Context;

class Config {
  public macro static function get(file:ExprOf<String>):ExprOf<ConfigDef> {
    final pos = Context.currentPos();
    //Присваиваем значение прямо из блока try. Потому что в хаксе все является выражение.
    final c:ConfigDef = try {
	//Перечисляем наше выражение, которое пришло извне:
      switch file.expr {
        //Если выражение - строковая константа, то мы передаем ее значение далее в getContent:
        case EConst(CString(s)): Json.parse(sys.io.File.getContent(s));
        //Во всех других случаях выбросим ошибку:
        case _: Context.fatalError("Invalid file name.", pos);
      }
    }
    catch (e:Any) {
	//Выбросим ошибку компиляции, если парсинг JSON не был успешным:
      Context.fatalError("Invalid project config or file is not exists.", pos);
    }
    //Возвращаем наш конфиг с валидацией его полей через type check:
    return macro ($v{c} : Config.ConfigDef);
  }
}

А наш модуль Main.hxисправьте следующим образом:

class Main {
  static function main() {
    trace(Config.get("./config.json").server);
  }
}

Также нам понадобится файл config.jsonв корне, рядом с выходным main.js:

{
  "server": "https://google.com"
}

Теперь скомпилируем и посмотрим на выходной JS:

class Main {
  static main() {
    console.log("src/Main.hx:3:", "https://google.com");
  }
}

Мы с вами прочитали JSON-файл во время компиляции, взяли из него значение и вставили в наш код. Посмотрите, никакого оверхеда в рантайме! Кроме того, вы еще и получили валидацию своего конфига на лету. Попробуйте изменить config.json , сделав там опечатку в слове server. Haxe не даст вам такое скомпилировать.

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

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

Приведу пример. В одном из своих pet-проектов я не стал использовать синтаксис Express.jsодин в один, как это предлагает фреймворк: хотелось больше безопасности и гибкости. И вот с помощью макросов я пришел к следующему виду роутера:

class EventsRouter implements IRouter {
  @:get("/events.get")
  function getEvent(id:String) {
    res.asJson({id: id, title: "Event Title"});
  }
}

Это компилируется в следующий JS-код:

class EventsRouter {
  constructor() {
    this.__router.get("/events.get", $bind(this, this.getEvent));
  }
  getEvent(req, res) {
    var status = {isSuccess: true, message: "Operation done."};
    if (req.query.id == null || req.query.id.length == 0) {
      res.writeHead(400, {"Content-Type": "application/json"});
      status.message = "Invalid request";
      status.isSuccess = false;
      res.end({status: status, data: null});
    }
    else {
      var id = Std.string(req.query.id);
      res.writeHead(200, {"Content-Type": "application/json"});
      res.end({status: status, data: {id: id, title: "Event Title"}});
    }
  }
}

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

Итак, благодаря Haxe и макросам вы сможете автоматизировать множество процессов в своем проекте.

Конец

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

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

Если кто-то не разобрался, как что-то скомпилировать, настроить и запустить, смело спрашивайте в комментариях.

Спасибо, что дочитали!

Полезные ссылки

Getting started with JavaScript
Мануал по Haxe
Примеры кода
Форум
Wiki по плагину VS Code
Бенчмарк со скриншота

Мои статьи о Haxe на DOU
Связь со мною в Telegramm

Статья написана в соавторстве с Екатериной Сиротинской, HR-директором в Omnicore, и Дмитрием Куявцем, консультантом в области цифровых и организационных трансформаций.

Эта статья посвящена опыту трансформации украинской сервисной команды в продуктовую. Здесь вы найдете как теорию, так и информацию о реализации.

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

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

Развитие по количественному сценарию, очевидно, является тупиковым, поскольку (даже организовав демографический бум :) ) страна не сможет выиграть в конкурентной борьбе за стоимость услуг у перманентно демпингующих Индии, Пакистана или Филиппин. Второй, качественный, сценарий является более сложным и рискованным, но он позволит выстроить долгосрочную ценностно ориентированную стратегию. Многие IТ-аутсорсинговые компании делают ставку на проектную разработку, немногие — на исследования, и лишь единицы предлагают продуктовую разработку.

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

Вывод № 1: удобно, но нехорошо

И все-таки, помимо снижения доходов из-за высокой конкуренции и «генерации» огромного количества низкопрофильных ИТ-специалистов, зачем отказываться от столь удобного ИТ-аутсорсинга и что-то там строить? Хорошо ведь!

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

Случайно или наспех собранная сервисная команда не способна решать сложные задачи в долгосрочной перспективе. Кроме того, такая команда не в состоянии эффективно интегрироваться в компанию-заказчика для совместной разработки инновационного продукта. А учитывая статистику, «текучка» кадров в аутсорсинговых IТ-командах составляет более 20%, что вообще вызывает вопрос, может ли эта группа людей называться командой. Не радуют такие перспективы? Тогда читайте, как трансформировать сервисную команду в продуктовую ниже.

Вывод № 2: нет, не клиентоориентированность

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

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

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

Ценности продуктовой команды как системы

Вывод № 3: эволюция, не революция

Что это за ценности, как с ними работать и как сделать так, чтобы появилась система ценностей, релевантная для команды, для клиента и для бизнеса одновременно? На этот нетривиальный вопрос хотелось бы ответить точным высказыванием: «Ценности — это не качества сотрудников, а идеи, за которыми стоит команда». То есть на передний план выходит понятие культуры как совокупности ценностей членов команды, которые inline с ценностями компании и заказчика, а также оказывают на команду и всю систему саморегулирующее управленческое воздействие.

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

Вывод № 4: нет, не денежное вознаграждение

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

Итак, 8 ключевых ценностей сотрудников продуктовых команд в порядке их приоритетности:

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

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

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

Вывод № 5: не линейно

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

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

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

Контекст взаимодополняемости на основе разных типажей личностей довольно широко известен и не будет фокусным в этой статье. Хотелось бы лишь напомнить, что будет уместно использовать такие подходы, как DISC и Belbin, с их отличными готовыми опросниками, описаниями и рекомендациями по композициям команд. В этой статье мы хотели бы сфокусироваться на создании общности на «живом» примере трансформации небольшой украинской команды из сервисного уровня в продуктовый.

История одной трансформации

Мотивационные факторы

Итак, изначально в нашем активе была маленькая команда Red Dot Square, состоящая из 7 человек, которые работали в сфере VR. На этапе маленькой команды нет необходимости в четко формализованной миссии и видении, достаточно наличия у сотрудников общих ценностей, которые будут их объединять. Также эта команда должна состоять из людей, имеющих одинаковый уровень ответственности (ownership) за свой продукт.

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

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

Чтобы более системно подойти к этой задаче, было принято решение взять за основу для развития команды теорию спиральной динамики. Состояние To-Be мы определили как уровень ценностей компании в спиральной динамике. Состояние As-Is — это тот уровень спиральной динамики, на котором находятся ценности команды в данный момент. К сожалению, готовых опросников по спиральной динамике нам не удалось найти, поэтому пришлось создавать собственные.

Эволюция развития команды Кантар

Дорожная карта трансформации из состояния As-Is в To-Be требовала ряда шагов, первых из которых стало создание инициативной группы агентов изменений (leadership team), миссией которых стала помощь команде в адаптации ценностей.

Миссия — агенты изменений

Зачем нужны агенты изменений? Потому что ценности и цели ToBe необходимо было донести до членов команды в доступной форме и на собственном примере, каскадируя их сверху вниз, от агентов к команде.

Для этого команда агентов изменений регулярно, с периодичностью один-два раза в две-три недели, собиралась для того, чтобы в неформальной обстановке прописать поведенческие стандарты, которые привязывались к каждой из ценностей. Например, We Develop — что это для нас значит? Означает ли это, что мы должны развиваться сами и помогать друг другу расти? Как нам это реализовать на практике? Так, расширить компетенции коллег можно посредством инициирования регулярных inspiration breakfast, когда еженедельно на протяжении часа любой член команды может поделиться своим опытом или новыми знаниями с коллегами. Сессия обязательна для всех членов команды.

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

Этапы каскадирования ценностей Кантар

Отладка взаимодействий в команде

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

Практики команды Кантар на этапе «синей» организации в спиральной динамике

И это все не осталось лишь «на салфетках». Так, поведенческие проявления (Behavior), которые являются следствием ценностей, имплементированными самими же сотрудниками, каждые полгода оценивались с помощью специального опросника 360 (опросник можно будет найти по ссылке ниже), который показывал, насколько ценности человека и его поведенческие паттерны соответствуют организационным. Продуктивность (Performance) сотрудника оценивалась по ряду KPI’s, которые отслеживались PMO-командой аудиторов заказчика и/или аутсорсинговой компании. Компенсация также была обязательной, однако зависящей от финансовых результатов компании.

Для оценки мотивации раз в квартал или раз в полугодие использовался специальный мотивационный опросник, который проводился один раз в квартал или один раз в полугодие в зависимости от этапа развития команды.

Мотивационный треугольник Кантар

Мониторинг процесса трансформации команды

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

В итоге наша система мониторинга прогресса трансформации свелась к:

• имплементации системы разовых ежемесячных опросов сотрудников (профайлы DISC & Belbin профайлы) с разъяснением результатов команде;
• введению системы регулярных опросов сотрудников (опросник по спиральной динамике, мотивационные факторы, Feedback, Team Self-Assessment) с проведением разъяснения результатов команде;
• получению обратной связи от руководства компании и клиентов с последующим разъяснением результатов команде;
• стандартизации активностей группы агентов изменений, в частности проведению inspiration breakfast, старта хакатонов и т. д.

Эволюция порога входа в команду Кантар

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

Этапы внедрения мотивационного треугольника Кантар

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

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

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

• PDP
• Motivations factors
• Опросник 360
• SAFe Team Self-Assessment

Привіт, мене звати Олег Свірський. Я — продакт-менеджер в американському InsurTech стартапі Maticз офісами у Сан-Франциско, Лос-Анджелесі, Коламбусі і Львові. Ми змінюємо традиційну галузь страхування — одну з найбільш консервативних і регульованих індустрій в США. За лічені хвилини ми допомагаємо клієнтам підібрати оптимальний варіант страхування їхнього майна. Я відповідаю за розробку власної CRM.

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

Щоб переконатися, що ці професійні граблі не є унікальними для мене, я поспілкувався з понад 20 колегами-продактами, які працюють в Україні й за кордоном (Zalando, Booking, Vimeo, Grammarly, Badoo, ZeoAlliance, Tickets.ua, Edunav, Matic).

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

Що складніше: продукт чи менеджмент?

Почнемо з того, що загалом робота продакт-менеджера виглядає нескладно. Роби, як пишуть в усіх книжках про продукт чи стартап: знайди проблему, провалідуй гіпотези, сформулюй рішення, збери метрики, ітеруй... ПРОФІТ!

Що ж може піти не так?

З моєї практики, трохи більше, ніж все:

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

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

Отримав цікавий результат: 90% опитаних сказали, що менеджмент є складнішим.

Чому так? Що саме є найбільшими викликами у менеджменті для продактів? Як їх вирішити? У цій статті я хочу дати відповіді на ці питання, базуючись на власному досвіді.

Перший виклик — це stakeholder-менеджмент

Так виглядає типовий день продакт-менеджера: балансування

Якщо звести суть роботи продакт-менеджера до одного слова — це балансування. Ти постійно балансуєш між очікуваннями користувачів і вимогами менеджменту, між стратегічним баченням розвитку продукту і вимогами контракту з зовнішніми партнерами... You name it.

Складність у комунікаціях

Продакти взаємодіють з Engineering, QA, Design, Sales, Marketing, Support, Customer Success, Finance, Legal та багатьма іншими людьми, залежно від структури компанії. Кожен зі стейкхолдерів має власні очікування від продукту, що знаходить відображення в численних запитах до вас. З ростом організації керувати цими очікуваннями і пріоритезувати запити стає все складніше. Тож затрати часу на комунікацію зі стейкхолдерами, зазвичай, зростають за експонентою.

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

Зростання організації має ще одну побічну дію, пов’язану з комунікаціями: появу і посилення політичних процесів. Про це чудово писав Володимир Мірненко.

Політика — це, напевно, найнадокучливіше явище, на яке скаржаться продакти у всьому світі (Alpha product management report).

How much time do you spend on politics?

Балансування інтересів користувачів і стейкхолдерів

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

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

Приклад абсолютно пересічного питання для продакта: інвестувати в покращення UX чи працювати над інфраструктурою для збору додаткових метрик для Sales?

Потреба у крос-продуктовій взаємодії

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

Із ростом компанії ми зіткнулися з ускладненням залежностей між продуктами і департаментами. Нижче розповім про спосіб вирішення цієї проблеми, який ми використовуємо у Matic.

Другий челендж менеджера — лідерство

У Маtic немає традиційних проджект-менеджерів, і, формально, продакт-менеджер не відповідає за ефективність процесу розробки. Водночас, продакт — це саме та людина, якій «більше за всіх потрібно».

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

Тому кожен продакт, особливо в організаціях, де ця роль є новою, зіткнувся з мовчазним (іноді, ні) запитанням: «Хто цей чувак і чому він командує?».

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

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

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

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

Третій челендж продакт-менеджера: Mr. No

Ми, продакт-менеджери, сотні разів змушені говорити «ні» — команді, стейкхолдерам, керівництву і користувачам продукту. Усе тому, що ми несемо відповідальність за складні трейд-офи і змушені обирати, що є достатнім, а не ідеальним рішенням проблеми. Таким чином, ми, з одного боку, руйнуємо мрії дизайнерів й інженерів про seamless UI і user flow, відсутність технічного боргу й найновіші ліби. А з іншого боку, — мрії кожного кастомера про вирішення продуктом його персональної проблеми вже наступного тижня. Як комфортно працювати з таким реноме?

Рішення

Отже, у вас немає формальної влади, зате є купа стейкхолдерів, інших продактів, команда і повна відповідальність за продукт. Що ж робити?

Жартують, що на таке питання існує єдина правильна відповідь: it depends. Тож поділюся тим, що спрацювало для мене.

Впровадьте чи вдоскональте існуючу систему постановки і моніторингу цілей. Визначне залежності між цілями

Ми у Маtic використовуємо фреймворк ОКR. На початку року і щокварталу топ-менеджмент встановлює цілі на рівні компанії, а продакт-менеджери визначають цілі продукту і команди. На цьому етапі треба знайти відповіді на такі запитання:

• Які стратегічні теми і бізнес-цілі є ключовими для нас у наступні 3 місяці?
• Як розвиток продукту допоможе досягти ці цілі?

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

• Наскільки збалансовані задачі команд між собою?
• Які проекти задіюють різні продукти? Чи враховано це у їх роадмапі?
• Чи достатньо сил і ресурсів у команд для реалізації цих цілей? Чи потрібно змінювати конфігурацію команд?

Наприклад, коли одна з команд Маtic працювала над ключовим проектом компанії, інші команди включили у список своїх key results підтримку цього проекту і розв’язання залежностей. Узгодивши цілі між командами, ми уникли ризику почути від сусіднього проекту: «Чому ми це повинні робити і яка нам з того користь?», який міг би мати власні, неузгоджені з нами цілі.

І, наостанок, встановіть періодичність відслідковування прогресу цілей. Наприклад, наша команда оновлює прогрес з OKR раз на два тижні, перед кожним плануванням спринта. Так ми переконуємося, що в спринті заплановані задачі, які безпосередньо впливають на виконання OKRs. Якщо ж ми відстаємо від цілей, це сигнал для продакт-менеджера переглянути пріоритетність задач.

Керуйте очікуваннями

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

Тому я виробив наступний формат відповідей щодо часу реалізації фіч:

• якщо запитують про задачу, яка запланована і пріоритезована, та не є критичною, повідомляю, що фіча буде зроблена за наступні 1-2спрінти (2-4 тижні);
• якщо задача допоможе досягти OKR, але не потрапляє у наступні 2 спрінти, то відповідаю, що фіча запланована у нинішньому кварталі;
• якщо фіча є не терміновою і не узгоджується з ключовими цілями на квартал, то повідомляю, що фіча додана в беклог.

У будь-якому разі обов’язково подякуйте за ідею, адже людина витратила свій час для того, щоб надати вам фідбек чи підкинути ідею. Якщо проігноруєте — наступного разу ви теж не отримаєте бажаного фідбеку.

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

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

Підтримуйте комунікацію

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

Як же не загубитися у комунікаціях і не забути повідомити усіх зацікавлених про важливі події? Як на мене, якщо в компанії працює понад 50 людей, продакту саме час розробити RACI-матрицю.

Спілкуючись зі стейкхолдерами усно або письмово, завжди персоналізуйте меседж і задавайте собі питання: what’s in it for me? Яку цінну для себе інформацію реципієнт отримує з вашого повідомлення? Як новини від вас можуть вплинути на його роботу, на терміни її виконання? Які деталі варто включити у ваше повідомлення з огляду на це? До речі, ось класний Телеграм-канал, який допоможе покращити email-комунікацію.

Захищайте команду

Найчастіше рішення щодо продукту продакт приймає не одноосібно, а в команді. Продакт може бути не згодним з рішеннями команди на всі 100%. Утім, якщо ви не змогли «продати» команді власну ідею, рішення команди стає і вашим рішенням. Тепер ваша задача — якнайкраще пояснити стейкхолдерам чи менеджменту, чому ідея реалізована саме так, як вона є.

Отримали баг на проді, гнівні коменти юзерів і наполегливі повідомлення від менеджменту «негайно пофіксити»? Ваша задача — оберігати від цього команду і взяти кризові комунікації на себе. У спокійній обстановці команда краще впорається з кризовою ситуацією. А ви, тим часом, краще принесіть всім чарку кави ;)

Пам’ятайте, продакт-менеджер, за RACI-матрицею, рідко Responsible й майже завжди Accountable.

Мінімізуйте політику

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

Будуйте крос-продуктову колаборацію

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

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

Розвивайте продуктове мислення команди

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

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

Втім, я дуже тішуся, що все частіше чую від членів команди: «Я подумав, що може бути корисно для користувача, і пропоную інший варіант вирішення проблеми, давай його розберемо».

Don’t be an asshole

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

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

А як щодо того, що є найскладнішим у роботі з продуктом?

Ви вже знаєте правильну відповідь: it depends. За результатами мого опитування понад 20 продакт-менеджерів, я отримав 15 різних варіантів суто продуктових челенджів. І це, напевно, найкрутіше, що є у роботі продакта. З розвитком продукту змінюються активності й ключові задачі, постійно з’являються нові виклики і речі, які тобі доведеться робити вперше. Це вимагає від продакт-менеджера розвивати нові скіли, оскільки, наприклад, продакт у pre-market fit стартапі й B2B Enterprise — це дві зовсім різні людини.

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

Stay tuned, coming soon, leave your email to get a free copy.

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

Це перший із серії матеріалів, присвячених розробці безсерверних веб-застосунків на Python.

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

Адаптування традиційних веб-застосунків для роботи на AWS Lambda це й досі не цілком тривіальне завдання, але варто в ньому розібратися і брати його до уваги наступного разу, коли десь треба буде впровадити веб-службу. І щоразу з ним буде простіше впоратися.

Отже, що ми тут розуміємо під «безсерверністю»? Ідеться про те, що більше нема потреби керувати серверами й довготривалими процесами. Ви просто завантажуєте код у хмару та виконуєте його коли й скільки разів потрібно, не переймаючись масштабуванням і оплачуючи лише процесорний час, об’єм пам’яті й інші ресурси, якими користуєтесь. Цей спосіб розгортання застосунків разюче відрізняється від звичного керування серверами й інфраструктурою, балансування навантаження й інших приколів, ніяк не пов’язаних із написанням коду та його розгортанням.

Python і Flask

Наразі є багато варіантів реалізації веб-фреймворків, і Python 3 у зв’язці з Flask — далеко не найгірший із них. Flaskдає змогу створювати прості веб-служби з мінімумом шаблонного коду, а також згодиться як компонент для розробки складнихвеб-застосунків з одним застереженням: він краще пасує для API, ніж застосунків із рендерингом на стороні серверу, на відміну від Django, наприклад. Та все одно в наші часи здебільшого доводиться мати справу з односторінковими застосунками.

Python — мова, що зажила широкої підтримки та має багатий каталог бібліотек-модулів, яка дає змогу писати легкий для сприйняття і простий у супроводженні код. Якщо ж витратити трохи часу на налаштування контролю якості коду засобами mypyі flake8, можна забезпечити завчасну перевірку відповідності типів і відловлювання поширених помилок. І підтримка для цього всього є в AWS Lambda.

Як виглядає безсерверний застосунок на базі Flask

Щоб створити безсерверний застосунок на платформі Lambda, потрібен шаблон конфігурації CloudFormation, що б описував вашу архітектуру.

Платформа Lambda є лише одним зі складників цієї архітектури — це функція, що повертає певний результат, яку можна будь-коли викликати. Щоб скористатися нею як веб-службою, треба якось отримати до неї доступ з інтернету. AWS має службу API Gateway (APIGW), яка може очікувати, доки на кінцеву точку надійде HTTP(S)-запит, і зробити те, що потрібно. APIGW може мати записи для кожної кінцевої точки (POST /api/foo, GET /api/bar тощо) або проксіювати запити, що надходять на певний хост, до Lambda із додаванням певного префікса шляху, а потім інтерпретувати відповідь як HTTP-відповідь та передавати її ініціаторові запиту. У такому разі ця служба буде працювати як загальний інтерфейс шлюзу (common gateway interface, CGI) або інтерфейс шлюзу веб-сервера (web server gateway interface, WSGI), і якщо ваш веб-фреймворк може виконувати десеріалізацію проксійованих API Gateway запитів, а потім серіалізувати відповідь у формат, прийнятний для APIGW, для вашого застосунку вона буде іще одним «контейнером» веб-застосунку.

Для цього у Flask є спеціальне розширення — AWSGI. На прикладі нижче — все, що потрібно для того, щоб ваш застосунок зробити безсерверним:

Єдине, що тут є специфічного для Lambda — функція lambda_handler, яка передає Flask потрібний об’єкт WSGI-запиту, а потім перетворює відповідь у формат, потрібний AWSGI.

Отже, інфраструктура доволі очевидна — хостинг коду на Lambda, API Gateway для зворотного проксіювання, і таке інше. Звісно, ще потрібні деякі супутні дрібниці на зразок дозволів для керування ідентифікацією та доступом (identity and access management, IAM) та, мабуть, бази даних чи об’єктного сховища — Amazone S3 bucket, або чого там іще потребує ваш застосунок. Все це можна визначити в шаблоні CloudFormation.

У AWS CloudFormation наявні «трансформації» (transform), які спрощують налаштування таких речей, надаючи шаблонні ресурси для вашого шаблону. Шаблони в шаблонах — дійсно вдалий спосіб визначення конфігурації. Від вас потрібен лише необхідний мінімум дій.

Resources:
    HelloWorldFunction:
        Type: AWS::Serverless::Function
        Properties:
            CodeUri: hello_world/build/
            Handler: app.lambda_handler
            Runtime: python3.6
            Events:
                HelloWorld:
                    Type: Api
                    Properties:
                        Path: /hello
                        Method: get

У підсумку ви отримуєте Lambda, на якій виконується код, завантажений у сховище S3 після виклику у /hello.

Розгортання

Розгортання відбувається не настільки гладко, як, наприклад, у випадку з Heroku, але ситуація поступово поліпшується. Хоча є кілька популярних інструментів для керування взаємодією систем у безсерверних конфігураціях на зразок Serverless Framework, але я поставив собі за мету зробити якнайбільше за допомогою власного інструментарію AWS.

AWS має службу, якою, мабуть, ніхто крім мене досі не скористався — CodeStar. Вона автоматично створює конвеєр (pipeline) для розгортання безсерверних застосунків, налаштовуючи CodePipeline, CodeBuild і CloudFormation так, щоб у підсумку отримати систему неперервної інтеграції та розгортання застосунків. Можна зробити так, щоб вона збирала застосунок щоразу, як ви щось додаєте у репозиторій на GitHub і автоматично повторно його розгортала за допомогою CloudFormation. Трансформація CodeStar CloudFormation додатково спрощує і так нескладний процес роботи з шаблонами.

Документація, присвячена CodeStar і супутній трансформації, доволі куца, тож розбиратися з ними — це для тих, хто не шукає легких шляхів. Втім, ця штука дійсно завантажує код у сховище S3 і налаштовує кілька ролей. Шаблон для CodeStar template.ymlможе виглядати якось так:

 Flask:
    Type: AWS::Serverless::Function
    Properties:
      Timeout: 10
      Handler: myapp/index.lambda_handler
      Runtime: python3.6
      Role:
        Fn::ImportValue:
          !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]

Якщо створити репозитарій із файлом myapp/index.py, що міститиме функцію lambda_handlerна зразок наведеного вище обробника AWSGI, отримаєте безсерверний веб-застосунок, що буде автоматично оновлюватися щоразу, як ви завантажуєте код у свій репозитарій на GitHub і виконується CodeBuild.

І хоча завдяки всьому, що можуть запропонувати AWS і CloudFormation, CodeStar потенційно може спростити розробку безсерверних застосунків до рівня Heroku, але, здається, ним досі ніхто активно не намагався користуватися. Я спробував додати IAM-роль до своєї функції Lambda, але стикнувся з проблемою, що спантеличила навіть службу підтримки AWS. Кінець кінцем там підтвердили, що задокументованого способу налаштувати роль IAM немає.

«Після додаткового тестування і дослідження проблеми, я дійшов висновку, що наразі немає можливості налаштувати IAM-роль безсерверної функції Lambda засобами template.yml. Натомість доведеться надавати потрібні права IAM-ролі вручну. Втім, як ви й зауважили, роль функції Lambda створюється автоматично і тому немає можливості визначити саме ту IAM-роль, яка буде застосована».

Як тимчасове розв’язання проблеми, можна простежити як трансформація CodeStar (принцип роботи якої не дуже зрозумілий) складає назву ролі, та надати права саме потрібній ролі. Маю сумнів, що це підтримується чи десь задокументовано. Але служба підтримки обіцяла все виправити.

Розгортаючи Lambda, можна цілком обійтися й без CodeStar, але якщо бажаєте пошаманити над екзотичнішими службами AWS, вона може стати цінним інструментом, залежно від ваших потреб. Але це завжди задоволення — бачити як занедбані служби AWS з часом розвиваються та набирають популярності (маю на увазі CodeDeploy тощо); до того ж, уявіть, як захоплено будуть слухати друзі про місяці ламання списів зі службою підтримки AWS з приводу однієї-єдиної проблеми.

До речі, коли спробував за допомогою CodeBuild провести кілька тестів на своєму проекті, виявилося, що образу з python 3.6 тут нема, тож користі в цьому випадку з інструменту було нуль. Наразі вони, здається, його додали, тож тепер можна щось робити.

Інші варіанти розгортання

Якщо вам просто треба налаштувати Lambda на швидку руку, заморочуватися з системою неперервної інтеграції та розгортання і CloudFormation не доведеться. Налаштування для одиничного використання можна виконати вручну — треба лиш написати трохи коду, запустити його, й забути. Чудовий варіант для Slack-ботів і невеликих веб-служб, як на мене. Я зробив собі плагін для Sublime Text 3, щоб редагувати AWS Lambda. Він дає змогу редагувати Lambda прямо у Sublime і завантажує оновлену версію щоразу, як ви зберігаєте файл. Також, можна її викликати й дивитися, що вона повертає, не покидаючи Sublime, а також можна зручно додавати залежності до проекту за допомогою pip. Це значно спрощує роботу і точно зручніше, ніж користуватися веб-редактором функцій або розархівовувати й архівувати назад свій пакет щоразу, як треба змінити код.

Залежності

Свою Lambda можна завантажити як звичайний архів папки у форматі ZIP. У папці буде код вашого застосунку, а також всі дані й залежності, які йому потрібні (десь там будуть також ваші мрії й сподівання). Якщо застосунок потребує додаткових бібліотек (на додачу до boto3, яка в Lambda вже є), їх потрібно буде додати.

Щоб спростити розгортання, можна скопіювати бібліотеки, інстальовані у віртуальне оточення проекту. Якщо бібліотеки містять апаратно-залежний код, його треба компілювати на linux-машині з архітектурою amd64, бо на такій працює Lambda. Деякі інструменти автоматизують цей момент за допомогою Docker.

Якщо потрібен зручніший варіант, можна створити папку, в яку можна швидко закинути все, що потрібно.

Для свого проекту я написав невеличкий скрипт, за допомогою якого можна встановлювати пакети через pip у визначену папку («vendor/»). Нічого надзвичайного, насправді. Він просто виконує команду «pip install -t ...» і видаляє потім непотрібні файли.

На початку файлу __init__.pyмого застосунку я додаю постачальника та вказую кореневий шлях до PYTHONPATH. У підсумку я отримую невеличке віртуальне оточення, в якому можу користуватися всіма модулями, інстальованими у директорії постачальника.

import os
import sys
vendor_path = os.path.abspath(os.path.join(__file__, '..', '..', 'vendor'))
lib_path = os.path.abspath(os.path.join(__file__, '..', '..'))
sys.path.append(lib_path)
sys.path.append(vendor_path)
from flask import Flask
...

А потім можна просто імпортувати всі потрібні залежності, які будуть додані у пакет.

Збираємо докупи

Я створив простий веб-застосунок, щоб поекспериментувати з CodeStar. Він дає користувачам змогу ставити питання й відповідати на них. Спочатку це був застосунок для Slack, але з ним все сталося не так, як гадалося.

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

Цей застосунок не робить нічого надзвичайного: просто дає змогу користувачам ставити питання і відповідати на них. Уперше я його реалізував як веб-службу, сумісну з Slack webhooks та Slash Commands HTTP API, згодом додавши підтримку REST API для вебу.

Був би це серйозний проект, я б зробив базу даних на PostgreSQL, але ж я хотів не просто навчитися добре проектувати безсерверні застосунки на базі Flask — треба було й мінімізувати витрати на хостинг. На жаль, PostgreSQL не можна наразі назвати цілком безсерверним рішенням, тож на AWS доведеться витрачати щонайменше кілька десятків доларів на місяць, якщо бажаєте, щоб ваш PostgreSQL-сервер працював не на безплатному мікроінстансі EC2. Отже, я вирішив скористатися NoSQL-рішенням від AWS — DynamoDB. Це доволі незручне сховище колекцій «ключ-значення» з документацією для boto3 написаною якимось садистом, але недороге та добре масштабується без зайвих зусиль. Принаймні, у теорії. Але на практиці це повна фігня.

За кілька доларів на місяць з DynamoDB ви отримуєте таблиці та індекси, і, на мою думку, можна цілком обійтися однією-двома, якщо не заморочуватися чимось на зразок реляційної бази даних. Додайте ще безкоштовнімільйон запитів і 400,000 Гбайт-секунд обчислювального часу на місяць на Lambda, і ви отримаєте місце, де можна виконувати код і зберігати дані майже задарма. І горизонтальне масштабування тут не має потребувати додаткових уваги та зусиль. Звісно, насправді все не настільки просто, але чудово знати, що таке можливо. Щонайменше мені більше не доведеться налаштовувати веб-сервер або адмініструвати машину просто для того, щоб розгорнути веб-застосунок, і доплачуватиму за це я (дуже) невелику суму. Одна з найбільших переваг безсерверних застосунків — можливість налаштувати все один раз і більше цим не перейматися. Якщо перший раз запрацювало — працюватиме й надалі. Вам не доведеться перейматися відмовою дисків і резервним копіюванням і думати, як впоратися з піковими навантаженнями та простоями. Звісно, AWS — не втілення довершеності, але коли йдеться про забезпечення цілодобової роботи моїх «лямбд», я їм довіряю більше, ніж багатьом людям і навіть собі. Особливо собі.

Таємні ключі

Як і з будь-яким розгортанням застосунку, вам знадобиться сховище для таємних ключів. Lambda не потребує ключа API AWS, бо вона виконується з IAM-роллю, якій можна надати доступ до всіх потрібних служб. Для зовнішніх служб можна використовувати сховище AWS SSM Parameter Store. Воно дає змогу зберігати таємні ключі й отримувати до них доступ ролям або користувачам, які мають дозвіл на їх зчитування. Це чудовий варіант для зберігання ключів API, токенів тощо.

Оскільки ми користуємося Flask, SSM Parameter Store можна легко інтегрувати у файлі config.pyфреймворку:

import boto3
ssm = boto3.client('ssm')

def get_ssm_param(param_name: str, required: bool = True) -> str:
    """Get an encrypted AWS Systems Manger secret."""
    response = ssm.get_parameters(
        Names=[param_name],
        WithDecryption=True,
    )
    if not response['Parameters'] or not response['Parameters'][0] or not response['Parameters'][0]['Value']:
        if not required:
            return None
        raise Exception(
            f"Configuration error: missing AWS SSM parameter: {param_name}")
    return response['Parameters'][0]['Value']

TWILIO_API_SID = get_ssm_param('qanda_twilio_account_sid')
TWILIO_API_SECRET = get_ssm_param('qanda_twilio_account_secret')
SLACK_OAUTH_CLIENT_ID = get_ssm_param('qa_slack_oauth_client_id')
SLACK_OAUTH_CLIENT_SECRET = get_ssm_param('qa_slack_oauth_client_secret')
SLACK_VERIFICATION_TOKEN = get_ssm_param('qanda_slack_verification_token')
SLACK_LOG_ENDPOINT = get_ssm_param('qanda_slack_log_webhook', required=False)

Таємні ключі: у безпеці.

Локальне виконання

Оскільки «лямбди» виконуються в AWS, можна припустити, що розгортання й тестування кожної заміни в коді за допомогою AWS — обтяжливий процес. Дійсно, було б дуже прикро, якщо б це дійсно доводилося робити. Є такий проект для AWS — SAM-CLI (інтерфейс командного рядка для застосунків безсерверної моделі). За допомогою докерних образів Lambda можна викликати застосунок у такому ж оточенні, в якому б він працював на Lambda. На нього можна передати файл JSON, де описаний запит для Lambda і подивитися відповідь, або запустити його як сервер, до якого можна під’єднатися як до будь-якого локального веб-сервера розробки. Вам також знадобиться ключ API AWS, якщо бажаєте, щоб застосунок використовував служби AWS, оскільки він виконується на локальній машині без підтримки ролі в інстансі AWS.

Ще приклади

Узагальнюючи написане вище, ось кілька думок, які треба брати до уваги під час створення та розгортання безсерверних веб-застосунків. Мені сподобалося, як усе зійшлося в моєму навчальному проекті QandAі пропоную вам поглянути на його структуру й вихідний код , якщо вам потрібен повноцінний приклад. Я міг би також заглибитися в подробиці щодо того, як я структурував Flask-застосунок, але це мало стосується Lambda чи безсерверного аспекту — якщо вам це цікаво, просто подивіться код.

Lambda ще на початковому етапі розвитку, і з нею працювати не так легко, як із Heroku. Але вона має й незаперечну перевагу: можливість просто «виконувати код у хмарі», не переймаючись керуванням сервером, майже задарма. Витративши трохи часу на налаштування безсерверного застосунку, ви матимете простий спосіб виконувати код в інтернеті, зосередившись лише на рівні «запит -> код застосунку -> відповідь». На мою думку, краще вже писати код і файли налаштувань, а не заморочуватися керуванням інфраструктурою й серверами.

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

Иллюстрации: Дарина Скульская

Унижай и властвуй

Начну, пожалуй, с «давным-давно». Так вот, давным-давно довелось мне устроиться на работу в свою первую IT-компанию и была у меня менеджер-женщина, 34+, пергидрольная блондинка, чуть полноватая и ругающаяся матом, как отпетый сапожник. Было у нее в подчинении 15 мужиков разных возрастов и 2 девочки-студентки. Такого порядка, четкости соблюдения сроков и практически 8-часовойпродуктивной работы я не видела больше никогда на проекте.

Вы думаете, какая-то чудесная методология разработки или очень точное планирование помогали добиться такого эффекта? (13 лет назад там никто и не слышал таких слов.) Страх! Унижай и властвуй — вот кредо этой мадам, которая, к слову сказать, оказалась довольно неплохим психологом и знала больные места каждого. Даже взрослые дядьки боялись ее гнева, не говоря уж о тощих юнцах, для которых эта работа вообще была первой. Так вот, через несколько лет я случайно узнала, как директора компании нашли столь ценный кадр. В ресторане! Да-да, она работала официанткой в ресторане, куда они зашли пообедать и обсуждали, что не могут найти менеджера для проекта.

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

Небожители

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

Технари

Далее следуют менеджеры-технари. Это обычно те, кого назначили на эту должность из программистов или системных архитекторов. Сами они ужасно этого не хотели и в душе жутко скучали по тем дням, когда могли натянуть наушники и просто кодить, но... У каждого причина была своя: кто-то не смог отказать начальству, кто-то погнался за ЗП, кто-то устал идти в ногу с технологиями и решил отсидеться в менеджерах: так солиднее, и учить новое не надо. В целом у этих ребят был один плюс: они технари, и за техническую часть проекта болели, понимали ее и даже брали на себя смелость объяснить это заказчику. Но на этом их менеджерские плюсы заканчивались. В основном это люди достаточно асоциальные, каждое обращение подчиненного с нетехническим вопросом вызывало у них физические страдания, и весь их вид кричал: «Уйди-уйди, пожалуйста, я не хочу этого знать».

Нетехнари

Была в моем опыте и полная противоположность этим ребятам. Это был менеджер, который пришел в IT из крупнейшего мобильного оператора. В IT-технологиях не понимал абсолютно ничего, но более блестящего руководителя мне не доводилось встречать. Он умело общался с заказчиками; сглаживал углы, если команда не успевала или портачила; решал все вопросы по персоналу (от сломанного стула до конфликта между людьми) либо умело делегировал их решение; хоть и имел отдельный кабинет, пользовался им только для переговоров; заботился о каждом сотруднике и о команде в целом.

Но знаете, в чем была главная изюминка его успешного руководства? Доверие! Мне все-таки кажется, что это была вынужденная мера, а не лично его стратегия; тем не менее она круто работала. В силу того, что технически он был не подкован, ему приходилось полагаться на свою команду, на то, что они знают, что делают, и сделают, как надо. Это, в свою очередь, породило ответную реакцию у команды: есть наш менеджер, который о нас заботится, делает нам хорошо, как же мы можем его подвести? И никто не подводил! Нужно задержаться — окей, нужно найти решение поставленной задачи — найдем. И все это делалось не из-под палки, а на энтузиазме и в благодарность. Не знаю, хорошо это или плохо; уверена, что будет не одно мнение на этот счет, но это показательный пример.

Тираны

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

Главное кредо таких горе-менеджеров — «преступление и наказание». Их основная задача — найти виноватого и наказать, а еще лучше — публично. Для примера: была у меня менеджер, которая приходила на работу на час раньше (сидела она напротив входной двери), и каждый раз, когда открывалась дверь, приподнималась из-за монитора, чтобы посмотреть, кто пришел и в какое время. Если ты опаздывал хоть на минуту, она записывала это и на дейли-стендапе (ну так, чтобы при всех) спрашивала: «А почему ты опоздал?» Ответ был неважен, главное было потом сказать: «А вот я прихожу на час раньше на работу, чтобы успеть подготовить свое рабочее место, выпить кофе и все такое и начать работу ровно в 9:00, и ты должен».

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

Еще одна представительница такого менеджмента все время пыталась убедить подчиненных, что они должны работать эффективно все 8 часов, а если хотят повышения, то и больше (ну и, само собой, бесплатно), «вы же заинтересованы в проекте». У вас не должно быть никаких интересов и мыслей, кроме как о благе проекта и компании. Дети, семья, хобби? Всему этому нет места в жизни по-настоящему хорошего и ценного сотрудника. (На самом деле в ее жизни, но... об этом как-то умалчивалось.) А главный аргумент был тот, что, если не будет проекта, у вас же не будет работы и вы умрете с голоду. Нет! Люди просто перейдут в другую компанию, что, собственно, сделали практически все ключевые разработчики и тестировщики на этом проекте после такого «менеджмента», где, чтобы корова меньше ела и давала больше молока, ее нужно меньше кормить и больше доить.

Кто такой хороший менеджер

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

Человечность. Хороший менеджер (украду мысль из «Черной книги менеджеров») должен не только сидеть в своем кабинете и строить графики, но и всегда знать, чем живет каждый член его команды. И если у условного Васи дома рожает любимая кошечка, хороший менеджер должен чувствовать глубину его переживаний по этому поводу. Возможно, лучше Васю отпустить на несколько часов домой, чем он будет сидеть и бесполезно пялиться в монитор, думая, как там его кошка.

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

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

Он не технарь. Тут я готова услышать holy war :) Просто оставлю это как мое субъективное мнение: из нетехнарей получаются лучшие менеджеры, чем из технарей. На вопрос программистов: «А к кому же мне идти, если у меня вопрос технического характера?» — отвечу так: у вас есть тимлид или старший коллега. Если вы сеньор, то это уже предполагает, что с большинством проблем и вопросов технического характера вы можете справиться сами.

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

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

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

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

Всегда в курсе.Хороший менеджер всегда держит руку на пульсе и всегда знает, «куда мы идем». Повторю свою мысль из предыдущего пункта: если это не так, то у вас проблема с процессами.

Вовремя реагирует.Руководитель должен моментально принять меры, когда что-то идет не так, а не ждать пока его «подданные» сами разрулят ситуацию. Если вам не сообщают вовремя о возникшей загвоздке, ваш процесс построен неверно.

Умеет строить процессы. Думаю, уже понятно, насколько это важно :)

В завершение

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

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

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

За традицією представляю на DOU новий рейтинг шкіл за результатами ЗНО-2019 на основі відкритих данихУкраїнського центру оцінювання якості освіти (УЦОЯО).

Минулого року свої рейтинги на основі даних УЦОЯО опублікували також й інші інтернет-видання, такі як Osvita.uaі Фокус. Це мене не може не радувати, тому що, публікуючи рейтинг і аналітику в 2016 році, я сподівався звернути увагу читачів на відсутність зрозумілої для батьків інформації про якість освіти в школах і на брак якісного аналізу сфери середньої освіти в Україні. Тепер, завдяки відкритим даним звітів УЦОЯО, у фахівців з’явилася гарна можливість оцінити рівень освіти в країні в цілому та регіонах, а також відстежувати динаміку змін. Один з хороших прикладів аналізу даних ЗНО — на порталі Vox Ukraine.

Отож, якщо подібні рейтинги вже публікують інші видання, то навіщо ще один?

По-перше, трохи відрізняються методики розрахунку. Наприклад, портал Osvita.ua у своєму рейтингувраховує дані лише за поточний рік і підвищує позицію шкіл з більшою кількістю випускників. Я розумію бажання порталу усунути похибку обчислень для шкіл з малою кількістю учнів, але з погляду статистики цей підхід не зовсім правильний та й несправедливий щодо малих шкіл, наприклад, приватних або сільських. У цьому рейтингу додатково враховуються результати двох попередніх років (за 2017 і 2018 роки), що дозволяє усунути таку похибку, а також згладити можливі аномалії. Адже якщо невелика школа показує стабільні результати з року в рік, її місце в рейтингу розраховано коректно.

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

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

Топ-100 шкіл в Україні

Нижче представлений зведений рейтинг найкращих 100 шкіл в Україні за результатами ЗНО за 2019 рік і двох попередніх років*. Безумовним лідером протягом чотирьох років є київський Ліцей Інтелект:

Показати більше шкіл

* Примітка.У рейтингу враховуються всі отримані бали незалежно від предмета (за 200-бальноюшкалою). Зауважимо, що бали виставлені за так званою «рейтинговою шкалою»від 100 до 200 балів. Ці значення не можуть бути використані для оцінки реальних знань, але дозволяють виявити рівень школи або учня щодо всього масиву даних.

Рейтинг складено за середнім арифметичним від усіх отриманих балів з усіх предметів у результаті тестування за поточний рік, з поправкою на такі ж результати попередніх років («зведений рейтинг»). Зведений рейтинг розраховується за методом зваженого ковзаючого середньоговід середніх балів школи за три роки.

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

Як бачимо з наступного графіка, Київ продовжує лідирувати за кількістю шкіл у топ-100, але тенденція зростання припинилася:

Розподіл шкіл з ТОП-100 за регіонами

Харківська область демонструє стійке зростання три роки поспіль. Цього року в топ-100 вперше з’явилися школи з Чернігівської та Донецької області, а Хмельницька область залишається єдиною, школи якої два рокi поспiль не потрапляли до рейтингу.

Топ-20 шкіл з розподілом за містами

Топ-100 шкіл для сфери IT й інженерних спеціальностей

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

Показати більше шкіл

** Примітка.У рейтингу враховуються тільки ті школи, з яких як мінімум три учні взяли участь у тестуванні по кожному з цих предметів.

Школи, що випустили найбільше відмінників

Нижче представлені 10 шкіл з найбільшою кількістю випускників, що здали тестування з трьох предметів і більше із середнім балом 190 і вище. Як бачимо, безумовним лідером є Львівський фізико-математичний ліцей-інтернат:

Найкращі загальноосвітні школи

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

Частка найбільших типів навчальних закладів

Нижче представлена двадцятка найкращих загальноосвітніх шкіл:

Школи з високою позитивною динамікою в результатах

Нижче представлені двадцять шкіл з найвищою позитивною динамікою в результатах за останні три роки:

Школи з високою негативною динамікою в результатах

Нижче представлені двадцять шкіл з найвищою негативною динамікою в результатах за останні три роки:

Школи з найнижчими результатами

Нижче представлені двадцять шкіл з найнижчими результатами цього року:

Наостанок

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

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

Цей текст буде корисний мобільним розробникам, які хочуть тренувати наявні ML-моделіна власних даних і використовувати їх у створюванні мобільних додатків.

Чому обчислювальні можливості мого комп’ютера можуть не підійти для тренування ML-моделі?

Якщо ви хочете навчити персептрон, щоб він виконував операцію XOR, можна навчити таку нейромережу навіть на старенькому мобільному.

Але деякі рішення для розпізнавання образів потребують значної обчислювальної потужності. Наприклад, для тренування YOLO (алгоритму розпізнавання об’єктів і їхнього розташування на фото) потрібні тижні (якщо не місяці) тренування на досить потужному CPU. На топових GPU час тренування може зменшитися з декількох днів до кількох годин. Можна, звісно, витратити декілька тисяч доларів на останню модель Nvidia Tesla GPU, але якщо ви не працюєте із цим активно, то, імовірно, таке придбання буде марним. Окрім того, треба зазначити, що інколи щоб пришвидшити обчислення, їх треба «розпаралелити» на декілька таких GPU. Тому досить часто доречно використовувати cloud-потужності.

Від чого залежить час тренування моделі?

Це залежить від багатьох параметрів: від розміру набору даних, на якому тренуватимете модель, від кількості ваг (weights, кількості каліброваних параметрів нейромережі), кількості ітерацій тощо.

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

Що таке epoch, step, iteration, loss, batch size, tensor shape, over-fitting?

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

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

Масив даних, на яких тренуватимемо нашу модель, поділяється на N-ну кількість партій (batches), і розмір кожної з них — це batch size. Далі, коли кожна із цих партій даних передається вперед і назад по обчислювальному графу (розраховуючи зворотне поширення помилки) через нейронну мережу, це і є одна epoch.

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

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

Кожна штучна нейронна мережа має input і output, тому щоб «згодувати» їй дані (та одержати вихідне значення), треба їх привести до відповідного формату, тобто до N-розмірного масиву. І форма (shape) — це кількість елементів у кожній з його розмірностей.

Наприклад, таку картинку, створену лише із 4 пікселів (зелений, чорний, синій, червоний), можна представити як N-розмірний масив

[   
   [ [0, 255, 0],   [0, 0, 0]   ], 
   [ [0, 0, 255],  [255, 0, 0] ]
 ]

Припустимо, ви намалювали червоними крапками знайомий ще зі школи графік функції y = x. Вийшло не надто рівно, і ви хочете побудувати ML-модель,щоб вона змогла домалювати продовження цього графіка.

Over-fitting — це коли ваша модель ідеально «прилягає» до даних, на яких вона тренується, у цьому прикладі — до всіх нерівностей, червоних крапок, які ви намалювали. Але далі намалювати продовження графіка правильно вона не може, тобто вже на тестових даних робить значні помилки.

Appropriate fitting — це коли ваша модель правильно виокремила закономірності даних, і в цьому прикладі може правильно домалювати графік, тобто добре працює на тестових даних.

Under-fitting — це коли ваша модель погано працює і на даних для тренування, і на даних для тестування.

Але іноді, у реальному житті, припустимо використовувати моделі, які можна назвати over-fitted, які ідеально працюють лише на деякому діапазоні даних (але за умови, що вони спрощують обчислення). Наприклад, формула додавання швидкостей (звичних людині в повсякденному житті) досить проста — просте додавання. Але якщо розглядати досить великий діапазон швидкостей, аж до порівнянних зі швидкістю світла, — вона вже має складніший вигляд. Тобто перша формула працює лише на одному виокремленому діапазоні даних, а друга — на ще ширшому. Але досить часто другою формулою можна знехтувати й заради спрощення обчислень використовувати першу.

Крок 1. Готуємо проект до тренування на Google Cloud

Для прикладу я вибрав проект open-source із розпізнавання об’єктів та їхніх координат на фото — YOLOv3, який використовує Keras.

Спочатку відредагуємо структуру нашого проекту:

trainer		 # Директорія яка містить train-модуль 
--- __init__.py
---  ….		# тут будуть файли нашого open source проекту
setup.py		# файл з dependencies

Вміст setup.py:
from setuptools import setup, find_packages

setup(name='some_project',
      version='1.0',
      packages=find_packages(),
      include_package_data=True,
      description='.......',
      author='…',
      license='Unlicense',
      install_requires=[
          'Keras==2.1.5',
          'tensorflow-gpu==1.6.0',
          'h5py==2.8.0',
          'numpy',
          'argparse',
          'Pillow',
          'matplotlib',
      ]) 

Для зберігання файлів нашого набору даних, який має обсяг декілька гігабайтів, використовуватимемо Google Cloud Storage. Створимо storage bucket за допомогою команди в консолі Google Cloud:

gsutil mb -p [PROJECT_NAME] -c [STORAGE_CLASS] -l [BUCKET_LOCATION] -b on gs://[BUCKET_NAME]/
Де PROJECT_NAME — назва нашого проекту в Google Cloud.

STORAGE_CLASSбувають Multi-Regional Storage, Regional Storage, Nearline Storage і Coldline Storage. Докладніше про storage class можна почитати тут.

BUCKET_LOCATION — розташування вашого storage bucket — може бути:

Для свого прикладу я використав такі параметри: storageclass — coldline, region — us-east1.

Далі треба завантажити файли набору даних. Я використав VOC dataset.

Для копіювання цих файлів до Cloud Storage у консолі Google Cloud використаємо команду:
gsutil -m cp -R [SOURCE_LOCAL_LOCATION]gs://[BUCKET_NAME]

З іншими командами gsutil можна ознайомитися тут.

Далі бажано всі операції File I/O робити через Bucket I/O, який чудово зреалізували в модулі tensorflow.python.lib.io.

from tensorflow.python.lib.io import file_io  # for better file I/O
import io
from PIL import Image
def gs_open(path, mode='r'):
   return file_io.FileIO(path, mode)
def gs_file_exists(path):
   return file_io.file_exists(path)
def gs_copy_file(src, dest):
   if not file_io.file_exists(src):
        raise Exception("Src file doesn't exist at %s" % src)
   file_io.copy(src, dest, overwrite=True)
def gs_open_image(path):
   file = gs_open(path, "rb")
   image_data = file.read()
   file.close()
   return Image.open(io.BytesIO(image_data))

Для цього окремого прикладу — тренування YOLO — нам потрібно ще створити train-file, який містить шляхи до картинок з набору даних, координати об’єктів на них та їхній тип (клас):

path/to/img1.jpg   x11,y11,x12,y12,some_class_A   x21,y21,x22,y22,some_class_B …
path/to/img2.jpg   x11,y11,x12,y12,some_class_B   …
…….

Де x11, y11, x12, y12 — координати «прямокутника» шуканого об’єкта на фото, some_class — клас об’єкта (число, усі класи можна подивитися у файлі classes.txt).

Для автоматизації цього процесу в репозиторії є скрипт voc_annotation.py.

python voc_annotation.py --voc_path gs://[YOUR_BUCKET_NAME]/VOCdevkit --voc_classes_path model_data/voc_classes.txt

Результат — створений файл 2012_train.txt.

Ми одержали таку структуру файлів на Cloud Storage:

Крок 2. Створення ML Cloud Job

Для створення Cloud Job у консолі Google Cloud запустимо команду:

gcloud ai-platform jobs submit training ${job_name} --job-dir ${job_dir} \
 --python-version 3.5   \
 --runtime-version 1.9  \
 --package-path ./trainer           `# модуль trainer`  \
 --module-name trainer.train   `# файл train.py`    \
  --region ${region}     \
 --scale-tier BASIC_GPU   `# single NVIDIA Tesla K80 GPU` \
  --  `# Окремо параметри для train.py` \
  --weights_stage "${job_dir}/weights_stage_exported_tiny.h5"   `# Наша stage pre-trained model, яка повинна створитися наприкінці` \
 --weights_final "${job_dir}/weights_final_exported_tiny.h5"     `# Наша final pre-trained model, яку маємо створити наприкінці` \
 --anchors_file "gs://${bucket_name}/tiny_yolo_anchors.txt" \
 --annotation_file "gs://${bucket_name}/2012_train_tiny.txt" \
 --classes_file "gs://${bucket_name}/voc_classes_tiny.txt"

Щоб кожного разу не писати команду з параметрами, я вивів її в окремий bash-скрипт.

Якщо зазирнете в логи, то побачите, що значення lossіз кожною epochдещо зменшується:

Найкраще значення loss — це близьке до нуля.

Після закінчення тренування знайдемо наші pre-trained моделі тут:

Повний код можна подивитися в цьому репозиторії.

Крок 3. Завантаження моделі на мобільному пристрої

Розглянемо декілька можливостей:

• Core ML (iOS/Mac);
• Metal Performance Shaders (iOS/Mac).

3.1 Core ML

Для завантаження через Core ML потрібно конвертувати нашу модель до відповідного формату.

Для Keras (*.h5):

#!/usr/bin/env python
importcoremltools
your_model = coremltools.converters.keras.convert('your_model.h5', input_names=['image'], output_names=['output'], image_input_names='image')
your_model.save('your_model_name.mlmodel')

Для TensorFlow (*.pb, *.proto):

import tfcoreml as tf_converter
tf_converter.convert(tf_model_path='my_model.pb',
                    mlmodel_path='my_model.mlmodel',
                    input_name_shape_dict=input_tensor_shapes,
                    output_feature_names=output_tensor_names)

Де input_tensor_shapes — це форма вхідного N-розмірного масиву, у разі YOLO v3 (tiny): [416, 416, 3], формат запису — [height, width, rgb values].

А output_tensor_names — це назви значень output, у прикладі YOLO це output1, output2, output3, де output1 shape = [13, 13], output2 shape = [26, 26], output3 shape = [52, 52].

Під час додавання моделі Core ML у проект Xcode автогенерується клас Yolov3. Проглянувши його реалізацію, ми бачимо, як і звідки завантажується наша модель.

Як ми бачимо, вона завантажується з директорії Yolov3.mlmodelc (з app bundle), де зберігаються файли, зокрема model.espresso.net (структура моделі), model.espresso.weights (ваги).

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

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

Для того щоб наша модель опрацювала картинку, треба викликати цей метод з параметром CVPixelBuffer:

Одержати CVPixelBuffer з відеопотоку камери можна за допомогою цього методу в делегаті AVCaptureVideoDataOutputSampleBufferDelegate:

Треба також зазначити, що якщо ви берете CVPixelBufferз AVCaptureSession (AVFoundation), то він має формат кольорової моделі RGB.

Але якщо ви берете CVPixelBuffer з [ARFrame.capturedImage] (ARKit), то він матиме вже формат YUV.

Ось що може «бачити» ваша нейромережа, коли замість очікуваного RGBви завантажили в її YUV:

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

У YOLO input shape дорівнює [416, 416, 3], тому висота й ширина зображення має бути 416.

Докладніший приклад використання Core ML окремо для YOLOv3 можна знайти в цьому репозиторії.

Core ML може працювати як лише на CPU, так і на GPU. GPU-реалізацію створили на основі Metal Performance Shaders.

3.2 Metal Performance Shaders

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

Якщо ви розглянете стек-трейс майбутнього виконання вашої моделі в Core ML, можете побачити там класи внутрішнього C++ ML-фреймворка Apple з назвою Espresso й Metal Command Buffer.

Далі поясню, як можна працювати з Metal Command Buffer.

Обчислювальний граф нашої моделі створюємо послідовно за допомогою обчислювальних нод.

SomeNode1, SomeNode2, … SomeNodeN — класи нод. Є input- і output-ноди. Серед наявних класів нод присутні MPSCNNPoolingMaxNode (max pooling), MPSCNNConvolutionNode (convolution), MPSCNNNeuronReLU (ReLU activation) тощо.

Граф нод у нашій ML-моделіможна подивитися за допомогою python через keras.utils.plot_model (для Keras).

Наприклад, граф моделі YOLO, яку ми розглядаємо — такий.

device (MTL Device) — інтерфейс Metal для GPU, який можна використовувати для графіки й паралельних обчислень.

Щоб працювати з вхідними даними в GPU-CPU shared memory space, їх треба підготувати для цього за допомогою конвертації в MTLTextureй далі через створення MPSImage.

Після виклику [MPSNNGraph.executeAsync]весь наш граф кодується в MTL Command Bufferдля виконання вже на GPU.

У [MPSNNGraph.executeAsync] ми можемо одержати outputImageу вигляді MPSImage, з якої можна вже скопіювати масив вихідних значень.

Докладніший приклад використання Metal Performance Shaders окремо для YOLO можна знайти в цьому репозиторії.

Якщо ви не хочете, щоб вашу ML-модельвикористовував хтось сторонній і міг просто інтегрувати в чужий застосунок, краще застосовувати безпосередньо Metal Performance Shaders, ніж Core ML. Але щоб розглянути всі методи захисту, краще присвятити цьому окрему статтю.

Робоче місце — «свята святих» будь-якого ІТ-спеціаліста. Від того, наскільки комфортно працювати, залежить продуктивність, стан здоров’я, задоволеність робочим процесом. Редакція DOU зібрала підбірку фото та коментарів про робочі столи, гаджети, книги, що допомагають працювати.

Якщо хочете показати своє робоче місце — присилайте фото, коментарі та DOU-профіль на maria@dou.ua.

Vlad Galagan, Software Engineer в Codica:

Олесь, розробник:

Maksym Romanchuk, Lead Generation consultant в LeadGen:

Андрій Мартинюк, директор в SINCH.PRO:

Егор Сопов, Business Analyst в Dev-Pro:

Иван Пономаренко, Web Researcher в Dev-Pro:

Олександр Пархоменко, Deployment Engineer в Grid Dynamics:

Володимир Рожков, Software architect:

Іван Данилюк, CTO в Sportity:

Костянтин Білик, Senior iOS Developer в Svitla Systems:

Yuriy Kostyuk, Senior Golang Engineer:

Юрій Бондаренко, Python Full-Stack Developer в Vilmate:

Нестор Сокіл, Software Engineer в Altigee:

Віктор Лукін, Delphi software developer:

Александр Буратинский, Scrum Master в Competera:

Федор Наврузов, Data Scientist в Competera:

Аби не пропустити участь у подібних підбірках — підписуйтеся на канал Редакції DOU.

В рубрике DOU Labsмы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

Всем привет! Я Сергей Хухра, CTO AR-студии Live Animations. Мы создаем контент и маркетинговые решения, используя технологию дополненной реальности. Я хочу рассказать, как наша команда работала над одним из самых необычных проектов за наши 5 лет на этом рынке — Alif and Sofia. Мы создали AR-контент для детских книг, которые рассказывают мусульманским детям, как правильно совершать обряд молитвы.

Идея

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

Тем более неожиданно для нас было осенью 2018 года получить из нашего офиса в Нью-Йорке новость о том, что от малазийской компании Big Bad Wolf поступил заказ на создание AR-контента и мобильного приложения для детских книг про мальчика Алифа и девочку Софию, которые учат детей, как правильно совершать исламский обряд молитвы. Хотя к тому времени мы и создали AR-контент уже для более чем 15 книг, такая тематика была для нас совершенно новой.

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

Главной целью проекта с учетом его тематики было сделать обучение исламским традициям и обрядам детей, живущих в странах Юго-Восточной Азии, более интересным и вовлекающим с помощью технологии AR. Заказчик хотел сделать книги не просто очередными детскими рассказами об обычаях ислама, а интерактивными медиаисториями с музыкой, песнями и танцами. Между прочим, до начала работы над этим проектом мы не знали, что в Индонезии живет наибольшее число мусульман в сравнении с другими странами.

Это был первый проект подобного рода в мусульманском мире, а потому начинать работу было вдвойне интересно: мы хотели посмотреть, как AR «ляжет» на столь консервативную тематику.

Как работает проект

Проект включает в себя набор AR-анимаций (по 12 для каждой книги) и мобильные приложения под iOSи Androidдля воспроизведения этих анимаций. Имея успешный опыт разработки мобильных приложений для детских книг, мы создали приложение по уже отработанному шаблону, добавив только уникальный дизайн в новой стилистике. При этом набор функций приложения дает пользователю возможность использовать AR-контент по максимуму. Приложение может:

• распознавать маркеры в виде рисунков на страницах для запуска соответствующих AR-анимаций;
• воспроизводить AR-контент в 3D с привязкой к книжным страницам (или просто закрепив сцену на экране телефона);
• делать снимки и записи экрана, чтобы делиться ими в соцсетях.

Помимо этого, приложение дает возможность взаимодействовать с AR-контентом.

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

Весь AR-контент хранится на сервере и предоставляется по запросу программы, поэтому пользователю не нужно загружать объемное приложение с маркетплейса. Мы также упростили интерфейс мобильного приложения и сделали его максимально доступным для целевой аудитории. Оно открывает камеру по нажатию одной кнопки на главном экране и сразу готово к распознаванию страниц и воспроизведению AR-контента.

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

Реализация

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

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

Что касается девелоперов, то один из них занимался редизайном и адаптацией приложения конкретно под этот проект и сборкой UX/UI, один был ответственен за размещение в сторах, двое работали над спецэффектами, еще один — над компасом в приложении.

Кстати, компас — это вообще уникальная штука, над которой мы изрядно попотели. Известно, что все мусульмане во время молитвы должны смотреть в сторону Каабы, расположенной в Мекке. Изначально мы хотели внедрить компас в трехмерное пространство, прямо в AR-контент, который воспроизводится при наведении на иллюстрацию.

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

Разработка началась в ноябре 2018 года, и, так как все специалисты, задействованные в проекте, состоят у нас в штате, за время реализации проекта состав команды не менялся. Озвучка персонажей — это единственное, что мы отдали на аутсорс. Так как мы уже давно набили руку в проектах с AR для книг, рабочий процесс состоял из привычных нам стадий.

Техническая реализация

С технической точки зрения мы используем движок Unity, с которым работаем уже довольно давно. Из-за того, что наше приложение должно без проблем функционировать на множестве девайсов всех ценовых категорий, Unity позволяет максимально оптимизировать AR-контент, который наши аниматоры и моделлеры создают с помощью Maya и Maya 3D. А чтобы вывести весь этот контент, мы используем Vuforia в качестве надстройки.

Конечно же, помимо разработки и оптимизации контента, необходимо подготовить работающее мобильное приложение, которое будет все это воспроизводить, создавая привлекательный user experience. Над последним мы, кстати, заморачиваемся особенно сильно, ведь без него невозможно получить высокий рейтинг в сторах, а для нас это очень важный показатель качества. Именно поэтому приложение Alif and Sofia было написано с нуля на C#+Mono с использованием почти 500 оригинальных скриптов. В итоге программисты потратили больше трех недель на то, чтобы создать стилизованное приложение, и еще неделю, чтобы добавить все анимации, спецэффекты и т. д.

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

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

С точки зрения 3D-моделинга полная паранджа является очень сложным техническим элементом, когда персонаж не просто стоит, а постоянно меняет позы: все изгибы и складки, то, как они ложатся на тело, должны быть продуманы до мелочей, чтобы избежать неестественности финальной картинки. Неудивительно, что на создание Софии команда 3D-моделлеров проекта потратила в два раза больше времени, чем на Алифа. И хотя 3D-модели обоих персонажей были предоставлены заказчиком, чтобы избежать компромиссов в качестве, пришлось заново создавать модели специально под этот проект.

Правки, которые поступали от заказчика, были обусловлены не плохим качеством работы, а культурными особенностями: исправлять надо было анимации, то, как должны двигаться персонажи и какие действия они должны совершать. Столкнувшись с новой культурой, наши ребята не всегда могли с точностью воспроизвести все характерные движения, требуемые исламскими обрядами. Например, при троекратном омовении водой необходимо было сделать так, чтобы Алиф каждый раз набирал в ладошки новую воду, а не использовал ту, что осталась после предыдущего омовения. Этого мы не знали, и поэтому пришлось переделывать. Отполированный с учетом всех правок проект Alif and Sofia был передан заказчику в апреле 2019-го,после пяти месяцев работы над ним.

Результаты и планы

Alif and Sofia стал одним из самых успешных среди наших проектов. В день презентации книжек на самой большой книжной выставке Азии Big Bad Wolf количество запросов на наши серверы (а AR-контент хранится именно там) превысило 150 тысяч в час, тогда как рассчитаны они были на 300 тысяч запросов в день — серверы не выдержали и легли, но мы быстро устранили эту неполадку. Такой интерес еще больше убедил нас в том, что технологии могут заработать даже в такой консервативной сфере, как мусульманская культура.

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

Привет, меня зовут Владимир Поло. Я основатель AcademyOcean — SaaS-продукта для онбординга и обучения сотрудиков. В течение последних нескольких лет я собираю коллекцию велкам-паков компаний по всему миру. В этой статье — подборка из украинских IТ-компаний.

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

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

Итак, перед вами подборка велкам-паков украинских IT-компаний.

Competera

Украинская продуктовая SaaS-компания, создающая платформу ценообразования нового поколения. Она помогает крупным ритейлерам конкурировать с такими гигантами отрасли как Amazon и Walmart. Компания основана в 2014 году, сейчас в команде работает более 90 человек.

Когда новичок приходит в компанию, его фотография и описание его «суперсилы» транслируются на экране в общей зоне офиса, а всем членам команды приходит рассылка с интересными фактами о новом сотруднике.

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

Reply

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

В велкам-пак входит почти полный набор одежды: футболка, худи, носки. А также ручка, чашка, значки, стикеры, павербанк и экосумка, чтобы всё это как-то унести :)

Youscan

Продуктовая SaaS-компания, разрабатывающая решения для мониторинга и аналитики социальных медиа. Компания основана в 2009 году, и сейчас команда состоит из 90 человек в двух офисах и удаленно.

В Youscan есть интересная нетворкинговая активность — «ланч-рулетка». Каждую неделю две пары коллег из офиса, случайным образом выбранные с помощью сервиса random.org, могут пойти на ланч за счет компании. Это помогает им лучше узнать друг друга и познакомиться с теми, с кем они не сталкиваются в работе.

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

На фото юбилейный велкам-пак: футболки и пряники в стиле пэкмэн, выпущенные к 10-летиюкомпании.

Netpeak

Одно из крупнейших в Восточной Европе агентств интернет-маркетинга. Входит в группу компаний Netpeak Group. Компания основана в 2006 году. Ключевая экспертиза — SEO и PPC. В агентстве работает более 200 человек, а в Netpeak Group — более 500 человек.

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

Велкам-пак включает в себя сумку, футболку, костер, блокнот, ручку и стикеры.

HYS Enterprise

Голландская IT-компания, основанная в 2007 году. В том же году появился центр разработки в Одессе. На сегодняшний день в одесском офисе работает 160+ сотрудников. Компания предоставляет услуги IT-консалтинга, веб-разработки, разработки мобильных приложений и программного обеспечения.

Велкам-пак в HYS включает в себя: корпоративную футболку, чашку, блокнот, ручку, дисконтные карточки компании в заведения Одессы (договоренности с ресторанными сетями, квест-румами, барбершопами и т.д.).

MacPaw

Украинская продуктовая компания, создающая программы, которые упрощают вашу жизнь с Mac. Наиболее известный продукт — приложение CleanMyMac. Компания основана в 2008 году. Сейчас в команде почти 200 человек.

В первый рабочий день специалисты получают стильную белую коробку.

В коробке ждут футболка, блокнот, стикеры и значок с логотипом компании.

Intellias

Крупная украинская IT-компания, основанная в 2002 году во Львове. По состоянию на июль 2019 года здесь работает более 1500 специалистов. В прошлом году компания получила звание «Велоработодатель года», которую присваивает Ассоциация велосипедистов Киева.

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

Provectus

Компания специализируется на сервисах R&D, консалтинге и аутсорсинге. Основана в 2010 году в Одессе. На текущий момент в команде более 400 человек.

Сразу после знакомства с командой новички получают Welcome Box со всем необходимым в первый день работы.

В плотной картонной коробке (которую впоследствии можно использовать для хранения мелочей на столе) есть чашка, блокнот и ручка для записи важных мыслей, шнурочек с ключом от всех дверей в компании и конверт с приветствием от Head of HR и нужными онлайн-доступами. Все предметы в Welcome Box брендированы логотипом Provectus.

GlobalLogic

Международная компания и один из лидеров в сфере разработки цифровых продуктов. В Украине представлена офисами в четёрех городах. Компания основана в 2000 году в США. Сейчас в ней работает более 14 000 человек. Из них в Украине — 4 300 инженеров.

В велкам-пак GlobalLogic входит: футболка, чашка, блокнот, ручка, лента для пропуска и обложка для паспорта.

Ubisoft

Один из мировых лидеров в игровой индустрии. В Украине представлена двумя студиями: в Киеве (открыта в 2008 году) и Одессе (в 2018 году). Компания была основана в 1986 году во Франции. Сейчас в ней работают более 16 тысяч человек. Из них в Украине работают 680 сотрудников.

Примеры продуктов, созданных компанией, — Assassin’s Creed и Far Cry. Непосредственное участие в разработке и тестировании этих игр принимал киевский офис.

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

EPAM

Одна из ведущих компаний-поставщиков услуг разработки ПО. Компания основана в 1993 году. Украинский офис основан в 2005 году. Регулярно входит в ТОП-25 публичных IT-компаний с наибольшей скоростью роста по версии Forbes.

Суммарно во всех офисах EPAM работают более 30 тысяч человек, из них в Украине — более 7 500 человек.

В велкам-пак входит: чашка, на которой изображены ценности компании, ручка, дополнительный набор канцелярии, а также блокнот-книга, в котором можно не только делать заметки, но ещё и познакомиться с ценностями компании, выполнить пункты из базового to-do list, а также найти ответы на часто задаваемые новичками вопросы.

После прохождения испытательного срока сотрудники получают футболку с логотипом.

Beetroot

Шведско-украинская аутсорс-компания, которая специализируется на создании профессиональных команд разработчиков и дизайнеров из Украины. Компания основана в 2012 году. Всего в ней работает 350 человек, из которых 345 — в Украине.

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

EVO

Украинская продуктовая IT-компания. Ежедневно на маркетплейсах EVO люди совершают более 2 млн заказов. В портфель компании входят Prom.ua, Bigl.ua, Kabanchik.ua, Shafa.ua, Crafta.ua и другие сервисы.

Компания начала своё существование именно с Prom.ua, который запустился в 2008 году. На текущий момент в EVO работают 1009 специалистов, из которых 951 — в Украине.

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

SoftServe

Входит в тройку крупнейших IТ-компаний Украины. Является одной из ведущих компаний-разработчиков программного обеспечения в Центральной и Восточной Европе.

Компания основана в 1993 году. Суммарно в 42 офисах работает более 8 300 человек. Из них в главном украинском офисе — более 7 400 человек.

В велкам-пак SoftServe входит сумка, футболка, чашка и флешка.

По сравнению с Западом, традиция велкам-паков только зарождается в Украине. Вы также можете посмотреть подборку приветственных наборов иностранных компаний.

Например, как выглядит велкам-пак в компании Dropbox:

И в компании SEGA:

Нужно признать, что многие украинские компании уже сделали серьезный шаг в этом направлении. Многие велкам-паки в этой подборке гораздо лучше, чем средний набор в западной компании. Так держать!

А как выглядит велкам-пак в вашей компании?

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

AWS має потужні служби, які, втім, потрібно відповідним чином поєднувати, щоб досягти потрібного результату. По суті, вони є модулями, які мають певну функціональність, але мають бути якось об’єднані в єдине ціле, щоб ними було дійсно зручно користуватися. На щастя, платформа підтримує скрипти, і вже з’являється додатковий софт і шари абстракцій, що спрощують для програмістів самостійне керування налаштуваннями, не вдаючись до посередництва додаткових апаратних засобів чи людей. CloudFormation (CF) дає змогу описувати інфраструктуру за допомогою JSON або YAML.

Завдяки шаблонам CF на зразок serverless і трансформаціям CodeStar, вам знадобиться значно менше коду, щоб описати безсерверну конфігурацію у CloudFormation. А такі інструменти як Serverlessдодають іще один рівень автоматизації, полегшуючи роботу розробникам. Amazon тут не пасе задніх, пропонуючи інструментарій навіть вищого рівня, який має назву Amplify (про нього розповім у наступних дописах) і дає змогу іще більше автоматизувати роботу із залученням апаратних і програмних засобів.

Інструментарій Serverless

Погравшись трохи з AWS SAM і трансформацією serverless для CF, я швидко відчув певні недоліки відмови від складнішої системи для автоматизації:

1. Перегляд логів. Переглядати логи CloudWatch в консолі AWS — не найліпший спосіб стежити в реальному часі (та й узагалі) за тим, що ваш додаток видає на виході.
2. Було незрозуміло, як зберегти деякі складники архітектури безсерверного додатку для повторного використання в інших проектах. Я поцікавився у розсилці Flaskі на його IRC-каналі, як реалізувати це в розширенні — і жодної путньої відповіді не отримав.
3. Визначення речей на зразок шлюзів API, сховищ S3 для коду і доменів засобами CF — марудна праця. Її можна автоматизувати більшою мірою.
4. Було б чудово отримувати одразу якусь інформацію щодо розгорнутого додатку, як-от його URL-адресу.
5. Розгортання, включно з розгортаннями до різних стадій.
6. Сповіщення про закінчення розгортання, особливо в разі використання CodeStar.
7. Виклик функцій для тестування і засобами автоматизації.
8. Керування залежностями.

І деякі інші аспекти, наприклад відстежування коректності профілю налаштування AWS й регіону.

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

Є такий інструментарій Serverless — не сказати, що назва додає ясності в обговорення недавньої тенденції використовувати безсерверні архітектури додатків, де вже маємо, наприклад, прикметник serverless, безсерверну модель додатку (Serverless Application Model (SAM)) і CF-трансформацією serverless для AWS.

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

Не буду описувати тут як починати роботу з Serverless, про це можна почитати його сайті. Тут нічого складного немає, особливо якщо у вас вже налаштовані реквізити AWS. Роздивімося краще переваги, які він надає:

Логування

Тут усе просто. Продивитися всі чи кілька останніх записів у файлах логів можна так:

sls logs -f myfunction -t

Повторне використання коду

# Створити Flask-додаток на основі шаблону
sls install --url https://github.com/revmischa/serverless-flask --name myapp

Дехто ще пішов шляхом Create-React-App і створив шаблони Serverless-проектів, до яких можна отримати доступ за допомогою команди «sls install». З одного боку, це значно спрощує створення й розповсюдження готових рішень і залишає можливість для розгалуження упродовж розвитку шаблонів. Але з іншого — додавати нові поліпшення до проектів на основі старих шаблонів стає значно складніше. Оскільки йдеться про Flask і Python, навряд самих лише шаблонів вистачить, щоб розв’язати цю проблему. Потрібен іще якийсь модуль для Python, який буде розвиватися паралельно. Було б чудово, якщо б це було щось аналогічне до пакета react-scripts, який співіснує з Create-React-App.

Налаштування і CloudFormation

Тепер оголошувати ресурси й функції можна у файлі налаштувань serverless.yml. Туди ж можна додати ще купу корисного.

Майже весь шаблонний код, який потрібен CF для налаштування всіх аспектів безсерверного додатку (сховища S3 для коду, IAM-дозволів для виклику і CloudWatch, API Gateway тощо) від вас схований — ним більше не треба перейматися. Від вас потрібні лише мінімальна конфігурація та CF, щоб описати те, що потрібно саме для вашого випадку. За шкалою зручності від sendmail.conf до .emacs, serverless.yml є доволі близьким до останнього.

Інформація

Тут усе просто. Де я там запаркував свій домен?

 $ sls info
Service Information
service: myapp
stage: dev
region: eu-central-1
stack: myapp-dev
api keys:
  None
endpoints:
  ANY - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev
  ANY - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev/{proxy+}
  GET - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev/openapi
functions:
  app: myapp-dev-app
  openapi: myapp-dev-openapi
Serverless Domain Manager Summary
Domain Name
  myappmyapp.net
Distribution Domain Name
  dcwyw3gslhqw1.cloudfront.net

Розгортання

Тут теж все просто, навіть занадто просто!

$ sls deploy
$ sls deploy -s prod  # specify stage

Ця команда збирає залежності, створює пакет служби, завантажує його у сховище S3 і запускає оновлення стеку CloudFormation.

Бачите розділ «Serverless Domain Manager Summary» (Короткі відомості для диспетчера доменів для безсерверних додатків)? Це налаштування плагіну serverless-domain-manager. Якщо вам потрібно розгорнути кінцеві точки під доменним ім’ям у зоні Route53 (сподіваюся, ви вже маєте ACM-сертифікат для регіону us-west-1), Serverless може автоматично прикріпити домен або піддомен, створити дистрибутив CloudFront і виконати зіставлення домену з API Gateway.

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

Очікування / Сповіщення

Після виконання згаданої вище команди розгортання ви отримаєте сповіщення. Потім одразу можна переходити до тестування. Щоб прискорити процес, можна розгорнути лише певну функцію, або скористатися опцією пришвидшення передачі даних (Transfer Acceleration) сховища S3, щоб пришвидшити завантаження ваших кунштиків. І ніякого марнування часу, розгортаючи непотрібні вам речі або роздивляючись веб-інтерфейс CodeStar.

Виклик функцій

Як і в AWS SAM, у Serverless немає нічого складного. Якщо ви пишете веб-додаток з використанням плагіну serverless-wsgi, його можна також обслуговувати локально.
Керування залежностями

(Ця частина стосується Python)

Як керувати залежностями вашої «лямбди» з кодом на Python? Просто записати їх у файл requirements.txt. Очевидно, еге ж? У всякому разі, із Serverless це більш-менш так. Також не забувайте, що всі залежності мають міститися у zip-файлі вашої «лямбди». Треба скомпілювати залежності в бінарники, а поряд немає 64-бітної linux-машини? Просто додайте рядок «dockerizePip: true»до налаштувань плагіну serverless-python-requirements у файлі serverless.yml.

Зверніть увагу: якщо вам треба викликати функцію локально або запустити WSGI-сервер, доведеться створити локальне віртуальне оточення. Якось мені трапився дивний шаблон — він не мав стосунку до Serverless, — в якому керування локальними залежностями й залежностями «лямбди» було реалізовано за допомогою pipenv. Не найкращий варіант, не раджу так робити.

Розширення функціональності Serverless

Я користуюся AWS Lambda здебільшого коли пишу невеличкі Web API-служби на Python з використанням мікрофреймворка Flask. Serverless надає мені потрібні інструменти, але хочу мати вже готові підвалини для свого додатку, щоб додатково спростити створення нових проектів.

Отже, я зробив форк шаблону serverless-flask і дещо його переробив. Зробив так, щоб він більше не питав, чи у вас Python 2 або 3 (чому б краще не питати хочу я UTF-8 або EBCDIC?) і усталено вимкнув докерування pip.

Створюючи API-сервер на основі Flask, можна полегшити собі життя, додавши marshmallowдля виконання серіалізації та десеріалізації запитів, flask-apispecдля інтеграції marshmallow з OpenAPI (Swagger) і Flask, а також CORS. У моїй версії шаблону це все потрібно, щоб спростити наскільки можливо створення документованого REST API засобами Python і Serverless найменшими зусиллями та з мінімумом написання коду. У якості бонусу він генерує клієнтські бібліотеки для вашого API на основі визначення OpenAPI будь-якою зручною для вас мовою програмування.

Інструкції з використання шаблону й швидкого початку роботи з ним шукайте тут.

Serverless? Чому б і ні

Цей допис — друга віха в нашій подорожі. Поліпшення процесу написання додатків та служб — це тривалий процес. Минулого разу ми розглядали служби AWS окремо, а у цьому дописі зосередитися на допоміжному інструментарії. Логічним наступним кроком могли б стати AWS Amplify та GraphQL. А може й ні. Стежте за оновленнями.

Читати першу частину статті

Привет! Меня зовут Ярослав Трохименко, я — Senior Java Developer. В этой статье хочу рассказать о жизне и работе в Польше, а точнее — Люблине.

Люблин насыщен вдохновением

История переезда

В Люблин я переезжал из Киева. Примерно 7 лет назад, будучи еще студентом, я устроился в DataArt Java-практикантом. Когда я окончил университет, компания как раз открыла центр разработки в Люблине и предложила желающим попытать счастья в Польше. Я уже был Middle Java Developer, в Украине меня ничего особенно не держало, и я подумал: почему бы и нет? Спросил мнение менеджера, он сказал, что никаких проблем для проекта в этом не видит. Мне помогли записаться на собеседование для оформления визы, через две недели подошла моя очередь. Интервью заняло день, еще полторы недели я ждал подтверждения. В общем, через месяц после того, как я впервые задумался о возможности переезда, я взял билет, собрал рюкзак и уехал.

Все произошло достаточно спонтанно, но изначально я не планировал задерживаться в Люблине надолго. До переезда я в этом городе не был, хотя уже тогда много путешествовал. Я посмотрел в интернете, как выглядит Люблин, оценил виды улиц на Google Maps — красиво, мне подходит. То обстоятельство, что я не особо разбирался заранее, наверное, оказалось даже к лучшему, в итоге было больше приятных сюрпризов. В общем, я втянулся, уже почти 5 лет тут. И мне все нравится.

В Люблине проходит много соревнований, особенно по бегу на длинные дистанции. Автор на награждении после одного из них. Фото из архива DataArt

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

Сейчас я Senior Java Developer / Team Lead в команде по разработке высоконагруженного мобильного сервиса, а это часть одного из самых больших и, по-моему, самых интересных проектов компании.

Город и природа

Нужно понимать, что Люблин — небольшой город, раз в восемь меньше Киева и более чем вдвое меньше Львова. Но именно Львов он в целом и напоминает. В центре находится небольшой, но очень красивый Старый город, где сохранились дома еще XVI века — здесь их называют «каменицами». Это туристическая часть Люблина, за ней внимательно следят, здания реставрируют. Здесь, как правило, все и гуляют, пьют пиво, устраивают посиделки.

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

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

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

Jean & Nathalie, flickr.com«>

В последние 5-6лет в Люблине появилось заметное количество IT-компаний, и примерно раз в 3-4месяца открывается новое представительство. Мне кажется, власти специально помогают нашему сектору: видят в нем альтернативу перезапуску промышленности. Поэтому почти любой прохожий не студенческого и не пенсионного возраста, скорее всего, окажется айтишником. А в случае, если кто-то решает сменить работу, особых проблем с поиском нового места возникнуть не должно.

Велосипеды, самокаты, автобусы

Основным недостатком Киева для меня была необходимость тратить на дорогу в офис чуть ли не два часа. В транспорте я проводил больше трех часов ежедневно! Если в выходной я собирался погулять с друзьями в центре, это тоже занимало много времени, и в конечном счете логистика становилась серьезной проблемой. Здесь масштаб города и транспортная инфраструктура таковы, что почти в любую точку можно добраться за 15 минут. Это если есть пробки.

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

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

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

До Варшавы отсюда всего 150 километров, а автобусное сообщение отлично развито во всей Польше. Куда угодно можно доехать с большим комфортом, правда, если речь идет о дальних путешествиях, это займет немало времени: до Праги, скажем, придется ехать часов десять. Именно поэтому мне кажется, что покупка автомобиля здесь — просто отличная идея, тем более что это не так дорого, как в Украине. Дороги в Польше хорошие, а водят хоть и быстро, но довольно аккуратно.

Спорт и развлечения

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

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

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

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

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

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

Рождественские гуляния в старом Люблине

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

Язык и общение

IT-сообщество в Люблине живое: регулярно проходят встречи технологических комьюнити — по Java, Python, другим языкам программирования. Свои IT Talks проводят, например, DataArt и Google. Недавно появились регулярные встречи специально для женщин. В общем, всем есть где пообщаться несколько раз в месяц, поделиться проблемами или рассказать о собственных решениях, найти коллег, с которыми можно потом поддерживать отношения.

У нас в DataArt основной язык общения — английский. Но так как половину моих коллег в Люблине составляют украинцы и русские, на этих языках мы тоже общаемся довольно часто — наверное, на них приходится процентов десять рабочих переговоров. Разговоры на кухне примерно наполовину ведутся на польском. Я на английском на бытовые темы уже не общаюсь, за пределами офиса практически полностью справляюсь благодаря знанию польского.

Терраса офиса DataArt в Люблине

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

Люди старше 50 здесь показались мне закрытыми. Кажется, многие соседи старшего поколения ни с кем не здороваются, и я вижу в этом минус. Народ, который моложе, гораздо общительнее, с кем-то из соседей мы постоянно болтаем, хотя даже толком не знакомы.

Безопасность и отношение к приезжим

Приезжих тут очень много, но преобладают среди них студенты. Да и вообще, разница между поляками и украинцами заметна только на каких-то больших праздниках и только по тем, кто крепко выпил. Негативные высказывания в адрес тех, кто «понаехал», мне слышать приходилось, хоть и редко. Но такого можно наслушаться почти в любом городе Украины. Среди политиков есть популисты, выступающие против иммиграции, но все, кто смотрит на ситуацию здраво, понимают, что Польше без притока людей со стороны не справиться. Слишком многие поляки уехали в Англию и Германию, поэтому для людей, которые приезжают сюда надолго, сделано довольно много. Допустим, все, что связано с легализацией и вообще документооборотом, стараются максимально упростить. Дело даже не в том, что и речи не идет о взятках, — никто не треплет вам нервы. Почти любой вопрос можно решить за 15-20 минут,даже не зная польского.

В бытовых ситуациях примерно 80% незнакомых людей вообще реагируют на то, что вы не поляк, абсолютно положительно. Правда, шанс столкнуться, скажем, с группой подвыпивших футбольных фанатов существует. Я, впрочем, ни разу не слышал, чтобы кого-то избили или хотя бы ударили, но обозвать или просто обозначить недовольство вашим присутствием могут. Хотя и тут надо сказать, что за пять лет я с чем-то подобным сталкивался всего дважды. Разумеется, весь негатив исходит исключительно от людей с низкой культурой.

Пьют здесь, кстати, в основном пиво. И выпить могут удивительно много, хоть 5 литров, особенно девушки. Зато сильно пьяных или напившихся до беспамятства людей здесь я видел значительно меньше, чем в Украине. Все скорее крутится вокруг прогулки по центру с заходами в бары. Правда, есть период в конце учебного года, который называется Ювеналия — месяц гулянок. Это официальное торжество, когда каждый из четырех основных университетов устраивает свой недельный музыкальный фестиваль. Вот здесь студенты могут погулять так, что приходится быть внимательным. Не потому, что они становятся агрессивными, а потому, что начинают выходить на проезжую часть. Я сам такое веселье не люблю, но вообще, всем в городе, по-моему, нравится, тем более что атмосфера очень дружелюбная. Ну а мне на это время остаются парки и городские окрестности.

В плане общей безопасности тут просто хорошо: я никогда не буду волноваться, что моя девушка идет домой одна после 11 вечера. Мне не бывает страшно за нее. В Люблине есть несколько районов, где вроде бы не советуют гулять по ночам, но я вообще не слышал, чтобы на кого-то напали и, например, ограбили. Напряжение по сравнению с тем же Киевом просто нулевое. И это один из серьезных плюсов.

Да, наверное, если вы на ночь оставите непристегнутым велосипед, ему кто-то приделает ноги (а где будет иначе?). Но я не могу представить, что кто-то ходит по Люблину с большими кусачками, чтобы перекусывать велосипедные замки.

Цены и еда

Цены в целом сопоставимы с киевскими. Аренда квартиры либо обойдется в ту же сумму, либо будет чуть-чуть дороже. Заметно дороже — в полтора, в два, а то и в три раза — будет только покупка квартиры. Если говорить о продуктах, то что-то стоит немного больше, что-то — немного меньше, а в целом расходы примерно те же. Мясо и овощи, скорее всего, обойдутся чуть дешевле. За качеством следят очень внимательно: любая просрочка вызывает громкий скандал, который потом долго обсуждается. Молочные продукты замечательные, а европейский импорт стоит очень дешево: из Италии везут сыры, из Норвегии — рыбу и т. д.

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

Но кое-чего мне все же не хватает. Здесь не купить украинских йогуртов с Карпат, совершенно нет сушеной рыбы или снеков типа сушеных кальмаров. Выбор сладкого заметно более скудный, чем в Украине. Когда к нам с девушкой приезжает кто-то из близких, часто просим привезти каких-нибудь вафель.

Еще о спорте

У нас есть озеро, почти на окраине Люблина, 6-7километров от центра и 11 километров по периметру. На подъезде к нему постоянно бегает целая толпа. В Люблине практически каждый месяц происходит какой-нибудь массовый забег на 5, 10 километров или более длинную дистанцию. Люблинские марафоны — события довольно известные, ну и, как водится, здесь живет один из сильнейших польских бегунов, лучший в триатлоне, дуатлоне и марафонском беге.

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

Мультиспортивная карта, которую я упоминал, позволяет сегодня пойти в бассейн, завтра — в тренажерный зал, потом — на скалодром. Захотел попробовать что-то новое — пошел на теннис или сквош — знакомиться со спортом для богатых. Если брать абсолютные цены, это было бы на 30–50%дороже, чем в Украине. Однако такая карта делает цены из прайс-листов нерелевантными.

В качестве заключения

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

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

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

Дело в том, что однозначного ответа не существует. Роль Product Manager в компании сильно зависит от стадии развития продукта, с которым он работает. Задачи продакта в стартапе сильно отличаются от того, с чем придется работать в проекте, который недавно вышел на рынок или который работает уже не первый год.

Если в стартапе все нужно делать максимально быстро, пусть даже «из добра и палок», лишь бы работало, то в период роста продукта от менеджера ожидают качества, достижения KPI и customer success. Так что буквально за два года на проекте Product Manager может сменить 3 разные роли, и у каждой есть свои плюсы и минусы. Важно понимать, что все проекты уникальны, и нельзя четко сказать, на каком количестве клиентов, размере команды и величине прибыли для Product Manager заканчивается одна стадия роста и начинается другая. Но лучше давайте обо всем по порядку.

Product Manager в стартапе на этапе поиска Product Market Fit

В стартапе весело, такой себе хакатон каждый день.

Первая и самая важная задача Product Manager в стартапе — создать и продать продукт. Это основная головная боль, которая не позволяет ему спать ночами. Он все время мучается вопросом «А не фигню ли мы делаем?». По этому поводу очень хорошо выразился Бен Хоровиц: «Когда я был CEO стартапа, я спал как младенец: каждые 2 часа просыпался и орал». Примерно так выглядит жизнь продакта, когда его цель — превратить новую идею в успешный бизнес.

Важно понимать, что в стартапе роль продакта необязательно выполняет человек, в LinkedIn которого написано Product Manager. Эти функции может брать на себя Founder, CTO, маркетолог. Ведь команда стартапа всегда ограничена теми, на кого хватило бюджета, а задач всегда больше, чем людей.

К примеру, когда я разрабатывал систему анализа электрокардиограмм в украинском стартапе Cardiolyse, моя позиция называлась CTO, хотя в мои обязанности входили задачи продакт-менеджмента, управления командами разработчиков, продажи, поиска инвестиций и даже QA.

В процессе игры «Создать и продать продукт» главная задача, которую решает Product Manager, — это поиск так называемого Product Market Fit, ситуации, когда продукт удовлетворяет потребности целевой аудитории и она готова за этот продукт платить.

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

С точки зрения бизнеса Product Manager в стартапе — это такой jack of all trades. Он занимается всем подряд:

• руководит разработчиками;
• пишет какие-то минимальные спецификации;
• тестирует продукт;
• продает продукт: занимается отладкой каналов для привлечения клиентов, продумывает воронки или даже лично общается с потенциальными клиентами и заключает сделки (если это B2B);
• привлекает инвестиции, а поэтому питчит продукт будущим инвесторам;
• демонстрирует прототипы (если таковые имеются);
• принимает решения о том, какие фичи будут внедряться в первую очередь, а если точнее, определяет, какой функционал реально нужно разработать для успешного MVP, а что лучше оставить на период, когда появятся деньги.

Одна из самых важных задач продакта в стартапе — именно питчинг. Это трехминутная презентация продукта инвесторам, которая отвечает на 5 вопросов:

1. Что представляет из себя продукт?
2. Какую проблему он решает?
3. Для каких пользователей он предназначен?
4. Кто наши конкуренты?
5. Как мы планируем на всем этом зарабатывать?

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

Product Manager в стартапе постоянно находится в состоянии неопределенности: он часто не знает, какая из идей выстрелит, поэтому очень много экспериментирует. Иногда релизы делаются чуть ли не раз в день. Чтобы нащупать тот самый Product Market Fit и начать расти, приходится участвовать в бесконечной гонке изменений.

В этом процессе продакт часто сталкивается с такой штукой, как пивот (pivot). Пивот — это изменение стратегии развития продукта, иногда это поворот на 180 градусов, который сопровождается сменой целевой аудитории, финансовой модели или даже сферы деятельности. Хороший пример — компания Odeo (сейчас Twitter), которая изначально была платформой для подкастов, но, когда в 2005-м Apple анонсировала iTunes, владельцы Odeo поняли, что не смогут конкурировать с гигантом. Нужно было перестраиваться — так родилась идея социальной сети, сформированной вокруг «статусов» пользователей.

Конечно, Product Manager принимает решение о пивоте не в одиночку, в таком важном вопросе принимают участие все — от фаундера до самого молодого разработчика. Ответственность продакт-менеджера состоит в том, чтобы вовремя понять, когда нужен разворот, и осознать, что текущая версия продукта не находит тот самый Product Market Fit, пользователи не хотят платить и в итоге рушится вся надежда стать прибыльными.

Момент нахождения Product Market Fit — чуть ли не конечная точка в работе Product Manager на стадии стартапа. Можно сказать, что на этом этапе стартап более-менее оправдал себя и в состоянии привлечь деньги инвесторов (или использовать прибыль) для масштабирования той самой модели, которую нашли и построили.

Product Manager в запустившемся продукте

Стадия «после запуска» условная, и каждый продукт переходит на нее в свое время — кто-то еще на этапе MVP, а кто-то после множества релизов. Если разработка продукта началась в гараже, с сырой идеей и собранными по друзьям инвестициями, то до выхода на прибыльность или до хорошо закрытого раунда Product Manager и думать не может о том, чтобы переключиться из «стартап-режима» на масштабирование и качество. Для новых продуктов в уже работающих продуктовых компаниях ситуация немного другая.

Product Manager в стартапе, «который смог»

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

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

Product Manager начинает фокусироваться на:

• приоритизации новых фич;
• соответствии продукта требованиям безопасности и другим compliance;
• аналитике: отслеживании количества регистраций и покупок, анализе взаимодействия пользователя с продуктом (customer journey);
• доработке, поддержке и багфиксах.

Теперь Product Manager — это не просто функция, но и название должности конкретного человека. Эти обязанности больше не тащит на себе основатель или другой представитель менеджмента.

Команда на этом этапе тоже расширяется: добавляются QA, UI/UX-дизайнер и маркетолог, если повезет, нанимают бизнес-аналитика.

Основная задача PM на этом этапе — закрепить продукт на рынке, получить достаточное количество клиентов и сделать так, чтобы они хотели пользоваться именно вашим решением.

Product Manager в «карманном» стартапе

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

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

Product Manager в «карманном» стартапе больше похож на менеджера в запустившемся продукте, ведь ему:

• не нужно искать инвесторов;
• не нужно питчить на каждом шагу: есть PR-команда, которая решает эти задачи;
• необязательно глубоко продумывать стратегию продвижения: есть маркетологи, которые могут выполнить часть работы и провести более серьезное исследование рынка;
• не приходится в спешке делать продукт «из добра и палок», PM может проводить качественный quality assurance, чтобы уже в первой версии продукта оказалось минимальное количество багов.

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

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

Product Manager в успешно развивающемся продукте

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

Product Manager в развивающемся продукте чаще всего занимается:

• стратегией и коммуникацией со стейкхолдерами внутри компании;
• вопросами масштабирования, оптимизации и роста.

В зависимости от сферы бизнеса у менеджера стабильно функционирующего продукта может быть 2 основных типа задач.

Для B2B: обеспечить масштабируемость (scalability) продукта

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

Несмотря на то что мы все еще переходим от стадии «запустились» к стадии «успешно развивающийся продукт», масштабируемость — уже моя основная головная боль. Весь roadmap на ближайшие 2 года расписан с фокусом на scalability. Никаких тебе новых модулей, up-sales и прочего, все фичи и вся разработка направлены на создание максимально гибкого и масштабируемого продукта, чтобы у каждого следующего клиента он запускался с наименьшим количеством усилий со стороны компании, в идеале — вообще подключиться к данным клиента, чтобы дальнейшей настройкой продукта вуз мог заниматься самостоятельно.

Если с масштабируемостью все не очень, растущий продукт быстро начинает терять прибыль, клиентов и долю рынка.

Для B2C: рост и улучшение метрик продукта, увеличение прибыли

Ключевой метрикой на этом этапе становится LTV — суммарная прибыль, которую получает компания от одного пользователя за все время его взаимодействия с продуктом. Именно LTV мотивирует продактов менять модель монетизации на подписку вместо разовой покупки, так как в долгосрочной перспективе подписка может оказаться гораздо выгоднее. Даже BMW и Mercedes-Benzпланируют продавать свои автомобили по этой схеме, задумайтесь!

Поэтому со временем основной целью менеджера продукта становится создание фич и модулей, которые позволяют делать up-sales продукта и его cross-sales c другими решениями из линейки компании — все для увеличения среднего чека, количества повторных покупок, уменьшения оттока клиентов и так далее.

На этом этапе развития компании Product Manager сталкивается с новыми реалиями:

1. 90% его идей о том, как улучшить метрики, не работают, и продакт должен бороться с постоянной фрустрацией, ибо «что бы ты ни делал, не растет кокос».
2. У PM появляется большое количество скучной работы, связанной с детализацией спецификаций, документацией и релиз-менеджментом.
3. Все еще возникают вопросы с compliance: в зависимости от доменной области продукта продакт может столкнуться с security, accessibility и любыми другими вариантами compliance.

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

В крупных компаниях требования по более-менее сложным и нудным вещам типа compliance собирает бизнес-аналитик, но за Product Manager все равно остается большая часть задач, связанных с пользовательским фидбэком: с пониманием, что нужно аудитории, возможным изменением ее потребностей и так далее.

Когда начинаешь смотреть на продукт с точки зрения проблемы пользователя, открывается дивный новый мир конкурентов, о которых раньше и не задумывался. Плюс Product Manager начинает очень много работать над оптимизацией воронки и sales процесса, ведь, повторюсь, на этом этапе основная цель — увеличивать прибыль и долю рынка.

Однако не деньгами едиными. По мере роста компании менеджера продукта начинают волновать вопросы культуры и миссии бренда: что мы создаем, каких людей нанимаем в команду, как выстраиваем процессы внутри компании, чтобы повысить качество и производительность. Тем более что команда сильно расширяется: как правило, под одну фичу выделяется кросс-функциональная команда из Product Manager, Marketing Specialist, Tech Lead, Data Scientist, Development Team.

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

В нашей компании, например, Project Manager нет, за процесс внедрения продукта у клиента отвечают VP of Engineering, VP of Client Success и Product Manager. Для нас вопросы культуры очень важны, потому что успевать контролировать и менеджерить всех специалистов даже втроем невозможно. А это значит, что поведение команды очень сильно влияет на качество, сроки и бюджет. Если Product Manager хочет получить на выходе классный продукт, придется найти время на все эти вопросы.

Какими навыками должен обладать хороший Product Manager на любой стадии развития проекта

Может сложиться впечатление, что для каждого этапа развития продукта нужны совершенно разные продакты, но это не совсем так. Product Manager — всегда CEO продукта. Это означает полную ответственность, в том числе и за финансовый результат.

Product Manager — лидер команды, и он должен во что бы то ни стало реализовать озвученное ранее и сформулированное в roadmap видение продукта. Для этого нужно как минимум ясно и понятно писать спеки и быть на «ты» с командой разработки.

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

А еще хороший Product Manager — отличный коммуникатор:

• умеет слушать и слышать клиента, говорит с ним на одном языке;
• владеет навыками презентации;
• умеет продать свои идеи клиентам, команде, инвесторам и вообще всем.

Ну и самое главное: Product Manager — евангелист продукта! Он верит в то, что делает, потому что иначе добиться успеха невозможно.

Если вы решили стать менеджером продукта, задумайтесь, каких черт в вас больше. Обладаете бесконечным запасом энергии, готовы рисковать, имеете хорошее понимание продаж и маркетинга? Идите в стартап. Вы эмпат, умеете строить системы, расставлять приоритеты и не боитесь работать с метриками? Развивайте недавно запустившийся проект. Разбираетесь в технологиях, любите все улучшать и готовы погружаться? Возможно, вас ждет большой успешный продукт. Главное, помните: легко не будет, но точно будет интересно.

Цього разу DOU Ревізорзавітав до Materialise — продуктової компанії, що створює програмні рішення та 3D-принтингові сервіси. Серед проектів Materialise у Києві: створення софту для планування операцій майже на будь-яких суглобах та черепі для хірургів, а також моделювання та створення алгоритмів для обробки 3D-зображень.

Materialise заснували 1990 року в Бельгії, в Україні компанія з’явилася вже 2000 року. Наразі вона має 26 офісів у 20 країнах світу на всіх континентах, крім Африки та Антарктиди.

Глобально з компанією співпрацює понад 2000 осіб. У Києві їх 400, з них 270 — технічні спеціалісти.

В околицях і поблизу

До офісу за адресою вул. Раїси Окіпної, 8А переїхали ще дванадцять років тому. Сама локація наразі потребує заміни вивісок: на першому поверсі будівлі донедавна знаходився банк, який залишив власний банер.

Офіс знаходиться в 9 хвилинах пішки від метро Лівобережна та в 3 хвилинах — від зупинки Раїси Окіпної.

Поблизу — сила-силенна закладів харчування різних цінових категорій:

• У 4 хвилинах пішки від офісу знаходиться ірландський паб з комплексними обідами To Dublin. Середній чек ~100 грн.
• У межах 5-7хвилин у бік метро є також «Пузата хата», «Євразія» і азійський ресторан Woki Toki. Середній чек у закладах складає приблизно 80-200 грн.
• У сусідній будівлі розташовано ресторан китайської кухні Kitaika з середнім чеком у 100-150 грн.
• Каву та солодощі можна придбати у кав’ярні «Буна», що також знаходиться неподалік.
• У межах 10-15хвилин прогулянки Русанівською набережною є Tarantino, Soul Café (обід — 80-200 грн),іl Molino, Pesto, «Моменти», «Жовток», Spezzo та інші заклади.
• Купити продукти можна в «АТБ», що навпроти офісу, або у «Сільпо» біля метро Лівобережна.

Перед входом до офісу знаходиться безкоштовний паркувальний майданчик на 40 автомобілів, а також 5-8 мотоциклів,відділений шлагбаумами. Втім, як ми дізналися з анонімного опитування співробітників, часто на ньому місця зайняті автівками мешканців сусідніх будинків. Понад 10% опитаних бажали б розширення загальної площі паркувального майданчику, тоді як пішоходи та велосипедисти воліли б прибрати парковку взагалі.

Для велосипедистів можливості вуличного паркування немає. Велосипеди спеціалісти залишають біля ліфтів на 2 та 3 поверхах офісу, де можна розмістити до 20 «залізних коней».

Офісний побут

Materialise Community займає весь простір шестиповерхової будівлі, плюс напівпідвальний «нульовий» поверх. Загальна площа всіх приміщень складає 3500 м^² (у середньому 500 м^²на один поверх).

Зазвичай спеціалісти присвячують проектам 8 годин на день. Бажано — з 10 до 19, втім, цей час можна рухати, головне — бути присутніми на основних зустрічах. Вони зазвичай відбуваються об 11-12 годині.

Щодо можливості віддаленої співпраці, то чітких усталених правил щодо цього Materialise поки не має. Як повідомляють представники компанії, наразі вони працюють над створенням такої політики. У компанії є спеціалісти, що віддалено працюють на постійній основі або 30-50%часу. З боку технічної реалізації все просто: можна під’єднатися з наданого ноутбука через VPN або за допомогою віддаленого доступу працювати з власного комп’ютера.

В офісі є книжкова шафа, до якої можна замовити будь-яку літературу для професійного саморозвитку. Серед замовлень — «Creativity» Едвіна Кетмелла та «Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers» Александра Остервальдера.

На кожному поверсі офісу розташовані точки з кавою, чаєм, водою та солодощами. Вони користуються попитом і часто стають осередками зустрічей та розмов, що, на жаль, дещо заважає командам поблизу. Щопонеділка на кожній такій точці з’являються свіжі фрукти. Цю традицію в компанії назвали «Sweet Monday». Ревізія припала якраз на понеділок, тож до об’єктива знімальної групи потрапили груші.

Повноцінна кухня з холодильниками, посудомийною машиною, мікрохвильовками та іншим приладдям знаходиться на нульовому поверсі. Також там розміщено багато обідніх столиків, розрахованих на 80-100 осіб.Крім холодильників, з яких можна придбати готову їжу та розрахуватися за неї карткою, на кухні є імпровізована снек-лавка. Це стелаж, за який відповідають самі члени Materialise Community, регулярно наповнюючи його снеками або чимось смачненьким від своїх друзів/знайомих.

Оскільки приміщення нульового поверху напівпідвальне, там немає нічого, крім кухні, п’яти кімнат для перемовин, лаунж-зони та простору для проведення зовнішніх і внутрішніх мітапів. (Див. розділ «Відпочинок та натхнення»).

У прольоті біля ліфта на першому поверсі знаходиться банкомат. Це досить зручно: можна знімати готівку, не виходячи з офісу.

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

Вторсировину компанії відсортовує підрядник, що вивозить сміття. Наразі в Materialise скоротили використання пластику в офісі, натомість придбали керамічний посуд та паперові стаканчики.

Щодо зон для паління, то вони знаходяться на вулиці, подалі від кондиціонерів та вентиляції.

Робочий простір

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

На кожному поверсі є від двох до п’яти переговорних кімнат, усього на офіс їх 18. Кімнати відрізняються за розміром: є як невеликі переговорні на двох-трьох осіб, так і просторіші. На п’ятому поверсі знаходиться велика кімната з дванадцятьма стаціонарними комп’ютерами, проектором та телескопом, в якій проводять навчання. Наразі в ній відбуваються заняття C++ академії Materialise. Курс триває три місяці, проводиться для попередньо відібраних учасників, а ті, хто найкращим чином проявить себе під час навчання, отримають пропозицію продовжити співпрацю з компанією.

Офіс вдало зоновано: тут є маленькі (на п’ять-шість спеціалістів) кабінети та великі опенспейси (до 30), поєднані коридором. Оскільки офіс розширювався поступово, кожен простір має власні особливості ремонту. Що стосується доступу до простору, то електронну перепустку необхідно мати при собі і щоб зайти, і щоб вийти з поверху. Пересування переговорними кімнатами та кабінетами не обмежується, виняток складає лише офіс-спейс для Deployment Team, до кімнати якої, відповідно до вимог SOX, мають доступ лише члени цієї команди.

У тих частинах, де збираються команди одного домену, поруч з open space знаходиться окрема зона для Department Manager. Зазвичай така посада передбачає багато зустрічей та синхронізацій, тож, щоб не займати переговорні кімнати, зустрічі проводять просто у цьому відведеному спейсі.

Раз на два-три місяці в Materialise проводять Newcomers’ Day, коли новачків знайомлять з традиціями, культурою, внутрішніми особливостями структури компанії, дарують брендовані блокноти. Department Manager-и кожного напрямку розповідають про те, чим займаються спеціалісти в їхньому домені. Також в програмі дня — ланч новачків та керівників департаментів і вечірній фуршет-нетворкінг.

Кожен спеціаліст, який приходить працювати до компанії, забезпечується усім необхідним: столом, тумбою, кріслом та комп’ютером Dell з периферією. Аналітики та менеджери проектів отримують ноутбуки, решта спеціалістів користуються стаціонарними комп’ютерами. Де-не-де в кабінетах зустрічаються iMac комп’ютери, які призначені для тестування. Але основна операційна система, на якій використовуються продукти, розроблені Materialise, — Windows, тож комп’ютери з «яблуком» — радше виняток.

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

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

У середньому, за даними компанії, на одну особу припадає 3,5 м^²офісного простору.

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

Відпочинок і натхнення

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

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

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

Втілити свої ідеї в життя та роздрукувати будь-які макети можна за допомогою одного з двох офісних 3D-принтерів.

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

У Materialise Community є футбольна команда, яку компанія підтримує: покриває вартість залу, форми, тренувань, а також участь у турнірах.

Спеціалісти мають змогу двічі на тиждень по півтори години займатися англійською. Для цього необхідно подати запит та скласти тестування. Після визначення рівня знань підбирається група (причому є як ранкові, так і вечірні заняття). В кожній — по 3-6 осіб.

На одному поверсі з кухнею знаходиться лекторій на 50 місць, де регулярно проводяться зовнішні мітапи спільноти ALT.NET, KyivAlgoClub, а також власні мітапи з С++.

DOU Ревізор запитує

Ми провели анонімне опитування членів Materialise Community, у якому взяли участь 124 спеціалісти, з яких 97 — технічні. Ми поцікавилися, чи задоволені вони офісом, і попросили оцінити за п’ятибальною шкалою певні характеристики: розміщення, графік і офісний простір.

Розміщенням цілком задоволені більше половини спеціалістів, і лише 13% опитаних оцінили цей критерій в 3 та менше балів. При цьому 8% називають розташування однією з основних переваг офісу.

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

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

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

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

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

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

Макс, Software Engineer, 3 роки в компанії

Круто те, що офіс розташовано на лівому березі. Якщо, як мені, треба їхати десь з Академмістечка, то достатньо просто застрибнути в метро, і за 50 хвилин ти вже на місці. Не потрібно штовхатись у заторах десь на Хрещатику. Плюс, у нас тут поруч Русанівка, Дніпро, тож повітря явно свіжіше та є де прогулятися.

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

Трапляються проблеми адміністративного характеру... Десь проектор відпадає, хтось попише дошку маркером для фліпчарта, і доводиться спиртом відтирати... Та це все «робочі моменти».

Що стосується організаційних штук — у нас все ок.

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

Що стосується меблів, то я власноруч проводив дослідження і намагався знайти класне ортопедичне крісло. Як виявилося, ми закупаємо одні з кращих, що є на ринку, і, в принципі, крісла — норм. Ще трапляється така практика, коли новим спеціалістам дають крісла, на яких вже хтось посидів. Коли я тільки почав працювати в компанії, то явно відчував, що мені дісталося вже «пожоване». Але старий інвентар намагаються заміняти, і зараз маю нове крісло, просто з заводу.

Поліна, функціональний аналітик, 6 років у компанії

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

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

Ілля, Software Engineer, 1,5 роки в компанії

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

Фіч в офісі небагато. Мені подобається вентиляція на шостому поверсі, нам доволі комфортно. Знаю, що на п’ятому є з цим проблеми. Обіцяють зробити невелику кімнату для відпочинку, але туди ще не привезли PlayStation.

Є кікер на п’ятому поверсі, щодня ми з товаришами ходимо туди грати. Ми дуже просили новий стіл для кікера, та більшість хотіла аерохокей. У нього ніхто не грає, ніхто навіть не знає, як його вмикати — стоїть собі пилом припадає. А ми, хоч на старенькому столі, та постійно граємо. Також варто було б покращити стільці. Нові стільці, які замовляють, просто жахливі. Два роки тому, коли до команди приходив новий співробітник, йому давали новий стілець. Та й зараз так. Але вони (ті, що темно-сині) якісь не дуже. А от блакитні — класні.

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

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

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

Андрій, Business Intelligence Engineer, 3,5 роки в компанії

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

Раньше я часто играл в пинг-понг. Сейчас мне нужно подниматься с первого на шестой, поэтому не играем. Я из «староверов», и проекты для меня — это все-таки проекты, а не лаунж-зона, где ты сидишь вальяжно расслабляешься. Бывает по-разному, но релакс и отдых у меня больше ассоциируется с домашним пространством. В офис ты пришел, выполнил свои задачи, поделился информацией — и пошел домой.

Было бы круто добавить что-то наподобие перегородок на первом этаже в опенспейсе. Раньше мы были тремя разными командами, а сейчас все команды сидят вместе. Может быть, сделать специальное покрытие стен, чтобы во время проведения митингов не гуляло эхо.

Добираться на работу на машине с Позняков мне было очень комфортно до открытия River Mall. Сейчас еще и реконструкция Южного моста со стороны Правого берега наложилась, так что на работу едешь 15-20 минут,а с работы — все 40. Но если на метро — то час.

Ну що, ми поїхали далі... А якщо ви хочете, щоб DOU Ревізор приїхав до вас, пишіть нам: revisor@dou.ua

Ми катаємося по Україні в пошуках найкреативніших та нестандартних офісів ІТ-компаній. Разом з нами ви зможете зазирнути за лаштунки офісного життя. Але вирішувати, гарний це офіс чи ні, будете тільки ви!

Стежте за нами у Facebook.

Підписуйтесь на відеоканал DOU Ревізора на YouTube.

Фотограф: Леся Коверега

От редакции: в рубрике DOU Booksучастники сообщества рассказывают о пяти любимых книгах — тех, которые меняют мировоззрение и могут быть полезны читателям-коллегам.

[Об авторе: Александр Головатый — Senior Front-end Developer в компании AppsFlyer, мировом лидере по мобильной атрибуции и аналитике. C 2011 по 2016 работал старшим разработчиком и руководителем Front-end команды в американской компании Inflection (Svitla Systems, outstaff), с 2016 по 2017 — Front-end Lead в американском стартапе JetBridge. Сооснователь курсов по программированию «FullStack Академия». Увлекается книгами о саморазвитии и стартапах]

Хочу поделиться пятью, на мой взгляд, лучшими книгами для изучения JavaScript. Книги будут полезны не только тем, кто недавно начал изучать вселенную JS, но и фронтенд-разработчикам с опытом. В основном, конечно же, книги предназначены для новичков.

Очень тяжело рекомендовать литературу для старших JavaScript разработчиков, (особенно когда нужно указать только 5). Спектр задач, которые можно решать с помощью JavaScript, очень широк: от мультиплатформенной разработки на Elektron, мобильной — React Native или NativeScript, веб-, как Front-end, так и Backend, до разработки браузерных расширений. Для более опытных JS «ниндзя» лучше всего подойдет специализированная литература под прикладные задачи, разбор открытых библиотек на GitHub и олимпиадные задачки по информатике, а также работа с ментором.

Нік Морган «JavaScript для дітей. Веселий вступ до програмування»

Невзирая на детское название, книга довольно технически сильная и читать ее будет не скучно даже опытным JS программистам. Я очень люблю изучать языки программирования на примерах разработки простых казуальных игр. Наверное, поэтому книга попала в пятерку лучших для изучения JavaScript. В ней, кроме классического изучения основ программирования по массивам, циклам, управлению элементов на веб-странице, вы также встретите примеры разработки онлайн-игр «Поиск сокровищ», «Виселицу» и «Змейку». Думаю, книга будет идеальном стартом. Что может быть интереснее и веселее, чем увлекательная разработка игр с множеством красочных картинок и последовательных примеров кода.

Илья Кантор «Современный учебник JavaScript»

Учебник написан настоящим гуру по JS Ильей Кантором, автором знаменитого русскоязычного онлайн-ресурса по изучению JavaScript — javascript.ru, знакомого каждому веб-разработчику. Этот трехтомный труд достойный похвалы, очень детализированное описание всех тонкостей и особенностей современного JavaScript. Кроме стандартного изучения основ, структур данных, замыкания, объектов, ООП в JS, вы также изучите более продвинутые темы: итераторы, промисы, генераторы, модули, события, создание графических компонентов, регулярные выражения, анимацию, AJAX, оптимизацию и еще много другого.

Учебник состоит из трех томов: «Язык JavaScript», «Документ, события, интерфейсы», «Тематические разделы». Книга читается легче, чем еще один классический труд — «JavaScript. Подробное руководство» Дэвида Флэнагана, который по праву также входит в нашу пятерку.

Флэнаган Дэвид «JavaScript. Подробное руководство»

Эта книга для меня является самым обширным справочником по JS. В первый раз она читается немного сложновато. Но через некоторое время книгу нужно снова прочесть для более глубокого понимания материала. В мире JavaScript, думаю, она уже давно стала священным «Граалем», обязательным для изучения. Вы сможете выучить кроме базового JavaScript, также работу с документами, объектом Window, обработкой событий, с протоколом HTTP, библиотекой jQuery, изучить работу с графикой и медиафайлами и как сохранять данные на стороне клиента, а также работу с прикладными интерфейсами HTML5.

Лично для меня две вышеперечисленные книги являются самыми лучшими и полными учебниками по JavaScript.

Кайл Симпсон «Вы не знаете JS»

В оригинале — Kyle Simpson «You Don’t Know Js»
Онлайн-версия книги на английском доступна на GitHub

Кайл Симпсон — это Open Web евангелист из Остина, штат Техас, который увлечен всем, что связано с JavaScript. Он — автор, тренер семинаров, технический спикер на многочисленных конференциях. На самом деле это целая серия небольших книг по JavaScript. Так как каждая книга раскрывает лишь небольшую часть материала, я рассматриваю их как один источник и как одну «книгу, разбитую на главы». Вот список: «Up & Going», «Scope & Closures», «this & Object Prototypes», «Types & Grammar», «Async & Performance», «ES6 & Beyond». Эта серия учебников идеально подходит для более глубокого изучения и понимания самых сложных частей JavaScript. Особенно стоит выделить «Scope & Closures», «this & Object Prototypes», «Async & Performance». Вся серия книг отлично дополняет изучение JS после трех вышеописанных учебников.

Michael McMillan «Data Structures and Algorithms with JavaScript»

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

В библиотеке современного разработчика находятся десятки, а то и сотни книг по программированию. Мне очень интересно узнать, какие ваши лучшие книги по изучению и разработке JavaScript. Пишите ваши топ-5 книг в комментариях, включайте также книги по React, Angular и Vue. Буду рад ответить на любые вопросы.