Представляем традиционныйфотообзор празднования Нового года в украинских ИТ-компаниях.

A-Level

Компания встретила новый 2018 год в родных стенах. В программе были поздравления, веселые игры: IT Alias, бирпонг и ребусы с айтишными пословицами. Все участники вечера получили от тайного Санты подарки.

Abto Software

Цьогоріч команда Abto Software влаштувала новорічний бал у футуристичному стилі. Локацією для Mask of the Future Party став Львівський Будинок вчених — архітектурна пам’ятка ХІХ століття, що початково була споруджена як казино. Гості дотримувалися дрес-коду Black Tie, доповнивши класичний одяг футуристичними аксесуарами та мейкапом. Таємничу атмосферу вечірки доповнило шоу мікромагії від ілюзіоніста.

Acceptic

Сотрудникам харьковского и киевского офисов Acceptic под Новый год выпал шанс войти в историю на Вечеринке Всех Времен.

AMC Bridge

Appus Studio

Party like a RockStar!

Archer Software

Archer Software отпраздновали дважды — на Mafia Party в Днепре и продолжили в Киеве.

Ascendix Technologies

Вечер в Ascendix Technologies прошел под аккомпанемент терменвокса и выступления шоу-балетов.

Astound Commerce

Astound Commerce влаштували Monochrome Evolution Party. Вечірка почалася з двох головних кольорів — чорного та білого, а закінчилася вибухом різноманітних барв!

B2B Soft

Binary Studio

По традиции Binary Studio отмечает зимние праздники поездкой в Европу. В этот раз — три рождественских города за неделю: сказочный Нюрнберг, веселый Будапешт и торжественный Берлин.

Bizico

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

Blackthorn Vision

Цьогорічний передноворічний корпоратив компанія BlackthornVision провела в тематиці фільмів Квентіна Тарантіно. У ньому взяли участь працівники двох офісів компанії зі Львова та Хмельницького. Яскравими елементами вечірки була фотозона, тематичні атрибути, виступи танцювального колективу та фокусника-ілюзіоніста. Також відбулася церемонія вручення нагород Company Awards: 15 найкращих працівників компанії отримали скляні статуетки.

Brander

В этом году в компании Brander решили подыграть глобальному потеплению и устроили «New Year Summer Party» с морской фотозоной, шоколадными фонтанами, фруктовыми пальмами, зажигательными латинскими танцами и африканскими барабанами!

Caspio

CHI Software

Уходящий 2017 год компания CHI Software провела на Black&White Secret Party в компании с Heart Beat Brass Band! Сотрудники потанцевали под зажигательную живую музыку, участвовали в конкурсах, получали призы, печатали настоящие фото на память и впервые провели награждение в разных номинациях для сотрудников каждого отдела компании.

Cleveroad

CodeIT

Codemotion

В Codemotion все были приглашены на Private Party на самолет элит-класса ;)

COI marketing & software

Львів’яни COI marketing & software влаштували стильний Новий рік.

Crysberry

Харьковский офис Crysberry отметил Новый год вечеринкой «Пати на хате» с конкурсом домашних костюмов, играми, Тайным Сантой, настойками, приготовленными по «семейным» рецептам, а также оливье, кальяном и песнями под гитару всю ночь напролёт...

Delphi Software

Новогодний корпоратив Delphi Software в стиле «Одесский дворик» прошел шумно, весело и полосато!

Dev-Pro

К Новому году команда Dev-Pro, как Алиса в сказке Кэрролла, выросла до небывалых размеров: на Dev-Pro New Year Party больше 300 человек попали в Страну Чудес.

Edvantis

Edvantis в стилі ретро фантазував на тему — як би то вони виглядали в міжвоєнному Львові. Панянки, батяри, забави та інші лєґуміни допомогли відсвяткувати прихід 2018 року.

EIS Group

Новогодняя вечеринка Illusion Party в компании EIS Group!

ELEKS

Хто ховається за маскою? Що чекає нас за наступними дверима? Secret Party — таку тематику ELEKS обрав для своїх новорічних вечірок.

ElifTech

Успіхи року, що минає, та початок 2018 команда ElifTech зі Львова та Вінниці відсвяткувала в ❄️засніжених Карпатах.

Envion Software

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

Evergreen

Была рулетка и крупье, аукцион-розыгрыш на выигранные в казино деньги, дресс-код в стиле 30-хи обмен подарками Secret Santa.

Exadel

На новогодней вечеринке Exadel Vinnytsia гости побывали в роли хипстеров. Были конкурсы, интервью, квадрокоптеры и зона для любителей Play Station, фотозона, масса угощений и напитков. Изюминкой вечеринки стал тематический торт и фейерверк.

Forma-Pro

Ирландские танцы, эльфы, друиды, лепреконы, душевная обстановка и веселье — именно так компания Forma-Pro провожала уходящий 2017 и встречала новый 2018 год — в ирландском стиле.

GeeksForLess

В этом году николаевский офис отправился в увлекательное путешествие на машине времени.

GlobalLogic

Киевский офис GlobalLogic отпраздновал Новый год в космическом стиле.

В Харькове команда отметила праздник в атмосфере бурлеска.

Львовский офис компании веселился на рок-вечеринке.

В Николаеве GlobalLogic провел вечеринку в стиле «Ночь в музее».

HYS Enterprise

HYS устроили тематическую вечеринку «Back to the future». Помимо угощений и программы, атмосферу дополнили шоу химических опытов, фотозоны и видеосюрпризы о жизни компании.

Infopulse

22 декабря все офисы Infopulse отметили зимний Professionals’ day в стиле стран Скандинавии: подвели итоги года, провели церемонии награждений, угостились традиционной кухней, «попрыгали» со снежных фьордов/гор в очках виртуальной реальности и отдохнули в кругу коллег.

Inoxoft

Intego Group

Компания Intego Group провела фестиваль, посвященный Route 66, где в Техасе было родео, а в Чикаго — казино, в Нью-Мехико лаборатория из «Breaking Bad», а у индейцев дартс и кальянная «трубка мира»! А ещё Голливуд, хиппи, Симпсоны с beer pong, американская уличная еда, рок-н-рол, кантри танцы, квест и призы!

Intellias

Усі офіси Intellias — у Львові, Києві та Одесі — зустрічали Новий рік не під бій курантів, а під гул гітарних рифів та барабанів. Це була RockStar Party! У Львові та Києві виступали гурти «Карна», «Біла Вежа» та «Веслярі». Останні, до речі, поміж репетиціями встигають ще й працювати в Intellias. Одеса відсвяткувала у вужчому колі колег, проте не без тематичної музики та костюмів.

InterLink

Новорічна вечірка InterLink пройшла у стилі бондіани :)

Itera

KeepSolid

Гангстеры и гламурные кинозвезды, кабаре и автоматы Томпсона, настоящее казино и мафиозное настроение — атмосфера Чикаго 30-хна новогодней вечеринке KeepSolid!

Jelvix

#J_maskarad2018 — именно под этим лозунгом прошел новогодний корпоратив Jelvix. Сотрудники перевоплотились в необычных героев. Были конкурсы, песни и танцы до упаду.

Light IT

В этом году Light IT отмечали Новый год в украинском стиле. Вышиванки, шаровары, сало и хреновуха.

Lionwood.software

Працівники компанії Lionwood.software розділили новорічний настрій в дружній та теплій атмосфері.

LoopMe

Фотозона, символ 2018 года, live band, квест из заданий и светловое шоу стали элементами празднования наступающего Нового Года в #LoopMe Ukraine.

Luxoft

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

Maytech

NIX Solutions

Итальянская мафия, якудза из Токио и банда острых козырьков — в этот раз NIX Solutions отмечали Новый год в традициях настоящих гангстеров!

Nullgravity

В этом году команда Nullgravity на день превратилась в Супергероев и Суперзлодеев. На вечеринке были Супервуман, Капитан Америка, Аквамен и брутальная Снегурочка. Не обошлось без тематических конкурсов, веселого ведущего и диджея.

Perfectial

Новорічний корпоратив Perfectial провів в драйвовій атмосфері рок-вечірки. Були улюблені рок-хіти, костюми працівників, бармен-шоу та розваги від ведучого.

Playtika

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

В днепровском офисе отпраздновали Новый год в стиле Rock Party, где каждый смог почувствовать себя рок-звездой. Награждение команд за супердостижения в 2017, выездной тату-салон, рокерские развлечения, зажигали под хиты рок-групы «Натолич», счастливчики выиграли супер приз — билеты на «30 seconds to Mars».

PortaOne

PortaOne провели уходящий год в компании коллег и их половинок, устроив вечеринку в классическом стиле с живым джазом, световым шоу, творческими номерами, игровой комнатой. Участников поздравили группа «Aддис Абеба», кавер-группа «Bad Sound», а после собрали полный танцпол с Dj Pupps и чилаут с DJ Miss Monique.

Poster

PROBEGIN

З нагоди завершення року PROBEGIN організував святкову вечерю. А зимовий корпоратив чекає на команду у лютому.

Roobykon Software

Душевні пісні та грайливі танці — ось лише маленька частинка всіх тих завдань, які виконала команда Roobykon Software!

RGAND

Праздновали корпоратив в стиле венецианского карнавала.

RubyGarage

QuartSoft

Краматорский офис компании QuartSoft провел корпоратив «Стиляги». Почти все сотрудники поддержали тематику. Живая музыка, песочная анимация, конкурсы, танцы до упаду в стиле 50-60-х годов прошлого столетия!

Rademade

Sigma Software

Темой новогоднего корпоратива Sigma Software стала хорошая британская традиция 5 o’clock tea. Конечно, кроме английского чая на вечеринке были и другие напитки Соединенного королевства. Все офисы собрались в Харькове, чтобы встретиться с коллегами и отпраздновать вместе Новый год.

Skelia

Skywell

SoftBistro

SoftServe

У Києві співробітники SoftServe святкували завершення року на Watchdog Night Party — наглядач ночі Жовта Земляна Собака була прихильною тільки до тих, хто від душі веселився.

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

В Івано-Франківську теж зібралися рок-зірки — святкували гучно, весело та драйвово.

Команда SoftServe Дніпро святкувала у Winter Wonderland. Атмосферу зимової казки створювали — крижане шоу, снігова фотозона та віртуальний лижний слалом. Головною родзинкою новорічної вечірки стали яскраві виступи співробітників.

Харківська команда SoftServe перетворилася на секретних агентів, які отримали спеціальне завдання «Christmas never dies».

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

SPD-Ukraine

Компанія святкувала Новий рік, відзначаючи найкращих на церемонії SPD AWARDS 2017.

Synebo

TapMedia

Це була неймовірна ніч! Новий рік зібрав всю сім’ю TapMedia під одним дахом. 350 чоловік, відмінна музика і море чудових подарунків — те, що потрібно, щоб провести 2017 рік гідно.

TechMagic

Компанія TechMagic відсвяткувала #MagicNight2018 в ресторані «Шпацер» за містом. Традиційно провели церемонію нагородження найкращих працівників року. Влаштували молодіжну вечірку і до ночі відривалися під музику гурту Sub Rosa.

Terrasoft

Trionika

Trionika отпраздновала новогодний корпоратив в Буковеле.

Ukietech

Знову зірки естради та світові хіти завітали до Ukietech!

Vakoms

Vakoms провели вечеринку в стиле Лас-Вегас — с казино, блэкджеком и... балетом!

Waverley Software

Передноворічна ніч в компанії пройшла в стилі Waverlate Night Show, aka Late-night talk show з традиційними гумористичними дійствами, інтерв’ю з гостями, комедійними ескізами та музичними виступами.

Если хотите добавить в статью ваши фото, присылайте их на alyona@dou.ua.

В выпуске:Эдди Османи о Progressive Web Apps, начинаем использовать сервис-воркеры и переходим на новые быстрые сборщики.

CSS и CSS in JS

Font-display — зачем он нужен и как работает

Modern Asynchronous CSS Loading — асинхронная загрузка стилей

Styling Components — Typed CSS With Stylable — как можно типизировать CSS?

CSS-in-JS Roundup: Styling React Components — 15 CSS-in-JS решений для React. Что выбрать?

JavaScript

The Hidden Treasures of Object Composition

Robust Client-Side JavaScript — надёжный JS на клиенте

Teach the CLI to Talk Back — как сделать CLI дружелюбными?

Fitting Flappy Bird Into a Tweet — Flappy bird в 280 символов

Service Workers: Going beyond the page — сервис-воркеры в Edge

Service Workers. Инструкция по применению — cервис-воркеры в 2ГИС

JavaScript Has Already Won — JavaScript захватил мир

Progressive Web Apps

All you need to know about Progressive Web App — зачем нужны Progressive Web Apps?

Эдди Османи о техник оптимизации производительности в Progressive Web Apps:

• Tinder
• Pinterest

PWA feature detector — проверяем возможности Progressive Web Apps в вашем браузере

React и React Native

Behind the Scenes: Improving the Repository Infrastructure — инфраструктурные изменение в React

Recommended by the React Team — что рекомендует нам команда React

The Ugly Side Of Redux

How to write highly readable React code — 10 coding style tips

React Performance Fixes on Airbnb Listing Pages

How to build a React and Gatsby-powered blog in about 10 minutes

Designing Reusable React Components

О прошедшем годе:

• React & React Native — Best of 2017
• The most popular React links of 2017
• A recap of front-end development in 2017
• 25 Amazing Open Source React.js Projects for the Past Year (v.2018)

Vue.js

Prototyping with Vue.js and Bootstrap

Build A Lazy-Load Router With Vue.js And The Latest Browser Features

Why Nuxt Js is perfect framework for your next landing page?

Vue.js review of 2017

Want to get things done and ship? 3 reasons to choose Vue over React in 2018.

Angular

Angular is easy — переходим на Angular

Angular 5 Service Worker

Angular 5 Server Side Rendering With Firebase  — Step-By-Step Guide

Top 10 Angular articles in 2017 from Angular-In-Depth you really want to read

Angular 5.1 & More Now Available

Пишем Progressive Web Apps на Angular 5:

• Part 1: Getting started with framework, creating an application, hosting it on github-pages
• Part 2: Progressifying the application

Node.js

Node.JS — Best of 2017

25 Amazing Open Source Node.js Projects for the Past Year (v.2018)

Building a Serverless REST API with Node.js and MongoDB

Building a FoodKick SMS Sale Notifier Bot

Библиотеки

Yew — пишем Front-end на Rust

Rustify — бандлим Rust

Microbundle — быстрый бандлер, без конфигураций и зависимостей

On-change — слушаем изменение объектов

React Native Typography — удобные нативные шрифты

React Performance Devtool — исследуем производительность React приложений

Unistore — минималистичный state-managment для React

Immer — работаем с иммутабельным состоянием

Послушать

Frontend Weekend:

• #32 — Андрей Смирнов о том, как появился Frontend Weekend и как из разработчика стать руководителем
• #33 — Виталий Фридман о создании и редизайне Smashing Magazine

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

• Выпуск № 98
• Выпуск № 99
• Выпуск № 100
• Выпуск № 101

Пятиминутка React:

• #38 — React + Typescript = ?

devschacht:

• Ночной фронтенд #14 — HolyJS. День 1
• Ночной фронтенд #15 — HolyJS. День 2, Rust захватывает мир, новости V8
• Ночной фронтенд #16 — PiterJS 20: Dart, Kotlin, Closure и Wallaby.js
• Выпуск № 10 — Новогодний. История Девшахты и планы развития

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

• Метод Кнута и Пряника
• #29 Vue.js для нищебродов
• #30 Код Абрамова или мироточащий монорепозиторий
• #32 Новогодний выпуск. Как свалить в Швейцарию

Radio.js:

• Выпуск 50: с юбилеем и новым годом!

Egghead подкаст:

• Episode 1: Using TypeScript with Basarat and Marius Schulz
• Episode 2: Functional JavaScript with Paul Frend and Briand Lonsdorf (Dr Boolean)
• Episode 4: Getting into Python
• Episode 5: Dan Abramov, co-author of Redux
• Episode 6: Learning React with Kent C. Dodds

Конференции

Odessa Front-end Meetup #4

KharkivJS #8 2017

dotJS 2017

Что нового?

HTML 5.2

Parcel — новый быстрый сборщик

Turbo — NPM-клиент в браузере

Docusaurus — создаем сайты с документацией для опенсорса от Facebook

Storybook 3.3

Ждем Webpack 4.0.0 — уже alpha 2

Итоги 2К17

State of JavaScript

Frontend in 2017: The important parts

Totally Tooling Tips Holiday Special: 2017 Year in Review — лучшие инструменты 2017

Angular vs. React vs. Vue: A 2017 comparison

Frontend in 2017: The important parts

Learn to code in 2018, get hired, and have fun along the way

2017: The year in GraphQL

Остальное

JavaScript Array Explorer — выбираем правильный метод массива

Manage Application State with Mobx-state-tree — разбираемся с MST на EggHead

Making your web app work offline:

• Part 1 — The Setup
• Part 2 — The Implementation

Why Design Systems Fail — Уна Кравец о дизайн-системах

Accessibility Through Semantic HTML — влияние семантики верстки на доступность веб-ресурсов

What happens when you visit ft.com?— как работает FT.com?

30 seconds of code — коллекция JS-утилит, которые можно понять за 30 секунд

How GitLab switched to Headless Chrome for testing — как GitLab пытался ускорить тесты

Building a custom WebdriverIO reporter using documented and undocumented WebdriverIO features — делаем результаты тестов лучше

Top JavaScript Libraries & Tech to Learn in 2018 — чему учиться в 2018

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

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

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

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

Количество женщин в украинском IT

По данным зарплатного опроса DOU и проекта «Портрет IT-специалиста»

Этот показатель будет расти и дальше, ведь среди тех, кто пришел в украинскую IT-сферу за последние 2 года, женщин было уже более четверти.

Кто приходил в IT-отрасль в разные годы

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

Доля женщин в компаниях разного размера

По данным зарплатного опроса DOU за 2011-2017 гг.

Доля женщин в компаниях разного типа

По данным зарплатного опроса DOU за 2011-2017 гг.

Мы решили пристальнее взглянуть на женщин, которые принимали участие в зарплатных опросах в 2011-2017годах и опросе «Портрет IT-специалиста» в 2017 году, чтобы выяснить, есть ли различия в занятости, мотивации IT-специалистов обоих полов и в чем они состоят?

Выбирают IT-сферу не случайно и видят себя синьорами

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

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

Почему приходят в IT

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

Почему женщины приходят в IT

Что касается эмиграции, то, хотя возможность переезда за границу и становится более важной причиной выбора IT-отрасли женщинами, но это, скорее, запасной вариант на будущее. Новички чаще говорят, что конкретных планов переезжать нет, а готовятся к переезду чаще опытные специалистки: 23% женщин, которые работают в IT более 5 лет, серьезно настроены на переезд (или уже переехали), а среди новичков таких только 11%.

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

Фактор случайности наиболее выражен в ответах тех женщин, которые работают на нетехнических должностях (28%). Для мужчин, работающих на нетехнических должностях и менеджерами проектов, этот показатель также выше, чем для технических специалистов (разработчиков и QA), хотя он и ниже, чем среди женщин — 19-20%.

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

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

Кем видят себя через 5 лет

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

Только 20% опрошенных женщин сказали, что ушли бы из IT, если бы пропала необходимость работать. Cреди мужчин этот показатель даже немного выше — 22%. Причем самая высокая разница между мужчинами и женщинами по этому показателю — среди разработчиков и QA.

Если бы пропала необходимость работать...

Занимают в основном нетехнические должности

Несмотря на схожесть мотивации, роли женщин и мужчин в украинском IT сильно отличаются. Женщины составляют подавляющее большинство на нетехнических должностях — в HR, PR, Sales. При этом разработка, топ-менеджмент и системное администрирование остаются «мужскими» занятиями: более 90% тех, кто работает на этих позициях, — мужчины.

Среди дизайнеров, QA специалистов, бизнес-аналитиков и менеджеров проектов доля женщин выше средней — более трети этих специалистов — женщины.

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

Количество женщин на различных позициях

Рост количества женщин в украинской IT-сфере сопровождается изменением структуры их занятости. Женщины, которые пришли в IT более 5 лет назад, чаще занимают технические должности: разработчик, менеджер проекта или бизнес-аналитик. В последние 5 лет прослеживается четкая тенденция к увеличению количества женщин, работающих на нетехнических должностях — HR, PR, Sales.

Кем работают женщины

В то же время отрасль и сама меняется, что тоже влияет на количество женщин. Например, среди участников Зарплатного проекта DOUс 2011 по 2017 год неуклонно падает удельный вес разработчиков, где мужчины составляют более 90%. Наряду с этим доля QA, других технических должностей и нетехнических специалистов растет (кроме менеджеров — их доля тоже падает), а это именно те сферы, в которых женщин довольно много.

Структура занятости в украинском IT

По данным зарплатного опроса DOU за 2011-2017 гг.

Но увеличение доли женщин связано не только с изменениями в самой сфере IT и ростом количества нетехнических вакансий. Если проанализировать удельный вес женщин на различных позициях в разные годы, то видно, что женщины понемногу «отвоевывают» места в IT-сфере у мужчин. Так, доля женщин среди менеджеров выросла в разы: с 4% в 2011 до 25% в 2017. Значительный рост заметен также среди другого технического персонала — с 9% до 20%. Среди QA рост составил 6 п.п., с 23% до 29%. Даже в разработке наблюдается небольшой рост доли женщин. А на нетехнические должности с самого начала (они появились в опросе в 2012 году) активнее привлекали женщин.

Доля женщин на разных должностях

По данным зарплатного опроса DOU за 2011-2017 гг.

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

Образование

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

На технических должностях различий в образовании между женщинами и мужчинами практически нет: например, среди разработчиков — и мужчин, и женщин — более ⅔ имеют ВО в сфере точных наук или программирования; для QA этот показатель составляет около 50%.

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

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

Интересно, что специальность, на которой учился IT-специалист, влияет также на его знание английского языка: выпускники технических специальностей — как женщины, так и мужчины — хуже оценивают свое знание английского по сравнению с теми, кто учился на нетехнических направлениях.

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

Знание английского языка

Украинская IT-отрасль характеризуется молодыми кадрами, и женщины не исключение. 81% IT-специалистов женского пола младше 30 лет (мужчины немного старше, так как начали приходить в ІТ раньше женщин — до 30 лет среди них 71%). Самые молодые женщины в IT — на нетехнических должностях и среди разработчиков.

Возраст

Более лояльные сотрудники и реже начинают свои проекты

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

Количество компаний, в которых работали

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

Удовлетворенность нынешним проектом

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

Еще один фактор, влияющий на количество часов, которые женщина проводит за работой, — это наличие детей. Женщины с детьми работают меньшее количество часов по сравнению с женщинами без детей (40 и более часов в неделю работают 47% и 58% женщин соответственно). Фактор этот исключительно женский: количество рабочих часов у мужчин не зависит от наличия у них детей.

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

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

Выбор проекта

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

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

Выбор проекта IT-специалистками

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

Собственные IT-проекты

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

Собственные проекты у IT-специалистов

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

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

Недостатки IT-специалистов

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

И женщины, и мужчины в украинском IT чаще всего довольны своими зарплатами: только 10% женщин и 13% мужчин в 2017 году были совершенно не довольны своей зарплатой.

Удовлетворенность доходом, в отличие от удовлетворенности работой в целом, растет с опытом: наименее довольны своей зарплатой джуниоры и специалисты с опытом работы до 3 лет — как женщины, так и мужчины. Значительной разницы в удовлетворенности зарплатой между разными направлениями деятельности IT-специалисток нет.

Удовлетворенность зарплатой

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

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

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

Зарплаты IT-специалистов

Медианные значения

По данным зарплатного опроса DOU за 2011-2017 гг.

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

Для более корректного сравнения зарплат, помимо должности необходимо учитывать множество других характеристик сотрудника — опыт работы, наличие необходимых для работы навыков, количество рабочих часов и даже личностные характеристики, которые могут повышать (или понижать) ценность сотрудника для компании. По данным недавнего исследования Glassdoor, если учесть различные характеристики сотрудников при расчете разницы зарплат мужчин и женщин, то в развитых странах она уменьшается с 14-24%до 4-6%.То есть разница в оплате труда мужчин и женщин все-таки существует, но она не такая значительная, как показывают абсолютные цифры.

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

Разница в зарплатах IT-специалистов

Отличие медианной з/п женщин от медианной з/п мужчин

Выводы

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

Значительное увеличение количества женщин на технических должностях (например, до 54% — таков удельный вес женщин в населении) — вопрос, скорее, среднесрочной перспективы, когда стереотипы об IT как о мужской отрасли станут менее значимыми. Ведь выбор профессии все еще сильно зависит от мнения обществао «женских» и «неженских» занятиях, в результате чего женщины реже выбираюттехнические направления в вузах, чем мужчины.

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

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

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

Я сталкивалась с sales, как работая с ними по одну сторону баррикад, в одной компании, так и по другую — как представитель заказчика. В основном работала с самыми популярными регионами: Восточной Европой, Индией и чуть-чуть Юго-Восточной Азией (Филиппины).

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

Специфика общения слишком отечественного бизнеса

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

• Добрый день! Давайте пройдемся с вами по требованиям, чтобы понять, какие есть вопросы и услышать вашу оценку.
• Добрый день! Да, конечно. Я тут пацанам дал посмотреть — вы ж понимаете, хоть в заявке было написано, что я один работаю, у меня тут команда — так вот они посмотрели и сказали, что смогут сделать.
• Ооок, в документе мы просили объяснить, какой способ имплементации вы выберете и почему.
• Ой, вы знаете, я вам не отвечу, давайте программиста подключу. (Вызванивает программиста в бэкграунде. Программист раскрывает свою точку зрения).
• Спасибо, понятно. У нас в очереди еще два кандидата, мы планируем определиться до конца недели.
• Шо, серьезно? Ааа, ну хорошо. Ну ваще программист у меня хороший, он точно сможет сделать. У меня еще один есть, если нужно. А мы как с вами работать будем: официально или неофициально?

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

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

Ctrl+C, Ctrl+V

Некоторые ребята имеют в арсенале только копипасту. В ход идут pdf с презентациями, портфолио, описание компании и её достижений. На звонке об обсуждении конкретно поставленной задачи озвучивается та же generic информация: «Большое спасибо, ваша задача так хорошо описана, мы являемся certified partner XYZ, все наши разработчики имеют уровень Золотого Специалиста, и мы больше десяти лет на рынке». Сейлзам обычно «всё понятно, вопросов нет».

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

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

Хроническое «да»

• Вы сможете сделать систему из пяти модулей с интеграциями двух API?
• Да. У нас есть опыт работы со всеми технологиями, что вам нужны.
• За три месяца?
• Я думаю, что да. У нас очень хорошая команда.
• Вам точно понятна задача?
• Да, ваша задача очень хорошо описана.

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

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

Беспомощность

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

Совет:переспросить себя несколько раз: «Я точно не могу ответить?». Клиент хочет интегрировать какое-то конкретное API? Прочитать про него, просмотреть проекты компании на предмет похожих интеграций и составить письмо с примерами. Если нет уверенности, что информация готова к отправке клиенту — отдать черновик команде на вычитку. После пяти-десяти повторений этой практики на разных запросах команда будет возвращать не «всё переделать», а «вроде ок, отправляй».

Нежелание ознакомиться с задачей

Часто на этапе запроса нет сложных технических моментов. Достаточно вдумчиво прочитать запрос несколько раз (учитывая стиль написания некоторых заказчиков, можно, правда, и 10 раз). «Хочу добавить себе платные подписки в SaaS», «Хочу себе тулзу, которая, используя кастомный шаблон, будет рассылать письма по списку адресов», «Хочу дизайн для своего landing page» — это примеры запросов, с которыми вполне можно справиться без делегирования технической команде. На самом деле много людей в работе сталкиваются с чем-то сложным и непонятным, но обычно стоит себя пересилить и начать разбираться — сразу становится легче и интересней. В то время как отношение «я не знаю, разберитесь» не приносит никому пользы.

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

Советы (на примерах, приведенных выше):

• Подписки в SaaS: ознакомиться с приложением клиента, посмотреть, с какими платежными системами есть опыт у компании, предложить на выбор. Если непонятно, на каком стеке сделано клиентское приложение — спросить. Можно сделать себе чеклист минимально необходимой информации со стороны заказчика и сразу выяснить всё, чего не хватает.
• Рассылка писем: с такими размытыми требованиями можно предложить MVP часов на 150.
• Landing: тут можно с примерами, даже с чужими: такой-то сложности — столько часов, такой-то сложности — столько.

Форма хорошая, контент плохой

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

• Нам нужна интеграция с Google Spreadsheets API.
• (Рассказ на 5 минут, о том, что вся команда уверенно пользуется Spreadsheets и в портфолио есть проект с интеграцией Google Maps).
• Позвольте, но это же совсем не то.
• (Еще 5 минут про то, что это все то же самое и, конечно, Google Spreadsheets API сделают).

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

Однажды искали очень узкого специалиста, пусть для примера будет «дизайнер по отрисовке кнопочек». Требования к исполнителям оформили предельно конкретно, с условием показать примеры отрисованных кнопочек. Опуская тему того, что в IT узкоспециализированные кадры — это редкость, и понятно, что портфолио из одних кнопочек — днем с огнем, но практически никто не постарался сделать выжимку из скринов с кнопочками. Основной посыл: «Можем всё, вот портфолио на 30 работ». Заказчики к этому довольно просто относятся: «Кто-то рассказал про опыт работы с кнопочками? Нет? Ищем дальше». Поэтому если ищут Google Spreadsheets API опыт, ключевые слова Google и API отдельно друг от друга не сработают. Лучше расскажите про похожий опыт, если непосредственно запрашиваемого нет.

Не понимает, что продает

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

Тут приведу диалог с человеком (Ч), который никогда в жизни услуги разработки софта не продавал, но имеет маркетинговый бэкграунд:

Я: Today’s one was a manager with zero understanding of what he’s selling.
Ч: Ah, sounds like the original team i hired.
Я: Did you eventually find the better ones?
Ч: Don’t really need a person for it.
Я: I’ve never seen good salespersons of software development besides the people who were developers themselves.
Ч: Yeah, you don’t want to talk to an inexperienced person who doesn’t know anything about what they’re selling.
Я: Yeah, no one wants to talk to them but there are so many for some reason.
Ч: I mean u can have a junior person but they should start the call off with
«just so you know, I’m not a software developer — I’m the sales person and it’s my job to learn about the project, tell you more about our company and gather more details so, if things look like they can be a fit, we can schedule our next call w the lead developers».
Я: 99% panic and switch to «I don’t know, I’m not a technical person, I’ll need developers/PM to help you».
Ч: Yeah and if the client is like
«why don’t your devs juts join the call now?»
«we’ve got a small team and we’re very focused on making our clients the very best software products we can. That’s why we like to let the dev’s focus on building, while we help out with gathering requirements for new opportunities, and making the next call with them as productive as possible».

Не ценит время

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

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

С другой стороны, время тратится, когда сейлз-коллега спрашивает у команды информацию, которую сам может найти. Работаем мы с node.js? А что такое MEAN? А какие мы делали похожие проекты?

Совет:гуглить новые термины, знать портфолио и уметь находить в нем нужное.

Не привносит полезности

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

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

Не знает свои ресурсы

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

Совет:есть смысл в кооперации с HR/PM поддерживать актуальным список скиллов компании. И общаться с разработчиками побольше. Узнавать, чем кто интересуется, кто что хвалит, кто что ругает и почему. Читать потом про то, что упоминали коллеги.

Bonus: виноват клиент

Не то чтобы это паттерн, скорее кулстори, встречается редко. Компания работает по fixed quote (что само по себе довольно тяжелая модель из-за хронического back&forth что было включено, а что нет), сделала проект, клиент пошел принимать и отдал список багов на исправление. Подрядчик в ответ жалуется, что не ожидал QA от клиента, которое будет пытаться найти все баги. И вообще они столько всего уже сделали out of scope, что надо бы доплатить уже, а вы еще и багфикс хотите!

Не скажу, как тут правильно поступать. Выглядит со стороны подрядчика непрофессионально, но может сработать :)

Выводы

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

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

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

У КНУ є 4 факультети, напрями підготовки яких пов’язані з IT:

• механіко-математичний факультет;
• факультет інформаційних технологій;
• факультет комп’ютерних наук та кібернетики;
• факультет радіофізики, електроніки та комп’ютерних систем.

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

Механіко-математичний факультет

На факультеті готують фахiвцiв зi спецiальностей «Математика», «Статистика», «Механiка», «Комп’ютерна математика», «Комп’ютерна механіка», «Комп’ютерна статистика та аналіз даних».

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

Мехмат святкує 77-річчя

Окремі магістерські програми на факультеті ведуть англійською мовою. Також студенти факультету мають можливість продовжити навчання за кордоном у рамках міжуніверситетських договорів. У рамках угод про співробітництво діють спільні навчальні програми, зокрема такі: програма з актуарної та фінансової математики (спільна магістерка з Університетом Ульма в Німеччині), програма з актуарної та фінансової математики (спільна магістерка з Університетом міста Тарту (Естонія) та інші програми в Франції, Канаді, США та Туреччині. Для магістрів діє спільна програма разом із Київською школою економіки, передумовою навчання на якій є складання іспиту англійською мовою (саме навчання теж ведеться цією іноземною).

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

Заняття бізнес-школи КНУ

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

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

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

(Марія, 3 курс)

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

(Дмитро, випускник)

Головні враження від навчання: ніхто ніколи не просить хабарів (на відміну від більшості факультетів КНУ); якщо ти не вивчив на мінімальному рівні 7 різних математик, то не довчишся; зі 150 студентів на старті платників було до 5.

(Тарас, випускник)

Факультет інформаційних технологій

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

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

Студенти факультету інформаційних технологій здобули друге місце у міжнародному конкурсі зі створення комп’ютерних ігор Global Game Jam Ukraine 2017

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

Студентам факультету дають освіту за принципом «навчання через практику». Основна увага приділяється практичній підготовці у сферах: програмування; створення інформаційних систем та технологій управління підприємствами; проектування та розробка комп’ютерних мереж і систем; розробка інтелектуальних систем майбутнього; інтелектуальне програмування; захист інформації та інформаційних технологій і систем; побудова інформаційно-комунікаційних систем.

Захист дипломів у магістрів

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

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

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

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

Серед інших, можуть здатися зайвими деякі предмети, які насправді роблять із вас досить різностороннього спеціаліста, що може застосувати свої навички у багатьох сферах. Я вважаю, що КПІ та факультет кібернетики дають більш фундаментальні знання, проте я, як і інші студенти, мав змогу працювати та практикуватись уже з першого курсу, тому на кінець четвертого я зміг отримати досвід роботи, та навіть змінити напрям діяльності. Також факультет досить лояльно ставиться до програми Work&Travel, що турбує багатьох, тому, наскільки мені відомо, студенти 3 та 4 курсу мали змогу долучитися до неї.

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

Вчимо ми переважно C#, проте на різних кафедрах у різних групах вивчаються додатково інші мови, зазвичай вищого рівня.

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

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

(студент, анонімно)

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

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

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

Програмування у нас вивчається на середньому рівні, нас 2 роки вчили С# (що і вплинуло на вибір моєї сфери діяльності). Також нас почали навчати Java на 4 курсі. Вважаю, це трохи запізно, але після нас її на 2 і 3 курсі також почали викладати. Дисципліни, які пов’язані з менеджентом програмних продуктів, викладаються добре, деякі знання навіть знадобилися у реальній роботі. Мінусом також вважаю трохи поганий розподіл обов’язкових гуманітарних дисциплін (у нас їх розтягнули на 4 роки). Краще було б на перших двох курсах все вичитати.

(студент 4 курсу)

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

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

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

Наскільки мені відомо, у факультету в планах зробити так, щоб ІТ-компанії розміщували у нас свої філіали, а ми змогли безкоштовно проходити практику. Також проводять конференції із ІТ-спеціалістами (виступали із того ж самого EPAM та була представник компанії Microsoft).

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

Подобається, що багатенько різної математики, предметів, що вимагають математичного і «програмувального» мислення: чисельні методи (Mathcad/Matlab/C++), теорія алгоритмів (C++/Java), комп’ютерна графіка (Photoshop/Illustator). Завдяки тому, що у нас різноманіття предметів, кожен може знайти собі те, що йому найбільше подобається і в чому би він на далі зміг себе розвивати.

(анонімно, 2 курс)

Факультет комп’ютерних наук та кібернетики

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

ML+AI Hackathon на факультеті

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

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

Конкурс «Міс Кібернетики»

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

Загалом я дуже радий з того, що навчався на факультеті. Програма навчання досить хороша, однак аж занадто різнобічна. Вчили всього потрохи, а детально мало що. Було б значно краще, якби була можливість обирати, куди розвиватися, оскільки я вже на 3-мукурсі працював по півдня і вже знав, що мені треба і пригодиться, а що — ні. Мені абсолютно не стали/стануть в пригоді знання ілюстратора, латеху, 1С і т. п., тому я по мінімуму старався займатися ними. Але все ж від здачі лабораторних/заліків/екзаменів не втечеш. З іншого боку, багато предметів, які пригодились/можуть пригодитись в майбутньому, або ж просто цікаві для вивчення. Мов програмування «вивчали» ми дуже багато, тому, звісно, що досить поверхнево: C++, Java, Python, Ruby, Prolog, Haskell, Matlab. Для загального бачення це класно, але нема можливості поглиблено вивчати ту мову, яка сподобалася.

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

(Андрій, випускник)

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

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

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

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

(анонімно, 3 курс)

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

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

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

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

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

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

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

Найголовнішим для мене, звичайно, були курси, пов’язані із практикою програмування. На жаль, загалом цей блок був особливо хаотичним. Були курси (наприклад, бази даних, паралельні обчислення, об’єктно-орієнтоване програмування), що давали непогані, але дуже базові знання. Деякі курси (наприклад, верифікація і валідація програмних систем, сучасні мови програмування) викладалися з відставанням у 10 років від поточного стану справ у індустрії. Інші курси (наприклад, обчислювальна геометрія, програмування, алгоритміка, парадигми програмування, розподілені системи) не давали самі по собі великої кількості знань, проте завдяки цікавим і складним лабораторним заохочували здобувати їх самостійно. Деякі важливі курси не давали і не вимагали серйозних знань для здачі, а перетворювали у малопов’язані із предметом розповіді викладачів «за життя» — наприклад, комп’ютерні мережі, інформаційна безпека. Курси пов’язані із soft-skills у програмуванні («Програмна інженерія», «ІТ-менеджмент», «Аналіз вимог», «Командна розробка», «Комерціалізація об’єктів інтелектуальної власності») виглядали абсолютною вигадкою, непов’язаною із реальністю останніх 10 років у порівнянні із тим, що ми бачили, працюючи в ІТ-компаніях. На старших курсах було багато спецкурсів із маловиразними назвами («Інтелектуальні технології», «Інформаційні мережі», «Інформаційні технології», «Математична біологія», «Штучний інтелект» та інші), що насправді часто виявлялися поверхневими лекціями на слабкопов’язані теми з абсолютно тривіальними лабораторними роботами.

Щодо мов програмування, які ми вивчали: С++ — як перша мова програмування, Java — два дуже базових і застарілих курси і кожного разу спочатку, PHP — декілька дуже простих лабораторних, Prolog, Haskell, Lisp — нескладні лабораторні, SQL — середній рівень. На деяких курсах викладачі давали постановку лабораторної задачі і повну свободу у виборі технологій і способів розв’язку, що завжди давало можливість вивчити щось нове і цікаве. На інших — навпаки вимагали використовувати технології, забуті усіма ще 10 років тому, наприклад, CORBA.

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

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

(Ярослав, випускник)

Факультет радіофізики, електроніки і комп’ютерних систем

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

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

Студентів факультету нагородили грамотами за активну участь у профорієнтаційних та іміджевих проектах університету

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

Факультет має налагоджені наукові контакти з університетами та науковими установами США, Бельгії, Німеччини, Франції, Нідерландів, Данії, Тайваню, Кореї, Іспанії, Італії тощо.

День відкритих дверей

ФРЕКС готує фахівців до наукової кар’єри, випускники, які бажають розвиватися в цьому напрямі, стають працівниками установ НАН України: інститутів фізики, фізики напівпровідників, металофізики, ядерних досліджень, фізіології; галузевих інститутів і конструкторських бюро; а також державних та приватних підприємствах.

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

Програма на 4.5/5, відповідних спеціалістів-радіофізиків вона чудово готує, усі мої однокурсники, які хотіли займатися радіофізикою професійно, нею займаються. Застарілих предметів було мінімум. Якщо говорити про фізику, то все чудово, я навіть їздив у 2012 році в Москву на міжнародний турнір фізиків за державні гроші, реалізуватися можна повністю. Але мені більше подобалося програмування, і тут програма універу перетиналася відсотків на 20. З іншої сторони, у нас були курси Cisco, пройшовши які цілком можна було стати сертифікованим інженером, але це вже було на 5 курсі, коли я зі своїм напрямком цілком визначився. Проте це були справді найсучасніші курси і знання.

Викладачі, окрім перших курсів, у 90% випадків ставилися з повагою.

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

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

(Іван, випускник)

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

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

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

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

(Максим, 2 курс)

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

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

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

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

(Іра, 2 курс)

Передусім програма побудована так, щоб дати базові знання в різних галузях, в яких може працювати майбутній спеціаліст. Варто відзначити, що програма щорічно модифікується, і навіть з‘являються нові спеціальності. Це свідчить про те, що факультет працює над підвищенням рівня викладання. Особливо корисні лабораторні практикуми. На ФРЕКСі маємо можливість навчатися й працювати на сучасному мережевому обладнанні від Huawei, IBM.

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

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

Цікавими є проекти нашого Студентського парламенту. Великою і потужною командою ми створили коворкінги Vault 33 і «Лунотека», а також маємо отримати 2 млн грн з місцевого бюджету на реалізацію проекту лабораторії робототехніки та альтернативної енергетики Smart Rex, що став переможцем конкурсу «Громадський проект».

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

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

(Роман, 1 курс магістратури)

Програма навчання не у всьому є продуманою. Є непотрібні гуманітарні предмети, але немає тих, які, на мою думку, були б необхіднішими. Наприклад, українська мова. Хоча б ділова українська. Більшість викладачів є професіоналами своєї справи, особливо не гуманітарних напрямків, що, особисто для мене, є важливим.

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

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

(анонімно, 3 курс)

Резюме

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

Катерина Несмелова — QA з понад десятирічним досвідом, одна з небагатьох в Україні, хто отримав сертифікацію Full Advanced Level ISTQB. Вона працює Test Lead у внутрішньому ІТ-відділі компанії PricewaterhouseCoopers (PwC) в Digital Transformation Team у Новій Зеландії. Маючи за плечима багаторічний досвід тренера з підготовки до ISTQB, Катерина Несмелова розповіла про те, як успішно здати цей екзамен і чому досвідченим QA це вдається важче, ніж початківцям, підготовку до релокації, розвиток ІТ-сектора у Новій Зеландії й хто такий «справжній тестувальник».

— Раніше ви займалися здебільшого Quality Control. Зараз ви — Test Lead у PricewaterhouseCoopers (PwC) в Digital Transformation Team, а це інший бік тестування. Розкажіть про це.

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

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

— В чому специфіка вашого відділу?

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

Зараз усі ми потрохи просуваємося в бік continuous deployment — програміст пише код, тисне кнопку й за дві години цей код вже в Production. Частіше за все, це якась дуже маленька зміна. До прикладу, частка нового функціоналу або частика виправлення дефекту. У тестувальників вже немає ані можливості, ані часу використовувати старі підходи. Код вже не деплоїться в Production великими шматками кілька разів на рік. Крихітні шматочки вистрілюють чи не кожну годину. У червні робитиму про це доповідь на конференції The Australia and New Zealand Testing Board 2018 (ANZTB2018).

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

Тестувальник перестає бути просто тестувальником, він стає більш T-shaped професіоналом, який має багато знань із сумісних областей. Коли програміст натисне кнопку задеплоїти код, ми вже не можемо нічого змінити чи протестувати, адже продукт вже пішов в Production. Ми повинні тестувати набагато раніше, починаючи зі стадії ідеї, та щільно співпрацювати з командою. Звичайно, є певні засоби, завдяки яким можна тестувати й в Production — feature switch, коли новий код є доступним лише для команди розробників, але не для юзерів. Але якщо щось хибне, навіть якщо воно не доступне для користувача, це може зруйнувати живу Production базу даних.

— Як ви потрапили в ІТ?

Це був смішний випадок. З 1998 по 2004 рік я працювала викладачем комп’ютерних дисциплін для нетехнічних фахівців, на кшталт фінансистів, економістів, менеджерів, у Харківському національному аерокосмічному університеті (ХАІ за тих часів). Якось в обідню перерву мій колега, що працював паралельно в одній ІТ-фірмі, сказав, що їм потрібні програмісти з добрими знаннями англійської мови, мова навіть важливіша за навички в програмуванні. В нас студенти не знали ні мови, ні програмування. На той час я англійську знала досить добре, програмування — в рамках своїх курсів — Pascal, Delphi, трішки С++, бази даних. Я вирішила спробувати й опинилась на посаді тестувальниці. Працюю вже п’ятнадцять років, й ніяк не відпускає. Випробовую різні галузі, напрямки, підходи, різні країни. Коли нудно, пробую себе в іншій ролі.

— Як виглядали ваші перші дні в новій професії?

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

— Як далі склалась ваша кар’єра в ІТ?

У першій компанії я пропрацювала близько чотирьох місяців. Там вважалось, що вершина кар’єри тестувальника — це стати програмістом. Мені це не подобалось, тому я вирішила шукати своє місце. Далі була Validio, яку згодом придбав GlobalLogic. Там було багато цікавих та різноманітних проектів, пов’язаних, здебільшого з медициною. Проте за два роки я зрозуміла: так, як там робиться тестування, — не моє. А коли воно зміниться, було невідомо. Тому знайшла маленьку компанію, де займалась тоді ще дуже новою темою data mining. Там я налагодила процес розробки та тестування, але не було перспектив росту. Наступною була EPAM, де я провела три роки, зробивши кар’єру від Senior Software Tester до Test Manager. Напевно, саме там були мої найкращі часи як менеджера. В мене була найкраща команда й дуже цікавий проект, який ми змогли зробити ефективним та розширили нашу команду більш ніж вдвічі.

Згодом я стала мамою. З декретної відпустки вийшла у Murano Software на дуже цікавий стартап-проект, пов’язаний з data centre management, який згодом придбала компанія Ericsson. Це був дуже цікавий досвід з неодноразовими відрядженнями до Сполучених Штатів. Коли ти випадаєш з родинного кола на 3-4тижні — це складно, особливо, коли дитина дуже маленька. Тому постав вибір: кар’єра в цій компанії або сім’я. Я обрала сім’ю. Далі була продуктова компанія TOA Technologies, яку декілька років тому придбав Oracle. Туди я прийшла на дещо іншу посаду — quality assurance manager — людини, яка налагоджувала процес. Нам вдалося поліпшити роботу компанії за рахунок кращого спілкування та взаємодії відділів.

Коли ми вирішили спробувати переїхати до Нової Зеландії, я не знала, чи зможу знайти роботу на позиції менеджера. А для роботи на позиції senior software tester мені був потрібен свіжий hands-on experience, якого на той час я вже довго не мала. Тому я вирішила в деякому сенсі зробити даунгрейд і зайнятись більш технічною роботою, що б допомогло мені знайти роботу саме технічного спеціаліста. Тому я повернулася до Murano Software на інший проект, де займалась більш практичним аспектом тестування. Коли ми переїжджали до Нової Зеландії, в мене вже був підписаний контракт на позицію senior software tester від команії Orion Health. Але знову кар’єрні перспективи були не дуже. Так я й потрапила до PwC на позицію Test Lead. Гадаю, що саме такий різнобічний досвід відкрив мені нові можливості.

— Над чим обов’язково потрібно задуматись перед релокацією?

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

Ключовий момент при переїзді: дослідження потенційних проблем та їх вирішення. Я дуже раджу вивчати всі доступні ресурси — від офіційних до форумів, де мігранти розповідають про деякі моменти, яких ти не побачиш в офіційних джерелах. Там вони діляться власним досвідом. Треба розуміти, чи зможеш ти прийняти всі відмінності й жити з ними. І чи зможеш ти собі це дозволити фінансово. Наприклад, найбільша проблема тут — все дуже дорого. По-перше, оренда житла, потім — їжа. А ще — дуже холодно взимку. Незважаючи на те, що температура дуже рідко буває нижче +5, вдома запросто може бути +7. Потрібно мати план Б у разі, як щось піде не так.

— Який план Б був у вас?

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

— Наскільки швидко розвивається ІТ-сектор в Новій Зеландії, порівнюючи з Україною?

Як на мене, український ІТ-сектор на аутсорсі відверто випереджує Нову Зеландію на 3-5 років.Нова Зеландія — маленька, доволі традиційна, а ще вона дуже далеко від усіх. Там є новинкою те, що в нас вже або давно використовується, або відходить.

— Що ви маєте на увазі?

Зараз тут дуже популярний скрам, всі намагаються його розповсюдити, а в нас він вже відмирає потроху. Півтора роки тому на конференції з програмування один зі спікерів розповідав, як вони налагодили continuous integration за допомогою Jenkins — аудиторія була у захваті. А ми з командою втілювали подібний процес років за п’ять до моєї релокації до Нової Зеландії. Хоча мені здається, що Україна і Нова Зеландія йдуть в одному напрямку — намагаються бути просунутими. На жаль, часто це відбувається у вигляді карго-культу, коли люди починають буквально копіювати все одразу з думкою, що на виході вони отримають такий самий результат. Але при цьому зовсім не беруть до уваги локальний контекст, поточні умови проекту, навички та настрої команди. Це відноситься до скраму, continuous deployment, big data тощо.

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

— Як ви оцінюєте розвиток спеціальності QA-інженера в Україні та у світі загалом?

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

— Чому?

Як можна автоматизувати, наприклад, user experience? Чи зручно юзерам використовувати нашу програму для вирішення їхніх проблем? Чи ефективно з точки зору кінцевого користувача це виходить? До того ж, перш ніж щось автоматизувати, треба розуміти, що ж саме необхідно зробити, і як це зробити найефективніше. Для мене автоматизація — це спільна робота тестувальника та девелопера. Хтось краще пише код, хтось краще розуміє, що саме потрібно перевірити і як. Дуже часто я бачила «автоматизаторів», які були, як морська свинка — ані код писати не вміли, ані в тестуванні не розбиралися. Справжніх профі я бачила дуже мало.

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

— Чому ви не хотіли перейти в інший розряд, наприклад, програмування? Чому сьогодні не спостерігається особливої тенденції в ІТ, коли тестувальники без вагань стають програмістами?

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

— Чи не вичерпали ви для себе QA?

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

— Ви написали статтю для журналу «Testing Trapeze», де зазначили, що успішний тестувальник — це не лише той, хто вміє створювати SQL-запити, автоматичні чи мануальні тести, знає бізнес-домен, словом, «tech pro». Хто такий справжній тестувальник?

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

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

— У тексті ви говорите про ваш девіз «People matter». Як він виник?

People Matter — це гра слів: з англійської це перекладається водночас як «люди важливі» і «те, що стосується людей». Для чого програміст пише код? Щоб результатами роботи цього коду так чи інакше користувалися інші люди. Космонавт летить до космосу за новими знаннями, щоб згодом їх передати іншим людям. Еколог рятує рідких тварин для того, щоб їх побачили наступні покоління людей. На жаль, це не всі розуміють. Деякі програмісти вважають, що пишуть код виключно заради написання коду, і взагалі не думають про кінцевих користувачів. А кожен проект — це люди, які створюють продукт та підтримують його, й ті, хто ним потім користуватимуться. Чим більше я читала книжок з психології, бізнесу та управління, тим більше я переконувалася: все, що ми робимо — робимо для людей.

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

— Ще в одній зі статей на LinkedIn ви писали про своє розчарування тим, що у Новій Зеландії випускників комп’ютерних наук не навчають належним чином тестуванню, й вони мають лише туманне уявлення про це. Чому так?

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

Коли через декілька років в IT я звернулася до рідного вишу з пропозицією викладати тестування студентам-програмістам, мені відмовили: все це дуже добре, але нам потрібно своїх аспірантів просувати. Спеціальності «Тестувальник програмного забезпечення» тоді не було взагалі. Я не знаю, чи є вона хоча б в одному українському виші. Єдина надія на ХНУРЕ. В Новій Зеландії також ніхто не готує професійних тестувальників, і не викладають тестування окремою дисципліною для студентів-програмістів. Ситуація майже така ж сама, як була в Україні.

— Розкажіть, як ви здобули сертифікацію Full Advanced Level ISTQB та з чого усе почалось? Чому вирішили сертифікуватись?

На той час проект, яким я займалася, закінчився, а нового мені ще не знайшли. Я діставала своїх директорів, мовляв, дайте мені якийсь проект, мені треба чимось зайнятись. Дали: отримай сертифікат. Тоді я почала міркувати, яку саме сертифікацію краще отримати та найголовніше — навіщо? Мені хотілося щось таке, що я потім зможу використовувати в своїй роботі. Microsoft, відверто, нічого саме для тестувальників не давав, тому він відпав одразу. Єдиний доступний в Україні був ISTQB. На ньому я й зупинилася. А ще мені дуже кортіло дізнатися, чи відповідаю я міжнародному рівню в своїй роботі. Наскільки ми, тестувальники з усього світу, спілкуємось однією мовою?

Я зібрала всіх тестувальників, що тоді працювали в харківському офісі ЕРАМ. Ми почали дискутувати щодо глосарія. Виявилося, під одним і тим ж терміном ми розуміємо зовсім різні речі. І саме це дає ISTQB — базовий рівень спільного глосарію й спільного контексту, таку собі точку опори. Звісно, ISTQB не панацея. До всього треба ставитися критично. Але саме в Foundation Level є багато здорового глузду.

— Наприклад?

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

— Як проходила ваша підготовка до іспиту та яка її роль?

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

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

— Чому? Важко перевчитись?

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

— Що варто прочитати під час підготовки до екзамену?

Раджу починати з курсу «Learning how to learn»на Coursera та книжки «Make it stick»Пітера С. Брауна. Ці ресурси вчать ефективно вчитися. Тоді до якого б іспиту ти не готувався, його буде складено успішно. Також нещодавно прочитала дуже цікаву книжку Насіма Талеба «Чорний лебідь». Основне, що я з неї винесла — це розуміння того, що все наше життя керується випадком. Ще один важливий здобуток, особливо важливий для критичного мислення в тестуванні, — це silent evidence, мовчазні докази. Стів Джобс став тим, ким він був, адже йому постійно таланило, обставини складалися вдало. А скільки було людей, так само талановитих, як Джобс, але які народилися не в тій країні, не тої статі, для яких обставини склалися не на їхню користь? Книжка також допомогла мені зрозуміти, як підвищити можливість того, що щасливий випадок трапиться, та мінімізувати наслідки нещасного.

Загалом класикою підготовки до іспиту ISTQB як Foundation, так і Advanced, є книжки Рекса Блека «Foundations of Software Testing ISTQB Certification»та всі три томи «Advanced Software Testing». Не принципово, яку саме книжку читати. Важливо те, як ти це робиш. В книжках потрібно знаходити відповіді на питання.

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

— Що підштовхнуло вас до проведення тренінгів?

Усе почалося у 2008 році, коли я складала ISTQB Foundation Level. Ми вирішили розглянути, як команда знає глосарій ISTQB. Що означає той чи інший термін? З цього мій тренінг і народився. Мені дуже закортіло спілкуватися однією мовою зі всіма тестувальниками та вчитися досвіду інших людей. Потім на тренінгу з тест-менеджменту мені пощастило познайомитися з чудовою дівчиною Вікторією Мусіяченко, організаторкою цього тренінгу. Ми говорили про те, що тренінгів для тестувальників не так і багато. Люди хочуть готуватися до іспиту ISTQB, а можливості немає, то чому б не зробити тренінг. Так і почалася наша дуже плідна співпраця, яка триває вже 8 років.

— Маєте бажання повернутися в Україну?

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

Меня зовут Максим, я работаю тестировщиком ПО, с интересом слежу за событиями в мире тестирования и IT. Самое полезное собираю вместе и с радостью делюсь с вами. Приятного чтения! :)

Новости

Жизнь после Meltdown и Spectre

Почитать

Качество, что за зверь и как его обнаружить

Расширяем тестирование граничных значений

Шесть проблемв рассуждениях о тестировании

5 тенденций, влияющих на будущее тестирования

Postman — помощь в тестировании REST API

Как тесты из Postman запуститьв командной строке Newman

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

Будни тестировщика, или при чем тут пирамида Маслоу

Бесконечное путешествие:обучение, тестирование, изучение

На AliExpress найдена уязвимость, которая позволяет внедрять вредоносный код

Переход из тестировщикав руководители проектов

Тестовая документация. Превращаем таблицы в деревья

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

Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста

Не ройте колодцы в тестировании

Как скомпрометироватьсистему документооборота в несколько кликов

QA Guild Podcast EP-1: Тестирование микросервисов

Сделайте тестирование API прощес помощью Karate

Кратко о разницемежду пентестом и сканером уязвимостей

Некоторые возможностиинструмента разработчика в Chrome

Дополнительный заработокдля тестировщика

Тестирование документациик программным продуктам

Занимательная историяпро важность логирования и соблюдение регламентов

Тестирование глазами разработчика: инструменты, мифы, ситуации

Разбери бэклог

Нагрузочное тестирование «не-HTTP». Ч.1 JMeter

Нагрузочное тестированиена фреймворке Gatling

Сложно о простом: как измерить время открытия страницы и не нажить себе врагов

Автоматизация

Антипаттерны в тестах

Топ 10 инструментов автоматизации тестирования 2018

Автоматизация тестирования REST APIпри помощи Postman и JavaScript

Jest и Puppeteer: автоматизация тестирования веб-интерфейсов

Настройка системы WEB — тестирования на основе headless chromium-browser, chromedriver, nightwatch и node.js на Ubuntu

Руководство: Cucumber + Java

Как ускорить UI тестированияиспользуя AWS Lambda

Мутационное тестированиена простом примере

Не совсем новый, но полезный материал «Автоматизация тестирования от „А“ до „Ы“»

Как мы в Positive Technologiesвнедряли идеи DevOps

Чтение документациикак средство от граблей и костылей

Нагрузочное тестирование, история автоматизации процесса

Юмор

Новая многообещающая методология разработки, которую уже назвали «убийцей Agile»

Исправление багов — занятие веселое...

Большое спасибо Татьяне Скрипник, Вячеславу Мирошко и Юлии Атлыгиной за интересные материалы! Пишите еще.

Все желающие делиться интересным — пишите на почту salnikov.maksim@gmail.com, обсудим, опубликуем, скажем, спасибо :)

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

Здравствуйте, коллеги. Меня зовут Евгений Пилипенко, и сегодня я предлагаю вашему вниманию дайджест новостей из мира Go.

Новости

What’s New and Different in Go 1.10 — обзор нововведений, которые нас ждут в Go 1.10. Уже сейчас можно ознакомиться с новыми возможностями, скачав последний релиз 1.10 Beta 2.

Почитать

Don’t just check errors, handle them gracefully — обработка ошибок в Go.

How To Embed Versioning Information In Go Applications — подход к версионированию в Go бинарниках.

Understand Go Pointers in Fewer Than 800 Words — Dave Cheney объясняет, что такое указатели.

The Go Type System — подробно о системе типов в Go для новичков.

The Ultimate Guide to Writing a Go Tool — подробное руководство по написанию утилиты для Go.

Микросервисы, gRPC и Kubernates — введение в разработки микросервисов на Go c использованием gRPC и развертыванием в кластере Kubernates.

Пошаговое руководство по написанию сервиса для Kubernetes

Туториалпо разработке Facebook бота используя Go и Messenger API.

Implementing 6 Sorting Algorithms — 6 алгоритмов сортировки, имплементированных на Go.

A Guide to Effective Logging in Go — основы логирования в Go, стандартизация логов, минимизация влияния на производительность.

A Million WebSockets and Go — разработка высоконагруженного WebSocket-сервера в mail.ru.

Building a RESTful API with Go — туториал по разработке RESTful API на примере приложения «Телефонная книга».

Http Rate Limit — туториал по тому, как сделать rate limit запросов в вашем API.

Reading files in Go — неплохая статья с описанием нескольких способов чтения файлов.

Calling Go functions from other languages — вызов функций Go из других языков c примерами для С, Python, Ruby, Node и Java.

Basic testing patterns in Go — основные шаблоны тестирования в Go.

5 Advanced Testing Techniques in Go — статья для тех, кто хочет повысить уровень тестирования своих приложений.

Automating Go Development with ‘make’ - отличная статья с примерами автоматизации разработки при помощи ‘make’.

Don’t afraid of makefiles — еще один пример того, как можно улучшить процесс разработки используя ‘make’.

Go Concurrency Patterns: Pipelines and cancellation — реализация одного из concurrency паттернов.

Pipeline Patterns in Go — три примера использования pipeline паттерна.

Write a Mini Load Balancer to Learn Concurrency in Go — автор предлагает разобраться с concurrency, написав простой load balancer.

Посмотреть

Capital Go 2017: Buffalo — Rapid Web Development in Go — знакомство с Web фреймворком Buffalo.

dotGo 2017: Debuggers from scratch — Liz Rice объясняет, как работает отладчик.

dotGo 2017: Machine Learning and Go — краткое введение в машинное обучение с использованием Go.

just forfunc #26: why are there nil channels in Go?— автор пробует разобраться, зачем нужны nil каналы.

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

Awesome Go: 1200+ Go Links, Library and Tools — потрясающий список различных библиотек и инструментов.

go-web-framework-stars:список фреймворков для Go с наибольшим количеством звезд на GitHub.

Go Play Space:— экспериментальная альтернатива Go Playground с подсветкой, темами и keyboard shortcuts.

HttpLive:— сервис, позволяющий mock’ать HTTP запросы.

Hermes:— генератор responsive email сообщений. Портирован с библиотеки Node mailgen.

Telebot 2:— фреймворк для разработки telegram ботов.

Config: configuration library for Go — работает с переменными окружения, JSON файлами и умеет автоматически перезагружаться при SIGHUP.

go-base: Boilerplate для построения RESTful API.

Colly:— фреймворк для парсинга.

kurly:альтернатива curl написанная на Go

Pixel:библиотека для разработки 2D игр.

Sergey Hobotсоздал канал с новостями из мира Go в telegram, подписывайтесь :)

Дайджест создан в соавторстве с Егором Папышевым.

00h > Интро

Приветствуем! В этом выпуске: уязвимости в продуктах известных вендоров, организаторы NoNameCon запускают CFP, M.E.Doc снова в центре внимания.

01h > Горячее

Однозначно самое знаменательное и отчасти скандальное событие в отрасли информационной безопасности — обнародование уязвимостей в современных процессорах: CVE-2017-5753, CVE-2017-5715, CVE-2017-5754. И публикация вариантов их эксплуатации (PDF): Meltdown, Spectre. Более подробно со всем этим можно разобраться, прочитав статьюребят из Project Zero. С наглядной демонстрацией использования Meltdown можно ознакомиться тут.

Отдельно стоит рассказать о драме, которая развернулась в сети после предложенных патчей, которые затрагивают производительность системы в целом. Очень много людей жаловалось на то, что после применения патчей совсем невозможно играть\работать\открыть терминал или упал сервер на AWS\Azure. Если некоторые жалобы были обоснованы лишь паникой и суетой, то патчи от Microsoft сделали свое темное дело, вследствие чего пропатченные OC перестали работатьна старых процессорах AMD, как собственно перестали грузиться и некоторые виртуалкина Azure.

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

Организаторы NoNameConначали поиск докладчиков, открыв официальный CFP. Конференция обещает быть крутой, так что откладываем всё и спешим отправлять заявки! ;)

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

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

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

Я думаю, что большинство наших читателей помнят плачевную ситуацию вокруг M.E.Docи роли этого вендора в масштабной атаке на инфраструктуру Украины. Судя по посту Sean Townsend — урок так и не был извлечен. У нас всего один вопрос: «Доколе?».

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

Пользователь Twitter YoptaScriptпишет, что разработал 0-Day RCE эксплойт под Google Chrome. Если это правда, то стоимость этого инструмента на черном рынке может достичь сумм c 5-юнулями.

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

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

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

Появилась свеженькая RCEв Oracle Weblogic, основанная на уязвимости в механизмах десериализации.

Также исследователи не обошли стороной и продукты Cisco, в результате чего выкатили в свет замечательную RCEпод Cisco IOS.

LPEна Linux системах через уязвимость в VMWare Workstation.

В современном мире, наверное, уже никого не удивить различными backdoor в продуктах мировых брендов. На этот раз оный был найден в D-Link DNS-320.

Уязвимостьв ОС Sony PS4 версии 4.05 позволяет сделать джейлбрейк и обойти механизмы защиты контента.

05h > Фан

Свой антивирусдля родителей предложил один из пользователей Twitter. Мы уверены, что в наших реалиях это также подойдет большинству пользователей ПК.

На фоне бурного обсуждения, какие CPU уязвимы к Spectre & MeltDown, а какие нет, эта картинкапредельно просто проясняет ситуацию.

06h > Аутро

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

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

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

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

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

Кому, як не їм знати, що справді важливо для хорошого спеціаліста?

Лінь

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

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

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

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

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

Заздрість

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

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

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

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

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

Жадоба

Aim for the stars!

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

Чому ти вважаєш, що галера — це твій вищий рівень? Ти пробував потрапити в Ґуґл? А хоча б у Амазон? Чи може навпаки, є сенс зібрати свій власний стартап і переплюнути цих зажравшихся стариганів?

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

«Ой, та я ж нічого не шарю...» Fake it till you make it! У більшості випадків шанс випадає не тим, хто його заслуговує, а тим, хто був поруч у потрібний момент.

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

Гординя

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

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

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

P. S. Є, звісно, ймовірність, що одного разу випадково заберешся занадто високо і відкусиш шматок, який не зможеш прожувати. Що ж, тоді і навчишся головного софт-скіла — делегування. Головне ж не команда зірок, а команда-зірка, чи не так?

Ненаситність

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

Проекти часто обмежують можливості росту і розвитку, але нащо тобі вільний час? На велосипеді і на пенсії можна покататися. А ввечері натомість можна почитати, що там намодулярили у дев’ятій джаві чи про брейкінґ-зміни нового Реакту. Або про те, що ж там поміняли у докері, що всі стали його хоронити.

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

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

Гнів

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

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

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

Ламборґіні почав робити машини, коли Ферарі не послухав його поради, а натомість послав «робити і далі свої трактори». От і ти не тамуй у собі злобу, покажи їм всім, як правильно будувати маркетингову політику стартапу!

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

Пристрасть

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

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

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

А інакше — ніяк.

Меня зовут Иван Бондаренко, я Senior Software Engineer и Ruby Technical Lead в CHI Software. Опыт разработки — 6 лет, из них последние 5 — я работаю с Ruby. До этого я программировал 1 год на PHP. Имея за плечами опыт преподавания (я вел курсы по Ruby в Spalah), я решил максимально доступно рассказать об этом языке программирования, поделиться опытом с начинающими специалистами и, возможно, заинтересовать кого-то из них Ruby.

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

Основные особенности и отличия Ruby

Часто слышу вопрос: стоит ли учить Ruby? Как правило, вопрос основан на сомнениях: насколько легко найти работу с данной специализацией, будут ли интересные проекты и так далее и тому подобное. Ruby — современный, постоянно развивающийся язык программирования, областей применения ему — масса. Наверняка вы слышали про Chef, Vagrant, Homebrew, но чаще всего все мы слышим о Rails. Вот постс комментарием самого автора фреймворка о том, почему стоит учить Rails.

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

Ruby — интерпретируемый, полностью объектно-ориентированный язык программирования с четкой динамической типизацией. Он сочетает в себе Perl-подобный синтаксис с объектно-ориентированным подходом. Также некоторые черты заимствованы из языков программирования Python, Lisp, Dylan и CLU. Кроссплатформенная реализация интерпретатора языка Ruby распространяется на условиях открытого программного обеспечения. Код, написанный на Ruby, может быть понятен даже человеку, который не разбирается в программировании. На RoR были созданы такие проекты, как Redmine, Twitter, Shopify, Basecamp, GitHub, Kickstarter, Airbnb и другие.

С ростом Node.js популярность Ruby on Rails несколько уменьшилась, но технологические стартапы часто используют RoR благодаря простоте прототипирования. Ruby — 11-йсамый популярный язык в индексе TIOBE.

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

• Многочисленное и доброжелательное комьюнити.
• Довольно высокий порог входа, что означает, что Ruby-разработчик с большой вероятностью имеет опыт работы как минимум с еще одним языком программирования.
• Вы используете только те библиотеки и модули, которые необходимы.
• Существует большое количество полезных библиотек, которые уже готовы к использованию (Ruby Gems).
• В интернете есть много информации по Ruby, в структурированном и отсеянном виде.
• В контексте обсуждения Ruby нельзя не упомянуть популярнейший фреймворк Ruby on Rails.

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

Скорость разработки

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

Штатные средства кеширования данных

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

Вначале тесты, потом код

Часто в процессе разработки крупных проектов возникает вопрос о тестировании, и не редкость, когда нет дополнительных средств на отдельную команду тестировщиков. В Rails есть решение и этой проблемы. Если сравнивать RoR с другими фреймворками в контексте тестирования приложения, то вы найдете массу готовых решений для любого вида тестов, будь то интеграционные или юнит. Все эти библиотеки работают «из коробки». В идеале в проекте на Ruby on Rails код не пишется до тех пор, пока под него не написаны тесты. RoR идеология предполагает изначальное использование методов BDD (Behavior Driven Development) или TDD (Test Driven Development).

Общепринятые стандарты процесса разработки у Ruby-разработчиков

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

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

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

Готовые решения для многоязычности проекта

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

Высокий уровень защиты данных

Сейчас нередко в сети публикуются статьи о взломах различных ресурсов. Разработчики фреймворка Ruby on Rails очень серьезно отнеслись к проблеме защиты данных. В RoR изначально присутствует шифрование паролей, данных кредитных карт и других личных данных пользователя, также исключены SQL инъекции и XSS атаки. Все входные параметры экранируются по умолчанию.

Изучение Ruby

А теперь поговорим, как именно можно освоить Ruby.

Теория

Начать следует, конечно же, с литературы. Я рекомендую эти источники:

• Ruby за 20 минут — хороший ресурс для совсем начинающих. Позволяет меньше, чем за полчаса ознакомиться с основными конструкциями языка и начать писать свои небольшие программы.
• Codecademy — платформа с онлайн-курсами по множеству направлений, включая чистый Ruby и Rails. Здесь довольно интересно построен обучающий процесс, дается теоретический материал и сразу же практическое задание, чтобы его закрепить. Финальные задания платные, но и без них можно получить нужные навыки.
• Материалы по Ruby и Rails — сборник ссылок на различные сайты и книги, посвященные изучению Ruby и Rails.
• Отдельно могу посоветовать книгу Flanagan D., Matsumoto Y. «The Ruby Programming Language». Она считается одной из лучших, её автор — сам создатель языка Ruby.
• Google :)

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

Вот парочка ресурсов, с которых можно начать:

• w3schools.com/sql — здесь можно почитать, попробовать и проверить свои знания по SQL.
• quizful.net/test — тут можно найти вопросы, которые часто задают на собеседованиях.

Английский

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

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

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

Практика

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

Курсы

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

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

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

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

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

Обратная связь. На уроке вы можете задать интересующий вопрос преподавателю или однокурсникам или просто поделиться опытом. Конечно, то же самое можно сделать и на конференции или митапе, но в отличие от посещения конференций, на курсах у вас будет возможность делать это чаще (обычно курсы проводятся 2-3раза в неделю).

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

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

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

И самое главное — трудоустройство. Говоря о курсах, я не имею ввиду только те, за которые нужно платить деньги. Часто компании сами проводят набор на обучение, чтобы потом лучших взять к себе на работу. Это могут быть внутренние курсы или стажировка/интернатура. Такой вариант — наилучший, так как вам не нужно ни за что платить, вы получаете опыт и все выше перечисленные плюсы и вдобавок — реальную перспективу трудоустройства. Попасть на них сложнее, но перспективы значимее.

Итого

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

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

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

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

Удачи в изучении! А в следующей статье мы поговорим о коде.

Подписывайтесь на наш Telegram-канал для джуниоров, чтобы не пропустить интересные вакансии, стажировки, курсы, статьи.

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

Вера Ткаченко, Software Team Lead в MacPaw

Первая работа — разработчик ПО в CyberVision, 2007 год

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

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

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

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

Хотя вначале очень часто переключали с одного проекта на другой, но тогда очень хотелось попробовать все, и для начинающего специалиста это играло на руку. Возможность быстро попробовать разные технологии, общение с разными командами, с разными людьми, а так как это был аутсорс, то еще и с заказчиками. Я писала не только на Java, но и Python, Lua, HTML, Javascript. Был и необычный мобильный проект телевидения по подписке под Brew на чистом C. Такая экзотическая платформа, о которой сегодня даже и не слышно. Это было очень сложно, не знала, как даже подойти к этой задаче вначале.

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

Тарас Мурашко, co-founder, CTO в EVO

Первая работа — java-разработчик в банке «Аваль», 2001 год

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

На опубликованное резюме, к моему удивлению, откликнулось несколько компаний. Больше всего приглянулось предложение от корпорации «Инком». Меня пригласили работать над проектом по внедрению системы документооборота Documentum в банке «Аваль». В то время они активно развивались в направлении системной интеграции и нанимали много студентов.

Сначала было достаточно сложно. Внедрение Documentum подразумевает знание огромного объема специфического АПИ. Но отличная документация и отзывчивые коллеги помогли мне достаточно быстро освоиться и начать приносить пользу проекту. Еще большим плюсом была быстрая обратная связь от команды внедрения. Это помогло нам сделать замечательный продукт для банка «Аваль».

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

Дмитрий Лапшин, СТО в Sigma Software

Первая работа — junior developer в Validio Software, 2000 год

Поработать на первом коммерческом проекте в ИТ мне довелось, еще когда я учился на 4 курсе ХНУРЭ в 1998 году. У нас в университете с 1996 года существовал «Отряд программист» — своего рода кружок по интересам, куда попадали студенты, которые интересовались программированием и хотели работать на благо родного универа. В первые годы существования отряда мы делали автоматизацию учёта книг в библиотеке, штатного расписания кафедры. Но подобные проекты сложно назвать коммерческими, скорее, они делались для удовольствия и самообразования.

Вместе с тем к концу 90-хмногие начали заниматься предпринимательством, даже госучреждения. В этот момент к нам пришел с реальным заказом НИИ Лазерных технологий (НИИ ЛТ) на базе опытного завода ХНУРЭ. НИИ ЛТ делал матрицы для керамической плитки: выжигали узор с помощью лазера на форме, которая потом использовалась для печати рисунка на плитке. Заказчику нужна была программа моделирования интерьера с возможностью сделать раскладку выбранной плитки на полу или стенах, посмотреть на плитку под разными углами и при разном освещении. Мы с коллегой взялись за этот заказ как самые сведущие на тот момент в отряде в вопросах компьютерной графики. Вначале разработка шла на Borland С++ Builder, но затем перешли на Visual C++ и MFC. Почему перешли, к сожалению, за давностью лет уже не вспомню. Вполне вероятно, к тому моменту популярность Borland уже сходила на нет и очень хотелось получить опыт в MFC, который тогда как раз был «в тренде».

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

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

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

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

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

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

Если же говорить о full-time работе в компании, то моей первой ИТ-компанией стала Validio Software (тогда, в начале 2000-х,она была известна как МИИК, а в конце нулевых была куплена GlobalLogic). Я был зачислен в интернатуру ранней весной 2000 года, а 4 мая был принят на работу как junior developer. По завершении интернатуры меня собеседовали как на С++, так и на Microsoft ASP проекты. Должен признать, что собеседование по С++ я так и не прошел, несмотря на предыдущий опыт из универа и интернатуры: на проекте требовались знания по ATL, с которым до этого я не сталкивался от слова «совсем». А вот на ASP прошел, благодаря тому, что ещё в отряде сделал на нём с нуля простой форумный движок.

Напоследок, хотел бы отметить, что, несмотря на специализацию, с которой меня взяли на первую работу, за первые два-три года пришлось поработать на очень разных технологиях, начиная от написания хранимых процедур в базе данных, и заканчивая JavaScript. Тогда это считалось нормальным, какого-то явного разделения на back-end и front—end разработчиков не было. Разве что, DBA считались отдельной «кастой», а остальные, в той или иной мере, были генералистами. Возможно, потому, что 15-17лет назад разработка ПО была заметно проще, чем сейчас, и объективной необходимости в узкой специализации просто не было.

Андрій Терлига, CTO в Intellias

Перша робота — Software Developer в ПКО «Політехніка», 2003 рік

Я розпочав свою кар’єру у 2003, навчаючись на 3 курсі «Львівської політехніки» за напрямком «Комп’ютерні науки». До нас з одногрупником звернувся один з керівників проектно-конструкторського об’єднання при університеті та запропонував взяти участь у невеликому стартапі. Метою стартапу була розробка продукту для автоматизації обліку пацієнтів у стоматологічних клініках, розрахована на український ринок. Ми з колегою особисто працювали майже над усіма етапами процесу розробки — збирали вимоги, створювали UX та UI, проектували архітектуру, розробляли та тестували продукт. Як для першого комерційного досвіду, результат вийшов непоганим, і після 6 місяців роботи нам вдалось запустити версію 1.0 в продакшн.

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

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

Після короткого пошуку серед наявних вакансій я натрапив на Intellias, які в той час шукали інженера у свій «пілотний» проект для нового клієнта. На початку 2004 компанія налічувала менше 15 людей, а проект-менеджмент виконували особисто засновники. Моїм першим проектом в Intellias була розробка вузькоспеціалізованої CRM-системи для лідера онлайн-ринку деревообробної промисловості. У якості основної технології виступав .NET, який у ті часи тільки набирав популярність. Після CRM-ки було ще декілька проектів з тим самим клієнтом з різним технологіями — вдалось трохи пописати на Java EE, потім на Struts та Spring, було багато JavaScript.

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

Саме так я розпочав свій шлях з Intellias, де залишаюсь і сьогодні, представляючи технічну ланку C-levelкомпанії, та вхожу до складу ради директорів.

Анатолій Литовченко, Head of Software Engineering and Development Office в ELEKS

Перша робота — .NET Developer в DevCom, 2005 рік

Свою першу роботу я знайшов наприкінці третього курсу, коли зрозумів, що в університеті не дають того, що я хочу. Мене цікавило програмування та більш новітні технології. Тоді якраз розпочався бум по технології .NET Framework, з’явилась її перша версія, незабаром друга і т. д. На четвертому курсі я взяв собі книгу по .NET, вивчив її повністю та пішов працювати. Це була компанія DevCom.

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

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

Мій перший запит виконувався десь 40 хвилин. Я його запустив, і далі з’явилось більше та більше завдань, більше технологій. Мабуть, за перші два роки я перепробував все — і С++, і Java, і Visual Basic, і різні бази, щось на back-end та front-end. Єдине, до чого руки не дійшли, — це до мобільних технологій, вони тоді були менш розвинуті, але я це наверстав у наступні роки роботи.

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

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

Після роботи у DevCom була ще серія компаній, через які я пройшов, а потім потрапив в ELEKS, де працюю майже чотири роки. У ELEKS я прийшов як R&D спеціаліст. Півроку попрацював у R&D на presale. Після цього з’явився проект, на який мені запропонували піти у якості ліда або архітектора, я одразу зголосився. Після цього я почав брати участь у розвитку community та працював на посаді competency manager з .NET та згодом доріс до хеда SEDO.

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

У рубриці DOU Проекторвсі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на editors@dou.ua.

Мене звати Микола Мацях — я co-founder, Team Lead та Android developer в команді Trustfel, а також студент програми «Internet of Things» у «Львівській політехніці». Сьогодні я розкажу про наш проект. CleanCity — це сервіс для покращення комунікації між владою та мешканцями міста у питаннях, пов’язаних з вивезенням сміття.

Ідея

Ідея створити CleanCity з’явилась одного разу, коли ми з друзями обдумували, як можна допомогти у вирішенні проблеми з вивезенням сміття за допомогою IT-рішення.

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

В команді, окрім мене, ще 3 співзасновники: Роман — Android developer, Віталій — Fullstack web-developer та Любомир — iOS developer.

Команда CleanCity

Реалізація

Перше MVP з’явилось буквально за декілька місяців і в подальшому одночасно з тим, як ми спілкувались з представниками влади і бізнесу, ми відшліфовували релізну версію проекту.

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

Якщо глянути, що «під капотом», тобто з технічної сторони, то серверна частина реалізована засобами мови програмування Python з використанням фреймворка Flask. Обмін даними між клієнтом та сервером здійснений за допомогою GraphQL. Серверна архітектура побудована за принципом мікросервісів (сервіс email-розсилки, аналіз даних та формування статистики, GraphQL API). У якості бази даних ми застосували PostgreSQL. Також використовувалась БД кешування Redis для збереження часто застосовуваних даних. Увесь сервіс запущено на AWS.

Для панелі адміністратора використовуємо React.js та бібліотеки керування станом додатку — MobX. Зі сторони андроїд-розробки ми застосовували Android Apollo для роботи з GraphQL.

Від ідеї до реалізації пройшло близько 10 місяців. І за цей час ми стикнулися з низкою проблем, в більшості через нестачу досвіду і знань. До прикладу, додаток ми переписували два рази, змінюючи архітектуру і технологію, це забрало досить багато часу. Також нам не вистачало технічних знань, бо особисто для мене це 2-йпроект взагалі. Тут нам допоміг ментор — Віктор Артем’єв — досвідчений андроїд-розробник. Він завжди допомагає, якщо виникають якісь складнощі. Однак це хороший досвід, і на початку 2018 ми зробили ретроспективу 2017 року, де обговорили все і узгодили плани на рік. Це задасть нам вектор розвитку і дозволить швидше рухатися, не вертаючись до чогось і не перероблюючи.

Результати і плани

У жовтні 2017 року ми взяли участь в студентському ідеатоні, де мали змогу поспілкуватися з менторами з різних сфер: юриспруденції, бізнесу, влади. Ми врахували їхні поради та критику і перемогли. Це був дуже цінний досвід, який вплинув на подальший розвиток проекту. Завдяки цій перемозі ми отримали можливість презентувати CleanCity на Форумі Е-врядування 451E, де нами зацікавились представники Кам’янця-Подільського. В листопаді ми подалися в Startup School, де мали багато цікавих лекцій та воркшопів, а також навчилися будувати бізнес-гіпотезу та рахувати витрати.

Презентація на Форумі Е-врядування 451Е

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

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

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

Я начал свою карьеру как специалист в сфере IT еще в далеком 2003 и с тех пор успел поработать на руководящих позициях в таких организациях, как «Укргазбанк» и «Терра Банк», был руководителем IT-департамента Государственного ипотечного учреждения, а с 2012 года активно занимался собственным бизнесом. Я переехал в Новую Зеландию из Киева в феврале 2015. А теперь обо всем по порядку.

О переезде

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

Так вышло, что с 2009 года я практически не занимался «прикладным IT». Я знал, как управлять в IT, и знал, как работает бизнес. У меня была своя IT-компания и стартап в сфере логистики, но все это казалось мне очень плохо применимым к Новой Зеландии. Еще до переезда мне пришлось в срочном порядке постигать азы программирования, работая программистом в собственной компании, и учить английский язык.

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

Самый простой способ эмигрировать в Новую Зеландию — через обучение. После окончания обучения вы получаете рабочую визу сроком на один год на поиски работы. Многие едут именно так. Стоимость обучения варьируется от $12 тыс. до $26 тыс. новозеландских долларов в год (1 NZD ≈ $0.68 — $0.72 USD).

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

IT-рынок Новой Зеландии

Отрасль IT везде сейчас находится на подъеме, и Новая Зеландия не исключение. Здесь работают такие компании, как Microsoft, IBM, HP, SAP, Intel, Canon, Samsung, Lenovo, Datacom, Orion Health, Xero. Хотя крупных компаний здесь много, IT-рынок Новой Зеландии не очень большой. Когда я просматривал сайты, на которых размещаются вакансии (tradme.co.nzи seek.co.nz), по некоторым направлениям (например, Ruby on Rails и ReactJS) в 2015 с трудом набиралось 10 позиций. К слову, сейчас этот показатель намного выше, например 30 вакансий на RoR и около 90 на ReactJS, так что рынок очень активно развивается в последнее время (подробнее об IT-рынке — в моем видео).

Знание языка программирования Go здесь вызывает удивление и недоумение от того, почему ты не в США. Blockchain-технологии воспринимаются как что-то сказочное, фронтендеру на ReactJS могут платить $100 тыс. NZD в год. К слову, минимальная зарплата в Новой Зеландии при 40-часовойрабочей неделе — $32 750 в год. Full stack developer получает в районе $80 тыс. Здесь говорят на английском, оплата труда дешевле, чем в США и Австралии.

Kiwi (так называют себя жители Новой Зеландии) иногда в шутку говорят, что они тестеры. Страна с населением в 4,7 млн отлично подходит для тестирования продуктов и идей, особенно в банковской сфере. Мобильный банкинг, открытие счетов онлайн, прием Swift-платежей через интернет, оформление страховки от банка без осмотра предмета залога, Apple Pay, EFTPOS и многое другое здесь работает просто превосходно. Я до сих пор не знаю, как выглядят некоторые бумажные деньги. В целом у Новой Зеландии очень большой потенциал, но в силу удаленности и относительной пассивности многих местных компании ей есть куда расти. Это просто вопрос времени.

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

Поиск работы

По прилете в новую страну возникает две проблемы: где найти жилье и где найти работу. О первой мы поговорим чуть позже, а вот из-за второй проблемы зачастую многие едут домой. Попадая в новую страну, вы должны понимать, что в большинстве случаев ваш предыдущий опыт просто сгорает. Работа вам нужна не только для того, чтобы зарабатывать, но и для того, чтобы легче было получить резиденство (вид на жительство). В Украине одна из моих компаний занималась разработкой на Ruby on Rails, так что с небольшим опытом работы в качестве программиста я занялся поисками именно по этому направлению.

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

Я проходил собеседования в трех рекрутерских агентствах, четырех компаниях и получил два оффера (имеется ввиду job offer — приглашение на работу). Меня взяли в качестве senior software developer’a в крупнейшую хостинг-компанию Новой Зеландии.

Особенности в работе

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

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

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

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

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

Уровень жизни и жилье

К сожалению, стоимость жизни в НЗ очень высокая, затраты на аренду недвижимости и транспорт довольно велики. Новая Зеландия занимает высокие позиции не только в рейтинге самых безопасных стран мира, но и в рейтинге самых дорогих для жизни стран, при этом дороже таких стран, как США, Австралия и добрая половина Европы. Это одна из стран, которые лидируют в рейтинге несоответствия доходов к расходам. Правительство даже сделало специальный калькулятор, который позволяет посчитать стоимость жизни в НЗ.

Самая большая проблема в Новой Зеландии, которую часто недооценивают, — это стоимость имущества, а точнее соотношение стоимости и качества. Эта проблема одинаково актуальна и для тех, кто хочет купить недвижимость, и для тех, кто арендует жилье. Если вы хотите жить в Окленде, самом большом городе Новой Зеландии (в котором, к слову, намного больше вакансий, чем в других городах), то придется задуматься о том, чтобы купить дом за $1 млн. новозеландских долларов. И этот дом не будет построен из красного кирпича, в нем не будет гаража, чтобы припарковать вашу Tesla, и в нем будет холодно зимой. Жилье действительно дорогое, и в хорошем районе (где хорошие школы), близко к центру может стоить в районе $2-2.5 млн новозеландских долларов. В целом для любой развивающейся страны актуальны высокие цены на недвижимость, и Новая Зеландия не исключение. Если вы в IT, то зарабатывать будете хорошо, но и затраты тоже будут немаленькие.

Спрос на жилье в Окленде просто огромный. Поиски зачастую занимают много времени, многое зависит от того, в какой период года вы приехали. Например, февраль — очень плохой месяц для поиска жилья — приезжает очень много студентов, а вот январь — хороший. Мы приехали как раз в феврале, и поиски заняли у нас практически целый месяц. Когда большой спрос, то выбираете не вы, а вас. За комнату в доме придется платить $250 NZD в неделю (здесь все меряется понедельно). За квартиру в центре $350-400 NZD в неделю (без учета коммунальных расходов, а это еще $200 NZD в месяц. За целый дом — около $700 NZD в неделю. Многие снимают сообща один дом и живут там с соседями. Для тех, у кого дети, вариант не самый подходящий.

Налоги и зарплаты

В НЗ действует прогрессивная налоговая ставка: чем больше вы зарабатываете, тем больше платите налогов. В целом справедливо. Если ваш доход составляет до $14 тыс. в год, вы платите всего лишь 10.5%, с $14 тыс. до $48 тыс. — 17.5% на разницу. Когда доход больше $70 тыс. в год, что в IT-сфере очень распространено, то ставка налогов — 33% на остаток. Все можно посчитать с помощью калькулятора.

Работодатели в Новой Зеландии всегда называют зарплату за год до вычета налогов. Если говорить цифрами, то ваша годовая зарплата сразу после окончания местного университета (без опыта работы) будет в районе 50-55 тыс.,с опытом работы 1-2года около 65 тыс., senior software developer получает примерно 80-90 тыс., team leader — 100-120 тыс., application delivery manager в районе 130-150 тыс.,но путь это очень, очень длинный. Если вы начали как junior, то расти вам до senior developer’a лет 5-10 минимум.Вообще в НЗ не принято давать высокие позиции приезжим, хочешь быть директором — открывай собственный бизнес.

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

Менталитет и жизнь в целом

В Новой Зеландии все очень вежливые. Поначалу ты этому радуешься, а потом начинаешь замечать, что многие улыбки на самом деле не искренние. Многие улыбаются тебе в лицо и говорят гадости в спину. Не все, но такие встречаются. Вообще Окленд — это мекка для эмигрантов, сюда едут все. Здесь очень много жителей Китая и Индии, переселенцев из соседних островов (Samoa, Tonga, Fiji и т. п.), много людей из Великобритании и мало из Европы. В последнее время приезжие очень разбавляют устоявшуюся культуру и образ жизни.

Самовыражение здесь — это очень важно: кем ты хочешь стать в профессиональном плане, что ты хочешь делать в своей жизни, какого пола ты хочешь быть. Тем не менее мне кажется, что мы, украинцы, более свободолюбивая нация. Когда здесь подписывали The Trans-Pacific Partnership Agreement (TPPA), в Окленде была волна протестов против подписания этого соглашения. TPPA подписали и протесты закончились. Здесь принято выражать свое мнение громко, когда никто его не слышит, и молчать, когда спрашивают.

Коррупция на низких уровнях отсутствует как факт, вместо коррупции здесь система. Хотите пойти к врачу — у вас два варианта: ждать бесплатную медицину 2-3недели (или дольше) или заплатить $89 за визит в частную поликлинику, в которой врач пропишет вам Panadol. Хотите записаться в спортзал — не забудьте заплатить joining fee $50. Нет света? — не беда. Сертифицированный электрик окажет вам услуги по ставке $120 час. Забыли повесить в офисе знак о том, что в душе скользкий пол — штраф. С другой стороны, если знак вы повесили, то платить вас не заставят. Полиция, бывает, не выписывает штрафы даже за явные нарушения ПДД.

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

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

Планы на будущее

В последнее время я много думаю о том, где хочу оказаться через 5, 10, 15 лет, и в этих размышлениях нет определенной страны. Я не хочу жить в Украине только потому, что это моя родина. Я не хочу жить в Новой Зеландии только потому, что здесь прекрасная природа или хорошие дороги. Я не хочу жить в США только потому, что это страна персональной свободы. Я хочу получать удовольствие от того, что я делаю, и от самого пути, по которому иду, и не хочу останавливаться на достигнутом. Я хочу менять жизни людей, менять их в лучшую строну, помогать людям добиваться большего. Я не знаю, куда приведет меня этот путь, буду ли я в Новой Зеландии, Австралии, США, Украине или в другой стране, но я пройду этот путь, ведь я уже иду по нему.

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

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

В’ячеслав Володько, iOS Engineer / Team Lead в Lohika

7 років досвіду розробки під iOS

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

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

Swift чи Objective-C?Із моменту випуску Swift у 2014 році для молодших розробників iOS з’явилась певна невизначеність — яку мову програмування вчити. З одного боку, мові Objective-C вже більше 30 років. І, незважаючи на її стрімкий розвиток у 2008-2014,вона не відповідає сучасним вимогам швидкості розробки, безпечності, а також вимагає досить серйозного знання механізмів управління пам’яттю та нутрощів Cocoa просто для того, щоб писати код без помилок.

Разом із тим, навіть зараз у 2018-муроці мову Swift не можна назвати готовою до комерційної розробки і тим більше її ранні версії. Відсутність бінарної сумісності, нестабільність компілятора та IDE і досі створюють певні труднощі у розробці крупних проектів, тому не кожен архітектор наважується використовувати Swift на своєму проекті. Що вже казати про сотні існуючих проектів на Objective-C, які тепер чомусь незаслужено називають «legacy». Також Objective-C має очевидні переваги при роботі із бінарними протоколами (привіт, Core Bluetooth, Core Audio).

Таким чином, новачки у нашій справі так чи інакше мусять вчити одразу дві мови. Для того, щоб бути конкурентним, я б порадив віддавати перевагу Swift. При цьому розбиратись у спільних із Objective-C технологіях: Foundation, GCD, Core Data.

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

Розширюйте горизонти. У якийсь момент вам буде здаватись, що ви знаєте достатньо багато. Це хороший момент для того, щоб подивитись на свою роботу під іншим кутом. Пробуйте вчити інші мови програмування: я особисто раджу Python/Ruby. По-перше, багато інструментів автоматизації у світі iOS написані саме на цих мовах, а по-друге, вони дають можливість займатись web-розробкою. Дуже раджу спробувати розробляти backend: це змушує вчитись проектувати не один компонент в системі клієнт-сервер, як часто буває при розробці мобільних додатків, а всю систему у цілому. Це безцінний досвід.

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

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

Цікаве чтиво:
objc.io
Natasha The Robot
NSHipster
Swift Documentation

Вячеслав Карамов, Lead iOS Engineer в Waverley Software

6 лет опыта разработки под iOS

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

Читайте книги, читайте документацию по языку, на котором собираетесь писать код. Для нативной разработки под iOS сейчас используются Objective-C и Swift. Второй более популярен на новых проектах, а старичок Objective-C — на «старых». Вы должны хорошо знать оба. По Swift могу посоветовать Advanced Swift: Updated for Swift 4.

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

• Учите английский! Он вам будет необходим как воздух, не только для чтения книг, документации и писем, но и для общения с заказчиком. Пока вы junior, вас могут и не показывать заказчику, но по мере роста вашей квалификации (и зарплаты) такая необходимость обязательно возникнет.
• Подпишитесь на интересующие вас рассылки и блоги по теме, например iOS Dev Weeklyи Mike Ash blog. Так вы сможете быть в курсе свежих веяний из мира разработки под iOS.

Заведите себе учетную запись на GithHub. Изучайте чужой код. Возьмите стороннюю библиотеку и разберитесь, как она реализована. Если нашли ошибку, сделайте fork, исправьте, пошлите pull request. Если представится возможность, напишите свою библиотеку, сделайте ее доступной через CocoaPods. Так вы не только повысите свою квалификацию, но и правильно пропиарите себя. Правильный PR еще никому не мешал.

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

Иван Сокуренко, Technical Lead of iOS Department в CHI Software

6 лет опыта разработки под iOS

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

Я бы выделил 6 основных направлений, на которых будут строиться ваши знания:

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

2. Базы данных и основной инструмент для работы с ними на iOS — Core Data. Здесь нам с вами повезло, так как в 90% случаев наш клиент является «тонким» и не предполагает большого количества записей в базе. Но подводных камней там достаточно, и вам предстоит набить много шишек, прежде чем получится сделать действительно хорошо.

3. Потоки. Есть несколько основных вариантов работы с ними: GCD, NSOperation и NSOperationQueue. Стоит не зацикливаться на одном, а изучить оба подхода. Работа с потоками поможет сделать ваши приложения максимально быстрыми, эффективными и приятными для пользователя.

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

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

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

Несколько общих советов

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

Изучите хотя бы на уровне чтения Objective-C.Несмотря на то, что Swift становится основным языком разработки под iOS и OS X и для него создано множество библиотек, все еще существуют крупные проекты, написанные на Objective-C. Возможно, вам даже повезет поработать на таком ;) Если же вы решили заниматься геймдевом, C++ — must have.

Читайте документацию.Еще одно преимущество от Apple — хорошая документация большинства фреймворков. При решении любой задачи в первую очередь загляните в документацию. Stack Overflow никуда не денется.

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

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

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

Автоматизируйте.Лень — главное достоинство программиста. В процессе разработки и выпуска приложения есть очень много рутинной работы, которая отнимает много времени и сил. Есть средства и сервисы, которые помогут избавиться от рутинной работы типа создания provisioning profile, добавления и обновления библиотек в проекте, сборки билдов и выгрузки их на Crashlytics и TestFlight. Лично я использую match, CocoaPods, Jenkins + Fastlane.

Полезные материалы

Обязательно смотрите The Apple Worldwide Developers Conference (WWDC).

Много полезных уроков, статей и видео можно найти здесь:

• www.appcoda.com
• www.raywenderlich.com
• http://nshipster.com
• www.objc.io

Конечно же, Хабрахабр. Ну и куда же без Stackoverflow. Много готовых и интересных UI элементов здесь.

P. S. You should have at least intermediate level of English.
P. P. S. Пусть работа и изучение новых технологий приносит удовольствие. У вас все получится!

Станислав Рябый, iOS Developer в Dev-Pro

5 лет опыта разработки под iOS

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

Главные советы для начинающего

Почитай документацию (скорее всего, ничего не поймешь).

Тогда найди книгу, где уже разжевали основы.

Посмотри на App Store простенькое приложение на два-три скрина и попытайся сделать такое же:

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

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

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

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

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

Тренды и полезности

• Рассылка: Digest MBLTdev — еженедельная подборка новостей из мира iOS-разработки.
• Видео, youtube-каналы конференций и компаний: WWDC, e-Legion, International Conference on Functional Programming (ICFP), Rambler&Co.
• Telegram-каналы: iOS.Heads, TechLead Good Reads, iOS GOOD Reads.
• Для общего развития — Medium.
• Книга по Objective-C, которая пригодилась: «Сила Objective-C 2.0. Эффективное программирование для iOS и OS X»Мэтт Гэлловей.

Нетехнические советы

Есть уйма технических советов, любой более опытный коллега, скорее всего, с удовольствием подтолкнет тебя в правильном направлении. Но я бы хотел поделиться еще и нетехническими советами, обозначить грабли, на которые наступать не стоит. Эти рекомендации, как мне кажется, могут облегчить жизнь не только iOS Junior Developer, но любому новичку в IT-компании.

Не испытывать чувство вины и быть реалистом.
Junior Developer приходит в первую компанию, чувствует себя неуверенно, начинает отдавать себя всего проекту. Этим часто пользуются. Вместо 160 часов новичок работает 180-200 часов,а говорит, что 170 из-за чувства вины за свое незнание. Мой совет: не чувствовать себя виноватым! Это не проблема Junior-специалиста, что он делает задачу медленнее, чем от него ожидали, это задача менеджера — учесть уровень разработчика в своих планах. Ответственность новичка — сказать, сколько времени ему реально понадобится.

Например, по оценке на задачу уйдет 70 часов, но ты понимаешь, что сделаешь за 100. Думаешь, что сможешь посидеть вечерами и успеть в срок. Это неправильный подход! Скорее всего, ты не успеешь закончить, станешь задерживать остальных, а риски будут на тебе, если не озвучишь их менеджеру заранее. Лучше сообщить, что эта задача может быть выполнена за 100 часов. PM сможет это учесть и вовремя скорректировать планы.

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

Не ориентироваться на других.
Если ты видишь рядом мотивированного «звездного специалиста», который работает 10-12часов и не выгорает — не пытайся за ним повторить! Ты способен(-на) быть отличным, талантливым специалистом, работая 8 часов, позволяя себе отдых и полноценный сон. А вот «звезды» часто становятся даже помехой успеха, а не двигателем проекта, завязывая все процессы на себе.

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

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

Кирилл Коваленко, iOS Tech Lead в Nullgravity

5 лет опыта разработки под iOS

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

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

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

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

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

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

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

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

Не прекращайте учиться и всегда стремитесь развиваться!

Павло Захаров, Senior iOS Developer / Team Lead в CoreValue

4 роки досвіду розробки під iOS

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

Завжди пам’ятай, що iOS розробникам дуже пощастило: 98% проблем, які в тебе виникнуть, вже були обговорені на stackoverflow.com. Тому вміння правильно сформулювати питання та швидко нагуглити відповідь, на мою думку, набагато цінніше за, наприклад, знання API напам`ять. Наступні поради можуть прозвучати дуже по-капітанськи, але з власного досвіду знаю, що далеко не всі девелопери вміють добре гуглити.

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

Не бійся нових фреймворків та технологій. Я вважаю, що єдиний спосіб вивчити новий фреймворк/технологію/мову програмування — це почати працювати з нею в реальному проекті. Теорія — це добре, але practice makes perfect. Якщо, наприклад, ти не писав на Swift, а тільки на Objective-C, або ж ніколи не працював з фреймворком Х і тобі пропонують робити проект з його використанням — не відмовляйся тільки через те, що в тебе немає досвіду з цим.

За декілька тижнів ти розберешся зі страшним і незрозумілим фреймворком, і речі, які здавались тобі складними, стануть очевидними і, найголовніше, — ти додаси в свій арсенал ще одну технологію. Якщо ж треба швидко подивитись на основні можливості фреймворка і розібратись, як він працює, найкращий ресурс — raywanderlich.com. Тут зібрано сотні туторіалів по iOS і не тільки. Пояснення зрозумілі і не сухі. Для кожного туторіала ти зробиш міні-проект, щоб отримати hands on expierence.

Не недооцінюй теорію. Іноді знання того, що і як працює під капотом, можуть вберегти тебе від нічних дебагінг-сесій та багатьох помилок. Найкращий ресурс для цього — лекції з WWDCвід Apple. Інженери Apple самі розповідають, що і як працює. Apple у цьому плані молодці. Кожна лекція з World Wide Developer Conference за кожен рік записується, щоб потім її можливо було передивитись в режимі онлайн. Є лекції про кожен фреймворк з Cocoa/CocoaTouch. Тонни інформації. Добре виробити собі звичку, якщо є вільна годинка — дивитись лекцію-дві. Потім ти зможеш використати в своїх проектах ті самі підходи, які використовує Apple. Ще один плюс — ця інформація стане тобі у нагоді на співбесідах, коли хитрий інтерв`юер захоче задати підступне запитання.

Swift у кожну хату. У 2014 багато людей казали, що Swift нестабільний, і обирали для проектів Objective-C. Через 4 роки Swift майже повністю витіснив Objective-C. Навіть останній ортодокс зараз визнає перевагу Swift над Objective-C. Якщо ти починаєш новий проект — тільки Swift. Якщо з якоїсь причини змушений писати на Objective-C — пам’ятай, що знати Swift для iOS розробника це must у 2018. Це неймовірна мультипарадигмальна мова, яка використовується не тільки для iOS програмування. Є фреймворки для написання бекенду та багато іншого. Спробуй перейти на Swift, якщо ще не перейшов, і ти полюбиш його, як полюбив я. Якщо хочеш якнайефективніше використовувати мову та задіяти всі можливості в своєму коді — Swift Talk від ObjC.ioдопоможе тобі в цьому.

Objective-C/C++. В минулому пункті мова йшла про те, що Swift перевершує Objective-C. Це так, але більш низькорівневі мови, як Objective-C та C++ дають вам розуміння того, як працюють деякі базові аспекти в програмуванні e. g. memory management, static/dynamic polymorphism, exception handling. Знання цих мов хоча б на початковому рівні допоможе розібратись, як мова працює «під капотом» і вбереже від багатьох помилок, які роблять програмісти.

Спрощуй собі життя. Все, що економить тобі час, є корисним. Вивчи гарячі клавіші в ХCode. Вони роблять навігацію по проекту швидшою і кожен раз, коли ти пересуваєшся між файлами, економлять тобі мілісекунди часу. Беручи до уваги, як часто це відбувається, за місяць набігає великий ресурс часу. Використовуй Alcatraz для XCode. Там багато корисних плагінів, які можуть допомогти саме тобі. Якщо дистрибутаєш свій проект тестерам та на AppStore, такі інструменти, як fastlaneта Crashlytics, зекономлять багато часу. Завжди відслідковуй, що вийшло цікавого і нового, дізнавайся, що ще може спростити тобі роботу.

Networking. Спілкуйся з іншими девелоперами, обговорюй свої проблеми та їх рішення, слухай, сперечайся. Як відомо, в суперечці народжується істина. Бери участь у різних заходах. Відвідуй хакатони та конференції. Це дасть тобі змогу знайти однодумців та непомітно для себе вирости як спеціалісту. Можу порадити з того, що відвідував особисто я, — конференція try! Swiftв Токіо та WWDC в Каліфорнії. Якщо буде можливість — їдь і не шкодуй грошей. Такі івенти дають натхнення та мотивують ще більше любити свою роботу.

For beginners. Окремо пункт для людей, які тільки починають свій шлях. Можливо, ти вирішив стати iOS девелопером і не знаєш, з чого почати? На мою думку, стенфордський курс по iOS Development — те, що тобі треба. Викладач торкається всіх основних можливостей CocoaTouch, дуже добре пояснює, проводить live демо для кожного уроку, є приклади коду. Дуже рекомендую. І ще дуже зверни пильну увагу на UIKit. На рівні Trainee/Junior більшість твоїх завдань буде пов’язана з юзер-інтерфейсом. І взагалі UI, на мою думку, — найважливіша частина програмування під iOS.

English. У XXI столітті кожна освічена людина, на мою думку, має володіти англійською мовою принаймні на рівні Intermediate. Особливо, якщо ти девелопер. Вся документація на англійській мові, спілкування з замовниками на англійській. Must know English. Якщо є проблема з англійською, рекомендую школу — Green Forrest. На моїх очах піднімали людей з абсолютно нульового рівня до Upper-Intermediate за короткий час.

Люби Apple. На мою думку, кожен хороший iOS Developer має бути трохи Apple fanboy. Слідкуй за новинками, дивись Keynote — надихайся. Якщо є можливість — купуй собі девайси від Apple, адже, user experience дуже важливий. Можливо, ти побачиш якісь цікаві рішення, які зможеш потім використати в своїх додатках.

Лінки

https://stackoverflow.com — якщо раптом хтось не знає, де відповіді на 98% питань :)
https://www.raywenderlich.com — туторіали по iOS і не тільки
developer.apple.com/videos — лекції WWDC
https://talk.objc.io — Swift Talk by ObjC.io
roadfiresoftware.com/...​shortcuts-for-developers — гарячі клавіші XCode
github.com/alcatraz/Alcatraz — менеджер плагінів для XCode
https://fastlane.tools — automatic deployment

Якщо маєш якісь питання чи зауваження — із задоволенням відповім. Пиши на developer.zakharov@gmail.com. Успіхів тобі, друже.

Подписывайтесь на наш Telegram-канал для джуниоров, чтобы не пропустить интересные вакансии, стажировки, курсы, статьи.

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

Я — Software Engineering Manager та керівник внутрішніх проектів EPAM Big Data Competency Center. Вже більше 10 років я працюю в ІТ-індустрії на проектах з різних бізнес-доменів: retail, finance, travel & hospitality, e-commerce тощо. У цій статті хочу більш докладно розповісти про проект — DLab. Його призначення підкреслює гасло: «Let your data scientist think about data and nothing but data».

Ідея

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

Сьогодні більшість компаній, котрі еволюціонують в «digital», частіше вдаються до аналізу внутрішніх та зовнішніх даних. Різноманіття вхідних даних та їхні обсяги, захист даних, наявність «sensitive» інформації, відсутність обчислювальних потужностей, інструментарію та можливості «експерементувати» з даними, не боячись «покласти» інфраструктуру та втратити дані, — унеможливлюють будь-яку аналітику та ускладнюють роботу data science та machine learning експертам.

Власне з цих та інших причин ми створили DLab — інструментальний акселератор у вигляді self-service для Data Scientist-ів, котрий допомагав би їм швидко розгортати потужні аналітичні «пісочниці» в «клаудах» без жодних DevOps-навиків. При потребі користувачі можуть додавати обчислювальні потужності, використовувати зручний інтерфейс для встановлення додаткових бібліотек та залежностей, взаємодіяти в межах команди та водночас не перейматися за безпеку середовища та даних.

Наш продукт є крос-платформеним та може встановлюватись на Amazon, MS Azure та Google Cloud. Задача DLab — забезпечити можливість data scientist-ам брати участь у проектах на стадії аналізу, пришвидшувати прийняття аналітичних рішень, не чекаючи моменту, коли остаточна інфраструктура буде доступною та архітектура буде узгоджена.

Чому вирішили зробити продукт open-source? За своєю суттю, DLab — такий собі оркестратор або панель керування, що поєднує безліч інструментів. Всі інструменти, технології та фреймворки, які увібрав у себе DLab, є у відкритому доступі: MongoDB, Docker, Angular, Jupyter, Zeppelin, RStudio, Git, LDAP, Python, Spark, Scala тощо. Ми вирішили розробити DLab як систему з відкритим кодом і під відкритою ліцензією (Apache 2.0), щоб допомогти іншим розробникам, data scientist-ам, фахівцям з machine learning зосередитись на обробці даних, тренуванні моделей та дослідженні даних, не переймаючись комерційною стороною продукту та проблемами ліцензування.

Команда

Розробка DLab стартувала в грудні 2016 року, коли наші колеги з EPAM Data Practice побачили потребу в такому рішенні. Зараз в команді працює три devops-інженери, front-end розробник, java-розробник, інфраструктурний архітектор і проектний менеджер. Вся команда знаходиться у Львові. Більшість вимог та побажань була сформована спеціалістами Data Science та Machine Learning, також ми тісно співпрацювали з фахівцями з інших галузей. Продукт є вже достатньо зрілим (10 релізів за 1 рік), але водночас «живим» — він постійно вдосконалюється.

Проектна команда DLab

Можливості сервісу

DLab — це self-service, кінцевими користувачами якого є безпосередньо Data Scientists. Але і працівники суміжних спеціалізацій або просто члени однієї команди, наприклад QA/QC інженери чи інші фахівці, які працюють з даними, також можуть вільно ним користуватися. Розгорнувши продукт у хмарі (Amazon, MS Azure та незабаром у GCP), вони отримують робоче середовище з простим та зрозумілим веб-інтерфейсом.

Ключові можливості DLab:

• інтеграція з необхідними для роботи аналітичними інструментами, такими як Jupyter, Zeppelin, RStudio, TensorFlow, Spark тощо;
• підтримка різних мов програмування (Python, Scala, R, Java);
• можливість встановлення різноманітних бібліотек та фреймворків;
• можливість під’єднати Spark кластер (або ж Cloud Data Engine, такий як EMR на AWS, Data Proc на GCP, HDInsight на MS Azure) і додати обчислювальних потужностей, коли потрібно обробляти великий обсяг даних і локальних ресурсів не вистачає;
• інтеграція з Azure Data Lake;
• безпека даних at rest та in motion;
• аутентифікація через LDAP, Cloud Identity Management Services, SSO;
• персональні та спільні сховища даних (AWS S3, Azure Blob storage, Azure Data Lake, Google buckets);
• фінансові звіти по утилізації клауд-середовища;
• можливість використання Spot Instances, Low priority та Preemptible VMs для економії коштів на AWS, Azure, GCP інфраструктурі відповідно.

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

Що всередині

Щоб зрозуміти, як працює DLab, пропонуємо розглянути діаграму з логічною архітектурою та головними компонентами сервісу (на прикладі AWS реалізації):

На діаграмі представлені основні компоненти DLab. Так виглядає розгорнута інфраструктура та візуалізована взаємодія між елементами системи.

Головні компоненти сервісу:

• Self-service node (SSN);
• Edge node;
• Notebook node (Jupyter, Rstudio, Zeppelin, etc.);
• Data engine cluster;
• Data engine cluster as a service provided with Cloud.

Self-service node (SSN)

Створення Self-Service node — це перший крок для розгортання сервісу DLab. Саме SSN є базовою нодою, з якої починається встановлення середовища. Вона містить такі ключові сервіси та компоненти:

• DLab Web UI — веб-інтерфейс користувача для управління всіма компонентами DLab;
• MongoDB — база даних, яка містить частину конфігурації DLab, персональні налаштування користувача, системні метадані;
• Docker — застосовується для розгортання інфраструктури;
• Jenkins — встановлюється на SSN ноду та може використовуватись для менеджменту інфраструктури як альтернатива Web UI.

Edge node

Створити Edge node — це наступний крок, який користувачеві потрібно зробити після входу в DLab. Він використовується як проксі-сервер та шлюз SSH для користувача. Завдяки Edge node користувачі можуть отримати доступ до Notebook через HTTP і SSH. Edge Node має попередньо встановлений веб-проксі-сервер HTTP.

Notebook node

Наступний крок — налаштування Notebook node (або Notebook server). Це сервер з попередньо встановленими програмами та бібліотеками для обробки даних, очищення та перетворення даних, математичного моделювання, Machine Learning тощо.
Аналітичні інструменти DLab, які інсталюються на Notebook node:

• Jupyter
• RStudio
• Zeppelin
• TensorFlow + Jupyter
• Deep Learning + Jupyter.

Також Apache Spark встановлюється для кожного з аналітичних інструментів, зазначених вище.

Data engine cluster

Після розгортання Notebook node користувач може створити для нього такі кластери:

• Data engine — автономний Spark кластер.
• Data engine service — платформа клауд-кластерів (EMR для AWS, HDInsight для MS Azure або ж Google Dataproc). Це спрощує використання Hadoop та Apache Spark під час процесу обробки та аналізу величезної кількості даних. Додавати кластер необов’язково і потрібно лише у випадку, якщо для задача потребує додаткових обчислювальних ресурсів.

Досвід використання DLab

Ми вже встановили DLab для кількох клієнтів EPAM, протестували його на внутрішніх проектах в середовищах AWS і Azure. Зараз активно розробляється та тестується інтеграція з GCP.

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

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

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

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

[Об авторе: Сергей Королев — управляющий директор в Railsware с более чем 15-летнимопытом работы в ИТ: от стартапов до корпораций. Инженер, продакт-оунер, бизнес-лидер]

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

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

Аналитика мирового рынка IT-услуг

Давайте для начала посмотрим на стоимость аутсорсинга на разных рынках. Мы анализировали средние рейты в следующих регионах: Восточная и Центральная Европа, Азия, Южная Америка, Западная Европа, Северная Америка (последние два пункта для сравнения с родными рынками большинства наших заказчиков).

Данные от Accelerance, Clutch.coи Sensium.comсовпадают с нашими наблюдениями в результате многолетнего опыта на рынке и общения с экспертами в индустрии.

Как видим, стоимость разработки в Восточной Европе (25-49 USD/час)в 2-3раза ниже, чем в Западной Европе и США (50-170 USD/час).При этом качество кода не уступает. Для многих украинских аутсорсинговых компаний одним из главных конкурентных преимуществ остается цена. Ведь при более высоких рейтах они будут выходить на более конкурентные рынки, где нужно играть по другим правилам. И мы решились на этот шаг в 2011 году.

От аутсорса к модели consultancy

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

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

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

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

Стратегия 65

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

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

Railswarian-ы обмениваются опытом и подходами с командой Pivotal Labs

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

В результате анализа рынка мы приняли решение в пользу построения consultancy-модели. Что же для этого нужно?

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

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

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

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

• продакт- и проджект-менеджеры;
• бизнес-аналитик;
• дизайнеры — графический и UX;
• Frontend- и Backend-инженеры;
• Разработчики мобильных приложений;
• DevOps;
• QA.

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

Если мы собирались предлагать команду полного спектра, 9-10узкоспециализированных специалистов не окупали бы себя. Потому мы перешли к концепции T-shape, при которой группа из 3-5экспертов закрывает все роли за счет расширения смежных експертиз. Как результат, наша команда имеет гибкий набор скиллов и может подключаться к разным функциям в зависимости от потребности. При этом количество людей остается небольшим, что позволяет им проще коммуницировать между собой.

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

В момент перехода с аутсорсинга на consultancy команда составляла около 50 человек. Первый этап миграции на новую модель заключался в принятии новых правил игры и занял около года. Software сonsultancy однозначно требует от команды выхода из зоны комфорта, больше работы над собой. Инженеру, например, теперь нужно развивать не только свои ключевые скиллы в разработке, но и коммуникацию, базовые UX-навыки, учиться управлять скоупом. К сожалению, не все были заинтересованы в своем развитии в рамках модели consultancy, потому около 10 человек покинули компанию. Остальная же часть команды успешно адаптировалась.

Изучив подходы лидеров рынка и применив их в наших реалиях, мы в течение года эволюционировали от простого аутсорсинга к software consultancy, которая нам дала, кроме удовлетворения от нового уровня качества сервиса, возможность поднять рейты до 65 USD/час.

Стратегия 75

Нашей следующей задачей было отточить новую модель на практике. Так как мы исповедуем data-driven подход, нам нужно было убедиться в силе Railsware consultancy на нескольких новых проектах. Хорошим примером стали Phillips, Interstellarи Restauranteers.

После года работы над 8 различными проектами мы убедились в том, что можем гарантированно предоставлять хороший результат с применением нового подхода к разработке продуктов. Потому мы решили поднять планку до 75 USD/час. При этом мы говорим о 75 USD/час на средне и долгосрочных проектах (от 2 месяцев до нескольких лет). В отдельных случаях нам удавалось закрывать короткие проекты (1-2 месяца)за 120 USD/час. Это возможно, но такие кейсы достаточно сложно воспроизвести. Эти переходы обеспечили площадку для запуска продуктового направления Railsware, которое мы активно развиваем сейчас.

Что в итоге

Итак, что поможет построить и поддерживать успешную consultancy модель?

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

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

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

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

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

Всех с наступившими праздниками! Меня зовут Виктор, и я работаю менеджером проектов в компании Cogniance. Делюсь дюжиной интересных материалов по управлению проектом и продуктом в первом выпуске PM Digest’a в 2018 году!

Project Management

GDPR — новые правила обработки персональных данных в Европе.Это касается всех, кто разрабатывает софт для заказчиков из «Старого Света»:

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

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

Product-Mode in software development instead of a Project mode.

Как раскрыть потенциал ваших лучших сотрудников и не потерять их — в статье HBR. Если же девелопер таки пришел к вам с заявлением: как с этим справляться руководителю и есть ли способы его сохранить — отвечает VP of Parallels.

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

Winter period of performance review is coming — here are the ideas you might use to build the competency matrix for your employees.

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

Шикарный доклад Сергея Архипенкова на CodeFest много лет назад полностью оцифрован — Теория и практика адаптивного управления проектом

Осторожно! Очень много контента — лучшее за 2017 годот ресурса thedigitalprojectmanager.com.

Agile, Scrum и все такое

Как не делать: 20 антипаттерновв поведении скрам-мастера.

О чемпросит Agile Coach Деда Мороза (Санта Клауса)? Версия Юргена Апелло.

В прошлых дайджестах не раз упоминались разные фреймворки масштабирования гибких методов. Но кажется мы не обсуждали DAD — Disciplined Agile Delivery. Рассмотрим принципы DADи погуляем по сайту фреймворка — здесь интересно.

Не отходя от кассы, предлагаю всем напомнить себе основы Scaled Agile Framework, пролистав официальный whitepaper.

10 фейлов скрам-мастераот Анны Лавровой.

Scrum Alliance продолжает публиковать отчеты о проникновении скрама во все сферы бизнеса :) Смотрим State of Scrum 2017-2018.

If you’re interested in agile, you should start learning about DevOps. Why? Because although it doesn’t replace agile software development, it complements it very, very well. This article will explain the difference between agile and devops.

Немного саркастичное, но искреннее признание в любви Scrum’у и мировому Scrum-сообществу.

Пример победы коротких итераций (в виде работы с почасовой оплатой) над планированием и реализацией проекта в целом в историигреческого фрилансера.

Fun

Когда заказчик интересуется состоянием проекта — с ним все отлично!

Попросил заказчика помочь расставить приоритеты:

You can always tell a ScrumMasters desk when you walk by...

Continuous Delivery Restaurant:

Sport is dead!Слово автору:

«Чуть ли не каждую неделю выходит одна-две статьи про то, что agile/scrum умер и больше не работает. Я решился систематизировать основные проблемы и жалобы по этому поводу и рассмотреть их на примере спорта. Итак...»

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

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Java Next

(!) Java 10 — The Story So Far. Интересно узнать, что из этого дойдет до релиза 10-ки.

Design of Java Value Types Makes Progress

(!) JEP draft: Switch Expressions for the Java Language

Что-то вроде новостей

(!) Вышел Flyway 5.0.0. На мой взгляд, более приятный тул для миграции, чем Liquibase.

Вышел Spring REST Docs 2.0.0.RELEASE. Основное нововведение — это работа со Spring 5.

Hazelcast Joins Eclipse Foundation to Collaborate on Open Source Enterprise Java

Почитать и посмотреть

What’s new in the Groovy language: 2018 roadmap. На DOU нет выделенного Groovy-дайджеста, но если у вас есть интересные материалы по тому, что происходит с этим языком, внизу указано, куда вы их можете отправить.

JUnit4, JUnit5, and Spock: A Comparison. Самое важное в этой статье — Spockеще жив, оказывается.

Оказывается, в 2018-мгоду люди все еще пользуются Eclipse-ом. Более того, все еще обсуждают на DOU и в юзер-группах Eclipse vs Intellij Idea. И это в то время, как все прогрессивное человечество переезжает (но никак не переедет) на VS Code.

Spring Cloud Stream and Apache Kafka based Microservices on Oracle Cloud ... скачать бесплатно без-смс. Тут важно узнать, что у Оракла тоже есть свой клауд.

This Year in Spring — 2017. Описание того, что случилось в Springв предыдущемгоду.

Getting Started with Microservices in SpringBoot. Мало ли, может кто еще не читал подобных статей.

(!) The First Nine Projects Proposed for EE4J. JEE дружно переезжает под крыло Eclipse.

Payara Server and Payara Micro in 2018

Eclipse Vert.x meets GraphQL. Почему-то хайп по GraphQLкак-то обходит Java-мир. Пытались ли вы использовать его в своих проектах? Как ощущения?

Aphyrпроанализировал Hazelcast 3.8.3. Если кратко, то «все пропало».

Psychosomatic, Lobotomy, Saw: What a difference a JVM makes?. Немного непотребств в новом году.

(!) Shenandoah: сборщик мусора, который смогот Алексея Шипилёва.

(!) Серия статей JVM Anatomy Parkот Алексея Шипилёва.

Разное

Resilience4j — альтернатива Hystrix

Предложения и пожелания все еще принимаются или через завсклад и товаровэдадминистрацию DOU, или через твиттер @_silverwolf. Также можно оставлять комментарии в специально выделенной темена форуме.

← Предыдущий выпуск: Java дайджест #36

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

Ярослав Пернеровский — Test Automation Lead, а также тренер и консультант по вопросам автоматизации. Работает в IT с 2005 года: за это время у него получилось побыть тестировщиком продуктов, заниматься аутсорс-тестированием и попробовать себя тренером на курсах «войтивайти» (QA Factory) еще до того, как это стало мейнстримом.

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

Возраст и опыт: 37 лет, 13 лет работает в IT.
Модель смартфона: OnePlus 3T.
Модель ноутбука: Acer, HP, MacBook Pro 13’’.
Суперспособности:чувствовать время и успевать делать важные вещи вовремя, объяснять сложные понятия простым языком.

— Как проходит ваш типичный рабочий день?

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

Дальше — чистая вариативность. Обычно есть запланированные дела, которые идут своим чередом: встречи с командой и заказчиками, собеседования с новыми кандидатами, тренинги в GL BaseCamp и GL ProCamp. А также есть элемент аджайла, когда все внезапно переигралось и теперь план другой. Отношусь к этому совершенно спокойно. Здесь мне помогает еще одна суперспособность — быть гибким и работать с задачами без вскрикиваний «Шеф, всё пропало!».

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

— Какие гаджеты, девайсы используете ежедневно?

Из-за специфики работы у меня несколько ноутбуков: Acer с Linux, HP с Windows, MacBook Pro 13″ — для души, стиля и красоты. Также использую смартфоны, стационарные компьютеры, большие и маленькие сервера, все то, на чем надо что-либо протестировать. Еще я люблю механические клавиатуры и беспроводные наушники.

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

— Как выглядит ваш воркспейс? Какими инструментами пользуетесь?

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

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

— Используете ли какие-то практики по тайм-менеджменту?

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

— Как часто проверяете почту, соцсети, мессенджеры?

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

Вообще считаю, что мессенджеры — это зло, а много мессенджеров одновременно — это смерти подобно. Потому меня до сих пор нет ни в Telegram, ни в Viber, ни в WhatsApp. Только Skype и почта. В соцсетях я есть в LinkedIn и Facebook, но и это только потому, что надо поддерживать полезные связи и быть в курсе того, что происходит вокруг. Странно, но до сих пор я не понял, зачем нужны Twitter и Instagram :)

— Ваш любимый to do менеджер?

Google Keep на телефоне. Иногда что-то нужно срочно записать, а ты в дороге — тогда этот сервис спасает, так как телефон всегда с собой. Потом можно просмотреть или сделать записи откуда угодно — хоть с компьютера, хоть с телефона. Считаю Google Keep идеальным, так как он не перегружен фичами, имеет продуманный и удобный интерфейс и отлично интегрируется в Chrome, что позволяет сохранять интересные идеи прямо из браузера. Еще, бывает, записываю что-то где придется, на каких-то бумажках, и фоткаю, чтобы не потерять :)

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

— Сколько часов в неделю работаете?

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

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

— А отпуск часто берете?

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

— Что вас вдохновляет?

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

— Что помогает быть продуктивным?

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

— Вы экстраверт или интроверт?

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

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

— Что последнее прочитали или читаете сейчас?

Последнее, что прочитал с огромным интересом, — «Людина розумна. Історія людства від минулого до майбутнього»Юваль Ноя Харари в идеальном украинском переводе от Я. Лебеденко. Теперь жду такого же крутого перевода следующей книги — «Homo Deus: A Brief History of Tomorrow». Однозначно всем рекомендую, так как в этой книге есть логика. Она позволяет многое переосмыслить и понять, почему мы такие, как есть.

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

Нассима Талеба представлять не надо. Единственное, что писать книгу такого объема о такой простой идее, как по мне, — это перебор. До сих пор не могу понять, что им двигало: то ли гонорар от издателя, то ли изощренное желание поглумиться над читателем. Но прочитать стоит, особенно айтишникам.

— С кем из известных личностей хотели бы встретиться? Что бы спросили?

Неплохо было бы потусить с Джеймсом Хэтфилдомиз Metallica. Очень крутой дядька. Спросил бы, как правильно играть «Master Of Puppets».

— За что любите и не любите свою работу?

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

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

— Что бы вы посоветовали себе 10 лет назад?

Само собой — вложиться в майнинг-ферму :) А если серьезно — не бояться делать. Я очень много времени тратил раньше на обдумывание: а что если все пойдет не так, а что если не получится и т. п. Все получится! А если не получится, то ты, по крайней мере, приобретешь ценный опыт и пойдешь дальше. Не надо бояться выходить из комфортной норки.

— Кем себя видите через 5 лет? :)

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

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