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

Александр Кондуфоров, Machine Learning Engineer и Data Science Competence Leader в харьковской компании AltexSoft, более трех лет занимается триатлоном. Он рассказал DOU, чем его привлекает эта связка из плавания, бега и велогонки, сколько времени уходит на тренировки и что нужно знать начинающим триатлонистам.

— Александр, чем вас заинтересовал триатлон? Как подписались на свою первую дистанцию?

Про триатлон, а точнее про его самую популярную вариацию Ironman, я узнал 5-6лет назад, когда увидел мотивационное промовидео одного из стартов. Люди делали какие-то невероятные вещи: плыли почти 4 км, ехали 180 км и затем бежали полный марафон — и всё это без остановки и отдыха! Для меня тогда даже марафон был чем-то запредельным, что уж говорить про Ironman, который считается одной из самых сложных однодневных гонок. В тот момент у меня в голове и засела мысль когда-нибудь попробовать триатлон.

Одно из лучших мотивационных видео о триатлоне

Подходящий случай представился чуть более трех лет назад. Зимой 2015 года я увидел анонс первого триатлон-старта в Харькове — Kharkiv Man. К этому моменту я уже несколько лет изредка бегал небольшие дистанции «для себя» и участвовал в любительских забегах (весьма посредственно, надо сказать), а также любил кататься на горном велосипеде. Дистанции спринта — 750 м плавание, 20 км велогонка и 5 км бег — мне показались достаточно вменяемыми, чтобы хотя бы дойти до финиша. И я зарегистрировался на свой первый старт.

— Сколько времени понадобилось на подготовку? И как все прошло?

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

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

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

— Расскажите подробнее, как устроен триатлон? Какие бывают варианты дистанций?

Триатлон — это относительно молодой вид спорта, состоящий из трех дисциплин: плавания, велогонки и бега. Первые соревнования, напоминающие современный триатлон, проходили еще в 20-30-х годах прошлого века во Франции, но они сошли на нет. В 1974 году в Калифорнии собрался первый клуб, объединяющий бегунов, велосипедистов и пловцов, где начали проводиться любительские соревнования на короткие дистанции.

Однако настоящий рост популярности триатлона начался после 1977 года, когда на Гавайях провели первые соревнования на длинную дистанцию — Hawaiian Ironman Triathlon. Цель гонки была наконец-то разобраться, кто же выносливее: бегуны, пловцы или велосипедисты. Участники должны были как раз проплыть те самые 2,4 мили (3,8 км), проехать на велосипеде 112 миль (180 км) и пробежать марафон — 42,2 км. С тех пор эта дистанция стала классической, гонка на Гавайях — чемпионатом мира на длинной дистанции, а почетный титул Ironman даётся каждому, кто сможет финишировать за 17 часов.

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

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

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

• Спринт — 750 м плавание, 20 км велогонка, 5 км бег;
• Олимпийская дистанция — 1500 м плавание, 40 км велогонка, 10 км бег;
• Триатлон 70,3 (половинка железной дистанции) — 1,9 км плавание, 90 км велогонка, 21,1 км бег;
• Триатлон 140,6 (классическая или полная железная дистанция) — 3,8 км плавание, 180 км велогонка, 42,2 км бег.

Кроме коммерческих стартов самой известной серии Ironman, в мире проводятся соревнования других серий и брендов: Challenge Family, Ocean Lava и т. д. Кроме этого, существует очень много региональных стартов для любителей и профессионалов, среди которых выделяются очень экстремальные северные гонки Norseman, Swissman, Celtman, финишировать в которых еще сложнее из-за плавания в ледяной воде, ветреных велоэтапов с большим набором высоты и бегового финиша на какой-нибудь горе.

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

— Чем именно вам нравится этот вид спорта, что привлекает и мотивирует?

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

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

Стартовый замес на плавании

— В каких соревнованиях вы участвовали? Каких результатов удалось достичь?

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

На каждой из дистанций у меня есть какой-то текущий рекорд, который я пытаюсь улучшить на каждом следующем старте, но они пока не очень высокие, нечем особо хвастаться :) Скажу лишь, что лучшее время на полумарафоне у меня 1:28, половинку полной дистанции я прохожу за 4:50-5:00 часов,а полную дистанцию пока прошёл один раз за 11 часов.

— А какие старты запомнились больше всего?

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

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

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

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

— Как удается совмещать триатлон и работу? Много ли времени уходит на тренировки?

Да, тренировки отнимают довольно много времени, потому что нужно тренироваться, по сути, в трех дисциплинах вместо одной, например, бега. В холодное время объемы тренировок немного падают, в весенне-летний сезон тренируемся много — 6 дней в неделю, иногда по 2 тренировки в день. Особенно много времени уходит на длинные велотренировки или кроссы.

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

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

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

— Полезны ли в жизни, работе какие-то навыки, полученные при занятиях триатлоном?

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

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

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

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

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

Иногда после финиша бывает тяжеловато

— Насколько серьезны требования к физической форме для триатлониста? Есть ли физические ограничения?

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

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

— Насколько в Украине развита культура триатлона? Какие соревнования и когда проходят? Как принять участие?

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

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

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

В прошлом году запустилась лига IronWay, которую организовали наши харьковские ребята и под эгидой которой в этом году пройдет несколько стартов в Харькове, Киеве и Одессе, включая половинку железной дистанции. В конце весны или начале лета проходит очень хороший старт в Днепре — Dnipro Triathlon Fest. В июне — спринт в Полтаве, традиционная олимпийка в Вышгороде (чемпионат Украины) и «Слов’янська Хвиля» — половинка в Переяслав-Хмельницком. В июле будет единственный и самый старый украинский старт на полную железную дистанцию UkrManв Беляевке (Харьковская область). Впрочем, он достаточно специфичен: это кросс-кантри триатлон по проселочным дорогам с небольшим количеством участников. В августе — спринт в Запорожье «Кубок Хортицы».

Мотивационное видео с триатлона IronWay

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

— Что можете посоветовать новичкам? С чего и как лучше начинать? На что обратить внимание?

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

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

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

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

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

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

Стартовый костюм, в котором проходится вся дистанция — от плавания до бега

— Сколько все это стоит? Насколько триатлон — дорогой вид спорта?

Триатлон — не самый дешевый вид спорта. И если плавки, очки (суммарно примерно $50), спортивная одежда (тоже по $30-50) и даже пара пар кроссовок (хорошие стоят порядка $100) вас не разорят, то карбоновый велосипед, а тем более велосипед для раздельного старта на хороших карбоновых колесах влетят в серьезную копеечку. Его стоимость стартует от $1000 для шоссейника и от $2000-3000 для разделки.

Дополнительные траты — регистрации на старт за границей ($200-300 половинка и $400-600 — полная железная дистанция) и поездки туда (стандартная стоимость проезда, проживания и питания). Будьте готовы к этому.

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

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

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

Вторая цель, которая также поможет первой, — пробежать марафон за три часа. Причем хочется это сделать на каком-нибудь старте из World Marathon Majors — например, в Берлине.

Меня зовут Дмитрий Растатурин, я работаю в компании Daxx NL и отвечаю за операционный менеджмент в Pindrop NL (компания-клиент). Наши end-customers — это Европа, основной рынок — Нидерланды, а также Франция, Бенилюкси UK.

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

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

Компоненты роли PM

Сфера менеджмента в ИТ охватывает довольно много смежных областей, поэтому необходимо учитывать, что в разных компаниях набор обязанностей может (а, вернее, будет всегда) отличаться. В этой статье я пишу о них с точки зрения project management (концентрация на проекте), а также delivery / operations management (мы управляем каким-то количеством проектов, распределенными командами, то есть концентрация на процессах).

Можно выделить такие главные компоненты роли PM-а:

1. Основы архитектуры. Управление релизами.
2. Планирование.
3. Коммуникация.
4. People Management.
5. Владение инструментами.
6. Управление требованиями и документация.
7. Управление бюджетом.

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

Давайте рассмотрим эту модель в привычной структуре, поскольку для начала нужно понять, как работают компоненты системы, и только потом двигаться на следующий уровень (step by step): Junior, Middle, Senior.

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

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

Основы архитектуры. Управление релизами

Junior

Необходимо понимание следующих основ:

• Клиентская / серверная часть (Backend, Frontend).
• API.
• HTTP и запросы.
• ООП.
• Release management — процесс, отвечающий за внедрение и контроль качества (части) вашего (кода) продукта, развернутого в ИТ-среде. В том числе в рамках управления релизами разрабатываются политики внедрения новых версий программного и аппаратного обеспечения. Релиз — это здоровье проекта. Иногда нужно делать релизы чаще, иногда нет. Далее я расскажу о том, как управлять кросс-проектными релизами для проектов среднего уровня.

Middle

• Управление версиями.
• Gitflow:
  
  • Также одна из лучших Git-моделей.
• Понимание, как создается сборка продукта (билд), доставка (deployment) в нужную среду (environment(s): development, staging, production).
• Что такое Continuous Integration (CI), то есть непрерывная интеграция кода (очень частые обновления системы (кода вашего проекта), но небольшими частями, и последующая автоматизация этого процесса).

Senior

• Имплементация практик Continuous Delivery.
• Business Intelligence (BI): имплементация и автоматическая отчетность.
• Мониторинг процессов в реальном времени:
  
  • конфигурация автоматических нотификаций аналитики по выбранным метрикам;
  • для начала подойдет eazyBI.

Что прочитать:«Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation» by Jez Humble, David Farley (минимум на уровне Middle).

Кейс

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

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

В нашей компании мы применяем кросс-проектный Скрам. Почему я говорю «кросс-проектный»? Мы используем Atlassian Portfolioдля управления большим количеством проектов, и концепция CPR (cross-project releases) прекрасно интегрируется в наш процесс.

Далее расскажу немного больше об управлении итерациями в планировании проекта.

Планирование

Junior

• Что такое Waterfall.
• Что такое Agile (в первую очередь мы хотим понимать, что представляет собой Scrum / Kanban).
• Что такое Lean.
• Типы контрактов. Отличия Fixed Price от Time & Material.
• Управление бюджетом проекта.

Middle

• Управление процессом планирования.
• Умение взять на себя роль Скрам-мастера (а часто совмещение этой и ПМ ролей).
• Работа с эстимейтами (см. книгу Mike Cohn), одновременная работа на нескольких уровнях планирования (high-level, story level, technical level).
• Построение Gantt-графиковдля клиента.
• Грамотное планирование релизов и планирование итераций.
• Концепции PMBOK, PRINCE2, их отличия от методологий Agile.

Senior

• Внедрение различных моделей планирования и понимание, какая подходит данному проекту.
• Управление кросс-проектными релизами.
• Релиз менеджмента в портфолио проектов.
• Продажа спринтов клиенту.

Что прочитать:

• «Scrum and XP from the Trenches» by Henrik Kniberg. Обязательно читать новичкам, есть в открытом доступе и на русском. Написана простым языком и дает понимание, как работают гибкие методологии.
• «Agile Estimating and Planning» by Mike Cohn.
• «The Lean Startup» by Eric Ries.

Кейс

Мы работаем на нескольких уровнях одновременно (контракт не учитываем, для примера берем общую модель):

• High (Epic) level: rough planning (range pessimistic / optimistic + разделение рисков с клиентом, где это возможно). Для оценки вероятности используется классическая модель PERT. На этом уровне мы продаем проект.
• Business (story) level: на уровне user story, планирование итераций с описанием / acceptance criteria, но без технической декомпозиции. Планирование фич по модели Kano. Это планирование итераций после того, как проект подтвержден и приоритизирован скоуп проекта.
• Technical (sub-task level):технические задачи для разработчика. Планирование в рамках одной итерации. Задачи на этом уровне максимально детализированы.

Мы используем классические двухнедельные спринты и в их названии придерживаемся формата «Sprint-X-year-month-week», для того чтобы:

А. Product Owner знал, когда он получит определенный функционал на staging environment (то есть среда, идентичная по конфигурации лайв серверу) без необходимости идти в календарь релизов.

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

Например, сейчас мы заканчиваем Sprint-3-18.6.2, то есть PО знает, что требуемый функционал он увидит на демо в конце второй недели июня. Это также позволяет более удобно планировать задачи для следующих итераций.

Как мы управляем версионностью?
Поскольку релиз итерации — это не всегда релиз в лайв, для релизов клиенту (staging) / в лайв, мы используем следующее управление версиями: в Git и в релиз-тикете.

Как мы это делаем в Jira, и если, например, необходим хотфикс до окончания итерации?
Создается тикет с кастомным issueType = `Release`, где указывается (Git) версия, и далее тикет планируется как часть итерации. Рекомендую внимательно прочитать, что такое управление версиями, поскольку зависимостей очень много в любом процессе, и правильная версионность позволяет грамотно ими управлять.

Как мы планируем ресурсы, которые могут быть разделены между несколькими небольшими проектами?
Мы используем термин Capacityкаждого FTE, то есть каждый член команды (команды также разделены в Atlassian Portfolio) имеет определенное количество часов в спринте, которые мы можем использовать. В Capacity автоматически включены риски, и также часть времени мы резервируем на случай непредвиденных рисков. То есть при правильной конфигурации менеджер может управлять ресурсами и строить планирование быстро и эффективно (конечно, должна работать двусторонняя синхронизация с Jira). Но ему нужно помнить о том, что релиз должен быть выполнен (а их может быть несколько, если мы говорим об управлении портфолио проектов) и скоуп не может быть перегружен.

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

Коммуникация

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

Junior

• Английский: upper-intermediate (min B2).
• Грамотная коммуникация рисков.
• Коммуникация в команде, позиция командного лидера.

Middle

• Английский: fluent (C1, C2).
• Управление проектом с момента подписания SOW (до релиза, возможно, исключая управление бюджетом).
• Управление рисками проекта и грамотная коммуникация рисков клиенту.

Senior

• Английский: fluent (C1, C2).
• Работа со стейкхолдерами (заинтересованными лицами проекта) С-уровня.
• Участие в presale.
• Delivery management.

Что прочитать:«Договориться можно обо всем»Гэвина Кеннеди

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

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

Кейс

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

Что мы сделали? Мы описали скоуп в рамках новых требований как Time & Material, декомпозировали на несколько фаз (Epics), начиная с MVP (minimum viable product), приоритизировали stories вместе с продакт-оунером, провели переговоры с клиентом, используя изначальные требования, построили планирование и провели клиента через весь процесс.

People Management

Junior

• Коммуникация прогресса заказчику и требований команде.

Middle

• Умение работать с конфликтами в команде.
• Управление рисками в команде.
• Проведение 1×1 митингов.

Senior

• Имплементация KPI, оценка performance (интеграция с BI).
• Управление кросс-проектными / shared / remote командами.
• Проведение интервью.

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

Инструменты

Junior

• Jira (user level), Confluence, Google Docs, Email / Slack.

Middle

• Jira advanced level, Confluence, инструменты прототипирования (Balsamiq Mockups, Proto.io, Axure etc, если необходимо), MS Project or similar.

Senior

• Jira deep configuration, Atlassian Portfolio, BI / process analytics systems (ServiceClarity & others).

Что прочитать:«JIRA Essentials» by Patrick Li, Third Edition.

Управление требованиями и документация

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

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

Документируются не только требования, но и митинги по время итерации:

А также процессы и политики внутри компании.

Управление бюджетом

Junior

• Управление только скоупом проекта (управление бюджетом — минимум, уровень Middle).

Middle

• Оценка проекта и коммуникация данных клиенту.
• Анализ трекинга времени.
• Коммуникация бюджета / управление бюджетом — в зависимости от политики компании.
• Репортинг.

Senior

• Администрирование часов.
• Мониторинг бюджета в BI.
• Автоматические нотификации о превышении бюджета (по итерациям / релизам).
• Бюджет команды / проекта.
• Бюджетирование на определённый период времени наперёд.
• Гибкое инвойсирование T&M часов (конфигурация экспорта в зависимости от аккаунта).

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

Выводы

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

Как я говорил в начале статьи, я намеренно даю информацию в таком формате, чтобы начинающий специалист не оказался посреди океана информации, не зная, за что браться. Градацию «junior — middle — senior» следует воспринимать условно. Аналогично можно использовать «A — B — C», поэтому не стоит предполагать, что менеджер проектов среднего уровня будет обладать именно таким сетом навыков.

В конце выделим несколько важных тезисов, которые определяют квалификацию и опыт менеджера:

• Мы управляем процессом, а не процесс управляет нами. Если менеджер is not in charge, вероятность того, что проект закончится успешно, — практически нулевая.
• Продукт нужно знать на уровне архитектуры, то есть вы должны понимать, что вы отдаете клиенту, как взаимодействуют модули, логику продукта etc.
• Не создавайте лишнюю работу, старайтесь упростить все, что можно упростить:
  
  • Касательно планирования задач и управления бэклогом — еще раз, изучите Kano Model of Satisfaction, а также как приоритезировать задачи и учитывать риски и зависимости. Кстати, Mike Cohn пишет об этом очень хорошо.
  • Всегда учитывайте влияние задачи на логику продукта.
• Не принимайте решения за разработчиков. Никогда не продавайте проект без оценки команды, если задачи выполнять будете не вы сами.
• Становитесь на сторону заказчика при коммуникации с ним, и на сторону команды при коммуникации с командой. Изучайте бизнес заказчика. Изучайте предметную область продукта.
• Планируйте и управляйте планированием на нескольких уровнях.
• Всегда считайте и учитывайте риски.
• Время — деньги. Always be in control of your budget.
• Структура и предсказуемость процессов. Процессы должны быть предсказуемыми для команды и заказчика. Да, именно так.
• Процессы должны быть гибкими. Если процесс рассыпается при малейшем отхождении от плана, это не процесс.
• Вы всегда работаете с людьми. Без команды вы не сможете сделать ничего, а без клиента вам будет нечем платить зарплату. Работайте по обе стороны баррикад :)

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

Впервые я столкнулась с термином «тестовая эвристика», когда мне на глаза попался James Bach’s Blog. Именно с него и начался мой интерес к тестовым эвристикам и мнемоникам. На сегодняшний день наиболее актуальная часть материалов по тестированию представлена как раз таки англоязычным контентом.

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

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

Что такое эвристики и мнемоники

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

Мнемоника — совокупность правил и приёмов, которые помогают запоминать нужные сведения и данные.

Преимущества тестовых эвристик:

1. Эвристики не дают забыть контекст, в котором используется тестируемое приложение.
2. Краткость. Эвристики удобно набросать в mindmap, записать в небольшом текстовом файле или просто на листе бумаги. Для запоминания эвристик могут использоваться мнемоники.
3. Эвристики помогают провести исследовательское тестирование приложения в более детальном и полном формате.
4. Они помогают избежать повторения ошибок, допущенных в аналогичных ситуациях при тестировании похожего ПО. Тестовые эвристики создают «напоминания» на основе предыдущего опыта — личного или опыта других тестировщиков.

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

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

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

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

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

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

Эвристики и мнемоники помогают нам описывать процесс нашего тестирования.

Отличие эвристики от мнемоники

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

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

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

Все, что мы делаем и используем в тестировании, является эвристическим. Все модели, оракулы и методы тестирования — эвристика.

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

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

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

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

• Test Heuristics Cheat Sheet (Элизабет Хендриксон);
• Heuristic Test Strategy Model (Джеймс Бах).

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

SFDPOT & CRUCSPIC STMP

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

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

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

SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):

• Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
• Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
• Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
• Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
• Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
• Time — время, проверка того, как приложение ведет себя в зависимости от времени.

Карен Н. Джонсон (Karen N. Johnson), эксперт в сфере тестирования программного обеспечения, ссылаетсяна данный эвристический метод и называет его San Francisco Depot (SFDPOT). Он позволяет понять окружение, в котором вы будете тестировать, с точки зрения объема, ресурсов и времени — вершин треугольника качества. Это важная часть тестирования, которая часто выпадает из поля зрения тестировщика.

Многие специалисты по обеспечению качества используют SFDPOT и CRUCSPIC STMP для исследования объекта тестирования. Например, Джеймс Бах — известный эксперт, который постоянно выступает на престижных конференциях, один из тех, кто стоит за исследовательской концепцией тестирования и школой Context-Driven Testing, его блог бьет все рекорды популярности по всему миру. SFDPOT описывает составляющие продукта, а CRUCSPIC STMP — атрибуты системы. Эти способы эффективны для определения объектов и целей тестирования, а также они эффективно взаимодействуют между собой.

Оба метода (SFDPOT и CRUCSPIC STMP) весьма разнообразны и могут ссылаться друг на друга. SFDPOT может быть частью Capabilities — «возможностей», а CRUCSPIC STMP может быть частью Operations — «использования» (часто интерпретируется как «риск»). Схема взаимодействия этих методов:

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

RCRCRC

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

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

• Recent — Недавнее
• Core — Основное
• Risky — Рисковое
• Configuration sensitive — Чувствительное к конфигурации
• Repaired — Исправленное
• Chronic — Хроническое

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

Для запоминания этой эвристики можно использовать аббревиатуру, состоящую из первых букв — RCRCRC: Recent-Core-Risky-Configuration sensitive-Repaired-Chronic.

1. Recent (Недавнее)

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

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

2. Core (Основное)

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

3. Risk (Рисковое)

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

4. Configuration sensitive (Чувствительное к конфигурации)

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

5. Repaired (Исправленное)

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

6. Chronic (Хроническое)

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

Резюме

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

CIDTESTD

• Customers — Пользователи
• Information — Данные
• Developer relations — Взаимодействие разработчиков
• Team — Команда
• Equipment & Tools — Оборудование и инструменты
• Schedule — График тестирования
• Test items — Тестовые объекты
• Deliverables — Ожидаемые результаты

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

CRUSSPICSTMPL

• Capability — Возможность
• Reliability — Надежность
• Usability — Удобство использования
• Security — Обеспечение надежности
• Scalability — Масштабируемость
• Performance — Производительность
• Installability — Возможность установки
• Compatibility — Совместимость
• Supportability — Возможность поддержки системы
• Testability — Тестируемость
• Maintainability — Удобство обслуживания
• Portability — Переносимость
• Localisability — Локализуемость

Эта эвристика представляет собой полный и необходимый список качественных характеристик системы. Карен Н. Джонсон предпочитает пользоваться ISO 9126 (международный стандарт, определяющий оценочные характеристики качества ПО), но CRUSSPICSTMPL дает превосходное покрытие основного функционала системы. А окончание «ity» в конце практически каждого слова эвристики помогает сосредоточиться на QualITY (качестве) продукта.

FDSFCURA

• Function Testing — Функциональное тестирование
• Domain Testing — Тестирование доменных имен
• Stress Testing — Стресс-тестирование
• Flow Testing — Тестирование потоков
• Scenario Testing — Тестирование сценариев
• Claims Testing — Тестирование требований
• User Testing — Пользовательское тестирование
• Risk Testing — Тестирование рисков
• Automatic Testing — Автоматизация

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

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

Другое определение оракула говорит о том, что это способ генерации ожидаемого результата теста.

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

HICCUPPSF

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

• History (История) — нынешняя версия системы соответствует предыдущим версиям продукта.
• Image (Изображение) — внешний вид продукта соответствует макету системы заказчика.
• Comparable Products (Аналогичные продукты) — система соответствует аналогичным системам. Они включают в себя другие продукты в одной и той же линейке продуктов; конкурентоспособные продукты, услуги или системы; или продукты, которые не относятся к одной и той же категории, но обрабатывают одни и те же данные; или же альтернативные процессы и алгоритмы.
• Claims (Требования) — продукт соответствует требованиям заказчика.
• Users’ Expectations (Ожидания пользователей) — система соответствует потребностям конечных пользователей.
• Product (Продукт) — каждый элемент системы (или продукта) будет соответствовать сопоставимым элементам в одной и той же системе.
• Purpose (Цель) — система соответствует явным и неявным целям и нуждам пользователей.
• Statutes (Законы) — система соответствует законам и правилам, которые описывают данный продукт и его использование.
• Familiarity (Осведомленность) — «F» означает «Familiar problems» (похожие проблемы). Другими словами, система не соответствует ни одной из проблем, с которыми сталкивался ранее тестировщик.

MAC RUSS — эвристика автора статьи для приемочного тестирования

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

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

• Maintainability — Удобство сопровождения
• Availability — Доступность
• Configurability — Способность к конфигурации
• Reliability — Надежность
• Usability — Удобство использования
• Security — Безопасность / обеспечение надежности
• Scalability — Масштабируемость

Для запоминания этой эвристики можно использовать аббревиатуру, состоящую из первых букв MAC RUSS: Maintainability-Availability-Configurability-Reliability -Usability-Security-Scalability.

1. Maintainability (Удобство сопровождения)

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

2. Availability (Доступность)

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

3. Configurability (Способность к конфигурации)

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

4. Reliability (Надежность)

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

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

5. Usability (Удобство использования)

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

6. Security / Securability (Безопасность / обеспечение надежности)

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

7. Scalability (Масштабируемость)

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

Резюме

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

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

Ключевые преимущества применения эвристики MAC RUSS:

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

Практическое применение и использование тестовых эвристик и мнемоник

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

Термин «эвристика» можно также трактовать как «некая устоявшаяся практика», и для Context-Driven Testing School этот термин уже давно прижился сам по себе.

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

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

Как говорит Кем Канер (Cem Kaner, автор книги «Testing Computer Software»), «тестирование — это исследовательская деятельность, которая предоставляет информацию, связанную с качеством программного обеспечения». Собирая различного рода информацию, мы должны быть открыты к интерпретациям, чтобы иметь возможность оценить проблему с разных сторон.

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

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

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

Пример использования мнемонических схем SFDIPOT и CRUSSPIC STMPL

Шмуэль Гершон (Shmuel Gershon) в своем блоге (статья «The Big Exploratory Testing Rolling Strategy Dice») описывает практическое применение мнемонических схем в исследовательском тестировании.

Шмуэль Гершон предлагает комбинировать две тестовые эвристики: SFDIPOT (Structures, Functions, Data, Platforms, Operations, Time) — эвристика тестовой стратегии Джеймса Баха и CRUSSPIC STMPL (Operational Criteria — CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility; Development Criteria — STMPL: Supportability, Testability, Maintainability, Portability, Localizability) — эвристика качественных характеристик продукта.

Например, для того чтобы выбрать первый элемент для тестирования, нам нужно подбросить кубик SFDIPOT, и, предположим, выпала грань «Platform» (платформа — проверка того, как приложение взаимодействует с платформой, на которой запущено). Чтобы определить, с какой точки зрения следует изучать тестовую платформу в первую очередь, подбросим кубик CRUSSPIC STMPL — допустим, выпадет грань «Testability» (тестируемость продукта). Теперь взглянем на наш продукт с точки зрения этих двух характеристик — стратегии и качества. Как и каким образом мы можем протестировать нашу платформу? Какие особенности платформы могут быть на системном уровне тестирования? Какие интерфейсы этой платформы могут быть? И какие баги, связанные с этим, мы можем найти?

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

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

Что говорят украинские эксперты

Егор Максимчук, Senior Software Engineer в SoftServe Ukraine

В IT я работаю с 2010 года. Кроме работы в SoftServe, преподаю в qastudy.online, был судьей на Dev Challenge 12 и веду телеграм-канал @QAStudy.Online.

Термин «тестовая эвристика» я узнал давно — на SQA Days и в блогах по тестированию. Лично я люблю совмещать два эвристических метода тестирования: SFDPOT и CRUCSPIC STMP. Они эффективны для определения объектов и целей тестирования, а их взаимодействие отлично покрывает большинство возможностей и рисков тестируемой системы. Я считаю, что особенно бесценны эвристики для новичков в области тестирования: если вдруг стало непонятно, с чего начать процесс тестирования нового софта. Они помогают начать и достаточно полноценно провести исследовательское тестирование приложения.

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

Самым удобным инструментом для оформления эвристик считаю mindmaps, например, xmind.

Чекановский Александр, QA lead в Aurora Technologies

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

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

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

На текущем проекте используем частичную комбинацию SFDPOT и HICCUPPSF.

Я бы назвал ее FUC*IT:

• Functional
• User ex
• Claims
• *Platform
• Image
• Target

Вячеслав Сахаров, QA Team Lead в COI Marketing & Software

Работаю в IT практически 6 лет. Самые трудные были первые два года работы единственным тестировщиком в Design Cont`d. Затем этот опыт самостоятельной работы помог мне работать QA Team Lead в компаниях Tallium, Customertimes, Helsi. Сейчас работаю в COI Marketing & Software — занимаюсь организацией, контролем и управлением работы QA команды, а также определением процессов, процедур и методик тестирования программного продукта; принимаю участие в создании регламентов и процедур разработки.

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

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

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

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

Резюме

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

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

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

«Квалифицированное исследовательское тестирование — это еще один эффективный мыслительный инструмент в репертуаре тестировщика». (Jonathan Kohl, основатель и главный консультант по программному обеспечению Kohl Concepts, Inc., ведет свой блог)

Список полезных ресурсов

Статьи

• «Немного про тестовые эвристики», Родион Горицков
• «Эвристики ХРОНИЧеского регрессионного тестирования», Карен Н. Джонсон
• «Как проводить эвристическую оценку?», Армен Газарян
• «Как проводить эвристическую оценку», Якоб Нильсен
• A software expert’s heuristic for regression testing, by Karen N. Johnson
• Heuristic Test Strategy Model, by James Bach
• Test Heuristics Cheat Sheet, by Elisabeth Hendrickson
• Testing Heuristics — Thinking like a tester, by Shane Hastie
• Software Testing Heuristics & Mnemonics, by Karen N. Johnson
• Software Quality Characteristics, by Rikard Edgren
• Intertwined SFDPOT & CRUCSPIC STMP, by Rikard Edgren
• Tester Diaries — Applying SFDPOT Heuristic, by Ridha, KnowledgeTester blog
• Applying the SFDPOT heuristic to mobile testing, by Karen N. Johnson
• The Big Exploratory Testing Rolling Strategy Dice, by Shmuel Gershon
• Heuristic Evaluation: How to Conduct a Heuristic Evaluation, by Euphemia Wong
• Testing Mnemonics, by Sneha Bhat
• Exploratory Testing: Finding the Music of Software Investigation, by Jonathan Kohl
• How Do You Spell Testing?, by James Bach
• Blog: Transpection Transpected, by Michael Bolton
• Mnemonics in Software testing, by Rishi Arora
• Testing Mnemonics — Desktop Download, by Del Dewar
• Heuristics Testing, techopedia
• Эвристический алгоритм, wiki
• Mnemonic != Heuristic, Ministry of Testing

Блоги

• Satisfice blog, Heuristic, James Bach`s blog
• Thoughts from the test eye, blog
• Testing Mnemonics, I`m tester blog
• Jonathan Kohl, blog
• Testing is Believing, Ash Winter`s blog

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

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

Передісторія

Ще у 2011 році аналітики Gartner прогнозували, що 85% випадків взаємодій із клієнтом буде відбуватися через розмовні інтерфейси. І вгадали. Чат-боти швидко увійшли в маси, особливо після того, як свої платформи запустили всі популярні месенджери. Свого часу через 2,5 місяці після запуску ботів на Facebook Messenger Platform їх було вже більше 11 000. Станом на 1 травня цього року їх було вже 300 000.

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

На щастя, небажання людей розводити «application zoo» розуміє і бізнес. Тому починає розробляти чат-ботів, щоб спростити користувацький досвід, бути ближчим до користувача та цілодобово тримати з ним контакт.

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

Перші — це, наприклад, боти, що замінюють перший рівень служби підтримки і розвантажують операторів. На ринку є продукти, які фокусуються на заміні IVR-систем (Interactive Voice Response) через технологію розпізнання голосу у поєднанні із NLP (Natural Language Processing). Коли відсоток розпізнання малий, людину автоматично перемикають на оператора. Ініціювати перехід може і сам клієнт.

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

Замовлення

Вже протягом двох років наша команда займається R&D у сфері conversational user interface. За цей час ми розробили більше 10 proof of concept для замовників із різних сфер на основі власного акселератора і доступних на ринку бот-фреймворків.

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

Спочатку мова йшла про те, що EPAM розробить тільки back-end бота на Java. Частину роботи, пов’язану з NLP, замовник планував делегувати каліфорнійському стартапу, який фокусується саме на NLP та чат-ботах. Проте наша команда, використовуючи акселератор та R&D-напрацювання, буквально за тиждень створила повноцінного чат-бота, і таким чином ми виграли bidding у каліфорнійців і стали відповідальними за весь проект.

Що зовні

Перше delivery ми зробили вже за 9 днів. На той момент це був чат-бот, який був сфокусований на пошуку музичних подій в США. Після кожного релізу відбувалося user acceptance testing для покращення користувацького досвіду.

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

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

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

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

Що під капотом

На ринку вже є достатня кількість рішень NLP. Є багато SaaS-рішень, які є частиною чат-бот фреймворків. Є SaaS-рішення конкретно по NLP — Microsoft LUIS, IBM Watson, Amazon Lex, Google Dialogflow. Є низькорівневі фреймворки, які працюють як сервіс чи бібліотека: Google SyntaxNet або Google Cloud Natural Language API, spaСy, Stanford CoreNLP.

Проте для чат-бота ми вирішили розробити кастомний бекенд та кастомний NLP Pipeline. Основною складовою була бібліотека NLP4J від Emory University. Інші складові — це онтологія knowledge graph, за допомогою якої знаходили і зберігали всі entity і зв’язки між ними. Наприклад, виконавець, який відноситься до жанру музики, її піджанру, сегменту і так далі. Так само зберігали деяку інформацію про користувача, яку він надавав, щоб бот не задавав однакові питання кілька разів.

Ще один компонент — Rule Engine. У деяких випадках команда писала невелику кількість дедуктивних правил, бо на початку дуже важко назбирати тренувальний набір даних. Це основна проблема багатьох проектів із машинним навчанням: без training set дуже важко побудувати будь-яку модель. Тому для «холодного старту» використовували knowledge graph, dependency tree, part of speech tree, named entity recognition для того, щоб збирати необхідний набір даних.

У замовника для такого проекту була суттєва перевага — у компанії вже є інформація про основні entity в системі. Є визначена кількість виконавців, майданчиків, країн, міст, різних можливих варіацій часу (увечері, наступного дня, тижня, місяця, у четвер). Тому, якщо речення просте і не містить заперечень, логічно використовувати named entity recognition і більш низькорівневі інструменти без training set. Без великої кількості репортів для генерації такого сету та процесу навчання.

NLP4J, як і Microsoft LUIS, дає можливість на основі training set виокремлювати з речення різні entity, включаючи параметри часу. Але команда використала її лише для складних кейсів. Наприклад, Осло може бути і містом, і театральним гуртом. У такому випадку користувач може вибрати, що він має на увазі. Проте якщо користувач, наприклад, пише «What’s up in Oslo?» одразу буде зрозуміло, що мова йде про географію.

Тести, тести, тести

Функціональність продукту ми планували у тісній взаємодії із замовником. На його стороні був один стейкхолдер з топ-менеджменту, UX-дизайнер і технічний стейкхолдер. Наш Product Owner постійно спілкувався із топ-менеджером клієнта — з ним формували візію та беклог. Львівська команда EPAM складалася з 9 людей: Delivery Manager, Product Owner, Solution Architect, NLP-інженер, два розробники, QA і два DevOps.

Основний ризик розмовних — та і загалом нових — інтерфейсів у тому, що такі технології зазвичай ще не повністю опробувані користувачами. Тому невідомо, наскільки чат-бот може бути популярним на ринку і чи взагалі користувачі, які, наприклад, купують квитки у додатку, будуть користуватися чат-ботом. Щоб підтвердити чи спростувати ці припущення, команда після кожного релізу проводила user acceptance testing.

Фактично близько 50% scope було визначено, а решта 50% формувалася на основі user acceptance testing. Він проходив через Slack-канали, де була внутрішня фокус-група із працівників клієнта — до сотні людей в різний час. Кожні два тижні після кожного релізу їм анонсували нову функціональність, збирали конкретний фідбек і всі результати зберігали в одному проекті в Trello. В Jira вже працювали з конкретним фронтом робіт, який вирішили передавати в розробку. Через те, що половина scope формувалася на основі відгуків користувачів, робота була побудована по Kanban.

Процес роботи над ботом

Досить багато часу у команди пішло на дизайн продукту. Ми розробили десятки різних прототипів із використанням Botsociety — цей інструмент дозволяє прототипувати чат-ботів і продукувати user experience. Необхідно було вирішити, яким чином чат-бот має виглядати: він має бути клікабельним чи розуміти мову?

Для аналізу спілкування тестових користувачів із ботом команда інтегрувала аналітичні інструменти Dashbot.ioта Google Analytics, для яких розробила кастомну метрику вимірювання конверсії.

Загалом проект мав декілька дедлайнів. Спочатку ми орієнтувалися лише на музичні події в США і реліз був запланований на грудень 2016 року. Але замовник захотів, щоб бот підтримував усі типи подій по всьому світу. Тобто до NLP-пошуку треба було додати місця проведення подій. Далі необхідно було додати всі їх типи: крім музичних — спортивні, театральні, мистецькі та інші.

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

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

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

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

Мене звати Юрій Ворон, я працюю у сфері web-розробки та паралельно розвиваю онлайн-ресурс з програмування для початківців — Ravesli. Я переклав більше 150 уроків із C++ та досить часто отримую питання щодо онлайн-курсів, їхньої ефективності та проблем, які виникають після їх завершення. Ще коли навчався в університеті і проходив численні онлайн-курси, я сам зрозумів, що це далеко не панацея, а лише короткочасне знеболювальне для тих, хто обрав професію програміста. Тому в цій статті розглянемо найбільш поширені причини, чому ж після проходження онлайн-курсу з будь-якої мови програмування ви все-таки не станете одразу затребуваним розробником та як це можна виправити.

Image by Роман Кривенко

Чому так виходить

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

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

З іншого боку, такі ресурси, як Codecademy, Treehouse, Code School, Khan Academy, Codewars, edX, Courseraта безліч інших, виконали фантастичну роботу з руйнування цього стереотипу і показали, що програмування не є чимось незрозумілим і недосяжним. Вас ніжно беруть за ручку і проводять, як дитину, у світ коду, змінних, функцій і масивів. І після кожної пройденої глави ваш рівень впевненості зростає все більше і більше. Допоки у вас не складеться, на жаль, помилкове враження, що ви не просто навчитеся програмувати, ви станете повноцінним та високооплачуваним розробником!

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

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

• «Я вивчив Python через онлайн-курс на Codecademy, але не знаю, як за допомогою нього можна щось запрограмувати».
• «Я знаю теорію, але не можу її реалізувати на практиці в коді».
• «Я знаю що таке цикли, але я не знаю, як і коли їх слід застосовувати».

І таких варіацій безліч. Зазвичай, завершуючи онлайн-курс з програмування, початківець ставить галочку біля відповідного поля в списку to-do і переходить до вивчення наступної мови програмування в наступному онлайн-курсі. А коли список завершився, усі онлайн-курси пройдені і настав час практики, то буває ступор. Як програмувати, де програмувати, що програмувати, навіщо — і це далеко не остаточний список питань, які виникають у горе-програміста. Розглянемо основні причини, чому після успішного завершення онлайн-курсів з програмування ви так і не навчилися програмувати.

Причина № 1: Штучне середовище програмування

Це те середовище, яке онлайн-курси надають своїм студентам для введення коду. Користувачі зазвичай пишуть код в одній частині веб-сторінки, а в іншій частині розміщені інструкції, що писати, та підказки з готовою відповіддю, якщо ви десь не зрозуміли покрокову інструкцію (згадуємо Codecademy). Це не справжнє програмування, це просто переписування готового коду. Тому, коли онлайн-курс завершився і пора використовувати реальне середовище програмування, як, наприклад, Visual Studio, ви відчуваєте себе «потєрями». Ви просто звикли до колишнього штучного середовища програмування, де були чіткі інструкції, що за чим натискати і що писати. І зараз ви не можете адаптуватися до нового середовища.

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

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

Причина № 2: Надмірна кількість інструкцій і підказок

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

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

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

Причина № 3: Швидке вивчення

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

Real talk

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

У такому випадку ви знаходитесь на 2-муетапі вивчення програмування — етапі «Розчарування», коли приходить болісне усвідомлення того, що все насправді не так просто, як було, коли вас водили за руку і допомагали у всьому. На цьому етапі ваша основна робота — постійна відладка програми і сотня запитань, які ви не знаєте кому і де задавати. Хоча спочатку все було так просто. Щоб розчарування вас зовсім не викинуло за борт, ось вам такі поради.

Порада № 1: Завантажте та налаштуйте повноцінне середовище програмування (IDE)

Налаштувати — значить не тільки натиснути три кнопки «оk» підряд і починати програмувати, а саме розібратися з наявними інструментами та можливостями вашої IDE, які потім будуть економити вам не тільки час і зусилля, але і нерви.

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

Порада № 2: Пишіть програми з нуля

Вам потрібно навчитися писати код без допомоги ззовні. Без інтернету, ментора, підказок, інструкцій і книг. Ніхто не каже про написання бібліотек з нуля, проте базові речі та завдання ви повинні вміти виконувати самостійно (наприклад, перевернути string чи реалізувати бульбашкове сортування). У Coderbyteі Codechefви знайдете безліч подібних завдань.

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

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

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

Порада № 3: Почніть з малого

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

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

Тому не лізьте поперед батька в пекло. Почніть з простих консольних програм/ігор (наприклад: «вгадай число», тест/вікторина чи хрестики-нулики), а потім вже переходьте до більш складних проектів — створення автоматизованих робочих місць (АРМ), органайзерів тощо.

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

Порада № 4: Пишіть багато коду

Програмування не є чисто теоретичним заняттям. Ви не можете читати книги, дивитися відео, проходити тести, а потім очікувати, що зможете написати S.T.A.L.K.E.R. 2. Щоб навчитися писати якісний код, вам доведеться писати його багато, багато і ще раз багато.

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

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

Кожна ваша наступна програма повинна бути більшою та кращою за попередню.

Порада № 5: Працюйте в парі

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

Порада № 6: Не бійтеся задавати питання та робіть це правильно

Є три категорії початківців-програмістів:

• ті, які просять допомогу кожні 5 хвилин;
• ті, які не просять допомогу взагалі;
• ті, які просять допомогу правильно.

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

Другий випадок. Якщо ви принципово не просите допомоги, то цим тільки гальмуєте свій розвиток. Якщо ви цілий день шукали рішення і не знайшли, то перспектива зекономити наступний день, спитавши поради, — непогана, чи не так?

Щоб ваше питання привертало увагу хороших програмістів дотримуйтеся таких порад:

1. Скопіюйте та вставте помилку, яка у вас виникла. Програмісти — не екстрасенси, і не потрібно розписувати цілі мемуари, пояснюючи свою проблему. Просто скопіюйте та вставте помилку.
2. Якщо повідомлення про помилку немає, тоді поясніть, який результат ви очікували від виконання вашого коду, який результат отримали та чому ви думаєте, що ваш код повинен працювати по-іншому. Часто проблема полягає не в коді, а у ваших очікуваннях — що цей код повинен виконувати (повертаємося назад до розуміння основ програмування). Якщо ви не поясните, який результат ви очікуєте, то отримаєте відповідь: «з кодом проблем немає» або «код робочий».
3. Вставте свій код. Дуже важко виправити проблему, якщо не бачиш перед очима код. Якщо ваш код громіздкий — скористайтеся сервісом Pastebin.comі прикріпіть посилання на свій код.
4. Вказуйте, що саме ви вже пробували для вирішення проблеми. Це дасть зрозуміти іншим, що ви намагалися самостійно вирішити проблему, а не відноситеся до першої категорії початківців-програмістів.
5. Будьте обережні з термінологією. Якщо ви не розумієте значення певних сленгових слів — не використовуйте їх.

Де задавати питання:

• у першу чергу Google;
• StackOverflow;
• Reddit — величезна спільнота, де є розділи буквально з будь-якої теми. Ось декілька популярних розділів з програмування:
  
  • Programming;
  • С++;
  • Розробка ігор;
  • Розділ для Android-розробників;
• Quora;
• Тостер;
• Форум DOU;
• Cyberforum.

Висновок

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

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

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

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

Я работаю на enterprise-level аккаунте Dev-Pro, посвященном платформе Point of Sale для ресторанов быстрого питания и retail-бизнеса. Когда-то на проекте был один бизнес-аналитик, сейчас наc 13 на 200+ специалистов. Хочу рассказать какие выводы сделал за год работы на enterprise-level проекте, например, как мы переделывали фичу 15 раз и чему научились из этого опыта, о внедрении изменений, которые могут улучшить процессы и в вашей компании.

Как построен процесс бизнес-анализа на POS-проекте

Задача бизнес-аналитика — описать и довести требования от заказчика до команды разработки. Под «довести» я подразумеваю выяснить, описать до конца, донести своё видение, а иногда — передать клиенту те комментарии и рекомендации, которые пришли от команды разработки.

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

Мы очень тесно работаем с Product Managers со стороны клиента. Все вопросы, связанные с тем, как что должно работать, — мы согласовываем с американскими коллегами, а реализацию обсуждаем с Dev Leads и QA Leads в Украине.

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

У нас затруднен доступ к фидбэку end users, мы не занимаемся исследованием рынка. Всю необходимую информацию и результаты анализа нам предоставляют Product Managers проекта — эксперты в сфере Quick-Service Restaurants, Table-Service Restaurants и Retail. Дело в том, что у нас множество типов заведений: от Table-service restaurants — обычных кафе, где можно поесть за столиком, например, skate-house, до фаст-фудов с бургерами или маленьких точек продажи мороженого. Продукт поддерживает все масштабы — от одного ларька до нескольких тысяч заведений. При таком количестве направлений лучше, если документацию создают эксперты в этой сфере.

Сфера ответственности и экспертизы

Часто можно встретить проекты, где нужен всего-то один бизнес-аналитик: это команды по 10-15 человек.Но что делать, когда аккаунт насчитывает более 200 специалистов, из них 13 — бизнес-аналитики?

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

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

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

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

Уроки

1. Введите груминг

Я рекомендую этот инструмент для более детальной проработки требований и сокращения времени разработки. Как живется без груминга: мы поработали над требованиями, Product Manager утвердил, команда запустила их в разработку. Затем сыпались тысячи вопросов от ребят, потому что ни мы, ни даже продакты, которые хорошо разбираются в доменной области, не можем продумать абсолютно все детали. Важно понимать, что у нас разный mindset: мы (BA, PM) размышляем, что нужно бизнесу, разработчики — как это будет интегрироваться с текущими компонентами, тестировщики продумывают все возможные негативные сценарии. Так и возникают вопросы.

Чтобы изменить эту ситуацию, мы ввели груминг: перед запуском требований в разработку мы собираем большую группу — Dev Leads, QA Leads, BA-team. Каждый задает всевозможные вопросы. Мы выясняем те моменты, которые остались без ответа, даем рекомендации и отдаем фичу в работу только тогда, когда вся команда соглашается и не остается пробелов. Груминг по одному требованию занимает от 1 до 5 митингов: иногда даже простые, на первый взгляд, требования, оказываются проблематичными и вызывают множество вопросов.

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

2. Всегда прописывайте end-to-end flow нового функционала и взаимодействие со всеми компонентами. Всегда!

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

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

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

3. Не бойтесь начать сначала

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

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

4. Обменивайтесь знаниями активнее

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

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

Выводы

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

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

Співбесіди

Була відкрита позиція Data Engineer. Після того як погодився поспілкуватися, було вступне інтерв’ю з HR, де мені розповіли детальніше, чим займається компанія. Після цього вислали досить цікаве та адекватне домашнє завдання.

Треба було придумати алгоритм оптимального використання AWS EC2 Spot Instance, з точки зору оплати та дотримання SLA. Є список задач, і кожна з них може зайняти від кількох хвилин до двох годин машинного часу, а білінг за кожну машину тоді ще був погодинний. Написав досить простий алгоритм, без всякого ML (було вказано що тривалість задач повністю випадкова), додав розрахунки кращого, середнього та найгіршого випадків. Мій варіант рішення сподобався.

Далі була технічна співбесіда з тімлідом: розбір домашнього завдання, питання про stream processing та мій досвід роботи з Apache Storm та дещо про JavaScript.

Наступний етап — співбесіда з СTО. Вийшла несподівано довга, детальна розмова, з великою кількістю технічних питань. Це було несподівано.

Фінальною частиною була розмова з проджект-менеджером: про Scrum, життя і про те, коли краще пити каву.

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

Про компанію

Компанія називається Realeyes, базується у Лондоні. Зараз там знаходяться Sales, менеджмент та частково клієнтська підтримка, а розробка та R&D — у Будапешті. Тут знайшли спеціалістів з комп’ютерного зору, які розробили та продовжують покращувати моделі з трекінгу обличчя та класифікації емоцій.

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

Працюю я у R&D команді. Наразі я єдиний Data Engineer — будую різноманітні системи обробки та збереження даних, системи збору даних для тренування класифікаторів. Також іноді займаюсь оптимізацією алгоритмів написаних дослідниками.

До речі, у нас відкрито багато позицій: Senior Computer Vision Researcher, Data Engineer, Data Engineering Intern та ще у WebDev команді — Automated Test Engineer, Senior Full Stack Developer. Цікава робота, хороша зарплата, дружній колектив, безлімітна відпустка. Пишіть мені, я розповім детально про кожну позицію.

Документи

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

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

Уся перша частина та підготовка документів адвокатами зайняла приблизно місяць, тому вже наприкінці травня 2015-гоми взяли документи й приїхали до консульства Угорщини в Києві. У середині липня отримали візу D для одноразового в’їзду, яка діє 30 днів. За цей час в Угорщині треба отримати тимчасову посвідку на проживання (іноді це займає більше часу, тому візу людям подовжують). Коли ми приїхали, дозволи на проживання були вже готові. Єдине, щоб їх отримати, треба було винайняти квартиру в довготермінову оренду і укласти договір з власником.

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

Житло

На перший місяць після переїзду я винайняв апартаменти на Airbnb. Ці витрати мені потім компенсувала компанія. Саме тоді знайти житло виявилося не так легко, як в інший час, адже в серпні у Будапешті відбувається всесвітньо відомий музичний фестиваль Sziget. До міста приїжджає майже півмільйона людей, майже 95% житла було заброньовано, і квартиру в Пешті знайти було майже нереально. Тому я вирішив спрямувати свій погляд до Буди, адже під час минулих візитів ми майже не звертали уваги на цю частину міста (Дунай ділить місто на дві частини — Буду і Пешт — ред.).

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

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

Далі почали шукати квартиру чи дім на тривалий термін. Три роки тому можна було винайняти двокімнатну квартиру і за 200-300євро (70-90тисяч форинтів, хоч і з труднощами). Але ми переїхали до Угорщини не на заробітки, а заради поліпшення якості життя. Тобто ми хотіли знайти квартиру набагато кращу, ніж у Дніпрі. Тому спинили вибір на двокімнатній квартирі у невеликому трьохповерховому будинку на 10 апартаментів; зі спортзалом, критим басейном та саунами. До квартири маємо ще додаткове приміщення для зберігання речей (у нас там зберігаються лижі, клюшки для гольфу, великі валізи, шина, алкоголь та пакет із пакетами). За місяць оренди сплачуємо 600 євро та приблизно 150 євро комунальних послуг. До офісу 7 хвилин машиною або 10 хвилин автобусом, до центру десь хвилин 15 автобусом. Зараз розглядаємо варіанти переїзду або у дім неподалік Будапешту десь на пагорбах або у квартиру з великою терасою. Але це складно, бо водночас бажаємо знайти щось краще і дешевше.

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

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

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

Купівля нерухомості

Ціни на нерухомість виросли приблизно вдвічі за останні три роки. За двокімнатну квартиру у непоганому місці і хорошому стані доведеться викласти приблизно 100 тисяч євро. Наприклад, мій колега придбав квартиру 160 м2 за 180 тисяч євро. Житло у центрі, у старовинному будинку, але в не дуже хорошому стані.

Чому зросли ціни? На мій погляд, перший фактор — низька ціна по кредитах (під 1-3%можна взяти іпотеку). Другий — держава для поліпшення демографії за народження трьох дітей видає 10 мільйонів форинтів (десь 35 тисяч євро) + стільки ж у виді безвідсоткового кредиту на купівлю або будівництво дому/квартири і практично звільняє від податків. Третій фактор — Будапешт є дуже популярним туристичним напрямом. Багато іноземців (китайців, наприклад) скуповують нерухомість і здають в оренду на Airbnb. Зараз бум на нього, бо якщо здаєш подобово, платиш менше податків, ніж за довготермінову оренду. Оскільки ціни ростуть, то це ще й інвестиція.

Також на матеріали для будівництва свого будинку відмінили ПДВ (був 27%). Але це до 2020 року, а далі будуть переглядати цю норму. Оскільки вже небагато часу залишилося, усі будують. Тому ринок просто вирує.

IT-ринок

Після України у мене склалося враження, що місцевий IT-ринок не такий активний. Особливість — тут небагато чистого аутсорсу, знаю лише про ЕPAM. Більше офісів місцевих стартапів, наприклад Prezi, Ustream, iGO або великих компаній, як IBM, Oracle, GE, Bosch, Cloudera, Hortonworks. Навіть є дата-центр CERN.

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

Зарплати

Ситуація схожа до української: зарплати в IT вищі за середні. Але все ж не такий великий розрив, як в Україні. Середня брутто-зарплата по країні — приблизно 250 тисяч форинтів (760 євро), у Будапешті — близько 350 тисяч форинтів (1000 євро), а середня зарплата програміста — приблизно 600 тисяч форинтів (1800 євро). Але є багато компаній, де ця сума в півтора-два рази більша. Також інколи у невеликих місцевих ІТ-компаніях частину зарплати виплачують у конверті.

Податки

Після роботи в Україні як ФОП третьої групи, податки тут здаються дуже великими. Компанії мають сплачувати корпоративний податок — у цьому році 19,5%, у минулому — 22%, раніше — 27%.

Інші податки плачу я. Їх знімають автоматично: найбільша частина — це 15% загального податку. Щороку його на один-два відсотки знижують (коли я приїхав, він був 18%). Було дивно — уперше бачив, що податки знижують. Пенсійний — 10%, медична страховка — 3%, соціальний податок — 4% та 1,5% відрахування на біржу праці. Загалом цього року працівник платить 33,5%.

Медицина

Як вже зазначав, обов’язкова державна страховка — це 3% від зарплати. Вона покриває все, навіть на 70-95%витрат на ліки. Стоматологічні процедури також входять у вартість (хоча мої колеги надають перевагу приватним лікарям).

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

Якщо не подобаються державні лікарні, можеш обрати приватні, вони не коштують дорого. Колега з британського офісу мав проблеми з коліном і ходив у приватну клініку. Сказав, що в Лондоні він витратив приблизно в 40 раз більше грошей і результату не було, а в Будапешті його проблеми вирішили за декілька відвідувань.

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

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

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

Мова

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

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

Національна кухня та продукти

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

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

На продукти та товари для дому на двох витрачаємо десь 90 тисяч форинтів (300 євро) на місяць. Оскільки приділяємо велику увагу якості та смаку продуктів, та, може, десь і подобається сам процес вибору, ми їздимо по різних магазинах та ринках. Овочі та фрукти беремо на великому критому ринку або на якомусь маленькому фермерському. Є можливість їх безпосередньо замовити додому у деяких фермерів. Також знаємо декілька хороших м’ясних крамниць (наприклад, є турецька крамниця з чудовою ягнятиною з власної ферми), але часто м’ясо, рибу, деякі крупи та інші товари для дому купуємо у «Метро». В Aldi дуже непогані всі «біо» молочні вироби, у Tesco часто бувають хороші знижки на різний алкоголь, у Lidl також інколи зазираємо. Є ще локальна мережа CBA, у деяких можна знайти дуже непогані місцеві продукти (наприклад, фрукти та хліб, але у нас є улюблена пекарня, тож замовляємо його там).

Для угорців їжа дуже важлива. На роботі хвилин 20 займає обговорення меню (у нас навіть є Slack-боти з меню всіх закладів поряд) та куди сьогодні йти на обід. Кафе і деякі ресторани пропонують щоденні обідні меню з 12:00 до 15:00. Вартість одного такого обіду з двох страв — приблизно 1200-1500форинтів (4-5 євро).Досить смачно і різноманітно, на такому ланчі можуть запропонувати і барбекю.

Вечеря на двох у кафе коштує 6-15тисяч форинтів (від 20 до 50 євро). У ресторанах часто можна замовити тільки від 3-хдо 6-хкурсів меню, без опції a la cartе. У Будапешті дуже велика кількість ресторанів, кафе, барів, пабів та місць, яким навіть важко дати якусь категорію, наприклад є свій аналог Mercato Centrale у Флоренції або перший Ruin Pub Szimpla.

Люди

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

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

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

Транспорт

Громадський транспорт дуже хороший, їздить часто, його багато. Усе побудоване навколо трамваїв — це головний транспорт у місті. Метро теж користуються, але менше. Найпопулярніший маршрут — 4 або 6, їздить найдовший трамвай у світі (54 метри завдовжки), у години пік ходить раз у 30 секунд.

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

Паперові квитки треба штампувати при вході. Контролери ходять часто. Один квиток коштує 300 форинтів (1 євро), якщо купувати 10 штук. У водія коштує 1,5 євро. Якщо на маршруті слід пересідати, то потрібен ще один квиток. Проїзний на один місяць коштує 10 тисяч форинтів (35 євро), він дійсний для всіх видів транспорту по місту і частково за містом.

Щодо таксі, раніше був Uber, потім таксисти вийшли на страйк, і його заборонили. Мотивація була в тому, що всі таксі мають дотримуватися умов: колір авто (жовтий), місцерозташування інформації про тарифи, усі повинні мати термінал для оплати карткою, лічильник, а також для всіх таксі — єдиний тариф — 300 форинтів (0,9 євро) за кілометр, та фіксована плата за посадку та час очікування. Таксисти можуть обманювати туристів, мовляв, карток не приймаємо, лише кеш. Якщо терміналу немає, то можна викликати поліцію — тоді він швидко знаходиться. Є кілька служб таксі, найкраща, на мій погляд, — Főtaxi. Наприклад, поїздка з центру до мого дому коштує 2000-2500форинтів (7-8 євро).

Переваги та недоліки життя в Угорщині

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

Дуже вигідне розташування країни — 600 кілометрів машиною до Хорватії і моря, 500 кілометрів до Австрії чи 250 кілометрів до Словакії і катання на лижах або 700 кілометрів до Баварії і прекрасного пива з чудовими краєвидами. До України всього 300 кілометрів. Також з аеропорту є багато недорогих рейсів у різні куточки світу (від Пекіна до Лос-Анджелеса). У Нюрнберг, наприклад, можна полетіти за 10 євро. Безпосередньо в Угорщині теж дуже багато цікавих місць — це така собі мініатюра світу: свої невеликі гори (максимум 1014 метрів) з лижними трасами, угорське «море» Балатон, термальні джерела, маленька Тоскана біля регіону Токай, згаслі вулкани, степи та маленька пустеля. І все це максимум за дві години машиною.

Балатон

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

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

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

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

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

Угорщина — такий собі мікс Західної і Східної Європи. У цьому її плюс і мінус водночас.

С 11 июня по 7 июля 2018 года мы проводили очередной анонимный зарплатный опрос, в котором приняли участие 9610 человек.

Исходные данные в CSV доступны на GitHub. Все зарплаты указаны в долларах США (по курсу межбанка), чистыми (после уплаты налогов). Для оценки зарплаты в выборках используется медиана. Статьи с результатами прошлых опросов здесь.

Портрет участников опроса

19,1% женщин, 80,9% мужчин. Доля женщин с каждым годом увеличивается:

Для должностей Junior Software Engineer, Software Engineer, Senior Software Engineer (развернуть):

Для должностей Junior QA, QA, Senior QA (развернуть):

Распределение анкет по возрасту, медиана — 27 лет:

Топ-7 городов: Киев (43,7%), Харьков (15,6%), Львов (12,1%) Днепр (6,9%), Одесса (5,8%), Винница (2,6%), Запорожье (1,6%). Удаленно работает 2,4% респондентов.

Уровень знания английского

Популярность должностей

Должности женщин

Должности студентов

Должности тех, кто работает удаленно

Средний возраст для разных должностей

Распределение возрастов Junior- и Senior-разработчиков:

Средний опыт работы для разных должностей

Популярность языков программирования

У Erlang 4 анкеты, у Flex/Flash/AIR 3, ABAP и APL по 2. См. также рейтинг языков программирования.

Среди тех, кто работает удаленно:

В стартапах программируют на:

Средний возраст разработчиков в зависимости от языка

Популярность вузов

См. также рейтинг вузов.

Распределение анкет по типам компаний

Средние зарплаты по всем должностям

Киев (развернуть)

Харьков (развернуть)

Львов (развернуть)

Днепр (развернуть)

Одесса (развернуть)

Зарплаты Java, C# и C++ разработчиков

В Киеве (развернуть)

В Харькове (развернуть)

Во Львове (развернуть)

Зарплаты Java Android и Java не-Android разработчиков

В Киеве (развернуть)

Зарплаты Android разработчиков: Java vs Kotlin

См. также серию статей Java vs Kotlin для Android.

Зарплаты Objective-C и Swift разработчиков

Зарплаты PHP, Python и Ruby разработчиков

В Киеве (развернуть)

Зарплаты JavaScript разработчиков

Зарплаты QA

В зависимости от специализации (Киев)

Зарплаты сисадминов и DevOps-инженеров

Зарплаты менеджеров

Есливыбрать только тех PM-ов, у которых 3+ лет опыт работы и английский выше среднего или продвинутый:

Зарплаты выпускников вузов

По всем городам и должностям, учитываются анкеты тех, кто уже закончил учёбу, показываются вузы с 40+ анкет:

Зарплаты студентов вузов

Показываются вузы с 10+ анкет:

Тип компании

Следующий график построен для Киева:

Динамика

Лучше всего смотреть страницу Динамиказарплатного раздела с интерактивными графиками. Вот несколько графиков оттуда (по всем городам):

Java

C#/.NET

C++

JavaScript

PHP

QA

Интерактивный зарплатный виджет:

Альтернативные виджеты: doustatistic.byethost7.com, devua.seektable.com

Раздел Зарплаты с подробной информацией: jobs.dou.ua/salaries.

Данные о количестве вакансий и откликов смотрите в разделе Тренды.

Від редакції: у рубриці DOU Booksспеціалісти розповідають про 5 своїх улюблених книжок — ті, які змінюють світогляд та корисні читачам-колегам.

[Любомир Остапів — засновник соціального проекту фінансової грамотності українців «Сімейний бюджет, партнер iPlan.ua. Раніше — фінансовий директор Coppertino, Stanfy, SupportYourApp]

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

Часто інвесторам-початківцям радять книжку «The Intelligent Investor» by Benjamin Graham, адже це вчитель самого Ворена Бафіта. Однак якщо й справді почати читати цю фундаментальну книгу, то «редкая птица долетит до середины Днепра». Мені більше подобаються книжки, де, окрім принципів і сухих цифр, є історії.

Thomas J. Stanley «The Millionaire Next Door»

У російському перекладі — Томас Дж. Стэнли «Мой сосед — миллионер»

4,5 зірки на Амазоні з 2600+ відгуків — промовисті.

Хоча в книжці багато статистичних даних і таблиць, насправді вона про цінності. На основі фактів з найбільшого в історії дослідження діяльності американських мільйонерів (net worth > $1 mln) автори показують, як насправді стиль життя багатих людей відрізняється від картинки в голлівудських фільмах.

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

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

Цікава думка, яка запам’яталася:

«I am not impressed with what people own. But I’m impressed with what they achieve. I’m proud to be a physician. Always strive to be the best in your field.... Don’t chase money. If you are the best in your field, money will find you».

Douglas P. McCormick «Family Inc.: Using Business Principles to Maximize Your Family’s Wealth»

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

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

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

Цікава думка, яка запам’яталася:

«As Family CFO, your job is much broader than making investment decisions, which is the typical role of investment advisers. The capital in your asset management has a significant influence on your ability to raise cash at various and sometimes unexpected times and consequently on how you should allocate your assets. Your priorities should be to arrange your assets to protect against financial distress and provide for required spending, expand and support your labor, and only then to make investments to support future consumption».

Carl Richards «The One-Page Financial Plan: A Simple Way to Be Smart About Your Money»

У російському перекладі — Карл Ричардс «Давай поговорим о твоих доходах и расходах»

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

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

Цікаві думки, які запам’яталися:

«Leave it alone. Would you ever plant a tree and then go in every month and dig it up to see how the roots are doing?».

«Real financial advisors diagnose before prescribing».

Владимир Савенок «Как составить личный финансовый план и как его реализовать»

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

Книга базова, але водночас для тих, хто починає планувати своє фінансове життя, вона розкладає все по поличках. Також є приблизна схема диверсифікації активів на основі статистики з США: 25% — пенсійний фонд, 20% ризиковані активи, 20% — нерухомість, 20% — бізнес, 15% — депозити і аналоги.

Цікаві думки, які запам’яталися:

«Если вы будете думать о бюджете как о „финансовой диете“, то наверняка настроите себя на неудачу. Бюджет — это лишь:

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

Сергій Біденко «Як розповісти дітям про гроші. Книга для батьків: 100 домашніх ігор і практик»

Цього року для мене стала актуальною тема фінансової грамотності дітей, тому я перечитав усі книжки українською мовою з цієї тематики. Окрім Кіри і пса Мані, можу порекомендувати книгу відомого українського експерта, засновника проекту «Детки-Монетки» Сергія Біденка.

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

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

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

Олексій Волков, 32 роки, Technical and Product Architect

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

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

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

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

За 15 років кар’єри про вищу освіту запитували лише рази два, але жодного разу це не вплинуло на результат.

Першим крокам в IT мене намагався навчити старший брат. У 9 років мені подобалося працювати за комп’ютером, однак інтересу до програмування особливого не було. Потім мені в руки потрапила книга «Мишка-програмишка в країні програмування». Це був якийсь підручник з Basic для молодших школярів, перекладений з французької. Завдяки подачі матеріалу зрозумів суть та основні принципи програмування.

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

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

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

Иван Карабаджак, 26 лет, PHP и Python разработчик

Начал программировать в 14 лет. Сначала было очень интересно, как компьютер работает изнутри, а потом захотелось заставить его что-то сделать. Учил С++, Delphi, PHP, C#, Java. Сейчас код пишу нечасто, в основном PHP, Python. Работаю консультантом в Beetroot, преподавателем в Beetroot Academy. Основная работа — развиваю свою компанию WP Rock.

Поступал в ОГАХ, специальность «Компьютерные системы и сети». Сразу были сомнения, что это все не нужно. Первой официальной работой было сисадминство в институте. Я устроился туда почти сразу на первом курсе. Достаточно неплохо исправлял проблемы с сетью, железом и ПО. Диплом не просили, так как знали, что мне всего 18 и я у них учусь.

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

Как программист в компании я начал работать только в Beetroot в 2016 году. И то на part-time. В итоге на проект подключили еще одного разработчика, и я стал только консультировать.

Мою учебу в ИТ можно разделить на 3 этапа:

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

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

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

Максим Волошин, 28 лет, Frontend Developer

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

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

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

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

Откровенно говоря, я не помню, почему я начал изучать именно фронтенд-стек. Когда начал интересоваться ИТ, я не имел ни малейшего представления о том, как все устроено и какие бывают специализации. Про DOU тоже не слышал :) Начал с HTML + CSS, сидел в основном на htmlbook.ru. Потом еще добавил JavaScript на javascript.ru. Мой английский был на очень базовом уровне, поэтому мог пользоваться только русскоязычными источниками. Не могу сказать, что самообучение было эффективным. При том, что я нормально усваивал материал, я совершенно не понимал, как это все использовать. Потом узнал про курсы в SoftServe. Моего трехмесячного самообразования оказалось достаточно, чтобы пройти технический тест, а английский был не на высоте у большинства «абитуриентов». Через три месяца курсов по фронтенду в сочетании с Ruby меня взяли в SoftServe, где я смог учиться уже на практике.

Мне кажется, что украинское образование безнадежно устаревает. И дело не столько в программе (не уверен, что к той же математике применимо понятие «стареть»), сколько в подходе. Образование в Украине ставит перед студентом задачи сдать определенные экзамены по определенным предметам и написать диплом условной актуальности, но не формирование профессиональной компетенции. Я какое-то время рассматривал возможность заочного обучения в Украине, но решил, что лучше не связываться. Год назад поступил в University of the People — американский вуз дистанционного образования. Он дает возможность учиться удалено за относительно небольшую плату. Может, через несколько лет закончу.

Денис Кулик, 21 год, Product Manager

Я начал работать в Readdle в команде поддержки. Затем полгода работал в отделе продаж Fluix (B2B продукт от Readdle). Получив хороший опыт, я присоединился к команде Spark в роли Product Manager’a. Работаю там уже больше года, и пока что самым большим достижением для нас был релиз Spark for Teams.

В 10-мклассе мне посчастливилось стать финалистом программы FLEXи получить стипендию на год обучения в США. Тогда же я решил, что хочу поступить в американский университет на специальность «Computer Science». Процесс поступления, уроки и результаты — это тема другой статьи :)

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

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

Работа сама нашла меня. Я слышал о Readdle и пользовался Spark. Однажды мне написали на LinkedIn с предложением пройти собеседование в Customer Support. О дипломе речь не шла. На тот момент мне помогли базовые навыки программирования, интерес к технологиям и, самое важное, хороший уровень английского после года жизни в Штатах.

У каждого есть личный онлайн-бренд. Рекрутеры часто смотрят LinkedIn, Facebook и прочие сайты. Важно использовать это как возможность показать свой профессиональный опыт и результаты проектов, над которыми вы работали.

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

Я считаю, что людей берут на работу не из-за диплома, а из-за навыков, которые потенциально стоят за этим дипломом. Поскольку диплома у меня не было, я рассказывал о примерах своих проектов: Hour of Code или образовательном проекте, который начал развивать после школы. Как по мне, вот эта статьяс World Economic Forum отлично описывает ТОП-10 навыков, которые работодатели будут искать в кандидатах к 2020 году. Очень советую почитать и понять, как ваше образование или проекты помогут получить эти навыки.

Еще со времен учебы в Штатах я понял, что самообразование — это мой единственный способ быть конкурентоспособным. Начиная с 10 класса, я старался максимально на нем сфокусироваться. В списке ниже, по моему мнению, самые интересные курсы для получения навыков работы в IT, которые больше всего помогли мне в роли Product Manager’а:

• Computer Science 50 from Harvard University;
• Product Design by Google;
• The Science of Everyday Thinking;
• Official TOELF English Language Course.

Эти курсы — только вершина айсберга. Очень советую посмотреть на платформы edX, Udacity, Khan Academy. Я верю в то, что обучение не заканчивается никогда и всегда можно получить новые навыки, которые помогут в работе.

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

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

Лично я решил продолжить образование в американском онлайн-университете University of the People. Для меня это возможность получить качественное образование и одновременно продолжать работать. Так я научился лучше распределять свое время и приоритеты. Но самое важное, я понял, что университет помогает получить теоретические знания, а работа дает возможность попробовать эту теорию в действии и понять, что нужно выучить дополнительно.

Никита Потапенко, 21 год, Junior .NET Developer

Программировать я стал около 2-хлет назад. Начинал с С/С++, но быстро перешел на C# (понравился очень :)). Работать начал около 9 месяцев назад. За это время изучил много нового, успел сдать экзамен от Microsoft и сталсертифицированным специалистом. Хобби: музыка, книги, программирование.

После окончания школы я, как и все, планировал поступить в вуз. Однако на меня повлияли мои старшие друзья. Многие из них говорили о том, что они ожидали большего от университета. В основном это было связано с некачественной программой обучения — материал был старый и не совсем актуальный. В итоге я решил не сдавать ВНО и не поступать в вуз, а заняться самообразованием. Учителя и родители, конечно же, беспокоились и постоянно говорили о том, что высшее образование необходимо, но не могли внятно объяснить, для чего — просто нужно, так делают все. В итоге, окончив школу, я всё же поступил в Академию ШАГ, которую так и не окончил, так как начал работать фуллтайм. Также я успел поучиться в BaseCamp’e по JavaScript от GlobalLogic, но тоже не закончил его, так как понял, что JS — это не моё. В целом от начала обучения до начала работы я потратил ~1,5 года.

Сейчас очень много компаний имеют свои «академии» — программы обучения для студентов. Через такую программу я, собственно, и попал в компанию. Меня спрашивали про высшее образование, но в результате это никак не повлияло на решение, брать меня на работу или нет. Когда я закончил обучение в академии Binary Studio, мне предложили присоединиться к компании, так как я соответствовал уровню Trainee .NET Developer. А после испытательного срока получил оффер.

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

Безусловно, фундамент знаний мне дали офлайн-курсы. Но через какое-то время я начал чувствовать, что этого недостаточно. Именно тогда я начал делать упор на самообразование. В основном я читал онлайн-документацию, книги и смотрел видеокурсы на Udemyи ITVDN. На ITVDN довольно неплохие курсы по .NET — с их помощью я реально узнал много нового и применил на практике. Так я учился около 4-6 месяцев.Да и сейчас продолжаю заниматься самообразованием — читаю книги, смотрю видеокурсы.

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

За 10 років роботи в галузі в мене назбиралось багато «корисних» порад для майбутніх CEO аутсорс-компаній, якими я просто не можу не поділитись. Ці поради (якщо їх не робити), зекономлять тобі купу грошей і вбережуть від стресу.

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

Почати легко

Бізнес-план можна ж не писати, правда? Почати варто з реєстрації юридичної особи. ТзОВ буде саме враз. Тиждень — і ти директор, життя вже стає веселішим!

Офіс

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

Бачив, які офіси у Фейсбука і Гугла? Щоб програмісти просто погодились прийти на співбесіду, доведеться вкластись у ремонт, зробити бар і поставити якісний блендер для смузі.

Команда

Бізнес — штука така, що самому буде тяжкувато, тому збери надійних одногрупників і дай їм долі в компанії. Тепер всі труднощі зможеш розділити на п’ятьох. Хто що буде робити придумаєте потім. Головне — ви вже команда!

Вмієш кодити?

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

Менеджер?

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

Перший проект

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

Є, звичайно, й інші способи знайти першого клієнта. Купи базу емейлів. Ну-у-у, як купи. Якщо гроші дуже треба на гіроскутер, то можна і на торентах знайти. Дивися, щоб база була надійна, щось типу ‘10M_emails_CTO_outsource_customers.rar’. Так само знайдеш скрипт для розсилки. Звучить ненадійно? Не парся, без проколів не буває . Одного разу я так привітав президента США та весь уряд з Різдвом і Новим роком. Ех, досі відчуваю холодок по шкірі, коли згадаю, як чекав на спецназ у квартирі після блокування всіх наших ресурсів.

Виділяйся

Зроби сайт — це важливо. До сайту треба підійти серйозно. Вордпрес, Вокс чи Тильда видасть у тобі новачка. Знайди відомого дизайнера і готовий дизайн закодуй на чомусь екстравагантному, наприклад, Go.

Поки не знаєш, на яких технологіях буде перший проект, напиши на сайті список усіх, про які чув —  не прогадаєш. Як ти думаєш я почав працювати з Ruby? У далекому 2006 я почув про Рельси від колеги і додав їх у список до PHP, Java і C++. Хто ж знав, що перший клієнт захоче саме цю технологію. І не переживай, що ніхто в команді не має досвіду — якось викрутишся.

Аутсорс, аутстаф, fixed price, MVP чи legacy. Розібратись у нюансах нереально. Просто берися за все, що є. На старті вибирати не доводиться.

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

Відразу заплануй два роадшоу в Європу і США. Це спосіб пошуку клієнтів для справжніх профі:  ти катаєшся по містах, набиваєш зустрічі і пробуєш продати своїх програмістів. Очна зустріч  - твій шанс запам’ятатись і почати будувати відносини. Привези подарунки, одягни костюм Скруджа МакДака. Задача — виділитись і запам’ятатись із сотень таких, як ти.

Цінності

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

Дорогу здолає той, хто йде

Що ж, коли все зроблено, можна насолодитись результатом. Програмісти кодять, бухгалтер виставляє інвойси, офіс-менеджер облаштовує вейп-кімнату  - красота. Деякі труднощі будуть, але ж ти знав, на що йдеш. Попереду багато рутини, нових випробувань і виправлення вже зроблених помилок ;)

А якщо серйозно...

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

У своєму інстаграмі я ділюся думками та ідеями щодо цих змін — підписуйся.

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

Алексей Цой, Senior Developer в Luxoft Ukraine

14 лет опыта

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

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

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

Естественно, в этом вам помогут книги, ставшие классикой. Это Герб Саттер и его «Exceptional C++», «More Exceptional C++»и «Exceptional C++ Style». Это Андрей Александреску и его «Modern C++ Design: Generic Programming and Design Patterns Applied»и «C++ Coding Standards: 101 Rules, Guidelines, and Best Practices», написанная вместе с Саттером. И, конечно же, книгиСкотта Майерса.

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

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

Андрей Каличак, C++ Competence Lead в Perfectial

14 лет опыта

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

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

Для начинающего программиста очень важно как можно быстрее расширить свои знания. Как только будет получен критически минимальный порог знаний по стандарту языка, смежным базовым технологиям его использования (XML, DB, basic patterns/idioms), и это закрепится первым опытом, тогда свои знания можно углублять в выбранном направлении.

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

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

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

Обязательно паралельно необходимо осваивать последние стандарты и технологии — C++11/14/17, библиотека Boost, Gtest, Git. Обрети уверенность в использовании хотя бы одной IDE (поиск, дебаг, рефакторинг). Это всё значительно повысит твою ценность на рынке труда.

И несколько маленьких советов, которые бы мне помогли в начале карьеры:

• Выделяй себе время на обучение: понятно, что проект может занять всё свободное время, и на первых порах действительно все мысли лишь об удачном старте, но потом, когда войдешь в спокойное русло, не забывай постоянно увеличивать свои знания.
• Отдавайся работе чуть больше, чем требуется: изучи часть чужого кода и найди баг, найди не очевидное, а оптимальное решение, углубись в новую библиотеку больше, чем требует этого выполнение задачи.
• Выпрашивай себе всё более сложные задачи, даже на первый взгляд непосильные для тебя: именно так и развивается разработчик. Плюс это хорошая мотивация для тех, у кого повышено чувство собственного достоинства и амбиции.
• Разбирай open-source код: там можно подсмотреть и научиться многим вещам.
• Старайся посещать собрания сообщества разработчиков: тут можно позадавать вопросы на более узкие темы и познакомиться с экспертами в разных сферах.
• Регулярно (не обязательно часто) проходи онлайн-тренинги или уроки: это разнообразит твою подготовку и позволит взглянуть под новым углом на некоторые вещи.
• Держи баланс во всём.

Главное — помнить, что никто не стал экспертом сразу. Все прошли через определённые этапы развития, хоть и в индивидуальном русле. И ещё — это всё должно быть в кайф!

Володимир Корнійчук, Senior Software Engineer в Infopulse

12 років досвіду

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

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

Чи варто читати стандарт?
Стандарт мови програмування С++ в одній з останніх редакцій, що траплялася мені на очі, налічує 1622 сторінки. Як це все прочитати (з урахуванням стилю документу) і залишитися при здоровому глузді, я особисто не уявляю. Вивчення С++ по стандарту — найгірша ідея у світі. Є багато книжок, що пояснюють С++ простіше і з теоретичної, і з прикладної точки зору. Можна почати зі списку на Isocpp. А стандарт залиште розробникам компіляторів.

IDE
Підберіть зручне середовище розробки. Я використовую Visual Studio з додатково встановленим плагіном Visual Assist X. Ця зв’язка знає про мову С++ більше за все інше, що я перебирав. Знаю людей, що користуються VS + ReSharper, CLion, Qt Creator, Vim. Мені не підійшло, але ви спробуйте і матимете власну думку.

Debugger
Навчіться користуватися дебаггером (як вбудованим у вашу IDE, так і зовнішнім, типу GDB чи WinDbg). Це, на диво, потужні інструменти, що іноді дозволяють робити неймовірні речі. Більшість розробників використовують їх доволі примітивно, у режимі «поставили точку зупинки — зупинилися на ній», навіть не знаючи про можливості віддаленої роботи, time-travel debugging, підтягування зовнішніх символьних файлів та коду, зупинки по модифікації адреси пам’яті тощо.

Профайлер
Ефективність та швидкість — одні з головних причин використання С++ в сучасних проектах. Без профайлера ви ніколи не здогадаєтесь, де саме «вузьке місце» у вашому коді. Для простих випадків підійде та ж Visual Studio, для складніших — Windows Performance Analyzer або інструменти від Intel. Не пробуйте вгадати, що саме у вас працює повільно. Я бачив, як на це марнувалися тижні. Просто зробіть замір профайлером і усвідомте факти. В більшості випадків проблема буде зовсім не там, де ви її очікуєте.

Інструменти статичного аналізу
Зараз є багато інструментів, що дозволяють вказати програмісту на можливу помилку в коді на С++. Є попередження стандартного компілятора, є нові можливості Visual Studio по аналізу С++ коду на відповідність рекомендаціям C++ Core Guidelines, є аналіз коду в Visual Assist X, є Cppcheck та Clang. Багато чого є, он одна тільки Вікіпедія скільки всього знає. Обов’язково оберіть собі щось і використовуйте. Особливо добре ці інструменти працюють у комбінації з системами неперервної інтеграції.

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

Тримайтеся на вістрі прогресу
Знайдіть собі якесь джерело новин про С++. Мова розвивається, виходять нові стандарти та компілятори, що їх підтримують. Особисто я читаю новини на Isocpp, обговорення — на Reddit, дивлюся відео з конференцій C++Nowта CppCon. Це вимагає не так багато часу, як може здатися, але дає можливість планувати як розвиток вашого проекту, так і ваш особистий.

Николай Родин, С++ Developer в Dev-Pro

8 лет опыта

Зачем нужен С++ сегодня

Мой выбор, когда я заканчивал институт 18 лет назад, был невелик. Web-направление только набирало обороты, и у меня фактически был выбор только между Visual C++ и Delphi. Сегодня же вариантов очень много, а применение С++ найти не так легко. В стремительно развивающейся web-индустрии ему по-прежнему нет места. Вытесняется он и из кроссплатформенного программирования. Если вам интересен этот язык — осталось всего несколько направлений, в которых С++ (и С) еще удерживают позиции:

1. Поддержка легаси проектов под Windows — речь о проектах, которым не один год, а может быть и не один десяток лет. Возможно, некоторым не по душе это направление, но саппорт важен и нужен. Новые проекты появляются редко, в них GUI пишется в основном с использованием библиотеки Qt.
2. Game Development — здесь C++ актуален, ибо важно быстродействие в сочетании с определенной безопасностью.
3. С++ под Linux — здесь С++ по-прежнему востребован ввиду развитости экосистемы. GUI вполне можно писать на Qt, драйвера и некоторые сетевые приложения пишутся даже на С.
4. Embedded — здесь С удерживает твердые позиции, особенно если речь заходит о системах, работающих в реальном времени и на ограниченных мощностях. C++ также вполне используется (как правило, в урезанном виде).

Кому стоит его изучать

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

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

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

Как изучить С++

Осваивать C++ я предлагаю от простого к сложному, начав с С. С считается низкоуровневым и поддерживает в основном процедурную парадигму. Но на его примере можно получить представление об указателях и прямой работе с памятью. Вы также научитесь мыслить битами и тактами, а не только абстракциями языка программирования и шагами алгоритмов. Помимо того, операционные системы до сих пор имеют API, написанный на С, и с ним нужно учиться взаимодействовать.
С++ поддерживает и процедурную, и объектно-ориентированную парадигму (ООП).

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

Полезная литература

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

Для изучения С++ желательно прочитать больше литературы. С++ я изучал по следующим книгам:

• Bjarne Stroustrup «The C++ Programming Language»;
• Джефф Элджер «C++: Библиотека программиста»;
• Скотт Майерс «Эффективное использование C++»;
• Андрей Александреску «Современное проектирование на C++».

Советы новичкам

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

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

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

Михайло Рудий, Senior Software Developer в Vakoms

6 років досвіду

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

Я б хотів поділитися кількома порадами.

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

Memory management.Навчись правильно працювати з пам’яттю. В C++ за пам’ять відповідаєш ти сам. Поки ти не скажеш «видалити» — ніхто за тебе це не зробить. Не хочеш сам керувати пам’яттю — тоді вчи smart pointers.

Класи і три страшні букви (ООП). Робота з класами — це дуже круто, тому старайся знати і вміти використовувати всі можливості класів і ООП.

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

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

Design patterns.Це мегакрута річ. Почни своє знайомство з ними із простого і рухайся до складніших, закінчуй архітектурними. Головне, навчись їх правильно застосовувати.

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

Запозичуй.Хочеш покращити свій код, спробуй знайти хоча б 2 рішення схожої задачі. Можливо, ти знайдеш там щось корисне для себе.

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

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

Не бійся.Не бійся важких тасків (інколи вони тільки здаються важкими). Не бійся спитати поради. Не бійся сказати: «Я вже все спробував і не знаю, як це зробити. Підкажіть, куди рухатись».

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

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

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

І знай, C++ неможливо вивчити повністю :) Завжди буде щось нове, що ти не знатимеш, тому не лякайся. Просто читай і постійно практикуйся.

Ресурси, які допоможуть:

• Bjarne Stroustrup «The C++ Programming Language», 4th Edition;
• Scott Meyers «Effective C++»;
• Scott Meyers «Effective Modern C++»;
• C++ reference;
• cplusplus.com;
• Erich Gamma «Design Patterns: Elements of Reusable Object-Oriented Software»;
• Андрій Будай «Дизайн-патерни — просто, як двері».

Привіт всім. Мене звати Андрій, мені 30, і я, мабуть, один із тих небагатьох, хто вернувся з Європи для того, щоб заробляти в Україні. Ця історія буде цікава для тих, хто хоче змінити своє життя, але боїться. Хто хоче почати, але не знає з чого... Хто мріє жити нормально, а не виживати десь на заробітках у Європі. Отже, поїхали.

Колись давно

Народився я у маленькому містечку Волинської області. Був цілком звичайною дитиною, без жодних суперздібностей. Оцінки в школі були вищі за середні, але вже тоді мені подобалося програмувати. В еру ZX Spectrum та інформації на касетах я вивчав основи Basic. На той час це було просто нереально, коли ти через LPT-порт міг запрограмувати блимання лампочок, щоб був ефект гірлянди :) Далі були перші Pentium і, звичайно ж, Pascal. Цю мову ми вивчали у школі... ну як вивчали. Мої знання були «трошки» більші, ніж у викладача. Зі своїми навиками я назбирав грамот з міських та обласних олімпіад з інформатики, алгебри та геометрії. Після школи я навчався у НАУ на факультеті телекомунікацій і захисту інформації, і все ніби сходилося... Але щось пішло не так :)

Відхилення від курсу

Оскільки родом я був з містечка біля кордону з Польщею, то мої далекоглядні ІТ-плани швиденько помінялися на можливість заробітку — «швидкі гроші». Їх можна було заробити вже і зараз, а не через 3-5років і то — можливо. Я свідомо вирішив завершити навчання після 1-гокурсу і пішов працювати. Був слюсарем-зварювальником, монтував металоконструкції до Євро 2012. Проте остання професія, яку я не збирався змінювати, — водій-далекобійник. Я їздив у Росію, Казахстан, Білорусь — до конфліктного періоду. Далі перейшов виключно на Європу. Стаж водія-далекобійника — більше 5 років. Наразі у мене документи на ПМП (постійне місце проживання) у Польщі, і провів я за кордоном близько 10 років.

Машина, на якій я їздив

І тут почалися думки про IT

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

Навчання

YouTube — наше все :) На той час я на вантажівці їздив у режимі 4/1, і за той 1 тиждень, який був дома, я качав з мережі все, що мені могло б допомогти, буквально гігабайтами. Я абсолютно не знав, ким я хочу бути в цій сфері, і тому доводилося вчити... багато. На вихідних у водіїв-далекобійників багато вільного часу: хтось варить їсти, хтось дивиться телевізор, хтось п’є спиртне. А я поглинав гігабайти інформації і пробував, пробував, пробував! Теоретик з мене ніякий — практика моє все :)

Почалися перші консольні програмки, далі WinForms і навіть трішки WPF зачепив. Ідея була така: треба знати все потроху, бо часу в мене не було довго вчитися. Я тоді поставив ціль: з нового року починаю шукати роботу (майже через 9 місяців самостійної підготовки). Після різнопланових десктопних програм я почав вчити ASP.NET, і мені ця технологія відверто «зайшла»... В інтернеті доволі багато безкоштовної інформації про цю веб-розробку на .NET. Звичайно, що кортежем пішли HTML, CSS, jQuery, Ajax та Bootstrap. Усе це було в перервах між дорогою, постійними завантаженнями та розвантаженнями по всій Європі.

З вересня я почав робити проекти. Першим був редизайн та розширення функціоналу сайту компанії, у якій я на той час працював. Мій шеф дуже здивувався, як це — далекобійник-українець в Польщі ще й сайти робить :) Далі були ще два більш навчальні проекти — інтернет-магазин (Entity, MS SQL) та портал для водіїв (SPA). А час минав...

Переломна зима: резюме

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

У резюме ніде не було зазначено, що я далекобійник, але і досвіду теж було нуль :) Я надсилав резюме майже на всі вакансії, де було написано Junior і .NET. І уже зараз я можу впевнено сказати: це і є запорука успіху. Розсилати треба чим побільше, а не на одну вакансію, і чекати, що це «воно». 80% компаній мені одразу відмовляли на етапі резюме, але були й такі, які відправляли свої тестові. Я їх робив завжди вчасно, проте, звичайно, що ніякого професійного досвіду у мене не було, і код не був таким, як слід. Хоча все і працювало згідно з технічним завданням. І тут, неочікувано для мене, почалися співбесіди...

Співбесіди: вір у себе і в те, що ти робиш!

І ось людина, яка ще півроку тому не знала, що таке С# і що з ним робити, яка абсолютно не вірила в цю авантюру, яка була впевнена, що професія водія-далекобійника — це саме те, починає вірити! Співбесіди я проходив і дома в період відпусток, і онлайн — прямо в кабіні вантажівки під час рейсу. Читаючи вакансії, я вже не лякався тих страшних слів, які там були написані, і моя «спам-розсилка» резюме стала ще більш активною :) Відправлено більше 100 резюме, пройдено близько 10 співбесід, виконано 17 тестових завдань та завершено 4 онлайн-тестування. І це все з нульовим досвідом розробки і без копійки грошей, вкладених у навчання.

План пошуку роботи «провалився»

Мета була одна — знайти роботу з нового року. Але разом з тим були й вимоги. Мені 30 років, сім’я, і працювати за 200-300доларів не логічно. Я хотів мати без досвіду мінімум 500 доларів на місяць. Плани не збулися... Так сталося, що на початок грудня у мене було вже 3 офери, і два з них навіть трохи перебільшували мої сподівання по ЗП! Почалося нове життя...

Сьогодні

З 9.01.2018 я .NET Developer у львівській продуктовій компанії з крутим, драйвовим колективом :) В основному працюю з WinForms та WPF. А з квітня працюю парт-тайм ще у стартапі. Там більше веб-стек технологій (ASP.NET Core, Polymer, ES6, Event Store). За півроку я перетворився з любителя-далекобійника в програміста з доходом Strong Juniora.

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

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

Иван Новоселов, Marketing Manager в Applicature

В Украине полгода, приехал из Молдовы

Почему переехал.В Украине очень динамично развивается ІТ-сектор. Большой упор делается на техническую сторону продуктов, но при этом вопрос о том, как продвигать продукт на рынок, остаётся открытым. А значит, мои профессиональные навыки весьма востребованы. Кроме работы, в Украине много всего привлекательного. Индустрия развлечений (рестораны, кафе, выставки и многое другое) позволяет приятно проводить время в нерабочие часы. Много интересных, прогрессивных людей, у которых европейский тип мышления.

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

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

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

Мне нравится отношение сотрудников друг к другу. Чувствуется, что мы — единая команда. В Киеве множество ІТ-компаний, что создаёт эффект синергии. Куда бы ни пошёл в кафе, почти всегда встречаю людей с открытым ноутбуком, которые что-то кодят или общаются с зарубежным заказчиком.

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

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

Nikola Krastev, Software Architect в CoreValue

В Украине год, родом из Болгарии, приехал из Великобритании

Почему переехал.До переезда я прожил более 10 лет в Западной Европе и Соединенном Королевстве. За это время сотрудничал с несколькими украинскими компаниями по разработке программного обеспечения более 4 лет и был впечатлен профессионализмом здешних инженеров.

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

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

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

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

О работе и украинском IT.Украинским ІТ-компаниям я бы посоветовал сосредоточиться на создании имиджа и репутации бренда. В стране есть наследие преимущественно аутсорсинга, в котором компании полностью полагаются на отношения с несколькими клиентами и, следовательно, адаптируются к их стандартам и методологии. Я считаю, что украинские специалисты обладают навыками и умением работать на гораздо более высоком уровне, чем большинство ІТ-компаний на Западе. Сервисные, производственные и аутсорсинговые компании здесь могут обеспечить более высокий уровень качества и, таким образом, выделяться из традиционных «злачных мест» разработки программного обеспечения.

Brody McKee, Lead Front-end Developer в TechMagic

В Украине около года, приехал из Австралии

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

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

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

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

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

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

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

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

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

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

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

Eoghan O’Donnell, Chief Engineering Officer в Innovecs

В Украине полтора месяца, приехал из США, прежде работал Technical Program Manager в Amazon

Почему переехал.Моя семья переехала в Украину, и предложение стать частью команды Innovecs для меня было очень своевременным. Украинцы очень доброжелательны. Сама страна напоминает мне Ирландию 90-х,когда она превращалась в «кельтского тигра» и был огромный экономический и инфраструктурный рост. Хотя я пока не путешествовал за пределы Киева, сама столица — красивый город с богатой историей. Что мне не нравится? Слишком много выбоин на дорогах!

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

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

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

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

Чему Украине поучиться у США? Я не американец, поэтому, возможно, мои взгляды похожи на взгляды европейцев, но американцы в целом ценят свою свободу. Религия в значительной степени — часть их образа жизни, и, наконец, я бы сказал, что там каждый считает, что может контролировать свой собственный успех в жизни.

Очевидно, что многие IT-компании появились на западном побережье США. Однако, если вы посмотрите на демографию рабочей силы, вы увидите, что значительную ее часть составляют эмигранты. Работа в такой среде учит быть толерантным и принимать разнообразие культур. Я бы также сказал, что это добавляет креативности.

Chris Tiemann, Manager Inside Sales, Lead Development в Cogniance

В Украине 2 года, ​приехал из США, Техас

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

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

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

Первое преимущество Киева по сравнению с США — стоимость жизни. Второе — это легкость, с которой вы можете добраться в любую точку города. Хьюстон вообще не такой. Там вы не сможете просто пойти пешком в продуктовый магазин или ресторан. Вы должны доехать до него на машине (метро нет). Лично я люблю ездить в Киеве на метро. И в такси стоимость проезда относительно невысокая.

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

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

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

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

Честно говоря, я не знаю, что еще украинский IТ-рынок может перенять у США. Это рынок с очень талантливыми людьми. Я бы сказал, просто нужно стараться быть открытым ко всему новому — возможностям, идеям. И я могу уверить, что украинские IТ-специалисты справляются с этой задачей с легкостью.

Torben Frølund, Senior Manager, Development Center Kharkiv в Telenor DK

В Украине 7,5 лет, приехал из Дании

Почему переехал.Я всегда хотел переехать работать за границу. Рассматривал несколько стран. Когда компания решила открыть центр разработки в Харькове, я переехал в Украину.

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

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

Мне нравится погода в Украине, потому что я из Дании :) У нас все время идет дождь. А здесь фантастическое лето. Мне даже зимы нравятся, поскольку у вас настоящие зимы со снегом.

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

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

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

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

Octavio Pérez, Country Coordinator в Preply

Приехал из Мексики

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

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

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

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

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

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

Simon Urbanek, Tutor Success Manager в Preply

В Украине около 9 месяцев, приехал из Германии

Почему переехал.Впервые я побывал в Украине в 2014 году благодаря проекту от университета, посвященному Приднестровью и его экономическим связям с Россией. Поскольку я изучал историю и политические науки, у меня было какое-то представление об Украине. Я, конечно, слышал про Крым, Киев и конфликт на Донбассе. Тогда об этом активно говорили СМИ. В тот раз я побывал в Одессе, познакомился с интересными людьми (мы до сих пор дружим!). Тогда было настолько хорошо, что я потом каждое лето приезжал в Украину по меньшей мере на две недели.

Мысль о том, чтобы уехать из Германии, возникла у меня в конце 2016 года, и, верьте или нет, я сразу выбрал Украину. Я переехал в октябре 2017 года, и не пожалел об этом ни разу.

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

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

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

Верьте или нет, мой уровень жизни здесь немного выше, чем в Германии. Здесь все гораздо более доступно: поездки на такси не стоят целого состояния, еда и вечеринки с друзьями не опустошают банковский счет, а аренда более чем доступна. По правде говоря, я живу сейчас в огромном особняке с двумя друзьями. У нас есть 8 спален, оплата 700 долларов.

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

О работе и украинском IT.Мое первое впечатление о работе заключалось в том, что здесь правила не настолько жесткие, как, например, в Германии. Я помню свой первый рабочий день в Украине очень хорошо (и мои коллеги тоже!). Поскольку у меня не было представления о том, что надевают на работу в украинской компании, в первый день я немного перестарался — надел брюки, рубашку... Меня все спрашивали, мол, ты собрался в банке работать? На следующий день я уже появился в толстовке с капюшоном, как и все остальные.

Я здесь легко привык к позднему началу рабочего дня. В Германии офис уже гудит в 8 утра, а вот в Украине, по моему мнению, обычное время для начала дня — это 10 утра, что я очень ценю.

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

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

Украинскому IT следовало бы быть более строгим и суровым. Пусть не на уровне Германии, но чуть более строгий и целенаправленный подход к чему-то может принести результат. При этом я вижу действительно светлое будущее для украинской ІТ-сферы. Давайте надеяться, что Украина быстро встанет на ноги и станет одной из ведущих стран мира. Она этого заслуживает!

Привет, меня зовут Руслан. Я работаю проектным менеджером в аутсорс-компании Relevant Software. За 4 года своей карьеры я видел много грамотно написанных проектов. К сожалению, не все из них стали успешными. Почти все проекты были сделаны в сроки, в оговоренный бюджет и скоуп. Но у них были одни и те же недостатки: отсутствие Problem/Solution fit, отсутствие ключевых метрик, непонимание того, как правильно приоритизировать, ориентир на чутье вместо данных. Именно поэтому в последнее время я работаю над внедрением продуктового подхода во всех проектах. 60% наших проектов — это стартапы, 40% — средний бизнес, которому нужна автоматизация процессов.

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

Цель этой статьи — дать выжимку самых популярных методологий и увидеть, как в действительности приоритизируют задачи в украинских продуктовых компаниях на примере Readdle, MacPaw, EduNav и Grammarly.

1. Impact/Effort

Самый распространенный подход — соотношение приложенных усилий к отдаче, которую мы получаем после реализации функционала. Effort может быть в человеко-часах либо в сторипоинтах. Impact может распределяться по шкале 1-5либо по шкале high/medium/low.

Очень важно измерять impact по метрике или набору метрик, важных для бизнеса. Сложность заключается в определении этой ключевой метрики, или, как ее еще называют, North Star Metric. У Facebook — это количество уникальных пользователей (DAU), у Booking.com — количество забронированных ночевок.

Сначала сосредотачиваемся на High Impact/Low Effort функционале, а затем Low Impact/Low Effort и High Impact/High Effort. Про функционал типа Low Impact/ High Effort забываем.

Itamar Gilad, бывший продуктовый менеджер Google, предлагает добавить еще один критерий к этому подходу — коэффициент уверенности в прогнозах. Больше можно прочитать в его статье «Why Impact/Effort Prioritization Doesn’t Work».

Приоритизацию Return on Investment часто путают с Impact/Effort. Единственное отличие от предыдущего подхода — в том, что ROI приоритизация базируется на финансовых показателях. Это отношение конечной прибыли к сумме инвестиций. Очень часто от клиентов можно услышать: «Я не могу оценить ценность этой фичи в долларах. Это будет слишком субъективно». Если страховые компании могут оценить ценность потерянного пальца или эмоционального расстройства в денежном эквиваленте, то такой же подход может быть применен и к оценке фичи.

2. Kano Model

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

• Must Be — минимальные требования; если их нет — пользователь не удовлетворен.
• Indifferent — функционал, который вызывает неоднозначную реакцию. Пользователям все равно, есть он или нет.
• Satisfiers (Performance) — функционал, который вызывает удовлетворенность, если он выполнен хорошо, или разочарование — если качество низкое.
• Exciters (Attractive) — функционал, повышающий удовлетворенность пользователя, если он есть. Если его нет — недовольства не возникает.

Обычно сначала фокусируются на Must be, затем — на Satisfiers и только потом — на Exciters.

Очень детальная статья на Folding Burritosо том, как применять модель Кано и как рассчитать ее показатели.

3. Buy the Feature

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

Как правильно организовать такой подход к приоритизации, можно прочитать на UX for the Masses.

4. RICE

Этот фреймворк был разработан в Intercom. После кучи тестов и итераций они остановились на 4 факторах:

• Reach (охват) — скольким пользователям мы улучшим жизнь?
• Impact (эффект) — насколько мы улучшим жизнь нашим пользователям?
• Confidence (уверенность) — насколько мы уверены, что вообще можем что-то улучшить?
• Effort (усилия) — сколько времени нам понадобится, чтобы реализовать задуманное?

По соотношению этих 4 факторов приоритизируем бэклог задач. C деталями можно ознакомиться в блоге Intercom.

5. Karl Wiegers Method

Фреймворк придумал американский инженер, консультант и автор книги «Software requirements» Karl Wiegers. C этим подходом оцениваются benefit, penalty, cost и risk по шкале от 1 до 9. Пользователи одновременно оценивают пользу от присутствия фичи и вред от ее отсутствия. Разработчики оценивают стоимость имплементации этой фичи и риск, связанный с ее разработкой. Далее данные подставляются в формулу и рассчитывается коэффициент приоритетности.

Больше можно прочитать в статье «First Things First: Prioritizing Requirements» by Karl Wiegers.

6. Feature buckets

Подход придумал бывший СEO LinkedIn Adam Nash. Все фичи условно распределяются между 3-мяведрами:

• Metric Movers — функционал, который двигает основные бизнес & продуктовые метрики: Engagement, Growth, Revenue etc.
• Customer Requests — функционал, который запрашивают пользователи. Не каждое желание пользователя может быть реализовано, но это уже тема отдельной статьи.
• Customer Delight — фичи, которые не обязательно запрашивают пользователи, но которые однозначно принесут им value.

Распределяя функционал по этим 3 категориям, можно честно ответить на вопрос: «Почему мы делаем этот функционал?». Потому что пользователи требуют? Потому что компания требует? Или просто потому что это killer фича?

Больше можно узнать в статье «Guide to Product Planning: Three Feature Buckets» by Adam Nash.

Как приоритизируют в украинских продуктовых компаниях

Резюме

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

Меня зовут Александр Белобородов, я .NET Developer в Community Management Department в Plarium. Наша команда разрабатывает инструменты для оптимизации работы агентов поддержки и комьюнити-менеджеров, а также инструменты вовлечения пользователей вне игры. Хочу поделиться нашим опытом использования машинного обучения для сбора обратной связи от игроков.

Зачем это нужно

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

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

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

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

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

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

Немного теории

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

Больше о методе можно почитать по ссылкам, приведенным в конце статьи.

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

• «Один против всех»: обучается N классификаторов, где N — количество классов.
  Классификатор с самым высоким значением функции выхода
  присваивает новый объект к определенному классу. Здесь идет сопоставление типа «самолёт / всё, что не самолёт», «дом / всё, что не дом» и т. д.
• «Один против одного»: обучается N классификаторов, только теперь объект присваивается к тому классу, к которому его отнесло большинство классификаторов. Стратегия напоминает то, как проводятся соревнования в футбольной лиге: команды играют между собой, и та, которая побеждает максимальное количество раз, становится победителем.

Преимущества использования метода опорных векторов:

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

Недостатки метода:

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

Области применения метода опорных векторов:

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

Метод опорных векторов в решении наших задач

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

Готовую реализацию метода мы взяли из библиотеки libsvm.net.

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

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

Адаптируем библиотеку libsvm.net под задачу классификации текста

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

Перед тем как обучать модель, необходимо очистить входную строку от «шумных» слов. Для этого мы разработали класс StringProcessor. Суть его в том, что он содержит два метода — Normalizeи GetWords.

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

public class StringProcessor : IStringProcessor
  {
    private readonly SvmModelSettings _settings;

    public StringProcessor(SvmModelSettings settings)
    {
      if (settings == null) throw new ArgumentNullException("settings");
      _settings = settings;
    }

    public string Normalize(string text)
    {
      var str = text.Replace('\n', ' ');
      return _settings.IgnoredPatterns.Aggregate(str,
        (current, pattern) => Regex.Replace(current, pattern, "", RegexOptions.IgnoreCase));
    }

    public IEnumerable<string> GetWords(string text)
    {
      return
        text.Split(_settings.Delimiters, StringSplitOptions.RemoveEmptyEntries)
          .Select(w => w.ToLower())
          .Where(w => !_settings.IgnoredWords.Contains(w));
    }
  }

Основные модели классификатора выглядят так:

  public enum Emotion
  {
    PositiveOrNeutral = 1,
    Negative = -1
  }

  public class ClassifiedItem //Классифицированный образец
  {
    public Emotion Emotion { get; set; } //Тональность образца
    public string Text { get; set; } //Текст
  }

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

public class SvmModelBuilder //Класс предназначен для создания модели
  {
    private readonly IStringProcessor _stringProcessor;

    public SvmModelBuilder(IStringProcessor stringProcessor)
    {
      _stringProcessor = stringProcessor;
    }

    public virtual SvmTrainedModel Train(IEnumerable<ClassifiedItem> items)
    {
      if (!items.Any())
        throw new InvalidOperationException("No data to train the model");

      var emotionArr = new List<double>();
      var vocabularySet = new HashSet<string>();
      var linewords = new List<string[]>();

      foreach (var classifiedItem in items) //строим словарь слов из полного входного набора
      {
        var words = GetWords(classifiedItem.Text).ToArray();
        vocabularySet.UnionWith(words);
        linewords.Add(words);
        emotionArr.Add((double)classifiedItem.Emotion);
      }

      var vocabulary = new Dictionary<string, int>(vocabularySet.Count);
      var sorted = vocabularySet.OrderBy(w => w).ToArray();

      //сортируем слова в словаре и проставляем индексы
      // чтобы потом исходную строку можно было превратить в вектор признаков
      for (var i = 0; i < sorted.Length; i++)
      {
        vocabulary.Add(sorted[i], i);
      }

      var problem = CreateProblem(linewords, emotionArr, vocabulary);

      //получаем модель при помощи классов библиотеки libsvm.net
      var model = new C_SVC(problem, KernelHelper.LinearKernel(), 1);
      
      //возвращаем модель, готовую к классификации
      return new SvmTrainedModel(model, vocabulary, _stringProcessor);
    }

    private static svm_problem CreateProblem(IReadOnlyCollection<string[]> lines, List<double> emotionArr, IReadOnlyDictionary<string, int> vocabulary)
    {
      return new svm_problem()
      {
        l = lines.Count, //общее количество классифицируемых комментариев

        //превращает строки в вектора признаков
        x = lines.Select(line => NodeUtils.CreateNode(line, vocabulary).ToArray()).ToArray(),

        y = emotionArr.ToArray() //вектор оценок комментариев
      };
    }

    //возвращает список слов из строки, очищенные от “шума”
    protected virtual IEnumerable<string> GetWords(string text)
    {
      var normalized = _stringProcessor.Normalize(text);
      return _stringProcessor.GetWords(normalized);
    }

    //тут извлечение модели из файла…
    //...
  }

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

public class SvmTrainedModel
  {
    private readonly SVM _model;
    private readonly IReadOnlyDictionary<string, int> _vocabulary;
    private readonly IStringProcessor _stringProcessor;

    public SvmTrainedModel(SVM model, IReadOnlyDictionary<string, int> vocabulary, IStringProcessor stringProcessor)
    {
      if (model == null) throw new ArgumentNullException("model");
      if (vocabulary == null) throw new ArgumentNullException("vocabulary");
      if (stringProcessor == null) throw new ArgumentNullException("stringProcessor");
      _model = model;
      _vocabulary = vocabulary;
      _stringProcessor = stringProcessor;
    }

    public Emotion Classify(string text) //выполняет классификацию строки
    {
      return (Emotion)Model.Predict(NodeUtils.CreateNode(GetWords(text).ToArray(), Vocabulary).ToArray());
    }

    //возвращает список слов из строки, очищенные от “шума”
    protected virtual IEnumerable<string> GetWords(string text)
    {
      var normalized = StringProcessor.Normalize(text);
      return StringProcessor.GetWords(normalized);
    }

   //тут методы для сохранения модели и словаря в файл
   //...
  }

Класс NodeUtils.Его задача — превращать массив слов в вектор признаков, используя словарь.

public static class NodeUtils
  {
    public static IEnumerable<svm_node> CreateNode(string[] words, IReadOnlyDictionary<string, int> vocabulary)
    {
      var uniqueWords = new HashSet<string>(words);
      foreach (var uniqueWord in uniqueWords)
      {
        int i;

        //пропускаем слова, которых нет в словаре
        //т.к. мы не сможем проставить для них индекс
        if (!vocabulary.TryGetValue(uniqueWord, out i)) 
          continue;

        //считаем количество вхождений слова в текущую строку (комментарий)
        var occuranceCount = words.Count(w => string.Equals(w, uniqueWord, StringComparison.InvariantCultureIgnoreCase));

       //сохраняем индекс слова в словаре и количество его вхождений
       // в данной строке (комментарии)
        yield return new svm_node() 
        {
          index = i + 1,
          value = occuranceCount
        };
      }
    }
  }

Вот как всё вместе выглядит в нашем проекте:

В этом и есть суть классификатора на основе библиотеки libsvm.net. Остается написать обертки в виде сервисов, которые уже будут специфичны для конкретного проекта.

Проверка классификатора на реальных данных

Для проверки работы метода на реальном примере мы отобрали 5 сообществ и извлекли 1 200 комментариев из каждого. После этого комьюнити менеджеры разметили их тональность, поставив «1» положительным и нейтральным комментариям и «-1» — негативным.

Классификатор обучали на 800 комментариях каждого сообщества по отдельности.

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

После обучения классификатора мы провели оценку качества: сверили оставшиеся 400 комментариев с каждого сообщества на совпадение оценок комьюнити-менеджеров с оценками, которые поставил наш классификатор. В результате сопоставления мы получили от 5% до 15% отличий. Результат совпадений в 85% нас устроил.

Способы совершенствования классификатора

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

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

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

Выводы

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

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

В заключение приведу полезные ссылки:

SVM Tutorial: Classify text in C#— статья-вдохновитель. Содержит пошаговую инструкцию, как использовать библиотеку libsvm.net в проекте на .NET.

Теория от ИНТУИТа — методы классификации и прогнозирования. Метод опорных векторов. Метод «ближайшего соседа». Байесовская классификация.

Классификация данных методом опорных векторов — описывает метод опорных векторов, показывает, как работает ядро.

Топ-10 data mining-алгоритмов простым языком — описание и сравнение разных методов машинного обучения.

К. В. Воронцов. Лекции по SVM — лекции по методу опорных векторов для тех, кто хочет разобраться подробнее.

В чем суть метода опорных векторов простым словами?— принцип работы классификатора объясняется ну очень простыми словами. Рекомендую новичкам.

Классификация документов методом опорных векторов — пример разработки классификатора на основе SVM.

Спасибо за внимание!

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

Михаил Шерстюк, Data Entry Specialist в Intetics, в качестве хобби выбрал работу стюардом на футбольных матчах. Он рассказал DOU, что входит в обязанности стюарда, есть ли у него привилегии и к чему нужно быть готовым, общаясь с многотысячной заведенной толпой.

— Михаил, кто такие футбольные стюарды? В чем заключаются их обязанности?

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

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

— Как вы сами стали стюардом? С чего все началось?

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

Стюардом я стал полтора года назад — в апреле 2017 года. В то время я еще был студентом и шерстил сайты в поисках подработки. Увидел вакансию в службу временного персонала ФК «Шахтер», отправил резюме, прошел собеседование.

— Были ли в вакансии какие-то требования к качествам и навыкам стюарда?

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

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

— Почему выбрали именно «Шахтер»?

Я болел, болею и буду болеть за «Шахтер». Так что помимо необходимости подработки, откликнулся на вакансию еще и потому, что хотел помочь этому клубу. Так случилось, что ФК «Шахтер», не имея постоянной базы для тренировки, после нескольких лет постоянных переездов остановился на харьковском стадионе «Металлист». Я решил, что хочу помогать любимой команде.

Матч «Шахтер» против «Сельта». Февраль, 2017

— Работа стюарда оплачивается или это волонтерство? Если оплачивается, то какие гонорары? :)

Да, конечно, работа стюарда оплачивается. Мне кажется, всякая работа должна оплачиваться. Это я говорю как волонтер с многолетним стажем.

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

— Как часто вы работаете на матчах? Как удается совмещать хобби и работу?

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

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

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

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

— А что за тренинги? Чему вас учат?

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

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

Кроме того, были тренинги по первой домедицинской помощи и пожарной безопасности.

Рига. Ноябрь 2015

— А вы лично сталкивались с какими-то конфликтными или неординарными ситуациями?

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

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

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

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

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

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

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

Но и поощрения, конечно, есть. В сообществе персонала ФК «Шахтер» в Facebook постоянно устраивают конкурсы, розыгрыши призов и сувениров среди работников. У нас действует референс-программа: если приведешь друга, будет тебе за это +1 к карме (ну и не только).

Также сотрудники могут получить по 2 билета на матчи Премьер-лиги. За хорошую работу дают билеты на матчи Лиги чемпионов.

Команда стюардов турникетной группы «Запад-1» с экс-капитаном «Шахтера» Дарио Срной. Май, 2018

— Что можете посоветовать тем, кто думает себя попробовать в роли стюарда? На что обратить внимание?

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

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

Шутка ли, когда игра уже началась, а за турникетом стоит очередь в 500 человек, где каждый хочет как можно быстрее попасть внутрь, а твоя задача — не допустить давки и при этом провести качественный досмотр. Мне кажется, то насколько безопасно и комфортно люди будут чувствовать себя внутри стадиона, на 90% зависит от того, как их встретят.

— За какие еще клубы болеете, помимо «Шахтера»?

В родном Краматорске есть местная команда «Авангард», но она пока играет только в Первой лиге. Если она попадет в Премьер-лигу, патриотизм за родной город заставит «Шахтер» подвинуться в моем личном рейтинге фаворитов :) Тем более последние два года новое руководство клуба прилагает все усилия, чтобы это свершилось.

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

— Какие у вас планы на будущее? Если у стюарда какой-то карьерный рост?

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

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

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

Андрей Галинский, Project Manager в Provectus

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

Вплоть до 2011 года работал в основном под Windows и Linux на разных языках и фреймворках, но всегда предпочитал C++. Затем ушел в мобильную разработку.

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

Таким образом, «чистым» PM, который к коду уже не прикасается, я стал после 10 лет работы техническим специалистом. И на этой позиции работаю уже 8 лет.

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

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

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

На текущий момент, думаю, актуальны Agile practices related topics, PMBoK, курсы от команды «Стратоплан». Есть также неплохой ресурс projectmanagement.com.

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

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

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

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

Илья Кубасов, Delivery Manager в Infopulse

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

Еще будучи студентом КПИ, я занимался всевозможными студенческими активностями, участвовал в разных молодежных организациях. С третьего курса стал руководить несколькими группами людей. На пятом курсе мы с друзьями из других областей создали свою всеукраинскую студенческую организацию. В 2010 году, оканчивая университет, я отвечал за работу группы порядка 150 студентов.

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

Поступив на работу в роли SQL Developer, я в первую очередь стремился развить технические навыки, расти профессионально. Помню, что первые 4 года о работе менеджером не думал. Считал для себя достижением пройти несколько собеседований и экспертных комитетов в EPAM, когда переходил с Middle-позиции на Senior. Только получив достаточный опыт работы разработчиком и уровень компетенции в том, что я делаю, я почувствовал желание снова заняться управленческой работой.

В общей сложности пусть от разработчика до позиции Delivery Manager занял примерно 6,5 лет и уже 2,5 года я работаю как Delivery Manager.

О переходе.На момент перехода я уже работал в Infopulse на позиции Senior SQL Developer и выполнял роль DB Lead на одном из проектов с распределенной командой. В нее входили люди из нескольких городов Украины, Индии и Америки.

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

И вот выпал удобный случай. В один день пришла рассылка от Head of Unit с темой «Кандидаты на карьерный рост», в которой говорилось, что наш юнит расширяется, требуются архитектор, менеджер, команда. Кто хотел бы попробовать себя в новой роли — пишите. Это письмо пришло ровно через одну неделю после того, как я получил сертификат Certified Scrum Master, и за неделю до того, как получил Certified Scrum Product Owner.

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

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

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

Об обучении.Как упоминал выше, я получил два сертификата от Scrum Alliance, что было очень вовремя. У меня не было формального опыта работы менеджером, и это послужило некоторым подтверждением компетенции.

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

Могу назвать несколько книг, которые мне понравились: «Power Listening»Бернарда Феррари, «Вальсируя с медведями»Тома ДеМарко, «Decisive»Чипа Хиза, «Менеджер мафии» V., «Государь»Никколо Макиавелли, «The Effective Executive»Питера Друкера, «Thinking, Fast and Slow»Даниела Канемана.

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

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

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

И еще немного подтяните английский. KubasovaETC — это тренинг-центр для менеджеров и участников IT-проектов, который создан с моим участием для тех, кому нужен рабочий IT-английский и менеджерские soft skills.

Нужен ли менеджеру технический бэкграунд?Этот вопрос возникает чаще у тех, у кого нет ни управленческого, ни технического опыта. Для некоторых пройденные курсы по JavaScript и пара месяцев работы в веб-студии — это технический бэкграунд. С другой стороны, у технарей много проблем при резком переходе в менеджеры, о чем написано в книге «Как пасти котов».

Мне очень понравилась статья на DOUот UI/UX эксперта Лины Кононенко, которая говорит о важности знания предметной области. Мне кажется, что для менеджера глубокое понимание предметной области важнее технических знаний. В таком случае коммуникация с бизнесом приобретает равноценный характер, менеджер может быть полноценным участником бизнес-процесса, вносить свои предложения и доносить видение команды в контексте, понятном клиенту, а не просто быть исполнителем заказа.

Лілія Ступницька, Senior Project Manager у SoftServe

Насправді я повернулася на позицію Project Manager вже вдруге. «Захворіла» комп’ютерами і програмуванням ще в 90-х,коли це було зовсім непопулярно. Більшість людей сприймали комп’ютери як небезпеку зіпсувати зір чи активність для «ботанів». Але мене тоді захопив той світ: можливість створювати щось, чого раніше не існувало, стирати межі нереального.

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

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

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

Про перехід.Моя перша робота на рівні delivery була в SoftServe на посаді Software Development Manager. Отримавши пропозицію керувати командами, я погодилася. Це був новий вектор розвитку кар’єри, і я вирішила спробувати.

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

В той час я отримала пропозицію від компанії Remit, де пропрацювала майже 4 роки на позиціях QA Director і Delivery Manager.

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

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

Про навчання.Основа основ у проектному менеджменті — це PMBoK. Проте вона може бути дещо складною, якщо це ваша перша книга в цьому напрямку. З власного досвіду можу порекомендувати для початківців:

• «Менеджерами не народжуються»Деннi Стрігл та Френка Свайтека;
• «Strengths based leadership»Тома Рата і Баррі Кончі;
• «Guide to Financial Management»Джона Теннета.

На ринку зараз достатньо якісної літератури, тому головне — не стримувати себе та багато читати.

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

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

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

Також варто розглянути освітні курси та модулі. Зараз їх досить багато — як для початківців, так і для людей з досвідом у менеджменті. Якщо ваша компанія не має власних курсів, а свого ментора ви переросли, проте відчуваєте, що ще потрібно здобути чи структурувати знання, то я б рекомендувала LvBS, зокрема курс MS in Tech Management.

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

Мені зустрічались зовсім не технічні менеджери, які чудово виконували саме функцію управління командами, а також класні технічні менеджери, які погано справлялися з управлінням. Один з найкращих PM-ів, з якими мені доводилось працювати, до роботи в IT керував меблевою фабрикою :) Проте в нього була технічна освіта і він дуже добре розбирався в технологіях.

Алексей Бойчев, Program Manager в Luxoft Ukraine

Моя инженерная карьера началась еще до Luxoft. Три года я работал программистом в IТ-отделе достаточно большой торговой компании. В 2011 году пришел в Luxoft на совмещенную позицию — одновременно был Software Tester и Junior Developer. Поучаствовал в нескольких проектах, а через год стал Junior Developer официально. Вырос до Middle, потом и до Senior.

С 2016 года я стал PM. Курировал параллельно несколько небольших проектов, по 4-5человек каждый.

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

О переходе.Мой переход в PM был довольно плавным. Кроме моих текущих проектов в Luxoft на тот момент, появились новые, которые было необходимо подхватывать. В этих проектах был некий вакуум процессов и планирования, который мне и пришлось заполнять. Суть работы оставалась той же, однако ее становилось больше.

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

Например, в моем текущем проекте я отвечаю за всю Software Engineering часть V-модели,за все шесть процессов инжиниринга и за два этапа системного уровня: Software Integration и Software Qualification Test. Мы занимаемся всем стеком согласно Automotive стандарту ASPICE — от Software Requirements Analysis до Quality Assurance.

Ранее моя зона ответственности ограничивалась одним-тремя этапами.

Об обучении.Библия PM — это PMBoK. Все остальное, связанное с проектным менеджментом, тоже надо читать и следить за трендами. Сейчас в моде Agile, это хорошо, но не стоит забывать про Waterfall, V-модель.Нужно следить, как они развиваются и как меняется PM-мир. Каждый проект требует индивидуального подхода, и вы должны быть способны выбрать правильную методологию и адаптировать её под ваши нужды.

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

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

Из книг могу посоветовать «Management Gurus»Дэвида Эванса об истории Automotive и о том, как менялся Project Management с ходом времени — от начала XX века и до сегодня.

Кроме того, для развития PM-у необходимо испытывать свои возможности и пределы. Именно проектный менеджер должен уметь принимать решения, когда другие их принимать уже не могут, и работать под давлением. Многие заказчики этим пользуются и часто пытаются продавить свои решения, пользуясь физической и психологической усталостью менеджера. Фактически нужно помещать себя в стрессовые условия время от времени — спорт, меньшее количество сна, хобби, требующие усилий. На старте проекта это будет очень полезно. По этой теме порекомендую книгу Питера Друкера «Managing Oneself».

С чего начать?Во-первых, нужно научиться планировать. Всегда и все, даже бытовые вещи, будь то замена розетки дома или задачи по проекту на работе. И в том и в другом случае постарайтесь выделить 50% времени на планирование, 40% на выполнение и 10% на анализ. Lessons learning — обязательное условие для саморазвития. Сделайте выводы, как можно ускорить выполнение задачи, а в следующий раз будете планировать уже по-другому. Этот важный навык должен стать вашей привычкой.

Во-вторых, испытывать себя и быть спокойным во время стресса. Лучше начинать приобретать этот навык до старта карьеры PM-а.

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

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

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

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

Любомир Лядик, Centres of Excellence Director в ELEKS

Спершу я займався розробницько-проектувальною роботою в одній хардверній компанії. Коли ж 12 років тому прийшов у ELEKS, то починав як QA-інженер, потім став QA-лідом.

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

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

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

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

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

З чого починати?Вимоги до PM-а — теперішні і ті, які будуть у майбутньому, — відрізнятимуться. Тобто потрібен буде не просто класичний адміністратор, який вміє організувати усі процеси на проекті, а людина-лідер з високими leadership-скілами, soft-скілами та емоційним інтелектом, яка вміє організувати довкола себе інших людей і досягати результату. Ну і, звісно, бути керівником і управлінцем на рівні людських якостей. Це ідеальний профіль керівника на майбутнє.

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

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

Чи потрібен PM-у технічний бекграунд?Якщо людина в минулому — розробник, то це, звісно, плюс, але не вимога. Щоб стати PM, зовсім не потрібно мати технічний бекграунд. Головне розуміти ази: як відбувається розробка ПЗ, з чого вона складається. Ґрунтовніші знання не є обов’язковими.

Сьогодні приблизно 90% PM — не технічні фахівці. Іноді це люди, які перейшли не з IT, а з інших сфер, де виконували управлінські обов’язки, які вміють спілкуватися з людьми, чути замовника, менеджити його потреби. Це саме ті люди, на яких ми перш за все робимо ставку.

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

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

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

Идея

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

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

В блокчейн-сетях администратор отсутствует. Любой блокчейн можно воспринимать как базу данных с управляющей логикой (кодом) для этих данных. Наиболее частое название для управляющего кода — смарт-контракт. Его копия, также как и копия данных, распределенно хранится на каждом узле. Соответственно, каждый узел может и, как правило, независимо вычисляет результат каждой транзакции. Физическое владение и административные права на каждый отдельный узел принадлежат разным компаниям или людям. Транзакции объединяются и упорядочиваются в блоки. Каждый блок сформирован одним из участников, который, в свою очередь, динамически определяется децентрализованным алгоритмом консенсуса.

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

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

Реализация и архитектура фреймворка

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

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

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

Компоненты узла в базовом варианте

На нижнем уровне узла, в базовом варианте, находятся четыре модуля:

• Реализация Ethereum блокчейн-протокола в варианте geth.Выбор в пользу Ethereum был сделан из-за наличия большого сообщества, хорошей динамики развития, а также сильной команды и поддержки в лице организации Ethereum Foundation.
• База данных MongoDB c GridFS.Многие реализации потребуют хранения данных. Хоть блокчейн, по своей сути, и является децентрализованной и отказоустойчивой базой данных, но хранение многих данных в нем нецелесообразно с точки зрения как минимум производительности. Таким образом, мы остановили выбор на этой широко используемой базе данных.
• Менеджер очередей RabbitMQ.Записи во многие блокчейн-базы данных требуют существенного времени из-за особенностей механизмов консенсуса, что может не укладываться во время, необходимое для отклика на вызов API узла. Реакция на события, происходящие при записи компаниями-партнерами в блокчейн, также может потребовать обработки этих событий в нужном порядке. Понимая, что нам понадобится функционал очередей и отложенной работы, мы выбрали RabbitMQ как одно из наиболее популярных решений.
• Модуль для хранения криптографических ключей.Для работы с блокчейн-протоколом и шифрованием в базах данных нужно хранить и управлять криптографическими ключами разных типов. В данный момент мы поддерживаем опцию проприетарного менеджера ключейи завершаем работу над опцией альтернативного модуля, удовлетворяющего критерии свободного ПО. Первый вариант необходим там, где может понадобиться такая сертификация, как FIPS 140-2.

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

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

Верхний уровень API представляет собой HTTP- и WebSocket-сервер, защищенный посредством TLS и предоставляющий публичные интерфейсы как для внешних приложений, так и для административного web UI. Запросы к интерфейсам валидируются в DMS-модуле и проксируются для запуска бизнес-логики. Она запускается в изолированной среде, легко кастомизируется под конкретного заказчика и работает с API нижнего уровня. При этом для разработки бизнес-логики не обязательно нужны экспертные знания блокчейн-технологии и других модулей самого нижнего уровня.

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

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

Пример взаимодействия двух узлов

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

Децентрализованная сеть на базе фреймворка

Команда и технология для разработки

Основной технологией фреймворка стала NodeJS. Мы выбрали ее по двум причинам: достаточное количество разработчиков на рынке и большое профессиональное сообщество.

Команда формировалась на протяжении последнего года, и в ее состав сейчас входит шесть человек: Sales Manager, Tech Lead, Senior NodeJS и Junior NodeJS разработчики, тестер и блокчейн-эксперт.

Из-за небольшого состава команды, некоторым участникам приходится совмещать несколько ролей. Например, наш тестер выполняет некоторые функции Project Manager’a; техлид, кроме контроля стандартов разработки, выполняет задачи по Backend-разработке и DevOps; блокчейн-эксперт пишет смарт-контракты, тесты и API для взаимодействия с ними.

Также мы привлекаем на разовые работы Frontend-разработчиков, дизайнера и DevOps.

Пример применения фреймворка для GDPR

Говоря про фреймворк, нельзя не дать конкретные примеры решений на его базе. В этом году стал актуальным вопрос GDPR (General Data Protection Regulation) — это принятый в ЕС акт о защите персональных данных. Он вступил в силу 25 мая. Помимо прочих пунктов, положения GDPR обязывают компании использовать персональные данные пользователя только с его разрешения и прекращать их использование по его требованию.

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

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

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

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

В наши ближайшие планы входит проведение нагрузочных тестов, реализация API для других блокчейн-протоколов, баз данных и систем хранения ключей, создание системы версионирования на разных уровнях, R&D работа по возможности использования децентрализованных баз данных (Swarm, IPFS и т. д.) как модулей нижнего уровня.

Цю статтю створено у співавторстві з Анастасією Білоус.

Продовжуємо знайомитися з основами машинного навчання разом з веселими героями. Якщо ви ще не читали першу статтю «Вступ до Machine Learning: знайомство з моделями» — зазирніть спочатку в неї. У цій статті ми перейдемо до практики роботи з TensorFlow.

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

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

Знайомство з Colaboratory і TensorFlow

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

На одному диханні він прочитав документацію Colaboratoryі сів розбиратися з програмним інтерфейсом TensorFlow. Він зберіг результати тестування з попередніх років у CSV файлдля того, щоб полегшити процес завантаження даних, і завантаживши його на Диск Гугл, отримав загальнодоступну адресу файлу: drive.google.com/...​QKnhBDYsf0OIkGysZxjadWeTv

В Colaboratory він його завантажив наступним блоком коду:

!mkdir drive
!wget 'https://drive.google.com/uc?id=1nlTTlDYQKnhBDYsf0OIkGysZxjadWeTv&export=download' -O drive/exams.csv

Вован порекомендував використовувати бібліотеку Pandasдля завантаження вхідних даних. Коля не зрозумів чому, але вирішив прислухатися. Наступним блоком коду вiн завантажив файл у pandas.DataFrame та вивів 15 верхніх рядків:

exams = pd.read_csv('drive/exams.csv')
exams.head(15)  # Виведемо 15 верхніх рядків

Ці дані він розділив на три набори, відділивши 20% у набір для ратифікації і ще 20% у набір для оцінки (дивитися чому — у попередній статті), решта 60% буде використовуватися тренером для навчання моделі. Ось код для розділення даних:

def split_data(data):
  training = []
  evaluation = []
  validation = []
  for (index, row) in enumerate(data.values):
    ind = index % 10
    if ind < 6:
      training.append(row)
    elif ind < 8:
      evaluation.append(row)
    else:
      validation.append(row)
  return (pd.DataFrame(training, columns=data.columns), 
          pd.DataFrame(evaluation, columns=data.columns), 
          pd.DataFrame(validation, columns=data.columns))
training_data, evaluation_data, validation_data = split_data(exams)

Йому було сказано зробити «аналіз даних» перед тренуванням моделей, але як його робити, Коля уявляв лише приблизно. Єдине, що він зрозумів з пояснень, — що це більше мистецтво, ніж наука. І для того, щоб знайти хоч якусь музу, потрібно дотримуватися першого правила аналізу даних: «Намалювати багато графіків і довго їх роздивлятися». Малювати графіки сам Коля не хотів, йому не терпілося уже приступити до тренування моделей. Лінь спонукала його шукати готове рішення. Одним з найпростіших йому здалося Facets — Visualizations for ML datasets, тому що воно доволі просто інтегрувалося в Colaboratory Facets for Colab (можете пропустити зараз цей момент і повернутися до нього після прочитання статті).

Тепер малювати багато графіків виявилося дуже просто — достатньо викликати функції FacetsDive() і FacetsOverview():

FacetsDive(training_data)

FacetsOverview(training_data, evaluation_data)

Порозглядавши їх, Коля не знайшов нічого надзвичайного і перейшов до визначення моделі. Йому потрібна була функція, яка, прийнявши (name, subject, test1, test2), передбачить успіх на екзамені. Так як успіх чи провал екзамену — величина булева, набори даних потрібно розширити додатковою колонкою:

outcome_column = 'failed'

# True = завалений екзамен (<= 50 балів)
training_data[outcome_column] = training_data['exam'] <= 50 
evaluation_data[outcome_column] = evaluation_data['exam'] <= 50

Тепер можна побудувати TensorFlow класифікатор (Classifier в нашому випадку LinearClassifier).

train_input = tf.estimator.inputs.pandas_input_fn(
      x=training_data[input_columns], # Вхідні колонки.
      y=training_data[outcome_column], # Вихідна колонка - те що ми передбачаємо.
      batch_size=50,
      num_epochs=None,
      shuffle=False)

# Визначення вхідних колонок для моделі, тут ми вказуємо тип кожної колонки
input_column_defs = [
    tf.feature_column.categorical_column_with_hash_bucket('name', 20),
    tf.feature_column.categorical_column_with_hash_bucket('subject', 20),
    tf.feature_column.numeric_column('test1'),
    tf.feature_column.numeric_column('test2'),
  ]

# Будуємо лінійний класифікатор
classifier = tf.estimator.LinearClassifier(input_column_defs,
  n_classes=2,
  optimizer=tf.train.AdagradOptimizer(
      learning_rate=0.2,)
)

# Тренуємо модель
classifier.train(train_input, steps=500)

Ми скористалися функцією classifier.train()для того, щоб навчити класифікатор на наших вхідних даних. Після тренування ми можемо його використовувати. Нас цікавитимуть два основні методи — classifier.evaluate() і classifier.predict().

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

eval_input = tf.estimator.inputs.pandas_input_fn(
        x=evaluation_data[input_columns],
        y=evaluation_data[outcome_column], 
        num_epochs=1,
        shuffle=False)

classifier.evaluate(eval_input)

Результат:

{'accuracy': 0.92771083,
 'accuracy_baseline': 0.77710843,
 'auc': 0.98397243,
 'auc_precision_recall': 0.9539273,
 'average_loss': 0.17726704,
 'global_step': 500,
 'label/mean': 0.22289157,
 'loss': 14.713165,
 'precision': 1.0,
 'prediction/mean': 0.1676192,
 'recall': 0.6756757}

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

def predict_exam_failure(name, subject, test1, test2):
  # Пакуємо вхідні дані в DataFrame
  data = pd.DataFrame(data={'name': [name], 'subject': [subject], 'test1': [test1], 'test2': [test2]})

  data_input = tf.estimator.inputs.pandas_input_fn(
    x=data,
    shuffle=False)

  predictions = classifier.predict(data_input)
  the_prediction = next(predictions)  # Витягуємо єдиний запис - так як на вхід був один рядок
  return the_prediction['probabilities'][1] # probabilities буде мати два значення - ймовірність False і ймовірність True - в сумі вони мають давати 1.
  # Нас цікавить ймовірність True - провалу екзамену.

Фінальний результат можна побачити в Додатку Colaboratory.

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

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

Нові метрики для оцінки точності моделі

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

Якщо вхідні дані можуть належати до одного з двох класів (успіх чи провал екзамену), і наша модель передбачає один з цих класів, у результаті ми маємо 4 різні варіанти:

1) передбачений провал і фактичний провал;
2) передбачений успіх, але фактичний провал;
3) передбачений провал, але фактичний успіх;
4) передбачений успіху і фактичний успіх.

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

Будемо називати цю таблицю матрицею помилок. Червоним кольором позначені випадки, коли реальність не відповідала моделі, і зеленим — коли передбачення було правильним.

Введемо дві нові метрики для оцінки точності моделі:

Позитивна точність (Precision)

= Коректно Позитивні / (Коректно Позитивні + Некоректно Позитивні)
= Коректно Позитивні / Передбачені Позитивні

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

Приклад: якщо модель вибрала 20 екзаменів, які передбачила як провалені, скільки з них буде фактично проваленими.

Покриття (Recall)

= Коректно Позитивні / (Коректно Позитивні + Некоректно Негативні)
= Коректно Позитивні / Фактично Позитивні

Інтуїція метрики — процент вибраних моделю позитивних записів.

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

Поріг

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

if predict_exam_failure(student.name, exam.subject, exam.text1, exam.test2) >= 0.6:
  num_failed += 1

Яким чином ми можемо отримати значення 0.6? Наприклад, побудувавши таблицю на зразок такої:

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

Метрики «позитивна точність» і «покриття» знаходяться в конфлікті одна з одною. Ми легко можемо отримати покриття 100%, просто передбачаючи позитивний результат для будь-якого запису даних (значення порогу = 0). Це призведе до низької точності — багато із записів, передбачених нами як позитивні, будуть фактично негативними.

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

Практичні завдання

Для закріплення матеріалу пропонуємо охочим відповісти в коментарях на такі запитання і зробити практичні завдання (для практичних завдань необхiдно зробити копію Colaboratory, дописати туди необхідний код і додати посилання в коментарі):

1. Чому рік не може бути вхідним сигналом?
2. Якщо ми не маємо жодної інформації про екзамен — ні предмету, ні року, ні студента, ні результатів тесту, то з якою ймовірністю він буде успішно зданий? А якщо ми знаємо тільки ім’я студента — Андрій?
3. Яким чином ми можемо порахувати значення точності для таблиці «Точність» для значень порогу?
4. Що цікавого ви побачили в даних?
5. Побудуйте графік (Точність, Позитивна Точність і Покриття) для різних значень порогу з набору даних для оцінки.
6. Наведіть приклади задач, для яких раціональним є вибір низьких значень порогів? А коли високих?
7. Натренувати модель, додавши до нього додаткові вхідні сигнали — стать студента.
8. Наведіть приклади даних, яких немає в заданому наборі, але які б могли суттєво покращити метрики моделі.
9. Складна задача: яким чином можна порахувати, наскільки наша модель перенавчилася? Напишіть код.
10. Складна задача: додати до моделі вхідний сигнал — статистика тестів і екзаменів з попередніх років.