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

Ми дізналися в ІТ-компаній про потребу в trainee/junior-спеціалістах і джерела пошуку молодих співробітників у 2019 році. В опитуванні взяли участь 55 ІТ-компаній. 5 з них не співпрацювали з новачками в 2019-му,а інші за минулий рік найняли понад 5370 молодих фахівців.

Як і торік, найбільші компанії беруть новачків переважно через власні курси та освітні програми. З-поміж іншого залишається популярним пошук джуніорів за рекомендаціями — 39 компаній згадали цей канал найму. Серед job-сайтів найпопулярнішими є DOU, Djinni.co та Rabota.ua.

Під джуніорами ми розуміємо спеціалістів без досвіду роботи або з досвідом менше як рік (у деяких компаніях такі фахівці звуться Trainee або Intern).

Найактивніше з новачками співпрацювала компанія SoftServe, але вона взяла на 420 джуніорів менше, ніж 2018-го.Далі йде EPAM Ukraine — тут, навпаки, +130 новачків до 2018-го.

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

75% джуніорів з опитаних компаній знайшли роботу в топ-3 містах — Києві, Харкові та Львові. Частка найманих початківців у цих містах майже однакова. Це є нехарактерним для наших опитувань. Але схоже, що великим ІТ-компаніям простіше шукати джунів поза столицею, де нижча конкуренція за таланти. Загалом опитані компанії брали на роботу початківців у 20 українських містах.

Найпопулярнішими технічними напрямами є QA, Java, Front-end/JavaScript. Динаміка тієї чи іншої спеціальності іноді залежить від участі або відсутності в опитуванні якоїсь компанії. Так, наприклад, цього року в опитуванні взяла участь компанія Zone3000, яка 2019-гозапросила на роботу 600 спеціалістів підтримки, через що категорія Support вийшла на друге місце за популярністю.

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

Підписуйтеся на Telegram-канал для джуніорів, щоб не пропустити цікаві стажування, курси, вакансії та статті.

У попередній серіїя розповідав про те, як вчився в Китаї, а також згадував, що отримав пропозицію від компанії Bosch, від якої важко було відмовитися. Ця назва була відома мені із самого дитинства, адже мій дядько завжди користувався електроінструментом цієї марки. Я не тямив себе від щастя, але це щастя ще треба було заслужити. Тож у цій частині розповім про оформлення на роботу, ІТ-ринок, побут та карантин через коронавірус.

Трішки про бюрократію

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

Далі HR компанії доручила мені взяти з університету No bad behavior record. Тоді я подумав, що це аналог довідки про несудимість. Запакувавши її разом з результатами медичного огляду, я передав це все інтернові компанії, який навчався в моєму виші, і з чистою совістю поїхав на канікули в Суми.

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

До мого повернення залишався один місяць, коли пані з відділу кадрів вийшла на мене знову. Цього разу вона сказала, що потрібна довідка про несудимість. Так я й дізнався, що її англійська назва — No criminal record. Я подав заявку онлайн на сайті МВС України. Наступного дня з відділу кадрів надійшло уточнення: оскільки протягом останніх трьох років я жив у Китаї, то цю довідку треба було брати саме там, а не в Україні. Ба більше, пані вже зверталася до місцевої поліції, і там сповістили, що такий документ має видати мій університет.

Я написав старій знайомій, на що та відповіла, що кампус на канікулах і вона випише мені довідку, коли я повернуся на навчання. Нагадую, що я встиг вступити до докторантури (PhD) ще до оферу. Так зруйнувався мій план поїхати до КНР уже за робочою візою, натомість розв’язалася проблема з місцем проживання на перший час.

У середині вересня я скористався зворотним квитком за маршрутом Київ — Стамбул — Шанхай і опинився в пустому, але такому знайомому житловому приміщенні гуртожитку. За літо в ній зробили ремонт, а мої пожитки чекали на мене в кімнаті мого колишнього сусіда. Минуло тільки два місяці відтоді, як я її покинув, а за відчуттями вона була ніби з іншого життя. Довідку про несудимість, замовлену через інтернет, я так і не забрав. Вона була готова наступного дня після вильоту. Термінову, як ви розумієте, замовляти не було рації.

Коли я забрав папірець у міс Янг, нашої кураторки, з’ясувалося, що це був не останній крок: документ треба було завірити в нотаріальній конторі міста Чанчжоу. Я поїхав туди й дістав зауваження: «Тут написано, що ти навчався з вересня 2015-годо липня 2018-го,але не вказано конкретні числа». За цим принциповим виправленням я поїхав назад до альма-матер, сподіваючись уладнати це питання до кінця робочого дня.

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

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

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

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

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

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

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

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

Я надіслав термінового листа до Сум службою EMS. Це зайняло п’ятнадцять діб. Через день мій дядько забрав довідку, що вже два місяці чекала своєї долі, і надіслав її зі звичайного поштового відділку. Це також зайняло п’ятнадцять діб. Тим часом непомітно підкрався грудень. Мені ще належало перекласти документ на китайську мову в місцевому бюро. Китайські перекладачі такі суворі, що «зашифрували» ієрогліфами навіть моє ім’я. А втім, проблеми це не склало, адже остаточний варіант документа мав пройти через консульство, де й надали йому належного вигляду.

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

Незадовго до католицького Різдва я отримав подарунок: міграційна служба міста Чанчжоу видала мені дозвіл на роботу. Я планував полетіти до В’єтнаму чи Гонконгу, щоб у тамтешньому посольстві Китаю оформити робочу візу.

Дуже швидко мої товариші з Росії й Азербайджану налякали мене моторошними історіями про те, як літали до наведених вище регіонів, а звідтіля — додому, бо зі студентської візи на робочу можна переходити тільки на Батьківщині. Там, у барі, я на кілька секунд втратив ознаки життя. Пізніше HR підтвердила їхні слова. Моїх заощаджень вистачило б лише на квиток в один кінець, про що я її і сповістив. Компанія погодилась оплатити мій переліт.

Квартирне питання

Оскільки моє працевлаштування ставало все реальнішим, варто було замислитися й про пошук нового помешкання. Мої вимоги були такі: район Уцзінь, у якому розміщено компанію; неподалік від Metro (мова про німецький супермаркет); у межах 2000 юанів на місяць. Агенти не забарилися й запропонували три варіанти. Я зупинився на другому з них: приміщення було над торговим центром, вхід до Metro прямо у дворі, автобусна зупинка — перед будівлею, а до станції міського метрополітену, що відкрився в нашому місті тільки 2019 року, не більш як десять хвилин пішки.

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

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

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

Цього разу я звернувся до колишньої однокласниці з курсів китайської, дружини мого майбутнього начальника, і попросив одразу 10 000. Вона трішки заклякла від такого прохання, але все ж виділила запитувану суму. Я таки вірив в успішне завершення операції, оскільки мої борги становили вже 15 000 юанів (~60 000 грн). В Україні така сума могла б стати ярмом на моїй шиї на кілька наступних років.

Якщо продовжити тему житла, то подружжя з Росії винаймає розкішні апартаменти в хорошому районі за 3000 юанів/місяць. У наявності: простора зала-їдальня, дві спальні, кухня, туалет з ванною і навіть маленька кімнатка, яку вони відвели під комірчину. З розрахунку на одну особу вони платять навіть менше, ніж я. Більшість же одинаків, у яких я був у гостях, орендують комфортні двокімнатні квартири в межах 2000 юанів, тому я й озвучив таку суму із самого початку. Є й невеликий інсайд із Шанхая: дві подружки-стюардеси платять 5000 за скромну оселю з двома спальнями неподалік від аеропорту «Хунцяо».

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

Тож ми забронювали квитки на друге січня з поверненням за дев’ять днів. Візовий центр у Києві працює в понеділок, середу й п’ятницю. Я вилетів у середу, щоб прибути до Борисполя в четвер, заночувати в столиці й зранку подати документи. Час чекання — рівно тиждень, який я планував провести вдома.

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

— У вас тут дозвіл на проживання, — сказала вона.

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

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

Мені забракло слів.

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

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

Після чарівного зимового тижня я повернувся до Китаю з пустими руками. Директор R&D сказав, що це невелика втрата й компанія підтримає й другу мою поїздку. Мені одразу полегшало.

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

З другої спроби мені таки видали візу, і того ж вечора я покинув країну. 31 січня 2019 року — дата мого останнього на цей час в’їзду до КНР, а першого лютого я офіційно поповнив лави працівників компанії «Rexroth. A Bosch company».

На щорічному корпоративі компанії «Rexroth. A Bosch company»

Кілька слів про «Rexroth. A Bosch company»

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

«Rexroth. A Bosch company» спеціалізується на гідравліці й виробничій автоматизації. Це не ІТ-компанія, і більшість реалій українських (і не тільки) «галер», про які я читаю на dou, їй не притаманна. Команда розробників — лише одна з багатьох ланок виробництва. У нас немає чіткого поділу, як-от: Front-end, Back-end, Desktop, Mobile, UI/UX тощо. Це вимагає від нас універсалізму.

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

Глобально Bosch перебуває на етапі трансформації в IoT-компанію. Торік запущено масштабну рекламну кампанію під гаслом «Like a Bosch». За ним ви можете знайти креативні й дещо смішні рекламні ролики на ютубі. Відповідно попит на спеціалістів у сферах IT та IoT постійно зростає. Я бачу велику кількість вакансій у всіх містах Китаю, де є представництва, тільки не всюди потрібні саме розробники програмного забезпечення.

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

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

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

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

Це спокійне містечко з чистим повітрям, оскільки там заборонили будь-яке виробництво, окрім двох: однойменна марка пива Qiandao hu і, мабуть, найвідоміший у Китаї виробник напоїв — Nongfu Spring. Обидва підприємства беруть воду з місцевого резервуара.

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

Вид з гори на заміську базу відпочинку

ІТ-ринок і зарплати

Я вже було полишив надію знайти бодай якусь інформацію з конкретними цифрами. Деталей свого контракту я не маю права розголошувати, а на сайтах для пошуку роботи пишуть лише про вимоги до кандидата і його майбутні сфери відповідальності. Але ось на китайськомовному ресурсі 51job.com я таки наклацав певну статистику для айтішників. Лінк мені надіслав наш тимлід, свого часу саме через цей сайт він знайшов вакансію в «Rexroth. A Bosch company» у місті Чанчжоу. Сам він родом із Чунціна — найбільшого міста світу.

Отже, діапазон такий: від 5000 до 42 000 юанів на місяць. Найбільше серед вакансій, що я знайшов, пропонують ECU-розробникові в місті Фошань, провінція Гуандун. На десять тисяч менше може розраховувати програміст під Linux, що володіє С/С++ і Python. Якщо відійти від пікових значень, то середній розкид грошової компенсації в межах 8000–15 000 юанів/місяць.Є попит на Java, C#, C++, Android, iOS і навіть VB і Delphi.

Щодо компаній, то, окрім всесвітньовідомих учасників місцевого ринку технологій на кшталт Xiaomi, Huawei, Tencent і Alibaba, є ще й представництва іноземних брендів, наприклад: EA, Amazon, Airbnb, Apple, а також велика кількість автовиробників, як-от: General Motors, BMW, Tesla, Volkswagen, зокрема й зі своїми RnD-відділами.

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

Тимбілдинг у місті Цианьдаоху

Гастрономічний екскурс

Майже всі ціни взято з Metro, де я найчастіше закуповую харчі.

Паковання нарізаного цільнозернового пшеничного хліба (250 г) коштує 7,20. П’ятилітрова пляшка олії може сягати 56 одиниць китайської валюти й більше. Тут є навіть «Олейна». Лоток з дванадцятьма яйцями має ціну 17,20 юаня.

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

На щастя, «Метро» — міжнародна мережа, тож має великий вибір імпортних товарів. Молоко я беру переважно ящиками. Ціна за ящик з 12 пачками по 250 мл коливається в діапазоні від 48 до 76 юанів залежно від виробника. Так зручніше, бо в запакованому вигляді воно довше зберігається. Як альтернативу можна розглянути півторалітрову каністру за 19,90.

Я не мав морального права оминути сири в цій розповіді. В асортименті є майже всі відомі мені сорти, зокрема й з пліснявою, від 36 юанів за 200 г. Імпорт з Ірландії, Швейцарії, Німеччини тощо. Є й скибочки від President для домашніх бургерів. Двісті грамів вершкового масла вищезазначеного виробника обходиться мені в 35 юанів.

Лише на четвертому році проживання я дізнався, що тут продається згущене молоко. Виробником виступає Nestle, і коштує така радість 16 юанів за 350 г. Ієрогліфи вам навряд чи багато про що скажуть, тому шукайте синього орла на білій банці. А от мед порівняно дорогий: від 31 юаня за трьохсотграмову баночку до 100–150юанів за 500 г.

Кілограм нарізаної меч-риби (якщо перекладач не обманює) вартий 57,60. А от та ж кількість лосося затягне на 148 юанів. А втім, якщо не вживати його кілограмами, інколи можна собі дозволити. Пів кіло курячих груднинок — 13,90.

П’ятсот грамів помідорів — приблизно 15 юанів. Картоплі — 14. Загалом, тут ви зможете знайти як звичні вам овочі, включно з кропом і петрушкою, які місцеві майже не вживають, так і популярні в китайській кухні. Усі, крім буряка. Цього «пана» можна замовити на таобао, але й тут є нюанс: його не висилають поштучно.

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

Фрукти. Яблука в середньому коштують 25 юанів/кг, груші — 26 юанів/кг, апельсини — 16 юанів/кг, банани — 16 юанів/кг.

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

Для розв’язання цієї проблеми знову звертаємося до таобао — це той самий Aliexpress, але для внутрішнього ринку. Там російські постачальники пропонують 2,4 кг гречки за ціною 46 юанів, стільки ж перловки — за 30, а пшоно — так і зовсім за 10. Я як замовив собі велику коробку з крупами років зо три тому, так і досі не маю потреби в поповненні.

Прошу звернути увагу, що в Китаї вагу вимірюють не в кілограмах, а в «цзінях» (1 цзінь = 500 г). Не знаючи цього, ми з другом колись подумали, що нас обважили. А коли ми розібралися з цим питанням, сталася інша оказія: ми взяли кілька ківі, а ціну нам нарахували, як за кілограм. Тому бажано відрізняти ієрогліфи «斤» (цзінь) і «个» (ge — штука).

Якщо говорити про походи до громадських закладів харчування, то насамперед варто скуштувати качку по-пекінськи. Її ви зможете знайти, наприклад, у мережі 全聚德 (Quánjùdé), заклади якої розташовано чи не в кожному місті. Будьте готові залишити там понад 200 юанів за вечерю на двох.

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

Дуже популярний серед китайців Hot pot (кит. Huǒguō). Ви сідаєте за стіл, посередині якого вмонтовано плитку. Є варіація, де газову плиту з балоном приносять окремо. На неї ставлять каструлю із заготовленим супом на ваш вибір, наприклад гострий, томатний або грибний. Можна вибрати відразу два різновиди, які відділять перегородкою.

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

А ще китайці, а особливо китаянки, шаленіють від молочного чаю, або, як його називають на Заході, бульбашкового чаю (Bubble tea). В оригіналі це різні сорти листового чаю з цукром, молоком і якимись добавками на зразок мармеладних кульок, які й відповідають за «бульбашки» в назві.

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

Транспорт

Почну з автобусів: 2019-гоціна за проїзд зросла вдвічі й тепер становить 2 юані. У місті функціює щонайменше два різновиди автобусних ліній: звичайні номери й BRT (Bus rapid transit). Зупинки першого розташовано на узбіччі, як ми до того звикли. У разі пересадки доводиться платити повторно. А от станції другого побудовано посередині доріг з окремою смугою для відповідних автобусів. Ви платите лише за вхід на зупинку, а далі можете сісти на будь-яку доступну одиницю транспорту. Під час пересадки доплачувати не треба, якщо ви не покидаєте станції.

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

Замість Uber тут функціює Didi з мінімальною вартістю 9 юанів. Можна замовити звичайне міське таксі, приватних перевізників, елітне авто або розділити вартість з незнайомцями, яким з вами по дорозі, — так званий carpool.

Швидкісні поїзди — це окремий вид мистецтва. Щоб дістатися Шанхая (~185 км) мені потрібно 50 хвилин і 75 юанів. Для порівняння: поїздка від Сум до Харкова, майже на таку саму відстань, займає три години. До Нанкіна їхати ще менше — ~130 км за 35–40хвилин і 65 юанів. Доїхати до Пекіна (~1110 км) можна за 5 годин і приблизно 500 юанів відповідно. Усі цифри наведено для другого класу прямих рейсів. Якщо їхати стоячи й з пересадками, ціну можна знизити втричі. Звичайні нешвидкісні поїзди також є. Бронюючи квитки у додатку, звертайте увагу на першу літеру в назві рейсу: G і D доставлять швидко, решта — не дуже.

Що зручно, навіть у таких маленьких містечках, як моє (населення приблизно 4 млн осіб), може бути два вокзали. У нас тепер будують третій. У мегаполісах їх зазвичай по чотири-п’ять. Однак квитки раджу купувати хоча б за один день. Можна спробувати придбати їх по приїзду, але є ризик опинитися в незручному становищі: змарнувати кілька годин через пізнє відправлення, їхати стоячи або з пересадками, про що я згадував вище, або ж не дістати квитків узагалі. Особливо це актуально перед вихідними. Напередодні великих свят, як-от Китайський новий рік або Національний день, я взагалі б радив планувати подорожі не пізніше як за місяць.

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

Припаркувався у дворі

Окрім вокзалів, у нас ще є аеропорт. Справжній, а не автобусна зупинка, як там, звідкіля я родом. З нього я літав до Ченду. Політ обійшовся мені в 1400 юанів в обидва кінці. Аеропорт міжнародний, тож можна замахнутися навіть на Японію, Малайзію чи Таїланд. У Шанхаї поки два аеропорти, третій — на стадії будівництва.

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

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

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

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

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

Це обмеження зачіпає й деякі інші сфери діяльності. Наприклад, я не можу самостійно заплатити за VPN або придбати гру на Steam. У найліпшому разі вдасться заплатити засобами online-банкінгу, але інтерфейси їхніх сервісів набагато складніші за Приват24. Мені вдалося провернути подібну операцію з Bank of communications, але я так і не розібрався із системою China construction bank. Куди простіше скинути код китайському другові, щоб він заплатив зі свого акаунту, і надіслати йому кошти. Але майте на увазі, що дія QR-коду збігає за кілька хвилин.

На більшості доріг «кишені» для мопедів відділено від основної траси клумбами або невеликими парканами. Проте не дивуйтеся, якщо побачите мопедиста, який їде основною дорогою. По третій смузі. Назустріч рухові машин. Правила дорожнього руху тут діють тільки для автомобілістів, яких штрафують за порушення ПДР, і після п’яти штрафів можуть навіть забрати посвідчення. Тож, переходячи дорогу, подивіться ліворуч, потім праворуч. Діставшись «острівка безпеки», повторіть.

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

Часто між локаціями можна переміщуватися, узагалі не виходячи на вулицю. Наприклад, між аеропортом «Хунцяо», однойменним вокзалом і двома торговими центрами — The Hub та Walking paradise (місто Шанхай) — є ціла система «катакомб» під землею, а також переходи над дорогами.

Держава в смартфоні

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

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

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

А з часом ваш телефон обросте додатками для банківських операцій, відстежування руху автобусів у вашому місті й, скажімо, замовлення пісень у KTV (караоке). Але це не обов’язково.

Виставка героїв кінематографічного всесвіту «Marvel», Шанхай

Ода охороні здоров’я

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

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

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

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

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

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

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

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

З купою паперів я повернувся до чергового медика. Мені так і не сказали, у чому причина і як це лікувати. Лише виписали направлення на крапельницю, про яку я так багато чув. З голкою в руці я просидів до четвертої ранку. Шлунок я, мабуть, лікуватиму під час наступного візиту до України.

Хроніка апокаліпсиса

Перший і другий тижні 2020 року

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

Третій тиждень

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

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

Четвертий тиждень

22 січня ми офіційно пішли на канікули. Китайський новий рік припадав на суботу 25-го,і колегам ще треба було дістатися до своїх рідних міст, щоб відсвяткувати його в колі близьких. Протягом свят у мережі все активніше обговорювали тему коронавірусу, що нагадало про лист на e-mail, одержаний на початку місяця. На таобао надійшло сповіщення, що з 17 січня до 3 лютого можуть бути затримки з постачанням масок. Звичайних хірургічних в аптеках не залишилося.

З перших днів канікул мені приходили оновлення з компанії про засоби запобігання зараженню вірусом. Якщо коротко, то:

1. Старайтесь якомога менше виходити з дому. Якщо є змога, то замовляйте доставку продуктів додому.
2. Не виходьте надвір без маски.
3. Уникайте великих скупчень людей.
4. Регулярно провітрюйте приміщення тощо.

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

П’ятий тиждень

Асортимент продуктів у Metro істотно скоротився, але все потрібне ще можна було знайти. Ресторани, клуби, бари позачиняли. Циркулювання громадського транспорту обмежили. Вулиці були порожні, і лише поодинокі фігури в «намордниках» розбавляли статичні пейзажі. Перед вихідними мене сповістили, що нашу відпустку продовжено ще на тиждень. У ліфтах з’явилися серветки. Я не розумів, для чого вони, аж поки жінка, що їхала зі мною, не натиснула через неї кнопку.

Шостий тиждень

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

Сьомий тиждень

Завод почав своє функціонування, але тим, хто не мав потреби фізично перебувати на території підприємства, рекомендували подати заявку на дистанційне робоче місце.

Цікаво, що люди за межами КНР непокоїлися через ці події сильніше, ніж ті, хто залишався там. Мені надходили повідомлення в соціальні мережі про те, у якому невеселому становищі я опинився, і з пропозиціями евакуюватися або хоча б перестати виходити з дому. Я всім відповідав приблизно однаково:

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

Восьмий тиждень

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

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

Дев’ятий тиждень

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

Десятий тиждень

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

Одинадцятий тиждень

З’явилася потреба отримати особистий «Код здоров’я» в Alipay, і лише за його наявності можна проходити пости охорони. А втім, з його допомогою я вдало відвідав прощальну домашню вечірку нашого начальника. А наступного дня пішов забрати каву, замовлену через додаток, і побачив людей, що сиділи в кав’ярні. За наявності коду й задовільного показника на термометрі можна долучитися до числа «обраних».

Одна з останніх моїх світлин: запускали повітряних зміїв у парку. Маски все ще обов’язкові, але великі скупчення людей, як бачите, вже дозволили

Шістнадцятий тиждень

На цей час припало третє відрядження до міста Нінбо і перший виїзд з Чанчжоу у 2020-муроці. Півгодини до вокзалу, три години потягом, ще сорок хвилин на таксі до першого прояву расизму за все моє життя. Охоронець заводу наших клієнтів підскочив, як тільки побачив моє іноземне обличчя. Потім почав вимагати у мене «код здоров’я», що нормально. Я показав йому шанхайський зразок, котрим користуюсь щоденно. Його такий розвиток подій не влаштував і він вказав на QR-код для WeChat, що висів на вікні пропускного пункту. Я відсканував і заповнив заявку для отримання місцевого екземпляру. За кілька хвилин у моєму телефоні вже було підтвердження, що у «чорних списках» Нінбо я не перебуваю. На це старий лише махнув рукою і сказав: «Дзвоніть керівництву».

Мій менеджер довго пояснював по телефону, що з Китаю я не виїжджав вже більше року, весь карантин пересидів в одному місті і на роботу вийшов разом з усіма, а він особисто є свідком. У наявності «зелені коди» двох міст, тека заповнених анкет в online- та offline-форматах, довідки, щеплення, до лотка привчений. На іншому кінці дроту попросили надати їм час для наради. За двадцять хвилин нам передзвонили і повідомили, що всередину зайти мені не можна. Таким чином, мої колеги пішли працювати, а я поїхав до готелю.

Якщо чесно, я не сильно засмутився, оскільки в мене з’явився час прогулятися містом, відвідати визначні місця і пошукати інформацію в інтернеті. Виявляється, Нінбо вважається містом з найкращими умовами для інвестицій у Китаї, найкращим містом для життя і найкращим туристичним населеним пунктом Китаю. А ще там знаходиться головний собор католицької єпархії КНР. Прямісінько біля мого готелю. Щоразу проходив повз нього, і тільки на третій раз дізнався про значення цієї готичної будівлі.

Що далі

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

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

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

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

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

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

Підписуйтеся на наш Telegram-канал, щоб дізнаватися про найактуальніші можливості для джуніорів. Туди ми надсилаємо сповіщення про оновлення дайджесту, нові курси, стажування та вакансії.

AltexSoft

Напрям:курси .NET, Front end, QA.
Місто:Кременчук.
Дедлайн подачі заявок:реєстрація відбувається постійно, навчання у вересні.

Вимоги до кандидатів:

.NET:

• технічна освіта або студенти 2 курсу і вище;
• базові знання C#/.NET/SQL;
• англійська Pre-Intermediate і вище.

Front-end:

• технічна освіта або студенти 2 курсу і вище;
• базові знання HTML5/CSS3/JS;
• англійська Pre-Intermediate і вище.

QA:

• розуміння основ тестування (типів, методів та технік тестування);
• розуміння принципів ООП;
• логічне мислення;
• англійська Pre-Intermediate і вище.

Як потрапити:зареєструватися на сайті.

Умови:заняття двічі на тиждень. Front end та QA: запланована дата старту — 30 березня, у будні з 18:00, тривалість заняття — 2 години, курс триває 2-2,5 місяці. .NET: запланована дата старту — 23 березня, по 2 години у будні день з 18:00 та 6 годин в суботу з 09:00, курс триває 2,5-3 місяці.Найкращим студентам після закінчення курсу пропонують подальше стажування в компанії і працевлаштування.

Деталі:на сайті, або пишіть на пошту lab@altexsoft.com.

EPAM

Тип:курси.
Місто:Харків.

Напрями та дедлайни подачі заявок:

• Test Automationt — 14 червня.
• .NET — 14 червня.
• Java — 14 червня.
• Software Testing — 14 червня.
• DevOps — 14 червня.

Як потрапити:зареєструватися на сайтіта пройти тест. Тестування включає технічний комп’ютерний тест та перевірку рівня знань англійської мови. Співбесіда з рекрутером.

Умови:зовнішні заняття (до 3 місяців), Pre-Production лабораторія (від 3 до 6 місяців). Після закінчення навчання найкращі випускники отримають можливість продовжити співпрацю з компанією.

Деталі:на сайті.

InternetDevels

Напрям:курси — розробка сайтів на CMS Drupal 8, QA та PM.
Місто:Луцьк.
Дедлайн подачі заявок:реєстрація відбувається на постійній основі, оскільки курси відбуваються регулярно. Охочих, що не встигнуть потрапити на цей набір, запрошують на наступний.

Вимоги до кандидатів:

• для майбутніх програмістів необхідне базове розуміння PHP, HTML, CSS, JavaSсript (не обов’язково);
• для майбутніх РМ’ів необхідне знання англійської мови на рівні спілкування;
• загалом необхідне бажання вчитися та розвиватися.

Як потрапити:подати заявку на сайті.

Умови:курс триває 4 тижні. Заняття 3 — 5 разів на тиждень по 2-3 години.Найкращим студентам після закінчення курсу пропонують подальшу інтернатуру в компанії і працевлаштування.

Деталі:на сайті, на сторінці Facebook.

NIX

Напрям:курси.
Місто:Харків.

Вимоги до кандидатів:

• навчання Java;
• практика PHP + CMS;
• навчання BA;
• навчання .NET;
• навчання Azure DevOps;
• практика Android;
• навчання Linux administration / DevOps.

Як потрапити:подати резюме на сайті, пройти тестування в офісі або ВНЗ, пройти співбесіду.

Умови:Практика — очне навчання 40 годин на тиждень в офісі компанії (під час карантину — онлайн) протягом 3-хтижнів у літній період. Навчання — 2-3рази на тиждень у вечірній час від 1 до 5 місяців. Інтенсив — очне навчання 40 годин на тиждень в офісі компанії (або онлайн на час карантину) протягом 2-хмісяців.

Деталі:пишіть на пошту education@nixsolutions.com.

QATestLab

Напрям:онлайн-курси QA.
Дедлайн подачі заявок:реєстрація відбувається постійно.
Вимоги до кандидатів:навчатися можуть усі охочі.

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

Умови:викладачi курсів — QAEngineers компанії QA TestLab. Формат навчання: онлайн. Тривалість курсів — від 3 до 5 тижнів. Курси включають в себе лекції, що проводяться через систему GoToWebinar двічі на тиждень, практичні домашні завдання та підсумковий іспит.

Деталі:на сайті.

RubyGarage

Напрям:курси Ruby/Ruby on Rails.
Місто: Online.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• базові знання HTML, CSS, JavaScript та мінімальний досвід роботи з цими технологіями;
• знання базових принципів роботи баз даних і мови SQL;
• розуміння об’єктно-орієнтованої парадигми програмування;
• знайомство з однією з серверних мов програмування (PHP, Java, С ++ / С #, Python...);
• технічна англійська на рівні читання документації;
• бажання навчатися та вирішувати задачі;
• мінімум 10-15вільних годин в тиждень на навчання.

Як потрапити:заповнити форму на сайті, виконати тестове завдання, пройти співбесіду.

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

Деталі:на сайтіабо пишіть на пошту railscourses@rubygarage.org.

SoftServe

Тип:курси.
Місто:Львів, Рівне, Харків, Чернівці.
Напрям та дедлайн подачі заявок:

Нижче вказані дати початку курсів. Реєстрація закривається за 14 днів до старту.

Test Automation with Java: Харків і Рівне — 25 травня.

Java : Чернівці — 20 липня.

.NET: Чернівці — 1 червня, Харків — 6 липня.

DevOps for Unix: Львів — 22 червня.

WebUI : Харків — 25 травня.

Test Automation with Python: Рівне — 25 травня.

Test Automation with C#: Рівне — 25 травня.

Вимоги до кандидатів:

• рівень англійської Intermediate+;
• студенти дотичних напрямків 2-йкурс і вище;
• готовність до насиченої роботи.

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

SoftServe

Тип:сертифікація.
Місто:Львів, Дніпро, Харків.

Вимоги до кандидатів:

• .NET;
• Quality Control;
• Python;
• Java;
• WebUI.

Як потрапити:заповнити заявку на сайті, пройти вступний технічний тест і тест з англійської. Опісля — обрати зручну дату для задчі сертифікації.

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

SPD-Ukraine

Напрям: Java, Front-end, Test Automation.
Місто:Черкаси.
Дедлайн подачі заявок:на постійній основі.

Вимоги до кандидатів:

Java:

• Java 8 Core: класи/інтерфейси, Generic, Collections API, IO, Exceptions, анотації;
• принципи ООП;
• знання алгоритмів і структур даних;
• основи SQL;
• основи HTML/CSS/JS;
• основи Web: HTTP запити, Cookies, Session;
• основи Git;
• рівень англійської Intermediate або вище.

Front-end:

• знання основ HTML/CSS;
• вміння користуватися одним із графічних редакторів;
• досвід верстки від 3 місяців;
• досвід Responsive або Adaptive верстки;
• розуміння основ програмування, структур даних та алгоритмів;
• базові знання Javascript;
• основи Git;
• рівень англійської Intermediate або вище.

Test Automation:

• теоретична база QA;
• основи Java 8;
• принципи ООП;
• основи SQL;
• основи HTML/CSS;
• основи Web: HTTP запити, Cookies, Session;
• основи Git;
• рівень англійської Intermediate або вище.

Як потрапити:подати заявку на сайті, пройти тестування (англійською), пройти співбесіду (українською).

Умови:тривалість курсу: 7 місяців. Останні півтора місяця — робота в командах над фінальними проектами. Після успішного завершення — сертифікат SPD-Ukraine.

Деталі:пишіть на пошту info@spd-university.comабо на сайті.

Yalantis

Напрям:курс Golang.
Місто:Дніпро.
Дедлайн подачі заявок:до 11 травня.

Вимоги до кандидатів:

• досвід у Back-end розробці/DevOps від 6 місяців;
• продакшн доcвiд використання одного з розповсюджених мов розробки;
• розуміння та досвід використання REST API;
• базове розуміння основ Golang буде плюсом;
• досвід роботи з Git і Gitflow;
• знання англійської мови на рівні Intermediate і вище;
• бажання вчитися.

Як потрапити:зареєструватися, пройти тестове завдання і тест з англійської мови, співбесіду з куратором школи.

Умови:онлайн-лекції та домашні завдання, лекції від PM та рекрутерів. Спілкування з викладачами та куратором школи буде відбуватися за допомогою месенджерів та відеозв’язку. Після успішного закінчення, студенти зможуть претендувати на позицію Golang developer в Yalantis.

Деталі:Facebook-сторінка, або пишіть на пошту mariia.kuliaka@yalantis.net, телефонуйте 050 20 111 80 або Skype: live:bcd219125209b11f.

Школа програмування Ш++

Напрям:курс Java.
Місто:Кропивницький.
Дедлайн подачі заявок:на постійній основі.

Вимоги до кандидатів:вміти пробігтись по масиву циклом, за допомогою однієї з мов: С++, JavaScript, Java.

Як потрапити:зареєструватися, пройти вступне випробуванняна одній із мов: Java, C++, Javascript.

Умови: Peer-to-peer — це коли ви навчаєтесь без менторів, груп, з офлайн-складовою. Тривалість курсу складає 4 місяці і дає можливість обрати напрямки для більш поглибленого навчання (наприклад, web/mobile development). Заняття проходять двічі на тиждень в м. Кропивницький.

Деталі:пишіть на пошту info@programming.kr.ua, телефонуйте 050 20 111 80 або на сайті.

Andersen

Напрям: JavaScript, .NET, QA.
Місто:Київ, Одеса, Харків, Чернігів, Черкаси.

Вимоги до кандидатів:

• впевнені теоретичні знання за вибраним напрямком;
• наявність навчальних проектів;
• знання англійської мови на рівні Intermediate.

Як потрапити:заповнити анкету на сайті.

Умови:термін навчання — 2 місяці, повний день на базі офісу, викладає індивідуальний ментор. Для стажування QA є оплата.

Деталі:пишіть на пошту d.krepkina@andersenlab.com.

BAKOTECH

Напрям:кібербезпека.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти та випускники технічних спеціальностей;
• знання серверної частини Windows (MS AD, DNS, DHCP);
• знання архітектури мережі (модель OSI, VPN, VLAN, та ін.);
• навички використання середовища віртуалізації: VMware та / або Hyper-V;
• розмовний рівень англійської мови.

Як потрапити:надіслати резюме з поміткою «Стажування з DOU» на пошту Tatiana.Kiselevich@bakotech.com, пройти співбесіду в офісі, виконати тестове завдання.

Умови:програма розрахована на 3 місяці з можливістю подальшого працевлаштування. Стажування проходить в офісі, 5 днів на тиждень, з 9 до 18 години. Програма включає практичні завдання під керівництвом спеціалістів відділу. Стажування передбачає помісячну оплату.

Деталі:написати на Tatiana.Kiselevich@bakotech.com, 063-117-84-78.

Clockwise Software

Напрям: JavaScript (React, Angular, Vue), NodeJS; Sales/Lead Generation.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

Sales/Lead Generation: англійська — upper intermediate.

JavaScript (React, Angular, Vue), NodeJS:

• базові знання алгоритмів;
• профільна вища освіта/курси;
• рівень англійської — intermediate.

Як потрапити:надіслати заявку на jobs@clockwise.software, або на сайті, зробити тестове завдання, пройти співбесіду.

Умови:індивідуальна форма інтернатури.

Деталі:пишіть на jobs@clockwise.software, або на сайті.

DB Best

Напрям:стажування .NET.
Місто:Харків.

Вимоги до кандидатів:

• знання .NET и C#;;
• розуміння базових принципів ООП — інкапсуляція, наслідування і агрегація, поліморфізм, обов’язково з прикладами;
• структури даних — списки, словники, бінарні дерева;
• базове розуміння HTTP-протоколу та Web у цілому;
• базові алгоритми — пошук, сортування та інше;
• знання англійської від Pre-intermediate+;
• будуть плюсом базові знання наступних технологій: ASP.NET MVC API, Angular JS, Entity Framework, MS SQL.

Як потрапити:подати заявку на hr-ukraine@dbbest.comабо на сайті.

Умови: 5 днів на тиждень, 4 години в день. Працевлаштування за умови успішного проходження стажування.

Деталі:пишіть на hr-ukraine@dbbest.comабо на сайті.

DIGIS

Напрям:стажування React Native.
Місто:Одеса.

Вимоги до кандидатів:

• студент 1-4 курсу;
• власні пет-проекти;
• англійская мова від рівня Intermediate;
• знання основ JavaScript.

Як потрапити:надіслати резюме на rn.internship@digiscorp.com.

Умови:викладач— Middle JS developer. Тривалість — 3 місяці. Оплати немає. Після успішного проходження — працевлаштування.

Деталі:пишіть на hr@do-it.co.

groupBWT

Напрям:стажування PHP, Python.
Місто:Запоріжжя.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• студенти 3-5курсів та випускники технічних спеціальностей;
• базові теоретичні знання програмування;
• готовність навчатися інтенсивно.

Як потрапити:надіслати резюме на сайті, пройти телефонне інтерв’ю, виконати тестове завдання, пройти співбесіду в офісі.

Умови:програма розрахована на 3 місяці с можливістю подальшого працевлаштування. Стажування проходить в офісі 40 годин на тиждень. Можливий індивідуальний графік для поєднання з навчанням у виші. У разі успішного виконання практичних завдань кандидат отримуватиме стипендію. Це не навчання, а стажування, тому теорію, якої не вистачатиме, необхідно буде освоювати самостійно. На стажуванні основний акцент робиться на PHP, Laravel, Python, методи збору і обробки даних (парсери). Крім того, кандидат навчиться працювати в команді, користуватися інструментами розробки та системами ведення проектів, ефективно використовувати свій робочий час.

Деталі:на сайті.

HYS Enterprise

Напрям:стажування .NET, QA.
Місто:Одеса.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

.NET:

• поглиблене розуміння об’єктно-орієнтованого програмування (ООП);
• високі знання HTML / CSS (Bootstrap) / JavaScript;
• знання та досвід роботи з C #, .NET (ASP.NET MVC, WebAPI, EntityFramework);
• SQL;
• знання Back-end and Front-end;
• вільна англійська.

QA:

• хороші теоретичні знання теорії якості;
• відмінне розуміння QA-процесів та методів тестування;
• аналіз вимог;
• створення та оновлення тестової документації;
• розуміння web, desktop, mobile apps, тестуванні API;
• аналітичний розум і здатність до вирішення проблем;
• знання програмного забезпечення для управління конфігурацією (систем відстеження помилок, сервери збірки);
• вільна англійська.

Як потрапити:надіслати резюме з поміткою «Стажування з DOU» на hr@hys-enterprise.com, пройти співбесіду (HR, технічну та фінальну англіською мовою).

Умови:стажування триває 2-3 місяці.За умови його успішного завершення, кандидат отримує статус джуніора в компанії.

Деталі:пишіть на пошту hr@hys-enterprise.com.

IdeaSoft.io

Напрям:стажування Sales.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

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

Як потрапити:подати заявку на пошту julia.s@ideasoft.io.

Умови:тривалість — 2 місяці, 6-годиннийробочий день. Початок — коли буде набрана група. Під час стажування буде навчання і підтримка від команди. Після закінчення можливе працевлаштування.

Деталі: Skype: julia.syzonenko.

JustAnswer

Напрям:стажування .NET.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• комерційний досвід роботи з різними технологіями від 1-гороку;
• рівень англійської Intermediate+;
• здатність швидко навчатись.

Як потрапити:надіслати резюме на пошту lesia.kogut@justanswer.comз темою «Bootcamp», пройти відбіркове інтерв’ю та технічну співбесіду в офісі.

Умови:оплачуване стажування тривалістю 3 місяці, повний робочий день. Можливе працевлаштування в компанії.

Деталі:пишіть на lesia.kogut@justanswer.com.

Leobit

Напрям:стажування .NET, Ruby.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти 4-5-го курсів або випускники за 2 останні роки (технічні спеціальності вищих навчальних закладів);
• теоретичні знання відповідно до обраного напрямку;
• хороші аналітичні навички;
• рівень англійської — Intermediate+.

Як потрапити:надіслати резюме на cv@leobit.comабо заповнити реєстраційну форму на сайті.

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

Деталі:пишіть на пошту cv@leobit.com.

MacPaw

Напрям:стажування macOS/iOS, Front-end, Back-end, QA, PR, Affiliate Marketing, Copywriting, Design.
Місто:Київ.
Дедлайн подачі заявок:до 24 травня.

Вимоги до кандидатів:

• стажерам має бути хоча б 18 років;
• необов’язково бути студентом.

Як потрапити:Виконати тестове завдання та відправити заявку на сайті.

Умови: cтажери працюватимуть 30 годин на тиждень та отримуватимуть стипендію впродовж усіх 2 місяців стажування (30 червня — 28 серпня).

Деталі:на сайтіабо пишіть на internship@macpaw.com.

Make IT in Ukraine

Напрям:стажування Project management, Growth, Product, Business Development.
Місто: remote.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

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

Як потрапити:надіслати резюме/LinkedIn або відео про себе 1-2 хвилини,портфоліо проектів (якщо є), найбільше досягнення, чому хочеш працювати з нами на max@makeitinua.comабо в Telegram @laconeat.

Умови:допомагати команді в роботі над продуктом, дослідженнями, залученням талантів на платформу, клієнтським сервісом та запуском нових напрямків. Орієнтовний початок стажування — 4 травня, тривалість — 3 місяці, оплата — від 5 000 грн/міс. за результатом співбесіди.

Деталі:пишіть на max@makeitinua.comабо в Telegram @laconeat.

OpenGeeksLab

Напрям:стажування Full-stack (React.js + Node.js + TypeScript).
Місто:Запоріжжя.
Дедлайн подачі заявок:реєстрація відбувається постійно, групи стартують 2 і 16 березня

Вимоги до кандидатів:базовий досвід роботи з Git, MongoDB, Mongoose ODM, JavaScript, TypeScript, Node.js, Nest.js, верстці (HTML CSS), React.js, Redux.

Як потрапити:заповнити форму на сайтіі пройти співбесіду.

Умови:термін навчання — 2 місяці, full-time на базі офісу (з понеділка по п’ятницю з 9.00 до 18.00). Дати старту — 2 березня (перша група) і 16 березня (друга група). Програма включає практичні завдання під керівництвом досвідчених менторів за структурованою програмою. Найкращим інтернам після закінчення навчання пропонують подальше працевлаштування.

Деталі:на сайтіабо пишіть на пошту hr@opengeekslab.com.

Quality Assurance Group

Напрям:стажування / виробнича практика QA.
Місто:Львів.
Дедлайн подачі заявок:немає.
Вимоги до кандидатів:курс можуть проходити усі охочі.

Як потрапити:подати заявку, заповнивши анкету, або телефонуйте (099) 376 65 05; (098) 903 64 45.

Умови:практика з реальними проектами у групах під керівництвом координатора. Робота з баг-трекінговою системою Jira; Zephyr test management tool, Test Rail, Jmeter etc.

Деталі:на сайті.

Sigma Software University

Тип:стажування JS.
Місто:Львів.
Дедлайн:до 12 травня.

Вимоги до кандидатів:

• принаймні ступінь бакалавра (бажано, з інформатики, інформаційних технологій, графічного дизайну чи суміжних дисциплін);
• хороші знання в JS;
• знання щонайменше однієї рамки/бібліотеки ІС СВ;
• розуміння основ Git;
• основне розуміння процесів роботи в ОС;
• розуміння OOP/OOD та шаблонів дизайну;
• основні знання щодо реляційних концепцій БД та SQL;
• принаймні Pre-Intermediate англійської мови;
• добре розуміння систем на базі Windows та Linux.

Як потрапити:заповнити реєстраційну форму на сайтіта додати резюме.

Умови:тривалість стажування від 3 до 6 місяців; повний робочий день.

Деталі:на сайті.

Sparkybit

Тип:стажування Salesforce.
Місто:Дніпро.

Вимоги до кандидатів:

• від 1 року досвіду роботи Back-end розробником (в ідеалі на Java, C #, C ++);
• розуміння і досвід роботи з системами контролю версій (Git);
• English: intermediate.

Як потрапити:написати на wehire@sparkybit.com.

Умови:навчання з подальшим влаштуванням на роботу. Навчання проходить 2-3місяці в офісі. Міжнародна сертифікація (оплачується компанією).

Деталі:на сайті.

SvitSoft

Тип:стажування PPC.
Місто:Київ.

Вимоги до кандидатів:

• вища освіта;
• бажання працювати з системами контекстної реклами.

Як потрапити:написати на vitalia.k@svitsoft.com.

Умови:два тижні безкоштовного навчання. Працевлаштування за умови успішного проходження стажування.

Деталі:пишіть на vitalia.k@svitsoft.com.

TeamDev

Напрям:стажування Java і С++.
Місто:Харків.

Вимоги до кандидатів:

Java:

• англійська рівня Intermediate;
• досвід програмування, крім курсових/дипломів;
• профільна технiчна незакінчена/закінчена вища освіта;
• знання основ математики;
• розуміння основних принципів ООП;
• базові знання Java.

C++:

• впевнені знання основ C++;
• досвід самостійного програмування, крім курсових / дипломів;
• англійська не нижче рівня Intermediate;
• знання основ математики;
• розуміння основних принципів ООП;
• досвід використання популярних інтегрованих середовищ розробки;
• досвід роботи в ОС Linux.

Як потрапити:заповнити реєстраційну форму, пройти співбесіду, виконати тестове завдання.

Умови:три-чотири мiсяцi, фултайм в офісі. Є можливість поєднувати з навчанням. Виконана протягом програми робота буде оплачена. Кращі студенти будуть запрошені у команду TeamDev.

Деталі:на сайтіабо пишіть на пошту booster@teamdev.com.

Weblium

Напрям:стажування HR, Marketing, Design.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти 1-5курсiв або випускники;
• теоретичні знання відповідно до обраного напрямку;
• для Marketing — рівень англійської — Upper-Intermediate+.

Як потрапити:відправити резюме на hr@weblium.com.

Умови:тривалiсть — 4 тижні, 20 годин в тиждень, гнучкий графiк. Видається сертифiкат. English Speaking Club, безкоштовне харчування. Можливе подальше працевлаштування в компанії.

Деталі:пишіть на на сайті.

WEB4PRO

Напрям:стажування PHP (Magento 2).
Місто:Харків.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• досвід роботи з PHP та MySQL;
• розуміння OOP;
• базові знання JS.

Як потрапити:відправити резюме на hr@corp.web4pro.com.ua, пройти тестування та співбесіду в офісі.

Умови:тривалість — 3 місяці. Стажування в офісі 8 годин на день 5 днів на тиждень. Є стипендія та ментор. Можливість працевлаштування в компанії.

Деталі:hr@corp.web4pro.com.ua.

White Label Agency

Напрям:стажування WordPress.
Місто:Полтава.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• студенти останнього курсу та випускники;
• базове розуміння CMS WordPress, PHP;
• знання HTML & CSS;
• досвід програмування.

Як потрапити:заповнити форму на сайтіабо відправити резюме на hr@thewhitelabelagency.com, пройти співбесіду та виконати тестове завдання.

Умови:викладачі інтернатури — Tech leads та Senior Developers компанії. Тривалість програми — від 1 до 2 місяців залежно від рівня кандидата. 5 днів на тиждень, 8 годин на день. Стажування оплачується щомісячно. Програма включає практичні завдання, розробку тесових проектів під керівництвом кураторів та лекції. За умови успішного проходження курсу є можливість працевлаштуватися на позицію Junior.

Деталі:на сайті.

WiserBrand

Напрям:стажування Customer Support.
Місто:Харків.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:володіння англійською на рівні Upper та вище.

Як потрапити:заповнити форму на сайті.

Умови:тривалість стажування 3 місяці, що оплачуються компанією. Є можливість подальшого працевлаштування в компанії.

Деталі:на сайтіабо пишіть на пошту alexa.a@wiserbrand.com, @Aleksa_Andr — telegram.

Expercast

Напрям:робота JavaScript, Ruby.
Місто: remote.

Вимоги до кандидатів:

• навички problem-solving;
• знання алгоритмів;
• знання англійської мови на рівні Upper-intermediate;
• можливість працювати віддалено;
• для JavaScript: базовий досвід програмування з JavaScript;
• для Ruby: знання Ruby (2.7) та Rails (5.2).

Як потрапити:відгукнутись на вакансію JSчи Ruby, або надіслати резюме на пошту hiring@expercast.com.

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

Деталі:на сайтіабо пишіть на пошту hiring@expercast.com.

MaybeWorks

Напрям:робота JavaScript.
Місто:Харків.
Дедлайн:до 28 травня.

Вимоги до кандидатів:

• розуміння та застосування принципів ООП у розробці;
• знання базових патернів і архітектури;
• досвід використання одного з фреймворків Front-end: Angular/React/Vue;
• вміння написати Back-end на Node.js;
• робота з БД на рівні SQL-запитів.

Як потрапити:подати резюме на сайтіз позначкою «Робота DOU», пройти онлайн-інтерв’ю

Умови:виконати тестове завдання. У разі успішного результату — працевлаштування (оплата з першого дня).

Деталі:на сайтіабо пишіть на пошту hr@maybeworks.com.

NIX

Напрям:робота.
Місто:Харків.

Вимоги до кандидатів:

• Hippo CMS;
• AQA;
• BA / Product Owner;
• Android;
• Java Full Stack;
• Scala;
• Tech Support;
• QA.

Як потрапити:надіслати резюме на сайті, пройти тестування та співбесіди.

Умови:повна зайнятість.

Деталі:на сайті.

Plarium

Напрям: Player Support Agent.
Місто:Львів.

Вимоги до кандидатів:

• знання англійської від Upper-Intermediate;
• любов до ігор.

Як потрапити:надіслати резюме на rocknrolla@plarium.com, виконати тестове завдання, пройти HR та технічну бесіду.

Умови:офіційне працевлаштування, фіксований п’ятиденний робочий графік.

Деталі:на сайті. Відправляти CV на email: rocknrolla@plarium.com.

Scalarr

Напрям: Data Analyst.
Місто:Харків.

Вимоги до кандидатів:

• досвід в бізнес-аналізі та аналізі даних;
• відмінні знання Excel;
• знання основ математики;
• знання основ SQL;
• вмотивованість.

Як потрапити:надіслати CV на hr@scalarr.io, або на сайті.

Умови:працевлаштування на увесь час.

Деталі:на сайтіабо пишіть @notyourmom (Telegram).

Solid Software

Напрям: Flutter Developer (Android, iOS).
Місто:Харків, Львів.

Вимоги до кандидатів:

• бажання працювати з новітніми та сучасними технологіями;
• розуміння принципів програмування OOP та SOLID;
• знання Git;
• володіння англійською мовою на середньому рівні та вище;
• здатність швидко навчатись та використовувати знання на практиці;
• здатність мислити аналітично та вирішувати технічні проблеми;
• бажана профільна вища освіта;
• буде плюсом: досвід з розробки додатків для Android, iOS або Flutter.

Як потрапити:надіслати резюме на сайті.

Умови:8-годиннийробочий день, гнучкий графік.

Деталі:на сайті. Відправляти CV на email: yana.mandziuk@solid.software. Телефон для зв’язку: +380508843646.

Ubisoft

Напрям:робота Game Tester.
Місто:Одеса, Київ.

Вимоги до кандидатів:

• базові знання ігрового тестування / процедури звітності про помилки / життєвий цикл помилки;
• ігровий досвід, знання ігрової термінології;
• базові знання комп’ютерних і консольних ігор;
• знання Microsoft Office (Word, Excel, Outlook);
• середній рівень англійської, як письмової, так і усної;
• уважність до деталей;
• здатність працювати в команді.

Як потрапити:надіслати резюме на сайті для Києвачи Одеси.

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

Деталі:Київ, Одеса, або пишіть на пошту hr_kiev@ubisoft.com.

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

Редакція DOU звернулась до тих, хто мав або має досвід роботи з трекером (як під час карантину, так і до). На умовах анонімності ІТ-фахівці поділились власними історіями та розповіли, як ставляться до контролю.

Трекер радше дресирує девелопера, як мавпу, замiсть того, щоб контролювати результати роботи

Ігор, Java Developer

Моя працездатність не зросла від використання трекера

Михайло, Manual QA

Контроль має бути в міру

Олеся, менеджерка

Трекінг заради трекінгу — не потрібен

Аслан, Front-End Developer

Для мене важливо, щоб ефективність вимірювалась не трекером

Дмитро, Back-end developer

Я не знав про цей трекер, у корпоративній розсилці інформації про нього не було, а ноутбук мені видали із вбудованим софтом і готовими налаштуваннями

Павло, розробник

На работе нужно работать

Виталий, Web developer

Ілюстрації Уляни Патоки.

Бывшие сотрудники The Ad Mastersв своих комментариях на различных интернет-ресурсах обвиняют основателя компании Ларби Амирушав невыплате вознаграждения за работу, угрозах и разглашении персональных данных. Сам господин Амируш в письмах к DOU говорит, что якобы стал жертвой кампании по дискредитации, и грозит подать в суд.

Редакция DOU поговорила с бывшими сотрудниками The Ad Masters и узнала, чем занималась компания и почему люди оттуда массово ушли. Мы узнали, что CEO Ларби Амируш продолжает преследовать бывших сотрудников, а на IT-рынке он уже представляет новую компанию Ironbelly Tech. Кроме этого нам удалось выяснить, что человек с таким же именем — Larby Amirouche — неоднократно обвинялся в мошенничестве прокуратурой в США.

Несуществующие таблетки по подписке

Девелопер Павел Бохан проработал в компании около четырех месяцев. «Сделал тестовое задание, потом прошел тест на IQ — это было обязательное условие для всех сотрудников. Официально трудоустройство оформлено не было — подписывался контракт в электронном виде на английском языке», — рассказывает Павел. Офис компании находился в Киеве на Печерске, в БЦ «Волна». Из бонусов — только бесплатные обеды, которые, по словам Павла, закончились через месяц.

«The Ad Masters разрабатывает передовое программное обеспечение для онлайн-продаж и маркетинга, предназначенное для предпринимателей и владельцев бизнеса, которые хотят продавать свои услуги и продукты в Интернете», — говорится на сайте компании. На деле же, по словам бывших сотрудников, это была разработка веб-сайта по продаже таблеток для похудения в США.

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

Чтобы банки не отследили схему, делались так называемые сайты-«прокладки». Об этом на стало известно от одного из бывших сотрудников The Ad Masters. Он поделился с нами списком таких сайтов за одну неделю работы в компании.

Богдан Чайка проработал на The Ad Masters примерно полгода с августа 2019-го.Как и Павел, он прошел стандартный тест на IQ, сделал тестовое задание и подписал договор в электронном виде на английском языке. «Работал я девелопером, а еще периодически рекрутером и кладовщиком», — смеется Богдан. Он рассказывает, что текучка кадров была постоянным явлением, причем несколько раз люди увольнялись сами всем отделом.

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

«Коллектив был дружный, как потом оказалось, это был единственный плюс этой работы. Однажды Ларби меня уволил, а через три минуты передумал. Это был рекорд. Других людей он мог похвалить в три часа дня, а в шесть вечера уволить без объяснений», — вспоминает Павел. Он также рассказывает, что часто приходилось засиживаться на работе допоздна и работать в выходные без дополнительной оплаты, а отпуск не давали совсем, даже за свой счет. «Ушел я в результате сам, последней каплей стало то, что многим коллегам не выплатили зарплату после увольнения», — рассказывает Бохан.

Работа без выходных и невыплата вознаграждения за работу

Диджитал маркетинг-компания The Ad Masters опубликовала на DOU 77 вакансий с марта 2019-гопо февраль 2020 года. Больше половины вакансий с минимальными требованиями к опыту («без опыта» или < 1 года). С опытом более 5 лет у компании было лишь две вакансии на DOU — HR Director и Regional General Legal Counsel.

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

«Мы всем отделом уволились сами, ибо поняли, что нет смысла здесь оставаться и тратить свое время. Расстались с компанией далеко не радужно — нам отказались выплачивать зп под предлогом: „Вы работали неэффективно“. И, как выяснилось, всем людям, которых они увольняли сами, точно так же не выплачивали зп, по той же причине», — пишет в своем комментарии на DOU IT-рекрутер Валерия Борс.

«Я проработал в этой компании аж 14 дней на позиции project менеджера HR-отдела) На протяжении всего этого времени мне говорили, что я хорошо справляюсь. Утром 14-годня мы с СЕО обсуждали мои KPI на следующий месяц. Кроме того, он предложил повышение и увеличение зп. Но уже вечером коллега из HR-отдела, сам ничего не понимая, позвонил мне и сказал, что его просили передать, что я уволен и вообще уже с завтрашнего дня могу не выходить на работу. И случилось это, конечно же, аккурат перед днем выплаты зп», — пишет на DOUНикита Мельников.

Мы пообщались еще с шестью бывшими подчиненными Ларби Амируша. Все они, по их словам, работали на The Ad Masters в разных должностях с лета 2019 года до февраля 2020 года. Согласился говорить под своим именем только бывший начальник HR отдела Ярослав Бокий. Остальные опасаются мести бывшего начальника. Бокий подсчитал, что господин Амируш не заплатил за работу как минимум 8 сотрудникам из его команды. «Проработал я 16 дней, и за это время у меня был всего один выходной. Однажды Ларби сказал уволить моего подчиненного Никиту Мельникова без указания причины. Причем за день до этого Ларби сам поднял ему зарплату. Когда мне сказали уволить еще двоих, я понял, что им, скорее всего, тоже не выплатят зарплату. Я собрал свой отдел, все им рассказал и сказал, что ухожу. Все решили уходить тоже. Это было 12 числа. А на следующий день нам не выплатили зарплату», — рассказывает Бокий. Он говорит, что коллеги написали соответствующее заявление в полицию.

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

«Как только на DOU появлялся негативный отзыв, Ларби сразу заставлял кого-то из офиса писать позитивный. Однажды заставил и меня, потом я этот отзыв удалил и написал правдивый», — рассказывает Павел Бохан.

Номера родителей и копии паспортов в ФСБ России

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

«Позвонил человек, представился юристом Амируша. Сказал, что у меня есть 12 часов, чтобы удалить комментарий на DOU. Иначе они поднимут контакты моих родителей, а на меня подадут в суд. Я сказал, что не против судиться», — говорит Богдан Чайка. Он переслал в DOU электронные письма от бывшего начальника с угрозами и переписку с ним в Telegram, в которой Амируш угрожает ему «проблемами».

Основатель The Ad Masters неоднократно писал DOU с требованием удалить комментарии, «очерняющие» его репутацию, а также с жалобами на своих бывших сотрудников:

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

У нас в распоряжении есть электронные письма, отправленные с адреса larby@theadmasters.comна электронную почту ФСБ Российской Федерации. В них автор не просто обвиняет Богдана Чайку и Павла Бохана в хакерстве, разрушении его бизнеса и даже работе на нефтяную промышленность Саудовской Аравии, а даже прикрепляет копии их паспортов!

Дела о мошенничестве и суды в США

DOU выяснило, что в 2009 году на человека с таким же именем, как у CEO The Ad Masters — Larby Amirouche, подавала в суды генеральная прокуратура штата Иллинойс и штата Аризона. Информация об этом размещена на официальном сайте генеральной прокуратуры штата Иллинойс.

В обоих случаях бизнесмена обвиняли в интернет-мошенничестве с продажей популярных в то время ягод асаи. Схема очень похожая на ту, которую описывают бывшие подчиненные Ларби Амируша, CEO The Ad Masters. Прокуратура утверждала, что господин Амируш вводил потребителей в заблуждение, предлагая бесплатную первую посылку, а затем списывал деньги с кредитных карт. «Процесс отказа от помесячной оплаты был очень затруднен», — говорится в официальном пресс-релизе прокуратуры штата Иллинойс.

Компания тезки Ларби Амируша также оказалась среди пятидесяти фирм, на которые в 2009 году подала в суд знаменитая американская телеведущая Опра Уинфри. Она обвиняла эти фирмы в незаконном использовании ее имени в рекламе ягод асаи. DOU пока не удалось выяснить, чем закончилось судебное разбирательство в Иллинойсе, но известно, что в аналогичном судебном деле в Аризоне господин Амируш вместе с другим участником процесса согласился заплатить штраф в размере $175 000. Об этом, в частности, писали газеты Courthouse News Serviceи Legal Newsline.

Новая вывеска во Львове

Совсем недавно при поиске «The Ad Masters» Google на первой же странице выдавал ссылку на вакансии некой компании Digital Wizards. Очевидно, что владелец меняет название компании на Work.ua, оставляя при этом страницу прежней. Но, в отличии от The Ad Masters, находится она не в Киеве, а во Львове.

Сейчас вакансии этой компании удалены с Work.ua. Но на смену Digital Wizards пришла новая компания — Ironbelly Tech. Владелец и тут просто сменил название.

А вот описания деятельности компаний авторы решили не менять вовсе. Меняем Ironbelly на The Ad Masters — и получаем полностью идентичный текст на сайтах обеих компаний: «Ironbelly Tech develops online sales and marketing software designed for entrepreneurs and business owners who want to market their services and products online. Ironbelly Tech technology solutions empower businesses to spread their message and products to change lives».

По состоянию на 27 апреля 2020 года на Work.ua эта компания также недоступна. Но у нее было 17 активных вакансий, Ironbelly Tech активно искала сотрудников во Львове — от девелоперов, юриста и бухгалтера до частных сыщиков в Киеве и Сумах, а еще личного повара и мануального терапевта.

Интересно, что на DOU на Ironbelly Tech было оставлено три негативных отзыва о Ларби Амируше. Два из них DOU удалило по просьбе авторов, которые, возможно, испугались угроз бывшего директора. Кстати, письма с угрозами рассылались им от имени Ларби Амируша с корпоративной почты домена ironbelly.com.

«Если он (Ларби Амируш, — ред.)думает, что может переехать в другой город, сменить вывеску — и все сойдет ему с рук, то он ошибается!» — говорит Павел Бохан. Его бывший коллега Богдан Чайка добавляет: «Я хотел предупредить об этом человеке всех в нашей отрасли. Никому не пожелал бы пережить то, что пережил за время работы в The Ad Masters я!».

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

Мы благодарим журналиста Светлану Тучинскую за помощь в подготовке материала.

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

Зачем все-таки нужны вопросы

По моему скромному мнению, менеджер задает вопросы, чтобы:

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

Теперь давайте разберемся, какие вопросы для этого подходят, а какие — нет. Это легко, так как по сути есть всего один плохой вопрос — «Почему?».

Почему же «почему» плохой вопрос

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

Например:

• Почему дедлайн снова сдвигается?
• Почему проблема до сих пор не решена?
• Зачем ты убил базу на проде?

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

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

Часто не имеет смысла.Если что-то плохое уже произошло, само по себе выяснение причин сбоя точно ничего не изменит.

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

Стоит ли задавать закрытые вопросы

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

• Ты можешь сделать эту задачу за 2 часа?
• Ты можешь выйти в субботу, чтобы сделать задачу быстрее?
• Этот кривой код — твой?

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

• Согласна ли команда с содержанием этого спринта? (Хороший вопрос после совместного планирования.)
• Раз уж мы обсудили все вопросы, давайте начинать работать?
• Все согласны со сдвигом сроков на две недели? (После того, как обсудили все варианты и ничего другого не остается.)

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

10 признаков правильных вопросов

1. Открытые, но не начинаются с «почему». Например:
   
   • Как мы можем решить эту задачу?
   • Какой план мы сможем предоставить клиенту?
   • Каких экспертов мы могли бы привлечь?
2. Помогают сфокусироваться на проблеме при помощи слов и фраз «ещё», «действительно», «что еще», «как именно». Например:
   
   • Что еще / какое еще решение можно предложить?
   • Действительно ли это та проблема, которую мы решаем?
   • Как именно ты хочешь это сделать?
3. Ориентированы на конструктив, результат и решение проблемы. Например:
   
   • Давай посмотрим, что приведет нас к эффективному и быстрому решению проблемы?
   • Как ты считаешь, что поможет быстрее достичь результата?
4. Направлены на интерес отвечающего.
   Допустим, менеджер проекта говорит с синьор-разработчиком. Что-то в системе не работает, и эту проблему нужно решить быстро и качественно. Здесь отлично подойдет вопрос: «Что мы как компания можем сделать, чтобы тебе помочь?» Разработчику поддержать такой диалог будет гораздо интереснее, чем пытаться ответить на запрос, который звучит так: «Что у вас там случилось? У нас тут пол фирмы в запаре. Если ты не решишь задачу, мы тебя уволим». Или даже так: «Решение этой проблемы поможет нашей бухгалтерии лучше справляться с работой». Запрос, направленный на интерес собеседника, всегда будет более эффективным, чем тот, связи с которым он не чувствует.
5. Помогают увидеть новые возможности. Важно, чтобы вопросы были направлены в будущее, а не в прошлое. Например:
   
   • Какие способы решения этой задачи ты мог бы предложить?
   • Что еще мы могли бы предпринять в этой ситуации?
   • Что можно сделать, чтобы подобных ситуаций не возникало?
6. Помогают активизировать творческие способности и изобретательность. Например, проджект-менеджер в ответ на запрос получает банальное решение, которое не работает или работает плохо. Дальше можно либо принять этот ответ, либо спросить:
   
   • Давайте представим, что эта проблема уже решена. Как вы думаете, какими способами мы этого достигли?
   • Чтобы ты посоветовал своему другу, у которого была бы точно такая же проблема?
7. Поддерживают и мотивируют. Например:
   
   • Это очень неплохое решение. Возможно, у тебя есть еще что-нибудь интересное?
   • То, что ты предложил, выглядит отлично, что нужно тебе и команде для решения этой проблемы?
8. Обращаются к эмоциям. Например:
   
   • Как должна выглядеть архитектура системы, чтобы ты и команда были счастливы?
   • Как переход на новую позицию будет влиять на твои жизненные планы?
9. Направлены на диалог. Не стоит задавать риторические вопросы или превращать их в длинные монологи. Например:
   
   • Это сложная проблема, когда лучше всего вернуться к ее обсуждению?
   • Какие риски ты видишь в связи с...?
10. На них нельзя ответить «да» / «нет» / «может быть». Например:
    
    • Как я могу помочь? Но не: Могу ли я помочь?

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

Кейс 1

Ваш тимлид только что при вас случайно убил базу данных на продакшене. Ваш первый вопрос? «Почему?» или «Какого черта?».

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

1. Насколько всё серьезно? — Вопрос направлен на анализ ситуации.
2. Что будем делать? — Вопрос направлен в будущее и никого ни в чем не обвиняет.
3. Что еще можно сделать? — Этот вопрос, как и два следующих, направлены на поиск решения проблемы.
4. Кого позовем на помощь?
5. Какие ресурсы вам необходимы?
6. Чем еще я могу помочь? — Подчеркивает ваше участие и готовность поддержать коллегу.
7. В какие сроки мы можем уложиться? — Уточняет детали и определяет дедлайн решения проблемы.

Кейс 2

Вы долго наблюдали на вашим лучшим Senior Java-разработчиком и после успешного завершения проекта предложили ему стать тимлидом проекта. Он отказался! Ваш первый вопрос? Снова «Почему»? На него могу ответить и я.

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

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

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

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

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

Какие вопросы подошли бы в этом случае:

1. Как бы ты хотел развивать свою карьеру? — Всегда очень хороший первый вопрос в разговоре о повышении.
2. Какая работа делает тебя счастливым? — Вопрос направлен на эмоции.
3. Как ты думаешь, что помогло тебе так хорошо делать свою работу? — Вопрос подводит человека к собственным сильным сторонам и помогает понять, в какую сторону он хотел бы развиваться дальше.
4. Какая роль в ближайшем будущем была бы для тебя комфортной? — Вопрос направлен на будущее и помогает задуматься о развитии.
5. Что должно измениться, чтобы ты захотел стать тимлидом? — Вопрос показывает, что компания ценит сотрудника и готова пойти навстречу.
6. Чем компания может помочь тебе в развитии твоей карьеры? — Например, человек может чувствовать, что ему недостает конкретных навыков (возможно, он прав, а может, просто себя недооценивает). Задав вместо этого вопрос «Почему ты не хочешь повышения?», вы только заставите человека признать у себя отсутствие нужных скиллов и усилите защитную реакцию. Предложив помощь и поддержку в развитии, вы можете прийти к решению, которое окажется оптимальным для обеих сторон.

Кейс 3

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

Хорошими вопросами в этом случае будут:

1. Что мы можем сделать, чтобы успеть вовремя / ускорить процесс?
2. Какие ресурсы нам нужны, чтобы успеть в срок?
3. Кого мы можем привлечь на помощь команде?

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

Как правильно задавать вопросы

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

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

Правильно: Внимательно выслушать коллег, возможно, что-то подобное предложит команда. Если не предложат — два раза подумать. Возможно, ваше решение не такое уж и гениальное?
Неправильно: «Давайте возьмем за основу вот такое решение...»

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

Правильно: Сфокусироваться на решении проблемы.
Неправильно: «Давайте искать автора коммита, который положил прод».

Не осуждайте и не критикуйте.К сожалению, восточноевропейской культуре часто свойственно общение в осуждающей манере: «Так поступать нельзя!», «Как ты умудрился такое сделать?». Но острая реакция на ошибку заставляет того, кто ее совершил, закрыться и не помогает решению проблемы. Постарайтесь избегать осуждения и негативной оценки.

Правильно: «Что мы можем сделать, чтобы исправить ошибку?»
Неправильно: «У нас такие ошибки даже джуны не делают».

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

Классический кейс. Менеджер устраивает коллегам one-to-one и безучастным тоном задает вопросы о планах, профессиональном развитии и тому подобное. Один из коллег обратил на это внимание и спросил: «Зачем ты задаешь эти вопросы?». Менеджер честно признался: «Меня попросили в HR-отделе».

Кстати, сам по себе вопрос «Кем вы себя видите через 5 лет?» — отличный! Он переносит вас в будущее, заставляет подумать, в какую сторону вы хотите расти, пересмотреть планы и так далее. Проблема в том, что за последнее время его испортили, выхолостив суть. Ведь чаще всего задают его на собеседованиях люди, которые знакомы с кандидатом 5 минут и практически ничего о нем знают.

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

В итоге

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

Иллюстрации Ульяны Патоки.

[В рубрике «Как я работаю»мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Сергей Король — Technical QA Manager с более 10 годами опыта в IT, который развивает в себе навыки тестировщика, разработчика, аналитика и менеджера. Сергей — член программного комитета и постоянный спикер крупнейших украинских конференций по обеспечению качества QA Fest и Selenium Camp, а также прошлогодний финалист конкурса Ukrainian IT Awards в номинации Quality Assurance. Автор нескольких open-source библиотекдля тестировщиков, модератор и редактор крупнейшего украинского портала автоматизаторов AT.INFO. Проводит тренинги, занимается консалтингом и обучает молодых специалистов.

Сейчас Сергей отвечает за развитие направления автоматизации, активно участвует в улучшении процессов, проведении аудитов и пресейлов, а также ведет Back-end разработку и «техлидит» один из проектов в компании Waverley Software.

О себе

«Садись рядом, смотри и запоминай. Последний раз переустанавливаю тебе Windows!» — такими были слова моего крестного, который еще в далеком 2000 году третий раз подряд приезжал и переустанавливал ОС. И это спустя месяц после того, как у меня появился ПК. На следующий день меня накрыла пытливость ума, и я сам снес Windows из-под DOS через Volkov Commander, чтобы по горячим следам усвоить новый материал.

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

«Диплом вуза — это лишь дорогое украшение. Самому важному в жизни мы учимся самостоятельно»

Свою первую работу на должности Manual Test Engineer я получил в 2009 году, когда учился на 6-мкурсе магистратуры ХПИ (кафедра «Системный анализ и управление»). Меня собеседовал мой будущий лид, с которым мы вместе учились на одном потоке в университете. Как оказалось, его отчислили после первого курса, он отслужил в армии, а к моменту проведения интервью уже два года работал тестировщиком. Этот человек очень многому меня научил и невольно заставил кардинально переосмыслить некоторые жизненные позиции.

«Самые правильные решения в моей жизни были приняты, когда я стоял на краю пропасти»

Хочешь быть лидом? Хочешь стать начальником QA-департамента? Эти вопросы мне начали задавать на четвертом году работы на позиции Manual TE. С одной стороны, это означало невероятные перспективы. С другой — огромную ответственность.

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

«Каким бы крутым специалистом ты ни был, всегда оставайся человеком»

Переход от Manual Lead TE сразу на автоматизатора высокой должности выглядел довольно авантюрным. Но на тот момент я уже привык к покорению заведомо высоких планок, и мне казалось, что знаний по написанию своих Selenium Frameworksвелосипедов, а также умения настраивать CI/CD должно быть достаточно. А вот и нет...

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

Из этой истории я извлек несколько уроков:

• не стоит указывать в CV того, с чем очень давно не работал;
• автоматизация — это хорошо, но без хорошего знания языка программирования это всего лишь monkey job;
• я должен сделать все возможное, чтобы никто и никогда больше не смог поставить меня в такое положение;
• и главное — нельзя вести себя как г**но, независимо от обстоятельств.

Переход в автоматизацию

«Синдром самозванца — отличный стимул для саморазвития»

Собеседование на Senior TAE я все-таки прошел в одной из контор. Это также открыло мне глаза на то, что Senior Senior’у рознь. У каждой компании свои требования и ожидания. Тем не менее, недавний провал еще долго меня преследовал и заставлял сомневаться в себе и своих решениях. Но, с другой стороны, такой пинок стал мощным мотиватором, чтобы глубоко погрузиться в изучение языков программирования, а также разобраться во внутренней специфике работы всех необходимых мне инструментов автоматизации. Со временем это дало свои плоды: и на карьерном уровне (в виде позиции лида), и на социальном (в форме постоянных выступлений на конференциях).

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

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

Спустя полгода мои привычки задавать много вопросов, системно мыслить, докапываться до любых мелочей, увлеченность абсолютно всем происходящем на проекте (Front-end, Back-end, инфраструктура, бизнес-анализ и тому подобное) привели к тому, что наш Solution Architect предложил мою кандидатуру на роль техлида — в дополнение к Back-end разработке.

Роль и обязанности

Если провести декомпозицию моего тайтла в Waverley — Technical QA Manager, вышло бы приблизительно следующее:

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

QA — аббревиатура, которую я бы не использовал в привычном всем виде, так как один человек ну никак не сможет обеспечить качество всего продукта. Это ответственность всей команды. Поэтому я бы расшифровывал QA как Quality Auditor на уровне проектов всей компании. Меня подключают как на узконаправленные аудиты, так и на полномасштабные Architecture Review.

Manager — сюда можно отнести развитие экспертизы по Test Automation и на уровне компании (процессы, инструменты и best practices), и индивидуально (менторинг, тренинги, цели и тому подобное).

В процентном соотношении выходит приблизительно 80% проектных активностей (development, tech leading) к 20% задач масштаба компании (presale, processes’ improvements, competence evolution, audits).

Тем не менее, именно последние представляют наибольший интерес. Если говорить о presale, к нам в компанию довольно часто заходят весьма амбициозные стартапы, требующие R&D. Погружение в бизнес-анализ, участие в построении Initial Architecture и Proposal — это бесценный опыт.

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

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

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

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

Типичный рабочий день

У меня есть несколько сверхпродуктивных фаз: 9:00-12:00,17:00-19:00и 22:00+. В эти периоды я могу выдавать максимальную производительность. Как я к этому пришел? Достаточно было понаблюдать за своим организмом и биоритмами. Но бывают и исключения, когда мысль вообще не идет — и надо срочно переключиться на другие активности. Или, наоборот, мысли могут полететь так, что их невозможно остановить. Тогда только чувство голода может преодолеть жажду созидать :)

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

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

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

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

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

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

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

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

В классическом случае вас бы попросили в тот же день задержаться в офисе ровно на столько, сколько вы отсутствовали. Только толку от этого не будет никакого. И скорее всего, сотрудник просто просидит это время, ковыряясь в носу и просматривая Instagram.

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

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

Мы с супругой стараемся придерживаться того же режима, что и до карантина. Даже желаем друг другу хорошего дня, расходясь по разным комнатам после завтрака. Разве что обедать стали вместе. В остальном с точки зрения рабочих процессов ничего не поменялось. А в чем-то стало даже проще: кто заканчивает работу раньше, может легко проследить за тем, чтобы партнер не засиживался.

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

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

Подход к продуктивности

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

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

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

Вы в недоумении побежите к тестировщикам (!) с криками: «Как так?». В результате долгого и нудного разбирательства окажется, что товарищ Петров, написавший 100 тест-кейсов за месяц, вообще не понимает, как работает продукт. А его тесты не обнаружили ни одного дефекта за последние полгода. А вот Сидоров с показателем в 20 тестов только и успевает заводить критикалы и блокеры.

«Ок, — скажете вы. — Давайте ориентироваться на количество заведенных багов и их severity!». Получаете цифры, хвалите одних, порицаете других. Только на качество продукта это почему-то никак не повлияло. «В чем же опять дело?» — спросите вы.

Да все просто, Карл! Процессы-то у вас совсем протухли! Разработчики не пишут тесты, о coding standards никто не слышал, статические анализаторы не подключены, прекоммит-хуков нет, код-ревью — для галочки, весь мусор летит прямо в master. Тестировщики ничего не успевают и совершенно не слышали об impact analysis, планирование проходит в полторы калеки под пивко и Spotify (причем без Product Owner’а и бизнес-аналитика), уровень токсичности в команде просто зашкаливает. А вы в это время все меряете продуктивность тестировщиков?!

Безусловно, метрики важны и нужны. Но реальная оценка продуктивности должна идти бок о бок с показателями эффективности. А здесь уже все становится куда запутанней.

Вот несколько примеров:

• Вася за два дня не запушил ни одной строчки кода. Ведь он продумывал то, как можно наиболее эффективно решить поставленную задачу, чтобы сэкономить команде кучу времени на реализацию и поддержку. Только вот он может вовсе и не найти оптимального решения. Означает ли это, что Вася потратил время зря? А если все же нашел, но через неделю требования переиграют? А вдруг в процессе реализации окажется неучтенным существенный нюанс — и это приведет к полному редизайну?
• Федор уделяет по часу в день на менторинг Пети. Через время Петя начинает неистово коммитить. Внимание, вопрос: это Федор так позитивно влияет на Петю или Петя просто много времени тратит на самообучение?
• Валя — тестировщица. Она пишет на 20% меньше тестов, чем остальные. Но на планировании всегда задает очень правильные вопросы, которые зачастую ставят разработчиков в тупик, а Product Owner’а заставляют взять паузу на обсуждение требований с остальными стейкхолдерами. Означает ли это, что Валя снимает часть рисков с команды и оказывает положительное влияние на развитие продукта? Или, может, в команде не хватает бизнес-аналитика, а Валя попросту занимается не пойми чем?
• Макс — автоматизатор, который покрыл 90% регрессии UI-тестами, встроил свой пайплайн в development flow и регулярно коммитит в Git. Но его тесты находят не больше пяти багов за год. Означает ли это, что такие тесты — неэффективны, а он делает бесполезную работу? Или просто у разработчиков на более низких уровнях все настолько хорошо покрыто, что большая часть багов находится еще до непосредственного запуска UI-тестов?

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

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

Случай из реальной жизни. Допустим, в ваших критериях к качеству прописано, что количество багов за спринт не должно превышать пяти. И вот однажды тестировщики находят целых 32 дефекта! Прибегает Product Owner к менеджеру с криками: «WTF?!» Менеджер — к тестировщикам. У всех паника, все горит, срочная ретроспектива.

В следующем спринте принимается решение вычистить все баги, с чем команда успешно справляется. Только цифру 0 в графе багов уже никто не может зарепортить, так как Product Owner подумает, что с продуктом наконец все хорошо. И, следовательно, будет очень сложно ему объяснить в следующем спринте, почему опять полезли дефекты.

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

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

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

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

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

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

Инструменты и рабочее окружение

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

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

Моё окружение:

• рабочий лэптоп Macbook Pro 13’, i5, 16Gb RAM;
• ПК i7, 32Gb RAM, SSD + HDD (Linux + Windows 10);
• USB-хаб на 7 слотов;
• 2×27’ монитора с настольным креплением;
• камера Logitech C922 (Full HD);
• микрофон Blue Yeti Pro + наушники закрытого типа Koss;
• роутер TP-Link Archer C1200;
• стул KULIK SYSTEM;
• на работе — надстройка для работы стоя STIY STIL.

Классические задачи разработки и автоматизации решаю за лэптопом. ПК в основном задействую для следующих задач:

• Эксперименты с различными инструментами. К примеру, как-то раз мне нужно было изучить все возможности связки Jira Server + Bitbucket Server + Jenkins. Чтобы не ждать две недели апрувов, доступов и прочей бюрократии, мне проще было развернуть все у себя.
• Поддержка пет-проектов, требующих кроссплатформенности.
• Работа с ML-задачами (все-таки загружать, допустим, 8 Гб векторов в RAM и отъедать по 50 Гб SSD для решения точечной задачи — это overkill для лэптопа), а также распознаванием и синтезом речи в реальном времени.

Для разработки предпочитаю продукты компании JetBrains. Хорошая IDE дает серьезный прирост производительности. Когда занимался автоматизацией на Java, мне хватало одной лицензии на IntelliJ IDEA. Как только влился в разработку — сразу подтянулся JS/TS и Python стек. Ну а IoT-хобби добавило сюда еще C++. После недолгих размышлений я купил лицензиюна весь Toolbox. В целом для среднестатистического инженера цена вполне приемлемая.

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

К слову, терминал тоже играет немаловажную роль. Мне понравилась связка iTerm2 + Zsh. Под него есть много полезных плагинов. Ну и куда же без алиасов? Я даже своим падаванам начал добавлять в цели: «Автоматизировать часть рутинных операций при помощи алиасов/функций».

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

Всего остального хватает и на уровне браузерных возможностей и расширений: Dev Tools, React Dev Tools, Talend API Tester, Octotree, Clear Cache, ImTranslator/Grammarly, JSONView, Jira HotLinker и JetBrains IDE Support. Ну а полезные рабочие и нерабочие линки у меня все сгруппированы в Bookmark folders.

Что касается основных средств коммуникации, то это Slack, Skype, Zoom, Hangouts и Gmail. У нас в компании официально используется G Suite, потому довольно удобно иметь все необходимое под рукой прямо в браузере. Даже с точки зрения управления почтой: Google позволяет гибко работать с несколькими профилями одновременно. У меня всегда открыты и рабочие, и личные табы. Почта всегда в поле зрения. Ну а фокусироваться на самом важном помогают фильтры и лейблы. Ввиду того, что частота приоритетных почтовых нотификаций не очень высокая, просматривать письма стараюсь ориентировочно раз в 2-3 часа,если только в тайтле не фигурирует ключевое слово «URGENT».

Все рабочие чаты организованы в Slack, что тоже удобно. Туда легко встраиваются всякие боты, календарь с напоминалками, статусы сборок и тому подобное. Здесь, помимо прямых username-упоминаний и ключевых тегов, высокий приоритет всегда у проектного, CTO и presale каналов — бывают довольно срочные запросы, которые нужно обрабатывать ASAP.

Все нерабочие каналы мессенджеров, например Telegram и Viber, у меня всегда по умолчанию стоят в беззвучном режиме.

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

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

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

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

Книги и самообразование

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

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

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

Простой пример. Допустим, ко мне приходит начинающий автоматизатор и спрашивает, что можно почитать по Java. Но я понимаю, что не могу ему посоветовать «Thinking in Java» 2006 года, по которой я учился азам. Или «Java 8 in Action» — ведь недавно был релиз 14-й.Лично мне после 8-йверсии достаточно было лишь активно следить за статьями в блогах известных разработчиков и JEP’ами, вошедшими в тот или иной релиз. Практическую ценность в покупке очередной «[Language] X in Action» я перестал замечать с определенного момента. Поэтому акцентирую внимание на специализированных статьях в блогах при решении конкретных задач.

Сейчас же начал читать «Leading Quality» by Ronald Cummings-John and Owais Peer. А из недавнего нетехнического выделил бы следующее:

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

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

Если же я просто хочу разобраться в новом фреймворке или библиотеке, то прежде чем читать API reference, я попытаюсь его запустить по Quick Start Guide и посмотреть, как это работает.

Но тут есть обратная сторона: если нужно исследовать несколько инструментов или сервисов, то одного лишь «Hello, World» запуска недостаточно. Придется нырять гораздо глубже: изучать возможности API, пробовать писать micro-POC и тому подобное.

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

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

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

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

Ретроспектива и планы на будущее

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

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

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

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

Від редакції: цю статтю ми готували у березні, до початку карантину.

Протягом двох місяців у львівському SoftServe вчилася група студентів за новим для їхньої IT Academy напрямом. Тут готували п’ятьох професіоналів з Accessibility Testing.

Журналісти DOU побували на одному занятті та дізналися, які саме знання отримують майбутні тестувальники, в чому особливість Accessibility Testing і навіщо готувати таких фахівців.

Шахіст

У приміщенні SoftServe IT Academy от-от розпочнеться заняття. Коридором швидко крокує хлопець і випадково зачіпає плечем двері. Це — Владислав Колпаков, один зі студентів курсу Accessibility Testing, що стартував в академії два місяці тому. У руках хлопець тримає тростину, а темні окуляри не знімає навіть у приміщенні.

Влад почав втрачати зір ще в дитинстві. Однак це не завадило йому закінчити філософський факультет Львівського університету ім. Франка та досягти майстерності у шахах. Сьогодні він — гравець і тренер збірної України з шахів серед людей з порушеннями зору. А ще невдовзі Влад стане професійним тестером сайтів на доступність.

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

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

Владислав Колпаков

Ринок, закон і доступність

Accessibility Testing — це тип тестування програмного забезпечення, яке застосовують, щоб сайт, додаток абощо були зручні в користуванні для людей з порушеннями зору чи слуху, ураженням опорно-рухового апарату, пам’яті тощо. Фахівці з такого виду тестування перевіряють, чи відповідає продукт критеріям, викладеним у Web Content Accessibility Guidelines (WCAG). Цей документ — частина із серії керівних принципів щодо доступності вебсторінок, які розробили у The World Wide Web Consortium.

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

Поштовхом для створення курсів з Accessibility Testing у SoftServe стали вимоги ринку та законодавства.

Вікторія Ширяєва, представниця бізнес-підрозділу, Senior QA та Project Manager, уже протягом двох років працює на проєктах SoftServe, які імплементують accessibility.

«У Сполучених Штатах приблизно кожен четвертий має ту чи іншу форму інвалідності. Тож це гігантський ринок, який потенційно може бути втрачений. Це бізнес-драйвер. Є і законодавчі драйвери — вимоги, відповідно до яких сайти мають бути доступними. Інакше їх не допустять до використання. Особливо суворо це регулюється в Америці. Останніми роками до цього питання більш уважно ставиться і Європа», — пояснює спеціалістка.

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

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

Активіст

Роману Савці — 34.

15 років тому він навчався у «Львівській політехніці», де опановував комп’ютерні науки.

10 років тому займався художнім ковальством.

Два місяці тому вперше познайомився з командою SoftServe та дізнався, що таке Accessibility Testing.

Роман Савка

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

Сьогодні Роман очолює громадську організацію «Рівні можливості для всіх», яка надає юридичні консультації у питаннях захисту прав людини. Згодом її учасники планують розробити рекомендації для уряду, щоб більш ефективно впроваджувати норми Конвенції ООН з прав людини на теренах України.

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

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

Тепер Роман почувається більш упевнено в своїх вміннях. Курс Accessibility Testing — це три години занять в аудиторії IT Academy тричі на тиждень і регулярні домашні завдання. Час, проведений в аудиторії та вночі за домашнім ПК, дав свої результати. Сьогодні Роман хіба жартує, що постійно ставить купу питань викладачкам. А вони й раді. Кажуть: якщо є питання, значить, людині справді цікаво, вона хоче розбиратися в предметі.

Комп’ютер, англійська та мотивація

Знайти таких, як Роман і Владислав, було непросто, хоча й вимоги до потенційних учасників курсу були невисокі:

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

«Чи не найбільше людей відсіяла саме англійська. Це не наша примха, а реалії ринку, оскільки українських замовників немає. А учасникам доведеться не тільки читати літературу, щоб розібратися в темі, а й спілкуватися із замовником чи його представниками», — пояснює менторка SoftServe IT Academy Вікторія Ряжська.

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

«У нас була дівчина із зором −13. Але ми не змогли її взяти, оскільки вона не використовувала жодного допоміжного інструмента. Вона максимально підходила до монітора, щоб побачити текст, зображення. Але таким чином дівчина ознайомлювалася із сайтом як звичайний користувач і не змогла протестувати його на предмет accessibility», — уточнює Вікторія Ряжська.

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

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

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

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

Філолог

Іван Яцига

Не так давно Іван закінчив Львівський національний університет ім. Івана Франка. Тепер він філолог, а репетиторство — його основний заробіток.

«Але я не роздумував над тим, чи варто йти на курси. Репетиторство — хоч і основне, але не постійне джерело доходу. А знайти роботу сьогодні, тим паче людині з інвалідністю, складно. Я добре вчився, закінчив університет, отримав диплом... Утім виявилося, що в реальному житті філолог не дуже комусь потрібен. Я ходив на співбесіди у школи, і мені відмовляли», — пригадує Іван.

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

«Якщо подивитися на перелік професій, то здебільшого люди з порушеннями зору можуть бути або масажистами, або... масажистами!» — зауважує студент.

Тож курси для нього — реальний шанс працевлаштуватися.

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

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

Щоправда, тепер хлопець жартує: поки не прийшов на курси, користувався сайтами нормально. А тепер куди не подивишся — все недоступне, адже тримаєш у голові критерії оцінки вебресурсів.

Теорія, практика та результати

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

«Певно, дев’яносто відсотків — це та інформація, яку ми даємо майбутнім Manual QA. А друга частина — саме Accessibility Testing. Відповідно її звичайні тестери не проходять», — уточнює менторка IT Academy Вікторія Ряжська.

Спочатку студентів ознайомили з критеріями доступності сайтів та аплікацій згідно з Web Content Accessibility Guidelines, демонстрували різні кейси. Потім перейшли до практичної роботи, як на проєкті.

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

Наприкінці курсу студенти Accessibility Testing складають фінальний тест і мають презентувати власний проєкт.

Англомовний

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

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

Олег Шапай

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

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

Чимала кількість домашніх завдань на курсах Олега не зупиняє. Каже, що й так багато часу проводив за монітором, а тепер може це робити з користю. Єдина річ, яка йому не подобається, — потреба багато писати. Хлопець зізнається: не любив цього ще в університеті, але тут уже нікуди не дінешся.

«Щось потестувати — легко, а от писати... Довелося змиритися», — з усмішкою додає він.

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

«Наприклад, ми бачимо, що сайт недоступний. А хочеться, щоб було інакше. То зробімо його доступним! Але не тільки для себе, а для всіх. Власне, це одна з речей, яка мене мотивує навчатися тут і рухатися далі», — додає Олег Шапай.

Випуск і плани

Наприкінці навчання команда взялася за тестування сайту SoftServe. Працюють за Agile-методологією, Scrum: з мітингами для планування, виконанням завдань і заповненням документації.

Вікторія Ряжська каже, що цей випуск — уже справжні експерти з Web Content Accessibility Guidelines. Вона тішиться результатами команди і твердить, що студенти мають дивовижну пам’ять.

«Є 50 критеріїв, за якими можна перевіряти сайт на доступність. У документі, яким ми послуговуємося, вони погруповані й пронумеровані. І якщо я попрошу когось з наших студентів назвати критерій, наприклад, 1.3.2, то людина не тільки скаже, що це, а й дасть його детальний опис, нюанси, коли цей критерій може не застосовуватися, і наведе приклади. Я ці цифри не можу запам’ятати, а у них все в голові, наче по поличках розкладено», — зауважує менторка.

Наразі основний план компанії — працевлаштувати випускників на проєкти SoftServe. Кажуть, якщо все пройде успішно і буде багато запитів під Accessibility Testing, другий набір точно оголосять. Однак поки що через карантин цей процес затягується, оскільки немає можливості організувати випускникам онбординг та робочі місця належним чином.

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

Олег Шапай переконаний: якщо їхня група отримає гідну роботу, то покаже, що можна й варто ламати стереотипи.

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

Читайте також: «Веб-доступність. Що варто знати кожному Front-end розробнику і дизайнеру»

Ця стаття написана в співавторстві з Yuliya Miadzvetskaya.

Що спільного між витоком даних, порушенням права на забуттята штрафом у 16 млн доларів? Їх усіх об’єднує принцип європейського права під назвою Privacy by Design (PbD), за порушення якого низка компаній уже отримала рекордні штрафи.

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

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

Ілюстрація Уляни Патоки

2019 року європейські контрольні органи видали перші штрафи за порушення принципу PbD, закріпленого в GDPR — Регламенті ЄС щодо захисту персональних даних, що набрав чинності в травні 2018-го.Тоді як багато людей знають про GDPR завдяки величезним штрафам, заявкам користувачів про видалення даних і надокучливим проханням сайтів погодитися на використання cookies, не всі стикалися з принципом Privacy by Design. Він передбачений ст. 25 GDPR і здатен завдати штрафів у мільйони євро ІТ- й телеком-бізнесам.

Навіть епідемія коронавірусу не змусила європейську владу послабити нагляд за дотриманням GDPR. А враховуючи збільшення частки людей, що працюють з дому чи у віртуальних офісах, значення GDPR зростатиме. Українські компанії зобов’язані дотримуватися вимог GDPR, якщо їхні розробки використовуються в ЄС. Загалом Privacy by Design — вимога для всіх компаній, але в цій статті ми сконцентруємося на секторі ІТ.

Що таке PbD

Принцип Privacy by Designозначає, що захисту персональних даних і приватності має приділятися увага в software development lifecycle (SDLC) ще на етапі планування архітектури, а не наприкінці розробки, як це трапляється зазвичай. Тобто ще під час планування структури застосунку чи сайту треба продумати, як забезпечити захист персональних даних, їх обробку та видалення на вимогу користувачів.

Якими бувають штрафи та за що

Поряд з PbD є technical and organizational measures (технічні й організаційні заходи) — TOMs, за якими контрольні органи можуть оцінити рівень комплаєнсу. Штрафи можуть виписувати як за незастосування PbD загалом, так і за погану реалізацію окремих TOMs.

Розмір штрафів здебільшого залежить від тяжкості наслідків, до яких призвело порушення.

Вони можуть бути дуже маленькими, коли, наприклад, DPA (Data Protection Authority, орган контролю) Румунії оштрафувала асоціацію домовласників (на кшталт нашого ОСББ) за недостатні TOMs під час встановлення камер відеоспостереження в багатоквартирному будинку. Зокрема, ОСББ не розмістила попереджень про наявність камер, не забезпечила обмеження строків зберігання відеозаписіві не обмежила доступ користувачів до файлівіз записами. ОСББ отримали два офіційних попередження та штраф у 500 євро. Повний текст румунською.

Трохи дивний кейс розглядала DPA Чехії, коли оштрафувала ІТ-підприємця, власника онлайнової гри. Сайт онлайн-гри став жертвою DdoS-атаки. Власник невдало спробував відновити сервери та встановити захист. Зловмисники вдалися до шантажу й почали вимагати від підприємця гроші за припинення атак. До того ж вони запропонували допомогу з установленням нового фаєрволу, щоб не допустити подібних атак у майбутньому. Власник сайту заплатив гроші та встановив фаєрвол, код якого надіслали самі зловмисники. Код містив бекдор, через який шахраї дістали доступ до серверів гри, встановили редирект на власний сайт і завантажили персональні данікористувачів. База даних 4500 користувачів (імена, паролі, імейли, телефони тощо) була опублікована в Інтернеті. Штраф за відсутність адекватних TOMs становив 980 євро.Повний текст чеською.

Також можна згадати доволі поширений кейс, коли магазини здійснюють загальну імейл-розсилку, де внаслідок помилки чи незнання не приховують адреси інших отримувачів. За таке порушення TOMs DPA Іспанії виписала штраф у 5000 євро. Повний текст іспанською.

Це кейси, які стосувалися невеликих компаній або приватних ІТ-підприємців. Але в разі роботи з великим масивом даних або особливого характеру інформації (дані про здоров’я, особисте життя, фінанси тощо) штрафи пропорційно збільшуються. DPA Румунії влітку 2019-гооштрафувала банк за відсутність мінімізації використання даних і належних захисних механізмів.

При оплаті онлайн зайві персональні дані платника надсилалися отримувачеві. Часто таке трапляється внаслідок неправильного генерування електронних документів (інвойсів, платіжок, чеків), чиї поля заповнюються автоматично через запити до баз даних. Контрольні органи звернули увагу на це порушення внаслідок скарги, найімовірніше від одного з клієнтів банку. Загалом особисті коди й адреси 337 042 клієнтів опинилися в доступі сторонніх осіб. Штраф за недостатні TOMs становив 130 тис. євро. Повний текст румунською.

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

Ще один поширений кейс, який дратує навіть авторів статті.Часто різні компанії або магазини здійснюють розсилки або навіть дзвінки, від яких неможливо відписатися. DPA Греції розслідувала скаргу користувача, що натиснув магічну кнопку ‘unsubscribe’, але спам і далі надходив. Контрольні органи видали штраф за порушення PbD через відсутність відповідного реагування на запити користувачів на 400 тис. євро. Пресреліз англійською.

DPA Франції провела цікаве онлайн-розслідування за скаргою одного з клієнтів компанії, яка займається нерухомістю. У скарзі зазначалося, що під час користування онлайн CRM-системою модифікація кількох символів в URL-адресі дозволила отримати неправомірний доступдо особистих документів сторонніх осіб.

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

Загалом, простою заміною символів інспектори завантажили 9466 документів різних користувачів. Скаржник повідомив компанію про дефект у TOMs у березні 2018-го,та реакції не було. DPA надіслала офіційне повідомлення 7 вересня 2018 р., але протягом тижня компанія так само не виправила дефект (імовірно, через відсутність ІТ-фахівців у штаті).

Інспектори встановили, що на момент перевірки у фактично вільному доступі перебували 290 870 документів. Компанія спробувала подати заперечення, посилаючись на процедурні порушення, проте заперечення відхилили. У підсумку за сукупністю умов, серед яких відсутність належних TOMs, природа даних (фінанси, особисте життя), а також за відсутність реакції на скарги, на компанію наклали штраф у 400 тис. євро, при початковій вимозі інспекторів накласти штраф у 900 тис. євро. Повний текст французькою.

Один з найбільших штрафів отримала одна німецька компанія. Під час перевірки DPA Берліна (ФРН) виявила порушення в обслуговуванні електронних архівів німецької рієлторської компанії.Компанія не передбачила механізму видалення даних за запитом користувачів і зберігала дані довше за розумний строк.

В архіві накопичувалися документи щодо працевлаштування, податкової історії, медичного страхування та банківських розрахунків. Перевірку провели у вересні 2017-го,тобто ще до вступу GDPR в силу. Але станом на березень 2019 року, після повторної перевірки, інспектори не виявили практично ніяких поліпшень.

Після цього компанія доклала зусиль до співпраці з інспекторами та видалення зайвих даних, зокрема колишніх клієнтів чи заявників, що не користувалися послугами компанії. Співпрацю компанії врахували, визначаючи штраф за порушення PbD, що сягав 14,5 млн євро (понад 16 млн доларів у березні 2019 р.). Станом на час публікації постанови компанія ще мала шанс оскаржити штраф. Повний текст рішення німецькою.

Наостанок можна згадати цікавий штраф, виданий державному органові. DPA Болгарії оштрафувала місцеву Національну агенцію доходів. Унаслідок неналежного технічного захисту хакери отримали дані щодо імен, ідентифікаційних номерів, адрес, телефонних номерів, податкові декларації, фінансові дані, дані соціального страхування, виплати за медичними страховками, дані щодо адміністративної відповідальності понад 4 млн живих (фактично все працездатне населення країни) і майже 2 млн померлих осіб. Штраф: 2,6 млн євро. Повний текст болгарською.

За що критикують PbD

PbD часто критикують за недостатню специфічність і відсутність точних «правил гри». І часом ця критика обґрунтована. Державні інспекції та органи з нагляду за дотриманням законодавства про захист персональних даних у своїх постановах щодо PbD посилаються або на недотримання принципу загалом, або на відсутність чи недостатність TOMs.

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

Як виконати вимоги PbD

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

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

Зокрема, треба зробити таке:

• Компанія має розробити чіткі внутрішні процедури обробки даних, а також визначити тривалість зберігання даних.
• Встановити відповідні обмеження, процедури авторизації та верифікації для унеможливлення незаконного доступу до даних.
• Видалення певних персональних даних повинно бути автоматизованим. Це стосується насамперед застарілих даних і даних колишніх користувачів.
• Треба переконатися, що неможливо повторно ідентифікувати анонімізовані дані чи відновити видалені дані.
• Використовувати захищені клауд-сервіси, високі вимоги до протоколів передачі даних, забезпечувати шифрування та/або анонімізацію даних при їхній передачі чи зберіганні.
• Вибрати найекономніші та найефективніші в плані обробки даних алгоритми, фреймворки й (інколи) мови програмування для розробки відповідного ПЗ.
• Подбати про захист інформації від атак (кібербезпека).
• Мінімізувати збір і використання персональних даних. Річ не тільки в зменшенні кількості імен або імейлів у базі даних ваших користувачів, а й у мінімізації будь-яких операцій з даними. Витік великих і деталізованих баз даних призводить до тяжчих наслідків. GDPR вимагає, щоб для досягнення цілей (надання послуги, розробки продукту) використовувалася якнайменша кількість потрібних для цього даних. Це саме стосується й кількості операцій (запитів до БД, збору, оновлення та пересилання даних) з персональними даними.

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

• Призначення Data Protection Officer (DPO), який/яка забезпечує розробку та впровадження відповідних заходів, документів, політик і інструкцій для компанії, а також буде відповідальною особою для зв’язків з органами контролю. Призначення DPO в разі обробки великої кількості даних є обов’язковим.
• Проведення навчання для працівників. Воно охоплює вміння відрізняти персональні дані від неперсональних, запобігання ненавмисному розголошенню даних; правила використання шифрування, пересилання даних громадян ЄС за межі ЄС (наприклад, коли клієнт хоче дати доступ до своїх БД розробникові з України), порядок дій у разі витоку даних. Особливо це стосується персоналу (РМ, ВА, розробники, рекрутери, служба підтримки), який напряму працює з персональними даними громадян країн ЄС і з клієнтами. На жаль, рівень культури при роботі з даними залишається вкрай низьким; з нашого досвіду можемо сказати, що лише одиниці читають власноруч підписані NDA, де зазначено правила поводження з даними й відповідальність за порушення.
• У компанії має бути протокол дій на випадок інспекції або офіційного листа від DPA чи іншого уповноваженого органу та відповідальна особа для опрацювання подібних звернень. Окрім DPA, розкриття даних можуть вимагати прокуратура, поліція, спеціальні служби, суди. І далеко не в усіх випадках ці органи матимуть відповідні повноваження.
• Установлення режимів фізичного доступу до комп’ютерів і серверів. Немає потреби перетворювати офіс ІТ-компанії на військову базу, але є рація переглянути доцільність доступу всієї команди до серверів чи «холодних архівів» з персональними даними.

Як зазначено в статті 25 GDPR, береться до уваги state of the art. Таким чином ІТ-компанії мають враховувати останні досягнення в технологіях для забезпечення приватності своїх користувачів і захисту їхніх персональних даних. Окрім state of the art, ІТ-компанії мають збалансувати свої ТОМs із витратами на реалізацію та цілями обробки персональних даних.

Простий приклад передбачає, що для обробки даних щодо здоров’я людини (особливо актуально для фітнес-застосунків і розумних годинників) потрібні жорсткіші та ґрунтовніші ТОМs, аніж для захисту бази даних з ніками користувачів онлайн-гри.

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

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

Для невеликих і середніх компаній (<100 співробітників) буде досить зовнішнього професійного аудиту та DPO/ІТ-юриста з досвідом роботи з GDPR compliance. Стаття 25 (3) GDPR передбачає можливість сертифікації для комплаєнсу з вимогами GDPR. Це означає, що якщо власника сертифікували в одній з країн ЄС, контрольні органи враховуватимуть це у своєму глобальному оцінюванні відповідності GDPR, зокрема стосовно PbD.

Великі ІТ-компанії та компанії, які працюють на ринок ЄС, можуть розглянути можливість отримання такої сертифікації, умови якої кожна європейська держава визначає самостійно (ґрунтовно таку сертифікацію та критерії описала Європейська рада з питань захисту даних). Також наявний окремий варіант сертифікації за стандартом ISO:27001, який хоч і не створений спеціально для GDPR, але буде корисним для організації керування інформаційної безпеки в міжнародній компанії. Сертифікація добровільна й не звільняє від відповідальності за порушення.

Тобто захист персональних даних і приватність — чинники, які треба враховувати насамперед архітекторам ПЗ під час планування нових рішень та бізнес-аналітикам при визначенні вимог до продукту.

ІТ-юрист + програміст = ?

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

З ускладненням правових вимог до ІТ-компаній з’явилося розуміння, що вже не можна обійтися юристом загальної практики, який «напише фопівський договір» і «шаблон для контрактів». Потрібні фахівці з інтелектуальної власності, міжнародних контрактів на розробку ПЗ і захисту персональних даних. Для невеликих компаній і студій буде досить мати юриста на аутсорсі, до якого звертаються кілька разів на місяць. Але зі збільшенням кількості клієнтів, зростанням компанії та ускладненням процесів з’являється потреба в in-house ІТ-юристі, а в разі роботи на ринок ЄС — і в Data Protection Officer.

Призначення DPO в ІТ-компанії — вимога GDPR, за винятком ситуацій, коли компанія взагалі не працює з персональними даними громадян країн ЄС. Єдина вимога до кваліфікації DPO — «експертне знання права захисту персональних даних». DPO підзвітний найвищому менеджменту компанії, фактично незалежний у здійсненні своєї діяльності (GDPR забороняє давати DPO вказівки щодо його/її обов’язків) і не має бути юристом.

Якщо в компанії є кваліфікований юрист або юридичний відділ, то роль DPO може виконувати спеціаліст у галузі інформаційної безпеки, який має розуміння GDPR. Залежно від специфіки компанії бекграунд спеціаліста може бути в compliance, system administration, DevOps, information security. Опитування, проведене International Association of Privacy Professionals, показало, що більшість з опитаних хочуть найняти in-house DPO з досвідом на посадах compliance specialist, IT specialist або non-technical manager з як мінімум 5 роками професійного досвіду.

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

На нашу думку (але це не вимога GDPR), DPO чи відповідного спеціаліста також треба прилучати до деяких фаз SDLC для забезпечення дотримання принципу PbD й GDPR загалом.

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

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

Зрозуміло, що кожна ІТ-компанія, а часом навіть і команда, мають власне бачення SDLC. Зазначене вище вирішення аж ніяк не претендує на повноту й безальтернативність, а радше є спробою мотивувати ІТ-компанії залучати DPOs і ІТ-юристів до SDLC.

Релевантність для України

На перший погляд може здатися, що PbD вартий уваги лише продуктових ІТ-компаній, які працюють на європейський ринок або мають представництво в ЄС, бо GDPR поки не поширюється на територію України. Проте все не так просто. Справді, поки немає докладних ухвал вищого судового органу ЄС — Суду справедливості — щодо застосування GDPR і PbD до іноземних компаній. Практика штрафів проти компаній, зареєстрованих поза ЄС, нерозвинена, бо поки незрозуміло, як DPAs зможуть проводити інспекції та виписувати штрафи на територіях третіх країн.

Цілком можливо, що державні органи вимагатимуть заборони діяльності таких компаній у ЄС і блокування доступу до їхніх ресурсів. Ініціативи ЄС вплинули навіть на США, де окремі штати (радимо ознайомитися з California Consumer Privacy Actі New York Privacy Act) ухвалюють або планують ухвалити власні закони про захист персональних даних.

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

Європейські стартапи та великі компанії з обережністю ставляться до персональних даних своїх користувачів і висувають серйозніші вимоги щодо приватності. Клієнти сподіваються отримати не просто технологічне рішення, а рішення, яке буде відповідати стандартам ЄС. У деяких конкретних кейсах, з якими стикалися автори, клієнти з Європейської економічної зони (куди входять ЄС і низка інших країн) навіть розглядали можливість призначення DPO в Україні з метою передати на аутсорс увесь свій проєкт разом з персональними даними. Окрім того, від техлідів, рекрутерів, PM і BA вимагатимуться навички роботи з персональними даними та бодай базові знання GDPR.

Висновки

GDPR «в силі» менш як два роки, але певні результати вже помітні. Нагляд за дотриманням GDPR ставатиме суворішим, як і вимоги європейського бізнесу до якості коду. До PbD додаються проблеми передачі персональних даних в Україну, не завжди оформлений належним чином допуск українських розробників до серверів з даними європейських компаній, елементарне незнання положень GDPR як європейськими замовниками, так і українськими розробниками. Українським ІТ-компаніям — як продуктовим, так і аутсорсам — уже замало бути GDPR-aware, а треба ставати проактивними у розробці своїх TOMs, щоб бути готовими до конкуренції на ринку.

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

Маленький ліричний відступ

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

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

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

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

Чому автогенерація важлива

Автогенерація коду — це перекладання однотипної роботи на комп’ютер (як і має бути) або спосіб уникнення помилок-одруків під час копіювання коду (навіть досвідчені спеціалісти помиляються).

Процес розробки й однотипна робота

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

Звикаєш до інструментів: IDE, тестів, CI/CD, каркасу з командами для генерації шаблонів DB-міграцій, CRUD-генераторів і ApiDoc-генераторів.

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

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

Правильні метафори

Щоб зрозуміло пояснити технологію, треба вибрати всім добре знайомий приклад.

Сайт з новинамиLamerNewsвикористовується як приклад для пояснення Redis-у.

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

gRPC для міжсервісної взаємодії

gRPC — високопродуктивний каркас для взаємодії між сервісами, що дає можливість згенерувати код клієнта й сервера на основі файлів з розширенням .proto.

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

Розгляньмо на основі прикладу про форум, який вигляд матиме proto-файл, де будуть методи для створення нової теми та редагування вже наявної:

syntax = "proto3";

service Forum {    rpc CreateTopic (CreateTopicRequest) returns (UpdateTopicResponse);    rpc UpdateTopic (UpdateTopicRequest) returns (UpdateTopicResponse);
}

message UpdateTopicResponse {    bool success = 1;    string error_message = 2;
}

message CreateTopicRequest {    string title = 1;    string description = 2;
}

message UpdateTopicRequest {    uint32 code = 1;    string title = 2;    string description = 3;
}

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

syntax = "proto3";

service ForumService {    rpc TopicCreate (UpdateTopicRequest) returns (UpdateTopicResponse);    rpc TopicUpdate (UpdateTopicRequest) returns (UpdateTopicResponse);
}

message UpdateTopicResponse {    bool success = 1;    string error_message = 2;
}

message UpdateTopicRequest {    uint32 code = 1;    string title = 2;    string description = 3;
}

Або навіть так, виділивши дані в окреме повідомлення і використовуючи як спільний код:

syntax = "proto3";

service ForumService {    rpc TopicCreate (CreateTopicRequest) returns (UpdateTopicResponse);    rpc TopicUpdate (UpdateTopicRequest) returns (UpdateTopicResponse);
}

message UpdateTopicResponse {    bool success = 1;    string error_message = 2;
}

message Topic {    string title = 1;    string description = 2;
}

message CreateTopicRequest {    Topic data = 1;
}

message UpdateTopicRequest {    uint32 code = 1;    Topic data = 2;
}

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

На основі proto-файлу можна згенерувати повноцінний клієнт під багато платформ; це може бути мікросервіс, мобільний застосунок або ж клієнт у браузері.

Ця стаття саме про клієнт, що застосовуватиметься в браузері.

Як це працює

Ми написали proto-файл forum.proto, на основі якого, за допомогою інструменту protoc, згенерували моделі й інтерфейс; інтерфейс реалізували на сервері, і тепер сервер готовий до використання.

Далі ми копіюємо цей proto-файл forum.protoв репозиторій з Front-end-ом; на його основі за допомогою інструменту protocі плагіна до нього protoc-gen-grpc-webгенеруємо моделі та клієнт, готові до використання.

Коли нам треба буде додати нові поля в уже наявні повідомлення чи додати нові rpc-методи, ми оновимо proto-файл, згенеруємо на сервері код, реалізуємо нову логіку, так само скопіюємо proto-файл forum.protoв репозиторій з Front-end-ом і згенеруємо клієнт.

Таким чином Front-end-розробник матиме готовий до використання gRPC-клієнт, а подивитися proto-файл буде простіше, ніж API документацію.

При описі я зробив спрощення, коли писав про один proto-файл. Зазвичай це тека, де є service.proto, у якому підключаються файли з повідомленнями.

Завдання і технологічний стек

У цій статті я реалізую прототип форуму DOU, заради цікавості додам нових фіч; сервер буде на Go, зберігатиму в MongoDB, запускатиму через docker-compose, а на клієнті буде Vue.js і Webpack.

Якщо ви хочете самі розібратися з gRPC Web, то можете клонувати репозиторій github.com/grpc/grpc-webз простою інструкцією, як запустити:

docker-compose pull
docker-compose up
browse http://localhost:8081/echotest.html

AJAX-лічильник, від простого до складного

Перед тим, як розглядати приклад з gRPC, розгляньмо простіший.

Візьмемо для прикладу вебсторінку, на якій показуємо число запитів; число запитів отримуватимемо через AJAX, а в наступному прикладі замінимо AJAX на gRPC.

Маємо три файли: index.html для зображення вмісту, counter.js, що робить AJAX-запит, та main.go сервер на Go:

 
├── main.go
└── public    ├── index.html    └── js        └── counter.js

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <title>AJAX counter example</title></head><body>    <p>        The page was viewed <span id="js-counter">0</span> times    </p>    <script src="js/counter.js"></script></body></html>

{    fetch("/api/counter.json")        .then(function (response) {            return response.json();        })        .then(function (json) {            document.getElementById("js-counter").innerHTML = json.count;        })        .catch(console.error);
}

package main

import (    "encoding/json"    "log"    "net/http"    "sync/atomic"
)

type CounterResponse struct {    Count uint32 `json:"count"`
}

func main() {    var counter = uint32(0)    http.Handle("/", http.FileServer(http.Dir("./public")))    http.HandleFunc("/api/counter.json", func(w http.ResponseWriter, _ *http.Request) {        var newCounter = atomic.AddUint32(&counter, 1)        json.NewEncoder(w).Encode(&CounterResponse{            Count: newCounter,        })    })    err := http.ListenAndServe(":8080", nil)    if err != nil {        log.Fatal(err)    }
}

Якщо хочете перевірити приклад, треба мати вже встановлений Golang.

go run main

browse http://localhost:8080/

Код AJAX-прикладу доступний у репозиторії.

gRPC-лічильник

У цьому прикладі ми:

1. Налаштуємо кодогенерацію серверної та клієнтської частини.
2. Опишемо файл counter.proto, на основі якого згенеруємо код для клієнт-серверної взаємодії.
3. На стороні сервера реалізуємо інтерфейс лічильника (інтерфейс згенерований через кодогенерацію).
4. На стороні клієнта під’єднаємо згенерований клієнт і зберемо проєкт через Webpack.

Встановити protocможна з офіційною інструкцієюдля Ubuntu (на момент написання статті найсвіжіша версія protoc 3.11.4):

PROTOC_ZIP=protoc-3.11.4-linux-x86_64.zip
curl -OL https://github.com/protocolbuffers/protobuf/releases/download/v3.11.4/$PROTOC_ZIP
sudo unzip -o $PROTOC_ZIP -d /usr/local bin/protoc
sudo unzip -o $PROTOC_ZIP -d /usr/local 'include/*'
rm -f $PROTOC_ZIP

Інструмента protocдосить для кодогенерації серверної частини на Go.

А ось для кодогенерації клієнтської частини на JavaScript потрібен плагін protoc-gen-grpc-web, що можна встановити на Ubuntu так:

curl -sSL https://github.com/grpc/grpc-web/releases/download/1.0.7/protoc-gen-grpc-web-1.0.7-linux-x86_64 -o /usr/local/bin/protoc-gen-grpc-web chmod +x /usr/local/bin/protoc-gen-grpc-web

Опишемо counter.proto:

syntax = "proto3";

package counter;

message Empty {

}

message Response {  uint32 count = 1;
}

service CounterSomeServiceName {  rpc CountSomeMethodName(Empty) returns (Response);
}

Файл counter.proto я розмістив у теці з довільною назвою protos:

 
~/go/src/gitlab.com/go-yp/grpc-counter
└── protos    └── services        └── counter            └── counter.proto

Назвав CounterSomeServiceName і CountSomeMethodName, щоб було простіше побачити, які суфікси та префікси додаються після кодогенерації.

Згенеруємо код для серверної частини:

mkdir -p ./models
protoc -I . protos/services/counter/*.proto --go_out=plugins=grpc:models

Оскільки кодогенерацію ви будете запускати після оновлення proto-файлів, рекомендую зберігати в Makefile:

proto-server:    mkdir -p ./models    protoc -I . protos/services/counter/*.proto --go_out=plugins=grpc:models

make proto-server

Після кодогенерації proto-serverотримаємо файл counter.pb.go:

~/go/src/gitlab.com/go-yp/grpc-counter
├── Makefile
├── protos
│   └── services
│       └── counter
│           └── counter.proto
└── models    └── protos        └── services            └── counter                └── counter.pb.go [+]

У файлі counter.pb.goбуде згенерований код моделей Responseі Emptyта методи цих моделей:

// Code generated by protoc-gen-go. DO NOT EDIT.
// source: protos/services/counter/counter.proto

package counter

// ...

type Response struct {    Count                uint32   `protobuf:"varint,1,opt,name=count,proto3" json:"count,omitempty"`    XXX_NoUnkeyedLiteral struct{} `json:"-"`    XXX_unrecognized     []byte   `json:"-"`    XXX_sizecache        int32    `json:"-"`
}

// ...

type Empty struct {    XXX_NoUnkeyedLiteral struct{} `json:"-"`    XXX_unrecognized     []byte   `json:"-"`    XXX_sizecache        int32    `json:"-"`
}

// ...

Методи моделей Responseі Empty — звичайні обгортки для реалізації службових інтерфейсів серіалізації protobuf-у через рефлексію, тому я їх прибрав з прикладу.

Також у counter.pb.goнам буде цікавий інтерфейс сервісу та реєстрації:

package counter

// ...

type CounterSomeServiceNameServer interface {    CountSomeMethodName(context.Context, *Empty) (*Response, error)
}

func RegisterCounterSomeServiceNameServer(s *grpc.Server, srv CounterSomeServiceNameServer) {    // ...
}

Тепер реалізуємо інтерфейс CounterSomeServiceNameServer:

package main

import (    "context"    "gitlab.com/go-yp/grpc-counter/models/protos/services/counter"    "sync/atomic"
)

type counterServer struct {    count uint32
}

func (s *counterServer) CountSomeMethodName(context.Context, *counter.Empty) (*counter.Response, error) {    var newCount = atomic.AddUint32(&s.count, 1)    return &counter.Response{        Count: newCount,    }, nil
}

var _ counter.CounterSomeServiceNameServer = new(counterServer)

Реалізуємо й запустимо на 50551-порті gRPC-сервер (також залишимо static-server з прикладу про AJAX-лічильник):

package main

import (    "context"    "gitlab.com/go-yp/grpc-counter/models/protos/services/counter"    "log"    "net"    "net/http"    "sync/atomic"    "google.golang.org/grpc"
)

type counterServer struct {    count uint32
}

func (s *counterServer) CountSomeMethodName(context.Context, *counter.Empty) (*counter.Response, error) {    var newCount = atomic.AddUint32(&s.count, 1)    return &counter.Response{        Count: newCount,    }, nil
}

var (    mainServer counter.CounterSomeServiceNameServer = new(counterServer)
)

func main() {    go func() {        lis, err := net.Listen("tcp", ":50551")        if err != nil {            log.Fatal(err)        }        defer lis.Close()        grpcServer := grpc.NewServer()        counter.RegisterCounterSomeServiceNameServer(grpcServer, mainServer)        if err := grpcServer.Serve(lis); err != nil {            log.Fatal(err)        }    }()    http.Handle("/", http.FileServer(http.Dir("./public")))    err := http.ListenAndServe(":8080", nil)    if err != nil {        log.Fatal(err)    }
}

Зробимо ініціалізацію Golang-проєкту й запустимо сервер:

go mod init
go run main.go

~/go/src/gitlab.com/go-yp/grpc-counter
├── go.mod  [+]
├── go.sum  [+]
├── main.go [+]
├── Makefile
├── protos
│   └── services
│       └── counter
│           └── counter.proto
└── models    └── protos        └── services            └── counter                └── counter.pb.go

gRPC-сервер чекає даних, переданих протоколом HTTP/2, а JavaScript-клієнт у браузері (який ми згенеруємо далі) передає дані протоколом HTTP 1.1; відповідно потрібен проксі, що зможе перетворити один протокол на інший.

Рекомендованим вирішенням є Envoy Proxy, про Envoy можна почитати в DevOps дайджестіабо послухати доповідь Envoy as TCP proxyОлега Миколайченка.

Я хотів зробити клієнт-серверну взаємодію напряму — тому знайшов вирішення, як це здійснити, у статті Proxy gRPC-Web directly in your Go Server.

package main

import (    "context"    "gitlab.com/go-yp/grpc-counter/models/protos/services/counter"    "golang.org/x/net/http2"    "golang.org/x/net/http2/h2c"    "log"    "net/http"    "sync/atomic"    "github.com/improbable-eng/grpc-web/go/grpcweb"    "google.golang.org/grpc"
)

type counterServer struct {    count uint32
}

func (s *counterServer) CountSomeMethodName(context.Context, *counter.Empty) (*counter.Response, error) {    var newCount = atomic.AddUint32(&s.count, 1)    return &counter.Response{        Count: newCount,    }, nil
}

var (    mainServer counter.CounterSomeServiceNameServer = new(counterServer)
)

func main() {    go func() {        grpcServer := grpc.NewServer()        grpcWebServer := grpcweb.WrapServer(grpcServer)        counter.RegisterCounterSomeServiceNameServer(grpcServer, mainServer)        var handler = h2c.NewHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {            w.Header().Set("Access-Control-Allow-Origin", "*")            w.Header().Set("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE")            w.Header().Set("Access-Control-Allow-Headers", "Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization, X-User-Agent, X-Grpc-Web")            grpcWebServer.ServeHTTP(w, r)        }), new(http2.Server))        err := http.ListenAndServe(":50551", handler)        if err != nil {            log.Fatal(err)        }    }()    http.Handle("/", http.FileServer(http.Dir("./public")))    err := http.ListenAndServe(":8080", nil)    if err != nil {        log.Fatal(err)    }
}

gRPC-сервер успішно запускається, тепер залишилося згенерувати й під’єднати клієнт у браузері:

proto-client:    mkdir -p ./client    protoc -I . protos/services/counter/*.proto --js_out=import_style=commonjs,binary:client --grpc-web_out=import_style=commonjs,mode=grpcwebtext:client

make proto-client

~/go/src/gitlab.com/go-yp/grpc-counter
├── client
│   ├── app.js
│   └── protos
│       └── services
│           └── counter
│               ├── counter_grpc_web_pb.js [+]
│               └── counter_pb.js          [+]
├── go.mod
├── go.sum
├── main.go
├── Makefile
├── protos
│   └── services
│       └── counter
│           └── counter.proto
└── models    └── protos        └── services            └── counter                └── counter.pb.go

У файлі counter_pb.jsбудуть моделі та службові обгортки:

// source: protos/services/counter/counter.proto
// GENERATED CODE -- DO NOT EDIT!

var jspb = require('google-protobuf');

// ...

proto.counter.Empty = function(opt_data) {  jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};

// ...

proto.counter.Response = function(opt_data) {  jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};

// ...

У файлі counter_grpc_web_pb.jsбуде gRPC-клієнт:

// GENERATED CODE -- DO NOT EDIT!

const grpc = {};
grpc.web = require('grpc-web');

const proto = {};
proto.counter = require('./counter_pb.js');

// ...

proto.counter.CounterSomeServiceNameClient = function(hostname, credentials, options) {  if (!options) options = {};  options['format'] = 'text';  this.client_ = new grpc.web.GrpcWebClientBase(options);  this.hostname_ = hostname;
};

// ...

Цього досить, щоб зробити реалізацію в app.js, схожу на попередній AJAX-приклад:

const {Empty, Response} = require("./protos/services/counter/counter_pb");
const {CounterSomeServiceNameClient} = require("./protos/services/counter/counter_grpc_web_pb");

const app = new CounterSomeServiceNameClient("http://localhost:50551");

const request = new Empty();

app.countSomeMethodName(request, {}, (err, response) => {    if (err) {        console.error(err);        return;    }    /** @type Response response */    document.getElementById("js-counter").innerHTML = response.getCount();
});

І останні приготування package.jsonі webpack.config.js, щоб зібрати клієнтську частину:

{  "name": "grpc-counter-example",  "version": "0.1.0",  "description": "gRPC counter example",  "license": "MIT",  "dependencies": {    "grpc-web": "^1.0.0",    "google-protobuf": "^3.6.1"  },  "devDependencies": {    "@grpc/proto-loader": "^0.5.4",    "webpack": "^4.16.5",    "webpack-cli": "^3.1.0"  },  "scripts": {    "build": "webpack --mode production"  }
}

module.exports = {    context: __dirname,    entry: {        app: './client/app'    },    output: {        path: __dirname + '/public/js',        filename: '[name].js'    },
};

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <title>gRPC counter example</title></head><body>    <p>        The page was viewed <span id="js-counter">0</span> times    </p>    <script src="js/app.js"></script></body></html>

~/go/src/gitlab.com/go-yp/grpc-counter
├── [4.0K]  client
│   ├── [ 514]  app.js
│   └── [4.0K]  protos
│       └── [4.0K]  services
│           ├── [4.0K]  counter
│           │   ├── [3.5K]  counter_grpc_web_pb.js
│           │   └── [8.4K]  counter_pb.js
├── [ 386]  go.mod
├── [5.8K]  go.sum
├── [1.4K]  main.go
├── [ 887]  Makefile
├── [4.0K]  models
│   └── [4.0K]  protos
│       └── [4.0K]  services
│           └── [4.0K]  counter
│               └── [7.0K]  counter.pb.go
├── [ 382]  package.json
├── [4.0K]  protos
│   └── [4.0K]  services
│       ├── [4.0K]  counter
│       │   └── [ 187]  counter.proto
├── [4.0K]  public
│   ├── [ 257]  index.html
│   └── [4.0K]  js
│       ├── [282K]  app.js
└── [ 186]  webpack.config.js

npm i
npm run build

go run main

browse http://localhost:8080/

Готовий приклад можна побачити в репозиторії.

Серед мінусів — розмір app.js ~ 282 KB, у якому підключені лише gRPC- і protobuf-бібліотеки.

gRPC-прототип структури форуму

Зробімо трохи складніший приклад, щоб подивитися, який буде розмір app.js.

Завдання: треба зробити простий форум зі створенням теми, коментарями та модерацією.

Підготуємо proto-файл, що описує методи:

syntax = "proto3";

package forum;

import "protos/services/forum/topic.proto";

service AnonymousForum {  rpc CreateTopic (CreateTopicRequest) returns (UpdateTopicResponse);  rpc UpdateTopic (UpdateTopicRequest) returns (UpdateTopicResponse);  rpc TopicList (Empty) returns (TopicListResponse);  rpc AddComment (AddCommentRequest) returns (Empty);  rpc Topic (TopicRequest) returns (FullTopicResponse);
}

service ModerationForum {  rpc TopicList(Empty) returns (TopicListResponse);  rpc TopicApprove(TopicRequest) returns (Empty);  rpc TopicReject(TopicRequest) returns (Empty);  rpc CommentList(Empty) returns (CommentListResponse);  rpc CommentApprove(CommentRequest) returns (Empty);  rpc CommentReject(CommentRequest) returns (Empty);
}

А такий вигляд матимуть моделі:

syntax = "proto3";

package forum;

message Empty {}

message UpdateTopicResponse {  bool success = 1;  string error_message = 2;
}

message CreateTopicRequest {  string title = 1;  string description = 2;
}

message UpdateTopicRequest {  string id = 1;  string title = 2;  string description = 3;
}

message Topic {  string id = 1;  string title = 2;  string description = 3;
}

message TopicListResponse {  repeated Topic items = 1;
}

message TopicRequest {  string id = 1;
}

message AddCommentRequest {  string topic_id = 1;  string username = 2;  string text = 3;
}

message Comment {  string id = 1;  string username = 2;  string text = 3;
}

message CommentListResponse {  repeated Comment items = 1;
}

message CommentRequest {  string id = 1;
}

message FullTopicResponse {  string id = 1;  string title = 2;  string description = 3;  repeated Comment items = 4;
}

└── protos    └── services        └── forum            ├── anonymous.proto            └── topic.proto

За аналогією з gRPC-лічильником згенерую клієнт:

protoc -I . protos/services/forum/*.proto --js_out=import_style=commonjs,binary:client --grpc-web_out=import_style=commonjs,mode=grpcwebtext:client

Під’єднаємо згенерований клієнт і використаємо його в прикладі:

const {CreateTopicRequest, UpdateTopicResponse} = require("./protos/services/forum/topic_pb");
const {AnonymousForum} = require("./protos/services/forum/anonymous_grpc_web_pb");

const app = new AnonymousForum("http://localhost:50551");

const request = new CreateTopicRequest();
request    .setTitle("gRPC forum example")    .setDescription("gRPC forum example");

app.addTopic(request, {}, (err, response) => {    if (err) {        console.error(err);        return;    }    /** @type UpdateTopicResponse response */    console.log(response);
});

├── [4.0K]  client
│   ├── [ 514]  app.js
│   └── [4.0K]  protos
│       └── [4.0K]  services
│           └── [4.0K]  forum
│               ├── [ 27K]  anonymous_grpc_web_pb.js
│               ├── [ 530]  anonymous_pb.js
│               └── [ 65K]  topic_pb.js
├── [1.0K]  Makefile
├── [ 382]  package.json
├── [4.0K]  protos
│   └── [4.0K]  services
│       └── [4.0K]  forum
│           ├── [ 755]  anonymous.proto
│           └── [ 898]  topic.proto
├── [4.0K]  public
│   └── [4.0K]  js
│       └── [310K]  forum-app.js
└── [ 229]  webpack.config.js

Бачимо, що розмір forum-app.js ~ 310 KB.

Далі буде

У цій статті я планував створити прототип форуму DOU зі збереженням у MongoDB, але стаття і так вийшла об’ємною; якщо сподобалася, то зроблю продовження.

Епілог

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

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

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

Чи переводити вже наявну REST-взаємодію браузера й сервера на gRPC web? Ліпше подумайте, а чи справді вам це треба.

У майбутньому хочу писати кращі статті, тому буду радий коментарям про те, як і що міг би пояснити простіше.

Меня зовут Максим, и я тестировщик. С интересом слежу за событиями в мире тестирования и IT. Собираю самое полезное и с радостью делюсь с вами. Приятного чтения! :)

Почитать

Что почитать о тестировании ПО?

Ошибки Junior QA на собеседовании.

Чеклист по планированию тестирования.

Ключевые тренды тестирования ПО из исследования SmartBear: виды тестов и тенденции.

Тестируем на проде: Canary Deployment.

Большой гайд по A/B-тестированию.

Как перестать беспокоиться и начать верить A/B-тестам.

Сканер ошибокна страницах сайта.

За это время вышли новые выпуски подкаста QAGuild.Заходите послушать.

Стратегия тестирования в условиях Scrum: зачем она нужна и как построить.

QA — специалист по пожарной безопасности вашего проекта.

Статья на тему TestOps, но тут ценны комментарии, почитайте.

Покрытие кода или покрытие тестами, что выбрать?

Свеженькое на старую тему QA vs QC.

Ручные тестировщики не нужны или пора уже в автоматизацию.

Стоит ли изучать Selenium в 2020?

Погружение в Charles Proxy

Grafana, InfluxDB, два тега и одна сумма. Или как посчитать сумму подгрупп?

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

Автоматизация

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

Что должен знать тестировщик бэкенда.

Масштабирование андроид-тестирования в Одноклассниках.

Обзор существующих инструментов тестирования на JavaScript 2020.

Selenium + AutoIT. Автоматизация тестирования Windows окон.

Как работает Selenium. Серия из 6 эпизодов в списке блогов.

Про относительные локаторы Selenium 4.

Xpath в web-тестировании, написание и отладка.

Прелести Pytest: Pytest-BDD

Cucumber JVM — не только BDD.

Чем Cypress прекрасен для новичков автоматизации?

Про нюансы Cypress.

4 лучших паттерна проектирования автоматизированного тестирования.

Cypress + Storybook. Хранение тестового сценария, данных и рендеринг компонента в одном месте.

Шаблоны проектирования с человеческим лицом.

Несколько советов по созданию page object классов здорового человека.

Единственно верный способ загружать и скачивать файлы в Selenium тестах.

Как тестировать ушедшие запросы с помощью Puppeteer (Playwright).

Как искать баги на фронтенде: 4 основных этапа.

Практическое руководство по разработке бэкенд-сервиса на Python. Полезно для общего развития.

Автоматизация тестирования веб-приложений под ключ, без регистрации и смс.

Property-based тестирование для JavaScript и UI: необычный подход к автоматизированным тестам.

Selenoid — сотни параллельных UI-тестов легко и быстро.

Визуализация покрытия автотестами.

Юмор

Отдельное спасибо Диане Пинчук за классную статью. Не останавливайся!

Все, кто желает поделиться интересным — пишите на почту (адрес в профиле), обсудим, опубликуем, скажем спасибо :)

← Предыдущий выпуск: QA дайджест #41

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

HTML

Responsive Images the Simple Way — оптимизируем загрузку картинок под нужное разрешение экрана.

SVG, Favicons, and All the Fun Things We Can Do With Them — меняем картинки в зависимости от темы.

CSS и CSS in JS

PostCSS 8.0.

Atomic CSS-in-JS.

90 Seconds on CSS Custom Properties.

Creating Playful Effects With CSS Text Shadows — как сделать 3D-текст?

Building a Scalable CSS Architecture With BEM and Utility Classes — строим БЭМ в 2к20.

CSS Scrollbar With Progress Meter — стилизуем прогресс прокрутки скроллбара.

How to Style Your React Apps with Less Code Using Tailwind CSS and Styled Components — стилизуем React-форму.

Level Up Your CSS Animation Skills — видеокурс по CSS-анимациям.

LCH colors in CSS: what, why, and how?— что такое LCH-цвета и зачем они нужны?

Разбираемся с новыми свойствами:

• @property;
• mask-repeat.

Строим Motion Path на CSS и JS:

• Create a Responsive CSS Motion Path? Sure We Can! (CSS);
• Different Approaches to Responsive CSS Motion Path (JS).

Добавляем темную тему:

• Building dark mode on Stack Overflow;
• Dark mode and variable fonts;
• Implementing Dark Mode In React Apps Using styled-components;
• Improved dark mode default styling with the color-scheme CSS property and the corresponding meta tag.

Статьи из блога Ахмада Шадида о CSS:

• CSS Findings From The New Facebook Design;
• Image Techniques On The Web;
• Overflow In CSS;
• Spacing in CSS;
• Selection in CSS.

Изучаем CSS Grid:

• The Ultimate Guide to CSS Grid — все, что нужно знать.
• 4 CSS Grid Properties (and One Value) for Most of Your Layout Needs — как CSS Grids могут помочь решать различные повседневные задачи?
• Thinking in Behaviors, Not Screen Sizes — разбираемся, как работать со свойством gap.

JavaScript

ECMAScript 2020: the final feature set — что войдет в новый стандарт JavaScript?

Creating Scheduled Push Notifications — назначаем push-уведомления, используя Service Worker’ы.

how to manage HTML DOM with vanilla JavaScript only?— подборка кейсов манипуляции DOM на чистом JavaScript.

Разбираемся с нативными API:

• The .classList() API;
• An introduction to the Web Contact Picker API — работаем с книгой контактов на мобильных устройствах;
• How to Detect Idle Browser Tabs with the Page Visibility API — определяем неактивные вкладки, используя Page Visibility API;
• Monitor your web page’s total memory usage with measureMemory()— экспериментальное API по отслеживанию памяти в браузере;
• WebSocketStream: integrating streams with the WebSocket API.

Storage for the web — как лучше сохранять данные в браузере?

Учим JavaScript за написанием игр:

• Learn JavaScript by Building 7 Games;
• How I Built My Own Tetris Game from Scratch with Vanilla JavaScript.

Typescript

Видеокурс по основам TypeScript.

Продолжаем разбирается с TypeScript в блоге Акселя Раушмайера:

• Types for classes as values in TypeScript;
• Typing functions in TypeScript.

Performance

Web performance checklist — начинать нужно с чек-листа.

The Cost of Javascript Frameworks — сравниваем время загрузки, обработки, выполнения, а также затраты памяти современных фреймворков.

Improve your Website’s Performance with Real User Monitoring — покрываем наш ресурс мониторингом производительности.

Optimising the Fonts on My Website — оптимизируем шрифты.

Performance monitoring in CSS animations — как лучше делать анимацию с точки зрения производительности? Смотрим под микроскопом.

Improved Next.js and Gatsby page load performance with granular chunking — новый способ уменьшения дублирующего кода в приложениях Next.js и Gatsby путем оптимизации Webpack-чанков.

React и React Native

A Sneak Peek at React Router v6.

How Animations Work in React Native.

Why I Switched to React Native to Create a Super Easy Bottom Sheet.

Упрощаем приложение с React-хуками:

• Getting Started With The React Hooks API;
• Best Practices With React Hooks;
• How to Create a Custom React Hook and Publish it to npm;
• Fetching Data in React using Hooks.

Строим приложения, используя React-хуки:

• Building a CRUD App with React Hooks & the Context API;
• How to Build a Simple Pokémon Web App with React Hooks and the Context API.

Обрабатываем формы:

• Using Formik to Handle Forms in React;
• React Hook Form — An Elegant Solution to Forms in React.

How to Build a TodoApp using ReactJS and Firebase.

Vue.js

Getting Started With Nuxt.

How the Vue Composition API Replaces Vue Mixins.

An Overview of What’s Coming in Vue 3.

More i18n with Vue: Formatting and Fallbacks.

Introduction to Vue Custom Events.

Using Vue Template Syntax to Build A Photo Gallery.

Angular

Make Your Angular Directive Functionality Lazy.

Angular 9 для начинающих, статьи от Free Code Camp:

• How to Install Your First App with Angular CLI;
• Components and String Interpolation.

Svelte

The Svelte Compiler Handbook — как работает Svelte под капотом?

Настраиваем голову на Svelt в двух частях: часть 1 и часть 2.

Node.js

Смотрим новую версию Node.js:

• Node.js version 14 available now;
• What’s Async Local Storage in Node.js v14?

Exploring Node.js Internals — что таит Node.js под капотом?

A Practical Guide to Memory Leaks in Node.js — ищем утечки памяти.

Performance Best Practices: How to Run and Monitor Express.js in Production — настраиваем мониторинг.

PWA Tutorial: How to Build a Geolocation App Using MongoDB, Node.js, and Express.js — отслеживаем геолокацию.

How we 30x’d our Node parallelism — как распараллеливание Node.js сэкономило компании $300 000 в год.

Браузеры

Апдейты Chrome:

• New in Chrome 81;
• Deprecations and removals in Chrome 83.

Статьи от Webkit:

• Web Animations in Safari 13.1;
• A Tour of Inline Caching with Delete.

Инструменты и библиотеки

Redaxios — минималистичная версия Axios.

Vite — экспериментальный дев-сервер для Vue.js.

Blitz — фреймворк на Next.js для создания фулстек-приложений на React.js.

Phelia — пишем приложения для Slack на React.

Editly — видеоредактор командной строки на JavaScript.

Reactive-Resume — строим резюме на JavaScript.

COVID-19 в мире JavaScript

Awesome Coronavirus.

COVID-19 — получаем актуальные данные:

• NovelCOVID;
• Covid19;
• Corona CLI;
• Coronavirus Tracker CLI;
• COVID-19 Scenarios;
• COVID 19 API.

COVID-19 в Индии:

• Covid19 India Cluster;
• Covid19 India React.

Строим интерактивную COVID-19 карту:

• How to create a Coronavirus (COVID-19) Dashboard & Map App in React with Gatsby and Leaflet;
• How to add Coronavirus (COVID-19) case statistics to your React map dashboard with Gatsby.

Послушать

Веб-стандарты:

• Выпуск 224: Safari и Chrome, ES2020, дизайнеры и код, палитры, анимации, устаревший Git Flow и видеоплееры;
• Выпуск 225: The F-Word, новинки браузеров, AVIF, WebStorm 2020.1, PostCSS 8.0, CSS-нудизм и тёмные темы;
• Выпуск 226: Браузеры, Chakra Core, Shower 3.0, jQuery, Гитхаб, ES-импорты, TC39, Телеграм против веба;
• Выпуск 227: Сайт Веб-стандартов, cssunderhood, Chrome, цвета, кастомные свойства, Brotli, цена фреймворков.

devschacht:

• Выпуск 113: Три проблемы nest;
• Мониторинг node.js на примере интересного кейса.

Фронтенд Юность (18+):

• Выпуск 131: Первый трёхмерный;
• Выпуск 132: Самый нерабочий;
• Выпуск 133: Самый беспилотный;
• Выпуск 134: Всё выглядит сложно, если ты тупой;
• Выпуск 135: Хуки лучше хоков.

CSSSR:

• Argumentarium — Коронавирус: удалёнка или страх и ненависть в IT;
• World Wide Work — Китай, Ухань, в гостях Арарат Мартиросян;
• Новости 512:
  
  • Новые тарифы Github, Three.js, SVG, frontendbookmarks, Vue 3 Beta.2, security-релизы git и Oracle;
  • Юбилей новостей, лямбда-JS, Ubuntu 20.04 LTS, NodeJS 14, Laravel 7.7, ещё security-релизы.

JS Party:

• #120 WFH!?
• #121 What even is a micro frontend?
• #122 What’s new and what’s Next.js;
• #123 JS “Danger” Party;
• #124 We got confs on lockdown.

CodePen:

• #260: Remote;
• #261: Following and Activity;
• #262: Dee;
• #263: A New Editor Vue;
• #264: Community Roundup.

Smashing Podcast:

• Episode 13 With Laura Kalbag: What Is Online Privacy?
• Episode 14 With Rachel Andrew: How Can I Run Online Workshops?

Остальное

Front-End Challenges — подборка сайтов с заданиями — от верстки до алгоритмов.

An abbreviated history of JavaScript package managers — история пакетных менеджеров npm, yarn и pnpm.

С вами был Григорий Шехет. До новых встреч =^.^=

← Предыдущий выпуск: Front-end дайджест #38.

Харьковчанин Евгений Мамут — специалист по кинематографическим спецэффектам, стоял у истоков компьютерной анимации в СССР. После переезда в США работал над 700 рекламами и 40 кинокартинами, среди которых «Голубая лагуна», «Грязные танцы», «Один дома», «Матрица», «Куда приводят мечты». Лауреат премии «Оскар» в номинации Scientific and Engineering Award за разработку трюк-машины для фильма «Хищник». Обо всем этом и о многом другом мы поговорили с Евгением Мамутом в интервью для DOU.

Лучшие годы — на флоте

— Я на самом деле для вас подготовила очень много вопросов, не знаю прям, как всё успеть задать... Вы были в Украине в ноябре 2019 года, участвовали в презентации фильма. Расскажите немного о нем?

Этот фильм сделала киностудия FRESH production по книге Станислава Сукненко «Из Украины в Голливуд». Он написал её примерно 2 года назад, а до этого больше 10 лет он копал, копал информацию... Потому что найти людей, которые из Украины попали в Голливуд, было очень сложно. Ведь когда они туда приезжали, они укорачивали фамилии или меняли имена, фамилии. Сукненко провел огромную работу, чтобы найти более 100 человек из Украины в Голливуде. И теперь по книге сняли фильм. В ноябре съёмочная группа презентовала свой фильм в городах Украины. Они пригласили меня и Ирину Борисову (супруга Евгения Шамаевича; по профессии Ирина Борисова — художник, мультипликатор, иллюстратор и пр. — прим. ред.)участвовать в презентации. Мы побывали в Харькове, Тернополе, Киеве...

— Вы родились в Ташкенте, а потом уже переехали в Харьков... В каком возрасте?

Я был совсем маленький, может, года три мне было... Так что ничего не помню.

— Получается, все сознательное детство уже прошло в Харькове.

Да. Одно из ранних воспоминаний: мама с папой пошли в театр Шевченко со мной. Я начал плакать, меня начали передавать по рядам, и только так смогли успокоить.

— Читала, что вы сменили три школы...

Да, все правильно. Глубоко копаете.

— А после школы?

В школе я любил работать в мастерской, делал всякие физические приборы, получил там четвертый разряд токаря. Я любил математику, физику. Сделал теодолит (геодезический и астрономический угломерный инструмент — прим. ред.)под руководством учительницы математики Нины Тoмасовны.

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

— Вы же отлично учились, почему были такие проблемы с поступлением и допуском?

В те времена было так.

— То есть это были причины, не связанные с учёбой?

Да, конечно.

— Целых 4 года вы служили...

Да, целых четыре... О, это были самые лучшие годы моей жизни!

— Даже так?

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

— Ничего себе...

Вы ожидали, наверно, дедовщину и прочее. Но там и близко такого не было.

— Когда вы вернулись, чем стали заниматься?

Я надел свою парадную морскую форму, явился обратно в ХПИ в отдел кадров и сказал, что я хочу вернуться на экспериментальный завод токарем. Начальник отдела кадров сказал: «Добро пожаловать! Мы рады приветствовать наших тихоокеанских матросов! Пожалуйста, давайте паспорт». Я ему паспорт, он посмотрел и сказал: «Извините, зайдите через неделю». Потом было снова «через неделю», ещё «через неделю»... А затем мне по блату устроили интервью на должность механика на кафедре ДПМ. Я пришел туда и увидел, что у них есть проблема с изготовлением датчика ускорения. Тонкая нихромовая проволока все время рвалась. Я забрал его домой и на следующий день принес работающий датчик. И меня взяли механиком в ХПИ.

— Но вы же и образование успели получить?

Когда я служил на Тихом океане, я попросил разрешение у командира корабля поступить на заочное отделение Дальневосточного политехнического института. Сначала ответ был таков: «На срочной службе не разрешено». Но когда я попросил в двадцатый раз, он сказал: «Хорошо, но есть два условия. Первое — никто об этом не должен знать. Второе — если ты хоть раз за четыре года пожалуешься, что у тебя не хватает времени, я сразу же это дело зарежу». Я согласился, и за четыре года ни одной жалобы от меня не поступило. Там я закончил два курса и после демобилизации перевелся в Харьковский политехнический на вечернее отделение. И как раз работал одновременно механиком на кафедре «Динамика и прочность машин».

— Я читала, что в это время у вас были и патенты, и медали...

Авторское свидетельство за датчик электрических измерений неэлектрических величин и медаль ВДНХ за модель электростанции с управляемыми предохранителями.

Модель электростанции для ВДНХ

Из списанного с военной базы трансформатора сделали мультстанок

— Такие были достижения... Не было жаль бросать эту сферу ради совсем другой?

Нет, сфера на самом деле была та же самая. Дело в том, что я увлекался техникой, физикой, математикой... Так случайно получилось, что в то время я попал на премьеру спектакля «Баня» Маяковского в постановке Керцера. Когда началось действо, я весь дрожал и подумал: «Что это за антисоветчина пропагандируется у нас на сцене?». Я начал оглядываться, представляя, что сейчас зайдёт рота автоматчиков и арестует весь зал...

Я еле-еле дождался конца, побежал в библиотеку, нашёл «Баню»... И когда прочел, то увидел, что все было слово в слово — ничего там Керцер не выдумал. После этого я увидел объявление о наборе в студенческую любительскую киностудию и пошел туда записаться, так как понял, что там мои единомышленники. У меня спросили: «Что ты хочешь делать? Быть режиссером? Актером?». Я ответил: «Нет, я ничего этого не умею и не хочу. А что у вас еще есть?». Мне говорят: «Ну вот, звукооператор». Вот это уже было по мне, так как ближе к технике.

Там была кинолаборатория, которая выполняла заказы кафедр. Они придумывали какие-то изобретения, а мы снимали. Например, рост магнитных доменов. Съёмка под микроскопом. И тут же на базе кинолаборатории была любительская киностудия. Это и стало толчком моей любви к кинотехнике. Именно к кинотехнике, а не к кинематографу. Потому что в кино я совершенно не разбираюсь. Меня интересует только техника.

— В Харькове никогда не было серьезной киностудии. Что из себя представляла киностудия ХПИ?

Там был энтузиаст — Владимир Петрович Зубарь, который достал всю профессиональную технику. У нас была 35-миллиметроваяаппаратура: «Конвасы», кинокамеры «Москва», «Родина», проявочная черно-белая машина, машина печати... Он доставал всё списанное с «Мосфильма», с Одесской киностудии. У нас было всё-всё. Когда я попал в Америку, там был тот же монтажный стол, те же звукозаписывающие аппараты. Мне не пришлось переучиваться. То есть техника в США 40 лет назад была точно такой же, как у нашей любительской киностудии в ХПИ.

— Удивительно. На киностудии ХПИ вы проводили эксперименты, которые были совершенно инновационными для того времени?

Да. Например, на киностудии не было мультстанка. Но тот же Зубарь достал списанный с военной базы трансформатор для расшифровки аэрофотоснимков. Мы переделали его в мультстанок и начали снимать мультфильмы. Но мы не знали, как это делается. Поэтому я поехал в Киевскую студию научно-популярных фильмов. Там очень приятная женщина сказала: «Я вам помогу». И дала мне по большому секрету книжку Уолта Диснея по раскадровке движений. Я приехал в Харьков, переснял эту книгу и отослал ее обратно.

Так мы начали изучать мультипликацию. Набрали группу художников. Многие из ХИСИ у нас были, в том числе Оля и Ира Борисовы.
А ещё мы делали титры и вставки для научных фильмов.

Первый мультик на ЭВМ

— А если конкретнее? К примеру, расскажите о мультике «Ванька-встанька».

К нам в студию пришел майор Владимир Бартеньев и сказал: «Давайте снимать стереомультики». Он рассказал нам про основы стереоизображения. Мы загорелись. И сделали мультик с цветными анаглифами — это красный и зелёный фильтры. Потом я повез его в Киев в телестудию и предложил пустить по всей Украине. А они: «Давайте, конечно. Но у людей же дома нет таких очков». Но мы привезли с собой очки и смотрели стерео на телемониторе.

Интересно, что когда я приехал в Америку, то лет через 20 во всех «Макдональдсах» объявили: в такое-то время по такому-то каналу вы можете посмотреть маленький сюжет. И по тому же методу, что мы делали два десятка лет назад в Харькове. В «Макдональдсе» бесплатно раздавали очки, чтобы люди могли посмотреть стереоскопический фильм.

— Я где-то читала, что это был первый стереоскопический мультик в Украине...

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

— А второй эксперимент с использованием компьютерной графики?

Когда я сейчас говорю вашему поколению слово «компьютер», вы сразу представляете фильмы, Skype, соцсети и так далее. В 1972 году этого ничего не было. Компьютер — это была огромная машина, занимавшая всю комнату. В эту машину вы закладываете перфокарты, на которых есть отверстия. Компьютер что-то считает, считает и выдаёт вам результат с принтера на длинном листе бумаги, где буквы и цифры напечатаны точками... Когда я прочел в газете, что инженер Безродный из «Промстройниипроекта» в Харькове изобрёл вывод изображения из компьютера на экран осциллографа или на платтер, то я прибежал к нему и сказал: «Давайте делать мультфильм».

Статья

То есть его компьютер мог на экране осциллографа рисовать кружочки, прямые линии... Он применил это для распечатки строительных чертежей. Я ему сказал: «Мне нужно, чтобы из треугольника получился на экране квадрат. Вы можете это сделать?». Он ответил: «Да, но мне нужно много программного времени на это». Тогда я попросил показать готовые программы. «О, как раз это то, что нам надо. У вас есть программа сечения». То есть мы могли построить пирамиду: в основании квадрат, а на вершине треугольник, и каждое сечение, каждая плоскость давала нам плавное изменение квадрата в треугольник.

Мы сделали такой примитивный фильм под названием «Азбучная истина». Но для того времени это было шок. И доказательство того, что компьютер может не только принимать и выпускать цифры и буквы, но и рисовать что-то на экране. Этот фильм я отвёз на «Союзмультфильм» показать Хитруку (известный советский режиссёр, художник и сценарист мультипликационного кино — прим. ред.). Мы встретились с Федором Савельевичем, и я начал ему петь песню: «Сколько вы копеек, рублей сэкономите, если будете использовать ЭВМ». Он мне ответил: «Меня это не интересует. Я только знаю, что компьютер сможет нарисовать то, что человек не может нарисовать». Это было 50 лет тому назад, и он был прав: вы сейчас видите, что компьютер в мультфильмах творит чудеса и человеку недоступно такое нарисовать.

— А батик-эффект? Я читала, что это тоже ваше изобретение.

Да, это была очень интересная работа с художником-мультипликатором Ириной Борисовой в 1978 году. Мы делали мультик по стихотворению Бориса Заходера про носорога. Положили шелк на пяльцы, потом невидимым клеем нарисовали контур носорога и сверху капали красками разных цветов. А камера была снизу и в реальном времени фиксировала, как расплывалась эта краска и проявлялся носорог. Это был цветной фильм, так что надо было показать все цвета. Мы поехали в Киев, проявили его. Но когда я уехал за границу, моё имя вырезали из титров, потому что я считался врагом народа.

— А потом не добавили обратно?

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

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

— Как же получилось так, что при всех этих успехах вы переехали в Америку?

Я не мыслил своей жизни без русского языка, без украинских песен, поэтому не хотел и не думал никогда переезжать. Но получилось так, что моя сестра с родителями поехали на год раньше и начали меня звать. Я говорил: «Нет, нет, нет. Я никуда не поеду. Я не могу без украинских песен. И потом у вас там безработица, угнетают черное население, угнетают рабочих...». И начал спрашивать, как это всё происходит. И мне сестра ответила: «Да, у нас забастовки, конечно, бывают. Но эти забастовки имеют право устраивать только те, кто в профсоюзе. Если он не состоит в профсоюзе, то бастовать не будет. И происходит это примерно так: человек зарабатывает 50 долларов в час, а хочет 100. И тогда он бастует». В этом я, кстати, убедился, когда приехал в Америку. Как раз бастовали сценаристы, потому что вместо 100 долларов в час хотели 200.

— Вы переезжали сами или с семьей?

Я переезжал с женой и 5-летнейдочкой. Мама написала: «Ничего с собой не берите. Берите Таньку и горшок». Понимаете, это был 1978 год, в то время на семью разрешалось поменять только 400 долларов. А надо ехать через океан в неизвестность, не зная, будешь ли ты работать или нет... Было очень страшно.

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

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

— В одном из интервью вы сказали, что вас «променяли на зерно»...

Да, тогда был неурожай в Союзе. И Америка согласилась продавать зерно, если Советский Союз начнёт выпускать евреев. Так мы и уехали.

Ни разу не показал диплом

— Когда вы переехали в США, то показывали свои работы, пытаясь устроиться на работу?

Когда я переехал, мне сказали: «Даже не пробуй устроиться на киностудию». Потому что приезжали люди из «Мосфильма», «Ленфильма», и у них ничего не получилось. Я на это не надеялся и разослал где-то 200 резюме в разные конторы как инженер-электрик. Из 200 резюме мне ответили всего на несколько, в том числе с трансформаторного завода. Я поехал туда, а там вообще ужас. Страшный район, поэтому туда я не стал устраиваться.

— И вы рискнули податься в киноиндустрию?

Помните ту встречу с Хитруком? Тогда он мне показал книгу о том, что делается в компьютерной мультипликации в других странах. В конце книги была библиография с адресами и телефонами людей, которые занимались этой самой компьютерной мультипликацией по всему миру. Я попросил переснять её. В Америке вспомнил об этой книге. И позвонил мультипликатору Джошу Розбушу и сказал: «Я нашел ваш номер телефона в книжке по компьютерной мультипликации, которую мне подарили в Москве. Можно с вами встретиться?». «Ну давай, приходи». Когда я пришел, Розбуш сказал с порога: «У меня для тебя работы нет, но я хочу знать, что делается в Союзе по компьютерной мультипликации».

У меня и сейчас ужасный английский, а тогда вообще был ноль. Но с карандашом и бумагой мы кое-как друг друга поняли. Тогда же это все было на зачаточном уровне: только палочки и кружочки. Но потом Розбуш сказал, что у него есть друзья в Университете Лонг-Айленда. Там тоже есть кинолаборатория, которая занимается этим вопросом. Он при мне позвонил туда и назначил для меня встречу на понедельник.

А еще до этого я побывал в киностудии EFX Unlimited. Показал журнал «Техника кино и телевидения», где была напечатана наша статья о мультике «Азбучная истина». Но мне сказали, что у них работы для меня нет: «Don’t call us, we will call you».

Когда я уже готовился идти на новое собеседование, мне позвонили из EFX Unlimited: «У нас заболел чистильщик пленки, так что, если хочешь, приходи завтра на работу. Но не в галстуке, а в джинсах, потому что это работа не для галстука». И я не пошел на встречу в понедельник. Но как раз в EFX Unlimited оказались те, кто потом стали великими киношниками: Джефф Клейзер, Джоэл Хайнек, теперь уже известные по всему миру обладатели множества наград (Джоэл Хайнек — лауреат «Оскара» за визуальные эффекты к фильму «Куда приводят мечты» (1998) — прим. ред.). Так что мне очень посчастливилось оказаться в студии, которая находилась в двух комнатках на 44-йулице в Манхэттене.

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

Да-да. Это была киностудия WorldЕffex. Там мне сказали: «Ты overqualified. Мы тебя взять не можем: ты через месяц уйдешь, а нам нужен человек, который будет работать постоянно». Что интересно, я у них увидел камеру «Дебри» начала 20 века, времен Чарли Чаплина, с ручкой, которую нужно крутить. У нас в Харькове была такая же, списанная с одной из киностудий. Мне было смешно, что мы на одном уровне: любительская студия и студия, которая в Манхэттене. Но как раз этот хозяин позвонил боссу профсоюза Нью-Йорка. Тогда профсоюзы были очень сильные: никто не мог без их разрешения взять на работу или уволить ни одного рабочего. Вот именно этот босс и устроил мне потом интервью на EFX Unlimited.

— Куда вас позвали чистильщиком пленки...

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

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

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

Первый опыт: реклама Renault и фильма «Флэш Гордон»

— Итак, вас поставили на трюк-машину...

Да, это было невероятное стечение обстоятельств. Там работал тот же Джефф Клейзер, у которого сейчас две киностудии. Джефф меня спросил: «А ты видел фильм „2001: A Space Odyssey“ Стэнли Кубрика?». И рассказал мне, как Дуглас Трамбалл (известный в Голливуде мастер визуальных эффектов — прим. ред.)сделал Slit Scan Effect (сканирование щелью).

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

Это легко понять на простом сканере. Положите ладонь на сканер и просканируйте. Получаем ладонь. Опять просканируйте, но ладонь двигайте вдоль движения. Получите удлиненную ладонь. А если двигать ладонь против движения, получаем укороченную ладонь. Так вот, Джефф Клейзер дал мне ключи от студии и сказал: «В любое время экспериментируй. Сколько хочешь используй черно-белой пленки и проявки. И вперед!». Я этим воспользовался. И ночами, и днями экспериментировал и придумал вот этот эластик-эффект, который потом использовался во многих рекламах и фильмах.

— В каком фильме или рекламе впервые использовались ваши эффекты?

В рекламе фильма «Флэш Гордон» (1980), машины Renault... Потом киностудия попросила нас сделать эффект для фильма «Хищник», чтоб Хищник был виден, когда движется, и был не виден, когда стоит на месте. Мы с Джоэлом Хайнеком усовершенствовали эластик-эффект и получили камуфляж-эффект.

Не хотели отпускать на вручение «Оскара»

— Расскажите о его сути.

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

В эластик-эффекте я использовал от 100 до 1400 масок, а в камуфляж-эффекте — от 6 до 12. То есть это было гораздо проще сделать, но результат получился очень красивый.

— Ожидали ли, что получите «Оскар» за этот эффект?

Нет-нет. Не за эффект, а за разработку трюк-машины, на которой стал возможен камуфляж-эффект.

Мы тогда работали по 17 часов в день. Никто ничего не ожидал. Это даже получилось случайно. Один из сотрудников киностудии Стюарт Робертсон предложил: «А давайте подадим заявку за разработку трюк-машины». Она управлялась компьютером. То есть не компьютерное изображение, а машина с моторами, которые управлялись компьютером. Для того чтобы сделать камуфляж-эффект, я ее модернизировал и поставил два дополнительных обтюратора (затвор, периодически перекрывающий световой поток в киносъемочных, кинопроекционных и других аппаратах — прим. ред.). Наша студия подала заявку на «Оскар», на номинацию Scientific and Engineering Award. Это была самая продвинутая трюк-машина в то время. Сейчас она уже часть истории и находится в Нью-Йоркском музее кино.

— Какие были ощущения, когда узнали, что выиграли?

Никаких. Ощущения были сейчас, 32 года спустя, в Тернополе, когда мы приехали на презентацию и все говорят: «Оскар», «Оскар». А тогда никто на это внимание не обращал.

— Вы говорили, что в то время очень много работали?

Да. Про заявку я даже не знал. Но потом в один прекрасный день секретарша приносит письмо из Киноакадемии: «Вы выиграли „Оскар“, приезжайте на презентацию...». На «Оскар» подавали меня, Джоэла Хайнека (моего супервайзера) и хозяина киностудии. Проходит день, два... А мне ничего не говорят. Я тогда пошел к хозяину и говорю: «Я получил такое письмо. Что делать?». Он сказал: «Я знаю, я тоже получил такое письмо. Мы поедем туда и привезем тебе приз». Я говорю: «Подожди, подожди. Я что, не могу поехать?». А он мне: «Понимаешь, на следующей неделе надо выпускать фильм. И если мы этого не сделаем, то представляешь, какая будет неустойка? Так что ты оставайся, а мы поедем».

— Обидно!

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

— А вы говорили, что уже позже встретились с Арнольдом Шварценеггером...

Да, он мне тогда показался таким маленьким. Курил сигару, не мог двух слов связать. На экране он производил совсем другое впечатление. Но сейчас я посмотрел в интернете: у него рост 182 сантиметра, у меня — 175. То есть он должен быть выше меня, но почему-то таким мне тогда не показался.

— Он вас благодарил?

Понимаете, у нас же постпродакшн. Мы получаем негатив, делаем комбинированные съемки и отсылаем новый негатив обратно. Поэтому мы обычно с актерами не встречаемся. Но когда мы закончили «Хищник», Шварценеггер пригласил нашу команду в ночной клуб. Была музыка, все танцевали, облепили его, говорили друг другу: «How are you?», «How are you?», «Thank you», «Thank you». То есть такое вот было общение: «Как поживаешь? Как дела? Спасибо, спасибо!».

«Голубая лагуна», «Один дома», фильмы Вуди Аллена

— Я читала, что вы работали где-то над 40 фильмами...

Да, где-то так. Хотя мы в основном делали рекламы. Но да, за это время прошло около 700 реклам и больше 40 фильмов. Комбинированные съемки — это 20–30 фильмов.В некоторых мы делали титры. Например, в фильме «Грязные танцы». Там в начале замедленное чёрно-белое изображение, они танцуют, а в это время проходят красные титры. Это не просто буквы. Это в своем роде тоже художественное произведение. Замедленное изображение я осуществил посредством наплывов в 6 кадров. Впервые мы это применили в мультфильме «Носорог» на киностудии ХПИ. Или «Один дома»... Там тоже были интересно сделаны титры.

— А для «Голубой лагуны» что вы делали?

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

— А «Леди-ястреб»?

Там превращение. Когда Мишель Пфайффер превращается в ястреба, а потом обратно в человека. Там ещё в титрах я не Юджин, а Евгений. Кстати, Джефф Клейзер — единственный человек в Америке, который продолжает меня называть «Евгений». Потому что ему нравится «Евгений Онегин».

— Все остальные называют Юджином?

Сначала я писал свое имя через «Y» — «Yevgeny», но скоро увидел, что всё равно никто не может это произнести. И я начал писать «Eugene» — Юджин. А потом и вовсе поменял имя официально.

— А в «Матрице» что вы делали?

Я выполнял там обычную техническую работу: перепечатка, ротоскопинг и так далее, но ничего не придумывал. То же самое, к примеру, в фильме «Куда приводят мечты».

Вообще журналисты напридумывали, что я получил два «Оскара», что придумал эффект застывшего времени в «Матрице»... Всяких неточностей в интернете хватает. В «Матрице» мы использовали 120 фотоаппаратов для эффекта застывшего времени. Уже в нашем музее я придумал, как сделать такой эффект с помощью восьми зеркал (Евгений Шамаевич вместе с супругой Ириной Борисовой создали частный музей анимации, спецэффектов и искусства Animagic — прим. ред.).

— А фильмы Вуди Аллена?

С ними интересно. В кинобизнесе это же всегда competition, соревнование. И Вуди Аллен боялся, что кто-то заберёт его идеи до того, как выйдет фильм. Поэтому, когда он приносил свои негативы на студию, он никогда не говорил, как называется проект и о чем. А рассказывал: «Вот на площади Таймс-сквер стою с девочкой и что-то делаю. Это тридцатые годы. А потом известный бейсболист, который жил тогда... он на стадионе, я хочу его туда впечатать...». И когда он приносил свои фильмы, то говорил: «Это проект называется „Зимний проект“. А этот — „осенний“, этот — „весенний“...». Мы никогда не знали, что делаем. А потом, когда фильм выходил в прокат, мы видели результат своей работы. Например, так было с «Зелигом» (1983).

Компьютерные игры и собственный музей

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

С Джеффом Клейзером, Джоэлом Хайнеком. Многие из моих бывших коллег сейчас преподают в колледжах. Например, Робертсон, Мразовский, Гейсек... Передают студентам свои навыки.

— А какие рекламы самые запоминающиеся?

Когда взорвался Чернобыльский реактор, это было на обложке журнала Time. Мы как раз делали рекламу для них и применяли мой эластик-эффект. Потом запоминающаяся реклама машины Renault, которая растягивалась, заворачивая за угол. Конечно, сейчас на компьютере это можно сделать очень просто. И такие эффекты, как я делал в «Хищнике», тоже. Например, план в 7 секунд, над которым я трудился две недели, сейчас на компьютере я сделал за 10 минут. Компьютер — это великое дело.

— А еще чем вы занимались?

Когда началось развитие электронной мультипликации и отдел оптической печати закрылся в R/Greenberg Associates (смешно, но моя должность называлась Optical Cameraman; часто, когда я заполнял анкеты, меня спрашивали: «А починить мои очки вы можете?»), то я пришел работать к Джошу Розбушу. Его офис был на 13-мэтаже Карнеги-холла в центре Манхэттена. Там мы делали компьютерные игры, но моя работа была чисто технической. Я много придумал всяких эффектов для игры Area 51. Но вдруг это всё прекратилось. Когда я спросил, почему так, Джош ответил мне: «Всё, все игры на DVD остановились. Инвесторы все деньги пускают на развитие интернета».

— Какие еще были проекты за эти несколько лет?

«The War in Vietnam» (1995) — интерактивный каталог всех карт, людей, действий, статей газеты New York Times, роликов новостей CBS за период Вьетнамской войны. Но там тоже я делал техническую работу. «Look What I see» (1996) — обучающий DVD для Metropolitan Museum of Art.

— Вы создали музей анимации и спецэффектов «Animagic». Расскажите о нем.

Мы создали его с моей супругой в 2002 году. Ирина Борисова участвовала в создании многих реклам для телевизионных каналов США, для компаний Burger King, Hallmark, Blue Cross... Она работала со всемирно известным аниматором Томом Гэйсеком, который делал «Каролина в стране кошмаров», «Уоллес и Громит», «Бегство из курятника» (последний мультфильм занимает 1-еместо в списке самых кассовых кукольных мультфильмов — прим. ред.). Когда они делали рекламы, там был очень красивый интерьер, на него постоянно приходили поглядеть. И в один прекрасный день Том сказал: «Мне уже настолько надоели эти люди, которые приходят посмотреть. Надо музей устроить». А я ответил: «Вот это идея!». И мы с Ириной сделали музей, где показываем историю мультипликации и комбинированных съемок, которые были сделаны здесь в Беркшире.

У нас в Массачусетсе собрались многие киностудии, потому что тут прекрасное место в горах, туристический район. Много озер, красивая природа, а зимой лыжные курорты. Поэтому к нам приходит много туристов. Мы обучаем людей от 5 до 80 лет, как делать элементарные мультики. Это простая покадровая съемка, они лепят из пластилина фигурку, фигурка танцует. Но вы бы видели: люди приходят такие уставшие, унылые... Но когда они сами сделают свой первый в жизни мультик, все выходят радостные, с улыбающимися лицами. Например, на прошлой неделе у нас был мужчина, который раньше работал судьей, а сейчас на пенсии, ему уже за 80. А талантливые малыши иногда даже с 4 лет могут сделать такой элементарный мультик.

— Читала, что и за 90 бывают посетители...

Мы у них паспорт не спрашиваем, но с виду — да.

— А постоянные ученики есть?

Да. Туристы приходят и уходят. Я им показываю, как они могут дома на телефоне продолжать делать мультики. А есть и группы, которые живут в округе, с ними мы постоянно занимаемся и сделали несколько мультиков.

— Что недавно делали?

В нашем музее мы сделали «голографический» полет тени отца Гамлета. А еще мы с супругой Ириной Борисовой сотрудничаем с Харьковским театром кукол. С Игорем Мирошниченко и Ириной Рабинович много чего понапридумывали.

— Ваша статуэтка «Оскара» тоже в музее?

Да. Под стеклом.

Главный секрет успеха

— А ваши дети, чем они занимаются?

Дочка живёт в Сан-Франциско, а сын — в Нью-Джерси. Татьяна изучала антропологию и экономику в Университете Беркли, доктор экономических наук. Преподавала марксизм в Беркли (когда я ужаснулся, она мне объяснила, что преподавала не политику, а экономику), работала на руководящих позициях в Amazon, сейчас — в социальной сети Nextdoor. Там общаются те, кто живут по соседству. Журнал Forbes назвал Таню одной из самых креативных женщин 2019 года. Сын Саша — программист, работает в интернациональной компании iHeartRadio — это трансляция радиопередач по всему миру. А его супруга — оперная певица.

— А внуков у вас много?

У меня две внучки в Сан-Франциско. Старшую зовут Алина, а младшую — Мира. На русском знают только три слова — «привет», «спасибо» и «пожалуйста».

— Какое, на ваш взгляд, самое главное ваше достижение?

Я считаю, что моя самая интересная работа — «Хищник». Мы сделали два фильма: «Хищник» и «Хищник-2». Много вопросов было поставлено, много задач решено. Рад, что мы тогда в Харькове в Политехническом институте сделали первый в Советском Союзе сюжетный мультфильм на компьютере. Это было началом того, что сейчас называется компьютерная анимация.

— А сейчас, когда эпоха компьютерных спецэффектов, нет желания заниматься этим?

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

— Нет чего-то, что вы хотели бы изменить, если бы была такая возможность?

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

— Какой главный секрет успеха, как вы считаете?

Главное — на работе не отбывать повинность, а чтобы было интересно. Мне посчастливилось, что я всю жизнь просто игрался на работе. Мне иногда так и говорили: «Женька, я работаю, а ты играешься». Если вы идете на работу, чтобы отсиживать часы, то ничего хорошего не добьетесь. А если вам нравится ваше дело, то будет успех.

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

Результати діяльності найбільших ІТ-спільнот

Kharkiv IT Cluster

Наразі харківська IT-спільнота в межах проєкту IT4Lifeзібрала понад 6 млн грн.

Кисневі траси

Харківський ІТ-кластер будує кисневі траси у лікарнях. Це збільшить кількість ліжко-місць з підведеним вологим киснем у реанімаційних відділеннях. За висновками лікарів-експертів, серед яких відомі в Харкові лікарі Андрій Пєньков, Олександр Золотарьов, Олег Яковенко, своєчасно наданий вологий кисень (навіть на нетривалий час — 2-3 доби)дає змогу запобігти ускладненням при захворюванні на COVID-19. Це сприяє швидшому одужанню хворих у стані середньої важкості, яких найбільше. Водночас пацієнти не потребують використання дороговартісних апаратів ШВЛ.

Зараз уже збудована киснева траса на 12 ліжко-місць у Харківській обласній клінічній інфекційній лікарні на суму 110 тис. грн (профінансувала компанія Dev.Pro). В обласному спеціалізованому диспансері радіаційного захисту населення сьогодні монтують кисневу трасу на 39 ліжко-місць загальною вартістю 245 тис. грн (профінансувала компанія DataForSEO).

Тепер кластер шукає фінансування на будівництво кисневої траси для Харківського обласного центру онкології.

Концентратори та кардіографи

15 квітня Kharkiv IT CLuster доставив кисневі концентратори та кардіографи у Харківську обласну клінічну інфекційну лікарню та Харківську обласну дитячу інфекційну клінічну лікарню. Закупівлю профінансували компанії Team International та StepInvest.

Медичні захисні щитки

3D-студія StuffHouse3d виготовила для лікарень Харківської області захисні щитки, вартість яких майже у 14 разів нижча за ринкову. 6 квітня разом з волонтерами ІТ-спільноти Kharkiv IT CLuster закупив і доставив понад тисячу захисних щитків до міських та обласних опорних лікарень. Робота із забезпечення регіону щитками триває, тому кластер шукає 3D-студії в інших регіонах або студії, які можуть надати в тимчасове користування 3D-принтери, для масштабування та колаборації.

Дізнатися докладніше про проєкт #IT4Life та долучитися можна за посиланням.

Lviv IT Cluster

Львівський ІТ-кластер наприкінці березня запустив проєкт United for Health. За перший тиждень ІТ-компанії зібрали 3 млн грн. Загальна сума наразі становить 6 млн грн. Перелік усіх, хто долучився, можна переглянути на сайті.

Насамперед волонтери замовили 20 тис. експрес-тестів на виявлення COVID-19. Після консультацій з медиками пріоритетною ціллю визначили саме запуск масового тестування населення у Львівській області. Всі тести передано місцевому та обласному штабам оперативного реагування.

Що встигли зробити в межах проєкту:

• 23 березня запустили кампанію з масового тестування населення у співпраці з обласною та міською владою. На той момент влада ще вагалася, чи доцільно тестувати усіх експрес-тестами. Станом на 30 квітня ними протестовано 24 997 осіб, виявлених підозр — 161.
• Спільно з фондом «Відкриті очі» розпочали збір коштівпоза межами спільноти.
• Протестували журналістів Львова, які не припиняють працювати під час карантинних обмежень. 21 квітня зробили тести 82 журналістам. Усі результати тестів — негативні.
• Розробили ІТ-рішення для боротьби з коронавірусом, залучивши компанії. Це інтерактивна картапоширення коронавірусу у Львові та області від N-iX; Viber чат-бот для швидкого збору результатів тестування від Chatbots.Studio; чат-бот для масового опитування населення про самопочуття від Bots Crew.
• Долучилися фінансово до проєкту страхування медиків (надали частину коштів, які були зібрані у межах United for Health). Спільно з партнерами область сформує страховий стабілізаційний фонд для виплат медикам, які інфікувалися коронавірусом. Зокрема, одноразову виплату у розмірі 15 тис. грн надаватимуть медичним працівникам, у яких діагностували коронавірус з допомогою ПЛР-тесту.

CEO Club Ukraine

Станом на 10 квітня до проєкту долучилося понад 82 людини, з них багато СЕО українських IT-компаній. На 27 квітня коштом середнього та великого бізнесу зібрано $426 800 (11 млн грн). Учасники проєкту створили ініціативну групу, яка працює над визначенням потреб медзакладів. І вже закупили 15 апаратів штучної вентиляції легень на суму $129 тис. Наступний етап — закупівля індивідуальних засобів захисту для медичного персоналу.

Результати благодійної діяльності IT-компаній

SoftServe — 10 млн від компанії та понад 2 млн від спеціалістів

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

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

«Ми зустрілись з неабиякими викликами — на доставку певного обладнання потрібно чекати до травня. Були випадки, коли країни закривали експорт товарів медичного призначення, а в нас вже були договори на етапі підписання з постачальниками з тих країн. Врешті нам потрібно було починати пошуки спочатку, — розповідає Вікторія Міщук, в.о. директора БФ „Відкриті очі“. — Водночас нам вдалося закрити частину нагальних потреб у засобах захисту та придбати експрес-тести на COVID-19. Більшість цих засобів ми вже передали або зараз передаємо в лікарні».

Загалом фонд придбав: 11 500 масок респіраторного типу (виробництво Україна), 1000 масок респіраторного типу 3М (США), 600 медичних костюмів, близько 4000 тест-систем (тип «One Step Test COVID-19 IgG / IgM device»), 2 апарати ШВЛ («Блізар», Україна), 7 500 костюмів індивідуального захисту для лікарів (Китай), 4000 захисних окулярів (Китай), 7 апаратів ШВЛ експертного типу V8600 (США).

EPAM — 7 млн від компанії та понад 500 тис. від спеціалістів

Загалом для протидії COVID-19 компанія виділила 7 млн грн. Також організовано збір коштів #TogetherAsOneсеред спеціалістів ЕРАМ. Зібрана сума становить 530 849 грн.

З виділених 7 млн компанія передала 5,5 млн грн на допомогу українським медичним закладам у межах партнерської угоди з фондом ЮНІСЕФ. Закупили важливе реанімаційне обладнання, безконтактні термометри, пульсоксиметри, кисневі концентратори. Очікують доставку другої партії кисневого обладнання, витратних матеріалів, безконтактних термометрів. Їх передадуть у лікарні Чернівецької, Івано-Франківської, Київської, Донецької, Луганської, Одеської та Черкаської областей.

Крім того, компанія виділила близько 1,5 млн грн на потреби медичних закладів тих міст, де є офіси EPAM. Це Київ, Львів, Харків, Вінниця та Дніпро. Місцеві медичні заклади звернулися по допомогу до локальних ІТ-спільнот. Закуплено захисні костюми (Дніпро), засоби для дезінфекції та кисневе обладнання (Харків). У Львові спільно з місцевим кластером ЕРАМ підтримує проєкт масового тестування населення United for Health.

Спеціальний проєкт EPAM UA is #TogetherAsOne займається збором коштів серед спеціалістів компанії на потреби лікарень у Києві, Харкові, Львові, Вінниці та Дніпрі. Медичні заклади підтримали понад 8 тис. фахівців, які співпрацюють з компанією, а також всі охочі.

У межах ініціативи #TogetherAsOne в різних містах планують закупівлю речей відповідно до нагальних потреб медзакладів.

У Києвізбирають гроші на потреби Київської міської клінічної лікарні № 9 та міської клінічної лікарні № 1:

• багатофункціональні монітори пацієнта VP 1000 (потрібні для спостереження за станом пацієнта в реанімації в режимі 24/7);
• два компресори для подачі стиснутого повітря на наркозно-дихальне обладнання та апарати штучної вентиляції легень;
• дихальні маски FaceFit (для підключення пацієнтів до дихального апарата);
• 1000 комплектів протиепідемічних для роботи зі збудниками І-IV групи патогенності;
• біохімічний аналізатор Mindray BS240 — для оперативного проведення аналізів крові та контролю стану пацієнтів.

• костюми індивідуального захисту для медичних робітників (при взаємодії з хворими);
• захисні прозорі щитки;
• захисні окуляри.

• захисні костюми для лікарів;
• респіратори.

• захисні комбінезони з водостійким покриттям;
• респіратори класу FFP2 або FFP3;
• рукавички нітрилові з довгою манжетою;
• захисні окуляри або щиток.

• рукавички нітрилові;
• респіратори;
• мікросепти для обробки рук і шкіри;
• захисні комбінезони (для біозахисту);
• захисні медичні окуляри.

WePlay! Esports — 3 млн від компанії та понад 5 млн грн ($188 879), зібрані на турнірі

Три млн спрямували на закупівлю апаратів ШВЛ для Хмельницької міської дитячої лікарні, Київської міської клінічної лікарні № 9 та обласної дитячої лікарні у Кропивницькому, по одному апарату на кожну лікарню.

Компанія також провела благодійний кіберспортивний онлайн-марафон WeSave! Charity Play — змагання з Dota 2. Зібрані кошти $188 879 передали в організації CEPI та GlobalGiving. CEPI займається розробкою вакцини, а GlobalGiving закуповує маски, захисні засоби, обладнання для медзакладів.

MacPaw — 7 млн грн

Компанія в рамках ініціативи #MacPawCares придбала:

• 2000 захисних костюмів з Китаю та 5 апаратів ШВЛ з Німеччини (усього на суму понад 6 350 000 грн). Апарати встановлять у тих лікарнях, де прийматимуть хворих на COVID-19, зокрема в Надвірнянській та Галицькій центральних районних лікарнях, а також одній з лікарень Києва;
• 2000 продуктових наборів на суму 500 тис. грн для людей похилого віку, дітей учасників АТО, а також людей з обмеженими фізичними можливостями в Києві для підтримки ініціативи фонду «Життєлюб»;
• пластик на суму 100 000 грн. Передала його та 3D-принтери компаніям, що за допомогою цього обладнання друкують захисні щитки для лікарів;
• одно- та багаторазові респіратори для рятувальників, що ліквідують пожежі у Чорнобилі, а також вологі серветки, рукавички, воду та їжу (загалом на 87 800 грн);
• обладнання для рятувальників Kyiv Animal Rescue Group (KARG) на 50 000 грн.

У кінці квітня для своєї команди компанія організувала безконтактну доставку #MacPawCares Home Kit. Привозили комплекти одноразових рукавичок і масок, лимони та апельсини, вітаміни й антисептики. Крім того, спеціалістам доставили офісні стільці, щоб робота з дому була комфортнішою.

На знак підтримки українських лікарів костел Святого Миколая у Києві змінив підсвічування на біло-червоне у межах акції «Лікарі — наші герої!» компанії Expolight. Проєкт підсвітки будівлі реалізували раніше за ініціативи MacPaw, а також компаній Ring Ukraine, SD Capital та комплексу «Торонто-Київ».

Поїздка в Чорнобиль з допомогою для рятувальників

Ajax Systems — 3 млн грн

У цю суму входять кошти компанії та особисто СЕО Олександра Конотопського, які він передав координаційному штабу СЕО Club Ukraine. Організація спрямувала їх на закупівлю апаратів ШВЛ, масок, захисних костюмів, антисептиків та іншого приладдя для захисту лікарів. Ці засоби вже прибули в медустанови по всій країні.

Також Ajax Systems застосовує свій багаторічний досвід в електроніці для профілактики апаратів ШВЛ. Купують необхідні комплектуючі (клапани, датчики температури, видиху, кисню, акумулятори) і проводять діагностику та калібрування апаратів. Три апарати вже відремонтовані та повернулися у лікарні. На черзі ще 50 з усієї України.

Для підсилення експертизи у команду проєкту шукають спеціалістаіз досвідом ремонту ШВЛ.

Moneyveo — 3 млн грн

На ці кошти купили 3 апарати ШВЛ S1200 експертного класу та медичні щитки для лікарів. По одному апарату ШВЛ доставлять у Київську міську клінічну лікарню № 9, Чернівецьку обласну клінічну лікарню та Тернопільську міську комунальну лікарню швидкої допомоги. Медичні щитки відіслали в лікарні Вінниці та Борисполя. У закупівлі допомогли Українська біржа благодійності та фонд «Корона».

Ciklum — 2,5 млн грн

Гроші передали у фонд «Таблеточки». З них мільйон грн піде на безпечне транспортування медиків до та з лікарень у межах проєкту «Лікарі на роботі», що здійснює компанія Uber у співпраці з Міністерством охорони здоров’я України. Проєкт діє у сімох містах: Києві, Одесі, Львові, Дніпрі, Харкові, Запоріжжі та Вінниці. За планом лікарі матимуть 5000 безкоштовних поїздок на роботу.

А 1,5 млн грн спрямують на закупівлю засобів індивідуального захисту та ліків для дітей, хворих на рак.

Компанія також розпочне внутрішній збір коштів.

ELEKS — 2,13 млн грн

У цю суму входять і благодійні внески спеціалістів.

Наразі компанія:

• профінансувала пошиття 2000 захисних костюмів для медиків від львівської фабрики спецодягу «Маріо»;
• закупила 2000 респіраторів Бук-3 FFP3 для Львівської лікарні швидкої допомоги;
• придбала 2000 експрес-тестів у межах співпраці компанії з ІТ Cluster Lviv (проєкт United for Health).
• виділила 509 тис. грн на закупівлю ПЛР-реагентів для високоточної діагностики коронавірусу в лікарнях Львова. Раніше аналізи треба було відправляти до Києва і чекати на результат кілька днів. А тепер ці тести робитимуть на місці, результат займе кілька годин;
• закупила 10 оксигенераторів Capiox Fx25 з інтегрованим артеріальним фільтром і твердостінним резервуаром для Львівської лікарні швидкої допомоги;
• придбала 6 кисневих концентраторів;
• купила 2000 захисних костюмів з бахілами та масками для лікарень Києва;
• закупила 1000 масок в Українського товариства глухих і передала їх в «Охматдит», Київ;
• зібрала канцелярію з київського офісу та відвезла в Київську лікарню № 8;
• придбала 200 захисних костюмів для медзакладів Франківська та Тернополя;
• розіслала всім спеціалістам компанії пакунки з рукавичками, антисептиками та масками;
• фінансово підтримала страхування медичного персоналу у Львові та області, ініційоване Львівською облдержадміністрацією.

NIX — 1,9 млн грн

Компанія придбала та передала медичним закладам:

• 3 апарати УЗД для ранньої діагностики запалення легень;
• 500 пар захисних масок та окулярів;
• 500 респіраторів;
• 300 захисних костюмів;
• 2000 хірургічних масок;
• 3000 пар хірургічних рукавичок;
• 100 літрів антисептика.

Апарати УЗД передали міським поліклінікам № 10 та № 11 та лікарні швидкої та невідкладної допомоги імені проф. О. І. Мещанінова Харкова. Засоби індивідуального захисту та медичні матеріали розподілили між опіковим відділенням Харківської міської лікарні швидкої та невідкладної допомоги № 4, відділенням інтервенційної кардіології інституту Зайцева, ДУ «Національний інститут терапії імені Л. Т. Малої Національної академії медичних наук України» та Харківським госпіталем ветеранів, який через пандемію переобладнали в інфекційну лікарню другої лінії.

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

Лікарі Харківського госпіталю ветеранів приміряють нові захисні костюми

iDeals Solutions — 1,7 млн грн

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

Крім того, на ці кошти придбано 1000 захисних костюмів для лікарень Києва.

Компанія співпрацює безпосередньо з лікарнями у Вінницькій, Хмельницькій, Чернівецькій областях, закуповуючи для них обладнання та витратні матеріали. Зокрема, це респіратори, захисні костюми, рукавички. Фінансує ремонт апаратів ШВЛ. Для Хмельницької міської дитячої лікарні придбає три камери для зберігання стерильного інструменту.

Intellias — 1,5 млн грн

Ці гроші компанія виділила на закупівлю 10 000 тестів для швидкої діагностики коронавірусної інфекції. Першу партію — 5000 тестів — вже отримали й передали Львівському ІТ-кластеру, який спільно з обласною та міською владою запустив кампанію тестування населення у місті та області. Другу партію тестів очікують незабаром.

Також компанія закупила набори індивідуальних засобів захисту для співробітників і доставила їх додому.

Львівський ІТ-кластер. Масове тестування населення

Innovecs — 1,5 млн грн

Цією сумою розпоряджається створений компанією фонд Innovecs COVID-19 Fund. У межах діяльності фонду закупили та встановили кисневу магістраль у Київську міську клінічну лікарню № 17. Це опорна лікарня, яка спеціалізується на легеневих захворюваннях. Нова магістраль охопить одразу кілька корпусів та дасть змогу одночасно рятувати до 60 людей. Її вартість становить 486 тис. грн.

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

N-iX — 1,5 млн грн

Компанія поставила собі за мету забезпечити працівників, їхні сім’ї та велику кількість українців тестами на COVID-19. Для цього створили спеціальний благодійний фонд, який наповнюється 50 на 50 працівниками та компанією. У фонд уже вдалося зібрати 1,546 млн грн (співробітники пожертвували 773 тис. грн, решту додала компанія; у травні очікують додаткові надходження у фонд). Частину цієї суми використали для закупівлі 8 тис. експрес-тестів у межах проєкту United for Health Львівського ІТ-кластера. Перші 2 500 тестів уже прибули з-за кордону. Їх використали для масового тестування у Львові та області, частину передали для потреб кількох медичних закладів у Київській області. Також організували тестування для кількох працівників компанії.

Крім того, компанія надає свою експертизу — допомагає розробити ІТ-рішення для львівських облдержадміністрації та міської ради. Серед них — інтерактивна картапоширення захворювань на COVID-19 у Львові та області.

Компанія планує підтримати заклик Львівської обласної держадміністрації щодо закупівлі засобів для захисту медиків міста та області.

Readdle — 1,2 млн грн

1,2 млн грн компанія пожертвувала на придбання апарата ШВЛ, який уже встановлено в Одеській лікарні водників. Також працівники зробили особисті пожертвування, так з’явилася ініціатива #MeandReaddlecare. Зібрану суму компанія подвоїла (усього вийшло 460 тис. грн) і планує купити тисячу респіраторів і тисячу біокостюмів для лікарів. Координувати цю діяльність допоміг БФ «Корпорація монстрів».

Новий апарат ШВЛ в Одеській лікарні водників

GlobalLogic — 1 млн грн

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

Частину коштів витратили на закупівлю 9 пульсоксиметрів, 18 мобільних інфузійних стендів, 12 медичних маніпуляційних столів і багатофункціональної каталки. Все це передали у Харківську міську клінічну багатопрофільну лікарню № 17. Частину обладнання скерують в інші медичні заклади регіону.

170 тис. грн компанія пожертвувала на проєкт United for Health Львівського ІТ-кластера.

Наступними кроками буде закупівля 1000 респіраторів класу FFP2 та 1000 комплектів захисного одягу для лікарів. Ці засоби повністю відповідають рекомендаціям МОЗ, їх відішлють у Київський центр швидкої медичної допомоги (для 24 відділень швидкої допомоги по всьому місту, загалом для 194 бригад).

Govitall — 700 тис. грн

У цю суму входять кошти компанії та співробітників. Підтримали такі організації: БФ «СВОЇ», Українська біржа благодійності ubb.org.ua, CEO Club Ukraine. Допомогли Київській дитячій лікарні № 2 і Київській міській дитячій клінічній інфекційній лікарні. Благодійники закупили монітори для апаратів ШВЛ, шприци, ЗІЗ, тонометри тощо.

Також передали 10 тис. грн у фонд «Клуб Добродіїв» для підтримки рятувальників, що гасили пожежі неподалік Чорнобилю.

Infopulse — 580 тис. грн

Група волонтерів компанії спільно з благодійним фондом «Діти надії та любові» реалізовує проєкт допомоги лікарям первинної ланки Житомира «Вантажівка здоров’я». Допомагати лікарням саме цього міста вирішили з кількох причин. По-перше, у великих містах сконцентрована більша кількість великого соціально відповідального бізнесу, який підтримує медзаклади, ніж в обласних і районних центрах. Там, на жаль, лікарні фінансуються винятково місцевим бюджетом, якого недостатньо для повноцінної підготовки для боротьби з COVID-19.

По-друге, Житомир — локація другого за кількістю спеціалістів офісу компанії, Infopulse є найбільшим представником ІТ-індустрії міста.

Станом на 17 квітня зусиллями спеціалістів компанії (благодійні внески спеціалістів і топменеджерів) було зібрано 580 071 гривня та закуплено такі засоби захисту для медиків:

• 2000 респіраторів;
• 100 захисних щитків;
• 1000 захисних костюмів, які наразі чекають на доставку.

Також розробники компанії на волонтерських засадах створили чат-бота @zakaz_ua_bot, який відстежує вільні слоти на доставку із магазинів Києва: «Ашану», «Мегамаркету», NOVUS, «Метро» та «Фуршету». Під час карантину попит на онлайн-замовлення та доставку продуктів значно зріс. Через великий ажіотаж люди були змушені регулярно оновлювати сторінку сайту та «ловити» вільні часові проміжки. А бот надсилає сповіщення, коли в магазині з’являється такий слот, тому користувач може одразу перейти на сайт і зробити замовлення.

Житомирські лікарі розбирають нові щитки та респіратори

Genesis — 400 тис. грн

У компанії продовжують шукати лікарні, яким потрібна допомога, тож сума пожертв буде зростати. Серед тих, кому вже передали кошти: благодійний фонд «Свої», комунальні некомерційні підприємства «Київська міська клінічна лікарня № 17», «Центр первинної медико-санітарної допомоги № 2» Шевченківського району Києва.

Насамперед купують засоби захисту для лікарів: маски, костюми тощо.

Dev.Pro — 230 тис. грн

У цю суму входять пожертви від компанії та її фахівців. Компанія спрямувала свої сили на три регіони: Харків, Київ і Дніпро.

У Харкові приєдналися до проєкту IT4Lifeвід Харківського IT-кластера. Наразі допомогу надають інфекційній лікарні № 22. Профінансували ремонт кисневих трас на суму 100 тис. грн. Компанія планує продовжити співпрацю з кластером та допомагати харківським лікарням.

У Києві долучилися до київської ініціативи AntiVirus. Зараз допомагають лікарні № 4 в закупівлі медичних рукавичок і респіраторів на суму майже 27 тис. грн.

У Дніпрі компанія у співпраці з Dnipro IT Community в рамках проєкту «Бізнес Дніпра vs COVID-19»фінансує придбання багаторазових захисних костюмів для лікарень міста. Наразі закуплено 67 костюмів на суму 26 800 грн.

Netcracker — 128 тис. грн

Київський офіс компанії разом з благодійним фондом «Твоя опора» запустив збір коштів серед співробітників. Загалом було зібрано 92 386 грн. На ці гроші закупили два професійні пульсоксиметри вартістю 1 400 євро кожен і розхідні матеріали для лікування хворих на решту суми. Все це передадуть у Київську міську клінічну лікарню № 4.

Одеський офіс у співпраці з БФ «Твоя опора» зібрав 12 тис. грн. На ці кошти купили 45 дезінфекторів і 1000 пар нітрилових рукавичок для Одеського обласного центру екстреної допомоги та медицини катастроф.

У Сумах фахівці робили внески у фонд «Бізнес — місто». Загальна сума від співробітників компанії становить 23 тис. грн.

Agiliway — 121 тис. грн

Менеджмент компанії здійснив перший внесок для подолання пандемії на суму 67 500 грн. Працівники теж підтримали ініціативу — переказали частину місячного заробітку (від 3 до 5%) у цей фонд — усього 53 730 грн. Разом зібрали 121 230 грн. Цей грошовий фонд розділили між двома офісами у Львові та Чернівцях.

У Львові кошти спрямували на закупівлю необхідних речей у Львівську міську клінічну лікарню № 5. Зокрема, придбали 10 пульсоксиметрів, 5 наборів для інтубації, 50 захисних екранів, 100 захисних масок, 100 респіраторів класу FFP2, 40 костюмів підвищеного захисту.

У Чернівцях кошти скерували для допомоги Хотинській центральній районній лікарні та Вашківецькій районній лікарні. У хотинську лікарню закупили 40 захисних екранів, 64 захисні костюми, 10 костюмів підвищеного захисту, 190 респіраторів FFP1, 30 респіраторів FFP2. У вашківецьку — 40 захисних екранів.

Delphi Software — 100 тис. грн

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

Ще компанія фінансово підтримала вінницький мінізоопарк і притулок для тварин «Планета», які через карантин опинились у скрутному становищі.

KindGeek — 100 тис. грн

Гроші витратили на закупівлю ЗІЗ у лікарню швидкої допомоги у Львові. Це перше місце, куди потрапляють львів’яни з підозрою на COVID-19.

YouScan — 85 тис. грн

Компанія долучилася до фандрайзингової кампанії CEO Club. За зібрані кошти (від усіх учасників клубу) ініціатори вже замовили 15 апаратів ШВЛ і планують закупити засоби індивідуального захисту та інші необхідні медикам ресурси.

Cieden — 66 тис. грн

Переказали 43 тис. грн від компанії та 23 тис. від співробітників у благодійний фонд «Крила Надії», який зараз допомагає львівським медпрацівникам з устаткуванням та ЗІЗ. На початку квітня в компанії влаштували опитування серед працівників про можливі варіанти витрачання ЄСВ, який можна не платити у зв’язку з COVID-19. Співробітники мали вибір: продовжувати платити податки в державну скарбницю, отримати їх на ФОП-рахунок чи переказати їх у БФ. Саме таким чином зібрали 23 тис. грн.

Honeycomb Software — 50 тис. грн

Ці кошти витратили на закупівлю засобів захисту (маски, респіратори, костюми захисту) для лікарів швидкої допомоги у Рівному.

Також благодійними внесками допомагали:

• Luxoftприєдналась до проекту #Antivirus від асоціації IT Ukraine. В рамках проекту компанія передає лікарням конче необхідні їм зараз медзасоби, головним чином, ЗІЗ та обладнання — пульсоксиметри та комплектуючі матеріалів, які потрібні пацієнтам, підключеним до ШВЛ. Загалом допомогу отримають чотири медичних заклади: дві клінічні лікарні в Києві, одна із лікарень Дніпра та інфекційна лікарня в Одесі.
• Svitla Systemsпідтримала фонд «Центр Допомоги», який допомагає закуповувати необхідні засоби для інфекційних відділень українських лікарень і військового шпиталю.
• Redwerkчастково профінансувала (10 тис. грн) одну з акцій благодійного фонду Let’s help. За ці гроші було придбано продуктові набори для самотніх пенсіонерів. У Деснянському районі Києва 300 осіб отримали адресну допомогу. Також співробітники компанії допомагають самостійно.
• uptechпідтримувала організацію «Життєлюб», купувала продукти для літніх людей.
• bvblogicнадсилали кошти на допомогу медикам у фонд «StopCOVID-19.if». Згодом цей фонд об’єднався з іншими ініціативними групами міста в межах єдиного «Антикризового Фонду» для координації роботи. Основні його зусилля спрямовані на збір коштів, закупівлю та доставку необхідних засобів в івано-франківські лікарні.
• Blackthorn Vision — добровільні пожертви співробітників та кошти компанії скерували в Червоний хрест у Хмельницькому та фонд «Із Янголом на плечі» у Львові. Здебільшого організації закупляли маски, респіратори та костюми.
• JetSoftProу межах Lviv IT Cluster взяли участь у проєкті United for Health. Було придбано експрес-тести для працівників та їхніх сімей — 100 шт., ще 300 шт. передали на потреби міста.
• DevComбезпосередньо поспілкувалися з медичним працівникам 8-їклінічної лікарні Львова, яка приймає хворих на COVID-19. На їхнє прохання закупили й передали 270 респіраторів.
• TEAM Internationalдопомогла з купівлею електрокардіографа та кисневих концентраторів для Харківської обласної інфекційної лікарні, долучившись до проєкту IT4Life Харківського IT-кластера. Також компанія придбала 1000 тест-систем для виявлення COVID-19 для львівських лікарень.
• INSARTкупила необхідні речі (маски, респіратори, рукавички, халати тощо) для Харківської міської лікарні швидкої та невідкладної допомоги № 4 і долучилася до проєкту IT4Life Харківського IT-кластера.

Крім того, компанії відкривали безкоштовний доступ до своїх розробок: Gismart — до застосунку для зміцнення ментального здоров’я Music Zen, Poster — онлайн-вітрини для закладів харчування, що допоможе їм перепрофілюватися на доставку, Innovations Development Lab — застосунку Doctor Online (онлайн-консультацій лікарів). Створювали й окремі розробки, як-от Vilmate — застосунок «Підвези медика».

Редакція DOU вже спілкуваласьз ІТ-спеціалістами, яких звільнили через коронакризу. Ми вирішили також розібратись, як відбувається пошук роботи на карантині: чи змінилися процес найму, кількість вакансій, ставлення рекрутерів, і як загалом реагує ринок на кризу.

На умовах анонімності ІТ-фахівці поділились власними спостереженнями щодо пошуку роботи.

Ілюстрації Уляни Патоки

«Маленькі компанії шукають людину-оркестр»

Рік досвіду в ІТ, на останньому місці роботи — 7 місяців на посаді Рroject Manager/Creative Producer.

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

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

Процес найму на роботу не змінився: співбесіда з HR, ТЗ, інколи тест на логіку чи behavioral test, технічна співбесіда. Єдине, що дивує: коли дають ТЗ на 2-3 дні,а потім не відповідають зовсім або кажуть, що вже давно знайшли іншого кандидата. Чому одразу не сказати, не попередити?

Уже пройшла шість співбесід. На співбесідах у маленькі компанії створюється враження, що шукають людину-оркестр: щоб був і Account, i BA, i PM, і Product Owner. Проте коли запитуєш про гарантії чи те, як карантин вплинув на компанію, часто інтерв’юери ухиляються від відповідей.

А ще кажуть, що зараз велика черга з претендентів, або пропонують дуже низьку зарплату, оскільки є люди з досвідом в ІТ 4-5 років,які готові працювати за менші гроші. Але погодьтесь, смішно отримувати зарплату $600 з релокацією до Львова чи Києва, коли лише на витрати, пов’язані з житлом, йде $300-500.

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

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

«Ринок турбулентний: є багато вакансій, що вже неактивні»

18 років в ІТ, 5 місяців на посаді Embedded C++ Developer у компанії Agile Fuel.

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

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

Я пройшов п’ять співбесід: в одному місці сказали, що це трохи не моя сфера, в іншому — віддали перевагу кандидату, який просив меншу зарплату.

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

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

«Бачу класні вакансії, але якщо ремоут не розглядають — це не для мене»

12 років в ІТ (5 років — QA, 2 роки — UX-аналітик). На останньому місці роботи працював два роки у BA-відділі в американському стартапі на ремоуті.

Коронакриза застала стартап зненацька. Спонсори спрямували фінансування на боротьбу з вірусом, тому довелося скоротити витрати та звільнити частину співробітників. Ще в четвер ми нічого не підозрювали, а наступного дня (у п’ятницю 13-го :) начальник департаменту розповів про звільнення. Мені все виплатили разом з відпускними, пропонували допомогу з пошуком роботи.

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

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

Я пройшов уже близько 10 співбесід. У мене вузький сегмент, я UX-аналітик. В Україні є UI/UX-дизайнери, а в США аналітика і дизайнера розділяють. Тому більшість вакансій мені не підходить. До того ж мене цікавить продукт, а через аутсорс продуктових компаній в Україні не так багато.

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

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

«Варто звертати увагу на міжнародні проєкти й запастися терпінням»

17 років в ІТ, на попередньому місці роботи — в одному з топових медіахолдингів України — працював рік на посаді Project Manager.

Зі мною розірвали трудовий договір і сказали, що річ не в компетенції. Компенсували +2 окладу.

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

У двох компаніях я дистанційно пройшов дві повноцінні співбесіди, які складалися з чотирьох етапів. Рекрутер -> ТЗ -> HR-партнер компанії -> інтерв’ю з керівником напряму бізнесу. Враження позитивні, але ці компанії не з України. HR-бізнес-партнер поінформував, що термін онбордингу поки не можуть точно назвати, відбирають кандидатів на перспективу.

Тож сьогодні я рекомендую підтягувати навички в технологіях і спробувати створити свій проєкт (раджу AI). Навіть якщо не вийде, буде досвід проходження циклу створення продукту.

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

«Потрібно шукати скрізь: холодні листи рекрутерам, job-сайти, рекомендації»

13 років у Sales, понад два роки працював керівником департаменту продажів у компанії національного інтернет-провайдера.

Я сам вирішив звільнитися (ще на початку березня, до чуток про карантин). Наступного дня після звільнення почав шукати роботу.

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

Зараз, якщо немає фінансової подушки на 3-6 місяців,потрібно інтенсивно шукати роботу скрізь: холодні листи рекрутерам, job-сайти, рекомендації. Раджу прокачати профіль LinkedIn (англійською). Створити резюме не більш як на дві сторінки (хронологічне + опис компетенцій). Не вказувати кліше із серії «командний гравець», цілеспрямований тощо. Скласти розповідь із позиції «достигатора»: зробив, збільшив, скоротив, створив, переформатував тощо. Використати усі можливі канали пошуку, зокрема LinkedIn (outbound-листи HR). Передплатити LinkedIn Premium на місяць (безкоштовно) для більш чіткого пошуку.

«Моя стратегія пошуку роботи — проходити якомога більше співбесід, навіть якщо бракує знань і думаєш, що не візьмуть»

14 років досвіду в ІТ, QA. Попереднє місце роботи — продуктова компанія в Польщі, працював QA Lead два місяці.

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

У Польщі взагалі багато ІТ-компаній припинили рекрутинг, тому вперше за чотири роки шукаю паралельно роботу в Україні. Цікаво, що на відміну від Польщі, де рекрутери відповідають за 2-3 дні,в нас 85% реагують або того ж дня, або максимум наступного.

Я зацікавлений у ремоуті, але й готовий залишитись в Україні. Щодня проходжу співбесіди. Одна з них тривала три години, я розраховував на $4000, але запропонували лише $2500. На такий рівень це замало.

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

Тенденції до погіршення рекрутингу не бачу, трапляються різні люди: і професіонали, і не дуже. Рекрутинг України й Польщі, Америки та Канади відрізняється. Якщо команда суто українська — то розмова тривала і суха. Українські рекрутери не надсилають інвайти в календар, а пишуть у скайп, телеграм, інші месенджери. Це незручно: коли в тебе 3-4інтерв’ю на день, а треба підготуватись, почитати про компанію, налаштуватись, складно згадати, де ж те запрошення. До того ж, враховуючи переїзди, номер телефону може змінюватись. Зручно, коли інвайт у тебе в календарі.

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

«Час вчити англійську, бо є можливість виїхати за кордон»

Понад 10 років досвіду в ІТ, на попередньому місці роботи — 5 років на посаді розробника.

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

Мене як Java-розробника запитували про те, як працює Linux-ядро. На трьох співбесідах із п’яти ні слова про Java. Дехто не хоче брати, бо досвід 10+ років коштує дорожче, а є можливість найняти низькооплачуваних фахівців.

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

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

«Здивований, що компанії не пропонують віддалену роботу»

Більш як шість років досвіду в ІТ, попередня посада — QA TeamLead, 2,5 року.

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

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

Пройшов кілька співбесід. Здивований, що компанії не пропонують віддалену роботу. Я думав, після карантину це питання переглянуть.

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

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

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

«За березень-квітень мені так і не вдалося дійти до етапу співбесіди»

Досвід роботи в ІТ — 4 роки, з них — 2 роки на позиції QA Test Lead.

Мені зменшили заробітну плату на 35% і скоротили команду тестувальників з 4 до 2 людей. Невідомо, як довго існуватиме проєкт, тож наразі шукаю роботу «наперед».

Шукаю проєкт з початку січня, але тоді я розглядала вакансії Senior/Middle Manual QA з релокейтом у Польщу. У лютому почала проходити співбесіди на дві позиції, а в березні мене повідомили, що вакансії заморозили на невизначений період. Крім того, в березні ще з двох компаній отримала відповідь, що вони не розглядатимуть людей з іншої країни. Після цього почала пошук роботи remote, а таких вакансій сьогодні мало. Тож за березень-квітень мені так і не вдалося дійти до етапу співбесіди.

Якщо є можливість не працювати кілька місяців, то, звісно, краще шукати те, що до вподоби. Можливо, варто домовитись про знижену ставку на період кризи з подальшим підвищенням після стабілізації ситуації. Вважаю, поступитися розміром зарплати можна, а ось щодо компанії та проєкту, тут треба обирати те, що подобається, щоб працювати із задоволенням.

«Жодної співбесіди за місяць пошуків»

Досвід роботи в ІТ-сфері — 17 років. На позиції керівника відділу аналітики платної реклами (Google Ads, Bing Ads) в IJM Interactive (Коннектикут, США) більше ніж 12 років.

Формально керівництво мене не звільнило. За контрактом я консультантка, але багато років мала працювати тільки на цю агенцію. Після погіршення ситуації з коронавірусом керівництво повідомило, що контракт ще дійсний, але зарплати не буде. Оскільки я консультантка, а зараз мої консультації не потрібні. Мене повідомили про це за 30 днів. Роботодавець сподівається, що після закінчення кризи я робитиму деякі проєкти.

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

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

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

От редакции: в рубрике DOU Booksучастники сообщества рассказывают о пяти любимых книгах — тех, которые меняют мировоззрение и могут быть полезны читателям-коллегам.

[Про автора: Cергей Жук — Engineering Manager в Facebook, Калифорния. Специализация — мобильные приложения и запуск новых продуктов. Работал в украинском аутсорсинге, берлинском e-commerce Zalando, а в 2018 году переехал в США. Основатель блога для Android-разработчиков ProAndroidDev.com, автор Android-дайджеста на DOU]

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

Antifragile by Nassim Nicholas Taleb

В украинском переводе — Насім Ніколас Талеб «Антикрихкість. Про (не)вразливе у реальному житті»

В русском переводе — Нассим Николас Талеб «Антихрупкость. Как извлечь выгоду из хаоса»

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

Забавляют и примеры в других книгах автора. Так, в Fooled By Randomness (2001) он обсуждал возможность столкновения авиалайнера с офисным зданием. В Black Swan (2007) речь шла о возможном появлении некоего вируса, путешествующего по миру вместе с рейсом Air France.

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

The Undoing Project by Michael Lewis

История о дружбе и работе двух классиков когнитивной психологии — Даниела Канемана и Амоса Тверски. Их исследования стали опорой социальных наук конца XX века.

Автор описывает простыми словами научные проекты, которыми занимались Канеман и Тверски. Интересным примером будет оценка риска и потенциальной выгоды, также известная как теория перспектив (Prospect theory). Как поступит человек, если у него есть выбор: получить наверняка $100 или c шансом 50/50 получить $200. Эксперимент показывает, что выбором будет $100. Но если мы предложим другой выбор: потерять $100 наверняка или 50/50 потерять $200, люди предпочтут рискнуть. Мы по-разному оцениваем приобретения и потери, часто упуская возможность максимизировать прибыль.

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

Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley by Antonio Martinez

В украинском переводе — Антоніо Ґарсія Мартінес «Хаос у Кремнієвій долині. Стартапи, що зламали систему»

Рассказ о бурной жизни предпринимателей и приключениях работников техиндустрии в Кремниевой долине. Автор построил рекламную платформу, попал в стартап-акселератор и продал свой проект по частям в Facebook и Twitter.

В книгу вплетено много коротких историй. Среди них — о том, чему учат в Y Combinator, какие советы дает Пол Грэм, как работает защита интеллектуальной собственности, почему маленькие команды «бунтарей» все еще могут конкурировать с гигантами индустрии. Рекомендую всем, кто едет в Калифорнию искать новые возможности и создавать продукты.

Вас порадуют рассказы про исторические районы Долины. Например, Sand Hill Road — это Уолл-стрит для технологических бизнесов и инвесторов. Какими компаниями обросла эта местность и почему? И как венчурный капитал в начале 70-хгодов начал оседать вокруг Стэндфордского университета и компаний его выпускников, занимающихся полупроводниковыми технологиями.

«Из Ада в Рай. Избранные лекции по психотерапии»Михаила Литвака

State of the art в подборке лучших работ современных авторов, совмещенный с примерами из классической литературы: Библии, произведений Сенеки, Данте и даже Пушкина. 18 глав — 18 отдельных лекций — читаются легко. Они заново открывают таких «заезженных» гениев, как Абрахам Маслоу и Зигмунд Фрейд.

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

«Лестница в небо. Диалоги о власти, карьере и мировой элите»Михаила Хазина и Сергея Щеглова

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

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

Среди прочих примеров приводится альтернативная версия того, как Стива Джобса убрали из Apple в 1985 году. Авторы проследили присутствие в совете директоров нескольких влиятельных персонажей, о которых забыли упомянуть в классической биографиисоздателя iPhone.

Приятного чтения и до встречи на страницах ДОУ!

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

Я уже более 15 лет управляюпроцессами создания продуктов — от гипотез до устойчивых продаж. Последние два года вместе с fellow kottansпомогаю новичкам и свитчерам приобретать новые технические скиллы в разработке, развивать soft skills и находить первую работу в IT. Часто вижу у людей проблемы с презентацией своих навыков и личных проектов, в частности профиля и репозиториев на GitHub, поэтому и решил написать этот материал.

Сразу договоримся о контексте: речь будет идти о настройке профиля на GitHub для поиска работы.

Нужно ли это

Чаще всего от кандидата на позицию разработчика ожидают определённого уровня технических знаний. Новичкам особенно тяжело: практики мало, опыта прохождения технических интервью тоже не хватает или совсем нет. А ещё прескрининг... Код кандидата, написанный до интервью, может стать конкурентным преимуществом. Тестовые задания дают не только для того, чтобы проверить умение писать алгоритмы и оперировать структурами данных, но и чтобы увидеть подходы к решению задачи, структуру проекта и код. Любой код, доступный на этапе прескрининга, может стать предметом изучения интервьюеров ещё до первой встречи. И кто знает, возможно, вам дадут меньше тестовых заданий или вовсе обойдутся без них. А тесты — это же всегда стресс, сказывающийся на качестве работы.

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

Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит (см. Простое решение). Для некоторых тим- и техлидов увидеть code style и способ организации кода в проекте (особенно в отношении кандидата-джуна) лучше, чем услышать 1000 слов на собеседовании. Правильное оформление профиля и двух-трёх наиболее показательных репозиториев на GitHub поможет обойти конкурентов. А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub.

Во всяком случае, если уж и указывать линк на GitHub-профиль в резюме, то точно есть смысл помочь ревьюеру увидеть самое главное.

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

Если профиль пустой, возникает закономерный вопрос: зачем в резюме добавлена ссылка на GitHub-профиль и почему в списке проектов — пусто? Ответ «Ну, если надо, то добавлю» — плохой.

Начнём с проектов.

Что показать, если показать нечего

Никто (sic!) не ожидает увидеть уникальный проект на 100500 строк кода. Оценивать, скорее всего, будут уровень владения шаблонами проектирования, стиль кода, способность написать минимальную документацию, навыки работы с Git. Почему это всё важно? Потому что это о коммуникации. Это то, чего будут ожидать от сотрудника, помимо написания собственно кода. Код пишется в первую очередь для других людей.

Разумеется, могут оценить и уровень владения технологиями. Одно дело — прочитать в резюме «CSS3 — средний» или услышать ответ на вопрос «А что ты умеешь в JavaScript?». И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки.

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

Выберите два-три проекта, которые наилучшим образом отражают ваши навыки. Учебные тоже годятся (быстро допили незаконченные). Или добавьте одну-две простых игры типа крестики-нолики, Froggerили Memory Game. Все новички делают что-нибудь такое, но не все завершают и показывают. Не ищите оригинальности — это всё ради демонстрации навыков и умений. Демо не обязательно должны быть сложными, с анимациями, встроенным видео и миллионом визуальных эффектов. Достаточно одной фишки.

Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirko — погодное радио (нажми кнопку ON). В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом. Нестандартный вид учебного проекта — это и дополнительная мотивация в процессе выполнения (делать подобные интерфейсы в разы интереснее), и повышение вероятности того, что на такой проект работодатель обратит внимание.

Было бы здорово, если бы кто-то сделал ревью вашего кода.

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

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

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

Оформляем репозиторий

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

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

Краткое описание и ссылка на публикацию

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

Начать просто — нажмите кнопку Edit.

Например, было:

Стало:

В вебе выглядит так:

Источник: kottans stats by Igor Kurkov

Из Description, кстати, формируется содержание тега <title>страницы проекта, if you know what I mean.

Документация

Чаще всего README.md содержит одну только строку: # project-name.

Что должно быть в README.md:

• О чём проект? Например: «A movies database web application», «Rick and Morty universe REST server».
• Зачем этот проект? Например: «I mastered CSS animations, CSS Grid, CSS Flexbox» (пункты, разумеется, оформить отдельными буллет-поинтами).
• Ссылка на демо (да-да, ещё раз повторить то, что уже есть в описании — overcommunication не грех).
• Инструкции по сборке и запуску проекта. Это вот всё git clone … , yarn build …и прочее — как во взрослых проектах.
• Структура проекта, архитектура приложения, API — это тоже показывает навыки, необходимые разработчику.

Пишите всё это в синтаксисе markdown. Так мы демонстрируем владение ещё одним полезным навыком.

Цель этого не только дать читателю хорошее представление о проекте, но ещё показать отношение к документированию (не любить писать документацию можно будет потом) и базовые навыки подготовки документации. Смотрите, например, учебный проект с использованием The Movie Database API.

Источник: Movie Database by Vlad Vorobiov

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

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

Вот так README.mdможет выглядеть, когда опубликован:

Источник: Git course. Проект на GitHub

Продвинутые техники

Скриншоты, скринкасты

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

А скринкаст в виде гифки сделает демо ещё более наглядным. Пример: описание задачи в курсе по фронтенду. Гифку лучше захостить за пределами GitHub, допустим, на imgur.

Чем сделать такую гифку? Например, oCam for Windows. Можно записать скринкаст с помощью QuickTime для Mac или встроенными средствами Windows 10 (Win+G) и затем сконвертировать с помощью MOV to GIFили MP4 to GIF.

Для записи работы в терминале хорошо подходит asciinema.

Topics

На будущее: topics помогают проекту появиться в поисковых запросах. Какие ключевые слова вписывать? Начните с используемых в проекте технологий: JavaScript, ReactJS, Python, Java, C#, Laravel, PHP, REST, MongoDB, Node, PostgreSQL, SPA, web app, AMP, CSS, HTML... Добавьте два-три ключевых слова о самом проекте: game, casual game, database, movies, weather, demo, educational, tutorial... GitHub ещё что-нибудь подскажет из своего списка.

Например, было:

Стало:

Источник: React patterns, demo by Vitalii Ovcharenko

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

Промежуточный summary

На хорошо оформленный репозиторий можно дать прямую ссылку в резюме. Указывайте ее прямо в разделе Skills или Education — где релевантно. Это должна быть ссылка не такого вида github.com/username/repo, а аккуратная и лаконичная, хоть и выглядящая немного «по-инженерному», например: react-patterns project. Тут реальный путь скрыт за описанием проекта. Щёлкать по линкам уж все умеют, а читабельность заметно лучше.

Оформляем профиль

Титульная страница профиля на GitHub позволяет быстро оценить активность пользователя. Для ее оформления также можно использовать альтернативную визуализацию (на примере профиля Bohdan Kovalchuk) — прямо берите и вставляйте в резюме чарты.

Но давайте сравним два профиля на GitHub.

Невыразительный:

Информативный:

Источник: профиль на Github by Aleksey Ivanov

Чем отличается второй:

• не рандомная аватарка;
• есть имя (если профиль — ваше резюме, то чего стесняться?);
• статус явно говорит о том, что Алексей открыт к предложениям о работе;
• коротко описаны скиллы (Front-end, React, NodeJS);
• есть ссылка на профиль в LinkedIn;
• есть 6 отобранных проектов, с которых заинтересованный посетитель и начнёт изучение портфолио.

Зайдите в свой профиль сейчас, нажмите Customize your pinsи добавьте хотя бы 2-3самых показательных проекты. Затем в настройках профиля заполните всё, что возможно.

Делаем личное портфолио на GitHub

Знаете ли вы, что проект вида username.github.ioпосле публикации доступен, собственно, под таким именем? Вот пример личного сайта-портфолио (проект на гитхабе,Ruslan Sakevych):

Код

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

Стиль кода

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

Так что «причешите» код, который планируете показывать. Линтерывам в помощь (заодно научитесь настраивать, если ещё не умеете). Можно, не стесняясь, брать преднастроенные проекты — Open Source. Например, ESLInt-Prettier-Husky boilerplate для JS фронтендаили EodData CLient (Python, Aleksey Ivanov). Для вашего стека придётся поискать или поспрашивать кого-нибудь.

Коммиты

Комментарии коммитов тоже пишутся для других людей. Комментарии вида «added file», «fixed», «add code» и подобные (осторожно, вредные советы!) говорят о недостаточно хорошо развитых навыках изложения мысли и нелюбви к людям, которые будут читать ваш код. Самое время приобретать правильный навык. И лучше немного помучаться над текстами коммитов в учебных или пет-проектах, чем потом выслушивать от старших по званию коллег ворчливые замечания или вообще не найти желающих сделать код ревью.

Вот один из примеров читабельной истории коммитов: frontend project lvl1 by Sergey Shramko.

Простое решение

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

Вот даже говорят, что это всё бесполезно: почему GitHub не поможет нанять разработчика / Хабр

Выбор — за вами.

Итого

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

Свидетельства «очевидцев» из числа моих знакомых разработчиков-новичков:

Евгений, Front-end Developer: «У меня спрашивали про самый интересный проект: что делает, почему так, логику и связи модулей. Ещё открывали другой проект и по нему тоже задавали вопросы. Я уже пару месяцев как трудоустроился. По моему мнению, что сработало: 1. Множество тестовых задач с других собесов, часть из которых опубликовал на гитхабе; 2. Собственные нетипичные и работающие микропроекты».

Лена, Front-end Developer: «Задавали вопросы по моим проектам на нескольких собеседованиях. Смотрели портфолио. На одном просили прокомментировать самый интересный проект из примеров на гитхабе».

А у вас когда-нибудь смотрели портфолио? Помогало ли портфолио при поиске работы?

Что ещё почитать по связанным темам

• Что портит резюме разработчика
• Резюме ІТ-спеціаліста: розбір типових помилок з точки зору HR
• Что писать в резюме, если нет опыта работы
• Что написать в резюме, если нет опыта работы
• Что написать в резюме junior программисту без опыта работы? — Блог Виктора Зинченко
• Идеальное резюме Junior’а: как найти лучшую работу в сфере информационных технологий
• 3 tools to visualize your GitHub profile
• Инструменты для построения онлайн резюме
• DataArt запустил бесплатный сервис улучшения резюме CV Duck
• A Guide to Creating and Hosting a Personal Website on GitHub

Credits

Спасибо команде kottans и персонально Christina Landvytovych, Oleksandr Lapshynза поддержку и contribution в материалы статьи.

В качестве иллюстраций здесь используются проекты разработчиков, которые так или иначе имеют отношение к комьюнити kottans. Если вам какой-то из проектов понравится, не пожалейте поставить ⭐ на GitHub — вам обязательно воздастся :-)

Якщо ви тільки починаєте працювати з інструментами для Infrastructure as Code або думаєте, як інтегрувати його у ваш CI/CD-пайплайн — це стаття для вас. Ми з’ясуємо, як побудувати процес автоматизації інфраструктури та втілити Infrastructure as Code.

Стаття дає базовий огляд Infrastructure as Code як концепції і фокусується на методології і принципах її впровадження в щоденній розробці та деплойменті.

Дисклеймер: ця стаття НЕ є серйозною документацією щодо конкретних інструментів і технологій.

Що таке інфраструктура

Інфраструктура — це ресурси, які потрібні для підтримки коду. Водночас дехто може уявити серверні стійки, світчі та зміїне кубло кабелів... Але це вчорашній день. Сьогодні 99% проєктів живе в «хмарах». Тобто ресурси — це віртуальні машини, контейнери, load balancers.

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

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

Чому варто звернути увагу на Infrastructure as Code

Infrastructure as Code є (вже не таким) новим трендом, який розв’язує актуальну проблему автоматизації інфраструктури.

Багатьом із нас доводилося бути в схожій ситуації:

— Слухай, мені треба задеплоїти лоад-балансер...
— Вибач, у нас завал! Будь ласка, створи тікет у JIRA і повертайся за два дні...

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

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

Проблема масштабу

За моїми спостереженнями, один мікросервіс в середньому потребує 10-12інфраструктурних ресурсів (a load balancer, RDS instance, security groups тощо). Якщо в нас є три середовища — test, staging, production — то це вже близько 30 ресурсів. А якщо мікросервісів 10-20-100,проблема стає ще більш масштабною.

Проблема передбачуваності

Якщо створювати всі ці ресурси вручну, то питання «Що робити, якщоми припустимося помилки і наші середовища будуть відрізнятися; до яких багів це може призвести?» перетворюється на «Що робити, коли...» Бо вірогідність припуститися помилки в кількох сотнях ручних операцій наближається до 100%.

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

Шляхи розв’язання

У нас є перевірені методології роботи з кодом, які ми можемо використати. Ми вже знаємо, як побудувати процес: як код зберігати, тестувати і деплоїти.

Одна з найвідоміших методологій роботи з кодом — The 12 Factor App. Її популяризував один із хмарних провайдерів — Heroku. Серед цілей цієї методології такі:

• забезпечити максимальну портабельність між середовищами, зменшуючи ризик відмінностей та багів. Таким чином ми робимо можливим Continuous Deployment;
• зробити автоматизацію максимально простою. Щоб розробники не витрачали багато часу на початок роботи над проєктом.

І якщо ми пригадаємо наші проблеми, то це те, що лікар прописав!

З-поміж 12 принципів The 12 Factor App найголовнішими є:

• Codebase
• Configuration
• Logging
• Development/Production Parity

Codebase

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

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

Configuration

Але для автоматизованого деплойменту конфігурацію треба зберігати окремо від коду і надавати доступ до неї під час деплойменту. The 12 Factor App рекомендує робити це через змінні середовища. Це універсальний підхід, який працює на будь-який операційній системі. Понад те, це безпечний підхід, на відміну від аргументів командного рядка, адже змінні середовища не можна отримати з іншого процесу простим ‘ps aux’.

Logging

Під час деплойменту інфрастурктури нам треба контролювати стан деплойменту і стан системи загалом. І зробити це можна за допомогою логів. Щоб вони працювали будь-де, The 12 Factor App пропонує розглядати логи як потік евентів без кінця та початку, які відсортовані хронологічно і виведені в stdout.

Логування — це окрема проблема, яку можна розв’язувати за допомогою Fluentd, Elasticsearch або скеруванням в інший файл чи процес. Найголовніше, що логи у stdout можуть інтегруватися з будь-якою системою або працювати локально, коли ви займаєтесь дебагінгом.

Development/Production Parity

І найголовніший принцип — це Development/Production Parity (еквівалентність середовищ). Якщо ми зберігаємо код у системі контролю версій і використовуємо його як універсальне джерело істини, а в самому коді немає спеціальних кейсів для окремих середовищ, усі унікальні налаштування зберігаються окремо і доступні під час деплойменту як змінні середовища — ми отримаємо систему, де немає розбіжностей між середовищами (test vs staging vs production).

The 12-Factor App FTW

Так, у нас може виникнути ситуація на кшталт «для тесту мені потрібні два інстанси, а для продакшену — 50». Але тут буде різниця в налаштуваннях, а не в коді. І це відкриває нам шлях до Continuous Deployment. Якщо ми можемо автоматично задеплоїти та протестувати наші зміни, то можемо автоматично це робити в будь-якому середовищі.

Якщо наші логи доступні у stdout, а наша конфігурація доступна як змінні середовища, то в нас немає жодних проблем з інтеграцією із сучасними CI/CD-рішеннями. Travis CI, Gitlab CI, Github Actions, Jenkins та інші інструменти можуть читати код із системи контролю версій, давати доступ до конфігурації через змінні середовища та працювати з логами в stdout.

«Hello, World!», або З чого почати

Якщо ми почнемо гуглити «infrastructure tools», то можемо здивуватися з вибору, який є на ринку. Нам треба обрати інструмент, з яким не просто вдасться написати аналог «Hello, World!», а з яким буде зручно підтримувати реальну систему.

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

aws elb create-load-balancer  --load-balancer-name myELB  --listeners      "Protocol=HTTP,       LoadBalancerPort=80,       InstanceProtocol=HTTP,       InstancePort=80"  --subnets subnet-15aaab61

Ось приклад команди, яка створює load balancer за допомогою AWS CLI. На перший погляд досить прозоро, ця команда буде працювати, як заплановано, і створить load balancer... Але чи існують інші ресурси (subnets, security groups), на які ця команда посилається. Якщо ні, їх треба створити (а це ще кілька команд). Якщо ресурси існують, але в них інші ідентифікатори — треба знайти ці правильні ідентифікатори і підставити їх у команду.

А що, як load balancer вже існує? Значить, треба додати команду, яка перевірить його існування. А що, як у нього інші параметри, не такі, як потрібно? Отже, доведеться перевірити його стан — і загорнути нашу команду в if-else-statement: «Якщо ресурсу немає — створи, якщо є — зміни його параметри».

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

Декларативні vs імперативні інструменти

Проблема нестабільності скрипта спричинена тим, що AWS CLI — імперативний інструмент. Імперативніінструменти працюють за схемою «я хочу змінити світ, для цього зроблю X». Але якщо світ не є в тому стані, який ми очікуємо, то в найкращому разі інструмент нам поверне помилку і нічого не зробить, у найгіршому — зробить не те, що ми очікуємо.

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

Серед декларативних інструментів для AWS є AWS CloudFormation і Terraform. Для нашого прикладу оберемо Terraform. У ньому load balancer матиме такий вигляд:

resource "aws_elb" "myELB" {  name = "myELB"  listener {    instance_port     = 8000    instance_protocol = "http"    lb_port           = 80    lb_protocol       = "http"  }  subnets = [...]  security_groups = [...]
}

...

Тут ми бачимо ще одну проблему — посилання одних ресурсів на інші. Щоб наш псевдокод став реальним, треба додати дефініції для security groups (subnets тощо). Наприклад, посилання на security group може мати такий вигляд:

resource "aws_elb" "myELB" {  name = "myELB"  ...  security_groups = ["${aws_security_group.elb.id}"]
}

resource "aws_security_group" "elb" {  name = "web_alb"  description = "Allow incoming HTTP connections to ALB."  ingress {    from_port = 80    to_port = 80    protocol = "tcp"    cidr_blocks = ["0.0.0.0/0"]  }  egress {    from_port = 0    to_port   = 0    protocol  = "-1"    cidr_blocks = ["0.0.0.0/0"]  }
}

Ми визначаємо правила для цієї security group — приймати трафік на порт 80 — і деталі деплоймента цієї групи стають неважливими. Terraform сам задеплоїть ресурс, отримає його ID і підставить у параметри load balancer.

Ми можемо додати декларації Terraform до системи контролю версій і використовувати їх як джерело істини для різних середовищ. І тут ми бачимо наступну проблему.

Стан світу

Як Terraform дізнається, що треба деплоїти, а що ні? Для цього йому потрібно десь зберігати поточний стан усіх описуваних ресурсів. За замовчуванням цей стан зберігається у файлі terraform.tfstate. Може постати питання: а чому б не зберегти цей файл і в системі контролю версій? Є дві причини, чому цього не варто робити:

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

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

output "web_alb_sg_id" {  value = aws_security_group.web_alb.id
}

terraform { backend "s3" {   key    = "iacdemo.tfstate"   region = "us-west-2"   bucket = "demobucket" }
}

Terraform підтримує багато механізмів remote state, але якщо ви працюєте з AWS, то рекомендую дивитися на AWS S3, оскільки цей механізм:

• підтримує шифрування, чим розв’язує проблему зберігання конфіденційних даних;
• підтримує версіонування — у разі несправностей ви завжди зможете знайти останній коректний варіант стану вашого світу;
• більшість команд може використовувати його безкоштовно протягом року (AWS free tier).

Але навіть розв’язавши цю проблему, ми одразу бачимо наступну. Так, ми створили load balancer та інші ресурси, але...

Не всі ресурси однакові

Так, load balancer важливий для нашого мікросервіса. Але security group, на яку він посилається, важлива для всіх мікросервісів. Зламати security group — це набагато гірше, ніж зламати один load balancer.

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

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

Як розділити інфраструктуру

Але розробникам все одно треба посилатися на ключові ресурси. Як це зробити?

Розгляньмо на прикладі Terraform. Ми зберігаємо стан світу окремо від коду. Це дає можливість імпортувати його і під час декларації ресурсів посилатися на ті його параметри, які були експортовані:

data "terraform_remote_state" "core" { backend = "s3" config = {   key    = "iacdemo.tfstate"   region = "us-west-2"   bucket = "demobucket" }
}


resource "aws_elb" "myELB" {  name = "myELB"  ...  security_groups = "${terraform_remote_state.core.web_alb_sg_id}"
}

Тепер ключова інфраструктура може бути задеплоєна окремо від інфраструктури мікросервісів.

І ми переходимо до найважливішого питання...

Як організувати процес деплойменту інфраструктури

Як і під час роботи зі звичайним кодом, ми можемо розбити процес деплойменту на частини:

1. Валідація
2. Тестування
3. Деплоймент
4. Димове тестування
5. (і потім усе повторюється в наступному оточенні, починаючи з п.1)

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

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

У Terraform це можна зробити за допомогою команд:

terraform init 

terraform plan -input=false

Перша команда ініціалізує Terraform і створює remote state або синхронізується з ним.

Друга команда повертає нам перелік ресурсів, які будуть створюватися або змінюватися. Щоб ми могли перевірити, чи насправді заплановані зміни — ті, які ми очікуємо. (Параметр «-input=false» потрібен для того, щоб усі змінні бралися зі змінних оточень, не чекаючи на введення з консолі. Це дуже корисно, коли команди виконуються в headless оточенні, наприклад у Jenkins, де консолі немає).

Обережно з видаленням

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

Якщо ваша інфраструктура не потребує 99.9% аптайму, це можна пережити, якщо ні — можливо, вам треба застосувати налаштування create_before_destroy. Але для цього потрібно розуміти, як це відобразиться на ресурсах, які залежать від того, в якому виникла проблема.

А тепер деплоїмо

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

# initializing configuration!
export TF_VAR_<your variable>=... 

# setting up or syncing with a remote state
terraform init


# reviewing a list of changes
terraform plan -input=false	    
# deploying our infrastructure changes
terraform apply -input=false -auto-approve

Як бачимо, це банальний shell-скрипт, який можна інтегрувати і з Jenkins, і з Gitlab CI, і з іншим CI-CD рішенням,зокрема з нашим CI-CD pipeline.Це розв’язує проблему з неавтоматизованим деплоєм лоад-балансера, описану на початку статті. Тепер ми можемо описати нашу інфраструктуру як код, зберігати зміни в системі контролю версій, робити їм code review та автоматично деплоїти за хвилини, а не за дні чи тижні. Але усе це стосується лише Terraform...

Чи є життя за межами Terraform

Так! Розглянемо приклад з Kubernetes, який дає змогу описувати інфраструктуру для контейнерів та мережних ресурсів декларативно. Можемо загорнути цю декларацію в шаблон, використовуючи банальний shell-скрипт (або більш просунуті інструменти — від YTT до Helm. Але це я залишу як домашнє завдання охочим :)

#!/bin/bash
cat <<YAML
apiVersion: apps/v1beta1
kind: Deployment
...
spec: replicas: 1 template:   spec:     containers:       - name: $SERVICE_NAME         image: $DOCKER_IMAGE         imagePullPolicy: Always         ports:           - containerPort: 8090
...
YAML

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

# initializing configuration!
export DOCKER_IMAGE=hello:latest
export SERVICE_NAME=helloworld

# reviewing a list of changes
k8s_template.yaml.sh | kubectl apply --dry-run -f -

# deploying our infrastructure changes
k8s_template.yaml.sh | kubectl apply -f -

Також саме ми описуємо наші ресурси як код, зберігаємо їх у системі контролю версій. Перевіряємо зміни перед тим, як деплоїти, і можемо інтегрувати цей процес з CI-CD pipeline.

А що в майбутньому

І навіть якщо в майбутньому з’явиться принципово новий декларативний інструмент для керування (наприклад!) нейромережами, то всі ці методи можна буде застосувати й для нього! Сподіваюсь, тепер вам буде легше починати експерименти з інфраструктурою. Якщо хочете дізнатися більше, рекомендую послухати ці доповіді про Infrastructure-as-code: evolving tools vs core principles:російськоючи англійською, Automated Testing for Terraform, Docker, Packer, Kubernetes, and More.

Також раджу прочитати книги

• Infrastructure as Code: Managing Servers in the Cloud by Kief Morris
• Terraform: Up and Running: Writing Infrastructure as Code by Yevgeniy Brikman

GitHub-репозиторійдля Core infrastructure та GitHub-репозиторійокремо для сервіса.

Дякую за увагу та бажаю всім легких деплойментів і 100% аптайму!

Ми проаналізували ринок праці у квітні 2020 року. Подивилися, що відбувалося з вакансіями та відгуками на jobs.dou.ua, а також поспілкувалися з компаніями, які активно продовжували наймати спеціалістів.

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

Кількість вакансій зменшилася більш як на третину

У квітні кількість опублікованих вакансій зменшилася на 38% (якщо дивитися на середньомісячну кількість вакансій за останній рік). Минулого місяця компанії опублікували на DOU 2992 вакансії, і це приблизно показники весни 2017 року. Якщо порівнювати квітень із березнем 2020-го,то просідання було на 20%.

Загальна кількість вакансій на jobs.dou.ua з березня 2019-гопо квітень 2020-го

Кількість вакансій зменшилася майже в усіх категоріях. Позитивна динаміка у квітні була лише у Unity, Security і Product Manager, але і там вона незначна. Якщо брати Unity, то 41 вакансія у квітні — це трішки вищий за середній показник у цій категорії. Серед найпопулярніших категорій найбільший спад (понад 50%) у .NET, QA, Front-End, Ruby і HR.

Кількість вакансій у квітні 2019-гоі квітні 2020-гоза категоріями

Дивіться порівняльну таблицю кількості вакансій у березні і квітні в нашому телеграм-каналі

Кількість вакансій з березня 2019-гопо квітень 2020-го

Якщо порівнювати квітень 2019-гоі квітень 2020-го,то загальна кількість вакансій у Києві зменшилася на 36%. З-поміж великих міст найгірша динаміка в Харкові та Львові — зниження на 44% і 40% відповідно. Майже не змінилася кількість віддалених вакансій. А в березні їх було чи не найбільше за останній рік.

Кількість вакансій за містами

Щодо досвіду, то попит на досвідчених спеціалістів змінився найменше: кількість вакансій для спеціалістів із досвідом понад 5 років зменшилася на 18% у квітні 2020-гопорівняно з квітнем 2019-го.А ось вакансії для спеціалістів без досвіду і з досвідом до року скоротили на 56% і 48% відповідно.

Кількість вакансій за досвідом роботи

39 відгуків на одну вакансію для HR і 25 — для Front-end

Суттєве зменшення вакансій призвело до збільшення конкуренції серед кандидатів. І якщо на одну вакансію для спеціалістів у квітні приходило майже 10 відгуківпроти 7 у березні, то з вакансіями джунів усе значно гірше. У квітні на одну вакансію з досвідом до року надходило майже 38 відгуків проти 27 у березні 2020-гоі 17 у квітні 2019-го.Якщо розглядати Київ, то тут було майже 45 відгуків на одну вакансію для початківців.

Щодо технологій, то в середньому минулого місяця на кожну вакансію у категорії Front-end відгукувалося 25 спеціалістів. І це в чотири рази більше, ніж торік. Цікаво, що на кожну віддалену вакансію подавалося понад 53 фронтенд-розробники. За іншими категоріями відгуки коливаються у межах 5-13 наодну вакансію.

Зменшилася кількість відгуків лише в категорії Unity — з 9 у квітні 2019-годо 4 у квітні 2020-го.

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

Якщо не брати до уваги розробників, то на інших посадах конкуренція ще вища. Минулого місяця буквально посипалися відгуки на HR-вакансії — до майже 39 проти 13 у квітні 2019-го,на QA — до 32 проти 15 у березні 2020-гоі 11 у квітні 2019-го.Проджект- і продакт-менеджери завжди були в топі за відгуками. Але 37 для проджектів — це також рекорд.

Кількість відгуків на одну вакансію за посадами

У кризуквітні шукали Front-end, QA і DevOps

Серед новачків найбільше вакансій було в категорії Marketing, QA, Sales і PHP. Серед мідлів, окрім Front-end і QA, в топ за кількістю вакансій вийшли ще DevOps. І враховуючи кількість відгуків (менше як 6 на одну вакансію), ці спеціалісти сьогодні почуваються чи не найспокійніше. Щодо вакансій з вимогою досвіду понад 5 років, то тут у топі були Java, Front-end і .NET.

За категоріями для досвіду < 1 року

Майже на чверть скоротилася кількість компаній з активними вакансіями

Кількість компаній, що публікували вакансії у квітні, зменшилася на 366 порівняно з квітнем 2019-гоі на 222, якщо порівнювати з березнем 2020-го.За нашими спостереженнями, найм призупинили або суттєво скоротили як маленькі компанії, так і великі із переліку топ-50.

Кількість компаній, що опублікували вакансії

В середньому щомісяця на DOU реєструвалося 140 нових компаній. У квітні цифра впала до 85.

Кількість нових компаній, що зареєструвалися на DOU

У квітні 21 компанія опублікувала понад 15 вакансій на jobs.dou.ua. Найбільше позицій розмістила продуктова компанія Genesis — разом з їхнім проєктом BetterMeвони опублікували 86 вакансій у квітні.

Найактивніші компанії квітня

«За тиждень ринок кандидатів став ринком роботодавця»

Ми також запитали ІТ-компанії, як вони переживають кризу і чи змінився ринок праці за ці півтора місяця.

Genesis

У Genesis розказали, що криза суттєво не вплинула на найм. Вакансій стало навіть більше через те, що деякі напрями бізнесу значно зросли. До того ж компанія продовжує запускати нові проєкти — здебільшого у напрямі mobile-розробки. Щодо ринку, то в Genesis зазначають: кандидатів стало більше. Практично щодня вони отримують інформацію від спеціалістів, що ті потрапили під скорочення, проєкт закрився тощо. Через це почав знижуватися і рівень зарплатних очікувань.

PMLAB

У PMLAB повідомили, що у квітні вони найняли рекордну кількість спеціалістів — близько 50 осіб. Як і раніше, шукають кандидатів у різні команди — від Technology і Revenue до HR і Admin-департаментів. До того ж у компанії відкрили нові позиції. Наприклад, зараз тут шукають талановитих математиків і створюють команду, що відповідатиме за математичні моделі та автоматизацію операційних процесів загалом. Водночас у компанії очікують спад найму на травень-червень, тому що в квітні люди практично не звільнялися. Якщо ще місяць тому на одного рекрутера припадало 10-12 вакансій,то сьогодні — 4-6.

Загалом у PMLAB зауважили, що регулярно чують, що через скорочення проєктів і вихід на ринок хороших кандидатів зараз золотий час для найму. Частково вони із цим згодні. «За тиждень ринок кандидатів став ринком роботодавця», — каже Head of Talent Acquisition Team Ольга Павленко. Однак додає, що компанії утримують сильних фахівців. І якщо говорити про збільшення потоку кандидатів, то переважно це фахівці рівнів Junior+ і Middle — люди, що працювали в малому і середньому бізнесі, на який припадає основна частина скорочень. На думку Ольги, якщо раніше переконати кандидата Senior-рівня розглянути пропозицію і перейти на нове місце було завданням із зірочкою, то тепер це ще важче: у фахівців висока тривожність. В умовах кризи люди бояться щось змінювати і намагаються триматися за стабільні робочі місця. Щодо зарплатних очікувань, то в компанії просідання поки не відчули. Багато кандидатів розуміє, що це тимчасове явище, і чекає осені з надією, що все вирівняється і буде більша кількість пропозицій.

Ubisoft

Наразі Ubisoft Kyiv і Odesa продовжують найм за двома основними напрямами — розробка і тестування. В компанії повідомили, що кількість кандидатів у департамент тестування залишилася на колишньому рівні, також не було значних змін у зарплатних очікуваннях. Що стосується департаменту розробки, то тут ситуація трохи змінилася. На окремі позиції стало більше кандидатів, переважно з аутсорсу (фронтенд, бекенд (.NET) тощо), але основні напрями, за якими компанія наймає — Programming, Art, Project Management — залишилися без змін. Також практично не змінилися зарплатні очікування, хоча багато хто готовий поступитися 10% на час карантину, за умови, що після нього вдасться вийти на очікуваний рівень ЗП. Загалом у продакшені Ubisoft бачить приріст найму приблизно на 5%.

Luxoft

Певним чином епідемія коронавірусу та її економічні наслідки торкнулися і клієнтів Luxoft. Кілька проєктів довелося тимчасово поставити на паузу, зростання деяких не такий стрімкий, як очікували. Втім є проєкти, які продовжують розвиватися, незважаючи на кризові явища. Оскільки останніх є чимало у кожному з ключових напрямів бізнесу (Finance, Automotive, Digital Engineering), Luxoft продовжує найм спеціалістів, хоча і в менших об’ємах. З метою збереження талантів усередині компанії чимало вакансій закривають внутрішніми ресурсами, однак частину фахівців добирають також з ринку. Стосовно ринку праці загалом, то, за словами представників рекрутингу Luxoft, помітно: кількість кандидатів на ринку зросла, однак це не мало значного впливу на зарплатні рівні, особливо це стосується затребуваних досвідчених фахівців. Утім деякі кандидати готові зменшувати свої зарплатні очікування, якщо потрапили під скорочення на попередньому місці праці.

Innovecs

В Innovecs розказали, що у них є вакансії за всіма ключовими напрямами: Supply Chain&Logistics, Retail&Ecommerce, Healthcare, Media&AdTech, FinTech, Gaming&Entertainment. Що стосується стеку технологій, то активно шукають фахівців Front-end, Back-end, DevOps, QA. Якщо порівнювати відгуки кандидатів за останні кілька місяців, то під час карантину компанія отримує більше резюме. Зокрема, зріс потік із сайтів-агрегаторів вакансій. Найактивніше цікавляться роботою за напрямами Front-end, Fullstack, QA, PHP. Водночас збільшення кількості кандидатів не сильно вплинуло на швидкість найму. Також у компанії відзначили, що кандидати стали більш відкритими. У тих, хто втратив роботу через кризу, відбулася переоцінка цінностей. Це помітно у стилі спілкування: розробники стали більш гнучкими, відкритими і доброзичливими. Деякі готові знизити зарплатні очікування — на першому місці зараз інтерес до самого проєкту і можливість кар’єрного розвитку.

N-iX

N-iX також не припиняв пошуки нових фахівців. У компанії повідомили, що мають чимало проєктів у сферах, які не так відчутно зачепила криза, пов’язана з COVID-19. Але загальна кількість вакансій скоротилася. Якщо раніше їх було +/- 80, наразі — близько 50. Чи не найкраще йдуть справи в геймдев-індустрії. Оскільки в N-iX є Game Development and VR Studio, багато відкритих позицій саме у цьому напрямі. Також компанія шукає фахівців для нових проєктів, які з’явилися вже в період карантину — у сфері фінансів, страхування, медицини та інших. Зі слів працівників, чимало їхніх клієнтів стикнулося з новими проблемами через збільшене навантаження на системи. Наприклад, одна з компаній виробляє апарати ШВЛ. Заводи працюють 24/7, а тому збільшилась кількість роботи для команди N-iX. Щодо ситуації на ринку, то в компанії відзначили збільшення кількості кандидатів рівнів Junior та Middle.

WIX

WIX також не відчув кризу, а навіть навпаки. За даними компанії, зараз у них відкрито близько 180 позицій у Києві і Дніпрі в той час, як до карантину було близько 60. У R&D-центр вони шукають спеціалістів за основними напрямами — Front-end, Back-end (Scala, Node.js, Python), Mobile (React Native), BI / Data Developers, Data Science. Один з великих проєктів, Wix Payments, розширює команду і шукає продакт-менеджерів, експертів з платежів, risk&fraud-фахівців. Також стартує ще одна e-com команда Wix Stores у Дніпрі, туди шукають інженерів Front-end, Back-end. В компанії активно розвивають іпідрозділ customer care. Що стосується ринку, то у WIX помітили, що претендентів стало більше, але талановитих у своїй справі професіоналів в активному пошуку все ж одиниці. Тому конверсія навіть трохи зменшилася в період карантину.

Підписуйтеся на Telegram-канал «Редакція DOU», щоб залишатися в курсі найважливішого. Туди ми надсилаємо редакційні запити, проводимо опитування, а також публікуємо найцікавіші матеріали.

Рано чи пізно це таки трапляється.

Тімлід призначає зустріч, на якій сором’язливо виставляє перед тобою папірчики з написом «Performance improvement plan». Або команді представляють нового техліда, і це зненацька не ти. Або СЕО ненароком кидає в курилці: «Певно, все ж треба було найняти професіонала на позицію СТО». А ти до цього конкретного моменту вважав, що ти і є професіонал!

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

Такі моменти завжди приходять, як грім на голову, і підготуватися до них неможливо. Апостеріорі, звісно, мозок підсуне тобі сотні причин, чому так сталося. Чому ж він ховав їх десь у глибині аж до цього моменту?

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

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

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

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

Перший хибний: авторефлексія

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

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

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

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

Ілюстрації Каталіни Маєвської

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

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

Є кращий спосіб.

Перший правильний: спостереження

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

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

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

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

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

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

Другий хибний: порівняння

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

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

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

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

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

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

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

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

Другий правильний: вимірювання

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

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

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

Наразі це досі відкрита проблема. Компанії створюють різні «рівні», «треки», «потоки» з абсолютно розмитим набором вимог, спеціальні комісії для аналізу цих вимог і купу багатолюдних зустрічей виключно з метою зміни якоїсь циферки десь там в особистій справі. Добре ще, коли це робиться правильно і має якісь наслідки (збільшення рівня впливу, зростання зарплати, більша кількість підлеглих). Але часто циферки (чи безглузді лички) виставляють просто так, для імітації процесу «кар’єрного росту». Тоді біда.

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

Погані новини: перевести самооцінку в конкретні цифри не простіше.

Хороші новини: деякі способи таки є.

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

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

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

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

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

Третій хибний: фідбек

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

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

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

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

А якщо ви продовжуватимете допит, на перше місце вийде вже саме формулювання питання.

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

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

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

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

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

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

Тому для об’єктивності варто спробувати щось інше.

Третій правильний: експеримент

Тут як у старому анекдоті. «Ви вмієте грати на фортепіано? — Не знаю, ніколи не пробував».

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

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

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

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

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

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

Ну і в кінці все зовсім просто: ми цю гіпотезу перевіряємоі записуємо результати.

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

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

Тут можна (і треба!) користуватися фідбеком від інших. Але в цьому випадку не абстрактним «як я тобі, як програміст і колега?», а чітким і вузьконаправленим: «чи легко було зрозуміти те, що я пояснював?» або «чи пахне мій код, як переспілий дуріан?». Якщо питання безособові, людям простіше на них відповідати, не боячись зіпсувати стосунки з вами як людиною. Ну і код, будемо чесні, критикувати набагато простіше, ніж особистість, яка стоїть за ним.

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

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

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

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

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

***

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

Інша система, «змагальна», вважає себе непогрішним божеством. Тому, що тільки повністю повіривши у свою обраність, непереможність, неможливість програти, можна ламати незримі бар’єри і стрибати набагато вище голови.

І якщо техніки, описані вище, вам навіть беззаперечно доведуть, що ви чогось зробити не зможете, це зовсім не означає, що так воно і є насправді.

Все ви зможете.

І все у вас вийде.