Всем привет! Понемногу включаемся в рабочий режим после праздников. Сегодня в выпуске: серия роликов Growth Master от Segment, как использовать social proofs для своего бизнеса, контент-фреймворки для стартапа и многое другое.

Почитать

60+ Important 2019/2020 Mobile Marketing Statistics. Мы можем с уверенностью сказать, что живем в мобильном мире. Это не то, что приближается, это происходит прямо сейчас. Udonis подготовила отчет со статистикой маркетинга мобильного рынка за 2019 год.

SEO for Startups: 7 High-Converting Content Frameworks. Сложно создавать контент, который будет не только повышать awareness вашего продукта, но и приносить продажи. В статье приведены фреймворки, которые стартапы могут использовать для привлечения пользователей из поисковых систем с высокой вероятностью конверсии.

The three strands of brand authenticity | Inside Intercom. Одним из главных определяющих факторов успеха компании является ясность ее послания и то, как эта ясность проявляется во всех взаимодействиях между продуктом и брендом. Intercom рассказывает, как они «делают интернет-бизнес персональным».

Power Up Your Website: 15 Must-Haves for Social Proof. Существует бесконечное множество техник, которые влияют на решения пользователя о покупке. Одним из самых важных является social proofs. В статье детально описано, что это такое и как это использовать для своего бизнеса.

Behavior-Based Attribution Using Google BigQuery ML. В статье от CXL рассказывается, как раскрыть весь потенциал сырых данных и начать использовать Google BigQuery ML, чтобы строить атрибуцию с помощью всего лишь небольшого количества SQL — без знания Python или R.

SaaS Landing Pages You Should Run at All Times. Unbounce рассказал о 5 лендингах, которые постоянно должны быть в арсенале SaaS-маркетолога.

Content Marketing in 2020: The Definitive Guide. С каждым годом все больше компаний инвестируют ресурсы в контент-маркетинг. В гайде от backlinko вы найдете ответы на такие вопросы: как создавать и продвигать свой контент, какие форматы работают сейчас.

Послушать

Pursuing a Mission While Bootstrapping to Millions with John O’Nolan of Ghost — The Indie Hackers Podcast. Фаундер Ghost делится мыслями о настоящем и будущем издательского дела, создании контента и почему он решил запустить non-profit проект.

Жизнь в Сингапуре, контент-маркетинг и отказ от аналитики с Tim Soulo, CMO в ahrefs. Тим рассказывает, как устроен маркетинг в ahrefs, почему они не используют Google Analytics и Facebook Pixel, а также как делать контент-маркетинг в 2020.

Посмотреть

В видео от Product School Нейт (Product Manager в Amplitude) делится советами и инструментами, которые помогают создавать продукты нового поколения.

Три совета по управлению заинтересованными сторонами от Чарльза Вонга, Senior Product Manager в WeWork.

Growth Masters. Segment запустил серию интерактивных видеороликов для продактов и маркетологов Growth Masters, в которых много отличного (и бесплатного!) контента. Очень крутые лекторы: Эндрю Чен, Густав Альстромер и Лекс Роман и многие другие. Охватывает такие темы, как привлечение, онбординг и исследования пользователей.

Спасибо, что дочитали до конца. Увидимся в следующем выпуске!

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

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

Привіт, мої любі сішники! Вітаю вас з Новим роком та Різдвом! Нехай у цьому році код стає якіснішим, компіляція швидшою, а проекти цікавішими! ;)

Новорічний випуск пропоную присвятити підсумкам року та оптимізації компіляції. То ж почнімо? :)

Підсумки 2019

C++ at the end of 2019 — детальний підсумок в подіях та фактах.

На Meeting C++ запущено опитування, за яким маємо такі цікаві результати (результати актуальні на 10 січня та можуть змінюватися в зв’язку з тим, що опитування ще триває).

Найчастіше зі стандартів використовуються:

Бібліотеки:

Середовище:

Оптимізація часу компіляції

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

Герб Саттер для вирішення цієї проблеми пропонує перевірити хедерита використовувати Pimpl, як і хлопці в цьому блозі:

• Reduce C++ Build Times by Reducing Header Dependencies,
• Reduce C++ Build Times (Part 2) with the Pimpl Idiom.

Онлайн книга С++ best practices пропонує більш розширений список рекомендацій.

З цієї теми корисно буде почитати:

• Faster C++ builds;
• Speeding up the Build of C and C++ Projects;
• A simple comparison;
• Making Compiles Slow Through Abuse of Templates.

Відео з CppCon:

• Optimizing compilation times with Templates
• Practical Techniques for Improving C++ Build Times

Modern C++

C++20: Concepts — What we don’t get

C++20: Concepts, the Placeholder Syntax

C++ coroutines: Getting started with awaitable objects

A beginner’s guide to C++ Ranges and Views

Корисні посилання

Substitution Failure is Error and Not An Error

Named Template Arguments

What Is MISRA and how to Cook It

Modern C++ type CoDec Challenge

Dry-comparisons: A C++ Library to Shorten Redundant If Statements

Accidentally Overwriting Another Local Variable in C and C++

A Compiler Writing Journey

The Eight Rules of Multithreaded Qt

Open sourcing Google Cardboard

Waiting for std::embed: Very Large Arrays in Clang

C++ UI Libraries

Інструменти

Top 10 Bugs Found in C++ Projects in 2019 PVS studio

CMake 3.16 added support for precompiled headers & unity builds

The Qt Marketplace has landed

A Gentle Intro to Developing C++ Apps for AWS and S3

CLion: Our Plan for Next Year and the 2020.1 Roadmap

Build C++ Applications in a Linux Docker Container with Visual Studio

Оновлення

Цього місяця маємо такі оновлення:

• CLion 2019.3;
• Wt & JWt 3.5.0 and Wt 4.2.0;
• Ogre 1.12.4;
• boost v.1.72.0;
• Qt 5.9.9, Qt Installer Framework 3.2.0, Qt 5.14, Qt Visual Studio Tools 2.4.2;
• Conan 1.21;
• Unreal Engine 4.24;
• CryEngine 5.6.5;
• Announcing NVIDIA PhysX SDK 5.0;
• Nsight Systems 2019.6;
• ReSharper C++ 2019.3;
• PVS-Studio 7.05.

Хвилиночка флуду

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

З 2 грудня до 5 січня ми проводили чергове анонімне зарплатне опитування, в якому взяли участь 10 187 ІТ-спеціалістів. Як і влітку, результати публікуватимемо у трьох частинах: зарплати розробників, зарплати тестувальників та зарплати інших технічних і нетехнічних спеціалістів.

У цій статті розглядаємо зарплати розробників, їх серед опитаних — 4921 спеціаліст. До розробників відносимо Software Engineer, TechLead і System Architect. Також цього разу ми дещо оновили анкету і для програмістів додали можливість обрати додаткову мову програмування й фреймворк/бібліотеку, що використовуються на поточній посаді.

Усі зарплати вказані в доларах США (за курсом міжбанку), чистими (після сплати податків). Для оцінки зарплат у вибірках використовується медіана. Статті з результатами минулих опитувань тут. Дані на GitHub та у віджет заллємо десь за тиждень.

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

Середні зарплати

У всіх категорій, окрім Software Engineer, за останні півроку середня зарплата по Україні зросла: +$200 у Software Architect, +$150 у TechLead, +$100 у Senior Software Engineer і +$50 у Junior SE. У Software Engineer зростання відбулося у Києві, Харкові, Дніпрі й Запоріжжі, в інших містах середня зарплата SE або не змінилася, або навіть зменшилася (в Одесі — -$220, у Вінниці — -$100).

Динаміка

Середні зарплати Senior-ів у Києві досягли позначки $4000, і це на $500 і $250 вище, ніж у Харкові і Львові відповідно. Щодо джуніорів, то найменше (серед топ-5 міст) отримують початківці у Харкові ($600), а найбільше — у Києві ($840).

За посадами

Доволі висока середня зарплата розробників в Івано-Франківську — $2000. В той час як в Одесі середня зарплата — $1550.

Цікаво, що середня зарплата Kotlin-розробників у Києві і Львові на $800 вища, ніж у Харкові. Вища за харківську й середня зарплата львівських JavaScript-розробників — на $185.

За містами

Середня зарплата Senior Scala за півроку зменшилася на $200, але все одно залишається найвищою серед інших мов програмування. Серед Software Engineer найнижча середня зарплата у 1C-розробників ($1400), а найвища у Go ($2800).

За мовами програмування

Середня зарплата Senior-розробників у продуктовій компанії на $400 вища, ніж в аутсорсинговій. Більше у продукті отримують і джуніори — $800 проти $700 в аутсорсі та $600 у стартапі.

За типом компаній

Найвищі середні зарплати серед випускників ДонНТУ, КНУ ім. Шевченка та НТУУ «КПІ» — у всіх по $3000. Серед студентів, що вже працюють, найвищі зарплати у тих, хто навчається у ДНУ ім. Гончара, НТУ «ХПІ», Львівській політехніці та КНУ ім. Шевченка — понад $1000. Найнижча середня зарплата у студентів ЛНУ ім. Франка — $600.

За вишами

Середні зарплати: динаміка, фреймворки й порівняння

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

Java

Почнемо з Java, за останні півроку лише позитивна динаміка: середня зарплата Junior SE зросла на $68, SE — на $100, Senior SE — на $130. А за останні п’ять років середні зарплати збільшилися на $68, $325 і $600 відповідно.

Динаміка середніх зарплат Java

Щодо фреймворків і бібліотек, то найпопулярнішими серед Java-розробників є Spring і Hibernate (601 і 346 анкет). Всі інші варіанти зібрали суттєво менше відповідей. А ось найвищі середні зарплати у тих, хто використовує в роботі Play, Apache Spark, Node.js.

Серед додаткових мов програмування найбільш популярними у Java-розробників є JavaScript, SQL і Kotlin. А ось найвищі середні зарплати у тих, хто, окрім Java, ще використовує Go і Python — $3400 і $3100 відповідно. Цікаво, що майже кожен третій Java-розробник не використовує додаткову мову програмування на поточній роботі.

Середні зарплати Java-розробників з розбивкою за фреймворками та додатковою мовою програмування

JavaScript

Переходимо до JavaScript, за останні півроку середня зарплата Junior SE зросла на $50, а SE — на $100. Середня зарплата сеньорів з червня не змінилася, але за останні п’ять років вона збільшилася на $775. А от у джуніорів навпаки з 2014 року негативна динаміка — середня зарплата зменшилася з $750 до $650.

Динаміка середніх зарплат JavaScript

Серед найбільш популярних фреймворків і бібліотек у JavaScript-розробників: React.js (792 анкети), Node.js (559), Angular/Angular.js (409), Vue.js (212), Express (188), jQuery (168), React Native (158). Найвищі середні зарплати серед цих інструментів у Node.js ($2250), Angular/Angular.js ($2100) і Express ($2000).

70% JavaScript-розробників використовують на поточній роботі лише одну мову програмування. Серед тих, хто використовує додаткову мову, найбільш популярною є PHP (119 анкет). Але, схоже, що на рівень зарплати це не впливає: середня зарплата JS-розробників, що використовують PHP, на $200 нижча, ніж тих, хто використовує лише JavaScript.

Середні зарплати JavaScript-розробників з розбивкою за фреймворками та додатковою мовою програмування

C#/.NET

Серед C#/.NET середня зарплата за півроку зросла лише у джуніорів — на $100. У SE і Senior SE середня зарплата не змінюється вже рік.

Динаміка середніх зарплат C#/.NET

.NET (544 анкети), .NET Core (472) і ASP.NET (437) — найбільш популярні платформи серед .NET-розробників. Також доволі популярний фреймворк Angular/Angular.js — 195 анкет. Але найвищі середні зарплати у тих, хто, окрім стандартних платформ, використовує у роботи React.js ($3000) і Xamarin ($2700).

Майже половина .NET-розробників використовує JavaScript як додаткову мову програмування. Але найвищі зарплати серед тих, хто додатково працює з SQL — $2500 проти $2000 серед тих, хто використовує лише C#.

Середні зарплати C#/.NET-розробників з розбивкою за фреймворками та додатковою мовою програмування

PHP

За останні півроку зарплати PHP розробників практично не змінилися — лише трішки зросла середня зарплата джуніорів (на $50).

Динаміка середніх зарплат PHP

Laravel (262 анкети), jQuery (214), Vue.js (122) — найпопулярніші фреймворки і бібліотеки серед PHP-розробників. 70% респондентів використовують JavaScript як додаткову мову програмування.

Середні зарплати PHP-розробників з розбивкою за фреймворками та додатковою мовою програмування

Python

Зарплата Senior Python за півроку не змінилася, проте вона суттєво зросла у першому півріччі (на $500). Цікаво, що за останні п’ять років середня зарплата Senior SE виросла на $1100, а ось SE і Junior SE лише на $200 і $100 відповідно.

Динаміка середніх зарплат Python

Серед найбільш популярних фреймворків у Python-розробників — це Django (169 анкет) і Flask (127). Щодо додаткових мов програмування, то частіше за інші розробники на Python використовують в роботі JavaScript, але найвища середня зарплата у тих, хто має у своєму арсеналі Go — $2700.

Середні зарплати Python-розробників з розбивкою за фреймворками та додатковою мовою програмування

C++

На $250 зросла середня зарплата Senior С++ розробників за останні півроку. Також на $100 збільшилася зарплата Junior C++ і досягла позначки $900. Наразі вона найвища серед зарплат джуніорів за основними мовами програмування.

Динаміка середніх зарплат C++

Найпопулярніша додаткова мова програмування — Python (40 анкет). Стільки ж респондентів сказали, що використовують лише основну мову — C++. Найвищі зарплати у тих, хто додатково працює ще і з Java — $3625.

Середні зарплати C++ розробників з розбивкою за фреймворками та додатковою мовою програмування

Ruby/Rails

Середня зарплата Junior Ruby/Rails-розробників зросла чи не найбільше серед основних мов програмування — на $225 за півроку. Зарплати Software Engineer і Senior Software Engineer також виросли, хоч і скромніше, ніж у джунів, — на $75 і $100 відповідно.

Динаміка середніх зарплат Ruby/Rails

Swift

Усі категорії Swift-розробників демонструють негативну динаміку за останні півроку: якщо середня зарплата Software Engineer зменшилася на $50, то середня зарплата джуніорів і сеньорів на $175 і $100 відповідно.

Динаміка середніх зарплат Swift

Середня зарплата Swift-розробників, що додатково використовують Objective-C, майже в два рази вища, ніж у тих, хто використовує лише Swift.

Середні зарплати Swift-розробників з розбивкою за фреймворками та додатковою мовою програмування

Дані про кількість вакансій і відгуків дивіться в розділі «Тренди».

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

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

• Администрирование.
• Отчетность.
• Нефункциональные требования.

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

Администрирование

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

Прошло полгода, и когда «сдавали» систему, представители заказчика спросили: «А как нам управлять справочными данными?» Дело в том, что один из основных справочников системы имел более 10 000 записей (вот вам и подводный камешек). А обновление данных должно было происходить не реже чем один раз в час. Также необходимо было реализовать синхронизацию данных пользователей системы из active directory.

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

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

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

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

Управление справочниками системы

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

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

Пример описания атрибутов я приводил во второй части статьив разделе «Объектно-ориентированная модель», данный подход использую и для описания атрибутов для обмена.

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

Управление учетными записями, ролями и полномочиями

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

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

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

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

Архивирование и восстановление объектов

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

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

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

При проработке требований к хранению удаленных объектов следует учитывать:

• Как и кто может восстанавливать данные?
• Какой срок хранения удаленных документов?
• Есть ли ограничения по объему удаляемого документа?

Журналирование действий пользователей

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

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

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

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

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

Отчетность

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

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

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

Итак, что я рекомендую учитывать при проработке требований к отчетности:

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

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

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

• Необходимо ли обрабатывать данные после отображения результата запроса?
• Есть ли необходимость хранить данные после получения (архив отчетов за период)? Если да, ВНИМАНИЕ: нужно более детально проработать требования к отчетности. Возможно, понадобится организовывать хранилище данных, а это совсем нетривиальная задача.

Источники данных

Для себя я выделяю три источника данных:

• Внутренняя — база данных системы.
• Внешняя — базы данных других систем.
  
• Гибридная — часть данных тянется из внутренней базы данных, а часть — из внешних.

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

• доступность данных на момент формирования отчета;
• производительность построения отчета.

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

Визуализация

Если вариант использования — «Для печати», рекомендую проработать так называемый визуальный макет, в котором есть:

• верхний колонтитул;
• заголовок (название отчета);
• тело отчета — основная часть;
• нижний колонтитул.

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

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

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

Самостоятельно реализовать сервис для визуализации данных будет трудозатратно. Уточните, какой ориентировочный срок и бюджет для реализации визуализации данных. Помните, что на рынке есть много хороших решений: PowerBI, Google Data Studio, Tableau и другие. Проанализируйте их.

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

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

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

Карта — представление показателей, связанных с географическими данными (страна, регион, город и т.д.)

А возможно, будет достаточно реализовать отображение графиков в Excel.

Источник

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

• возможность настраивать представление данных;
• навигацию между разделами отчета.

Дополнительные возможности

Отчеты могут иметь ряд дополнительных возможностей:

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

Нефункциональные требования

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

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

1. Runtime — это требования, которые описывают время работы системы.
2. Design time — это требования, определяющие аспекты проектирования системы.

К группе Runtime относят:

1. Доступность.
2. Надежность.
3. Время хранения данных.
4. Масштабируемость.
5. Удобство использования.
6. Безопасность.
7. Производительность.
8. Ограничения.

1. Доступность — требования ко времени непрерывной работы системы

Пример требований к доступности: система должна поддерживать режим 24*7 — круглосуточный режим работы.

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

Мне больше нравится, как это изложено в требованиях по доступности, ранжированных по девяткам:

Сразу скажу, все заказчики хотят доступность в шесть девяток, но когда начинаем прорабатывать аппаратную архитектуру, соглашаются на 95-99 :-D

2. Надежность

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

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

Ниже приведу несколько примеров:

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

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

3. Требования к времени хранения данных

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

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

При проработке архивирования данных не забывайте о возможных связях объектов вашей системы.

4. Масштабируемость

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

Как правило, выделяют два направления масштабирования:

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

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

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

5. Требования к удобству использования

Пример из реального документа с требованиями:

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

Когда я вижу подобное в требованиях, сразу задаю вопрос: какие критерии проверки удобства и дружественности интерфейса?

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

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

1. Шрифты:осмысленные размеры шрифтов и их поведение при адаптивном дизайне.
2. Адаптивность:проработайте размещение и поведение элементов системы при адаптивности. Максимальное и минимальное разрешение. Разрешение, при котором изменяется размещение элементов.
3. Ошибки:информативная обработка сообщений об ошибках. Недостаточно показать код ошибки — следует сообщить, что пользователю делать с этой ошибкой. А также потрудитесь отдельно проработать требования к страницам с информацией об ошибке.
4. Навигация:отдельно раскрывал эту тему во второйчасти статьи.
5. Поиск:для удобства пользователя поиск размещают практически на всех интерфейсах пользователя (я не говорю сейчас о диалоговых или информационных интерфейсах). Поиск информации может быть глобальным — в рамках всей системы, или локальным — в рамках определенного модуля, а также контекстным.
6. Кроссбраузерность:если у вас система работает через браузеры, опишите браузеры и их версии, на которых должна функционировать система. Тут важный аспект: чем больше браузеров, тем больше работы у разработчиков и верстальщиков, а также увеличивается время на тестирование.
7. Обработка отдельных элементов:к примеру, ссылки, которые посещал пользователь, должны отображаться не синим, а фиолетовым. Также необходимо указать коды цветовой гаммы: цвет активной ссылки — #0000FF, цвет посещенной ссылки — #800080

6. Требования к безопасности

Требования к безопасности бывают трех категорий:

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

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

Примеры требований с разграничением доступа:

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

Примеры требований, связанных с работой с приватными данными:

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

Примеры требований, направленных на снижение рисков от внешних атак:

• Обмен документами между компаниями холдинга должен выполняться только через сервисную шину предприятия.
• Веб-приложение должно использовать протокол https.

7. Требования к производительности

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

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

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

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

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

8. Ограничения

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

На одном из проектов мы с удивлением узнали, что у клиента есть ПК, на которых установлена ОС Windows XP c браузером IE 8, и это очень ограничивало нас в разработке, а именно — в выборе технологии реализации.

К группе Design time относят:

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

Требования к расширяемости

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

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

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

Требования к переносимости

В требованиях к переносимости описывают требования работы системы на разных платформах.

Переносимость системы включает:

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

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

Требования к взаимодействию

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

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

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

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

Зачастую для разработки API разработчикам достаточно описания данных в следующем виде:

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

При мапинге полей следует обращать внимание на совпадение типа полей и их длину (в таблице указал в скобках максимальное количество символов).

Требования к поддержке

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

Примеры функций:

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

Требования к возможности тестирования

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

Пример шаблона тест-кейсов:

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

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

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

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

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

Уверен, что моя статья, как минимум, натолкнет вас на размышления.

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

Гармонии вам и процветания! До новых встреч на страницах DOU!

Привіт, мене звуть В’ячеслав Колдовський, я Programming Mentor. У веб-розробці я з 1990-х,тепер працюю в SoftServe над навчальними проектами. Чверть століття я спостерігав за еволюцією вебу, бачив появу та смерть технологій, робив ставки в конкурентних війнах, мене завжди цікавило, куди воно все рухається, — саме про це хочу з вами поговорити, і розмова не буде короткою.

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

Перший веб-сайт побачив світ 6 серпня 1991 року. Це був набір примітивних веб-сторінок, які, власне, і презентували всесвітню павутину — World Wide Web. Цікаво, що він і досі доступнийза тією самою адресою, що й майже три десятиліття тому.

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

HTML

Як сам батько вебу — фізик-контрактор CERN Тім Бернерс-Лі — його уявляв, можна побачити на тому самому першому сайті: «The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents». У вільному перекладі звучить так: це така собі бібліотека документів, пов’язаних між собою гіперпосиланнями. Тобто мовиться про всього-на-всього документи, які подані у форматі гіпертексту та поєднані між собою гіперпосиланнями. Ключові терміни тут: «документи», «гіпертекст» та «гіперпосилання».

Цікаво, що Тім Бернерс-Лі не був автором ні ідеї, ні самого терміна «гіпертекст». Термін винайшов ще 1963 року Тед Нельсон, який працював над проектом Xanadu — спробою переосмислити поняття документа й роботою з інформацією взагалі. Xanadu — це проект усього життя Теда Нельсона, а його ідеї випередили час. Але як нерідко трапляється в реальному світі, успішним стає не оригінальний автор науково обґрунтованої рафінованої ідеї, що часто відірвана від реальності, а той, хто побачив, як поєднати ідею з реальністю, навіть пожертвувавши якимись її важливими принципами. Тут можна згадати класичний випадок, коли автор ООП Алан Кей жорстко розкритикував C++ як невдалу імплементацію його задумів: «Коли я винайшов ООП, то не мав на увазі C++». Те саме можна сказати й про винахід Теда Нельсона — йому не надто сподобалося, як його ідеї були зреалізовані у WWW. Ось цікаве відеоз 2008 року, де автор демонструє робочий прототип і пояснює ключові концепції свого проекту. Там на власні очі можна переконатися: воно дуже відрізняється від того, що зреалізував Тім Бернерс-Лі.

Крім концепції гіпертексту та гіперпосилань, варта уваги й імплементація веб-сторінок за допомогою HTML. Усі веб-розробники знають про сучасну п’яту версію HTML, але мало кому відомо, що першою формальною версією цієї мови є HTML 2.0, яка вийшла у форматі RFC аж у листопаді 1995 року. До того моменту як такого стандарту мови взагалі не було. Тім Бернерс-Лі запозичив ідею мови в SGML, але водночас досить вільно інтерпретував її, а тому веб-сторінки не були коректними SGML-документами, хоча й використовували синтаксичні конструкції мови, такі як теги та атрибути. Утім, версії HTML із другої по четверту будувалися як SGML-документи, однак уже в HTML5 від такої ідеї відмовилися. Для охочих залишається можливість зреалізувати веб-сторінки у форматі XHTML, але сенсу в тому небагато, бо виникають деякі побічні ефекти, наприклад селектори CSS стають чутливими до реєстру тощо. Історія показала, що ідея підтягнути HTML відповідно до SGML із самого початку була нелогічною, — схоже, треба вміти вчасно відрубати кінці минулих ідей і не тягти із собою в майбутнє ворох минулого — веб у цьому сенсі гарний антиприклад.

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

Якщо ж говорити про використання HTML як UI для аплікацій, то вона для цього мало пристосована, і, наприклад, будь-який звичний для UI елемент у формі табів та прив’язаних до них блоків сторінки просто відсутній у HTML. Те саме стосується «карусельки» з елементів чи відомого всім бургер-меню — звісно, їх усі можна зреалізувати, але не тільки засобами чистого HTML, що вкотре доводить: мова для цього не була задумана. Особливо цікаво, що таких елементів у чистому HTML немає дотепер, хоча й трапляються вони мало не на кожному сучасному сайті. Для дружнього до UI середовища було б логічним мати можливість програмно «намалювати» щось на екрані — досить дати координати й усе. Однак це не зовсім легко, бо не можна просто так узяти й намалювати щось поверх інших тегів сторінки, ми обмежені DOM-деревом і не можемо малювати «просто на сторінці», необхідно використати canvas, спозиціювати його тощо.

CSS

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

Вважається, що автором CSS є норвежець Гокон Лі (Håkon Wium Lie), який запропонував ідею Тімові Бернерс-Лі в жовтні 1994 року, а перша версія стандарту вийшла два роки після того. До CSS як такого поділу на представлення і контент в HTML не існувало, і ідею розділити обов’язки можна було б вважати геніальною, якби вона не була одним з фундаментальних принципів розробки програмних проектів. Але, як ми знаємо, зло ховається в деталях, і найбільше це стосується CSS. Іронічно, що сайт винахідника CSSне дуже добре виглядає ні на занадто широких, ні на вузьких екранах, і навіть валідатор CSS має до нього претензії.

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

Написання коду на чистому CSS приносить мало задоволення, особливо тому, що в ньому практично відсутні були механізми реалізації одного з найважливіших принципів розробки — DRY (Do Not Repeat Yourself). Донедавна змінних не існувало, для вкладених елементів DOM доводиться повторювати ланцюжки селекторів, а можливості перевикористовувати код, модифікуючи його поведінку залежно від певних умов, немає й тепер.

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

Узагалі CSS — такий потужний і гнучкий інструмент, що його часто застосовують не за призначенням, скажімо, виправляючи хиби HTML. Наприклад, у HTML є тег, який дозволяє зробити горизонтальну лінію, логічно було б мати тег, який робить вертикальну. Однак такого немає, і щоб намалювати вертикальну, доводиться креативити, багато хто робить це по-різному і використовує CSS. Водночас особливо цинічний випадок такого застосування — це трансформувати елемент горизонтальної лінії в лінію вертикальну. «Цинічний» — бо якщо сприймати код HTML семантично, то тег hr, що має створювати горизонтальну лінію, повинен створювати саме горизонтальну лінію. (Якщо говорити про семантично коректний підхід до того, як розв’язати це завдання, то тут ліпше створити власний елемент в HTML, стандарт це дозволяє, ось приклад).

JavaScript

Переходячи до, ймовірно, найцікавішої складової фронтенду, варто зробити відступ і запитати: а що робить мова програмування на фронтенді взагалі? Тут варто зазначити, що в 1990-хлюдину, яка займалася веб-сайтом, дуже часто називали веб-майстер, і далеко не завжди це була людина з навичками програмування. Якось на цю тему пожартував Кріс Коєр, засновник css-tricks.com: «Два фронтенд-розробники сидять поруч у барі. Їм ні про що говорити». І це не той випадок, коли хтось пише на React, а інший на Angular. Це радше про те, що один типовий програміст — з алгоритмічним мисленням, якому зручніше згенерувати весь контент динамічно та імперативно, досить лише отримати контейнер, а другий, навпаки, людина, для якої ближчою є семантика елементів, структура контенту, стилі, анімації тощо, тобто декларативний підхід. Якщо говорити про філософію, закладену в HTML, то саме другий підхід є коректнішим, хоч би як дивно це здавалося для декого з розробників сьогодні.

Джерело

Власне, сам Тім Бернерс-Лі жодної мови програмування всередині браузера не передбачав, тому не дивно, що історія її виникнення скидається на детектив. Компанія Netscape, заснована у квітні 1994-го,випустила першу публічну версію браузера Netscape Navigator з номером 0.9 у листопаді того самого року. Браузер стрімко почав набирати популярність, і вже за чотири місяці займав три чверті всього ринку.

Частка ринку браузера Netscape Navigator, 1994–2007

Засновник компанії Марк Андрессен вирішив, що HTML не вистачає саме легковагової скриптової мови програмування, код якої можна було б писати прямо в тексті веб-сторінок. Тож у квітні 1995 року він найняв Брендона Айка, який був тоді відомим фахівцем з мов програмування, для того щоб вбудувати мову програмування Scheme у браузер Netscape Navigator. Однак у мови Scheme досить специфічний синтаксис, а Sun тоді мала сильні ринкові позиції та активно просувала Java, тому однією з вимог, які висунув Брендон Айк до нової мови, була синтаксична подібність з Java. До вимог також належало, щоб мова була досить проста та не містила класів, тож для Брендона вона стала своєрідним челенджем — він вирішив зреалізувати в ній ООП, але без класів.

У Netscape прийнято було працювати дуже швидко, тому Брендон Айк розробив прототип мови за 10 робочих днів у травні 1995 року. Це справді дуже мало для того, щоб створити власну мову програмування з нуля, але, схоже, цілком досить, якщо базуватися на вже готових рішеннях. Саме тому нова мова запозичила синтаксис із Java, основну функціональність із Scheme, а реалізацію ООП із Self.

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

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

Діалог у твітері з Брендоном Айком стосовно блочної області видимості

Годі було 1995 року уявити, що одного дня JavaScript стане найпопулярнішою мовою програмування у світі. Власне, тоді, у 1990-х,старт JS серед розробників навряд чи можна було вважати вдалим, бо ця мова сприймалася як щось недосить серйозне, чим слід користуватися, коли треба замінити зображення, поверх якого рухається курсор миші, чи якесь інше схоже завдання.

Варто згадати про тогочасний тренд — уникати написання коду на фронтенді загалом і використовувати інструменти, що дають змогу конструювати сторінки візуально, а код генерувати автоматично. Серед таких інструментів — Vermeer FrontPage, що вийшов 1995 року (пізніше Microsoft FrontPage) та Macromedia Dreamweaver (пізніше Adobe Dreamweaver), який вийшов 1997-го.Можливість згенерувати код веб-сторінки з візуального її представлення отримав Adobe Photoshop. Тобто дуже часто фронтенд-частина сайту сприймалася як частина проекту, з якою працюють дизайнери — не програмісти, бо для останніх є бекенд.

До речі, програмування на бекенд прийшло значно раніше, ніж на фронтенд, там його місце здавалося логічнішим. Першою такою технологією, що давала змогу динамічно генерувати HTML, була технологія CGI (Common Gateway Interface), створена 1993-го,всього за два роки після запуску першого сайту. Зреалізована вона була дуже примітивно: HTTP-запит від клієнта направлявся на скрипт на сервері, який отримував параметри запиту та генерував відповідь, направивши її на стандартний вивід, що, власне, і отримував браузер у відповідь. CGI дозволяла писати код будь-якою мовою, досить було запустити її на сервері — хоч Perl, хоч C, однак загалом це робилося доволі трудомістко.

Справжнім проривом у веб-розробці стала поява PHP 1995 року — ця мова спеціально була створена для вебу й давала змогу органічно поєднати HTML та синтаксично близьку до C мову програмування. Ідея виявилася напрочуд вдалою і послугувала прообразом для Active Server Pages від Microsoft, що вийшла 1996-го,та багатьох інших технологій, які зайняли свою нішу ринку, проте не змогли наблизитися до популярності PHP навіть чверть століття після того.

Певною мірою своїм успіхом PHP завдячує тому, що браузер тоді не сприймався як серйозна платформа для програмування. Можливості JavaScript у роботі зі сторінкою були дуже обмежені, до того ж у другій половині 1990-хрозгорілися браузерні війни: Microsoft випустила свій браузер, у якому імплементувала власну інтерпретацію JavaScript під назвою JScript, і особливо проблемно було створювати кросбраузерний код.

Ось, наприклад, фрагмент коду з реального сайту 1998 року. Можна лише уявити, яке «задоволення» приносило писати щось таке:

Саме такий вигляд мав кросбраузерний код 1998 року

RIA

Як додаткове підтвердження того, що пара HTML/JavaScript не сприймалася як платформа для розробки, слід назвати появу та розквіт різноманітних плагінів, які мали бути вбудованими у веб-сторінки — чи взагалі заміняти їх — і надавати розробникам «повноцінніший» досвід програмування. Зокрема, 1996 року Sun у межах платформи Java випустила Java Applets, а Microsoft представила ActiveX, водночас компанія Macromedia придбала FutureWave Software і випустила свій плагін для браузера — Macromedia Flash, який спочатку позиціювався як медіапрогравач, але згодом став повноцінною програмною платформою.

Усі ці плагіни були сторонніми для вебу, потребували часу на завантаження та інсталяцію й не приносили особливого задоволення користувачам браузерів. Водночас можливості для програмування в браузерах саме за допомогою JavaScript розвивалися досить повільно, хоча й були перші зрушення. Зокрема, коли в Netscape відчули серйозну загрозу з боку Microsoft, то вирішили віддати JavaScript на стандартизацію в організацію Ecma International. Організація досить оперативно взялася стандартизувати та розвивати мову й упродовж 1997–1999років випустила три версії EcmaScript. Також 1997 року світ побачив Microsoft Internet Explorer 4.0 — нищівний для Netscape продукт, завдяки якому MS перемогла в браузерних війнах. Серед його особливостей була задекларована підтримка Dynamic HTML — набір технологій, до яких входили JavaScript та DOM, що нарешті давали змогу повноцінно маніпулювати вмістом HTML-сторінки на клієнтському боці й навіть динамічно застосовувати стилі.

Браузерні війни 1996–2009

Утім, розробники браузерів та плагінів об’єднали зусилля й запропонували 2002 року концепцію RIA — Rich Internet Applications, у яких ідея користуватися браузерами з плагінами подавалася як необхідність для того, щоб отримувати якісний медіаконтент та досвід роботи із сайтом загалом. Такий підхід значною мірою нівелював ідею вебу як єдиної платформи обміну інформації, бо Flash, Silverlight тощо — це, по суті, окремі незалежні платформи, контрольовані комерційними організаціями, які самостійно визначають правила гри.

Web 2.0 / Web.3.0

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

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

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

Мета семантичного вебу — дати можливість машинам розуміти дані, які описує HTML. Досягнути її можна, використовуючи такі технології, як RDF (Resource Description Framework) та OWL (Web Ontology Language).

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

Наприклад, звичайний елемент div, що містить інформацію про людину, доповнений RDF-атрибутами, може мати такий вигляд:

Семантична розмітка

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

AJAX

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

Однак 1999 року разом із браузером MS IE версії 5.0 Microsoft випустила оновлену версію ActiveX бібліотеки MSXML, однією з особливостей якої була підтримка можливості без перезавантаження сторінки та асинхронно, не блокуючи потоку виконання JavaScript-коду, надіслати запит на сервер, отримати результат і за допомогою DHTML вбудувати його в сторінку.

Цікаво, що кілька років таку можливість не помічали: хоча її і використовували на певних сайтах, але загалом про масове поширення не йшлося доти, поки Google не запустила у 2004-мусервіс Google Suggest, що показав можливості технології всьому світу. У лютому 2005 року Джеймс Ґаррет опублікував статтю «AJAX: новий підхід до побудови веб-аплікацій», у якій було запропоновано сам термін та детально описано технологію, що й зумовило активне її застосування.

AJAX фактично був останнім фрагментом у тому пазлі технологій, які перетворювали рідні компоненти вебу — HTML, CSS та JavaScript — на повноцінну платформу програмування.

jQuery

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

2006 року світ побачила перша версія бібліотеки jQuery, яку розробив Джон Резіґ, що надихнувся ідеєю вибору елементів HTML за допомогою селекторів CSS в іншої бібліотеки cssQuery, але вдало поєднав її зі зручними методами маніпуляції DOM та вбудував можливість робити AJAX-запити.

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

HTML5 / EcmaScript 2015

У січні 2008 року вперше побачила світ чернетка нової, п’ятої версії HTML. Крім власне модифікації самої мови розмітки, вона містила також опис значної кількості API, що перетворювали браузер на повноцінну платформу програмування. Якщо говорити власне про мову розмітки, то серед важливих змін варто назвати появу семантичних тегів і відмову від деяких тегів, що відповідали за представлення. Вихід HTML5 як стандарту затягнувся на цілих шість років. Утім, як розробники самих браузерів, так і веб-розробники сприйняли його дуже позитивно, адже нарешті він перетворював браузер на повноцінну програмну платформу, нівелюючи потребу в такому сторонньому для вебу створінні, як плагіни для RIA.

Паралельно з роботою над HTML5 велася робота й над черговою версією JavaScript. 2009 року виходить EcmaScript 5, рівно через 10 років після попередньої версії. На диво, змін за десятиліття було запропоновано відносно небагато, незважаючи на те що вже почали відчуватися ті хиби мови, які були закладені під час її створення. Лише через шість років світ побачив по-справжньому оновлений стандарт мови під назвою EcmaScript 2015, і разом з ним мова нарешті позбулася деяких дитячих хвороб, які її переслідували (наприклад, уже згадана раніше блочна область видимості), а також отримала оновлений синтаксис, зберігаючи водночас зворотну сумісність з ES5.

Саме парочку HTML5 / ES2015 варто вважати переходом веб-платформи в період зрілості, потреба в jQuery суттєво зменшилася, програмувати на чистому JS стало значно комфортніше.

Шлях стандартизації HTML5 був непростим, тривалий час існувало два окремі стандарти: від W3C та WHATWG, і лише 2019 року двом організаціям вдалося домовитися про єдиний стандарт — тепер це просто HTML Living Standardбез номерів версій, над яким оригінально працювала WHATWG. У стандартизації EcmaScript також відбулися важливі зміни: нова версія стандарту мови тепер виходить щороку, мова розвивається динамічніше й водночас зміни не навантажують розробників великими порціями.

SPA

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

Knockout, Backbone, ExtJS, AngularJS — далеко не повний перелік SPA-фреймворків, які почали тоді з’являтися й здебільшого використовували патерн MVC або його похідні. Сам патерн винайшли ще наприкінці 1970-х,але у веб-розробці його використання стало особливо поширеним. Вважається, що вперше MVC у вебі застосували 1996 року в маловідомому на сьогодні серверному фреймворку WebObjects, потім він швидко поширився на інші серверні фреймворки й загалом дуже комфортно почувався у вебі, накладаючись на традиційну модель комунікацій, яка передбачала перезавантаження сторінки під час кожного запиту клієнта.

Однак з появою AJAX гармонія MVC почала руйнуватися, бо, крім традиційних запитів на контролер, які мають оновити представлення, з’явилися запити, які не зовсім вкладаються в патерн. І саме за допомогою SPA цю гармонію вдалося відновити. Також у пригоді став створений на початку двотисячних Дуґласом Крокфордом формат передачі даних JSON — значно зручніший за XML. За десять років SPA розквітли й закріпилися на фронтенді, практично монополізувавши його як підхід до створення веб-рішень. Багато веб-розробників навіть не бачили альтернатив і не задумувалися про них, та й узагалі навряд чи запитували себе, чи потрібно щось інше, ніж SPA.

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

Спочатку така відповідь може збентежити, але якщо задуматися, то складно не погодитися з тим, що Single Page — це не дуже добре, оскільки в самій природі вебу закладено мати багато сторінок, щоб з’єднати їх гіперпосиланнями. І ці сторінки не мають бути просто імітацією в браузері, вони мають бути доступні будь-якому клієнту, який робить HTTP-запит до сервера за конкретною адресою, а не лише тому, який отримає мініміфікований код на JavaScript, виконає його та імперативно збудує сторінку — у такому разі ми втрачаємо декларативну сутність вебу, підміняючи його аплікаціями. Власне, тут і стає зрозумілим, що Application теж зайва — хіба ми не визначилися з тим, що HTML значно ближче до книжки чи журналу, ніж до графічного інтерфейсу комп’ютерних аплікацій?

Слід визнати, хоч би як це було прикро сучасним розробникам, які не уявляють фронтенд без SPA, що ця концепція насправді чужа для вебу, бо намагається підмінити ідеї, закладені у веб, підходами, що прийшли з розробки аплікацій з графічним інтерфейсом користувача. Хтось, можливо, вважатиме, що це не принципово, і якщо воно працює, то яка різниця, як саме воно зроблено. Але практика показує, що це не так. Усе-таки SPA виконуються в браузері, і щонайменше залишається потреба мати можливість робити посилання на окремі сторінки. Для цього почали реалізовувати deep linking, перенаправляючи будь-які запити на бекенд на одну сторінку, що є точкою входу в аплікацію, і виводячи потрібну сторінку на фронтенді. Але потім стало зрозуміло, що не можна цілком відмовитись від декларативного HTML на фронтенді й повністю підмінити його динамічною аплікацією, ліпше мати HTML-контент на сервері, як наслідок — виникло поняття Server-Side Rendering. Однак, реалізуючи SSR, виникає завдання передати стан із сервера до клієнта, це теж потребує певних зусиль на реалізацію. Також не дуже тривіальною виявляється підтримка доступності (accessibility) для SPA-аплікацій, декларативний HTML для цього ліпше пристосований. І так далі — скидається на безперервний процес, у якому розв’язання одних проблем призводить до появи інших.

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

А що в нас із фреймворками?

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

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

Багато хто вже «поховав» Angular, але тут не все так просто: у Google переписали AngularJS з нуля, навіть ім’я змінили, повністю поламавши зворотну сумісність, проте навряд чи хтось скаже, що цим вони зробили гірше. Як наслідок — вийшов такий собі мегаконструктор SPA, який не дуже підходить для нескладних проектів, але вдало знайшов свою нішу в корпоративних. Він і далі активно розвивається, Google забезпечує серйозну підтримку — загалом майбутнє видається значно оптимістичнішим, ніж може здатися на перший погляд.

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

Але справжнє відкриття 2019 року, яке ще має себе показати у 2020-му, —це «фреймворк, що щезає» — Svelte. Поки React та Vue називають Virtual DOM своїми перевагами, Svelte, навпаки, серед переваг називає його відсутність. Але ключова його особливість полягає в тому, що після збірки аплікації в ній не залишається фреймворку як такого — аплікація компілюється в чистий JS, за допомогою якого і відбуваються маніпуляції з елементами сторінки. Це досить суттєво відрізняє Svelte від інших, хоча такий підхід використали розробники Angular в останніх версіях із новим двигуном рендерингу Ivy.

Наприкінці 2019 року серед фронтенд-розробників всього світу проводилося традиційне опитування «State of JS», у якому за рівнем цікавості Svelte посів перше місце.

Рейтинг фреймворків за рівнем цікавості 2019 року

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

Що з бекендом?

Ще з 1990-хна бекенді заправляє балом стек LAMP і похідні, створені за його образом та подобою. І питання навіть не в конкретному наборі технологій, які його формують, а в загальних принципах роботи — запити з фронтенду обслуговуються динамічно, у процесі залучена база даних та сервер аплікацій, що відносно повільно працюють та складно масштабуються по горизонталі. У такому підході принципово нічого не змінилося навіть з приходом SPA, які дозволили відмовитися від передачі згенерованих сторінок із сервера, переганяючи лише дані за допомогою RESTful API.

Водночас варто зазначити, що розробникам на бекенді доводиться розв’язувати типові завдання навіть у різних проектах — зреалізовувати аутентифікацію та авторизацію, створювати типові CRUD-операції для сутностей предметної ділянки, передавати DTO між різними рівнями аплікації, покривати все це тестами тощо. Щоб не повторюватися щоразу й перевикористовувати зроблені раніше рішення, ще з кінця 1990-хстали набирати популярність CMS (Content Management Systems), а з поширенням RESTful API — так звані Headless CMS, що взагалі не мають фронтенду.

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

Одна з цікавих інновацій на бекенді, що швидко набуває популярності й здатна вплинути на прийняті підходи до розробки рішень, — це GraphQL, розроблена у Facebook технологія, що дозволяє на фронтенді сформувати запит до структури даних, які має повернути бекенд. Такий підхід позбавляє бекенд-розробників потреби створювати нескінченні CRUD-операції та загалом є гарною альтернативою до RESTful API.

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

JAMstack

Наприкінці 2017 року вийшла цікава стаття, у якій досить детально було описано стек технологій під загальною назвою JAMstack (JavaScript + API + Markup). Сам термін винайшла та активно просуває компанія Netlify, яка дуже вдало почала просувати ідею альтернативного до SPA підходу, що насправді зовсім не новий, але значно ближчий до оригінальних ідей вебу, ніж SPA.

JAMstack пропагує ідею так званих статичних сайтів, хоча термін «статичний» тут зовсім недоречний, бо насправді статичними ці сайти не є, просто, на відміну від SPA, їхній звичайний стан — це заздалегідь відрендерений статичний HTML-контент, розміщений на CDN, і динамічні вставки лише там, де треба. Бекенд розглядається у вигляді набору API, до яких можна звертатися за допомогою JavaScript, і це далеко не завжди кастомний бекенд, це можуть бути вже готові сервіси, які реалізують аутентифікацію, сервіси збереження даних і таке інше. Текстовий контент не обов’язково тримати у вигляді HTML, для цього доцільно застосувати якусь із мов розмітки, наприклад Markdown. А сам сайт оновлюється за допомогою процесів CI/CD, які стартують за тригером, наприклад після оновлення коду в системі контролю версій.

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

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

GatsbyJS — один з найвдаліших фреймворків для JAMstack, на DOU навіть є цикл публікаційпро нього, він поєднує в собі підтримку React, GraphQL, Markdown і досить гнучкий, щоб адаптуватися до різних сценаріїв використання.

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

JAMstack формують добре відомі складники

WebAssembly

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

Оскільки серед основних аргументів на користь WebAssembly називають швидкість, то ми, ймовірно, спостерігатимемо процес, коли десь там «під капотом» у реєстрі npm оновлюватимуться бібліотеки, які будуть оптимізовуватися за швидкістю з використанням альтернативних до JavaScript мов, однак їхні інтерфейси так само залишатимуться на JavaScript.

Звісно, WebAssembly поступово почне «відкушувати» частину розробників у JavaScript, цьому сприятимуть такі проекти, як, наприклад, Microsoft Blazor, призначені здійснити давню мрію бекенд-розробників: позбавити себе задоволення вивчати JS. Проте ці процеси навряд чи відбуватимуться швидко, і якщо говорити про перспективу кількох найближчих років, то монополії JavaScript на фронтенді це навряд чи суттєво загрожуватиме.

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

Висновок

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

У цій боротьбі завжди з’являється хтось, хто відчуває в собі сили та бажання підім’яти під себе веб, встановивши монополію на браузер чи певні технології, які мають використовувати розробники. Спочатку це була Netscape, потім її витіснила Microsoft, згодом у вебі почала панувати Google, яку, своєю чергою, витісняє Facebook. Але втримувати корону ще складніше, ніж її одержати, бо сила вебу — у відкритості стандартів, і щоразу, коли його намагаються монополізувати чи інфікувати сторонніми складниками, — як, наприклад, було з RIA, — він знаходить сили оновитися й позбутися їх. Але веб не робить це самостійно — це роблять розробники, що своїми руками сьогодні надають йому тих форм, які він матиме завтра. І щоб розробляти під веб, треба розуміти його, треба відчувати його філософію, ідеї, які заклали в нього його творці. Саме тому я закликаю розробників відповідальніше ставитися до тих рішень, які ми ухвалюємо, і підходів, які ми застосовуємо, старатися менше використовувати сторонніх для вебу речей, а більше того, що нам він дає як платформа, бо, як казав геніальний Алан Кей, «немає найліпшого способу передбачити майбутнє, ніж створити його».

Контакти автора: LinkedIn, телеграм-канал, веб-сайт.

Всем привет! Меня зовут Вадим, я Machine Learning Researcher в Wix. Работаю в продуктовых компаниях в сфере Data Science уже более шести лет. Занимался построением Machine Learning моделей и закрывал весь цикл Data Science проектов. Мне доводилось строить проекты для разнообразных бизнес-задач, а также в разных доменах ML & Deep Learning.

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

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

Этапы Data Science проекта

В Data Science, как в других IT-направлениях, уже давно есть эффективные процессы структурирования проектов. Удивительно, но далеко не все дата саентисты догадываются об их существовании. Первый фреймворк был придуман в 1996 году и называется CRISP-DM (Cross industry process in data mining). Модной фразы Data Science тогда еще не было, и говорили просто Data Mining. Интересно, что за 24 года своего существования система все ещё актуальна. Появились новые процессы, более подходящие под текущие реалии, но они так или иначе базируются на CRISP-DM. Примером для больших команд может быть процесс Microsoft, а на Медиумеесть хорошая инструкция для стартапов.

Чтобы лучше понять, как же устроена работа дата саентиста, давайте за основу возьмем CRISP-DM и пройдемся по основным этапам этой методологии (я немного изменил оригинальную схему для лучшего воcприятия):

1. Определение бизнес-необходимости проекта и установление KPI.Обдумать KPI — задача нетривиальная, поэтому над ней зачастую не заморачиваются. Но это может привести к очень неприятным последствиям, вплоть до закрытия проекта.
2. Работа с данными, которые необходимо где-то взять, убедиться в их качестве и подготовить для тренировки. На этом этапе нужно «засучить рукава», забыть о моральном вознаграждении и очень скрупулезно поработать. Интересный факт, что для достижения хороших результатов на этот этап тратится около 80% общего времени.Проверено на личном опыте :)
3. Построение модели, — наверное, самый приятный этап. Мне кажется, именно из-за него программисты часто хотят перейти в Data Science. Но опытные специалисты знают, что это опасное место, на котором можно зациклиться и потратить много времени зря.
4. Оценка качества модели — самый критичный этап. Во время построения модели мы делаем множество итераций и экспериментов, слабые места есть всегда. От того, как мы их проработаем, зависит скорость развития проекта и его финальное качество.
5. Вывод в продакшн — во многом инженерная часть, но тесно связанная с алгоритмами Machine Learning.

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

Давайте подробнее рассмотрим каждый из этапов жизни Data Science проекта.

Business understanding

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

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

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

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

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

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

Получение данных

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

Отмечу, что не для всех задач нужны размеченные данные. Исключение — задачи unsupervised learning (например кластеризация).

Ключевой фактор результативности модели — качество данных! Если что-то не так с данными, модель выявит неправильные взаимосвязи, и результаты не будут отображать реальность, а полезность будет нулевая. В Data Science кругах ходит популярная фраза: «Garbage in = garbage out». Никакая модель не сможет дать правильное предсказание, если данные на вход были неправильными. Именно поэтому хороший дата саентист проводит гораздо больше времени, разбираясь в данных, нежели тестируя разные модели.

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

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

Базы данных (логов) продукта

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

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

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

Скрэйпить из интернета

Думаю, тут сложность очевидна: вытащить данные из разных источников и унифицировать их. Вдобавок к инженерной сложности соскрейпить данные возникает другая проблема. Часть данных может не иметь никакого отношения к моделированию, и определить и исключить эти данные — достаточно кропотливая работа. Допустим, для задачи необходимо вытащить заголовки текстов с разных сайтов. Как это сделать? Вытаскивать заголовки по тегам <h1>, <h2> недостаточно, потому что пользователь может обойтись без них и просто сделать для обычного текста шрифт побольше. Вытаскивать все тексты со шрифтом больше 32pt тоже нелогично, ведь на сайте может быть весь текст с таким шрифтом. То есть чтобы получить качественные данные, нужно выбирать текст, учитывая особенности каждой отдельной страницы.

Ручная разметка

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

При этом автоматически получить размеченные данные для тренировки невозможно. Поэтому для таких задач человек вручную размечает N примеров, а потом эти данные используются для тренировки алгоритма. Задача ручной разметки данных с 2014 года превратилась в отдельную огромную индустрию и продолжает расти. Есть множество компаний, которые занимаются разметкой ваших данных. Например, вы платите компаниям, чтобы они разметили автомобили на ваших видеороликах. По оценкаманалитических компаний, в 2018 году рынок аутсорса Data Labelling достиг $318 миллионов, и предсказывают рост до $1,5 миллиарда к 2025. А некоторые эксперты ожидают вдвое больший рост.

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

Моделирование

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

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

Выбор алгоритма влияет на то, как и какие данные необходимо собирать. Допустим, есть задача отсортировать «объекты» по качеству. Вот два разных способа, как разметить данные, от которых будет кардинально зависеть выбор модели:

• каждому объекту давать оценку от 1 до 10 и потом усреднить результаты;
• показывать объекты попарно и спрашивать, какой лучше.

В целом, для дата саентиста задача моделирования сводится к следующему:

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

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

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

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

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

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

Оценка результативности и принятие решения

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

По своему опыту обратил внимание, что коммуникация результатов очень подвержена такому когнитивному искажению, как Halo effect. (Из Википедии: результат воздействия общего впечатления о чём-либо на восприятие частных особенностей. Примером может служить впечатление, что у людей с привлекательной внешностью большие умственные способности.)Он работает как в позитивную, так и в негативную сторону. В связи с этим обсуждение текущих результатов модели создает определенную эмоциональную окраску для будущих оценок. Это влияет на принятие конечного решения. И даже если все ваши решения data driven, из-за неправильного донесения особенностей выход модели в продакшн может изрядно замедлиться (например, в середине проекта решают ужесточить ранее установленный KPI).

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

Бывает, что качества модели недостаточно, чтобы выводить ее в продакшн. При этом нет четкого понимания, какие действия наверняка улучшат качество. Такая ситуация вероятна, так как Data Science проекты не имеют четко определенного пути к цели. Задача сводится к пониманию проблемы, составлению гипотез и разнообразным экспериментам. Причины неуспеха могут быть связаны как со сложностью задачи, так и с качеством и количеством данных. Умение признать нерешаемость задачи и найти достойный pivot — очень ценный навык. Хороший пример pivot`a от сложной к более простой задаче: не делать полноценную систему рекомендаций, а внутри каждой категории рекомендовать самый популярный продукт.

Выведение в продакшн

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

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

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

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

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

• Устаревание модели. Для некоторых проектов это естественная ситуация, так как меняется продукт, поведение пользователей, данные. Если модель привязана к «текущему состоянию проекта» — то для того, чтобы она еще долго оставалась полезной, ее нужно обязательно обновлять. Перетренировку модели на актуальных данных, сравнение качества и выливание в продакшн можно и желательно автоматизировать. Это можно делать и вручную, но тратить на это время — не очень эффективная стратегия.
• Выход новой версии.Когда дата саентист приходит с новой версией модели, обычно, кроме самой модели, меняется и процесс обработки данных. А это ведет к необходимости дополнительной оптимизации, а также проверки эффективности по качеству и скорости. У нас на проекте был интересный use case с нейронной сетью, где на одном из этапов мы уменьшаем разрешение картинки. Для продакшна мы заменили библиотеку для преподготовки изображения с PIL на OpenCV. И вот одна и та же функция с одним и тем же названием bicubic_interpolation давала разницу примерно в ~7%. Несложно догадаться, что это значительно повлияло на качество :) Так что тесты и мониторинг — это правильный уровень maturity Data Science проекта. (По ссылкехороший набор критериев для оценки уровня развитости вашего Data Science проекта.)

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

Итоги

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

Ключевые идеи:

• Важно понимать целесообразность использования Machine Learning для решения задачи.
• Установление правильных бизнес-требований — ключ к успешному проекту.
• Главная сложность и залог успеха — в получении качественных данных.
• Данные гораздо важнее, чем модель!
• Процесс моделирования состоит из проверки гипотез, и вполне вероятно, что ни одна из них не сработает.
• Деплоймент модели в продакшн — отдельный и значимый этап, который требует дополнительной автоматизации и другого подхода к данным.

Спасибо за ваше время!

Интересные ссылки

• Microsoft Data Science Process;
• Data Science Flow for Startups;
• Google ML Recommendations;
• Joel’s Test for Data Science;
• CRISP-DM.

Меня зовут Станислав Малкин, я технический специалист. В разработке уже более 10 лет, а в данный момент DevOps в небольшом стартапе (45+ сотрудников) в сфере eHealth в Берлине.

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

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

Попробуем, тем не менее, составить максимально полное руководство для иммигранта (-ки) в Берлин.

Итак, оффер получен. Что дальше?

Я с двоюродной сестрой, Берлин

До подписания

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

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

Стоит посмотреть свои дипломы и понять, в какой области возможна занятость, нужно ли будет проводить процедуру признания дипломов (немцы не признают по умолчанию наши дипломы, кроме IT-специалистов) и/или учить немецкий язык до уровня С1/С2.

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

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

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

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

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

Если вы хотите получить Blue Card (требования довольно простые: профильное образование и зарплата выше 55,200 евро брутто, так же смотрите FAQпо поводу Blue Card) — стоит проверить, что ваш диплом есть в списке Anabin (должен быть статус H+ или H+/- [в этом случае надо проверять конкретный факультет и специальность — если они есть в списке]) и что по офферу вы будете получать не меньше этой суммы в год. Если диплома нет в списке — отчаиваться не стоит, за 200 евро специальное учреждение проверяет ваш дипломи он может быть добавлен в базу, если будет соответствовать немецкому.

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

Узнайте, в чем будет состоять помощь компании при переезде: очень часто бывает так, что помогают с жильем на первое время, сопровождают с документами и помогают определить дату посещения министерства по делам иностранцев (Ausländerbehörde aka АБХ) на месте (вы обязаны поменять въездную визу на резидентство в течение 3–6месяцев по приезде, но тут есть нюанс, о котором чуть дальше). Это может как сильно облегчить процесс переезда, так и усложнить (есть случаи, когда не помогают ни с чем, кроме контракта).

Для многих оказывается неожиданным факт, что за уровень зарплаты можно поторговаться, уже получив контракт на подписание. Вы можете получить на 5–10%больше, даже просто спросив об этом. За спрос ведь не бьют, верно? По моим ощущениям и опыту моих знакомых и друзей, переезжавших в последнее время, уровень зарплаты в 60 тысяч евро в год и более будет вполне комфортным для старта. Рассчитать, сколько у вас будет оставаться после налогов, можно на этом калькуляторе. Стоит внимательно изучить контракт и обсудить с работодателем все непонятные или спорные моменты.

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

Также нелишним будет заранее пожить 2–3недели в Берлине, ведя тот же образ жизни, что и у себя в стране, чтобы понять, насколько комфортно вам будет в немецкой столице. Это поможет не удивляться потом моментам, которые обычно видны даже в течение недели-двух, таких менталитет населения (например, поощрение ЛГБТ-движения), отношения с местными, тот факт, что люди не парятся над подбором одежды и веяниями моды, уровень бытового обслуживания: парикмахерские услуги, медицина, транспорт, развлечения и т. д. (добавьте свое).

Берлин в декабре. @herrhehn

Контракт подписан

Попросите прислать подписанный контракт почтой DHL (так надежнее и быстрее).

Теперь можно назначать дату подачи визы и, если нужно, свадьбы (если будете уезжать вместе и еще не оформились, можно все сделать очень быстро в «Готово»). А также начинать собирать вещи (и раздавать те, которые не будете забирать с собой).

Кстати, вещи можно передать перевозчиками из Львова, отправив им вещи «Новой Почтой». Мы перевозили с помощью Юрия (брал 1 евро за 1 килограмм вещей). Доставил оперативно и без проблем.

Также можно вступить в группу «Украинцы в Берлине» (довольно живая группа, в которой можно найти анонсы мероприятий, ответы на вопросы или задать свои).

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

Виза получена

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

Ваш термин, к слову, является гарантией вашего легального пребывания в стране даже по окончании визы, но выехать из Шенгена вы не сможете (да и внутри него с невалидной визой я бы не рекомендовал передвигаться). Получение статуса резидента (по Blue Card) может занять до 8 недель с момента подачи заявки, поэтому, чем раньше подаемся, тем лучше для нас. Есть вариант прийти рано утром и получить термин в тот же день, но, во-первых, приходить надо в 4–5 утра,а во-вторых, место может находиться далеко от вашего места жительства, поэтому лучше записаться заранее.

Особый пункт — поиск жилья в Берлине. Если компания с этим не помогает, оно может быть существенной заморочкой. Я настоятельно не рекомендую снимать квартиру удаленно, но многие хотят приехать, чтобы уже было где жить (в таком случае можно воспользоваться сервисами Airbnb/Wunderflats).

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

Обязательно уточняйте, возможна ли прописка (в Airbnb/Wunderflats это обычно не проблема).

Ботанический сад в Берлине, Рождество. @herrhehn

По приезде

Регистрация

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

Жилье

Я рекомендую по приезде пожить в отеле 1–2 недели,посмотреть на город, его районы и понять, где вам будет удобнее (все районы разные). Снимать жилье сразу на долгий срок не рекомендую потому, что немцы любят контракты и приехавшему будет очень сложно найти что-то адекватное. К тому же почти всегда требуется документ, называемый Schufa (подтверждение кредитоспособности), который приезжий может получить, но он будет пустой, так как истории жизни в Германии у него не было. Поэтому шансы приезжего на успех будут существенно малы ввиду огромного спроса на аренду жилья и отсутствия у него отличительных преимуществ.

Лучше снять меблированную квартиру на 3–6месяцев (их выбор больше, и документов обычно нужно меньше) и за это время спокойно поискать долгосрочный вариант. Так как долгосрочные квартиры, как правило, идут без мебели, вам нужно будет заниматься всем: от покупки и транспортировки мебели до подключения интернета (3–4 недели)и заключения контракта на электричество. Согласитесь, ненужная нагрузка на первый месяц, когда нужно разбираться с множеством других нюансов. Заодно и с районами ознакомитесь.

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

Мобильная связь

Хорошим вариантом для старта может стать Aldi Talk. Сим-карту можно купить в любом магазине Aldi в первый же день приезда. В базовом тарифе за 8 евро идут 300 минут на звонки внутри сети и 3 гигабайта интернета, которые можно использовать по всему ЕС, как дома. Регистрация не требуется.

Страховка

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

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

Банковский счет

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

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

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

Попробуйте Comdirect, Commerzbankили Deutsche Bank (обычно новоприехавшие успешно открывают счет в одном из этих банков).

Барахолки и покупка фурнитуры

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

Изучение языка

При получении Blue Card в АБХ можно запросить для своей пары бесплатное направление на интеграционные курсы, где в том числе идет преподавание немецкого языка.

Успешного переезда!

Люба Шипович — успішний ІТ-фахівець, колишня СТО нью-йоркської компанії. У 2015 році продала її та приєдналася до реформаторської команди Міхеїла Саакашвілі в ОДА. Наразі Люба є позаштатним радником прем’єр-міністра.

Про те, чому успішна девелопер вирішила відмовитись від кар’єри задля допомоги Батьківщині, Люба Шипович розповідає спеціально для DOU.

З України я не шукала вакансій: взяла останню зарплатню і переїхала до США

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

Я з третього курсу працювала в канадській компанії: країни схожі, та і правила ІТ-сектору в різних країнах подібні — мене очікувало щось звичне. Тому з України я не шукала вакансій, просто взяла останню зарплатню і приїхала до США. Втім, я мала місяць, аби знайти роботу: запаси грошей не вічні. Як математик, я одразу подивилась статистику винаймання — відгук за резюме десь 7%. Все просто: треба розсилати по 100 резюме на день, аби отримувати десь 6-7 дзвінків.Потім з’ясувалось, що я «трошки» не догледіла: статистика була за всіма спеціальностями, а за ІТ показник значно вищий — близько 50%. Тож за декілька тижнів мені довелось змінити номер телефону — мобільний просто розривався від дзвінків. Моя активність дала результат — дуже швидко я отримала два привабливих офери, навіть трошки поторгувалась між ними — і обрала першу роботу.

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

В 2011 році я запропонувала СЕО компанії зробити офіс в Україні, бо тут є кваліфіковані програмісти

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

В 2011 році я запропонувала СЕО компанії зробити офіс в Україні, бо тут є кваліфіковані програмісти. Основний аргумент — вони дешевші, кваліфіковані, і шукати їх швидше. За умов теперішнього перегрітого ринку в Україні не знаю, чи запропонувала б я цей варіант. Але тоді то була гарна ідея. Ми хотіли не просто робити аутсорсинг. Я працювала в такому форматі в Україні і розуміла, що в аутсорсингу люди не відчувають зобов’язання перед роботодавцем, причетність до роботи, не мають розуміння компанії та клієнта. Тож у 2011-2012 япросувала ідею, що в Україні треба створювати продуктові офіси: не offshore team, а office extension. Тоді ще не існувало такого поняття, як аутстафінг. Та, власне, ми використали саме такий формат, але називали його office extension.

Я вмовила СЕО прилетіти до України, і після купи різних перемовин, зважень усіх рішень, вирішення юридичних аспектів ми вийшли на Алекса Луцького з Innovecs. Проте на той час Innovecs існував просто в альбомі на моделях — його ще не створили. Алекс розповідав нам, якою крутою буде компанія і класним — офіс (тоді ще) на Тараса Шевченка, а ми розказали про свої плани. Отак зустрілися два мрійники і повірили одне одному. І за два місяці Алекс справді запустив офіс, а ми винайняли перших людей. Модель спрацювала: дехто з найнятих ще у 2012 році працює в компанії і дотепер.

EZ Texting був першим комерційним клієнтом MongoDB, які тоді займалися альфа-бета тестуванням. А мені якраз хотілось пробувати щось нове. Продукт був сирий, але по роботі я відвідала багато різних конференцій, де виступала і ділилась іншими нашими історіями успіху. І з самою компанією ми тісно співпрацювали — був період, коли я занурювалася в технологічну частину. Це був один з пікових періодів моєї публічності, тож у 2015 році кар’єрний портал Zippia включив мене до топ-50 жінок-розробниць Нью-Йорка.

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

В 2013 році EZ Texting викупила CallFire — компанія, яка займалась голосовими повідомленнями. Я стала головним інженером текстингової платформи.

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

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

На другий день мене додають до Facebook-групи «Закордонні українці для Євромайдану», де люди бідкались, що не знають, як допомогти. Я поділилась своїм досвідом, і до мене звернулись українці з Японії — щоб я через сестру придбала щось і передала для Майдану. Ми вирішили, що треба ще один електрогенератор: 700 доларів вони зібрали швидко. На ранок ми скинули японцям звіт, і гадали, що на цьому історія з допомогою закінчується.

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

Зрештою суми перелічених коштів перевалили за $2000 на день

Згодом на мене вийшли кілька американських корпорацій, які хотіли допомогти, але відкрито їм не можна було цього робити. Ці компанії прагли захистити ЗМІ від DDoS-атак. Саме тоді ми домовились про «щити» для захисту інформаційних видань «Українська правда», «Еспресо», «Громадське», а також про додатковий зв’язок.

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

Зрештою суми перелічених коштів перевалили за $2000 на день. Все це йшло на мій рахунок, тож я мала платити податки — а в США це немалі відсотки. До того ж, в США ми почали також робити протести на підтримку українського Майдану. І певної миті збагнули, що створення громадської організації спростить нам фінансову частину та процедуру отримання дозволів на протести. Спочатку ми спробували приєднатися до українських ГО, але довіри до нас не мали: ми місяць як об’єднались, і нас мало знали. Тож одного вечора ми сіли і придумали назву Razom for Ukraine — зареєстрували онлайн, подали документи на неприбутковий статус. Так і почали.

Усі ми мали роботу full-time, і вся діяльність з підтримки Майдану велась паралельно: кожен учасник був зацікавлений в автоматизації процесів. Раду директорів ми обирали на skype-зустрічах, голосування проводили онлайн, працювали в Google business suit, тобто застосовували свій досвід з бізнесу в нон-профіт секторі. Зараз НГО тільки приходять до цього. А ми мали обговорювати багато питань: бюджети, рішення, статут. Щоб не втратити неприбутковий статус, ми також мали діяти зважено — бо існували певні обмеження у діяльності.

Тобто організувалася американська частина, було ГО, і моя робота нікуди не зникла. Компанія, до речі, також динамічно зростала: була штаб-квартира, офіси в Лондоні, Нью-Йорку та Києві. Потім почалася війна, і події стали більш прогнозованими — можна було планувати на день-два, а на Майдані треба було приймати рішення за півгодини. Та простіше від того не стало.

Це був момент великого піднесення, ми ще жартували, що «впливаємо на політику США»

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

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

Якоїсь миті на нас вийшов молодий помічник Джордж Барроз, який мав родичів з України, тож прихильно ставився до нашої Батьківщини. Він і розповів, що треба робити для ефективного результату. На той момент створили законопроект 2828 про підтримку України: нам треба було його протягнути на голосування, бо він дуже допоможе Україні. Це документ, згідно з яким США матимуть законодавчу підставу надавати допомогу Україні, в тому числі військову. Без цього документу Америка не могла прийняти таке рішення. Наше головне завдання — зробити все, аби українське питання було на порядку денному якомога більшої кількості конгресменів. Адже вони підтримують ті законопроекти, які стосуються наболілих проблем своїх громадян. А оскільки багато американців — вихідці з України, шанс ми мали.

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

І нам вдалося: законопроект прочитали з трибуни, і за нього проголосували. Ми спочатку не вірили, бо тоді якраз були бюджетні слухання, коли на порядку денному стояли більш нагальні для США питання. Проте нам вдалося пролобіювати документ.

Та це був не кінець: другий рівень — добитися, щоб документ підписав Обама. Найгірше, що могло статися, — документ не відхилять і не підпишуть. Тобто він міг «зависнути», і все прийшлося б організовувати спочатку. Аби цього не трапилось, ми почали кампанію «подзвони президенту». Ми мали менше 10 днів на те, щоб переконати Білий дім, що цей документ важливий: у календарі створюємо графік, де кожні 10 хвилин хтось має телефонувати до офісу Обами. Мета — забити лінію Білого дому, щоб ніхто не міг додзвонитися. За графіком з 8:00 до 18:00 ми дзвонили, і на 8-йдень Обама врешті-решт підписав Ukraine Freedom Support Act, який став засадничим для надання допомоги Україні. Це був момент великого піднесення, ми ще жартували, що «впливаємо на політику США».

Приїхала без представлень, призначень і «корочок»: просто прийшла до ОДА

У такому режимі я жила до червня 2015 року: купа дзвінків по роботі, паралельно — по Майдану. І я зрозуміла, що більше не можу так розриватися: треба обрати щось одне. І я звільнилася. Причому пішла одразу до HR-департаменту, підписала всі необхідні папери — аби не можна було нічого відкотити.

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

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

ІТ-шники, яких ніхто ніколи не кликав, хотіли долучитися до змін, і це дуже надихало

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

Для себе я бачила три головні завдання: i-government (автоматизація), ІТ-освіта, щоб виховувати кваліфікованих фахівців, та розвиток ІТ-кластера — об’єднання ІТ-компаній регіону.

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

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

Ми відібрали приблизно 20 сильних фахівців. Та девопсів у команді все одно не вистачало: з ними допомогли ІТ-компанії. Вони просто передали двох осіб, які волонтерили в ОДА, а по факту отримували ставку в себе на роботі. Я змогла отримати кімнату на +20 додаткових осіб: в адміністрації це не так просто, до речі. Та ось ми починаємо працювати в ОДА без всяких статусів. Для початку — на платформі, яку надає Google: вперше для українських шкіл вони дали можливість підключитися до Google apps для освітніх цілей. За весь час роботи нам вдалося підключити 160 шкіл, натренувати вчителів для роботи з платформою і провести силу-силенну занять з дітьми. Більшість шкіл продовжують працювати за системою і надалі.

Великий челендж: натренувати чиновників працювати з Confluence та Jira

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

Тож ми почали працювати з Confluence та Jira. Великий челендж: натренувати чиновників працювати на цьому софті. Звісно, йшло туго, а паралельно ми ще починаємо конкурс на електронний документообіг. В той час запускається Prozorro, і я наполягаю: щоб Одеська область була прогресивною, ми маємо долучитися до руху. Це був один з найскладніших кроків, бо ми почали наступати на фінансові інтереси. Ми отримуємо «добро» від Саакашвілі, і рухаємось в напрямку Prozorro.

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

Тому розпорядження про впровадження Prozorro на державному рівні в нас губилося п’ять разів. На різних стадіях: сьогодні можна було принести документ, а завтра отримати здивовані погляди на кшталт «у нас нічого немає, ми нічого не отримували». Тоді я дізналася про популярний у чиновників вислів: «приробити ноги документу». Це значить, якщо ти не носитимеш документ і не чекатимеш на підпис отут і зараз, нічого з місця не зрушить. І я носила, чекала на підпис — тільки так розпорядження підписали. Щоправда, коли воно пішло на друк, то внесли «випадкову» правку до суми: зі 10 000 грн вона зросла до 20 000 грн. Я переробила і пройшла всі кола заново. Це було складно, але ми розуміли цінність Prozorro: так, система не вирішує питання корупції, але вона робить її видимою. І це справді заважає корупціонерам.

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

Я виробила для себе правило: з України треба вилітати принаймні кожні 100 днів. Бо якщо засидітися більше, складається враження, що все тут — норма. А треба дивитися, як буває інакше, розвиватися і прочищати мозок, а тоді вертатися. Я лечу до Нью-Йорка, повертаюся в січні 2016 року в адміністрацію. А на вході змінилась охорона, і мене не впізнають і не пускають. Виявляється, я пропрацювала півроку без жодної перепустки чи документу. Я подзвонила в апарат, попросила зробити мені якусь перепустку — волонтера, наприклад. На що мене питають: «А ти що, не заступник голови адміністрації?» Виявилось, що колеги, включно з топкерівництвом, вирішили, що я обіймаю саме цю посаду. Того ж дня мене роблять позаштатним радником, в мене з’являється посвідчення, і я можу спокійно приходити на роботу.

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

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

Загалом на держслужбі я була дев’ять місяців. За цей проміжок до Одеси вдалось залучити 650 млн гривень інвестицій. Ми жартували з журналістами: «Якою була б сума, якби цим займався хтось з більшим досвідом?» Насправді, в Одесі з інвестиціями було нескладно, і моїх компетенцій більш ніж вистачило.

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

Траплялися і смішні, і страшні випадки — навіть рейдерські захоплення

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

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

Весь цей час я жила на свої заощадження: ми продали EZ Texting, я мала гарний бонус, до того ж власні накопичення — десь $80 тисяч

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

Весь цей час я жила на свої заощадження: ми продали EZ Texting, я мала гарний бонус, до того ж власні накопичення — десь $80 тисяч. Я знала, що можу дозволити собі рік перебування в Україні. Та довелося затриматися на півтора: коли я готувала свого наступника, Саакашвілі саме пішов з посади. Я не могла кинути власну команду: до того ж, в.о. голови адміністрації залишалася Соломія Бобровська. Через це я і затрималась на додаткові півроку. Щойно було призначено нового голову адміністрації, його першим наказом стало моє звільнення. За час роботи в уряді я коштів витратила як на хороший MBА: частину — на власні проекти, бо не звикла просити. Але якщо говорити про знання, то я їх отримала набагато більше.

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

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

Просто комерція мене тепер не цікавить: у роботи має бути місія

У січні 2017 я повернулась до Штатів. Адже усвідомлювала: я не знаю, як в Україні заробляти гроші — просто працювати в ІТ-компанії не бачила сенсу. Та і в Нью-Йорку я розуміла, що просто комерція мене більше не цікавить: у роботи має бути місія. Я пішла в стартап-інкубатор віце-президентом з інженерії. Мені сподобалась мета вирощувати нові компанії та стартапи. Перші місяці було страшенно цікаво — та потім стало зрозуміло, що в усіх стартапів приблизно одні і ті самі проблеми, і я просто циклічно виконую одну і ту саму роботу. Тому я звільнилася і почала шукати роботу через своїх агентів.

Зупинилася на компанії Flocabularly, яка спеціалізується на educational tech та робить навчальний хіп-хоп. Тобто предмети зі шкільної програми перекладають на хіп-хоп: співпрацюють з різними реперами, які з матеріалів уроків роблять речитатив, і паралельно ще існувала команда операторів та монтажерів. Працювали з різними предметами: фізика, хімія, історія. Клієнти — школи або school districts (шкільні управління). Я працювала там техлідом до жовтня 2019 року.

У липні 2019 року президент Зеленський з командою поїхав до Торонто. В команді був і Олексій Гончарук, з яким я знайома з 2014 року: ми багато співпрацювали по Одесі, коли він був радником з Мінекології. Він попросив мене зібрати в Торонто групу інвест-банкірів, людей з ІТ, щоб обговорити якусь ідею. Він презентував IT Creative: описав, що в ІТ-компаніях України є нестача кадрів, постійне змагання людей, яке сповільнює розвиток компаній. Що це відбувається через недосконалу систему освіти. Тож є ідея створити фонд розвитку ІТ-екосистеми, який може наповнюватися від податків або міжнародних донорів.

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

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

IT Creative — це платформа для обговорення та створення рекомендацій

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

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

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

ІТ-галузь України досягла бар’єру, коли вона не збереже темпи зростання без кооперації з державою

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

Я відкривала офіс в Україні 2012 року — тоді були інші умови. Коли в останній компанії стало зрозуміло, що нам також треба робити аутстафінг, ми обрали Аргентину. Рівень володіння англійською мовою, часова різниця і ціна години роботи фахівців — три важливі фактори, на які звертають увагу компанії. У будь-якому разі винаймають junior чи junior to middle — senior в інших країнах не беруть, адже вони надто дорогі. Отже, за цими критеріями ми обрали іншу країну.

Так, Україні зараз є чим приваблювати: галузевими спрямуваннями, якістю експертизи — до прикладу, фінансової. Та якщо вирівняються з/п з Америкою та Канадою, то навіть у цих галузях буде важко конкурувати. Коли є office extension, компанії розуміють, що будуть незручності: перш за усе, часові. Але вони мають перекриватися вартістю чи кваліфікацією. А якщо ці незручності не будуть перекриватися — відповідно, обиратимуть інші країни. Швидкість винаймання — інший важливий показник. У Нью-Йорку — це три-чотири місяці, в Україні — до двох. Якщо ми зрівняємось за швидкістю винаймання з Америкою чи Канадою, Україна відставатиме ще більше. Тому ринок треба підтягнути — щоб наповнювати фахівцями, а ще — боротися зі стереотипами.

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

Цього разу я не можу волонтерити дуже довго — на жаль, я компанію не продала

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

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

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

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

Вступление

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

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

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

Начнем сначала: если вы не знакомы с Flutter и/или GraphQL (я не знаю, зачем вы открыли эту статью), начните с небольшой вводной:

• официальная документация по Flutter;
• чем Flutter так хорош;
• о GraphQL.

Увидимся после прочтения :)

Подготовка

Что бы хотелось получить:

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

Что для этого потребуется:

• Android Studio (или любой другой продукт JetBrains) — взять их можно тути тутсоответственно;
• установить Flutter;
• настроить IDE;
• установитьв IDE плагин JS Graphql;
• установить NodeJS (сомневаюсь, что у кого-нибудь ее не будет).

Практика

Создаем новый Flutter проект

File -> New -> New Flutter Project

В открывшемся окне оставляем выбранный пункт по умолчанию — Flutter Application.

Жмем Nextдо самого конца (ничего не меняя в настройках), и в конце — Finish.

Более красочно процесс описан в документации в разделе Test Drive.

В итоге у нас получится демо приложение с любимым каунтером.

Устанавливаем graphql_faker

npm install -g graphql-faker

или

yarn global add graphql-faker

Запускаем graphql-faker ./fake.schema --open

Запустится сервер, автоматически откроется страница в браузере для редактирования API.

Параметр ./fake.schemaуказывает файл, который будет взят за основу схемы. Так как у нас нет такого файла — за основу будет взят дефолтный мок, поставляемый с сервером.

Попробуем кое-что добавить: после 20-йстроки пишем id: ID! @fake(type: uuid)и нажмем кнопку Save, в папке с проектом появится файл fake.schema с внесенными вами изменениями. Его будет удобно в последующем использовать для старта сервера, закоммитить для шеринга между командой или как вам заблагорассудится.

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

Приятный бонус — проект поддерживает наш земляк Иван Гончаров. Сейчас активно готовится версия v2.0.0, нелишним будет поддержать коллегу пиаром или детальным баг-репортом.

Плагин JSGraphQL

Создаем файл .graphqlconfig в корне проекта. Заполняем копи/пастой

{
 "name": "Schema",
 "schemaPath": "my.schema.json",
 "extensions": {
   "endpoints": {
     "Default": {
       "url": "http://localhost:9002/graphql",
       "introspect": true
     }
   }
 }
}

Сохраняем изменения, переходим на вкладку GraphQL, дважды щелкаем на Default, выбираем Get graphql schema from endpoint:

Будет создан файл my.schema.json, содержащий свежую схему вашего АПИ.

Плагин будет удобен для контроля над ошибками и помощи в автозаполнении при написании запросов. Это легко проверить: создаем папку graphql в корне проект, в ней — файл employee_data.graphql, пробуем набрать несложный запрос:

query EmployeeData($id: ID!) {
   employee(id: $id) {
       firstName
       id
   }
}

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

Возвращаемся в редакторgraphql_faker, меняем у employee firstNameна firstName1, жмем Save, обновляем локальную схему и радуемся отображению ошибки.

Flutter-часть

Нам понадобится два плагина: flutter_graphqlдля работы непосредственно с GraphQL и artemisдля генерации типов.

Добавляем в pubspeck.yaml следующие строки:

dependencies:…
 graphql_flutter: ^3.0.0-beta.3
 path_provider: ^1.5.1
 equatable: ^1.0.2
 json_serializable: ^3.2.3
 gql: 0.12.0


dev_dependencies:
 ...
 build_runner: ^1.7.2
 artemis: ^2.1.4

Выполняем в консоли flutter packages get.

Artemis

Начнем с настройки artemis (подробнее о настройках — здесь).

Создаем файл build.yaml в корне проекта со следующим содержимым:

targets:
 $default:
   sources:
     - lib/**
     - graphql/**
     - my.schema.json
   builders:
     artemis:
       options:
         schema_mapping:
           - schema: my.schema.json
             queries_glob: graphql/*.graphql
             output: lib/graphql_api.dart

Запускаем генерацию типов

pub run build_runner build

или

flutter pub run build_runner build

Спустя 10-20секунд генерируется два файла:

• graphql_api.dart;
• graphql_api.g.dart.

flutter_graphql

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

Возвращаемся в редакторgraphql_fakerи после 14-йстроки добавляем idдля компании id: ID! @fake(type: uuid) — это нам понадобится для корректной работы кеша. Сохраняем. Обновляем локальную схему.

Создаем новый файл graphql/companies_data.graphql.

targets:
 $default:
   sources:
     - lib/**
     - graphql/**
     - my.schema.json
   builders:
     artemis:
       options:
         schema_mapping:
           - schema: my.schema.json
             queries_glob: graphql/*.graphql
             output: lib/graphql_api.dart

Генерируем типы flutter pub run build_runner build.

Создаем файл lib/graphql_provider.dart.

import 'package:graphql_flutter/graphql_flutter.dart';
import 'package:flutter/material.dart';

String uuidFromObject(Object object) {
 if (object is Map<String, Object>) {
   final String typeName = object['__typename'] as String;
   final String id = object['id'].toString();
   if (typeName != null && id != null) {
     return <String>[typeName, id].join('/');
   }
 }
 return null;
}

final OptimisticCache cache = OptimisticCache(
 dataIdFromObject: uuidFromObject,
);

ValueNotifier<GraphQLClient> clientFor({
 @required String uri,
 String subscriptionUri,
}) {
 Link link = HttpLink(uri: uri);
 if (subscriptionUri != null) {
   final WebSocketLink websocketLink = WebSocketLink(
     url: subscriptionUri,
     config: SocketClientConfig(
       autoReconnect: true,
       inactivityTimeout: Duration(seconds: 30),
     ),
   );

   link = link.concat(websocketLink);
 }

 return ValueNotifier<GraphQLClient>(
   GraphQLClient(
     cache: cache,
     link: link,
   ),
 );
}

/// Wraps the root application with the `graphql_flutter` client.
/// We use the cache for all state management.
class GraphqlProvider extends StatelessWidget {
 GraphqlProvider({
   @required this.child,
   @required String uri,
   String subscriptionUri,
 }) : client = clientFor(
         uri: uri,
         subscriptionUri: subscriptionUri,
       );

 final Widget child;
 final ValueNotifier<GraphQLClient> client;

 @override
 Widget build(BuildContext context) {
   return GraphQLProvider(
     client: client,
     child: child,
   );
 }
}

В файле main.dartдобавляем функцию host, которая в зависимости от платформы подправит адрес localhost’a.

String get host {
 if (Platform.isAndroid) {
   return '10.0.2.2';
 } else {
   return 'localhost';
 }
}

А MaterialApp (в том же файле main.dart) виджет оборачиваем в:

GraphqlProvider(
 uri: 'http://$host:9002/graphql',
 child: MaterialApp(...),
)

Параметр bodyменяем полностью на:

Query(
 options: QueryOptions(
   documentNode: CompaniesDataQuery().document,
 ),
 builder: (
   QueryResult result, {
   Future<QueryResult> Function() refetch,
   FetchMore fetchMore,
 }) {
   if (result.hasException) {
     return Text(result.exception.toString());
   }

   if (result.loading) {
     return const Center(
       child: CircularProgressIndicator(),
     );
   }

   final allCompanies = CompaniesData.fromJson(result.data).allCompanies;

   return ListView.builder(
     itemBuilder: (_, index) {
       return ListTile(
         leading: Icon(Icons.card_travel),
         title: Text(allCompanies[index].name),
         subtitle: Text(allCompanies[index].industry),
       );
     },
     itemCount: allCompanies.length,
   );
 },
)

Перезапустите приложение, и у вас получится что-то наподобие:

Немного подробностей реализации:

Виджет Query предоставляет нам возможность отправить запрос.

В параметр documentNode мы передаем непосредственно сам запрос, сгенерированный artemis.

options: QueryOptions(
   documentNode: CompaniesDataQuery().document,
 ),

После того как flutter_graphqlперешел в версии 3 на documentNode формат, а artemisдобавил генерацию кверей, эти две системы стали замечательно работать вместе.

В функции builderтри стандартных части:

Вывод ошибки

if (result.hasException) {
     return Text(result.exception.toString());
   }

Вывод спиннера

  if (result.loading) {
     return const Center(
       child: CircularProgressIndicator(),
     );
   }

Вывод содержимого результата

   final allCompanies = CompaniesData.fromJson(result.data).allCompanies;

   return ListView.builder(
     itemBuilder: (_, index) {
       return ListTile(
         leading: Icon(Icons.card_travel),
         title: Text(allCompanies[index].name),
         subtitle: Text(allCompanies[index].industry),
       );
     },
     itemCount: allCompanies.length,
   );
 },

Итог

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

Весь код по ссылке.

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

• flutter;
• graphql-flutter;
• artemis;
• js-graphql-intellij-plugin.

В комментариях оставляйте ссылки на свои любимые библиотеки для работы с GraphQL.

А также присоединяйтесь к нашей группе «Art Flutter»в телеграме — нас много, и мы рады помочь вам с решением проблем :)

Чи можуть незрячі люди навчитись програмувати та працювати в IT? Відповідь на це питання знає Роман Боренько, співзасновник Inclusive IT у Львові. Разом з командою громадської організації він влаштував курси для незрячих з основ роботи з комп’ютером та Python. Як це переросло у соціальне підприємство, де працюють випускники курсів і до чого тут вебдоступність, Роман розповів для DOU.

Офіційно в Україні 6-7%людей з інвалідністю. Ці люди є частиною економіки країни, хоч їхня купівельна спроможність і нижча. Бізнесу варто це враховувати, і ми прагнемо в цьому допомогти. Візьмімо, зокрема, інтернет-магазини. Люди з сенсорними порушеннями (зір, слух) не зможуть самостійно щось замовити.

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

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

Від Сенсотеки до курсів програмування для незрячих та людей зі слабким зором

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

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

У 2012-2013роках я надавав IT-допомогу організації, а потім почав впроваджувати власні ідеї і обіймати керівні посади. В 2014 році засновника Миколи Пеха не стало, і ми замислились, що робити далі, в який бік рухатись. Я на той час вже цікавився тим, як живуть і працюють незрячі, тому озвучив ідею створення Сенсотеки у Львові.

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

Дитяча арт-терапія у Сенсотеці

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

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

Саме навчання заснувала Марта Дропа. Вона стажувалась у National Industries for Blind в США, де подивилась, як відбувається навчання, і побудувала систему для Inclusive IT, яка запустилася 2017 року. Звісно, постало питання, які саме курси робити: HTML, Java чи PHP, проте ґрунтовно ми зупинились на Python, тому що це найпростіша мова для незрячих, і при цьому доволі потужна. Крім того, ми виявили базові потреби у незрячих в користуванні комп’ютером, пакетом Microsoft, Google Docs, без яких працювати неможливо. Навчання триває 3-4 місяці.

На сьогодні ми маємо наступні курси:

• користування програмою екранного доступу NVDA незрячими;
• Word для незрячих;
• Excel для незрячих;
• англійська мова;
• HTML/Javascript для незрячих;
• Python для незрячих.

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

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

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

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

Python викладає Руслан Іськов (програміст та тестувальник), який навіть створив підручник з Python для незрячих. Цей підручник — набір статей, в яких доступно пояснюється, як програмувати за допомогою асистивного програмного забезпечення.

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

Іноді на курси приходять люди, які вже десь працюють, але хочуть покращити свої навички, аби швидше працювати з комп’ютером. Наприклад, Марія Гогільчин з Івано-Франківська — незряча юристка, якій дуже допомогло знання Excel. Іноді курси допомагають людині змінити життя: зокрема, Оксана Войтко заснувала своє підприємство «Handmade-клубок»і веде сторінки в соціальних мережах, а Олександр Грищенко з Черкас працює Python-програмістом.

Оксана Войтко

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

Руслан Іськов рекомендує використовувати для програмування Notepad++, і це не просто так, а тому що не всі програми добре працюють зі скрін-рідерами. Деякі програми, як і сайти, не адаптовані під потреби незрячих, це також намагається виправити Inclusive IT. Скрін-рідер — це просто озвучувач, який добре працює, якщо є забезпечення. Продукти від Microsoft, а також інструменти Google гарно пристосовані і запрограмовані з урахуванням потреб незрячих, тож ми можемо навчати ними користуватись. А все інше потрібно розглядати окремо.

Чим займається соціальне підприємство Inclusive IT та як сприяє розвитку вебдоступності

Отже, саме недоступність більшості сайтів і програм стала рушієм до створення соціального підприємства Inclusive IT. Те, чим ми займаємось, називається вебдоступністю. Ми тестуємо сайти і аналізуємо, наскільки вони доступні для людей з інвалідністю. Наші Accessibility QA`s мають сертифікати від провідних курсів з вебдоступності Deque Univeristy.

На сьогодні в команді вісім осіб: четверо тестувальників і тестувальниць, троє з яких незрячі, і адміністративний відділ. Я заохочую приходити до нас працювати студентів наших курсів. Наприклад, в Inclusive IT вже працюють випускниці Лариса Колот і Наталія Ульянова. Вони не лише тестують вручну сайти чи вебдодатки, але й враховують результати автоматичних тестів, які видає бібліотека axe-core. Завдяки курсу з англійської мови ми можемо писати баг-репорти, що дає нам переваги у роботі з іноземними клієнтами.

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

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

Якщо ви все ще не зрозуміли, що таке вебдоступність, поясню на кількох прикладах зі стандарту WCAG 2.1 (Web Content Accessibility Guidelines — Настанови з вебдоступності контенту).

1. Чи є альтернативний текст до зображень?
   Незряча людина відкриває сайт і починає читати його за допомогою скрін-рідера. Програма озвучує весь наявний на сторінці текст, але фото саме по собі не перетвориться на текст, доступний до озвучування. Необхідно описати зображення, аби програма екранного доступу змогла його озвучити за допомогою text-to-speech. Те саме стосується і кнопок, їм теж необхідні підписи.
2. Наскільки зручно користуватись сайтом лише з клавіатури?
   Як я згадував, незрячі користуються комп’ютером, в основному, з клавіатури. Але крім цього, є люди, які, наприклад, мають гіпс на правій руці або інші порушення опорно-рухового апарату. Вони не можуть користуватись мишкою, тож необхідно забезпечити повну функціональність сайтів та програм з клавіатури.
3. Чи має сайт чіткі кольори та шрифти?
   Користувачі зі слабким зором можуть не помітити, наприклад, світло-сірий напис на білому фоні.
4. Чи є можливість призупинки та відновлення для всієї анімації на сайті?
   Це необхідна вимога, що допоможе користувачам, які можуть не встигнути зрозуміти, що було на попередньому зображенні, коли насувається наступне.

Тема вебдоступності логічно увійшла до мого життя і громадської організації «ІУС», крім того, мене надихнули спроби незрячих колег працювати в IT. Мабуть, тому все і починає вдаватися. Крім того, ця тема затребувана в Європі та США, оскільки щомісяця збільшується кількість нормативних актів, що зобов’язують громадські місця, в тому числі і сайти, бути інклюзивними. Так само збільшується і кількість судових позовів для порушників. Я вважаю, що Україні слід підхопити цей рух. Необхідно надати людям можливості для освіти та працевлаштування, але на їхньому шляху перешкода — недоступні інструменти. Якщо оцінювати суб’єктивно, то в Україні невебдоступні щонайменше 90% сайтів.

Ви можете самостійно перевірити свій сайт за допомогою автоматичного тестування, яке доступне в інтернеті (плагін Axe для браузера, HTMLCodeSniffer, WebAIM та інші), але об’єктивно він виявляє не всі помилки. Наприклад, у тому полі, де має бути альтернативний текст до зображення, написано «зображення». І програма автоматичного тестування це пропустить, оскільки формально підпис є. Але це не те, що необхідно незрячому користувачу сайту. Ось чому наша команда не нехтує ручним тестуванням.

Ми хотіли б бути помічниками для будь-якого проєкту, який хоче зробити свої сервіси доступними для широкого кола користувачів. Запит на це на ринку потроху з’являється через розвиток нормативної бази, а також вплив західних практик. Є вагомі зрушення у питанні інклюзивності: наприклад, у супермаркеті «Ашан» 6% людей з інвалідністю серед всього персоналу. Або гарний приклад — пекарня Владислава Малащенка Good Bread from Good People, де люди з інтелектуальними порушеннями печуть кекси.

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

Заходи зі школярами

Третій напрямок Inclusive IT — робота зі школярами. Цього року у Львові ми активно співпрацювали зі школою-інтернатом № 100 для дітей з порушеннями зору. Зустрічі відбувались досить неформально, зі школярами ми обговорювали теми вебдоступності, інклюзивності, розбирали закордонні кейси, проводили дебати для розвитку софт-скілів.

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

Заняття зі школярами на тему вебдоступності

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

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

Всем привет! Меня зовут Вячеслав Сахаров, и сейчас я работаю на позиции Release Manager в компании Playtech. Начать я хотел бы с дисклеймера.

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

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

Каким образом я пришел к моделям зрелости

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

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

После длительного периода изучения best practice в поисковиках я натолкнулся на модели зрелости управления проектами в целом. К моему удивлению CMM (Capability Maturity Model), которая является прародительницей всех ныне известных моделей зрелости, — явление родом еще с 80-х.Несмотря на то что у нас о моделях зрелости ни сном ни духом, в Америке она активно используется и показывает высокий уровень эффективности. Тут стоит отметить, что изначально эта модель была разработана по заказу вооруженных сил США, а это уже говорит о серьезности вопроса. Тем не менее использование какой-либо из этих моделей не могло ограничиться только моим отделом, а требовало вовлечения всей организации, особенно менеджмента. Мне нужно было более быстрое и узкопрофильное решение.

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

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

Модели зрелости тестирования

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

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

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

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

Testing Maturity Model Integration (TMMi)

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

Critical Testing Processes (CTP)

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

Из минусов: есть сложности в актуализации модели, а последняя редакция сильно устарела.

Systematic Test and Evaluation Process (STEP)

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

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

IDEAL Model

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

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

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

Test Process Improvement (TPI Next)

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

Большинство моделей зрелости (в том числе те, которых нет в этом списке) объединяет общий паттерн, по которому происходит работа с ними. У них есть 5 уровней зрелости, свои процессные области и требования, которым должна соответствовать организация для перехода на следующий уровень. Сам переход на следующий уровень в большинстве моделей предполагает соответствие организации требованиям во всех процессных областях. И тут мы плавно подходим к вопросу отличия TPI Next от родственных моделей.

Структура TPI Next

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

Модель TPI Next включает в себя:

• 16 ключевых областей — разных составляющих процесса тестирования ПО в целом;
• 4 уровня зрелости. Их условно можно считать этапами совершенствования процессов в компании. Цель всех моделей зрелости — переход на новый уровень;
• 160 чек-пойнтов. Каждая из 16 ключевых областей обладает своими контрольными точками, которые служат для оценки процессов и помогают определить, к какому из 4 уровней зрелости они сейчас относятся;
• 13 кластеров. Грубо говоря, это степень приоритетности выполнения тех или иных чек-пойнтов. Некая разбивка уровней зрелости на спринты, подразумевающие совокупность задач в разных процессных областях, которые стоит выполнять вместе.

Что отличает TPI Next от других моделей зрелости тестирования

Быстрая для старта

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

Матрица зрелости: слева — 16 ключевых областей, справа — приоритизированные чек-пойнты

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

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

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

Пример чек-пойнтов для ключевой области Test process management

Открытая документация

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

Понятные чек-пойнты

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

Сам инструмент TPI Next — Exсel-файл с простейшей матрицей (см. скрин ниже). В строку напротив ключевых областей расположены сами чек-пойнты, у которых есть своя приоритетность в алфавитном порядке (те самые кластеры). Сначала стремимся выполнить все чек-пойнты с отметкой A, затем B, C и т. д. Эту приоритетность определяете вы сами на этапе адаптации модели к своим реалиям.

Пример чек-пойнтов для ключевой области Test organisation

А теперь о самих чек-пойнтах. Каждый из них — это, по сути, требования, которые нужно выполнить. Вот, например, первые 4 чек-пойнта для области Test organisation:

A. People involved know where to find the persons (or department) responsible for test services.
B. There is a structure of control and accountability within the test organization.
C. Test tasks and responsibilities are defined (and documented) and are assigned to a person or organizational unit.
D. The products and services of the test organization are clear to its clients.

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

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

Требует дополнения и адаптации

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

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

Теперь разберемся в том, что можно и нужно менять.

• Сами чек-пойнты.Если вас не устраивают требования, описанные в чек-пойнтах, или вы находите их неактуальными для себя, перепишите их. Главное, чтобы вы были уверены в важности и достижимости каждого чек-пойнта, а их содержимое было понятно всем участникам команды.
• Количество чек-пойнтов.Кому-то удобнее работать с более мелкими и узкими задачами, иным — смотреть на ситуацию более глобально и абстрактно. К какой бы группе людей вы ни относились, вы всегда можете подогнать под себя степень детализации чек-пойнтов и уменьшить или увеличить их количество.
• Порядок и приоритетность.Вы уже знаете, что у всех чек-пойнтов есть своя приоритетность. Тем не менее если та или иная область для вас более значима или проседает больше других, смените приоритетность. Приоритетность всегда очень относительная и придается чему-либо только в частном порядке. Главное, чтобы вы всегда знали, за что браться далее.
• Зоны.Несмотря на то что список ключевых зон у TPI Next исчерпывающий, некоторые из них могут оказаться для вас лишними. Или же, наоборот, некоторых областей может не хватать, как, например, мне не хватало автоматизации (которую мы добавили как 17-юзону).
• Уровни. TPI Next построена на базовом для всех моделей зрелости количестве уровней зрелости, и, как по мне, оптимальном. Тем не менее если вас по каким-то причинам такая концепция не устроит, можно и это поменять.

Необходимо массовое вовлечение

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

• Начальство.Для того чтобы практиковать подход TPI Next, так или иначе понадобится время. Время — это ресурс, который вам должны выделить. Во избежание дальнейших недоразумений убедитесь в том, что топ-менеджмент понимает, за что вы боретесь, поддерживает вас и готов способствовать вашим устремлениям. Как минимум некоторые чек-пойнты будут касаться вашего руководителя напрямую и требовать от него работы над собой (в случае пробелов по этой части).
• Коллеги или подчиненные.Люди очень не любят перемены, это факт. И вам придется очень постараться, чтобы убедить их в целесообразности предлагаемых нововведений. Они будут упираться, говорить, что «раньше было лучше», что вам ничего не надо улучшать или что это не сработает. Но без них у вас ничего не получится. Совет один: убедите их попробовать, поставьте очень скромные и реалистичные цели для первого этапа и наберитесь терпения. Как только они увидят первые результаты и закрасят в табличке новые чек-пойнты зеленым цветом, энтузиазма прибавится.

Варианты имплементации TPI Next

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

Все за, а вы получаете полный карт-бланш.

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

Начальство за, а команда против.

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

Команда за, а начальство говорит «не сейчас».

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

Все против, и вы чувствуете себя Кассандрой XXI века.

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

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

Мой личный опыт внедрения

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

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

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

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

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

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

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

По большей части вся предстоящая работа вращалась вокруг следующих задач:

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

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

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

• полноценное использование автоматизации;
• организация литературного клуба для шеринга знаний;
• подготовка команды к участию в QA-ивентах;
• внедрение новых инструментов и процесса R&D внутри отдела.

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

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

Выводы

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

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

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

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

За традицією зібрали найцікавіші, на думку редакції, ролики, зняті минулого року.

#MakeUsefulUnboring — гасло MacPaw.

Кажуть, у NIX відбуваються дива...

Цього року новорічний корпоратив NetPeak був у стилі весілля 90-х.Ось і відео.

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

А так у Poster зустрічають нових співробітників.

ELEKS вирушає назустріч викликам на ракеті з педалями.

«Втеча з Шоушенка» від AB Soft. П-с-с-с, пацани, якщо вас дійсно ув’язнили — підморгніть двічі.

Redwork — головні фанати GoT. Дочекались виходу останнього сезону, а далі що? Фінал сподобався хоч?

Не зоовсім впевнені, що це таке, але курочка нормально співає.

А ви так можете? Давайте, спробуйте і покажіть відео #bottlecapchallenge

А так співробітники київського офісу SoftServe боролись з надмірною кількістю опадів. Плавзасіб лишився з корпоративу :)

Переглянути цей допис в Instagram

Допис, поширений dtp.kiev.ua (@dtp.kiev.ua) 29 Лип 2019 р. о 6:21 PDT

Уявіть, якби сміття ожило і напало на вас... CleanMyMac показали, навіщо прибирати непотріб.

У ЛУН влаштували змагання: хто швидше добереться з м. Вишневе до найближчої станції метро.

IT Academy SoftServe — це коли на плейстейшн не залишається часу.

Про жінок в ІТ уже багато жартували, але так, напевно, ще ні.

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

На улице зима, а это значит, что хочется быть поближе к горам. В связи с этим хочу всех пригласить на VITechGym митап, который пройдет 23 января во Львове и будет посвящен Computer Vision. А если вы любите кататься и планируете быть в Буковеле в период с 24 по 26 января, то команда спикеров митапа будет рада продолжить общение уже на склонах и вместе отлично отдохнуть ;) Присоединяйтесь! А пока предлагаю свежую подборку материалов.

Predictions

AI, Analytics, Machine Learning, Data Science, Deep Learning Technology Main Developments in 2019 and Key Trends for 2020 — редакция KDnuggets пообщалась с экспертами о том, какие были основные события в области машинного обучения и искусственного интеллекта в 2019 году и какие основные тенденции они ожидают в 2020 году.

Baidu Research: 10 Technological Trends in 2020 — прогноз 10 основных технологических трендов на 2020 год от команды Baidu Research.

Industry AI, Analytics, Machine Learning, Data Science Predictions for 2020 — мысли представителей индустрии, что нас ждет в 2020 году от таких компаний как: Alluxio, Alteryx, AppenGlobal, CasertaData, Circonus, dotDataUS, Infoworksio, Izenda, Lexalytics, Mathworks, Percona, Sisudata, and StreamSets.

Data Science Trends for 2020 — что нас ожидает в 2020, по мнению Hugo Lopes (SW Engineer & Data Science Manager at Google).

Статьи

Data project checklist — хороший список вопросов, который может вам помочь понять детали data-проекта перед его стартом.

Introducing Flyte: A Cloud Native Machine Learning and Data Processing Platform — о data-платформе, которую построили в Lyft.

NLP Year in Review — 2019 — хороший обзор NLP за 2019 год.

Open Sourcing Manifold, a Visual Debugging Tool for Machine Learning — обзор новой системы для отладки моделей от Uber.

ML4H 2019: Machine Learning for Health — обзор докладов воркшопа Machine Learning for Health, который прошел на NeurIPS 2019.

Anomaly Detection with Autoencoders in TensorFlow 2.0 — статья о том, как разработать нейронную сеть для обнаружения аномалий, используя TensorFlow 2.0.

Using neural networks to solve advanced mathematics equations

An Introduction to Biomedical Image Analysis with TensorFlow and DLTK — статья о том, как начать работать с медицинскими изображениями, используя TensorFlow и DLTK.

GPU Dashboards in Jupyter Lab — обзор расширения NVDashboard, которое позволяет мониторить GPU в Jupyter Lab.

Научные статьи

Начиная с сегодняшнего выпуска, я запускаю еще один блок, о котором просили многие. Сегодняшняя подборка научных статей — это статьи из канала #article_essence Slack-чата Open Data Science сообщества, к которому я приглашаю всех присоединяться.

Self-training with Noisy Student improves ImageNet classification

Momentum Contrast for Unsupervised Visual Representation Learning

Plug and Play Language Models: A Simple Approach to Controlled Text Generation

Analyzing and Improving the Image Quality of StyleGAN

Side-Tuning: Network Adaptation via Additive Side Networks

Stacked DeBERT: All Attention in Incomplete Data for Text Classification

Видео

Deep Learning State of the Art (2020) — MIT Deep Learning Series

2019 Conference on the Mathematical Theory of Deep Learning

Chai Time Data Science — Eugene Khvedchenya | Kaggle, Computer Vision & Best Code Practises

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

VITechGym meetup: Tricks and hacks for Computer Vision — 23 января, Львов. На митапе поговорим про аугментацию и семантическую сегментацию изображений, а также про новые ML сервисы от AWS.

Data Science UA — 14 марта, Киев. Для читателей дайджеста скидка 7% по промокоду: DSdigest_7.

Data Science fwdays’20 — 13 июня, Киев. Для читателей дайджеста скидка 15% по промокоду: digest_dsfwdays.

Eastern European Computer Vision — 11-12 июля,Одесса.

Odessa Data Fest — 5 сентября, Одесса — бесплатная конференция сообщества Open Data Science. Бронируйте дату, регистрация скоро будет открыта. Если вы желаете выступить с докладом, пишите мне в личку.

На крутой healthcare проект в VITechмы ищем Data Engineer. По всем вопросам можно писать мне в личку.

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

Присоединяйтесь к Telegram-каналудайджеста и его страницам в соцсетях: Medium, Facebook, Twitter, LinkedIn.

← Предыдущий выпуск: AI & ML дайджест #15

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

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

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

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

Спочатку основним мотиватором було насильство

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

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

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

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

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

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

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

Ілюзія контролю

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

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

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

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

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

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

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

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

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

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

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

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

Чому не варто покладатися на мавпу

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

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

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

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

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

Уся наука про мотивацію — своєрідний перекладач з людської мови на мавпячу

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

Так, звісно, можна. Тільки дуже ненадовго.

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

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

Горезвісне тренування сили волі — нонсенс

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

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

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

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

Найпростіший стимул — негативний

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

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

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

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

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

Рутина — це зрозумілий мавпочці мотив

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

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

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

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

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

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

Як ми вираховуємо користь від дії

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

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

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

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

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

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

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

Самооцінка: підпишіться на Ілона Маска

У голові кожної людини є чітке уявлення про те, що вона може, а що ні. Часом це уявлення може бути викривлене (12% американських чоловіків вважають, що зможуть узяти гейм у грі із Сереною Вільямс), а часом — вигнуте в протилежний бік («та чого я туди резюме слатиму, я ж тупий»).

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

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

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

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

З чітким планом — простіше

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

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

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

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

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

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

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

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

Еволюція: розмножитися й вижити

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

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

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

Розмноження, утім, часом мотивує навіть сильніше, ніж виживання. Тіло конкретної істоти рано чи пізно однаково зіпсується. А ось гени, які воно несе, можуть прожити куди довше.

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

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

Прагнення статусу

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

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

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

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

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

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

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

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

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

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

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

Допамін та жага до пізнання

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

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

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

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

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

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

Я казав, що статус породив і мистецтво? Що ж, я збрехав, бо допаміновий складник там не менший, а то й більший. Деколи щось робиться не тому, що приносить користь, а просто тому, що це має бути зроблено. «Я пишу, бо не можу не писати». Знайомо?

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

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

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

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

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

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

Насамкінець

Хочу додати ще одну ремарку.

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

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

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

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

А як ні, то ні. Може, воно вам просто не треба? Підіть краще поспіть.

Ілюстрації Каталіни Маєвської

Я Ігор Стареправо, VP Delivery в Intellias, і відповідаю за automotive-вертикаль у компанії.

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

ІТ та automotive — дві, на перший погляд, різні індустрії, але, якщо придивитися уважніше, мають багато спільних історичних паралелей. Читаючи мемуари таких знакових осіб в автомобілебудуванні як Генрі Форд (Henry Ford) і Лі Якокка (Lee Iacocca), я помітив певну схожість в етапах їхнього розвитку, яку опишу в цій статті. Давно шукаю відповідь на одне важливе запитання: чи можливо обернути процес створення програмного забезпечення з яскравого індивідуального мистецтва програміста-одинака в індустріальну машину, що продукує якісний і функційний код, з ефективністю, властивою сучасній автомобільній індустрії?

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

Автомобільна індустрія: розвиток і теперішня ситуація

В автомобільній індустрії все почалося з того, що 1806 року швейцарський винахідник Франсуа Ісаак де Ріваз (François Isaac de Rivaz) винайшов перший двигун внутрішнього згоряння. Через рік він збудував рухомий транспорт на базі карети, який приводили в дію через цей двигун. Навряд чи за цим одороблом хтось бачив майбутнє суспільства й світової економіки.

1886-гоКарл Бенц запатентував свій винахід — триколісний автомобіль Motorwagen, що рухався завдяки чотиритактному бензиновому двигунові, розміщеному між двома задніми колесами. Через три роки чоловік почав продавати свої автомобілі. До того часу такі продукти були справою ентузіастів, які у вільний від роботи час конструювали «саморухомі» апарати. Використання таких транспортних засобів не виходило за межі особистих інтересів аматорів, бо на вулиці панували «дорослі» парові машини.

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

1908 року компанія Ford створила Ford Model T — перше доступне авто для середньостатистичної американської родини. 241 компанія в проміжку 1904–1908 рр.виготовляла автомобілі для американського споживача, але вони коштували щонайменше вдвічі дорожче за машину Форда, були популярні в бізнесі, їх сприймали як «примхи для багатіїв». На зорі IBM PC, 1977 року, Кен Олсен, основоположник комп’ютерної індустрії, власник DEC, сказав: «Я не бачу ні найменшої потреби в комп’ютері вдома». Проте вже в 80-іроки PC почали масове проникати в малий бізнес, школи й домівки простих людей.

1913-гоГенрі Форд розпочав конвеєрне виробництво Ford Model T, зменшуючи час виготовлення одного авто до 93 хвилини, поділивши процес створення деталей на 45 кроків. Це відкриття було революційним для автомобілебудування, давши згодом новий напрямок розвитку для всього індустріального виробництва. 1918 року половина всіх американських автомобілів була Ford Model T. Це щось таке ж масове, як поширення Windows у 1990-хроках.

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

20–30-ті пам’ятають у США через Велику депресію. Автомобільне виробництво тоді зменшилося на 50%. Багато хто з нас пам’ятає dot-com bubble, коли за один рік понад 80% інтернет-компаній обернулися в порох.

У 1960-хавтовиробники сконцентрувалися на безпеці автомобілів. І в ІТ останні 10–15років спостерігається значне посилення уваги до інформаційної безпеки.

У 1990-хпочали порушувати питання поступового вичерпування ресурсів, що призвело до появи на дорогах електромобілів — технології, відомої з середини IX сторіччя. Поступове зростання потужності CPU і побудову масштабних ЦОД тепер змінюють гібридні процесорні архітектури, compute fusion, IoT та новий етап розвитку embedded-технологій.

1991-го Toyota започаткувала Lean Manufacturing. А ви, напевно, думаєте, що Agile — це унікальна ідея, що виникла в найліпших головах розробників програмного забезпечення?

Пропущена ланка

Сподіваюся, я не втомив вас своїми паралелями? Є, втім, одна дуже важлива ланка розвитку автомобілебудування, яку пропустили в ІТ. Повернімося в 1913 рік, коли конвеєрне виробництво стало причиною завоювання ринку Фордом. А що призвело до домінування Microsoft наприкінці 1990-х?З усією повагою до цих хлопців, але це не принципово новий метод розробки програмного забезпечення. Тут вплинуло багато чинників, зокрема й фокус на новий ринок домашніх PC, і партнерство з IBM, і низка досить далекоглядних вирішень, які на той час були доволі неочевидними. Однак факт залишається фактом — Microsoft ні до, ні після не винайшли принципово інших методів розробки ПЗ, і дотепер це «жупел» якості програмних продуктів.

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

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

Чому ж в ІТ досі немає свого «конвеєрного виробництва»? Одна з версій: ІТ-продукт не має проблеми тиражування, властивої автоіндустрії. Так, але навіть Model T пережила близько сотні модифікацій і редизайнів, водночас залишаючись надійним агрегатом. Інша версія — це значно більша кількість і сувора відповідність стандартам. Безумовно, уся сучасна виробнича індустрія базується на сотнях галузевих норм, стандартів і типових вирішень. Ми не замислюємося, чому болт не може бути автомобільним чи паротяговим — він такий, бо його конструкція довела свою життєздатність. У софті немає ні своєї гайки, ні болта. За більш ніж 30 років існування індустрії програмного забезпечення ми перейшли від функційного до об’єктно орієнтованого (і назад), до методів машинного навчання та розподілених мікросервісів. Але нічого конкретного так і не вибрали.

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

Висновок

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

У минулій статті розглядали зарплати розробників. Тепер дивимося на зарплати тестувальників.

З 2 грудня до 5 січня в черговому зарплатному опитуванні взяли участь 10 187 респондентів, із них 1720 — тестувальники. До них відносимо QA Engineers усіх рівнів (Junior, Middle, Senior, Tech Lead) та спеціалізацій (Manual, Automation, General, Performance). Зарплати інших технічних і нетехнічних спеціалістів розглянемо в заключній статті циклу. Але ви вже зараз можете подивитися їх у віджеті.

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

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

Середні зарплати

У цілому зарплати тестувальників демонструють позитивну динаміку. Вперше за півтора року відбулося зростання медіанної зарплати Junior QA — на $100, і наразі вона складає $600. Це найвищий показник з 2014 року. Зарплата зросла у всіх топ-5 містах, окрім Харкова — тут зарплата джуніорів навпаки зменшилася на $60.

Медіанна зарплата QA Engineers за півроку збільшилася з $1400 до $1500. За останні три роки вона зросла на $350. У другому півріччі 2019-гонайбільше зростання відбулося у Києві й Дніпрі — на $200 і $150. У Харкові і Львові зарплата спеціалістів цього рівня зросла несуттєво — близько $50. А в Одесі спостерігається негативний тренд — зменшення на $150 за півроку.

Зарплати Senior QA за останнє півріччя майже не змінилися. У Києві після активного зростання до $3000 в першому півріччі 2019-го,наприкінці року медіанна зарплата знову зменшилася до $2800. У Харкові, Львові, Дніпрі суттєвих коливань із зарплатами сеньорів не відбулося. Значне збільшення медіанної зарплати Senior QA в Одесі ймовірно пов’язане з невеликою кількістю анкет у цій категорії.

Динаміка

Найбільше отримують київські QA TechLead — $3600, а найменше — харківські Junior QA — $500. Доволі невисока середня зарплата у QA Engineers у Запоріжжі — лише $825, але там майже всі респонденти Manual QA приблизно з трьома роками досвіду.

За посадами

Senior Automation QA у Києві отримує на $1100 більше, ніж київський Senior Manual QA — $3560 проти $2400. Серед великих міст найнижчі зарплати у Manual QA Engineers у Дніпрі й Одесі — $1100 й $1000 відповідно. Тим часом коли у Києві їхня медіана — $1500.

За містами

Майже не відрізняється середня зарплата Junior Manual і General — $550 проти $600. А ось у джунів автоматизаторів зарплата вже суттєво вища — $720. Середня зарплата Senior Automation QA на $1300 вища за зарплату Senior Manual QA.

За спеціалізацією

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

Найбільш популярні мови серед тестувальників — Java (355 анкет), JavaScript (159), Python (150) і C# (149). Близько половини опитаних відповіли, що не використовують жодної мови програмування на поточній посаді. І їхня середня зарплата майже в два рази менша за тих, хто використовує — $1000 проти $2000 для Java і C# й $1800 для JavaScript і Python.

За мовами програмування

Найвищі середні зарплати у Junior QA із C# — $670. У Java і Python — по $600. У тих джуніорів, що не використовують жодної мови програмування, медіана — $550.

Цікаво, що серед QA Engineers зарплати тих, хто має у своєму арсеналі Python на $200 вищі за C# й JavaScript. А у сеньорів майже все зрівнюється — по $3000 середня зарплата у Java, Python, C#, тільки у JavaScript — $2700.

За мовами програмування і посадами

На відміну від розробників, різниці у розмірі середньої зарплати між аутсорсом і продуктом серед тестувальників немає — незалежно від рівня спеціаліста зарплати у цих типах компаній однакові. На цьому тлі суттєво вирізняється аутстаф, де QA Engineer і Senior QA отримують на $200 більше, ніж в аутсорсі й продукті.

За типом компаній

Найвищі зарплати серед випускників КПІ та ХНУРЕ — $2000, а найнижчі — в ХПІ ($1470) і ЛНУ ім. Франка ($1285).

Серед студентів мінімальний бар’єр у 10 анкет подолав лише один виш — ХНУРЕ, студенти-тестувальники якого отримують близько $650. За результатами літнього опитування їхня середня зарплата складала $500.

За вишами

Середні зарплати чоловіків і жінок QA

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

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

Незважаючи на те, що жінок більше саме серед Manual QA, але і там ситуація майже не відрізняється від загальної картини: наприклад, чоловіки Manual QA із досвідом більше 6 років отримують на $300-400 більше за жінок із тим самим досвідом і спеціалізацією.

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

Інтерактивний зарплатний віджет

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

Детальна інформація з розбивкою за категоріями, містами та досвідом у розділі «Зарплати».

Дані про кількість вакансій і відгуків дивіться в розділі «Тренди».

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

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

Ця стаття — третя із серії матеріалів на DOU, яку присвячено здоров’ю. Тут ви знайдете поради від психотерапевтів і психологів (серед яких ІТ-фахівці) щодо симптомів та профілактики поширених психологічних захворювань, а також кейси від ІТ-спеціалістів і HR. Уже опубліковані статті з загальними порадамита порадами від невролога.

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

Ілюстрації: Дарина Скульська

Чому складно провести межу між фізичним та психологічним здоров’ям

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

Утім, психічне й фізичне здоров’я пов’язані набагато сильніше, аніж ми звикли думати, і часто за фізичним (соматичним) симптомом стоять психічні чинники. The World Health Organization (WHO) прямо заявляє, що there is no health without mental health, і наводить приклади взаємозалежності хронічних захворювань і психологічних проблем (одне може спричинити інше, і навпаки). Але справжній взаємозв’язок не обмежується лише хронічними станами.

Є спеціальна медична сфера під назвою психосоматика, яка вивчає вплив психологічних і соціальних чинників на фізичне здоров’я. Варто сказати, що, хоч вона й розвивається дуже активно останні років сто, запитань, на які немає переконливих відповідей, досі багато. Один із батьків-засновників сучасної психосоматичної медицини Франц Александер, запропонував «святу сімку» захворювань, в основі яких лежать психологічні причини (представники the holy seven — бронхіальна астма, нейродерміт, гіпертонія тощо).

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

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

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

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

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

Важливість емоційного здоров’я

Олександр Конопко, Consultant in Java / Big Data і за сумісництвом психотерапевт-практик, розповідає, що порушення зв’язку з емоційною сферою життя призводить до появи численних симптомів:

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

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

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

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

Ризики для ІТ-фахівців

З персонального досвіду Анни Метельської, співзасновниці Mental Health for Business, консультантки з психічного здоров’я в організаціях і психотерапевтки, найтиповіші складнощі, з якими стикаються люди у сфері психічного здоров’я в усьому світі (й Україна не виняток), — це депресії, біполярні афективні розлади (БАР), тривожні розлади, соціальні фобії та залежності (наркотична, алкогольна, ігрова тощо). Щодо України, то тут люди ще доволі часто стикаються з ПТСР (посттравматичний стресовий розлад) у зв’язку з тривалою війною на Сході.

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

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

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

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

Профілактичні заходи для попередження ризиків

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

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

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

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

Як вибрати психотерапевта

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

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

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

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

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

Ще варто сказати кілька слів про різницю між психологом, психотерапевтом і психіатром.

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

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

Психотерапевт — людина з психологічною, гуманітарною або медичною освітою, яка додатково (5–6 років)вивчала один або кілька психотерапевтичних методів (наприклад, позитивну крос-культурну психотерапію, екзистенційний аналіз, психоаналіз, транзакційний аналіз, гештальт-терапію, клієнт-центровану терапію тощо).

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

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

Вартість годинної консультації у фахівців дуже різна й коливається від 400 до 2500 грн/год. Середня ціна в Києві становить 600–800 грн.

Докладніше про психічні розлади

Професійне вигорання

Наталя Павлова, керівник компанії «Студія розвитку керівників SmartTime», консультант з керування та психотерапевт, вважає, що важливо розуміти формулу вигорання. Якщо уявити цю формулу спрощено, то можна сказати, що вигорання — це сума:

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

Проте є дві добрі новини.

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

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

А які ж ознаки справжнього професійного вигорання? Коли насправді вже пізно пити «Боржомі»?

Цих ознак усього три. До речі, саме їх перераховує шкала відомого тестуК. Маслач і С. Джексона:

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

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

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

Фронт перший — стрес-менеджмент і керування енергією. Стежте за здоров’ям, вчасно проходьте діагностику, здайте кров на баланс вітаміну D і кортизол. Розберіться зі сном і режимом дня, медитуйте й робіть розтяжку вранці та ввечері, щоб розслабити м’язи. Улаштовуйте довгі відпочинки: по 7–14днів тричі на рік або частіше.

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

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

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

Депресія

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

Вона зазначає, що, за даними Всесвітньої організації охорони здоров’я (Depression and Other Mental Health Disorders research, 2017, page 20), Україна посідає перше місце в Європі за кількістю тривожних і депресивних розладів. У всьому світі на депресію страждає майже 300 млн людей (і це дані тільки щодо цивілізованих країн, де є якісна діагностика). І ця кількість постійно зростає.

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

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

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

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

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

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

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

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

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

1. Стежте за якістю сну. Він має бути регулярним, достатнім за тривалістю й повноцінним. Я цілком позитивно ставлюся до коротких курсів снодійного. Невропатолог може призначити його в разі порушень сну, які ви не можете скоригувати самостійно.
2. Забезпечте собі регулярний і повноцінний відпочинок. Це може бути будь-яка діяльність, яка розвантажує мозок і додає вам сил, а не забирає їх. Наприклад, перемикайтеся з розумової діяльності на фізичну. Або якщо ви стомилися на роботі, ліпше побудьте вдома в тиші або погуляйте в парку, аніж проводити ніч з друзями в гамірному барі. Не дозволяйте втомі стати хронічною.
3. Займайтеся спортом і бувайте на свіжому повітрі.
4. Практикуйте позитивне мислення. І займайтеся активностями, які вас наповнюють і приносять радість.
5. Повноцінно харчуйтеся (особливо важливо вживати продукти, що сприяють синтезу серотоніну, як-от чорний шоколад, банани, фісташки, жирні сорти риби тощо).
6. У темний період року (з жовтня по квітень) вживайте вітамін D (зазвичай це 2000 МО на день). Але найліпше здати аналіз на рівень цього вітаміну в організмі й дібрати ідеальну для вас дозу з допомогою лікаря.
7. Також добре працюють активності, які допомагають розслабитися (спа-процедури, масаж тощо).
8. А ще — спілкуйтеся. З приємними вам людьми й ліпше наживо. Дослідження доводять, що люди соціальні, тобто які пов’язані з іншими й мають на кого спертися, щасливіші й менш тривожні.
9. Крім того, хороша профілактика депресії — регулярна робота з психотерапевтом, який допоможе краще розуміти ваші психічні особливості, правильно реагувати на стресові події й ефективно розв’язувати конфлікти в робочому та особистому житті.

Також частиною профілактики є обережне ставлення до традиційного й некоректного сприйняття депресії:

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

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

Mindfulness — як один зі способів поліпшити психічний стан

Вікторія Горбунова, доктор психологічних наук, психотерапевт, експерт із психічного здоров’я в організаціях, радить застосовувати практику Mindfulness.

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

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

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

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

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

Досвід ІТ-компаній

Редакція DOU звернулася до українських ІТ-компаній з проханням розповісти, як керівництво дбає про здоров’я своїх співробітників.

У компанії Intellias проводять тренінги Stress Management, завдяки яким можна вдосконалити свої навички керування стресом, а соцпакет AB Soft містить щотижневі консультації в корпоративного психолога, доктора психологічних наук Тетяни Рожнової.

Турбота про співробітників у Poster ґрунтується на філософії wellbeing. Її суть у тому, щоб підтримувати баланс між фізичним, емоційним і фінансовим добробутом, а також формувати усвідомлене ставлення співробітників до власного здоров’я. У працівників компанії є можливість безпосередньо в офісі отримати безоплатну психологічну консультацію. У штаті компанії є два people partners. Вони проводять індивідуальні психологічні консультації, а раз на три місяці — one-on-one-зустрічі з кожним співробітником, щоб оцінити загальну психологічну ситуацію в колективі й запобігти можливим конфліктам.

У Beetroot восени 2019 року спільно з Urban Space Radio створили цикл програм під назвою «Хтознаяк», присвячених психічному здоров’ю на роботі й поза нею. Щотижня там нова тема й гість студії. Уже говорили про професійне вигорання, особливості сну, токсичні стосунки, mindfulness, культуру зворотного зв’язку тощо. Можна слухати ефір або потім завантажити подкаст отут. У компанії також регулярно проводять серію внутрішніх і відкритих подій про самопочуття на роботі — #beetrootoyourself (якщо швидко прочитати, Beetroot тут перегукується з be true to yourself — будь самим собою).

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

Lohika організовує різноманітні тренінги, наприклад Burnout та Emotional Intelligence. Задля збереження work-life balance співробітники мають різдвяні канікули (з 31 грудня до 7 січня), окрім планованих відпусток і вихідних.

А ось що говорять ІТ-фахівці про власний досвід.

Вікторія Павліченко, бізнес-консультант в ІТ:

Юрій Козій, організаційний консультант, керівний партнер компанії AgileDrive:

Наталя Петровська, UI/UX Designer:

Анатолій Шарà, аналітик One Philosophy Group of Companies:

Vladyslav Vcherashnii, Senior iOS software engineer в Softwarium:

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

Привіт! Мене звати Олена, і я працюю продакт-менеджером у київському офісі компанії N-iX. До цієї позиції я йшла сім років, працюючи в різних компаніях і на різних посадах. Починала роботу в IT як проджект-менеджер в ізраїльському стартапі Waze. Прийшла в цю сферу без будь-якого технічного бекграунду, маючи за плечима лінгвістичну освіту, досвід роботи перекладачем і вільно володіючи англійською й німецькою мовами.

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

У цій статті поділюся власним досвідом роботи продакт-менеджера в аутсорсинговій компанії. Окреслю головні правила життя продакта, які допоможуть як початківцям, так і досвідченим POs (Product Owners), що починають розробку нового продукту.

Image by Paul Garland

1. Продакт-менеджмент — це не романтика

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

Якщо коротко описати мої обов’язки за весь час роботи на цій посаді, то сюди входять не тільки звичні всім market research, vision, roadmap, планування, специфікація, демо тощо. За ці роки я навчилася бути трохи психологом і трохи дипломатом. Доводилося мирити стейкхолдерів, вислуховувати їх у приватній розмові й, головне, чути кожного, не боятися сказати «ні», обстояти власну позицію в розмові з CTO, вислуховувати найнеприємнішу критику й фідбеки від клієнтів.

2. Будьте готовими до недовіри з боку клієнта

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

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

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

Проте той факт, що я знаходилася поряд з командою розробників, мав безліч плюсів:

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

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

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

3. Вам доведеться щоразу починати з нуля

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

Проте завдяки цим складним умовам, з часом я здобула безліч нових знань у різних галузях — наприклад, отримала безцінний досвід в сфері охорони здоров’я в США й Канаді. Пройшла сертифікацію HIPAA, глибоко дослідила основні вимоги стосовно безпеки даних пацієнтів (PHI), а потім перейшла на новий проект — і знову все спочатку :)

4. Вивчіть сферу до старту проекту

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

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

Ваш список справ на перші 30 днів роботи:

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

5. Переконайтеся, що ви отримали доступ до всієї інформації

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

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

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

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

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

6. Знайте своїх стейкхолдерів

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

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

7. Поясніть вашу роль та обов’язки

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

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

Як я вирішила цю проблему:

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

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

8. Пропонуйте свою допомогу

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

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

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

9. Розвивайте емоційний інтелект

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

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

10. Перетворіть неподатливих стейкхолдерів на союзників

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

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

11. Будьте переконливими та підготовленими

Наполегливим стейкхолдерам замало вашого слова як професіонала.

Попри 9-річнийдосвід роботи, я жодного разу не дозволила собі прийти на зустріч непідготовленою чи відповісти на запит стейкхолдера простим «ні», без обґрунтувань і пояснень. Я завжди маю напохваті конкретні докази: дослідження ринку, технічну оцінку й відгуки кінцевих користувачів. Стейкхолдери завжди мають розуміти, як ви дійшли певних висновків і чому ухвалили конкретне рішення. Тоді вони не потребуватимуть додаткових переконувань чи дискусій.

12. Залучайте ключових стейкхолдерів на кожному етапі (і чим раніше, тим краще)

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

Для себе я розробила ідеальну схему взаємодії зі стейкхолдерами:

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

З таким підходом стейкхолдери отримують навіть більше інформації, ніж їм насправді потрібно :)

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

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

13. Будьте терплячими

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

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

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

Начать следует с двух важных тезисов:

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

Африка. Бизнес

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

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

Микрокредитование в Африке

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

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

Кредиты бывают на 20 или 30 недель. Да, они выплачиваются еженедельно равными частями. Заемщик может заплатить больше ожидаемого, но не меньше. Если один человек не платит — платит группа. Ставка по кредитам варьируется от компании к компании в диапазоне 15-30%.Как правило — не годовых. Даже если заемщик платит вперед, сумма, которую он должен вернуть, не меняется. Например, заемщик получает $100 под 25% — значит, он должен вернуть $125, и не имеет значения, сделает он это за 1, 5, 20 или 30 недель.

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

Кредит на одного человека стартует с $80, что эквивалентно 300 тысячам угандийских шиллингов. Имея за плечами 3-4закрытых кредита и хорошую бизнес-идею, можно получить до $300.

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

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

На что же тратятся кредитные деньги? Основные бизнесы заемщиков: ритейл-магазины, кафе и рестораны, секонд-хенд, аграрная сфера (выращивание овощей, бананов).

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

Примеры статей расхода: усовершенствование оборудования или закупка товаров для сбыта. $200 — на покупку поливалок или партию одежды из Европы более чем достаточно.

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

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

Про три реальности

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

Подготовка к поездке

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

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

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

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

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

Теория VS практика

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

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

Но мы все равно полностью провели этот день на выезде.

Путаница и недостаток информации

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

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

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

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

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

Состояние бизнесов

Слоган местной строительной компании — There is so much to do. В целом, на этом можно заканчивать этот пункт. Но перейдем к деталям.

Ручной труд

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

Технологии

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

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

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

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

Интернет

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

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

Качество мобильного интернета отличное. Здесь LTE, покрытие практически везде. Вот только стоит это $90 в месяц. Помня о суммах кредитов, понимаем, что это удовольствие не для каждого.

Мобильные деньги

Mobile money — местный феномен. Тут важны два фактора:

1. Практически у всех есть какие-никакие телефоны.
2. Простые люди не могут открыть даже дебетовый счет в банке, так как считаются неблагонадежными.

По этим причинам телекомы превратили мобильные номера в платежные карты. И фактически стали банками. На счет телефона можно положить деньги и потом расплачиваться ими где угодно.

Провайдер мобильных денег Pegasus и пример их использования

Используя USSD-меню, можно платить за коммуналку и перекинуть деньги другу. Комиссии при этом космические. Простой P2P-перевод обойдется в 5-20%в зависимости от суммы.

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

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

Выпуск такой карты стоит $1,8, обслуживание — $2,7 в месяц. И это совсем не платиновая карта «Монобанк».

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

Образование

У ребят очень слабая база. Нужно обучать основам.

Офисы

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

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

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

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

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

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

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

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

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

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

Английский

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

Идеи

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

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

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

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

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

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

Выводы

Работая с Африкой:

1. будьте готовы к разнице менталитетов;
2. не верьте словам и обещаниям. Верьте только в то, что видите сами;
3. даже не пытайтесь ничего делать сами — ищите местного партнера;
4. по возможности встречайтесь лично. Если нет возможности — ищите. Здесь это важно;
5. инвестируйте в обучение;
6. не работайте с наличными.

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

Привет! Меня зовут Ян, и я работаю в сфере ИТ с данными более 10 лет — начиная с телекомов и заканчивая финансами и текстовыми корпусами (text corpus). Работая над одним из своих личных проектов, а именно над AI.Decider — системой помощи принятия ежедневных решений для обычных пользователей, я проанализировал огромное количество информации о том, как на самом деле люди принимают решения. И хотя проект еще далек от совершенства и ожидает нескольких пивотов, накопленная информация, которую я структурировал в этой и последующих статьях, может быть полезна не только в сфере принятия решений, но и всем, кто работает в области User Experience; а это, как мы знаем, достаточно широкая область применения.

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

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

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

Ну что же, приступим!

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

Манипулятивная модель АРЕТ

Модель, изображенная выше, соответствует научной модели APET, построенной нейробиологами, и расшифровывается следующим образом:

• Аctivating agent — это то, над чем вам предстоит поработать в своем продукте после прочтения этой статьи, триггер для воздействия на позитивное решение пользователя. Этот триггер может быть нацелен на одну из последующих (или все) подсистем модели мозга пользователя.
• Рattern matching — инстинктивный поиск паттерна на основании предыдущего опыта пользователя.
• Еmotions — эмоции, которые мы хотим вызвать у пользователей.
• Тhoughts — логические размышления, для которых мы предоставим информацию в случае, если подсистемы Р и Е не сработали. Ваш продукт не должен быть самым лучшим, он должен казаться самым лучшим.

Итак, гопник из 90-хподходит к вам с широкой улыбкой, на ходу протягивая руку, чтобы поздороваться, со словами: «Привет, дружище/сосед/коллега!» и т. д. Он, как опытный разводила, подсознательно использует модель APET, оттягивая включение Системы 2 до того момента, когда жертве уже будет поздно думать.

1. Активатором служит пара позитивных триггеров, которые он вам скармливает: протянутая рука, улыбка, определенные слова.
2. Наша паттерн-система на 100% включается, распознав знакомые паттерны как неопасные, слово «сосед» и протянутая рука — стандартный позитивный активатор для всех нас.
3. Улыбка также задействует наш эмоциональный процессинг — и тут у нас тоже нет признаков угрозы, особенно после позитивных распознанных паттернов.
4. После распознавания паттернов и позитивных эмоций на секунду вам даже может показаться, что вы знаете этого человека. Именно так воздействует на нас Система 1, крича о том, что это знакомый, нечего тут думать. Только потом наша ленивая Система 2 начинает медленно включаться, говоря нам: «Wait a minute...» — и медленно лицо, кажущееся знакомым минуту назад, становится совершенно незнакомым и проявляется противоречие между поведением гопника и тем фактом, что это незнакомец... Но уже поздно =)

Система 2. Логика

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

• Система 1 = эмоции + инстинкты;
• Система 2 = логика = когнитивное мышление.

Мы начнем рассмотрение своих манипуляций с логической Системы 2, самой медленной, ленивой и точной подсистемы нашей модели мозга (и самой близкой программистам по духу). Это немного нестандартно, так как эта подсистема последней принимает участие в принятии решений, а иногда и просто дремлет, отдавая бразды правления Системе 1. Зато есть очень много методов, которые применимы в текстовом общении с пользователем (через различные интерфейсы, такие как веб-страницы), да и самое вкусное я оставлю для следующей статьи.

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

Примеры можно увидеть по отдельности ниже для каждого из предложенных манипуляторов. Для иллюстрации псевдологичных рассуждений вспомните диалог из фильма «Трасса 60», когда Гэри Олдмен рассказывает главному герою о том, что всю жизнь прожил без члена и что «мир становится другим, когда не приходится постоянно думать о сексе и сексуально на все реагировать». Звучит логично, не так ли? Но главный герой ловит лепрекона на этой лжи для Системы 2: откуда тому знать, как живется с членом, и как он может сравнивать с чем-то то, с чем никогда не жил?

Правило трех

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

Не верите? Откройте веб-сайт Appleи узрите! Вторая строчка в топе написана именно с использованием этого метода:

Этот же метод вы можете встретить везде: Sex & Drugs & Rock’n’Roll. Хороший, плохой, злой. Вера, надежда, любовь. На старт, внимание, марш. Заходят в бар русский, украинец и американец. Отец, Сын и Святой Дух.

Почему работает (теории).

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

Рифмы

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

«Жиллет» — лучше для мужчины нет! Fake it till you make it! Hot or not? Вилкой в глаз или....

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

• подборка различных типов рифм на английском языке;
  
• подборка синонимов и антонимов.
  

Баланс

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

Некоторые структуры баланса в речи: «Не это..., а то», «Или» («Быть или не быть?»), «Или..., или» («Или с нами, или против нас»).

Почему работает (теории).

Перспективы

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

Два важных фактора, которые идут в ногу с этим методом:

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

Option 1: Join Amazon Prime.
Option 2: No thanks, I do not want fast, free shipping (вот это поворот!).

Цифры

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

Работая с цифрами, важно понимать несколько простых принципов:

1. Найти наиболее выгодные точки сравнения. ЗП директора — 4,4 млн, VS ЗП директора — в 120 раз выше ЗП сотрудника, VS ЗП директора составляет лишь 0,5% от прибыли компании. Это то же самое, что и метод перспектив, но с цифрами.
2. Если нет задачи заморочить голову пользователю, не надо топить его в море цифр. Выберите наиболее убедительные и выгодные цифры для презентации.
3. Используйте графику там, где возможно.
4. Сами по себе цифры никому не интересны, они должны рассказать историю пользователю.
5. Задайте ритм. Obama: Increase capital gains and dividends taxes from 15 to 20 percent for those making more than $250,000 (couples) or $200,000 (single).

Краткость

Будь краток!

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

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

Антипаттерны Системы 2

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

1. Слишком много опций для выбора (парадокс выбора).Система 2 думает, сопоставляет и принимает сложные решения в отличие от Системы 1 — не надейтесь на быстрый и импульсивный выбор. Пример:попросив Систему 2 выбрать между восемью различными вариантами конфигурации хостинга, не надейтесь на быстрое и выгодное вам решение. Ведь ничего не выбрать — это еще одна опция, которая есть у пользователя, и Система 2 ею воспользуется, если пользователь не сможет прийти к однозначному ответу, держа все опции в голове.
2. Заставить пользователя сравнивать неоднородные опции.Если вы предоставляете пользователю выбор, сведите его решение к выбору значений одних и тех же переменных, иначе рискуете остаться с универсальным выбором пользователя ничего не выбирать. Пример:невозможно сравнить три опции хостинга между собой, используя разные характеристики: Cores 2×2.1 GHz VS Memory 2 Gb VS Bandwidth Cap 2 Tb.

Система 1 — эмоции

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

Гормональный коктейль

Наиболее известные гормоны, связанные с нашими эмоциями:

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

Персональные истории

Хорошая история манипулирует нами с помощью нескольких гормонов одновременно, например:

• Хороший образ героев вызывает прилив окситоцина, когда мы соотносим свою личность с личностью героя благодаря общим действиям, ситуациям и поступкам.
• Хорошая дилемма или проблема как источник напряжения способствует продуцированию кортизола и вовлекает в сюжет. Именно кортизоловое недоразумение остается у нас после просмотра последнего кадра фильма «Начало», так как развязки мы так и не получили и гештальт не закрылся у тех, кто увлекся сюжетом ленты.
• Хорошая развязка способствует продуцированию дофамина как вознаграждения за то, что мы завершили историю. Я прямо физически почувствовал, как мне не хватает дофамина в конце фильма «Начало» =)

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

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

Слова-сущности (образы)

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

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

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

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

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

Лесть

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

Мало кто считает себя хуже среднего в управлении автомобилем или в сексе, ведь правда? =)

Думаете, Apple случайно выпустил бюджетную версию iPhone, которая практически неотличима от обычной версии?

Повторение, повторение, повторение

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

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

Преувеличение

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

Общие ценности

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

• Build-A-Bear: Di-bear-sity. Colla-bear-ate.
• Atlassian: Don’t #@!% the customer.
• Google: You can make money without doing evil. The need for information crosses all borders.
• Facebook: Build social value.

Культурные сходства

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

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

North Face: Walls are Meant for Climbing — отличная отсылка к культуре своей левой аудитории во время анти-Трамп-истерии с идеальной интеграцией в спортивный бренд The North Face.

История

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

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

Связка эмоциональной Системы 1 с когнитивной Системой 2

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

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

• ценности + баланс;
• ценности + правило трех;
• повторение + баланс;
• преувеличение + краткость.

Послесловие

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

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