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

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

Майже рік тому мене запросили на проєкт тімлідом — зібрати команду і очолити фронт-розробку (оскільки останнім часом я спеціалізуюся на React-застосунках).

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

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

Поганий код вбиває. Хто відповідальний за код і його якість

Важливість якісного коду (який ще називають чистим кодом, clean code за Робертом Мартіном, Uncle Bob) часто пояснюють на прикладі жарту про Джона — «серійного програміста». Суть жарту в тому, що коли програміст робить помилку в програмному забезпеченні, то користувачі витрачають час на те, щоб обійти її. І якщо користувачів дуже багато, то навіть кілька зайвих витрачених хвилин у кожного з них у сумі це сотні років. Також поганий код краде час в інших програмістів.

Але хто ж відповідає за якість коду? Роберт Мартін вважає, що лише програмісти. Одним з прикладів відповідальності він називає доволі свіжу історію з компанією Volkswagen. Великий скандал, який стався через маніпуляції з результатами показів викидів вихлопних газів автомобілів, щоб обдурити тестувальні апарати. На суді СТО компанії, коли його запитали, як це могло статися, відповів, що це зробили кілька розробників з якоїсь причини. Звичайно, ця причина нам зрозуміла — менеджмент попросив про це програмістів. Але вони могли відмовитися виконувати таке завдання. Нині ці спеціалісти в тюрмі (як зазначив Роберт Мартін у своєму виступі), а компанія втратила десятки мільярдів євро.

Що таке рефакторинг і навіщо його виконувати

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

Навіщо той код переписувати? «Щоб робити його кращим» — скаже будь-який програміст. Але кращим для кого? Відповідь проста, але часто не зовсім очевидна — для нас, програмістів. Відомий факт, що код набагато частіше читають, аніж пишуть. Читають код зазвичай програмісти.

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

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

Технічні аспекти та принципи оцінювання якості коду

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

Іншою важливою особливістю коду є можливість його розширювати та масштабувати. Наприклад, відомою є проблема, коли клас має багато обов’язків, слабко пов’язаних між собою, що порушує принцип єдиного обов’язку (single responsibility principle). У такому разі краще розділити клас на кілька атомарних елементів.

Деякі аспекти оцінювання якості коду є суперечливими. Тож команда має просто обрати набір стилів та найкращих практик, яких планує дотримуватися. Більшість проблем із якістю ми можемо знайти в коді за допомогою програмного забезпечення, що вже давно існує. Його можна внести в пайплайн CI/CD.

Що таке технічний борг і що з ним робити

Вперше метафору «технічний борг» щодо «брудного» коду запропонував програміст Ворд Каннінг.

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

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

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

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

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

1. Тиск з боку бізнесу.
2. Відсутність розуміння наслідків технічного боргу.
3. Відсутність боротьби з жорсткою обмеженістю компонентів.
4. Відсутність автотестів.
5. Відсутність документації.
6. Відсутність взаємодії між членами команди.
7. Довготривала одночасна розробка в кількох гілках.
8. Відкладений рефакторинг.
9. Відсутність контролю за дотриманням стандартів.
10. Відсутність компетенції.

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

Чи є причини не робити рефакторинг

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

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

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

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

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

Чому б не писати код, який не потрібно рефакторити

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

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

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

Поширена думка, що якісний код потрібен лише програмістам (є навіть окремий термін DX — developer experience, або досвід розробника). Але роботи Роберта Мартіна та мій досвід з легасі-системами показують, що якісний код і чиста архітектура (clean architecture) потрібні насамперед самому бізнесу. В книжці Clean Architecture автор описує проєкт зі свого досвіду, в якому збільшення кількості програмістів практично не підвищило продуктивність роботи відділу, а видатки на розробку значно зросли.

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

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

Знаю, що багато хто не погодиться зі схожою думкою, бо бувають ситуації, коли продукт треба зарелізити якнайшвидше, щоб протестувати бізнес-модель, а потім вже братися за покращення коду. Але для того, щоб перевірити бізнес-модель, застосунок не потрібен, можна написати PoC (Proof of Concept), який потім викинути. І це доволі поширена проблема, коли пишуть PoC і після релізу беруть його за основу продукту (адже воно ж працює і вже є багато коду), але то вже інша історія.

Передумови для успішного рефакторингу

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

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

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

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

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

Чи обов’язково задачі на рефакторинг мають бути в беклозі

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

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

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

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

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

Привет! Меня зовут Евгений Дорфман. В прошлом я Senior AdOps Engineer. Сейчас я ушел в технический менеджмент и работаю на позиции TPM (Technical Project Manager) в компании Postindustria, но продолжаю заниматься подбором и обучением AdOps-инженеров.

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

AdOps (Advertising Operations) Engineer — достаточно редкая позиция как в Украине, так и в мире. Большинство IT-компаний еще не пришли к тому, чтобы выделить эту роль в отдельную специальность. Поэтому чаще всего разные элементы работы AdOps берут на себя инженеры, менеджеры по продукту, бизнес-аналитики, маркетологи и другие специалисты.

Задачи и обязанности

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

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

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

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

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

В ходе работы AdOps-инженер выбирает:

• Источники рекламы. Как правило, это рекламные сети и Supply-side platform, платформы для продажи рекламных мест. На рынки есть сотни вендоров: MoPub Marketplace, Smaato, PubMatic, InMobi, Chartboost, AdColony, OpenX и так далее.
• Механизмы поставки рекламы. Например, для баннерной рекламы можно настроить медиацию с несколькими партнерами. Это означает, что мы интегрируем одновременно нескольких источников на одно рекламное пространство — с последовательным или параллельным перебором их для каждого показа.
• In-app Bidding решение. Это решение для проведения параллельных торгов между несколькими источниками перед каждым показом внутри приложения. Одно из самых популярных — Amazon TAM и Prebid.org.
• Ad Servers. Это сервер, на котором настраивается, как доставлять рекламу в приложение на каждое рекламное пространство.

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

• Google Ad Manager как Ad Server и платформа для медиации. Это максимально гибкий вариант, минусов практически нет.
• MoPub как Ad Server и площадка медиации с подключенным MoPub Advanced Bidding решением. Это удобно, но у такого решения чуть меньше гибкости по сравнению с Google Ad Manager.
• AdMob как платформа для медиации с теми партнерами, которые поддерживаются «из коробки», а также кастомный Bidding. Такая архитектура позволяет провести быструю интеграцию, но дает минимум фич.

Затем AdOps-инженер устанавливает контакт со всеми партнерами, чтобы получить аккаунты издателя на стороне каждого из них. Процедуры могут отличаться: где-то работает self-service registration, а где-то нужно личное интро.

После этого он настраивает инвентарь в аккаунтах партнеров и на Ad Server. Это делается в панелях управления. После настройки на стороне партнера AdOps-инженер должен подключить его к аккаунту на рекламном сервере для рекламного юнита. Для этого он копирует ID партнера и вставляет их в соответствующих полях в панели управления Ad Server.

Следующий этап — интеграция. AdOps-инженер прописывает разработчикам задачи на интеграции мобильных SDK, а также детали интеграции — Ad Unit IDs, Account IDs и тому подобное. А затем размещает итоговые ads.txt / app-ads.txt файлы в корневом домене издателя.

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

После релиза AdOps-инженер обязан отслеживать показатели монетизации (Fill Rate, CPM, CTR, Viewability) и на их основании продумывать дальнейшие шаги для оптимизации: добавить ли источников, инвентарь и так далее.

Особенности направления

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

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

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

KPI-граф и как AdOps на него влияет:

Чтобы улучшить рекламные показатели, AdOps-инженер может использовать типичные приемы из продакт-менеджмента и инструменты для тестирования гипотез. Например, A/B-тесты: тестируем два источника рекламы. На одном и том же рекламном пространстве 50% пользователей видят один источник, 50% — другой. Затем мы сравниваем показатели. Например, первый источник приносит больше денег — значит раскатываем его на всех пользователей. Это простейшая оптимизация.

Как и работа менеджера по продукту, работа AdOps-инженера — это бесконечный цикл develop → release → accumulate feedback → learn → decide → develop. Индустрия и продукт все время меняются, мы постоянно накапливаем знания и адаптируем рекламные механизмы. В этом состоит и основной вызов и драйв работы в AdOps.

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

Зарплаты AdOps-инженеров соизмеримы с зарплатами проектных менеджеров и менеджеров по продукту.

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

Преимущества и недостатки

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

На этой позиции меня привлекает сложность и нетривиальность рыночных структур и возможность решать интересные задачи оптимизации. Собственно, задача всегда одна и та же: как заработать больше денег? К примеру, на одном из проектов мы долго решали, какими источниками наполнить свои рекламные пространства, чтобы Fill Rate был выше 80%. Потом начали решать задачу повышения CPM — отобрать такие источники, которые позволяют максимально повысить этот показатель.

Это бесконечный процесс: мы постоянно экспериментируем с новыми источниками. Например, интегрировали три In-app Bidding решения в одно приложение: Amazon TAM + PubMatic OpenWrap + Prebid. Это обеспечивает конкуренцию между большим количеством источников.

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

Если говорить о недостатках специальности, я могу выделить обилие рутины. Из-за слабой автоматизированности AdOps-инженеры вынуждены выполнять много шаблонных и простых действий вручную. Например, обычный copy-paste: при конфигурировании источников рекламы нужно копировать ID рекламных пространств, которые настроены в конкретных сетях, и вставлять их в свой Ad Server через Web UI. Это ручная работа с высокой ценой ошибки.

Но мы боремся и с этой проблемой рутинности: например, разработали инструмент автоматизациитипичных задач AdOps при настройке Header Bidding ордеров.

Как стать AdOps-инженером

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

Начинать изучение специальности я советую с профессиональных терминов. Хороший глоссарийесть у Google. Затем можно освоить IAB-стандарты.

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

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

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

• софт для аналитики самого продукта (Firebase, Amplitude, Flurry, Indicative, кастомные BI-решения вроде Python ETLs, Time series DBs);
• инсталл-атрибуция, то есть софт, что помогает определить источники, из которых пришли пользователи (AppsFlyer, Kochava);
• инструменты для A/B-тестирования (например, Firebase);
• инструменты для маркетинг-автоматизации (Swrve, Braze, Firebase);
• рекламные серверы (Google Ad Manager, MoPub, AdMob);
• специальный софт для настройки Header Bidding ордеров на рекламных серверах (PubMonkey);
• девелоперские инструменты (Charles Proxy).

Из софт скилов AdOps-инженеру нужно знать английский, а также развивать:

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

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

Статья написанаИгорем Качуройв соавторстве с Андреем Когутом, Александром Колесником, Сергеем Мокиенко.

В статье поговорим о приложении Wix, заглянем «под капот», поделимся опытом инженеров, которые работают в разных командах и над разными продуктами, элементами системы, и расскажем, как это все упаковывается в единый user experience.

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

Гильдии в XXI веке

В Wix есть «вертикали», которые называются компаниями, и «горизонтали» — те самые гильдии. «Компании» объединяют людей по продуктам, над которыми они работают. Например, Payments by Wix, Wix Media, Wix Groups и так далее. В них свои центры принятия решений, менеджмент. Гильдии же объединяют разработчиков по технологиям, с которыми те работают. Например, в Wix, кроме прочих, есть Front-еnd, Back-еnd и Mobile гильдии.

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

OneApp to rule them all

Сегодня в мобильной гильдии Wix более 100 разработчиков. И все мы работаем над одним проектом — Wix OneApp. Такое название дали неспроста: тут мы хотим показать, что делаем одно универсальное приложение для бизнеса, учитывая все потребности. Кто знаком с идеей приложения WeChat, может тут провести параллель.

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

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

Как же все-таки удается организовать работу более 100 инженеров над одним мобильным приложением, да так, чтобы еще делать регулярные апдейты, не иметь merge-конфликтов и вообще получать удовольствие от процесса?

Правила организации труда

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

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

Архитектура

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

Команда каждого проекта имеет возможность добавить к процессу CI свои проверки. Общие для всех Unit-тесты, E2E-тесты.

В сердце всего приложения OneApp главный модуль, который обеспечивает платформу для встраивания новых модулей и коммуникации между ними. Он называется OneApp Engine. А еще он хранит все нативные зависимости. И если мы добавляем в OneApp новую нативную зависимость, то делаем это в одном месте через OneApp Engine. Релиз движка происходит раз в две недели, после чего QA тестируют свои вертикали. Если есть что-то критическое — делаем хотфиксы, если нет — новая версия идет в App Store / Google Play.

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

Вокруг OneApp организована инфраструктура, где более сотни мобильных разработчиков могут работать над одним codebase. Это и команды для разработки инструментария (deployment, build pipeline setup, reusable UI components etc), и бизнес-аналитики, которые проводят огромное количество A/B-тестов (даже цветовая схема кнопки имеет под собой статистически доказанного счастливого пользователя), и Content Writers, которые готовят тексты и контролируют локализацию. Они готовят большие in house open-source решения (Detox, react-native-ui-lib, react-remix, react-native-navigation etc.). Все это сделано для того, чтобы разработчик максимально фокусировался на новых фичах, а не настройке окружения.

Принимаем платежи

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

Ведает всем этим команда Payments. От ввода номера кредитной карты для очередной покупки билетов в WiX Events или оплаты занятий по йоге в WiX Bookings до подключения платежных методов к своему бизнесу. Над этими продуктами трудятся более 70 человек, из которых около половины — разработчики. Пользователи проводят миллиарды долларов через Wix, а поскольку ошибки при таких объемах стоят дорого, мы вынуждены подходить к работе максимально ответственно: используем Unit и end-to-end тесты, непрерывно следим за разнообразными метриками систем и никогда не употребляем алкоголь перед выкатыванием очередных обновлений ;)

Не так давно мы добавили поддержку украинских платежных провайдеров.

На скринах выше — пример того, как выглядит функционал «пейментов» в приложении

Технологии

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

Detox (открытый исходный код) — разработанный в WiX инструмент для end-to-end тестирования React Native приложений. Такие тесты показывают, что не только отдельные функции, но и весь модуль работает правильно. Особенность инструмента в том, что он встраивается в приложение и имеет очередность задач, позволяя нам писать тестовые сценарии в формате «выбери платежный метод, нажми „далее“, убедись, что на экране отображается сообщение об успешном платеже» — никаких дополнительных «подожди 2 секунды, пока загрузится следующий экран».

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

Ambassador (проприетарный) — новый инструмент, разработанный в WiX, который предоставляет удобную абстракцию для общения с микросервисами на бекэнде. Нужно просто установить автоматически сгенерированный npm-пакет, и мы получаем набор сервисов, умеющих делать rest или rpc-запросы. Причем отправляемые и получаемые данные могут быть проверены TypeScript-компилятором.

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

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

Картинки с выставки

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

В рамках мобильного приложения команде приходится уделять особое внимание производительности. Значительная часть бизнес-логики OneApp написана на TypeScript, который работает под управлением React Native. И тут все хорошо, но из-за специфики JavaScript React Native не всегда работает быстро в тех частях приложения, где происходит много общения с нативной платформой. Потому часть модулей мы пишем нативно, используя Swift / Objective C и Java / Kotlin. Модульная структура проекта дает возможность изолировать такой код и использовать в модулях новые нативные технологии.

В команде Media 4 проекта: Video Maker, LiveStream, Video on demand и Media Manager.

• У Video Maker пользователи создают профессиональные проморолики для продвижения своих продуктов в несколько касаний (буквально).
• LiveStream позволяет стримить видео с телефона и добавлять стриминги себе на сайт.
• Благодаря Video on demand пользователи продают / покупают / арендуют видео, имея свои каналы. У владельцев бизнеса есть возможность создавать pricing plans для более гибкой монетизации контента.
• Media Manager отвечает за загрузку, обработку, сжатие и редактирование медиафайлов. Этим продуктом пользуются практически все модули в приложении.

Под капотом

Мобильных разработчиков у нас можно условно поделить на две группы: инфраструктурные и продуктовые. В инфраструктурные входят UILib, react-native-navigation, ребята, которые разрабатывают detox. Продуктовые: Payments by Wix, Wix Groups, Wix Stores и так далее. Media Manager — где-то посередине. С одной стороны, мы даем инфраструктуру почти для всех продуктовых команд. С другой — наш модуль предоставляет пользователям OneApp возможности редактировать, загружать и сохранять фотографии. Благодаря Media Manager’у люди ежемесячно загружают миллионы медиаресурсов, также проект является вторым во всем приложении по CTA.

С самого начала проект Media Manager задумывался как медиагалерея, собственно так он и был реализован. Но со временем пользователям стало мало этого функционала, им хотелось иметь возможность работать с большим количеством типов контента. Так было принято решение двигаться из медиагалереи в сторону файлового менеджера. Мы сразу подумали о скорости разработки нового функционала. Решили перенести часть функционала, отвечающий за галерею, на React Native. В результате за пару месяцев удалось полностью переписать интерфейс Media Manager. Еще эта часть полностью покрыта e2e-тестами (используем detox).

В нативной части проекта на iOS пока что все работает на Objective-C / Swift. На Android — Kotlin. Та часть Media Manager, которая отвечает за коммуникацию с React Native, представляет собой тонкую прослойку TypeScript / JavaScript-кода для JavaScript-разработчиков из других команд. Нативная работа связана с выбором медиафайлов, сетью и редактированием изображений. Это все то, что требует хорошего перформанса. В JS-модуль вынесено публичное API для других модулей.

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

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

Касательно организации проекта: когда мы начинали, использовали только Git Issues. Потом стали расти и перешли на Jira. Со временем решили перестроить процесс и стали использовать Asana. Так что с выбором инструментов для организации работы все очень гибко — берем то, что нравится, и то, что работает.

Планы: перенести часть кодовой базы с Objective-C на Swift. Еще хотим изменить структуру проекта, больше вынести на уровень RN.

Социальная составляющая

А еще у нас есть талисман. Его зовут Чендлер :)

Пара слов про технологии, которые инженеры Wix Groups любят особенно:

• Draft.js — помогает пользователям создавать посты с динамической версткой и поддерживает много функций — от изменения шрифтов до добавления опросника в середине поста.
• Petri (feature toggles) — благодаря этому команда несколько раз в неделю может выкатывать новые фичи и контролировать к ним доступ, что сокращает QA-цикл, при этом можно не волноваться, что в результате критического бага нужно будет несколько дней раскатывать новую версию. Feature toggles позволяют открывать фичи на небольшое количество пользователей и все выключать и возвращать на доработку, если вдруг результат не устраивает.
• Rehab (integration testing) — мы разработали собственный подход к интеграционному тестированию внутри модуля, можно тестировать весь путь кода от нажатия кнопки до вызова сети или отправки аналитического события без использования реального мобильного устройства.

20% времени на саморазвитие

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

Например, мы делаем эксперименты с Machine Learning для распознавания картинок, которые, возможно, скоро станут частью основного приложения. Несколько проектов были направлены на создание прототипов на Flutter, Kotlin / Native, Svelte Native, на создание инфраструктурных решений, которые улучшают Dev Experience других команд. Плюс поощряется работа над open-source проектами.

Кстати, про Open Source Software (OSS). Начиная работать с React Native и ставя перед собой амбициозные цели, мы столкнулись с ограничениями платформы React Native и недостатком библиотек для разработки. Решили это исправить сами и начали инвестировать время, выделяемое на саморазвитие, на OSS. Один из результатов — уже упомянутая библиотека Detox, ставшая № 1 в своей нише E2E-тестирования. Библиотека React Native Navigation, которая наряду c React Navigationявляется лидером в навигационных библиотеках. Стоит отметить наш OSS UI Kit, который используем для основного приложения Wix. Туда мы добавили прослойку стилей и цветовых решений. На сегодня у нас около 50 OSS библиотек.

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

Вместо послесловия

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

Меня зовут Филипп Кандыба, я Middle Automation QA Engineer в одном из проектов компании Genesis — Jiji. Это маркетплейс, представленный в виде сайта, мобильной, десктопной версий и приложений для iOS и Android.

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

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

Особенности работы приложений в Африке

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

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

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

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

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

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

Первый уровень: unit-тесты

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

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

Второй уровень: интеграционные тесты

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

Третий уровень: тесты пользовательского функционала

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

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

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

Как я упоминал выше, в основе тестирования нашего проекта лежат unit-тесты. Их довольно много — порядка 8000. Однако количество никогда не свидетельствует о качестве. Нельзя сказать, что на проекте используется метод разработки через тестирование (TDD), однако вся функциональность — как существующая, так и новая — покрыта тестами. Почти каждый pull-запрос так или иначе содержит в себе изменения файлов с тестами.

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

UI-тестирование

На самом же верху нашей пирамиды, как и положено, находятся UI-тесты. Этот уровень тестирования закрывает QA-команда. Сейчас у нас написаны и постоянно запускаются 1500 UI-тестов — это тесты только для веб-приложения. Все они используют Selenium и написаны на Python.

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

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

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

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

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

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

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

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

Нужно ли на проекте мануальное тестирование

До недавнего времени в Jiji не было мануального тестирования. Так сложилось исторически: все QA было на плечах самих разработчиков и QA Automation-инженера. Спустя время нам таки пришлось нанять мануального тестировщика. Объем выпускаемых фич настолько большой, что без него невозможно даже произвести приемочное тестирование, не говоря уже о более вдумчивой и комплексной проверке нового функционала.

Так как Jiji — не только веб-, но и мобильное приложение, то еще этот отдельный продукт нужно проверять. Наш подход к тестированию Android и iOS-приложений стандартный: мы используем Appium, а все тесты пишутся так же, как и для веба — на Python. На данный момент для обоих приложений созданы автоматизированные тесты для основного функционала.

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

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

Нас интересует не только тестирование UI и модулей. Мы стараемся автоматизировать все, что возможно, для обеспечения безопасности приложений. Чтобы понять, с чего начать, не нужно быть хакером — достаточно воспользоваться открытыми источниками. Например, обратится к OWASP Top 10.

Мы тестируем безопасность путем автоматизированной проверки зависимостей, которые используются на проекте. Есть уйма инструментов, которые уберегут вас от их вреда: safety для Python и обычный npm check для JS.

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

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

Что в результате

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

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

Привет! Меня зовут Алексей Миллер, я исполнительный директор DataArt: занимаюсь стратегией, финансами и много общаюсь с клиентами, правда, теперь в основном дистанционно. С 2002 года живу в Нью-Йорке.

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

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

Иллюстрация Алины Самолюк

Опустеют ли офисы на Манхэттене

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

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

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

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

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

Кто открыл для себя удаленку

Концепцию удаленной работы с инженерами, администраторами, аналитиками многие из наших потенциальных заказчиков открыли для себя еще в 1980-е.Кто-то познакомился с ней в 1990-х,но каждые 5–10лет новый пласт клиентов и всевозможного корпоративного начальства обнаруживал, что это вариант может быть эффективным и комфортным. К 2019-мубольшая часть мира идею приняла, хотя оставался класс отщепенцев, не готовых отдавать работу на удаленку по идеологическим причинам.

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

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

Среди бизнесов, с которыми мы работаем или могли бы работать, таких было явное меньшинство. Но вынужденный перевод собственных сотрудников из офисов домой разрушил психологический барьер: сопротивление последних противников удаленной работы оказалось сломлено. Исключения теперь станут совсем уж редкостью. И, хотя драматического эффекта не будет, рынок в один момент увеличился, по моим ощущениям, на 10–15 %.Может быть, даже 20 %.

Стоит ли платить аутсорсерам

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

Компании вроде DataArt исторически приносили пользу, обеспечивая клиентам связь с техническими специалистами. Просто какой-нибудь американской компании было неловко ходить по Крещатику с фонарем, выкрикивая: «Ищу инженера!». Это было далеко, некогда, неловко и, в теории, чревато проблемами, например, с местными властями. Сейчас все стало гораздо проще, потому конкуренция на рынке аутсорсинга так выросла.

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

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

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

Зачем все-таки нужны офисы

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

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

Не слишком ли много систем и решений

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

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

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

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

Можно ли сохранить секреты внутренних систем

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

Поэтому формулу «для внешнего мира — как надо, для себя — абы как» придется пересмотреть. Это отразится и на нас, ведь мы нередко создаем внутренние системы для компаний-клиентов. Обычно считается, что в этом случае можно меньше беспокоиться о безопасности (все свои) и user experience (на работе людям придется пользоваться тем, что выдали). Если пользователей не больше сотни, можно и насчет правильной архитектуры на слишком заморачиваться, все равно больших нагрузок не ожидается.

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

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

Узнаем ли мы друг друга при встрече

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

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

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

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

Думаю, пандемия, карантинные ограничения, переход на удаленку не изменили глобальных трендов. Только ускорили или замедлили некоторые из них. Я склонен считать, что человечество вообще не так сильно испугалось самого COVID-19. Трагедий много, но само ощущение того, что шансы выздороветь, даже если ты заболел, в целом неплохие, скорее успокаивает. Может, даже слишком. Однако благодаря неопределенности повседневной жизни (не закроют ли школы? Не отменят ли рейсы? Не придется ли оставаться дома весь следующий месяц?) общий объем стресса чрезвычайно возрос. Мегаполисы и рынок продолжат расти, офисы не опустеют, а всего лишь станут менее людными, даже качество задач, которые придется решать, скорее всего, будет выше. Но главное на фоне выхода из кризиса не забывать друг о друге. И задуматься о глобальных проблемах иногда тоже не будет лишним.

Мене звати Олександра Дзигал. Я вибудовую та розвиваю комунікацію брендів і продуктів. Наразі відповідаю за якісний контент продукту AdSaver в українській холдинговій IT-компанії SvitSoft.

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

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

Вам буде цікаво, якщо ви:

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

Почнімо з особистого бренду розробника: навіщо

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

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

Заздалегідь наголосимо: не всі такі. У багатьох розробників є план розвитку, який передбачає постійне удосконалення soft skills. Наразі це не просто мода, а необхідність. Якщо не володіти м’якими навичками, можна втратити багато шансів та бонусів, як-от омріяну позицію чи підвищення, можливість співпрацювати з певним клієнтом. Через брак вмінь пояснити щось, презентувати себе і свою компанію є ризик легко вилетіти з гри. Добре, якщо лише на деякий час, а не назавжди через власну впертість. Життя — це гра, яка потребує багатьох зусиль. Як то кажуть, не граєш ти — грають тебе!

Як працює особистий бренд IT-спеціаліста

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

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

Три причини, щоб створити власний бренд

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

2. Багато хто звертається за експертною порадою / оцінкою, що дає можливість підтвердити свою експертизу, розвинути пул можливостей, сформувати власну спільноту однодумців.

3. Фундамент для побудови власного бізнесу.

Особистий бренд в IT: ЦА та цілі

Перше, що важливо зробити для побудови особистого професійного бренду — визначитися, скільки часу цьому потрібно приділяти. Загальна формула свідчить, що 5–10%буде достатньо для поступового та впевненого розвитку. Однак треба розуміти: що більша інвестиція, то більший та швидший прибуток.

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

Канали: комунікація без надриву

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

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

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

1. «22 способи знайти інформацію про цільову аудиторію»;
2. «Цільова аудиторія: навіщо знати свого клієнта»;
3. «Топ інструментів для роботи в соцмережах, із текстами та зображеннями»;
4. «Керівництво по складанню контент-плану для блогу і соцмереж»;
5. «7 трендів копірайтингу в 2021 році»;
6. «Формування особистого бренду експерта: що заважає створювати контент?».

Кейси: Girl In Tech Олена Киричок, Оксана з Магадану та блондинки, які пишуть код

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

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

Хорошим прикладом розвитку особистого бренду «за взаємністю» можна назвати Telegram-блог PHP-розробниці, українки, яка мешкає у Празі — Олени Киричок. Її канал має привабливу назву GIRL IN TECH. Тут вона пише про свій досвід роботи, порушує актуальні теми, ділиться різними можливостями для студентів-початківців та тих, хто хоче розпочати свій шлях в IT.

Про розробниць можна послухати також на YouTube-каналі Coding Blondе. Веде канал Марія. Вона мешкала певний час в Англії та стажувалася в Google. Нині живе та працює в Америці. У Марії є добірка відео Women in Tech, де вона спростовує стереотипи про сферу, бере інтерв’ю на різні теми у програмісток. Маша розвиває не лише відеоформат, а й веде повноцінний блог на сайтіта в соціальних мережах Instagram, Facebook, LinkedIn.

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

Написання статей: інсайти

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

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

1. Починаємо з найменшого речення.
2. Продовжуємо думку, проговоривши її про себе. Пішло?
3. Пишемо і пишемо, не думаючи про правильність.
4. Відкладаємо написане.
5. Перечитуємо наступного дня і доповнюємо.
6. Знову забуваємо на деякий час про текст.

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

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

Типові помилки:

1. Робити великий контент-план публікацій, не спробувавши хоч щось написати.
2. Наймати когось, хто писав би замість вас.

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

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

На завершення

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

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

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

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

Про базовий № 4303-д

Найперше розберімось у законодавчій базі Дія City. Зазначу, що на сьогодні її формують два зареєстрованих у ВР документи: законопроєкти № 4303-д «Про стимулювання розвитку цифрової економіки в Україні» та № 5376 «Про внесення змін до Податкового кодексу України щодо стимулювання розвитку цифрової економіки в Україні».

Решта законопроєктів застарілі: альтернативні № 4303-1 та № 4303-2 комітет ВРУ з питань цифрової трансформації відхилив, № 4303 — повернули на доопрацювання. Тож висмикувати з інших документів окремі норми та подавати їх як положення Дія City щонайменше некоректно.

Крім цього, мережею активно ширяться чутки, начебто не всі учасники ІТ-ринку зможуть стати резидентами Дія City. Насправді ж у законопроєкті № 4303-д чітко визначено критерії вступу як для компаній, що вже функціонують, так і для стартапів. Водночас вимоги до середньої місячної винагороди чи заробітної плати спеціаліста, який працює у компанії-резиденті (не менш як 1,2 тис. євро), і кількості ІТ-спеціалістів (понад 9 осіб) не стосуються стартапів на етапі входу до проєкту. «Шлюпки», «галери», «байдарки», як їх дехто називає, — усі зможуть увійти в Дія City, якщо відповідатимуть встановленим для кожного з них критеріям.

Критерії для стартапів:

• здійснення видів діяльності, визначених законодавством про Дія City;
• 90% доходів — від здійснення цих видів діяльності;
• зареєстровані не раніше ніж за 24 місяці до дня подання заявки;
• річний дохід не більше як 7 млн грн;
• відсутність «негативних» критеріїв (компанії-нерезиденти України; частка держави в компанії 25% і більше; неприбуткові організації’ нерозкриті власники в ЄДР; частка держави-агресора в компанії; компанія, визнана банкрутом або під санкціями тощо).

Критерії для компаній, що вже активно працюють на ринку:

• здійснення визначених законодавством про Дія City видів діяльності;
• 90% доходів — від здійснення цих видів діяльності;
• середня зарплата або винагорода GIG-спеціалістів — не менше ніж €1200;
• 9+ працівників та/або GIG-спеціалістів;
• відсутність «негативних» критеріїв.

Також хочу прояснити ситуацію з гіг-спеціалістами. Заяви про те, що законопроєкт не визначає їхній правовий статус, не відповідають дійсності. Проєкт закону № 4303-д чітко говорить: гіг-контракт є цивільно-правовим договором. Також некоректно називати гіг-працівників підприємцями, оскільки це суперечить ч. 7 ст. 15 законопроєкту № 4303-д і вони не є платниками ПДВ.

Податковий № 5376

14 квітня 2021 року у Верховній Раді був зареєстрований законопроєкт № 5376 «Про внесення змін до Податкового кодексу України щодо стимулювання розвитку цифрової економіки в Україні». Саме цей документ встановлює податкові умови Дія City. Рекомендую колегам надалі, коментуючи податкову складову спецрежиму, керуватися саме цим документом, аби не вводити в оману читачів.

Отже, податковим законопроєктом як для працівників, так і для гіг-спеціалістів буде встановлено такі ставки податків: 5% ПДФО, 22% ЄСВ від мінімальної зарплати та 1,5% військовий збір.

Ще один важливий момент — сплата корпоративних податків. Резидент матиме право обирати між податком на виведений капітал у розмірі 9% і податком на прибуток (18%). У разі ухвалення рішення про перехід на ПнВК резидент має подати окрему заяву до Державної податкової служби.

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

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

Примітно, що консолідовану думку щодо податкових умов, викладених у законопроєкті № 5376, висловив ІТ-бізнес. Заяваз підтримкою податкових ставок Дія City з’явилася 27 травня на сайті Європейської бізнес-асоціації. Як зазначено у заяві, до правильного балансу для стимулювання вітчизняного ІТ-сектору бізнес разом із самими законотворцями дійшли через низку роз’яснень і дискусій. Так, зазвичай найбільше недовіри до нового законодавства спричиняє необізнаність, часто підживлена маніпулятивними трактуваннями політиків, а не фахівців з права. Тож я вважаю, найкращим способом позбутися упереджень щодо законодавчих ініціатив є багатостороннє обговорення змін, які вони з собою несуть. Сподіваюся, мій аналіз законопроєктів про Дія City посприяє конструктивнішій дискусії навколо проєкту.

3 мая 2021 года — мой первый рабочий день в People.ai. Я подготовился к интервью менее чем за месяц и успешно его прошел. Это мой рекорд, и все благодаря новому подходу. Раньше подготовка к таким мероприятиям занимала до трех месяцев, со стрессами и полной изоляцией от всех. Этот раз был «по любви», но пришлось заплатить 880$.

Меня зовут Саша. Я пишу код с 1998 года, а работать программистом начал в 2007-м,сразу после окончания КПИ. С 2014 года живу в США. До 2021-гоя был уверен, что интервью по алгоритмам — это самый геморройный вариант подготовки. Как оказалось, я просто «не умел его готовить».

В январе 2021 года я получил задание по одному из моих предметов MBA — провести networking-интервью с человеком из моей вертикали (разработка ПО), который на 3–5ступеней выше. Надо было узнать, в чем состоит его работа, с какими трудностями специалист сталкивается ежедневно, на что обращает внимание при найме людей, и получить советы по карьерному развитию. Я нашел пять человек в LinkedIn, написал им, и с четырьмя удалось провести интервью. Среди них был CTO People.ai — Андрей Аксельрод.

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

Состояние на январь 2021

1. Стабильная работа в Indeed.
2. Приближается срок вестинга внутренних опционов, 3 года.
3. Премии + бонусы + Unlimited PTO.
4. Дома все в порядке — жена и двое детей.
5. МBA образование — вечернее.
6. Спорт.
7. Друзья.

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

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

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

Забегая вперед, скажу, что уже на пятый день после встречи я понял, что буду работать в People.ai. Вопрос оставался за малым — пройти собеседования и получить офер. И я это сделал за 4 недели и 880$.

Шаг 1. Разведка

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

Узнать правду. В данном случае нужно было удостовериться, все ли так радужно, как я услышал и понял для себя. Для этого я воспользовался Google и LinkedIn. В Google я нашел события за май 2020-го,когда компания уволила часть сотрудников, и это меня немного насторожило, поэтому поиски стали усерднее. Я подключил LinkedIn Pro и написал тем, кто работал в People.ai прежде. Найти их достаточно просто, на платформе есть опция показать людей, которые раньше работали в конкретной компании. Из 11 человек ответили 7. Были разные мнения, но большинство бывших сотрудников сходились на том, что проект интересный, команда крутая и нужно серьезно и много впахивать. Это меня вполне устраивало.

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

Подтвердить факты. Всегда интересно знать, как отличается представление о компании у действующих лояльных сотрудников и тех, которые ушли. Я спросил Андрея о возможности поговорить с людьми из компании и получил утвердительный ответ. Мне удалось это сделать с тремя инженерами и одним Sales Manager. Противоречий не обнаружено: «Задач больше, чем людей, клиенты нас любят, от конкурентов есть защита, есть проблемы, но мы о них знаем и скоро решим». Удивило то, что все были на одной волне и точно знали, как и куда идет компания.

Шаг 2. План действий

Как проходит интервью, как тебя будут оценивать и на чем нужно сконцентрироваться.

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

Основа любой стратегии:

• узнать начальное положение (А);
• понять цель (В);
• понять, как из А попасть в В.

От Андрея я узнал, как проходит собеседование в People.ai. Также пересмотрел все предыдущие интервью Андрея и Олега (CEO). Особенно помогло интервьюОлега на Big Money, где он подробно описал процесс того, как компания нанимает людей и почему это происходит именно так (книга Who, 13,85$).

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

Шаг 3. Подготовка и фидбэк

Чем больше интервью ты прошел — тем увереннее себя чувствуешь.

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

1. Алгоритмы и структуры данных.
2. Архитектура и дизайн программных систем.
3. Проект из прошлого.
4. Карьерный путь.
5. Интервью с рекрутером.

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

Алгоритмы и структуры данных + System Design. Оба пункта мне были знакомы, но назрело два ключевых вопроса:

1. Какой уровень у меня сейчас?
2. Как быстро достичь желаемого уровня?

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

Я нашел идеальный вариант — interviewing.io.

Платишь — и тебе проводят интервью из FAANG и дают развернутый фидбэк, из которого действительно можно сделать хорошие выводы и оценить себя. Интервьюеры и наставники interviewing.io работали в Facebook, Microsoft, Google, Uber, Twitch, Amazon, Netflix, DropBox и других всемирно известных компаниях.

При покупке мелким оптом — скидка, и это был мой вариант. В сумме я отдал 745$ за полученный опыт. Каждое интервью обходилось мне от 100$ до 225$. Большой плюс этой платформы в том, что ты получаешь отличный фидбэк и советы по улучшению своих навыков. Также интервью с компаниями там можно проходить анонимно.

Моя стратегия была следующей: раз в неделю интервью на тему «Алгоритмы и System Design», после которого я получаю подробных отзыв, и четыре раза в неделю проходить анонимные собеседования.

Вот парочка фидбэков на мои интервью:

Algorithms. Дополнительно при подготовке я обращался к следующим способам и источникам:

1. Cracking the Coding Interview (24$).
2. Leetcode premium (35$/месяц) — минимум 4 задачи в день.
3. Распечатка задач.

Отличный вариант — решать самые популярные задачи, начиная с уровня easy и постепенно повышаться до уровня medium.

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

труднее. Если на собеседовании уровень hard, то либо у компании серьезные проблемы с процессом, либо нужны люди под специальную задачу с безупречным знанием алгоритмов. За два дня я разогрелся на easy, получил заряд уверенности и повысился до medium.

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

System Design. Дополнительные ресурсы:

1. Книга System Design Interview (24,99$).
2. Курс по System Design (39,99$).

Два года назад я проходил курс по System Design и сделал mind map по этой теме. Сейчас мне это помогло быстро восстановить в памяти ключевые моменты. А с System Design вообще повезло: на первом mock-интервью мне показали отличный алгоритм прохождения, на втором я его применил для задачи Ticket Master, и интервьюер был в восторге! Задача Ticket Master мне попалась и в People.ai, результаты вы уже знаете.

Past projects. Расскажите об интересном проекте из прошлого. К счастью, у меня с этим проблем нет. За 15 лет накопилось столько кейсов, что можно часами про них рассказывать. Я подготовил два проекта, в которых было много челленджей и интересный объем данных. Для подготовки советую посмотреть метод STAR и заранее разложить свои проекты по нему.

Метод STAR — это структурированная схема для проведения собеседования. Она включает в себя поведенческие вопросы и ответы на них по следующему шаблону:

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

Задача. К какой цели вы стремились?

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

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

Я отлично решил задачу, но не ту, что надо.

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

Собеседование

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

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

Итоги

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

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

Попит на Ruby-розробників за останні роки зріс, але на ринку їх чомусь не густо. Це результати хайпу ~2010-го, коли фреймворк Ruby on Rails став модний, та антихайпу ~2015-го, коли відбувся відплив інженерів у Node.js, React, Python, Elixir та інші суміжні вебтехнології. Та попри це проєкти на Rails нікуди не зникли. Ба більше, спостерігаємо ренесанс цієї технології для фулстек-розробки. За роки роботи вже сформовані найкращі практики, написано багато книг і безліч статей, що допоможуть початківцю впевненіше почуватися. Але сьогодні бракує не в початківців, а саме досвідчених інженерів. То де ж їх брати?

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

Розберімось.

Як стати рубістом з Pivorak

П’ять років тому ентузіасти спільноти Pivorak запустили курси для Ruby-розробників — Pivorak Ruby Summer Course. В їхню основу лягла ідея менторства та самонавчання. Курс триває всього два місяці. Місяць інтенсивної теорії та місяць практики з досвідченим ментором над справжнім проєктом. За 4 сезони нам вдалось випустити у світ добру сотню рубістів-початківців. Ключовим успіхом курсів є високий рівень працевлаштування після їх завершення завдяки підтримці партнерів. Багато з випускників виросли в досвідчених інженерів, та дехто так і не наважився на крок у професію і зійшов з дистанції. Та чимало тих, хто за 1–2роки губиться у світі Ruby та надто уповільнюється у зростанні.

Чому, маючи уже декілька років професійного досвіду на проєктах в продакшені, спеціалісти все ще плавають в основах Ruby та не можуть сформувати власне бачення професійного розвитку? Як так стається, що одна людина після першого року знає та використовує SOLID і патерни, а інша за 10 років так і не подужала нічого складнішого за «сервАйс» об’єкти, вважає, що бізнес-логіка в моделі та колбеки — це норм, і нічого не чула про Faraday?

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

Валідація гіпотези

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

Інформаційні джерела

З цим усе складно. Як правило, на запитання «Де читаєш про новинки в рубі» у відповідь мовчання або щось типу: «Гуглю за потреби». Гуглити — це корисна навичка, але не така уже й ефективна. У момент вирішення проблеми варто мати 2–3 варіанти,щоб вибрати оптимальний, а для цього найкраще підходять кейси з прочитаних книг і статей. Тому так, доведеться читати. Коли чую на інтерв’ю від початківців щось на зразок: «Книги це довго та нудно», хочеться пустити сльозу. Людство ще нічого кращого для навчання, ніж читання, не придумало. Ви ж чомусь зараз читаєте цей текст. Читання — це довгий і медитативний процес, під час якого не треба запам’ятовувати все слово в слово. Варто вибрати важливе та сформувати власну думку. Ось і все. Терпеливість і праця.

Мій вибір для читання:

• Щотижневий дайджест RubyWeekly — найкращий спосіб завжди бути в курсі новинок, скандалів і всього найцікавішого зі світу Ruby.
• Правда життя в тому, що не у всіх fluent English, тому Олексій Васільєв веде чудовий RWPod-подкаст російською мовою. Цінним для новачків буде якісний аналіз новин світу Ruby та Web від Олексія. Не просто «що», але й «чому»
• Twitter — місце, де все швидше з’являється, ніж на RubyWeekly, але й обсяг значно більший. Знайдіть усе можливе щодо Ruby, Rails, Hanami та просто будьте в темі. З часом ви навчитесь бачити, що саме варте уваги.
• ruby.libhunt — мій компас щодо актуальності бібліотек. Завжди його використовую, коли постає питання «а що ж взяти, щоб самому то не кодити».

Основи Ruby

У своїй основі Ruby проста мова. Головних будівельних блоків не так уже й багато. Все є об’єктом, і на всіх об’єктах можна викликати метод object_id чи public_methods та побачити усе на власні очі. Об’єкти належать до класів, а вони між собою наслідуються. Модулі потрібні для неймспейсів або міксинів. Примітивні типи даних, такі як Numeric, String, Hash та Array дуже потужні, але варто також звернути уваги на Struct, OpenStruct, Set, Queue та інші. З коробки є надто багато всього. Не все варто використовувати, але знати корисно.

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

Рекомендована література:

• The Well-Grounded Rubyist, Third Edition (David A. Black, Joseph Leo III) — поки нічого кращого для початківців не бачив.
• Ruby programming language (David Flanagan, Yukihiro Matsumoto) — це була моя перша книга з Ruby. Вже старенька, але все ще добре передає ідею ruby-way.

ООП

Чи треба знати ООП для мови, де все є об’єктом, — питання риторичне. Об’єктноорієнтований дизайн нам потрібен для зрозумілого опису бізнес-процесів програми. Код ми пишемо для людей, а не для машин, тому і власні велосипеди вигадувати не варто. Індустрія вже придумала все за нас. Залишилось тільки ознайомитись та взяти на озброєння. Варто не просто знати SOLID, а й активно ним користуватись.

Ось вам чудова добіркапатернів з прикладами на Ruby від мого колеги Богдана.

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

• Practical Object-Oriented Design, An Agile Primer Using Ruby (Sandi Metz) — цікаве ООП дизайну на прикладі компанії для прокатів велосипедів. Рубісти вважають це класикою.
• 99 Bottles of OOP (Sandi Metz, Katrina Owen, & TJ Stankus) — на продовження теми філософії ООП дизайну.

Метапрограмування

Магії не існує. Це просто код, котрий написали не ви. Метапрограмування — це спосіб написання коду, котрий генерує інший код. Це темна сторона сили, і про неї варто знати, а от чи користуватись — це вже інше питання. Для побудови DSL я застосовую class_eval, instance_eval, define_method, send та public_send. Корисно розуміти, як воно працює. На цю тему можу порадити книжку Metaprogramming Ruby 2 (Paolo Perrotta).

З відеоматеріалів рекомендую лекціюмого колеги Володимира Биньо з першого сезону курсів Pivorak.

Тестування

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

RSpec є стандартом у світі комерційної Ruby-розробки, тому варто розібратися, що тестувати і як:

• Effective Testing with RSpec 3 (Myron Marston and Ian Dees);
• Everyday Rails Testing with RSpec (Aaron Sumner).

Ruby on Rails

Як я вже писав, магії не існує. Це просто код, котрий написали не ви, а конкретно ось ці люди. Насамперед варто знати складники Rails: ActionPack, ActiveRecord, ActiveModel, ActionView та інші. Сам фреймворк модульний, і завжди можна щось прибрати, а щось додати. В Rails багато можливостей, але не всім варто користуватись. Бізнес-логіка в контролерах і моделях — це одразу «ні», а все решта прийде з досвідом. Моєю першою книжкою була Agile Web Development with Rails (Sam Ruby and David Bryant Copeland), але ще версії 3.0, а от стисло та доступно викладено у Rails Crash Course: A No-Nonsense Guide to Rails Development (Anthony Lewis).

Звісно, Rails — це фреймворк для створення вебзастосунків, і тут без фішок не обійтись. Свого часу я передивився всі RailsCastsвід легендарного Ryan Bates, а зі свіженького раджу GoRailsвід Chris Oliver.

Не можу не згадати Crafting Rails 4 Applications (José Valim), і нехай вас не лякає цифра «4» в назві. Те, що Жозе описав у тій книзі, свого часу змінило моє ставлення до розробки вебзастосунків з Rails. Книга досі залишається актуальною.

У продовження теми раджу ознайомитись з Modular Rails (Thibault Denizet). Ця книга відкриває зовсім інший світ архітектури Rails-аплікацій. Упевнений, гурмани оцінять.

Якщо проєкт, на який ви потрапили, вже «пахне», ознайомтесь з Fearless refactoring railsвід колеги з Вроцлава Andrzej Krzywda.

Що далі

Практика. Багато практики. Програмування не в голові, а на пальцях рук. В голові варто тримати тільки думки про те, як ефективно розв’язати проблему.

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

Технічні аспекти веброзробки практично не мають меж. І важливо бути в курсі новинок. У світі Ruby існує багато цікавого, крім Rails: Hanami, Grape, Sinatra, DryRb, Trailblazer.

Я вірю, що неможливо бути хорошим рубістом, якщо знаєш тільки рубі. Є інші класні мови програмування та фреймворки, звідки можна багато чого почерпнути. Нові техніки та парадигми тільки розширюють потенціал для генерації ефективних рішень у Ruby. Тепер ви вже знаєте одну мову, тому вивчити наступну буде значно простіше. Свого часу для мене такими стали Elixir та Phoenix Framework. Практика з цими технологіями зробила мене кращим рубістом, а рубі дало змогу знизити поріг входження в Elixir. Тут можу порадити класну книгу Phoenix for Rails developers (Elvio Vicosa).

Підсумок

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

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

Ну й підписуйтесь на мій телеграм-канал ;)

Меня зовут Саша Емельянов, я Chief Product Officer в health-tech компании bioniq ($15M series A).

Свой путь в продакт-менеджменте я начал с собственного стартапа, затем работал в разных украинских продуктовых компаниях. Последняя из них MacPaw, где я был менеджером по продукту и вместе с командой создал приложение Gemini Photos. В 2018 году получил офер от дейтингового сервиса Badoo, который подразумевал релокейт в Лондон, где живу по сей день, работая уже в bioniq.

В моем опыте менеджмента разных продуктов были многочисленные User Research, поэтому в этой статье я решил дать развернутый ответ на вопрос: «Исследование пользователей — действительно ли нужно?». Спойлер: да.

Тема User Research — совсем не новая, но, как мне кажется, очень недооцененная, особенно в украинском продуктовом менеджменте. У нас исследования пользователей обычно считают прерогативой крупных компаний. А когда я работал в Badoo в Лондоне, у нас была отдельная команда User Research, которая постоянно пыталась валидировать новые гипотезы и лучше понимать пользователей через разные техники. Это было поставлено на поток.

Физические интервью с пользователями Bumble в лондонском офисе компании

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

Обычно компании, которые игнорируют User Research, работают примерно по такой схеме: «Давайте будем делать продукт А для аудитории В и закрывать потребность С». Это в целом нормальный визионерский подход, но потом может оказаться, что продукт А не подходит аудитории В, потому что у нее потребность совсем не С. В таком случае бюджет компании будет потрачен фактически в пустую, а работу придется начать с начала. Чтобы этого избежать, стоит сделать шаг навстречу User Research.

Почему нельзя обойтись без User Research

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

Как провести User Research без оверхедов

Шаг первый

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

Один из видов опросов, который мы с командой используем, — это Product/Market Fit Survey (темплейт). Эта техника помогает определить положение продукта на рынке, оценить, решает ли он проблемы потребителей и довольны ли они этим продуктом.

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

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

Простота применения опроса в том, что его можно создать за полчаса в Typeform или Google Forms. Задав правильный сет вопросов, быстро получите качественную информацию для первичного понимания ситуации.

Шаг второй

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

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

Работая Chief Product Officer в продуктовом стартапе bioniq, я регулярно общаюсь с пользователями. Компания работает в сфере health-tech, занимается мониторингом здоровья и персонализированными витаминами. Фокус наших интервью всегда направлен на личные истории юзеров и проблемы, с которыми они пришли к bioniq. В общении мы никогда не навязываем продукт. И именно такой подход дает возможность получить прекрасные инсайты.

Например, однажды в ходе user interview с клиенткой оказалось, что она узнала о компании от своей дочери. Затем еще несколько бесед показали, что потребители начинают пользоваться bioniq по совету знакомых и друзей. Таким образом стало понятно, что большим драйвером для нашего продукта является не та маркетинговая информация, которую мы предоставляем на сайте, а реальные истории использования, то есть наглядные use-кейсы. Мы пришли к тому, что нужно делать ставку на реферальную систему и драйвить продукт с этой точки зрения, использовать это в бенефитах и tone of voice. И действительно сейчас наш referral rate составляет 95 %. Грубо говоря, каждый наш клиент приводит в компанию ещё одного, и это классный источник привлечения пользователей. Без проведения этих user interview продукт bioniq мог уйти совершенно в другом направлении.

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

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

Шаг третий

Когда наступает этап валидации идеи продукта, акцентируем внимание на такой технике User Research, как prototyping. Когда я работал Product-менеджером в компании MacPaw, моя команда занималась развитием продукта Gemini 2. Это было macOS-приложение для удаления дубликатов файлов на ноутбуках.

Как только я пришел в компанию, мы, разумеется, начали проводить User Research, чтобы понять реальные проблемы пользователей. После проведения опроса пригласили часть людей на user interview, на котором задавали вопросы по типу: что вы удаляете на своих ноутбуках? Откуда берутся дубликаты файлов? Какими программами пользуетесь, чтобы решить проблему? Платите ли вы за эти программы? В ходе интервью выяснилось, что пользователи часто чистят свою фотогалерею, которую импортируют с iPhone, так как алгоритмы Gemini 2 считали похожие фотографии дубликатами. Соответственно, юзеры хотели бы решать проблему в месте ее возникновения — на iPhone. Мы не узнали бы об этом из количественной аналитики. Поэтому приняли решение делать продукт для iPhone и стали валидировать эту идею с помощью prototyping.

Чтобы убедить стейкхолдеров компании выделить бюджет на разработку, опросили пользователей в платных Google Surveys (не путать с Forms), который подтвердил реальность проблемы накопления дубликатов файлов на iPhone.

На скейле, чтобы прикинуть наш TAM/SAM/SOM, важно было понять, существует ли проблема в небольшом сегменте аудитории, пользователей Gemini 2 (значит уже есть сформированная «боль»), или на рынке в целом.

Затем купили инструмент сплит-тестирования (метод маркетингового исследования, который позволяет выяснить, какие изменения продукта улучшают показатели метрик), сделали с его помощью фейковую страницу Gemini Photos в App Store (так мы апгрейднули название нашего приложения), как будто продукт уже существует, и начали привлекать пользователей для того, чтобы увидеть хотя бы неполный флоу по CAC продукта. Мы поняли, что аудитория реагирует на наши креативы и у нас неплохая конверсия.

На сплит-тесте нескольких вариантов креативов, иконок и описаний в рамках prototyping кампании обнаружили, что install rate будет не меньше 30%. Это значило, что продукт достаточно хорошо резонирует с аудиторией. Параллельно с этим показывали разные прототипы приложения коллегам, общались с людьми и таким образом с помощью пользователей сделали продукт. Опять же, если бы этап User Research был упущен, приложение могло провалиться или вовсе не запуститься.

После этапа prototyping применили для Gemini Photos нестандартную технику soft launch — локализовалась только в Австралии, которая была похожа по поведенческим параметрам на наши целевые страны. Мы выпустили продукт и стали привлекать пользователей исключительно в одной стране, и это помогло.

На этом ограниченном трафике мы замеряли десятки метрик и тестировали различные варианты креативов в Facebook, store listing, onboarding flow, расположение и конфигурацию paywall в продукте и так далее, даже не проведя А/В-тестирования. Это позволило на не очень большом бюджете улучшить продукт до полноценного запуска и увеличить paid-конверсию в три раза. После этого реализовали огромную кампанию и начали овладение остальными рынками. После полноценного запуска удалось заскейлить продукт до 1M ARR за первые полгода работы, а также взять Product of the day на Product Hunt и второе место на Mobile App Of The Year в 2018-мпосле эпловских Shortcuts.

Вместо выводов

Безусловно, в огромных компаниях есть отдельные команды Research operations, которые проводят исследования на более профессиональном уровне и занимаются только ими изо дня в день. Но это совершенно не означает, что обычный Product-менеджер небольшого стартапа не может провести User Research для своего продукта, потратив на это минимальное количество усилий и ресурсов. Игнорировать исследование пользователей может оказаться плохой затеей, об этом стоит помнить каждый раз, когда вы запускаете что-либо: будь то продукт, его новые фичи или любые другие изменения.

Если вам понравилась статья, подписывайтесь на мой канал в телеграм, где я делюсь личным опытом.

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

О зарплатных вилках

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

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

Основной вопрос тут — должен ли рекрутер говорить зарплатную вилку кандидату?

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

Если человек тестирует рынок через завышение своей цены, то он просто ломает модель с закрытыми вилками. Бывает, рекрутеры слишком лично воспринимают ответы кандидатов и эмоционально реагируют, если, например, человек завышает запрашиваемую сумму, просто тестируя вилку «а вдруг заплатят гораздо больше». Но лет так 15–20назад все было совсем иначе, постепенно люди двигали рынок вверх. Затем рынок начали двигать заходящие к нам компании, в ажиотаже скупавшие разработчиков на +1К.

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

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

Японские свечи на бирже

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

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

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

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

«Недооцененный актив» — человек, не понимающий своей реальной цены. То есть максимальной цены продажи, за которую он может совершить сделку в данный момент. Таких людей выгодно хантить по закрытой вилке. Я сам менторил нескольких разработчиков, имеющих зарплату 600—1000$. После общения со мной им удалось получить оферы на 2000$ и 2500$. Они были теми самыми недооцененными активами.

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

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

Непрозрачность этой системы может быть обусловлена NDA от клиента (если рекрутер не штатный).

О ценообразовании компаний

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

Аутсорсинговая компания

Прибыль = деньги, которые платит клиент за ресурс — зарплата — операционные расходы компании.

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

Аутстаффинговая компания

Прибыль = деньги, которые платит клиент за ресурс — зарплата — операционные расходы компании.

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

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

Продуктовая компания

Прибыль = прибыль от продажи продукта — зарплата — операционные расходы.

Прибыль продукта может быть потенциально неограниченная сверху. Технологические решения продуктовых компаний довольно сложные, ввиду конкуренции через техническую реализацию продуктовые компании по всему миру могут платить очень высокие зарплаты. Топ зарплат наблюдается в Кремниевой долине, где, по статистике западных сайтов, джуниор может рассчитывать на 200К в год. Кстати, вот видеопрохождения интервью в компанию на джуна (2–3года опыта) на 300K в год.

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

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

Стартап

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

Стартапы бывают двух типов:

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

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

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

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

Аутстаффинг, маскирующийся под продукт

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

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

Прямая работа на зарубежного клиента

Для специалистов высокого уровня есть смысл искать варианты для работы на клиентов с США / Европы / UK напрямую. Кто-то очень хитрый выясняет регион кандидата и пытается предложить сумму по его локальным вилкам, кто-то платит всем контракторам в мире +/- одинаковые зарплаты.

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

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

Как просить повышение

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

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

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

Резюмируя: бизнес-модель аутсорс-компаний — оптимизация издержек.

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

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

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

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

Повышения лучше просить чаще и на меньшие деньги, чем сразу и на большие. Этому есть объяснения:

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

Тестовое задание и этапы отбора

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

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

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

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

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

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

О хитростях

Хитрости найма

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

• Всегда говорить про зарплату в GROSS (до налогов), даже явно этого не упоминая.
• Согласиться на ваши условия, но выслать офер на незначительную сумму меньше, сославшись на несовершенное знание внутренних ограничений (грешили даже лидеры рынка).
• Изначально заявить, что вилка найма гораздо меньше не только в компании, куда вы нанимаетесь, а и вообще по рынку. И вас на деньги больше просто не наймут. Это хорошо работает с начинающими разработчиками.
• Заранее не оговаривать курс конвертации из $ в UAH.
• Придумать сложную бонусную систему, которая слабо влияет на фактическое изменение компенсации.
• Предлагать взять человека на заведомо ниже грейд с сохранением желаемой компенсации либо же чуть ниже, чтобы потом утверждать, что на грейд выше нужно показывать совершенно иные результаты.
• В договор добавить пункт о сокращении компенсации в случае «плохого качества кода / нарушении дисциплины / плохой погоды». На интервью говорить, что это всего лишь формальность, но использовать как аргумент при увольнении.
• Нанимать на конкретный проект или технологии, но в итоге нанять на бенч: ситуация довольно частая, нередко происходит не по вине компании. Сервисный бизнес так устроен, что даже на последнем этапе согласования тендера клиент может уйти к другому подрядчику.
• Предлагать зарплату на испытательный срок ниже, чем после. В других отраслях это считается практически нормой, но последнее время на тестовом периоде в IT платят такие же деньги, как и после.
• Пытаться как-то замять спорные вопросы на этапе собеседования либо же сослаться на «решение их позже». Позже вас просто вынудят согласиться на условия компании.
• Не делать явного акцента на договоре, в котором вы можете быть бесправным контрактором.
• На вопрос «А бывают ли овертаймы?» получаете скользкий ответ в стиле «Иногда ребята работают допоздна, но овертаймы не компенсируем». В аутсорсе с этим проще, но для продуктов такая история может означать, что вы фигачите по 10 часов в день без выходных, а получаете как обычно. Вопрос переработок лучше обсуждать не с менеджерами или HR’ами, а с разработчиками непосредственно.

Хитрости после найма

• Долго не поднимать зарплату, утверждая, что наняли человека и так выше рынка.
• После найма придумывать планы развития, в которых разработчики должны писать статьи и делать митапы (у меня никогда не было с этим проблем) и не давать райзов из-за невыполнения каких-то пунктов.
• Продвигать идею о том, что ваша зарплата такая же, как и у топ-менеджеров местных компаний. Это очень много, а поэтому работайте, как юристы в США, по 20 часов в день, чтобы достичь высокого результата. С таким же успехом можно сравнивать зарплаты гендиректоров компаний из Киева и джунов из Сан-Франциско.
• Придумать метрики по повышению зарплаты после испытательного срока, которые изначально невозможно пройти.

Хитрости в процессе работы

• Некоторые компании могут продавать людей на фулл-тайм сразу двум клиентам, потом просить выкручиваться и репортить по 8 часов везде. В итоге на вас будут давить оба менеджмента клиентов и ваш локальный менеджмент.
• Менеджер может просить вас взять какую-то халтуру от него лично в обход основного проекта, не снижая к нему требований.
• Продавать вам идею работы со включенными камерами, трекерами экрана как часть корпоративной культуры взаимоуважения: «У вас бы и так экран было видно, если бы в офисе сидели», чтобы потом спрашивать вас за каждые 15 минут отсутствия и просить отработать все 8 часов полностью (не секрет, что максимально возможная загруженность разработчика в день — до 6 часов продуктивной работы, остальное время нужно для восстановления и мыслительного процесса).
• Некоторые компании додумались вводить бонусную систему за доносы о нарушении корпоративных политик. Например, если сотрудники берут подработки на другие компании.

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

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

Про бенч

Психологические проблемы бенча

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

Главное на бенче — не переставать кодить, чтобы потом проектная работа не стала для вас стрессом.

Чем заняться на бенче?

Я использовал долгий бенч в одной из прошлых компаний себе на пользу:

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

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

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

О процессах рекрутинга

Почему он не ответил?

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

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

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

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

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

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

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

Почему он не согласен менять работу?

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

• Разработчик задумывается о смене работы, если видит несправедливость по отношению к себе с точки зрения компенсации либо рабочего процесса.
• Если фактическая позиция не соответствует карьерному плану.
• Из-за дискомфорта на рабочем месте по разным причинам.
• Если разработчик знает, что его фактическая цена на рынке может быть значительно выше, но компания не разделяет его мнения. С пунктом № 1 отличие в том, что тут виновата система, а там другие люди могут претендовать на что-то, а рассматриваемый виртуальный разработчик не может.

Личные границы в деловом общении

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

• звонки по телефону;
• сообщения в скайпе / телеграме или фейсбуке.

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

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

Кстати, в своем мнении я не одинок, что показал недавний опрос на платформе LinkedIn среди разработчиков

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

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

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

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

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

Что делать, если бонус не платят?

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

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

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

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

Глобальный рынок и тенденции

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

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

Давайте немного посмотрим на ситуацию в целом:

• IT-рынок в мире стабильно растет. Даже во времена «черных лебедей» (кризисы, эпидемии, войны) сработала упругость, бизнес адаптировался под новые условия. Посмотрите хотя бы графики выпуска приложений в Apple Store & Google Play.
• В IT не бывает кризиса перепроизводства.
• Даже в условиях роста зарплат в мире сфера IT все равно остается рентабельной.

Аутсорс-компании из США продают местных специалистов на местном рынке по рейтам 100 долларов/час минимум. Этот ценник может доходить до 200–300 долларов/часза сеньоров со знанием сложных доменов либо редких технологий. Либо же это может быть обусловлено регионом: в Калифорнии всегда дороже.

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

За последнее время в Украине произошли качественные изменения:

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

Следовательно, наши компании повышают рейты до 40–60 долларов/час.А в некоторых случаях до 100 долларов/час.

Мое мнение: потолка мы еще не достигли, и, когда наши компании будут продавать по 100–150 долларов/часи самая высокая зарплата будет 10—15К, тогда можно будет сказать о неком потолке.

Причем причиной этому может стать не только укрепление нашего региона в мире, а и сам рынок США, который постоянно растет.

Кстати, вот ещё неплохая статьяпро рост зарплат в США. Следует учитывать инфляцию доллара как вторичный фактор увеличения зарплат в Украине. Каждый 4-йдоллар в США был напечатанв 2020 году.

Разница между наймом тут и на Западе

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

На условном Западе все гораздо спокойней. Работу найти бывает сложно, высокооплачиваемую тоже сложно, но можно, если вы переедете в Кремневую долину и устроитесь в FAANGи близким к ним компаниям, где зарплата джуниоров может быть до $300К в год. Именно Долина тянет весь рынок вверх по чуть-чуть.

В США принято заказывать Resume Writing & Cover Letters. Специально обученные люди помогут грамотно составить и отформатировать резюме и сопроводительное письмо за $100–200. Причем некоторые из таких компаний работают на рынке США прямо из Украины, маскируясь под западные. Еще в США развито карьерное консультирование. Крупные компании ставят скрининг на поток с помощью специальных сервисов, отсеивая соискателей сотнями, ведь хорошую работу там найти гораздо сложнее, чем у нас. Состав команд часто интернациональный: в США уезжает множество людей из Индии, Китая, стран СНГ, в том числе Украины. Бывает, что наши крупные аутсорсеры перевозят туда специалистов под не самые выгодные условия, где по контракту человек должен проработать пару лет либо внести значительную сумму, чтобы уволиться.

Одно из различий еще в том, что в США норма, если ты джуниор первые несколько лет своей карьеры. Условные синьоры там чаще всего — это ребята с более чем 10-летнимопытом.

В заключение

Также я создатель таких карьерных ресурсов:

• Сервис поиска парт-тайм работы для разработчиков.
• Канал с вакансиямис вилкой выше рынка.
• Канал с вакансиямипо 100% удаленной работе.
• Закрытая группа для лидов и архитекторов на стеке .NET, пишите в личку — добавлю.

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

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

Як впливати на людей

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

Батьки хочуть, щоб їхні діти їли більше фруктів і менше солодощів. Це — вплив на поведінку дітей, бо вони зазвичай хочуть протилежного. Мета в такому випадку зрозуміла: батьки люблять дітей і прагнуть, щоб вони росли здоровими. Досягти цього можна різними шляхами: проханням («з’їж, будь ласка, яблуко»), торгуванням («з’їж спочатку яблуко, а потім можеш взяти печиво»), наказом із загрозою покарання («їж яблуко, бо дам по шиї») тощо. Керівники впливають на поведінку команди, щоб кожен її учасник ефективно та вчасно виконав свою частину роботи.

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

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

Шах і мат

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

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

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

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

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

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

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

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

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

За Фоггом є три шляхи до збільшення можливості:

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

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

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

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

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

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

Тригери бувають внутрішніми та зовнішніми.

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

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

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

Як це використати

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

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

Далі треба вибрати, який тип тригеравикористати, коли та як саме, щоби підштовхнути користувачів до першої дії. Для цього варто провести дослідження та побудувати user journey map.

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

І наостанок

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

Щоб дізнатися про поведінку людей більше, рекомендую ознайомитися з оригіналом робітБ. Ж. Фогга, а також із книжками «На гачку. Як створити продукт, що чіпляє» Нір Еяля та Seductive Interaction Design by Stephen P. Anderson.

Меня зовут Александр Рябцев, я работаю на позиции Back-end Lead в компании Django Stars, и в этой статье мы поговорим о том, когда необходимы обновления и как их сделать, не влияя на функциональность приложения. Это особенно важно в финтехе, поскольку технологии и навыки пользователей продолжают развиваться. И по мере того, как это происходит, пользователи становятся более требовательными и хотят больше функций, таких как лучшая безопасность или возможность проводить платежи онлайн.

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

Что такое обновление устаревшего кода и как это сделать

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

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

Критерии оценки для обновления устаревшего кода

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

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

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

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

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

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

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

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

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

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

От чего зависят обновления кода

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

• Возраст. Очень важно, имеет ли код возраст один год или пять. Например, вы должны понимать, что пять лет в Python и Django (технологии, с которой мы работаем) — это далекая галактика. За это время многое изменилось, и код, скорее всего, будет иметь огромные дыры в системе безопасности и так далее. Некоторые части кода будут слишком старыми для перехода на новую версию — их будет легче переписать.
• Архитектура кода. Монолитный или микросервисный? Если разработчики могут разделить приложение на части (например, CRM, CMS, веб-сайт и файловое хранилище), они могут и обновлять его по частям. Но если нет видимых частей, остается единственный вариант — переписать код. Обычно, если невозможно разделить код на части, он написан плохо, и его рефакторинг будет сложной задачей.
• Тестовое покрытие. Это определяет, покрыт ли код тестами должным образом (и какие именно тесты) или команде нужно их написать.
• Развертывание. Команда проверит, как проходит развертывание, когда новый код входит в старую систему.

До обновления устаревшего кода: список дел

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

Соглашайтесь на ожидания

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

Определите риски

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

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

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

Обеспечьте достаточное покрытие тестами

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

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

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

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

Привет! Меня зовут Алексей Чаплыгин, я Chief Information Officer в Reface, руковожу техническим департаментом, в том числе ML-отделом.До этого запускал с нуля отдел Data Science и ML в компании PVH в Амстердаме. С 2012 года живу в Нидерландах. По образованию я физик, поэтому люблю решать разные задачи, будь то AI, бизнес или стратегия.

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

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

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

Почему я перешел из разработки в ML

Лет 8 я занимался девелопментом разного уровня, начиная с низкоуровнего Си (без всяких плюсОв) и заканчивая ERP-системами. В какой-то момент кодить несколько наскучило, так как прикладное программирование — решение по сути решаемых задач. Это как решать школьные примеры, когда знаешь, что правильный ответ точно есть и задача сводится только к тому, чтобы его найти и записать. С опытом «найти» становится все проще, а «записать» все скучнее.

Работа с ERP-системами требует постоянной работы с данными, поэтому постепенно к своему инженерному опыту я начал добавлять Data Science, параллельно освежил математику (благо образование в области теоретической физики позволяло), а в свободное время уходил с головой в ML. Момент, когда я оказался полностью в ML, прошел незаметно даже для меня, так как 7 лет назад уже был хайп вокруг AI, специалистов не хватало, поэтому работодатели были только рады моему перевоплощению.

Волей случая я попал в компанию PVH (Tommy Hilfiger, Calvin Klein и другие бренды) с HQ в Амстердаме, где с нуля поднял отдел DS и ML. В целом динамики хватало, но все равно казалось, что в прикладном ML я работаю на 5% от расчетной мощности. Корпоративная медлительность, узкий спектр задач — не то, что драйвит ресерчера, поэтому я решил создать что-то свое и параллельно с основной работой два года самостоятельно занимался АI-проектом виртуальных примерочных Beyond Belief. Если бы не поддержка семьи и жены, наверное, я бы в какой-то момент все бросил, но в итоге сделал MVP продукта, который был по сути Full Body Swap, записал проморолик, выложил на YouTube, и через пару дней на меня отовсюду посыпались предложения о сотрудничестве. Первым же, кто постучался в Facebook, был Олесь Петрив, с которым мы созвонились буквально через пару дней, и я сразу понял, что именно с Reface нам по пути.

Как создавать новое с помощью ML

Сегодня я остановлюсь детальнее на подходе, который позволил мне в одиночку создать Beyond Belief, при том что до сих пор некоторые из задач остаются нерешенными и нет ни одного пейпера, гита или продукта, который бы описывал пайплайн технологии Full Body Swap.

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

Например, дропаут. Что это на самом деле?

Я часто задаю этот вопрос кандидатам на интервью сразу же после «Что такое производная?» (кстати, на вопросе про производную в Европе отлетают 90% кандидатов, в то время как у ребят из СНГ подобное спрашивать иногда даже стыдно, университетская восточноевропейская матподготовка и правда на порядок сильнее узкопрактической европейской). И почти всегда ответ формально правильный, ровно как написано в книжках, но при этом показывающий, что собеседник не задумывался о том, как именно работает подобная техника.

Что не так с книжными определениями

Я взял определения дропаута из «Википедии», гугла и «Медиума».

• «Исключение» (дропаут) нейрона означает, что при любых входных данных или параметрах он возвращает 0... (дальше можно не продолжать...)
• Термин «dropout» («выбивание», «выбрасывание») характеризует исключение определённого процента (например, 30%) случайных нейронов (находящихся как в скрытых, так и видимых слоях) на разных итерациях (эпохах) во время обучения нейронной сети.
• ... dropout refers to ignoring units (i.e. neurons) during the training phase of certain set of neurons which is chosen at random. By «ignoring», I mean these units are not considered during a particular forward or backward pass.

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

Определение сути дропаута

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

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

output = f(x), f — функция, определяющая нейросеть.

x — входной тензор.

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

layer_N = g(layer_N-1), где g — функция, определяющая один слой;

layer_N — тензор из некого латентного пространства, возникающий по ходу преобразований.

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

Тогда Dropout — это:

1. Определим тензор А, в котором есть значения строго 0 или 1, где выбор между 0 или 1 происходит согласно равномерному распределению с вероятностью p (скажем, вероятность p определяет выбор значения 1).
2. Договоримся по-джентльменски, что размерность А совпадает с размерностью layer_N-1.
3. layer_N = g(A · layer_N-1 / p), где ·— dot product.

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

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

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

Как поможет глубокое понимания дропаута на примере

«Пример курильщика» — это картинка из интернета, которая, как мне кажется, не дает полного понимания, как работает дропаут и что с ним делать. Как он определен? Какие операции стоят за кружочками и стрелочками?

«Пример здорового человека». Справа — матрица А, слева layer_N-1, на выходе — layer_Nпосле применения dropout. Да вот и всё... И тут можно начать задавать вопросы: почему А состоит только из нулей и единиц? Почему заполняется ими согласно юниформному распределению? Можем ли мы вместо нулей и единиц использовать другие значения? Да, можем. Или выбрать другое распределение — это тоже можем. Такое понимание делает инструмент гибким.

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

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

Вывод

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

В молодости мой отец программировал под БЭСМ-6, когда в машинный зал размером со школьную столовую необходимо было записываться за неделю, печатать программу на перфокартах, когда вместо экрана был принтер и рулоны бумаги, когда малейшая ошибка откладывала получение результата на дни до следующей попытки. Эта ситуация мне напоминает современный ML: да, теперь тренировка сетей стала возможна, но тяжелые модели все еще необходимо тренировать днями. Возможно, через 15 лет время перфокарточного ML пройдет и ML станет не сложнее прикладного программирования на высокоуровневых языках, но сегодня цена ошибки все еще высока. А значит, проектировать действительно сложные модели надо обдуманно, в голове: на пробежке, во время похода в магазин, перед сном. Для этого необходимо развивать «интуицию», что на самом деле не более, чем опыт и глубокое понимание деталей.

Привет, меня зовут Денис, я Tech Lead компании UKAD. В этой статье я хотел бы рассказать про особенности экзаменов Microsoft, поделиться своим опытом и дать полезные советы тем, кто решил получить сертификаты.

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

«После прохождения сертификации 67% технических специалистов увереннее чувствуют себя в отношении своей способности выполнять работу, 41% получают большее удовлетворение от работы, а 35% сообщают об увеличении зарплаты», — Pearson VUE (2018 год), отчето ценности IT-сертификации.

Моя же мотивация состояла в следующем:

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

Обзор сертификаций Microsoft

Начиная с января этого года компания Microsoft полностью перешла на новый подход сертификации специалистов. Теперь вместо множества разных экзаменов с кодом 70-***, нацеленных на отдельно взятые технологии или продукты, ввели так называемые role-based сертификации, в которых подразумевается, что отдельный сертификат подтверждает широкие навыки специалиста определённого направления. Так, например, для его получения по платформе Azure необходимо сдавать экзамены с кодом AZ-***, для Power Platform — PL-***, для специалиста по безопасности — SC-*** и так далее.

Недавно коллега поинтересовался, почему он получил бейдж сертификации всего с одной звёздочкой — значит ли это, что он плохо сдал? Всё дело в том, что сертификации разных направлений разбиты на три уровня сложности: Fundamentals, Associate и Expert. Это своего рода сертификационная геймификация. Красивый бейдж сертификата уровня Fundamentals имеет одну звёздочку, уровня Expert — три. Немного особняком стоят узкие специализации. Windows Virtual Desktop Specialty, например, не вписывается в общую иерархию и не имеет звёздочек вовсе.

Ещё один момент, который часто вводит в заблуждение людей, впервые столкнувшихся с сертификациями: успешное прохождение экзамена не означает получение сертификата. Зачастую для этого необходимо сдать один или несколько экзаменов из пререквизитов к этой сертификации. Например, для Azure Solutions Architect Expertнеобходимо сдать два экзамена с кодами AZ-303и AZ-304.

Подробный перечень тем можно найти по ссылке Download exam skills outline в секции Skills measured. Этот документпредставляет собой основной ориентир во время подготовки. Когда и если содержимое экзамена изменяется, эта информация отражается только в Exam skills outline.

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

Срок действия сертификата зависит от его вида и даты получения. Fundamentals не имеют срока истечения, более объёмные — наоборот. Те, кто сдал экзамен до июня 2021 года, получили сертификаты, которые действительны в течение двух лет. Сдавшие экзамен после этой даты получат сертификат, который будет действителен в течение одного года. Но хорошая новость в том, что Microsoft разработала процедуру продления сертификации прямо на Microsoft Learnпортале. Оно бесплатно и потребует только прохождения короткого теста. Его можно делать многократно с интервалом в один день, если не получилось с первой попытки.

Почему решил проходить именно эту сертификацию и какие получал еще

Свой первый сертификат Microsoft я получил ещё в 2011 году. Сдал экзамен 70-511,и мне дали целых два сертификата Microsoft^® Certified Technology Specialist: .NET Framework 4, Windows Applicationsи Microsoft Certified Professional. На тот момент это дало ускорение моей карьере, фокус сместился, и я забыл про сертификации почти на 10 лет.

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

Выбрать сертификацию было легко. Так как у меня в прошлом девелоперский бэкграунд и мне нравится платформа Azure, я решил, что целью будет сертификат Azure Developer Associate, соответственно экзамен AZ-204. Уже в процессе подготовки я узнал, что есть сертификаты разного уровня, и принял решение сперва сдать AZ-900для получения Azure Fundamentals, что казалось более лёгким стартом. В результате так и сделал, а после вернулся к своей основной цели.

Подготовка

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

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

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

Теория

На этом этапе я старался максимально получить общее представление о каждом из разделов сертификации, особенно уделял внимание темам, в которых имел меньше всего опыта. Для проработки теории подходит любой источник. Многие рекомендуют курсы от Scott Duffy на Udemy, со скидкой курспо AZ-204 стоит $12 (скидки на платформе практически постоянно) и состоит из почти 10 часов видеоматериалов и практического теста. Этот курс был хорошо структурирован, еще понравился мне чистым произношением диктора.

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

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

Практика

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

Идеальный сценарий — это когда можно получить практический опыт из реальных проектов, но, если такой возможности нет, есть огромное количество практических заданий в свободном доступе. На портале Microsoft Learn есть отличная подборка материалов по экзамену AZ-204 и множеству других. Ссылки на учебные модули находятся прямо на странице сертификации, в разделе Two ways to prepare — Oline — Free. Каждый модуль представляет собой учебный сценарий, есть набор сервисов и инструкции по выполнению. Некоторые модули полностью теоретические, другие предполагают работу с реальной подпиской Azure, нередко это бесплатная учебная подписка на время прохождения.

Ещё один источник практических заданий — лабораторные работы на GitHub в аккаунте Microsoft Learn. Такой подход немного менее интерактивный, но не уступает по качеству, поскольку контент подробный и понятный.

Практические тесты

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

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

Многие вопросы в тестах были похожи на вопросы из реального экзамена, потому имеет смысл проходить их несколько раз, особенно если с первой попытки не получилось набрать проходной балл. Кроме тестов из курса на Udemy, я использовал примеры от MeasureUp (€91), которые рекомендует Microsoft, и от Whizlabs ($16), рекомендованные комьюнити. На мой взгляд, стоимость у MeasureUp слегка завышена, но по счастливой случайности мне они достались бесплатно, чем я и воспользовался.

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

Как я сдавал экзамен

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

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

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

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

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

Продолжительность зависит от вида и уровня сложности. К примеру, экзамен AZ-204 (Developing Solutions for Microsoft Azure) длится два с половиной часа и содержит от 40 до 60 вопросов. Кроме того, до и после экзамена даётся дополнительное время, чтобы пройти подготовку рабочего места и дать обратную связь по экзамену или отдельным вопросам, если есть чем поделиться. Экзамен AZ-900 (Microsoft Azure Fundamentals) длится всего час. На экране можно видеть, сколько времени осталось. Так как вопросы могут быть разного уровня сложности, стоит следить за временем, чтобы не задержаться слишком долго на каком-то одном. Имеет смысл начать готовиться за полчаса до запланированного старта, чтобы в спокойном режиме пройти все процедуры.

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

Вопросы экзамена могут быть разбиты на секции. После перехода к новой секции уже нельзя будет вернуться к предыдущей, просмотреть все, изменить ответы или что-то исправить. При этом в AZ-900 (Microsoft Azure Fundamentals) всего одна секция, а в экзаменах уровня Associate или Expert секций может быть несколько. Это стоит учитывать.

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

Вопросы бывают нескольких видов:

• с одним вариантом ответа;
• с несколькими вариантами ответа, обычно указано, сколько вариантов нужно выбрать;
• выбор правильных и расположение в правильном порядке опций из списка;
• заполнение пробелов на диаграмме или в коде;
• сценарии (Case Study) — набор из нескольких вопросов к общему обширному сценарию, где подразумевается, что нужно принять правильное решение, ознакомившись с описанием существующего или планируемого решения. В моём экзамене AZ-204 было два Case Study, вынесенных в отдельные секции.

В результате я успешно с первой попытки сдал AZ-900 с баллом 930 и AZ-204 с баллом 792.

Общие рекомендации

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

В качестве минимального набора я бы рекомендовал приобрести курс по выбранному экзамену на Udemy и практические тесты на Whizlabs. Расходы на учебные материалы составят до $30, зато позволят более структурировано пройти подготовку и повысить шансы на успех.

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

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

Несмотря на то, что цена экзамена весьма умеренная в сравнении с временем, затрачиваемым на подготовку, даже здесь можно сэкономить. Экзамен AZ-204 стоит $80 для Украины, AZ-900 всего $55. Для экзаменов уровня Fundamentals Microsoft проводит виртуальные тренинги, так называемые Virtual Training Days, в формате одного или нескольких вебинаров. Посетив такой вебинар по выбранной тематике, вы получите ваучер на бесплатную сдачу.

Для экзаменов уровнем выше Microsoft проводит челленджи. Некоторые проходят постоянно, а некоторые привязаны к событиям. Например, недавно был масштабный челлендж, привязанный к конференции Microsoft Ignite. Это набор из учебных модулей на Microsoft Learn, которые нужно сдать за месяц. В зависимости от вида челленджа, после него вы получите скидку или ваучер на бесплатное прохождение экзамена. Пример того, что дает 50% скидку: 30 Days to Learn It.

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

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

Имеет смысл глубже разбираться с темами, которые пригодятся в работе или подготовке к последующим экзаменам. Например, AZ-900 только поверхностно касается работы с Azure Storage, но всё равно будет хорошим подспорьем в изучении нюансов и обязательно пригодится в будущем.

Слова напоследок

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

В самом начале подготовки к экзамену стоит заглянуть в практические тесты, чтобы представлять себе уровень сложности и виды вопросов. Имеет смысл заранее зарегистрироваться в Certification Dashboardи на Microsoft Learn, используя один и тот же email. Также стоит привязать свой сертификационный профиль к платформе Learn. Это поможет избежать путаницы и общения с саппортом в будущем.

Я настоятельно рекомендую всем, кто готовится сдавать экзамены по платформе Microsoft Azure, завести собственную подписку, так как многие темы сложно проработать без доступа к ней. Microsoft предоставляет бесплатную подписку на месяц, но даже по истечению этого периода стоит продолжать и перейти на Pay-As-You-Go, а при возможности использовать студенческую подписку или партнёрскую опцию. Если применять личную подписку только для обучения и не забывать удалять ресурсы после экспериментов, плата за месяц редко превышает пару долларов. Это, на мой взгляд, вполне умеренные расходы за полученный опыт. Кроме того, многое можно проверить только через бесплатные ресурсы.

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

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

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

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

Удачи, Денис.

Привіт! Я Володимир — Unreal Engine Developer у компанії N-iX. Я та ще кілька моїх колег розробили з нуля Unreal Engine курс для Національного університету «Львівська політехніка». Як і навіщо? Поясню у статті. Сподіваюся, моя розповідь стане корисною тим, хто теж хоче ділитися своїми знаннями зі студентами.

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

А якщо замахнутися та запустити курс з UE4 у виші як окремий предмет? У нас це займе два з половиною роки. Так, на осінь 2022-говже запланований напрям з вивчення Unreal Engine у Львівській політехніці. Але про все за порядком.

Робочий процес в N-iX Game & VR Studio

Як усе почалося

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

Хто ми

Ми — це N-iX Game & VR Studio. 150+ фахівців, які займаються розробкою ігор та B2B-застосунків віртуальної реальності. Для розробки ми використовуємо UE4 та Unity, маємо багато втілених проєктів і відомих партнерів. Безпосередньо над курсом з нашого боку працювало шість фахівців — три програмісти та три гейм-дизайнери.

Я відповідав за організацію курсу від N-iX, маю педагогічну освіту і до ІТ відпрацював 6 років у профтехосвіті (маю звання вчителя 1-їкатегорії — то як мідл). Також, окрім викладання, ліцензував нові професії у профтехосвіті.

Як в університетах можуть з’являтися нові курси

Будь-який навчальний заклад готує студентів суто за спеціальностями. Кожна спеціальність базується на програмі — переліку предметів, тем і годин, які будуть викладати. Програму затверджує Міністерство освіти та науки України, вона підкріплюється сертифікатом. Відхід від програми загрожує санкціями та зниженням держзамовлення (фінансування) для закладу. Якщо ж виш хоче ввести нову спеціальність, потрібно підготувати програму на 5–6років і підкріпити її дидактичними матеріалами з усього циклу. Це для розуміння, чому нові напрями з’являються нечасто і в наших університетах усе ще вчать принципи роботи ЕОМ.

Сумно? Насправді не зовсім, адже кожен навчальний заклад має змогу змінити програму під себе на 15–20%,що закладається «вільними» годинами в план. І розроблений нами курс з UE4 має якраз зайняти частину цих годин для однієї з професій в політесі.

Як ми працювали над курсом і його структурою

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

Паралельно я та ще двоє моїх колег — Олексій Ковалевський та Ігор Пундєв, Senior-розробники з досвідом роботи над ААА FPS — працювали над матеріалом для курсу.

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

Тож ми розділили курс на 5 блоків: ознайомлення з Unreal Engine, робота з системою Foliage, UI, штучний інтелект та анімації. І кожен з нас зайнявся свою частиною. Щоп’ятниці проводили зустрічі з Данилом Полуденним, Head of N-iX Game & VR Studio, де фіксували наш прогрес і визначали, що маємо закінчити до наступного тижня (залежно від завантаженості на роботі). Оскільки ми фултайм зайняті на проєктах, то готували курс у позаробочий час з підтримкою компанії — N-iX оплачувала нам ці додаткові години.

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

Для побудови курсу користувались матеріалами від Unreal Engine, взявши проєкт First Person Shooter як базу. Вся ігрова логіка мала бути в С++, з якою ми працюємо багато часу, тоді як в Blueprint мали бути макети UI-панелей, анімації та налаштування ігрових модулів.

Наш план був такий:

• Ознайомити студентів з Unreal Engine та навчити створювати перші базові класи.
• Розповісти про системи Foliage і показати, як можна робити власний унікальний ігровий рівень, створювати та застосовувати матеріали, виставляти світло та налаштовувати звуки.
• Запланували додати UI, щоб ознайомити студентів з UMG і Slate, та готувати HUD-елементи для відображення кількості набоїв, життів тощо. Логіку ми робили в Blueprint, а студенти мали б переписати це на C++ (оскільки вони взаємозалежні).
• Навчити налаштовувати ігрового персонажа та прописувати його поведінку.

Окремий блок був про анімації та АІ, де запланували розповісти, як налаштувати просту AI-модель для бота та у разі знаходження опонента стріляти по супротивнику.

Кінцевий етап — дати студентам зібрати build, який би підсумував вивчене під час курсу.

Крім того, підготували й лекційну частину: додали інформацію про розробку ігор від Данила, Head of N-iX Game & VR Studio, та наших гейм-дизайнерів, які склали чотири лекції про вступ в ігрову індустрію, як вона працює та що таке дизайн ігор.

Пілотний проєкт

Через локдаун студентів перевели на дистанційне навчання, і вони втратили доступ до лабораторій політеху, а відповідно й до шоломів віртуальної реальності. Ми вирішили не сидіти без діла та використати це, щоб потестити наші напрацювання з курсу на малій групі слухачів. Тож підготували факультатив для студентів 2-гокурсу кафедри програмного забезпечення. Вони вже мали базу із С++ і ООП, тому можна було сконцентруватися на UE і проєктах. Університет дав нам список охочих, з кожним ми провели технічну співбесіду, яка відповідала матриці компетенції компанії на посаду джуніора. Питання ставили суто з С++ і лінійної алгебри. Так відібрали 8 осіб для факультативу.

Перед викладанням курсу студентам ми провели внутрішню апробацію на фахівцях N-iX. Це були або C++ деви, які ніколи не працювали з UE4, або QA-спеціалісти, які мали досвід з UE4, але не вміли програмувати. Завдяки цьому отримали зворотний зв’язок та виявили деякі труднощі, внесли корективи. Наприклад, додали більше візуальних матеріалів для розуміння, що саме студент має отримати в проміжному результаті, що було особливо важливо під час самостійного опрацювання матеріалу. Також зробили окремий розділ з відповідями на стандартні питання та описали налаштування середовища й дали список корисних порад у відповідь на «що робити, якщо мій білд не запускається?».

Приклад, який ми додали в матеріал курсу

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

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

Висновки

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

За результатами «курсових робіт» ми вже запропонували роботу в N-iX трьом студентам.

Сподіваюся, що розроблений нами курс справді допоможе Львівській політехніці запустити потужний Unreal Engine напрям та готувати кваліфікованих фахівців, які в майбутньому стануть і нашими колегами в N-iX. Адже потреба у крутих Unreal Engine розробниках є завжди.

Дякую, що дочитали :) Якщо є питання — лишайте у коментарях, спробую відповісти. Також приєднуйтесь до нашої команди N-iX Game & VR Studio, у нас завжди є відкриті позиції.

Я Любомир Гумецький, VP Global Delivery Leadership у SoftServe. Моя команда займалася розробкою оновленої системи професійного розвитку працівників, яка відповідає сучасним тенденціям в індустрії, вимогам бізнесу, а також очікуванням співробітників і потенційних кандидатів.

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

Але спершу трохи про контекст і те, чому ми вирішили змінюватися.

Інший ринок та очікування бізнесу — інші вимоги до працівників — інші критерії оцінювання — інша система розвитку працівників

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

Раніше більша частина наших проєктів — це був так званий «body shop». Клієнт приходить з чітко окресленою технічною задачею. Компанія повинна мати у штаті людей, які володіють компетенціями на достатньому рівні, аби виконати завдання. Професійний розвиток зводився здебільшого до поглиблення знань і вдосконалення володіння технологіями (тобто мовилося переважно про hard skills).

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

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

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

Від цього виграють усі:

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

Тож ми у SoftServe комплексно взялися за об’єднання інтересів компанії з потребами працівників і реалізували це в нашій People Excellence — оновленій системі професійного розвитку, розкриття потенціалу і відзначення співробітників.

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

Як було і стало. Що змінилося на практиці

Було

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

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

Досягнення людини оцінювали за такими критеріями:

• Технічні навички та знання — працівнику потрібно було довести, що рівень його знань підвищився. Був фіксований перелік того, що потрібно знати та розуміти на кожному рівні.
• Наявність сертифікацій — набір внутрішніх та зовнішніх сертифікацій, які потрібно було отримати.
• Performance appraisal (оцінення результатів роботи) — ми мали градацію навичок під відповідний рівень відповідної компетенції.
• Рівень володіння англійською — має відповідати певному технічному рівню.
• Кількість років досвіду.

Рев’ю досягнень проходило в три етапи:

1. Knowledge evaluation — чи відповідає рівень знань тому, на який претендує працівник.
2. Оцінення перформансу — стосувалось насамперед soft skills і меншою мірою результативності чи продуктивності роботи.
3. Оцінення технічної експертизи — враховували рівень володіння англійською мовою та пройдені зовнішні чи внутрішні сертифікації.

Тобто цей підхід значною мірою базувався на знаннях людини (був knowledge-based). Підвищення = кількість років досвіду + наявність сертифікацій + знання теорії + виконання роботи з проєкту.

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

Стало

Knowledge-based підхід (те, що ви повинні знати) еволюціонував у Experience-based підхід (те, що ви повинні вміти).

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

Наприклад, якщо узагальнити, то Software-інженеру, щоб з Junior підвищитись до Middle, потрібно почати виконувати роботу Middle-інженера, а це означає навчитися самостійно розробляти прості модулі відповідно до стандартів, а також імплементувати рішення середньої складності, а з Middle до Senior — виконувати роботу Senior-інженера, тобто розробляти комплексні модулі та компоненти, а ще проговорювати із замовником вимоги до ПЗ.

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

Тепер рев’ю досягнень людини (яке ми називаємо Performance Review) має 4 етапи:

1. Self-evaluation — працівник заповнює форму для оцінювання результатів, куди вносить усі свої досягнення за період оцінювання (не за весь час роботи на проєкті).
2. Оцінювання технічної експертизи — розмова з незалежним технічним експертом для визначення прогресу у практичному застосуванні hard skills, необхідних для того, щоб приносити більше цінності конкретному проєкту.
3. Зворотний зв’язок — колеги по команді, менеджер та клієнт дають фідбек щодо роботи фахівця у команді і його внеску в проєкт.
4. Підсумки — розмова з менеджером для обговорення прогресу та досягнень, а також визначення подальших кроків.

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

Як вибудовуємо процес для об’єктивного оцінювання

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

Є bottle necks, з якими треба ефективно попрацювати. Нижче — ключові моменти, які варто враховувати.

Як пересвідчитися в тому, що при self-evaluation працівник вказав свої реальні досягнення?

• Працівник повинен бути готовим надати підтвердження кожного із зазначених досягнень під час розмови з незалежним експертом

Як об’єктивно оцінити досягнення працівника?

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

Хай там як, а людський фактор повністю не елімінується, а отже бувають і спірні ситуації (наприклад, працівник готовий до підвищення, але менеджер за результатами performance review його не підвищив). Як їх відстежувати та вирішувати?

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

Буває, що працівник виконує на проєкті кілька ролей (наприклад, PM і BA). Якщо оцінювати його лише за основним профілем, це буде недооцінювати його реальний внесок.

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

Нове впроваджувати складно. Люди не завжди готові до цього.

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

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

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

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

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

Ілюстрація Марії Рибак

Що таке Salesforce

Штаб-квартира Salesforce у Сан-Франциско розташована в найвищому хмарочосі Західного узбережжя з промовистою назвою Salesforce Tower. Це цілком характерна деталь: компанія любить увагу, багато в чому на ній тримається бізнес. Колишній менеджер з продажу, що піднявся до віцепрезидента в Oracle, Марк Беніофф заснував Salesforce 1999 року. Тоді в неї вклалася низка інвесторів, зокрема Geneva Venture Partners. Уже у 2000-мувони змусили говорити про себе, нахабно розмістивши рекламний банер з написом «The End of Software» навпроти місця проведення конференції Siebel, прямого конкурента і на той момент лідера ринку CRM.

Відтоді минуло понад 20 років, Siebel займає не більше як 8% ринку CRM-рішень. До того ж її ще 2006 року поглинула компанія Oracle, але й це злиття не допомогло учасникам угоди скласти серйозну конкуренцію Salesforce. Компанія колишнього співробітника Oracle вже вісім років зберігає позицію одноосібного лідера ринку, займаючи більшу частку, ніж та сама Oracle, SAP, Microsoft і Adobe разом узяті.

Слоган з того рекламного банера задав напрям усій маркетинговій стратегії Salesforce. У дещо зміненому вигляді вони використовують його навіть у номері телефону: 1-800-NO-SOFTWARE.

У 2004 році компанія стала публічною та почала торгувати акціями на Нью-Йоркській біржі з тікером CRM. На момент написання статті загальна її капіталізація трохи перевищила $201,4 мільярда, акція Salesforce коштувала $218,72 (для прикладу одна акція Apple Inc. у цей момент коштувала $123, Microsoft — $242,35, Facebook Inc. — $298,66), а дохід компанії 2020 року становив $4,875–4,885 млрд.

Починаючи з 2006 року Salesforce поглинула понад десять компаній, серед яких Heroku (PaaS-рішення), Quip (текстовий онлайн-процесор), MuleSoft (проміжне програмне забезпечення), Tableau (BI-рішення, орієнтовані на візуальний аналіз) і Slack (корпоративний месенджер).

Дванадцять років поспіль Salesforce входить до списку 100 найкращих роботодавців за версією журналу Fortune.

Причина успіху

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

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

Термінологія

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

SF, SFDC — скорочення для назви Salesforce.

Salesforce organization/org (рідше Salesforce instance) — екземпляр, відкритий для конкретного клієнта Salesforce. Може стосуватися одного з різновидів: Production, Sandbox, Developer, Scratch. У побуті часто називають «оргою».

Production org — орга або інстанс, з якими безпосередньо працюють кінцеві користувачі.

Sandbox org — пісочниця для експериментів, прив’язана до будь-якої Production org.

Developer org — орга, здебільшого призначена для створення пакетів для AppExchange. Ще частіше її використовують для експериментів або роботи з безкоштовною навчальною SF-платформою Trailhead. Нові клієнти зазвичай починають саме з Developer org, потім після установок і міграції конвертують її у Production.

Scratch org — особливий тип орги з обмеженим циклом існування (до 30 днів), призначений для виконання окремих задач або створення Proof of Concept. Дуже популярний при роботі у великих командах, де немає можливості створювати окрему пісочницю для кожного розробника. Часто застосовують для CI/CD.

Salesforce Cloud — готове рішення для будь-якої галузі від Salesforce.

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

ISV(Independent Software Vendor) — незалежний постачальник ПЗ. Зазвичай так називають тих, хто розробляє пакети для AppExchange.

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

Application (App) — у контексті Salesforce цей термін є багатозначним. Найчастіше App-кою називають набір згрупованих вкладок, рідше App — це автономна Aura-аплікація, зовсім рідко вживають у значенні Package.

SaaS — Software as a Service — модель, всередині якої програмне забезпечення поставляється не інсталяційним пакетом або виконуваним файлом, а здебільшого у вигляді вебзастосунку, під капотом якого приховано хмарне рішення.

PaaS — Platform as a Service — модель надання послуг, яка дає змогу швидко розгортати та масштабувати сайти або сервіси, не надто турбуючись про налаштування. Компанія, що надає PaaS-послуги, бере на себе відповідальність за сам процес розгортання.

Готові рішення Salesforce

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

Дохід від найбільш прибуткових Salesforce Clouds (©). На 2021 рік аналітична платформа Statista прогнозує зростання доходу Salesforce на 25%

У таблиці нижче наведено огляд найпопулярніших рішень Salesforce.

Є безліч інших рішень для конкретних сфер застосування. Government Cloud призначений для державних організацій, Healthcare Cloud об’єднує в єдину мережу пацієнтів і постачальників медичних послуг. Vaccine Cloud, побудований на основі Experience Cloud та інтегрований з Government Cloud, дає змогу швидко знайти клініку для вакцинації, а уряду й медичним установам спростити сам процес. Для благодійних організацій розроблено Non Profit Cloud, він же Nonprofit Success Pack, або NPSP, що надає десять безкоштовних ліцензій. Крім того, є Education Cloud, Industries Cloud, Financial Service Cloud, Commerce або B2C Commerce Cloud, що активно інтегрується з CMS; Analytics Cloud — з Tableau; Integration Cloud — з інтернет-шиною Mulesoft.

Інший Salesforce-функціонал

• Force.com sites — PaaS-сервіс, призначений для спрощення розробки та розгортання хмарних застосунків і вебсайтів.
• Chatter — корпоративний месенджер, продукт сторонньої компанії, поглиненої Salesforce. Допомагає швидко створювати чатботів, але, можливо, в компанії його вважають застарілим. З цим може бути пов’язане придбання Slack.
• Omni channel — центр, що об’єднує різні канали спілкування з клієнтами.
• Einstein™ AI — штучний інтелект від Salesforce, здебільшого відповідає за аналіз даних на вашій Salesforce-орзі. Дуже обмежений у програмній взаємодії, вона майже цілком зводиться до налаштування та адміністрування.
• Вбудовані інтеграції з продуктами Google (Gmail, Calendar, Contacts, Drive), Microsoft (Outlook) та Amazon, зокрема з AWS, де є можливість налаштувати private connect в обхід HTTP/HTTPS-трафіку.

Salesforce з погляду розробника

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

У Salesforce можна міняти бекенд, фронтенд і навіть модель бази даних. Є можливість для декларативного програмування, до того ж вбудованих інструментів багато. Звісно, нюанси та обмеження все ж існують, поговоримо про них піде далі.

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

Систему, побудовану на хмарних технологіях, навіть встановлювати на локальний сервер не потрібно. Salesforce бере на себе всю відповідальність за налаштування і підтримку серверів, архітектура його CRM є багатошаровою та розподіленою: основні сервери розміщені у CША, Великобританії, Німеччині, Франції та Японії, а ті, що працюють на AWS-інфраструктурі, — у США, Канаді, Індії та Австралії. Бази даних одного клієнта зберігаються на одному сервері, але є інформація, що ці дані зберігаються в одній базі з даними інших клієнтів. Проте зі зрозумілих причин компанія неохоче розповідає про те, як організовано зберігання інформації, і взагалі намагається тримати в таємниці максимально багато технічних деталей.

У Salesforce є Mobile SDK для створення кастомних Android та iOS-застосунків для інстансів клієнтів. Крім того, є офіційні аплікації.

Модель бази даних

Система містить низку вбудованих об’єктів, з повним списком ознайомтесятут. Можна створювати і свої — кастомні. Наприклад, у версії Unlimited Edition є змога зробити 2000 штук, а ще 1000 встановити як частину пакетів. У Salesforce об’єкт, який можна зберегти у базі даних, називають SObject, його аналог у реляційній базі даних — таблиця. Здебільшого об’єкти у Salesforce створюються через UI-інтерфейс чи Metadata API. Крім того, SObject робиться автоматично на основі даних, імпортованих з електронних таблиць.

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

Для створення мовних версій використовують інструмент Translation Workbench. Під час розробки кастомних компонентів рекомендують виносити всі надписи у Custom Labels, які підтримують багатомовність. Є підтримка різних валют з прив’язкою до курсу на конкретну дату.

У Salesforce аналогом колонок таблиці БД слугують поля. Виділяють такі типи:

• Auto Number — автоматично нумерує запис, дозволяє створити шаблон.
• Checkbox — може приймати значення true/false.
• Currency — тип валюти, представлений в ISO-стандарті.
• Date — дата зберігається у GMT, але показується відповідно до часової зони користувача, який переглядає поле.
• Date/Time — аналогічно до попереднього, але дає змогу зберігати й час.
• Email — призначений для зберігання електронних адрес.
• External Lookup Relationship — спеціальний тип зв’язку, що використовують для інтеграції із зовнішніми системами.
• Formula — значення для поля-формули не зберігаються в базі даних, а обчислюються безпосередньо в момент доступу до нього. Тут виділяють такі підтипи: Checkbox, Currency, Date, Date/Time, Number, Percent, Text, Time.
• Geolocation — дозволяє зберігати координати: широту та довготу.
• Hierarchical Relationship — спеціальний тип зв’язку, доступний для об’єкта User.
• Indirect Lookup Direction — спеціальний тип зв’язку між зовнішніми об’єктами.
• Lookup Relationship — слабкий тип зв’язку.
• Master-Detail Relationship — сильний тип зв’язку, коли child (detail) успадковує від parent (master) власника налаштування загального доступу. Під час видалення master запису автоматично видаляється і detail.
• Number — числовий тип дає змогу зберігати до 18 цифр (наприклад, 18 цифр цілого числа або 16 цифр цілої частини плюс дві цифри дробової частини).
• Percent — для зберігання відсотків, по-різному відображається на UI, у формулах і Apex-коді.
• Phone — поля для телефонних номерів, по суті текстові.
• Picklist — назва dropdown у Salesforce. Хоча база даних тут вважається нормалізованою, вона охоплює тип поля, який суперечить вимогам до нормалізованих БД.
• Picklist (Multi-select) — ще один тип, якого не має бути в нормалізованій базі даних. Зберігає значення для multi select combobox, у базі даних вибрані значення зберігаються у вигляді текстового поля та розділяються за допомогою крапки з комою.
• Roll-Up Summary — спеціальний тип поля, доступний лише на master-об’єктах, проводить обчислення через функції агрегації (COUNT, SUM, MAX, MIN). Значення детермінованих функцій зберігаються в базі даних, інші перераховуються під час зміни пов’язаних detail-записів.
• Text — текстове поле, що дозволяє зберігати до 255 символів.
• Text (Encrypted) — текстове поле, яке кодується за допомогою 128-бітного AES-ключа, обмежене 175 символами.
• Text Area — поле, обмежене 131 072 символами, підтримує символи табуляції.
• Text Area (Rich) — дає можливість зберігати текст обсягом до 131 072 символів, відформатований за допомогою HTML, підтримує обмежений набір тегів.
• Time — найновіший тип поля, призначений для зберігання часу.
• URL — призначений для зберігання гіперпосилань.

Невдовзі має з’явитись новий тип поля Address.

Email, Number і Text поля можна використовувати як External ID, що особливо зручно під час міграції даних та інтеграціях.

Для реалізації зв’язку «багато до багатьох» створюються Junction Objects, які мають два Master-Detail Relationship поля. Власне, два — максимум для цього типу поля на одному об’єкті.

Для полів у Salesforce є вбудована підтримка політики приватності, зокрема GDPR. Для текстових закодованих полів передбачений Classic Encryption (128-бітне AES-шифрування). Також є платний Salesforce Shield, який не обмежується текстовими полями та використовує 256-бітне AES-шифрування.

Крім того, є вбудована система доступів на рівні об’єктів, полів, записів. Записами можна ділитися автоматично, наприклад, за допомогою sharing rules і Apex managed sharing або вручну.

Якщо у вас накопичилися мільярди записів, то для Big Data є Salesforce Big Objects.

Докладніше про типи полів можна прочитати у статті Custom Field Types, про види зв’язків між об’єктами — у Different types of relationships in Salesforce.

Бекенд

Коли говорять про бекенд, найчастіше приділяють увагу Apex-класам і тригерам. Рідше — функціоналу на Heroku чи інтеграції за допомогою платформ MuleSoft і DellBoomi. Ще рідше під цим терміном мають на увазі кастомні ETL-рішення.

Нещодавно Salesforce оголосила про запуск Salesforce Functions, проте ця послуга поки на стадії beta-тестування. Це FaaS-інструмент (Functions-as-a-Service), який дає змогу писати бекенд-рішення за допомогою не лише Apex, а й інших мов програмування, та безшовно інтегрувати їх з вашим Salesforce-інстансом.

Apex

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

Ось приклад Hello World, написаного на Apex:

System.debug(‘Hello World!’);

В основі Salesforce — transaction based і event-based архітектура, але підтримується і можливість запуску коду на вимогу, відповідно до завчасно запланованого із користувацького інтерфейсу, або за допомогою CRON expression. Наприклад, static змінні будуть зберігатися лише у контексті однієї транзакції (скажімо, під час створення запису та всіх викликаних ним синхронних і деяких асинхронних дій).

Мова містить такі види даних:

• Примітивні: Blob, Boolean, Date, Datetime, Decimal, Double, ID, Integer, Long, Object, String, Time.
• SObject — стандартні та кастомні об’єкти, які зберігаються в базі даних.
• Колекції: List, Set, Map.
• Типізований список значень (enum).
• Користувацькі Apex-класи.
• Визначені системою Apex-класи.
• Null.

Усі види даних успадковуються від Object, усі стандартні та кастомні об’єкти — від SObject.

Так, Salesforce має лише три типи колекцій. Масиви (Arrays) та списки (List) — тут фактично одне й те саме. Але ніхто не забороняє вам створювати власні імплементації інших колекцій, зокрема для цього передбачений інтерфейс Iterator. З досвіду скажу, що найчастіше доводиться імплементувати multi map.

Щодо об’єктно-орієнтованості в Salesforce теж є специфіка: ви можете створювати класи, абстрактні класи та інтерфейси. Наприклад, в інтерфейсі не можна ставити сигнатури властивостей (property), але це не єдине обмеження. Тут є змога визначати конструктор класу, ініціалізатор класу, але, наприклад, немає можливості визначити деструктори.

Для роботи з базою даних є DML (Data Manipulation Language), SOQL (Salesforce Object Query Language) і SOSL (Salesforce Object Search Language). Для маніпуляцій із записами не треба встановлювати з’єднання з базою даних чи створювати DTO-класи. Це, мабуть, найбільша перевага під час роботи з базою даних Salesforce.

DML — мова маніпуляції даними. Підтримує операції: insert, update, upsert, delete, undelete, merge. DML працює з одним записом або списком SObject-записів, створених користувачем програмно або отриманих за допомогою SOQL.

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

SELECT Id, Name, (SELECT Id, Name FROM Contacts) FROM Account

Тут контакти пов’язані з компанією за допомогою lookup поля AccountId, а назва зв’язку в конкретному випадку — Contacts.

SOQL може повертати:

• Один запис (якщо є LIMIT 1 або у WHERE вказується конкретне ID).
• Порожній список SObjects, Custom Setting чи Custom Metadata Types (коли заданим критеріям не відповідає жоден запис).
• Список SObjects, Custom Setting чи Custom Metadata Types.
• Агреговані результати чи просто число (наприклад, для функції агрегації COUNT).

Для оптимізації запитів є можливість індексувати поля, а деякі типи полів індексуються автоматично.

SOSL — мова запитів, призначена суто для пошуку. Використовується значно рідше за SOQL, особливо корисна під час написання глобального пошуку. Приклад SOSL-запиту:

FIND {"Joe Smith" OR "Joe Smythe”} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

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

Governor Limits

Оскільки Apex працює в середовищі багатошарової архітектури, виконання Apex-коду суворо обмежується, щоб унеможливити монополізацію ним спільних ресурсів. Обмеження накладається майже на все в контексті однієї транзакції: кількість пошукових запитів за допомогою SOQL; кількість SOSL-запитів, які вони повертають; кількість DML-операцій, Heap size, CPU Time тощо. Для асинхронного Apex ці обмеження є не такими суворими.

Докладніше про Governor Limits можна прочитатитут.

Вписатися в обмеження допоможуть Apex Design Best Practices.

Асинхронний Apex

Є такі типи асинхронного Apex:

• Future — використовують для порівняно коротких callouts (до 60 секунд).
• Continuation — для тривалих callouts, доступний і для VisualForce, і віднедавна для Aura та LWC.
• Batch — дає змогу асинхронно обробляти великі обсяги даних, обійти Governor Limits.
• Queueable — як і Batch, застосовують для обробки великого обсягу даних. Головна перевага перед Batch — можливість викликати інший Queueable, тобто сформувати ланцюжок.
• Schedualble — дозволяє запускати код у певний час і з певним інтервалом.

Подійно-орієнтована архітектура

Для побудови Event-based архітектури застосовують Platform Events (publish-subscribe модель для взаємодії із зовнішніми застосунками, також використовують для винесення ресурсоємного функціонала), Change Data Capture Events (використовують для обробки змін записів), звичайні та асинхронні тригери.

Безпека і контроль доступу

У профайлі користувача можна надати або забрати доступ до Apex-класу. Як і багато C-подібнихмов програмування, Apex має такі модифікатори доступу: private, protected, public. Крім них, є global, який найчастіше використовують під час розробки сторонніх пакетів, рідше — для імплементації деяких стандартних інтерфейсів.

Коли ви оголошуєте клас, можете вказати ключові слова: with sharing (усіх sharing rules, CRUD, FLS буде дотримано), without sharing (код матиме доступ до всіх записів і цілковитий доступ до CRUD і FLS), inherited (означає, що sharing mode класу залежатиме від sharing mode класу, який його викликав).

Приклад оголошення класу:

public inherited class AccountService {}

Веб та Email-сервіси

За допомогою Apex можна розробити повноцінні SOAP, REST-based Web та Email-сервіси. Наприклад, для параметрів і значень, що повертаються, Apex REST підтримує такі види даних:

• Примітиви Apex (виключаючи Object і Blob).
• SObjects.
• Списки або map примітивів Apex чи SObjects (підтримуються тільки map із текстовими ключами).
• Типи, що визначаються користувачем та містять змінні — члени вищеперерахованих типів.

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

Юніт-тести

Код на Production-орзі не можна редагувати безпосередньо, тому принцип «раз-раз і в продакшен» тут не спрацює. Код пишеться й тестується, наприклад, на Sandbox, а на Production він лише деплоїться. До того ж весь код на Production має бути покритим юніт-тестами не менше ніж на 75% та не валитися при розгортанні, принаймні локальні тести мають працювати без помилок. Для деплойменту Sandbox => Sandbox таких вимог немає.

Налагодження

Для налагодження Apex-коду існують Debug Logs з різними рівнями логування. Можна створити Traced Flags для: 1) автоматизованого процесу; 2) Platform Integration; 3) конкретного користувача; 4) Apex-класу; 5) Apex-тригера. У коді для кращого налагодження варто ставити breakpoints.

Apex-тригери

Є можливість створювати before та after тригери для наступних DML-операцій: insert, update, delete, undelete (відновлення запису, раніше видаленого в кошик). Для операції undelete можна визначити тільки after тригер. Залежно від операції доступні такі контекстні змінні: Trigger.new (List зі зміненими значеннями), Trigger.old (List зі значеннями до зміни), Trigger.newMap (Map — те саме, що Trigger.new, тільки у вигляді Map), Trigger.oldMap (Map — те саме, що Trigger.old, тільки у вигляді Map) та інші. Upsert DML операція — це мікс Insert і Update, merge — мікс Update і Delete.

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

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

Кожен Salesforce-розробник має пам’ятати про Order of execution. Оскільки під час DML-операціїзапускається не лише тригер, а й безліч іншого декларативного функціонала, в окремих випадках це може викликати рекурсію та, як наслідок, вихід за Governor Limits. Докладніше про порядок виконання можна прочитатитут.

Замість висновку

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

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

Продовження огляду — у наступній частині. Скоро на DOU :)

Вітаю, колеги. Мене звати Андрій Трубіцин, я співпрацюю з ЕРАМ у ролі Senior Solution Architect. Мої робочі завдання передбачають документування архітектури рішень. Багато документування... Без діаграм у цій справі ніяк. Пропоную в статті розібрати деякі аспекти використання статичних і динамічних діаграм для документування архітектури, процесів тощо.

Чому не варто нехтувати візуалізацією

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

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

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

Загальна інформація

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

Як приклад розглянемо, які типи статичних і динамічних діаграм пропонує UML.

UML-діаграми

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

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

Розглядаємо деталі. Статичні діаграми

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

Статична Context-діаграма

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

Статична діаграма розгортання у хмарі Amazon

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

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

Статична модульна діаграма

Розглядаємо деталі. Динамічні діаграми

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

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

Use Case діаграма

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

Я завжди використовую такі діаграми, коли процес створення сервісу чи нового функціоналу дещо складніший за CRUD (тобто create, read, update, delete). Під час розмови з клієнтом намагаюсь робити чернетку діаграми процесу і демонструю її під час бесіди. Часто замовник пам’ятає основні моменти, але забуває про деякі corner cases (наприклад, що робити, коли крок закінчився невдало, як реагувати на помилки). Саме завдяки Activity-діаграмі можна побачити, що не всі шляхи ведуть до завершення процесу або що на якихось кроках бракує інформації для ухвалення рішення тощо.

Звичайно, створення динамічних Activity (або Business Process Model and Notation) діаграм потребує навичок і знання сили-силенної позначок і символів як від вас, так і від клієнта.

Activity-діаграма пошуку та купівлі онлайн

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

Статична Component Auth 2.0 діаграма

Але статичну діаграму використовують для іншого. Її завдання — показати, що є три компоненти, інтеграція і напрямок інтеграції задано. Якщо дати цю діаграму для імплементації комусь, хто не працював з Auth 2.0, то ви отримаєте купу запитань і затримки у впровадженні. Також під час оцінювання обсягу робіт менш обізнаний розробник може подумати, що тут тільки три звернення між компонентами. В той час як насправді все по-іншому. Це стане очевидно, коли ми поглянемо на динамічну Sequence-діаграму:

Динамічна Sequence-діаграма Auth 2.0 аутентифікації через KeyCloak

Тут уже видно, що логіка набагато складніша й оцінювання часу на створення продукту буде вже зовсім іншим. Та навіть цю діаграму можна вдосконалити та додати URL-шаблони для запитів. Найцінніше те, що динамічні Sequence-діаграми задають порядок запитань між компонентами для реалізації складної логіки, а ще з’являється розуміння, як тестувати таку систему. Звичайно, це приклад і майже кожен інженер має досвід роботи з Auth 2.0, але якщо у вашому проєкті є складний алгоритм чи потреба в оркеструванні процесу, який не вартий окремої Activity-діаграми, але все ж таки складний, то Sequence-діаграми стануть у пригоді.

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

Jaeger Tracing Dashboard

Кілька рекомендацій до візуалізації

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

Немає сенсу малювати дуже велику «діаграму всього».Якщо проєкт великий, така діаграма буде зовсім нечитабельною і складною для підтримки. Інколи її можна намалювати для себе один раз, щоб зрозуміти весь ландшафт рішень та їхню взаємодію. Але загалом мені подобається підхід Carnegie Mellon Software Engineering Institute (SEI). Він пропонує використовувати метод «точки зору» та зрізу системи. Відповідно до цього варто створювати діаграми, які служать одній меті та відображають обмежений набір елементів системи. Наприклад, щоб описати дизайн безпеки інфраструктури в AWS, ви можете зосередитися на групах безпеки, листах контролю, політиках безпеки сервісів та їх ролях, вказуючи протоколи обміну даних, назви ключів, сертифікатів, алгоритми шифрування тощо. Точно немає сенсу зображати на такій діаграмі, наприклад, розмір дисків, кількість процесорів, обсяг оперативної пам’яті тощо.

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

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

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

Наостанок поділюсь кількома корисними джерелами:

• Специфікаціямови моделювання UML.
• Приклади UML-діаграм.
• Специфікаціямови моделювання BPMN.
• Documenting Software Architectures: Views and Beyond 2nd Edition.

Тема діаграм широка. Маєте що додати з власного досвіду? Пишіть у коментарях. Буду радий конструктивній дискусії.