[«Fail review» — это сборник историй о рабочих провалах: что произошло, как исправляли и какие выводы сделали. Если есть, чем поделиться — присылайте свои истории на editors@dou.ua]

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

Сергей Сыроватченко, SQL Server DBA

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

Пока коллега собирал вещи, у меня с финдиректором вышел весьма забавный диалог:

— Ты базы данных знаешь?
— Нет.
— Выучи за ночь. Завтра как мидла базиста тебя клиенту буду впаривать.

Именно так и началось мое знакомство с SQL Server. Все было новое, непонятное и чаще всего делалось по методу проб и ошибок. Очень не хватало толкового человека рядом, на которого мог бы равняться.

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

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

Попалась на глаза вакансия от агентства. Искали для себя разработчика со знанием .NET и SQL Server, чтобы сделать новую CRM систему по работе с клиентами. Их офис был в центре, но за день до собеседования попросили приехать в другой район. Аргументация была простая — их техлид сейчас работает на Залютино (прим. ред. — окраина Харькова)и собеседовать ему удобнее там. Для тех, кто из Харькова, — думаю, вы понимаете, какое это дно для офисного планктона. Текущая работа сильно пригрузила, и очень хотелось перемен, так что я все-таки рискнул.

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

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

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

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

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

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

Практически дословно:

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

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

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

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

Николай Рожков, DevOps Engineer

Первый случай назовем «А что я здесь делаю?». Однажды у меня закрутило в одном месте желание что-то изменить. В тот момент я был разочарован в текущем месте работы, и хотелось чего-то большего. Под руку попалось объявление о поиске админа в Ukr.net. Пожалуй, еще одним фактором было то, что их офис на Леонтовича, именно в том легендарном месте зарождения украинского интернета, сети обмена трафиком и трех широкополосных магистралей на Франкфурт.

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

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

— Для начала реши математическую задачку.

И тут я, удивляясь самому себе, ответил:

— Я не считаю, что нам стоит продолжать. До свиданья.

Дядька опешил (правда, я тоже был немного шокирован) и начал брать меня на слабо:

— И что, даже не попытаешься?

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

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

И вторая история, — скорее, курьез «Как я провтыкал работу мечты».

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

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

В назначенный час я ожидаю в скайпе, проглотив швабру и пырясь краем глаза в камеру, не выгляжу ли я как полный осёл. Я списываюсь с представителем компании, и тут он говорит: «Сорри, а мы можем перескочить в другую программу, потому что у меня скайп заглючил?». Скидывает ссылку, я думаю: «Так, надо быренько поставить», — забывая о том, что ее плагин не работает в Сафари. Ставлю там — нифига, ставлю в Хром, перезагрузка. Мысленно при этом машу рукой: «Прощай, работа мечты». Спустя 20 минут мучений мы созваниваемся, я заплетающимся языком чет говорю, натужно прощаемся, он кладет трубку.

В это время входит сестра:

— Ну как собеседование?
— Просрал.

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

Георгий Олейников, Full-Stack Developer

Первое мое собеседование было провальным. Я тогда учился в Канаде (в 2012 году). Хотел летом пойти в интернатуру, потому что денег у меня было в обрез, а там платили. Компания, которая первой мне попалась, — Fog Creek Software, ее основатель позже создал StackOverflow. Я страшно волновался, потому что у них на сайте было написано, что интерны получают пять тысяч долларов в месяц. У меня от таких сумм чуть глаза не повылазили. И я подумал: «Неужели такое бывает? Счастье — вот оно». Но меня туда не взяли. На собеседованиях по ту сторону океана спрашивают алгоритмические задачки. Нужно что-то в прямом эфире написать, какой-то код, самый простейший. А я, как человек, пришедший в IT из математики, вообще этих алгоритмов не знал. Я расстроился, потому что пять тысяч долларов остались не при мне.

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

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

— Вы знаете, все-таки эту задачу надо решать динамическим программированием.
— Да, и как же?
— Ммм.... Ну ладно...

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

После учебы я пошел работать в Amazon, а через три года вернулся в Харьков. Думаю, надо искать работу в Украине. Решил поискать в Киеве, все же столица. Первое собеседование было в Luxoft. Это было совершенно провальное собеседование по Java. В «Амазоне» я три года программировал на Java, вроде как там разобрался во всем. Но на собеседовании что ни спросят — ни на один вопрос ответить не могу. Они задают вопрос про какой-то фреймворк, а я им: «Впервые слышу».

Потом они задали мне вообще классический вопрос: «Какие есть методы класса Object?». Я не думал, что у меня когда-нибудь в жизни такое спросят. Видел это в интернете и всегда смеялся. Для контекста — из класса Object наследуются все остальные объекты, и у него, конечно, есть некоторые стандартные методы, и любой вменяемый программист на джаве вспомнит несколько. Но меня этот вопрос застал врасплох. Говорю: «Ну, не знаю, какие, какие-то есть, надо бы загуглить. Я помню парочку, но полный список не назову».

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

Еще существует такая проблема: когда сидишь в большой компании, помимо основного языка программирования, ты еще знаешь определенный набор инструментов, с которым работаешь. Их целая куча. О них никто не знает, кроме твоих коллег. Ты выходишь из компании (Amazon была моя первая работа) и думаешь: «Что в мире происходит, какой-то JavaEE, чего?». Ничего этого я не знал. И, конечно, это, наверно, повергло интервьюера в шок.

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

Кирилл Черных, MS SQL Server DBA/DB Developer

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

В одно прекрасное утро (это был четвертый день поисков, помню как сейчас) раздался звонок, и меня пригласили на собеседование в одну небольшую компанию, назначив собес на вечер этого же дня. Честно сказать, особого желания идти туда не было, но согласился. Прибыв, я набрал Алексея, ПМа, который привел меня в комнату к СЕО — Евгению.

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

После этой хвалебной оды Евгения самому себе, в разговор вступил Алексей. Рассказал о проектах (на тот момент было два, тестировать нужно оба по очереди), о командах. И плавно перешли к моим знаниям в предметной области. И тут Евгений достает распечатанный текст на листе формата А4 и начинает задавать вопросы с этого листа (список вопросов был похож на «что спросить на собеседовании у тестировщика»). Я ответил на все из них (сам был удивлен этому факту) и решил спросить:

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

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

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

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

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

Артем Быковец, Agile Coach & ScrumMaster

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

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

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

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

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

Чувак просто теряется, он не в состоянии вспомнить. Я вижу, у него начинает проступать такая троллиная улыбка в стиле: «Блин, вот это я вляпался». Смотрю на НR, говорю: «Ну что?». Они такие: «Ну ладно, ладно».

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

Это не единственный пример, порой были другие прикольные штуки. Когда в резюме у человека были написаны чуть ли не все языки программирования через запятую, все базворды, которые можно встретить в описаниях вакансий. При том он идет на интерн-тестировщика в большой аутсорсинг. Говоришь:
— А зачем тебе эти все слова в резюме или чего тогда на интер мануал тестировщика?
— Ну я все это учил, старался.
— Окей, хорошо, давай по порядку. Что такое http?
— Ну это интернет. (*Мм, отличный уровень познания*)
— Хорошо, а у тебя написано html, XML — это что?
— html — это веб-страница.
— Хорошо, а XML?
— Ну я там...мм...

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

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

Резюме на восемь страниц! Мы сначала думали, что это какое-то вложение портфолийное распечатано вместе с CV, потому так много страниц. Потом присмотрелись и поняли, что нет :) Это настолько детально описана каждая позиция, проект, технологии...

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

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

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

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

Я говорю: «Вроде бы суммарно я там три часа провел. Я не знаю, как у тебя, но у меня впечатление, будто я пошел радио послушал, а не собеседовал».

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

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

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

И вот спустя где-то три года после этого, когда мы искали Senior QA Automation инженера, ко мне приходит наш QA Lead и говорит: «Вот еще один кандидат». Я смотрю резюме и узнаю моего старого доброго друга. Говорю:
— Елки ты палки, как в жизни повезло. Я сильно предвзятый, давайте я сразу не пойду его собеседовать.
— Так, может, сразу ему откажем?
— Нет, мне реально интересно, может, он очень крутой. Тем более, людям свойственно взрослеть, он был молодой, ему было там года 21, может, плюс-минус, всякое бывает, глупости делаем все.

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

Мы спросили:
— Ок, почему ты считаешь, что это твое?
— Ну как, потому что я — крутой инженер, а не манки тестер.
Я говорю:
— Да, я в курсе, ты там сайты взламываешь на Drupal, умеешь гуглить уязвимости. Ладно, расскажи тогда, как работает авторизация в http, как и для чего работают кеш, куки? Ответы последовали из серии: «Куки и кеш — это временное хранилище данных». Я говорю:
— Ну, а как это устроено?
— Я никогда не заморачивался, как это устроено. Мне это не надо, чтобы тесты писать.
— Ок, здорово, а что ты знаешь про тестирование АРІ?
— Я не тестировал АРІ, потому что у меня галимая команда, компания, мне там не дают этим заниматься, но я очень хочу, поэтому я точно ухожу.

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

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

Он говорит:
— А-а-а, наверное, Чернигов.
— Да-да, точно Чернигов. У меня там есть знакомый, я у него останавливалась.
— А как его зовут?

Оказалось, что она два года назад была в Чернигове, останавливалась у его родного брата. Тесен мир не только в украинском IT, он вообще очень тесен. И перед тем, как кому-то куда-то нагадить, надо дважды подумать, стоит ли это того.

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

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

Эта статья посвящена самому, как мне кажется, распространенному и опасному заблуждению, связанному с этим инструментом. Подавляющее большинство людей, которым я задавал вопрос «Кто определяет Definition of Done?», отвечали на первых секундах: «Клиент».

Минутка матчасти

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

Например:

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

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

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

Кому это нужно

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

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

Сферический конь в вакууме

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

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

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

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

Ближе к делу

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

Обратите внимание, Клиент не ориентируется в 50 оттенках серого от «уже сделал локально» и «залил в dev, но еще не проверили» до «прошли все тесты на stage». Не ориентируется совсем и воспринимает фразу «Функционал готов» самым буквальным образом — готов быть залитым в живой production.

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

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

Необходимых с чьей точки зрения?

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

Клиента! Но ведь Клиент — единственное причастное к разработке Продукта лицо, которое не знает, как разрабатывается программное обеспечение! Зачем у него спрашивать, и уж тем более, зачем у него спрашивать разрешения правильно делать работу Команды? В этом нет никакого бизнеса, это технология!

Естественно, не менее абсурдно выглядят и попытки Клиента ускорить разработку за счет «выставки народной резни» по качеству вообще и Definition of Done в частности: «А без юнит-тестов?», «А зачем мы тратим время на ревью?», «Зачем документация по API?», «Не рассказывайте сказки, я сам в 1812 году работал с перфокартами» и так далее.

Представьте, что к каменщику, которого наняли строить и который между рядами кирпичей кладет или ложит раствор, подходит Заказчик и говорит: «Слушай, мужик, зачем ты тратишь свое время и мои деньги на это месиво? Нельзя просто положить кирпич на кирпич, а раствора туда иногда для запаха между каждым десятым и каждым одиннадцатым рядом?!»

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

Кто виноват и что делать

Во-первых, Definition of Done должно быть. Причем даже если Команда не одна, а N, оно должно быть одно на всех.

Потому что если ваш цех по производству Kotlin-пасочек станет хронически обгонять цех RxSwift-пасочек по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении с Клиентом.

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

Позволю себе привести формулу для расчета количества Definition of Done в зависимости от количества команд:

NDoD = 1 ^NT

где NDoD — количество Definition of Done,
NT — количество Команд

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

После титров

И в завершение позволю себе пару небольших ремарок.

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

И нет, я не считаю, что это легко — не позволять Клиенту диктовать Definition of Done. Это трудно. Но если мы считаем себя профессионалами, подход должен быть профессиональным.

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

Спасибо, буду крайне признателен за комментарии.

Наша команда поддержки пользователей работает с 10 проектами Plarium Kharkiv, обрабатывает около 1 300 обращений в день и общается с игроками на 9 языках, включая японский и корейский. Чтобы улучшить пользовательский опыт, мы регулярно анализируем работу департамента и по возможности оптимизируем процессы.

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

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

Ответы игрокам на иностранном языке

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

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

Довольно быстро я нашел книгу Google Apps Script: Web Application Development Essentials. В ней рассказывается о возможностях автоматизации работы с таблицами, документами и другими сервисами Google.

Затем важно было понять, как Zendesk (программа, которую мы используем для работы с игроками) может обрабатывать данные со своей стороны. Благо, проблем с этим не возникло: у Zendesk довольно широкий API, который позволяет получить доступ практически ко всем функциональностям. Он дает возможность разрабатывать кастомные приложения и интегрировать их в свой софт. И, что немаловажно, на официальном портале можно найти много хороших уроков для начинающих.

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

Флоу агента до автоматизации

После автоматизации агенту нужно только разобраться в ситуации и написать ответ на английском в Zendesk. Остальное сделает скрипт.

Флоу после автоматизации

В итоге большая часть процесса выполняется программно. Рассмотрим его подробнее.

Для автоматического перевода запросов на английский мы используем Google Translate. На данном этапе нам очень помогает Zendesk с его встроенными функциями.

Каждый раз, когда игрок создает или обновляет тикет в Zendesk, срабатывает триггер, который отправляет соответствующий http-запрос в Google Apps Script с номером тикета и текстом, который нужно перевести. После перевода мы возвращаем сообщение обратно в тикет (через Zendesk API) в виде приватного комментария (доступен для просмотра только агентам). Весь процесс занимает считанные секунды.

Скрипт, который выполняет функцию перевода

function doGet(e) — функция получает URL от Zendesk и парсит его, выделяя ticket ID (e.parameter.id), текст, который необходимо перевести (comment = e.parameter.comment), и язык, с которого нужно переводить (locale = e.parameter.locale).

function translateComment (comment, locale) — функция делает перевод с соответствующего языка на английский, используя Google Language service.

function sendTranslatedComment (ticketId, locale, translated) — функция получает переведенный текст и отправляет его назад в Zendesk с помощью Zendesk API Tickets End Point.

Агент видит сообщение от игрока в Zendesk в таком виде:

Далее агент проверяет ситуацию, готовит ответ на английском и оставляет его заметкой к тикету с хештегом #to translate.

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

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

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

Игрок получает персонализированный ответ в следующем виде:

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

Процесс коммуникации (Slack Messenger)

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

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

Изначально флоу агентов состоял из таких шагов:

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

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

Если игрок задает вопрос, связанный с разработкой, или сообщает о возможном баге, агент вносит текст сообщения в форму, выбирает тип запроса (Question или Bug Report), выбирает из списка канал по проекту и нажимает «Отправить».

После этого происходит несколько параллельных действий.

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

Так выглядит сообщение в Slack с типом Bug Report:

Так выглядит сообщение в Slack с типом Question:

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

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

Результаты

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

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

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

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

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

Антон Романьков, FullStack JS developer

Radio T — когда я начинал свой путь в IT, подкаст позволил мне «подслушать» диалоги профессионалов и прикоснуться к IT-тусовке. Иногда можно услышать детальный разбор новой технологии, архитектурного подхода или обнаруженную дыру в безопасности данных. Туда также заходят интересные гости, с которыми устраивают технические дебаты. Обсуждения написания кода, инструментов для разработки и вечные споры о том, как лучше писать код.

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

Дмитрий Маленко, CTO в rollApp

Exponent — Ben Thomson (автор stratechery.com) и James Allworth глубоко раскапывают причины событий, происходящих в high-tech, а также их неочевидные последствия для бизнеса и общества. Этот подкаст не про мегапиксели в смартфонах, а про то, например, почему прямолинейная законодательная регуляция Facebook, скорее всего, лишь укрепит его положение.

Accidental Tech Podcast — три Apple-гика, три веселых друга обсуждают новости IT, технологии и иногда автомобили. Всегда интересно слушать умных людей, которые имеют свою точку зрения и умеют ее обосновать.

99% Invisible — документальный подкаст, в котором рассказывают о неординарных историях обычных и необычных вещей. Например, был выпуск о том, как Генри Форд построил утопический город-завод в амазонских джунглях и почему у него не получилось.

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

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

Сергей Пирогов, QA Automation consultant

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

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

The Art of Programming — подкаст, который я слушаю выборочно. Автор комбинирует форматы от соло до интервью с интересным гостем. Выпуски редко бывают дольше 1 часа, поэтому удобно слушать без перерывов по пути на работу.

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

Talk Python to me — англоязычный подкаст про Python и все, что с ним связано. Я слушаю эпизоды выборочно. Помогает погрузиться в чуждый джависту мир Python и немного прокачивает восприятие английской речи. Рекомендую всем, кто работает с Python и крутится в этой экосистеме.

Сергей Бутенко, Cocoa Engineer в MacPaw

Один из моих любимых подкастов — это небезызвестный Радио-Т. Благодаря ему я узнал о множестве вещей, с которыми я, как iOS\macOS разработчик, вряд ли бы столкнулся. А теперь я в курсе, что это и как это работает (тот же Docker). К тому же это еще и развлекательное шоу.

Еще один подкаст, из которого можно почерпнуть много интересного как технически, так и не технически — The Art Of Programming. Часто записывают людей из разных областей — HR, Java, Web и так далее. Всегда интересно узнать, как ребята из других сфер решают похожие проблемы и какие есть неочевидные ограничения и особенности платформ.

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

Владимир Агафонкин, Lead JavaScript Engineer at Mapbox

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

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

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

Я в IT последние пять лет, и за это время координировал проекты c разными технологиями, широкой географией и самого разного масштаба: от 100 до 50 тысяч пользователей.

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

Речь пойдет об одном из сегментов проектных рисков, которые непосредственно связаны с людьми — их качествами, личными устремлениями, мотивацией и т. д. Упомянутые в статье вопросы и советы по большей части универсальны, то есть работают для 5-гокласса средней школы, бригады шахтеров в забое или для вашей Agile/Waterfall-команды. Главное, что мы говорим о группе людей, занятых общим делом.

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

Токсичные люди

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

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

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

Итальянская забастовка (work-to-rule). Человек или группа людей могут работать в строгом соответствии с должностной инструкцией или договором, но с крайне низким результатом. То есть «я работаю с 9 до 6 только по формализованным указаниям и не более». Бороться с этим work-to-ruleочень сложно, поскольку официальные требования к работе коллега старается выполнять, и формально придраться практически не к чему.

Пассивно-агрессивное поведение.Конфликты, часто на пустом месте или в обычной рабочей ситуации. Неадекватная реакция на штатные ситуации. Постоянные споры.

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

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

Что делать

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

Внутренний раскол

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

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

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

Что делать

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

Как увеличить шансы на успех

1. Старайтесь привлекать внешнюю экспертизу в сложных ситуациях, если хотя бы малость сомневаетесь в собственном опыте. Даже если в вашей компании позиции People Manager не предусмотрено, наверняка есть HR, DM, AM и просто другие опытные менеджеры, с которыми можно посоветоваться.
2. Пробуйте. Иногда можно реформировать команду в тестовом режиме, попробовать разные конфигурации с минимальными затратами времени и ресурсов для отработки конкретного кейса. Если идея не сработала, все можно отыграть назад.

Как оценить результаты

Установить отдельный KPI по удовлетворенности команды очень сложно. Но понимать, довольны ли люди в команде, вы все равно должны (да, я опять о разговорах!). Ключевым показателем, успешно ли вы работаете, в том числе на направлении people management, будет успех вашего проекта или продукта. В конце концов, речь не о дружбе или совместном отдыхе, а о работе.

Профессиональное выгорание

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

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

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

Что делать

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

Сопротивление переменам

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

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

Что делать

• Помогают разделение ответственности и плоская структура, когда PM и тимлид не ставят себя демонстративно выше других. Если все чувствуют ответственность за проект, пробовать новое им гораздо интереснее.
• Показывайте успешное использование новых техник другими командами. Находите early adopters, в среднем 5–10%людей всегда интересно первыми попробовать что-то новое.

Недостаток квалификации

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

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

Что делать

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

Слишком высокая квалификация

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

Недопонимание

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

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

Что делать

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

Bus-фактор

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

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

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

Что делать

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

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

Все меняется

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

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

Tips and tricks

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

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

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

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

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

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

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

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

Идея

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

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

Я давно понял, что хочу создавать и продавать, а не покупать и перепродавать. Подобных мне в Украине достаточно много. Рынок робототехники очень многогранен и растет с каждым годом примерно на 30%. Чего мало в Украине — возможностей для развития подобных специалистов. Самый большой сдерживающий фактор — недоступность источников знаний и условий для обучения во многих населенных пунктах Украины. Так я пришел к идее создания уникального и достаточно смелого проекта — RoboBus.

RoboBus

Реализация

Цель проекта проста — осуществить прорыв в области IT-обучения и стать помощником государственным реформам в сфере STEM образования. Передвижные школы могут «довозить» образование в самые отдаленные уголки Украины.

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

Программное обеспечение писали наши ребята, подключая открытые нейросети. Хардвердная часть смиксована из STM32 и RaspberryPI. Софтверная основана на взаимодействии Python, C, JavaScript (React). Выбрали данные технологии, базируясь на основных курсах программы обучения RoboBus.

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

Обучение будет происходить в таких направлениях:

• программирование С/С++, Python, Swift;
• робототехника на базе платформ Raspberry Pi, Arduino, STM32;
• ИИ на базе открытых нейросетей;
• 3D моделирование и печать на базе Solidworks и AutoCAD;
• создание квадрокоптеров и ракетомоделирование.

Программа занятий подготовлена нашими специалистами и имеет 2 формата:

• Мастер-классы для детей и взрослых. Цель — привлечь максимальное количество людей для профориентации.
• Курс обучения для детей и взрослых. Экспресс-курсы от 12 занятий для предоставления базовых знаний по современным технологиям.

Создание прицепа

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

Производили RoboBus в Украине в течение года. Абсолютно все инженерные решения были подготовлены нашей командой ребят. Первым этапом создания было макетирование с реальным соблюдением норм для условий комфортного и безопасного обучения. Второй этап — подготовка платформы с минимальным количеством отклонений от стандартных размеров разрешенных МРЭО прицепов. Самым сложным оказался этап создания технического задания заводу-производителю. Мы выделили 3 менеджера проекта для детального контроля и постоянных переговоров о поиске альтернативных решений поставленных нами задач.

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

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

Результаты

Обучение стартовало 12 мая в г. Буча. RoboBus посетили 5 групп учеников. Проект получает первые заказы на франшизу. Он очень заинтересовал европейских партнеров, так как уникален в плане форматов обучения.

На данный момент RoboBus собирает заявки на посещения. На их основе мы создаем карту передвижения машины.

В течение 5 лет планируется выпуск 10 RoboBus’ов для расширения маршрутов на небольшие поселки и села Украины.

Планируем объехать все областные центры Украины в течение 3-хлет, при этом обучить не менее 10 000 человек азам основных направлений. Обучение платное, так как знания достаточно высокого уровня и требуют участия опытных специалистов. Минимальная стоимость занятия — 170 грн с человека. Мы активно ищем грантовые площадки, спонсоров для оплаты услуг нашего проекта, таким образом некоторые группы обучаются бесплатно.

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

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

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

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

Photo by Krists Luhaers

Основные принципы

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

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

Учитывая размеры системы и все ограничения, а также применение правила «разделяй и властвуй» к решению подобных задач, мы определили 3 основных принципа мониторинга:

1. Каждый сервис имеет Service Level Agreement (SLA — соглашение о качестве сервиса).
2. Каждый экземпляр каждого сервиса отслеживает поток входящих запросов и параметры реакции на них.
3. Каждый экземпляр каждого сервиса отслеживает поток исходящих запросов к другим сервисам и параметры их реакции на эти запросы.

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

SLA — соглашение о качестве сервиса

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

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

Эти параметры называются Service Level Indicators (SLI — параметры качества сервиса). Wikipedia приводит достаточно хорошее описание SLI. Существует несколько популярных комбинаций этих параметров, они собраны на этом слайде.

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

Имея допустимые интервалы для параметров производительности и доступности, мы определяем Service Level Objective (SLO — измеримые характеристика сервиса). Больше про SLOможно прочитать на Wikipedia. Примеры SLO: сервис должен быть доступен 99,9% времени в течение года, в 95% случаев время ответа должно быть не более 300 миллисекунд. Сохраняя запас между декларируемыми SLO и реальными характеристиками системы, мы оставляем себе возможность заранее определить негативные тренды в поведении системы и отреагировать на них.

Следующий шаг — это определение Service Level Agreement (SLA — соглашение о качестве сервиса). Wikipedia содержит неплохую статью о SLA.

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

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

Мониторинг входящего потока

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

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

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

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

Мониторинг исходящего потока

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

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

Когда экземпляр нашего сервиса отправляет запрос к внешнему сервису, мы записываем метрики, определенные как SLI этого внешнего сервиса. Так как метрики описывают поток исходящих запросов, генерируемых нашим сервисом — мы называем это «мониторинг исходящего потока».

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

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

Выводы

Комбинация из SLA, мониторинга входящих и исходящих потоков дает нам:

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

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

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

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

Скорочення (у порядку їх появи в тексті):

BLE — Bluetooth Low Energy — технологія Bluetooth з низьким енергоспоживанням
PCB — Printed circuit board — друкована плата
API — Application Programming Interface — програмний інтерфейс застосунку

Основні підходи

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

Щоб відповісти на це питання, я рекомендую застосовувати кілька підходів:

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

Тож давайте обговоримо кожен підхід детальніше.

Сніффер

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

Щоб встановити такий інструмент, вам потрібно лише кілька речей: спеціальна PCB-плата та відповідний застосунок. Я використовував Wireshark та тестову плату Nordic Semiconductors. Разом вони забезпечують потужний набір інструментів для сніффингу. Інструменти-сніффери можуть бути використані в двох режимах — реклами та з’єднання.

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

• Інформація про інструменти для сніффингута те, як вони працюють.
• Сніффер nRF-Sniffer-UG.
• Wireshark.
• XQuartz (потрібен для деяких версій Wireshark).

Сторонні програми для тестування API

Один з найшвидших способів перевірки вашого пристрою — це використання сторонніх рішень. З їх допомогою ви легко можете сканувати, надсилати/отримувати або навіть симулювати деякі функції свого пристрою. Чудові приклади: LightBlue, BlueGecko.

Ведення логу

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

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

Прошивка

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

На цьому етапі я припускаю, що середовище розробки повністю працює, і все, що вам треба, це просто засукати рукава та почати програмувати :)

Про що подбати

Щоб гарантувати вашому користувачеві найкращий user experience, ви повинні повністю контролювати середовище Bluetooth всередині вашої програми та, відповідно, у всіх його аспектах. Загалом ви повинні подбати про такі моменти:

• доступність Bluetooth-пристрою (спостереження за статусом пристрою);
• тайм-аут для відповіді від підключеного пристрою;
• обробка багаторядкових відповідей (за необхідності);
• робота в фоновому режимі (за необхідності);
• з’єднання з кількома пристроями одночасно (за необхідності).

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

Спостереження за статусом пристрою

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

import Foundation
import CoreBluetooth
final class BLEStatusObserver: NSObject {
    public struct Notifications {
        public static let BLEStatusObserverDidDetectBLEStatusChange = "BLEStatusObserverDidDetectBLEStatusChangeNotification"
        struct Keys {
            static let availability = "availability"static let message = "message"
        }
    }
    static let observer = BLEStatusObserver()
    var isBleDeviceActive:Bool {
        return currentState == .poweredOn
    }
    private var centralManager:CBCentralManager?
    private var currentState:CBManagerState = .unknown
    // MARK: - LifeCycle
    override init() {
        super.init()
        centralManager = CBCentralManager(delegate: self, queue: nil)
    }
}
extension BLEStatusObserver:CBCentralManagerDelegate {
    // MARK: - CBCentralManagerDelegate
    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        var notificationMessage:String? = nilswitch central.state {
            case .unauthorized:
                notificationMessage = NdynamicLocalizableString"bleService.message.StatusUnathorized")
            case .unsupported:
                notificationMessage = NdynamicocalizableString("bleService.message.Unsupported")
            case .poweredOff:
                notificationMessage = NdynamicocalizableString("bleService.message.PowerOff")
            case .poweredOn:
                notificationMessage = NdynamicocalizableString("bleService.message.PowerOn")
            default:
                break
        }
        currentState = central.state
        NotificationCenter.default.post(name: NSNotification.Name(rawValue: BLEStatusObserver.Notifications.BLEStatusObserverDidDetectBLEStatusChange), 
                                       object: nil, userInfo: [
                                                                    Notifications.Keys.availability : central.state == .poweredOn,
                                                                    Notifications.Keys.message : notificationMessage ?? ""
                                                                ])
    }
}

Тайм-аут

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

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

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

Беручи це до уваги, пропоную починати з 70-100 мілісекунд,а потім адаптувати цей час до ваших потреб.

Багаторядкові відповіді

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

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

Цей підхід надзвичайно простий та, повірте мені, дуже ефективний. Якщо ви його запровадите, ви можете навіть почати краще спати вночі :)

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

Робота у фоновому режимі

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

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

Висновки

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

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

• Apple Developer — Core Bluetooth Programming Guide, Documentation
• WWDC 2012 Videos — Core Bluetooth 101
• WWDC 2012 Videos — Advanced Core Bluetooth
• WWDC 2013 Videos — Core Bluetooth
• Tutorials
• Gists
• Sniffer tool

Те, що ми колись називали технологіями майбутнього, покоління Z (ті, хто народилися після 1995 р. — ред.)вважає невід’ємною частиною повсякденного життя. Деяким його представникам навіть немає 18 років, а вони вже подають ідеї та створюють проекти, які покликані покращити майбутнє людей.

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

Соломія Леньо, 16 років

Future cognitive scientist, фіналістка Intel ISEF та ICYS-2018

«Я не знаю річ, яку не можна запрограмувати»

Усе почалося з 8-гокласу. Раніше я думала, що маю схильність до гуманітарної сфери й можу стати, наприклад, художником, дизайнером, навіть юристом. Якось після 7-гокласу мама розповіла мені про літній табір з комп’ютерних наук. Того літа мені особливо не було чим займатись, тож я вирішила спробувати. Після трьох тижнів табору я вже усім розповідала, що хочу бути програмістом. У моїй родині є технарі, вони мене підтримували. А ось більш далеким родичам було дуже складно мене зрозуміти. Це звучало приблизно так:

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

Після таких слів я часом сумнівалась у правильності вибору, думала, можливо, це лише тимчасова ейфорія після табору. Все ж згодом я вирішила записатись на гурток «Юний програміст». Ми вчили Delphi і Pascal. На першому зайнятті сиділо 30 хлопців і я — одна дівчина, а вже на останньому — зі мною залишилось лише троє хлопців. Згодом я занурилась у С++ і об’єктно-орієнтоване програмування.

Мій перший серйозніший досвід — програма, яка проводила генетичні розрахунки. Це була власна науково-дослідницька робота, яку я захищала в Києві, а згодом в 11-мукласі подала її на конкурс Intel Techno Ukraine й посіла третє місце.

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

Я вчилася в медичній школі, де нахил був на хімію та біологію. Якось ми з шкільною вчителькою дійшли до ідеї, яка передбачає створення нейронної мережі, що аналізує електрокардіограми. З цією роботою я подалася на всеукраїнський конкурс Intel Eco Ukraineв секцію «Наука про людину», де пройшла далі вже на міжнародну виставку-конкурс Intel ISEF (International Science and Engineering Fair), з якої я приїхала лише кілька днів тому. Цьогоріч він проходив у місті Пітсбург, штат Пенсильванія.

Загалом це була моя друга подорож за кордон і перша до США. Участь брали понад 2000 учасників із близько 1700 проектами. Вони представляли більше ніж 75 країн світу, а до складу журі входили шість лауреатів Нобелівської премії та понад 100 професорів. У перший же день конкурсу у нас була Pin-party, де ми обмінювалися значками та гостинцями зі своїх країн. Мій рюкзак був настільки заліплений значками, що я не могла знайти замок-блискавку.

Не менш цікавими були дні постерного захисту. З кожним членом журі ми мали п’ятнадцятихвилинну дискусію. Найприємніше було, що завдяки моїй англійській мало хто здогадувався, що я не з Штатів. Цього ж дня було нагородження Special Awards, з якого я вийшла з двома нагородами — від української Малої академії наук під егідою ЮНЕСКО та від арабського короля. Загалом у цей день наша українська команда повернулася до готелю з 5 нагородами. Такі конкурси насправді сильно змінюють твоє світобачення та внутрішні ідеали.

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

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

Дмитро Лопушанський, 15 років

Front-end розробник, автор ідеї додатку Under Control, соцмережі Tagbe та телеграм-бота NewsKit.

«Програмування — це суцільна помилка, яку потрібно вирішити»

Все почалося два роки тому. Я завжди був відмінником, але не знав, ким хочу бути. Якось за порадою батьків я вирішив спробувати програмування й зараз займаюся front-end розробкою. Знаю HTML, CSS, JavaScript, Python, трохи PHP. Не всі однокласники спочатку сприймали те, що я обрав для себе. Було багато скептицизму, але й були люди, які мене підтримували. Батьки раді, що це для мене зараз і хобі, і робота, яка приносить гроші.

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

Свій перший «дотик» до ІТ я зробив у літньому таборі на тижневому курсі з програмування. Мені розповідали про те, як виглядає HTML-сторінка і що це взагалі таке. Пам’ятаю свої шалені емоції, коли в тезі style я писав background-color: red — і сторінка в браузері ставала червоною, а згодом red змінив на aqua — і сторінка ставала блакитною. Навіть не мав уявлення, що так взагалі можна робити. Звучить дуже смішно, але так було. Зараз я ходжу на курси з програмування й працюю над кількома проектами. Один з них — Tagbe. Це соціальна мережа, в якій основна функція — відокремлення того, що ви хочете бачити в своїй стрічці новин від того, що не хочете. Котики окремо, ділові справи окремо. Ви обиратимете й отримуватимете лише те, що самі вважаєте корисним.

Інший проект — телеграм-бот NewsKit, який інтегруватиметься з Tagbe. В NewsKit ви обираєте медіа, тематику й час, у який вам зручно отримувати новини за вказаними параметрами.

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

Я брав участь у багатьох IT-конкурсах, більшість з яких — змагання на кшталт startup-competitions. Останній раз був учасником молодіжного конкурсу «Золотий Байт» з Tagbe та NewsKit. На самих змаганнях я здобув друге місце. А наступного тижня вже буду спікером на одному інноваційному форумі.

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

Анастасія Лівочка, 17 років

Винахідниця, фіналістка Intel ISEF — 2017 (Los Angeles), MILSET — EXPO (Brazil) і Stockholm Junior Water Prize (Sweden)

«Знання — одна з найголовніших цінностей, а особистість — цінність, яку ми формуємо самі»

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

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

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

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

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

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

Єлізавета Годовікова, 16 років

Винахідниця, автор стартап-ідеї Waste Manager

«На кухні мені дуже тяжко, простіше запрограмувати бота»

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

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

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

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

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

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

Зараз я вчуся в політехнічному ліцеї «КПІ» та паралельно в комп’ютерній академії, а ще займаюся в гуртку радіотехніки. Обожнюю мікроконтролери. Цього року ще планую здавати тести, аби вступити до навчального закладу в США. Все це поки не дає мені сконцентруватись на проектах. Зараз я заглибилась у навчання. Багато моїх однокласників не знали, чим я займаюсь. Лише те, що я схиблена на математиці. Є немало знайомих в ліцеї, які взагалі не цікавляться технологіями. Є такі, що не знають елементарних команд, наприклад, Ctrl+C/Ctrl+V, хоча ми всі народились в комп’ютерну епоху. Те, чим я займаюсь — схоже на безумство, яке перемішане з наукою та творчістю.

Володимир Андрюшко, 17 років

Розробник ідеї додатку EASYPARK

«Коли знаходжу баг — отримую задоволення»

У моїй родині всі мають добрі здібності в математиці, тому у виборі професії я довго не вагався. Батьки одразу підтримали мій вибір, адже бачили, що я маю певні успіхи в цій справі. Програмуванням займаюся з 9-гокласу й досі відвідую курси двічі на тиждень. Тоді я починав з Pascal та Delphi, далі був С++. Коли я працював над своїм проектом, то сам перейшов на С#. Зараз я опановую Java й хочу бути розробником додатків.

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

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

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

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

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

З 24 квітня по 8 травня на DOU проходило щорічне опитування, присвячене якості освіти в українських ЗВО (заклад вищої освіти — ред.). Загалом цього року зібрано 2938 анкет.

Із цікавого — у трійці лідерів одразу два харківських університети, КПІ, як і минулого року, всередині списку, а Львівська політехніка погіршила свої позиції і впала до аутсайдерів. А ще визначили, що майже половина нинішніх студентів ідуть у виш лише за «корочкою», а 25% отримують роботу вже 1-2 курсі.Але про все по черзі.

Результати

Рейтинг ЗВО у 2018 році не зазнав значних змін порівняно з 2016-17 роками.

Третій рік поспіль лідером за оцінками своїх студентів та випускників залишається НаУКМА: готовність рекомендувати цей заклад оцінюється у 8,9 бала з 10.

За ним слідують харківські університети: ХНЕУ ім. Кузнеця (8,2 бала) та ХНУРЕ (7,9 бала). Ці ЗВО і минулого року були серед лідерів, а за рік їм вдалося дещо підвищити свої бали.

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

Серед університетів, які отримали оцінку вище середнього рівня, — також КНУ ім. Шевченка (7,1 бала), Чернівецький університет ім. Федьковича (7,0 бала; вперше в рейтингу) та Сумський державний університет (6,9 бала).

Високі оцінки отримали також два факультети КПІ ім. Сікорського — ФПМ (6,8 бала) та ІПСА (6,7 бала). У цілому університет оцінили на середньому рівні — 6,2 бала.

Середній бал також у Чорноморського національного університету ім. Петра Могили, ХНУ ім. Каразіна, ХАІ ім. Жуковського, ЛНУ ім. Франката ДНУ ім. Гончара.

Перелік аутсайдерів теж не зазнав значних змін порівняно з минулим роком: нижче за інші університети були оцінені Львівська політехніка, ОНПУ, ВНТУ, ХПІта НАУ. У 2017-муЛьвівська політехніка входила в групу ЗВО із середнім показником готовності рекомендувати, проте цього року оцінка університету знизилася. Чи є ці зміни в рейтингу сталими, з більшою впевненістю можна буде сказати наступного року.

Блакитним кольоромвиділені показники вищі, ніж у решти ЗВО, жовтим — нижчі. Показники в чарунках без заливки не відрізняються від оцінок решти вишів (рівень значимості 90%).

Чарунки з числами показують середню оцінку за шкалою від 1 до 10, з відсотками — частку від усіх респондентів конкретного вишу / факультету.

Як і в попередні роки, українські ІТ-спеціалісти не дуже високо оцінюють свої університети за всіма показниками — середні оцінки коливаються в межах 4-7балів з 10.

Цікаво відзначити, що ті, хто вже закінчив університет, оцінюють своє навчання дещо краще, ніж ті, хто ще вчиться. Наприклад, випускники дещо вище, ніж студенти, оцінюють вплив університету на шанси знайти цікаву (6,2 та 5,9 бала відповідно) та високооплачувану роботу (6,0 та 5,7 бала відповідно), а також дещо частіше вважають, що університет дає корисні знання для роботи в ІТ (5,5 та 5,2 бала відповідно). Це може бути пов’язаним як з більшим робочим досвідом випускників і розумінням, як саме університет впливає на кар’єру, так і зі змінами, які відбуваються у сфері освіти останнім часом, зокрема появою широких можливостей для самоосвіти.

Імідж, викладачі та навчальні програми визначають готовність рекомендувати ЗВО

Готовність рекомендувати свій ЗВО / факультет / кафедру в середньому для всіх вишів залишається на тому ж доволі низькому рівні: 6,2 бала з 10.

На готовність рекомендувати ЗВО впливає декілька груп факторів.

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

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

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

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

Вища освіта в ІТ: формальність, але важлива

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

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

Ще одна причина вчитися в університеті, важливість якої зростає — можливість сховатися від армії. Більше чверті нинішніх працюючих студентів назвали це серед причин навчання у ЗВО, а серед тих, хто випустився до 2012 року, таких тільки 12%.

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

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

Отже, якість освіти має тенденцію до покращення. Водночас її цінність для студентів падає.

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

З іншого боку, схоже, що наразі український ІТ-ринок має таку потребу у працівниках, що готовий давати роботу навіть тим, хто не пройшов і половини терміну навчання в університеті: 25% нинішніх працюючих студентів отримали роботу в ІТ на 1-2курсах університету або ще до вступу. Для тих, хто випустився з університету в попередні роки, характерне більш пізнє працевлаштування: найчастіше вони починали працювати після 3 курсу.

Готовність роботодавців працевлаштовувати студентів, яким ще далеко до завершення університетського курсу, може бути важливим чинником ставлення студентів до навчання у ЗВО як до формальності. Принаймні ті, хто почав працювати раніше, рідше вказують, що навчання в університеті потрібне для отримання професійних знань. Серед нинішніх студентів, які працюють в ІТ з 1-2 курсу, 36% назвали причиною навчання отримання професії, 54% — отримання формального документу, а 32% — можливість уникнути армії. Серед тих, хто почав працювати на 3 курсі чи пізніше, таких 43%, 48% та 26% відповідно.

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

Вища освіта за кордоном

Якби респонденти мали другий шанс, 37% з них знову вступили б у той самий заклад, на ту саму кафедру чи факультет. На другому місці за частотою згадувань — навчання за кордоном. Чверть опитаних, якби їм дали другий шанс, не вступали б до університету в Україні, а поїхали б за кордон.

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

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

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

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

Оцінки університетів

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

Національний університет «Києво-Могилянська академія»

Університет третій рік поспіль займає найвищу сходинку в нашому рейтингу ЗВО і має дуже високий показник рекомендацій: 51% випускників оцінили свою готовність рекомендувати його на 10 балів з 10. Це найкращий показник серед усіх університетів.

Що стосується окремих аспектів роботи університету, то переважна більшість з них теж оцінені вище середнього. Випускники, очевидно, пишаються своїм університетом: престижність цього закладу оцінена вище за всі інші університети (8,5 бала з 10). Крім того, випускники та студенти НаУКМА частіше за інших вважають, що роботодавці цінують їх диплом (7,8 бала з 10).

Навчальний процес є сильною стороною університету: студенти вивчають більше різноманітних ІТ-технологій, ніж в більшості інших університетів (5,7 при середній кількості 3,8). Частіше за інші університети НаУКМА залучає ІТ-фахівців до викладання (це вказали 78% респондентів, при середньому показнику 41%). Також університет отримує допомогу від ІТ-компаній в облаштуванні навчального простору (66% при середньому показнику 34%). Що ж стосується корупції, то тут один з найнижчих її показників (особисто стикалися 2%, при середньому показнику 33%) та один з найвищих показників нетерпимості до плагіату (6,3 бала з 10 при середньому показнику 4,9). Адміністрація ЗВО / факультету оцінена найвище серед усіх університетів за орієнтацію на студентів та допомогу їм у складних ситуаціях (8,5 з 10 при середньому показнику 5,8).

Слабким місцем НаУКМА, порівняно з іншими університетами-лідерами, є цікавість навчальної програми. Її оцінили на середньому для всіх ЗВО рівні — 4,6 бала при середньому показнику 4,3.

Харківський національний економічний університет ім. С. Кузнеця

Два харківських ЗВО — ХНЕУ та ХНУРЕ ділять 2 і 3 місце за показником готовності рекомендувати університет.

ХНЕУ входив до лідерів і минулого року, а в 2018 показник готовності рекомендувати цей виш помітно зріс — з 7,3 до 8,2 бала (чи є ця тенденція сталою, ми побачимо наступного року).

Цей ЗВО має найвищий серед проаналізованих університетів показник рівня знань та мотивованості студентів до навчання, а також найвищу кількість технологій, які вивчаються в межах навчальної програми (5,9 при середньому показнику 3,8).

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

Харківський національний університет радіоелектроніки

Університет представлений факультетом комп’ютерних наук (КН) та факультетом комп’ютерної інженерії та управління (КІУ).

Загалом готовність рекомендувати університет складає 7,9 бала з 10, що вище середнього рівня.

КН оцінюється помітно краще за КІУ (готовність рекомендувати — 8,2 проти 7,3 відповідно) і за своїми оцінками наближається до лідерів рейтингу — НаУКМА та ХНЕУ.

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

Серед відмінностей двох факультетів, які можуть впливати на різницю їхніх оцінок, можна назвати насиченість навчальної програми: кількість технологій, які вивчаються, на КН вища (5,8 на КН проти 4,5 на КІУ), а співробітництво з ІТ-компаніями тісніше (зокрема, допомога з технічним забезпеченням — 64% проти 36%, спонсорство навчальних заходів — 59% проти 34%, організація спільних курсів — 48% проти 31%, запрошення на лекції спеціалістів з ІТ-компаній 66% проти 55%).

Окремо варто відзначити досить високий рівень корупції в цьому закладі: 27% наших респондентів особисто стикалися з хабарями в університеті, що помітно вище, ніж в НаУКМА і ХНЕУ (там — не більше 10%), і наближається до середнього показника по всім університетам.

Київський національний університет ім. Шевченка

КНУ ім. Шевченка представлений факультетом комп’ютерних наук та кібернетики, а також іншими факультетами (жоден з яких не набрав 40 відповідей, тому ми не аналізуємо їх окремо).

Оцінка готовності рекомендувати цей університет / факультет не змінилася порівняно з минулим роком. Проте ХНЕУ та ХНУРЕ дещо покращили свої показники, через що КНУ ім. Шевченка опинився на 4-мумісці в рейтингу.

Факультет комп’ютерних наук та кібернетики оцінили дещо вище, ніж інші факультети — на 8 з 10 (університет загалом — 7,1 з 10).

Серед особливостей університету слід відзначити високі оцінки складності навчання (5,9 з 10) та мотивованості студентів (7 з 10, а на факультеті комп’ютерних наук та кібернетики — 7,5 з 10), а також низький рівень корупції (8% при середньому показнику 33%). Водночас випускники і студенти цього університету називали менше технологій, які вивчаються — зокрема, рідше називали JS (22% при середньому показнику 39%) та PHP (10% при середньому показнику 30%), рідше зазначали, що університет співпрацює з ІТ-компаніями (про залучення працюючих ІТ-спеціалістів до викладання згадали 32% при середньому показнику 41%, про організацію спільних курсів — 18% при середньому показнику 23%), а також відзначали більш поблажливе ставлення до плагіату, ніж в інших топових ЗВО (на 5 з 10, в той час як в топ-3 університетах в рейтингу цей показник складає від 5,7 до 6,9 бала).

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

Чернівецький національний університет ім. Федьковича

Чернівецький університет вперше набрав достатню кількість голосів та потрапив у рейтинг вишів з високим результатом: середня оцінка готовності рекомендувати — 7,0 бала з 10, що вище середнього рівня.

Незважаючи на досить високу готовність рекомендувати ЗВО, студенти і випускники рідко вважають, що їх диплом цінується роботодавцями (4,5 бала з 10 при середньому показнику 5,5). В цілому, на відміну від інших університетів з високими позиціями в рейтингу, імідж Чернівецького університету серед його студентів та випускників помітно гірший і знаходиться на середньому рівні. Наприклад, престижність свого факультету студенти та випускники цього вишу оцінили на 6,6 бала (в університетах, що займають перші 4 сходинки рейтингу — від 6,6 до 8,5). Чи сприяє навчання здобуттю цікавої / перспективної роботи — оцінили на 6,4 бала (проти 6,9-8,5),чи допомагає отримувати гідну зарплатню — 5,6 бала (проти 7,0-8,5).

Серед сильних сторін університету — високі оцінки якості викладання (зрозуміла подача матеріалу — 6,6 при середньому показнику 6,0), технічного стану приміщень (7,0 при середньому показнику 5,4) та технологічного забезпечення навчання (6,7 проти 5,7 загалом), орієнтації адміністрації університету на інтереси студентів та готовність допомогти (6,7 при середньому 5,8). Кількість технологій, які вивчаються, вища за середнє значення (4,5 проти 3,8).

Корупція в університеті оцінена на середньому рівні (29% стикалися особисто, середній показник — 33%). Співробітництво з ІТ-компаніями теж на середньому рівні, окрім гостьових лекцій співробітників ІТ-компаній (про них згадали 60% студентів та випускників, при середньому показнику 46%) чи пропозицій з працевлаштування (52% при середньому показнику 38%).

Сумський державний університет

Сумський державний університет ділить 3-5місце в рейтингу з КНУ та Чернівецьким університетом. Середня готовність рекомендувати виш — 6,9 з 10, що вище за середнє по всім університетам.

Сильні сторони університету: викладачі (зрозумілі пояснення — 6,3 бала при середньому показнику 6,0, досвід роботи — 5,8 при середньому показнику 5,4, жорстке ставлення до плагіату — 5,8 при середньому показнику 4,9), технічний стан приміщень (7,1 при середньому показнику 5,4) та забезпечення навчання (технологічним обладнанням — 7,1 при середньому показнику 5,7; навчальними матеріалами — 7,3 при середньому показнику 6,1), адміністрація (готовність допомогти — 7,5 при середньому показнику 5,8; організація навчального процесу — 7,1 при середньому показнику 5,5) та імідж вишу (престижність — 7,0 при середньому показнику 6,2; вплив навчання на отримання цікавої та перспективної роботи — 6,5 при середньому показнику 6,0; вплив на розмір зарплатні — 6,3 при середньому показнику 5,9; оцінка диплома вишу роботодавцями — 6,2 при середньому показнику 5,5).

В університеті частіше за інші ЗВО організовують повноцінні навчальні курси разом з ІТ-компаніями та часто залучають ІТ-спеціалістів до викладання. Як результат, університет має високу частку тих, хто вступає сюди саме з метою отримати знання та навичок для професійної діяльності (62% при середньому показнику 48%).

Рівень корупції в університеті нижче середнього: 16% стикалися з хабарями особисто при середньому показнику 33%.

Разом з тим, студенти та випускники менше задоволені відповідністю розміру оплати за навчання та якості освітніх послуг (27% вважають, що вартість відповідає якості, при середньому показнику 33%).

Чорноморський університет ім. Петра Могили

Чорноморський університет ім. Петра Могили належить до групи університетів з середнім рівнем рекомендацій — 6,4 бала з 10.

Сильні сторони ЗВО оцінені вище, ніж в середньому — викладачі, навчальна програма, адміністрація, технічне забезпечення процесу навчання, залучення ІТ-спеціалістів до викладання та читання лекцій. Також тут один з найнижчих рівнів корупції (лише 3% особисто стикалися з хабарями в університеті при середньому показнику 33%).

Водночас співвідношення ціни та якості освіти рідше, ніж в середньому по всіх університетах, оцінюється як оптимальне (26% проти 33% в середньому по всім університетам), а 38% опитаних студентів та випускників, якби в них був другий шанс, поїхали би навчатися за кордон (в рідному університеті лишилися б 32%).

НТУУ «Київський політехнічний інститут ім. Сікорського»

КПІ представлений у вибірці 4 факультетами, які ми змогли проаналізувати окремо: ФПМ, ІПСА, ФІОТ та ТЕФ (інші факультети набрали менше 40 анкет).

Загалом готовність рекомендувати КПІ знаходиться на середньому рівні (6,2 бали з 10), проте ситуація дуже відрізняється на різних факультетах:

• ФПМ та ІПСА оцінюються вище середнього (6,8 та 6,7 бала відповідно)
• ФІОТ та ТЕФ оцінюються на середньому рівні (6,3 та 6 балів відповідно).

КПІ загалом має один з найвищих показників складності навчання (6 з 10 при середньому показнику 5,3), високий рівень знань та мотивації студентів (6,5 при середньому показнику 6,1), хороший імідж серед роботодавців (6,1 при середньому показнику 5,5). На середньому рівні оцінена корисність отриманих знань (5,3 бали), доволі низько — їх актуальність (4,1 при середньому показнику 4,3).

Що ж до навчальної програми, то ФПМ та ТЕФ пропонують до вивчення більшу кількість ІТ-технологій, ніж університети в середньому (4,7 та 4,2 відповідно при середньому показнику 3,8), а ІПСА та ФІОТ — на середньому рівні (3,6 та 3,8 відповідно). При цьому якість викладання та технічна забезпеченість оцінюються досить низько: на ФІОТ та ТЕФ нижче середнього рівня (зрозуміла подача матеріалу — 5,4 та 5,5 відповідно при середньому показнику 6,0; стан аудиторій та гуртожитків — 3,9 та 4,1 при середньому показнику 5,4), на ФПМ та ІПСА — переважно на середньому рівні (зрозуміла подача матеріалу — 6,4 та 5,9 відповідно; стан аудиторій та гуртожитків — 4,8 та 4,9 відповідно).

ФПМ та ІПСА мають низький рівень корупції (до 10% респондентів стикалися з хабарями), ТЕФ — рівень корупції вище середнього (44% особисто стикалися з хабарями), ФІОТ — середній (27%).

Харківський національний університет ім. Каразіна

Готовність рекомендувати університет на середньому рівні — 6,2 бала з 10.

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

Програма навчання оцінюється студентами як цікава, проте не дуже актуальна. Кількість технологій, яка вивчається студентами, нижче середнього рівня (3,2 при середньому показнику 3,8). Співробітництво з ІТ-компаніями теж досить неактивне: тільки 7% респондентів загали спільні курси університету та ІТ-компаній (при середньому показнику 23%), 21% сказали, що ІТ-компанії надавали факультету технічну підтримку (при середньому показнику 34%). У результаті 26% студентів та випускників зазначили, що обрали б інший ЗВО, якби мали другий шанс (у середньому цей показник складає 16%).

Національний аерокосмічний університет ім. Жуковського «ХАІ»

Готовність рекомендувати університет не відрізняється від середнього значення — 6,1 бала з 10.

Більшість показників, за якими оцінювали університет, на середньому рівні: його імідж та престижність, викладачі, навчальні програми, адміністрація, співробітництво з ІТ-компаніями. Вище середнього оцінена технічна база (стан приміщень — 6,4 при середньому показнику 5,4, забезпечення технікою для навчання — 6,5 при середньому показнику 5,7) та забезпеченість навчальними матеріалами (6,9 при середньому показнику 6,1).

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

Львівський національний університет ім. Франка

Дещо більше половини вибірки університету складають студенти та випускники факультету прикладної математики та інформатики, решту — інші факультети вишу.

Готовність рекомендувати ЛНУ на середньому рівні — 6,0 бала з 10. Наразі ми спостерігаємо тенденцію до поступового зниження готовності рекомендувати цей ЗВО, з 6,5 бала в 2016 році до 6,0 бала в 2018.

Високо оцінюється складність навчання в університеті, особливо на факультеті прикладної математики та інформатики (6,0 у виші в цілому, 6,7 на факультеті прикладної математики та інформатики при середньому показнику 5,3). Також високо оцінюється співвідношення ціна-якість навчання в університеті (55% вважають це співвідношення не завищеним при середньому показнику 42%).

Оцінки факультету прикладної математики та інформатики кращі за оцінки університету в цілому: вище оцінюється його імідж (престижність факультету оцінена на 7,5 бала, а університету загалом — на 6,0), сприйняття серед роботодавців (5,2 проти 4,9) та роль в отриманні цікавої роботи і гідної зарплати (6,5 проти 5,7); вище оцінюється корисність (5,3 проти 4,8) та актуальність програми навчання (4,0 проти 3,7), рівень знань та мотивованості студентів (6,2 проти 5,6), корисні професійні зв’язки та знайомства, які можна завести в університеті (5,4 проти 5,0), вивчається більша кількість технологій (3,8 проти 3,0). Менша частка студентів стикається з корупцією та хабарництвом (20% проти 26%).

У цілому схоже, що студенти та випускники не дуже задоволені своїм університетом, і 25% з них обрали б інший ЗВО в Україні (середній рівень — 16%).

Національний університет «Львівська політехніка»

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

Загалом готовність рекомендувати ЛП нижче середнього рівня — 5,9 бала з 10. Інститут комп’ютерних технологій, автоматики та метрології оцінюється дещо краще — на середньому рівні (6,2).

Сильні сторони університету — високо оцінений технічний стан приміщень (5,7 бала при середньому показнику 5,4). Слабкі сторони — рівень викладачів (зрозуміла подача матеріалу — 5,3 при середньому показнику 6,0; досвід роботи — 4,6 при середньому показнику 5,4; суворість до плагіату — 4,3 при середньому показнику 4,9) та адміністрація університету (готовність допомогти студенту — 4,6 при середньому показнику 5,8, організація навчального процесу — 4,4 при середньому показнику 5,5).

Щодо інших показників, то ситуація помітно відрізняється у двох досліджених інститутах. Інститут комп’ютерних технологій, автоматики та метрології краще оцінюється за кар’єрними перспективами (можливість отримати перспективну роботу — 6,1 проти 5,5 в Інституті комп’ютерних наук та інформаційних технологій; можливість отримати гідну зарплату — 5,6 проти 5,0), цікавістю та актуальністю навчальної програми (цікавість навчання — 4,3 проти 3,3; корисність знань — 5,2 проти 4,6; актуальність знань — 4,1 проти 3,5).

При цьому в Інституті комп’ютерних технологій, автоматики та метрології один з найвищих показників корупції — 60% студентів та випускників стикалися з нею особисто (в Інституті комп’ютерних наук та інформаційних технологій — 38%, в середньому по всім університетам — 33%). Крім того, 30% тих, хто навчався в Інституті комп’ютерних технологій, автоматики та метрології, хотіли б змінити його на інший факультет в рамках цього ж ЗВО (в Інституті комп’ютерних наук та інформаційних технологій — 14%, у середньому по всім університетам таких 11%).

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

Дніпровський національний університет ім. Гончара

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

Наразі готовність рекомендувати університет на середньому рівні — 5,8 бала з 10. Нижче середнього оцінили факультет прикладної математики (5,6 бала).

Серед сильних сторін університету — висока оцінка навчальної програми як цікавої (4,7 при середньому показнику 4,3) та корисної для роботи (5,7 при середньому показнику 5,3), проте не дуже актуальної (3,7 при середньому показнику 4,3). Імідж, оцінка викладачів та студентів, зміст навчальної програми та співробітництво з ІТ-компаніями — на середньому рівні.

До слабких сторін відноситься адміністрація ЗВО (готовність допомогти студенту — 5,3 при середньому показнику 5,8; організація навчального процесу — 4,6 при середньому показнику 5,5), а також технічний стан приміщень (найнижча оцінка з-поміж усіх університетів — 3,4 при середньому показнику 5,4), забезпечення навчального процесу технікою (3,7 при середньому показнику 5,7) та навчальними матеріалами (4,9 при середньому показнику 6,1). Рівень корупції також досить високий: 45% студентів факультету прикладної математики особисто стикалися з хабарями, що вище середнього показника по всім університетам (33%).

Якби була можливість, майже чверть студентів та випускників університету змінили б його на інший виш в Україні (в середньому по всім університетам — 16%).

Одеський національний політехнічний університет

Готовність рекомендувати ОНПУ знаходиться на рівні нижче середнього — 5,6 бала з 10. Дещо краще оцінюють Інститут комп’ютерних систем — на 6 балів.

Низько оцінюють корисність та актуальність знань, які дає університет (корисність — 4,4 при середньому показнику 5,3, актуальність — 3,5 при середньому показнику 4,3), підготовку та практичний досвід викладачів (вміння пояснювати — 5,2 при середньому показнику 6,0; практичний досвід — 4,9 при середньому показнику 5,4), їх ставлення до плагіату та списування (4,4 при середньому показнику 4,9), технічний стан приміщень (4,2 при середньому показнику 4,9) та забезпеченість засобами для навчання (навчальні матеріали — 5,2 при середньому показнику 6,1, технологічні можливості — 5,0 при середньому показнику 5,7), а також імідж університету (престижність — 5,7 при середньому показнику 6,2; вплив на отримання перспективної роботи — 5,4 при середньому показнику 6,0; вплив на отримання хорошої зарплатні — 5,3 при середньому показнику 5,9) та вартість навчання (53% вважають вартість завищеною, при середньому показнику 35%).

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

Низьким оцінкам університету відповідає специфіка цілей його студентів: більше 50% вступили, щоб отримати «корочку» (в середньому по університетам — 41%), більше чверті — щоб уникнути армії (в середньому — 20%). 20% студентів та випускників університету не стали б вступати у виш, якби в них був другий шанс; в Інституті комп’ютерних систем таких 13% (в середньому по університетах — 9%).

Вінницький національний технічний університет

Як і минулого року, ВНТУ відноситься до трійки університетів з найнижчим показником рекомендацій: 5,3 з 10, що нижче середнього по університетам (факультет інформаційних технологій та комп’ютерної інженерії — 5,4).

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

В університеті один з найвищих показників корупції (особисто стикалися з хабарями 60% студентів та випускників вишу при середньому показнику 33%) та один з найвищих показників поблажливості до плагіату та списування (суворість у ставленні до плагіату оцінили у 3,8 бали при середньому показнику 4,9).

Серед сильних сторін респонденти відзначили можливість завести корисні для професійної діяльності зв’язки та знайомства (оцінені на 5,8 з 10, що відповідає середньому рівню).

Як і в ОНПУ, вище середнього частка тих, хто вступає до ВНТУ з метою отримання «корочки» (50% при середньому показнику 42%) або уникнення служби в армії (27% при середньому показнику 20%). Також вище середнього частка тих, хто не вступав би до університету взагалі, якби була така можливість (18% при середньому показнику 9%).

НТУ «Харківський політехнічний інститут»

ХПІ демонструє стійку тенденцію до зниження готовності респондентів рекомендувати університет: з 6,1 бала в 2016 році до 4,8 бала в 2018. Наразі університет другий з кінця за показником рекомендацій.

Майже за всіма показникам університет має оцінки нижче середнього: навчальна програма, викладачі, студенти, забезпечення технікою та матеріалами, співробітництво з ІТ-компаніями, а також імідж університету та його вплив на можливості працевлаштування. Університет має один з найвищих рівнів корупції (56% студентів та випускників особисто стикалися з хабарями при середньому показнику 33%, а в НаУКМА, ХНЕУ, КНУ, Чорноморському університеті та в деяких факультетах КПІ цей показник — до 10%).

28% студентів та випускників, якби мали можливість, обрали б інший ЗВО в Україні для навчання.

Національний авіаційний університет

Як і в попередні два роки, НАУ займає останню сходинку в нашому рейтингу університетів. Цього року готовність рекомендувати університет складає 4,5 бала з 10, а Інститут комп’ютерних інформаційних технологій — 4,3 бала.

Університет має найнижчі оцінки майже за всіма характеристикам. Дуже низький рівень співпраці з ІТ-компаніями: лише 31% респондентів згадали лекції спеціалістів ІТ-компаній (при середньому показнику по всіх університетах 46%), 23% сказали, що ІТ-спеціалістів залучали до викладання курсів (у середньому — 41%), а 16% згадали, що ІТ-компанії спонсорувати різні навчальні заходи (при середньому показнику 30%). Рівень корупції, навпаки, один з найвищих (стикалися з хабарями 56% студентів та випускників при середньому показнику 33%).

Студенти університету загалом менше орієнтовані на отримання знань в університеті: 18% з них вступили у виш, лише щоб отримати «корочку» та / чи уникнути армії (при середньому показнику 8%), а 22% студентів та випускників взагалі не вступали б у виш, якби мали другий шанс (при середньому показнику 9%).

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

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

Дмитрий Лысенко, Web-researcher в Dev-Pro.net, разводит пчел: его пасека насчитывает более 50 ульев. Дмитрий рассказал DOU, чем ему нравится пчеловодство, сколько меда удается собрать за сезон и как совмещать такое хобби с основной работой.

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

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

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

— Что вообще означает пчеловодство? Сколько времени нужно уделять пчелам? Как все это происходит?

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

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

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

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

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

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

— Сколько у вас ульев, пчел? Где они находятся? Какой мед делаете?

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

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

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

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

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

— Насколько пчеловодство — дорогое занятие? И может ли оно быть источником дополнительного дохода для пчеловода-любителя?

Пчеловодство трудно назвать дорогостоящим хобби: пчелы самодостаточны и не требуют каких-то больших затрат. На любительском уровне можно обойтись минимальным инвентарем. Улей с пчелами стоит около $100 (весенняя цена за комплект), медогонка — около $150 для любительской пасеки. Оставшийся инвентарь — пчеловодный костюм, дымарь, стамеска — обойдется еще примерно в $100-200. Это все разовые затраты, которые делаются в самом начале.

Что касается заработка, кто-то продает мед друзьям и знакомым, кто-то сдает оптом экспортеру, кто-то делает медовуху. Чем опытнее пчеловод, тем больше отдачи он получает от своего занятия. Как правило, хороший показатель для новичка — 20-30 кгмеда от одной пчелосемьи. Опытный пчеловод при определенных условиях может получить 50-60и даже 80 кг меда с пчелосемьи. У меня получается собрать в среднем около 30-40 кг —я Intermediate Beekeeper :)

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

Дикий рой отстроил сот и залил медом (слева); пчелиная пыльца (справа)

— Чем именно вам нравятся это занятие? Изменился ли ваш характер после того, как вы начали заниматься пчеловодством?

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

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

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

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

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

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

— Как при общении с пчелами уберечься от травм, не быть покусанным?

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

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

Пасека

— Насколько в Украине развита эта отрасль? Среди пчеловодов больше любителей или же профессиональных пасечников?

Пчеловодство в Украине очень развито. Мы по производству меда занимаем 3-еместо в мире после Китая и Аргентины. Пока что берем за счет количества, а не качества, — на 90% наш мед произведен пчеловодами-любителями. Хотя за последние 3-4года увеличивается количество пасек в 100-200и более пчелосемей. Отдельные пчеловоды-промышленники содержат 500 и даже 1000 пчелосемей.

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

— Как при покупке отличить качественный мед от подделок? :)

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

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

Мед с наличием антибиотиков.У пчел бывают заболевания — вирусные и бактериологические. Лечат их с помощью сильных антибиотиков, которые при определенных условиях могут попадать в мед. Экспорт такого меда в США и страны ЕС запрещен. Западные лаборатории допускают содержание 1 грамма антибиотика в партии 20 тонн меда. На нашем внутреннем рынке таких исследований не проводят. В бытовых условиях, соответственно, этого тоже не определить.

Подделка в виде добавления сахарного сиропа или патоки.Чтобы определить подделку, взвесьте мед, который вам предлагают. При комнатной температуре и нормальной влажности мед имеет плотность 1,430 г/см³. Значит, стандартная литровая банка с медом должна весить 1,830 грамм или около того (учитывая массу банки — 400 грамм). Если на весах вы увидите цифру значительно меньше — это повод задуматься. Также мед должен быть однородным, не допускается никаких расслоений и комочков.

— Какие у вас цели и планы, связанные с хобби?

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

Мене звуть Юлія, працюю General Manager в еквадорському офісі компанії WebCreek. Коли 6 років тому ми з чоловіком-еквадорцем вирішили переїхати з України на його Батьківщину, я спочатку не планувала продовжувати роботу в IT, хоч і мала семирічний досвід на позиціях рекрутера, техрайтера і аналітика у різних компаніях. Але на місці все склалося по-іншому.

Переїзд

Усе почалося з того, що в 2011 році ми з чоловіком приїхали в Еквадор подивитися країну. Вона мені так сподобалася, що я наполягла на переїзді в столицю Кіто.

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

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

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

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

Історичний центр, м. Куенка (Cuenca)

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

Робота

По приїзду попри наміри не працювати в IT, з цiкавостi почала моніторити місцевий ринок: тут є, приміром, Microsoft, але вони більше орієнтуються на продажі, є Tata Consultancy Services, Oracle. Практично всі описи робіт, які знаходила, мене насторожили: грубо кажучи, одна людина повинна була робити все. Наприклад, job description проджект-менеджера (а крім ПМ інших позицій я не знайшла) включав бізнес-аналіз, розбір вимог, створення проектної документації, індикацію проекту (що ок) плюс мити туалети. Позицій аналітика або техрайтера не було в принципі. Тому я не хотіла йти на таку стресову роботу. У нас був невеликий готель, що давав засоби для існування, тож необхідності працювати не було. До того ж тоді я практично не говорила іспанською, тому вирішила уникнути ще одного стресу.

У 2016 ми з чоловіком поїхали подивитися Колумбію, після чого вирішили, що це непогана країна і можна переїхати пожити туди. Я вже пакувала валізи, коли у фейсбуці знайшла оголошення російською мовою, явно не через гугл-транслейт: аутсорсингова компанія в Еквадорі шукає бізнес-аналітиків, проджект-менеджерів, техрайтерів, програмістів. Залишила коментар під оголошенням — зразу запропонували інтерв’ю, на якому була рекрутер (до речі, киянка), і CEO компанії. Співбесіда включала в себе тест на техрайтинг і тест на рівень англійської. Потім запросили в офіс, щоб я поговорила з людиною, яка на той час була Operations Manager. Він розповів про облаштування офісу, правила контракту, також обговорили зарплату. Одразу після цієї розмови запропонували роботу аналітиком, а через тиждень, у січні 2017-го,приступила до праці. Погодилася з цікавості: як це працювати в IT в Еквадорі?

Насправді жодної різниці нема, бо компанія така ж аутсорсингова, headquarter у Техасі, клієнти всі тамтешні. Намагаємося шукати і латиноамериканських, але основна робота все ж у Штатах. Є три офіси — в Хьюстоні, Кіто і Львові. У Кіто працює понад 40 людей: девелопери, неймовірно крута команда дизайнерів, усі проджект-менеджери тут (оскільки основні клієнти з Техасу, Каліфорнії, то дві години різниці в часі не є критичними).

У травні CEO запропонував бути general-менеджером. Я в менеджменті не мала жодного досвіду, але СEO запропонував підтримку і запевнив, що бачить у мені потенціал. Розрахунок був зрозумілим, бо через місяць засновник відправив мене в Україну: відкривати офіс у Львові, який зараз теж потроху розвивається.

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

Пошук житла

Ми з чоловіком орендуємо квартиру недалеко від моєї роботи, в центрі міста, щоб зранку не стояти в заторах. Від офісу до дому — 10 хвилин пішки, 15 на каблуках :)

Двокімнатна квартира (кухня, поєднана з залом і окремо спальня) в жирному центрі міста навпроти головного парку буде коштувати приблизно 400-600доларів на місяць. Трикімнатна квартира за українськими мірками — дві спальні і зал — у центрі міста коштуватиме 600-700 доларів.

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

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

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

Ціни на компослуги

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

За світло плачу 6-7доларів у місяць (при тому, що в мене все електричне: плита, душ нагрівається від електрики). Власник мого лофта має субсидії, тому плачу не так багато. Але в середньому рахунок на сім’ю з двох-трьох людей складе 20-30доларів щомісяця, електрика тут дорога.

Інтернет — це проблема всієї Латинської Америки. Сплачую 23 долари у місяць, швидкість на download — 5 МБ, на upload — 3 МБ. Тобто інтернет такий собі. Є інші провайдери, наприклад, платиш 40 доларів у місяць за швидкість 20 МБ. Коли дивишся фільми, слухаєш музику онлайн на Youtube, переривається, звісно. Коли дощ, з інтернетом теж чомусь колапс. В офісі у нас найдорожчий тариф — 130 доларів у місяць за 100 МБ.

У великих містах на зразок Кіто і Гуаякіля на автобусних зупинках, у туристичних центрах, а в Гуаякілі і в самому громадському транспорті є безплатний Wi-Fi і 4G. 3G і 4G так само є майже всюди в містах. Геть у джунглях і горах узагалі нема зв’язку.

Ціни на нерухомість

Купити квартиру дорого. Ціни завищені, надто в центрі. За 60 тисяч доларів можна купити невеликий дім у спальному районі. Кіто розташований у долині між двома горами, місто вузьке і довге, у довжину — близько 80 кілометрів, а в ширину — центральна частина найвужча — кілометрів 4. Кінець міста бачу з двох сторін на захід і на схід, а південь і північ — дуже далеко.

У спальних районах на півдні і півночі є невеликі конхунто (житлові комплекси) з територією, що охороняється, дитячими майданчиками й іноді навіть басейнами — звідти 40-60хвилин їзди на машині від центру. Там можна купити двоповерховий дім (на 3-4 спальні,два гаражі) приблизно за 60 тисяч доларів. Це залежно від потреб, якщо сім’я велика. Мені це не актуально: робота починається о 8-ій,ще зранку тратити годину на дорогу накладно.

Квартири в центрі дуже дорогі. Ціни стартують від 100-120тисяч за 50-60м². Столиця, центр міста — чого ще чекати. В інших містах ціни нижчі, але з іншого боку Еквадор на економічному підйомі і, думаю, ціни падати не будуть. Три роки тому держава запустила субсидійовану програму будівництва, тут усюди зводять висотки. Усі дружньо передбачали, що ціна на житло впаде, але цього не сталося: ні на оренду, ні на купівлю.

IT-ринок

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

Знайти хорошого проджект-менеджера з досвідом роботи дуже складно. Наприклад, в Україні є тенденція: ти був девом або QA, а потім тобі стало цікаво рости в менеджменті, і ти змінив сферу діяльності. В Еквадорі такого нема. У нас у команді лише одна проджект-менеджер із досвідом роботи в IT-сфері. Один із найсильніших наших проджект-менеджерів займався управлінням на виробництві машин, не в IT. Інший — еквадорець, вчився в Австралії на проджект-менеджера, ми дивом його знайшли.

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

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

Зарплати хороші. Суми приблизно такі ж, як в Україні. Єдине, що мінімальна зарплата в Еквадорі — 386 доларів (це пов’язано з курсом соціалізму). Джуніор-девелопер буде отримувати до однієї тисячі доларів, мідл — до двох. Дешевшою є робота дизайнерів: джун — від 600 доларів; 2-3тисячі доларів, якщо ти директор або суперсеньйор.

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

Податки

Іноземцям із професійною візою можуть запропонувати три типи контракту. Перший — трудовий, тобто людина має статус співробітника. Компанія за тебе частково оплачує офіційну страховку + щомісяця в тебе вираховують до 9,45% на страховку. До того ж двічі на рік є додаткові виплати на зразок нашої 13-їзарплати. Через три роки на трудовому контракті маєш право взяти іпотеку з пониженою відсотковою ставкою.

Другий — на зразок українського ФОПа. Працівник повинен платити 10% податкової ренти і 12% ПДВ. Якщо все правильно декларуєш, то в кінці року можуть до 80% із ренти повернути. Тобто якщо щомісяця платиш 100 доларів ренти, то в кінці року можуть повернути 1000 доларів. Можна платити 20 доларів бухгалтеру, щоб він за тебе все задекларував.

Третій — американський контракт. Він не реєструється в Еквадорі, тому людина з таким контрактом не має платити жодних податків.

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

Менталітет

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

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

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

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

Індійці Kichwa, еквадорська Амазонія

Погода і клімат

Найбільша перевага Еквадору для мене — це його клімат. Кіто розташований на висоті 2800 метрів над рівнем моря. Це додає свого шарму, хоча іноді стаються запаморочення, коли ти ще не адаптувався. Екватор пролягає десь за 20 кілометрів від міста. Завдяки висоті тут весь час погода приблизно як в Україні на травневі свята. Зараз у нас суперзима (це коли на небі хмари й іноді йде дощ). Сонце не прогріває повітря, і температура вдень опускається до 16 градусів тепла щонайнижче. Але більшу частину року світить сонце, 20-27 градусів,яскраво, радісно. Я навчилася не виходити з дому без сонцезахисного крему, бо зі світлою шкірою легко обгоріти.

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

Медицина

Медицина буває державна і приватна. Приватна дорога, прийом у лікаря коштує доларів 10-15,клініки на кожному кроці. Державна медицина — або страхова (якщо в тебе трудовий контракт або страховка), або в принципі безплатна.

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

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

Мови

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

Туризм

Є 4 зони: джунглі, гори, узбережжя, Галапагоські острови. Джунглі — це рослинність, тварини, річки, водоспади. Гори — це і кратерні озера, вулкани, хайкінг куди завгодно. Узбережжя — не Кариби, але в океані хоч і не поплаваєш, на хвилях пострибати можна. Також є місто Монтаніта. Воно вважається серферною і тусовочною столицею Латинської Америки для різних серферів, хіпі, хіпстерів. Грубо кажучи, рибацьке село, куди приїзджають діджеї зі світовими іменами і влаштовують грандіозні тусовки. Є багато маленьких рибацьких сіл, де можна зупинитися на вихідні. Нема інтернету, тільки пляж — сам вимикаєшся і відпочиваєш.

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

Транспорт

У місті і поза ним усі пересуваються автобусами. Великий мінус у тому, що нема поїздів, важко у горах прокладати рейки. Автобусна система дуже розвинена, міжміські автобуси ходять 24/7 з інтервалом у 20 хвилин. Найпопулярніший маршрут із Кіто в Гуаякіль (портове місто) — 8 годин дороги за 12 доларів. Нічні автобуси комфортні безпечні, оснащені системою GPS, спати зручно.

Ще мінус у тому, що нема лоукостів. Переліт між Кіто і Гуаякілем в один бік — 70 доларів. Це дорого, хіба що іноді можна завчасно купити квиток дешевше (я недавно купила за 38, що теж багато за 50 хвилин польоту).

Міських автобусів багато, у годину пік — інтервал 3-5 хвилин,у свята і вихідні — 10-15.Проїзних нема, 25 центів при вході платиш кондуктору. Кондуктор зазвичай висовується з вікна і кричить, куди йде автобус, якщо ти раптом не встиг почитати.

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

У 2014-мув Кіто почали будувати метро. Хоча не знаю, навіщо в Андах вирішили свердлити тунелі під землею, а не, як в інших країнах Пiвденної Америки, прокласти надземне метро. Кажуть, до 2020 року закінчать.

Економіка

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

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

Два роки тому на побережжі Еквадору був сильний землетрус — 7,8 бала, практично всі будівлі були зруйновані. До Кіто дійшло 6 балів — теж добряче труснуло, але без жертв. Це сталося 16 квітня 2016 року, а з 1 червня на 2% підняли ПДВ і податок на експорт. Усі це відчули на собі, почалися протести. Тоді влада запевнила, що це для того, щоб допомогти країні відновити побережжя, що це тільки на 1 рік. І справді, через рік скасували ці податки. Я тоді вперше побачила, щоб податки знижували, а не піднімали.

Із мінусів в Еквадорі — модель соціалізму. Базовий споживчий кошик тут дуже дешевий: на 300 доларів у місяць можна прекрасно жити і харчуватися. Але щойно захочеш трохи більшого, смачнішого, все відразу стає дорогим. Якщо ти середній клас і вище, то платиш значно більше за всі блага. Якщо ж тобі досить їсти рис і курку з помідорами, то за 200-300доларів це реально. В Еквадорі добре бути безробітним індійцем із постійно вагітною дружиною і 8 дітьми, бо буде безплатна школа, медицина, субсидії, може, навіть дім дадуть у селі. А за чий рахунок? Середнього класу, який віддає мінімум 20% на податки.

Техніка тут дуже дорога. Експорт, відповідно, теж дорогий. Позиція влади така: купуйте своє, щоб стимулювати виробництво. Але це смішна позиція, бо Еквадор, наприклад, не виробляє телефонів або лінз для фотоапаратів. Податок на техніку — до 75%. Коли їду в сусідню Колумбію, можу купити телефон за 400-500 доларів,а вдома такий самий коштуватиме 700-800.Податки в еквадорських аеропортах — одні з найвищих у Латинській Америці.

Їжа

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

Ресторани

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

Є поняття комплексного обіду: з 12:00 до 15:00 усі офісні працівники йдуть їсти almuerzo (комплексний обід). Такі обіди готують у спеціальних закладах, які після 15:00 зачиняються. Ціни — від 1.75 до 5 доларів. Варять усе у великих каструлях: окремо каструля супу, окремо каструля рису, риби, м’яса, салату, як правило, з чечевицею або картоплею. Можна замовити страви з меню, а можна швидко взяти almuerzo. До нього обов’язково подають сік і десерт — маленький пиріг або солодкий фрукт. Я всю порцію з’їсти не можу, тому замовляю або перше, або друге.

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

Плюси і мінуси життя в Еквадорі

Якщо взяти все найкраще з України і найкраще з Еквадору, то вийде ідеальна країна. Вони доповнюють одна одну, хороше тут не пересікається з хорошим там.

Еквадор відстає від України в плані трендів, технологій років на 5. Тут усе спокійно, стабільно, ніхто нікуди не спішить. Звісно, жодного стресу, але іноді хочеться чогось живішого, активнішого. До прикладу, тиждень була в Боготі — це мегаполіс. А Кіто більше як велике село: тихо, спокійно, одні і ті ж місця, люди. Одноманіття в Еквадорі врівноважується тим, що практично щовихідних подорожую. Мене дуже влаштовує теперішній варіант: жити тут і частину робочого часу (2-3 місяці)проводити в Україні. Для відпустки є багато варіантів: Куба, Колумбiя, Перу, Мексика, Маямi дуже популярне.

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

Не подобається mañana, звичка все переносити на завтра. Моя знайома північна американка за 14 років тутешнього життя зробила висновок: коли з кимось домовляєшся про зустріч і якщо людина не підтверджує цю зустріч у цей день зранку або максимум за 2 години до домовленого часу, то ти теж не приходиш. З іншого боку, друзі-еквадорці, які подорожують, сприймають час по-іншому, розуміють, що я іноземка, що для мене це не дуже комфортно.

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

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

Привет, я Владимир Павлов, один из авторов проекта и разработчик в smart-MAC (Measure, Analyze, Control). Это умные счетчики с облачным сервером данных и веб-инструментами для анализа и визуализации данных.

Идея

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

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

Команда smart-MAC (слева-направо): Николай Потипака — поддержка, полиграфия и дизайн; Владимир Павлов — разработка программного обеспечения; Сергей Базиленко — программное обеспечение и производство; Алексей Жоголев — R&D и производство; Александр Бибиксаров (не присутствовал, когда делали фото:)) — продажи.

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

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

Реализация

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

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

Умный счетчик — это устройство для мониторинга потребления электроэнергии, которое устанавливается на DIN-рейку с 1 проводом (если одна фаза) или 3 проводами (если 3 фазы) с замеряющими трансформаторами тока (в виде защелки или кольца), которые измеряют поток электричества. По Wi-Fi модулю пользователь подключает устройство (как Wi-Fi клиент) к своей сети, и счетчик передает данные на наш облачный сервер, а по web-интерфейсу пользователь может подключаться к устройству для настройки. Кроме потребленных ватт, электросчетчики измеряют текущие значения тока, напряжения, мощности и косинуса фи (power factor) электросети.

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

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

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

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

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

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

Форма настройки параметров графиков потребления и затрат.

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

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

Как уже упоминалось, сами устройства реализованы в формате установки на DIN рейку в 3-хмодульным корпусе DR50, которые производятся в Днепре. Производство самих умных счетчиков пока мелкосерийное. Монтаж и калибровка устройств выполняются в Киеве. Каждое устройство калибруется под конкретный трансформатор тока, что позволяет добиться высокой точности измерений с погрешностью до 1%.

Для хранения и обработки данных выбрали вариант облачного сервера и веб-приложения для клиента, чтобы универсально решить вопросы совместимости для всех платформ и всех возможных браузеров. На самих энергомониторах код написан на С, сервер — на Node.js, а клиентская часть — на HTML, СSS и JavaScript.

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

У пользователя есть несколько путей для анализа собранных данных. Во первых, это наш дашборд, доступ к которому предоставляется бесплатно для одного устройства. Сам дашборд разработан в виде веб-приложения. Коммуникация между сервером и клиентом осуществляется по WebSocket-протоколу, что обеспечивает двухсторонний обмен информацией в режиме реального времени. Напомню, устройства в режиме реального времени отправляют текущие данные каждые 5 секунд, и пользователь имеет возможность организовать диспетчерский пульт для мониторинга своих объектов online. Во вторых, все устройства могут выступать как MQTT клиент и отправлять данные на сторонний MQTT сервер. В третьих, устройство легко интегрировать с умным домом и сторонними системами учета данных через открытый API интерфейс, который базируется на REST запросах.

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

Результаты

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

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

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

Но если пользователю все-таки хочется управлять своей электросетью, в устройстве есть коммутационное реле для включения или выключения внешней нагрузки. Управляется с Dashboard, Web-страницы устройства, через MQTT и API интерфейсы.

Что дальше

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

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

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

Список возможного к разработке функционала широк. Например, можно сделать срабатывание триггеров и уведомлений (по смс или по email), если потребление резко возрастет/упадет на N-Ватт или параметры измеряемого ресурса выйдут за нормальные пределы, к примеру, 185 вольт вместо положенных 220. Также возможны любые сложные алгоритмы сбора данных и построения графиков по желанию клиента. Клиент даже сможет сделать свои скрипты в нашем коде, благодаря которым он сможет прописать сложные расчеты потребления для разных тарифных планов. В разработке самые разные сценарии обработки данных, для разных моделей потребления.

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

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

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

Денис Прилуцький, Head of PMO у Perfectial

25 років досвіду в ІТ-галузі, з них понад 18 у проектному менеджменті

З чого почати

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

Що далі

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

Як не треба робити

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

Які перші кроки

Враховуючи сучасний стан індустрії, вам знадобиться Agile (Scrum та Kanban), естімації (story points та людино-години), розмовна та письмова англійська на рівні не нижче Intermediate, вміння організовувати та проводити зустрічі і перемовини та володіння найбільш популярними інструментами Atlassian Jira та Confluence. Пам’ятайте, що незалежно від часу основним операційним інструментом ПМ’а залишається Excel (і це не жарт). Привчайте себе мислити системно — завжди майте повну картинку в голові, не зосереджуйтесь на деталях. І пам’ятайте, що 80% роботи ПМ’а — це комунікації. Вчіться говорити з людьми, розвивайте свій емоційний інтелект, опановуйте публічні виступи. Бажаю успіху!

Татьяна Иванова, PMO в Waverley

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

Как прокачать знания:

• Найти, скачать и проштудировать библию PM`а — PMBOK. Даже если концепции, представленные там, не имеют с вашими проектами ничего общего — это та теоретическая база и кейсы, которые расширят ваш инструментарий.
• Scrum Guide, Agile Manifesto, FDD, Kanban... («Википедия» вам в помощь) — знать, прочувствовать, понять границы применимости. И заготовить минимум 15 вариантов не Scrum, но тоже Agile-процессов управления проектами. Это расширит ваш кругозор и даст выбор и свободу от рамок.
• Выбрать инфлюенсеров — успешных PM`ов и наладить контакт. Спрашивать совета. Хорошо почитать биографии — почти все известные люди так или иначе решали задачи управления.
• Участвовать в жизни комьюнити, организовывать свою, обговаривать кейсы и учиться-учиться-учиться.
• Выбирать проекты, которые кажутся чуть сложнее, чем делал до сих пор. Снова учиться. И сюда же — учиться у своих клиентов и членов команды.
• Emotional Intelligence.
• Строить планы (всегда везде и на все), применяя все, что знаешь и умеешь, с тем, чтобы это стало вторым дыханием, поведением по умолчанию, самым очевидным и легким способом действий в любой ситуации.
• Быть или научиться быть самокритичным и честным с собой и окружающими. Не приукрашивать. И уметь философски принимать и хорошее, и плохое, понимая, что одно без другого не приходит.
• Играть в шахматы или любые другие многоходовые игры. Мозг любит тренировки.
• Теория решения изобретательских задач, алгоритмы, теория игр... Это и многое другое, что позволяет мыслить шире и быстрее находить оптимальные решения.

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

А вообще, наверное, главный совет — нужно любить свою работу. Если в IT PM вы попали в погоне за деньгами и сама работа и рутина PM`a вас тяготит, я бы серьезно задумалась о смене профессии. Их много, а вы у себя один (одна).

Олег Кубай, Senior Project manager у CoreValue

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

Project manager — це перш за все досвід. Ніхто не хоче довіряти Project manager без досвіду. Тому задача для PM`ів-початківців — здобути якнайбільше досвіду за обмежений період часу. До цього можна також підійти як до одного з перших проектів, мета якого здобути досвід.

Декілька варіантів, як це зробити:

Find a mentor.Працюйте в парі з досвідченим та успішним PM. Він може бути рольовою моделлю для вас. Ви уникаєте прямої відповідальності, якої може бути забагато на початку, але працюючи пліч-о-пліч, ви маєте можливість побачити безпосередньо, як досвідчений PM працює, і перебрати його найкращі практики. Переважно затребувані PM мають більш ніж достатньо обов’язків, які вони можуть делегувати. Отож, ви можете підміняти його у разі відсутності.

Internal projects.Як правило, в компаніях є проекти для власних потреб (CRM/ERP системи, Security audit, ISO сертифікації, RnD). Дізнавайтеся про такі проекти та беріть у них активну участь. Пропонуйте власний проект, якщо бачите можливість покращити якийсь з бізнес-процесів у своїй компанії.

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

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

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

Александр Даник, Project Manager в Softengi

8 лет опыта в ИТ

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

Определяемся, что «прокачивать». Джунами принято называть людей с незначительным опытом или совсем без него. Хорошо это или плохо, но я не встречал PM`ов без опыта. Люди приходят в менеджмент из смежных областей: кто-то был хорошим team lead, кто-то test lead (последнее чаще). Потому PM — обычно уже с приличным багажом знаний и имеет представление о своих сильных и слабых сторонах. Как вы понимаете, перед такими project managers вопрос, что именно ему прокачивать, не стоит.

«Сходите на собеседования». Да, именно, просто так сходите. Возможно, рекрутеры и не скажут мне спасибо за такой совет, но тем не менее, рекомендую сходить на собеседование в любую другую компанию. Узнаете много нового о себе. Это бесплатно, и результат всегда дает богатую пищу для размышлений. Не хотите ходить на собеседование? Ознакомьтесь со списком требований к кандидатам в топ-компаниях.

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

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

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

Если повторять одно и то же действие в течение 21 дня, оно откладывается в подсознании, и мы начинаем делать его на автомате (source).

Используйте другие источники информации:

• Вступите в группы, где вы можете обсуждать вопросы с другими менеджерами (для поиска таких каналов информации можно использовать группы в Facebook, Telegram, Skype, etc).
• Существует масса курсов для менеджеров. Не знаю, насколько все они адекватны, выбирайте аккуратно, не все йогурты одинаково полезны. Рекламу делать не буду, но среди них есть стоящие.
• Я одно время интересовался конференциями по менеджменту, но не могу сказать, что вынес оттуда много. Мне по характеру больше подходит вдумчивое чтение. Но все люди разные. Может, вам конференции подойдут больше. Найдите то, что работает лично для вас.
• Последнее время появилось много видео на эту тему. По моему мнению, сейчас просто неприлично жаловаться на отсутствие или недостаток информации.

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

• Сю — первая ступень, означающая, что надо заучивать всё точно так, как показывает учитель. Требуется много лет тренироваться, иначе не будет базы для перехода на следующую ступень.
• Ха — вторая ступень, согласно которой нужно освободиться от правил, где правил нет, а есть естественный ход вещей. Многие пробуют делать это слишком рано, поскольку переоценивают свои возможности.
• Ри — третья ступень, означает подняться над всем, что изучалось раньше, создать более высокие и более общие принципы (source).

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

Оксана Гривнак, Project Manager в SoftServe

6 років в ІТ

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

Опираючись на власний досвід, можу поділитись не конкретними прикладними порадами, а швидше своєю професійною філософією. Сподіваюсь, це допоможе тим, хто хоче будувати свою кар’єру у напрямку project management.

Читайте постійнопро все: бізнес і стратегію, нові технології та стартапи, біографії лідерів, історичні події та розвиток економік світу, корпоративні культури та міжкультурні відмінності, емоційний інтелект і мову тіла, командну роботу та психологію, продажі та переговори, менеджмент та лідерство, управління змінами і тайм-менеджмент, фінанси та планування, Agile та SDLC, і, звісно, PMBOK. Шукайте книги, і найпотрібніші знайдуть вас. Пораджу лише останню прочитану, яка досі мене не відпускає — «The Four: The Hidden DNA of Amazon, Apple, Facebook, and Google», by Scott Galloway.

Відвідуйте тематичні події, пов’язані з project management та IT-індустрією, до прикладу: ІТ-Weekend, ІТ-Арена, PM Day; різноманітні конференції, мітапи, презентації, зустрічі тощо. Там можна отримати нові знання, поділитися власним досвідом, переконатися, що унікальних проектних викликів насправді дуже мало, розширити коло своїх професійних знайомств, долучитися до спільнот, які творять проектний менеджмент в Україні і світі.

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

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

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

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

І насамкінець — будьте РМом у всьому і завжди, як у професійному житті, так і поза роботою. Адже Project Manager — це не просто професія, це покликання генерувати синергію людей і таким чином творити гармонію у своєму мікрокосмосі — маленькому чи великому проекті. Це можливість робити світ цікавішим і добрішим :)

Сергей Идельс, Program Manager в Luxoft Ukraine

5 лет опыта

3 must навыка для PM

1. Хорошее управление временем.Если у человека нет никаких знаний по тайм-менеджменту, я очень рекомендую ему их получить. Это планирование дня, трекинг времени на различные активности и их оптимизация, применение техник вроде Pomodoro или аналогичных, что позволяет работать в потоке. PM`у просто нужно выгружать все из оперативной памяти на бумагу. Рекомендую завести блокнот, записывать свои дела, записывать свои мысли для того, чтобы они не «роились» в голове. Это необходимо, так как основное, что получает человек «в подарок», приходя на менеджерскую позицию, — это огромное количество давящих со всех сторон информационных потоков, которые необходимо регулировать.

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

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

Если Junior освоит эти три вещи плюс технический бэкграунд, все вообще будет хорошо. Да, техническая база важна, так как без нее PM`у будет по меньшей мере сложно осуществлять Technical Leadership, а он иногда нужен.

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

3 вещи, которые делать не нужно

1. Если junior PM далеко не junior в какой-то технической специальности в целом, то ему не следует продолжать заниматься тем, чем он занимался раньше. Проще говоря, если он втайне надеется продолжать программировать или тестировать и part-time совмещать это с управлением, то это возможно только короткий промежуток времени. Если junior PM этим увлечется, он может «откатиться назад», развития как менеджера не произойдет. Если это полноценный проект со всеми его характеристиками — общение с заказчиком, планирование, отчетность, P&L, Stakeholder Communication Management и прочее, — то у этого специалиста не хватит времени, чтобы еще «чуть-чуть покодить». Нужно признаться себе, что сделан новый карьерный шаг, и научиться технические задачи делегировать.

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

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

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

Чего мне не хватало на старте моей карьеры, так это Stakeholder Communication Management.Все коммуникации нужно планировать так, чтобы ключевые люди в проекте получали свою частицу времени, а само общение давало своеобразный «выхлоп», результат. Задача Project Manager’а — выступать либо фасилитатором встреч, либо тем, кто вовремя распознает неэффективное принятие решений от участников и изменит ситуацию. Успешный менеджмент этих процессов освобождает время на другие задачи для PM`а.

Где начинать работать джуниору

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

Например, в моей программе достаточно много начинающих PM, с которыми я плотно работаю. Если они потенциально могут совершить ошибку, я им готов помочь ее не допустить и подсказать, что сделать по-другому. Это не значит, что начинать с работы в большой компании — единственно правильный путь. Разумеется, он более комфортный или более безопасный с точки зрения проекта, так как доверять целый проект новичку — это большие риски. Как для компании, так и для самого специалиста, который может быстро «перегореть» и так же быстро закончить карьеру Project Manager’а.

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

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

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

Ниже представлена документация, в которой детально описано, как построить клиентскую библиотеку на iOS, как настроить тестовое приложение, а также как работать с Iroha blockchain с мобильных девайсов.

Инструкция по библиотеке Hyperledger Iroha

Перед тем как приступить к работе, убедитесь, что на вашем компьютере установлено нужное ПО:

• XCode;
• Carthage;
• Git;
• Cmake;
• Postgresql.

Разработанная инструкция была протестирована на следующей конфигурации:

• MacOS Sierra 10.12.6
• Xcode 9.2
• carthage 0.29.0
• cmake 3.11.0
• iPhone 7 iOS 11.2 Simulator

Ключевые функции Iroha:

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

Как нефункциональное требование стоит отметить высокий уровень отказоустойчивости сети (Byzantine Fault Tolerant). Библиотека Iroha iOS позволяет генерировать ключи и управлять подписью транзакций и запросов, которые отправляются в сеть.

Давайте перейдем к более детальной инструкции.

1. Запустите консоль и перейдите в папку, где будет выполняться вся настройка:

cd path/to/your/folder/for/example/iroha-ios/project/

2. Склонируйте репозиторий для клиента под iOS:

git clone https://github.com/soramitsu/iroha-ios.git

3. Перейдите в папку Iroha-ios:

cd iroha-ios/

4. Обновите зависимости:

carthage update --platform iOS

5. Перейдите в папку с примером:

cd SwiftyIrohaExample

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

carthage update --platform iOS

7. Переместитесь в папку, где находится GRPC библиотека:

cd grpc-swift/

8. Удалите ее содержимое (Warning:убедитесь, что вы находитесь внутри grpc-swift/)

# removes all files from the current directory
rm -rf ./*
#removes all hidden files too (so clean build can be done)
rm -rf ./.*

9. Скачайте релизную версию GRCP с git в текущую папку:

git clone --branch 0.3.3 https://github.com/grpc/grpc-swift.git .

10. Скомпилируйте библиотеку:

make

11. Перейдите в корень папки, где выполняется вся настройка (из первого пункта — path/to/your/folder/for/example/iroha-ios/project/):

cd ../../..

Warning:прежде чем продолжить, убедитесь что вы находитесь в path/to/your/folder/for/example/iroha-ios/project/

12. Этим шагом загружается скрипт для клиентской библиотеки, который ее соберет. Загрузим ее с git:

curl https://raw.githubusercontent.com/hyperledger/iroha/master/shared_model/packages/ios/ios-build.sh > ios-build.sh

13. Дадим права на выполнение загруженному скрипту:

chmod +x ios-build.sh

14. В конце соберем библиотеку. Доступно две опции — платформа: OS | SIMULATOR | SIMULATOR64; тип сборки: Debug | Release:

./ios-build.sh SIMULATOR64 Debug

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

# this command shows location for simulator artefacts
# use this command for device instead:
# mkdir -p iroha-ios/libs/iOS/
mkdir -p iroha-ios/libs/Simulator/

16. Скопируем артефакты:

# this command shows location for simulator artefacts
# use this command for device instead:
# cp lib/* iroha-ios/libs/iOS/
cp lib/* iroha-ios/libs/Simulator/

17. Так же скопируем заголовочные файлы:

cp -a include/. iroha-ios/headers/

18. Теперь нужно сконфигурировать проект в Xcode для примера. Откроем SwiftyIroha.xcodeproj:

19. Выберем SwiftyIrohaExample.xcodeprojи вкладку general, добавим SwiftProtobuf из папки <code>iroha-ios/SwiftProtobuf.framework:

20. Перейдем в SwiftGRPC.xcodeproj и удалим zlib-example из секции target:

21. Выберем группу Proto и удалим ее (в следующих релизах этот шаг не будет нужен):

22. Поздравляем! Все шаги выполнены. Выберем SwiftyIrohaExample и симулятор для iPhone, соберем приложение, чтобы убедиться, что нет ошибок сборки:

23. Перед тем как запустить приложение и протестировать его, нужно запустить Iroha на локальной машине.

Шаги 1-17 ненужно выполнять вручную каждый раз — для этого есть скрипт.

Скрипт для установки и настройки клиента под iOS:

iroha_preparation_script.sh 
#!/bin/bash
#download ios client and update dependencies
git clone https://github.com/soramitsu/iroha-ios.git
cd iroha-ios/
carthage update --platform iOS
cd SwiftyIrohaExample
carthage update --platform iOS
#build grpc client for sample application
cd grpc-swift/
rm -rf ./*
rm -rf ./.*
git clone --branch 0.3.3 https://github.com/grpc/grpc-swift.git .
make
#back to the root where script was executed
cd ../../..
#download and build Iroha library for iOS
curl https://raw.githubusercontent.com/hyperledger/iroha/master/shared_model/packages/ios/ios-build.sh > ios-build.sh
#optional step - sometimes connection timeout appears when using git: scheme instead of https url
sed -i '' 's|git://github.com/hyperledger/iroha-ed25519|https://github.com/hyperledger/iroha-ed25519.git|g' ios-build.sh
#build library
chmod +x ios-build.sh
./ios-build.sh SIMULATOR64 Debug
#place artefacts to proper sample's locations
# this command shows location for simulator artefacts
# use this command for device instead:
# mkdir -p iroha-ios/libs/iOS/
mkdir -p iroha-ios/libs/Simulator/
# this command shows location for simulator artefacts
# use this command for device instead:
# cp lib/* iroha-ios/libs/iOS/
cp lib/* iroha-ios/libs/Simulator/
cp -a include/. iroha-ios/headers/

Запуск узла Iroha

В качестве хранилища Iroha использует PostgreSQL. Для начала создадим сеть в Docker, чтобы контейнеры для Postgres и Iroha могли быть запущены в одной виртуальной сети и могли передавать данные. В качестве имени используем iroha-network, но можно указывать любое имя. В консоли запустите следующую команду:

docker network create iroha-network

Запуск контейнера PostgreSQL

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

docker run --name some-postgres \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=mysecretpassword \
-p 5432:5432 \
--network=iroha-network \
-d postgres:9.5

Note:если уже запущен Postgres и использует порт по умолчанию(5432), должен быть выбран другой порт, например, 5433: -p 5433:5432 \

Создание хранилища блоков

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

docker volume create blockstore

Настройка сети Iroha

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

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

git clone -b develop https://github.com/hyperledger/iroha --depth=1

Запуск контейнера Iroha

Warning:Убедитесь, что вы находитесь в папке path/to/your/folder/for/example/iroha-ios/project/

Команда docker run использует относительный путь: iroha/example

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

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

docker run -it --name iroha \
-p 50051:50051 \
-v $(pwd)/iroha/example:/opt/iroha_data \
-v blockstore:/tmp/block_store \
--network=iroha-network \
--entrypoint=/bin/bash \
hyperledger/iroha-docker:develop

Давайте рассмотрим ее в деталях:

• docker run -it —name iroha \ связывает нас с контейнером под именем iroha.
• $(pwd)/iroha/example:/opt/iroha_data \ добавляем папку, где находится файл конфигурации в папку контейнера /opt/iroha_data.
• -v blockstore:/tmp/block_store \ добавляем хранилище данных в контейнер.
• —network=iroha-network \ соединяем контейнер с созданной сетью под именем iroha-network, так чтобы Iroha и Postgres видели друг друга.
• —entrypoint=/bin/bash \ Hyperledger/iroha-docker выполняет свой скрипт после запуска. На этом этапе нам нужно переопределить точку входа, чтобы запустить Iroha демон вручную.
• hyperledger/iroha-docker:develop \ изображение из ветки develop.

Запуск Iroha демона

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

irohad --config config.docker --genesis_block genesis.block --keypair_name node0

Вот так будет выглядеть результат успешного запуска узла:

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

А так будет выглядеть результат в консоли (где запущен узел):

Отлично! Мы отправили транзакцию в блокчейн и проверили ее наличие после.

Скрипт для настройки Iroha ноды:

 iroha_preparation_script.sh
IROHA_CONTAINER='iroha'
POSTGRESS_CONTAINER='some-postgres'
IROHA_NETWORK='iroha-network'
#fresh install
docker container kill $IROHA_CONTAINER
docker container kill $POSTGRESS_CONTAINER
docker container rm $IROHA_CONTAINER
docker container rm $POSTGRESS_CONTAINER
docker network rm $IROHA_NETWORK
docker network create $IROHA_NETWORK
docker run --name $POSTGRESS_CONTAINER \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=mysecretpassword \
-p 5432:5432 \
--network=$IROHA_NETWORK \
-d postgres:9.5
docker volume create blockstore
docker run -it --name $IROHA_CONTAINER \
-p 50051:50051 \
-v $(pwd)/iroha/example:/opt/iroha_data \
-v blockstore:/tmp/block_store \
--network=$IROHA_NETWORK \
--entrypoint=/bin/bash \
hyperledger/iroha-docker:develop

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

irohad --config config.docker --genesis_block genesis.block --keypair_name node0

Детальная видеоинструкция

Выводы

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

Главное преимущество перед другими решениями — мобильные клиенты работают напрямую с блокчейном без промежуточного звена. Благодаря этому преимуществу и в целом отличной адаптации под мобильные устройства у Iroha есть огромный потенциал стать частью решений MBaaS (mobile backend as a service).

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

[Алексей Скориков — Delivery Manager в Intellias, спикер, пилот, программист, MSCS. В разных ролях работает в IT с 2003 года]

Daniel Goleman, Richard E. Boyatzis, Annie McKee «Primal Leadership, With a New Preface by the Authors: Unleashing the Power of Emotional Intelligence»

В русском переводе —Дэниел Гоулман, Ричард Бояцис, Энни МакКи «Эмоциональное лидерство. Искусство управления людьми на основе эмоционального интеллекта»

Эту книгу в свое время мне порекомендовал мой ментор. Позднее заметил ее в библиотеке Стэнфорда на полке с литературой, обязательной для подготовки по программе «Executive Program in Leadership». Домой уехал со своей бумажной копией.

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

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

Morag Barrett «Cultivate: The Power of Winning Relationships»

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

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

Benjamin Hardy «Willpower Doesn’t Work: Discover the Hidden Keys to Success»

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

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

Austin Kleon «Steal Like an Artist: 10 Things Nobody Told You About Being Creative»

В русском переводе — Остин Клеон «Кради как художник. 10 уроков творческого самовыражения»

В украинском переводе — Остін Клеон «Кради як митець. Креативні „фішки“, про які тобі ніхто не розповість»

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

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

Viktor E. Frankl «Man’s Search for Meaning»

В русском переводе — Виктор Франкл «Человек в поисках смысла»

В украинском переводе —Віктор Франкл «Людина в пошуках справжнього сенсу. Психолог у концтаборі»

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

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

За допомогою емпатії у центр усіх процесів ставимо не технології, а людину

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

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

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

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

Дизайн допомагає перевірити найбожевільніші ідеї з мінімальним ризиком і витратами

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

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

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

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

Воркшопи — «серце» дизайн-досліджень

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

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

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

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

Дизайнер — це не картинкомалювач, а ідеолог

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

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

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

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

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

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

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

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

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

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

Для початківців раджу не оминати увагою ґрунтовну літературу класиків дизайну, як-от книги Нормана, Нільсена чи Купера. Але що більше досвіду має дизайнер, то більше варто зазирати у майбутнє — прогнозувати дизайн-методологію, яка стане популярною через 3, 5, 10 років. Тут стануть у пригоді статті про дизайн на Medium, а також підписка на світові медіа про технології, наприклад, TechCrunch, Designboom, Uideo, Smashing Magazineта інші.

Дизайнер повинен брати участь у всіх процесах, зокрема й у переговорах із керівниками компаній

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

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

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

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

Це розвиває вміння бачити більшу картину. Знати Photoshop чи Sketch уже недостатньо. І тому треба розвивати нові компетенції у суміжних галузях. Наприклад, ми рік тому почали організовувати для дизайнерів проходження міжнародних програм сертифікації у Nielsen Norman Group та інших інституціях.

Висновки

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

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

Культура

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

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

Рынок труда

Прямо напротив моего дома — бизнес-центр с логотипом SoftServe, компании, которую все, наверное, знают в Украине. Чуть дальше — EPAM, через дорогу — Accenture. Есть здесь и Luxoft, и Playtech. Наверное, самый большой игрок — VMWare с RnD-центром на 2,5 тыс. человек. Большой исследовательский центр в Софии есть и у Hewlett-Packard, расширяется Uber, появился SBTech, хорошо известный в Украине. В общем, когда я решил сменить работу, варианты были, и DataArt я выбрал сознательно.

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

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

Язык

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

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

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

Формальности

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

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

Но получение разрешения на пребывание постоянно упрощали, и сейчас это занимает около двух месяцев. Сама процедура такая: для начала нужно получить налоговый номер. Для этого ты должен либо сам приехать в Болгарию (для чего виза, конечно, не нужна) и прийти в местную налоговую, либо написать на болгарском болгарскому адвокату доверенность. Тогда он сделает это за тебя. Когда налоговый номер присвоен, ты подписываешь контракт, регистрируешь его в налоговой, тогда компания подает запрос на разрешение на работу для тебя — blue card — в агентство занятости. Они его рассматривают обычно около месяца, но в моем случае на это ушло 2,5 месяца — время совпало с летними отпусками. Документов нужно много: переводы дипломов, трудовой книжки и т. д., но если вас пригласили те, кто уже кого-то перевозил, проблем не будет. Я это вижу по компании, где работаю сейчас.

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

Переезд семьи

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

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

Дополнительные документы

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

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

Налоги

По сравнению с ИП и ЧП, налоги в Болгарии выше. НДФЛ — 10% плюс дополнительные отчисления в пенсионный фонд, в соцстрах, на обязательное медицинское страхование. Я когда-то подсчитывал, получалось процентов 15-16для программистов. Здесь вообще получается интересно: чем больше ты зарабатываешь, тем меньше налогов в процентном отношении платишь. Ставка плоская, а многие платежи фиксированные. Поэтому, скажем, Java-архитектором быть здесь ну просто очень выгодно.

Жилье и безопасность

Цены на жилье здесь такие же, как в Киеве. Приличную двушку можно в нормальном районе можно снять за 300–400 евро.Из моего окна видны и панельки, где цены намного ниже, но обычно там айтишники не живут.

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

Транспорт

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

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

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

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

Путешествия

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

Можно побывать в странах, куда вряд ли догадаешься поехать из Украины: в Сербии, Македонии, Румынии. В Сербию и Македонию я уже по паре раз ездил, там очень красиво. А Сербия вообще удивляет — после американских фильмов от нее ждешь чего-то совсем другого, а это очень уютная, цивилизованная страна. Белград мне вообще очень понравился. К тому же в Сербии постоянно проводят какие-то фестивали еды: самой разной, вплоть до картошки. Тогда из Софии может стоять пробка прямо до Димитровграда — первого приграничного сербского города. Он ведь всего в 60 километрах. Люди едут просто поесть чего-то особенного и затариться едой — она там в принципе дешевле, а во время таких праздников цены еще ниже.

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

С ребенком

Наш ребенок родился уже в Болгарии. Кстати практически все семьи из Украины или России, кого мы знаем по местной тусовке, либо уже родили здесь, либо собираются. Здесь есть all-inclusive-сервис: выбираешь родильный дом, платишь фиксированную сумму (примерно 900-2000 евро).После этого они делают все осмотры во время беременности, принимают роды, когда придет время, обеспечивают и маму, и ребенка всем необходимым, включая питание и одежду. Даже если вы приехали раньше, но врач решает оставить женщину в больнице, доплачивать не придется. Я после родов просто забрал жену, а заодно еще и кулек всяких подарков от роддома. Сервис мне понравился.

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

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

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

Фрукты и выпивка

Еда в Болгарии очень вкусная, качество продуктов мне очень нравится. Хотя сами болгары им все время недовольны, говорят: вот раньше было другое дело, пока испанских помидоров не навезли, гадости. Но у меня вопросов не вызывают ни болгарские, ни испанские, ни греческие, ни турецкие, которые можно здесь купить. В отличие от Украины, выбор не слишком зависит от сезона: все время есть практически все. И цены меняются не так драматически, клубника может подорожать зимой, но процентов на 20. Летом можно по 2 евро покупать отличный инжир и вообще круглый год объедаться хоть местными, хоть привозными фруктами. Из инжира, кстати, получается отличное варенье, с ним продают булочки и пирожки.

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

Тусовка

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

Связь и интернет

У меня с ним проблем не было. Из того, что я знаю об инфраструктуре, — в Болгарии хаб, где проходят оптоволоконные кабели из Европы в Азию. Так что если тебе бывают нужны китайские, японские, русские сайты, здесь соединение даже лучше. Связь, пожалуй, подороже, чем в Украине, но уж точно дешевле, чем в Западной Европе. Я плачу 10 евро в месяц за 4G, 3 Гб в месяц. При этом, покупая пакет мобильной связи, ты сразу же получаешь и европейский роуминг. Так что можешь совсем не беспокоиться, если выехал в Германию или ближнюю Грецию.

Сложности

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

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

Городская жизнь

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

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

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

Привет! Меня зовут Владимир Курило, я создатель и CEO продуктовой компании CleverStaff, разрабатывающей и поставляющей одноименный софт для подбора персонала. Наша система автоматизирует самые трудоемкие процессы в рекрутинге: поиск подходящих соискателей во внешних ресурсах, ведение базы кандидатов и организация взаимодействия с ними на стадиях отбора. Кроме того, наш софт полезен в работе команды рекрутеров, когда нужно быстро и удобно делегировать задачи, составлять отчеты, отслеживать эффективность методов и сотрудников. До CleverStaff я работал в банковской сфере Java-программистом, Team Lead и начальником департамента ИТ.

Идея проекта

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

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

Часть команды CleverStaff

Реализация

На бекенде CleverStaff ATS использует PostgreSQL, Java 8, Apache Tomcat, Apache Solr, а на фронтенде — AngularJS и Bootstrap. Самое ценное, что есть у рекрутера, — его база кандидатов и история взаимодействия с ними — может храниться в облаке или на сервере пользователя. У системы также есть расширение для Google Chrome для быстрого добавления резюме из внешних ресурсов в свою базу.

Первый релиз CleverStaff мы выкатили всего через 5 месяцев после начала разработки — в сентябре 2014-го.Вся разработка и техподдержка делалась силами пяти человек из одесского офиса. Самая первая версия CS представляла собой удобный пользовательский интерфейс для хранения всех данных по подбору персонала и поиска по ним.

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

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

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

Фейлы

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

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

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

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

Результаты и планы

CleverStaff сегодня — это прибыльный растущий сервис. Нашей системой пользуются в основном рекрутинговые и ИТ-компании в разных странах мира (более 30-тистран, по состоянию на май 2018 года). Большинство клиентов, конечно, из Украины и соседних стран, но есть пользователи даже из Бразилии и Новой Зеландии.

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

Нашим большим конкурентным преимуществом я бы также назвал интеграцию как с глобальным рынком талантов (LinkedIn), так и с локальными HR-рынками. Парсинг резюме, помимо стандартного английского, у нас доступен на 13-тиязыках Восточной и Центральной Европы: русском, украинском, чешском и других. Мы постоянно работаем над интеграцией системы с популярными локальными сайтами поиска работы: superjob.ua, hh.ua, hh.ru (Россия), hh.kz (Казахстан), hh.by (Беларусь), CV-Online (Прибалтика и Польша), job.kg (Кыргызстан), — всего больше десяти ресурсов.

Расширение формата и дальнейшие планы

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

В середине мая этого года мы провели наше первое офлайн-мероприятие для рекрутерского сообщества — CleverHR Party, — на которое пригласили наших клиентов и просто всех, кто в теме. Ивент мы задумали так, чтобы пользователи системы смогли донести свой фидбэк непосредственно до тех, кто делает CleverStaff: проджект-менеджера, техподдержки, тестировщиков. Часть нашей команды таким образом успешно развиртуализировалась :)

CleverHR Party в самом разгаре

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

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

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

Часто в повседневной работе продуктовой компании в отделе Business Intelligence (или его зародыше) могут встречаться ad hoc задачи по выгрузкам из БД. Если их много, то они могут занимать почти все рабочее время без перерывов на более инновационную и результативную работу. В результате страдает как бизнес, так и сотрудники компании.

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

Зачем это нужно

В отделе Business Intelligence OLX мы работаем с отделами монетизации, маркетинга, продукта, безопасности, поддержки пользователей в 3-хстранах — Украина, Казахстан, Узбекистан. Иногда прилетают задачи и из других стран. Отдельно стоит выделить работу в B2B Unit, где аналитики нашего отдела создали инновационную CRM-систему для работы колл-центров разных стран. Но об этом чуть позже. А сейчас рассмотрим проблему простых, коротких задач, которые могут отнимать много времени, так называемые ad hoc задачи, которые аналитикам стоит обходить стороной или уметь их держать под контролем, чтобы в них целиком не погрязнуть.

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

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

Кроме того, автоматизация дала бы возможность прозрачно вести учет обращений от каждого менеджера, делать историю обращений и времени обработки запросов в БД. До этого под каждую задачу писались скрипты на Python, R, PHP. Все скрипты были в разных местах на сервере, что создавало определенные неудобства и многочисленные дубли кода. Стоит отметить, что в компании используются разные инструменты под разные типы задач. Я же сторонник использования BI CRM.

За первый месяц внедрения BI CRM обработала около 500 запросов менеджеров, не считая автоматических выгрузок по cron. Что позволило значительно снизить нагрузку на BI отдел, увеличить скорость получения данных для менеджеров, построить аналитику по частотности SQL-запросов. С точки зрения разработчика, это кажется вполне логичным и обоснованным решением — создать единую контролируемую точку входа и сохранять различные метрики по использованию. Однако к этой идее мы пришли не сразу. Итак, начнем с истории.

Каталог SQL-запросов

Вначале было создано нечто вроде каталога SQL-запросов. Принцип довольно прост. Есть таблица с SQL-скриптами, есть PHP-скрипт, который по cron выполняет каждый запрос SQL. У такого решения есть недостатки. Нет нормального фронтенд-интерфейса для работы, нет статистики по запросам, отсутствует интерактивность и т. п. Мы все еще продолжали часто пользоваться отдельными скриптами, которые запускались по cron.

API для работы с БД в Excel

Когда стало приходить много задач типа «выгрузи мне данные по такому-то параметру», появилась идея API для работы с БД в Excel. Что уже лучше, впервые менеджер сам мог использовать API, не обращаясь к аналитику. Можно контролировать обращения менеджеров, нагрузку на БД. API состоял из двух типов SQL-запросов и представлял собой изнутри, по сути, все тот же каталог SQL-запросов. Первый тип запроса взял символ «R» из CRUD и позволял прочитать все, что находилось в базе по какому-то ID. Второй тип — предопределенные запросы, составленные аналитиком. Например, аналитик создает функцию посчитать количество объявлений пользователя и называет ее «get_count_ads». После этого к этой функции можно обращаться по GET-запросу.

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

Идея BI CRM

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

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

Инструменты создания: PHP, MySQL

Базы, с которыми работает система: Amazon Redshift (PostgreSQL), MS SQL, Amazon MySQL.

Архитектура интерфейса

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

Если первые очень похожи на старый, добрый автообновляемый каталог запросов SQL, то вторые — это новое custom-решение. Здесь задача называется «Шаблон». Аналитик создает шаблон SQL-запроса и задает плейсхолдеры. Выглядит шаблон таким образом:

SELECT * FROM payments
WHERE id_user IN (#1)
AND created_at  BETWEEN #2 AND #3

Здесь #1 — это плейсхолдер для подстановки набора user_id, #2 и #3 — интервал дат.

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

Примеры: Text — textarea для ввода списка чисел или списка слов. Input — небольшое текстовое поле, Category — предопределенный набор данных в виде списка, который хранится в системе.

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

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

Отдельно стоит упомянуть более сложные типы плейсхолдеров: категории, города и т. п. Технически они хранятся в таблице predefined в формате: id, element_id, name, type, id_country, value. Где type — это тип, например category, value — это список id через запятую. Он представляет из себя список значений id, например категорий. Впоследствии значения используются в запросе: SELECT * FROM predefined_items WHERE id IN (values). То есть все сложные плейсхолдеры имеют стандартный формат записи.

Что под капотом

Внутренняя часть основывается на самописной CRM (техническое название движка — crud crm), которая уже использовалась в OLX ранее и хорошо себя зарекомендовала. Система представляет собой конструктор CRM для быстрого развертывания (в течение часа) CRM разных видов, будь то для техподдержки пользователей или колл-центра. Именно на этой CRM обрабатываются вопросы и баг-репорты клиентов по OLX-доставке. Внутри это CRUD-система (PHP, Twig, MySQL), ядро которой состоит из соответственно добавления, чтения, обновления, удаления любых типов данных. Есть предустановленный шаблон, который автоматически генерирует визуальные элементы на основе последовательности, заданной в конфигурации. Есть возможность использовать свои custom-шаблоны, что мы и делали, так как менеджеры в основном хотят видеть только то, что им нужно.

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

Пример обновления столбцов в ядре:

foreach ($listColumns as $column) {
	$sql = "UPDATE $table SET `$column`='{$itemArr[$column]}' WHERE id=$id";
	$this->db->exec($sql);
}

Пример инициализации CRUD CRM в index.php:

require_once "init.php";
/*
 *  Подключение ядра
 */
/* ... */
/*
 * Инициализация ядра
 */

$appCrud = new Crud($connections);

$appCrud->addTwig($twig);

// Создание URL
$appCrud->addPath("bicrm");
/*
 * Создание страницы (в админке, в левой части появится пункт меню)
 * table_name - название таблицы для CRUD, column_names - человеческие названия столбцов в БД
 */
$appCrud->addPage(array(
    "title" => "BI CRM SQL",
    "table_name" => "query",
    "column_names" => array("id" => "Id","id_db" => "DB","title" => "Title",
        "id_schedule"=>"Scedule","id_category"=>"Category",
        "id_rewrite_report"=>"Write Type",
        "running"=>"Running",
        "last_update_date" => "Last update","email" => "Email"),
));

/*
 * Сколько элементов выводить на страницу
 */

$appCrud->setMaxItemsOnPage(20);
/*
 * Задаем отображение столбцов из БД в интерфейс пользователя (HTML)
 */
$appCrud->setTypeField("query","text");
/*
 * Повесим на столбец first_date_start JS календарь
 */
$appCrud->setTypeField("first_date_start", "datepicker");

/*
 * id_db будет выпадающим списком, данные брать из таблицы db (в таблице db данные содержатся в формате id, value)
 */

$appCrud->setTypeField("id_db", "combobox",array("table" => array("db")));
$appCrud->setTypeField("id_schedule", "combobox",array("table" => array("schedule")));
$appCrud->setTypeField("id_category", "combobox",array("table" => array("category")));
$appCrud->setTypeField("id_rewrite_report", "combobox",array("table" => array("rewrite_report")));

$appCrud->addPage(array(
    "title" => "BI CRM Template",
    "table_name" => "template",
    "column_names" => array("id" => "Id","id_db" => "DB","title" => "Title",
        "id_category"=>"Category",
        "id_rewrite_report"=>"Write Type",
        "running"=>"Running",
       "email" => "Email"),

));

if($appCrud->isLoggedUser()) {
    $appCrud->render("index");
} else {
    $appCrud->render("login");
}

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

Внутренняя архитектура BI CRM

Обновление запросов организовано следующим образом:

По cron запускается scheduler, который ищет задачи для выполнения по условиям:

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

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

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

Что в итоге

• Систематизирована работа аналитиков и менеджеров, ведется учет полного цикла их работы.
• Менеджеры получают данные моментально.
• У коллег появилось время для работы над более сложными задачами. Решена проблема потери времени и ресурсов из-за ad hoc задач.

В будущем запланированы:

• интеграция PivotTable.js для построения pivot и визуализации данных прямо в «Представлении»;
• умный редактор SQL-кода;
• интеграция Python, R, PHP-скриптов в BI CRM.