Дайджест создан в соавторстве с Павлом Кривко.

00h > Интро

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

01h > Горячее

Май планирует быть насыщенным, и у вас есть шанс одним махом посетить сразу два больших ивента по кибербезопасности. NoNameConсостоится в Киеве 16-17 мая,а 18-гомая откроет двери Security BSides Kyiv. Если вы студент и желаете сходить на BSides, то можете попробовать решить небольшой CTF и получить существенную скидку.

В открытый доступ утек инструментарийиранской хакерской группы APT34, которую связывают с правительственными структурами. Неизвестный хакер Lab Dookhtegan выложил в сеть не только используемые тулзы, но и некие досье на отдельных членов группировки, информацию о некоторых целях для атак в разных странах и другую годноту. Неплохие разборы тами сям. А тут, кому лень читать, доступен для скачивания полный лик, vJrqJeJo2n005FF* это был пароль. Судя по всему, АПТ34 надолго выведены из игры, и нужно какое-то время для актуализации и разработки нового инструментария, прежде чем ребята снова смогут вернуться в строй.

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

02h > Около секьюрити

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

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

Господин Кребс зачастил со статейками о ребятах, угоревших по разработке малвари. Первый материал о рейде правоохранителей на разработчика ORCUS Rat, а второй гораздо более интересный: небезызвестный @MalwareTechтаки призналсяфедералам, что писал и продавал Kronos. Забавно совпадение, что оба продукта начали активно распространяться в 2015 году.

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

Мобильные приложения, маркеты, трекеры, персональные данные пользователей, придет ли этому конец?

Ничего нового: Facebook все также продолжает делатьс данными своих пользователей разные, совсем уж неприличные вещи. Ну фу.

03h > Интересное

Семейство малвари под MacOS пополнилась новым семплом от группы Ocean Lotus, детальнее тут.

CloudFlare активно продвигает свой новый сервис 1.1.1.1 вместе с VPN, обещаютдаже не хранить логи и не продавать данные пользователей, хм...

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

Забавный материална SANS о поиске скрытых камер наблюдения в жилье от Airbnb, написанный по мотивам этого инцидента.

Уже в который раз на страницах нашего дайджеста вы могли встретить в одной строке слова «Google Play» и «Malware», и, как вы уже догадались...

Хорошая статьяна тему DLL hijacking и lateral movement.

Эй, охотнеги, смотрите какая крутая штука. Полезно.

04h > Уязвимости && Эксплоиты

Сразу две крутых статьи про эксплуатацию от Google Project Zero. Первая — про эскейп из сандбокса Chrome. Вторая про абьюзюзер мод дебага в Windows.

Неужто SQL-injectionв недрах Magento?

Несколько LPE в Win10 раз, два, три, четыре, пять, шесть, вроде все?

Внезапно Atlassian Confluence, внезапно RCE.

Глядите-ка, WinRAR exploit builder! Выбираете свой пейлоад, фигак-фигак и в продакшн. Просто, удобно и для людей. Ссылка в ТОR, если шо...

Кстати, попробуйте поделочкус названием fireELF: это опенсорсный malware-фреймворк, который позволяет удобно создавать и управлять пейлоадом.

05h > Фан

Ты, когда сабмитишьочередную CVE...

Script kiddie эксплойтитнайденную RCE-ху.

CISO vs Pentester, LOL.

Когда сгенерилсебе пароль, чтобы перед пацанами не было стыдно.

Олды тут?

06h > Аутро

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

← Предыдущий выпуск: Information Security дайджест #13.

Галині Харківськійдвадцять чотири роки, уже рік вона працює web-аналітиком у Booking.com.Ще зі школи дівчина знала, що пов’яже життя зі статистикою, адже захоплювалася математикою й обчисленнями, скільки себе пам’ятає. Тому після закінчення фізико-математичного ліцею вступила на теоретичну й прикладну статистику до ЛНУ імені Франка.

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

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

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

Стажування в Аbto Software і пропозиція Booking.com

Аbto Software — це українська аутсорсингова IT-компанія, яка створює програмні рішення для лідерів різних галузей (телекомунікації, енергетики, транспорту, медицини, будівництва, безпеки) і державних установ. Для роботи над проектом від замовника зі Штатів, Сан-Франциско, компанія набирала команду талановитих дата-аналітиків. Тому організувала літнє місячне стажування для студентів четвертого-п’ятого курсів. Залежно від результатів цього стажування учасникам пропонували роботу.

Щоб потрапити на стажування, треба було розв’язати математичні задачі. Там не було жодних запитань, пов’язаних з бізнесом, тому моїх знань з університету вистачило, щоб виконати тестове. Знання англійської було в пріоритеті, тож я додатково вчила її на мовних курсах. Ще однією вимогою було знати або вивчити найближчим часом мову SQL. В університеті навчали тільки Python і R, тому SQL була новою для мене, і я приділяла багато часу її опануванню. Зрештою, це дало свої результати, і із шести стажистів я потрапила до трійки, якій запропонували роботу. Так я стала junior data analyst в Аbto Software.

Це була моя перша робота й перша серйозна відповідальність у компанії. Моїми обов’язками було аналізувати дані й давати рекомендації щодо поліпшення продукту. Мені подобалася атмосфера в нашому офісі, я легко знайшла спільну мову з іншими працівниками. Але коли минав 2016-й,мій другий робочий рік, одержала листа від рекрутера з Booking.com, яких зацікавив мій профіль у LinkedIn.

Це був новий шанс для мене. До того ж я дуже хотіла здобути досвід у великій іноземній компанії, а Booking.com — це найбільша технічна компанія у сфері подорожей. Тому це мене справді зацікавило. І попри те, що в Аbto Software не всі зраділи, що я можу піти, усе ж спробувала влаштуватися до Booking.com.

Співбесіди й culture fit

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

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

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

Цього разу я спілкувалася з рекрутером і директором аналітики. Інша частина цього інтерв’ю була з аналітиками: треба було розв’язувати різні задачки й бізнес-кейси. Головна мета останнього інтерв’ю — з’ясувати culture fit. Тобто чи впишуся в команду, чи в мене такі самі амбіції, чи розумію, як поводитися тощо. Booking.com шукає допитливих талановитих людей, які прагнуть розвиватися й адекватно реагують на критику. Головне під час цієї розмови бути собою.

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

Перша співбесіда була в січні, і вже за кілька місяців, у квітні, мені повідомили, що я підходжу на вакансію. Тепер працюю в Booking.com на посаді web analyst. Щоб стати data-аналітиком у Booking.com, не треба було складати жодного тесту з програмування чи виконувати якісь технічні завдання. Це було неважливо. Їм насправді байдуже, яку мову програмування ти знаєш і з якими програмами працюєш узагалі. Головне — бути фахівцем у своїй галузі, адже вони наймають людей лише з досвідом і тих, які готові розвиватися далі. Я їм підійшла й із квітня 2018 року працюю на посаді web analyst у Booking.com.

На своїй роботі відповідаю за все, що стосується гугл аналітики компанії. Ми працюємо із серверами даних гугл аналітики, використовуючи BigQuery. І тут мені став у пригоді досвід з попередньої роботи, а саме мова SQL. З її допомогою я можу діставати й опрацьовувати дані. Крім того, використовую програми Tabloй Data Studioдля візуалізації й аналізу даних.

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

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

Переїзд і перші дні в Booking.com

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

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

Перші три дні в Booking.com я не мала свого робочого місця (це називається onboarding). Тоді всі ми, сорок п’ять новачків серед двох з половиною тисяч працівників компанії, знайомилися між собою й слухали лекції від різних працівників Booking.com: про цінності компанії, про те, куди ми рухаємося, і яка в компанії vision mission. Ми вивчали всі канони, які треба знати, перш ніж почати працювати в компанії.

Офіс Booking.com величезний, і тому для нас зорганізували квест: бігати всім офісом, збирати відповіді на різні запитання й так вивчати його. Це було як гра, тому справді було цікаво.

Разом з новими колегами

Про роботу web analyst

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

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

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

Умови роботи

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

Ми всі працюємо в open space, немає такого, що кожен сидить окремо. Робоча мова англійська, нею послуговуються в роботі й говорять в офісі. Усі працівники між собою спілкуються. Оскільки всі живуть в Амстердамі, то майже немає жодних skype-call чи віддаленого конференц-зв’язку: зустрічаємося наживо й говоримо face to face.

Про корпоративи

У компанії є тільки два великі свята. Одне з них на Новий рік — Booking annual meeting — це цілий робочий день у форматі конференції. А на завершення — грандіозна вечірка. Цього року в ній брало участь п’ять тисяч людей, тобто всі, хто працює в Амстердамі у відділі development, і всі, хто працює в customer service в інших європейських офісах.

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

Другий корпоратив улітку — Summer party. Минулого року я була на ньому вперше. Це грандіозна вечірка в легкому літньому форматі. Ми зустрілися на природі, компанія зорганізувала кейтеринг — усе, щоб відпочити.

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

Галина разом з командою на природі

Цінності й етика компанії

Зазвичай кожна компанія має свої цінності, які вони шукають у людях і за якими й наймають на роботу. У Booking.com важливо бути humble й curious. Амстердам — толерантне місто, відкрите для людей усіх гендерів, і оскільки Booking.com — нідерландська компанія, вона теж поважає права людей і не чинить перешкод.

У нашій компанії працює багато людей різних статі, національності й культури. Ми виступаємо за рівність жінок і чоловіків, тому один з девізів Booking.com — diversity. Бо міжкультурність і міжрасовість робить нас лише сильнішими.

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

Подорожі завдяки Booking.com

Я завжди любила подорожувати, ще до роботи в Booking.com, а вся ця атмосфера компанії й те, як вони підтримують у подорожах, надихає мене ще більше. Вони навіть мають девіз: «Empower people to experience the world». У нас тут багато людей, які спочатку мандрують, а потім улаштовують різні майстер-класи чи спічі й розповідають про це. До того ж Booking.com спонсорує такі ініціативи. Мета компанії зовсім не в тому, аби продати якомога більше готелів, а в тому, аби допомогти людям подорожувати й зробити мандри enjoyable. Щоб можна було забронювати житло всюди, де хочеться, і не мати жодних проблем.

Для працівників Booking.com є знижки на житло під час подорожей. Також є програма dogfooding — це коли працівники компанії на власному досвіді переконуються в зручностях готелів чи інших апартаментів. Резервують номер як члени команди Booking.com, а потім розповідають про свій досвід у компанії. Щоб винагородити, компанія повністю оплачує таку подорож — літак і ніч у готелі. Але це має бути не проста подорож, ти повинен мати якусь ідею: пояснити, що хочеш протестувати, на що подивитися, так би мовити, відкрити щось нове для компанії.

Місто вільного вибору

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

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

Транспорт

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

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

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

Житло

Через великий наплив туристів та емігрантів ціни на житло високі. Якщо винаймати квартиру-студію в місті, але не в центрі, то не варто розраховувати не менш як 1200 євро плюс 100-200євро комунальні послуги. Якщо ви готові ділити квартиру з іншими людьми, то окрему кімнату можна винайняти від 600 євро на місяць.

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

Пунктуальний Амстердам

Після приїзду мені треба було пройти медогляд за візою, тож я одержала запрошення до лікаря на 14:47. Я була спантеличена, що такий час: не 14:40 чи 14:50, а саме сорок сім хвилин. Я хвилювалася, але прийшла вчасно, і справді саме в той час мене й прийняли.

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

Люди

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

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

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

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

Відпочинок по-нідерландськи

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

Одного із сонячних днів

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

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

Плани на майбутнє

Я дуже сумую за Львовом. Мій робочий контракт необмежений, тож я можу будь-якої миті піти, якщо захочу. У Booking.com я заради досвіду життя за кордоном і роботи у великій компанії, а потім планую повернутися до України й далі розвиватися як дата-аналітик.

Привіт! Мене звати Олександр, я працюю full-stack розробником, пишу статті, допомагаю на StackOverflowі беру участь у кількох open-sourceпроектах. У цій статті хотів би розповісти про свій досвід навчання в Binary Studio Academy, яку закінчив півтора року тому. Поділюся інсайтами, порадами, чого чекати, як готуватися й дійти до кінця.

З чого все починалося

Моя освіта не була пов’язана з IT, тож мої знання з програмування обмежувалися домашніми потребами, наприклад, перевстановленням Windows. За 6-7місяців до того, як анонс набору до академії потрапив мені на очі, я вперше відкрив для себе HTML, CSS і JavaScript. Пройшовши всі безкоштовні уроки на HTML-Academyй наполовину опанувавши онлайн-підручникіз JavaScript, я почав шукати способи практикуватися, і саме тоді з’явилися перші проблеми:

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

Тимчасовим рішенням були відеоуроки/підкасти на YouTube, де розробники діляться досвідом, показують, що таке «хороший код» і як його досягти. Після кількох переглянутих відео я здійснив тотальний рефакторинг свого коду (хоча тоді навіть не знав слова «рефакторинг»). Але все ще не був упевнений у всьому коді, оскільки виправляв лише те, на що звертали увагу автори відео.

Після марних спроб знайти сервіс, який би розв’язував усі мої проблеми одним заходом, я змінив свій запит у Google:

Серед результатів були різні варіанти, зокрема Coursera/Prometheus, які, на мій погляд, є лише розширеною версією YouTube, тож я проігнорував їх. А згодом натрапив на Binary Studio Academy. Швидко переглянувши умови, не одразу повірив, що такий курс може бути безкоштовним. Але уважно перечитавши FAQ, переконався в правдивості й з радістю зареєструвався на JavaScript напрям.

Підготовка до вступного тестування

Відбір до академії складається з трьох етапів: онлайнового тестування обсягом приблизно 30 запитань з основ програмування, зокрема й з ООП і баз даних; трьох відеолекцій та домашніх завдань до них і невеличкої співбесіди з HR компанії.

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

У процесі підготовки:

• встановив Apache сервер на ПК для тренування MySQL;
• проходив різні туторіали із SQL;
• кілька разів перечитав статті на Вікіпедії про терміни ООП;
• двічі проходив демотест.

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

Відбір

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

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

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

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

Перші лекції другого відбіркового етапу розповідали про Git, ES6 та MongoDB. Вони не здалися мені занадто складними, тож виконавши основне завдання, я робив альтернативну або доповнену версію розв’язання до кожної лекції. Так, наприклад, у завданні з ES6 і прототипування в JavaScript додатково використовував HTML/CSS, роботу з DOM й Adobe Photoshop, і от що вийшло:

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

Що можу порекомендувати для цього етапу:

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

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

За результатами тесту й перших домашок я подолав відбірковий етап. І після невеликого інтерв’ю з представником Binary Studio в скайпі став студентом академії та одержав запрошення на першу лекцію в офісі компанії у Львові.

Початок навчання та лекції

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

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

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

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

З усіх порад для подолання етапу лекцій можу виокремити основні:

• плануй свій час і не відкладай до останнього;
• спілкуйся з іншими студентами;
• не соромся запитувати викладача;
• допомагай іншим порадами.

Проект

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

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

Поради для роботи над проектом:

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

Завершення академії

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

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

Життя після академії

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

Нині, за півтора року після закінчення академії, планую брати участь у проведенні Академії-2019, можливо, уже як лектор та/або коуч, щоб поділитися здобутим досвідом і допомогти комусь стати справжнім інженером, готовим до викликів сучасного розроблення.

Висновки

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

[От редакции: в рубрике «Эволюция зарплат»мы приглашаем читателей DOU анонимно рассказать о своем карьерном пути, зарплатных взлетах и падениях. Если готовы поделиться своей историей, пишите на valentina@dou.ua]

Иллюстрации: Алина Кропачева

Всем привет. В благодарность DOU за все полезности для IT-сферы Украины, и не только, я решил поделиться историей своей карьеры. Хочу рассказать не столько о количественном увеличении своего дохода в IT, хотя он был значительным и за 11 лет вырос с $200 оплаты стажировки Java Developer до $8000 ежемесячной зарплаты Project Manager, — сколько о качественных изменениях, необходимых для обоснованного и стабильного роста оплаты труда.

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

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

1. Java Developer
2. C# Developer
3. Business Analyst
4. IT Consultant
5. Project Manager

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

Мой путь уникален тем, что мне удалось «попробовать» несколько IT-профессий без потерь в зарплате при смене вида деятельности. Отмечу, что я не достиг совершенства ни в одной из них. Как видите, я сменил три профессии: программиста, аналитика и проектного менеджера. Ни у одной из этих позиций нет приставки Senior: я не смог достичь этого уровня ни как программист, ни как аналитик. Senior PM я себя также не считаю, хотя формально это моя текущая должность с соответствующей зарплатой.

И еще один момент. В описании каждого этапа будут указаны одно или два ключевых события, способа или действия, которые «сделали» этот этап. На каждом этапе это что-то свое, особенное. Однако есть и общее свойство — Work Hard. Я не буду повторять это в описании каждого этапа, но это нужно держать в уме и добавлять предложение к выводам этапа: все стало возможным при перемножении Work Hard на те или иные события, способы, действия. Это означает много работать, не лениться. Если нужно, работать больше, чем много. Быть доступным всегда, когда ты нужен клиенту, проекту или команде. Никогда не плевать в потолок, а если на данный момент конкретной задачи нет, то искать работу в проекте самому.

Этап 0. Подготовка

Период: 2008 год
Зарплата: $0
Должность:студент
Где:Украина, город-миллионник

Моя карьера начиналась по классике: студент предпоследнего курса технического вуза, курсовая работа на Java, летняя практика и знакомство с Java Swing. Язык был выбран старшим товарищем на основе трендов 2008 года — как самый перспективный на последующие годы.

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

Знал я очень мало. Выучил наизусть определения полиморфизма и наследования и пошел по собеседованиям. Через два месяца меня взяли на оплачиваемую практику — $200 в месяц. После ее успешного прохождения предлагали должность Junior Java Developer c зарплатой около $400.

Мне очень помог войти в IT знакомый синьор. Он направил и вдохновил меня. Сказал: «Ты сумеешь. Ты уже многое сделал и можешь, иди — и кодируй!» Я бесконечно благодарен ему за это.

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

Этап 1. Первая работа

Период:2008-2009
Средняя зарплата: $500
Должность: Junior Java Developer
Где:украинская аутсорсинговая компания, город-миллионник

Забегая вперед, скажу, что меня из компании уволили :) За что я благодарен и своему тимлиду, и менеджеру. Если бы они решили оставить меня, все сложилось бы совершенно по-другому. Хотя вот такпусть сложится у каждого!

Дело в том, что Java мне, как говорится, «поперла». Я прошел практику за полтора месяца вместо трех, немного попилил внутренний проект, и меня продали дедиком (dedicated developer) одному заграничному клиенту, назовем его просто «дядя». Так я полгода проработал на проекте одного артиста с устаревающими технологиями, который явно не добавлял никаких плюсов моему резюме, однако был мегавыгодным для продававшей меня компании. При рейте $4 в час меня продавали за $20. То, что я гублю на этом проекте свою молодость, никого не интересовало. Но меня это не устраивало, и я решил поставить свой первый в карьере ультиматум начальству: либо новый проект и другой рейт, либо я ухожу.

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

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

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

Этап 2. Первый апгрейд

Период:2009-2011
Средняя зарплата: $1000
Должность: Java Developer
Где:удаленка через ФОП в Украине, все тот же город-миллионник

Честно скажу, мне очень повезло. «Крыша» в гости не спешила, я продолжал работать в привычном для меня проекте, но теперь уже дома и с х2 зарплатой. Однако, как сказал однажды Путинху*ло: «Везет тем, кто везет. Работать надо!», — и я работал. Работал много, был всегда на связи — и фиксил, фиксил, фиксил. За год с лишним стал Senior Java Bug Fixer с зарплатой хорошего мидла.

Мидлом на этом проекте я так и не стал, зато получил незаменимый опыт поддержки продукта на каждом этапе SDLC. Ведь я был сам себе PM, BA, Dev, QA, IT Ops, Support. И учтите, что за моей спиной больше не сопел тимлид, который был всегда готов прийти на помощь. Нужно было самому искать ответы на все вопросы, принимать решения и, следовательно, отвечать за последствия. Мы даже пытались расширяться и наняли второго программиста. Это было немного абсурдно: собеседовать мидла, являясь явно джуном :)

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

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

Этап 3. Смена языка, и не только программирования

Период:2011-2013
Средняя зарплата: $2000
Должность:С# Developer
Где:удаленка, через ФОП в Западной Европе, город-миллионник

К тому времени я уже перебрался из Украины в Европу доучиваться в магистратуре (на жаль, «Україна — це Європа» наразі тільки у гаслах політиків). Расходы значительно увеличились: на $1500, а это была минимальная зарплата в той стране, особо не разгуляешься.

В Украине оставались некоторые IT-связи, и мне предложили небольшой проект, который должен был закончиться через полгода — в итоге он продолжался чуть больше года и умер, аминь. Там была небольшая команда из Украины, к которой я должен был присоединиться на полставки аналитиком, а на вторые полставки... C# программистом. О C# я знал только то, что я его не люблю, потому что я джавист. Нам положено не любить .NET. Однако нелюбовь + хороший рейт = любовь по расчету. Меня продали клиенту как опытного C# программиста, просто заменив в резюме Java на C#.

Первый месяц был для меня взрывом мозга. Нужно было выучить новый язык, среду программирования, подходы, библиотеки. И в то же время не «спалиться» перед клиентом, что многие вещи я вижу в первый раз. Взрывать себе мозг я уже привык, переходный период закончился, и я успешно отработал в проекте. Попутно написал дипломную работу, скопипастив в нее и исходный код, и многие User Stories из проекта — с позволения клиента, конечно. Отличный пример Code Reuse :)

Этот проект стал последним, в котором моя основная роль заключалась в программировании. И я оказался в затруднительном положении: с одной стороны, пять лет опыта работы, с другой — я все еще Junior Java Developer и Junior C# Developer. А еще мне нужно найти работу в офисе, если я хочу остаться жить в этой стране, да и рейт свой сохранить. В помощь пришел все тот же копипаст. Ctrl + H: Junior → Middle → Replace All. И я пошел по собеседованиям.

Этап 4. Как во мне умер программист

Период:2013-2014
Средняя зарплата: $3000
Должность: Business Analyst
Где: IT-компания в Европе

Чувство дежавю не покидало меня ни на минуту. Спустя пять лет я пытался устроиться на должность Middle Java Developer, зная о программировании на Java лишь немногим больше, чем тогда, когда устраивался на работу в первый раз. Технологии, которыми я владел, окончательно устарели. Последние два года я вообще не занимался Java, опыта в C# у меня было еще меньше... Пишу эти строки и прямо вспоминаю, как жалко мне было себя тогда :) Испортил себе карьеру, при этом уже привык к хорошему рейту — ну хоть стреляйся, жизнь больше не имела смысла :)

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

Профессия бизнес-аналитика показалась мне наиболее близкой. Опыт работы с клиентами у меня уже имелся, исходный код я читать умел, что очень пригодилось в проектах без какой-либо документации. User Stories сам себе я также писал. Осталось собрать весь опыт в кулак и хорошо продать себя. И снова Ctrl + H — я стал Business Analyst with strong technical background. По собеседованиям я заметил, что бывших программистов берут в аналитики с бо́льшим удовольствием, чем непрограммистов, что тоже было для меня плюсом. Я нашел свою компанию, в которой разработка велась по каноническому Скраму, и по этим же канонам меня стали называть Product Owner.

Играть в Скрам мне нравилось. У каждого своя четкая роль, задачи и сфера ответственности. Бесконечные митинги, ревью, обсуждения... Правила я выучил довольно быстро. С обязанностями, за которые мне платили зарплату, я справлялся где-то за 60% времени. Остальное время я пропадал на производстве. Изучал документацию, структуры баз данных, взаимосвязи между всеми программными продуктами производственной линейки, а их было больше сотни. Расспрашивал клиента о тех или иных бизнес-процессах, просил потрогать агрегаты. В общем, я был таким маленьким ребенком, которому все интересно, — развлекался как мог.

Через полгода произошло событие, которое помогло мне получить значительное повышение зарплаты в компании, где обычный цикл повышений длится один год и пересмотр ставки вне очереди необходимо согласовывать чуть ли не с CTO. У начальника отдела случилось эмоциональное выгорание (aka burnout), и на несколько месяцев я как мог стал вести его проекты. Это был самый сложный период в моей карьере, который, однако, был и самым полезным. Я перестал бояться брать на себя любую ответственность, а также понял, что иногда с клиентом все же нужно говорить на «ты». Когда уверен, что даешь ему больше, чем получаешь.

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

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

Этап 5. Не получается брать качеством, берем количеством

Период: 2015
Средняя зарплата: $3500 + $1000 = $4500
Должность: Senior Business Analyst, C# Developer
Где:консалтинговая компания в Европе + удаленка

Меня перевели в материнскую компанию на должность IT Business Consultant. Это такой человек, который сначала рассказывает клиенту сказки о прекрасном будущем с несуществующим продуктом, а затем, когда сейлзы эту сказку продали, воплощает ее в реальность с помощью команды опытных мотивированных коллег-программистов и аналитиков. В сети есть множество мемов «ожидание vs реальность», так вот это было про меня и проекты, в которых я участвовал.

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

Вспоминая то время, жалею только о соцпакете. 5 недель отпуска, брать можно как хочешь — мы уходили в недельный отпуск до пяти раз в год. Болеешь 3 дня без больничного — можно было уходить в запой на выходных и к четвергу выходить на работу как ни в чем не бывало, и это сколько угодно раз в году. Полная медицинская страховка, возможность уйти на 6 месяцев посидеть с нынче модным эмоциональным выгоранием. Целых 14 зарплат в году: на Рождество и к летнему отпуску выдается двойная зарплата, а в начале года — годовой бонус. И талоны на обед :) В этой зоне комфорта можно было оставаться бесконечно. Что и делают до сих пор мои глубокоуважаемые коллеги, с которыми я уезжал в Европу учиться. Но я не искал легких путей. «Есть зона твоего комфорта, а есть места, где случаются чудеса», — еще один аноним.

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

Этап 6. Home Sweet Home

Период: 2016
Средняя зарплата: $5500
Должность: BA, PM
Где:удаленка через ФОП в Украине

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

Видимо, клиент в меня поверил, и мне дали тот рейт, о котором я всегда мечтал, когда в детстве слышал: «Вот когда будешь директором с зарплатой $5000 тогда и будешь умничать». Директором я не стал, однако умничать зарплата уже позволяла. И снова работа с дома, self control и домашние тапочки... Уже в то время я понял, что работать в офис я не вернусь, наверное, никогда. Для меня те несколько часов в день, складывающиеся в дни и недели жизни, которые я не трачу на поездки в офис, командировки и обеды, дороже любых денег. Время ведь не купишь и не вернешь.

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

Этап 7. Настоящее

Период:2017-сейчас
Средняя зарплата: $7000
Текущая зарплата: $8000
Должность: Project Manager, R&D Manager
Где:удаленка через ФОП в Украине

В конце статьи вас, дорогой читатель, ожидает небольшой «облом»: о моем текущем проекте я расскажу меньше, чем о предыдущих. Я очень дорожу отношениями со своими коллегами и клиентом и не хочу ни случайно, ни специально «писнуть» ничего лишнего, о чем потом буду жалеть. Может, пройдет пару лет, и я буду писать еще одну статью о зарплате при достижении следующей планки в 10K, тогда и опишу текущий проект. А может, через год уйду пилить какой-нибудь свой стартап факап и вообще не вернусь даже на текущий уровень. Жизнь непредсказуема.

Конечно, я продолжаю делать то, что умею. Делаю это с полной отдачей. Я больше не кодирую, редко смотрю чужой код, однако раз в несколько месяцев запускаю Visual Studio и пишу, чтобы не потерять сноровку. Мой текущий акцент в работе — это проектный менеджмент. Моя главная цель — наконец-то стать Senior. А соответствующая зарплата приложится :)

Выводы

Зарплата $8000 в месяц — это много или мало? Смотря с чем сравнивать. $96 тыс. в год недотягивают до средней зарплаты хорошего проектного менеджера в США — $105-120 тыс. А чтобы выплачивать такую зарплату, работодатель должен иметь еще процентов на 30 больше в фонде зарплаты, то есть около $150 тыс. Зарплаты проектных менеджеров в Швейцарии, Сингапуре, Ирландии, Австралии еще выше. Я говорю о gross. То, что в Украине gross практически соответствует net, а также важность частных пенсионных фондов и социального страхования — темы для отдельной статьи.

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

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

Будьте уверены в себе. Если вы делаете свою работу на 120%, то и оплачиваться она должна соответственно. Не бойтесь просить. Однако перегибать палку тоже не стоит. Как вы помните, мой первый ультиматум закончился печально. Хорошо, что только первый.

Ну и напоследок. Постоянно улучшайте себя и свое окружение. Сделайте Continuous Improvement своей главной рабочей философией, и регулярное повышение вашей рыночной стоимости вам гарантировано!

P. S. Если у вас есть интересные вопросы, ответы на которые помогли бы вам в вашей конкретной ситуации, и вы считаете, что я смог бы вам помочь, пишите мне на dou.article.feedback@gmail.com. Могу вдохновить, направить, послать :)

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

Спасибо маме, крестной маме и синьору! Без вас я бы не достиг и половины того, что умею и имею сейчас.

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

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

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

Binary Studio Academy

Напрям:курси JS, PHP, .NET, QA.
Місто:онлайн.
Дедлайн подачі заявок: 3 травня.

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

• мати базові знання з JS / .NET / PHP / QA;
• вміти працювати з даними (наприклад, через SQL), розуміти принципи ООП та / або ФП;
• знати англійську на рівні розуміння документації;
• приділяти навчанню від 8 до 12 годин на день з липня по 14 вересня;
• не має значення: вік, місце проживання та рівень здобутої освіти.

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

Умови:Липень — лекції, напрацювання теоретичної бази. ~ 15 відеолекцій від топових розробників Binary Studio з домашніми завданнями. Виконані завдання проходять код-рев’ю у викладача, який вказує на помилки та пропонує, як оптимізувати твоє рішення.

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

Демо завершених проектів учасники презентують на випускному 14.09 у львівському офісі компанії Binary Studio.

Деталі:на сайтіпишіть на пошту academy@binary-studio.comабо телеграм боту @AcademyRoBot.

Edvantis

Напрям:курси HTML/CSS/Javascript, Python.
Місто:Львів.
Дедлайн подачі заявок: 10 травня.

Вимоги до кандидатів:студенти 3-4курсів з профільною освітою.

Як потрапити:зареєструватисяабо відправити резюме на job@edvantis.com. Пройти тестування з Technical Test, English Test, Personality Test в офісі компанії.

Умови: Bootcamp триватиме 6 тижнів з 03.06 — до 12.07. Кожного робочого дня. Обов’язкова присутність в офісі не менше 6 годин. Викладачі — провідні спеціалісти Edvantis. Кожен випускник Bootcamp 2019 має шанс потрапити на роботу в компанію.

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

EPAM

Тип:курси.
Місто:Київ, Львів, Харків.

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

Київ:

• QA — 13 травня;
• Design — 17 травня;
• DevOps — 6 травня;
• Java — 30 квітня;

Львів:

• QA — 17 червня.

Харків:

• Test Automation — 15 червня;
• Front-end — 2 червня;
• Software Testing Introduction — 8 червня;
• DevOps — 15 червня;
• .NET — 15 червня;
• Java — 15 червня.

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

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

GeeksForLess

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

Вимоги до кандидатів:для зарахування необхідно володіти базовими знаннями MySQL та OC Linux.

Як потрапити:надсилайте свої резюме з поміткою «курси по базам данних MySQL» на mykolayiv@geeksforless.comдо 10 травня та домовляйтесь про співбесіду.

Умови: 3 рази на тиждень по 2 години.
Деталі:у Facebookабо пишіть на пошту mykolayiv@geeksforless.com.

NIX Solutions Ltd

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

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

• практика .NET;
• практика Android;
• навчання Business Analysis;
• практика Front-end;
• практика iOS;
• навчання Java;
• інтенсив JavaScript;
• практика PHP+CMS;
• практика PHP;
• навчання Ruby;
• інтенсив Angular;
• навчання Linux Administration / DevOps.

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

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

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

QATestLab

Напрям:онлайн-курси QA.
Дедлайн подачі заявок:реєстрація відбувається постійно. «Основи тестування ПЗ» — старт 18 червня.

Вимоги до кандидатів:навчатися можуть усі охочі.

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

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

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

RubyGarage

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

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

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

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

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

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

SoftServe

Тип:курси.
Місто:Львів, Київ, Рівне, Івано-Франківськ, Чернівці, Харків.

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

• Python: Харків — 2 липня;
• DevOps: Львів — 3 травня, 6 червня, Київ — 17 червня;
• .NET: Львів — 7 травня, Дніпро — 13 травня, Чернівці, Харків — 3 червня;
• Java : Львів — 6 червня, Чернівці — 17 червня;
• Test Automation: Рівне (Pytnon) — 6 травня, Львів (.NET) — 17 травня, Чернівці (Pytnon) — 10 червня;
• QC: Рівне — 16 травня, Львів — 2 червня, Івано-Франківськ — 17 червня, Чернівці — 24 червня;
• Software Engineering in Test: Львів — 15 травня;
• WebUI/Node.js Development: Львів — 6 травня;
• WebUI Development: Дніпро — 22 травня, Харків — 2 липня;
• Golang Development: Дніпро — 5 червня.

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

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

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

Synebo

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

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

• англійська рівня intermediate / upper-intermediate;
• бакалавр або спеціаліст / магістр в області ІТ (або суміжних спеціальностях);
• розуміння принципів ООП;
• навички програмування на Java, C ++ або C #;
• базове знання HTML, CSS і JavaScript.

Як потрапити:заповнити заявку.

Умови:початок занять — 13 травня. Курс триватиме 4 тижні по 2 заняття на тиждень, тривалість кожного — 1,5 год. Найкращих студентів запрость на роботу.

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

ABTO Software

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

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

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

Як потрапити:надіслати резюме nataliya.babirad@justanswer.comпройти відбіркове інтерв’ю та технічну співбесіду в офісі.

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

Деталі:пишіть на пошту nataliya.babirad@justanswer.com.

AMC Bridge

Напрям:стажування C++, C#, web services.
Місто:Дніпро, Львів, Суми, Хмельницький, Чернівці.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:студенти 3-6-го курсів технічних спеціальностей вищих навчальних закладів. Термін стажування повинен збігатися з навчальним планом ВНЗ.

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

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

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

DataArt

Напрям: .NET, Design, Java.
Місто:Харків.
Дедлайн подачі заявок:немає.

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

• базові знання за обраним напрямком;
• володіння розмовною англійською.

Як потрапити:надіслати резюме на hr-kyiv@dataart.com, пройти співбесіду англійською, а також технічну з ментором.

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

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

EVO

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

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

Mobile

• ідеальний кандидат любить програмувати, удосконалюється в розробці і проектуванні;
• знає структури даних і алгоритми;
• володіє і вміє в ООП (застосовує без шкоди для себе і оточуючих :)
• розуміє, як взаємодіють клієнтські і серверні додатки;
• вміє працювати з базами даних;
• знайомий з багатопоточністю (синхронізація доступу, атомарність операцій, часті проблеми);
• знайомий з git;
• для iOS-напрямку — знає одну з мов SWIFT / ObjC / C ++;
• для Android-напрямку — знає Java і знайомиться з Kotlin (Generics, Collections і операції з ними).

Python

• кандидати мають кілька pet-проектів (щось для себе або тренування в будь-якої технології) на Python / JavaScript / Go / Ruby;
• добре розуміють, що набагато важливіше знання самої мови, а не фреймворків;
• мають теоретичні знання в Computer Science — алгоритми, структури даних;
• можуть розгорнути сайт на простому хостингу (heroku, digitalocean);
• вміють читати свій і чужий код;
• розбиралися на базовому рівні з різними API;
• мають знання SQL (прості запити в базу: select, joins, group by);
• цікавляться, що відбувається в сучасних web-технологіях (бібліотеки і тд);
• знають про практики хорошого коду (codestyle, тести, SOLID);
• знають, що таке DOM і як з ним працювати;
• розуміють, що помилка на етапі визначення вимог коштує найдорожче;
• якщо потрібна функція з 10 рядків, то не обов’язково тягнути в проект сторонню бібліотеку, в якій ця функція реалізована;
• знайомі з системами контролю версій;
• знайомі зі стандартною бібліотекою Python;
• знайомі з основами JavaScript і чимось зі сторонніх бібліотек.

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

Умови:інтернатура триває 2 місяці з 2 липня приблизно з 11-00до 18-00.Можливе працевлаштування.
Деталі:на сайті Mobile, Python.

groupBWT

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

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

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

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

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

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

HYS Enterprise

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

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

• поглиблене знання OOP;
• поглиблене знання HTML / CSS (Twitter Bootstrap), JavaScript (jQuery);
• знання і досвід з C#, Microsoft.NET (ASP.NET, MVC, ADO.NET, WCF);
• знання веб-сервісів, XML, UML, VSS;
• розуміння Back-end and Front-end розробки;
• рівень англійської Upper-Intermediate є обов’язковим.

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

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

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

InterLink

Напрям:стажування Java+Angular.
Місто:Черкаси.
Дедлайн подачі заявок: 10 червня.

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

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

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

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

Деталі:на сайті, або пишіть на пошту hr@interlink-ua.com, в месенджерчи телефонуйте 068 496 30 60.

Kozak Group

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

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

• хороші знання PHP, OOП, JS, HTML, CSS;
• англійська від Intermediate;
• плюсом буде досвід роботи на позиції PHP Developer від 6 місяців і вільна англійська.

Як потрапити:надіслати резюме і приклади робіт на пошту yulia.kozak.hr@gmail.com.

Умови:стажування триватиме 2 місяці. У разі успішного навчання — працевлаштування. Гнучкий графік.

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

Leobit

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

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

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

Як потрапити:надіслати резюме на cv@leobit.co, виконати тестове завдання, пройти співбесіду по телефону та технічну в офісі.

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

Деталі:на сайтіабо пишіть на пошту cv@leobit.co.

MacPaw

Напрям:стажування macOS/iOS Development, Quality Assurance, Product Management, Agile, Customer Care, PPC, Design.
Місто:Київ.
Дедлайн подачі заявок: 5 травня.

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

• вік стажерів — від 18 років;
• знання англійської мови Intermediate+;
• базові знання з обраного напрямку стажування (орієнтир — профільне завдання, яке є частиною онлайн-форми реєстрації).

Як потрапити:заповнити анкетуі успішно виконати тестове завдання до 5 травня; пройти співбесіду з HR-менеджером та менторами напрямку.

Умови:програма триватиме з 10 червня по 30 серпня. На стажерів чекає повна зайнятість та робота з ментором у київському офісі компанії (30 годин на тиждень), стипендія на весь період стажування, робота над реальними продуктами, повне занурення в культуру та життя ІТ-компанії. В якості залікової роботи — розробка продукту та його презентація із іншими стажерами.

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

Quality Assurance Group

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

Вимоги до кандидатів:курс можуть проходити усі охочі.

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

Умови:стажування повністю присвячене практиці. Студенти працюють з реальними проектами самостійно у групах під керівництвом координатора і таким чином отримують досвід роботи та напрацювання у якості прикладу своїх робіт. Робота проходить з баг-трекінговою системою Jira; Zephyr test management tool, Test Rail, Jmeter ect. Навчання проводять спеціалісти компанії QArtrock.

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

Right&Above

Напрям:стажування QA (manual), Java, Front-end, iOS, Android.
Місто:Київ.
Дедлайн подачі заявок:немає.

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

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

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

Деталі:у Telegram.

RubyGarage

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

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

• рівень англійської: Strong Intermediate та вище;
• теоретичні знання QA (проходження курсів або досвід роботи до 6 місяців).

Як потрапити:відправити резюме на пошту recruiting@rubygarage.orgз темою листа «QA інтернатура RubyGarage». Пройти 3 етапи відбору: тестове завдання, тест англійської та співбесіду з технічним спеціалістом.

Умови:програма складається із теоретичних занять та практичних завдань для підготовки спеціалістів з мануального тестування. Кожний інтерн також отримує підтримку досвідченого ментора. Після успішного виконання технічного завдання найкращі інтерни отримують оффер на позицію Junior QA. Будь ласка, зверніть увагу, що інтернатура проходить в офісі RubyGarage на full-time основі.

Деталі:пишіть на пошту recruiting@rubygarage.org.

Samsung R&D Institute Ukraine

Напрям:стажування Artificial Intelligence/Machine Learning.
Місто:Київ.
Дедлайн подачі заявок: 3 липня.

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

• студенти 3-6курсів або аспіранти;
• знання із фундаментальних дисциплін (математика, фізика, статистика);
• базові знання C/C++, Java (достатньо базового синтаксису).

Як потрапити:відправити своє резюме на srk.hr@samsung.com. У листі необхідно вказати ваше ім’я та прізвище англійською (як у закордонному паспорті). Тема листа — «SRK Internship 2019-2020 | Name Surname». Отримати запрошення на тест. Прийти до центру та здати тест. Тестування проводиться кожного четверга, триває 4 години (14:00 до 18:00), є лише 3 спроби. Пройти співбесіду. Якщо успішно пройшли всі етапи — ви зараховані!

Умови:тривалість: 6 — 12 місяців, ви отрмуєте грошову підтримку, напрямки: Artificial Intelligence/Machine Learning (із застосуваннями у Security, Augmented Reality/Virtual Reality, Visual Understaning). Групи по 2-5 учасників,що працюють над високотехнологічним проектом у режимі start-up, кожну группу ведуть досвідчені наставники, гнучкий графік роботи: 20 годин на тиждень (час може бути збільшено за спільною згодою).

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

Sigma Software University

Тип:стажування.

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

• Project Manager (Web and Mobile): Харків — 26 квітня;
• Project Manager: Харків — 26 квітня;
• JavaScript: Харків, Львів — 26 квітня;
• Embedded: Львів — 20 травня.

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

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

SoftServe

Напрям: R&D incubator.
Місто:Львів.
Дедлайн подачі заявок: 24 квітня.

Вимоги до кандидатів:студенти будь-якого року навчання, які мають необхідні знання та досвід і готові інвестувати 20+ годин на тиждень у проект.

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

Умови:програма передбачає паралельну роботу двох груп за напрямками: Доповнена реальність та Штучний інтелект. У кожній групі буде по 4 людини. R&D Incubator триватиме із 02.05 по 02.08 у Львові в офісі SoftServe. Кожного тижня експерти компанії проводитимуть учасникам інтенсиви або воркшопи за напрямками фінанси, маркетинг, інтелектуальне право, продажі, дизайн тощо. Під час програми учасникам надається щомісячна стипендія у розмірі $200. Ті, хто успішно завершить програму, отримає грошовий бонус і запрошення на роботу.

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

Steelkiwi

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

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

• добре знання ООП;
• добре знання реляційних баз даних;
• досвід роботи з VCS;
• сильне знання * nix систем;
• розуміння клієнт-серверної архітектури і принципів розробки API;
• англійська Intermediate.

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

Умови:повний робочий день. 3 місяці оплата 1000 грн, наступні 3 місяці — $350, потім працевлаштування із оплатою $500.

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

TeamDev

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

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

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

Як потрапити:заповнити реєстраційну форму, надіслати резюме за адресою work@teamdev.com. Надіслати приклад вашого коду — це може бути будь-який код на будь-якій мові програмування: покажіть код, яким ви пишаєтеся! Пройти співбесіду з фахівцями компанії.

Умови:перший місяць — теоретична підготовка з практичними заняттями. Другий — стажування на проекті. Виконана протягом програми робота буде оплачена. Найкращі студенти будуть запрошені у команду TeamDev.

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

White Label Agency

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

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

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

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

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

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

БАКОТЕК

Напрям:стажування адміністрування баз даних.

Місто:Київ.

Дедлайн подачі заявок:немає.

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

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

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

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

Деталі:Tetiana.Gnidets@bakotech.com, 067-51-68-487.

Competera

Напрям:робота Python Developer.
Місто:Київ.

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

• бажання писати високоякісний код;
• мінімум півроку досвіду розробки на Python;
• знання фреймворка Scrapy (з ним пов’язане тестове завдання);
• принаймні Intermediate англійська (читання технічної документації).

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

Деталі:на сайтіабо пишіть на пошту k.tsiapusta@competera.net, @c_kapusta.

Expercast

Напрям:робота QA, UI/UX Designer, Content Curator, Recruiter.
Місто:віддалено.

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

• сильні навички вирішення проблем і здатність швидко навчатися;
• високий рівень ініціативи та творчості;
• англійська мова Upper-intermediate;
• для Junior QA Engineer — навички ручного тестування та початкові знання JavaScript, SQL, HTML/CSS;
• для дизайнерів — навички створення графічного дизайну для web та мобільних додатків.

Як потрапити:надіслати резюме на сайті UI/UX Designer, Content Curator, QA, Recruiter.

Умови:віддалена робота, гнучкий графік.
Деталі:на сайті UI/UX Designer, Content Curator, QA, Recruiterабо пишіть на пошту artur.sargizov@expercast.com.

GlobalLogic

Напрям:робота QA, DevOps.

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

• Manual QA: Київ;
• Automation QA: Київ;
• DevOps: Харків;
• DevOps: Львів.

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

Agilites

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

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

• вища освіта та/або курси QA;
• гарне знання теорії тестування програмного забезпечення;
• розуміння SDLC;
• базове знання SQL, SOAP та XML.

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

Умови:випробний термін — 2 місяці (з виплатою зарплатні з першого дня), після успішного проходження — подальше працевлаштування. Великий ентерпрайз-проект, в команді 20+ QA інженерів. ЗП $250–450.

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

Biencode Ukraine

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

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

• розуміння концепцій методології OOD;
• знання мови C #, NET платформи;
• базові знання JavaScript, HTML, CSS;
• англійська.

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

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

Codeminders

Напрям:робота Researcher in Formal Methods.
Місто:Київ.

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

• вища освіта у галузі комп’ютерних наук;
• досвід у цих сферах буде перевагою: Programming Languages, Logic, Static Code Analysis, Abstract Interpretation, Automated Proof Assistants, SAT/SMT Solvers, Functional Programming;
• здатність проводити незалежні дослідження;
• важливм є знання англійської мови, здатність швидко вчитися, аналізувати інфоромацію.

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

Умови:повний робочий день.
Деталі:на сайті.

Jooble

Напрям:робота HTML.
Місто:Київ.

Вимоги до кандидатів:базові знання будь-якої мови програмування, знання HTML.

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

Умови:гнучкий графік.
Деталі:на сайтіабо пишіть на пошту hr@jooble.com.

LoopMe

Напрям:робота JavaScript.
Місто:Дніпро.

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

• практичний досвід та / або курси на JavaScript (ES6);
• упевнені навички використання HTML5 / CSS3;
• практичний досвід у адаптивному веб-дизайні;
• зацікавленість у анімації та інтерактивному дизайні.

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

Деталі:на сайтіабо пишіть на пошту oksana.boiko@loopme.com, olha.mohunova@loopme.com.

N-iX

Напрям:робота QA, BI.
Місто:Львів.

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

Як потрапити:надіслати резюме на сайті QA Automation Engineer, BI Software Engineer.

Деталі:на сайті QA Automation Engineer, BI Software Engineerабо пишіть на пошту recruitmentteam@n-ix.com.

NIX Solutions Ltd

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

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

• QA Engineer;
• Tech Support Engineer;
• QA/BA Engineer;
• Data Scientist;
• .NET Developer for Modern Stack Long Term Project;
• Data Analyst;
• QA Automation Engineer (Python);
• General QA Junior;
• Android developer;
• Data Engineer;
• Sales Manager;
• Market Researcher/Lead Generator Specialist.

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

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

Tickets.ua

Напрям:робота Ruby on Rails Developer.
Місто:Львів.

Вимоги до кандидатів:півроку досвіду розробки на Ruby on Rails або PHP.

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

Умови:гнучкий графік.
Деталі:на сайті.

Ubisoft

Напрям:робота.
Місто:Київ — Game Tester (QC), Одеса — C++ Programmer.

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

Game Tester (QC)

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

C++ Programmer

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

Як потрапити:надіслати резюме на сайті C++ Programmer, Game Tester.

Умови:повний робочий день.

Деталі:C++ Programmer, Game Tester.

YouScan

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

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

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

Умови:стандартний робочий тиждень, 5-8годин на день за гнучким графіком, можливість працювати віддалено.

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

Съемочная группа DOU Ревизоруже была в компании Innovecs зимой 2014 года. С тех пор число специалистов в ее киевской команде выросло в два с половиной раза, а офис расширился еще на три этажа.

Innovecs — глобальная IT-компания с офисами в Нью-Йорке, Сан-Франциско, Лондоне, Тель-Авиве и R&D-центрами в Киеве и Николаеве. Компания основана в 2012 году и специализируется на разработке программного обеспечения для рынков Supply Chain & Logistics, Healthcare, Gaming & Entertainment, Retail & E-Commerce, Media & AdTech.

В настоящее время команда Innovecs насчитывает 609 человек. В Киеве работают 570 человек, 520 из них — технические специалисты.

В округе и поблизости

В здание БЦ «Премиум» по адресу ул. Вацлава Гавела, 6з, компания переехала еще весной 2013 года. Станция метро «Берестейская» находится в 20 минутах ходьбы от офиса. Отсюда каждые 15 минут отправляется автобус «Богдан», доставляя специалистов, работающих в этом бизнес-центре.

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

• В здании бизнес-центра расположен банкетный зал «Балалайка», комплексный обед в котором обойдется приблизительно в 70 гривен.
• Обед в кафе «Food Простір», которое тоже находится в бизнес-центре, будет стоить около 100 гривен.
• Стоимость бизнес-ланча в пиццерии Mamamia! в соседнем с офисом здании — 115 гривен.
• Также в минуте ходьбы от бизнес-центра расположено кафе Lviv Croissants, где средний чек составляет примерно 80 гривен.
• Стоимость обеда в Silver Cafe, расположенном в 6 минутах ходьбы от офиса, — около 90 гривен.

В одной башне с компанией находится премиум-отделение «Укрсиббанка», а в соседних зданиях — отделение «ПриватБанка» и «Райффайзен Банк Аваль».

Поблизости есть небольшие магазины, такие как «АТБ маркет» — в 5 минутах ходьбы от офиса, и «Фора», до которой идти 8 минут. К ближайшим отделениям «Новой почты» от офиса Innovecs можно добраться пешком за 15–20 минут.

В распоряжении специалистов Innovecs две платные автомобильные парковки: одна — на 44 места (плюс 3 парковочных места для кандидатов) с внутренней стороны бизнес-центра, другая — на 60 мест в 15 минутах ходьбы от офиса. Место на наземной парковке бизнес-центра стоит 1500 гривен в месяц, на подземной — 1800, на дальней — 600. Чтобы получить собственное место на платной парковке, нужно записаться в FIFO-очередь (first in first out — первым получает обслуживание тот, кто первым встал в очередь. — Ред.)и дождаться, когда освободится одно из уже закрепленных мест. Можно также занять место на бесплатной парковке перед бизнес-центром, но для этого желательно приехать на работу к семи-восьми часам утра.

Мотоциклистам и велосипедистам для бесплатной парковки доступны всего 10 мест.

Офисный быт

Офис Innovecs занимает 5-йи 9–13-й этажи бизнес-центра; весь 10-йэтаж выделен под склад. Общая площадь всех помещений составляет 5400 м². В среднем на одного человека приходится 9,4 м², включая места общего пользования. Если считать исключительно рабочее пространство, получится 5,5 м².

Офис открыт 24/7, длительность рабочего дня составляет 8 часов. Как правило, график работы команд — с 10 до 19 часов, но работать можно и с 11 до 20, и с 9 до 18 — все зависит от задач и проекта. Чтобы договориться об индивидуальном графике, нужно согласовать его с руководителем. Некоторые команды находятся в офисе с 20 до 5, поскольку у них американские заказчики.

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

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

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

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

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

Каждый день в офис доставляют еду из заведений «Желтое море», DetoxBar и «Віденські булочки». Оплатить ее сотрудники могут с помощью терминалов, которые установлены возле некоторых холодильников, или отсканировав QR-код в приложении «Приват24».

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

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

Рабочее пространство

Рабочие зоны представляют собою open space на 40 человек. В каждой команде уникальная атмосфера. Например, в отделе, где занимаются проектом одного израильского заказчика, развешаны экраны, на которых локальные мемы сменяются анонсами. В команде есть номинация «Герой месяца», победитель в которой получает премию в 500 долларов, а его портрет размещают на одном из таких экранов.

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

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

Если же сотрудник хочет заменить или заказать что-нибудь дополнительно, например монитор, то он через бота отправляет запрос в Jira. По словам специалистов Innovecs, обработка такого запроса занимает, как правило, 1–2 дня,если в нем нет ничего специфического. Когда же сотрудник хочет конкретный монитор Dell или новый iMac Pro, причем он договорился об этом с заказчиком проекта и доказал, что это действительно необходимо, то срок выполнения запроса сдвигается, поскольку такую технику нужно заказывать, а не просто выписывать со склада. Все зависит от сложности запроса. Увлажнитель воздуха могут принести и в течение часа.

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

Переговорных в офисе более чем достаточно — на каждом этаже от 5 до 10 таких комнат. Бронируются они через календарь Office365.

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

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

У специалистов есть 10 дней в году для удаленной работы. На постоянной основе удаленно трудится 3% разработчиков.

Отдых и вдохновение

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

Есть в офисе шахматы и акустические гитары. Но если шахматы — это спорт, который не производит лишнего шума, то на гитарах можно играть тихо в обед или уже после работы. У некоторых специалистов на рабочем месте есть и собственные музыкальные инструменты. Например, R&D-менеджер Алексей для команды DOU Ревизор сыграл пару аккордов на своей электрогитаре.

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

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

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

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

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

Хаб активно используют для празднований и развлекательных событий внутри компании. Специалисты Innovecs собираются здесь на корпоративные вечеринки, просмотр футбольных матчей, вечера кино, а недавно в хабе проводили PlayStation-турнир по FIFA и отмечали 8 Марта.

DOU Ревизор спрашивает

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

Андрей, Senior Software Development Manager, 6 лет с компанией

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

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

Василий, Motion Designer, 5 месяцев с компанией

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

Из офисных фич попробовал, в принципе, все. Правда, как-то записался на массаж, спланировал сеансы на целый месяц — и так ни разу и не сходил, все отдавал другим. Постоянно что-то мешало: то тренировка, то английский, то встречи по проекту. Мы работаем на ноутбуках. Конечно, десктопные компьютеры мощнее, чем ноуты, зато у нас есть возможность работать в любом месте без привязки к рабочему месту. У любой медали две стороны, но я рад, что у нас именно ноуты. Самое главное здесь — взаимодействие. По своему проекту можно договориться о чем угодно. Например, работать не по 8 часов, а меньше. Если ты успеваешь выполнять свои задачи быстрее, то почему бы и нет?

Даниил, Software Development Manager, 4 года с компанией:

Из рабочей техники у меня всегда были «маки». Но последние полтора года я использую свой компьютер, поскольку с ним мне проще путешествовать и вообще быть мобильнее. Не всегда хочется брать рабочий компьютер. Плюс так лучше по ISO. Мне нравится наша лаундж-зона, иногда хочется просто уйти туда и отдохнуть. Но у меня есть свой угол, где я могу и почитать что-то по работе, и отдохнуть. Ребята всегда стараются улучшать что-то в офисе. Постоянно что-то меняется. Раньше была проблема с едой, но сейчас обновили холодильники, да и меню стало гораздо разнообразнее. Чуть ли не каждый год меняется страховка, потому что мы в вечном поиске лучшего предложения.

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

Дмитрий, Front-End Developer, 8 месяцев с компанией

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

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

Мы катаемся по Украине в поисках самых креативных и нестандартных офисов ИТ-компаний. Вместе с нами вы сможете заглянуть за кулисы офисной жизни. Но решать, хороший этот офис или нет, будете только вы!

Следите за нами на Facebook.

Подписывайтесь на канал DOU Ревизор на YouTube.

[DOU Hobby — рубрика о нетехнических проектах IT-специалистов: творчество, интересное хобби и другие lifestyle-достижения. Если вам есть о чем рассказать — пишите на valentina@dou.ua]

Дмитрий Леонов — тимлид и тестировщик на проекте Avid (решения для аудио- и видеопродакшена — ред.)в компании GlobalLogic. А еще он музыкант. В этом году Дмитрий вместе со своей группой Brunettes Shoot Blondes, где он выполняет роль бас-гитариста и бэк-вокалиста, вышел в финалнационального отбора на «Евровидение». В интервью для DOU Дмитрий рассказал о том, что общего у музыки и IT, возможно ли музыканту жить, а не выживать, а также, как IT балует творческих людей.

Brunettes Shoot Blondes, фото Кирилла Светашова

— Дмитрий, с чего все началось для вас в IT?

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

Как-то друг посоветовал мне загрузить свое резюме на один сайт по поиску работы. Я так и сделал. И вскоре в одной из вакансий наткнулся на фразу Pro Tools editing — единственное слово, которое я знал, потому что сам пользовался этим продуктом в студии звукозаписи. Это была вакансия тестировщика. Я полез читать, что это такое, как это вообще получается, что софт, которым я пользовался в студии звукозаписи, создается в Киеве, чем эти люди занимаются. Но я не сразу попал в компанию. Нужно было пройти много интервью. На тот момент нужно было постараться, чтобы попасть на проект, не имея вообще никакого опыта работы.

— А музыка?

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

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

— В каких еще группах вы играли и как попадали туда? Почему покидали их?

Сразу после переезда в Киев меня познакомили с барабанщиком из моего родного города Запорожья. На тот момент он был довольно известным в Киеве музыкантом, успел поиграть в составе Esthetic Education. Его собственной группе тогда нужен был клавишник, и он предложил мне поиграть с ними. Так я попал в музыкальную тусовку. В это время я был студентом, утром ходил на пары, а остаток дня пропадал на репетициях, студиях и концертах. Так было до момента, когда я устроился работать в GlobalLogic. Еще некоторое время я играл в джазовой группе, но совмещать было трудно. Музыкальная пауза в моей жизни длилась около полугода.

Концерт с группой Alloise, 2012 год

Я был знаком со звукорежиссером группы «Крихітка», в прошлом — «Крихітка Цахес». Он предложил мне поработать с ними над одной песней, а затем меня пригласили отыграть с «Крихіткой» несколько концертов, выступить на открытии «Евро-2012», на фестивале Zaxid Fest. С Сашей Кольцовой и группой я дружу по сей день. В 2017 году мы сняли лайв трех песенна студии в рамках Istok Live Sessions. Сегодня я постоянный участник группы Brunettes Shoot Blondes. Я был знаком с их клавишником и саунд-продюсером около полутора лет. В сентябре2017-гоу ребят было запланировано два концерта, но их тогда покинул бас-гитарист. У меня как раз была бас-гитара, я немного умел играть, но никогда не думал, что буду басистом. Парни предложили сделать пробную репетицию, и уже через несколько дней мы ехали вместе на концерт в Ужгород.

— Музыка была вашим хобби?

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

— Что можно позволить себе, занимаясь только музыкой? Как жить, а не выживать?

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

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

В составе BSB на фестивале Atlas Weekend 2018

— То есть жить небедно можно.

Запросто. Зарплата топового музыканта оперного театра или национального симфонического оркестра сравнима с зарплатой Middle/Senior Engineer в сфере IT. Среди эстрадных (джазовых) музыкантов есть практика работать на круизных лайнерах в составе главного оркестра или более малочисленных коллективов. После нескольких таких круизов можно приобрести недорогое жилье в Киеве, конечно, если не тратить все заработанное в каждом порту, куда заходит лайнер.

— Что бы вы посоветовали молодым музыкантам, исходя из собственного опыта?

Советы довольно просты:

1. Не загонять себя в рамки.
2. Не бояться экспериментировать.
3. Инвестировать в хорошие инструменты, которые ты используешь.
4. Освоить несколько музыкальных инструментов. Когда ты мультиинструменталист, у тебя больше свободы в музыкальном самовыражении. Это делает тебя чем-то вроде универсального солдата в музыке.

— С одной стороны, вы тимлид и тестировщик, с другой — музыкант в группе, которая вышла в финал национального отбора на «Евровидение». Что общего в этих сферах?

На самом-то деле общего мало. Музыку можно рассматривать как шоу-бизнес, где, в принципе, работают свои законы. Хотя сейчас, когда в открытом доступе легко можно найти принципы работы в большой компании и другое, уверен, в шоу-бизнесе тоже, возможно, применяются технологии Agile, может быть, SCRUM, хотя и не так серьезно, как это происходит в IT-компаниях. Я знаю, что в одной известной украинской телекомпании успешно внедрили методологию Agile. Ребята ходили на тренинги, у них это, кажется, заработало, и все были в восторге от такой возможности лучше контролировать рабочий процесс. Думаю, что в плане методологии эти сферы могут соприкасаться.

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

— Тогда обязательно ли быть музыкантом или иметь музыкальное образование, чтобы разрабатывать музыкальное программное обеспечение?

Я скажу откровенно: было бы намного лучше, если бы наши программисты были немножко музыкантами. Это та деталь, которая очень отличает украинских программистов, работающих над музыкальным программным обеспечением, и таких же программистов из США или Германии, например. Там люди, которые пишут код, зачастую минимально умеют играть на гитаре, барабанах, или же они в прошлом музыканты. Они профессионалы в одной сфере, приходят с этим опытом в другую, переучиваются и трансформируют свой опыт. И такому человеку работать в проекте вдвойне интереснее. Кстати, там и вариаций таких проектов больше, чем у нас. Насколько мне известно, почти все топовые компании, разрабатывающие профессиональное ПО для работы со звуком, были созданы либо в Германии, либо в США, где их ресурсы сосредоточены до сих пор. Не все компании решают отдать часть своего продукта на аутсорс.

С барабанщиком Brunettes Shoot Blondes

— То есть быть немножко музыкантом все же нужно.

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

— Ваша группа Brunettes Shoot Blondes вышла в финал национального отбора на «Евровидение». Как все это выглядело с технической точки зрения?

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

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

— А если говорить о конкурсе и опыте в IT, они пересекались?

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

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

Brunettes Shoot Blondes, фото Кирилла Светашова

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

— Что для вас значит выход в финал нацотбора на «Евровидение»?

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

— Как вы стали тимлидом?

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

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

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

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

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

— Вы занимаетесь музыкой и работаете в IT. Не думали оставить что-то из этого?

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

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

Дмитрий играет с певицей Lissa Wassabi на дне рождения музыкального портала UMBAR

— По сути, сегодня программирование просачивается во всевозможные сферы, даже в журналистику, например data journalism. О чем, на ваш взгляд, это говорит?

Если посмотреть, как развивается мир, то да, это неизбежно. Сейчас мы видим диджитализацию. Впервые это слово я услышал как раз в музыке. Сейчас вся музыка, которая выпускается, в первую очередь размещается на диджитал-сервисах: Spotify, Apple Music, Google Play. Уже специально делают такие релизы. При этом музыку выпускают и на пластинках, и на кассетах, но диджитализация берет верх. Думаю, что такое внедрение IT во всевозможные сферы жизни вряд ли плохо. Наоборот, это дает новый опыт, технику, возможности, профессии. Если говорить о музыкантах, если кто-то хочет быть новатором и впереди планеты всей, то зачастую он занимается проектом, который включает в себя что-то связанное с IT. Например, какой-то новый формат звука — не две колонки, а 3D-саунд или звук для VR. Это очень быстрое движение вперед. Появляется концепт. Компании, у которых планы расписаны на несколько лет вперед, даже не успевают подобраться или соответствовать тенденциям, которые появились и уже работают.

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

— Не кажется ли вам, что с появлением IT в музыке сами артисты разленились: мол, какой смысл выкладываться, как прежде, записываться с энного раза, если все можно отредактировать и склеить?

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

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

Дмитрий был диджеем на презентации коллекции дизайнера Lena Ivanova

— Какие у вас планы и цели насчет музыки?

Сейчас Brunettes Shoot Blondes работает над новым материалом. Параллельно мы стараемся активно репетировать, чтобы быть сыгранными и в хорошей форме. Планируем несколько выступлений в Европе в мае. В октябре у нас будет большой сольный концерт в Киеве, мы готовим новые песни и хотим сделать концерт особенным в плане шоу, возможно, привлечем дополнительных музыкантов.

Что касается глобальных планов и продвижения музыки, то менеджер и пиарщик группы работают в направлении выхода на американский рынок. С песнями на английском языке непросто завоевать большую аудиторию в Украине, часто выступать; и вместе с тем видеоработы группы хорошо заходят среднестатистическому слушателю в США. Мы хотели бы поехать в небольшой тур по Америке в обозримом будущем. За несколько лет у меня также скопилось много домашних зарисовок разной стилистики, которые я хотел бы оформить в мини-альбом. Мне катастрофически не хватает времени, чтобы это закончить, но я стремлюсь к тому, чтобы этот материал увидел свет.

Від редакції: ми починаємо серію матеріалів про повернення в Україну. Розповімо про IT-спеціалістів, які поїхали з країни, але з різних причин повернулися. Якщо ви чи ваші знайомі мають такий досвід, напишіть на vlada@dou.ua.

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

Антон з дружиною

Освіта й перший досвід роботи

Антон — типовий український програміст, який опинився в ІТ, закінчивши технічний ВНЗ України. Його альма-матер — Вінницький політехнічний університет, де він здобув освіту за фахом «Мікро- й наноелектроніка». «Якихось знань, пов’язаних з web-програмуванням, я не мав. Перші базові знання здобув від дядька — розробника Delphi Software. Учився в нього із четвертого курсу. Фактично, якби не почав розвиватися в IT, то міг би працювати на фірми, які складають плати, ремонтувати телефони чи щось подібне», — ділиться Антон.

Серед одногрупників йому першому вдалося знайти роботу після закінчення університету. 30 серпня 2014 року Антону вручили диплом, а вже 1 вересня він вийшов на роботу в ІТ-аутсорс-компанію ASPB, яка працювала з WordPress. Материнську компанію розміщено в Нідерландах, звідти й надходили завдання.

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

Потім Антон пішов працювати до WebSoftGroup, яка також розміщувалася у Вінниці. Компанія працювала з країнами СНД. Він зізнається, що одержував менші гроші за свою роботу, але йому подобалося там працювати: «Це були хлопці одного віку й одного професійного рівня зі мною. Це була компашка із сорока осіб, які сиділи у двокімнатній квартирі в одній з багатоповерхівок Вінниці й день і ніч „клепали“ сайти для замовників з колишнього Радянського Союзу. Найважливіше, що я здобув, працюючи там, — це досвід. Я робив різне: верстав сайти, працював як із front end, так і з back end. Мені казали: „Будеш робити SEO-оптимізування“, я відповідав: „Так, звісно“ — і брався за будь-яку роботу».

Перші серйозні проекти

З часом справи на WebSoftGroup пішли донизу. Це був кінець 2014 — початок 2015 років — розпал військового конфлікту на Донбасі. Антон пояснює: компанія втратила левову частку своїх замовлень, долар різко зріс, а зарплатня так і залишилася досить невеликою. Ситуація змусила його шукати іншу компанію. Нею стала Sky IT Group, куди він потрапив за рекомендацією свого товариша. На той час Sky IT Group мала support-team у Вінниці, де працювало п’ять людей. Основний офіс компанії був у Нью-Йорку (США). Фірма відома тим, що збирає дані в клієнтів — Lacoste, Dolce & Gabbana, — обробляє їх і висвітлює на так званих dashboards.

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

«Ще працюючи в Sky IT Group, я одружився, і ми разом із дружиною Анею вирішили пожити якийсь час за кордоном. Ми думали, що там дуже круто, та й досі так думаємо. За місяць після весілля ми поїхали до Вроцлава. Чому туди? Там уже мешкали наші друзі й знайомі, і ми подумали, що так ми легше облаштуємося. До того ж Аня вступила до Вроцлавського університету, і принаймні для неї питання візи й легалізування були на деякий час закриті», — розповідає Антон.

Пошук роботи в Польщі

Антон не відразу знайшов роботу в Польщі. Два місяці йому довелося працювати віддалено на своїй попередній роботі в Україні. «Я надсилав своє резюме через LinkedIn, але згодом зауважив, що найкращий спосіб достукатися до компанії — це заповнити аплікацію в них на сайті, у розділі „Робота“. Після кількох невдалих спроб мені надійшла відповідь від ІВМ і мене запросили на співбесіду».

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

«Я здивувався, коли мені надіслали offer на позицію Control Desk Administration and Maintenance (QS). Мене знову запросили на співбесіду, але вже з office manager. Тут зі мною сталася цікава ситуація: річ у тому, що в Польщі та, мабуть, у всьому світі, пропозицію зарплатні озвучують у брутто, тож, побачивши суму, яку мені запропонували, зрадів. Уже потім дізнався, що від цієї суми потрібно було відняти майже тридцять відсотків податків».

Скільки заробляють в ІВМ, корпоративна культура й труднощі адаптування

ІВМ — американська електронна корпорація, один з найбільших світових виробників усіх видів комп’ютерів і програмного забезпечення. Компанію заснували в США 1888 року. Станом на кінець 2018 року капіталізування компанії становило сто чотирнадцять мільярдів доларів США.

У Вроцлавському ІВМ, крім звичного нам розподілення програмістів на Junior, Middle й Senior, була власна система кваліфікацій — Band, яка складалася з тринадцяти позицій. Наприклад, Антонові відразу, як він погодився на пропозицію компанії, дали четвертий рівень, що дорівнювало дев’ятистам доларів США після оподаткування. З кожним новим рівнем зарплатня збільшується на 10–20%.

«Мій рівень вважався базовим, але я знав, що мої скіли дають мені змогу претендувати на кращий рівень оплати, ніж запропонований. Це також розуміли в ІВМ, але просили дати підтвердження з попередніх місць праці. Я написав своїм колегам зі Sky IT Group, але мені відповіли, що нічим допомогти не можуть. Та сама ситуація була й з іншими колишніми роботодавцями».

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

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

Відділення ІВМ у Вроцлаві спеціалізувалося на global support. Компанія має продукт, який продавали іншим ІТ-компаніям, а у Вроцлаві його підтримували. Антон каже, що це була технічна робота, але вона йому подобалася: «Це велика корпорація, усе нове, курси для працівників, team buildings. Тут я познайомився з ITIL (Information Technology Infrastructure Library), і це мені знадобилося на теперішній роботі».

Польський офіс IBM

Життя й побут у Вроцлаві

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

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

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

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

Труднощі з легалізуванням у Польщі й повернення до України

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

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

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

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

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

«Збігав строк мого перебування в зоні Шенгену. Конкретики від поляків я не бачив і був змушений повернутися до України, де й знайшов вакансію ServiceNow Developer у вінницькому офісі Playtika. Мене запросили на співбесіду, ще коли я був у Вроцлаві. Тоді зі мною сталася цікава історія. Коли повертався додому, дивився відеотранслювання футбольного матчу, де грали іспанська „Севілья“ й ще якась команда. На футболках „Севільї“ я побачив спонсора Playtika й подумав, що це знак :)».

Н̶е̶Дружній Вроцлав

Покинути спокійне життя в далеко не останній за рівнем життя країні Європейського Союзу й повернутися до України — рішення не з простих. Утім, Антон каже, що рано чи пізно це мало статися: «Мені здається, що ми з дружиною чужі в цьому середовищі, і, хоча умови проживання там реально набагато кращі, побутове спілкування та стосунки з людьми не будуть такими, як удома. Наприклад, мої спроби спілкуватися з місцевими польською: вони часто кпили з моєї вимови, було таке відчуття, що тебе сприймають як недорозвинутого. Або ситуація з „картами побиту“: за словами наших колег, які переїхали до 2014 року, такого довгого очікування не було ніколи. Масла у вогонь підливали повідомлення . У таких випадках думаєш не про комфортне життя, а про банальне виживання».

Чому Україна краща, і що Антон робить тепер

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

Нині він ServiceNow Developer у Playtika. Йому подобається, що в компанії працюють натхненні люди, які мотивують одне одного. «На відміну від ІВМ, де ти почувався мурахою у великому колективі, такі маленькі компанії згуртовані й командні, і це створює позитивну атмосферу в колективі».

Ким бачить себе за десять років, Антон не знає, однак упевнений, що його робота буде пов’язаною з ІТ і буде в Україні.

У рубриці DOU Labsми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

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

Ідея

Основна мета, яка привела до створення архітектурного шаблону, — це автоматизування бізнес-процесів і/або публікування API для великих підприємств. Тут слово «великих» приховує за собою значну кількість ІТ-систем, котрі забезпечують роботу цих підприємств.

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

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

Та останнє, але часто вирішальне — сукупна вартість володіння продуктом (total cost of ownership (TCO)).

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

Запитайте себе: чому цей та інші процеси на підприємствах не автоматизовано? Великі підприємства — це купа маленьких систем, а іноді Excel-файлів, які зінтегровано між собою через людей і папірці. Перше, що пропонують для автоматизування й інтегрування, — поставити та налаштувати систему планування ресурсів підприємства (ERP), яка має поглинути всі системи. Для підприємства це значна зміна процесів та ІТ-архітектури. Та це все виходить дуже дорого.

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

Команда, яка працювала над проектом

Вирішення

Отже, вирішення було описано ще в межах сервісно-орієнтованої архітектури (SOA): «Архітектурний шаблон програмного забезпечення, модульний підхід до розробки програмного забезпечення, який ґрунтується на використанні розподілених, слабко пов’язаних замінних компонентів, які оснащено стандартизованими інтерфейсами для взаємодії за стандартизованими протоколами».

Доповнено основними ідеями мікросервісної архітектури:

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

І, звичайно, розвиток хмарних вирішень вимагає від нас гнучкості в реалізації (гнучкості в архітектурі?).

Критика

Головним пунктом критики сервісно-орієнтованої й мікросервісноїархітектур є: «витрати (latency) в разі передання мережею та перетворення форматів».

Ми апріорі перебуваємо в ситуації, коли маємо багато систем, і всі дані й бізнесові функції рознесено, і вони доступні переважно в мережі. Тому нам не уникнути ні передавання даних мережею, ні форматів. І ця ситуація ідеальна для створення сервісно-орієнтованої чи мікросервісної архітектури. Щодо форматів, то JSON/Swagger (OpenAPI) витісняє SOAP/WSDL через їхню надлишковість і складність. Чи не ефективніше використовувати рідні протоколи без посередників?

В одному з проектів, бізнесовий успіх якого був сумнівний, потрібно було зберегти фотографії клієнта, проте сховища для таких документів не було. Знайшлося файлове сховище, доступне за протоколом NFS.Зробили REST-сервіс, який реагує на GET/PUT/DELETE-запити й здійснює відповідні операції з файлами через NFS. Бізнесова ідея виявилася успішною, проте сервіс роботи з файлами став «тісним місцем» у процесі. Але після того як ми позбулися NFS у ланцюжку викликів, перемістивши сервіс на машину з файловим сховищем, сервіс запрацював у десятки разів швидше, а максимальна кількість одночасних запитів збільшилася в тисячі разів.

Реалізація

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

Компоненти платформи

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

У колонці «імплементування» розміщено одне з найкращих, на наш погляд, вирішень із відкритим кодом (open-source). Будь-який компонент можна замінити іншим вирішенням, яке, можливо, є в клієнта. Для реалізації шаблону ми використовували перевірені open-source вирішення, щоб мінімізувати первісну вартість проекту. Оскільки нашою метою є будь-яка хмарна платформа, то для контейнерування ми вибираємо docker, а для оркестрування контейнерів kubernetesяк лідерів у своїй сфері.

Розгортання й запуск

Без можливості запуску представлена вище схема залишається лише схемою. Тому публікуємо демонстраційни коддля розгортання інфраструктури й деякої кількості компонентів. На цей час опубліковано конфігурації з підтримуванням Amazon Web Services (AWS). Проте з мінімальними змінами таку саму або схожу інфраструктуру ви зможете підняти в іншій хмарі.

Infrastructure as a Code — це основний підхід для справді швидкого впровадження проекту й розвитку сервісно-орієнтованої чи мікросервісної архітектур. На цей час ми обрали Terraform.

Terraform — уможливлює представити хмарну інфраструктуру як мінімалістський код з підтримуванням основних хмарних провайдерів. Це дає змогу розгортати потрібну інфраструктуру з мінімальними витратами в будь-яких хмарах, зокрема й приватних (on-premises), що ґрунтуються, наприклад, на OpenStack.

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

Що дає ця платформа

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

Як же бути з наведеним вище для прикладу NFS-протоколом? Адже такі ситуації обов’язково виникнуть, якщо ми не вносимо змін до поточної інфраструктури клієнта.

Підприємства не хочуть уносити великих змін до інфраструктури. Часто це пов’язано з великими витратами або теоретичними втратами. Здається, найкраща стратегія тут — Least effort & Maximum effect. Спочатку інтеграційну платформу можна позиціювати як надбудову над поточною архітектурою — фасад, який приховує реальні системи й протоколи всередині підприємства. Як тільки ми під’єднуємо до фасаду нові системи, можемо моніторити швидкість роботи й навантаження на сервіси, а потім оцінювати вартість і планувати внесення змін до конкретних сервісів та, можливо, інфраструктури підприємства.

Скільки коштує сама платформа

Ми принципово використовуємо продукти з відкритим кодом з ліцензією Apache 2.0 або схожою на неї. Саме це дає змогу запустити проект із мінімальними витратами. По суті, клієнт платить тільки за хостинг потрібних компонентів у хмарі.

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

Як оцінити обсяг робіт щодо впровадження сервісної архітектури

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

Однак конкретні deliverables можна оцінити. Наприклад:

• Первинний аналіз поточної архітектури й дизайн нової: десять-п’ятнадцять днів. Охоплює схему й компоненти високорівневої архітектури, мета — унесення змін до архітектури та кількох проміжних варіантів.
• Складання базових правил для розвитку інтеграційної архітектури: п’ять-десять днів.
• Розгортання платформи для інтеграції сервісів. За наявності хмарної передплати й узгодженої конфігурації розгортання забирає кілька годин. Імовірні доробляння, конфігурація, налаштування VPN... — це окремо.
• Під’єднання кожної нової системи: від двох до п’ятнадцяти днів. П’ятнадцять днів — якщо щось нестандартне, для чого немає конекторів.
• Публікування проксі-сервісу: від одного до трьох днів. Охоплює API-дизайн і мінімум інтеграційної логіки. У разі усталеного процесу — найчастіше один день і менше.
• Імплементування комплексного сервісу: від трьох до п’яти днів. Працюють із кількома джерелами даних.
• Імплементування нового сервісу: від трьох до п’яти днів. Сюди потрапляють сервіси, для яких ще не існує бек-енд системи, але є всі ресурси для імплементування.
• Розробка процесного сервісу (бізнесового процесу): Десять днів — тридцять кроків процесу.
• Розробка CI/CD-процедур для кожного виду сервісу: від трьох до п’яти днів.

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

Скільки сервісів потрібно реалізувати

Як вибрати правильну грануляцію сервісу? Які вхідні й вихідні параметри мають бути в сервісі? Створювати два методи create + update або один register? Наскільки «мікро» мають бути сервіси?..

80% успіху розробки сервісу залежить саме від правильного API. Успіх я б вимірював тривалістю існування API без унесення змін.

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

Чого не варто робити в сервісах

Найбільше зло — транзакційність. Не поєднуйте все в одну велику транзакцію.

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

Найчастіше «вузьким місцем» є back-end системи підприємства, проте не слід одразу пропонувати збільшувати їхню потужність, адже завдання можна розв’язати на рівні middleware за допомогою систем автоматизування процесів (Business Process Server) або черг повідомлень.

З чого починати, коли підприємство перебуває в процесі змін

Це типова ситуація. Без змін у бізнесі змінювати архітектуру ніхто не буде. Отже, маємо безліч невідомих: обсяги робіт, системи й спосіб взаємодії з ними (особливо з тими, які написано десятки років тому), архітектура/інфраструктура в клієнта перебувають у перехідному стані в межах свого життєвого циклу...

Потрібна точка опори. Опиратися на системи недоцільно. Навіть «прибиті цвяхами» до бізнесу системи раптово стають застарілими. У моїй практиці був проект упровадження сервісної архітектури й автоматизування бізнес-процесів (чотири роки), у межах якого основну бізнесову систему (core system) було замінено двічі.

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

• Основний протокол для взаємодії з усіма системами в межах бізнесових функцій. Сьогодні найчастіше вибирають JSON + HTTPS (XML, SOAP та ін.).
• Формат опису/документування сервісів (Swagger/OpenAPI (RAML, WSDL ін.)).
• Мови програмування й технології, які прийнятні для клієнта в межах інтегрування. Імовірно, клієнт має свою команду для розвитку й супроводження ІТ-систем, яка впливає на рішення.
• Стандарти безпеки. Захищені протоколи передавання даних TLS (SSL) і протоколи автентифікування/авторизування.
• Правила публікування й виклику сервісів: правила йменування, версіювання, виклику, валідування, виведення з експлуатації тощо.

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

Що ми одержимо в ідеальних умовах

API Manager виступає централізованою точкою для документування, створення нових сервісів і гарантування їхньої безпеки. Створення прототипу нового сервісу може зініціювати й бізнесовий аналітик, маючи під рукою браузер. Оскільки всі бізнесові функції представлено сервісами, створення бізнесового процесу за допомогою Business Process Server стає питанням конфігурації, яку також може виконати бізнесовий аналітик. Усі процеси, як і сервіси, описано, завтоматизовано й легко змінити. За допомогою систем моніторингу просто знаходити проблемні сервіси й планувати зміни.

Підсумки

Навіщо це все? Адже якщо взяти, наприклад, API Manager, то практично у всіх хмарних провайдерів є свій сервіс: Apigee API Platform from Google, Azure API Management from Microsoft та API Gateway from Amazon. На жаль, цей сервіс не має загальних стандартів розробки й конфігурації. А якщо потрібно зробити Cloud-agnostic-рішення або розгорнути в приватному клауді чи на локальних серверах, то варіант, про який ішлося вище, конкурентний.

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

Меня зовут Арт Тоноян, я Senior DBA в Provectus, и в конце марта я сдал свою первую AWS сертификацию Cloud Practitioner. Хотел бы помочь сделать первые шаги в получении сертификации Amazon другим.

Зачем нужна AWS сертификация

Экзамен Cloud Practitioner подходит разработчикам, DevOps, NOC и QA специалистам. Специалист с сертификацией уже не будет нуждаться в подтверждении своих знаний. Если есть сертификат, он получает возможность работать на проектах высокого уровня.

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

Я лично захотел сдать экзамен потому, что было интересно:

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

Как готовиться

Если вы уже знаете принципы безопасности и архитектуры AWS, представляете особенности развертывания и работы в облаке, подготовка к сертификации будет довольно простой. У меня общая подготовка, ввиду опыта, заняла дня три. Я выделил три шага на пути к сертификату.

Шаг 1. Зарегистрироваться на aws.training

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

Шаг 2. Пройти учебный курс AWS

Если вы только вошли в мир облачных сервисов, потребуются базовые знания про основные сервисы Амазона (S3, EBS, EC2, SQS), которые можно легко получить на курсе от AWS. Обучение позволяет расширить технические навыки и изучить рекомендации по работе с AWS. Неплохо освежить знания про устройство сети в Linux OS.

На досуге почитайте ресурсы AWS Library, AWS Cloud Practitioner Essentials (Second Edition). Они очень помогут и дадут полезные знания не только для AWS, а в общем о таком понятии, как облачные технологии.

Шаг 3. Изучить стек технологий

Наверное, один из самых важных шагов — это изучение стека технологий, который предоставляет AWS. При изучении с нуля, если уделите этому час-два в день, то примерно уже через 3-4недели на должном уровне будете знать, что такое S3 и чем он отличается от RDS. Просмотрите понятия Storage, Compute, Que. Их знание 100% проверяется на экзамене. После этого — определите, что еще необходимо изучить.

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

Изучите технические описания, написанные специалистами AWS, независимыми аналитиками и партнерами AWS. Особое внимание обратите на такие:

• Обзор Amazon Web Services.
• Разработка облачных архитектур: рекомендации AWS.
• Принципы ценообразования в AWS.
• Сравнение программ поддержки AWS Support.

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

Как сдать экзамен

Выбрать время и место сдачи экзамена в ближайшем центре сертификации можно на странице aws.training. Я выбрал Киев.

• Время.У вас будет 90 минут (до экзамена в личном кабинете можно еще вручную добавить 30 минут к этому и всем предстоящим экзаменам).
  
• Формат.Тестовые вопросы, допускающие несколько (!) правильных ответов. Будьте внимательны.
• Результат.Вы сразу узнаете прошли его или нет. Нужно набрать от 700 баллов. Диапазон: минимум 100, максимум — 1000.

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

Есть еще фановый способ в виде квиза проверить свой уровень знаний экосистемы AWS. Мой коллега Ильнур Гарифуллин, ML Engineer, создал телеграм-бота A Guru of the Week, который собирает вопросы с форума A Cloud Guru и использует их, чтобы проверить знания пользователя. Удостовериться в правильности ответа можно по ссылке Reference, где есть детальные описания, почему одни варианты действий применимы в заданных сценариях, а другие — нет. Вместе с правильным ответом, подтвержденным командой A Cloud Guru, можно найти множество альтернативных мнений участников форума. Вопросы в чат-боте обновляются еженедельно и соответствуют экзаменационному уровню.

Выводы

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

Если намерены сдать AWS сертификацию уровня Cloud Practitioner или Associate/Professional и нужна консультация, напишите на hello@provectus.com. Ребята смогут быстро ввести в курс и помочь подготовиться. Компания помогает с сертификацией в рамках развития AWS User Group Ukraine.

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

Разработка ПО — сложный процесс, результатом которого является работающий «в миру» продукт/сервис. Давайте познакомимся с подходом, позволяющим упростить жизненный цикл разработки.

Реализация

Начиная с версии 17.05, в докере появились многоступенчатые билды. Многоступенчатые сборки полезны для всех, кто пытается оптимизировать Docker-файлы и образы, сохраняя их легкими для чтения и обслуживания. До появления этой фичи применяли подход под названием «Builder Pattern». Подход «Builder Pattern» заключается в создании двух Docker-файлов и sh-скрипта:

• Dockerfile.build — собирает приложение (вытягивает зависимости, компилирует и т. д.).
• Dockerfile — запускает приложение.
• build.sh — копирует артифакт, полученный из Dockerfile.build, в контейнер, собирающийся из Dockerfile.

Пример «Builder Pattern». Исходный код примера можно получить на GitHub.

Dockerfile.build

FROM golang:1.12.4-stretch
# Change worck directory
WORKDIR /go/src/github.com/zhooravell/docker-multi-stage-builds/builder-pattern
# Copy go code & dep files to worck directory
COPY main.go   Gopkg.toml Gopkg.toml ./
# Install dep, packages and build application
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh \&& dep version \&& dep ensure \&& CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

Dockerfile

FROM alpine:latest
# Add ssl support
RUN apk --no-cache add ca-certificates

WORKDIR /root/

COPY app .

CMD ["./app"]

build.sh

#!/usr/bin/env bash
echo Building docker-multi-stage-builds/builder-pattern:build
# Билдим образ с приложение (зависимости, компиляция)
docker build -t docker-multi-stage-builds/builder-pattern:build . -f Dockerfile.build
# Создаем контейнер с коротким именем extract
docker container create --name extract docker-multi-stage-builds/builder-pattern:build
# Копируем артефакт из контейнера на хост-машину
docker container cp extract:/go/src/github.com/zhooravell/docker-multi-stage-builds/builder-pattern/app ./app
# Удаляем контейнер
docker container rm -f extract

echo Building docker-multi-stage-builds/builder-pattern:latest
# Собираем образ с скомпилированным приложением
docker build --no-cache -t docker-multi-stage-builds/builder-pattern:latest .
# Удаляем артефакт
rm ./app

Запустим контейнер и убедимся, что у все работает, как ожидалось:

$ docker run -p 8080:8080 docker-multi-stage-builds/builder-pattern

В результате получается очень маленький образ, с минимальным набором пакетов/зависимостей — только то, что нужно для запуска приложения. Production-образ не содержит инструментов сборки, компиляции, систем управления версиями.

$ docker images
REPOSITORY                                 TAG     IMAGE ID      CREATED         SIZE
docker-multi-stage-builds/builder-pattern  latest  4be00adf69b0  16 seconds ago  13.8MB
docker-multi-stage-builds/builder-pattern  build   3f0177d07175  20 seconds ago  819MB

Что же тогда multi-stage build? И зачем он нужен?

Многоступенчатый билд позволяет достичь того же результата, но без bash-скриптов, без нескольких Docker-файлов. Это достигается за счет использования нескольких инструкций FROM. В результате предыдущий пример будет выглядеть так:

FROM golang:1.12.4-stretch as builder
# Change worck directory
WORKDIR /go/src/github.com/zhooravell/docker-multi-stage-builds/go-multi-stage-build
# Copy go code & dep files to worck directory
COPY main.go Gopkg.toml Gopkg.toml ./
# Install dep, packages and build application
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh \&& dep version \&& dep ensure \&& CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
# Add ssl support
RUN apk --no-cache add ca-certificates

WORKDIR /root/
# Copy just the built artifact from the previous stage into this new stage
# The Go SDK and any intermediate artifacts are left behind, and not saved in the final image.
COPY --from=builder /go/src/github.com/zhooravell/docker-multi-stage-builds/go-multi-stage-build/app ./

EXPOSE 8080

CMD ["./app"]

Вся «хитрость» заключается в конструкции COPY —from=builder. Она копирует артефакт с шага с алиасом builder (FROM golang:1.12.4-stretch as builder). Соберем наш контейнер:

$ docker build --no-cache -t docker-multi-stage-builds/go:latest .

Давайте рассмотрим еще пример использования multi-stage builds.

Angular и Docker multi-stage builds

На основе docker multi-stage build можно реализовать полный жизненный цикл angular-приложения:

1. Разработка (npm start).
2. Сборка (ng build —prod).
3. Деплой (nginx).

Исходный код примера можно получить на GitHub. Docker-файл будет содержать 3 шага (FROM) сборки и выглядеть будет так:

### STAGE 1: Develop ###
FROM node:11.14.0-alpine as develop

USER node

RUN mkdir /home/node/.npm-global && mkdir /home/node/logs

ENV PATH=/home/node/.npm-global/bin:$PATH
ENV NPM_CONFIG_PREFIX=/home/node/.npm-global
ENV HOME=/home/node

WORKDIR $HOME/app

RUN npm i -g npm

RUN npm install -g @angular/cli && npm cache clean --force

EXPOSE 4200

CMD [ "node" ]

### STAGE 2: Build ###
FROM develop as builder

USER root

COPY app .

RUN npm install && ng build --prod --output-path=dist

### STAGE 3: Setup ###
FROM nginx:1.15.12-alpine
# Remove default nginx website
RUN rm -rf /usr/share/nginx/html/*
# From 'builder' stage copy over the artifacts in dist folder to default nginx public folder
COPY --from=builder /home/node/app/dist /usr/share/nginx/html

Первый шаг (develop) содержит в себе установку пакета Angular CLI и будет использоваться для разработки. Второй шаг (builder) предназначен для сборки приложения: RUN npm install && ng build —prod —output-path=dist. Третий шаг предназначен для копирования артефакта (сбилдженого приложения) в контейнер с HTTP-сервер.

Для этапа разработки будет использоваться docker-compose. Начиная с версии 3.4, docker-compose поддерживает build.target, что позволяет остановить сборку контейнера на конкретном шаге (в нашем случае этот шаг — develop).

version: "3.4"

services:
  angular:
      build:
        context: .
        target: develop # use stage develop
      ports:
        - 4200:4200
      volumes:
        - ./app:/home/node/app:rw
      command:
          - /bin/sh
          - -c
          - |
              cd /home/node/app && npm install && npm start

Выполнив команду docker-compose up, мы получим полноценно работающее окружение для разработки Angular-приложения (компиляция TypeScript, релоад браузера и т. д.).

Чтобы получить сборку приложения, готовую к деплою, нужно выполнить команду:

$ docker build --no-cache -t docker-multi-stage-builds/go:latest .

Запуск контейнера с HTTP-сервером и Angular-приложением выполняется так:

$ docker run -p 8080:80 docker-multi-stage-builds/angular:latest

Выводы

Docker multi-stage build позволяет оптимизировать сборку образов. Сделать контейнеры более «легкими», а также унифицировать процесс разработки, сборки и деплоя.

Надеюсь, эта информация была вам полезна.

В выпуске: .NET Internals Cookbook, шпаргалки для разных инструментов, storing UTC, the secret to happy code.

.NET

Building a Reverse Proxy in .NET Core

Announcing .NET Core 3 Preview 4

.NET Internals Cookbook

Docker

Dockertest
Интересная идея создания контейнеров во время выполнения тестов. Не находил такого для .NET, впрочем, особо и не искал пока.
Думаю, что-то похожее можно сделать используя SimpleExec.

Integrating docker-compose steps with Octopus Deploy

MongoDB Enterprise Operator for Kubernetes and OpenShift
Только я так и не понял, можно ли его использовать с MongoDB Community Edition. Поделитесь впечатлениями, если кто-то пользовался.

.NET Core Container Images now Published to Microsoft Container Registry

Docker Tagging: Best practices for tagging and versioning docker images

Разное

You probably don’t need a single-page application

How to Negotiate Your Job Offer

Rico’s cheatsheets
Шпаргалки для разных инструментов, в том числе bash, vim.

Storing UTC is not a silver bullet
Довольно интересная статья и размышления о том, как правильно хранить время.

Consistent Hashing Simplified

Developer Survey Results 2019

.NET fwdays’19

Недавно прошла конференция .NET fwdays. В целом, было довольно интересно, особенно хочу отметить несколько докладов, которые мне были особенно актуальны:

Building Service Mesh with .NET Core

Life, Liberty and the Pursuit of APIness : The Secret to Happy Code

Дилан здорово зажигал на after-party, особенно актуально (запись с выступления на DotNext, в живую сильно лучше звучит :)):

Вот будет лето, все поедут на дачу.

Я не могу, я в продакшен фигачу.

← Предыдущий выпуск: .NET Дайджест #26

У випуску: Mozilla працює над розширенням наукового стеку в браузері, як працюють модулі, трішки WebAssembly, Python метакласи.

Новини

Roberto Rosarioзакриває 33 Python/Django репозиторії.

Python is shipping on the new TI-83 Premium CE calculators in France

Нові релізи

Django 2.2 released
Спрощений синтаксис роутінгу, адмінка з підтримкою мобільних девайсів, Window expression.

pygame 1.9.5

Python 3.8.0a3 доступний для тестування. Найбільш вагомою зміною нової версії вважається PEP-0572 Assignment Expressions.

Цікаві бібліотеки

Fastapiфреймворк для побудови web api.

Pyckitupігровий рушій, що працює з WebAssembly.

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

Python-ext-wasmбібліотека для запуску WebAssembly бінарників.

AdaptiveТулза для семплінгу математичних функцій.

Pyrightтайп чекер від Microsoft для Python.

Animoji : Animate apple animoji на коліні.

З Amie-fernви можете транслювати jupiter експерименти в Python скрипти.

Iodideнауковий Python-стек в браузері від Mozilla.

Qutebrowserбраузер на Python.

PEP’s

PEP 570 — Python Positional-Only Parameters

PEP 584 — Add + and — operators to the built-in dict class

Статті/ресурси

10 ресурсів по Python

Застосування метакласіву Django ORM

Як працюють *args та *kwargs

Вступ в модулі

Як працює pip install

Квітневі Python апдейтиу VS Code

36 Amazing Python Open Source Projects (v.2019)

Mozilla details Pyodide, which brings Python to browsers

Computer Vision for Vaporwave Art

Чому оператори корисні на думку Гвідо

Трекінг зіниць на OpenCV

Відео

How To Create A Telegram Bot With Python

Python Regular Expressions (15+ videos, beginner to advanced features)

Dataclasses in Python

← Попередній випуск: Python дайджест #19

[Про автора: Альона Черненко-Диба — QA Manager у Astound Commerce з 11-річнимдосвідом в ІТ — від джуніор тестувальника до функціонального менеджера команди. Її кредо як менеджера: «Успіх вашої команди є досягненням команди, невдача команди є результатом вашого неефективного менеджменту»]

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

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

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

Лідер з відкритими очима

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

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

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

Як сказала Твайла Тарп у книзі «Звичка до творчості»: «Недосвідченість дарує дитячу безстрашність на противагу уявній мудрості, яку накладає на нас вік. „Мудрість“ говорить, що є недосяжні цілі, марна трата часу, шлях до невдач. У найбільш чистому вигляді недосвідченість стирає відчуття страху. Ви не знаєте, що можливо, а що ні, і тому для вас можливо все». Лідеру важливо дивитися на людей і на їх вміння, не оцінюючи їх на базі емоційної реакції.

Це про ясність сприйняття завдяки чесності з собою.

Helicopter view for a leader

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

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

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

Це про рішучість в особистісних змінах задля об’єктивності.

Команда як екзоскелет

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

Лідер, орієнтований на особистісний і професійний розвиток, має і повинен дозволити усім членам команди відрізнятись, мати свою думку. Скажу відверто, мені треба було 3 роки практичного досвіду управління людьми, щоб зрозуміти, що наша сила в тому, що ми — різні. Адже саме такий підхід допомагає на початку проекту згладити всі гострі кути, а стадії storming-norming пройти швидше і менш ресурсозатратно в плані емоцій та енергії. Прийняття себе і довколишніх через відкрите спілкування та регулярний зворотній зв’язок — рецепт успіху побудови згуртованої команди. Зміщуючи акценти з питання «для чого ця людина мені?»на «для чого ця людина команді, компанії, бізнесу?», відбувається перехід з особистісного на стратегічний або ж лідерський рівень сприйняття.

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

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

Це про відкритість до можливостей і розвиток.

Надійність конекторів, зв’язків

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

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

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

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

Це про якість, надійність і гнучкість.

Висновки

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

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

Лідер є частиною команди, є з командою. Саме тому лідер формує ефективну команду, де кожен учасник доповнює одне одного, працюючи пліч-о-пліч, збільшуючи командну ефективність.

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

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

Мудрий лідер вміє довіряти. У кожного лідера свій шлях від «правильно» до «ефективно». Перевірте самі :)

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

Проблема

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

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

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

Выбор метода

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

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

1. Документ получился большой и требовал немало времени на ознакомление.
2. Большие документы никто не читает.

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

I. Адресность — общайся с тем, кто действительно может решить проблему.

II. Своевременность — общайся тогда, когда можно повлиять на ситуацию.

III. Аргументированность фактами — во время общения опирайся исключительно на факты.

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

Приведу простой пример работы этих принципов. На проекте прилег CI. Работа остановилась. Коллега разражается тирадой о предпочтениях в личной жизни DevOps-части команды.

Является ли такое общение адресным? — Нет, он не с DevOps-ами общается.

Является ли своевременным? — Нет, CI-тоуже лежит, и время мы только теряем.

Аргументированно ли такое общение фактами? — Да, факт на лицо.

Соблюден ли принцип «Намерение решить проблему, а не человека»? — Ну нет.

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

Создание тренинга

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

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

Вот наш чеклист от идеи к результату:

0. Утвердить бюджет с руководством компании.

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

В нашем случае тренинг занимал полтора часа и компенсировался контракторам по обычному рейту.

1. Создать презентацию.

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

Первый — зачем этот тренинг нужен компании и проекту понятно, а вот нафига он разработчику? Во время тренинга, для того, чтобы объяснить, я делаю вот что:

• Уточняю у группы, какие скилы нужны для работы. Это Hard Skills, Soft Skills, английский.
• Уточняю, понимает ли группа отличие Hard Skills от Soft Skills.
• Говорю о том, что тренинг нацелен на повышение Soft Skills.
• Потом показываю две картинки и спрашиваю, кого бы вы скорее взяли на работу?

Специалиста 1

Специалиста 2

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

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

Повторю принципы еще раз:

I. Адресность.
II. Своевременность.
III. Аргументированность фактами.
IV. Намерение решить проблему, а не человека.

Лучшие практики разбираем для следующих каналов:

1. Комментарии в таск-трекере.
2. Комментарии в системе контроля версий.
3. Общение в чатах.
4. Конференционные звонки.

Приведу пример разбора лучших практик для канала конференционные звонки:

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

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

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

Пример кейса:

2. Провести презентацию для пилотной группы.
3. Поправить презентацию.

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

4. Сделать презентацию о презентации ПМ’ам на проекте.

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

5. Разбить команду на группы 6-8 человек.

В нашем случае получилось 9 групп.

6. Провести презентацию всей команде в короткий срок.

Если презентацию могут проводить 3-4 ПМ’а,то можно и за неделю управиться.

7. Собрать обратную связь.

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

8. Profit.

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

Еще пару выводов

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

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

Надеюсь было полезно. Если что-то нужно осветить подробнее — пишите в комментарии или стучитесь в Facebook.

Успехов!

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

Марина Поповиченко, UI/UX Designer

15 лет опыта в дизайне

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

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

Английский язык.Знание английского на уровне Intermediate, а ещё лучше — Upper-Intermediate позволит быстрее найти работу и общаться с заказчиком напрямую. Также статьи по дизайну и новым методикам в UI/UX выходят прежде всего на английском языке.

Дизайн-тренировка.Daily UI — просто находка для развития навыков UI-дизайна. Каждый день вам присылают новое задание, которое необходимо выполнить в течение этого дня. Уже через 10 рабочих дней в портфолио будет 10 работ. Всего 100 заданий. В таком темпе вы получите хороший рост hard-skills :)

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

Нетворкинг. Любое мероприятие — это знакомства. Очень советую посещать митапы (Dribbble, Silicon drinkabout, Product tank) и конференции именно для нетворкинга. Быть может, что вы окажетесь единственным знакомым дизайнером человека с митапа и вам предложат сотрудничество.

Статьи и курсы:

• medium.com/topic/design — хорошая подборка дизайн-статей;
• jvetrau.com — дизайн-директор Mail.ru собирает интересные статьи, есть Telegram-канал;
• sobakapav.ru/publications — инсайты и бесплатные онлайн-книги по UX;
• Tilda.education — статьи и курсы;
• Product Design — бесплатный курс на Udacity.
• «Не заставляйте меня думать», Стива Круга — книга о том, как сделать интерфейс удобным.

Олег Мороз, Product Owner

7 лет опыта в дизайне

UX/UI Designer — это человек, обладающий навыком проектирования и создания интерфейсов, который может комплексно решать задачи, охватывающие множество областей. Чем больше спектр и охват задействованных зон, тем интереснее и неординарнее задача у специалиста.

Звучит интересно? А в жизни, это еще «взрывоопаснее». Эта специализация поможет вам вырасти в других направлениях. Я встречал многих дизайнеров, которые уходили из UI-части и становились экспертами в архитектуре и решениях сложных задач, генерируемых клиентом. Некоторые отходили от UX-части и занимали должности UI Expert/Brand manager. Также не стоит забывать о специалистах, которые развили в себе те навыки, о которых не могли и мечтать в самом начале своей карьеры, и стали прекрасными продуктовыми/проектными менеджерами.

Если вы уже стали на этот путь, нужно понимать главные аспекты IT-индустрии:

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

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

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

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

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

Лина Кононенко, UX Team Lead

опыт 7 лет

В самом начале карьеры профессиональное развитие UX/UI дизайнера, на мой взгляд, прямо зависит от двух аспектов: количество реальных проектов, в которых он принял участие, и количество направлений, которые он изучает.

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

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

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

• Технические навыки.С этого проще всего начинать: изучайте инструменты, основные методологии и техники. Изучайте варианты всех возможных deliverables работы дизайнера, но в начале фокусируйтесь на самых необходимых в вашей работе.
• Дизайн-процесс — это то, что превращает хаос в упорядоченность и итеративность. Изучайте возможности построения дизайн-процесса в разных условиях и контекстах, после чего углубляйтесь в каждый из его этапов. Особенное внимание здесь обратите на возможности оптимизации как лично вашей работы, так и всех специалистов, с которыми вы будете взаимодействовать: продакт-менеджеры, разработчики, тестировщики.
• Принятие UX-решений — это касается как знаний основных правил, паттернов и догм, на которых строятся интерфейсы для различных задач, так и возможности генерировать новые гипотезы и предположения того, как тот или иной функционал может работать для пользователей. Это одно из самых трудных направлений для улучшений и может занимать годы, поскольку один из самых главных способов его улучшить — получать опыт.
• Работа с данными.Если мы говорим конкретно про UX-дизайн, еще одна большая часть работы происходит с количественными и качественными показателями. Изучайте, как работает аналитика, какие типы данных существуют, какие метрики используются продуктами для измерения своих успехов, а какие метрики можете использовать вы, чтобы валидировать или измерять свои дизайн-решения.
• Пользовательские исследования — один из основополагающих этапов в дизайн-процессе. Именно правильно построенные исследования наиболее глубоко раскрывают информацию об их поведении, мотивации и нуждах.
• Софт скиллы.Для работы UX/UI-дизайнера софт скиллы критично необходимы. Надо понимать, что большая часть работы дизайнера как раз и заключается в необходимости коммуницировать — с бизнесом, пользователями, командой. Учитесь презентовать свои решения, находить компромиссы и поднимать новые инициативы.

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

Фундаментальная UX-литература:

• Don Norman «Design of everyday things»;
• Steve Krug «Don’t make me think»;
• Alan Cooper «About Face»;
• Susan Weinschenk «100 Things Every Designer Needs to Know About People»;
• Jeff Gothelf «Lean UX».

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

• David Travis «Think like a UX Researcher»;
• Brad Nunnally «UX Research»;
• Tomer Sharon «Validating Product Ideas».

Продуктовая литература:

• Nir Eyal «Hooked»;
• Jason Fried «Rework»;
• Peter Thiel «Zero to One».

Софт скиллы и работа в команде:

• Tom Greever «Articulating Design Decisions»;
• Tom Kelley «Creative confidence».

Полезные ресурсы:

• Nielsen Norman Group Articles;
• UXPin E-books;
• UX Collective;
• Smashing Magazine;
• Intercom Blog.

Максим Поливода, UI Designer

5 лет опыта

Ты кто вообще такой?

Для начала задайте себе следующие вопросы:

— Почему я хочу быть или стать дизайнером?

— Какая моя истинная мотивация?

— Почему я делаю то, что делаю?

— Кем я себя вижу в этой дисциплине через год, пять лет?

— Какую ценность я приношу себе, окружающим меня людям, обществу и миру своей работой?

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

Существует отличная техника «5 почему», которая используется во многих сферах и профессиях для изучения причинно-следственных связей, лежащих в основе проблемы. Также рекомендую посмотреть популярныйTEDx Talk от Simon Sinek. Этот подход поможет внести ясность в вашу профессиональную деятельность и жизнь.

Век живи, век учись

Для того, чтобы постоянно оставаться «в рынке», нужно следить за последними трендами в дизайне. При этом обладать фундаментальной классической базой по направлению дизайна, которое вы выбрали. Чтобы начать строить качественный фундамент, обратите внимание на онлайн-курсы по дизайну от таких платформ, как Coursera, Udemy, edX.

Мне нравятся следующие специализации на платформе Coursera: «Графический дизайн», «Проектирование взаимодействия».
Ресурс Udemy будет более полезным для изучения инструментария, например, как пользоватся Sketch, Principle, AI и др.

Отличными основополагающими ресурсами с качественной информацией о дизайне, различных стандартах, usability, user interaction и др. являются:

• nngroup.com;
• design-system.service.gov.uk;
• developer.apple.com;
• design.google;
• material.io/design;
• medium.com.

Читайте книги, блоги, посты популярных дизайнеров, которые создавали революционные продукты и решения: Don Norman, Steve Krug, Aaron Draplin, Alan Cooper, Jony Ive и т. д. Издано огромное количество хороших книг вышеописанных авторов, рекомендую забить в поиск и обратить внимания на те, у которых самый высокий рейтинг и лучшие отзывы на Amazon.

Кроме этого, следите за дизайн-системами и фундаментальными принципами крупнейших технологических компаний — Google, Apple, IBM, SAP:

• carbondesignsystem.com;
• ibm.com/design/language;
• design.sap.com;
• developer.apple.com;
• material.io/design.

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

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

Следите за общими визуальными трендами на Dribbble, Awwwards.

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

Сражение за портфолио

Когда вы уже готовы выходить в поле и начинать бой за кеш и портфолио, можно начинать с фриланса на Upwork, 99designs, Fiverr. Если хотите начинать строить карьеру в рамках компаний, ищите стажировки и дизайн-школы, которые ведут крупные компании в вашем городе.

Коммуникация и умение продавать — must have навык

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

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

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

Wrap it up

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

Вдохновляйтесь, создавайте, творите и максимально реализуйте свой потенциал!

От редакции: в рубрике DOU Booksучастники сообщества рассказывают о пяти любимых книгах — тех, которые меняют мировоззрение и могут быть полезны читателям-коллегам.

[Об авторе: Алексей Орап — CEO и основатель компании YouScan, SaaS-системы мониторинга социальных медиа. C 2008 по 2009 работал директором по развитию Яндекс.Украина, ранее занимался продажами и техническим консалтингом в компаниях Nortel, Alcatel-Lucent. Автор блога про SaaS-бизнес — SaaSDojo.com]

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

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

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

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

Garry Kasparov «How Life Imitates Chess: Making the Right Moves, from the Board to the Boardroom»

В русском переводе — Гарри Каспаров «Шахматы как модель жизни»

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

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

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

Patric Lencioni «The Five Dysfunctions of a Team: A Leadership Fable»

В русском переводе — Патрик Ленсиони «Пять пороков команды»

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

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

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

Jared Diamond «Collapse: How Societies Choose to Fail or Succeed»

В русском переводе — Джаред Даймонд «Коллапс. Почему одни общества приходят к процветанию, а другие — к гибели»

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

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

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

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

Naomi Klein «This Changes Everything: Capitalism vs. The Climate»

В українському перекладі — Наомі Кляйн «Змінюється все. Капіталізм проти клімату»

Эта книга очень провокационна — именно в этом её главная ценность. В этом бестселлере по версии New York Times Наоми Кляйн рассуждает о том, почему мы до сих пор видим так мало реального прогресса в вопросах защиты окружающей среды. Она критикует природозащитные организации, приводя факты банального подкупа многих из них корпорациями, которые вносят наибольший вклад в её загрязнение; рассказывает о том, как многомиллионные экологические инициативы миллионеров типа Ричарда Бренсона по факту остаются только пиаром, и о том, чем опасны идеи решить проблему глобального потепления чисто технологическими способами, например распылением в атмосферу аэрозолей, снижающих интенсивность солнечного излучения.

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

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

Clayton Christensen «How Will You Measure Your Life?»

В русском переводе — Клейтон Кристенсен «Стратегия жизни»

Клейтон Кристенсен — профессор Harvard Business School и известный бизнес-автор. Пожалуй, самая знаменитая его книга — это «Дилемма инноватора», которая заложила основополагающую и системную теорию о том, как создавать инновации в компаниях.

В новой книге «How Will You Measure Your Life» (почему-то странно переведенную на русский язык как «Стратегия жизни») Кристенсен излагает своё видение того, как найти настоящие ценности и жить осмысленной и полноценной жизнью. В отличие от многих книг, которые принято называть «мотивационными», у Кристенсена деловой и системный подход — в качестве иллюстрации своих тезисов он приводит мини-кейсы как из жизни (в том числе своей собственной), так и из бизнеса.

Читайте эту книгу, если задумываетесь о том, как же вы хотите строить и оценивать свою жизнь.

P. S. Мне было очень сложно выбрать только пять книг для обзора, поэтому мне очень хочется хочется добавить еще одну — «Далекий простiр»Ярослава Мельника, которую я прочитал совсем недавно. Пожалуй, это одна из лучших художественных книг, которые мне встречались, и вдвойне приятно, что она написана украинским автором. Эта современная антиутопия заставит вас задуматься о том, насколько наше восприятие мира соответствует действительности, и о том, что такое настоящая свобода (если она существует).

[Від редакції: ми починаємо серію матеріалів про повернення в Україну. Розповімо про IT-спеціалістів, які поїхали з країни, але з різних причин повернулися. Якщо ви чи ваші знайомі мають такий досвід, напишіть на vlada@dou.ua].

Тая Холодова — Java-розробниця з 14-річнимстажем. А також засновниця Voopty — освітнього порталу, який поєднує в собі CRM та пошуковик шкіл, репетиторів, курсів, спортивних програм та іншого. У 2006 році вона зі своєю сестрою-близнючкою закінчила механіко-математичний факультет Харківського національного університету імені Каразіна. Спеціальність — викладач математики та інформатики. Проте не склалось — дівчата пішли в ІТ. Тая змінювала чимало компаній, а вже в 2014 році переїхала до Мюнхену в Німеччину на проект в Wirecard, а згодом в Holidu. За ці 5 років вона зрозуміла: досить працювати на когось — й заснувала Voopty.

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

— Університет ви разом зі своєю сестрою мали закінчити вчителями інформатики та математики, але стали програмістками. Що не так із вчительською професією?

Освіта, яку ми здобули в університеті хороша, але я б, наприклад, про математику так не розповідала. У нас погано пояснюють причини того, навіщо людині це треба знати і як використовувати, наприклад, геометрію чи математичний аналіз у житті. Вже згодом я дивилася лекціївід Массачусетського інституту. Там все набагато простіше. Півлекції учням пояснювали простими словами, що це і для чого, використовуючи багато жартів. Наприклад, теорію графів вони пояснювали за допомогою теми, чому у чоловіків за життя більше статевих партнерів, ніж у жінок. Для 17-річнихпідлітків це цікава тема. Та й справді, чому б це не використати як метафору? А у нас — здебільшого суха теорія. Люди засинають, мотивація низька.

Якщо брати хоча б фінансовий бік — це не вигідно. В той час, в 2005 році, старший викладач в університеті міг отримувати близько 700 гривень зарплати, тобто десь 150$. До того ж в таких структурах, як університет, дуже багато бюрократії і своєї політики на кафедрах. Так само в учительських в школах. Зрештою, це не тільки робота з учнями чи студентами. Є ще заповнення звітів, журналів та іншої документації.

Тоді як старший викладач отримував 150$, я в той же час першу роботу знайшла Junior Developer’ом за 200$ в комфортних офісних умовах. Відверто, гроші — це серйозна мотивація. Особливо, коли ти багато працюєш і багато отримуєш. Водночас, мені здається, велика зарплата демотивує, коли мало працюєш. У мене таке було в декількох компаніях.

Пригадую, у нас була практика на 4-мукурсі. Усі, хто навчався на нашому факультеті, проходили її в школах або коледжах. Закінчуючи університет, автоматично можна викладати у навчальних закладах. Оскільки я мала педагогічне направлення, то ми проходили практику в коледжі в Харкові. Саме тоді ми з сестрою зрозуміли, що дуже важко бути вчителем в Україні.

— Чому?

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

— Спробуйте пригадати, як вирішили покінчити з ідеєю викладати й спробувати себе в ІТ?

Я захистила бакалаврську роботу, треба було йти на 5-йкурс і отримувати магістра. Літо було вільне. Після 4-гокурсу я зрозуміла, що викладання — це не моє, а грати в ці політичні війни в навчальних установах не хотіла. Я дуже рефлексую на зацікавленість студентів. Якщо її немає, коли я викладаю, я буду обурюватись як щодо себе, так і щодо студентів. Для викладання в українських навчальних закладах треба витрачати забагато ментального ресурсу, а в поєднанні з бюрократією, політіграми і маленькою зарплатою — це точно не для моє. Літом перед 5-мкурсом я вирішила вивчати Java, читала книжки, наприклад, класику «Мова програмування Java SE 8» Джеймса Ґослінґа та «Effective Java» Джошуа Блоха. Вже на початку навчального року шукала собі першу роботу в Харкові.

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

Пам’ятаю: і в школі, і в університеті всі жалісно запитували, мовляв, навіщо нам ці синуси і косинуси. Якраз ці знання допомогли мені писати 3D- чи 2D-графіку. Я починала з цього. Коли ти працюєш в ІТ, то завжди можеш побачити результат. Якщо ти математик, твої роботи можуть люди ніколи не прочитати. Натомість твій елементарний сайт вже люди бачать. Вони можуть його поклацати, сказати, тут працює, тут не працює, можуть зрозуміти ідею. У математиці з цим дуже складно.

— За 12 років після університету ви змінили близько 7 компаній. Що вам в них не підходило?

Моя перша робота була тестувальницею, я на ній пропрацювала 9 місяців. Мені не сподобалось, я хотіла писати код. Тому згодом я знайшла собі іншу роботу на позиції Junior Java Developer, пропрацювала більше двох років. Це було дуже хороше місце. Я працювала з хлопцями з «Яндекса», «Рамблера» й багато чому там навчилася. Але мені хотілося все ж таки більш англомовне середовище, а там була лише російська мова. Згодом у 2008 році я перейшла в EPAM, тоді у них була криза, люди потрапляли під скорочення.

Загалом, моїм найулюбленішим проектом був Scalepoint у харківському Ciklum, це був 2011 рік. Більше двох років я там працювала на позиції Lead Java Developer. Окрім цікавих технічних задач, наприклад, розробка пошукових алгоритмів на базі Apache Solr, я, сама того не розуміючи, займалась трендовим зараз DevOps. 8 років тому цей напрям був ще не такий розвинений, але вже тоді відчувалась велика потреба приділяти більше уваги менеджменту інфраструктури і тісній співпраці між операційниками, розробниками та тестувальниками.

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

— Як так вийшло, що ваша сестра зараз у США, а ви працюєте тут?

Я ніколи не отримувала гідних пропозицій роботи в США. Були кілька інтерв’ю в Google, Amazon, але без успіху. Їхати в якийсь бодішоп і два роки сидіти на поганій зарплатні — я не хочу. В Україні і так можна непогано жити. Я проходила інтерв’ю в Google. Раз у півроку вони мені пишуть, щоб спробувала ще раз. Зараз я зайнята своїм проектом.

— Як ви в потрапили Німеччину?

Все просто: в LinkedIn мені написала рекрутер, сказала, що сподобався мій профіль й запропонувала спробувати. Я спробувала. У мене було два технічних інтерв’ю. Запропонували непогану зарплатню як для Німеччини, і я вирішила, що треба погодитися. Це була середина 2013 року. Окрім того, що мені було майже 30 років й завжди хотілось спробувати пожити за кордоном, також на мене тиснуло відчуття того, що в Україні трапиться щось погане. Я не знала що, але відчувалась гнітюча атмосфера в країні. Тому я погодилась на релокейт. Пам’ятаю, сиділа в аеропорті Борисполь з квитками — це було 19 лютого 2014-гороку — і бачила по телевізору, як розстрілюють Небесну сотню. Це було дуже складне відчуття.

— Це був страх невизначеності? Як ви собі це пояснювали?

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

— Ви сказали, що рекрутери запропонували вам непогану зарплатню. Для Німеччини непогана — це яка?

У 2014-мумені запропонували 65 тисяч євро на рік. Це нормально. Правда, у них зараз зарплатня трішечки росте. Можуть давати і 80 тисяч євро на рік. У той час 65 тисяч — це було дуже добре. Емігрантам там платять не менше, ніж місцевим, на відміну від США.

— На якому рівні у вас була тоді німецька мова?

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

До речі, я зауважила, що німці дуже традиційні й люблять цю свою рису характеру. Якраз про сексизм я вперше дізналася саме в Німеччині. Україні ще далеко до такого. У нас уже виросло третє покоління жінок, матері яких працюють. У Німеччині це буде лише перше. У них всі матері — зазвичай домогосподарки. Відтак, якщо на проекті йтиметься про велику відповідальності, тебе просто не помітять. Так було і зі мною. Нас було четверо розробників: я, дівчина з Росії і ще 2 хлопці, які мали нижчу кваліфікацію, ніж ми. Коли доходило до розподілу сфер відповідальності або менеджерських позицій, СТО нас не зауважував. Коли я йому прямо про це сказала, він відповів: мовляв, не думав, що вас таке може цікавити. Вони не розуміють, що жінка може добре працювати. А тим більше, що робота для неї може бути найголовнішим у житті.

Схожа ситуація з дитячими садками в Німеччині. Моїй подрузі, коли вона шукала місце для дитини, щоб піти працювати, сказали: навіщо це вам, коли маєте працюючого чоловіка? Хоча дитсадки і Німеччина — це окрема історія. Якщо ви емігрант, знайти для своєї дитини садок — майже неможливо. Там треба мати зв’язки, адже вам скажуть, що немає місць. Мій знайомий з Харкова, який зараз живе в Берліні, шукаючи місце для своєї дитини, якось прийшов у дитсадок і сказав прямо: «Я бачу, що у вас дуже поганий сайт, можу вам його зробити». Його дитині в результаті знайшли місце.

— Ви брали саббатікал, але до роботи так і не повернулись. Як так сталось?

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

— А чому не могли зізнатися?

Страшно. Я працюю відтоді, як мені виповнилось 21. Найдовша моя відпустка тривала 3 тижні. Я завжди знала, що у мене є робота, немає боргів, кожно місяця маю стабільну зарплату. А тут сказати, що я починаю свою справу і розуміти, що перший рік буде дуже непередбачуваний й фінансово від’ємний — це страшно. Згодом страх минув. Думаю, цим саббатікалом я сама себе обманювала, а то й страхувала. Я дала собі півроку і вирішила: якщо не вийде, через півроку я повернуся на цю роботу. Зрештою, не повернулася. Навіть можна сказати, що я відчула певне вигорання працювати на когось. Я 12 років працювала на чужі ідеї, тепер хочу приділити час своїм. Тому це вигорання дещо інакше: не від професії, а, скоріше, від певного способу виконання роботи.

Балет — хобі Таї

— Саббатікал для Європи — це звична справа?

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

Загалом, з життя в Німеччині я зрозуміла, що насправді впродовж цього часу отримала хороший досвід. Мені навіть хочеться комусь його передати, бо, здається, я мало чому можу вже навчитись на своїй позиції. Цей висновок я зробила, коли дивилася на своє керівництво в Німеччині. Я зрозуміла, що нічим не гірша. В Європі люди починають працювати набагато пізніше. Мені зараз 35, а досвіду вже маю майже 15 років. В Європі мені ніхто не вірив, тому що вони починають працювати з 30-тироків.

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

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

— Як народилася ідея вашого стартапу?

Переїхавши до Німеччини, я хотіла, знайти собі якесь заняття, яке було б неподалік мого будинку, наприклад, аеробіку, тренажерний зал, танці, кросфіт абощо. Здоров’я — це для мене важливо. У мене завжди були погані показники на фізкультурі, я нікуди не ходила, мала алергії та інше. Але коли в 26 років я почала займатися фізичними вправами, усе минуло. У Німеччині в мене була проблема: окрім мови я не знала і місто. Думала, мені допоможе інтернет, але ні. У всіх фітнес-студій сайти слабенькі, навіть якщо бюджет великий. Мені спочатку хотілося зробити для школи чи спорт-студій конструктор сторінок-візитівок, щоб можна було і розклад сконфігурувати, і знайти все на одному ресурсі. Я почала гратися з цим, хотілося ще навчитися Node.js, адже писала на Java 10 років. Хотілося вивчити щось новеньке.

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

— Як ви подолали цей страх?

Коли звільняєшся з роботи, розумієш — шляху назад вже немає. Була робота — можна було сидіти на зарплаті і не боятися, що не вийде. Після звільнення часу на страх немає, треба йти і розмовляти з людьми. Загалом почала займатись цим наприкінці 2015-гороку. Працювала над своїм проектом годину або кілька на день. На вихідних більше, по буднях менше. Бувало, що я могла на роботі сказати, що хворію, а сама — сиджу і працюю вдома над стартапом. Зараз приділяю йому близько 60 годин на тиждень.

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

Після зустрічі з користувачем Voopty у Бостоні Тая завітала до Гарварду

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

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

Мені сподобалися лекціїв Стенфорді від Y Combinator за 2013-йрік. Вони провели близько 20 лекцій. Там розповідають, що таке справжній стартап. Одразу на першій лекції кажуть: треба працювати 80 годин на тиждень і навіть більше. Треба відповідати повідомлення, які приходять на пошту о будь-якій годині доби, розмовляти з покупцями, а великі інвестиції вас не рятують. Гроші ні на що не впливають. Там про стартапи розповідають люди, які справді на цьому собаку з’їли, наприклад, Пітер Тіль.

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

Всем привет! Я — Андрей Товстоног, DevOps Engineer в компании Genesis. В статье поделюсь опытом построения маленького микросервиса с использованием бессерверной архитектуры AWS. Также расскажу, как работают push-уведомления и с какими проблемами мы столкнулись при реализации этого решения.

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

Не могу не согласиться: такое решение имеет право на жизнь. Но это добавляет работы. Поднятый инстанс нужно мониторить и в случае чего «тушить пожары». А, как известно, инженеров всегда напрягает, когда что-то идет не так. Да и просто хотелось «потрогать» такие сервисы, как Lambda и DynamoDB, пускай даже в такой небольшой, но жутко интересной задаче. Поехали.

Постановка задачи

Мы работаем в сфере медиа, и нам важно совершать рассылку уведомлений, чтобы держать заинтересованную аудиторию в курсе происходящих событий. До этой задачи у нас были отправки только ручных push’ей, то есть редакторы всегда сами совершали рассылку какой-то новости. Немного поразмыслив, мы прикинули, что было бы весьма неплохо сделать автоматическую отправку уведомлений, основываясь на топе читаемых статей. И нет, ручные push’и никто не отменял, они по-прежнему остаются :)

Окей, идея есть — теперь сформулируем задачу.

Необходимо по заданному расписанию выполнять рассылку push-уведомлений пользователям. Для этого будем использовать сервис аналитики (Analytics Service), который может отдавать по API топ-статьи по количеству просмотров за определенный период. На основании полученной информации формировать тело push’а и отправлять все это добро на API сервиса отправки push’ей (Push Service).

Как работают push-уведомления

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

Рис. 1. Пример работы push-нотификации (на схеме есть Apple Push Notification service, но все описание далее будет касаться Firebase Cloud Messaging — у Apple принцип работы похожий)

Итак, что мы имеем:

• Push Service — сервис, который отвечает за отправку push-уведомлений. Это красивая, функциональная обертка (стандартизированный API) над FCM (Firebase Cloud Messaging) / APNs (Apple Push Notification service), которая предоставляет сервис группировки пользователей (например, мы можем отправить push даже одному конкретному человеку, провести A/B-тестирование, просмотреть информативные отчеты и статистику). Этот сервис позволяет также не заморачиваться с форматами push-уведомлений, так как он сам этим занимается, а с нашей стороны необходимо всего лишь дать ему данные (payload).
• FCM — это Firebase Cloud Messaging (далее — FCM), сервис, который, собственно, и осуществляет непосредственную отправку push-уведомлений пользователям, используя их уникальные идентификаторы. Здесь может возникнуть законный вопрос: а каким образом FCM знает, как доставить push-уведомление? Все дело в том, что браузер (User Agent) держит перманентное TCP-соединение (одно для всего User Agent) с серверами Google, которые являются частью FCM. Это и объясняет, каким образом push доставляется практически моментально после отправки. Вообще, концептуально FCM состоит из двух частей: FCM backend и application server.
• FCM backend — это балансировщики нагрузки, а также серверы, выполняющие доставку сообщений клиенту. А вот и ответ на то, почему они выполняют и роль балансировки нагрузки. Они посылают клиенту специальные служебные уведомления о том, что необходимо сменить connection-сервер, а это означает, что текущее соединение разрывается и устанавливается новое; так и производится балансировка.
• Application server — это и есть Push Service, то есть часть, отвечающая за передачу уведомления нашему приложению через FCM backend.
• User Agent — это наш браузер.
• Service Worker (см. рис. 2) — это JavaScript-файл, который браузер запускает в бэкграунде, отдельно от веб-страницы, открывая доступ к фичам, которые не требуют запущенной страницы сайта или каких-либо действий со стороны пользователя, а также отвечающий за взаимодействие c Browser APIs, такие как Push API и Notification API. Эта штука является неким прокси, находясь между веб-сайтом, сетью и кешем. Да-да, именно он руководит тем, сходить ли нам в кеш или сделать запрос к серверу. Он и позволяет перехватывать события и выполнять какие-то действия на них. Можно еще отметить, что он работает непостоянно, то есть засыпает, когда не используется, и возобновляет свою работу, когда происходит какое-либо событие, на которое он подписан, в нашем случае это push event.
• Push API — это web API для управления подпиской на push-уведомления от Push Service, а также для обработки push-уведомлений. Благодаря Push API Service Worker получает возможность обрабатывать событие onpush.
• Notification API — отвечает за показ уведомления пользователю.

Еще несколько слов об API.

Рис. 2. Так работает Service Worker

API в контексте нашей темы делятся на два вида:

• API браузера;
• сторонние API.

Также они имеют одно общее название — это Web API, которые призваны облегчитьжизнь программистам.

Так вот, Push API и Notification API относятся к API браузера и представляют собой конструкции (набор объектов, функций, свойств и констант), построенные на основе языка JavaScript.

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

Откуда же берется Service Worker

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

Рис. 3. Жизненный цикл Service Worker

1. Регистрация. Происходит один раз при первом обращении к сайту.
2. Загрузка. Выполняется при первом обращении к сайту и повторно через определенные промежутки времени для того, чтобы предотвратить использование старой версии.
3. Установка. В случае первой загрузки будет произведена установка, а в случае повторной загрузки выполняется операция побайтового сравнения и, если есть отличия, производится его обновление.
4. Активация.

Service Worker готов к работе — поехали дальше!

Подписываемся на push-уведомления

Здесь можно отметить два шага:

• Запрос разрешения пользователя на отображение push-уведомлений. Это именно то назойливое окно, которое всплывает слева вверху с двумя кнопками — Block и Allow, когда мы заходим на сайт в первый раз и на сайте подключены push-уведомления.
• Подписка пользователя на push-уведомления (Push Subscription).

Подписка содержит всю информацию, которая необходима для отправки уведомления пользователю. Со стороны Push Service это выглядит как уникальный идентификатор устройства — ID. Далее это все добро (Push Subscription) отправляется на наш Push Service, где сохраняется в базе для последующей отправки push-уведомлений зарегистрированному пользователю.

За эти все процедуры отвечает тот самый упомянутый выше Push API.

Отправка push’а

Отправка push-уведомления заключается в триггере API нашего Push Service. Этот вызов должен содержать информацию, которую мы должны показать пользователю (payload), и группу пользователей, которой этот push будет отправлен. После того как мы сделали API-вызов, Push Service сформирует правильный формат для браузера и отдаст его в FCM, который поставит уведомление в очередь и будет ожидать, когда User Agent появится в сети.

Но push-уведомление не может жить в очереди вечно, поэтому у Push Service есть опция TTL (Time to Live), или время жизни уведомления, по истечении которого уведомление будет удалено :)

Получение push-уведомления пользователем

После того как Push Service отправил push-уведомление, FCM доставит (ну или не доставит, если что-то пошло не так) его в браузер, последний создаст такую штуку, как Push Event, на который отреагирует Service Worker и запустит обработку push-уведомления.

Вот мы и узнали в общих чертах, как работают push’и, так что теперь можем приступить к выполнению задачи.

Реализация

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

Рис. 4. Схема микросервиса

Состав нашего стека:

1. AWS Lambda Function — собственно центр нашего микросервиса, исполняет написанный в нашем случае на Python код. Эта штука сама выделяет ресурсы, которые необходимы для вычисления кода, и оплачивается только за фактическое время работы и за потребляемую память. Если верить описанию документации AWS, то облако даже гарантирует высокую доступность сервиса, что, конечно же, не может не радовать.
2. AWS DynamoDB — это база данных пар «ключ — значение» и документов, обеспечивающая задержку менее 10 мс при работе в любом масштабе. Это полностью управляемая база данных, которая работает в нескольких регионах с несколькими ведущими серверами и обладает встроенными средствами безопасности, резервного копирования и восстановления, а также кеширования в памяти для интернет-приложений. DynamoDB может обрабатыватьболее 10 трлн запросов в день с возможностью обработки пиковых нагрузок — более 20 млн запросов в секунду. В процессе формирования и отправки push-уведомления на Push Service выполняется проверка, было ли push-уведомление с таким ID уже отправлено или нет, а эти данные достаются из DynamoDB и пишутся в ней.
3. AWS CloudWatch — в нашем случае «двуглавый змей», который выполняет роль лог-сервиса, записывающего лог-выполнения Lambda и Event rule, который триггерит функцию по указанному времени, фактически выполняя роль планировщика (cron).
4. Analytics service — сервис с API, в котором «происходит магия», и в итоге мы можем доставать топ-статьи, например по количеству просмотров.
5. Push Service —  сервис, позволяющий отправлять наши push’и.
6. Slack — старый добрый «слак», куда же без него, в который делаем нотификацию по отправке.

Итак, начинаем с того, что пишем код для Lambda-функции. Особенность его в том, что необходимо определить входную точку, так как Lambda-функция вызывает функцию (2) внутри Lambda-функции, которая объявляется как Handler (1) :)

1) Handler —  это и есть входная точка, которую и вызывает Lambda. Название Handler должно совпадать с именем функции в коде; 2) имя функции, которая будет входной точкой в Lambda; 3) Event и Context — встроенные параметры, которые передаются вызываемой функции

Здесь возникает законный вопрос: а что же такое эти переменные, которые мы передаем функции?

Документация говоритисчерпывающе:

Event — этот параметр используется для передачи данных о событиях обработчику. В нашем случае мы достаем из поля event тело ответа от API Analytics Service. Прилетает оно в формате json.

Context — передает контекст объекта обработчику. Этот объект предоставляет методы и свойства, которые предоставляют информацию о вызове, функции и среде выполнения. Перейдя по ссылке, можно увидеть методы и свойства, а также здесь доступен пример логирования информации контекста. Из контекста мы берем request_id, который используется для того, чтобы Lambda не запускалась несколько раз.

А вот как это все работает под капотом. CloudWatch event rule по расписанию триггерит Lambda-функцию, она в свою очередь выполняет код, выполняет запрос / обновление данных в DynamoDB, записывает логи через CloudWatch и делает уведомление в Slack.

Ниже представлена блок-схема, которая описывает алгоритм работы сервиса.

Рис. 5. Алгоритм работы микросервиса

Работа скрипта начинается с того, что он делает запрос в сервис аналитики (Analytics Service) и достает 100 топ-статей. Почему именно 100? Это связано с поддоменами, так как на каждый поддомен должна отправляться статья, опубликованная именно на нем, например example.com и subdomain.example.com. На example.com должна уйти статья, опубликованная на example.com, а на subdomain.example.com — опубликованная на поддомене subdomain. Так как поддомен subdomain является более специфическим или конкретизированным, то статьи на нем появляются реже. А если совсем просто, то Analytics Service API не умеет возвращать список статей для конкретного поддоменного имени, а только для домена целиком. Вот как-то так :)

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

После этого выполняется отправка push-уведомления пользователям с уникальной статьей.

Проблемы, с которыми столкнулись

А теперь о проблемах, с которыми мы столкнулись при реализации этого сервиса.

Изначально скрипт представлял собой, условно говоря, 5 строчек:

• брали одну топ-статью с сервиса аналитики;
• формировали json;
• отправляли на Push Service.

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

Решили мы эту проблему, подключив в нашу логику DynamoDB для записи отправленного article_id. После маленьких правок мы стали доставать из сервиса аналитики по 5 топ-статей и сравнивали article_id c записью article_idиз базы; если повторялся, брали следующую статью из топ-выборки, обновляли запись в базе и отправляли push.

Проверяем, полет нормальный, но недолгий :)

Настигла нас проблема, что push’и начали повторяться через 1–2отправки (ну оно и логично :)), так как у нас в базе лежит только один ID статьи и он перезаписывался — небольшой просчет в архитектуре сервиса.

Поэтому следующим шагом стало то, что мы начали создавать массив items, состоящий из article_id, и записывать его в базу DynamoDB. Длину массива решили определить равную 5 — этого более чем достаточно, но в случае необходимости всегда можно увеличить. Проверяем, полет нормальный, но недолгий, хотя дольше, чем в предыдущем случае.

Следующая проблема — это перезапуск Lambda-функции, что влекло за собой отправку 3 push-уведомлений с интервалом в 1 мин. Это происходило, когда сервис отправки push’ей отваливался по тайм-ауту и Lambda-функция считала, что она завалилась, и запускалась повторно. Это, как оказалось, стандартное поведение для Lambda-функции, которая работает в асинхронном режиме, и, если при выполнении функции она вернет ошибку, Lambda попробует выполнить ее еще раз. По умолчанию Lambda будет пробовать дополнительно 2 раза с интервалом в 1 мин.

Решили эту проблему добавлением в DynamoDB такого поля, как request_id. При каждом новом запуске Lambda генерирует уникальный request_id (он не меняется при перезапуске функции), который мы и вытягиваем из context. Проверку уникальности request_idвыполняем перед проверкой article_id, а обновляем его каждый раз, когда article_id уникален. В итоге мы обрываем повторное выполнение функции, если такие попытки появляются.

Следующий вопрос может стать таким: «Так если Push Service отваливается по тайм-ауту, то как вы понимаете, ушел push или нет?». И это тоже очень правильный вопрос. На самом деле на протяжении всего полета «не было ни единого разрыва» :) То есть push отправлялся всегда, даже если мы не получали никакого ответа от API Push Service. Об этом говорит статистика отправки в административной панели Push Service, а также уведомления в Slack.

Подводя итоги

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

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

Цифры в скобках возле заголовков — примерное время на изучение материала.

Статьи

Общее

ТОП-25 ошибок в BPMN(15 мин). Лаконичная статья, в которой собраны наиболее часто повторяемые ошибки при проектировании моделей с использованием BPMN. Большинство из них и сам встречал, совершал на практике. Полезно будет как новичкам, так и тем, кто хочет освежить основные нюансы использования нотации.

Karl Wiegers: Revealing Invisible Requirements(10 мин). Краткая выжимка советов из книги «Software Requirements, 3rd Edition». Статья дает рекомендации о том, как работать с неявными, подразумеваемыми и пропущенными требованиями.

Karl Wiegers: Six Estimation Safety Tips(9 мин). Очень стоящие советы, которые стоит выучить не только каждому аналитику, а вообще всем. Эти советы давно всем известны, только почему-то, по опыту, мало кто ими пользуется. Вспоминаем и применяем :)

Краткая информация об области знаний «Business Analysis Planning and Monitoring»(1 мин). Для тех, кто всерьез интересуется изучением BABOK и последующей сертификацией, Денис Гобов подготовил удобную схему взаимосвязи задач, техник и других компонент этой области знаний.

Краткая информация об области знаний «Requirement Life Cycle Management»(1 мин). То же, что и выше, но для другой области знаний. С нетерпением ждем таких же таблиц для остальных областей :)

Бизнес-аналитик в распределенной команде (часть 1)(5 мин). Денис Гобов делится своим опытом и размышлениями о работы распределенной команде. Рекомендую изучить, так как вы обязательно столкнетесь со всеми указанными проблемами, если попадете в подобный проект.

Why Agile Isn’t Enough Part 1: How Lean Startups Fulfill The Promise Of Agile(10 мин). Статья из цикла о методологии Lean, которая призвана лаконично дать понимание основных концепций методологии. В следующих частях автор обещает больше погрузить нас в методологию, а также сделать обзор инструментов и техник, которые помогают аналитику строить Lean Startups.

Бизнес-процессы. Извлечение BPMN-модели из документа. Часть 1(12 мин). Статья о том, как из процесса, описанного в виде текста, генерировать BPMN-модель. Предварительно ощущается, что проще, все же, отрисовать блоки с нуля (особенно с учетом ограничений метода). Тем не менее, стоит подождать продолжения, прежде чем делать окончательный вывод, так как сам по себе подход очень нетривиальный.

Как провалить внедрение CRM-системы?(30 мин). Истории из практики, которые будут полезны всем, кто сталкивается с CRM: компаниям — каких ошибок избежать при внедрении, разработчикам CRM — как помочь своим клиентам, аналитику — как сделать правильный выбор, оценить альтернативы.

Mike Cohn: Your Team Won’t Think of Everything in Sprint Planning Meetings. And That’s OK.(6 мин). Рекомендации от одного из создателей SCRUM о том, как лучше всего планировать скоуп спринта.

The Best Self-Service BI Tools For 2019(12 мин). Автор статьи приводит различия между классическими BI-системами и BI-инструментами, которые позволяют работать с данными без привлечения IT-департамента. Также представлен обзор лидирующих self-service инструментов.

Understanding Business Data Analytics(9 мин). Whitepaper от IIBA, в котором рассматривается концепт дата-аналитики и его отношение к практикам бизнес-анализа.

UI/UX, prototyping

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

Design Checklist for the Perfect Charts(8 мин). В большинстве случаев для графиков проще взять готовую бесплатную библиотеку (коих много), чего будет более чем достаточно для решения задачи. Но если какие-то стандартные решения вас не устраивают и вам пришлось создавать решение самостоятельно — этот чеклист поможет вам определиться с тем, что именно вы или ваш клиент ищете в решении для графиков.

Search UX: 6 Essential Elements for ‘No Results’ Pages(16 мин). Практические советы по оформлению страниц результатов поиска в случаях, когда «ничего не найдено». Если вкратце: просто показать текст «ничего не найдено, попробуйте поискать иначе» — самое худшее, что может случиться. Есть и другие, более достойные альтернативы.

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

When Cancel Buttons Should Not Say «Cancel»(6 мин). Классическая проблема именования кнопок CTA и второстепенных альтернатив — автор объясняет на примерах, как делать правильно, а как — нет.

How to Prevent Accidental Data Loss from Destructive Actions(9 мин). Защита от случайного удаления данных — известная задача. Автор статьи рассматривает наиболее удачные и неудачные примеры решения задачи и дает рекомендации о том, как правильно выстраивать такую защиту.

Learn, Discover, Find, and Search: Elements of Usable Design(16 мин). Интересные размышления о ключевых принципах поиска (как явления в принципе) и об их применении в разработке функциональности поиска.

What is User Testing? Best Practices UX Designers Should Know(10 мин). Автор рассматривает основные виды пользовательского тестирования, его отличие от юзабилити-тестирования. Также автор делится ссылками на инструменты / платформы для проведения тестирования и примерами проведения реального пользовательского тестирования.

5 Tips For Improving Your UX Writing(5 мин). Краткие, но простые подсказки, следуя которым ваш UX Writing станет более эффективным. А еще автор делится ссылкой на инструмент, который умеет автоматически валидировать ваши тексты на избыточность и корректность.

Effective Mobile App UX Enhancement(7 мин). Статья о том, как простыми вещами улучшить ваше мобильное приложение. Советы основаны на успехе таких гигантов, как LinkedIn, Netflix и т. п.

The Good, The Bad, And The Ad: How To Deal With Bad Mobile Ads(12 мин). Мобильная реклама — зло, но зло зачастую необходимое. Пользователи ненавидят мобильную рекламу, и это не изменить. Но можно попробовать сделать так, чтобы ваше мобильное приложение с рекламой вызывало минимум негодования. Как это сделать — см. рекомендации в статье.

How To Use Spaces In Web Design With Gestalt Principles(20 мин). Достаточно подробное исследование об использовании гештальт-принципов при проектировании интерфейсов.

Очень интересный цикл статей на тему проектирования функциональности, связанной с приватностью пользователей. В нем автор исследует возможные подходы к сбору данных и взаимодействию с системой, которые будут наиболее деликатными в отношении пользователя. Изучение полного цикла займет около полутора-двух часов. Статьи: Privacy UX: Common Concerns And Privacy In Web Forms(часть 1, 27 мин), Privacy UX: Better Cookie Consent Experiences(часть 2, 21 мин), Privacy UX: Better Notifications And Permission Requests(часть 3, 25 мин), Privacy UX: Privacy-Aware Design Framework(часть 4, 14 мин).

5 Techniques to Make Mobile Call to Action Buttons Intuitive(6 мин). Простые и вместе с тем очень действенные советы о том, как делать делать CTA-кнопки.

Motion Design Doesn’t Have to Be Hard(6 мин). В статье рассматривается множество примеров реализации motion design на основе Google Material Design. Внутри много очень много примеров анимации, так что залипнуть можно и больше, чем на 6 минут. Вас предупредили :)

Accessibility

Designing for accessibility is not that hard(12 мин). Простые, понятные и не требующие больших дополнительных затрат рекомендации, которые сделают ваш сайт более доступным для людей с ограниченными возможностями. Автор — дизайнер из InVision Studio — изучил множество действующих стандартов и сделал их них выжимку. Несмотря на то, что статья за июнь 2018, все советы из нее актуальны.

10 Tools for Improving Website Accessibility (4 мин). Обзор набора инструментов, которые помогут сделать ваше веб-приложение более приспособленным для людей с ограниченными возможностями. Наиболее перспективные для использования — 508checker (но почему-то требует «кредиты», хотя указана как бесплатная, а где заплатить — непонятно), WAVE и mobiReady (еще в бете, потому хоть результаты весьма интересные, визуализация еще очень сырая).

Supporting Localization(20 мин). Размышления на тему важности локализации систем + набор рекомендаций о том, что делать и чего не делать, чтобы успешно спроектировать систему.

My Web Accessibility Testing Process(6 мин). Автор делится своим подходом тестирования доступности веб-приложений с использованием инструментов от WebAIM.

Color Blindness Considerations for Designers and Content Managers(6 мин). Немного размышлений на тему важности правильного выбора цветов для того, чтобы люди с проблемами зрения могли пользоваться вашей системой, не чувствуя ограничений.

Nielsen Norman Group

How to Report Errors in Forms: 10 Design Guidelines(10 мин). Статья о том, как помогать пользователям обрабатывать ошибки валидации и не только. В частности, автор предлагает в явном виде описывать проблему и предлагать способы ее решения.

Web Page Footers 101: Design Patterns and When to Use Each(18 мин). Подвалы страниц (футеры) — это такая вещь, которая сегодня есть на каждом сайте. Но не всегда футерам уделяется достаточно внимания, так как почему-то считается, что это второстепенная вещь. Статья призвана разубедить читателя в этом заблуждении и показать критичность футера для веб-приложений.

Status Trackers and Progress Updates: 16 Design Guidelines(23 мин). Очень практическое руководство по созданию эффективных статус-трекеров и прогресс-баров, а также как их можно и нужно применять вместе.

Top 10 Application-Design Mistakes(18 мин). Список 10 наиболее распространенных ошибок при проектировании приложений (по версии NN Group), собранные и проанализированные за последние 11 лет.

UI Copy: UX Guidelines for Command Names and Keyboard Shortcuts(14 мин). Хорошие гайдлайны по проектированию команд быстрого доступа. В статье рассмотрено много удачных и неудачных примеров, в том числе в известных приложениях.

Teenager’s UX: Designing for Teens(18 мин). В прошлом выпускея уже упоминал про обновленный отчет «Children’s UX: Usability Issues in Designing for Young People». Текущий отчет также получил обновление. Статья — обзор, полный отчет доступен по ссылкеза $149 (индивидуальная лицензия) и $288 (групповая лицензия). Также хочу упомянуть, что у группы есть еще один отчет, за 2016-йгод — Young Adults/Millennials as Web Users (Ages 18–25)(8 мин).

Коммуникация

How to give feedback without being an asshole(10 мин). Статья с провокационным названием — выжимка из книги «How to Do Great Work Without Being an Asshole», которая посвящена нетоксичности в рабочем окружении и о том, how to be a nice guy. Автор статьи приводить ключевые нюансы, которые нужно учитывать, чтобы ваш фидбек был услышан. Также есть советы по правильному принятию фидбека о вас.

Как давать обратную связь: 9 правил(10 мин). Хорошее руководство с примерами — «бери и пользуйся» :)

How to Give Constructive Criticism(8 мин). Еще один весьма трезвый взгляд на проблему дачи и принятия фидбека.

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

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

5 Killer Questions Types For Digital Transformation(8 мин). Автор поднимает тему нюансов коммуникации между data scientists и бизнесом, в частности о том, как правильно задавать вопросы. В статье представлены примеры вопросов от data scientist и то, как business analyst трансформирует их на более привычный бизнесу язык. Рекомендую статью всем аналитикам, так как подход к коммуникации актуален и без учета специфики.

Подкасты

Lightning Cast: Death, Taxes, and Missed Requirements(8 мин). В ходе подкаста обсуждаются причины, которые вызывают потерю требований, а также как этого избежать.

The BA Role on a Scrum Team(26 мин). Авторы подкаста пытаются разобраться, почему вопрос ценности и роли BA в Scrum-командах до сих пор обсуждается весьма активно и, по случаю, высказывают свое мнение на вопрос. Также рассмотрены примеры того, что аналитик может делать, чтобы быть более ценным членом Scrum-команды.

Lightning Cast: Non-Functional Requirements in Agile(7 мин). Авторы высказывают свое мнение на счет места, ценности и способов управления нефункциональными требования в Agile-проектах.

Business Analysis in Agile(27 мин). Не впервой вижу материал, в котором Agile рассматривается уже не столько как «серебряная пуля», а еще и как достаточно сложная среда, к которой нужно приспособиться. Вот и в этом эпизоде обсуждаются проблема и вызовы, которые перед компаниями, командами и аналитиками, работающими в Agile-среде.

События

Май

4 мая, вебинар Prototypes in Business Analysis.

23 мая, вебинар The BA’s friend or foe? How to fit Requirements Engineering into Agility.

Июнь

6 июня, вебинар Agile Business Analysis.

11 июня, вебинар Not Your Mama’s Acceptance Criteria: A Product Owner’s Guide to Writing Excellent User Stories.

13 июня, вебинар Our Requirements Are Good, So Why Aren’t We Delivering Value?

Стажировки, курсы

7 мая стартует курс «Business Analysis»в Харькове, от тренинг-центра AdvanceIT. Курс предназначен для тех, у кого уже есть опыт в IT. Игорь Ямшанов (один из тренеров курса), который ранее давал интервью для статьи «Советы сеньоров: как прокачать знания Junior Business Analyst», рекомендует курс как «очень практический, в результате прохождения которого можно получить ценные артефакты, которые потом можно переиспользовать в работе» ©

7-8июня пройдет второй THINKSTAGE. Как и в прошлом году, обещают много опытных спикеров, готовых делиться своими секретами, а также массу интересных докладов.

Продолжается набор на cтажировку по направлению «Business Analysis»в NIX Solutions.

Инструменты

Состоялся долгожданный релиз Axure RP 9.

В Draw.io есть отличный шаблон Business Model Canvas. Выглядит отлично, легко редактируется. Если искали простой и бесплатный способ отрисовки Canvas — это самое то.

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

За январь-март Trello выкатили целый набор новых power-up’ов, а также пачку досок для управления командами.

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

Balsamiq представилипереработанный фулл-скрин режим для презентаций.

Большое обновление Camunda Modeler 3.0.0.

Не менее крупное обновление Bizagi 3.4.

Если вы используете Slack, то будете рады исправлению ряда дефектов на всех платформах: Windows, Mac, iOS, Android. На последней также появилась поддержка Google Smart Lock.

Значительные обновления Skype. В частности очень радуют две возможности. Первая — запостить несколько файлов одновременно, с предварительным просмотром списка файлов, которые собираешься сбросить. Вторая — заблюрить задний фон во время звонков: теперь посторонние движения в квартире не будут смущать собеседников ;)

Другое

Ричард Фейнман — Магниты и вопросы «почему?» (8 мин). Отрывок из интервью с лауреатом нобелевской премии по физике. В нем Ричард в ответ на вопрос, «почему магниты работают так, как работают, и как работают вообще», высказал очень интересную теорию о природе вопросов типа «почему». Меня этот монолог навел на интересные мысли о нередких проблемах в коммуникации между очень разными профессиями, в частности в IT — сложности взаимопонимания между дизайнером и разработчиком, клиентом и командой и т. д. В том числе — как правильно задавать вопросы и отвечать на них. А еще сразу вспомнилась техника «5 Whys» — ее важность, полезность и применимость как инструмента, с помощью которого можно дать хороший ответ на вопрос.

Юмор

Мечты стейкхолдеров

Современные проблемы требуют современных реше... Оу...

Смилуйтесь и хоть иногда давайте клиенту передохнуть от сессий вопросов и ответов :)

Предыдущий выпуск: BA дайджест #0→