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

1. FVM

FVM — аббревиатура от Flutter Version Manager. Аналогичный инструмент вы могли встречать в работе с Node.js — NVM. FVM позволяет вам гибко переключаться между версиями Flutter. Поддерживает загрузку как конкретных версий Flutter, так и каналов Master, Dev, Beta, Stable.

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

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

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

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

Устанавливаем: flutter pub global activate fvm.

Затем любую желаемую версию: fvm install master, или fvm install 1.17.0.

Дожидаемся скачивания. Потом в папке с проектом fvm use 1.17.0выбираем желаемую версию.

Дальше все команды выполняем, как раньше, только с приставкой FVM. Внутри команды проксируются к нужной версии фреймворка.

Первый раз запускаем проект вручную, чтобы докачались все нужные для конкретной версии модули: fvm flutter run.

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

2. VS Code

Добавить в settings.json:

"dart.flutterSdkPaths": [    "fvm"
]

3. Android Studio

В настройках проекта нужно поменять путь к папке с фреймворком.

Заходим: Preferences -> Languages&Frameforks -> Flutter. Указываем путь к папке с версией фреймворка. На macOs это: /Users/[your_user_name]/fvm/versions/[verstion_name].

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

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

Для самых ленивых

4. flutter_launcher_icons

Этот пакет помогает мне в одну команду создать и сложить по своим местам иконки для приложений Android и iOs. Базовая настройка включает в себя всего несколько строчек в pubspec.yaml:

flutter_icons: image_path_android: "assets/icon/android.png" image_path_ios: "assets/icon/ios.png" android: true

Запускаем командой flutter pub run flutter_launcher_name:mainи наслаждаемся результатом.

5. flutter_launcher_name

Позволяет в одну команду изменить имя приложения. Настройка лаконична — добавьте секцию в pubspec.yaml: ios: true.

flutter_launcher_name: name: "Your app name"

C запуском справится даже начинающий: flutter pub run flutter_launcher_name:main.

Это не сложно и вручную сделать. Но название секции как бы намекает...

6. change_app_package_name

Изменяет название пакета для Android:

• Обновляет AndroidManifest.xml для release, debug & profile.
• Обновляет build.gradle.
• Обновляет MainActivity (для Java и Kotlin).
• Перемещает MainActivity в новую структуру папок.
• Удаляет старую структуру папок.

Для получения результата в командной строке выполняем: flutter pub run change_app_package_name:main com.new.package.name

7. build_context

С помощью extensionдает быстрый доступ к часто используемым методам контекста.

Вместо MediaQuery.of(context).orientation == Orientation.landscapeпишем context.isLandscape.

Коротко и удобно — полный перечень сокращений в readme.

Для суровых, но все еще ленивых

Рассмотрим три библиотеки для кодогенерации: json_serializable, freezed, auto_route.

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

8. json_serializable

Большинство приложений общаются с бэкендом и получают в ответ старый добрый JSON. Для работы с ним Dart из коробки предлагает две функции — jsonEncode и jsonDecode. Если вы играете в песочнице — поле для фантазий бесконечно. Можно голый JSON передавать между компонентами или вручную написать несколько классов для сериализации/десериализации, как в этом примере.

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

Библиотека json_serializable помогает генерировать методы fromJSON и toJSON для моделей данных с бэкенда. Для примера возьмем jsonplaceholder.typicode.comи сделаем выборку постов и комментариев по ним.

Создадим файл post.dartи две модели Post и Posts.

Posts

class Posts {  final List<Post> posts;  Posts({this.posts});
}

Posts

class Post {  final int userId;  final int id;  final String title;  final String body;  Post({this.userId, this.id, this.title, this.body});
}

Добавим импорты и аннотации.

Импорты

import 'package:json_annotation/json_annotation.dart';

part 'post.g.dart'; // файл, который будет сгенерирован

Аннотации

Указывают, что мы хотим сгенерировать методы fromJson и toJson для аннотированных классов:

@JsonSerializable()
class Posts {...

@JsonSerializable()
class Post {...

Добавляем методы fromJson и toJson в классы:

@JsonSerializable()
class Posts {  ...  factory Posts.fromJson(Map<String, dynamic> json) => _$PostsFromJson(json);  Map<String, dynamic> toJson() => _$PostsToJson(this);
}

@JsonSerializable()
class Post {  …


  factory Post.fromJson(Map<String, dynamic> json) => _$PostFromJson(json);  Map<String, dynamic> toJson() => _$PostToJson(this);
}

Запускаем генерацию: flutter pub run build_runner build.

По окончанию генерации появится новый файл post.g.dart. Проделываем те же манипуляции для комментариев.

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

9. freezed

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

Из коробки можно создавать const-объекты классов. Это может быть выходом, но ограничивает вас созданием объектов только на этапе компиляции. Существует пакет metaс набором аннотаций для статического анализа. Он предлагает директиву @immutable, которая в dart analyzer подскажет, что не все поля в классе типа final, но не сильно воспрепятствует на этапе написания кода.

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

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

Модифицируем post.dart, чтобы сгенерировать необходимый код.

Добавляем импорты:

import 'package:freezed_annotation/freezed_annotation.dart';
part 'post.freezed.dart';// файл который будет сгенерирован

Правим аннотации:

@freezed JsonSerializable()
class Posts {...

@freezed JsonSerializable()
class Post {...

Убираем лишний код: пакет freezedотлично интегрируется с json_serialaizable, но нужно немного поправить код класса.

Обновленный класс Posts:

@freezed
abstract class Posts with _$Posts {  factory Posts({List<Post> posts}) = _Posts;  factory Posts.fromJson(Map<String, dynamic> json) => _$PostsFromJson(json);
}

Обновленный класс Post:

@freezed
abstract class Post with _$Post {  factory Post({int userId, int id, String title, String body}) = _Post;  factory Post.fromJson(Map<String, dynamic> json) => _$PostFromJson(json);
}

Запускаем генерацию: flutter pub run build_runner build

По окончанию генерации появится новый файл post.freezed.dart.

Проделываем те же манипуляции для комментариев.

10. auto_route

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

Используем библиотеку для добавления роутинга между экранами со списком постов и комментариями к ним.

Создадим route.dart.

Добавим импорты:

import 'package:auto_route/auto_route_annotations.dart';
import 'package:doutoolbox/comments_view.dart';
import 'package:doutoolbox/posts_view.dart';

Определим класс роутинга: @initial — указывает на то, что postsViewбудет стартовым.

@MaterialAutoRouter()
class $Router {  @initial  PostsView postsView;  CommentsView commentsView;
}

Запускаем генерацию: flutter pub run build_runner build.

Сгенерируется route.gr.dart.

Поправим main.dart, добавив туда роутинг:

MaterialApp(      // ...      builder: (context, nativeNavigator) =>          ExtendedNavigator<Router>(router: Router()),    );

По клику на пост откроемстраницу с комментариями:

onTap: () => ExtendedNavigator.of(context).pushNamed(    Routes.commentsView,    arguments: CommentsViewArguments(        postId: snapshot.data.posts[index].id)),

В итоге получим типизированную передачу аргументов в роут и сгенерированные имена роутов.

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

Подписывайтесь на наш Telegram-канал, следите за обновлениями!

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

Ілюстрація Уляни Патоки

«Якщо поставити сеньйора робити прості нудні завдання, то скоро він почне вносити різноманітність у рутину»

Павло Кручіна, Development Director в Fintech Project, 14 років досвіду в ІТ

Senior-фахівець, вибачте за тавтологію, повинен мати зрілі технічні навички та зрілі компетенції (soft skills). З технічного боку це означає знати та вміти застосовувати «стандартні» рішення, розуміти, чому вони стали стандартом, межі їхнього застосування і що буде, якщо їх не використовувати. «Креативне рішення» звучить красиво, але зазвичай приносить більше проблем, ніж користі. У плані компетенцій важливо усвідомлювати свої емоції, комунікувати з іншими членами команди та брати на себе відповідальність.

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

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

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

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

Як компаніям привабити Seniors

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

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

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

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

«70% українських сеньйорів у вебпрограмуванні насправді є зарозумілими мідлами»

Стас Довгодько, веброзробник, СТО, керівник у вільному плаванні, більш як 17 років досвіду в ІТ

Провів понад сотню співбесід і зробив офер 30-40 фахівцям.

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

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

Інший бік медалі аутсорсу — український ринок програмування вихований лише аутсорсерами. У нас, на жаль, майже не було локального замовника років 10, і тому всі спеціалісти (як і я) з’явилися разом із замовниками «звідти». Ринок був порожнім, наповнювався швидко, градацію вигадували щомісяця в боротьбі за кожний долар-per X. Двадцятирічний сеньйор як явище виникло саме тоді й не на порожньому місці. Лише спілкування із закордонними колегами прочищало мізки: було не дуже зрозуміло, як з того боку скайпу людина вдвічі старша, набагато талановитіша та з більшими знаннями та досвідом, а сеньйор тут ти.

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

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

Я переконаний, що співбесіда на позицію Senior має відрізнятися від інших. Вона має відбуватися у форматі діалогу «про життя». Лише обговорення комплексних ситуацій, максимально наближених до реальних. Розгорнута відповідь вебсеньйора на запитання «Як би ви спроєктували власний CDN для стримінгу відео та які ви бачите проблеми на шляху?» розповість вам набагато більше, аніж 50 питань типу «Де помилка в цій функції на 30 рядків?». Також важливими є зворотні питання від кандидата до потенційного працедавця. Саме в ці моменти стає зрозуміло, чим дихає кандидат і чого очікує від вас.

Власний досвід

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

Пам’ятаю і ситуацію, коли на співбесіду Senior прийшов хлопець, за фахом, здається, зварювальник. Без попередження, просто зайшов в офіс зі словами: «Я талановитий, а що, справді така зп? Що треба робити?». Оскільки того дня відбувалося 3-4 співбесіди,я проґавив момент, що хлопцю її не призначали. Діалог виявився кумедним, і я запам’ятав саме його співбесіду. Ще була зустріч, на якій кандидат сказав, що розповість про себе лише тоді, коли домовимося про кінцеву зарплату. Мовляв, йому все зрозуміло, чого тягнути, а як ні, то піде в іншу компанію. Довелося сказати, щоб краще йшов в іншу.

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

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

Як компаніям привабити Seniors

Думаю, по-перше, компаніям варто з’ясувати, чи справді їм потрібні сеньйори та навіщо. Якщо ж відповідь позитивна, на мою думку, українського сеньйора із досвідом 10-15-20років зараз може втримати три моменти:

• Стабільність.Ну не вірю я в 35-40-річного спеціаліста, який буде ганятися за приставкою в холі. Він радше хотітиме довгострокового «кредиту». Тут ще можна гратися в соціальні бонуси, як-от довгострокове медичне страхування, включно із сім’єю. Логіка така: я витрачаю своє життя на розвиток компанії, то хай компанія забезпечить мою сім’ю хоч якимось гарантіями.
• Професійна свобода дій.Не завжди спеціаліст має змогу пояснювати технічні рішення, він розв’язує комплексну проблему і розраховує на довіру замовника. Middle-фахівець іноді корисніший, адже пояснює більше.
• Чесність з боку керівництва.Молоді спеціалісти через свій вік не завжди можуть/хочуть помітити фальш чи лестощі в спілкуванні. Людина, старша за безпосереднього керівника, знає, чого хоче. Її не вмотивувати табличкою «Найкращий працівник». Проте такий фахівець може зрозуміти та розв’язати проблеми, якщо знатиме ситуацію повніше (це перетікає в пункт про стабільність).

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

«Є кандидати, які спочатку роздувають себе до позиції Senior, хоча знають, що не дотягують до неї»

Богдан Гусев, CTO в Unstoppable domains, 13 років досвіду в ІТ

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

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

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

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

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

Приклади гарних запитань на співбесіді — у форматі алгоритмічних завдань. Наприклад, у вас є функція draw_point (x, y), запрограмуйте функцію draw_circle (x, y, radius), використовуючи draw_point. Або «Вам потрібно спроєктувати реляційну базу даних соціальної мережі, в якій користувачі можуть додавати одне одного в друзі (а-ля фейсбук). Які таблиці та колонки для цього створите?».

Очікування vs реальність

Одна з моїх головних вимог до кандидата — вміння розв’язувати задачу будь-якого рівня складності відповідно до займаної позиції. Senior Developer повинен добре виконувати завдання рівня Junior, Middle і Senior. Кандидати, що претендують на звання сеньйора, часто валяться на елементарних завданнях, які може зробити будь-який студент.

Інший абсолютно жахливий аспект — небажання Senior-кандидата приділити достатньо часу та сил інтерв’ю. Людина не розуміє, що за три години вирішується, як і де вона проводитиме чверть свого часу в найближчі кілька років. Коли я ухвалюю рішення взяти фахівця на роботу, то подумки дістаю з-під столу валізу з 50 000–100 000доларів і даю її кандидатові. Саме в стільки зазвичай обходиться компанії Senior з урахуванням усіх витрат. І попри це кандидат не готовий виділити три години свого часу. Прикро бачити таке ставлення.

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

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

Про слабкі місця Senior-спеціалістів

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

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

Як компаніям привабити Seniors

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

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

Максим Ковтун, Chief Software Architect в Sigma Software, понад 18 років досвіду в ІТ

Особисті та професійні якості Senior-спеціаліста

Є модель спеціалістів під назвою T-shaped. Здається, вперше її описала компанія Valve у своєму хендбуці. Суть у тому, що спеціаліст має володіти глибокою експертизою в одному напрямі та знати потрохи в інших напрямах і сферах. Глибока експертиза дає змогу робити свій внесок у проєкт, а широкий кругозір — ефективно поєднати її з іншими експертизами та полегшити спілкування з командою. Думаю, ця модель вдало змальовує те, яким має бути Senior-спеціаліст. Це повинна бути експертиза з вирішення якогось типу проблем чи побудови певного типу рішень, а не просто «із застосування технології». Наприклад, «експерт з побудови мобільних бізнес-додатків» або «експерт з оптимізації хмарних рішень», а не «експерт з .NET MVC». Такі фахівці добре опанували кілька технологій, інструментів і підходів, стежать за появою нових і підбирають необхідну комбінацію під кожен проєкт. Натомість «спеціаліст із застосування молотка» всі проблеми вирішує молотком.

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

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

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

Про співбесіди

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

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

Про слабкі місця сеньйорів

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

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

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

Як компаніям привабити Seniors

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

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

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

«Описую просту вигадану мову програмування і прошу кандидата за її допомогою запрограмувати поведінку мікроконтролера»

Олександр Кагановський, CTO / Engineering director у Larch Networks, понад 15 років досвіду в ІТ

Провів понад 1000 співбесід на трьох останніх місцях роботи. На посади Senior — близько 300 чи 400. Із них найняв приблизно 50 фахівців.

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

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

Не менш важливо й таке (пункти йдуть у довільному порядку):

1. Добре знати базові поняття Computer Science, щоб розуміти, як його ПЗ працює в реальній системі.
2. Розуміти технології, що використовують у предметній галузі проєкту.
3. Мати достатні навички спілкування, щоб обговорювати технічні рішення з колегами, замовниками, керівництвом.
4. Володіти англійською мовою на достатньому рівні, якщо це потрібно для роботи в команді, із замовником і технічною документацією (і якщо навіть якийсь проєкт не потребує англійської, то для читання документації вона знадобиться).
5. Мати навички роботи в команді для передачі досвіду колегам.
6. Бути відповідальнім, володіти тайм-менеджментом (наприклад, вчасно брати участь в робочих мітингах).
7. Мати добрі навички самонавчання (щоб вивчати необхідні нові технології або предметну галузь).
8. Мати аналітичне та інженерне мислення та вміти шукати способи розв’язання проблем.
9. Бути здатним працювати на результат, а не на процес.
10. Розуміти методи розробки ПО загалом та особливості їх використання в його команді / проєкті / компанії.
11. Вміти за потреби писати документацію, а не тільки код.
12. Пропонувати способи підвищити ефективність своєї роботи або роботи команди.
13. Розуміти, що ми живемо в реальному неідеальному світі, тому інколи треба орієнтуватися на доцільність проєкту і потреби замовника, а не програмувати лише заради мистецтва (тобто краще щось просто добре зробити вчасно, ніж зробити ідеально — але ніколи).
14. Бути професіоналом і робити не тільки те, що цікаво, а й те, що потрібно для проєкту.
15. І найважливіше — на Senior-розробника можна покластися, він не потребує мікроменеджменту з боку керівництва. Якщо в нього виникнуть проблеми чи питання в процесі роботи, він сам повідомить керівника про це.

А що на практиці

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

Якщо я стикаюся з інженером з іншої компанії, то для мене важливим є те, як він розуміє проєкт і рівень своїх повноважень. Пам’ятаю, як колись у 2006 році влаштовувався в компанію Flextronics (потім вона змінила назву на Aricent). Після співбесіди, коли зайшла мова про мою градацію, я сказав, що для мене однаково, буду я вважатися Junior чи Senior. Для мене важливо, чим я займатимуся та який буде рівень оплати. І тоді мене взяли як Senior-розробника.

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

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

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

Наведу ще кілька прикладів.

У нас значна частина коду пишеться на С та С++. І дуже дивує, коли кандидат претендує на оплату рівня Senior і водночас не знає, як працює цикл for або вивід з форматуванням printf. Чи не може пояснити, що таке балансоване відсортоване бінарне дерево, та порівняти ефективність деяких операцій у такому дереві з two-way list.

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

Слабкі місця українських сеньйорів

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

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

Якщо казати про недоліки роботи Senior-інженерів із Заходу, то я стикався з різними ситуаціями. Наприклад, інженер має значний досвід у розробці апаратури (HW), де його рівень, можливо, справді Senior. І хоч у програмному забезпеченні (SW) він не дуже тямить, його призначили відповідальним за це. І замість того, щоб консультуватися з більш досвідченими SW-розробниками, людина намагається самостійно придумати архітектуру SW. Або інженер, що має титул Senior, пише код і не виносить спільні великі частини у функції, а натомість шанує copy-paste. Не знає, як працюють вказівники (pointers) у C, чи не може в таск-трекері сформулювати проблему і пише «система зламалася» без жодних деталей. Або ж має проблеми із soft skills — не приходить вчасно на запланований мітинг.

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

«Відсутність досвіду роботи з конкретною технологією — не проблема»

Леонід Литвиненко, СТО в YouScan, PhD в Computer Science, 14 років досвіду в ІТ

Провів понад кілька сотень співбесід, з яких близько 30% — з кандидатами на позицію Senior (найняв 7).

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

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

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

А ще важливо, щоб людина писала код, який буде легко підтримувати та змінювати. Для мене це особливо цінно, бо в YouScan, за статистикою, за три роки повністю переписали 95% коду.

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

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

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

Крім того, варто пам’ятати, що різні компанії рівень Senior бачать по-різному (і мова не лише про аутсорс). Поширеним інструментом для оцінювання рівня розробника є так званий Engineering Ladders Framework.

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

«Якщо звести систему мотивації працівників професійно розвиватися суто до підвищення зарплат — це призведе до професійного вигорання»

Андрій Агеєв, Competence Manager у Software Development Office, SoftServe, 25 років в ІТ

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

Якщо говорити безпосередньо про SoftServe, то в нас є чіткі фреймворки визначення рівня працівників, які охоплюють як hard skills (рівень технічної експертизи), так і soft skills (продуктивність, відповідальність та інші якості). За їхню розробку і постійне вдосконалення відповідає окремий відділ — Software Development Office. Серед його функцій — розробка плану розвитку менш досвічених фахівців до рівня Senior. Оскільки для компанії, яка прагне будувати успішний бізнес, важливо вирощувати свої таланти.

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

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

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

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

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

За індивідуальний розвиток інженерів у нашій компанії відповідають Talent Success Leads (TSL). Вони ведуть конкретні компетенції в конкретному розробницькому центрі і мають бачення загального стратегічного розвитку. Водночас TSL перебувають у постійному контакті з інженерами та їхніми менеджерами. Розуміючи глобальний контекст і особливості конкретної людини, вони допомагають побудувати персональний план довготривалого розвитку в компанії.

Варто зазначити, що підвищення спеціаліста в нашій компанії визначають відповідно до навичок, а не часу перебування на попередній позиції. Є чіткий список знань і вмінь, якими має володіти Senior. Претендує кандидат на цю роль? Навички є? Ласкаво просимо. І байдуже, має він досвіду рік чи десять. Тут я згадую одного кандидата з величезним потенціалом і мотивацією. Він прийшов у компанію наприкінці 2015-гона позицію Trainee. Вже у 2017-мувін став сеньйором. Далі обрав для себе архітектурний напрям і за два роки став Solutions Architect. Гарний приклад для наслідування.

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

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

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

Я займаюся оцінюванням персоналу вже 4 роки і зараз обіймаю посаду Head of Assessment Office в ELEKS University. Серед іншого я розробила модель компетенцій (soft skills), а також побудувала систему оцінювання soft skills у компанії. Над нею ми спільно з колегами й сьогодні натхненно працюємо. За цей час довелося багато навчатись, «ставати на граблі» й здобувати власний досвід.

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

Вартує дізнатись, у чому ж фокус, і все так просто. (The Prestige, 2006)

Що ж таке soft skills і як їх можна виміряти

У професійному світі оцінювання soft skills ще називають компетенцією. Компетенція — це набір поведінкових реакцій, які дають змогу одним людям бути ефективнішими за інших при аналогічному рівні hard skills (професійної компетентності). Грубо кажучи, якщо ви помічаєте складну якість особистості, яку на перший погляд неможливо оцінити на інтерв’ю — це і є компетенція. Наприклад, лідерство, організованість, орієнтація на результат тощо. До опису компетенції не можна застосувати терміни «знання» чи «навичка», але можна — «здатність».

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

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

Поведінкові індикатори

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

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

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

Навіщо потрібне оцінювання спеціалістам і компаніям

— Скажіть, будь ласка, куди мені звідси йти?
— А куди ти хочеш потрапити? — відповів Кіт.
— Мені все одно... — сказала Аліса.
— Тоді все одно куди і йти, — зауважив Кіт.
(«Аліса в Країні чудес» Л. Керрола)

Оцінювання в компанії використовують для двох цілей — розвиткових (найбільше зацікавлений сам працівник і його керівник) і бізнесових.

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

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

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

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

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

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

Нерідко для цього використовують особистісні опитувальники. І вони справді можуть бути корисними в контексті розвиткових і бізнесових завдань. Ми в компанії, до прикладу, застосовуємо Predictive Index Test (PI).Однак тут варто зауважити, що особистісні опитувальники не вимірюють компетенції, а лише якусь її частину. Найчастіше це якості, риси, характеристики, а також цінності, мотиви. Наприклад, Predictive Index Test показує екстраверсивність чи інтроверсивність, домінантність, терплячість, формальність. Він дає багато корисної інформації, проте не замінює оцінювання soft skills, а радше верифікує це в іншій площині.

Популярними тестами, які використовують у бізнесі, окрім PI, є DISC, MBTI, Caliper тощо. Зазвичай за їх допомогою отримують вхідну інформацію, коли для всебічного оцінювання немає часу чи можливостей або це нерентабельно (наприклад, на вході в компанію). Або це є доповненням для створення повнішої картини. Наведу власний приклад. Згідно з персональним опитувальником я є напрочуд детальноорієнтованою людиною — «ботан 80-горівня». Це справді так. Якщо взяти до уваги лише це і не оцінювати скіли, можна припустити, що я маю суттєві складнощі в роботі із системами та системними рішеннями. Колись побачити ліс за деревами для мене було складно. Однак кілька років тому я розв’язала це питання через інструменти мисленнєвих процесів, теорії обмежень (ТОС). Аналогічні приклади можна спостерігати з інтровертами, які комунікують багато, напрочуд ефективно та переконливо.

Що таке модель компетенцій

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

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

Розглянемо на конкретному прикладі.

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

Створення профілів спеціалістів

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

Візьмемо, наприклад, посаду Middle Software Developer. Що має робити людина на цій позиції і якою вона має бути? Чи має вона бути командною? Так. Ок, значить, у профіль цієї посади додаємо компетенцію «командна робота». На якому рівні розвитку повинна бути ця компетенція, щоб працівник добре виконував роботу, але і щоб не виставляти до нього надмірно завищених вимог? Припустімо, спеціаліст має ділитися своїми ідеями з іншими, бути готовим шукати спільне рішення і дослухатися до думки колег. Чи має вміти Middle Software Developer фасилітувати процес групового ухвалення рішень або створювати самоорганізовані команди? Мабуть, ні. Ок, тоді для його профілю ми обираємо той рівень, який містить перший набір, і не обираємо вищого рівня.

Якщо взяти вищенаведену компетенцію «клієнтоорієнтованість», то для позиції Middle Software Developer достатньо, щоб вона була розвинена на рівні 1. Усього в профілі мідл-девелопера є 5 компетенцій:

Керуючись такою логікою, ми створюємо профілі компетенцій для усіх посад. Головне завдання — ставити досяжний рівень розвитку й потрапити в потік, щоб не було ані нудно, ані заскладно. Зазвичай у профіль додають не більше як 5-6 компетенцій,а це значить, що з моделі треба вибрати необхідне і відмовитись від того, що не є критичним для виконання посадових обов’язків. Для профілю Middle Software Developer, наприклад, компетенції на зразок «мотивація інших», «вплив на інших», «стратегічне мислення» можна не враховувати. Адже вони не є найважливішими для виконання поточних завдань. І як би не хотілось додати у профіль якнайбільше і «на виріст», від цього треба утриматись, щоб не перевантажити його і зробити систему оцінювання керованою і практичною, а не просто красивою.

Приклад моделі компетенцій для асесора:

Наша історія

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

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

Ми будували модель понад рік силами кросфункційної робочої групи, до якої ввійшли спеціалісти із корпоративного університету, HR, рекрутингу, а також Competence Development. Спочатку організували навчання, на якому учасники вчились проводити інтерв’ю зі збору поведінкових індикаторів. Наступним кроком стало створення критеріальних вибірок для проведення інтерв’ю. З кожної групи посад, що існують у компанії, влаштували вибірки в розрізі «найкращий результатник» і «посередній виконавець». Це потрібно, щоб потім розібратись, які саме зразки поведінки ведуть до кращих, а які до гірших результатів.

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

У результаті наша модель містить 10 компетенцій, кожна з яких описана поведінковими індикаторами від рівня −1 до 3-го.Кожен наступний рівень від нульового містить попередній. Шкала має таку логіку: −1 рівень — деструктивна поведінка, 0 — непостійний результат, який залежить від зовнішніх факторів (гарний настрій, є всі ресурси навіть у надлишку або навпаки, болить голова, з’явилась якась непрогнозована перепона). А от від 1-горівня вже спостерігається постійна результативна поведінка. Тож людина, яка демонструє 2-йрівень, напевне, має показувати й індикатори нижчого 1-горівня.

Як оцінюють компетенції

Хоч навчити всіх оцінювати компетенції не є метою цього тексту, все ж кілька слів про те, як це робити, сказати варто. Лише на основі реальних дій у критичних ситуаціях ми можемо прогнозувати майбутню поведінку (це «золоте правило» від основоположників концепту). Це основний принцип для всіх інструментів оцінювання компетенцій. Всі види оцінювання базуються на минулому досвіді. А тепер докладніше. Компетенції найчастіше оцінюють двома методами: за допомогою інтерв’ю за компетенціями та асесмент-центру.

Найваліднішим є асесмент-центр.У різних джерелах його здатність прогнозувати вказують від 0,29 до 0,7, але більшість підручників сходиться на цифрі 0,65. Її, власне, підтверджує дослідження Шмідта (Schmidt, F., & Hunter, J. (1998). The validity and utility of selection methods in personnel psychology: Practical and theoretical implications of 85 years of research findings. Psychological Bulletin, 124(2), 262-274.).Що це означає на практиці? Цей метод здатний прогнозувати майбутні результати в робочих ситуаціях. Наразі він робить це найточніше.

Експерти не рекомендують використовувати для оцінювання інструменти/методи, валідність яких є нижчою за 0,4. Наприклад, валідність рекомендацій становить 0,25, а професійних тестів — 0,39.

Як він працює? Це комплексний метод, який базується на спостереженнях за поведінкою учасників у вправах/іграх/кейсах, які моделюють різні аспекти бізнес-діяльності, однак не мають відтворювати їх один в один. Серед найбільш поширених є, наприклад, рольова гра з клієнтом. За легендою клієнт має певний набір претензій до компанії й учаснику оцінювання треба врегулювати ситуацію за певний час (зазвичай 15-20 хвилин).Або, наприклад, групова дискусія зображає ситуацію, коли 4-6учасників оцінювання мають власну мету і командну, які мають якимось чином «примирити».

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

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

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

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

Feedback 360 градусів — це метод, згідно з яким ділове оточення (колеги, керівники, підлеглі, клієнти) оцінює рівень розвитку компетенцій учасника на основі спостереження за його поведінкою у робочому середовищі. Респондентам (колегам, керівникам, підлеглим, клієнтам) надсилають опитувальник з одним єдиним запитанням: «Як часто пан Х демонструє таку поведінку?». Після цього наводять конкретні поведінкові індикатори із компетенцій, які є в профілі людини, і пропонують записати у шкалу: ніколи /рідко / іноді / часто / завжди. Переважно заповнення цього опитувальника займає не більше як 15 хвилин, оскільки респондентам не треба відповідати на відкриті запитання, а індикатори сформульовані достатньо чітко.

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

Як у нас? Сьогодні в ELEKS оцінюванням займається окремий підрозділ — Assessment office, а Assessor — це окрема спеціалізація і кар’єрний напрям, що вимагає відповідної сертифікації.Оцінювання методом Assessment center у нас проходять як менеджери, так і технічні спеціалісти. Щоправда, наразі лише рівня Senior, а Middle — якщо виконує на проєкті роль Lead. Запит на оцінювання подає менеджер спеціаліста. Окрім того, людина сама може ініціювати власне оцінювання за погодження менеджера. Відтак вона отримує зворотний зв’язок, який триває від 1 до 2 годин, залежно від кількості компетенцій у профілі. За цей час асесор розповідає про сильні сторони, а також про те, що потребуєрозвитку, дає рекомендації, відповідає на всі запитання спеціаліста щодо оцінки.

Окрім того, результати оцінювання (після надання зворотного зв’язку) передають HR-спеціалісту та його керівникові, які спільно можуть встановлювати розвиткові цілі та сприяти їх реалізації. Наприклад, щоб спеціаліст міг відточити свою компетенцію «мотивація та розвиток інших», він має мати для цього відповідні повноваження, можливості, а також підтримку на проєкті, яку й забезпечить керівник. Сьогодні ми активно працюємо над запуском інструмента Feedback 360 градусів за компетенціями, який допоможе нам створювати розвиткові плани для ширшого кола спеціалістів компанії.

Граблі: не повторюйте наші, шукайте свої!

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

Граблі № 1: не майте ілюзій, що можна все встигнути за півтора місяця, а далі піде як по маслу!

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

Ще одна важлива річ — крива досвіду дає такий значний ефект і конкурентну перевагу, бо її не вдається здобути швидко. Ми ставили SLAs (Service-level agreement)на надання зворотного зв’язку за результатами оцінювання надто оптимістично, та не одразу могли його забезпечити. Наприклад, ще не маючи асесорів на повну зайнятість і працюючи за матрицею, коли оцінка — це додаткова активність, ми обіцяли надати звіт за два тижні після оцінювання. Це, власне, на етапі навчання самих асесорів було практично неможливо. І, своєю чергою, могло призвести до розчарування тих небагатьох шанувальників цього процесу, які були. Тож тут або одразу виділяти під оцінювання значний ресурс — асесорів на повну зайнятість, або ставити реалістичні SLAs, які ви зможете поступово поліпшувати разом зі здобуттям переваг кривої досвіду. Продуктивність точно зросте, але дайте собі час. З досвіду — гарного асесора можна підготувати за пів року.

Граблі № 2: оцінювання — це окрема спеціальність

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

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

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

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

Граблі № 4: все в книжках не прочитаєш, просто будьте готові вчитись і виправляти помилки

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

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

З останнього, що вигулькнуло, — COVID-19. Довелось адаптовуватись, тож відтепер в нас працює онлайн-оцінювання. Microsoft Teams до наших послуг.

У підсумку

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

Привет, меня зовут Андрей, я Engineering Manager в компании Uptech. В этой статье хочу рассказать об одном из архитектурных подходов для создания приложений — гексагональной архитектуре. Рассмотрим пример ее использования для создания Node.js-приложения.

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

TLDR. Разделяйте бизнес-логику и любые внешние зависимости — будьте счастливы.

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

Рассмотрим типичное приложение:

В более общем случае:

Вроде все хорошо, но что обычно происходит в реальной жизни?

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

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

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

Порты и адаптеры

Если посмотрим на описанный выше флоу, увидим, что роуты — это просто точки «входа» к бизнес-логике, а база данных и другие сторонние сервисы — «выходы» из приложения. И таких точек «входа» и «выхода» может быть много. Заметив это, Алистер Коберн в 2005 году предложил подход к архитектуре приложений, который назвал «гексагональная архитектура», или «архитектура портов и адаптеров».

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

Наша основная цель — это изоляция бизнес-логики. Но нужен способ взаимодействия с ней. Порт служит именно для этой цели. Порт — описанная спецификация взаимодействия уровня логики с любыми внешними зависимостями. Это просто интерфейс, по которому бизнес-логика вызывается или сама вызывает внешние зависимости, без каких-либо деталей имплементации. Для большинства языков порт — это интерфейс и DTO (Data transfer object), связанные с этими интерфейсами. Порты принадлежат уровню бизнес-логики.

После того как описали процесс взаимодействия с бизнес-логикой, стоит раскрыть логику взаимодействия с конкретными сторонними сервисами и соединить их вместе. Для этой цели служат адаптеры. Адаптер — конкретная имплементация работы с другими сервисами. Эти сервисы бывают двух типов по отношению к «ядру» приложения. Те, которые логику вызывают — HTTP-роуты, Socket-соединения. Их называют первичными (Primary) адаптерами. И те, которых бизнес-логика сама вызывает: база данных, платежные программы, сервисы уведомлений и так далее. Их называют вторичными (Secondary) адаптерами.

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

Выглядит это приблизительно так:

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

Первичный адаптер. HTTP endpoint

Наш календарь имеет обычный REST API и взаимодействует с внешним миром через HTTP. HTTP endpoint — самый простой пример первичного адаптера. Контроллер, который работает с вашим фреймворком и обрабатывает HTTP-запросы.

В данном случае метод CreateEvent обрабатывает POST-запросы по роуту /event, парсит все параметры запроса и вызывает eventCreationService, который есть частью слоя с бизнес-логикой. Он принимает на вход только значения и ничего не знает об особенностях транспорта, что его вызвал, таких как тело запроса или заголовки.

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

@injectable()
@JsonController('/event')
export class EventController {    // ...    @Post()    public async createEvent(        @Body() input: EventCreationInput,        @CurrentUser({required: true}) userId: number    ): Promise<EventResponse> {        return await this.eventCreationService.createEvent(input, userId);    }    // ...
}

Порт. Сервис нотификаций

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

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

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

export interface NotificationService {    sendNotifications(message: NotificationMessage, userTokens: string[]): Promise<void>;
}

Вторичный адаптер. Сервис нотификаций

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

@injectable()
export class FCMNotificationAdapter implements NotificationService {    private readonly fcmApp: admin.app.App;    constructor() {        this.fcmApp = admin.initializeApp({            credential: config.firebase.authJson        });    }    public async sendNotifications(message: MessageData, tokens: string[]): Promise<void> {        const payload = {            tokens,            notification: message.notification,            data: {                data: JSON.stringify(message.data)            }        };        const response = await this.fcmApp.messaging().sendMulticast(payload);    }
}

Inversion of Control

Обратите внимание: чтобы сделать вторичные адаптеры независимыми от бизнес-логики, используем Dependency injection (DI). Получается, что зависимости направлены к Application core. Работает принцип Inversion of Control сразу на уровне архитектуры.

Организация Application core

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

Для организации бизнес-логики мы объединили подход слоевой архитектуры (Layered Architecture) и DDD (Domain Driven Design).

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

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

Сервис Аpplication-уровня работает приблизительно так: он инжектит в себя вторичные адаптеры, не зная ничего о конкретной имплементации этих сервисов. В данном примере EventRepository и NotificationService — это порты, описанные на доменном уровне, для которых из DI-контекстаинжектится конкретная имплементация взаимодействия с внешними сервисами.

@injectable()
export class EventCreationService {    private eventRepo: EventRepository;    private notificationService: NotificationService;    constructor(        @inject(EventRepositoryType) eventRepo: EventRepository,        @inject(NotificationServiceType) notificationService: NotificationService,    ) {        this.eventRepo = eventRepo;        this.notificationService = notificationService;    }    public async createEvent(input: EventCreationInput, userId: number): Promise<EventResponse> {        const newEvent = Event.fromObject({            ...input,            creatorId: userId        });        const savedEvent = await this.eventRepo.save(newEvent);                const message = {            title: `You invited to ${event.title}`,            body: 'Wanna participate?',            data: {eventId: event.id}        };        await this.notificationService.sendNotifications(message, tokens);        return savedEvent;    }
}

Второй шаг организации Application core — это разделение на компоненты по доменной области. В каждом из них лежат сервисы и модели, которые тесно связаны между собой, но слабо зависимы от других частей приложения. Такой себе Bounding Сontext из DDD. Примеры таких компонентов: User, Reminder, Event и так далее.

В итоге получаем такую схему:

Для уменьшения связности между компонентами можно использовать event-driven подход и реализовать их взаимодействие на основании ивентов.

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

Тесты

У нас было 3 вида тестов, каждый отвечал за свою часть архитектуры.

Unit-тесты

Классические unit-тесты для каждого сервиса. С их помощью мы протестировали бизнес-логику в Аpplication core. Они достаточно легковесны и быстро исполняются.

Integration-тесты

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

Acceptance-тесты

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

Звучит это все хорошо, а в чем подвох, спросите вы?

Проблемы

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

Транзакции

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

Оптимизация

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

Валидация

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

Выводы

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

Полноценный демопроект можете найти на GitHub.

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

Abto Software

Agiliway

AMC Bridge

ANODA Software Development Agency

Appus Studio

Більшість співробітників перебуває та відзначає свято вдома. Але дехто вранці вибрався до пам’ятників національним діячам мистецтва.

Astound Commerce

Bakotech

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

Beetroot

Bini Bambini

bvblogic

Подейкують, що вишиванка — це код нації, а кодити ми любимо!

Cadabra Studio

CharStudio

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

Ciklum

CodeIT

Codeminders

Conscensia

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

Daxx

DataArt

DB Best Technologies

Devart

Devlight

ELEKS

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

eSputnik.com

Grid Dynamics

iDeals

InternetDevels

Intetics

Infopulse

Intellias

До Дня вишиванки запустили Vyshyvanka flash mob: Show your quarantine pattern! Співробітники компанії робили фото у вишиванці за улюбленою справою на карантині та ділилися світлинами з колегами: на фото — Роман, Delivery Director в Intellias, який у перервах між робочими мітингами та онлайн-школою проводить час із сином.

Itera

JustCoded

Kharkiv IT Cluster

Luxoft

MassMedia Group

Mobilunity

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

Netfully

Попри віддалену роботу працівники компанії підтримали щорічний флешмоб. Ми цінуємо культуру і традиції. Вишиванка — наш генетичний код. Горді бути українцями!

N-iX

Щоб відсвяткувати День вишиванки разом, в N-iX запустили флешмоб #N_iX_Vyshyvanka. У четвер працівники компанії ділилися своїми фото у вишиванках та мали можливість виграти призи від компанії.

Redwerk

Synebo

TEAM International

Telesens

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

ViSoft

Wargaming

Waverley Software

Wirex

Yukon Software

Знаємо, любимо та підтримуємо українське!

Zagrava Studios

IT-фахівці

Христина Єлісєєва

Алла Ляшенко, IT Recruiter/HR в Danavero Inc.

Олександр Кривобочек, QC

Юлія Горкій, Java-розробниця у UKEESS Software House

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

Оксана Савчук, QA, контент-менеджерка

Юлія Скофенко, Project Manager

Вікторія Стус, HR Generalist в SkySoft.tech

Олена Сергата, QA Engineer SPD-Ukraine

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

Катерина Селезньова, Marketing Specialist у MWDN

У вишиванці день виявився продуктивнішим. Такий одяг додав святковості та мотивації до відвідування мітингів із ввімкненою камерою :)

Світлана Джой, графічна дизайнерка

Любов Розвєзєва, International Accountant в Together Networks

Максим Лепьохін, Travel & Hospitality Team Lead at Dev.Pro

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

Лариса Тетьора, SEO-спеціалістка в EVO

ІТ-сім’я на карантині.

Ігор Федоров, Recruiting&Employer Branding Specialist у KeenEthics

Оксана Леонова, Project coordinator у Plarium

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

Project Management

Новость для тех, кто давно собирался сдать экзамен РМР: PMI запустил запись на сдачу экзамена онлайн. Обновление экзамена и релиз новой версии PMBOK тоже перенесли до января 2021 года. Кстати, про ожидаемые изменения и то, как поменяется свод знаний по управлению проектами в 2021 году, рассказывает наш коллега Анатолий Савин в недавнем вебинаре.

Великолепный Manager’s Playbookописывает эвристики управления и стоит десятка других ссылок этого выпуска.

Полезная статья для всех нас, жертв локдауна: удаленная работа и психическое здоровье. Как позаботиться о себе?

За период карантина десятки компаний заполнили свои блоги историями о том, как они наладили remote-функционирование. Кроме уже опубликованного в прошлых дайджестахгайда от GitLab, мне понравился логично разделенный на секции Remote Work Guideкомпании Zapier.

Открываю вам портал в великолепную базу знаний и личного опыта для менеджеров проектов — ЖЖ Сергея Колганова, ПМ’а с многолетним стажем. Базовая страница — лучшие рубрики блога, FAQ для начинающихсразу демонстрирует основательность подхода. Здесь можно задержаться надолго и решить не один свой менеджерский кейс.

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

Отличный текст 11-летнейдавности Opinion: The unspoken truth about managing geeksобречен на актуальность для всех менеджеров в ІТ.

Minimal Project Management — еще один self-made фреймворк. Здравый подход, будет работать для зрелых команд.

14 способов стать лучше в роли менеджера инженеров.

Ребята из Redmadrobot сделали подборку типичных ошибок PM’aи дали рекомендации по их решению.

Способ для фиксирования изменений в архитектуре ADR — Architecture Decision Recordsбыл предложен в далеком 2011 году и c недавних пор используется в Spotify.

Agile/Scrum

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

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

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

8 шляп скрам-мастера: The Scrum Master as a Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover и Change Agent. Отличный вайт пейпер для идентификации непонимания этой все еще противоречивой для многих роли.

Remote Agile Guide — надстройка над скрам-гайдом в мире ремоут и ряд полезных рекомендаций для скрам-мастеров (для доступа к скачиванию нужно оставить имейл).

Еще один способ с пользой провести ретроспективу — Trust Anti-Pattern Cards. В оригинале требует физического присутствия участников, но не вижу проблем попробовать это упражнение удаленно, используя Jamboardили Mural. Больше по теме: в записиполезного митапа Online Retrospectives от Тимофея Евграшина.

Очень много контента для Agile Coaches — Agile Coaching Institute разработал фреймворк компетенций со многими полезными ссылками для укрепления навыков.

Красивая маркетинговая история подходит к завершению, последние иллюзии развеиваются — рассказ о том, как Spotify model провалился в самом Spotify.

Самые известные метрики для Scrum’a — это burndown chart и story point velocity. Для планирования спринтов большинство скрам-мастеров интересует исключительно velocity chart. Предлагаю ознакомиться с advanced-метрикой, полезной для планирования спринта: Throughput forecasting.

12 техникдля фасилитации митингов.

Fun

Agile Coaches обладают множеством полезных навыков:

Великолепный комикс ☺

Не говорите им!

Agile Coach свою работу сделал:

Поговорил с РМ’ом:

Зачем он спросил?

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

В выпуске: соместный проект Apple и Google на Go, как язык помогет разрабатывать софт для борьбы с COVID-19, результаты Go Developer Survey 2019.

Новости

Совместный проект Google и Apple по борьбе с COVID-19 написан на Go, а в этом выпуске ребята из Generic Talksразбирали его по деталькам.

Зарелизили Go 1.14.3 и 1.13.11.

Что нас ждет в Go 1.15 на слайдахот Дэниэла Марти, и еще одна статьяс детальным розбором некоторых новинок.

Результаты Go Developer Survey 2019

Свежее интервью с Робом Пайком

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

Caddy 2 вот и релиз!

Анонс

GoWayFest 4.0 goway.io — 4-аяконференция в Беларуси, полностью посвященная языку Go, переходит в онлайн и пройдет 11-12 июля.

Среди спикеров этого года:

👍Dave Cheney — раскроет тайну того, как важен нейминг для вашей кодовой базы.

👍Ellen Körbes — поможет ускорить процесс «от изменения кода до запуска процесса» для приложений Go.

👍Iskander Sharipovс подробным описанием внедрения эффективной VM в Go.

Читаем

Life Without Line Numbers

Отличная статья от GitHub про 3 бага в Go драйвере MySQL

Подменяем stdin и stdout в Go

Как работает инлайнинг в Go

Prometheus для начинающих

Asynchronous Preemption в Go 1.14

Как построить систему мониторинга COVID пациентов на Go и Vue за 3 дня!

Используйте последнюю версию Go

Как оформить Go GitHub репос

Go в браузере с WebAssembly и TinyGo

Broccoli: Brotli компрессия статики в Go

Код конвенции Thanos для Go

Строим свой TCP протокол

Дженерики в Go: откуда зачем и как

Statically Compiling Go Programs

Как я делал облачную игру с WebRTC и Go

Ордеринг обьектов в Go

Таймауты и отмена контекста при работе с базами

Как контрибьютить в компилятор Go

Смотрим и слушаем

Строим приложения с Go и MongoDB

Строим микросервисы Go в GoLand

A Beginner’s Guide to gRPC in Go

Щупаем

shotizam — сколько весит ваш бинарник

go-elasticsearch — клиент для elasticsearch

go-leetcode — 100 LeetCode задач на Go

gomodifytags — автозаполнение стракт тегов

pester — немного ресайленса в ваш HTTP клиент

waitabit — работаем с сигналами прерывания

go-fault — инекция ошибок в ваши хендлеры

go-tinytime — эффективная работа с time.Time

facebookincubator/ntp — библиотека для работы с ntp

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

[Об авторе: Алексей Орап — CEO и основатель компании YouScan, SaaS-системы мониторинга социальных медиа. C 2008 по 2009 работал директором по развитию Яндекс.Украина, ранее занимался продажами и техническим консалтингом в компаниях Nortel, Alcatel-Lucent. Автор блога про SaaS-бизнес — SaaSDojo.comи канала про возобновляемую энергетику CleanTech News]

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

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

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

Итак, вот список моих основных принципов для работы и бизнеса.

1. Доверие

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

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

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

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

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

2. Честность

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

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

3. Не откладывать сложные решения и разговоры

Иллюстрации Каталины Маевской

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

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

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

Чувствуете, что надо расстаться с сотрудником, который уже давно не тянет, несмотря на все ваши усилия исправить ситуацию, но при этом эпизодически подает признаки надежды? Сделайте это прямо завтра. Вы и так уже опоздали с решением на несколько месяцев (у меня было такое не раз). Вы нафакапили, и клиент требует компенсацию, не пытаясь вникнуть в причины произошедшего и дать вам шанс исправиться? Дайте ему эту %$#X* компенсацию либо расторгните договор. Но сделайте что-то уже сегодня. Вас ждет не слишком приятный разговор с бизнес-партнёром об ответственности в команде? Лучше поговорить сейчас, чем отложить еще на неделю.

Часто правильного решения просто нет, сколько бы вы не взвешивали все «за» и «против». Парадокс в том, что это особенно относится к сложным и неприятным вопросам (иначе они не были бы сложными!). Узнать, что было правильно, а что нет, вы можете, только сделав что-то.

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

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

4. Стараться понять мотивацию

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

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

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

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

5. Дела значат больше, чем слова

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

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

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

6. Движение вперед с помощью проб и ошибок

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

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

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

Позже я познакомился с концепцией Lean Startup, а разнообразные Agile-подходы стали мейнстримом. Однако я по-прежнему вижу, что на практике все часто выглядит по-старому. Когда люди сталкиваются с необходимостью планирования в условиях неопределенности, они продолжают попытки составить всеобъемлющий и детальный план действий или проекта. Безусловно, это полностью оправдано, если вы строите АЭС или проектируете новый кардиостимулятор. Но, скорее всего, вы занимаетесь чем-то другим.

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

Варианты:

А. Спланировать наше сотрудничество по всем направлениям и составить детальный план действий.

Б. Выбрать небольшой проект и попробовать реализовать его без излишней формализации.

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

В заключение

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

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

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

Читайте также:DOU Books: 5 полезных книг, которые вы вряд ли читали, от Алексея Орапа, CEO YouScan

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

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

У меня экономическое образование. Когда стоял выбор между финансами и экономической кибернетикой, я выбрала кибернетику. После института мне предложили поработать аналитиком-консультантом по внедрению 1С-систем. Позже работала PM, потом снова вернулась в бизнес-анализ. И вот в DataArt я уже три года.

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

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

Первый вызов — выявить истинную бизнес-потребность

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

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

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

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

Как выяснить истинную бизнес-потребность заказчика

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

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

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

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

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

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

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

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

Дальше у нас состоялся примерно такой диалог:

Я: А что конкретно не устраивает в Excel, почему решили перейти на 1С?

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

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

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

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

Второй вызов — знать бизнес-домен

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

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

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

Реально ли хорошо знать бизнес-домен до начала работы на проекте

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

• Знакомиться с первичными документами и оригинальными формулировками от заказчика. Кстати, здесь помогут тикеты и заявки на доработку в техподдержку.
• Если возможно использовать наблюдение (BABОK даже выделяет это как отдельную технику по выявлению требований), то посмотреть на сам процесс работы бизнес-подразделений полезно для бизнес-аналитика.
• Подписаться на периодические издания по теме бизнеса.
• Проходить внутренние курсы компании: часто для бизнес-подразделений проводят курсы для новичков или для повышения квалификации. IT-шники также могут включиться.

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

Третий вызов — строить доверительные отношения

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

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

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

Как завоевать доверие клиента

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

Настраиваться на одну волну с заказчиком мне помогает образ из «психологического айкидо», о котором говорит Ирина Хакамада:

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

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

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

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

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

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

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

Четвертый вызов — решать конфликты в требованиях стейкхолдеров

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

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

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

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

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

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

Как договориться со стейкхолдерами

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

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

Можно попробовать альтернативный способ решения конфликта:

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

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

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

Пятый вызов — защитить систему от плохих решений

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

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

Как плохое решение может выглядеть в интерфейсе.

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

Как не пропустить неудачное решение

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

В работе над продуктом клиент описывает идею или бизнес-требование, а задача БА — вовремя отследить, когда речь идет о приемлемых требованиях, а когда — о workaround или исключениях, что не вписываются в систему.

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

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

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

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

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

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

Шестой вызов — подтвердить договоренности

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

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

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

Как фиксировать договоренности

Для меня оптимально сохранять результаты общения с заказчиком в заметках (meeting minutes) и видеозвонках. А для сбора обратной связи и подтверждения требований удобно использовать, например, прототипы.

Заметки и запись видеозвонков

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

Разработка прототипа

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

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

Седьмой вызов — пережить on-site переговоры

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

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

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

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

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

Как почувствовать себя комфортно

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

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

• Профессионально настроиться на тему встречи: четко представлять вопросы и цели обсуждения, подготовить все презентации. Это самое важное.
• Если это переговоры с людьми другой культуры, лучше заранее поискать информацию о национальных особенностях или поспрашивать коллег, которые уже ездили в страну.
• Соблюдать дресс-код. Еще один важный момент в переговорах on-site. Самым универсальным для переговоров считается стиль smart casual. При этом задача БA — одеться так, чтобы было удобно. Если вы совсем не привыкли носить пиджак и чувствуете себя некомфортно, это тоже будет влиять на переговоры.

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

Если кратко, то справляться с вызовами при выявлении требований мне помогают несколько вещей:

1. Фокусироваться в первую очередь на проблемах клиента, а только потом — на вариантах решения.
2. Предварительно готовиться, изучать предметную область.
3. Доброжелательно относиться к заказчикам, даже если что-то пошло не по плану.
4. Гибко подходить к решению конфликтов между стейкхолдерами.
5. Оптимизировать бизнес-процессы и приводить их к общему стандарту, прежде чем начнется разработка системы.
6. Фиксировать договоренности с помощью заметок, видеозаписей и прототипов.
7. Учитывать особенности ведения бизнеса в других странах или культурах.

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

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

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

Фото з колеса огляду в Гаазі

Як я отримав запрошення на релокейт

Я почав задумуватися про переїзд ще 2014 року, але на той час мені бракувало досвіду, щоб отримати гідну пропозицію роботи за кордоном. У 2017-муя став цілеспрямованіше шукати варіанти. Оновив профіль у LinkedIn, гортав Stack Overflow, а також розміщував резюме на різних локальних job-сайтах (тоді я вже обрав для себе Нідерланди).

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

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

Sim-карту з більш-менш вигідним тарифом одразу купити неможливо. Для її отримання оператор просить надати виписку з банку за останні 3-6місяців (залежно від оператора), а також дозвіл на проживання в Нідерландах. Звісно, що виписка з українського банку не підійде. Є сім карти, які можна придбати в супермаркеті, але тарифи в них набагато дорожчі, аніж у звичайних операторів. Під час написання статті з‘ясував, що сімкарту можна купити раніше, ніж за 3 місяці й без довідки з банку в магазині Belsimpel оператора Ben.

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

Про роботу та IT-ринок: пошук, річні бонуси та бюрократія

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

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

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

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

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

Коли в мене був вільний час, я створив сайт, який виводить топ музичних відео, доданих нещодавно. До речі, це Progressive Web Application. На базі цього функціоналу я також запустив бота, який щотижня складає топ-10 нещодавно доданих музичних відео.

Загалом процес найму на роботу в Нідерландах не злагоджений: можуть не передзвонити чи не дати фідбек після надісланого тестового завдання. Буває так, що в проєктах немає HR. Далеко не всі використовують Scrum та Agile. Я працюю в компанії, де більше ніж 30 розробників, а ми досі застосовуємо Trello. Більша частина коду написана на Python 2.7.

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

У контракті більшості компаній прописано, що працівник отримує річний бонус. Як правило, ця сума вже закладена в договір, але під час пошуку роботи на це треба звертати увагу. Наприклад, у вас запитують, яку зарплату хочете отримувати. І ви озвучуєте суму 50 000 євро брутто (включаючи податки). Чи містить ця сума річний бонус у вигляді 8%? Якщо так, то щомісяця ви будете отримувати дванадцяту частину від 46 000 (46 000/12), а також додатково 4000 раз на рік.

Отже, якщо ви висококваліфікований працівник-мігрант і отримуєте зарплату вище ніж 56 000 євро (якщо вам за 30 років), включаючи річний бонус, то 30% зарплати не оподатковуються. В інтернеті є калькулятори для розрахунку зарплати із 30% рулінгом, але все-таки наведу приклад. Якщо ваша місячна зарплата становить 4600 євро брутто, то із 30-відсотковимрулінгом ви заплатите 1290 євро податків. Без 30% рулінгу — 1840 євро. Різниця — 500 євро. Тобто з рулінгом на місяць ви отримуватимете на 500 євро більше.

У Нідерландах усе ще багато бюрократії. Розгляд документів на рулінг може тривати 6–8 місяців.Тож, з одного боку, ця ситуація вчить економити гроші, а з іншого боку, якщо розгляд документів затягнувся і, скажімо, ви не витрачаєте гроші з рулінгу та дотягли до річного бонуса, то за один повний рік можете накопичити 10 000 євро (500 євро * 12 (рулінг) + 4000 бонусу). І тут постає питання: що робити з грошима? Платити за оренду помешкання (1200-1800 євро)чи брати іпотеку? Купити авто та повернутися на батьківщину? У кожного свій вибір, але тепер я не дивуюся, що хтось їде додому.

Довготривала іпотека та важливість фінансового помічника

Маючи на рахунку 10 000 євро, можна задуматися і про іпотеку. Пропозиції та ціни на оренду/купівлю житла переглядайте тут. Наприклад, ви вибрали будинок за 300 000 євро. Це означає, що на місяць виплачуватимете приблизно 1200 євро протягом 30 років. Ви кажете маклеру, що готові купити будинок за 300 000 євро. А він зауважує, що треба заплатити більше, ніж було вказано спочатку. Бо переважно ціни нефіксовані й нерухомість отримує той, хто запропонує більше. Будинок вам дуже сподобався, і ви готові придбати його за 310 000 євро. Припустимо, ви виграли торги. Йдете в банк, а там у вас просять звіт про ринкову вартість будинку, і виявляється, що вона становить 300 000 євро. Банк може видати іпотеку лише на цю суму, а різницю 10 000 маєте заплатити додатково зі своєї кишені.

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

Регулярні платіжки за дороги та ціни на проїзд

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

Здебільшого платять ті, хто ними користується: власники автомобілів та муніципалітет за громадський транспорт. Не знаю, чи закладено в ціну пального відсоток на ремонт доріг, проте проїзд у громадському транспорті в Нідерландах дорогий. Шлях, який я долаю на сітібайку за 15 хвилин, коштує приблизно 2 євро, якщо їхати автобусом. Двадцятихвилинна подорож потягом (45 км) вартує 9 євро. Туристи платять повну суму, а для жителів є так звані підписки, які дають змогу економити. Наприклад, місячна підписка на 5 євро дає 40% знижки на поїздки у будні та вихідні, окрім годин пік. З Утрехта в Амстердам — 8 євро, а зі знижкою — 5. Одна невелика подорож у два боки одразу «відбиває» плату за підписку.

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

Автомобілісти платять за дороги раз на квартал. Сума розраховується на основі важкості автомобіля та виду пального. Якщо у вас важкий джип, який їздить на дизелі, доведеться платити космічні суми. Наприклад, у мого знайомого — «універсал» на дизелі, він обходиться у 167 євро на місяць. Для мене це велика сума. Якщо ж у вас невеликий «хетчбек» на бензині, платитимете 100 євро у квартал. Ось тутможна розрахувати податок на калькуляторі.

Щомісячні платежі та пакет сміття за 1 євро

Комунальні платежі, оплата інтернету, телебачення та іншого списується автоматично з вашої дебетової картки щомісяця. 8 Гб мобільного інтернету та 300 хвилин дзвінків коштують приблизно 13 євро. Домашній безлімітний інтернет з динамічною IP-адресою — 45 євро. Є популярний оператор кабельного інтернету та телебачення — Ziggo: платиш за інтернет 45 євро (як і в інших операторів), але отримуєш доступ і до базових кабельних телеканалів. Саме тому обирають Ziggo: мало хто хоче додатково платити за телебачення.

Сміттєві контейнери в Нідерландах закриті, доступ лише за магнітною карткою. Не можна викинути сміття зі свого будинку в інший контейнер. Магнітна картка прив’язана до квартири. Використання картки для одного сміттєвого пакета — 1 євро. Плата за газ, воду та електроенергію становить приблизно 150 євро за все. Воду можна пити з-під крана без додаткових фільтрів.

Штрафи

Мабуть, усі знають, що в Європі високі штрафи і штрафують за різні порушення. Наприклад, якщо ви гуляєте з собакою без повідка — 70 євро, немає пакетика для сміття для собаки — 70 євро, не прибрали за собакою — 100 євро, немає при собі документів для ідентифікації особи — ще 100 євро.

Пологи вдома та правила медичного страхування

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

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

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

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

Дитячий садок за 2000 євро на місяць, школа з 5 років, тести й рекомендації для вступу у середню школу

Дитячі садки в Нідерландах платні. Ціна за годину коливається в межах 8–10 євро.Повний день п’ять разів на тиждень коштуватиме приблизно 1500-2000євро на місяць. Від держави можна отримати відшкодування, сума якого залежить від кількості дітей і вашого заробітку. Отримати гроші можна, якщо працюють обоє батьків. Треба податися на субсидію: зайти на сайт, заповнити анкету та чекати. Дані перевірять, і якщо ви підпадаєте під критерії субсидії, то її вам видадуть. Розмір субсидії залежить від достатку, зайнятості батьків, кількості дітей тощо. Мій син не ходив на повний день у садок, тож я не можу сказати точних цифр. Але знайомі, які мають одну дитину, розповідали, що отримують 300 євро від держави.

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

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

Заняття закінчуються приблизно о 14-йгодині. Якщо потрібен догляд після занять, за додаткову плату функціонує група продовженого дня (приблизно 8–10євро за годину). Іноді для цього приїжджає автобус, який завозить дітей до групи продовженого дня, адже не в кожній школі вона є.

Безперервні дощі 5 місяців на рік і відпустка лише у пік сезону

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

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

Навесні Нідерланди перетворюються на неймовірно красиву країну тюльпанів.

Про мову

Майже всі в Нідерландах знають англійську. Проте якщо хочете тут жити, треба вчити нідерландську мову, а вона дуже складна. Якщо емігрували за робочою візою, то не отримаєте жодних привілеїв для вивчення мови. Мовні курси дорогі: приблизно 500 євро на місяць. Щоб пройти один рівень, знадобиться 4 місяці. Можна сказати, що ви більш-менш знаєте мову, якщо пройдете хоча б три перші рівні: A1, A2 та B1.

Підсумок

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

Я не перконую вас у тому, що не варто їхати у Нідерланди. Але нагадую, що варто цінувати й те, що маєте.

До останніх днів свого 98-річногожиття ветеран обчислювальної техніки Борис Малиновський не розлучався з комп’ютером і сам відповідав на листи, що надходили на його електронну скриньку. Борис Малиновський — один із тих науковців, що найбільше доклалися до зародження і розвитку IT в Україні, обличчя її кібернетики. Зокрема, він один із першопрохідців обчислювальної техніки. З 50-хроків минулого століття був конструктором першої в тодішньому Союзі напівпровідникової ЕОМ «Дніпро» та систем управління на її основі, брав участь у розробці мікро-ЕОМ «Електроніка С5», М-180, сигнальних процесорів.

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

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

Фото: Даніл Павлов

І. Солдат, який став ученим

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

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

Те, чого не судилося зробити Левові, втілив Борис.

А поки що він теж пішов на фронт, заледве закінчивши школу. Отримав кілька серйозних поранень.

«Коли помер Лев, я думав: вб’ють мене — закінчиться рід Малиновських. Але залишився живим. Якби навколо за 4 роки можна було зробити окружність на 200 метрів і порахувати, скільки снарядів, мін і бомб упало на цю площу, то справді дивовижно, що я вижив», — казав Борис Миколайович.

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

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

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

Але після війни на Бориса Миколайовича чекала кар’єра вченого та участь у становленні української кібернетики.

ІІ. Конструктор ЕОМ і руйнівник міфів про кібернетику. Як створювали «Дніпро»

Після випуску Борис Малиновський вступив до аспірантури в Інститут електротехніки АН УРСР — з другої спроби, першого разу не вдалося скласти іспит з української мови. У 1953 році захистив кандидатську. Його керівником із дисертації був Сергій Олексійович Лебедєв, творець першого в континентальній Європі комп’ютера. Малиновський з повагою та захопленням відгукувався про відомого вченого: «Дивовижна людина. Він — основоположник комп’ютеробудування в Радянському Союзі. Запропонував мені розробити безламповий тригер. В результаті з’явилася моя кандидатська дисертація».

У цей період Малиновський почав цікавитися цифровою обчислювальною технікою і зробив перші кроки у цій сфері. Кібернетика на просторах країни щойно зародилася, тож молодий учений Борис стояв біля її джерел. За кілька років він пройшов шлях від наукового співробітника лабораторії обчислювальної техніки Інституту електротехніки АН УРСР до заступника директора з науки та керівника відділу спеціалізованих цифрових машин в обчислювальному центрі АН УРСР. У його стінах і сконструював одну з найвагоміших розробок свого життя (як сам її характеризував, називаючи у спогадах комп’ютер «пам’ятником вітчизняної науки і техніки») — напівпровідникову машину управління широкого призначення «Дніпро». Робота тривала впродовж трьох років, із 1958-годо 1961-го.«Дніпро» створили, щоб контролювати технологічні процеси, управляти ними та складними фізичними експериментами, а також вивчати процеси під час їхньої алгоритмізації.

«Я назвав машину УМШН (управляющая машина широкого назначения — рос.). Директору інституту Глушкову це не дуже подобалося, але добре — УМШН так УМШН. Але якось Глушков виступав на партійному активі, де була присутня один із секретарів ЦК КПУ. Після виступу Глушкова вона йому каже: «Це що за УМШН? Вікторе Михайловичу, та назвіть її по-людськи! Назвіть „Дніпро“. Ось так і з’явилася назва „Дніпро“», — згадував учений.

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

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

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

«Довелося „спеціалізуватися“ у сфері навігаційних задач, що виникають на борту бомбардувальника, в особливостях роботи бортових радарів, питань наведення на ціль літака-снаряда», — пише у спогадах Борис Малиновський.

Тоді до апаратури літака змакетували напівпровідниковий арифметичний пристрій невеликих розмірів — у майбутньому саме він знадобився під час розробки «Дніпро».

Улітку 1956 року Борис Малиновський перебував у профспілковому санаторії «Феофанія», коли в кімнаті пролунав телефонний дзвінок. Телефонував директор Інституту математики АН Борис Гніденко — спішив познайомити з новим завідувачем лабораторії Віктором Глушковим. Той виявився молодим чоловіком із серйозним поглядом з-за скелець окулярів і, як буде відомо потім, одним з основоположників IT в Україні. Він розробить теорію цифрових автоматів, створюватиме багатопроцесорні макроконвеєрні супер-ЕОМ, організує Інститут кібернетики АН України.

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

Утім новий керівник лабораторії був палким прихильником кібернетики і його «групою підтримки» стала решта працівників. Малиновський тоді склав листа до ЦК КПУ, в якому навів факти, що розробки у сфері обчислювальної техніки у Радянському Союзі відбуваються куди повільніше, аніж у США, Англії чи Франції. Хоча в Києві є великий потенціал у цій сфері та підготовлені висококваліфіковані спеціалісти, матеріальна і виробнича підтримка робіт недостатня. Останнє речення листа закінчувалося так: «Стан обчислювальної техніки в Україні межує зі злочином перед державою».

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

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

«Первістком українського будівництва комп’ютерів виявився „Дніпро“, появі якого я віддав найкращі роки свого життя. Трирічну напружену працю великого колективу молодих працівників УРСР, більшість із яких щойно закінчила інститути і технікуми, президент НАНУ Борис Патон назвав „героїчною епопеєю“», — пише Борис Малиновський в одній зі своїх книжок, у третій частині документальної трилогії «Очима ветерана».

На просторах тодішнього Союзу «Дніпро» був першим управляючим комп’ютером широкого призначення, його використовували у найрізноманітніших, у той час передових, системах управління. Комп’ютери почали масово випускати в 60-хроках, за їх допомогою створювали сотні систем управління по союзних республіках і за кордоном.

Що означало створити перший український комп’ютер у тодішніх умовах? Як писав Борис Малиновський, середній вік науковців, які трудилися над запуском, становив 25-30 років.Директору обчислювального центру Глушкову було на той час 34 роки (сам же Малиновський, тоді заступник директора з наукової частини, був на два роки старшим). Спогади про війну були ще свіжими, і, як пише Борис Миколайович, вони багато в чому допомагали.

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

Готовий комп’ютер виконував 88 команд і працював із середньою швидкістю 10 000 операцій на секунду. Комп’ютери «Дніпро» випускав київський «Електромаш» — усього вийшло 500 одиниць. В Україні їх застосовували всього кілька десятків, ще кілька одиниць «помандрували» за кордон та в інші союзні республіки, решту використовували в Росії.

ІІІ. Ветеран ІТ. Пам’ять про 500 колег і 40 ЕОМ

Поза «Дніпром» Борис Малиновський доклався до низки інших важливих розробок. Керуючи з 1962-гопо 1981-йвідділом кібернетичної техніки і завідуючи відділом машин управління Інституту кібернетики імені Віктора Глушкова АН, він провів багато досліджень. Вчені проєктували нові комп’ютерні та кібернетичні прилади. Зокрема, після «Дніпра» з’явилася мікро-ЕОМ «Електроніка С5» — перша в Радянському Союзі мікро-ЕОМ широкого призначення, розроблена інститутом разом із ЛКТБ «Світлана» (ленінський комітет техніки безпеки). Від «Дніпра» вона відрізнялася тим, що була розроблена не просто на інтегральних схемах, де окремо один напівпровідник, а на великих інтегральних схемах: на платах, пам’ять зберігалася на піварифметичних приладах.

«Велика річ — мікро-ЕОМи, — розповідав Борис Малиновський. — Їх використовували не просто окремо, а почали вбудовувати в різноманітні прибори. І ось Мінпромзв’язку, яке випускало такі прилади, за нашою порадою і допомогою почало вбудовувати в них наші мікрокомп’ютери. Вони були маленькими, працівники зв’язку називали їх контролерами. За їхню розробку ми отримали премію Ради Міністрів, адже багато заводів використовували їх. З Мінпромзв’язку приїздили до нас в Академію наук працювати разом: тодішній заступник міністра та вчені з технічного управління міністерства, які вважалися масштабними особистостями свого часу».

Потім учені розробляли комплексні мікропроцесорні прилади — «Нейрони». Це теж було замовлення Мінпромзв’язку: установа потребувала налагоджувальних пристроїв. На базі «Нейрону» проводили налагодження наступних розробок. Також у «портфоліо» Малиновського — управляючі машини M-180, кластерні системи, перші зразки аналогової техніки. У середині 60-хроків допомагав заводу «Південмаш» — основній «кузні» радянських міжконтинентальних і космічних носіїв у (тодішньому) Дніпропетровську автоматизувати випробування ракетних двигунів.

Уже після розпаду Союзу, за незалежної України, Малиновський намагався реанімувати комп’ютерну індустрію країни. Організований ним у 1998 році міжнародний симпозіум «Комп’ютери в Європі. Минуле, теперішнє і майбутнє» став своєрідним підсумком діяльності самого вченого та Інституту кібернетики загалом. На захід запросили професора з Великобританії Моріса Вілкса, якого у професійних колах називають батьком мікропрограмування. Українським вченим теж було про що розказати. А саме про те, як зароджувалася кібернетика та обчислювальна галузь — із 16 людей, які 1957 року почали працювати у новоствореному обчислювальному центрі. Вони розробили понад 15 видів ЕОМ для управління технологічними процесами. В Інституті кібернетики таких досягнень було вже більше: понад 40 видів ЕОМ, що загалом становили третину комп’ютерів, які випускали в тодішньому Союзі. Досягнення українських розробників — це і бортові машини управління «Карат», які застосовували на багатьох підводних човнах і ракетоносіях, і «Мікроприбор» та «Кристал», на яких виробляли перші в Європі інтегральні схеми. Загалом же тодішні комп’ютери, випущені в Україні, забезпечували 60-70відсотків усіх систем управління в Союзі.

Утім найбільшою кар’єрною гордістю Бориса Малиновського залишився «Дніпро», про що він написав у мемуарах і неодноразово повторював у інтерв’ю. А також люди, що проєктували ЕОМ, визнання серед колег, подальші державні та академічні нагороди. У розмові з DOU Борис Миколайович укотре описував своє життя цифрами: «За час моєї роботи у відділі кібернетичної техніки зі мною пліч-о-пліч пропрацювали 500 людей із шести різних підрозділів. Пів сотні людей зробили спільний багаторічний внесок у комп’ютерну науку і розвиток техніки».

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

Життя Малиновського можна описати, як він любив, цифрами: 10 докторів і понад 40 кандидатів наук, яких він підготував. Можна титулами та нагородами: двічі лауреат Державної премії України, премій Президії Національної академії наук України імені Лебедєва та Глушкова, премії Вернадського; заслужений діяч наук і техніки України. Можна кількістю документальної прози, яку він написав: три книги про участь у Другій світовій війні та понад десяток з обчислювальної техніки.

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

Над матеріалом працювали Ярослава Тимощук, Владислава Зацаринна.

У підготовці використали цитати з книг:

«Зберігати довічно/Store eternally». Київ, видавничий дім «Києво-Могилянська академія», 2007 рік.

«Документальна трилогія». Київ, видавництво «Горобець», 2011 рік.

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

Ілюстрації Каталіни Маєвської

«Що б я не спитав у тімліда, це викликало в нього люту агресію»

Junior JavaScript Developer

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

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

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

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

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

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

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

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

«Люди, яких я знав як професіоналів найвищого рівня, сварились на рівному місці»

HR

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

Роль HR-менеджера в цій компанії була суто адміністративна: заповнення документів, пейрол і підняття духу команди «своїми силами». Інші важелі впливу, як-от тренінги, перегляд зарплати, перерозподіл обов’язків чи людей у командах, мав Project Manager. За цю команду відповідав PM, і з часом, коли ситуація ставала все критичнішою, він перестав справлятись і вигорав. Це стало наслідком багатьох токсичних дій як щодо команди, так і щодо мене.

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

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

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

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

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

Критична ситуація виникла з людьми. Рівень звільнень зашкалював, люди йшли, бо не витримували тиску. Замовники собі дозволяли не те що хамити, а з матом говорити (англійською) на стендапах, наприклад. А якось усі понаднормово працювали і всім пообіцяли за це оплату, а потім її вчасно не видали. Комусь не видали її взагалі. Члени команди були незадоволені. Через великий ворклоуд почалися конфлікти. Люди, яких я знав як професіоналів найвищого рівня, сварились на рівному місці.

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

Менеджер не відповідав співробітникам, оскільки на ньому була величезна кількість обов’язків, які можна було погрупувати на project-related і people-related. Відповідно людей він ставив трохи далі в пріоритетах.

«Человек не решал проблему непосредственно с коллегой, а шел к старшему менеджеру и жаловался»

Project Manager

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

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

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

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

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

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

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

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

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

«СЕО компании сказал фразу настолько ужасную, что моя самооценка упала»

FullStack Developer

Устроилась я на работу Full stack JS-разработчиком. Всё хорошо, и по беку, и по фронту (веб и мобайл) тянула без проблем. Компания росла, появлялись новые проекты, разработчики. Нас начали делить на фронтовиков и бэкендщиков. Так как я очень хорошо знакома с фронтом, опыта больше и скорость разработки наивысшая, меня туда и отправили. Полгода проработала в этом режиме.

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

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

Сначала он произнёс дивную речь, которая меня насторожила. Что-то наподобие: «О твоей зп узнали другие программисты и начали завидовать». (Хотя все мы получаем приблизительно одинаково. Откуда я знаю? Помогала нанимать их!) Что, мол, ты получаешь деньги, живёшь на Бали, работаешь удалённо... А они «вынуждены» каждое утро в Киеве вставать, ехать на работу в метро, в дождь и в холод зимой.

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

И предложил мне три варианта:

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

Сказал, что даст мне подумать неделю и потом спросит о моём решении. Прошло уже 4 месяца. Меня никто не переспрашивал. А я, униженная, продолжаю делать свою работу молча...

Всего у меня 5 лет опыта в разработке. Мой путь примерно такой: HTML+CSS+LS -> Java -> Kotlin -> Android -> React Native. Когда компания меня нанимала, я была только React Native специалистом. В первый же день работы мне сказали, что нужно сначала писать на React, а следующий проект уже на React Native. Нет проблем. Через полгода работы сказали, что нужно ещё на Node писать. И тут я тоже согласилась, за месяц прошла курсы и влилась в поток....

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

Фидбек был всегда позитивный, вплоть до того, что мне аплодировали клиенты, когда мы презентовали продукт (я лидом тогда была). А когда меня переключили чисто на фронт, я сделала всё, чтобы развить максимальную скорость разработки. Такую, что полностью закрывала фронт-задачи и помогала бэкендщикам. Например, если было выделено 4 недели, то у меня уходило 2-3 максимум.

Большинство работает удалённо. Есть основные группки людей в киевcком офисе (4-5 человек)и в европейском офисе (7-10 человек).Мы мало общаемся — в основном звонки или видеозвонки. Отношение коллег ко мне не изменилось, всё хорошо. Уверена, что это не люди мне завидовали, а СЕО придумал. Психологический ход. С тех пор с ним больше не общалась. Сама я стала более замкнутой. Реже прошу о помощи и спрашиваю что-либо. Постоянно не уверена в себе.

Думки експертів

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

Александр Конопко, гештальт-терапевт, в прошлом Senior Java Developer

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

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

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

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

Анна Кураева, Delivery Manager Luxoft

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

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

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

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

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

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

Вікторія Дробович, керівниця команди бізнес-партнерів ЕРАМ у Києві

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

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

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

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

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

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

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

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

Що робити, якщо ви менеджер у токсичній команді?

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

Я вже майже три роки працюю як Big Data Engineer. Час від часу доповідаю на технічних конференціях/мітапах в Україні та за кордоном і нерідко замислююся, як там представлятися. Якщо скажу, що працюю Big Data Engineer, більшість людей або не зрозуміє, чим я займаюсь, або буде плутати з іншими спеціальностями — Data Scientist, Data Analyst. За останні кілька років помітила, що рідше потрапляю в такі ситуації за кордоном, ніж в Україні.

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

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

Що таке Big Data Engineering

Є багато визначень, що таке Big Data Engineering, і всі вони крутяться навколо даних і маніпуляцій над ними. Це поняття пояснюють як практики маніпуляції над великими даними, що охоплюють побудову інфраструктури роботи з даними, зберігання даних, отримання доступу до них і їх форматування. Великі дані (Big Data) — це дані, в яких є специфічні ознаки, що називають 5V (Volume, Velocity, Veracity, Valence, Value): обсяг, швидкість, точність, зв’язаність, цінність.

Але в назвах професій Data Scientist і Data Analyst теж є слово data. Невже це означає, що всі вони пов’язані? Так. Хоча завдання для Big Data Engineer з’явилися майже одночасно із завданнями для Data Scientist, як професію її виокремили тільки недавно. Тому не дивно, що немало спеціалістів в ІТ-індустрії не чули про Big Data Engineering.

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

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

Робота Data Engineers — побудувати систему зберігання даних, очистити та відформатувати ці дані, налаштувати процес оновлення даних і їх прийому системою, розгортання системи й допомога в побудові моделей машинного навчання (ці завдання також можуть виконувати Machine Learning Engineers).

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

Image Source: Close look at Data Scientist vs Data Engineer

Для Data Scientists краще підійде математична база, тоді як Data Engineers варто мати базу знань з розробки програмного забезпечення. Якщо розібратись, таке розмежування між Data Science і Big Data Engineering є логічним і очевидним. Тому більшість компаній, які створюють продукти у сфері машинного навчання, в якийсь момент зрозуміли, що Data Scientists не можуть одночасно ефективно виконувати завдання з обробки даних і розробляти моделі машинного навчання. Для цього потрібні інші люди з іншим набором навичок. Так професія Big Data Engineer стала відокремлюватись від інших. У чому ж її специфіка?

Типові завдання, які розв’язує Big Data Engineering

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

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

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

Тепер розберімо технічний бік завдань, які найчастіше виконують Big Data Engineers.

Побудова ефективних процесів конвеєрної обробки даних (Data Pipelines) — одне з найважливіших для Big Data Engineers у будь-якому проєкті. Треба створити структуру процесів обробки даних і, звісно ж, реалізувати її. Багато інших завдань є частиною цього процесу та допомагають його поліпшувати з погляду ефективності. Серед них відомий ETL (Extract Transform Load) — вилучення даних, проведення трансформацій над ними та завантаження в іншу систему для зберігання і подальшої роботи. Для різних видів даних використовують різні інструменти, у Big Data часто працюють зі статичними або потоковими типами даних. Для таких цілей застосовують фреймворки Apache Spark, Flink, Storm, Kafka та хмарні сервіси AWS, Google Cloud, Azure.

Зберігання даних. Big Data Engineers часто визначають механізми зберігання даних та отримання доступу до них. Побудова сховища даних (Data Warehouse або Data Lake) — це досить поширене завдання, для виконання якого треба брати до уваги велику кількість даних, їх різноманітність і погану структурованість (сирі дані). Для зберігання можуть слугувати як реляційні (PostgreSQL, MySQL, MsSQL, Oracle DB), так і нереляційні бази даних (Cassandra, MongoDB, Neo4j), та інші сховища, як-от HDFS чи хмарні сервіси.

Обробка даних.Дані найчастіше бувають різноманітних форматів, тому для їх використання в базах даних чи інших сховищах, треба переводити дані у відповідний структурований формат. Такий тип обробки передбачає зміну формату даних (якщо це необхідно), очищення даних, виявлення аномалій. Найбільш поширені типи даних у сфері Big Data — Parquet, Avro, Protobuf, CSV. Попередня обробка даних може бути частиною конвеєрної обробки або одним з етапів створення моделі машинного навчання.

Інфраструктура. Big Data Engineers повинні розгортати створені рішення (Docker, Kubernetes), брати участь у налаштуванні CI/CD (Jenkins, TeamCity), визначити необхідну кількість ресурсів для виконання програм, будувати механізми збору метрик і логування (Prometheus, Grafana).
І якщо ми повернемося до порівняння з Data Science, то побачимо, що всі ці завдання складаються в одне ціле.

Image Source: Data engineers vs. data scientists

Часто Data Engineering і Data Science становлять дві частини одного продукту. Але Data Engineers можуть працювати та над створенням проєктів, які не охоплюють технології машинного навчання. У моїй кар’єрі більшість проєктів не містили частини Data Science, тож мені не доводилося працювати з відповідною командою. Тому існування незалежних Data Engineering проєктів цілком реальне.

Big Data Engineers здебільшого співпрацюють з командами інфраструктури, тестування, Data Science. І якщо створення інфраструктури і тестування рішень вимагають навичок і знань у сфері великих даних, Data Science частина переважно створюється незалежно. Тому, на мою думку, найбільше труднощів виникає у співпраці з Data Science командою або командою аналітики. Data Scientists і аналітики/ні виступають у ролі споживачів даних (які обробляються і зберігаються Big Data командою). Відповідно в них є вимоги щодо того, як ці дані представляти й надавати. Тому в спілкуванні між ними і Big Data Engineers можуть виникати складнощі й навіть конфлікти.

Головні виклики

Основні виклики пов’язані з природою даних. Йдеться про дуже великий обсяг даних (терабайти/петабайти даних), високу швидкість потокових даних, нестандартний формат, різноманітність даних, які вимагають специфічної обробки. Це проявляється в типовій проблемі оптимізації систем і особливо запитів у БД, враховуючи те, що Data Engineers часто доводиться працювати з ними.

Коли я працювала з потоковими даними, які трансформувались частково за допомогою БД і частково за допомогою фреймворку Spark, головною проблемою було створення такого запиту в NoSQL базі даних, щоб за секунду будувались дані для мільйона користувачів.

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

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

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

Плюси та мінуси професії

Головні плюси:

• Сфера ще досить молода, особливо в Україні, тому завжди є місце для інновацій і досліджень. З’являється все більше застосувань у різноманітних галузях.
• Конкуренція на кожну позицію не така висока, як в інших сферах, оскільки на ринку загалом не так багато Big Data Engineers. Часто на позицію Big Data Engineers беруть тих, хто працював у back-end розробці, з урахуванням вивчення Big Data екосистеми в процесі.
• Більшість завдань орієнтована на роботу з даними різних форматів, тому, якщо вам таке подобається, це буде великим плюсом у професії.

Але в цій сфері також є мінуси:

• Різноманіття інструментів для розв’язання завдань. Нерідко виникає питання, який інструмент і де краще використовувати. І найскладніше те, що бажано розбиратися в наявних інструментах і фреймворках. Звідси випливає наступний недолік.
• Високий поріг входу в професію. Потрібен кількарічний досвід у розробці, щоб компенсувати знання фреймворків. Деякі інструменти можуть здаватись занадто ускладненими, тому вивчити їх швидко не вийде. Якщо ви зміните роботу, технологічний стек може змінитися теж і доведеться вчитися знову. Досвід у Big Data можна отримати на реальних проєктах через специфіку великих даних. Рet-проєкти в цьому не дуже допомагають.
• Невидима робота. Завдання, які виконують Big Data Engineers, є базою для багатьох рішень, але вони не спрямовані на користувачів. Тому робота цих спеціалістів часто залишається в тіні, на відміну, наприклад, від Data Scientists. І виміряти вплив на продукт/проєкт від цієї роботи — не просто.

Бекграунд для входу в професію

Data Engineering ближче до back-end розробки, ніж до аналітики, тому найпростіше перейти в Big Data з досвідом розробки будь-якою мовою програмування. Під досвідом розробки маю на увазі базове знання алгоритмів та структур даних, їх використання для реальних завдань. Корисно, якщо є досвід роботи з різноманітними типами даних, їх очищенням та обробкою.

Ще краще, якщо такими мовами були Scala, Python чи Java, тому що вони є найбільш поширеними у сфері великих даних. В Україні ринок вакансій Big Data Engineers практично 50 на 50 розділений між Python і Scala з малим відсотком Java. Тому якщо постає питання, яку мову краще вивчити чи удосконалити для отримання позиції Big Data Engineer, не вдасться відповісти однозначно. Але можна проаналізувати вакансії та обрати відповідно до зацікавлення у конкретному проєкті чи компанії.

Я зустрічала інженерок/ів, які навіть працювали з фреймворком Apache Spark, але не виконували повного спектра Big Data завдань. Для них поріг входу може бути найнижчим. Деякі Data Scientists також працювали зі Spark, тому їм для переходу в Data Engineering достатньо опанувати інші необхідні фреймворки або інструменти для побудови інфраструктури (якщо не було з ними досвіду раніше). Навички в машинному навчанні допоможуть краще розуміти контекст і роботу Data Science команди.

Дуже важливо мати гарні аналітичні навички, знання SQL, досвід з різноманітними базами даних — написання запитів, дизайн баз даних. Тому цілком реально перейти з аналітики чи SQL-розробки в Big Data, але тоді треба вдосконалювати навички програмування.

Якщо аналізувати ситуацію за кордоном, то можна знайти спільні тренди в європейському та американському регіонах. Там професію Big Data Engineer почали виділяти раніше, ніж в Україні, тому в більшості компаніях, де є позиція Data Scientist, є і Data Engineer. Галузі, в яких Big Data Engineers вирішують завдання, різноманітніші за кордоном, ніж в Україні, оскільки і кількість компаній більша, і сфера розвивається довше.

Найчастіше посаду Big Data Engineer можна побачити у великих компаніях, як-от Apple, Amazon, Google, Facebook тощо. Таких вакансій мало в Східній Європі та Прибалтиці (там рідко бувають представництва великих гравців або Big Data розробку організовують в інших офісах). Мова програмування буде залежати від того, якою мовою програмування створено більшість проєктів у компанії. Також Big Data Engineers є в консалтинг-компаніях (аутсорс) і стартапах.

В Європі та США зарплати в Big Data Engineering будуть вищими, ніж у бекенд-розробці на Python чи Scala. В США Scala — одна з найбільш оплачуваних мов програмування, тому Big Data Engineers зі знанням Scala можуть очікувати на вищу зарплату, ніж зі Python.

Щодо оплати праці, то на DOU немає окремого розділу зарплат і вакансій для Big Data Engineers, тож це більше залежить від основної мови програмування і компанії. Деякі компанії оцінюють цю спеціальність вище, ніж бекенд-розробку. Але буває, що зарплати з бекенд-розробниками збігаються. Поки що ринок Big Data в Україні не дуже стабільний і не явно відокремлюється від Data Science ринку.

Особистий досвід розвитку в галузі

До того як стати Big Data Engineer, я була Java-розробницею. У якийсь момент машинне навчання набрало популярності, і я теж цим зацікавилась. Я починала зі статей та експериментів з різними алгоритмами, але сам процес побудови моделей машинного навчання мене не захоплював, на відміну від роботи з даними. Тоді я дізналася про окрему спеціальність Big Data Engineer і з цього почався мій шлях у світ великих даних. Я переглянула чимало курсів на Coursera, почала вивчати Python, Spark, Hadoop, але цього було недостатньо.

Тоді ж я подавалася на стажування та офлайн-курси в Big Data. Я пройшла на курси від DataRoot Labs, але викликом стало те, що основною мовою програмування була Scala. Хоча курс був розрахований на тих, хто раніше не вивчав цієї мови, темп був досить швидкий. Заняття тривали два з половиною місяці, після яких я вже могла впевнено програмувати на Scala, вивчила основи Akka, Docker, Ansible. Результатом курсів був фінальний проєкт — у моєму парсились дані з Twitter, записувались в базу даних, зчитувались з неї, відтак на цих даних будувалась мінімальна аналітика. У межах цього проєкту я вперше попрацювала з потоковими даними, які потрапляли в систему в режимі реального часу.

Компанії-партнери курсів відбирали найкращих студентів для працевлаштування, з-поміж них і Ciklum. Так я отримала першу роботу як Big Data Engineer у Big Data & Analytics department (зараз Ciklum Digital). Я брала участь у кількох проєктах, і мої завдання охоплювали дослідження специфічних БД, створення прототипів для внутрішніх програм на основі цих досліджень, робота з потоковими та статичними даними, побудова ETL. Крім того, я брала участь в налаштуванні CI/CD процесів. За півтора року в Ciklum я значно поліпшила свої big data навички та долучалася до різноманітних проєктів.

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

Курси і стажування — гарна можливість, щоб отримати знання і практичні навички у цій сфері. Тому раджу починати з них. Та це не найважливіше. На мій розвиток дуже вплинули ментори. Тож дуже рекомендую шукати менторів на робочому місці, на стажуванні/курсах чи в спільнотах, які самі організовують такі програми. Нині я беру участь у менторській програмі від Women Who Code Kyiv як менторка Big Data напряму.

Шляхи розвитку

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

Для Big Data Engineers є змога перейти в суміжні спеціальності — Data Science чи аналітику. І, звісно ж, можна зростати в менеджменті або архітектурі. Але це доволі очевидні варіанти. На мою думку, мало висвітлюється перехід з Big Data Engineering в Devops-related спеціальності, хоча інженерки чи інженерки можуть виконувати багато інфраструктурних завдань. Схоже поєднання навіть створює нові посади, наприклад є ML/Big Data DevOps спеціалісти. Думаю, ця професія не може набриднути, адже завжди можна генерувати нові ідеї та рішення.

Висновки

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

Сподіваюсь, ця стаття допомогла вам зрозуміти, чим займаються Big Data Engineers і чи потрібні вашій компанії такі спеціалісти.

Ресурси для розвитку в Big Data Engineering

Якщо вам цікаво дізнатися більше про сферу Big Data, раджу такі ресурси:

• Книга про основи: Big Data Fundamentals: Concepts, Drivers & Techniques by Thomas Erl, Wajid Khattak.
• Книжка, в якій багато інформації про задачі, які вирішуються у сфері та за допомогою яких інструментів: Big Data: Principles and best practices of scalable realtime data systems by Nathan Marz, James Warren.
• Фундаментальна спеціалізація на Coursera.
• І більш детально про data engineering vs data science у статтях на DataCampі TowardsDataScience.

Привіт, мене звати Богдана. Я розвиваю напрям бізнес-аналізу в компанії TechMagic. У цій статті поділюся порадами щодо комунікації із замовниками, які ґрунтуються на власному досвіді та перевірені протягом майже 7 років роботи в ІТ :) Читати варто всім, хто спілкується з клієнтами: бізнес-аналітикам, проєктним менеджерам, тестувальникам, розробникам. Можливо, хтось почерпне щось нове, хтось нагадає собі те, що призабув, а дехто подивиться на ту чи іншу ситуацію під іншим кутом.

Інструменти комунікації

Communication Plan

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

1. Список стейкхолдерів (як з вашого боку, так і з боку замовника).
2. Ролі та обов’язки (наприклад, Олег — техлід, відповідає за архітектурні рішення, надає права доступу в GitHub; Мішель — проєктна координаторка від замовника, відповідає за дедлайни, надає права доступу в Jira та Confluence тощо).
3. Про що інформувати стейкхолдерів та з чим до них можна звертатись (наприклад, повідомлення про реліз, зміщення графіка, уточнення вимог, зміни в складі команди, державні вихідні та відпустки).
4. Як часто інформувати (раз на тиждень, щодня, щоразу після змін у певному компоненті тощо).
5. План (на малюнку внизу).
6. План стейкхолдерам (якщо про цей план будете знати лише ви, він навряд чи сильно вплине на якість комунікації на проєкті).

Emails

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

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

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

Тема листа — «RE:RE:FW: Discussion on some important points» не можна вважати зразком чіткої теми :) А от, наприклад, «Follow up on discussing migration to new server» звучить вже значно краще.

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

Перевірка.Перечитайте те, що написали: чи все зрозуміло, чи нічого не забули. Можна дати ще комусь почитати, якщо йдеться про складну чи важливу проблему. Недарма ж у кожного письменника є редактор :)

Meetings

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

1. Готуватися до зустрічі. План, учасники: хто має бути обов’язково присутній, а кому це опціонально. (Може, люди зможуть зробити щось корисніше, ніж гортати стрічку соцмереж, слухаючи ваші обговорення у фоновому режимі :) Розішліть матеріали, які будете обговорювати. Це значно зменшить кількість питань типу «А що, там десь таке писало? А де це таке не дизайні?»
2. Дотримуватись плану зустрічі.
3. Контролювати мову тіла. На одній зустрічі, де обговорювали новий проєкт, який ми хотіли виграти, замовник захоплено розповідав про свій геніальний задум, а скептичний вираз обличчя та закрита поза техліда давали зрозуміти, що ця ідея не гідна навіть того, щоб бути висловленою. Думаю, не важко здогадатись, що проєкт ми так і не здобули ;)
4. Вести нотатки. Ви структуруєте, чого досягли під час зустрічі, які наступні кроки і хто за що відповідальний (і завжди можете послатись на нотатки, якщо люди не дотримуються зобов’язань

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

Замовники із різних країн

Ситуація

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

Що зробила я

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

Висновки

1. Враховуйте різницю в часі.
2. Прочитайте книгу Cultural Map Ерін Меєр на тему культурних відмінностей.
3. Спростіть своє усне мовлення та письмо, якщо є ризик того, що вас можуть не зрозуміти.
4. Фіксуйте домовленості в письмовій формі.
5. Враховуйте стиль спілкування співрозмовника, а не просто копіюйте: якщо замовник використовує жаргонну лексику, це не означає, що вам пора вітатись у листах «hey, dude», варто перейти просто на менш формальне спілкування.

Велика кількість стейкхолдерів

Ситуація

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

Що зробила я

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

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

Висновки

1. Визначити, хто ухвалює рішення. Це буває складно: «Ми ухвалюємо рішення колегіально, у нас демократія». У такому разі запитайте, хто затверджує бюджет. 99% ймовірності, що ви відразу дізнаєтесь, хто вирішуватиме.
2. Документувати вимоги та зберігати всю інформацію в єдиному місці, доступному всім.
3. Проводити Impact analysis. На що вплине те чи інше побажання одного із замовників, як воно відіб’ється на системі, які є ризики.
4. Визначити плюси та мінуси кожного рішення. Якщо є кілька альтернативних варіантів, краще підготувати переваги та недоліки кожного й одразу підкреслити той, який ви та ваша команда вважаєте оптимальним.
5. Презентувати результати аналізу усім стейкхолдерам для визначення пріоритетів. Як показує практика, це дає змогу клієнтам зрозуміти, наскільки той чи інший запит важливий, скільки часу (та грошей) займе його реалізація.

Заперечення

Ситуація

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

Що зробила я

1. Проаналізувала, у чому причина. Виявилось, не було кому сидіти й описувати вимоги і клієнти ділились усно ідеями з дизайнером, який те все малював.
2. Візуалізувала недоліки підходу документування дизайнів. Схематично зобразила сценарії користувача за допомогою user flows, на яких чітко можна було помітити пропущені моменти в дизайні.
3. Показуючи візуалізацію, підкреслила, що, якщо просто описувати екрани, усі ці недопрацювання можна не помітити, тому краще документувати вимоги та зіставляти їх з дизайнами.
4. Була одним з ініціаторів дизайн-рев’ю сесій, під час яких разом з клієнтом та дизайнером обговорюємо різні сценарії використання.

Висновки

1. Визначити причини. Часто це може бути брак бюджету, страх втратити авторитет чи й просто нерозуміння важливості змін.
2. Пояснити, чому зміна важлива.
3. Візуалізувати свої аргументи.
4. Наголосити на вплив, який матимуть ті чи інші зміни.

Робота з негативом

Ситуація

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

Що зробила я

1. Опанувала себе й замість емоційної реакції відписала клієнтам, що ми проаналізуємо ситуацію та проведемо зустріч, щоб усе обговорити.
2. Дослідила причини: зібрала всі баги, посортувала за пріоритетом, статусом, тим, чи знайдені вони замовником, чи нашою командою, вивела метрики.
3. Обговорила результати аналізу з клієнтом. Стало зрозуміло, що баги, про які писали клієнти, пов’язані з різним уявленням про те, як будуть поводитись користувачі.
4. Разом з тестувальниками переглянули тест-стратегію, скоригували сценарії та затвердили з клієнтами, щоб уникнути таких ситуацій надалі.

Що робити

1. Зберігати спокій і позитив.
2. Виграти час. Клієнт виявив критичний баг у продакшені й бурхливо вимагає негайного виправлення, але ви розумієте, що це неможливо зробити за 5 хвилин. Скажіть, що усвідомлюєте серйозність проблеми і зробите все можливе, щоб її ліквідувати, і в жодному разі не залишайте листи клієнта без відповіді довго.
3. Дослідити причину негативу з боку клієнта.
4. Скласти стратегію розв’язання проблеми.
5. Доповнити пояснення цифрами чи візуально. Якщо клієнт не розуміє, як працює якийсь функціонал і чому це не так, як він хотів, намалюйте діаграму, розпишіть сценарії, зробіть скріншоти. Маючи візуалізацію, значно легше обговорювати навіть дуже складні питання.
6. Ніколи не сперечатись з клієнтом до з’ясування всіх обставин.
7. Ніколи не звинувачувати нікого зі своєї команди в комунікації з клієнтом.
8. Бути готовим визнати свої помилки: усі ми помиляємось, головне робити висновки і не повторювати одні й ті самі помилки багато разів :)

Брак комунікації

Ситуація

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

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

Що зробила я

1. З’ясувала канал комунікації, найзручніший для клієнта, зокрема для термінових питань.
2. Склала план відпусток і вихідних і попросила клієнта повідомляти, коли він буде недоступний.
3. Почала додавати в тему листа помітку Blocker, якщо була потрібна швидка реакція.

Що робити

1. Визначити канали комунікації, зручні для клієнта. Можливо, він не любить користуватись електронною скринькою і віддає перевагу листуванню в чаті.
2. Наголосити на важливості та терміновості питання. Проте тема листа на зразок «Need clarification about some issue» аж ніяк не дає розуміння того, що без цього уточнення ваш реліз заблоковано, і не викликає бажання миттю кинутись відповідати на запитання. Краще написати «Release blocked due to lack of decision on ».
3. Якщо клієнт продовжує ігнорувати ваші послання, спробуйте порушити питання на вищому рівні (як з вашого боку, так і з боку клієнта, якщо це можливо). Наявність у СС менеджменту зазвичай підсилює важливість вашого звернення, але перед тим, як його туди вписувати, переконайтесь, що питання справді важливе і цього варте.

Підсумок

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

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

З того часу минуло вже 7 років, які я присвятила саморозвитку у сфері програмування. Зараз співпрацюю з EPAM як Senior Java Developer. Я з тих, кому буває ліньки зробити щось для себе, але якщо пообіцяв другу, то хоч зі шкіри вилізь, але виконай. Тому, щоб поглибити свої знання, я вирішила навчати інших. Впродовж року була менторкою та тренувала студентів курсів з програмування. Потім кілька років викладала, проводила вебінари та виступала на подіях для новачків-розробників. Успіхи моїх студентів та їхнє прихильне ставлення надихали вивчати щось нове та ділитись знаннями. Найкращими уроками були ті, що підпадали під визначення «гарного пояснення» Ейнштейна: «Якщо ви не можете пояснити це шестирічній дитині, ви самі цього не розумієте».

Наступною сходинкою після викладання Java дорослим стало викладання програмування більш вибагливій аудиторії — дітям. Цим я успішно займалась останні 4 роки здебільшого в EPAM, на проєкті eKids. Я працювала з групами учнів від 7 до 16 років, викладала різні мови програмування в команді з іншими тренерами або самостійно. Програму писали в процесі, орієнтуючись на рівень дітей та їхні вподобання, тому спробували різне.

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

У якому віці починати програмувати

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

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

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

Наступна градація базується на власному досвіді роботи з різними віковими групами дітей.

<7 років:«Мої батьки найкращі, тому з ними я готовий займатись чим завгодно».

8-9 років:«Програмування — це прикольно, адже це гра!»

10-12 років:85-90%дітей радо спробують програмування і більшість того, що ви їм запропонуєте. З підтримкою дорослих вони серйозно хочуть дізнаватись усе, що є навкруги, аби почуватися дорослими та поважними.

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

Порада 0: Дитині теж потрібен «час на себе»

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

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

Переконайтесь, що дитині справді потрібно програмувати

Кажу я так тому, що була членом журі конкурсу «Володарі Scratch»та бачила роботи дітей 9-10 років.За умовою конкурсу у складі команди могли бути до трьох дітей від 10 до 12 років та один дорослий наставник. Молодшим не забороняли реєструватися. Як не дивно, у кількох командах-переможцях у помічниках або навіть головних програмістах були саме дев’ятирічні діти! Ці учасники були звичайними дітьми, яким кортіло взяти участь у конкурсі. Але на питання щодо коду краще відповідав учитель, ніж вони.

У дитинстві всі хочуть вирости

Не раз чула в магазинах, як батьки кажуть дітям, що «іграшка коштує грошей» і вони або не мають їх достатньо, або не вважають, що доцільно витрачати їх на третій водний пістолет або залізну дорогу. Особисто мені не подобається ставлення до грошей як до ресурсу, який 1) закінчується 2) можна витрачати, коли він є. Гроші — це можливість, якою варто розумно розпоряджатись, а також примножувати. Ще є правило: робота, що дає задоволення, приносить дохід у квадраті. Ви краще робите те, що вам подобається, намагаєтесь вигадати таке, щоб результат був кращим, більш екологічним, а значить, заслуговуєте більше грошей за зусилля.

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

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

Порада 1: Один за всіх, а всі за одного

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

Гра на замовлення

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

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

• Тімлід (Team Lead) — учитель.
• Сеньйори (Seniors) — діти, які вже багато разів були на курсах, працюють самостійно вдома та добре розбираються в програмуванні.
• Джуніори (Juniors) — діти, які програмують не так давно, але звання програмістів уже заслужили.

Порада 2: Омріяна винагорода

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

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

Порада 3: Усе відбувається насправді

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

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

Порада 4: У кожного віку свої особливості

Тімлід почав голосно та чітко перераховувати вимоги до майбутньої гри:

• Головний герой пересувається полем, (не) натикається на різні об’єкти.
• Існують бали, які свідчать про силу героя та кількість його життів.
• Мають бути рівні гри. З часом грати стає важче.
• Гра має бути особливою та несхожою на інші.

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

Неочікувано, але тімлід усміхнувся. «У тому й справа, що тут немає жодної конкретики. Ідея та реалізація в наших руках! Можемо писати, що захочемо, а нам за це платитимуть! Обмежень немає. То що, мозковий штурм?»

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

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

Порада 5: Створи таке, не знаю яке

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

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

Порада 6: Нове місце для нових ідей

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

Порада 7: Діти відверті, коли їм комфортно

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

Порада 8: На кожному уроці — досягнення

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

Порада 9: Потрібен лідер

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

Порада 10: Success Story 1 -> Success Story 2 ->...

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

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

Порада 11: Зробіть момент влучним для навчання

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

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

Алгоритм пояснення нового матеріалу

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

1. Згадайте історію, яка б стосувалася дитини, а ще краще її буденного життя. Це може бути мурашник, побачений на прогулянці, та працьовиті мурахи, що один за одним несуть крихти до свого палацу; човниковий біг командами на уроці фізкультури; похід за новою сукнею до магазину...
2. Продумати з дитиною одну дію.
3. Додати другу, третю ітерацію цієї ж дії, обговорити необхідну кількість ітерацій.
4. Якщо дитині все зрозуміло, завдання можна ускладнити та спитати, як би вона його розв’язала.
5. Якщо точно все зрозуміло на словах, а може, і на малюнках, можна братись програмувати.

Як з нічого зробити все, або Як допомогти взятись за програмування

Уявімо, що ви йдете разом з дитиною в магазин, а потім на дитячий майданчик, і спілкуєтесь:

Д: Тату, може, зразу підемо кататись?

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

Д: Мій улюблений? Значить, купимо сир з величезними дірками, який я відрізатиму товстелезними шматками?!

Б: Домовились, а мамі купимо солоних огірків, мені гострий кетчуп, сестричці дитячу ковбаску.

Д: Це всім треба буде зробити різні бутерброди?! Ого!

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

Д: А як же ми можемо зробити різні бутерброди в одному циклі?

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

Д: Так, це я зможу, але ж зверху теж треба щось покласти!

Б: Пам’ятаєш, ви раніше вивчали структуру if-then-else?

Д: Виходить, я можу написати, що якщо я, то сир, якщо мама, то сир та огірки, якщо сестра, то ковбаска, а тобі все та кетчуп?

Б: Так, спробуймо, коли повернемось?

Д: Звісно, я ще картинки гарні намалюю!

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

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

Коли шкода дітей

Проблема перфекціоністів: Not Good Enough

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

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

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

Є дорослі, які, пояснюючи дитині щось, приділяють занадто багато уваги деталям або історії. Прикладом може слугувати пояснення умовного блоку if. Тямущому DevOps не складно дійти до глибин побудови комп’ютера та розказати про роботу транзисторів як бази для порівняння значень елементів. Хтось урок з Python починає з винайдення калькулятора як першої обчислювальної машини, розказує про програмування на машині Тюрінга, мову Ада тощо. Добре, якщо розповідь буде захопливою. Я за те, щоб, окрім обмеженого пояснення мови програмування, розширювати кругозір дитини, додаючи цікаві факти та жарти. Це сприятиме асоціативному мисленню та полегшуватиме запам’ятовування інформації. Але вся інформація має стосуватися теми уроку й підводити до неї та не відвертати уваги дитини надовго від суті.

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

Проблема успішних: ви говорите, а дитина не слухає

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

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

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

Якщо ви повторили щось вже 100 разів, а ефекту нема, не варто повторювати 101-йраз. Змініть підхід або ставлення.

Проблема притягування за вуха: всяка тримає свій ум голова

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

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

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

Як зацікавити дитину

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

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

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

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

З чого почати

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

Я користувалася сферичним роботом BB-8. Він підійде для маленьких дітей зі своєю Scratch-подібною мовою або тих, хто хоче спробувати JavaScript. Незабутнє відчуття проводити перший урок для маленьких дітей з роботом переодягненою в чарівницю! Також весело було проводити урокдля дорослих.

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

Raspberry Pі — чудовий конструктор, але самій дитині без знань схемотехніки важко розібратись з під’єднанням елементів. Програмувати можна різними мовами, зокрема на Python.

Є й інші роботи на будь-який смак.

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

Причини небажання вчитись

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

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

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

Головне, що мають зробити батьки, — це навчити свою дитину вчитись.

Нездібність. Чи справді вона є та чи можна її помітити під час написання програми? Важливо відрізняти саме нездібність від сильного бажання займатись чимось іншим. Пам’ятаю одну дівчинку, яка, здавалось, не дуже хотіла писати програму, адже присвятила багато часу вибору фону та головних героїв. Однак коли вона закінчила з цим, їй стало цікаво, як змусити їх рухатись. Вона намагалася розв’язати це питання, дивилася код у сусідів замість того, щоб кликати вчителя та просити все знову пояснювати. У кінці уроку дівчинка показала вже робочий проєкт! А коли звикла до вчителів та розкрилася, продемонструвала власні намальовані мультики. Я була вражена з яскравого таланту художниці та творчої особистості у 10-11 років!

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

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

Роль учителів у мотивації

Є така жартівлива градація:

Поганий вчитель — приходить на урок, розказує та йде.

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

Найкращийвчитель — мотивує людину самостійно здобути знання.

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

Є три речі, які мотивують:

• Гроші й те, що можна за них купити.
• Слава, визнання.
• Цікавість.

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

P.S.

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

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

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

Потреблять с базовым представлением о multithreading и design patterns.

Меня зовут Денис, я свитчер из химии, за 10 лет в embedded так и не научился паять и пользоваться осциллографом. В статье попытаюсь объяснить разницу между синхронным, асинхронным и смешанным подходами обработки событий, в частности — для soft real time систем с относительно большим количеством логики.

Итак, SIP<->(DECT|FXS) gateway внутри Wi-Fi роутера.

Действующие лица

DECT — стандарт, по которому работают радиотелефоны. Описывает связь между трубкой и базой. Разбивка по уровням похожа на OSI-стек. Томов много, но большую часть (нижние уровни стека) имплементят производители «железа» в фирмваре, так что в приложении остается совсем ничего, какие-то три тома: GAP (звонки), CAT-iq 1 (согласование кодеков), CAT-iq 2 (параллельные звонки, телефонная книга, история звонков).

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

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

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

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

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

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

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

Adapter — переводчик стихов. Часто пишет отсебятину в надежде, что понимает оригинал лучше автора.

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

Mediator — риелтор.

OS/Vendor/Hardware Abstraction Layer — демократические выборы. Неважно, кто и за кого голосует — по сути ничего не изменится.

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

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

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

Upper/Lower Half — разделение общества на пролетариат и буржуазию.

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

Описание системы

Есть домашние Wi-Fi роутеры с USB-портами. Есть USB DECT база (обеспечивает связь с трубками радиотелефонов). Нужно, чтобы при подключении USB DECT-базы роутер превращался в телефонную станцию. Чтобы можно было с радиотелефонной трубки звонить через сеть, используя семейство стандартов связи SIP. После трех лет в продакшене понадобилось добавить также поддержку проводных телефонов, сделав свое USB FXS-устройство.

В итоге имеем embedded telecom soft real-time application. Астериск в роутер не влазит по размеру (флеша всегда мало), да он и не поддерживает нужные USB-«железки». Значит, пишем свой, маленький и непрожорливый. На роутере стоит линукс, что несколько облегчает задачу:

1. Программу можно будет запускать и дебажить на компьютере (совместимый код) без дополнительной разработки OS Abstraction Layer. Большой плюс.
2. Линукс дает pthread и потоки с приоритетами. В результате обработка логики сможет прерывать работу с файлами или индексацию телефонной книги, а передача голоса между USB и сетевыми сокетами — логику.
3. Можно втянуть небольшие библиотеки. В данном случае — libusb и PJSIP. Последняя просто спасла ситуацию: написать с нуля поддержку SIP со всеми дополнениями нереально.

Ограничения:

1. Soft real-time (voice) — голосовые пакеты бегают каждые 10-20 мс (в зависимости от «железа») для каждого звонка. Если задержать пару пакетов, в голосе будет щелчок. То есть, чем бы приложение ни занималось в данный момент, оно всегда должно быть готово обработать голос: либо по выставленному на 20 мс таймеру, либо когда голосовой пакет приходит.
2. Soft real-time (logic) — когда пользователь нажимает кнопку (или поднимает трубку) на телефоне, он ожидает какую-то реакцию. Можно протупить 100 или 200 мс, но за полсекунды очень желательно отреагировать: начать гудеть при поднятой трубке, оборвать звонок при положенной, разобраться, соответствует ли номер с новой набранной цифрой одному из правил набора. Если да — отправить запрос создания звонка на сервер через нужную учетку. При этом неважно, что в данный момент делают другие пользователи с другими трубками, есть ли связь с сервером или насколько эта связь тормозит — действия пользователя должны немедленно приводить к ожидаемому результату.
3. Процессор — кодеки на таком лучше не запускать: они начнут тормозить систему, торренты остановятся — и покупатели выбросят роутер через окно.
4. Флеш (размер программы и библиотек) — очень ограничен. Файловая система read-only.
5. Язык — С или С++, смотри пункт 4.

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

Обзор архитектуры

Далее описывается последняя версия приложения (с поддержкой USB FXS устройства). Общая структура с начала проекта не менялась, только добавлялись новые модули, а старые делились на части, когда кода в одном классе становилось слишком много.

Вид на систему из космоса, Adapter

Использованный подход называется Half-Async/Half-Async [POSA2]. Суть в том, чтобы выделить один поток (на картинке — большой квадрат с месивом из стрелочек) под бизнес-логику, ни на чем его не блокировать, а с периферией общаться месседжами. Тогда нет race conditions в основном коде, при этом все данные (как последнее известное состояние периферии) синхронно доступны из прокси, и обработка любой операции происходит быстро (high throughput/interactivity). Бонусом получаем Hardware/Vendor Abstraction Layers.

Если посмотреть на систему, видно, что это гипертрофированный Adapter [GoF] с сотнями настроек, логированием, телефонной книгой и прочими блэкджеками. Соединяет телефонный сервер где-то там далеко и локальное «железо», подключенное через USB.

Начнем с центра:

Call — то, ради чего система существует. Связывает два полиморфных участника, передает между ними события. Разросшийся Mediator [GoF].

Line, HS (Handset), Port — с одной стороны, участники звонков, с другой — Proxy [GoF], моделирующие состояние и обеспечивающие связь с «железом» (или учеткой на сервере). Очередной Adapter между абстрактным внутренним интерфейсом/контрактом звонков и логикой работы соответствующего типа (SIP/DECT/FXS) периферии.

SIP/DECT/FXS Wrapper — адаптеры между внутренним высокоуровневым протоколом и API конкретной «железки» или библиотеки. Mostly stateless. Тут водятся мютексы. Цель прослойки — отделить управление hardware от бизнес-логики и оградить последнюю от любых изменений периферии (версии, вендор) Messaging-интерфейсом (как лабораторию в [Devs]).

DECT/FXS Autotest — эмулятор устройства, управляемый из командной строки. Назначение соответствует названию.

DB + Files — поднятые в память телефонная книга и история звонков. Дают синхронный доступ с последующим асинхронным сохранением изменений в файл.

App + CLI — интерфейс управления из командной строки.

Notify — кормит тролля демона информацией о происходящем.

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

AudioDev — передача аудиофреймов между сетью и USB-устройством. Бежит в максимальном приоритете, просыпается каждые 20 мс, обрабатывает все каналы и опять засыпает.

Синхронность и асинхронность

Сравним:

1. Блокирующий синхронный Thread per Request (Reactor [POSA2]).
2. Неблокирующий полусинхронный Half-Async/Half-Async (Proactor [POSA2]).
3. Асинхронный Actors (Active Objects [POSA2]).

Для примера возьмем относительно простой, но показательный сценарий:

1. Приходит входящий вызов из сети (INVITE).
2. Создаем звонок.
3. Ищем номер звонящего в телефонной книге, чтобы отобразить имя.
4. Рассылаем звонок ({CC-SETUP})на 3 зарегистрированные DECT-трубки.
5. Отвечаем 100 Trying (приняли звонок, обрабатываем) серверу.
6. Вторая трубка включена и громко звонит ({CC-ALERTING}).
7. В то же время от сервера приходит отмена звонка (CANCEL).
8. Отсылаем 180 Ringing (устройство играет мелодию звонка) на сервер.
9. Отсылаем 487 Terminated (звонок завершен) на сервер.
10. Рассылаем завершение вызова ({CC-RELEASE})на трубки.
11. Сохраняем звонок в истории звонков.

Синхронная блокирующаяся обработка звонка (Reactor) — ждем, пока пользователь поднимет трубку:

Отмена входящего звонка, Reactor

Диаграмму взаимодействия не удается дорисовать из-за следующих проблем:

1. Нам нужно разослать входящий звонок на все зарегистрированные DECT-трубки. Правильным в синхронной парадигме было бы делать RPC для каждой. Вот только проблема: мы не знаем, какие из трубок включены и доступны. DECT — энергосберегающая технология, и кипэлайвы не предусмотрены. То есть база посылает сообщение и ждет, будет ли ответ. После таймаута (порядка 5 секунд) USB DECT донгл пришлет извещение, что трубка не найдена и звонок никуда на пошел. Но ведь пользователь, который нам звонит, не будет ждать на линии бесконечно, пока мы будем на всех когда-то зарегистрированных трубках поочереди получать таймаут по 5 секунд. Звонящий положит трубку, а наш юзер даже звонок услышать не успеет. Второй вариант — что-то в стиле foreach(), таким образом разослать запрос на все трубки. Тут другая проблема: а на чем тогда блокировать выполнение для ожидания ответа, если мы разослали запрос через foreach()?
2. Допустим, разослали foreach() и ожидаем, пока какую-то трубку поднимут (нажмут зеленую кнопку). Трубки начинают присылать {CC-ALERTING} —сообщение о том, что играет мелодия. По-хорошему, первое из них нужно преобразовать в 180 Ringing и отправить на сервер. Тогда у звонящего пойдут длинные гудки. Вопрос — как это сделать, если наш поток-обработчик звонка висит и ждет, пока поднимут трубку. Заводим второй поток-обработчик ALERTING и получаем межпоточную синхронизацию с мютексами для доступа к звонку, трубке и линии. И начинаются на каждом шаге проверки того, а живой ли звонок, для которого мы сейчас обрабатываем запрос. Ведь какой-то другой поток, обрабатывающий другой запрос, мог его убить. Второй вариант — блокироваться на обработчике многих событий и выходить из блокировки и когда приняли звонок, и когда трубка что-то другое прислала. Но в этом случае мы начинаем дублировать (рекурсивно вызывать?) main loop нашего потока, только уже с несколькими вызовами методов на стеке. Это некрасиво. Третий вариант — забить на ALERTING. И без него жить можно.
3. Допустим, забили на ALERTING. Сервер присылает CANCEL — звонящий передумал. Нужно погасить звонки на трубках, сохранить пропущенный вызов в историю и освободить ресурсы. Как мы это сделаем, когда CANCEL приходит с той же стороны, на которой начинается наш стек вызовов? Мы же ожидаем результат от DECT-трубок, а не отмену звонка из сети. Обрабатываем CANCEL другим потоком как новый запрос — снова получаем мютексы и проверку состояния всех объектов при каждом обращении к ним. И как фаталити — нужно будет потоком-обработчиком CANCEL как-то разбудить поток-обработчик INVITE, который до сих пор ждет, какая из трубок примет звонок.

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

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

Отмена входящего звонка, Proactor

Здесь видим, что весь сценарий, который невозможно было решить синхронной блокирующей парадигмой Reactor, нормально описывается полусинхронной (синхронное взаимодействие между компонентами логики и асинхронное — с периферией) неблокирующей обработкой трех событий в парадигме Proactor. В данном случае сообщение CANCEL от SIP-сервера попадает в очередь — в момент его получения поток-обработчик обслуживает {CC-ALERTING}от трубки радиотелефона. Когда поток завершает обработку {CC-ALERTING},стек раскручивается, поток оказывается в основном цикле, вынимает из очереди следующее сообщение (CANCEL) и начинает его обрабатывать. Таким образом события не конфликтуют: они сериализуются очередью, которая является единой точкой входа в систему.

Тем не менее за все нужно платить. Если для Reactorвесь процесс установки звонка — от его создания до поднятия трубки — можно было бы (если бы парадигма сработала) пошагово отдебажить, то для Proactorтакое невозможно. Например, на диаграмме вверху создание и разрыв звонка начинаются с обработчиков разных событий. Пошагово можно пройти реакцию только на одно событие, после этого поток выпадет в main loop и займется неизвестно чем, вероятно, каким-то другим событием из другого сценария с другими объектами. С другой стороны, как только выполнение остановилось на брейкпоинте в обработчике события, никто не может прервать отладку или как-то изменить данные. Любые изменения состояния являются результатом обработки событий, а события мирно накапливаются и ждут своей очереди. Если, конечно, не забыли отключить watchdog в конфиге.

Также неприятностью может быть reentrancy. Когда метод A1 объекта A вызывает метод B1 объекта B, который вызывает A2 в объекте A. В этом случае:

1. Во время выполнения A1 может нарушаться инвариант, тогда A2 начнет выполняться на объекте с неправильным состоянием.
2. Если A2 меняет состояние A, внутри A1 нужны проверки состояния: закешированные в локальных переменных данные могут стать устаревшими в результате выполнения A2.

Это обходится посылкой сообщения B1=>A2, которое будет обработано после того, как A1 завершится и стек раскрутится. Только лекарство не всегда лучше болезни: между A1 и A2 может обработаться постороннее сообщение, меняющее состояние системы (и объекта A). И в любом случае код A1-B1-A2, который ранее вызывался синхронно и легко отслеживался в IDE (Ctrl+click), становится разбит на несвязанные части A1-B1 и A2. Альтернатива — написать в коде комментарий, что здесь «грабли» (reentrancy).

Полезно будет пройти еще один шаг в сторону асинхронности. Если в Proactor вся логика жила в одном потоке, то для Active Objectsкаждому компоненту выделяется свой поток и кусок памяти. И вместо синхронных вызовов функций происходит обмен сообщениями.

Отмена входящего звонка, Actors

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

1. Это нельзя дебажить. Выполнение любого сообщения из внешней среды завершается почти сразу отсылкой сообщений другим объектам. Они будут асинхронно обрабатываться другими потоками, и обработчики будут отсылать еще больше сообщений. Разобраться в таком можно только при помощи логирования и удачи (внутренние сообщения от запуска к запуску будут в разном порядке, и логи будут отличаться).
2. По той же причине пересечения сообщений диаграмма стала более запутанной. Логика работы программы становится еще более рваной: те данные, которые раньше возвращались вызовом метода объекта, теперь приходят сообщением и обрабатываются отдельным методом. Пример — работа с именем звонящего (Alice).
3. При пересечении нескольких сценариев (на диаграмме — {CC-ALERTING}и CANCEL) внутренние сообщения устаревают. Например, запрос имени звонящего приходит в звонок уже после его завершения. В данном случае ничего страшного не произошло, но практически в каждом обработчике сообщения (а здесь нет других публичных методов) нужно проверять состояние объекта либо использовать (анти)паттерн State [GoF], что, по моему опыту, ужасно для читаемости кода.
4. Из-за асинхронности сценариев части данных может не хватать в нужный момент. Тогда либо потребуется отложить выполнение сценария (закешировать сообщение или добавить промежуточное состояние), либо выполнять сценарий, основываясь на неполных данных. Пример — завершение звонка до того, как телефонная книга нашла имя звонящего по номеру. В результате или сейчас сохраняем звонок в истории без имени, или нужно временно оставлять его в состоянии «deleting — waiting for caller name».

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

Half-Async/Half-Async

Мы рассмотрели архитектуру для бизнес-логики. Еще есть:

1. Работа с библиотеками и API подключаемых устройств.
2. Работа с файлами.
3. Взаимодействие с управляющим демоном (или тестировщиком).

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

Вид на систему из космоса, Layers

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

И драйвера, и приложение для телефонии управляют физическими устройствами через низкоуровневый интерфейс. В обоих случаях важна скорость реакции на события и возможность управления устройствами с разным API. Это обеспечивает асинхронная тонкая нижняя половина, инкапсулирующая специфику управляемого устройства. Верхняя половина занимается высокоуровневыми сценариями, превращая их в последовательность запросов к нижней половине и обработчиков нотификаций от нее. При этом интерфейс верхней половины драйвера для клиентских приложений стандартный, в соответствии с API операционной системы. И в телефонии участники звонка (SIP Line, DECT Handset, FXS Port) предоставляют одинаковый интерфейс для звонков, их связывающих.

В итоге, если сравнивать телефонию с user space приложением, пользующимся драйвером устройства в операционной системе, наш Logic layer будет соответствовать приложению, Proxy layer — верхней половине драйвера, Vendor layer — нижней половине драйвера устройства, Library layer — Hardware Abstraction Layerоперационной системы.

Верхняя и нижняя половины драйвера могут взаимодействовать синхронно (верхняя половина вызывает метод нижней, нижняя — превращает вызов в команду по шине, блокирует вызывающий поток, ожидает ответ и возвращает результат ожидающему потоку) и асинхронно (обмен через очередь сообщений или мейлбокс). Синхронное управление называется Half-Sync/Half-Async [POSA2] и часто встречается в других областях, не критичных ко времени отклика. Например, оно описывает приложение, работающее с файлами или сокетами.

Обычные чтения или записи блокируют приложение (верхнюю половину), пока операционная система (нижняя половина) проводит много асинхронных действий и вернет результат. Асинхронное управление называется Half-Async/Half-Async [POSA2] и соответствует работе приложения с файлами или сокетами через polling/async IO. В этом случае приложение внутри синхронно (однопоточно), но с периферией (операционной системой), взаимодействует через неблокирующие команды и нотификации (колбеки + мейлбоксы). В результате один поток может параллельно обрабатывать много запросов (используется в высоконагруженном бэкенде).

Можно заметить, что название (и описание) системы зависит от того, как ее повернуть: разные диаграммы одного приложения выглядят как Adapterи как Layers; Half-Sync/Half-Asyncпри исключении нижнего слоя из рассмотрения превращается в Reactor, а Half-Async/Half-Async — в Proactor. Это свойство архитектуры, которая по сути есть набором удобных приемов и правил описания сложных систем. А что можно описать, то можно представить, смоделировать и в нужный момент применить.

Messaging

Важный компонент системы — обмен сообщениями между потоками. Рассмотрим, как это работает.

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

Если Actor сложный (содержит несколько объектов-получателей сообщений), для распределения сообщений между адресатами используется многоуровневый Visitor [GoF]. В результате получаем древовидную иерархию сообщений, каждое ветвление которой решается через Visitor:

Фрагмент иерархии сообщений

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

Итоги

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

Полезно почитать

[Devs] Alex Garland et al, Devs (2020).

[GoF] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software (1994).

[POSA2] Douglas C. Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann. Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects (2000).

Усім привіт, мене звати Микола. Два роки я працюю на позиції System Integration Engineer у компанії SoftServe, сертифікований Dell Boomi Architect. У цій статті пропоную розглянути платформу Dell Boomi. Якщо ви ще не ознайомлені з iPaaS-рішеннями, рекомендую прочитати статтюмого колеги Ярослава Клочника про те, для чого потрібні інтеграційні платформи, які їхні переваги та сфери застосування.

За той час, що працюю з платформою Dell Boomi, я реалізував близько 20 різних інтеграцій. Інтеграція відбувається з HCM (Human Capital Management), в якій люди звітують про свою роботу, планують робочі дні чи беруть лікарняні. Такою системою користуються багато клієнтів: супермаркети, авіакомпанії, готелі тощо. Окрім основного функціонала, вони ще хотіли б бачити звіти з агрегованими даними за відділами компанії. Або, наприклад, функцію, щоб певним працівникам додати додатковий вихідний. Таку логіку ми реалізовуємо саме через платформу Dell Boomi та клієнтські APIs, які дають змогу експортувати та імпортувати дані.

Згідно зі звітами, Gartner Dell Boomi вже 6 років поспіль один з лідерів на ринку iPaaS-рішень. З’ясуймо, чому він такий популярний.

Dell Boomi Platform — це ESB-based iPaaS-рішення, яке дає змогу інтегрувати дані та аплікації як у межах компанії in-the-cloud, так і з On-Premise. Однією з особливостей платформи є гнучкість та простота у підключенні до різноманітних систем. Boomi пропонує широкий спектр готових конекторів для інтеграції з AWS, Salesforce, Google Cloud, Microsoft Azure, NetSuite та інших, незалежно від того, чи це Cloud, чи On-Premise. Якщо навіть знадобиться створити кастомний конектор, така можливість є.

Якщо розглядати Dell Boomi з технічного погляду, все крутиться навколо атомів, у деяких випадках — молекул. Що ж це за хімія і навіщо вона використовується в інтеграціях?

Atoms, Molecules

Boomi пропонує хмарну інтеграційну платформу, яка підтримує дві моделі розгортання: Cloud — коли всі endpoints містяться в хмарі, та On-Premis — якщо хоча б одна з integration endpoints міститься в межах корпоративної мережі. Під час використання хмарної моделі всі інтеграційні процеси можуть бути розгорнуті на Boomi Atom Cloud. Щоб забезпечити модель On-Premise, Boomi пропонує Atom — по суті розгорнуту Java-аплікацію.

Якщо, використовуючи On-Premise, ви хочете досягнути високодоступного та load balanced рішення, то в пригоді стане концепція Molecule.

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

1. Local Atom. Якщо потрібно отримати доступ до даних, що містяться поза фаєрволом, тоді цей тип вам підходить. Я завжди працюю з локальними атомами на своїх проєктах.
2. Cloud Atom. Якщо всі потрібні дані розміщені зовні, Cloud Atom буде оптимальним рішенням. Це спрощує обслуговування атома, бо цим займається дата-центр Dell Boomi.

Atom

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

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

Forked Execution

Розподілене виконання є за замовчуванням активним в Atom Cloud, також це можна опційно активувати в Molecule. Це дає змогу виконувати кожен процес в окремій JVM. Завдяки цьому нода є більш стійкою, бо катастрофічні збої, які відбуваються з іншими процесами, не вплинуть на її виконання.

Принцип роботи Molecule

Environments

Всі молекули та їхні частини — атоми — існують в певному середовищі. Dell Boomi використав такий самий підхід: чи це Local Atom, чи Cloud Atom або Molecule — всі вони закріплені за певним середовищем. У платформі Dell Boomi вони можуть давати такі переваги:

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

Batch vs Real-Time Processing

Dell Boomi пропонує два типи виконання інтеграцій: Batch та Real-Time. Розгляньмо, яка між ними різниця.

Batch Processing.У цьому випадку Boomi буде запускати інтеграцію за певним інтервалом — від хвилини до річного кварталу. Ви можете це контролювати відповідно до потреб.

Real-Time Processing. Boomi також обробляє запити в режимі реального часу. Це допомагає перетворити процес в listeners, які очікують на тригер. Щойно тригер спрацьовує, починається інтеграція. Майже всі мої інтеграції — це Real-Time Processing. Вони реагують на клік кнопки в системі, зв’язаній з Dell Boomi.

Platform components

Для циклу розробки інтеграційних рішень (розробка, розгортання, тестування та підтримки) Dell Boomi пропонує три основні компоненти:

• Build
• Deploy
• Manage

Розберімо кожну з них детальніше та сферу їх використання.

Build

Boomi використовує концепт Build для організації та контролю обробки даних. Щоб інтегрувати аплікації безпосередньо з вебу, Dell Boomi застосовує вбудований візуальний інтерфейс (visual designer), де користувачі створюють process flow.

У Build ви можете:

• створити, редагувати та видаляти компоненти;
• будувати інтеграційні процеси;
• налаштувати Atom або Molecule (що це таке, я розповім трохи згодом);
• користуватись бібліотекою готових інтеграцій Dell Boomi User Guide.

Build tab

Deploy

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

1. Packaged Components дає змогу створювати та керувати пакетами для процесів і компонентів, які ви створили.
2. Deployments допомагає моніторити наявні розгортання та створювати нові.
3. Integration Packs дає змогу користувачам розгортати або встановлювати інтеграції, спільні для їхнього облікового запису.

Корисна функція, якою я часто користуюсь, — Copy Deployment. Вона дає змогу перенести версію з одного атома на іншій в кілька кліків.

Manage

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

• Process Reporting
• Atom Management
• Cloud Management (якщо це дозволено у вашому акаунті)
• Boomi Assure (якщо це дозволено у вашому акаунті)
• Process Library (якщо це дозволено у вашому акаунті)
• Integration Packs (якщо це дозволено у вашому акаунті)
• Trading Partner Management (якщо це активно у вашому акаунті)

Process Reporting

Component locking

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

Subprocesses

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

Compare Deployments

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

Недоліки

Варто згадати й про недоліки, з якими мені доводилось стикатись:

• Boomi — це документоорієнтована платформа, часто дані в документах потрібно посортувати за однією чи кількома колонками, а готового функціоналу для цього нема. І потрібно писати скрипт на Groovy або JavaScript.
• Нема циклів. Щоб прогнати певні алгоритми роботи кілька разів, треба писати шматок логіки з блоків платформи.
• Не можна стандартно вивантажити всі дані з CRT. У Boomi є таке поняття, як Cross Reference Tables. Це таблиці, які використовують, щоб, наприклад, за значеннями у двох колонках знайти значення третьої. На моїх проєктах буває, що потрібно всі значення з певної колонки додати в API-запит. Для цього треба додавати ще одну колонку з інкрементним значенням і циклом вивантажувати ці значення по одному.
• Іноді складно виправляти помилки виконання інтеграцій. Особливо коли ми працюємо в тестовому режимі з великим обсягом даних. Boomi обрізає логи, і нам потрібно запускати інтеграцію частинами даних у тестовому режимі, щоб знайти реальну помилку.

Підсумовуючи все написане, я не агітуватиму використовувати цю платформу. Але хотів би, щоб ви звернули увагу на iPaaS-рішення і Dell Boomi під час вибору технологічного стека, враховуючи ті переваги та недоліки, які вона пропонує.

Якщо вирішили спробувати Dell Boomi

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

Якщо хочете докладніше ознайомитись з корисними функціями Dell Boomi та самою платформою, переходьте за посиланнями:

• Dell Boomi
• Component locking
• Deployment
• Training and Certification

А также: работа с Sandwich, Firebase Kotlin, Android Bluetooth Low Energy, автоматизация рабочих процессов с помощью GitHub Actions.

Этот дайджест написан в соавторстве с Сергеем Жуком.

Новости и аналитика

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

Android Studio 4.0 — новый редактор Motion Editor, Build Analyzer для расследования причин более медленных сборок и языковые API-интерфейсы Java 8, которые вы можете использовать независимо от минимального уровня API вашего приложения.

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

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

Kotlin

Расширения Firebase Kotlinвышли из бета-версии! Если вы разработчик Firebase и используете Kotlin — не упустите полезный материал.

Kotlin 1.4-M2 — изменения в существующем API, такие как обновление подписей и введение новых констант, больше функций в общей библиотеке и новые функции для массивов и коллекций.

MVI — это идеальный шаблондля использования при использовании Kotlin Multi-Platform. Правда это или нет — решать вам, но можете проверить это по ссылке by Arkadii Ivanov.

Kotlin — Firebase + MVVMили о том, как написать мультиплатформенное приложение на Kotlin, которое взаимодействует с Firebase by Javier Arroyo.

Для новичков и не только. Практическом примеры работыс потоками, фоновой обработке и, конечно же, корутины Kotlin by Animesh Roy.

Trending patterns and Frameworks

Руководство по Android Bluetooth Low Energy, а также реальные примеры распространенных операций BLE, таких как сканирование, подключение, чтение, запись и настройка показаний или уведомлений by Chee Yi Ong.

Почему использование ViewModels в Android Jetpackявляется отличным подходом для отделения бизнес-логики от операций / фрагментов by Bevan Steele.

Сравнение того, как выглядит биометрический входв Pixel 4, Pixel 3 и эмуляторе API 26а by Sam Edwards.

Создание «конвейера DevOps»или сравнение онлайн-сервисов непрерывной интеграции, которые можно использовать для мобильных приложений by Peter-John Welcome.

Когда и как использовать внутренний общий доступдля закрытого тестирования приложений в Google Play или Firebase App Distribution by Peter-John Welcome.

Сравнение Kotlin Flow и RxJava.Правда ли, что Kotlin Coroutines Flow имеет больше преимуществ? Ответ в статье by Antoni Castejón García.

Как построить структуру сети и обрабатывать данные об ошибках, полученные из ответов? Это возможно сделать с помощью новой библиотеки Sandwichby Jaewoong Eum.

Почитать/посмотреть/попробовать

GitHub Actions — это новинка в автоматизации рабочих процессов. Руководство о базовых настройках того, как выполнять некоторые проверки и тесты Android-проекта by António Valente.

Ориентация, связывание и вставки — статья о том, как ваше Android-приложение будет работать на Surface Duo by Meir Ben Itay.

При использовании шаблоны чистой архитектуры иногда могут возникнуть проблемы с обработкой ошибок. В статье автор наводит хорошие примеры, как с этим справиться by Duy Phạm

Как просто добавить восхитительную анимацию в приложение? Прекрасным вариантом для этого является библиотека Lottie by Bevan Steele.

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

Простой AlertDialog имеет множество скрытых функций, с которыми и познакомит вас эта статья by tomerpacific.

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

MarvelHeroes — пример приложения Marvel heroes на основе архитектуры MVVM (ViewModel, Coroutines, LiveData, Room, Repository, Koin).

Android-lints — пользовательский набор правил Android Lint.

Decorator — это библиотека Android, которая помогает создавать комбинируемые поля и разделители в RecyclerViews.

gradle-static-analysis-plugin — простая и последовательная настройка инструментов статического анализа для Android и Java проектов.

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

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

Ілюстрація Уляни Патоки

Став редактором корпоративної дитячої книжки, щоб колеги-батьки мали чим зайняти своїх дітей

Михайло Зінченко, Team Lead, Wargaming

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

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

А найбільшим особистим (та й геймерським) досягненням під час карантину вважаю першу здобуту «платину» в PSN, у грі Assassin’s Creed Odyssey. Платиновий трофей вручають за здобуття всіх-всіх-всіх трофеїв, включаючи досить рідкісні. Зазвичай на схоже ніколи немає часу, але карантин диктує свої правила гри. Останнім для мене виявилось досягнення Stink Eye, де треба було, скажімо, дістати око Циклопа з кози. Тільки не питайте, як око потрапило до кози — краще пограйте самі, а ось саму козу довелося шукати по всій Кефалонії. А я трохи шкодую, що свого часу ознайомлювався з грецькою історію та міфологією не настільки інтерактивно.

Написал Android-приложение для ухода за растениями

Дмитрий Чеботарский, Senior Software Engineer в TomTom

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

Во время карантина появилось свободное время, и я, вооружившись терпением, выбрал новый для меня язык программирования Kotlin и начал разрабатывать приложение Waterly. Разработку начал в первых числах марта, уделял 3-5часов каждый день после основной работы. 9 апреля выложил первую версию приложения в Google Play. После этого продолжил исправлять ошибки и добавлять новые функции.

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

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

Разом із сином вчиться писати ігри на Unity

Олег Шанковський, Java developer в US company in Kyiv

Мій робочий день починається об 11:00. Уже протягом місяця я разом із 13-річнимсином встаємо о 8:30, снідаємо й з 9-їдо 11-ївчимося писати ігри на Unity. Купили кілька курсів на Udemy, зараз проходимо другий — максимально детальний курс на 80 годин. Синові цікаво, матеріал дається легко. На курсах лектори говорять англійською, що дає додатковий бенефіт.

Плануємо продовжувати вчитися, досягти рівня впевнених юніті-програмістів і публікувати ігри на майданчиках типу Google Play, Steam тощо. Маємо вже певну кількість готових аркад, 2D-стрілялок, які поки не публікували, оскільки вони написані в межах курсів, а не є результатами наших ідей. Можливо, програмування на Unity стане майбутньою професією сина.

Сделал «тихий» компьютер

Сергей Пирогов, QA Lead, EPAM

Шум — одна из проблем, на которую мы обращаем мало внимания. До наступления карантина я работал на домашнем компьютере от силы 2-3часа в неделю и не ощущал дискомфорта. Сейчас я работаю из дома, и в качестве основного компьютера у меня системник и два монитора. С того момента, как начал проводить за системой много времени, столкнулся с проблемой сильного шума. На тот момент на вдув и выдув у меня стояли 2 кулера 120 мм Be Quiet silent wings 3, башенный кулер ноунейм Vinga и Vinga блок питания на 500 Вт. Еще присутствовала видеокарта GeForce 1050TI. Насколько шумным был мой компьютер, слышно на этом видео:

Я понял, что шумит кулер видеокарты, покопался в настройках, твиках, и оказалось, что именно в этой серии видеокарты нельзя сбросить обороты кулера меньше 30%. Я решил поменять карту и поставил NVIDIA GeForce GTX 1650. Она поддерживает пассивный режим (кулеры не крутятся, если температура нагрева карты ниже 60 градусов). Стало получше, но как только я убрал шумный элемент, вскрылись новые шумные части. На этот раз — башенный кулер процессора. Я долго читал форумы, советовался с диванными экспертами и решил заменить кулер Vinga на Noctua NF-P12 PWM для башни процессора и двух Noctua NF-S12B redux-1200 для корпуса.

После этих манипуляций системный блок стал работать намного тише, но на фоне тишины оставался достаточно неприятный шелест блока питания. Полечить проблемы простой заменой кулера не получилось из-за того, что там была китайщина на 2pin. Я долго сопротивлялся, но все же купил новый блок питания be quiet! Pure Power 11 600W CM.

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

Зібрала допомогу для лікарів завдяки онлайн-барахолці

Яна Стовбур, HR Marketing manager, GBKSOFT

Під час карантину провела у телеграм-каналіонлайн-барахолку. Спочатку долучались лише мої друзі — продавали свої картини та handmade вироби, але завдяки 72 репостам аудиторія розрослась. Барахолка тривала з 7 по 28 квітня, за цей час свої лоти виставила 31 людина, всього вийшло 52 пропозиції. Покупці придбали 16 лотів, загалом ми зібрали 17 745 гривень. На ці кошти разом з друзями закупили костюми, бахіли, маски, дезінфектори, фартухи та халати для лікарів Запорізької обласної лікарні.

Крім цього, купила укулеле та освоїла кілька акордів. Зараз є виклик зіграти Over the rainbow. Проходжу курс для HRів і вже перебуваю на екваторі. Виявляється, навчатись у 30 років цікавіше й дорожче, ніж у 17. Переглянула 14 серіалів, багато з яких дуже раджу: від Unorthodox і Mindhunter до Devs і Fleabag. А ще віддалено навчила маму користуватись Zoom.

Почав вивчати C# й написав утиліту для Docker

Богдан Пархоменко, PHP Developer, Agiliway

Кілька років я працюю PHP-розробником, нещодавно спробував себе у ролі тімліда. Та останнім часом розумію, що PHP мені все менш цікава, тож почав придивлятись до інших. Я дуже люблю Windows й кілька років тому цікавився C#. На карантині з’явилося багато вільного часу, взявся вивчати його глибше. Програмки типу «Привіт, світ!» не хотілось писати, але з’явилась ідея утиліти для Docker.

Знання здобував на YouTube-каналах англомовних розробників і ресурсі Metanit. На початку карантину я втратив роботу й приблизно чотири дні, поки тривали пошуки, міг присвячувати по 8-12годин навчанню. Нову роботу знайшов швидко й у середньому приділяв 4-5годин на день C#. За місяць написав дві утиліти. Перша — найпростіший менеджер для Docker-контейнерів, публікувати у публічному просторі її не став.

Друга ідея виникла з мого досвіду у PHP. Є така російська утиліта — OpenServer. Вона допомагає швидко розгорнути середовище для написання нового проєкту. Я вважаю, що вона трошки застаріла, і вирішив зробити схожу програму тільки вже на базі Docker-контейнера.

Я запустив сайтдля утиліти, там є невеличка документація англійською мовою, принцип роботи й лінки для завантаження. Опублікував цей сайт на DOU, закинув у LinkedIn, Хабр Q&A, Stack Overflow і Medium.

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

Прочитал 4 книги по менеджменту

Сергей Иванюк, Team Lead Web-отдела, Appus Studio

Еще до карантина у меня началась стажировка на позицию Team Lead Web-отдела. Опыта работы на аналогичной должности не было, я понял, что мне нужно развивать soft skills. Когда начался карантин, я остался без возможности практиковаться вживую с командой — мы перешли на удаленку. Я решил извлечь максимум пользы в этой ситуации и подтянуть свои навыки по менеджменту с помощью литературы.

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

Список наиболее полезных и интересных из них:

1. «Deadline. Роман об управлении проектами» Т. Демарко.
2. «Пять пороков команды. Притчи о лидерстве» П. Ленсиони.
3. «Почему не все любят ходить на работу. Правда о вовлеченности сотрудников» П. Ленсиони.
4. «Scrum. Революционный метод управления проектами» Д. Сазерленд.

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

Створив на Android додаток-агрегатор українськомовних технічних новин

Ярослав Гаврилович, Senior Software Engineer у HekuIT

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

Я довго думав над ідеєю проєкту й вирішив створити щось, що я б і сам використовував. Увагу звернув на те, що протягом дня я постійно перемикаюсь між ресурсами, щоб читати українськомовні технічні новини: DOU, Codeguida, Tokar, Pingvin. Так придумав написати агрегатор технічних новин з українськомовних ресурсів.

Перші напрацювання були в лютому, але стабільна версія, яка має весь функціонал, з’явилася у квітні, оскільки на карантині я мав багато часу. Проєкт розробляв паралельно з основною роботою в HekuIT. На час карантину перебрався за місто й міг виділяти 3-4години на день. Ще й залишався час на спорт. У вихідні працював над застосунком до 6-8 годин.Що вийшло, можете подивитись на Google Play.

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

Розробив сервіс із вивчення англійської мови

Владислав Лєсной, Go developer, DataArt Dnipro

У 2018 році я брав участь у Global Hack Weekend з ідеєю сервісу вивчення англійської мови через матеріали, які обирає сам користувач. Це здається мені максимально близьким до того, як вивчають мову native-спікери: більшість слів уже відома (близько 95%), а нові слова вчаться із контексту природним чином. Після того я обдумував усе, аналізував отриманий фідбек, але часу на реалізацію не було аж до березня 2020-го.

Перший коміт у репозиторій зробив 1 березня. Карантин насправді не додав часу, але дав мотивацію. Багато хто кинувся навчатися, проходити курси, вчити мови, і я зрозумів, що такий сервіс зараз буде актуальним. Я виділяв час на проєкт щоранку — десь 2-3години й у вихідні. За 3 місяці вийшло приблизно 200-250 годин,або півтора робочого місяця. Зі створенням сервісу допоміг мій колега Антон — Junior developer, який за цей час досить добре вивчив Go та VueJS (технології, на яких зроблений проєкт).

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

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

Допомагає сину-восьмикласнику опанувати шкільну програму

Олексій Мельниченко, Senior Drupal Dev в MaiaLearning, Inc.

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

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

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

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

Створив професійний контент на YouTube

Роман Якимчук, Senior QA/QA Lead Trinetix, QA Consultant в Roman Yakymchuk Consulting

З березня я почав проводити «Посиденьĸи про Quality Assurance» на YouTube. Вони відбуваються один-два рази на тиждень у вигляді балачок про досвід різних людей зі сфери тестування. Я завжди любив біографічні інтерв’ю з різними людьми, це зацікавлює та надихає.

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

Серед планів — залучити до підписників YouTube-каналу всіх QA з Уĸраїни, моя мета — розвивати саме уĸраїнсьĸу спільноту й робити тестування більш яĸісним і різноманітним. Хочеться розповідати людям про реальне життя тестувальниĸів: яĸ вони борються з проблемами на проєĸтах, яĸ придумують «велосипеди», як оптимізують старі процеси.

Прошел 15 IT-курсов

Алексей Оголенко, Microsoft DevOps Engineer, innovations development group

Требования в IT-сфере растут, поэтому приходится постоянно изучать новые материалы, чтобы соответствовать. Я начал более активно изучать направление DevOps с конца февраля после того, как понял, что современному рынку труда уже не нужны обычные инженеры по Microsoft-технологиям.

В основном изучаю материалы по облачным технологиям Azure, хочу подготовиться к экзамену Microsoft Azure DevOps (AZ-400). Для этого использовал различные ресурсы: LinkedIn academy, Udemu, Cloud Academy, Pluralsight, WithLabs, Microsoft learn. В день старался уделять от часу до трех часов изучению новых материалов, хотя загрузка по работе не всегда давала возможность отвлечься на учебу. Всего удалось пройти около 15 курсов за 2 месяца.

Хочется выделить те, которые мне понравились больше всего:

• Prepare for Microsoft Azure Administrator Certification (AZ-103);
• Linux Foundation Certified System Administrator (LFCS);
• Azure DevOps.

22 мая сдал экзамен Microsoft Azure Administrator (AZ-103). На данный момент готовлюсь к сдаче экзамена по Microsoft Azure DevOps Solutions (AZ-400), надеюсь подтвердить приобретенные знания через 1,5-2 месяца.Впереди громадный список того, что еще предстоит изучить. Это Kubernetes, TeamCity, Ansible, Puppet, Terraform и множество других интересных технологий.

Щороку навесні ми складали портрет українського айтішника, а на початку літа запускали зарплатне опитування. Цього року коронавірус і карантин внесли свої корективи — портрета навесні не було. Ми вирішили об’єднати два великих опитування в одне і зібрати якомога більше анкет.

Приділіть 7 хвилин і візьміть участь в опитуванні.

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

Результати опублікуємо у липні. Підсумки попередніх опитувань: портрет, зарплатні звітиабо віджет.

Усі питання, пропозиції та побажання щодо опитування можна залишати в коментарях до цього посту або надсилати поштою на vlada@dou.ua.

Поїхали! Заповнити анкету