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

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

— Марта, як ви зацікавились музикою і зокрема бандурою? Коли, де і як вчилися?

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

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

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

Після закінчення музичної школи одна з викладачок покликала мене до колективу «Дзвінга». Тоді для мене це була не лише змога продовжувати грати, але і поїхати побачити світ. Щороку ми маємо гастролі у Бельгію, але окрім того були на фестивалях у Франції, Словаччині, Чехії, Польщі. Одного разу навіть відвідували з концертами Полтавщину, яка вразила нас своєю душевністю, відкритістю і теплом не менше, ніж Європа.

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

— Чим саме вам подобається бандура? Чому обрали саме цей інструмент?

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

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

— А які твори вам подобається грати і в яких аранжуваннях?

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

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

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

— А костюми для виступів виготовляєте самостійно?

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

\

— Яка музика вас надихає найбільше? Кого ще з крутих бандуристів порадите послухати?

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

— Чи вважається бандура складним інструментом для музиканта? У чому її особливості з точки зору опанування гри?

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

Але вважаю, що це досить індивідуальна річ. Наприклад, як і вивчення мов: комусь це може складно даватись, а іншим — навпаки. Якщо є бажання, то все під силу.

— Ви граєте в капелі бандуристок «Дзвінга». Розкажіть, будь ласка, детальніше про вашу діяльність, гастролі.

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

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

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

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

— Ви граєте тільки українські народні пісні чи й інші?

Наш репертуар майстерно складають керівники — Марія Соломко та Наталія Мишловська. Вони завжди дослухаються до нас, коли ми просимо включити якусь пісню в репертуар. Тому ми виконуємо і народні твори, і класику, таку як Adagio Albinoni. Деякі наші виступи можна переглянути на YouTube.

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

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

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

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

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

— Порівняйте свою роботу та хобі. Які відчуття у вас викликає те та інше? Що вам в житті дає робота, а що хобі?

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

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

— Наскільки бандура користується попитом в Україні і світі? Є якісь фестивалі, події, де бандурист може показати своє вміння?

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

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

— Як новачку опанувати бандуру? З чого починати? Чи треба мати якусь попередню музичну підготовку?

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

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

Виконання композиції «Місто спить» на гастролях в Бельгії, місто Іпр

— Чи ви хотіли б коли-небудь перетворити хобі на повноцінну роботу замість IT?

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

— Які у вас подальші плани щодо вашого хобі?

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

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

Всем привет, меня зовут Александр Гончар. Я занимаюсь исследованиями и внедрением машинного обучения для анализа биосигналов в Mawi Solutions, исследованиями на пересечении quantitative finance и машинного обучения в University of Verona и консультирую компании несложно догадаться относительно чего. Также веду популярный блог на Medium, выступаю на конференциях и митапах в Украине, Италии и других странах.

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

Все есть вектор

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

Image Source

То есть после «ковыряния» в уже обученных нейронках (в данном случае convolutional neural nets), которые показывают хорошую точность, мы смогли понять, что они уже выучивают признаки, очень похожие на те, что выучивает зрительная система в нашем мозгу:

Image Source

По факту, на каждом слое у нас есть разные представления картинок — и все они математически описываются какими-то векторами (или другими структурами, но чаще всего это все же векторы). Если по каким-то причинам у нас вместо пары вход-выход есть только вход (так называемые неразмеченные данные), то мы все равно можем обучить нейросеть находить эти представления — с помощью автоэкодеров или генеративных состязательных сетей. Более того, принято считать, что генеративные модели лучше подходят для описания данных per se. Все-таки не зря Ричард Фейнман как-то сказал: «То, что я не могу создать, я не могу понять». Пока что нам достаточно того, что любые объекты с помощью нейронных сетей можно упаковать в вектора, по которым в принципе можно определять соответствующие им свойства. Но это не всегда было так.

Все есть формула

Давайте сделаем шаг назад (а точнее лет 50) и посмотрим, как математики раньше описывали входные данные. Можно даже вернуться на пару сотен назад и вспомнить то, как Ньютон и компания создавали основы классической механики. Что такое известная формула S = V * T ? По сути, это описание процесса движения, которое было основано на наблюдении каких-то данных. Чем не машинное обучение? Разве что без выборки с координатами объектов в разные моменты времени в .csv, конечно.

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

Image Source

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

Слева — примеры реализации геометрического броуновского движения, справа — jump diffusion process

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

«Развязанные векторы»

Image Source

Но главное преимущество машинного обучения в том, что никаких формул придумывать не нужно! Как же тогда совместить гибкость нейронных сетей и «понятность» и доступность математических моделей? Если за основу «понятности» взять свойство каждого отдельного элемента вектора описывать одно единственное свойство входного объекта, то такой входной вектор называется disentangled representation. Entangled вектора, в свою очередь, имеют элементы, которые «связаны» — меняя один элемент, мы меняем сразу несколько свойств объекта. Проще всего этот концепт иллюстрируется на такой картинке:

Image Source

Котик теперь преобразовывается не просто в вектор, которым можно распознать его породу (конечно же, непонятно как, но зато с точностью 99%), а еще и понять основные свойства. А теперь представьте, что ваша любимая нейронка (даже не важно, supervised или unsupervised) умеет выучивать такое — каждый элемент вектора отвечает за свое единственное уникальное свойство. Что это нам дает?

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

И что, кто-то такое уже делает?

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

Алгоритмов тоже немало. Есть хаки, использующие такой себе meta-supervised подход, который использует информацию о свойствах при обучении, например InfoGAN, IB-GANили из последних успешных — TL-GAN. Работает очень неплохо, смотрите сами:

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

Повороты лиц. Image Source

В reinforcement learning. Image Source

А теперь главный вопрос. Если раньше математикам приходилось по крупицам составлять сложнейшие математические модели, чтобы учесть все свойства объектов или процессов, а вот такие вот алгоритмы уже скоро будут выучивать их сами по себе, нужно ли будет математическое моделирование как таковое вообще? Детальнее об этой теме я расскажу на конференции Data Science UA, которая пройдет 16 марта.

Что дальше

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

Переобучать сетки под новые данные (а как вы сейчас будете адаптировать ваши «умные» вектора под видео с разных камер и разного качества? Собирать терабайты данных и тратить месяцы?). Уменьшать количество данных, нужных для обучения (а это время и деньги). Фиксить ошибки (париться с векторами). Интерпретировать результаты (снова париться с векторами). Делать отчеты (расскажете клиенту в МинОбороны «ну... это... ResNet сам все танки врагов в векторах выучил!»). А ведь еще можно изобретать новые лекарства, материалы и открывать новые знания. Создавать предметы искусства или фейковые видео. Отвечать за жизни людей (в медицинских или военных проектах) или большие суммы денег (банки, фонды). Выбор за нами.

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

Теми, розглянуті нижче:

• Структура сторінок і роутинг
• Компоненти, шаблони та їх взаємодія
• Робота з даними
• Плагіни
• Стилізація сайту
• SEO-оптимізація з використанням react-helmet
• Налаштування PWA

Підготовка

yarn global add gatsby-cli

npx gatsby new gatsby-tutorial https://github.com/gatsbyjs/gatsby-starter-hello-world
cd gatsby-tutorial

git init
git add .
git commit -m "init commit"

yarn start

Структура сторінок і роутинг

Щоб створити сторінку в Gatsby, досить просто помістити новий файл в папку /src/pages, та його буде скомпільовано в окрему HTML-сторінку. Важливо зауважити, що URL до цієї сторінки буде відповідати фактичному шляху з назвою.Наприклад, додамо ще кілька сторінок:

src
└── pages
    ├── about.js
    ├── index.js
    └── tutorial
        ├── part-four.js
        ├── part-one.js
        ├── part-three.js
        ├── part-two.js
        └── part-zero.js

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

import React from "react";

export default () => <div>Welcome to tutorial/part-one</div>;

Перевіряємо в браузері:

• localhost:8000/tutorial/part-one
• localhost:8000/about

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

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

Зв’яжемо створені сторінки за допомогою посилань ― для цього скористаємося компонентом <Link /> з пакета Gatsby, який створений спеціально для внутрішньої навігації. Для всіх зовнішніх посилань слід використовувати звичайний <a> тег.

/src/pages/index.js

import React from "react";
import { Link } from "gatsby";

export default () => (<div><ul><li><Link to="/about">about</Link></li><li><Link to="/tutorial/part-zero">Part #0</Link></li><li><Link to="/tutorial/part-one">Part #1</Link></li><li><Link to="/tutorial/part-two">Part #2</Link></li><li><Link to="/tutorial/part-three">Part #3</Link></li><li><Link to="/tutorial/part-four">Part #4</Link></li></ul></div>
);

<Link>під капотом має дуже хитрий механізм щодо оптимізації завантаження сторінок і тому використовується замість <a>для навігації по сайту. Детальніше можна почитати тут.

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

Компоненти, шаблони та їх взаємодія

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

Створимо компоненти для хедера та навігаційної панелі:

/src/components/header.js

import React from "react";
import { Link } from "gatsby";

/**
 * Зверніть увагу на те, що зображення для логотипу
 * імпортується так само, як і в звичайному React-проекті.
 * Це тимчасове і не оптимальне рішення, тому що картинка
 * поставляється "як є". Трохи далі ми розглянемо
 * як це робити "правильно" використовуючи GraphQL і gatsby-плагіни
 */
import logoSrc from "../images/logo.png";

export default () => (<header><Link to="/"><img src={logoSrc} alt="logo" width="60px" height="60px" /></Link>
    That is header</header>
);

/src/components/sidebar.js

import React from "react";
import { Link } from "gatsby";

export default () => (<div><ul><li><Link to="/about">about</Link></li><li><Link to="/tutorial/part-zero">Part #0</Link></li><li><Link to="/tutorial/part-one">Part #1</Link></li><li><Link to="/tutorial/part-two">Part #2</Link></li><li><Link to="/tutorial/part-three">Part #3</Link></li><li><Link to="/tutorial/part-four">Part #4</Link></li></ul></div>
);

і додамо їх в /src/pages/index.js

import React from "react";

import Header from "../components/header";
import Sidebar from "../components/sidebar";

export default () => (<div><Header /><Sidebar /><h1>Index page</h1></div>
);

Перевіряємо:

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

Gatsby layout == React container
так-так, саме неточна рівність, тому що це «майже» одне і те саме_

/src/components/layout.js

import React from "react";

import Header from "./header";
import Sidebar from "./sidebar";

export default ({ children }) => (<><Header /><div
      style={{ margin: `0 auto`, maxWidth: 650, backgroundColor: `#eeeeee` }}><Sidebar />
      {children}</div></>
);

/src/pages/index.js (і всі інші сторінки)

import React from "react";

import Layout from "../components/layout";

export default () => (<Layout><h1>Index page</h1></Layout>
);

Готово, дивимося в браузер:

Чому в проекті всі назви файлів з маленької літери? Для початку визначимося, що naming convention для Reactвиходить з того, що «кожен файл — це клас, а клас завжди називається з великої літери». В Gatsbyфайли, як і раніше, містять класи, але є одне «але»: «кожен файл є потенційною сторінкою, а його назва ― URL до цієї сторінки». Ком’юніті прийшло до висновку про те, що посилання виду http://domain.com/User/Settings― це не comme-il-fautі, і затвердило kebab-case для назв файлів.

src
├── components
│   ├── header.js
│   ├── layout.js
│   └── sidebar.js
├── images
│   └── logo.png
└── pages
    ├── about.js
    ├── index.js
    └── tutorial
        ├── part-eight.js
        ├── part-five.js
        ├── part-four.js
        ├── part-one.js
        ├── part-seven.js
        ├── part-six.js
        ├── part-three.js
        ├── part-two.js
        └── part-zero.js

Робота з даними

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

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

Для роботи з GraphQL, з другої версії, в пакеті gatsby є компонент StaticQuery, який може використовуватися як на сторінках, так і в простих компонентах, і в цьому його головна відмінність від його попередника ― page query. Поки що наш сайт не з’єднаний з якимись джерелами даних, тому спробуємо вивести метадані сторінок, для прикладу, а потім перейдемо до більш складних речей.

Щоб побудувати query, потрібно відкрити localhost:8000/___graphqlі, користуючись бічною панеллю з документацією, знайти доступні дані про сайт. І не забудьте про автодоповнення.

/src/components/sidebar.js

import React from "react";
import { Link, StaticQuery, graphql } from "gatsby";

export default () => (<StaticQuery
    query={graphql`
      {
        allSitePage {
          edges {
            node {
              id
              path
            }
          }
        }
      }
    `}
    render={({ allSitePage: { edges } }) => (<ul>
        {edges.map(({ node: { id, path } }) => (<li key={id}><Link to={path}>{id}</Link></li>
        ))}</ul>
    )}
  />
);

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

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

Плагіни

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

Створимо на кореневому рівні додатку файл /gatsby-config.js<|em>, який відповідає за конфігурацію компілятора в цілому, і спробуємо налаштувати перший плагін для роботи з файлами.

Встановлення плагіну:

yarn add gatsby-source-filesystem

Конфігурація у файлі /gatsby-config.js:

module.exports = {
  plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`,
      }
    }
  ],
}

/**
 * gatsby-config.js це файл, який повинен
 * за замовчуванням експортувати об'єкт JS
 * з конфігурацією для компілятора
 */
module.exports = {
  /**
   * поле 'plugins' описує pipeline процесу компіляції
   * та складається з набору плагінів
   */
  plugins: [
    /**
     * кожен плагін може бути вказаний у вигляді рядка
     * або у вигляді об'єкта для налаштування його опцій
     */
    `gatsby-example-plugin`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`,
      }
    }
  ],
}

Пам’ятайте ми говорили про «правильний» імпорт картинок в Gatsby?

/src/components/header.js

import React from "react";
import { Link, StaticQuery, graphql } from "gatsby";

export default () => (<StaticQuery
    query={graphql`
      {
        allFile(filter: { name: { eq: "logo" } }) {
          edges {
            node {
              publicURL
            }
          }
        }
      }
    `}
    render={({
      allFile: {
        edges: [
          {
            node: { publicURL }
          }
        ]
      }
    }) => (<header><Link to="/"><img src={publicURL} alt="logo" width="60px" height="60px" /></Link>
        That is header</header>
    )}
  />
);

На сайті нічого не змінилося, але тепер картинка підставляється за допомогою GraphQL, замість простого webpack-імпорту. З першого погляду може здатися, що конструкції занадто складні і це лише додає проблем, але давайте не поспішати з висновками, бо справа в тих же самих плагінах. Наприклад, якби ми вирішили розміщувати на сайті тисячі фотографій, то нам в будь-якому випадку довелося б думати про оптимізацію завантаження всього контенту. Щоб не будувати свій lazy-load процессз нуля, ми б просто додали gatsby-imageплагін, який би оптимізував завантаження всіх картинок, що імпортуються за допомогою query.

Встановлення плагінів для стилізації:

yarn add gatsby-plugin-typography react-typography typography typography-theme-noriega node-sass gatsby-plugin-sass gatsby-plugin-styled-components styled-components babel-plugin-styled-components

gatsby-config.js

module.exports = {
  plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`
      }
    },
    // add style plugins below
    `gatsby-plugin-typography`,
    `gatsby-plugin-sass`,
    `gatsby-plugin-styled-components`
  ]
};

На офіційному сайтіможна знайти плагін на будь-який смак.

Стилізація сайту

Почнемо стилізацію додатку, використовуючи різні підходи. У попередньому кроці ми вже встановили плагіни для роботи з SASS, styled-componentsта бібліотекою typography.js. При цьому важливо відзначити, що css.modules підтримуються «з коробки».

Почнемо роботу з глобальних стилів, які, як і інші речі, що відносяться до всього сайту, повинні бути налаштовані в файлі /gatsby-browser.js:

import "./src/styles/global.scss";

Детальніше про gatsby-browser.js.

/src/styles/global.scss

body {
  background-color: lavenderblush;
}

З різних причин тенденції останніх років схиляються в бік «CSS in JS» підходу, тому не варто зловживати глобальними стилями і краще обмежитися зазначенням шрифту і глобальних класів. У цьому конкретному проекті планується використання Typography.jsдля цих цілей, тому глобальні стилі залишаться порожніми.

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

/src/utils/typography.js

import Typography from "typography";
import theme from "typography-theme-noriega";

const typography = new Typography(theme);

export default typography;

Можна вибрати будь-який інший пресет зі спискуабо створити свій власний, використовуючи API пакету (прикладконфігурації офіційного сайту Gatsby).

/gatsby-config.js

module.exports = {
  plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`
      }
    },
    {
      resolve: `gatsby-plugin-typography`,
      options: {
        pathToConfigModule: `src/utils/typography`
      }
    },
    `gatsby-plugin-sass`,
    `gatsby-plugin-styled-components`
  ]
};

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

Додамо файл з глобальними змінними /src/utils/vars.js

export const colors = {
  main: `#663399`,
  second: `#fbfafc`,
  main50: `rgba(102, 51, 153, 0.5)`,
  second50: `rgba(251, 250, 252, 0.5)`,
  textMain: `#000000`,
  textSecond: `#ffffff`,
  textBody: `#222222`
};

import React from "react";
import { Link, StaticQuery, graphql } from "gatsby";
import styled from "styled-components";

import { colors } from "../utils/vars";

const Header = styled.header`
  width: 100%;
  height: 3em;
  display: flex;
  justify-content: space-between;
  align-items: center;
  background-color: ${colors.main};
  color: ${colors.textSecond};
  padding: 0.5em;
`;

const Logo = styled.img`
  border-radius: 50%;
  height: 100%;
`;
const logoLink = `height: 100%;`;

export default () => (<StaticQuery
    query={graphql`
      {
        allFile(filter: { name: { eq: "logo" } }) {
          edges {
            node {
              publicURL
            }
          }
        }
      }
    `}
    render={({
      allFile: {
        edges: [
          {
            node: { publicURL }
          }
        ]
      }
    }) => (<Header>
        That is header<Link to="/" css={logoLink}><Logo src={publicURL} alt="logo" /></Link></Header>
    )}
  />
);

import React from "react"
import { Link, StaticQuery, graphql } from "gatsby"
import styled from "styled-components"

import { colors } from "../utils/vars"

const Sidebar = styled.section`
  position: fixed;
  left: 0;
  width: 20%;
  height: 100%;
  display: flex;
  flex-direction: column;
  justify-content: center;
  background-color: ${colors.second};
  color: ${colors.textMain};
`

const navItem = `
  display: flex;
  align-items: center;
  margin: 0 1em 0 2em;
  padding: 0.5em 0;
  border-bottom: 0.05em solid ${colors.mainHalf};
  postion: relative;
  color: ${colors.textBody};
  text-decoration: none;

  &:before {
    content: '';
    transition: 0.5s;
    width: 0.5em;
    height: 0.5em;
    position: absolute;
    left: 0.8em;
    border-radius: 50%;
    display: block;
    background-color: ${colors.main};
    transform: scale(0);
  }&:last-child {
    border-bottom: none;
  }&:hover {&:before {
      transform: scale(1);
    }
  }
`

export default () => (<StaticQuery
    query={graphql`
      {
        allSitePage {
          edges {
            node {
              id,
              path
            }
          }
        }
      }
    `}
    render={({
      allSitePage: {
        edges
      }
    }) => (<Sidebar>
        {
          edges.map(({
            node: {
              id,
              path
            }
          }) => (<Link to={path} key={id} css={navItem} >{id}</Link>
          ))
        }</Sidebar>
    )}
  />

)

Вже існуючі елементи стилізовані, і настав час зв’язати контент з Contentful, підключити Markdown-плагін і згенерувати сторінки, використовуючи createPages API.

Детальніше про те, як зв’язати Gatsby і Contentful, читайте в попередній статті.

[
  {
    "id": "title",
    "type": "Symbol"
  },
  {
    "id": "content",
    "type": "Text",
  },
  {
    "id": "link",
    "type": "Symbol",
  },
  {
    "id": "orderNumber",
    "type": "Integer",
  }
]

Встановлення пакетів:

yarn add dotenv gatsby-source-contentful gatsby-transformer-remark

/gatsby-config.js

if (process.env.NODE_ENV === "development") {
  require("dotenv").config();
}

module.exports = {
  plugins: [
    `gatsby-transformer-remark`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`,
      }
    },
    {
      resolve: `gatsby-plugin-typography`,
      options: {
        pathToConfigModule: `src/utils/typography`,
      },
    },
    {
      resolve: `gatsby-source-contentful`,
      options: {
        spaceId: process.env.CONTENTFUL_SPACE_ID,
        accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
      },
    },
    `gatsby-plugin-sass`,
    `gatsby-plugin-styled-components`,
  ],
}

Видаляємо папку /src/pagesз усіма файлами всередині і створюємо новий файл для керування вузлами в Gatsby:

/gatsby-node.js

const path = require(`path`);

/**
 * Експортована функція, яка перезапише існуючу за замовчуванням,
 * та буде викликана для генерації сторінок
 */
exports.createPages = ({ graphql, actions }) => {
  /**
   * Отримуємо метод для створення сторінки з екшенів,
   * щоб уникнути зайвих імпортів і зберігати контекст
   * сторінки і функції
   */
  const { createPage } = actions;
  return graphql(`
    {
      allContentfulArticle {
        edges {
          node {
            title
            link
            content {
              childMarkdownRemark {
                html
              }
            }
          }
        }
      }
    }
  `).then(({ data: { allContentfulArticle: { edges } } }) => {
    /**
     * Для кожного елемента з відповіді
     * викликаємо createPage () функцію і передаємо
     * всередину дані за допомогою контексту
     */
    edges.forEach(({ node }) => {
      createPage({
        path: node.link,
        component: path.resolve(`./src/templates/index.js`),
        context: {
          slug: node.link
        }
      });
    });
  });
};

Детальніше про gatsby-node.js.

Створюємо template-файл, який буде основою для сторінок, які генеруються/src/templates/index.js

import React from "react";
import { graphql } from "gatsby";
import Layout from "../components/layout";

export default ({
  data: {
    allContentfulArticle: {
      edges: [
        {
          node: {
            content: {
              childMarkdownRemark: { html }
            }
          }
        }
      ]
    }
  }
}) => {
  return (<Layout><div dangerouslySetInnerHTML={{ __html: html }} /></Layout>
  );
};

export const query = graphql`
  query($slug: String!) {
    allContentfulArticle(filter: { link: { eq: $slug } }) {
      edges {
        node {
          title
          link
          content {
            childMarkdownRemark {
              html
            }
          }
        }
      }
    }
  }
`;

Чому тут не використовується <StaticQuery /> компонент? Вся справа в тому, що він не підтримує змінні для побудови запиту, а нам потрібно використовувати змінну $slug з контексту сторінки.

import React from "react";
import { Link, StaticQuery, graphql } from "gatsby";
import styled from "styled-components";

import { colors } from "../utils/vars";

const Sidebar = styled.section`
  position: fixed;
  left: 0;
  width: 20%;
  height: 100%;
  display: flex;
  flex-direction: column;
  justify-content: center;
  background-color: ${colors.second};
  color: ${colors.textMain};
`;

const navItem = `
  display: flex;
  align-items: center;
  margin: 0 1em 0 2em;
  padding: 0.5em 0;
  border-bottom: 0.05em solid ${colors.main50};
  postion: relative;
  color: ${colors.textBody};
  text-decoration: none;

  &:before {
    content: '';
    transition: 0.5s;
    width: 0.5em;
    height: 0.5em;
    position: absolute;
    left: 0.8em;
    border-radius: 50%;
    display: block;
    background-color: ${colors.main};
    transform: scale(0);
  }&:last-child {
    border-bottom: none;
  }&:hover {&:before {
      transform: scale(1);
    }
  }
`;

export default () => (<StaticQuery
    query={graphql`
      {
        allContentfulArticle(sort: { order: ASC, fields: orderNumber }) {
          edges {
            node {
              title
              link
              orderNumber
            }
          }
        }
      }
    `}
    render={({ allContentfulArticle: { edges } }) => (<Sidebar>
        {edges.map(({ node: { title, link, orderNumber } }) => (<Link to={link} key={link} css={navItem}>
            {orderNumber}. {title}</Link>
        ))}</Sidebar>
    )}
  />
);

SEO-оптимізація з використанням react-helmet

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

yarn add gatsby-plugin-react-helmet react-helmet

react-helmetгенерує <head> ... </ head>для HTML сторінок і в зв’язці з Gatsby рендерингом є потужним і зручним інструментом для роботи з SEO.

/src/templates/index.js

import React from "react";
import { graphql } from "gatsby";
import { Helmet } from "react-helmet";

import Layout from "../components/layout";

export default ({
  data: {
    allContentfulArticle: {
      edges: [
        {
          node: {
            title,
            content: {
              childMarkdownRemark: { html }
            }
          }
        }
      ]
    }
  }
}) => {
  return (<Layout><Helmet><meta charSet="utf-8" /><title>{title}</title></Helmet><div dangerouslySetInnerHTML={{ __html: html }} /></Layout>
  );
};

export const query = graphql`
  query($slug: String!) {
    allContentfulArticle(filter: { link: { eq: $slug } }) {
      edges {
        node {
          title
          link
          content {
            childMarkdownRemark {
              html
            }
          }
        }
      }
    }
  }
`;

Тепер titleсайту буде завжди збігатися з назвою статті, що буде істотно впливати на видачу сайту в результатах пошуку, конкретно з цього питання. Сюди ж можна легко додати <meta name="description" content="Опис статті"> з описом кожної статті окремо, надаючи цим можливість користувачеві, ще на сторінці пошуку, зрозуміти, про що йде мова в статті. І взагалі всі можливості SEO тепер доступні, і ними можна керувати з одного місця.

Налаштування PWA

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

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

• https-протокол;
• наявність manifest.json;
• офлайн-доступ до сайту за рахунок service workers.

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

Переходимо до інших пунктів. Для цього встановимо два плагіни:

yarn add gatsby-plugin-manifest gatsby-plugin-offline

і налаштуємо їх /src/gatsby-config.js

if (process.env.NODE_ENV === "development") {
  require("dotenv").config();
}

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `GatsbyJS translated tutorial`,
        short_name: `GatsbyJS tutorial`,
        start_url: `/`,
        background_color: `#f7f0eb`,
        theme_color: `#a2466c`,
        display: `standalone`,
        icon: `public/favicon.ico`,
        include_favicon: true
      }
    },
    `gatsby-plugin-offline`,
    `gatsby-transformer-remark`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images/`
      }
    },
    {
      resolve: `gatsby-plugin-typography`,
      options: {
        pathToConfigModule: `src/utils/typography`
      }
    },
    {
      resolve: `gatsby-source-contentful`,
      options: {
        spaceId: process.env.CONTENTFUL_SPACE_ID,
        accessToken: process.env.CONTENTFUL_ACCESS_TOKEN
      }
    },
    `gatsby-plugin-sass`,
    `gatsby-plugin-styled-components`,
    `gatsby-plugin-react-helmet`
  ]
};

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

Ніяких змін в режимі розробки ви не помітите, але сайт вже відповідає останнім вимогам світу web. І коли він буде розміщений на https:// домені, йому не буде рівних.

Висновок

Кілька років тому, коли я вперше зіткнувся з проблемами виведення в інтернет React-додатку, його підтримки і оновлення контенту, я і не міг уявити, що на ринку вже існував JAM-stack підхід, який спрощує всі ці процеси. І зараз я не перестаю дивуватися його простоті. Gatsby вирішує більшість питань, які впливають на продуктивність сайту просто «з коробки». А якщо ще трохи розібравшись в тонкощах, налаштувати його під свої потреби, то можна отримати 100% показники за всіма пунктами в Lighthouse, чим суттєво вплинути на видачу сайту в пошукових системах (принаймні в Google).

Репозиторій з проектом

Наостанок

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

Читайте також мою попередню статтюпро те, як створити і опублікувати особистий блог, використовуючи JAM-stack.

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

Медицина

— Почему все врачи работают на полторы ставки?
— Потому что на одну кушать нечего, а на две — некогда.

К сожалению, в этой шутке не доля правды, а все 100%. Это при том, что доктора сперва учатся 6 лет не самой простой специальности, а теперь работают по 50-60часов в неделю за 150 баксов (это на полторы ставки).

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

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

Копирайтинг

Из-за безденежья и постоянных больничных у меня в жизни и появился копирайтинг. Тогда 10 баксов в день были серьёзной прибавкой к зарплате. Были месяцы, когда копирайтингом я зарабатывала больше, чем врачеванием. Так купила первый нетбук (невероятно удобная штука, выручал меня много лет) и смогла попутешествовать (31 день отпуска + 14 бесплатного). Да и просто это же так круто — собирать из разрозненной информации красивое, связное повествование, расставлять все эти запятые и мягкие знаки, и делать это дома, когда и как удобно.

Друзья-программисты

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

Так я впервые познакомилась с волшебным миром IT. С очень странными и очень интересными людьми, которые, даже сидя у костра in the middle of nowhere, продолжают обсуждать работу, потому что им это интересно. Которые могут сделать какую-то полезную магию, и её можно загрузить к себе на комп. Которые поднимают FTP-сервер, чтобы обменяться походными фотками. Которые объясняют тебе, что такое рекурсия на примере матрёшки, просто потому что могут. И знаете, за пять лет общения с ними получилось неплохо так подтянуть компьютерную грамотность. Потому что когда на жалобы, что залитый на сайт рассказ выглядит убого, тебе говорят: «Так добавь там теги», — ты идёшь, гуглишь, что такое теги, куда их добавлять, как и зачем. И так далее. А в какой-то момент оказалось, что я понимаю, о чём они разговаривают, когда обсуждают работу :)

Поход в Карпатах, 2017 год

Тестирование

Со временем в походные ряды затесались несколько тестировщиков, и после общения с ними я поняла — вот она, та часть IT, в которой я могу разобраться и делать это за деньги. На дворе был 2013 год, и кроме Савина с Канером информации о тестировании, можно сказать, не было. Классическая парочка была изучена, законспектирована и отложена до лучших времён. Особенно запомнилось и запало в душу вот это — «Will work day and night» из Савина. Тогда я ещё не понимала, насколько это правда.

Уточню, что в Донецке в то время было три аутсорсинговые фирмы, в которых в сумме работало 100-150 человек.Соответственно, шансов найти работу тестировщиком не было абсолютно.

Война

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

Курсы-курсы

Пока искала заказы на копирайт, попалось объявление о наборе на бесплатные курсы тестировщиков с последующим трудоустройством. Конечно, я отправила резюме и через пару недель начала постигать азы. Написать впервые «The button is not clickable» было настоящим подвигом при довольно пассивном английском. Но за пару недель я втянулась, выучила стандартные описательные фразы, разобралась с системой трекинга (кажется, там была Bugzilla). После окончания курса оказалось, что только я и еще 4 человека из 36 на курсе благополучно выполнили все условия и получили сертификат. Прошли недели, обещанного приглашения на работу не было, и я задумалась о поиске работы в тестировании.

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

Волшебный мир IT

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

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

Первый проект

Это была система со сложной, постоянно меняющейся логикой, поэтому тестирование проходило полностью в ручном режиме. Когда я появилась на проекте, его как раз переводили с типичного Waterfall на что-то более гибкое, с переменным успехом. Мои опасения по поводу того, что работать будет дико скучно, не оправдались. Разбираться, как оно работает, как должно работать и почему всё нужно переделать, оказалось очень увлекательно. А разработчики, которые писали в Jira «My code is perfect, problem is in your server», только добавляли азарта.

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

Моя первая реакция на его переход была: «А что, так можно было?». Вторая: «А можно на его место?!». Намного более интересная и технически сложная работа, маленькая команда «фидеров» — на тот момент это было идеально.

Нужно уточнить: тогда мне казалось, что единственно возможный путь из тестировщиков в разработчики выглядит так: ручное тестирование → автоматизированное тестирование → разработка. И этот переход коллеги в другой отдел просто перевернул мои представления. Это же можно не учить Java и фреймворки тестирования, а сразу упороться в JS и сопутствующее и ломиться во фронтенд! Очень к месту оказалась и беседа с тимлидом о моём прогрессе и направлении дальнейшего роста, которая утвердила меня в мысли двигаться сразу в разработку.

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

После перехода в команду фидеров начался мой «марафон» по обучению JS длиной в полтора года. На перерывах, по выходным и вечерам — все попавшиеся бесплатные курсы были моими, Coursera и Codecademy постоянно висели во вкладках браузера. Да, было тяжело, да иногда всё доставало, хотелось просто лечь и лежать, и я забивала на всё и шла бегать. Лечь и лежать далеко не всегда помогает :) И ведь главное в марафоне — не избежать падения, а после него встать, отряхнуться и бежать дальше.

Признание

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

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

if 1:
    print('true')
else:
   print('false')

А у коллеги написано так:

if 1:
print(„true“)
else:
print(„false“)

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

Смена руководства

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

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

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

Примерно в этот момент звёзды сошлись, и мне назначили собеседование в JS отдел. Огромное спасибо начальникам отделов, которые всё это организовали!

На переднем крае

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

Выше я писала, что учить программирование и одновременно работать тестировщиком — тяжело. Фигня. Если то был марафон, то здесь — ультратрейл, 200 километров по горам без сна и отдыха. Там я успевала ходить на тренировки и почти всегда спать не меньше 7 часов. С программированием такое не прокатило. Приходишь с работы — и продолжаешь то же самое дома, для обучения. И так 4 месяца. Через 4 месяца я настолько отвратительно себя чувствовала, что пришлось выбирать — возобновить регулярные тренировки и госпитализироваться из-за проблем со спиной. Но к этому моменту я уже достаточно уверенно справлялась с текущими тасками, поэтому выделить 3-4вечера в неделю на восстановление получилось.

Софт скиллы

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

Легаси JS

Так, постепенно доучиваясь, после нескольких проектов по несколько месяцев каждый, я впервые попала на Очень Большой и Старый Проект. Да, JS — молодой язык, но и на нём уже есть легаси-проекты. Да, это страшная штука. В нашем было намешано всё — от чистого JS и Jquery начала 2000-х,до React и Angular. И снова софт скиллы не подвели — общаться и переписываться пришлось ой как много.

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

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

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

Мама, я не хочу так работать

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

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

Попытки что-то поменять и последние месяцы работы

Я начала напрягать лидов, менеджеров и всех, до кого дотянусь, в попытках поменять график, отпуск, да что угодно. Так уж сложилось, что большая часть интересных и полезных мне активностей происходит вечером, и мне удобнее работать с 8-9до 17-18 часов.Но нет, нельзя. График до 19, вот и работайте до 19.

Подготовка к соревнованиям по туризму, 2016 год

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

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

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

Есть ли жизнь после IT

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

Деньги я отложила ещё во время работы, а так как мы живём вдвоём с парнем — затраты на квартиру и еду не такие уж большие. Хватало и на поездить, и на проживание.

Upwork

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

Что сейчас

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

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

Волонтёрю в нескольких проектах — тоже текстами и переводами.
Бегаю.
Отдыхаю.
Гуляю с друзьями.
Готовлю еду, потому что интересно, а не потому что надо.
Не отпрашиваюсь.
Могу поехать в отпуск, когда захочу.
Да, денег меньше, но жизни — больше.

Жалею ли

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

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

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

А ещё я в который раз убедилась в том, что работа должна быть по любви. Ну хоть по небольшой симпатии. Мы же выбираем приятных нам и комфортных в общении партнёров для жизни. А работа — следующее (или первое, если не учитывать сон) по количеству затрачиваемого времени занятие. С программированием же ещё сложнее. Если ты хочешь быть хорошим разработчиком (а я привыкла делать работу хорошо), то 40 часами в неделю не обойдёшься. 9-10часов в офисе (учитывая перерыв и английский), плюс час-два в день на дорогу — и оставшиеся 3-4часа нужно провести не с семьёй или на приятной и полезной тренировке, а программируя. Потому что иначе через полгода ты безнадёжно отстанешь по технологиям и будешь сидеть в том самом Большом и Старом Проекте, потому что больше нигде не нужен. Мне не настолько интересно программирование, чтобы заниматься этим 12 и больше часов в день. Поэтому да, я плохой разработчик. И да, работа должна быть по любви.

Хочу ли я вернуться в IT? Точно не сейчас и точно не программистом. Может, техническим писателем или БА. Но, как написали мне на Djinni, 80% их вакансий — полный день в офисе. А остальные 20% — «гибкий график». На один такой гибкий я уже насмотрелась.

Что дальше

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

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

Привет! Меня зовут Богдан, я работаю JavaScript программистом. Изучаю исходный код (JavaScript и не только) уже почти 10 лет. В этой статье я хочу рассказать свою историю разработки инструментов для анализа кода, а также представить свой последний Github-проект Codecrumbs. Он позволяет изучать, документировать и объяснять кодовую базу быстрее.

Идея

Всё началось ровно два года назад, когда я решил изучить исходный код React. Это оказалось довольно непростой задачей, и я провозился почти 3 месяца, пытаясь понять и построить в своей голове хоть какую-то картинку того, как всё работает. В итоге появился проект Under-the-hood-ReactJS. По отзывам сообщества, его можно считать «успешным», но уже тогда было понятно, что мой процесс изучения исходного кода был крайне неэффективным. Взять хотя бы рисование блок-схем: я описывал логику вручную, через flow-charts, и каждый раз, когда находил что-то новое в коде, — вынужден был перерисовывать схему. Нужно было это автоматизировать. В итоге появился проект js-code-to-svg-flowchart — библиотека, которая генерирует блок-схему по исходному коду. Уже лучше, но не совсем то, что мне было нужно.

Анализируя собственный опыт изучения исходного кода больших проектов, я пришел к выводу: мне не так сложно понять кусок кода какой-то конкретной функции, как тяжело увидеть «big picture», наложить абстракции и отсеять неважные детали. Каждый раз я ловил себя на мысли, что я начинаю бессмысленно прыгать между файлами, зачастую открывая один и тот же файл несколько раз и осознавая, что «ой, я это уже видел, это не то место» или «где же то нужное место, которое я только что видел». Итак, мне нужен был какой-то инструмент, чтобы помечать важные места в коде, и в идеале, чтобы он строил ту самую «визуальную картинку» того, как все работает. Также он должен работать с существующими кодовыми базами без необходимости переписывать код для каждого «нового фреймворка». Так появился проект Codecrumbs (название производное от «code» и «breadcrumb») — инструмент, который позволяет оставлять «хлебные крошки» в коде и по ним строить визуальную схему.

Реализация проекта

Проект является классическим примером клиент-серверной архитектуры с общением через сокеты. Всё реализовано средствами JavaScript. Сервер анализирует код проекта и ищет комментарии, содержащие «codecrumbs», собирает их и отправляет на клиент. Клиент накладывает их на структуру проекта и рисует SVG картинку. Есть поддержка «live updates», так что процесс использования может быть следующим: на одном мониторе ваш редактор кода, на другом — вкладка браузера с Codecrumbs-клиентом. Пишете комментарий — схема перестраивается на лету.

Давайте рассмотрим основные фичи.

Trail of breadcrumbs («цепочка крошек») — последовательность крошек, которые описывают какой-то сценарий внутри приложения (например, аутентификация или отправка формы на сервер и т. д.).

Dependencies tree («дерево зависимостей») — позволяет легко определять, «что куда импортируется».

Flowchart («блок-схема») — позволяет посмотреть блок-схему выбранного файла.

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

После всего этого также можно скачать и «отправить другу» схему, которую вы только что изучили. Воспользуйтесь функцией «download», чтобы получить текущее состояние приложения в формате json-файла. Файл будет содержать минимальное количество данных, чтобы отобразить схему: для этого не обязательно иметь локально тот же исходный код — Codecrumbs может работать в «standalone» режиме в браузере. Пример тут.

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

• JavaScript;
• TypeScript;
• Python;
• PHP;
• Java;
• C++.

JavaScript предлагает больше функционала, чем остальные, так как только он использует AST-парсер для обработки кода.

Дальнейшие планы

Codecrumbs позволяет изучать, документировать и объяснять кодовую базу быстрее. Кроме того, функция «download/upload» позволяет очень легко распространять результаты исследования кода. Конечная цель — разместить множество таких «кейсов» на codecrumbs.ioи получить что-то в стиле библиотеки проектов «explained with Codecrumbs». Место, где все смогут делиться знаниями на примерах реальных проектов.

More cool features coming soon, stay tuned! И да, нажмите «star» и «расскажите друзьям» :) GitHub-репозиторий тут. Спасибо!

Ниже будет много текста исключительно про мексиканцев, поэтому пару слов о том, почему решил написать этот материал. В отличие от других авторов публикаций подобного формата, я не был айтишником до переезда. В юности разрывался между двумя увлечениями: музыкой и компьютером. Закончив музыкальную школу им. Столярского и не доучившись на ИМЭМ в ОНУ им. Мечникова, получил приглашение работать в мексиканском оркестре. Гастролировал по городам и штатам, а потом воспользовался возможностью поработать в более прибыльных сферах и ушел в менеджмент, а затем переквалифицировался в PM. Работал в дочерних компаниях крупного медиахолдинга, которые занимались мобильной разработкой для ретейлера смартфонов (зачастую с предустановленным софтом). Также были разовые аутсорс-заказы.

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

Образование и квалификация

Мексиканцы достаточно работящие, но зачастую их квалификация сильно хромает. Вы можете встретить сеньоров с десятилетним стажем, которые по своей подготовке соответствуют уровню наших начинающих мидлов. В Мексике в целом школа разработки слабая, а образование очень узкопрофильное. Я не раз становился свидетелем ситуаций, когда DBA не мог закрыть вопросы DevOps’a, а Front-end не понимал, как работает Back-end. В Мексике высшее образование получает намного меньше людей, чем в Украине. Это достаточно дорого, и позволить себе могут немногие. Поступление в университет в глазах общественности приравнивается к входу в ряды если не элиты, то среднего класса точно. Есть разные scholarship программы, которые финансирует государство. Стать их участником можно по результатам успеваемости на первом курсе. Обучение первокурсники оплачивают из собственного кармана, но можно получить образовательный кредит, подписавшись на работу в университете после диплома в течение нескольких лет.

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

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

Отношение к работе

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

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

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

Порядок на рабочем месте — явление редкое, но еду там не найдешь

Общение

Для начала забудьте про хороший английский. Это одна из главных проблем мексиканского IT. Вообще, если есть планы релокейта в Латинскую Америку — учите испанский. На нем говорят повсюду кроме Бразилии (бывшей колонии Португалии). Поэтому латиноамериканцы не особо мотивированы учить английский. Особенно если они не планируют переехать в США. Поэтому для удачной адаптации в коллективе знание испанского обязательно. Мексиканцы предельно вежливые. Ipocrecía — знаменитая мексиканская вежливость на грани с лицемерием. Они никогда не скажут тебе в лицо, что действительно о тебе думают. Только завуалировано в духе: «Вы замечательный специалист и великолепно делаете свою работу, но это немного не то, что было в тех. задании».

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

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

Популярность киновселенных Marvel и DC не прошла мимо Мексики

Субординация

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

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

Мексиканцы очень любят Lego

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

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

Лень

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

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

Мексиканцы без скепсиса относятся к корпоративным активностям

Интересы

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

В Мексике по сей день популярна corrida de toros. Есть категория людей, которые регулярно ее посещают не только ради эмоций, но и делают ставки. В больших городах с более чем миллионным населением (Мехико, Гвадалахара, Монтеррей) проходят сезонные ивенты Temporada de Toros или Fiesta Brava.

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

Празднование Дня мертвых (Día de los Muertos)

Влияние климата и сиеста

Говоря про климат Мексики, вообще некорректно что-то усреднять или обобщать. Государство растянулось на 4000 километров с юго-востока на северо-запад и охватило три часовых пояса. Климатически Мексику тоже можно разделить на три зоны. Для центральной характерен умеренно континентальный климат с уклоном в субтропики. Его можно сравнить с Кипром или Испанией. Юг больше напоминает Таиланд или Бали. Север по климату похож на Калифорнию — летом температура держится в районе +40 градусов по Цельсию, а зимой редко опускается ниже +10.

В Мексике, как и во многих других латиноамериканских странах, есть сиеста. Но она короче, чем в Испании. Длительность зависит от климата и в большинстве городов составляет час или полтора. Это не вместо часового перерыва на обед, а плюс к нему. Как правило, это время все проводят так же, как и у нас. Кто-то ходит обедать в кафе, кто-то ездит домой. Единицы спят днем, но это, скорее, исключения. Но есть территории, для которых сиеста — это не просто формальность. К примеру, в северной Мексике зафиксированы одни из самых высоких регулярных температур на планете (52 °C). В таких местах днем жизнь просто останавливается. С таким климатом можно практически забыть про теплую одежду. И мужчины, и женщины круглый год носят джинсы с футболками, делая исключение только для официальных мероприятий. Это касается не только сферы IT. Так делает 80% населения. У них нет культа стильно или оригинально одеваться. Носят то, что удобно.

Мексиканцы не упускают случая тематически украсить офис

Безопасность

Несколько лет я прожил в городе Кульякан. Это штаб-квартира наркокартеля Синалоа, который возглавлял знаменитый «Коротышка» Гусман (один из самых разыскиваемых преступников планеты). В плохих районах бывало слышно очереди в небо. Пострелять они любят. Никогда не слышал, чтобы просто так нападали на мирных жителей. За пять лет жизни в Кульякане меня ни разу это не коснулось. Но у моего знакомого застрелили собаку. Кстати, большинство IT-офисов находится в достаточно спокойной центральной части Мексики.

Стоит ли переезжать

Если вы рассматриваете Латинскую Америку, то Мексика — один из лучших вариантов по ЗП. На уровне с Чили и Бразилией, но последняя куда криминальнее в плане обстановки. Для удаленной работы Мексику не советую, поскольку по уровню цен она дороже Доминиканы или Коста-Рики. Здесь вы получите меньшее за большее. Если же у вас есть оффер в мексиканский офис, то соцпакеты, правовая защищенность в этой стране на достойном уровне.

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

Привет, DOU. Меня зовут Ярослав Степаненко, я Product Marketing Manager в компании MacPawи сооснователь конференции Growth Marketing Stage. В этой статье я расскажу, как измерить Product/Market Fit для уже запущенного продукта и какие инсайты можно от этого получить.

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

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

• Нужен ли наш продукт кому-то?
• Будут ли за него платить?
• Как не потерять деньги, вложенные в маркетинг?

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

Большие компании делают это по-разному. В этом году на Growth Marketing Stage мы постарались сделать акцент на том, как важно понимать своего пользователя, чтобы растить продукт. Для этого мы везем ресерчеров из Dropbox и Uber, которые расскажут, как в их компаниях с помощью исследования пользователей создают возможности для роста. Однако что делать, если вы — не Dropbox? Я хочу поделиться простым фреймворком для измерения Product/Market fit для продукта, у которого уже есть первые пользователи, который применяю у себя в практике.

Что такое Product/Market fit

«Product/Market fit означает наличие продукта, который может удовлетворить потребности конкретного рынка».
Марк Андриссен, сооснователь Andreessen Horowitz

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

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

Как опрашивать пользователей на примере Telegram

Далее я продемонстрирую работу опросника на примере продукта Telegram.

Главный вопрос анкеты — «Как бы вы отреагировали, если бы Telegram исчез (прекратил свое существование)?». Согласно методотогии Шона, если 40%+ респондентов ответили«Я бы очень сильно расстроился», у бизнеса есть product/market fit. Ответы на остальные вопросы анкеты дают море инсайтов и идей. Детали ниже.

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

Важно не собирать ответы у всех. Для получения качественных данных, опросить необходимо только активных пользователей. Предлагаемый критерий определения активных — те, кто взаимодействовал с продуктом в последние 2 недели. Для достоверности потребуется не менее ста (чем больше, тем лучше) респондентов. Ни в коем случае нельзя платить за ответы или обещать какого-либо рода «ништяки». Поощрение приведет в ложным комплиментам и не даст понимания реальной картины.

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

Что мы узнали про Telegram

Отличная новость: Telegram — это продукт, у которого есть product/market fit. 54% пользователей будут очень расстроены,если он прекратит свое существование. Стоит заметить, что Telegram имеет 200M+ MAU, поэтому в этом конкретном случае нет ничего удивительного в таком результате.

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

Лояльные пользователи

Этот сегмент видит ценность Telegram в следующем:

• скорость;
• минимализм;
• простота;
• полезные каналы:
  
  • новые знания;
  • новости;
• ведение своих каналов;
• боты.

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

Примечательно, что, отвечая на вопрос про альтернативу Telegram, два «лагеря пользователей» очень по-разному описывают возможные заменители этого продукта. Пассивный сегмент просто называет смежные решения (FB messenger, Viber, WhatsApp), в то время как лояльные пользователи зачастую резко высказываются об альтернативных решениях:

• Бесят вацап, вайбер и до%*$нный месенджер фб.
• С%$&ный Viber (((( зачем вы такое спрашиваете , настроение портится от одной мысли об этом.

Ценность продукта

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

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

Профиль пользователя словами пользователя

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

• Молодые люди в больших городах.
• Те, кто работает в условиях большой оперативной коммуникации (текст/звонки/файлы).
• Те, кто нуждается в секьюрной переписке.
• Пользователи, которым важно быстро и удобно обмениваться сообщениями.
• Авторы пабликов и каналов.
• Люди, которым нужна быстрая связь со своим кругом общения.
• Те, кому важны комьюнити и стабильный понятный мессенджер.
• Люди, которые зарабатывают на своих каналах.

Что нужно улучшать

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

• Убрать каналы из общего списка чатов.
• Каждому пользователю дать свое облако для файлов. Аналог Google Drive.
• Добавить видеозвонки и шеринг экрана компьютера.
• Поиск каналов по тематикам с качественной фильтрацией.
• Разбить нотификейшены на 2 типа для каналов и для личных сообщений.
• Возможность отмечать непрочитанными каналы с конкретного места.
• Добавить возможность «напоминаний о сообщениях».
• Как в Slack, разделить каналы и личные сообщения на разные списки.

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

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

В этой статье речь пойдет об интерпретируемости моделей машинного обучения, методах объяснения результатов и исследования работы моделей, а также о необходимости интерпретирования моделей как отдельной задачи. Материал является улучшенной версией теоретической части доклада How to explain predictions of your network, прочитанного на конференции AIUkraine 2018.

Зачем объяснять модель

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

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

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

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

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

— Почему мы должны верить вашей программе? Как вы докажете, что система работает?
— Мы взяли датасет A, архитектуру нейронной сети B, обучили ее методом C, в итоге на сете валидации мы получили значение метрики D (например, точность в 95%).
— Ну хорошо... А как ваша модель предсказывает?
— Вот архитектура сети (тут сложная картинка на страницу). Циферки со входа бегут слева направо на выход. В конце мы получаем вероятность для каждого возможного ответа, берем ответ с максимальной вероятностью.
— Допустим. А как модель сработает с такими картинками? Как модель найдет здесь собак? Что она будет для этого использовать?
— !?!
— Понятно. В production мы это пропустить не можем. Вдруг кто-нибудь из-за этого умрет? Или обратится в суд и отсудит очень много денег?

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

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

1. Практические:
   
   • Необходимость доверия пользователя к результатам модели.
   • Получение рекомендаций относительно того, как улучшить работу модели.
   • Наличие состязательных примеров (adversarial examples): например, как на картинке выше.
   • Исследование модели, получение новых знаний из модели.
2. Социальные, регуляторные, философские...

Доверие к модели

С одной стороны, data scientist’ы привыкли к тому, что качество работы модели определяется только целевой метрикой. С другой стороны, конечным пользователям системы это все равно не дает полной уверенности в корректности работы, так как они не чувствуют и не понимают, что за этой метрикой стоит. Для того чтобы сформировать это доверие, можно идти разными способами. Например, можно:

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

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

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

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

Отладка моделей

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

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

Состязательные примеры/атаки

Состязательные атаки (adversarial attack) — это очень актуальная тема, которая массово стала подниматься полтора года назад. Суть атаки состоит в том, что мы минимально меняем изначальный вход (например, изображение) таким образом, чтобы модель начала давать неправильные ответы. Например, сеть распознает изображение слева как панду всего лишь с вероятностью 57,7%. Но если наложить на изображение «белый шум» с очень маленьким весом (0,007), сеть с точностью 99,3% определит, что это гиббон.

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

Однако в ноябре 2017 года исследователи пошли еще дальше: они создали и распечатали на 3D-принтере игрушку — черепашку, которая для людей выглядела вполне нормально, а вот модель детекции объектов Google стабильно распознавала эту игрушку как винтовку.

Подробнее эксперимент можно посмотреть на видео.

Исследование модели

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

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

FATE

Так, в настоящее время сформировалось понятие FATE in AI (Fairness, Accountability, Transparency, Ethics — честность, отчетность, прозрачность, этика). Это проблемы, которые требуют своего рассмотрения при разработке модели, взаимодействующей с людьми. В настоящее время этими проблемами занимаются различные коллективы в университетах и больших компаниях, например в Microsoft Research.

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

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

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

Что означает интерпретация модели машинного обучения

Итак, необходимость объяснения моделей понятна, но все же что значит «проинтерпретировать модель» на практике? Что для этого нужно сделать?

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

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

• Если мы объясняем модель data scientist’у, то ему нужно сообщить одну информацию. Например, он в целом и так понимает, как архитектурно выглядит модель, но не знает, какое было распределение данных, какие входные параметры оказались важными для всей системы.
• Если мы объясняем пользователю системы, то у него другие задачи, и, соответственно, нужны другие объяснения. Например, ему будет более интересно, почему в его конкретном случае система выдала именно такой ответ, а не другой.
• Если объяснений системы требует регулирующая организация, то им нужна будет другая информация, более полная и охватывающая множество разных ситуаций.

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

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

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

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

Простые интерпретируемые модели машинного обучения

Обычно интерпретируемыми считают следующие модели:

• Линейные модели
• Деревья решений
• Некоторые нелинейные модели
• Обобщенные аддитивные модели

Линейная модель

y = a₀ + a₁×₁ + a₂×₂ + ... + a_nx_n

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

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

Однако что, если переменных 1000 или 10 000? Сможем ли мы легко интерпретировать такую модель? Скорее всего, нет. Мы просто не сумеем рассмотреть каждый коэффициент, не запомним, как что влияет и как они работают вместе. В этом случае часто применяют разные методы спарсификации данных, делают отбор признаков и пытаются уменьшить размерность этой модели. Будет ли такая модель интерпретируемой? Сложно сказать. Возможно, из 1000 признаков останется только 20, и тогда модель будет понятна в целом. А может быть, останется 800 признаков, и тогда интерпретация будет затруднена.

Деревья решений

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

Возникает вопрос: насколько глубокое дерево вы сможете объяснить или понять? Если глубина дерева составляет 5 уровней, можно попробовать. А если 10? В этом случае мы имеем около 1000 правил (для бинарного дерева). А если глубина его 15 уровней, степень разбиения — не 2, а 3? Это уже проблема.

Нелинейные модели

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

Обобщенные аддитивные модели

g(y) = f₁(x₁) + f₂(x₂) + ... + f_n(x_n)

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

Однако многое ли мы сможем понять, например, из такой модели:

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

Классификация методов интерпретации моделей

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

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

• Глобальные или локальные методы
• Моделезависимые или моделенезависмые
• Когда производится объяснение:
  
  • до построения модели
  • в процессе построения модели
  • после построения модели

Глобальные vs локальные интерпретации

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

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

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

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

Моделезависимые и моделенезависимые подходы

Здесь методы интерпретации модели будут отличаться тем, известна и используется ли структура модели при объяснении. Примеры моделезависимых подходов:

• Интерпретация коэффициентов в линейных моделях
• Интерпретация на основе механизма Attention в нейронных сетях

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

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

Интерпретируемость до построения модели

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

Интерпретируемость во время составления модели

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

• Линейные модели
• Разреженные модели
• Подходы, основанные на правилах (деревья решений)
• Монотонные модели (монотонные ограничения, например в XGBoost)
• Attention-механизм в нейронных сетях

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

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

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

This is a Kentucky warbler because this is a yellow bird with a black cheek patch and a black crown. Это кентуккский масковый певун: птица имеет желтый окрас перьев, черные пятна на щеках и черный хохолок.

Интерпретируемость после составления модели

Более интересный и, наверное, максимально востребованный подход — исследование и попытка интерпретации некоторого «черного ящика». Речь идет о предобученных нейронных сетях, моделях Support Vector Machines, ансамблях и т. д.

Здесь возможны сразу три задачи:

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

Объяснение модели

По факту данный метод занимается вычленением правил из моделей и в целом похож на Model Distillation, только при условии, что полученная модель должна быть не меньшего размера, а максимально интерпретируемой. Например, в 2017 году команда Google Brain выпустила статью Distilling a Neural Network Into a Soft Decision Tree, где конволюционная сеть приближается небольшим деревом решений.

Объяснение результата

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

Типичными примерами таких методов являются:

• Маски чувствительности (Saliency maps)
• Алгоритм LIME
• SHAPley-коэффициенты

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

Внутреннее исследование «черного ящика»

Здесь мы решаем примерно ту же задачу, что и при объяснении выхода, но не для последнего слоя, а для внутренних слоев. Мы пытаемся объяснить, что делает каждый конкретный слой внутри сети. Например, для этих целей мы можем использовать библиотеку Lucid, которая разрабатывается в Google (смотрите статьи Feature Visualizationи The Building Blocks of Interpretability).

Заключение

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

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

• Формального определения объяснения модели не существует, то есть объяснения для разных моделей и для разных реципиентов будут различными.
• Мы не можем выразить качество объяснения численно, например: «Это объяснение хорошее, его показатель 90%, а это чуть хуже, его показатель 85%». Пока таких метрик нет. Есть очень сложные подходы, сложные фреймворки по постановке таких экспериментов, но на практике они очень трудны для воспроизведения.
• Непонятно, сколько времени занимает понимание объяснениямодели. Иногда это может происходить быстро, а иногда для понимания модели нужно воспроизвести все вычисления, происходящие в модели.
• Не всегда понятны цели обучения. Для кого создается объяснение? Для data scientist’ов, владельцев бизнеса, конечного пользователя?
• Что делать с конфликтующими объяснениями?

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

Также в последнее время появилось множество различных библиотек для объяснения моделей. Недавно вышла статьяо новом фреймворке Google для объяснения моделей работы нейронных сетей What-if. IBM только недавно подключиласьк этой гонке с фреймворком Fairness 360 Kit.

Полезные ссылки:

• Interpretable Machine Learning.
• A Survey Of Methods For Explaining Black Box Models.
• Techniques for Interpretable Machine Learning.
• Interpretable Machine Learning, ICML presentation.
• Advanced Uses of SHAP Values.
• Awesome Interpretable Machine Learning.
• Lucid Framework.

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

[Дмитрий Малиночка сотрудничает с EPAM Ukraine в качестве Training & Development Specialist. Сертифицированный бизнес-тренер с 7-летнимопытом. За это время разработал и провел 7 авторских тренингов, готовил спикеров к выступлениям на TEDx, а также обучал специалистов крупных международных компаний. Увлекается психологией и, в частности, темой коммуникации между людьми]

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

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

Эрик Берн «Игры, в которые играют люди. Люди, которые играют в игры»

В оригинале — Games People Play: The Basic Handbook of Transactional Analysis, by Eric Berne

Универсальная книга. Она будет полезна каждому человеку. Я много слышал о ней, но прочитал недавно. Эрик Берн — известный американский психолог и психиатр XX века. На его счету есть авторское направление в психологии: трансакционный анализ и сценарный анализ. Трансакция — это взаимодействие между людьми. Если в трансакции есть скрытый смысл — это называется «игра». Книга именно об этом. С помощью «Игр, в которые играют люди...» можно понять многие bottle necks в своей жизни, осознать свои слабые места, вещи, из-за которых нами могут манипулировать. Потому издание полезно и для бизнеса, и для личной жизни.

Джон Кинг и Дэйв Логан «Лидер и племя: Пять уровней корпоративной культуры»

В оригинале — Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization, by David Logan and John King

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

Крис Андерсон «Успешные выступления на TED. Рецепты лучших спикеров»

В оригинале — TED Talks. The Official TED Guide to Public Speaking, by Chris Anderson

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

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

Дэвид Аллен «Как привести дела в порядок. Искусство продуктивности без стресса»

В оригинале — Getting Things Done: The art of Stress-Free Productivity, by David Allen

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

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

Михай Чиксентмихайи «Поток. Психология оптимального переживания»

В оригинале — Flow: The Psychology of Optimal Experience, by Mihaly Csikszentmihalyi

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

Сьогодні Роксолана Косів — iOS-розробниця в стокгольмському офісі Spotify, а почалося все з природничо-математичного ліцею в місті Долина Івано-Франківської області. Саме там дівчина потрапила до середовища, яке давало стимул сумлінно вчитися. Тоді її життя почало обертатися навколо математики й англійської мови. З легкої подачі тата-програміста вирішила пов’язати майбутнє з програмуванням та обрала нову на той час спеціальність «Програмна інженерія» у Львівській політехніці.

Робота в IT замість Work&Travel

Літо 2013-го,після свого третього курсу, дівчина планувала провести за програмою Work & Travel в Америці, але відмова у візі спонукала зайнятися чимось в Україні. Знайти роботу, наприклад. Шлях до розробки під iOS розпочався з вакансії Android-розробниці (стажиста) у компанії Remit. На співбесіді Роксолані сказали, що Android вона не знає, але запропонували вчити iOS. І вона погодилася, бо, за її словами, це єдине, що могла відповісти студентка третього курсу. Remit — це шведсько-українська компанія, де після стажування Роксолані запропонували роботу. Працюючи там майже два роки, дівчина їздила в бізнес-поїздки, тому ще тоді змогла познайомитися зі Стокгольмом.

Потім працювала в стартап-студії, а відтак — Mac-розробницею в N-iX. І хоч раніше Роксолана не мала досвіду в Mac-розробці, дівчину підкупив бренд компанії, адже, за відгуками працівників, це хороше місце для роботи. Після чотирьох років, розробляючи продукти під iOS і Mac, Роксолана зрозуміла, що мобільна розробка лежить ближче до душі. Крім того, з’явилося бажання працювати не підрядником, а безпосередньо з продуктом і впливати на те, що отримує кінцевий споживач. В Україні часто трапляється, що ті, кому набридла робота в аутсорсі, знаходять замовників і створюють власні маленькі компанії, де продовжують робити те саме. Роксолана також розглядала варіанти роботи в продуктовій компанії в Україні. Ті компанії, які їй імпонували, були в Києві, а переїжджати до столиці дівчина не хотіла. Та й швидко з’явилася можливість працювати віддалено.

Замовником став ресторатор із Франції. Саме ця робота дала змогу експериментувати. Дівчина багато читала, проходила курси на Udemy, стежила за новинами iOS-розробників на Medium і могла впроваджувати вирішення, які вважала доцільними. А в лютому 2018-горозпочалася історія Spotify.

Про Spotify

Spotify — це саме той улюблений багатьма сервіс, який уможливлює слухати музику й подкасти легально. Це саме той сервіс, який досі офіційно недоступний в Україні, хоча його й засновано 2006 року (тут, до речі, можна проголосувати за ідею запуску Spotify у нашій країні). 4165 людей у 18 офісах у всьому світі працюють для забезпечення роботи й розвитку сервісу, аби 200 мільйонів людей у 78 країнах мали безперервний доступ до 40 мільйонів аудіозаписів.

Роксолана не планувала працювати в Spotify, точніше не шукала роботу саме там навмисне. Її самі знайшли, і доволі стандартно — через LinkedIn. «Тобі цікаво пройти співбесіду?» — запитала рекрутерка. Звісно, що дівчині було цікаво. Переїжджати з України не планувала, бо й у Львові їй було класно (не дарма його визналинайкомфортнішим серед українських міст). Але коли з’явилася можливість, то чому б не спробувати? Пройти співбесіду заради самої співбесіди в цій компаній — це вже крутий досвід.

Співбесіди

Отож спочатку три онлайн-інтерв’ю: з HR, технічне й культурне. Під час першої розмови, окрім загальних запитань, потрібно взяти участь у технічній вікторині, з варіантами відповідей «так» і «ні». Запитання стосувалися як загалом програмування, так і безпосередньо напряму iOS. Результат quiz’у — це і є допуск (чи недопуск) до наступного інтерв’ю, якого Роксолана боялася найбільше.

Другий етап — технічна співбесіда. Тут варто бути готовим і до теоретичних запитань, і до практичної частини. У Spotify — online coding. Роксолані довелося поділитися своїм екраном, пояснювати й коментувати, що та чому вона використовує для виконання завдання. Це інтерв’ю тривало майже півтори години.

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

Далі — onsite-співбесіда (або цілий день співбесід). Роксолана проходила інтерв’ю в головному офісі в Стокгольмі, їй оплатили дорогу й два дні перебування в місті. Три співбесіди й обід з потенційними співробітниками забирають увесь день. Перша співбесіда знову була культурною. Потім Роксолана проходила тестування на System Design, де потрібно було скласти архітектуру роботи програми, намалювати на дошці й пояснити свої рішення. Обід — це теж своєрідна співбесіда, адже після нього також дають зворотний зв’язок: наскільки людина комунікабельна та як поводиться в компанії.

Останнє інтерв’ю — Show and Tell. Його проводила iOS-програмістка Таня з Києва, яка привіталася українською (у Spotify багато дівчат-програмістів :)). Після дня співбесід це було найкраще, що можна було почути :) Тут показували свої проекти та їхні source code. Роксолана готувалася до цього й багато рефакторила, але однаково були місця, які хотілося покращити. Про це треба чесно й відверто говорити. Цей етап ще раз доводить, що, окрім основної роботи, варто мати власні pet-проекти (оскільки більшість проектів на компанію захищено договорами про нерозголошення).

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

Документи й переїзд

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

Кожному працівникові, який приїжджає з іншої країни, дають relocation package. Сюди входять оплата квитків, relocation allowance, шведський ID, допомога з відкриттям рахунку в банку. Релокейт-пакет охоплює також переїзд для сім’ї. Якби хтось хотів привезти із собою меблі, то їхнє перевезення теж би оплатили :)

Tyresta — національний парк біля Стокгольма

Корпоративна культура: ти маєш вплив

То чим відрізняється робота в аутсорс-компанії від роботи в продуктовій? «Усім!» — каже Роксолана. Spotify — це 100% agile-компанія. Команди маленькі й автономні, зазвичай не більш ніж вісім людей. Автономність означає, що кожна команда сама визначає, як побудувати процес, які інструменти для цього використовувати, скільки мають тривати спринти.

«Make podcast great for the first time», — жартують у команді Роксолани. Вони працюють над розвитком подкастів. Це відносно новий продукт Spotify, і саме подкасти є стратегічним фокусом компанії на 2019 рік. У їхній команді 8 людей: продакт-менеджер, розробники під iOS, під Android, QA, Agile Coach. Останній стежить за наявними процесами, інколи фасилітує мітинги, інколи допомагає придумати чи вдосконалити процес. Роботу побудували в такий спосіб: щоквартально вони планують завдання й задачі, які слід вирішити, а щотижня визначають поточний фокус.

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

Співпраця команд у Spotify. Джерело: Spotify Engineering Culture — Part 1

Невеликий розмір команди вможливлює кожному висловити свої зауваження чи коментарі з приводу тієї чи тієї фічі. Для шведів важливо, щоб до голосів секретаря й генерального директора дослухалися однаково. У Spotify працюють люди із 70 країн, сама Роксолана безпосередньо співпрацює з людьми з Філіппін, Німеччини, Британії, Мексики, і всі мають право голосу. Це створює унікальний досвід. Вони разом обговорюють розвиток продукту й те, що в підсумку отримає користувач. Для планування спринту використовують фізичну дошку й кольорові наліпки, для решти є JIRA та багато документів. Команди розміщуються в оупенспейсі, проте мають власні зони відпочинку й місця для обговорень, а практично кожна стіна в офісі — дошка.

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

Стандартно потрібно відпрацювати 40 год/тиждень, проте тут роботу побудовано на довірі. Немає clock-in i clock-out. Оскільки кожного члена команди активно залучено до процесу планування й розвитку, то він відчуває відповідальність за роботу, яку виконує. Роксолана здивована: «Ніхто не стежить, коли ти працюєш. У принципі, напевно, можна й не працювати. Але я не знаю нікого, хто хотів би нічого не робити :) Бо людям подобається те, чим вони займаються».

Оупенспейс у Spotify. Фото: Business Insider Nordic

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

Safe place to fail і кар’єрне зростання

«Ми хочемо робити помилки швидше, ніж будь-хто інший», — Даніель Ек, засновник Spotify. У процесі розробляння уникнути помилок неможливо. Кожна невдача — це можливість навчитися й перевірити свої знання. Тут за помилки не сварять, ба більше, навіть заохочують пробувати й помилятися. Саме тому про Spotify говорять, що це safe place to fail.

Роксолані пощастило потрапити до команди людей із 7-10-річним досвідом. У них є чому навчитися. Дівчина каже, що тут прийнятно чогось не знати й ставити багато запитань. Spotify — середовище, яке готове допомогти й підказати та зацікавлене у твоєму розвиткові. Два культурні інтерв’ю проводять для того, аби одразу відібрати правильних кандидатів, які дотримуватимуться принципів компанії. Spotify має рекомендації, як повинен поводитися працівник, який хоче сходити кар’єрною драбиною. Розвиток технічних навичок — це лише 20% на шляху до нового рівня. Переважно все залежить від поведінки. Тут головне — бути проактивним, брати ініціативу на себе, комунікувати з іншими й думати про те, як твоя робота вплине на бізнес.

У межах команди є Engineering Manager, який відповідає за людські ресурси й кар’єрне зростання працівників. Проте в Spotify існує правило «Drive your own development». Компанія створює багато воркшопів, можливостей для навчання й розвитку. Завданням програміста є їх використовувати, бо тут ніхто нікого не змушує. Інженер повинен бути проактивним. Нові знання, навички, підвищення — індивідуальна відповідальність кожного.

Тим паче Spotify заохочує інновації від працівників. 10% робочого часу (2 дні на місяць) працівники можуть використовувати, як хочуть: для навчання, власних проектів чи hack-проектів компанії. Spotify проводить Hack Days і Hack Weeks — досить популярну практику в продуктових компаніях, яка дає можливість утілити в життя всі найбожевільніші ідеї. Саме ті ідеї, на які немає часу через нагальні робочі задачі. Це може бути що завгодно: новий інструмент, який хотілося дослідити, створення нової фічі для продукту, покращення процесу, амбітна маркетингова компанія чи будь-що інше, що допоможе покращити Spotify. Так, наприклад, Discover Weekly — плейлист, який почався з рядка коду саме на одній з таких подій.

Життя в Швеції Spotify

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

Тут і справді є все, бо компанія планує навіть дозвілля своїх працівників. Кожен охочий може вибрати собі курси до душі. Наприклад, можна безплатно вчитися грати на гітарі, робити красиві фото чи міксувати музику. Spotify може похвалитися власною репетиційною та студією звукозапису Spotify Studios, які доступні для співробітників (такі самі студії є в офісах у Нью-Йорку, Лос-Анджелесі, Лондоні, Нешвілі).

Spotify Studios у Стокгольмі. Фото: Business Insider Nordic

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

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

Серед переваг роботи в Spotify: до соцпакета входить страхування, є можливість купити акції компанії та стати співвласником. Для працівників діє Stock Option Program, проте купувати чи ні — вибір кожного. А ще кожен, хто працює в Spotify, раз на рік може вибрати собі одну конференцію, а компанія оплатить квиток, проживання й харчування. Кажуть, що в Україні багато вихідних. Так от у шведському офісі Spotify пропонують 30 оплачуваних днів відпустки, лікарняні та, окрім того, можливі бізнес-поїздки.

Ціна за комфорт

Вартість життя в Стокгольмі вища за середньоєвропейську. Податки в середньому становлять 30% від зарплати (податок залежить від рівня доходу). Тому заощадити багато грошей, живучи в Стокгольмі, навряд чи вийде. Проте Роксолана переконана, що це — ціна комфорту, який того вартує. Дівчина їхала за досвідом, адже досвід у компаніях рівня Spotify — безцінний.

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

Шведську столицю можна обійти пішки, об’їхати автомобілем чи велосипедом, бо маршрути складено для всіх. Тут велосипедисти є такими самими учасниками дорожнього руху, як пішоходи чи автомобілісти. Для перших усюди є велодоріжки й окремі світлофори. Якщо немає власного велосипеда, не проблема: є безліч сервісів оренди, і навіть у найменшому з них, десь на набережній, можна розрахуватися платіжною карткою. Це, до речі, ще одна перевага для прихильників cashless economy: у магазинах, кіосках, таксі, метро чи туалетах не вимагатимуть готівку. І хоч Стокгольм — найбільше місто Швеції, його населення становить трохи менше ніж мільйон. Тут, навіть у центральній частині, не буде таких величезних натовпів людей, як, наприклад, у Римі чи Парижі.

Оскільки місто збудували на 14 островах, воно на третину складається з води, а ще на ⅓ — із зелених насаджень. У центрі дуже багато парків і скверів, а вже за 15 хвилин їзди можна насолоджуватися прогулянкою тихим лісом.

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

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

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

С каждым годом IT-индустрия уверенно развивается. Согласно исследованиям Gartner, в 2018 году мировой IT-рынок достиг 3,65 миллиардов долларов, что превысило показатель прошлого года на 3,9%. Прогноз на 2019 год тоже позитивный ー рост на 3,2% до $3,767 млрд. Основу рынка формируют 3 ключевых сегмента: информационно-телекоммуникационные технологии ($1,417 млрд), IT-услуги ($1,030 млрд) и девайсы ($679 млн). Но безоговорочным лидером в развитии является сектор разработки и внедрения корпоративного программного обеспечения, который с 2017 года растет в среднем на 9% ежегодно.

Давайте рассмотрим подробнее, какие инновации будут создавать инженеры во всем мире, нестандартные технологии в автоиндустрии, робототехнике и VR/AR, новинки от производителей гаджетов, а также навыки, которые понадобятся ІТ-специалистам.

Автомобили

В машиностроении беспилотные автомобили уже не новинка, но тема становится все популярнее. Согласно исследованиям J`son&Partners, рынок продаж самоуправляемых авто вырастет до 30,4 млн машин в год до 2035. Соответственно, мировые автопроизводители продолжают разрабатывать и презентовать прототипы self-driving vehicle. Полностью автономными становятся не только пассажирские, но и грузовые авто и мотоциклы.

Audi AICON. Здесь и дальше фото автора

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

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

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

Собственное видение развлечений в дороге презентовала компания Audi во время выставки CES 2019. Производитель оборудовал модель e-tron очками виртуальной реальности, которые переносят пассажира за штурвал космического корабля. Движения в игре полностью соответствуют движениям автомобиля, при повороте в реальной жизни, космолет также будет поворачивать. Во время игры пассажир не просто летает по космосу, а сражается с пришельцами и другими космическими кораблями с помощью небольшой кнопки. Помимо этой технологии компания представила концепцию интерактивного встроенного кинотеатра «Audi Immersive In-Car Entertainment», который работает, когда машина находится в неподвижном состоянии. Ключевая особенность кинотеатра в том, что зрители, то есть пассажиры, полностью ощущают все, что происходит в фильме: повороты, прыжки, падения, дорожные условия и т. д. Это похоже на технологию 4DX, только все действия происходят в машине. Конечно, пока разработкой могут пользоваться только пассажиры, но и это уже большой шаг на пути к «in car» развлечениям. Уверен, скоро и водителей займут какой-то увлекательной игрой.

Invisible-to-Visible Technology by Nissan

Также хочется отметить решение R.E.A.D. (Real-time Emotion Adapting Driving) от KIA. Технология способна распознавать человеческие эмоции, когда человек садится в машину, R.E.A.D. считывает, в каком эмоциональном состоянии он пребывает, а затем подстраивает свет, температуру и даже музыку под настроение водителя.

Гибкие дисплеи

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

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

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

Rollable TV by LG

Роботизация и умные помощники

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

AvatarMind iPAL Robot Family

Уже упомянутая компания Samsung на выставке CES также презентовала собственного робота на основе искусственного интеллекта. Bot Care ー персональный помощник по здоровью, он может измерить пульс, давление и другие жизненные показатели с помощью сенсорного дисплея на «голове» робота. В будущем его можно будет приобрести и использовать в домашних условиях.

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

Smart Home

За прошедший год в этой сфере прорыва не произошло. Основные проблемы такие же — сложность конфигурации, совместимость устройств от разных производителей и fail safe operation — и они все еще требуют решения. Рынок нуждается в производителе, который представит потребителям удобную концепцию использования технологий «умного» дома, как это десять лет назад сделал Apple со смартфонами.

5G

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

Виртуальная и дополненная реальность

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

Конечно, среди отраслей применения VR/AR энтертейнмент в будущем будет приносить наибольший доход. По прогнозамисследовательской компании International Data Corporation, в 2019 году рынок потребительских технологий достигнет 6,6 миллиардов долларов, из которых 4,6 миллиарда составляет сфера видеоигр, а 2 — сфера просмотра видео.

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

Забавные технологии

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

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

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

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

Underwater scooter Trident

Мировые тренды в Украине

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

Выводы

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

Что нужно знать и уметь в 2019 году, чтобы быть востребованным специалистом? Вот основные технологические драйверы роста:

• AI/ML ー технологии востребованы и применяются почти во всех упомянутых отраслях из-за активного перехода производителей от этапа концепции к масштабному производству. Специалисты в этой сфере, кроме очевидного аналитического склада ума, нуждаются в знании математических дисциплин.
• Embeddedー знание технологии понадобится всем, кто хочет разрабатывать программное обеспечение для автомобильной индустрии и IoT. Вам будут очень полезны знания в области hardware, необходимо разбираться в особенностях аппаратных платформ, понимать работу сетей, уметь тестировать и делать отладку. Embedded-разработчики постоянно востребованы на рынке.
• Edge Computing,или периферийные вычисления ー также одно из трендовых направлений 2019 года в связи с требованиями IoT и V2X и новыми возможностями 5G. Edge Computing охватит практически все сферы деятельности, начиная с логистики, сбора данных о производстве товаров до полной роботизации процессов.
• Среди языков программирования основной рост ожидается в Python, C/C++ и Node.js. Сферы применения этих языков включают все — от анализа данных, cloud-разработки до автоматизации тестирования.

Читайте также:

DOU Labs: как в WeAR studio создали приложение — виртуальный интернет-магазин бытовой техники

Три основные проблемы умных домов и как их можно решить

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

Всем привет! Меня зовут Тая, я Java разработчик. Хочу рассказать про наш стартап Voopty — веб-портал, который совмещает в себе CRM для школ/репетиторов и поисковик по тем же школам, репетиторам, курсам.

Идея

Я и моя сестра-близнец Настя закончили в 2006 году механико-математический факультет ХНУ им. Каразина по специальности «Преподаватель математики и информатики». Преподами мы не стали, а сразу впрыгнули в бурное харьковское IT. Я выбрала Java, а Настя (сейчас проживает в США) — .NET. Работали на разных проектах, в разных странах.

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

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

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

Как работает сервис

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

Балетные школы Харькова

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

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

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

На платных тарифах CRM дает возможность:

• вести учет посещаемости большого количества клиентов;
• автоматизировать бухгалтерию;
• рассылать Telegram, Viber, Email, SMS уведомления;
• записывать клиентов на урок online;
• работать с разными отчетами и проводить анализ при помощи чартов;
• у клиентов школы появляется личный кабинет, где они могут посмотреть историю своих посещений, оплат, домашние задания и т. д.

Больше информации про наши цены и фичи тут.

Killer Features

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

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

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

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

4. Мониторинг и аналитика. Всегда полезно знать, какой из ваших сервисов самый востребованный, какой педагог самый популярный и т. д. Грамотная аналитика наше все!

Технологии

На данный момент full-time над Voopty работаю я как (full stack developer) и еще два нанятых сотрудника, занимаются дизайном, SMM, Sales. Моя сестра Настя, .NET разработчик, тоже принимает активное участие в проекте, но part-time.

Слева — Тая, справа — Настя

К разработке мы приступили в конце 2015 года. Проработав 10 лет на Java, думала писать, на чем умею (был небольшой опыт с Ruby on Rails, но как-то не задело). Но потом решили посмотреть в сторону NodeJs, который как раз набирал обороты. Гуру JavaScript мы не были, но я всегда считала этот язык ambiguous and sexy (простите, не могу подобрать подходящих русских слов, если вдруг кто сможет, пишите). В начале было очень тяжело представить, что можно писать back-end на JavaScript, принять однопоточность, отсутствие вменяемого ООП, но все-таки мы прониклись. Low ceremony и функциональщина NodeJs очаровала джавистов и дотнетчиков. Так как технологию учили в процессе разработки, нам иногда аукается не сильно качественный, старый код, но по факту получилось довольно неплохо. Наверное, все-таки нас спас 10-летнийопыт на других технологиях.

Frontend пилим на ReactJS, чем тоже вполне довольны. Данные храним в MongoDВ, ищем через Elastic Search. Инфраструктура полностью на AWS, с использованием Docker контейнеров, бегающих внутри Kubernetes кластера.

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

Кто наши клиенты

Теоретически все, кто пользуются педагогическими и тренерскими услугами, — аудитория Voopty. Но в этом разделе я хочу рассказать про кастомеров Voopty CRM. Пользователи CRM — это маленькие и средние школы, студии, репетиторы. На данных момент у нас 25 зарегистрированных школ/репетиторов.

Семейный клуб «Мечта»

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

Преподаватель английского Анастасия Винограденко

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

Настя использует функции CRM для трекинга своих учеников. Для нее мы решили задачу учета прогульщиков. Так как она очень востребованный педагог, ей нужна статистика, чтобы не засорять свое расписание людьми, которые не ходят, и отдать время тому, кто будет заниматься регулярно. Она перестала вести посещаемость в бумажках и ведет всю бухгалтерию в Voopty. Настя использует CRM с мая и в этом году дала себе New Year’s resolution открыть свою школу. С Voopty она уверена, что сможет легко менеджить большее количество клиентов и развивать бизнес. Так как айтишники — основные клиенты Насти, она проявила себя как отличный Product Owner и продолжает давать качественный feedback по фичам :)

Pole Studio Kharkiv

Этим эффектным дамам мы даже сделали сайт на нашем движке polestudio.kh.ua, полностью интегрированный с CRM. Девчонки активно используют онлайн-расписание и Telegram bot для записи на занятие, различных напоминаний о продлении абонемента и оплате. Вот ссылкана наше интервью с руководителем этой студии, где Алина говорит про Voopty.

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

Проблемы

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

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

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

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

Цели и планы

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

Хотим добиться, чтобы школы отошли от бумажек и Excel. На входе в класс студенты сами отмечали бы себя через планшет или регистрировались заранее online, через приложение получали бы домашнее задание и все около учебные материалы. Девиз наших клиентов: «Я викладаю, для рутини та IT у мене є Voopty».

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

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

Про CRM
Поисковик по Харькову

Наши Instagram-страницы:
www.instagram.com/voopty_inside
www.instagram.com/voopty_portal
www.instagram.com/voopty_kids

На початку березня ми провели опитування ІТ-спеціалістівщодо їх ставлення до ініціативи підвищити єдиний податок до 10% для ІТ-ФОПів. У опитуванні взяли участь 7 973 спеціалісти, які наразі працюють у сфері ІТ. Подивимося, що думає спільнота про цей законопроект.

Про дослідження та портрет респондента

За законопроектом № 10094пропонується створити окрему п’яту групу ФОП, спеціально для спеціалістів, що провадять діяльність винятково у сфері інформаційних технологій (випуск комп’ютерних ігор та іншого програмного забезпечення, комп’ютерне програмування, консультування та пов’язана з цим діяльність, обробка даних, розміщення даних на веб-вузлах та пов’язана з ними діяльність, веб-портали), та поступово, до 2025 року, довести ставку єдиного податку для цієї групи до 10% від сукупного доходу від підприємницької діяльності.

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

Портрет респондента виглядає так:

89% опитаних зареєстровані як ФОП, 5% — як штатні працівники, 4% — ніяк не оформлені.

Більшість респондентів займають технічну посаду (90%) та мешкають в Україні (97%).

Понад 40% респондентів мають досвід в ІТ 6 і більше років. Спеціалістів з досвідом менше року лише 8%.

57% опитаних ФОП сплачують податки з доходів самостійно, 34% працівників компанія повністю компенсує сплату податків, ще 9% компанія компенсує частину податку.

ІТ-спеціалісти проти підвищення податку

Переважна кількість ІТ-спеціалістів, які взяли участь в опитуванні, висловилися проти підвищення ставки єдиного податку: 65% опитаних не підтримують ідею, запропоновану в законопроекті. Натомість 24% опитаних вважають, що податок можна підвищити, а ще 11% не визначилися з позицією.

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

Розподіл тих, хто підтримує ідею підвищення податку

У першу чергу, законопроект зачіпає інтереси тих ІТ-спеціалістів, які зараз оформлені як ФОП, тому природно, що 67% з них не хотіли б підвищення податків для себе, а підтримують цю ініціативу лише 22% з них. Проте ті, чиї стосунки із замовниками та роботодавцями оформлені іншим чином та кого ці зміни не стосуються безпосередньо, також не в захваті від ідеї. Дещо прихильніше ставляться ті, хто зараз оформлені як штатні працівники (34% вважають, що податок можна підвищити), а серед тих, хто отримує винагороду повністю чи частково в конверті, таких лише 19-20%.

Дещо більш прихильні до їдеї підвищення податку ті спеціалісти, яким компанія наразі повністю компенсує його розмір (63% з них не підтримують ідею підвищення, а 25% — підтримують). Ті ж спеціалісти, які самостійно оплачують податки (навіть якщо компанія бере на себе часткову сплату податку), більш скептичні: 70% з них не підтримують підвищення, і тільки 20% вважають, що податок можна зробити вищим.

Серед тих, хто більш прихильно ставиться до їдеї підвищення податку, опинилися також топ-менеджери компаній (34% з них, які взяли участь в опитуванні, вважають, що податок можна збільшити) та ІТ-спеціалісти з великим досвідом роботи (31% тих, хто працює в ІТ-сфері понад 5 років). Можна припустити, що це групи ІТ-спеціалістів з доходом вище середнього, внаслідок чого їм не так важко платити збільшений податок (більше 70% респондентів з цих груп, які підтримують підвищення податку, вважають, що податок в 10% — це небагато).

Єдиною групою опитаних, яка прихильно поставилася до ідеї збільшення податку для ІТ-спеціалістів, виявилися ті, хто зараз живе та працює у сфері ІТ за кордоном: серед них рівень підтримки підвищення податку сягнув 62% (майже 80% з них вважають, що 10% податку — це небагато).

Недовіра до держави — основна причина скептицизму ІТ-спеціалістів

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

З яких причин ви не хочете платити більший податок?

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

• відсутність обгрунтування, чому окрема група та окремий податок вводиться саме для ІТ-сфери («почему ІТ-специалистов необходимо выделять в отдельную когорту? Далеко не все специалисты в ІТ-сфере зарабатывают существенно больше других категорий граждан»);
• низька якість державних та соціальних послуг в Україні, зниження конкурентоздатності української ІТ-сфери внаслідок підвищення податків («это снизит привлекательность Украины для инвесторов, что может привести к упадку рынка IT, особенно на фоне и так постоянной конкуренции с более дешевой Индией»);
• загальна неефективність податкової системи («не бачу сенсу платити більше, якщо навколо купа людей, котрі отримують досить високий дохід і не сплачують взагалі нічого»);
• низькі доходи, які не дозволяють платити вищий податок («даже с такой зарплатой тяжело накопить на своё жильё. Тем более, когда надо помогать своим родителям и бабушкам с дедушками»).

В Україні й так високі податки (розподіл за місцем проживання)

У першу чергу недовіру до ефективного використання збільшеного податку державними органами висловлюють саме ті респонденти, які наразі оформлені як ФОП (92%), і лише 16% з них вважають, що податки в Україні і так високі. Дещо інша мотивація у тих, хто зараз оформлений як штатний працівник або отримує винагороду в конверті: для 88% з них корупція, відсутність реформ та розкрадання бюджету також є причиною не підтримувати ініціативу, проте помітно частіше за ФОПів вони вважають, що податки в Україні і так високі (28%). Ті, хто отримує винагороду в конверті, частіше за інших просто не хочуть платити більші податки — 17% (серед ФОПів та штатних працівників таких 12%).

Свій погляд на проблему у тих ФОПів, які працюють як фрілансери. Вони теж називають корупцію, відсутність реформ та розкрадання бюджету (87%) основною причиною небажання сплачувати вищі податки. Проте помітно частіше за інших ФОПів вони вважають, що податки в Україні і так високі (21% проти 15% серед тих ФОПів, які працюють в ІТ-компаніях), а також їм частіше видається несправедливим та необгрунтованим, що саме ІТ-спеціалістів пропонують виокремити в 5-тугрупу ФОП.

Схожа мотивація і у топ-менеджерів, які виступають проти підвищення податку для ІТ-ФОПів. Як і для інших опитаних, основною причиною для них є відсутність змін на краще, корупція та розкрадання бюджету (89%), але частіше за інших вони також вважають, що податки в Україні і так високі (20% проти 17% серед усіх опитаних) та що ІТ-спеціалісти не мають бути окремою групою ФОП.

За яких умов ви би погодилися на збільшення податку до 10%?

Водночас ті, хто висловилися проти підвищення податку зараз, переважно готові платити більше за умови видимих позитивних змін у країні. 72% готові платити більше, якщо система освоєння бюджетних коштів стане більш прозорою («когда коррупцию искоренят; не хочу платить за чей-то спорткар», «якби я міг частину єдиного податку (1-2%)віддати напряму на якісь роботи в місті»), а 65% — коли побачать реальні позитивні зміни в державі («перечисление денег на ремонт дорог, реставрацию зданий, повышение зарплат учителям в школе, а не на „фантомные покращення“», «коли б процент тих, кто не платить податки, зменшився», «справедлива судова система»).

Лише 9% противників підвищення не готові сплачувати вищий податок за жодних умов. Дещо частіше таку думку висловлювали фрілансери (12%).

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

10% податку — це небагато

Основними аргументами тих, хто підтримує підвищення податку для ІТ-спеціалістів, є те, що запропонований рівень оподаткування є невисоким та вигідним для платників. 69% прихильників ідеї вважають, що 10% — це небагато, а 63% відзначають, що це все одно менше, ніж податки на доходи тих, хто оформлений як штатний працівник («при наших зарплатах мы можем себе позволить платить такие налоги. И, собственно, мы должны поддерживать страну так же, как остальные. Чем мы лучше других»).

Чому ви підтримуєте підвищення податку?

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

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

Розподіл тих, хто вважає, що 10% — це небагато

Збільшення податку посилює бажання поїхати з країни

Збільшення розміру податку для ІТ-спеціалістів може стимулювати їхній від’їзд за кордон. 48% тих, хто не підтримує збільшення податку чи не визначився з позицією (або 37% від усіх опитаних), шукатимуть можливості для переїзду, якщо податок все-таки зросте. 14% тих, хто не підтримує збільшення податку чи не визначився з позицією (або 11% від усіх опитаних), точно переїдуть до іншої країни (серед тих, хто має понад 5 років досвіду в ІТ, таких 13%).

Якщо все ж таки податок збільшиться, ваші дії?

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

Лише 19% тих, хто не підтримує збільшення податку, готові залишитися і платити його за новими ставками. Переважно про це говорили нетехнічні спеціалісти (таких серед них 30%) та ті, хто працює в ІТ менше 1 року (29%).

Ще 17% тих, хто не підтримує збільшення податку чи не визначився з позицією (або 13% від усіх опитаних), підуть в тінь або будуть шукати можливості для оптимізації та зменшення податку. Особливо ця позиція популярна серед топ-менеджерів ІТ-компаній — про це заявили 27% тих, хто не підтримує збільшення податку чи не визначився з позицією (або 18% усіх опитаних топ-менеджерів).

Якщо все ж таки податок збільшиться, ваші дії? (розподіл за посадою та досвідом)

Від редакції

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

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

Підписуйтеся на Telegram-канал «Редакція DOU» — лише декілька постів на тиждень про найважливіше на DOU й в українському ІТ.

Текст і аналітика: Ірина Іпполітова
Візуалізація даних: Ігор Яновський

Привет! Меня зовут Вадим Билецкий. Всю жизнь я любил компьютерные игры и с детства мечтал их создавать. Я считаю их видом искусства, равноценным кино и литературе. Когда я стал студентом факультета кибернетики КНУ имени Тараса Шевченко, я начал программировать и самостоятельно создавать простые демоигры. Полгода назад я успешно прошёл отбор на оплачиваемую стажировку в Ubisoft, а сейчас у меня есть шанс релоцироваться в одну из студий во Франции. Скоро я начну работать непосредственно в одной из игровых студий Ubisoft.

С чего все начиналось

В прошлом году я искал работу и наткнулся на два предложения от Ubisoft.ua. Первая вакансия предлагала полноценную работу в компании, а вторая — оплачиваемую стажировку в Ubisoft Coding Campus. Сначала мне больше нравился первый вариант, но взвесив все «за» и «против», я выбрал кампус, потому что у меня всё-таки было мало опыта. В сфере разработки игр я работал не больше, чем полгода, да и масштабы нельзя сравнивать — это были не ААА-проекты, а какие-то казуальные игрушки на телефоне. Такой опыт мало что мне дал, кроме денег.

Отбор

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

Следующий этап проверял знания C++ и SQL. Вопросы были достаточно базовые, в виде тестов и задач. В целом, если ты программист или учишься в университете по этому направлению, решить эти задачи не составит труда. Для общего представления скажу, что в моей группе в кампусе есть один парень, который тоже учится на кибернетике в КНУ, и он пока только на втором курсе. Так что всё зависит от знаний и желания учиться.

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

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

Стажировка

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

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

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

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

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

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

Рабочий день

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

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

Атмосфера

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

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

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

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

Впечатления от стажировки

Я определённо многому научился. До этого у меня были хорошие базовые знания в сфере computer science, и в принципе они на том уровне и остались, но в большей мере я научился прикладным всяким штукам и техникам. Это был первый раз в моей жизни, когда я писал проект такого масштаба. До этого, за весь свой опыт, я решал только какие-то локальные задачи. И вот, у меня появляется первый большой проект, целая игра! Хоть она и простая, но она была написана мной, и я лично отвечал за качество. Как раз это на меня и повлияло сильнее всего — наличие большой ответственности. Я был вынужден к этому привыкать. Нужно учиться правильно разделять свои ресурсы, планировать решения задач. С такой прикладной точки зрения я действительно много чего освоил и чувствую в себе улучшения.

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

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

Окончание стажировки и релокация

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

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

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

Могу сказать, что мечты сбываются. У меня это ощущение было особенно сильным на первых порах этой стажировки. Сейчас я уже привык, но я помню те чувства в самом начале, когда я только шёл на первое собеседование. Я чувствовал воодушевление от одной мысли о том, куда я сейчас иду и чем я буду там заниматься. Не знаю точно, чем я буду заниматься во Франции, и как я буду там жить. Буду, наверное, учить язык, заниматься саморазвитием, работать. У меня там будет больше свободного времени, потому что сейчас его съедает университет. Тем более во Франции короткая рабочая неделя, всего 35 часов. Я жду того, что попаду на какой-нибудь действительно интересный проект, уже немного надоело делать учебные задания, проходить все эти тренировки, обучения. Хочется уже в настоящий «бой». Мне самому интересно, что там будет происходить.

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

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

За помощь в оформлении материала благодарим Сергея Казаряна.

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

В этой статье пойдет речь о моем личном опыте и ошибках за два с половиной года на позиции Business Development Manager, на которой моей основной задачей является продажа услуг компании потенциальным клиентам. Пожалуйста, не ожидайте, что я расскажу то, о чем пишут в своих книгах такие гуру продаж, как Орен Клафф или Нил Рекхэм. Я хочу поделиться тем, как начать карьеру в этой сфере, предупредить о подводных камнях, показать, чем привлекательна такая профессия.

«Первое плавание»

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

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

Остановимся на каждом из пунктов подробнее.

Поиск наставника

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

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

Приятные манеры

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

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

Страх общения

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

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

Эрудиция

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

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

Внимание к деталям

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

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

Первые крупные сделки

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

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

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

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

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

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

Разнообразие в работе

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

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

Умение слушать и слышать

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

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

Гибкость

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

Выводы

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

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

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

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

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

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

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

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

Игнорирование резюме

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

Задания и задачи

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

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

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

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

Вопросы о мелких деталях

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

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

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

Soft skills

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

Умение учиться

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

Набор ценностей

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

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

Выводы

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

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

Появилась свободная минута на то, чтобы не в последний раз смахнуть пыль со своего резюме и удалить аббревиатуры, расшифровки которых я уже не помню, а вместо них добавить чего-нибудь посовременнее. Что там сейчас в тренде? Data Science, ML, AI? Ну что же, начнем...

Анаконда уже установлена и нежится на рабочем столе в ожидании данных. Титаникмне не интересен, до Чемпионата мираеще далеко, а вот нашумевшая база ФОПов (да-да, та самая с адресами и фамилиями) — в самый раз. Забегая наперед, успокою многоуважаемых, что под катом никаких личных данных.

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

Анализ данных

Для начала разомнемся и выведем количество IT-шников, сгруппировав по статусу ЧП. Предварительно отфильтруем их от остальных ФОПовцев по КВЭД 62-63:

Одной картинки на Data Science инженера маловато будет — нужно кодить. И не просто кодить, а геокодить! Положиться на бесплатные сервисы и загеокодить ~250 000 записей по точному адресу — никаких лимитов не хватит, а заморачиваться с установкой своего инстанса Open Street Map ой как не хотелось. Ищем на просторах интернета и находим базу украинских почтовых адресов с геокоординатами — то что нужно!

17 000+ не замапилось (ожидал, что будет хуже). Не беда — поселим ~10 000 «бездомных» на соседние почтовые индексы, а остальные 7 000 распределим на уровне городов — на общие цифры это не повлияет.

Забываем пока об остановленных (мы к ним еще вернемся) и выведем распределение зарегистрированных IT-шников по регионам:

Останавливаться тут не над чем — тройка лидеров известна каждому джуну. Задачка на мидла — проецируем записи из базы на карту:

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

Фиксим график путем притягивания за уши Machine Learning алгоритмов. В сеньоры не метим и ограничимся одним из самых простых — k-means алгоритмом. Эмпирическим путем выбираем количество кластеров, равное 15-ти. 3 строчкикода на Python — вот и весь ML:

Как видно из картинки, ML разбил позиции всех IT-шников на 15 кластеров. В центре масс каждого кластера расположена точка с радиусом, пропорциональным количеству зарегистрированных особ в данном кластере. Все становится на свои места: в Киеве в два раза больше зарегистрированных, чем в Харькове. Львовяне тем временем не отстают.

В чем сила, брат? В параметрах! Тонкий тюнинг моделей с последующей оценкой ее качества — довольно сложный процесс и больше похож на искусство. В k-means особо тюнить нечего, кроме как количество кластеров, поэтому в преддверии выборов немного поиграемся и установим n_clusters = 2:

Ха! Запад победил! Ну а справедливости ради, если делить по Днепру... Меньше воды, больше графиков. Вспомним о неактивных ЧП и распределим их по регионам:

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

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

Вывод

Пока скрипт экзекьютится, а графики отрисовываются, подведем итоги:
1 статья, 19 комитов, 7 графиков, 80 строк на питоне и +3 строчки в резюме, а выводы делайте сами.

Что дальше

Еще во времена, когда Nokia выпускала своего первого убийцу айфона, а Android делал первые неуверенные шаги, уже тогда наш Screenshot-based доморощенный солюшен использовал Computer Vision техники (видосик для затравочки в конце статьи). Поэтому в следующий раз поговорим о том, как далеко можно послать селекторы и применим Computer Vision и Deep Learning техники для Screenshot-based автоматических тестов.

Привет, меня зовут Артур Селецкий, я Co-Founder / Partner в It Network. Мы с коллегами занимаемся развитием сообщества бизнес-аналитиков и руководителей проектов в Украине. В этой статье я хотел бы поделиться своим опытом и подходом к определению ценностей разрабатываемого ПО и их оценке.

Проблема удовлетворенности разработанным ПО

По среднестатистическим данным исследования Standish Group:

• 29% IT-проектов завершились успехом;
• 52% завершились с превышением бюджета, не в срок или с реализацией меньшего функционала, чем ранее было запланировано;
• 19% IT-проектов закончились провалом.

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

Источник

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

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

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

Концептуальная модель по бизнес-анализу BACCM. Источник

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

Виды ценностей

Для себя я выделяю два вида ценностей:

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

На следующем рисунке приведен пример визуализации ценностей для проекта по внедрению внутреннего корпоративного портала.

Визуализация ценностей корпоративного портала

Определение ценностей

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

• Почему это необходимо разрабатывать?
• Какая польза от этого?

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

Пример цели внедрения корпоративного портала: «Автоматизировать и консолидировать накопление экспертных знаний сотрудников путем создания корпоративной базы знаний».

Ценность:

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

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

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

Соотношения ценностей задач с ценностями проекта

Когда заказчики приходят с новыми требованиями, я всегда определяю, насколько новое требование соотносится с целями и ценностями проекта. Если ценность требования (epic или story) не соотносится с ценностями проектных целей, следует задуматься над вопросами:

• Действительно ли стоит реализовывать это?
• Какую пользу от этого получать пользователи?
• Почему это не соотносится с нашими проектными целями?

Этот рисунок отображает пример соотношения ценности epic с ценностями проекта:

Пример соотношения epic с ценностями проекта

Оценка ценностей

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

1. Определение целей проекта.
2. Определение ценностей по каждой цели проекта.
3. Оценивание ценностей по каждой из цели проекта.
4. Определение приоритетов по достижению целей.

При определении целей я использую два простых правила:

• цель должна основываться на ценностях;
• цель должна быть достижима.

Для определения ценностей, как отмечал я выше, ищем ответы на два вопроса:

• Почему это необходимо разрабатывать?
• Какая польза от этого?

Часто использую подход «покер планирования» из гибких методологий для оценки ценностей. Ранжирование ценностей происходит по так называемых размерах майки: S, M, L, XL, XXL.

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

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

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

Гармонии вам и процветания.

Продолжаем серию «Карьера в IT»: на этот раз поговорим о разработке технологий Blockchain. Об этой предметной области нам рассказали специалисты из компаний BlockSoftLab, Dev-Proи Titanium.

Особенности направления

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

Соответственно, Blockchain-разработчик создает программные приложения, которые будут выполняться узлами, входящими в цепочку блоков. Также он настраивает взаимодействие «классического» программного обеспечения, или DApp (Distributed application), с этими приложениями.

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

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

«Так как Blockchain-разработка имеет очень много ограничений, связанных с природой технологий, нам приходится постоянно объяснять заказчикам, что некоторый функционал не может работать так, как они предполагают» (Алекс Кучер, CTO Titanium).

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

«Работа Blockchain-разработчика отчасти похожа на работу системного программиста. Необходимо „выдавать“ оптимизированный код как по количеству операций, так и по используемому объему памяти. Соответственно, необходимо хорошо изучить, как работает Blockchain „под капотом“, чтобы при оптимизации учитывать не только количество операций, но и особенности их реализации на низком уровне» (Blockchain Developer в BlockSoftLab).

Задачи и обязанности

Главная задача Blockchain-разработчика — разработка цифровых «соглашений» (смарт-контрактов). Условия в них описываются программно, а полученный смарт-контракт располагается в цепочке блоков. Это предотвращает вмешательство в его работу или изменение его содержания. А значит, отвергается и возможность отклонения от правил, заложенных в «соглашении».

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

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

«Кроме непосредственно смарт-контрактов мы также разрабатываем веб-страницы или мобильные приложения, через которые будет происходить взаимодействие с Blockchain. Для этого используем JavaScript, Java и Swift» (Игорь Ермаков, Blockchain Engineer в Dev-Pro).

Типичный рабочий день Blockchain-разработчика проходит по-разному в зависимости от этапа разработки продукта.

«На этапе проектирования большая часть времени у меня уходит на разработку архитектуры, участие в „мозговых штурмах“, определении инструментов и техник разработки, выделении и распределении задач. На этапе разработки 6-7часов в 8-часовомрабочем дне занимает программирование. В оставшееся время я исследую новые технологии, участвую с командой в митингах, посещаю образовательные семинары. Во время тестирования мы создаем юнит-тесты для смарт-контракта и занимаемся мануальным тестированием интерфейса взаимодействия» (Blockchain Developer в BlockSoftLab).

Принцип работы технологии Blockchain (image source)

Преимущества и недостатки

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

«Каждый человек в какой-то момент жизни хочет заниматься чем-то полезным для общества и чувствовать вовлеченность в его развитие. Инструментарий, который можно разработать с помощью технологии Blockchain, способствует созданию гражданского общества и прозрачности власти, в том числе и в Украине, а также прозрачности сделок во взаимодействии людей друг с другом. Причем если в классических сделках некоторые вещи можно трактовать двусмысленно, то в программировании смарт-контрактов такие неоднозначности отсутствуют» (Blockchain Developer в BlockSoftLab).

«Привлекает прозрачность и неизменяемость данных. При открытом исходном коде и полном доступе к серверу, на котором он выполняется, его не взломать. Конечно, при условии, что программист не допустит ошибку» (Игорь Ермаков, Blockchain Engineer в Dev-Pro).

«Блокчейн предполагает собой обещание децентрализованного будущего, где не будет игроков, которые будут контролировать большую часть чего-либо. Эта специализация молодая, но многообещающая. Мне интересно, в какую сторону будет развиваться эта технология и что можно будет оптимизировать и децентрализовать с ее помощью» (Алекс Кучер, CTO Titanium).

Среди недостатков — незрелость технологии и высокая цена ошибки.

«Пока что основной минус — молодость технологий и инструментов. Значительная их часть еще даже не дошла до продакшена и находится в фазах тестирования. Во-первых, это порождает наличие ошибок в архитектурах продуктов. Во-вторых, из-за периодических изменений в инструментах учебный материал или инструкция к какой-то библиотеке часто совсем не соответствует фактическому положению вещей. Это повышает стресс во время разработки и ставит под угрозу сроки выполнения задания.
Также разработка требует постоянного внимания к требованиям ИБ. В случае с Blockchain продукт уже невозможно будет изменить после запуска. А значит, не получится и исправить ошибку или ликвидировать уязвимость патчем» (Blockchain Developer в BlockSoftLab).

«Поскольку технология молода, инструменты, которые используются для ее разработки, еще не полностью отлажены. Поэтому иногда могут возникать проблемы, пути решения которых не очевидны. Также, поскольку не все заказчики понимают лимитированность и специфичность этой технологии, иногда бывает трудно объяснить, почему она работает так или иначе» (Алекс Кучер, CTO Titanium).

«Пожалуй, недостаток заключается в том, что полученные навыки сложно или невозможно применить в других сферах» (Игорь Ермаков, Blockchain Engineer в Dev-Pro).

Как стать Blockchain-разработчиком

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

Разобраться с сутью технологии Blockchain поможет статья «Bitcoin: A Peer-to-Peer Electronic Cash System» by Satoshi Nakamoto, а также работы Nick Szabo: «Advances in Distributed Security»и «Formalizing and Securing Relationships on Public Networks». О «криптовалютной» стороне технологии можно почитать «Cryptocash, cryptocurrencies, and cryptocontracts» by Neal Koblitz and Alfred Menezes.

«Как стать Blockchain-разработчиком? Прежде всего, выберите платформу, под которую интересно разрабатывать (EOS, Ethereum, Neo, Nem). Затем почитайте White Paper, Yellow Paper выбранной платформы, разберитесь, как в ней работают смарт-контракты (для Ethereum, например, разобраться с EVM). Наконец, изучите язык программирования под выбранную платформу (например, для Ethereum — Solidity, для EOS — C++)» (Игорь Ермаков, Blockchain Engineer в Dev-Pro).

«Я советую начать с Solidity — языка программирования для Ethereum. Напишите тестовый проект, который будет содержать код на Blockchain и подключение к нему через какую-нибудь веб-страницу. Что касается источников информации, я советую изучить подборки The Crowdsourced Ethereum Reading Listи Crypto Canon» (Алекс Кучер, CTO Titanium).

«Рекомендую читать техническую документацию той технологии Blockchain, под которую предполагается разработка. Например, для разработки под Bitcoin необходимо изучить документациюи следить за перечнем измененийв технологии. Для разработки под Ethereum есть мощный справочный ресурспо используемому там языку смарт-контрактов. Следить за новинками и учебными материалами помогут группы и каналы в мессенджерах. Я читаю Solidity Clubи Cryptology Club» (Blockchain Developer в BlockSoftLab).

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

Привіт! Мене звуть Федір Симоненко, я co-founder проекту ReSell — маркетплейсу для простої і безпечної купівлі/продажу майже нової електроніки. З його допомогою ви можете оцінити свій старий девайс та продати його без будь-яких ризиків, а також купити майже новий пристрій з гарантією якості. Перед тим як присвятити себе цьому проекту, я встиг попрацювати розробником баз даних, а також займався автоматизацією бізнес-процесів та пошуком і інтеграцією ІТ-рішень у великій FMCG-компанії.

Ідея

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

Після цього і з’явилася ідея створити сервіс, який допоможе вирішити усі питання, пов’язані з оцінкою, можливим ремонтом, технічною перевіркою вживаних пристроїв. Крім того, мені дуже подобалися принципи безпечних покупок на міжнародних майданчиках, таких як AliExpress. Тому я вирішив, що для уникнення шахрайства необхідно звести до мінімуму готівкові розрахунки. Погугливши, я знайшов декілька нішевих маркетплейсів у США, таких як swappa.comі glyde.com. Далі я знайшов партнера, який мав досвід запуску стартапів.

Зліва — директор з маркетингу Максим Байталюк, справа — Федір Симоненко

Реалізація і створення MVP

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

Ми визначили такі критерії для вибору фреймворку:

• швидкість і вартість розробки;
• можливість масштабування і кастомізації проекту;
• кількість розробників на ринку і вартість доробок;
• кількість open source модулів / підтримка спільноти.

Після аналізу існуючих рішень я відразу відкинув шаблонні рішення типу Wordpress, оскільки вони слабо кастомізуються. В результаті я обирав між Ruby-on-Rails і Python-Django. На користь Python зіграла більша кількість розробників і низький поріг для входу нових спеціалістів (а отже, рейти не повинні швидко зростати). Django ж підкупив величезною спільнотою, автоматичною генерацією адмінки, а також ростом популярності останнім часом серед eCommerce-проектів.

Фінальна таблиця для вибору фреймворка виглядала так:

Після цього ми провели низку зустрічей/скайп-колів з компаніями і фрілансерами, які могли б реалізувати MVP-версію. В результаті трохи більше аніж через півроку перша версія продукту являла собою написаний фрілансерами монолітний web-застосунок на Django (Python 2.7) з адаптивною версткою.

Як працює маркетплейс

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

В подальшому реалізували мобільну версію і дещо спростили анкету:

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

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

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

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

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

Цей продукт допоміг протестувати ідею і залучити перші інвестиції на акселераторі Intecracy.Ventures.

Зміна архітектури і реліз

Разом з тим ми розуміли, що без нормальної мобільної версії сайту і гнучкої архітектури проекту ми не зможемо швидко розвиватися. Тому використали Django REST для створення web API з мікросервісною архітектурою і паралельно переписали проект на Python 3.6. Також ми використали Celery для обробки асинхронних задач. Клієнтську частину вирішили писати на React JS + Redux.

База даних: PostgreSQL (вона й була з самого початку). Всі сервіси розгорнуті в Docker-контейнерах, хостимося на DigitalOcean, в якості CI використовуємо Jenkins. Сам проект має структуру SPA з рендерингом на клієнтській частині (CSR). Деякі сторінки (лендінги) ми рендеримо на сервері через Django-templates, а для створення блогу інтегрували сервіс ghost.org.

Після отримання перших інвестицій, ми почали збирати команду для full-time роботи над проектом. Окрім програмістів, для розвитку і підтримки проекту було створено відділ маркетингу і реклами та службу підтримки клієнтів. Цей процес зайняв декілька місяців. В результаті наша команда розробки складається з бізнес-аналітика, UX-UI дизайнера, трьох бекенд-розробників Python, двох фронтенд-розробників React JS і тестувальника.

Команда ReSell

Фейли

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

CSR (client side rendering). Для будь-якого комерційного проекту ключовим завданням є зниження вартості залучення клієнта (CAC), а це можливо тільки за умови постійного зростання органічного трафіку з пошукових систем. Хоча Google і заявляє, що його боти вже давно читають JavaScript і можуть індексувати SPA-сайти, на практиці все проходить не так гладко. Ми були змушені достатньо поморочитися для того, щоб добитися коректної індексації наших ключових сторінок. Була ідея навіть використати Next JS, але відмовилися від неї через брак часу. В результаті нам вдалося прибрати більшість перепон на шляху краулера, але все ще залишається багато завдань з оптимізації.

Результат і плани на майбутнє

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

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

В результаті, майже за 4 місяці активної роботи наш сайт відвідало більше 350 000 унікальних користувачів, зареєструвались в системі близько 6 000 відвідувачів. Усього через майданчик ми отримали близько 1 000 замовлень. А кількість замовлень від наших перевірених продавців зростає в 2 рази кожного місяця, що свідчить про актуальність даної послуги на ринку.

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

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