В предыдущих статьяхя уже начал рассказывать о нюансах работы бизнес-аналитика. Сейчас же хочу поделиться мыслями о том, как стать BA — какие навыки важны, где учиться и как сменить специализацию. Данная статья будет полезна людям, которые хотят получить позицию Business analyst / Product owner, будь то новички в мире ИТ или же специалисты других направлений, такие как разработка или тестирование.

Есть ли смысл идти на платные курсы?

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

Основной вывод: каждый трактует работу, как он хочет, оперирует высокоуровневыми терминами и понятиями. Те, кто хоть немного понимает в IT, продают знания от $300/курс и выше. Вот вам один из примеров. Стоимость за 3 дня — 1000 евро с тренером, который никогда не работал как БА/PО.

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

С чего начать и что делать?

У вас должна быть цель, к которой вы будете идти. У кого-то это всеобщее признание и $1000 на счету или покупка квартиры. Если нет цели, вы не будете знать, куда идти, соответственно, не сможете составить план действий, чтобы достичь ее.

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

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

Много работайте. Если будете тратить на работу и развитие 8 часов в день, то вы станете крутым специалистом через 5 лет (если станете)! А те, кто будут тратить по ~12 часов в сутки, станут таким же за 3 года. Главное — быть увлеченным тем, что делаешь! Старайтесь углубляться как можно больше в каждый вопрос, на который вы ищите ответ.

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

Кто есть кто?

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

Дата-аналитик — это человек, который работает с большим объемом информации. Основная обязанность заключается в том, чтобы извлечь нужные данные и проанализировать их для дальнейших решений. То есть этот специалист решает 3 основные задачи: сбор и анализ данных, а также разработка бизнес-решений на основе полученной информации. (wiki)

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

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

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

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

Имеем процесс, но не имеем как таковой позиции. Это то, что было придумано исключительно на нашем рынке. Зачастую это означает смесь системного аналитика и product owner.

Product owner — связующее звено между заказчиком и командой. Главная его задача — создать и контролировать backlog. (источник)

Product manager — специалист, который работает с продуктом, исследует рынок, анализирует финансовую часть. Фактически этот человек выступает CEO продукта. (wiki)

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

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

Как начать?

Используйте разные информационные ресурсы для изучения. Для начала важно получить базу и узнать основные понятия IT. Вот несколько источников, которые мне помогли:

• Modern.analyst.com
• Artofba.com
• Telegram chat: Business Analysis Magazine_chat
• Telegram chat: UA BA Community Chat
• Telegram chat: Анализ Систем
• Facebook group: IT Network — Business Analysis & Project Management

Там же в телеграм-чатах пробуйте найти ментора.

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

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

Как перейти в бизнес-анализ?

Задавайте вопросы, ищите новые знакомства и расширяйте свои горизонты. Берите на себя больше обязанностей. «Я готов», — эта фраза должна стать вашим девизом.

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

Отвечу на простом примере — как свичнуться для QA: это люди, которые имеют прямое отношение к разработке ПО:

1. Попросите у себя на проекте вести демо: вы подтянете английский, научитесь слушать клиента, сможете что-то рекомендовать, уйдет страх.
2. Обратитесь к Product owner с прямой просьбой: «Я хочу заниматься бизнес-анализом, помоги мне разобраться». То есть просите. Это не стыдно, наоборот, это возможность бесплатно получить информацию от практика.
3. Вы получите теоретические знания, но дальше нужно пробовать идти на джуниор позиции.

Что нужно знать на старте?

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

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

Почитайте про UML. Все вам не понадобится, нужно будет только пару диаграмм (Activity / Class / Use case). Хорошо, если у вас будут achievements с предыдущей работы, даже если это не касается IT (улучшение процесса, оптимизация чего-то).

Загуглите что такое SDLC. После этого, у вас будет представление того, что и как происходит хотя бы в теории.

Помогают ли курсы получить работу?

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

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

Нужна ли сертификация?

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

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

Нужна ли техническая экспертиза?

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

Какие программы нужно знать, чтобы начать работать?

Я бы сказал — никакие. Максимум — Excel. А Jira, TFS и прочие отличаются во всех компаниях. Они настолько разные, что невозможно все знать. Я бы сказал, что это самое последнее, в чем нужно разобраться.

Нужен ли английский?

Да, Upper-Intermediate — must have. Рекомендую украинский продукт Grammarly, помогает при написании документации. Я учил английский на оффлайн-встречах. Первые 2 месяца молчал, максимум мог сказать «Yes» или «No». Но потом начал пытаться говорить и спустя год уже хорошо коммуницировал с собеседниками.

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

Львів’янка Марія Панютіна переїхала до Силіконової долини разом із чоловіком у 2012 році. Після роботи у GlobalLogic та Verifone, Марія влаштувалась на позицію software engineer у LinkedIn. Через рік жінка отримала підвищення до senior software engineer. Про етапи проходження співбесід, структуру роботи в команді та те, над чим зараз вона працює в компанії, Марія розказала DOU.

Про початок кар’єри програміста

Мені 29 років, програмістом я працюю більше 10 років. Почала як фрілансер ще у 2008-му.Тоді це не було мейнстрімом. У 2010 році я закінчила Львівський політехнічний інститут за напрямом «Комп’ютеризовані системи, автоматика і управління». За спеціальністю попрацювати не вийшло, не було сильного зацікавлення.

В Україні працювала в OSF Global Services та SoftServe UI-інженером. Майже всі проекти, де я побувала, були пов’язані з американським ринком. Чоловік також програміст, пише на С/С++. Познайомились ми в 2007 через спільних друзів. Жили в гуртожитку, вчились, працювали, правда, в різних компаніях. Разом росли кар’єрно — книжки, курси, фріланс. Узаконили стосунки в 2009. Це було доволі смішно.

Він: Маш, може одружимось?
Я: коли?
Він: давай у серпні?
Я: якщо 15-те —субота, то давай в суботу...

Переїзд і перша робота в США

У 2012 році він отримав можливість поїхати в США, і ми вирішили ризикнути. Ми приїхали за L1/L2 візами (внутрішньофірмовий переїзд). Тому в мене не було можливості працювати офіційно і потрібно було чекати на work permit (дозвіл на роботу). Перші кілька місяців я закінчувала свої проекти на SoftServe, потім, поки чекала, вибирала вакансії, які мені подобаються, складала список вимог, яких мені не вистачало, чого я ще не навчилась, та вдосконалювала знання, практикувала англійську. За час поки я чекала work permit — подавала на нього декілька разів, — я встигла навіть народила дитину. Їй було три місяці, коли я нарешті отримала дозвіл.

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

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

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

Пропрацювавши на Verifone (через посередника GlobalLogic) більше півтора року, я вирішила глянути, що робиться на ринку праці. Пройшовши успішно декілька інтерв’ю в невеликих продуктових компаніях і отримавши оффери, вирішила піти, але менеджер з Verifone зробив контроффер, і я залишилась. Правда, пішла на інший проект. Там ще пропрацювала близько 10 місяців на стандартному проекті (Portal System).

Потім отримала дзвінок від рекрутера з LinkedIn і зрозуміла — це мій шанс працювати з Big Data, у великих проектах, змога застувати свої знання для покращення продуктивності і швидкості веб-додатків. Ще під час роботи на GlobalLogic і Verifone ми з чоловіком розуміли, що треба вчити щось нове, і майже весь свій вільний час тратили на LeetCode і «Cracking The Coding Interview» (вечорами, коли дочка спала чи вихідними — на прогулянках). Це того вартувало: чоловік працює в Google, а я — в LinkedIn як FTE (штатний інженер).

Про роботу в LinkedIn

Великі компанії завжди шукають кандидатів. Рекрутери з Facebook, Google, Apple мені пишуть раз у півроку (питають, чи бува не готова поміняти роботу). Зазвичай у день буває 2-3повідомлення зі стартапів, раз у тиждень — з менших компаній.

У LinkedIn я проходила стандартний набір: телефонна розмова з рекрутером, телефонне інтерв’ю (2 практичні алгоритмічні задачі і близько 5 теоретичних питань), і onsite (8-годинне7-модульнеінтерв’ю). Після проходження всього мені на вибір запропонували піти в одну з чотирьох команд. Це було дуже приємно. Я вибрала організацію Data.

У нашій команді близько 25 людей. Тут і data scientists, і pipeline engineers, backend, frontend. Ми працюємо над проектом, який називається «Test, Ramp and Ехреrementations» — платформа, що дозволяє менеджити налаштування і виконання A/B тестів незалежно від код релізів. Також ця платформа дозволяє ізолювати реальні результати експерименту від шуму.

Наприклад, було вирішено оновити версію якоїсь частини LinkedIn (уявімо, що треба поміняти зелену кнопку з написом Accept на оранжеву з написом Admit). Оскільки ці зміни зможуть побачити всі користувачі, а це більше 500 млн людей, ми подаємо ці зміни тільки на 5% користувачів — вони обираються рандомно за специфічним алгоритмом. Потім моніторимо, як змінились метрики. Якщо все ок, тоді піднімаємо процент (ramp) ще на 10%. І дивимося далі до миті, поки не буде 100% з позитивними метриками. Моніторинг, сповіщення — усе відбувається автоматично, базуючись на даних. Наразі в нас активні десятки тисяч тестів. Мені дуже подобається бачити, що всі рішення на фічі для продукту базуються на реальних даних, а не на баченні окремого менеджера чи інженера.

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

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

LinkedIn прагне і працює над тим, щоб бути єдиною платформою, яка допомагає зростати кар’єрно. Тут стараються охопити всі вікові і соціальні групи. Після купівлі «Лінди» з’явилася можливість проходити технічні і нетехнічні курси. Головні правила компанії: «Members First», «Act like an owner» і «Make shit done». І вони мені подобаються своєю відвертістю. Я їх транслюю так: «Бери відповідальність за свою роботу, наші користувачі повинні мати можливість робити кар’єру своєї мрії».

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

Співбесіди в LinkedIn

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

В LinkedIn, як і у всіх великих компаніях Долини, є свій процес інтерв’ювання. Перше — це, звичайно, HR, який перевіряє загальну адекватність програміста. Потім телефонне інтерв’ю. Воно зазвичай триває 45-60 хвилин.Перші 5 хвилин — представлення, наступні 15 — прості теоретичні питання, потім 30 хвилин — 1 чи 2 задачки (зазвичай використовується Skype for interview чи інший online editor), і якщо залишився ще час — то прикінцеві питання (типу, а який фреймворк ви використовуєте, а яка завантаженість).

Якщо пройшов телефонну співбесіду, то наступний крок — onsite. Це зазвичай інтерв’ю з 09:00 ранку до 16:00 вечора, яке складається з 7-мимодулів. Кожен модуль триває 45-60 хвилин:

1. Алгоритими.
2. Бачення продукту.
3. Мова програмування (JavaScript у моєму випадку).
4. Прагматичне програмування.
5. Системний дизайн і архітектура.
6. Обід з менеджером.
7. І на кінець — hiring менеджер з рандомної інженерної організації.

На всіх модулях є по два інтерв’юери, окрім 6-гоі 7-го —там тільки по одному. Модулі 1, 3, 4 — написання коду на дошці з покриттям тестів і дизайном, 5 — діаграми на дошці. Решта — зазвичай проста розмова. Після онсайту кожен інтерв’юер має написати відгук на проходження свого модуля.

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

Мій процес (від дзвінка рекрутера до першого дня в компанії) зайняв 4 місяці. Готувалась я за книжкою «Cracking the coding interview» + leetcode.com i hackerrank.com.

Наразі я тут працюю вже 2,5 роки і отримала підвищення з software engineer до senior software engineer. Кожен процес підвищення — подання заявки менеджером, фідбеки від команди і інших менеджерів, рев’ю комітів з тестами і документацією — займає від 3 місяців, а якщо з позиції senior до staff — то від 6 місяців. Ти не можеш прийти до менеджера і сказати, що хочеш на вищу позицію. З менеджером постійно йде комунікація.

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

Як компанія утримує своїх співробітників

Заробітна плата складається з 3-хскладників: база, бонуси і акції. Бонуси нараховують раз у рік, базуючись на річній продуктивності (OKRs, oncalls, feedbacks, etc). База може переглядатись і частіше. Акції нараховуються на 4 роки в момент підписання оффера і видаються перший раз після першого року в компанії 25% і по 6,25% кожних 3 місяці. Але розмір зарплати дуже залежить від компанії. На мою думку, найкращу зарплату з великих компаній дає Facebook, найменшу, — напевно, Tesla.

Я народила другу дитину, працюючи в LinkedIn. Ця компанія вважається найкращою в плані відпусток і декрету. Дають 12 тижнів повністю оплаченого parental leave і чоловікам, і жінкам, якщо у вас народилася дитина, коли ви були співробітником LinkedIn. Також дають 8-12тижнів disability (pregnancy/delivery) leave (у середньому 75% від заробітньої ставки, ці гроші не оподатковуються).

Усім співробітникам надають 2 тижні оплачуваного shut down (відпочинку — ред.): 1 тиждень на День незалежності, інший — на Різдво. Також є нелімітована відпустка: зазвичай люди беруть по 1-2тижні до кожного shut down. Якщо ти чи твоя дитина захворіли, можна взяти вихідний день чи працювати із дому.

Дуже зручний графік роботи. Наприклад, у нас будинок на околиці Сан-Хосе, і мені їхати на роботу по дві години в одну сторону у звичний для всіх час. Тому я приїжджаю на роботу о 6-йранку і закінчую о 3-йпо обіді, щоб уникнути цього трафіку. Усі мітинги, де я потрібна, закінчуються до цього часу.

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

Кожен місяць в п’ятницю є InDay, коли можна займатися своїм проектом чи покращувати свої знання на курсах. Є безкоштовні курси з 3D printing, laser cutting, photo printing, etc.

Медична страховка у всіх великих компаніях однакова. За два тижні коштує близько $900 на сім’ю. Я з них плачу тільки $100 на два тижні за всю сім’ю, все інше доплачує компанія. Але це страховка настільки хороша, що я за свої ускладнені пологи доплатила лише $250. Також у нас є послуги адвокатів. За $5-10 в місяць у тебе є адвокат на 2 випадки в рік. Є страховки життя. За два тижні я плачу за всі страховки (до оподаткування) близько $340. Є внески в пенсійний фонд. У свій приватний пенсійний фонд я відкладаю $500, а компанія доплачує від цієї суми 50%, але максимум $9 тис. у рік.

Підвищення кваліфікації

Вчитися потрібно завжди. Нові мови, нові стандарти. Прийшла в big data — і маєш трішки розбиратися, що це таке. Також до пари глянути на machine learning. Постійно треба, крім досвіду, отримувати нові знання. Я не закінчувала додаткових університетів, але я брала додаткові курси, і в Україні також. На інтерв’ю не було питань щодо моєї спеціальності, бо в мене диплом системного інженера. Це явно не те, чим я зараз займаюся. Але в мене був кращий старт, ніж у випускників Стенфорда, бо в мене багато досвіду. Я знаю, як писати продукт, працювати з менеджерами, з командою. Тут дивляться на те, наскільки ти знаєш, що ти робиш.

Усі компанії, в котрих я підписувала оффер, робили background check. Це не тільки виписка з поліції. Це ще й наскільки ти правдиво себе описав у резюме. Копія диплому нічого не означає, вони роблять офіційний запит в університет, щоб перевірити, що я там навчалася. Також вони дзвонять у попередні компанії, де ти працював останні 5 років. У моєму випадку дзвонили в GlobalLogic, SoftServe, OSF Global Services.

Життя з родиною в Силіконовій долині

Найскладніше все починати з нуля. В Україні в мене була родина, кар’єра, друзі, знайомі, власна квартира. Тут — нічого. Як і в будь-якому місці, тут є свої плюси і мінуси. Найбільшою перевагою для нас є те, що ми — обоє програмісти — живемо в центрі технологій. Будь-коли можемо поміняти роботу. Мінус — тут дуже дорого. Це одне із найдорожчих місць у світі. Наприклад, приватний дитсадок і дошкільний/післяшкільний догляд — $2 300 у місяць, кредит на будинок + податок + комунальні послуги = $4 100 (в місяць). І це все опісля оподаткування заробітної плати, що в середньому складає близько 35%.

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

Я прокидаюся о 5:00 ранку, готую меншому в дитсадок lunch box і одяг на день, старша снідає та обідає в школі. О 5:45 виїжджаю з дому, о 6:15 я вже в офісі. Чоловік прокидається о 5:30. О 6:20 будить і одягає дітей, о 6:45 відвозить у школу (дошкільний догляд) і їде в офіс. Я о 3:00 їду додому. Там маю годину, яку я можу присвятити собі. О 5:00 виїжджаю по дітей, о 5:45 ми з дітьми вдома. О 6:30 приїжджає чоловік, і до 8:30 стараємося присвятити час тільки дітям. О 8:30 ванні процедури, і кладемо дітей спати.

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

Я часто чую від українок, що я погана мама, бо займаюся кар’єрою, а не домом і дітьми. На таке стараюся уваги не звертати, бо ми якісно проводимо час. Наприклад, моя дочка наприкінці своїх 4-хроків почала писати і читати. Зараз (5 років минуло у вересні) вона вже переписується зі мною і чоловіком в скайпі, багато читає самостійно і пише нам з чоловіком записки. І оскільки ми знаємо, що в нас мало часу вдень — ми його цінимо ще більше.

Часу на соціальне життя майже не лишається, але нам це не дуже заважає. Ми домашні і можемо спокійно сидіти з кавою і цікавою книжкою. Зараз можу сказати, що ми зробили дуже хорошу кар’єру в США. Чоловік після Verifone перейшов у Googlе. Але це було дуже важко — виховувати дітей, вчитися і працювати.

Що далі

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

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

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

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

Project Management Institute (PMI)

PMI — международная организация, которая привлекает волонтеров для создания стандартов по управлению проектами. Созданный PMI свод знаний по управлению проектами (PMBoK) был признан Американским национальным институтом стандартов (ANSI) и Международной организацией по стандартизации (ISO). PMI объединяет более 500 тыс. экспертов в более чем 190 странах. В Украине он представлен PMI Kyiv Chapter. Самая распространенная PMI сертификация Project Management Professional (PMP) считается одной из самых престижных. На сегодня более 800 тыс. человек получили эту сертификацию.

Обзор PMI Сертификаций:

Project Management Professional (РМР) — для допуска к экзамену требуется 3,5 года опыта работы проектным менеджером. Подготовка к экзамену занимает около 3 месяцев. Обязательным критерием является прохождение обучения в аккредитованном центре, не менее 35 часов. Сам экзамен состоит из 200 вопросов за 4 часа. Вопросы построены так, что на них, как правило, нет очевидного ответа. Все предложенные варианты могут выглядеть правильными, но надо выбрать только один из 4-х.Сертификация особенно распространена в США, но в мире она также остается одной из самых узнаваемых. Экзамен строится на материале из PMBoK, но готовиться к экзамену лучше по специальным материалам. Одними из самых популярных являются руководства к подготовке от Rita Mulcahy.

Certified Associate in Project Management (CAMP) — аналог PMP, ориентированный на кандидатов с небольшим опытом работы или даже без него. Вопросы те же, но их меньше и поэтому экзамен немного проще. Как и PMP, он базируется на PMBoK.

Portfolio Management Professional (PfMP)и Program Management Professional (PgMP) — сертификации считаются одними из самых сложных существующих профессиональных сертификаций. Требуют опыт в 6000 часов управления проектами, программами или портфелями проектов. В мире чуть больше 500 сертифицированных PfMP и чуть более 2000 PgMP.

Risk Management Certification (RMP) — сертификация не особо распространенная в наших широтах. Она рассчитана на тех, кто занимается оценкой проектных рисков. Как правило, роль риск-менеджера выделяют на очень больших проектах или как отдельное лицо/подразделение в организации. Экзамен дает обширный набор инструментов и практик для работы с рисками. Скорее, имеет смысл как дополнение к PMP или любой другой сертификации.

PMI-SP — эта сертификация ориентирована на тех, кто специализируется на построении календарного плана для проекта. Как и RMP, имеет ценность как дополнение к PMP или аналогичной сертификации.

PMI-PBA — сертификация предназначена для бизнес-аналитиков. Вполне достойный аналог BABoK и сопутствующих сертификаций.

PMI-ACP — в рамках сертификации рассматриваются Agile, Scrum, Kanban, XP, Lean и др. Достойная альтернатива различным Agile-сертификациям.

AXELOS

Совместное предприятие правительства Великобритании и компании Capita, объединило сертификации, которые находятся в собственности правительства. Из них самые распространенные: ITIL, PRINCE2, P3O, MoP, MSP.

ITIL — набор лучших практик по управлению IТ-сервисами. Очень недооцененная сертификация и одна из наиболее релевантных для сферы ІТ-аутсорсинга. Свод практик состоит из 5 книг, которые по структуре чем-то напоминают PMBoK. Тут нет областей знаний, только группы процессов, и вместо 49 их около 30. Сертификация имеет много уровней.

Самый высокий уровень Masterсопоставим по сложности с PfMP, хотя сравнивать эти сертификации довольно сложно. Особое распространение ITIL получил в ІТ-департаментах крупных компаний. ITIL идет часто об руку с ISO 20000 или COBIT (альтернатива). Сертификация имеет модульную структуру.

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

Относительно недавно в структуре появился новый уровень Practitioner Level. Если начальный уровень — это лишь теория, то на этом уровне проверяются уже практические аспекты. За прохождение уровня Practitioner дается 3 балла.

Следующий уровень ITIL Intermediate Levelтребует как минимум сданного ITIL Foundation и обучения на авторизованных курсах. Данный уровень имеет модульную структуру и разделяется на две категории: Service Lifecycle и Service Capability. Для получения сертификата можно выбрать лишь одно из направлений. Service Lifecycle ориентировано на изучение процессов управления жизненным циклом сервисов в 5 модулях (курсы и соответствующие экзамены):

• Service Strategy;
• Service Design;
• Service Transition;
• Service Operation;
• Continual Service Improvement.

За каждый экзамен группы Lifecycle дается 3 балла.

Service Capability покрывает практики управления ІТ-услугами в отдельных областях. Сюда входит 4 модуля:

• Operational Support and Analysis (операционная поддержка и анализ);
• Service Offerings and Agreements (сервисные предложения и соглашения);
• Release Control and Validation (управление конфигурациями и изменениями);
• Planning Protection and Optimization (защита и оптимизация планирования).

За каждый экзамен группы Lifecycle дается 4 балла. Для тех, кто решил пойти дальше, как раз и нужны эти баллы. Кандидату необходимо набрать минимум 22 балла, чтобы получить уровень ITIL Expert Level. Еще одним необходимым условием является сдача экзамена MALC (Managing Across the Lifecycle), который дает 5 баллов.

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

PRINCE2 — одна из самых распространенных альтернатив PMI PMBoK. Британский стандарт по управлению проектами, как и его американский аналог, применим в разных индустриях, не имеет ограничений по размеру или специфике проекта. Основное отличие, которое можно выделить, — это то, что PMBoK есть сводом знаний, в то время как PRINCE2 позиционируется как методология, фокус на том, что необходимо делать.

По сути, PRINCE2 и PMBoK не являются конкурентами и не противоречат друг другу, некоторые компании используют и то, и другое. PRINCE2 имеет несколько уровней сертификацииPRINCE2 Foundationи PRINCE2 Practitioner. Оба экзамена заметно проще PMP. В 2017 году Axelos обновила экзамен, но пока еще есть возможность сдавать версию 2009 года. Также есть экзамен PRINCE2 Agile, Guidebook, который представляет собой комбинацию из оригинального PRINCE2 и Agile-принципов и лучших практик.

P3O, MoP, MSP

MSP — это логическое продолжение сертификации PRINCE2. Если PRINCE2 описывает, как управлять проектами, то MSP, или Managing Successful Programmes — это методология по управлению программами. MSP представляет собой практические рекомендации по созданию среды программы и объясняет, как уровень программ должен взаимодействовать с уровнем проекта и более высокими уровнями в рамках крупной организации, которая обычно видит программу как часть общего портфеля.

Для обеспечения надлежащего управления бизнес-изменениями и всеми связанными инициативами (программы и проекты) необходим портфельный уровень управления. MoP™ — Management of Portfolios — является подходящим руководством для этого. Для объединения подходов по управлению проектами, программами и портфелями была разработана модель P3O и фреймворк для оценки зрелости процессов в компании P3O3. Все эти модели и руководства имеют сертификации. Большинство разделено на два уровня — Foundation и Practitioner. Но пусть название Foundation не вводит в заблуждение, это всего лишь уровень владения методологией, как правило, означает теоретические знания. Для выбора подходящей сертификации стоит обращать внимание именно на саму методологию. PRINCE2 — это уровень Project Manager/Senior Project Manager, MSP — Program Manager/Delivery Manager. MoP- Director/VP. P3O — подойдет для C-levelменеджеров, собственников бизнеса.

International project management association (IPMA)

Европейский аналог PMI IPMA предлагает четыре уровня сертификации:

• IPMA A — Сертифицированный директор проекта
• IPMA B — Сертифицированный старший менеджер проектов
• IPMA C — Сертифицированный менеджер проектов
• IPMA D — Сертифицированный помощник менеджера проектов

В отличие от сертификаций PMI и PRINCE2, которые проходят на базе сертификационных центров (Prometric, PeopleCert), сертификация IPMA проводится местным сертифицирующим органом. В Украине это Сертификационное отделение УКРНЕТ/Серт Украинской ассоциации управления проектами «УКРНЕТ» , которая прошла международную валидацию на соответствие сертификационной программы IPMA^® 4-L-C правилам IPMA^®.

Процесс сертификации выглядит следующим образом:

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

Также организация проводит сертификацию консультантов по управлению проектами. Два уровня международной сертификации IPMA^®:

PMC IPMA^®: Сертифицированный консультант по управлению проектами
За последние 8 лет имеет не менее 3 лет опыта работы в качестве консультанта по управлению программами и портфелями проектов. За последние 20 лет имеет 3 года опыта работы в качестве менеджера проектов. Способен консультировать в области управления проектами на уровне проекта.

PPMC IPMA^®: Сертифицированный консультант по управлению программами и портфелями проектов
За последние 8 лет имеет минимум 5-летнийопыт консалтинга по УП, не менее 2 лет из которых — в качестве консультанта по управлению программами и портфелями проектов. За последние 20 лет имеет 3 года опыта работы в качестве менеджера комплексных проектов. Способен консультировать в области управления проектами на уровне стратегии/организации.

Scrum Alliance

Провайдер одной из самых распространённых сертификаций для проектных менеджеров CSM (Certified Scrum Master)часто предлагает связку сразу из двух сертификаций CSM и CSPO (Certified Scrum Product Owner). Полная карта сертификаций выглядит следующим образом:

Также предлагаются сертификации Scrum Alliance Certified Enterprise Coach℠ (CEC), Certified Scrum Trainer^® (CST^®),Certified Agile Leadership. В последнее время Scrum Alliance подвергается критике, так как для получения сертификации нужно пройти обязательный тренинг. Цена тренинга составляет $800-1500, и, как правило, он проходит в игровом формате. После его прохождения открывается доступ к экзамену, который носит больше формальный характер.

Scrum.org

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

• Professional Scrum Master Certifications — имеет три уровня PSM I ($150), II ($250), III ($500);
• Professional Scrum Product Owner Certifications — имеет два уровня PSPO I ($200), II ($500);
• Professional Scrum Developer Certification ($200);
• Scaled Professional Scrum Certification ($250);
• Professional Scrum with Kanban Certification ($200);
• Professional Agile Leadership Certification

ICAgile

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

Large Scale Scrum (LeSS)

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

• Certified LeSS Basics — Overview of LeSS;
• Certified LeSS Practitioner — Principles to Practices;
• Certified LeSS for Executives — Principles, Organization, & Change.

Scaled Agile Framework (SAFe)

Scaled Agile — Scaled Agile Framework (SAFe vX.X) — один из самых тяжеловесных Agile-фреймворков. Для оценки масштабов достаточно взглянуть на сравнение инфографики, описывающей Scrum и Scaled Agile Framework:

Scrum

SAFe 4.5

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

• Certified SAFe^® Agilist (SA)
• Certified SAFe^® Program Consultant
• Certified SAFe^® Practitioner
• Certified SAFe^® Scrum Master
• Certified SAFe^® Advanced Scrum Master
• Certified SAFe^® Release Train Engineer
• Certified SAFe^® Product Owner/Product Manager
• Certified SAFe^® DevOps Practitioner (SDP)

Lean Kanban University

Сертификации, которые предлагает этот университет могут заинтересовать тех, кто практикует Kanban.

Practitioner (TKP)покрывает основные концепции Kanban. В рамках обучающих классов проходят 4 типа Kanban-систем, как проходят ежедневные митинги и обзор следующих уровней сертификации.

Manager (KMP)состоит из двух частей KMP I и KMP II. В отличие от первой, сертификация подразумевает, что вы можете не только следовать процессам и знать их основные нюансы, но и построить систему с нуля или оптимизировать существующую.

Также есть сертификации для тренеров Trainer (AKT)и коучей Coach (KCP). На них стоит обратить внимание тем, кто планирует не только строить процесс, но и учить других, как это делать, выступать в роли тренера.

Six Sigma

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

• Yellow Belt:этот уровень рассчитан на члена проектной команды или организации, который работает над улучшениям на проекте/в организации (process improvement).
• Green Belt:обладатель этого пояса также работает над улучшениями, но уже оперирует метриками и может самостоятельно вести небольшой проект.
• Black Belt:черный пояс дают тем, кто способен вести проект и тренировать остальных в своей команде.
• Master Black Belt (этот уровень не всегда присутствует в иерархии сертификаций провайдеров): это тот, кто работает на стратегическом уровне в организации, проводит тренинги и готовит к сертификации обладателей черного и зеленого поясов.

Организации, которые предлагают сертификацию по Six Sigma:

• American Society for Quality (ASQ);
• Institute of Industrial and Systems Engineers (IISE);
• Chartered Quality Institute (CQI);
• Lean Six Sigma Accredited Provider (IASSC).

Также ряд университетов имеет сертификационные программы по Six Sigma.

Непростой выбор

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

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

Немного о моем опыте

PMO Competence Manager в SoftServe, в прошлом — Senior Project Manager. Вел несколько крупных аккаунтов, вырастил из нескольких небольших проектов третий по величине аккаунт на SoftServe. На данный момент ответственный за направление People Excellence. Занимаюсь разработкой моделей компетенций для проектных менеджеров. Оптимизирую процессы оценки знаний и performance руководителей проектов всех уровней, отбора внешних кандидатов. Координирую менторские и on-boarding программы для PM-ов. Совместно с SoftServe University разрабатываем тренинги для проектных менеджеров.

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

Примерно через год после сдачи PMP, на одном проекте с крупным британским концерном, столкнулся с процессами, которые отличались от тех, что в PMBoK. Оказывается, у них на корпоративном уровне внедрен PRINCE2. Чтобы лучше понимать процессы на стороне клиента, прочитал Managing Successful Projects with PRINCE2^® 2017 Edition. Уже после окончания проекта достаточно хорошо разобрался в этом подходе и без труда сдал экзамен.

На другом проекте мы перешли от Fixed-Price модели к SLA поддержке. Решил построить процесс согласно best practices и изучил ITIL Service Operation. Через некоторое время для более полного понимания картины прочитал остальные 4 книги и решил сдать экзамен, больше чтобы проверить свои знания и понимание.

Веду в SoftServe тренинги по Scrum и Kanban, но сертификаций в этом направлении не проходил, пока не вижу в этом смысла. Планирую в ближайшее время пройти тренинг и сдать сертификацию по SAFe. Есть большой интерес со стороны клиентов к этому фреймворку.

В выпуске: новый блог Дэна Абрамова, как улучшить производительность вашего веб-приложения, разбираемся с React Hooks и Lazy-loading, а также материалы по Angular, Vue.js и Node.js.

CSS и CSS in JS

Making Future Interfaces With Custom Properties — кастомные свойства в CSS

A look at CSS Resets in 2018 — смотрим на CSS Rest с современным взглядом

Dark modes:

• Dark modes with CSS
• From dark to light and back again — инженеры 1Password о том, как сделать темную тему в блоге

A timing attack with CSS selectors and Javascript — CSS для хакеров

Preventing Content Reflow From Lazy-Loaded Images — как правильно загружать картинки

Bridging the Gap Between CSS and JavaScript:

• CSS and JavaScript: CSS-in-JS
• CSS Modules, PostCSS and the Future of CSS

Новинки из мира CSS in JS:

• Announcing native support for the css prop in styled-components
• Announcing Emotion 10!

Пишем CSS по новому:

• color-adjust
• scrollbar-gutter
• Everything about CSS environment variables
• How and when to use the tabindex attribute

JavaScript

Hummingbird: Building Flutter for the Web

Console.rules()— становимся гуру консоли

The Power of Web Components — почему нужно использовать веб-компоненты

Web workers vs Service workers vs Worklets — зачем нам нужны веб-воркеры, сервис-воркеры и ворклеты

Going Offline First — делаем веб-приложение оффлайн

Little known features of JavaScript — баги и фичи JavaScript’а

These tools will help you write clean code — пишем код лучше с Prettier, ESLint, Husky, Lint-Staged и EditorConfig

Handling Errors in JavaScript: The Definitive Guide — как лучше отлавливать ошибки

An Introduction to Functional Programming Style in JavaScript — пишем функциональный JavaScript

Understanding Asynchronous JavaScript — the Event Loop — разбираемся в асинхронности

Performance

The Baseline Costs of JavaScript Frameworks — почему современные фреймворки такие большие?

A Netflix Web Performance Case Study — Эдди Османи анализирует производительность Netflix

CSS and Network Performance — как CSS влияет на производительность вашего веб-приложения

Improving Document Preview Performance — как инженеры Dropbox ускорили отрисовку превью документов

Fast Google Fonts with Cloudflare Workers — как оптимизировать подгрузку шрифтов вместе с Cloudflare

You need neither PWA nor AMP to make your website load fast — Никита Прокопов рассуждает, как сделать ваш сайт быстрым

React и React Native

A Guide to Custom Elements for React Developers

These are the concepts you should know in React.js (after you learn the basics)

How to create a three layer application with React

Testing React Components with Jest and Enzyme- In Depth

Inside Fiber: in-depth overview of the new reconciliation algorithm in React

Lazy Loading:

• Lazy loading (and preloading) components in React 16.6
• How to use React.lazy and Suspense for components lazy loading

React Hooks:

• Making Sense of React Hooks
• How to Build a Todo List with React Hooks
• Handling Errors in JavaScript: The Definitive Guide
• Why React Hooks, and how did we even get here?
• Under the hood of React’s hooks system
• Simple Code Reuse with React Hooks

How to Develop a Location-based Application Using React Native

Vue.js

Structuring a Vue project — Authentication

How to create a Vue.js app using Single-File Components, without the CLI

My Favorite Vue.js & Nuxt.js packages for 2019

Real-life use cases for computed properties in Vue

Turn your Vue Web App into a PWA!

Plans for the Next Iteration of Vue.js

Type Vue without TypeScript

Angular

Building Interactive Lists with the new Angular 7 Drag and Drop tool

Theming Angular

Keeping browser tabs in sync using localStorage, NgRx, and RxJS

Best practices for a clean and performant Angular application

Creating a toast service with Angular CDK

The benefits of using pure pipes in Angular templates

How to optimize Angular applications

Node.js

Lets build express — пишем свой Express с 0

Writing memory efficient software applications in Node.js

NodeJS: In Three(ish) Minutes

How to use NodeJS without frameworks and external libraries

Nodejs C++/JS Boundary: Crossing The Rubicon

Why You Should Consider hapi

Библиотеки и инструменты

Fx — инструмент командной для форматирования JSON на JavaScript

HTM — JSX на шаблонных литералах

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

Linaria — новый CSS in JS, который генерирует CSS

NCC — CLI для компиляции Node.js от Zeit

ImmortalDB — key-value хранилище в браузере

Progress Estimator — логируем прогресс выполнения промиса

Worker Plugin — добавляет поддержку Web Worker’ов в Webpack

Ervy — строим графики в терминале

Carlo — браузерное окружение для Node.js приложений

Percollate — инструмент командной строки для превращения веб-страниц в PDF-файлы

Демо

3D Astronaut — на веб-компоненте <model-viewer>

3D Emoji Town (Pure CSS)

Послушать

Frontend Weekend:

• #77 — Александр Амосов о том, почему стоит начать работать с 3D в браузере
• #78 — Антон Черноусов aka golodnyj о становлении менеджера продукта из программиста и подкастинге
• #79 — Олег Поляков об основании CodeDojo и о том, как это стало основным местом работы
• #80 — Гордей Левченко о переезде в Казахстан и развитии frontend-сообщества в Астане
• #81 — Екатерина Павленко о том, как работает программный комитет HolyJS изнутри

Веб-стандарты:

• Выпуск № 144
• Выпуск № 145
• Выпуск № 146
• Выпуск № 147
• Выпуск № 148

devschacht:

• 55: Быть тимлидом
• 56: NodeConf EU 2018
• 57: Как в компании Wrike используют язык Dart
• 58: UFADEVCONF, состояние Node.js в 2018 году
• 59: Как сделать крутой доклад

Фронтенд Юность (18+):

• #69 Java не успевает за JavaScript
• #70 Капитан Хук и Кот
• #71 На работу к Илону Маску через ректальные хуки
• #72 Как попасть к Ситнику в Browserslist
• #73 Три корочки Эдди Османи

CSSSR Новости 512:

• Выпуск № 27 (29.10 — 04.11)
• Выпуск № 28 (05.11 — 11.11)
• Выпуск № 29 (12.11 — 18.11)
• Выпуск № 30 (19.11 — 25.11)
• Выпуск № 31 (26.11 — 02.12)

RadioJS #53

Конференции и митапы

FrontTalks 2018

WSD в Киеве 2018

WSD в Минске 2018

HolyJS 2018 Piter лучшее

MoscowJS 43

dotCSS 2018

dotJS 2018

Chrome Dev Summit 2018

ReactiveConf 2018

React Day Berlin 2018

KharkivJS #9 2018

Что нового

PageSpeed Insightsтеперь работает на Lighthouse

VisBug — редактор интерфейсов в виде расширения для Chrome

Microsoft переводит Edge на платформу Chromium:

• Microsoft is building a Chromium-powered web browser that will replace Edge on Windows 10
• Microsoft Edge: Making the web better through more open source collaboration

Overreacted — персональный блог Дэна Абрамова

Остальное

State of JavaScript 2018

Web.dev — коллекция курсов по разработке веб-приложений

Рассылай и властвуй: инструменты для создания и тестирования рассылки — как в 2ГИС создают и тестируют email-рассылки

I don’t know what to say — уязвимость event-stream

Exploiting Developer Infrastructure Is Ridiculously Easy

7 bad excuses for not using TypeScript — почему не TypeScript

DevTools for Designers

The Ultimate VSCode Setup for Front End/JS/React — настраиваем VSCode под повседневные задачи

Готовимся к интервью:

• Front-end JavaScript Interviews in 2018–19
• Learn to code in 2019, get hired, and have fun along the way

Grammarly ищет талантливых Front-End инженеров для усовершенствования нашего продукта, создания минималистичных элегантных пользовательских интерфейсов и решения сложных технических задач. Нашим продуктом пользуются миллионы пользователей каждый день. У нас замечательная команда, вместе с которой мы используем самые передовые технологии. И если вам интересно стать частью её, то смотрите открытые вакансииздесь, или стучитесь ко мне в Facebook.

С вами был Григорий Шехет. За помощь в оформлении дайджеста благодарю своих коллег.

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

У випуску: автори PHP і Zend Framework йдуть із Zend, реліз Symfony 4.2 і WordPress 5.0 „Bebo”.

Основне

Розробники ядра PHP і основні контрібьютери Zend Framework йдуть з Zend, а точніше з компанії Rogue Wave Software, яка його поглинула в 2015 році і вирішила, що крім Zend Server їй нічого розвивати не цікаво.

З ZF це Matthew Weier O’Phinneyі Enrico Zimuel. З PHP це Zeev Suraski, співзасновник Zend, і Дмитро Стогів, який зробив PHP 7 таким швидким і зараз робить JIT-компіляцію для PHP 8.

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

WordPress will require PHP7 by the end of 2019

Що нового в PHP 7.3 за 30 секунд у Diffs

NPM dependency hell: comparison with Symfony, Laravel and API Platform

The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)

WordPress 5.0 „Bebo” released

php-ext-wasm now supports „imported functions”: Run Rust/C/C++/Go via WASM in PHP, and define the extern function implementations in PHP directly!

PHP Support in AWS Lambda coming soon

Accurate decimal numbers in PHP

How PHP conferences can be improved

Релізи

Вийшов PHP 7.3.0:

• Гибкий синтаксис Heredoc і Nowdoc
• Міграція regex на PCRE2
• Покращення в MBString
• Підтримка LDAP Controls
• Покращене логування FPM
• Покращення у видаленні файлов під Windows
• Частина фіч помічена як застаріла

Повний список змін можна знайти в ChangeLog.

Symfony 4.2 Released

Symfony тепер має офіційний admin interface ReactJS-based, безкоштовний і 100% open source

Open source

A time range immutable value object

PHPArch: Architecture testing for PHP applications

Різне

З вами був Роман Севастьянов.

Підписуйтесь на мій Телеграм канал про PHP — я там публікую новини зі світу PHP, security баги в live режимі.

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

Цього року ми перезапустилирейтинг роботодавців — обнулили попередні голоси, розширили анкету та створили категорію для великих компаній. За два місяці 14 602 ІТ-спеціалісти проголосували за 993 компанії.

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

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

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

Поехали! Заполнить анкету

Результаты опроса — приблизительно через месяц. Результаты предыдущих опросов можно посмотреть в отчетахили с помощью виджета.

Все вопросы, предложения и пожелания по поводу опроса можно оставлять в комментариях к этому посту или присылать по почте на cb@dou.ua.

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

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

Хочу викладати. До кого звертатися?

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

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

Артем Коротенко, Software engineer в Tatem Games та викладач НТУУ «КПІ»:

«Я помітив, що мене тегнули під постом від представника ФІОТ (факультет інформатики та обчислювальної техніки) про пошук викладачів на два вільні курси. Я закінчив цей факультет, але іншу кафедру рік тому. Отож порозуміння з керівництвом кафедри вдалося досягти швидко. Фактично я отримав дозвіл взяти достатньо нестандартний курс — „Введення в ігрову розробку“ та майже з нуля створити матеріали до нього».

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

Андрій Заблоцький, QC Expert у SoftServe та викладач НУ «ЛП»:

«Я звернувся до Зеновія Вереса — колеги по SoftServe та засновника програми „Інтернет речей“ в НУ „Львівська Політехніка“. Він уже не перший рік працює над трансформацією навчальних програм. Зеновій запропонував мені зробити пілот курсу „Основи тестування ПЗ“. Отже, моє бажання збіглося з прагненням університету змінюватися та переходити від вивчення Pascal з конспектів до створення живих робочих аплікацій, які вирішують певні задачі. А головне — почав співпрацювати з людьми, які поділяють мою думку та бачать у цьому сенс».

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

Максим Почебут, директор освітніх програм в EPAM Україна, кандидат технічних наук:

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

До яких формальностей готуватися

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

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

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

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

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

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

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

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

Як розробити навчальну програму

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

Він рекомендує викладачу поставити собі запитання: кого ви, як лектор, хочете бачити в кінці вашого курсу навчання?

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

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

За його словами, розробка всієї навчальної програми зайняла приблизно один тиждень. При цьому майбутній викладач спирався на поради Зеновія Вереса та вже готову програму курсу Quality Control ІТ-академії SoftServe.

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

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

За словами Зеновія Вереса, засновника програми «Інтернет речей» в НУ «Львівська Політехніка» та Solution architect у SoftServe, конкретні вимоги до навчальної програми вказані у нормативних документах кожного ЗВО. Наприклад, у ЛП викладач сам вирішує, що саме викладати під час курсу. Проте є вимоги до того, які компетенції студенти мають здобути на виході, як розподілятимуться бали, яку літературу брати за основу.

Як стати хорошим викладачем

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

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

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

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

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

За словами Артема, N років у сфері та бейджик Senior/Lead не робить з людини гарного викладача. Це, по суті, інша професія.

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

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

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

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

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

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

І головне питання. Навіщо?

Якщо у вас немає вченого звання (доцент чи професор) або ж наукового ступеня (кандидат чи доктор наук), імовірно, вас влаштують як асистента кафедри та запропонують зарплатню 4-6 тис.грн. Це за умови роботи на повну ставку — 600 годин навчального навантаження у рік (це як заняття, так і, наприклад, перевірка курсових чи консультування студентів-дипломників). Якщо менше, це відповідно складатиме 0.75, 0.5 або 0.25 ставки. Також є різні надбавки — наприклад, за роботу з контрактниками чи статусність ЗВО.

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

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

До того ж, досвід викладання дав Андрію привід освоїти з нуля встановлення трекінгових та test case management систем.

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

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

Меня зовут Максим Вороной, я — Consultant Engineering в GlobalLogic (Харьков). С 2000 года я занимаюсь архитектурой ПО, в круг моих интересов входят распределенные и облачные системы, а также построение систем с элементами искусственного интеллекта. Кроме этого, я веду учебный курс для разработчиков по современной архитектуре программных приложений.

Недавно во время GlobalLogic Kharkiv Java Conference 2018 я сделал доклад об использовании Spring Global Lock и написал эту статью на его основе.

Как мы получили проект

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

Специалисты южной страны сказали: «Да! Точно! Мы знаем, в чем причина!». Разработчики добавили парочку временных задержек в коде, установили для пользователя ограничение на длительность сеанса работы, сказали: «Теперь все работает!», — и выпустили второй релиз. Европейская страна проверила, и оказалось, пока в системе два человека, — все прекрасно, а на десяти начинаются уже известные проблемы.

Южная страна выпустила второй, третий релиз, разработчики добавили кое-что «волшебное»: еще больше увеличили задержки, добавили пару лишних инстансов серверов JBoss. Тестировщики опять добросовестно проверили базовые бизнес-сценарии, по которым все работало. А европейская страна сказала: нет, ребята, не работает — пожалуй, на этом мы с вами и расстанемся.

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

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

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

Case Study: книжный магазин

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

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

Как было

Дизайн таблиц базы данных для задачи тривиальный:

Таблица Store содержит все доступные для покупки книги с первичным ключом isbn.

Таблица Payment содержит результат совершенной покупки, где: payment — первичный ключ, amount — сумма, которую нужно заплатить за приобретаемые книги, transaction — атрибут, отправляемый банком.

Таблица BookOrder, реализует связку 1:N между Store и Payment (1 платеж за N книг).

Южная страна с давними традициями программирования написала следующий код (для простоты приводятся только используемые SQL-запросы в порядке выполнения):

public void buyBooks(List<Book> books, Payment userPayment){
// Validate:
final String checkSql =
"SELECT 1 FROM Store WHERE isbn = ? AND amount > 1";
// Modify business entities
final String insertPaymentSql =
"INSERT INTO Payment (amount, transaction) VALUES ...";
final String insertOrderSql =
"INSERT INTO BookOrder (payment, isbn) VALUES ...";
final String updateStoreSql =
"UPDATE Store SET amount = amount -1 WHERE isbn = ?";
}

Валидация заключается в простом запросе: SELECT 1 FROM Store WHERE isbn = ? AND amount > 1. Таким образом мы проверяем, имеется ли книга на складе. Затем создаем «платежку» в таблице Payment, добавляем новую запись в таблице BookOrder и в финальной строке кода уменьшаем количество экземпляров книги на складе на единицу.

Три подхода к решению

Реализация уровня junior

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

@Transactional // (!)
public void buyBooks(List<Book> books, Payment userPayment){

В этом месте читатель, должно быть, улыбнется: понятно, что проблема решена не была.

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

Способы организации транзакций

Тут я напомню о двух из пяти вариантов изоляции транзакций в базах данных:

Read committed — транзакция читает только фиксированные данные (от завершенных транзакций). Этот уровень изоляции используется в большинстве существующих баз данных по умолчанию (Oracle, SQL, MySQL и пр.). Оптимальное соотношение между производительностью и изоляцией, но подвержено т. н. фантомному чтению.

Serializable — гарантия невмешательства в данные. Минус — время ожидания пользователя в очереди увеличивается.

Любые «игры» с описанными уровнями изоляции, к сожалению, наш код не спасали. Даже если мы выберем Serializable, следующая строка останется проблемным местом системы:

UPDATE Store SET amount = amount -1 WHERE isbn = ?

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

Более удачная реализация — уровень middle

Как можно было бы устранить проблему в коде? Мы оставляем сигнатуру транзакции, остальные три запроса остаются как есть, но мы добавляем одно волшебное ключевое слово (в синтаксисе MS SQL):

@Transactional
public void buyBooks(List<Book> books, Payment userPayment){
// Validate:
final String checkSql =
"SELECT 1 FROM Store WHERE isbn = ? AND amount > 1 FOR UPDATE";
// Modify business entities
final String insertPaymentSql =
"INSERT INTO Payment (amount, transaction) VALUES ...";
final String insertOrderSql =
"INSERT INTO BookOrder (payment, isbn) VALUES ...";
final String updateStoreSql =
"UPDATE Store SET amount = amount -1 WHERE isbn = ?";
}

Существует, похожий синтаксис для JPA спецификации:

em.find(isbn, LockMode.PESSIMISTIC_READ )

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

Анализируем дальше.

К сожалению, даже к этому коду есть множество претензий.

Рассмотрим процесс покупки поэтапно:

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

Зададимся вопросом, что в частности произойдет, если получение подтверждения банка займет более 40 секунд (время, установленное для обрыва транзакций в большинстве баз данных по умолчанию)?

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

Реализация уровня Senior

Что же может предложить для устранения этой проблемы «сеньор» или архитектор?

Здесь на сцену выходит поставляемая в базовом наборе Spring библиотека Spring Global Lock, позволяющая полностью решить нашу проблему. Как это будет выглядеть?

Autowired
private LockRegistry lockRegistry;
@Transactional
public void buyBooks2(List<Book> books, Payment userPayment){
    for(Book b: books){
        Lock lock = lockRegistry.obtain(b.getIsbn());
        lock.lock(); // lock.tryLock();
        try{
            doInsertAndUpdate(b);
        } catch (InterruptedException e1){
            //give up
            Thread.currentThread().interrupt();
        } finally{
            lock.unlock();
        } //try
    } //for
}

Есть некоторый класс LockRegistry — создадим его Autowired instance.

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

Покупка книги в данной по версии 2 будет выглядеть следующим образом:

• в виде JSON-файла приходит список книг, которые хочет купить пользователь, а также информация, достаточная для того, чтобы осуществить платеж;
• из LockRegistryполучаем всем известный java.util.concurrent.locks.Lock (стандартный интерфейс библиотеки Java), на котором устанавливается блокировка — можно использовать по желанию методы lockили tryLock;
• после этого добавляем классический код: try, catchи finally (finally гарантирует разблокировку по окончанию вне зависимости от ошибок);
• покупка книг происходит в стороннем методе doInsertAndUpdate.

Для любопытных приведу дополнительно пару зависимостей, как они выглядят в Maven:

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-integration</artifactId></dependency><dependency><groupId>org.springframework.integration</groupId><artifactId>spring-integration-core</artifactId></dependency>

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

Ключ getIsbn в коде позволит точечно заблокировать только необходимую книгу. Что именно вы используете в качестве ключа для Spring значения не имеет: можно указать глобальный идентификатор для блокировки всей системы либо точечный Isbn, блокирующий одну запись. Spring принимает любой Object, который и будет использован в качестве ключа.

Что под капотом

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

LockRegistry в базовой поставке библиотеки SpringLock имеет пять основных вариантов реализации:

1. PassThruLockRegistry.
2. GemfireLockRegistry.
3. RedisLockRegistry.
4. JdbcLockRegistry.
5. ZookeeperLockRegistry.

PassThruLockRegistryне делает вообще никакой блокировки — это пустая заглушка, применяется для тестирования.

GemfireLockRegistry — как и RedisLockRegistry — используют соответственно Gemfire и Redis базы для реализации глобальных блокировок.

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

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

Но даже наличие поля when не спасает нас от другой проблемы. Рассмотрим диаграмму, взятую из статьи Мартина Клепмана.

На изображении выше вы видите сервис блокировки и два клиента. Таблица Lock в данном случае реализует JdbcLockRegistry.

• Клиент 1 захватывает и удерживает блокировку в течение длительного времени (допустим, у этого клиента в какой-то момент включился Garbage Collector, который затормозил всю Java).
• Cервис блокировок отслеживает для нас наступление time-out при помощи поля when и отменяет блокировку. Пока все корректно.
• В игру вступает Клиент 2. Он забирает на себя блокировку, успешно завершает собственную бизнес-транзакцию.
• Тут Garbage Collector Клиента 1 заканчивает работу, и Клиент 1 точно так же благополучно записывает свои данные в базу.

И это полное фиаско. Все данные транзакции Клиента 2 были перетерты.

Для разрешения подобных ситуаций в JdbcLockRegistry добавляется целочисленное поле version.

Теперь картина выглядит так:

• На момент, когда происходит захват транзакции, Клиент 1 получает токен (в примере на картинке — 33).
• Вступает в работу Клиент 2. Он делает захват уже после обрыва блокировки, ему выдается токен 34, Клиент 2 записывает данные.
• Garbage Collector Клиента 1 просыпается, но когда Клиент 1 пытается произвести какие-то действия с базой, оказывается что устаревший токен 33, конфликтует с токеном 34. В результате Клиент 1 получает ошибку.

Такой код с полем when и version обеспечивает корректное бизнес-поведение в сложных распределенных сценариях.

Вернемся к рассмотренному ранее компактному рабочему коду:

public void buyBooks2(List<Book> books, Payment userPayment){
    for(Book b: books){
        Lock lock = lockRegistry.obtain(b.getIsbn());
        lock.lock(); // lock.tryLock();
        try{
            doInsertAndUpdate(b);
        } catch (InterruptedException e1){
            //give up
            Thread.currentThread().interrupt();
        } finally{
            lock.unlock();
        } //try
    } //for
}

Где здесь обработка экспирации? Каким образом Spring понимает, что отведенное время закончилось? В Spring ответственность за правила экспирации возложена на программиста (предусмотрена даже возможность ввести вечную блокировку). Можно указать явное описание, в течение какого времени данная блокировка должна быть отпущена. Мы вычеркиваем Autowired-код с простым lockRegistry и заменяем его на ExpirableLockRegistry. В этом случае при конфигурации lockRegistry программисту необходимо будет использовать более гибкий подход, создав Scheduler: в нашем примере это fixedDelay, равный 50 секундам, и метод, который очищает все существующие в системе блокировки, превысившие время ожидания — expireUnusedOlderThan (также с указанием 50 000 миллисекунд).

@Autowired
private LockRegistry lockRegistry;
@Autowired
private ExpirableLockRegistry lockRegistry;
@Scheduled(fixedDelay=50000)
public void cleanObsolete(){
    lockRegistry.expireUnusedOlderThan(50000);//that are not currently locked
}

Теперь давайте уделим еще немного внимания реализации ZookeeperLockRegistry .

Apache Zookeeper — иерархическое распределенное хранилище информации. Это не база данных, но может использоваться в качестве базы (хотя это и не совсем удобно). Zookeeper активно используется при реализации крупных распределенных систем, и, например, широкоизвестная Apache Kafka, хранит в нем такие важные для себя настройки как:

• список разрешенных пользователей;
• кто выступает лидером;
• какой уровень избыточности и пр.

Информация в Zookeeper организована в виде дерева, в узлах которого могут храниться какие-либо данные. Zookeeper — практически «неубиваемая» система, которая поднимает несколько экземпляров, для обеспечения требуемого уровень репликации информации. В терминах CAP-теоремы Zookeeper — это типичная СР-система (Consistency — Partition Tolerance): хорошо распределяется в сети и гарантирует, что информация будет надежно сохранена.

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

Как еще можно использовать Spring Global Lock

Современные распределенные системы постоянно вынуждены решать одну и ту же задачу — «договориться» между собой, кто из них лидер. Это необходимо при проектировании микросервисов, создании fault-tolerant или high-available кластеров и прочих подобных задачах.
Расскажу об алгоритме Algorithm of Leader Election, который работает в нескольких компонентах Spring Cloud (более подробно можно прочитать в Spring Cloud Release Notes).

Реализация алгоритма спрятана в компоненте LockRegistryLeaderInitiator.

Эта компонента:

• Использует глобальную блокировку с обработкой time-out.
• Допускает существование только одного лидера.
• Допускается отсутствие лидера в течение коротких промежутков времени.

Один из примеров применения Algorithm of Leader Election — Zookeeper (написанное на чистой Java без использования Spring). Zookeeper не использует Spring Lock, но с идеей Spring Lock мы можем порассуждать, каким образом реализовывать механизм leader election.

В более простых приложениях роли явные прописываются администратором системы. Например, вы организуете транзакцию в схеме Master-Slave. Данные распространяются от Master к Slave по явно прописанным правилам, кто Master, а кто Slave.

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

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

Почему Zookeeper является именно СР, а не АР-системой? Именно потому, что на момент блокировки мы делаем временно всю систему недоступной. Система глобальной блокировки гарантирует, что если во время выбора какой-либо экземпляр прекратил работу, блокировка со временем будет снята и другой лидер выдвинет себя в качестве главного. Минус такого подхода — на какое-то время (время захвата Global Lock или восстановления по time-out) система может оказаться недоступной.

Подведем итоги

Плюсы

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

Минусы

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

Если вам интересно развитие в Java-направлении, рекомендую также посмотреть материалы GlobalLogic Kharkiv Java Conference 2018.

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

Разработчик Сергей Савченкоработает в харьковской компании Jabil Software Services, а в свободное время занимается косплеем — шьет костюмы культовых персонажей и затем воплощает эти образы на фестивалях. Он уже побывал Джокером, Зверем из «Людей Х», Чудовищем из диснеевского мультфильма — и не только.

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

— Сергей, как вы увлеклись косплеем? С чего все началось?

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

И вот как-то одна из подруг предложила взять участие в аматорской театральной постановке на 5-15минут на крупном харьковском косплей-фестивале «Ханифест». Это был 2016 год, мероприятие проходило в клубе «Радмир». Недолго думая, я согласился. Это обещало быть занятным приключением.

— Каким был ваш первый персонаж? Почему именно этот образ?

Первым персонажем, сделанным мною, был Джокер Хита Леджера. Этот образ был нужен ребятам для сценки, так что выбора я особо не имел.

— Костюм делали сами?

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

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

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

Джокер из фильма «Темный рыцарь» («Ханифест», 2016)

— А как делаете костюмы сейчас? Как придумываете образ, где ищете материалы?

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

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

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

Также для пошива костюмов иногда требуются дополнительные аксессуары — например, мечи, посохи и прочая нетривиальная бижутерия. Эти вещи, или крафт, как мы их называем, ищу в строительных магазинах и барахолках. К примеру, из материалов может пригодится Eva Foam, дерево, трубы из ПВХ — все, что покажется юзабельным в создании. Где что найдете, то и ваше. Ну и штурмую художественные магазины в поисках красок, кисточек и так далее.

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

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

— Какие самые интересные образы составляли?

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

Также был интересен и приятен образ Чудовища из диснеевского «Красавицы и Чудовище». И к этому персонажу люди отнеслись с огромным теплом.

Чудовище («Ханифест», 2017)

А наиболее успешным считаю Хоука (Hawke) из вселенной Dragon Age. Основу костюма я купил у человека, который уже дедал и вывозил на фестиваль этого персонажа. Многое в костюме меня не устроило, и я занялся крупным рефакторигом, допиливанием и перепиливанием. По сути, остались лишь самые сложные части, которые были в наиболее удовлетворительном состоянии. Но даже их коснулась кисточка.

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

— Сколько времени уходит на один костюм?

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

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

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

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

Сейчас весело вспоминать такие моменты, но за ночь до фестиваля это все достаточно стрессово.

Костюмы все сложные, каждый по-своему. Могу лишь сказать: проверяйте вещи, которые заказываете у швей или крафтеров. Тщательно! Так как на фестивале это может доставить массу неудобств.

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

Слева: Акира Отоиши из аниме «Невероятные приключения ДжоДжо» («Ханифест», 2018)Справа: образ гопника из Харькова для сценки («Ханифест», 2018)

— А насколько дорого обходится один образ? На что идет основная часть трат?

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

Самый дорогой мой костюм и он же самый качественный — это Hawke из Dragon Age. Сама основа обошлась где-то в 5-6 тыс.грн. Вместе с расходниками на доделывание-переделывание и новыми частями образ обошелся примерно в 12 тыс. грн.

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

Цены на материалы очень разнятся и зависят от качества и места продажи. Если готовы рисковать и ждать, AliExpress — ваше все. Если нет, придется немного раскошелиться. Мои парики стоили около 600 грн за штуку. Все они неплохого качества, но это лишь основа, похожая на необходимый образ. Достригать и укладывать прическу необходимо было самим. Боюсь представить, сколько отдают мастерам некоторые ребята, у которых в образах большие и сложно уложенные парики.

— Насколько в Украине развито сообщество косплейщиков? Какие есть фестивали, мероприятия?

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

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

В Киеве проходит Comic Con Киев. В этом году прошел первый Comic Con Украина — это было великолепно: масштабно и просто незабываемо.

В Одессе есть Fan Expo, в Днепре — «Акихабара», во Львове — Anicon. И еще хочу отметить маленький провинциальный фестиваль Pokemon Fest, который прошел в городе Первомайский Харьковской области. Он состоялся впервые, но по уровню организации может дать фору некоторым крупным фестивалям из больших городов.

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

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

— С чего начать новичку, который хочет заняться косплеем? Что можете посоветовать начинающим?

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

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

И еще — не стоит с наскоку брать очень сложные костюмы. Лучше начинать потихоньку, с относительно простых. Кстати, одни и те же костюмы можно выгуливать костюмы не на одном фестивале.

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

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

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

Слева: Hawke из вселенной Dragon Age 2 (ComicCon Украина, 2018)В центре: Итати Утиха из аниме «Наруто» (Pokemon Fest, 2018)
Справа: Джокер из фильма «Темный рыцарь» («Ночь Супергероев» в клубе Plazma, 2016)

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

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

— Какие у вас планы на будущее? Какие образы готовите на следующие фестивали?

Планов на будущее много. Как минимум сделать что-то масштабное по Dragon Age — или сценку, или дефиле, или вообще стенд. Но это пока в подвешенном состоянии.

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

Если кому интересно следить за нашим творчеством: косбенд «Oh, my Bets!»всегда рад стараться радовать людей своими образами и сценками!

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

Такая мечта нашей управленческой команды сбылась. За последний год мы агрессивно выросли (почти в 10 раз), о чем и хочется рассказать, поделиться накопившимися уроками и опытом. Приведенный ниже кейс описывает инструменты и практики масштабирования, примененные в команде при росте с 10 до 60 разработчиков за полгода, которые помогли всему аккаунту «прыгнуть» с 30 до 250 человек.

Онбординг

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

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

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

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

Как выглядит онбординг:

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

Что мы получили после внедрения этой структуры:

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

Переосмыслить проект в целом

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

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

Выделить новые роли

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

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

Для этого создали роль Group Lead. Это разработчик не ниже Intermediate или Senior уровня, уже обладающий доменной экспертизой, с командой около пяти программистов: с таким количеством людей он/она могут валидировать задачи, уделяя внимание каждому. Также мы переосмыслили роль тимлида: для команды из 60 человек у нас их стало трое, каждый в своей экспертной области:

• Тимлид по техническим вопросам, ответственный за R&D и фундаментальные технические вопросы.
• Тимлид по бизнес-интересам и технологическому развитию — отвечает за взаимодействие «бизнес — команда разработки», валидирует требования.
• Тимлид, отвечающий за процессы разработки — их имплементацию и контроль.

Тот же маневр проделали и с командой менеджмента. Выделили Project Managers, которые непосредственно работают с командой, Project Coordinators и Resource Coordinators, которые всегда готовы прийти на помощь. Это позволило разграничить зоны ответственности внутри аккаунта, обозначить сферы влияния от ежедневного распределения ресурсов до стратегического планирования.

Новый взгляд на сам процесс разработки

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

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

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

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

Поднажали на усовершенствование CI/CD практик, инвестировали в тестирование и инфраструктуру:

• Пересмотрели подход и фреймворк для unit-тестирования.
• Прокачали инфраструктуру, стали выполнять пакет тестирования не на каждый билд, а на каждый пулл-реквест, с автоматическим запретом мержа в случае ошибок. Конечно, стоило ввести это с самого начала, чего мы не сделали, но вынесли урок, который будем применять на других проектах.
• Внедрили SSA (system stability assurance) процесс, который по своей сути содержит набор интеграционных тестов и событий, регулирующих их запуск. Этот подход призван сместить фокус автоматического тестирования с отдельных юнитов в сторону бизнес-сценариев, что позволит ускорить поставки и быть уверенным в их качестве. Говорят, когда Титаник тонул, у него из трубы все еще шел дым и в рубке горел свет — вот такие false-positive результаты тестирования мы и устраняем.

Пересмотрели подход к ревью кода. Перешли от модели «Пулл-реквесты проверяют лиды» на «Пулл-реквесты проверяют носители компетенции в целевом компоненте». Это означает, что большее количество специалистов взяли на себя ответственность за процесс. Мы выявили техэкспертов по компонентам и разгрузили лидов — децентрализовали принятие решения. В перспективе движемся к формированию SME (subject matter experts) по каждому из компонентов системы и специализации отдельных команд.

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

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

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

Вывод

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

Также к заслугам отнесем и то, что все процессы, которые мы внедряли для команды из 60 человек, успешно работают для 250 человек на стороне Dev-Pro и для 400 специалистов на стороне клиента. Более того, наша команда позитивно влияет и на работу других вендоров заказчика.

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

Всем привет! Меня зовут Стас, и я работаю на позиции Cloud Solutions Architect. Мне часто приходится инициировать старт проектов. При этом важно выбрать средства обеспечения жизненного цикла решения. Необходимо решить, какие именно средства команда будет использовать для создания, поддержки и развития решения.

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

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

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

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

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

Основные понятия

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

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

Категории средств

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

Размещение

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

Рассмотрим следующие варианты размещения:

Размещение на стороне исполнителя (on-prem)

Плюс:

• Некоторые инструменты могут быть уже развёрнуты и настроены.

Минусы:

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

Размещение на стороне заказчика (on-prem)

Плюсы:

• Нет необходимости передавать артефакты.
• Клиент сам платит за лицензии.

Минусы:

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

Размещение на третьей стороне (service)

Плюс:

• Все артефакты принадлежат клиенту через договор оказания услуг с третьей стороной.

Минус:

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

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

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

Средства

Есть два варианта получения набора средств:

• собрать из разных инструментов от разных поставщиков.
• использовать решение от одного поставщика.

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

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

• Option A — на основе сервисов и продуктов компании Atlassian, иногда упоминается как Atlassian Stack. На самом деле чаще всего используется максимум 3 продукта от Atlassian.
• Option M — на базе сервисов и продуктов Microsoft, в основе которого лежит пакет облачных сервисов Azure DevOps. До недавнего времени являлся одним продуктом Visual Studio Team Services. Имеет версию, доступную on-prem.

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

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

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

Некоторые Area не описаны, это сделано с целью упрощения. Потому как выбор тех же Communication средств — это тема ещё одной статьи.

Сравнение вариантов

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

Сравнение систем по функциональности систем здесь не проводим, ибо в целом системы +/- обладают одинаковой функциональностью и, например, сравнение Jira с Boards — это также отдельная тема.

Если ваш проект в регулируемом домене, например Healthcare, то желательно, чтобы абсолютно все сервисы, которые вы используете, соответствовали требованиям, специфичным в этом домене. Например, если ваш проект в домене Healthcare и территориально в USA, то вам лучше использовать только HIPAA Compliant средства.

Сценарии использования

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

• Stakeholders работают только с требованиями.
• Все члены команды как минимум имеют доступ к системе тестирования для просмотра планов, кейсов и результатов.
• Стоимость Pipeline Agents, Load Tests не включены.
• Стоимость Option M может быть уменьшена, если члены команды имеют Visual Studio Subscription.

Scenario 1 Команда малого размера: 3 stakeholders, 5 developers, 1 tester.

Scenario 2 Команда среднего размера: 5 stakeholders, 20 developers, 5 testers.

Заключение

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

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

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

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

Заработная плата

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

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

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

Карьерный рост

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

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

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

• количеством сотрудников в вашем подразделении;
• вашими полномочиями;
• какие ожидания от вас как руководителя;
• почему позиция руководителя вакантна.

Руководство

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

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

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

И в тоже время руководитель и есть «Редиска». Именно он заставляет работать, иногда делает взбучку, и самое неприятное — увольняет сотрудников.

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

Невозможность саморазвития

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

Вас, извините, закатали в 3-литровуюбанку, как овощ? Как вам мешают развиваться? Большинство ИТ-компаний перепродают ваш труд или трудочасы, и они имеют право вам ставить задачи на 8 часов в день, и вы при приеме на работу соглашаетесь на это — так или нет?

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

Расскажу по своему опыту. Довольно долгое время я работал в банках на позиции бизнес-аналитика. И это не мешало мне заниматься саморазвитием: мне никто не запрещал читать BABOK, PMBOK, посещать разнообразные митапы и курсы. Именно работая в банке, с целью обмена опытом и саморазвитием, я создал группу в ФБ — IT Network — Business Analysis & Project Management (для любителей статистики там есть опрос). При помощи группы я познакомился с чудесными людьми, профессионалами своего дела, которые помогли мне развиваться и достигать новых карьерных высот. Не ищите причины — ищите возможности!

Профессиональное выгорание

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

Причины моего профессионального выгорания:

• рутина;
• работа на износ.

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

Работа на износ — думаю, многие читатели сталкивались с этим. Моя проблема крылась во мне:

• Неумение делегирования. С ростом моей должности росло и количество задач, и сцепив зубы, я начал выполнять практически все задачи сам, работая по 12-16часов в день. При этом команда аналитиков спокойно отсиживала 8 часов и уходила домой. Я ничего не успевал делать, я злился и, как свеча, медленно сгорал. Спасибо моему менеджеру. Он мне рассказал о том, как правильно планировать и распределять задачи, как работать с приоритетами... Как говорит мой друг: «Работать нужно головой, а не 12 часов».
• Неумение отказать. Каждый должен оценивать свои силы и говорить друзьям, коллегам, руководителям волшебное слово — нет. Не набирайтесь задач. Самостоятельно вы все задачи не выполните. Оценивайте свои силы. Только вы сами можете сказать, сможете сделать поставленную задачу или нет. При отказе не скупитесь на аргументацию, отказ принимать также сложно.
• Мультизадачность. У меня часто бывали ситуации, когда задач слишком много, и приходится переключаться с задачи на задачу. Что делать? Все довольно просто: выставить приоритеты и не соблазняться на переключение между задачами. Именно последовательное выполнение задач увеличит вашу эффективность. Если передо мной стоит важная и срочная задача, я отключаю все раздражители: социальные сети, почту, иногда даже телефон и выполняю эту задачу.

Как понять, в чем ваша проблема? Поделюсь своим лайфхаком. При получении новой лычки на мои погоны (Head of PMO) у меня эффективность очень сильно снизилась. Я работал все больше и больше, а результата не было, и это очень сильно меня огорчало. Мне посоветовали сделать одно упражнение. На протяжении двух недель я начал записывать ежеминутно, чем занимаюсь на работе, включая прочтение интересных статей, переписку в ФБ или в скайпе, перерывы на обед, разговоры по телефону и так далее. После этого провел анализ. Результатом был поражен. Анализ показал, что больше всего времени я трачу на консультации сотрудников. Но это моя святая обязанность — консультировать коллег, ею я не мог жертвовать.

По результатам анализа мне удалось найти закономерность: меньше всего меня отвлекают в период с 9:00 до 10:30, с 12:30 до 14:30. Это были самые продуктивные часы. Посоветовавшись с моим руководителем, я попросил его изменить мой график и работать с 8:00 до 17:00. А обед — с 12:00 до 12:30. Теперь у меня появился еще 1 час для продуктивной работы. Кажется, всего час, а для меня это еще целый час, когда меня никто не отвлекает. Также взял за правило не заходить в соцсети на протяжении рабочего дня, это еще экономит мне до 30 мин в день.

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

Атмосфера в коллективе

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

Расскажу историю, которая приключилась со мной в 2009 году. В то время я устроился на новое место работы и незадолго до этого открыл для себя новый метод управления проектами — Scrum. Проникшись глубиной методологии, начал нести с собой плакат: «Даешь гибкость в разработке!».

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

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

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

А какие по вашему мнению весомые причины для смены работы?

Image by Tea Wetyšková

Привет! Я Research & Development Lead в Intellectsoft AR Lab. Мы разрабатываем решения под Microsoft HoloLens в сфере строительства. В этой статье я рассмотрю плюсы и минусы очков Magic Leap, которые вышли недавно.

Появление Magic Leap очков техноэнтузиасты ждали семь долгих лет. Уже с первого тизера, создатели обещали пользователям впечатляющий AR/VR опыт, который может быть применен в самых разных сферах — от развлечений до комплексных решений бизнеса. Выпуск откладывался несколько раз, и в итоге 8 августа 2018 года состоялся долгожданный релиз очков Magic Leap, которые на тот момент можно было купить всего в нескольких городах СШA.

До выхода Magic Leap, мы в Intellectsoft AR Labработали с решениями в дополненной реальности для строительной индустрии, выпустив MEP Layout демо для Microsoft HoloLens под названием KADO. Наконец, у нас появилась возможность испытать новое и долгожданное устройство.

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

Предлагаем рассмотреть все плюсы и минусы в нашем детальном обзоре Magic Leap.

Преимущества

1. Поле обзора Magic Leap больше, чем у очков Microsoft HoloLens

С первого взгляда заметно, что активная область Magic Leap больше, чем у Microsoft HoloLens — единственного устройства, близкого к ним по возможностям. Это важное преимущество. Большее поле обзора Magic Leap позволяет охватить большее пространство меньшим движением головы, что упрощает процесс адаптации для новых пользователей. Малое поле обзора у Microsoft HoloLens считают критическим недостатком многие пользователи устройства. По их мнению, это делает технологию не очень подходящей для широкого использования. Команда создателей Magic Leap приняла это во внимание.

2. Небольшой вес очков

Еще одно преимущество Magic Leap — вес. Очки почти в два раза легче, чем Microsoft HoloLens: 345 грамм против 579 грамм. Это позволяет дольше работать с AR-очками, например, для дизайна или 3D-моделирования.

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

Очки Magic Leap работают на чипе NVidia Tegra X2 с интегрированным 256-ядернымграфическим процессором NVidia Pascal, 6-ядернымпроцессором ARMv8 с 64-битнымпроцессором, и 8 ГБ памяти LPDDR4 с 128-битныминтерфейсом. Половина памяти (4 ГБ) будет доступна для приложений разработчика. Емкость памяти составляет 128 ГБ, для разработчиков доступно — 95 ГБ.

Все это инкапсулируется в отдельное устройство под названием Lightpack, которое пользователь должен носить с очками. Устройство небольшое и легко крепится к карману.

Такая комплектация — еще одно существенное преимущество, так как позволяет разработчикам работать с крупными и более сложными 3D-моделями.

4. Технология Magic Leap поддерживает разработку на macOS

Разработчики, работающие на Mac, будут очень рады: Magic Leap поддерживает разработку на macOS, а их творческие усилия в области AR, больше не будут ограничены исключительно Windows.

Недостатки

1. Наличие двух размеров очков усложняет покупку, разработку и тестирование

Нашу пару очков Magic Leap привез к нам в офис курьер службы доставок Enjoy. При заказе нам сообщили, что нужно выбрать между двумя доступными размерами — они так и назывались: «Размер 1» и «Размер 2». В чем же разница? Выбор будет зависеть от вашего межзрачкового расстояния. Мы провели необходимые замеры и определили, что троим из четверых членов команды подходил «Размер 2». На нем мы и остановили наш выбор. Тем более, как мне известно, этот размер должен подходить порядка 30% пользователей.

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

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

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

Вдобавок к этому, очки Magic Leap поставляются с 5-юразличными размерами носоупоров (носовых фиксирующих колодок), и я часто сам перепрыгиваю между размерами 2, 3, 4 и 5 после того, как передавал очки кому-то другому. Опять же, это добавляет сложности при использовании. Это приемлемо, если вы используете Magic Leap в качестве индивидуального устройства, но неудобно для работы и тестировании в команде.

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

Во время тестирования Magic Leap я заметил больше визуального дрожания, чем у HoloLens. Пространственное согласование также не работает должным образом. Каждый раз, когда я запускаю Magic Leap после перезагрузки, они не могут распознать уже знакомое пространство. Эта проблема сохраняется, как в случае с многофункциональными поверхностями, так и на больших пространственных расстояниях, независимо от усилий, которые вы приложили. Следовательно, одновременная локализация и построение карты (SLAM) затруднительно. Это проблема с софтом, и я надеюсь, что разработчики уже работают над ее устранением.

4. Ограниченное использование «мэша» комнаты

Очки Magic Leap имеют все необходимое для выполнения постоянного сканирования комнаты. Однако я обнаружил, что операционная система Lumin OS не использует это активно для системных интерфейсов. Вы можете увидеть, как системное меню проходит сквозь стены, или вы можете расположить экраны приложений за стеной или сквозь пол. На мой взгляд, пространственный компьютерный интерфейс должен знать об окружающей среде пользователя и последовательно объединять физические и цифровые миры. Я полагаю, что этот процесс слишком вычислительно затратный, и разработчики решили его оптимизировать в данном релизе, а позже добавить больше функций, которые будут распознавать пространства.

5. Навигация трекпада контроллера не очень удобная

Я был удивлен, что пользовательский интерфейс Magic Leap не предполагает использование жестов или контроля взгляда вообще. Вместо этого компания реализовала навигацию на основе трекпада. Вам нужно провести по трекпаду контроллера большим пальцем, чтобы переместить фокус между элементами пользовательского интерфейса. Я думаю, что навигационная система, основанная на жестах, которую мы видели в гарнитурах VR, таких как Oculus Go и Google Daydream, была бы более подходящей и удобной на предприятии и в целом. Подход, основанный на направлении взгляда, как в Microsoft HoloLens, также лучше подходит для интерфейсной навигации и ввода текста. Наше тестирование Magic Leap проходило в относительно просторном офисе, но использование контроллера в более узких пространствах, например, на строительных площадках, будет неудобным.

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

6. Голосовой интерфейс и навигация используются недостаточно

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

7. Выключение очков и отсутствие режима сна

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

8. Нет простого способа носить очки Magic Leap с собой

Почти любой современный гаджет помещается в обычный рюкзак и не нуждается в особой защите, но это не относится к Magic Leap. Устройство хрупкое, плюс вы не сможете отключить компьютер Lightpack от него. Кроме того, вам нужно дополнительное место для носоупоров, зарядного устройства и контроллера. Кажется, понадобится отдельная коробка для того, чтобы носить все это, если вы не хотите разбить устройство по пути на важную встречу.

9. Очки Magic Leap не подходят для ношения сверху очков для зрения

Большинство членов нашей команды носят очки для коррекции зрения. И для того, чтобы комфортно использовать Magic Leap, нам нужно каждый раз переходить на контактные линзы. Я также попробовал использовать устройство во время ношения своих очков, и мой опыт взаимодействия был значительно хуже.

10. Чрезмерное нагревание — основной недостаток

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

Выводы

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

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

Для наших корпоративных клиентов Magic Leap дает возможность экспериментировать с более крупными BIM моделями (Building Information Modeling) в сферах производства и строительства. Сфера образования и сфера развлечений — это те индустрии, где я также вижу возможность подтвердить работоспособность концепции и протестировать устройство на реальных приложениях.

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

Понравился наш обзор гарнитуры Magic Leap? Напишите свои вопросы в комментариях или прямую в Intellectsoft AR Lab.

Привет, меня зовут Сергей. Уже больше 8 лет я работаю в сфере разработки программного обеспечения, последние 3 года — с Go. Вы, наверное, удивлены, что этот выпуск пишу я, а не Женя Пилипенко. Не волнуйтесь, Женя никуда не пропадает, и дайджесты мы будем выпускать совместно.

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

Яркие события в Go community за 2018 год

Релиз Go 1.10, который принес кучу оптимизаций:

• пост в оффициальном блоге;
• релиз-ноутсы.

VGO — инструмент для управления зависимостями, предложенный Рассом Коксом. Эта тема гремела очень долго:

• пост в оффициальном блоге;
• ряд статейс детальным описанием дизайна;
• огромный тред в Twitterс холиваром Расса Кокса и Сэма Бойера (автор dep);
• в итоге предложение Расса приняли.

Релиз Go 1.11, который принес Go modules и поддержку WebAssembly:

• пост в оффициальном блоге;
• релиз ноутсы;
• очень крутое выступлениеБреда Фитцпатрика про Go 1.11;
• слайды от Валялкинас разбором патчей, нацеленных на улучшение производительности.

Go 2 Draft Designs — Расс Кокс представил первые драфты дизайна Go 2, которые нацелены на хендлинг ошибок, дженерики:

• пост в оффициальном блоге;
• драфты;
• замечательное выступление Роба Пайкана эту тему.

Стоит также отметить новый брендинг языка.

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

Итоги

2018-йбыл несомненно крутым годом для Go и его сообщества. Согласно Stack Overflow’s 2018 Developer Survey, язык попадает в топ-5 по уровню удовлетворенности, а также по уровню востребованности. Этот факт подтверждает и ActiveState’s 2018 Developer Survey.

Опрос JetBrains’s 2018 Developer Surveyпоказывает, что программисты, которые сейчас пишут на других языках, все больше интересуются Go. Это подтверждают и 38% респондентов HackerRank’s 2018 Developer Survey, которые выбирают Go как следующий язык для изучения.

В этом году мне удалось посетить GopherCon Iceland, и больше трети слушателей там, работают с Go первый год. Количество новых программистов растет с каждым днем.

Взгляд в будущее

Новый процес подачи пропозиций для внесения изменений в Go.

Планы по улучшению Go modules на 2019.

Новости

Релиз Go 1.12 Beta 1

Релиз Go 1.11.3 and Go 1.10.6 — фиксы безопасности

Релиз Go 1.11.4 and Go 1.10.7 — с мелким фиксами для 1.11.3 и 1.10.6

Читаем

Distributed Tracing Using Jaeger — распределенный трейскинг а Jaeger от Uber

Future of GopherJS and Go in the browser — GopherJS, WASM, и взгляд в будущее.

String interning in Go — хитрости со строками.

Animated QR data transfer with Gomobile and Gopherjs — невероятный Ваня Данилюк и его магия c анимированными QR кодами.

Go and Apache Arrow: building blocks for data science

Apache Beam and Google Dataflow in Go

The Relationship Between Interfaces and Reflection

Building a Chat Application in Go with ReactJS — немного фулстек магии

Validating Kubernetes Manifests — валидируем Кубер манифеста с помощью Go

Batch get from Golang’s buffered channel — забираем пачками из буферизированного канала

Migrating to go mod in just 3 steps — мигрируем на Go mod быстро и без слез

Building real-time messaging server in Go

Go Concurrency Design Patterns — Generator

Using Golang to Build Microservices at The Economist: A Retrospective — как престижное издание фигачит микросервисы

Errors in Go: From denial to acceptance — про хендлинг ошибок, снова.

Load balancer at your fingertips — пишем свой балансер на Go.

Build a DNS server in Go — пишем DNS сервер (балансера видать было мало)

Postmortem debugging Go services with Delve — вскрытие показало: пациент спал.

Sending big file with minimal memory in Go — меньше памяти, больше денег в кармане :)

Develop your 1st blockchain program in Go — рынок крипты стремительно падает, а решений на базе блокчейн становится все больше. Давайте смотреть, как с этим всем работать.

GoLang Templating Made Easy — как работать с шаблонизатором в Go.

Creating WebGL apps with Go

Смотрим

Учимся писать спрайтыв новом эпизоде Go after Dark.

Все про production ready микросервисыот ребят из Go-Jek.

The Scheduler Saga — очаровательная Kavya Joshi о скедулере Go.

Becoming a Go Contributor — контрибьютить просто.

justforfunc #42: Intro to Go Modules and SemVer — Францеск про Go modules часть 1

justforfunc #43: Migrating Go Modules to v2+ — Францеск про Go modules часть 2

Щупаем

Авто Lets Encryptдля ваших приложений.

А вы знаете, сколько весит ваш struct?

Отличная обвязкана HashiCorp Vault.

Вызываем Swift-код из Go.

Простая библиотекадля форматирования текста таблицами.

Автоматическое профилирование c pprof от JBD.

Супер быстрая БДдля структур Go.

Запускаем Pythonвнутри Go.

Оркестратордля service mesh (что-о-о?)

Библиотека для cliот Питера Боргома

Также я веду канал в Telegramоб интересном в мире Golang. Подписывайтесь!

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

У випуску: Python отримує нову модель „уряду”, AWS Lambda підтримує Python 3.7, PyCharm 2018.3.

Новини

Super Potato Bruh, написана на Pygame, доступна в Steam. Сорси доступні тут.

Red Hat Linux 8.0 Beta реліз замінюєдефолтний Python 2.7 на Python 3.6.

Python стаєофіційною мовою програмування для навчання у Франції.

Funding for 64-bit Armv8-a support in PyPy — PyPy отримує кошти на підтримку 64-bit Armv8-a.

AWS Lambda Supports Python 3.7 — AWS додає підтримку 3.7 до Lambda.

Advent of Code 2018 is now online — різдвяний календар задачок розпочато!

Python gets a new governance model — розбір нової моделі управління Python.

Python governance vote (December 2018): Results.

Нові релізи

Qt for Python 5.12 Released

PyCharm 2018.3 — тайм-трекінг, можливість зберігати термінали, підтримка Cassandra та інше.

Bokeh 1.0

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

Camelot — парсінг таблиць з PDF-файлів.

Dampr — Pure Python Data Processing.

Molten — фреймворк для побудови HTTP API, в стилі rocket.

Video-to-ascii — програвач відео в терміналі за допомогою ASCII символів.

Loguru — Python logging made (stupidly) simple.

WordRPG — текстова RPG, написана на Python.

Python port scanner in asyncio.

Thonny: The Beginner-Friendly Python Editor.

pyAudioClassification — класифікація аудіо на базі Keras & TensorFlow.

PEP’s

PEP 8016 — The Steering Council Model — нова модель правління Python.

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

Explaining the Python global interpreter lock — ще один раз про GIL.

Top 50 matplotlib Visualizations for Data Analysis — The Master Plots — підбірка для дата аналізу та візуалізації з прикладами коду.

Moving over to Go has made it painfully apparent how spoiled Python devs are to have the Requests library — про біль без requests і подібних бібліотек в Go.

50 Free Machine Learning Datasets: Natural Language Processing — набір датасетів від Cambridge Spark.

Using dice to recreate a picture — моделювання зображень з гральних кубиків.

Python at Microsoft: flying under the radar — від синдрому „винайдено не нами”до підтримки Python в Visual Studuio/Visual Studio Code та наймання core розробників у Microsoft.

Fixing a Tough Memory Leak In Python — як знайти витік пам’яті в Python-коді.

Dependency Injection in Python: The Java Guy’s Perspective

Profiling Python applications using Pyflame — профілювання коду з Pyflame на основі системного виклику ptrace.

Pipenv: promises a lot, delivers very little.

The Rise of Python for Embedded Systems Continues — стан Python в embedded-системах від Zerynth.

Відео

Python pet detector — розпізнавання котів з Raspberry та Python.

MIT AI: Python (Guido van Rossum) — доповідь Гвідо на MIT:AI.

How To Install Python and Set It Up With Visual Studio Code.

The entire MIT Intro Computer Science class using Python is available for free, with course materials — відео з популярного курсу MIT 6.000.

Туторіали

Як побудувати Alexa аплікації з Python.

Build A Simple Live Flight Tracking in Python — трекінг та візуалізація польотів літаків з matplotlib.

Continuous Integration With Python: An Introduction.

Designing Well-Structured REST APIs with Flask-RestPlus: Part 1.

Bash completion with Python — написання bash автодоповнень на Python.

A complete tutorial on data visualization with Python using Matplotlib.

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

Всем привет, меня зовут Саша Емельянов. Полтора года я работал в MacPaw, а сейчас переехал жить и работать в Лондон. Теперь я Revenue Product Manager в крупнейшем дейтинг-приложении в мире — Badoo.

В этом выпуске: как подходить к созданию UX-продукта, выводы из истории Netflix, подкаст об UX Research, как согласовывать продукт и маркетинг.

Почитать

С переходом в лондонский Badoo я столкнулся с огромным количеством данных и сотнями A/B тестов (может, не как у Booking.com, но тоже прилично). В своем ресерче наткнулся на очень неплохой цикл статей об A/B тестировании в Twitter, которые и хочу представить вашему вниманию:

Как A/B тестирование помогает Twitter делать инновации

Технический обзор экспериментов Twitter

Определение размера выборки в A/B тестах

Использование нескольких контрольных групп в A/B тесте

Мой коллега по Badoo Toby Wilkins ведет свой блог, в котором немного рассказал о том, какими принципами мы руководствуемся, проводя продуктовые эксперименты.

Разбавим теорию историей о том, как Netflix в далекие 2000-е 6 лет безуспешно пытался добавить социальную составляющую в продукт, но закрыл фичу. Сама история не выглядит впечатляющей, но из нее сделаны хорошие выводы. Какие? Читаем в статье Gibson Biddle, бывшего CPO Netflix.

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

Если у вас вдруг SaaS-стартап (а у кого сейчас его нет), вам пригодятся 9 советов от ребят из Intercomо том, как при прийти к успеху (спойлер — у них получилось).

Послушать

Julien Codorniou из Facebook рассказывает о том, как и зачем превращать компании в комьюнити.

К счастью, Product Market Fit хайпспадает (и это хорошо) но Dan Olsen в конце 2018 года еще раз рассказывает нам о том, как его искать. Еще раз можно послушать.

Подкаст об UX Researchи о том, кто его должен делать. Краткий пересказ — PMs should be doing research.

Посмотреть

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

Matt Hodges из Intercom рассказывает о том, как согласовывать продукт и маркетинг.

Отец UX Дон Норман в своем коротком видео рассказывает о том, как подходить к созданию UX-продукта. Ключевая фраза, которую я надолго запомню: «У меня 50 лет опыта и PhD в психологии. Но я всегда неправ».

Спасибо, что дочитали до конца. Увидимся через месяц!

P. S. Весной я довольно случайно создал канал с работой в Телеграм Wanna Work, а сейчас это крупнейшая украинская телеграм-площадка с топовыми IT-вакансиями напрямую от рекрутеров. И конечно же, есть вакансии продактов :) Увидимся там!

← Предыдущий выпуск: Product Management дайджест #5

Всем привет! Меня зовут Антон, я DevOps-инженер в MacPaw, экс-сотрудник Swiftype (an Elastic company), Grammarly, Bigmir.net. За 10 лет в ИТ я успел побывать в мире VoIP-хаоса, FreeBSD-сект, тимлидства, MacOS-разработки (со стороны DevOps), стандартного веба. Минимум половину своей карьеры мне приходилось собеседовать людей, поэтому с опытом я выработал для себя некие правила и чекпоинты, которыми и хотел бы сегодня с вами поделиться.

Статья будет полезна техническим специалистам, которые проводят интервью в стиле «как карта ляжет» или понадеявшись на импровизацию. Особенно для тех, кто проводит интервью на роли DevOps/SRE Engineer, преимущественно для уровней middle, senior, TL.

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

Сломанный процесс

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

Что такое inode? Разница между Apache и Nginx? Что произойдет, если я нажму Tab-Tab? Как часто, будучи в роли кандидата, вы слышали подобные вопросы? И как часто вы делали мысленный фейспалм на них? Высока вероятность, что ваш собеседник просто загуглил список вопросов «Linux System Administrator/DevOps Interview Questions», который вы даже когда-то скролили, попивая пивко вечером, но вряд ли запомнили все ответы. В итоге проверили вашу память, и, в лучшем случае, немного знаний.

Что делать, если вы собеседующий

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

Не надо так

Это очень важный блок! Перечитайте его дважды, даже, если вы не относитесь к DevOps. Не нужно спрашивать:

• Как бы кандидат разруливал сложности «прогонки» 10 Tbit/s на FreeBSD, потому что это прикольная история, которую рассказал сосед по общаге в 2005.
• Про межпланетный интернет. Да-да, такой проект существует, и правда интересно обсудить, как он работает. Но прочтите ниже блок «Поведенческие моменты» и поговорите об этом с будущим коллегой в пабе ;)
• О чем сами узнали только вчера. То, что кандидат ничего не знает из недавних changelogs, ни о чем не говорит. Не все мы ноулайферы.
• О том, чего у вас нет в компании. Вы планируете когда-то использовать Kafka? Нет? Вот и не нужно спрашивать!
• Специфический опыт, который доступен тем, кто строил какой-то левый хостинг, но денег у вас не было, и вы извращались как могли, и познали дзен! Туда же VoIP, CI/CD on MacOS/Windows и подобное! Само собой, только если это не требуется от позиции.
• Что делает вот тот ресурс в Chef и почему DSL там сработает так, а не иначе? Впрочем, если у вас колбаса самописного шефа и самописные LWRP, которые надо будет редактировать, то вопрос может быть и правильным.
• Не задавайте вопросы, на которые можно ответить первой строкой из описания в «Википедии». Такие вопросы не помогают понять, сможет ли человек делать конкретную работу. Один мой друг жаловался, что не может проходить собеседования, так как не знает все о HAProxy, о Postgres, да еще и про MongoDB. Я посоветовал заучивать первые предложения из описаний, и количество пройденных интервью возросло.
  
  • Вы знаете, что такое риак?
  • Ну, это распределенный KV датастор, как Динамодб.
  • А, ну ок!

Let’s talk about real systems

Задавайте открытые вопросы, в которые можно углубляться. Если вы не знаете таких вопросов, то возьмите вопросы, которые вам близки, и умножайте нагрузку, пользователей, rps в X2-X5-X1000 раз.

Пример открытого вопроса:

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

• А если мы хотим использовать Spot Instances, что изменится?
• ALB или NLB?
• Мы же уже на Spot? Zero downtime shutdown, как?
• MySQL master-master, master-slave, автоматическое переключение, как?
• Зашивать код в AMI? Идет в разрез с системой деплоймента? Как можно по-другому? Или триггерить билд на конкретный инстанс? А чтобы не деплоить на всех в группе при этом?
• Куда будем класть сикреты?
• А если у нас часть инфраструктуры в другом облаке или до сих пор на bare-metal? VPN? Хм...

Пример вопроса с «умножением»:

У нас есть Data Pipeline: ALB-Nginx-Python-RabbitMQ-Some_Workers-S3-Hadoop-Whatever. Система хорошо работает при количестве запросов X1, но при X2 начинает скапливаться очередь, где может быть проблема, что делать?

• При X5 nginx начинает выдавать 502, что не так и куда смотреть? Трейсинг, интересно?
• При X20 опять очередь, и наш реалтайм процессинг уже совсем не похож на реалтайм.
• У нас прилетело Х100, реббит упал, и потерял все данные? План по High Availability, как это будет выглядеть, сколько чего добавляем, а если опять чертов Spot? А как быть с остальными частями системы?
• Kubernetes? Отлично, давай поговорим, как будет выглядеть вся система?
• Мы же не забываем все это замониторить и читать логи, CI/CD? А как, откуда кто куда пишет и т.д.

Troubleshooting + hands-on

Это все отлично, скажете вы, но как же мне работать с человеком, который не знает, что такое LA или всех флагов lsof на память?

Нет, конечно, никто вам не запретит опять скатиться в «Apache vs Nginx». Но лучше сами немного подготовьтесь, сделайте виртуалку, сломайте в ней что-нибудь и дайте своему собеседнику. Эта часть займет у вас минут 5-7,но закроет очень много скучных вопросов. Заодно можно узнать что-то новое.

Deep dive

Если вам интересно узнать, например, как работает GTID в MySQL, то воспользуйтесь советами из блока «Let’s talk about real systems» и подведите к этому в обсуждении про увеличение нагрузки. То же самое с сетями, конфиг-менеджментами и т. д. Не стоит спрашивать подобные вопросы, ни к чему не привязываясь. Человек не в контексте, а вы такие бац! А как ElasticSearch делает flush-commit под капотом? И тут судорожно приходится вспоминать что-то про Lucene, что приведет к неловким попыткам выдать хоть что-нибудь.

Программирование и тестирование

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

Здесь нужно учитывать нюанс, что инфраструктурные вещи, как правило, отличаются от CRUD, например. Поэтому, самое худшее, что можно придумать — это позвать проверить эту часть программиста. Я даже помню (но не буду вслух) одну украинскую компанию, которая просила от DevOps-инженера алгоритмы, структуры данных и вот это вот все.

Понимая под какие задачи вы пишете код, можно подготовить правильные вопросы или тестовое. Например, вам по задачам достаточно только bash и прочий sh. Даем вот такой кусок лога Nginx:

host=setapp.com remote_addr=134.21.127.86 request="GET /v4/customer?access_token=lol HTTP/1.1" status=200 bytes_sent=813 user_agent="Setapp/1.18.2 CFNetwork/974.1 Darwin/18.0.0 (x86_64)" request_length=385 request_time=0.078 upstream_time=0.078 request_id=47f01df614e6c777d88270417c9ac871
host=setapp.com remote_addr=134.21.127.86 request="POST /v4/apns_token HTTP/1.1" status=204 bytes_sent=454 user_agent="Setapp/1.18.5 CFNetwork/974.1 Darwin/18.0.0 (x86_64)" request_length=655 request_time=0.081 upstream_time=0.074 request_id=9174d3b3712c4fd1e93696457f255439
host=setapp.com remote_addr=99.59.88.166 request="GET /v5/token/lol HTTP/1.1" status=200 bytes_sent=910 user_agent="Setapp/1.18.5 CFNetwork/975.0.3 Darwin/18.2.0 (x86_64)" request_length=371 request_time=0.011 upstream_time=0.011 request_id=d51d8230b753f5c9ac5fe31f4d1279a3

И просим вывести только IP-адреса, затем убрать из вывода remote_addr=, а после отсортировать, вывести топ повторяющихся IP, удалить дубликаты и т. д. Набросать подобных и более сложных задачек из жизни по bash совсем не сложно.

Идем дальше. Кандидат знает Python, Ruby, Go? Попросите сделать такой же парсинг лога, только на любимом ЯП. Хочу отметить, что во время интервью, под стрессом, скорее всего, мало кто справится со следующими просьбами, и для их выполнения может понадобиться несколько часов или больше. Скажу честно, что сам довольно редко просил делать тестовое, однако вы можете всегда иметь заготовки под рукой. Адекватно оценивайте количество времени, которое кандидат будет готов потратить на тестовое задание ради вашей компании на данном этапе.

Еще примеры:

• Написать CLI программу, которая будет парсить JMX и высчитывать процент или частоту запуска GC.
• Программу, которая сможет принять вебхук, распарсить json и, используя готовые библиотеки, отправить ключевые значения в Slack или в Jenkins API.
• Написать какой-то «кукбук» для Chef/Puppet — тоже вариант. Ansible? Скажи что-нибудь по YAMLовски :)

К сожалению или к счастью, 99% задач по написанию кода в этой профессии сводятся к подобному.

Хотел было что-то добавить про написание k8s operators, но голос разума подсказал, что это оверкил. Скорее всего, нужно будет готовиться к подобному в недалеком будущем, но пока я и сам не сталкивался с такими заданиями на интервью.

Тестирование тоже желательно должно быть. Не буду долго тут расписывать, но, если кандидат когда-то имел опыт с inspecили подобным, то это уже хорошо! Умеет и писал тесты к своему коду — отлично!

Поведенческие моменты

Я не предлагаю спрашивать о том, кем вы себя видите через 5 лет! Скорее, о чем-то, что может быть важным для вашей команды или компании. Очень простой и банальный пример, когда вы решили внедрить, ну я не знаю, blameless postmortems, а перед вами типичный злой сисадминхейтер всего и всех. Также можно расспросить, работал ли человек в команде, как принимали решения о внедрении чего-то нового. Это покажет, работал ли он с другими людьми и есть ли вообще опыт принятия решений с кем-то вместе.

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

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

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

Доводилось ли тебе быть «евангелистом»? Как ты доносил (бы) людям идею изменений какого-либо процесса или технической части в продукте, команде?

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

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

London is the capital of Great Britain

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

Фидбэк после интервью

Для HR

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

Вспомните, как часто на DOU мелькают недовольные отзывы кандидатов «Все было хорошо, но потом HR так и не перезвонил и не дал фидбэка». Но HR не было на собеседовании с вами, скорее всего, и поэтому нельзя просто взять и придумать фидбэк самостоятельно. Кандидат уделил время нам, и мы проявляем к нему уважение, не просто говоря «Прости, ты не подходишь нам», а объясняя, почему именно и где уже хорошо, а над чем еще стоит поработать.

Для кандидата напрямую

Тут нужно быть осторожным, так как ненамеренно можно и обидеть человека, и оставить плохую ассоциацию с компанией! У меня был случай, когда я выдал человеку аккуратное «слабенько с AWS», а он оказался каким-то там трижды сертифицированным по AWS. Было неудобно. C тех пор я стараюсь показать свой отзыв кому-то из коллег и конкретизировать: «Не хватило знаний с такой-то и такой-то штукой в AWS».

В большинстве случаев человек сам способен провести ретроспективу и понять, где он плавал, а где был силен. Но, если речь явном запросе «что бы почитать?», то вам же несложно накидать список хороших книг, WebOps/DevOps/SRE Weekly и дать ссылочку на UkrOps Slack, правда?

Послесловие

В конце хотелось бы обобщить важное:

• Готовьтесь к интервью независимо от того, на какой вы будете стороне.
• Не превращайте интервью в сценку «Я здесь самый крутой чувак!».
• Не делайте из интервью экзамен, их, вроде, и в универе должно было хватить :)
• Выбирайте себе коллегу, а не набор чекпоинтов напротив нужных скиллов.

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

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

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

EPAM

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

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

Київ:

• JavaScript — 8 січня;
• QA — 21 січня;

Львів:

• JavaScript — 28 грудня;
• Business Analysis — 1 лютого.

Вінниця:

• .NET/Sitecore Development — 25 січня.

Харків:

• Business Analysis — 31 січня;
• Software Testing Introduction — 1 березня;
• Test Automation — 1 березня;
• Front-end — 1 березня;
• DevOps — 8 березня;
• .NET — 8 березня;
• Java — 8 березня.

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

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

Kottans

Напрям:курси Front-end.
Місто:Київ.
Дедлайн подачі заявок: 5 січня.

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

• базове розуміння програмування;
• знання англійської.

Як потрапити:виконати вступне завдання до 5 січня. Деталі.

Умови:під час курсу ви зможете вивчити основи Front-end розробки: HTML, CSS, JS та Front-end фреймворки. Цього разу буде більше колективних обговорень та командних проектів.

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

La’Soft

Напрям:курси React, ROR, Python.
Місто:Львів.
Дедлайн подачі заявок: 20 січня.

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

• знання ООП, досвід з базами даних, початкові знання з React, ROR, Python;
• готовність протягом 3 місяців приділяти час навчанню;
• освіта не так важлива, але завершені курси або профільна освіта полегшать старт;
• англійська рівня intermediate.

Як потрапити:надіслати резюме на пошту yuliya.tsuper@lasoft.org.

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

Деталі:пишіть на пошту yuliya.tsuper@lasoft.org.

Luxoft

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

Вимоги до кандидатів:попередній досвід у програмуванні, бажання використовувати широкий технологічний стек та перепрофілюватися у Java.

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

Умови:тривалість курсу — 3 місяці. Початок — 1 лютого. У разі успішного завершення можливе працевлаштування.

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

Netcracker

Напрям:курси для Application Analyst та QA.
Місто:Суми, Одеса.
Дедлайн подачі заявок: Application Analyst — 11 січня (Суми), QA — 27 січня (Одеса).

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

Application Analyst

• вища або незакінчена вища освіта;
• розвинена логіка, аналітичні та базові математичні здібності;
• основи SQL, Web;
• комунікаційні навички.

QA

• англiйська мова не нижче B1;
• освiта вища або студенти останнiх курсiв.

Як потрапити:

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

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

Умови:

Application Analyst:тривалість навчання — від 2 до 3 місяців. Курс складається із лекцій, практичних занять із професійними викладачами та роботи над навчальним проектом із провідними представниками компанії в ролі наставників. Після успішного закінчення можливе працевлаштування.

QA:тривалість навчання — 2 тижні, заняття проходитимуть після 18:00. Передбачено 8 занять. Після успішного завершення курсу можливе стажування у компанії. Тестування кандидатів проведуть до 3 лютого. Початок занять — 4 лютого.

Деталі:

Application Analyst:на сайтіабо пишіть на пошту HumanResourceSumyGroup@Netcracker.com.

QA:на сайтіабо пишіть на пошту hr.odessa@Netcracker.com.

NIX Solutions Ltd

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

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

• навчання .NET;
• навчання iOS;
• навчання Java;
• навчання Linux Administration / DevOps;
• навчання PHP + CMS.

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

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

QATestLab

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

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

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

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

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

RubyGarage

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

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

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

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

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

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

Serpstat

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

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

• знання англійської на рівні не нижче Upper-Intermediate;
• бажання приєднатися до команди Serpstat в одному з напрямків: Support або Customer Success;
• комунікабельність, допитливість і емпатія;
• грамотна письмова і усна мова;
• дисциплінованість (всі прогульники будуть відраховані з курсу);
• готовність виділити в тиждень 6-8годин вільного часу на навчання.

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

Умови:це можливість для тих, хто хоче працювати в IT, не маючи технічного бекграунду. Розклад занять: 22, 24, 29 січня з 09:00 до 18:00.

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

SoftServe

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

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

• Python: Дніпро — 4 січня;
• DevOps: Львів — 26 січня, Дніпро — 29 січня, Івано-Франківськ — 11 лютого, Харків — 19 лютого, Рівне — 27 лютого;
• .NET: Івано-Франківськ — 9 січня, Рівне — 15 січня, Чернівці — 28 січня, Львів — 4 лютого;
• Java : Рівне — 10 січня, Львів — 25 січня;
• Test Automation: Дніпро (Python) — 4 січня, Івано-Франківськ (Ruby) — 21 січня, Львів (Java) — 25 січня, Харків (.NET) — 29 січня;
• QC: Чернівці — 14 січня, Дніпро — 15 січня, Львів — 28 січня;
• Ruby Development: Львів — 20 лютого;
• Golang Development: Львів — 15 лютого;
• С++ Development: Львів — 4 лютого;
• WebUI/Python: Чернівці — 14 січня, Львів — 11 лютого;
• WebUI/NodeJS Development: Львів — 21 січня;
• WebUIDevelopment: Чернівці — 4 лютого.

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

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

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

AMC Bridge

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

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

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

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

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

Cleveroad

Напрям:стажування iOS, UI/UX Design.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

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

iOS

• базові знання однієї з таких мов, як: C / C ++, Java, C #;
• знання структур даних і алгоритмів;
• знання SQL і баз даних;
• знання і розуміння принципів ООП;
• розуміння клієнт-серверної архітектури, REST;
• досвід роботи з системами контролю версій.

UI/UX Design

• базові навички по роботі з інструментами (Photoshop або Illustrator або Figma або Sketch);
• базові знання типографіки, композиції та теорії кольору;
• естетичний смак;
• бажання навчатися і розвиватися.

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

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

Деталі:iOS, UI/UX Designerабо пишіть на пошту alena.yarochevska.cr@gmail.comчи телефонуйте +38093 849 61 77.

DataArt

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

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

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

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

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

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

groupBWT

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

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

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

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

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

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

HYS Enterprise

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

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

• добре розуміння ООP;
• знання C#, Microsoft.NET (ASP.NET, MVC, ADO.NET, WCF);
• хороші знання HTML/CSS, JavaScript (jQuery);
• базове знання розробки Back-End та/або Front-End;
• вільна англійська.

Як потрапити:подати резюме на hr@hys-enterprise.com.

Умови:тривалість стажування — 1-3місяці залежно від результатів співбесіди.
Деталі:на сайті.

Leobit

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

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

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

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

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

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

Quality Assurance Group

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

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

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

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

Sigma Software University

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

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

• UI/UX Designer: Харків — 8 січня;
• .NET: Харків — 15 січня;
• Project Management: Харків — 20 січня;
• PHP: Харків — 4 лютого;
• Test Engineer: Харків — 15 лютого;
• JavaScript: Харків — 15 лютого;
• Java: Харків — 15 лютого;
• Project Management: Львів — 30 грудня;
• Java: Львів — 15 лютого.

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

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

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.

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

Wix

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

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

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

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

БАКОТЕК

Напрям:стажування Information security.

Місто:Київ.

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

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

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

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

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

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

Ascendix Technologies

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

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

• вища технічна освіта: студенти 5-6 курсiв/випускники,що спеціалізуються на комп’ютерних науках, математиці або вивчали суміжні дисципліни;
• знання алгоритмів та структур даних;
• розуміння принципів ООП;
• базові знання Java, JS, XML, HTML, CSS, SQL;
• англійська: Intermediate.

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

Умови:стажування (iнтернатура) проводиться в офісі компанії (ст. метро 23 Серпня), задачі близькі до реальних, навчання за спецiально розробленими тренiнг-програмами пiд наглядом досвідчених менторiв/технiчних лiдiв. Строк стажування — 3 мiсяцi, (8 годин на день, 5 днiв на тиждень). Пiд час стажування iнтерни отримують стипедiю. Гарантоване працевлаштування у разі успішного проходження стажування.

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

Ciklum

Напрям:робота System Administration/Configuration Intern.
Місто:Київ.

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

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

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

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

Devico

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

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

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

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

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

Playtech

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

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

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

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

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

TechMagic

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

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

• закінчені курси QA за останній рік;
• розуміння API тестування;
• розуміння зв’язку сервер-клієнт;
• досвідчений користувач комп’ютера і телефона;
• англійська — Upper-intermediate і вище.

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

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

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

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

Програмісти: +33 тис. спеціалістів

Щороку ми пробуємо оцінити кількість фахівців у галузі, використовуючи дані зарплатного опитування і ТОП-50.

За даними липневого зарплатного опитування, 16,6% опитаних працюють у компаніях «від 1 000 спеціалістів». З липневого рейтингу ТОП-50сюди потрапляє 13 компаній (від EPAM до Intellias), в яких усього працює 26 508 технічних спеціалістів.

Таким чином, отримуємо 26 508 / 16,6% = 159 687 спеціалістів.

Ріст ринку vs. ТОП-25

Рік тому за цією ж формулою ми нарахувалив Україні 126 990 працівників ІТ, тобто за 2018 індустрія виросла на 26%. За останні два роки ІТ-галузь зросла на 60%.

На початку року ми підрахуваликількість ІТ-фахівців за даними Мін’юсту — отримали 125 тисяч ФОПів-айтішників.

Вакансії: +48% до 2017

Кількість опублікованих на DOU вакансій зросла за рік у півтора рази — з 3 111 до 4 606 в місяць.

Кількість відгуків зросла на 23% порівняно з минулим роком — з 270 тис. до 330 тис. Кількість компаній, які розміщують вакансії, зросла на 38% — з 2 419 до 3 339.

Кількість вакансій за роками

Найбільш затребуваними в 2018 році були Front-end, QA і PHP — частка цих трьох категорій складає 31% від загальної кількості вакансій.

Усього вакансій за 2018 рік за категоріями

У топі за співвідношенням вакансій / відгуків тримаються в основному нетехнічні напрямки в ІТ. На кожну вакансію Product і Project Manager припадає понад 15 відгуків. Тоді як на одну вакансію Fron-end — тільки 5.

Кількість відгуків на одну вакансію, листопад 2018

Зарплати: +27% у Senior Ruby, +25% у Junior QA

Уперше з 2014 року у Junior і Middle QA спостерігається позитивна динаміка зростання зарплат — за даними липневого опитування. За останній рік у Junior QA зарплата збільшилася з $400 до $500, у Middle — з $1100 до $1300. Найбільший стрибок за рік стався у Senior Ruby (+$800).

Рухається вгору і середня зарплата проджект-менеджерів — за останній рік +$200. Це перша позитивна зміна динаміки зарплати ПМ-ів з грудня 2013 року.

Зарплати істотно відрізняються не тільки залежно від досвіду роботи, але і в розрізі міст. ПМ у Києві отримує в два рази більше, ніж ПМ в Одесі і Львові. Junior Java краще платять в Одесі, а львівські Middle Swift отримують на $900 більше, ніж столичні.

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

Бонуси в IT: в топі гнучкий графік роботи і корпоративи

У 2014 році ми вже публікували статтю про бонуси в ІТ. Цього року знову вирішили поглянути на цю темуі в анкету «Портрета ІТ-спеціаліста» додали два питання: які бонуси надає ваша компанія і які бонуси вам би хотілося отримувати.

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

Найкращі канали пошуку спеціалістів

У лютому 2018 року на Djinni проходило опитування роботодавців та рекрутерів. Дізнавалися, хто, як і де шукає ІТ-спеціалістів.

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

Ефективність каналів пошуку

Найкращі ІТ-роботодавці

Цього року ми перезапустили рейтинг ІТ-роботодавців. Намагалися врахувати критику минулих років — тепер у рейтингу нова анкета, є окрема категорія для українських ІТ-гігантів і ще низка інших оновлень. За два місяці зібрали майже 15 тис. голосів та визначили найкращих IT-роботодавців 2018 року.

Школи та виші

Рейтинг вишівтретій рік поспіль очолює Могилянка. З профільних ВНЗ у п’ятірці лідерів тільки ХНУРЕ (3 місце). КПІ зайняв лише 8 місце, а Львівська політехніка — 12-е.

Топ-10 найкращих вишів на думку учасників опитування:

Третій рік поспіль ми готуємо рейтинг шкіл за результатами ЗНО. Цього року враховували результати попередніх двох років (2016/17).

Портрет ІТ-спеціаліста

Традиційно завершимо огляд Портретом ІТ-спеціаліста. Цього року зібрали 8 638 анкет, додали кілька нових питань, а Popel Agency намалювали нам гарну інфографіку в стилі Pixel art.

Із цікавого — жінок в ІТ вже 23%, у Києві частка тих, хто працює в аутсорсі та продукті, майже однакова — 36% проти 35% відповідно, двоє з трьох ІТ-спеціалістів працюють в опенспейсі.

Ідемо в 2019-й.