[Об авторе: Максим Ицкович — СЕО компании Mobindustryи глава правления Днепровского IT кластера]

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

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

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

Касается ли Украины, а в частности украинского IT, феномен ресурсного проклятия, и если да — то как с этим бороться? Именно об этом и пойдёт речь в статье.

Что происходит с IT в Украине и за её пределами

Чтобы понять это, давайте посмотрим на официальные данные.

Наиболее обширная статистика, которую я сумел раздобыть, принадлежит корпорации Evans Data. По их данным, в мире на 2016 год — 21 миллион профессиональных разработчиков. При этом 60-65%всех айтишников мира сосредоточено в Европе, Африке и Азии. Посмотрим поближе на Европу. 263 тысячи разработчиков — именно столько находилось в Украине на 2014-йгод. В России почти 900 тысяч, а в Польше — 295.

Теперь давайте посмотрим на этот график:

Здесь мы видим данные мирового аутсорсингового рынка в целом, собранные американской консалтинговой компанией At Kearney. Ежегодно она проводит исследования по рынкуи оценивает каждую страну по трём критериям:

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

Как видите, несмотря на то, что в Польше меньше разработчиков, чем, к примеру, в той же Индии или России, она занимает достаточно высокое 12-еместо. Добилась она этого за счёт простоты ведения бизнеса, поднявшись ещё на на две позиции в этой категории в 2017 году по сравнению с прошлым годом.

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

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

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

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

Давайте разбираться. В чем проблема?

Проблема в перегретом рынке

Это показал опрос, проведённый среди IT-компаний.

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

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

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

Преимущества Украины для аутсорсинга

Конкурентное качество. Украинский сервис является достаточно высококачественным на мировом рынке IT, особенно по сравнению с азиатскими сервисами, в противовес которым многие строят свой главный конкурентный месседж (мы же не индусы!).

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

Просто сравнитесредний американский рейт в $120/час, и украинский — $30/час, и станет понятно, почему американским клиентам выгоднее работать с Украиной.

Близкий часовой пояс. Разница между США и Украиной по времени составляет от 7 до 12 часов. Кажется, что это не так уж и мало, но даже при таких условиях возможность обеспечивать ежедневное общение между украинскими разработчиками и американскими заказчиками всё равно есть, а это очень важно для успеха проекта.

Между США и той же Индией, к примеру, разница составляет уже 10,5-14 часов.При таком раскладе прийти к какому-то общему знаменателю можно лишь в ночное время для одной из сторон.

Между Европой и Украиной разницы во времени нет практически совсем, поэтому сдвиг в сторону работы с европейскими заказчиками с каждым годом кажется всё вероятнее.

Недостатки Украины для аутсорсинга

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

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

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

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

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

Слабое предпринимательство. Это самая главная проблема Украины — мы не умеем продавать, не умеем превращать идеи в бизнес. В то время как в Америке люди с детства учатся предпринимательству (вспомните гаражные распродажи или лимонады на улице), на украинской территории 25 лет назад за коммерцию была предусмотрена уголовная (сначала административная) ответственность. Закономерно, что и по сей день что-то продавать считается чуть ли не постыдным.

Тем временем, в мире на первое место выходит сервис

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

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

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

Всё идёт к тому, что вскоре место товаров в мире займёт именно сервис. Поэтому Украине нужно ускорять своё движение от сервиса по разработке проектов к сервису разработки продуктов.

PSD 2.0 (Product development services 2.0)

Напоминаю, мы говорим в контексте сервисных IT-компаний. Поэтому универсальный совет «делайте продукты» находится за пределами нашей темы.

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

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

Итак, решение проблемы аутсорса в Украине:

Превратиться из поставщиков ресурса разработчиков — в производителей высокотехнологичного продукта с высокой добавочной стоимостью (product as a service).

Как и что делать

0. Думайте о клиенте вашего клиента

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

1. Выучите английский. Сейчас же

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

2. Дайте своим детям достойное образование и опыт

Сейчас существует масса программ по обмену опытом для детей и студентов, где ваш ребёнок сможет получить знания и опыт совершенно другого уровня, которые затем сможет привезти в Украину. Этим занимаются следующие организации: AIESEC, Work and Travel, Sokhnut.

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

3. Учитесь сами. Каждый день

• Цените преподавателей и учителей. Не относитесь к этой профессии как к второсортной, потому что именно учителя — это те, кто строит наше будущее.
• Выделите бюджет и время на своё образование. Это должно стать таким же важным, как выделять деньги на еду.
• Учитесь маркетингу, прислушивайтесь к зарубежным практикам. В этом плане Украина очень сильно отстаёт, поэтому изучайте и внедряйте свежие идеи.
• Учитесь менеджменту. Украинская практика управления беспощадно устарела — мы применяем то, что уже 30 лет назад начало устаревать в тех же Штатах. Кому интересно, можете почитать про теорию спиральной динамики.

4. Развивайте культуру предпринимательства в Украине

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

5. Обменивайтесь опытом

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

6. Имейте терпение

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

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

Вывод

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

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

Тема перехода от ресурсного к продуктовому сервису — основная тема конференции ITEM 2018, где будут рассмотрены практические кейсы и решения, которые можно внедрить уже сейчас в каждой IT-компании.

Цього разу DOU Ревизорзавітав до Intellias — української аутсорсингової компанії, яка була заснована у Львові у 2002 році. Сьогодні в офісах у Львові, Києві та Одесі — понад 800 спеціалістів.

У львівських офісах Intellias наразі працюють 552 спеціалісти, 476 з них — у бізнес-парку «Оптіма Плаза», 76 — в офісі на вул. Парковій. З тих, хто працює в «Оптіма Плаза» — 400 технічні спеціалісти та 76 — нетехнічні.

В околицях і поблизу

Найбільший львівський офіс Intellias знаходиться в приміщенні бізнес-парку «Оптіма Плаза» за адресою вул. Наукова, 7Д. Ми вже писали цікаві факти про цей «зелений» бізнес-парк, коли робили огляд Sigma Softwareцього літа. З того часу центр отримав ще декілька міжнародних премій: EE Real Estate Awards 2017 у сфері «зеленого будівництва» та офісний проект року, а також кришталеву цеглу за найкращу будівельну інвестицію по обидві сторони східного кордону Європи. Самі спеціалісти компанії зауважують, що в забудові є лише один недолік — ліфти, які курсують як громадський транспорт, зупиняючись на кожному поверсі, і їх можна довго чекати в години пік.

Ми не можемо об’єктивно оцінити розташування офісу, оскільки були в компанії лише один день. Але Львів — не надто велике місто: щоб доїхати від офісу до центру міста громадським транспортом, знадобиться 15-20 хв.

Поруч з офісом немає великого різноманіття закладів громадського харчування. У приміщенні Парку є лише бістро «Смачні сезони» (середній чек ≈ 50-70 грн).А от за 5 хвилин транспортом можна дістатися до ТЦ Victoria Gardens, фудкорт якого налічує більше 10 кафе та ресторанів (середній чек у кожному ≈ 100 грн). В офісі Intellias є також власне кафе «Томато», яке пропонує повноцінне меню для обідів та перекусів. Середній чек тут складе ≈ 70-90 грн.Недалеко від офісу знаходиться супермаркет «Сільпо», а в самій будівлі бізнес-парку — спортивний комплекс Sport Life.

Машину можна залишити на відкритій парковці внутрішнього двору (650 грн на місяць) або в критому паркінгу (900 грн на місяць). За паркування працівники сплачують самостійно. Для велосипедів зроблена крита вертикальна парковка.

Робочий простір

Загальна площа офісу Intellias — близько 6500 м². Компанія займає 6, 7 та 8 поверхи. Тип проектування робочих зон змішаний — тут є і звичні опенспейси, і кабінети, розраховані на команди з 7-10 осіб.Не можна не відзначити велику кількість мітинг-румів. Їх тут 19 без врахування фон-боксів.

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

На одну людину в офісі припадає 11 м²робочого простору (за даними компанії).

Відпочинок і натхнення

Офіс облаштовано так, щоб задовольняти не лише базові потреби працівників. Окрім кухонь на кожному поверсі та fun room з тенісним столом, є і дещо цікаве:

• Невеликий масажний кабінет, в якому на постійній основі працюють 2 масажисти. Кожен співробітник має можливість 2 рази на місяць записуватися на прийом.
• Дитяча кімната. З 15:00 до 20:00 тут працює няня, яка доглядає за малятами, поки їхні батьки закінчують робочий день. Цікаво, що напроти цієї кімнати облаштована окрема дитяча вбиральня.
• Салон краси. Тут за попереднім записом можна зробити манікюр та скористатись послугами барбера (працівник самостійно оплачує роботу майстра).

DOU Ревізор питає

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

Микола, PHP Developer, 5 років в компанії:

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

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

Ольга, Head of Documentation Department, 4 роки в компанії:

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

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

Олег, Senior C++ Developer, більше 2 років в компанії:

Подобається розташування бізнес-центру. Можна відлучитися на 5 хвилин і будь-які справи вирішити. Офіс доволі сучасний.

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

Таня, Test Engineer, 2 роки в компанії:

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

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

Ну що, ми поїхали далі ... А якщо ви хочете, щоб DOU Ревізор приїхав до вас, пишіть нам — revisor@dou.ua

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

Слідкуйте за нами на Facebook — www.facebook.com/dourevisor

Дивіться закулісні кадри того, що не проходить цензуру, в Instagram — instagram.com/dourevisor

Підписуйтесь на відеоканал DOU Ревізор на YouTube — www.youtube.com/...​/UCYyiAq3Bn1w1V5T7y0f-Uzw

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

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

Требования к уровню знаний слушателей программы разнятся в зависимости от направления подготовки. Если обобщить, то минимальный набор знаний включает уверенные знания алгоритмов и структуры данных, ООП, уровень письменного и разговорного английского не ниже среднего — В1 согласно Common European Framework of Reference for Languages. Также проверяются аналитические способности и сообразительность при решении нестандартных задач.

Плюсом будет опыт работы с БД, понимание процессов тестирования, понимание работы систем контроля версий. Для направлений, связанных с разработкой, таких как Java, .Net и JavaScript, желателен опыт разработки на любом из языков программирования.

Программа подготовки у нас состоит из двух этапов: внешнего факультатива — при сотрудничестве и на базе вузов и внутреннего pre-production — на базе компании.

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

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

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

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

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

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

Евгения Стрелкова, эксперт учебного центра NIX Solutions

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

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

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

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

Business Analysis:Карл Вигерс «Разработка требований к ПО».

Front- end:

• Бен Фрейн «HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств» 2-еизд.
• Джон Дакетт «HTML & CSS: Design and Build Web Sites»
• Дэвид Мак-Фарленд «CSS: The Missing Manual»
• Джон Дакетт «JavaScript and JQuery: Interactive Front-End Web Development»
• Marijn Haverbeke «Выразительный JavaScript»
• Дэвид Флэнаган «JavaScript: Подробное руководство»
• Кайл Симпсон «ES6 and Beyond»
• learn.javascript.ru

• The Java™ Tutorials — Oracle Documentation (ввести в поисковике java tutorial, выбрать вариант, где написано oracle)
• Хорстманн, 2-томныйсправочник по Java

.NET:Эндрю Троелсен «Язык программирования C# и платформа .NET» (лучше читать самую последнюю версию).

iOS:App Development with Swift.

Android:developer.android.com/index.html

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

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

Наши планы в обучении связаны с бизнес-задачами компании и развитием рабочих проектов. Соответственно, мы планируем учебные программы по актуальным для нас направлениям: Think PHP EDU, Business Analysis Education, обучение Java, обучение Front-end, обучение/практика .Net, практика iOS, практика C++.

Татьяна Бахтырь, PR Lead в Sigma Software University

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

Чтобы попасть к нам в интернатуру, необходимо пройти предварительное собеседование с рекрутером; техническое — с профильным специалистом и повторное собеседование с HR-специалистом и руководителем проекта/департамента. Если показываете хороший прогресс в процессе обучения, то ваши шансы остаться в команде стремятся к 100%. У нас хорошая статистика :)

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

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

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

А еще мы даем рекомендации по ключевым направлениям: iOS, Android, .NET, Java, JavaScript, PHP, Software Testing, Project Management, Python, включая список литературы, видеоуроков и статей.

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

В планах на будущий год, пока без привязки к городам, интернатуры по таким направлениям: Java, .Net, AR/VR, Unit 3D, Тестирование, JS, PHP, Android, iOS, PM, Embedded.

Наталия Олейник, Head of Growth and Development в Genesis

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

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

О том, как готовиться и где искать необходимую информацию, написано у нас на сайте Gen.tech. Мы проводим свои образовательные проекты, такие как Genesis IT School и Genesis Data Science School. После этих школ мы приглашаем к себе на работу около 20% выпускников. Остальные ребята также устраиваются на работу в другие IТ-компании.

У нашего идеального кандидата есть:

• Подтвержденные примеры getting things done — реализации проектов в университете, участие в олимпиадах, успешная карьера. Для каждого кандидата на работу к нам в компанию должно быть то, что отличает его от других таких же людей.
• Отличные фундаментальные знания (математические, технические, экономические) и любовь к цифрам. Очень много сотрудников Genesis закончили лучшие технические университеты в Украине и у нас есть тяга к точным наукам.
• Самое важное — огромное желание строить карьеру в продуктовом IT.

Павел Никиточкин, CTO & Management 3.0 Practitioner в JetThoughts

Наши требования к джуниорам:

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

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

Чтобы лучше подготовиться, необходимо:

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

Наш портрет идеального кандидата:

• студент 2-3 курса;
• со школьной скамьи любил математику, физику, информатику;
• участвовал в олимпиадах (даже без результатов);
• дома стоит *nix операционная система — нет сюрприза — непонимания, как настраивать разного рода приложения и системы;
• больше 2-хсвоих проектов;
• знает, как решить 90% проблем на проекте самостоятельно, функционально работает, но код не понятен или, как говорится, с запашком;
• читает книги по технологиям и методам разработки;
• экспериментирует с технологиями, играется; если не находит применение в своих проектах, то просто делает вводные примеры;
• читает англоязычную литературу и блоги;
• общительный и открытый.

Иван Резник, Delivery Director киевского офиса Intetics

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

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

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

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

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

Татьяна Хряпина, Head of Learning and Development Department в GlobalLogic

У нас есть две тренинг-программы:

— GL BaseCamp — для студентов, курсы проходят на базе технических вузов страны. Направления: QA, C++, DevOps, JS.
— GL ProCamp — для инженеров, которые уже имеют 1-2года опыта коммерческой разработки, но хотят овладеть более сложным и комплексным инжинирингом. Направления: Linux Kernel, System Development for Android OS, C/Embedded.

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

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

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

Как лучше готовиться и где искать информацию?

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

Наш портрет идеального кандидата.

Помимо хороших теоретических знаний:

• Опыт участия в реальных проектах (стартапы, open source). Статистика показывает, что такие люди демонстрируют более сильный уровень знаний и проактивности.
• Знания английского. Тогда человек сможет не только более глубоко погрузиться в тему благодаря самообучению, но и быстрее перейти к реальным проектам GlobalLogic, где нужно постоянно общаться с клиентами.
• Soft skills, которые отвечают нашей корпоративной культуре. Идеальный кандидат — positive thinking, хочет двигаться вперед, понимает, что такое deliver quality. Он прислушивается к ментору и умеет эффективно работать в команде.

Андрей Переймибида, менеджер IT-Академии SoftServe

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

По результатам работы в 2017 году у нас трудоустраивается более 70% выпускников.

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

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

У нас на каждое направление — конкурс от 5 до 15 человек на одно место в зависимости от направления. В течение 2017 (за первые 11 месяцев) мы выпустили около 600 человек, 470 из которых были трудоустроены в компании.

Татьяна Кинда, Head of Recruitment в Luxoft

Требования к новичкам разнятся от проекта к проекту — подход очень индивидуален. Знание основ — обязательно: умение различать методологии и технологии. Желание учиться и быть в этом аспекте проактивным — залог успеха для начинающих.

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

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

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

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

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

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

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

[Про автора: Краковецький Олександр — CEO в DevRain Solutions, кандидат наук, спікер, Microsoft Regional Director, Microsoft MVP AI, CTO ДонорUA]

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

Корпоративний день донора у Winner

Що таке ДонорUA

В розвинених країнах кількість кроводач на 1000 жителів на рік становить 33 кроводачі. В Україні цей показник — всього 13,3. В умовах війни та поганого стану медицини питання створення ефективної служби крові та рекрутингу донорів крові є критичним.

ДонорUA — це автоматизована система рекрутингу та управління донорами крові. Реалізується силами ВМГО «Асоціація молодих донорів України»та ІТ-компанією DevRain Solutions, керівником якої я є.

Проект об’єднує на одному майданчику донорів крові, реципієнтів, центри крові, бізнес і є спробою побудувати єдину автоматизовану екосистему навколо донорства крові в Україні.

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

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

Реальність

Наш підхід

Технологічно це хмарний сервіс з декількома персональними кабінетами (адміністратора, донора крові, центра крові, партнера), а також додаткові складові та інструменти — ДонорUA.Бот, моніторинг соціальних мереж, мобільні додатки для iOS, Android, Windows 10, мобільні додатки для партнерів бонусної програми (для iOS та Android), аналіз відкритих даних Міністерства охорони здоров’я. Також тестуємо NLP інструменти та системи штучного інтелекту для ще більшої автоматизації процесів (це тема окремої статті).

За ідею використання чат-ботів та штучного інтелекту для рекрутингу донорів крові проект ДонорUA отримав перше місце на Startup Weekend: Social Innvations у Стокгольмі (Швеція)

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

Чому варто звернути увагу на ДонорUA

ДонорUA — проект, що є прикладом синергії:

• громадської організації, члени якої досконально розбираються в предметній області та проблематиці, але далекі від інформаційних технологій та систем;
• ІТ-компанії, яка використала свій досвід розробки корпоративних рішень для створення продукту, що вирішує важливу соціальну проблему;
• волонтерів, які на базі відкритого API допомагають розвивати проект (наприклад, застосунок ДонорUA для Windows 10 було створено Микитою Бондаренко, GlobalLogic Ukraine, з власної ініціативи);
• корпоративного сектору, який в рамках бонусної програми та корпоративних днів донорів розвиває сферу донорства та заохочує донорів регулярно здавати кров.

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

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

Вчасно знайдений донор — чиєсь врятоване життя. Ось, наприклад, статистика за листопад:

• до нас приєднався 851 донор (всього в базі — 15 784).
• 190 реципієнтів звернулися за допомогою;
• 119 людей ми змогли врятувати;
• 58 ще чекають на донорську допомогу.

Давайте рятувати життя разом.

Донорство як корпоративний захід

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

Натомість я пропоную українським ІТ-компаніям розглянути можливість підтримки проекту ДонорUA, зокрема, в плані організації регулярних корпоративних днів донора для співробітників або під егідою компанії.

Зі своєї сторони ми:

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

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

До нашої ініціативи вже приєднались такі компанії, як Winner, ПриватБанк, Luxoft, Innovecs, Homer Software House, KPMGта інші.

Відгуки учасників

Анастасія Войткевич, менеджер з онлайн клієнтоорієнтованості у Winner:

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

Антон Наконечний, програміст:

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

Хочете приєднатись? Деталі за посиланням. Будь-які ідеї по співпраці надсилайте на alex.krakovetskiy@donor.ua.

І на завершення невеличке відео про донорство:

Дякую за увагу!

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

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

Начните с переписки и сбора доказательств

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

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

Оксана Кочкодан, партнер Axon Partners

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

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

Юлия Блешмудт, юрист Integrites

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

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

Павел Батищев, управляющий партнер AURUM

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

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

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

Но не стоит начинать битву, если не уверены в своей правоте.

Оксана Кочкодан, партнер Axon Partners

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

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

Не спешите в суд

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

Оксана Кочкодан, партнер Axon Partners

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

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

Василий Юрманович, старший юрист Integrites

В договоре на предоставление услуг между компанией и специалистом как ФЛП важно предусмотреть следующее:

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

Оксанa Кочкодан, партнер Axon Partners

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

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

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

Павел Батищев, управляющий партнер AURUM

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

Оксана Кочкодан, партнер Axon Partners

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

Риски ФЛП-сотрудника при сотрудничестве с компанией

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

Юлия Блешмудт, юрист Integrites

Основные риски или особенности для специалиста при сотрудничестве с компанией как ФЛП следующие:

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

В договоре «ФЛП — компания» часто прописано мало деталей, что также несет определенные риски для предпринимателя.

Павел Батищев, управляющий партнер AURUM

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

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

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

Оксана Кочкодан, партнер Axon Partners

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

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

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

Испытательный срок без договора

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

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

Павел Батищев, управляющий партнер AURUM

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

Василий Юрманович, старший юрист Integrites

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

И напоследок

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

Павел Батищев, управляющий партнер AURUM

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

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

Привет, я — Дмитрий Немеш, СТО в компании Lalafo, волонтер в GeekHub, более 7 лет работаю с PHP/Java/Node.js. В этой статье расскажу, как мобильный С2С маркетплейс переходил на микросервисы и с какими вызовами столкнулся.

Lalafo — это приложение для покупки и продажи б/у вещей, авто и поиска недвижимости, работы и услуг. В нем применяется машинное обучение и компьютерное зрение для распознавания товаров на фото, выявления мошенников, улучшения релевантности контента. Сегодня Lalafo активен на 4 рынках, на 3 из них сервис стал мобильным маркетплейсом № 1. Сегодня проект обрабатывает более 900 запросов в секунду, и его машины нагружены на 25-30%мощности.

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

Почему микросервисы

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

• переписать монолит;
• перейти на сервисно-ориентированную архитектуру;
• перейти на микросервисно-ориентированную архитектуру.

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

Основные вызовы

Нам нужно было объединить 7 баз данных из 7-мирынков в одну глобальную. Это нужно было сделать с расчетом, что все данные будут сначала объединены в одну глобальную базу данных, а потом разнесены в отдельные базы для каждого микросервиса. Также нам нужно было сохранить все связи между сущностями. Что это означает? Например, нужно было решить все конфликты ID-шников (то есть юзер под ID 1 — это 7 разных пользователей в 7 разных странах). При этом один и тот же пользователь мог быть зарегистрированным в 7 разных странах. Потом нужно было повторить старый API, чтобы все приложения продолжали работать. В Lalafo несколько миллионов клиентов, и бесшовный переход был критично важным моментом.

И в дополнение, нам нужно было сохранить SЕО трафик. Это значит, что все проиндексированные ссылки должны были остаться доступными по тем же адресам с теми же ID, что и до миграции.

Какие бывают модели микросервисов

Различают 3 модели микросервисов: звездоподобная, модель Twitter, сервисно-ориентированная. Для Lalafo мы остановились на последней и вот почему.

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

Модель Twitter— мы ее использовали. У нас весь API версионный: версия 1, версия 2 использует как раз эту модель. Есть фронт-микросервис, он работает как front controller в MVC фреймворках. Он принимает на себя все запросы, и он же их верифицирует, анализирует и перенаправляет на другие микросервисы. Все хорошо, замечательно, нам нравится, но на фронт-микросервис приходилось слишком много трафика. Поэтому возникло желание его переписать. У нас он написан на PHP, оптимально было бы перейти на Rust или Go, чтобы он работал быстрее. Хотя на тот момент проблем с производительностью не было, прежде чем переписывать его мы подумали, а может есть какой-то другой вариант? И попробовали сервисную модель.

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

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

Как мы мигрировали

Когда мы решили начать разработку, нам нужно было понять, можем ли мы работать с микросервисной архитектурой. Для этого мы разработали SDK (Logs, InfluxDB, Services, Helpers, HttpClient), который помогал синхронизироваться с разными микросервисами и ускорить разработку. Также мы разработали инструменты, которые помогали работать с микросервисами в виде ORM. Все это было сделано, чтобы разработка осталась максимально похожей на привычную разработку монолита. В результате разработчикам было несложно привыкнуть к ней, так как стиль кода оставался похожим на монолитный.

Мы также адаптировали компоненты фреймворка, которые мы использовали для access control, users, логирования. В итоге разработчик использовал все необходимые компоненты как и раньше. Данный подход помог нам за 3 месяца написать полностью рабочую MVP версию проекта, который писался более 2-хлет.

Мы объединили 7 баз данных с помощью микросервиса «migrate», также он умел доливать данные. Этот микросервис отсылал всю историю старых и новых ID на микросервис «map», по которым строилась карта старых и новых идентификаторов. Это решало проблему обратной совместимости и сохранения SEO трафика. Также мы зарезервировали диапазон идентификаторов для старых данных, чтобы можно было определить, где данные с монолита, а где те, которые уже созданы в новой архитектуре. После этого мы создали еще один микросервис, который разнес данные из большой базы по отдельным базам данных микросервисов. В итоге мы получили данные, где все записи сохранили все отношения друг с другом, но имели новые ID и карту для получения данных по старым ID. Диапазон-разделитель ID помог нам понимать, какие данные нужно доставать по карте, а которые оставить как есть.

Процесс перехода

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

Stack, который мы выбрали:

• PHP 7, Yii2, Codeception;
• Python — data-science стек для компьютерного зрения и машинного обучения;
• NodeJS — comet server для сокетов;
• PostgreSQL — основная база данных,
• MongoDB, Cassandra, Google BigQuery — БД для наших кастомных аналитик;
• Redis — кеш и сессии;
• ElasticSearch — полнотекстовый поиск;
• RabbitMQ, Kafka — очереди и message bus для аналитики;
• InfluxDB+Grafana — метрики;
• Graylog2, Zabbix — логирование и мониторинг системы;
• GitLab, Kubernetes, Docker, CloudFlare;

В результате мы пришли к такому количеству микросервисов:

Core: user, catalog, chat, sender, moderation, payment, security, fraud.
Supplementary: page, location, SEO, translation, Migrate-app, map, mobile-api, cache, analytics, upload, file node.
AI: classify, classify-analytics, duplicates, image processing, content filtering.

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

1. Идеально! Ты работаешь с некоторыми из них и думаешь: «Круто, это действительно работает!».
2. С другими ты думаешь: «Что-то не так, эти несколько микросервисов можно было объединить в один».
3. Ты видишь, что микросервис работает плохо. И это не проблема микросервиса.

Идеальные микросервисы: translations, sender, analytics, security, upload, classify.
Микросервисы, которые хочется объединить: user, catalog, location.
Микросервисы, которые хочется переосмыслить: fraud, moderation.

Важность тестирования

С микросервисной архитектурой невозможно жить, не используя автотесты. Мы используем гибридные Codeception тесты, смесь Acceptance (REST Module) с Functional тестами — это оптимальный вариант. У нас получаются легко читабельные Acceptance тесты, простые в написании и поддержке, плюс с фикстурами и моками, как в функциональных тестах. На их прогон нужно немного времени, в связи с чем у нас быстрый continuous integration — у нас маленькие микросервисы, у которых маленькие наборы тестов, непосредственно связанные с этим микросервисом. Как только какое-то изменение произошло, continuous integration сразу же тестит это изменение независимо от ветки.

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

Вывод:

• автотесты — must have;
• ручное тестирование — боль;
• Acceptance + functional tests (REST Module);
• Fast continuous integration.

Микросервисная коммуникация

• REST API with http-cache;
• Queue Rebbit MQ/Kafka;
• Global events with Kafka (Message Bus/ Event-drive).

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

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

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

Активные и пассивные микросервисы

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

• 1 разработчик — один активный микросервис;
• 1 разработчик — 3 пассивных микросервиса, которые он знает.

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

Стабильность микросервисов

Если следовать рекомендациям по созданию микросервисной архитектуры, у вас должно быть много серверов. Например: eсть микросервис 1 и микросервис 2. На каждый тип или группу микросервисов должен быть балансер, а на каждую группу микросервисов должна быть своя база данных в режиме master-slave. И выходит так, что на каждую группу мы должны выделить от 5 серверов для того, чтобы добиться максимальной отказоустойчивости. Если у вас 20 микросервисов, теоретически должно быть более 100 серверов. Это если мы говорим о своем железе.

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

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

Выводы

Важные моменты при переходе на микросервисы:

• микропроблемы лучше, чем большие проблемы на монолите;
• контейнеризация и автотесты — must have;
• легкое масштабирование как проекта, так и команды;
• легкость в интеграции новых технологий;
• плавная миграция с монолита лучше, чем force;
• мощная и продвинутая система мониторинга;
• хороший системный администратор или DevOps;
• отдельная тема — это контейнеризация, которая будет раскрыта в отдельной статье. Но если коротко сказать, то использование Kubernetes + Docker + GitLab CI выводит управление и мониторинг микросервисов на другой уровень.

Микросервисы — это идеальная экосистема для экспериментов:

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

«Распределенный монолит»

Недавно я был на ивенте PHP Friends meetup #4 (Tech Leads Panel), на котором я очередной раз рассказывал о нашем опыте и микросервисах. Я познакомился с Максимом Волошиным из OWOX (очень техничный и опытный специалист) и услышал от него фразу «распределенный монолит» — это дало пищу для размышлений. Так как у нас разнообразные микросервисы — некоторые абсолютно самостоятельные, а некоторые плотно завязаны на другие микросервисы — у меня появилось ощущение, что 2 наших микросервиса (User и Catalog) можно справедливо отнести к распределенному монолиту.

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

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

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

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

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

Определение диагноза

На момент старта поиска путей для развития своей квалификации и экспертизы, я регулярно использовал лишь 20-30%из всех навыков и компетенций, необходимых для профессионального UX дизайнера. Это Stakeholder Interviews, Рrototyping, User Testing. Еще 30% мне посчастливилось использовать на 3-4интересных долгосрочных проектах — анализ бизнес-процессов, service blueprints, CJM, продолжительные и обширные серии user research. Они сформировали и вырастили меня с профессиональной точки зрения. Но, к сожалению, эти навыки использовались не регулярно в основной деятельности, а после — и вовсе стали ослабевать.

И, наконец, last but not least — почти не используется часть навыков по Product Design, связанных в основном с ранними этапами разработки решения, которые проводятся обычно в продуктовых компаниях. Это анализ рынка, поиск новых возможностей для продуктов, уникальных конкурентных преимуществ в мультидисциплинарных командах.

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

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

Поиск возможностей

Итак, я начал искать всевозможные курсы по UX, Interaction Design, Human-Computer Interaction и пытаться понять, насколько они мне подходят. Базовые курсы я не рассматривал — для меня они бесполезны, а их большинство.

• Короткие курсы, онлайн и оффлайн — дорого и обзорно/точечно, отсюда малая рентабельность и полезность.
• Более длительные, онлайновые — затрагивают одинаковые темы, низкая интенсивность и минимальная связь с преподавателем, часто оценки и обратная связь с помощью peer review. Хорошо для hard skills и формирования базовой системы знаний. Примеры: Interaction Design на Coursera, дизайн-курсы Нетологии.
• Длительные и оффлайновые — дорогие. Несколько месяцев стоят как master’s degree и при этом все равно состоят из базовых программ. К тому же, проживание на несколько недель или месяцев максимально проблематично в финансовом плане — отели дороги, аренда квартиры на такой короткий срок невозможна. Примеры: курсы Norman Nielsen Group в США и Европе.
• Master degree! При высокой стоимости (зависит от страны и вуза — от $1К до $25К+) дает наибольшее количество практики. Есть возможность более или менее фундаментально пересобрать в голове все концепции, сделать короткие практические проекты с начальной стадии по Define стадию. Отработать как раз те шаги, которые так редки в повседневной деятельности.

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

Для меня такой формат не подходил по двум причинам:

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

В ходе продолжительных поисков мне попался Hyper Island. Он сразу же «купил» меня своей сжатой и очень структурированной программой. Очная часть с основной теоретической и практической частями за счет интенсивности была сжата до полугода. Остаток года предстояло потратить на самостоятельную заочную работу над дипломом.

Еще одним важным аргументом «за» был город Манчестер — крупный деловой и образовательный центр. Он не такой баснословно дорогой, как Лондон, но и не маленький тихий кампус на периферии. Золотая середина была найдена, и я выбрал программу MA Experience Design.

Northern Quarter, Манчестер, вид из университетской студии

Подготовка

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

Первоначально я планировал отказаться от участия в проектах компании и полгода жить на оставшиеся сбережения (что было бы очень нелегко). Однако, когда я поделился своими планами в компании, мне предложили не сжигать все мосты, а попробовать вести мой проект удаленно на part-time, пользуясь помощью Junior-дизайнера. Проектом я занимался в основном рано по утрам перед парами и во время обеденного перерыва, чтобы время совпадало с активными часами команды в Харькове. А коммуникации с заказчиком из США удобно попадали на время после занятий (которые шли с 9 утра до 5-6 вечера).Не думаю, что реально обойтись без дохода, уезжая учиться на 6-18 месяцев.Рart-time на своем хорошо знакомом проекте намного эффективнее, чем обычный freelance, с большим overhead по административным задачам и коммуникациям.

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

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

Особенности учебы

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

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

1. Преимущественно командная работа. Как и в индустрии — проекты делаются командами дизайнеров. Индивидуально выполняются только письменные работы по результатам каждого курсового проекта: обзор темы курса, литературы по ней и анализ-ретроспектива командного курсового проекта.
2. Не преподаватели придумывают проекты. Продуманные, хорошего уровня брифы приносят компании-партнеры университета. От студентов они ожидают анализа рынка и продуктов для валидации их собственных исследований. Безусловно, им интересны свежие, независимые идеи: от стратегий в необычных сегментах рынка, до прототипов продуктов и сервисов. Компании делают все, чтобы сделать студенческие проекты максимально применимыми для своих целей.
3. Самостоятельная работакоманды:
   
   • взаимодействие с заказчиком для корректировки проделываемой работы пару раз в неделю;
   • взаимодействие с консультантом-экспертом по методикам работы — 1-2раза в неделю по полчаса.
4. Еще один важный аспект учебы — участие профессионалов из известных компаний. Они выступали в качестве приглашенных лекторов, кураторов-консультантов (supervisors) курсовых проектов, представителей заказчика (product owners).

Мы учились у представителей крупнейших design consultancies, список далеко не полный:

• IDEO (London) — руководитель отдела исследований лондонского офиса, проработавшая в IDEO 10 лет;
• ustwo (London) — один из двух основателей компании, сравнимой по уровню с IDEO;
• R/GA, SapientRAZORFISH, ZONE (London) — Chief Creative Officer крупнейшего независимого дизайн-агентства в UK, до этого 15 лет проработавший дизайн-лидом в R/GA (New-York) и еще 5 лет в Sapient.

Вышеуказанные лекторы, таким образом, представляют крупнейшие мировые дизайн-агентства, включая как Design Consultancies, так и Digital Agencies, находящиеся на пути бизнес-трансформации:

• Barclays — product owner, руководитель отдела инноваций банка из четверки крупнейших в UK, с брифом о повышении финансовой грамотности клиентов;
• BBC — product owner, менеджер, руководивший реформированием корпоративной культуры главного офиса BBC, когда он был закрыт в Лондоне и перенесен в Манчестер;
• IBM Retail IoT division (London) — во время проекта по бизнес-трансформации донорской службы министерства здравоохранения Соединенного Королевства;
• Adidas — product owners с брифом по реформированию human resource политик в британском офисе компании;
• Speedo — product owners с брифом по повышению популярности и регулярности занятий плаванием у любителей.

Мы посещали офисы всех вышеперечисленных компаний, и в этих же офисах, а не в университете, презентовали результаты наших курсовых проектов.

Мои личные открытия и откровения

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

• Команда и проект могут, при вдумчивом подборе, выиграть от присутствия разных людей, как с точки зрения типов личности (team dynamics), так и профессиональных навыков (multidisciplinary team).
• Оказывается, есть пропасть между тем, насколько я продуктивен и полезен в командах разного состава и типа. Таких разительных различий в моей профессиональной практике я не наблюдал. Круто, что есть разработанные методики построения команд с хорошим уровнем эмоциональной и профессиональной совместимости и сплоченности. Этими вопросами сейчас особенно активно занимается мой друг и однокурсник по Hyper Island, Ваня Голяков.
• Ценности дизайн-мышления, которые раньше были просто словами, приобрели смысл после практического использования:
  
  • Discovery — поиск решения. С этим я сталкивался всего на нескольких сложных проектах, где заказчики знакомы с концепцией user-centered design. Мне доводилось долго интервьюировать, говорить с людьми, закидывать широко сети в поиске первоисточника проблемы или потребности группы людей. Я научился сначала разбираться в проблеме (discovery and empathy), а потом прорабатывать прототипы, при этом не затягивать с поиском широкого круга решений (divergent thinking and ideation).
  • Ideation этапы и техники — как быстро генерировать множество идей (divergent thinking), обсуждать их с командой, а потом сообща отбирать объективно лучшие (convergent thinking).

Пусть мой пример вас вдохновит

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

За время учебы удалось много узнать:

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

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

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

Всем привет! Меня зовут Виктор, я работаю менеджером проектов в компании Cogniance. Делюсь дюжиной интересных материалов по управлению проектом и продуктом в декабрьском выпуске PM Digest’a!

Project Management

Самое время проверить и, возможно, обновить свой реестр рисков — 22 типа проектных рисков.

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

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

Лидерствов проектном управлении. Интересный анализ.

PRINCE2 Project Management in 90 Seconds — 7 processes, 7 Principles, 7 Themes.

Project Communication Plan. How-to?

Как визуализировать проектное управление? Ответы в статье. Бонус — шикарный whitepaper на эту тему (не бесплатно — за ваши данные).

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

10 афоризмов проектного менеджмента. Must Read.

Agile, Scrum и все такое

Два подходак наполнению вашего спринт беклога на планировании: Yesterday’s weather и Fill the Bucket. В моем опыте всегда происходит некий микс этих подходов. А как у вас?

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

Одна из ветвей эволюции Agile — Modern Agile, пионером которого является Joshua Kerievsky. Почему вам стоит ознакомиться с подходами Modern Agile и обсудить их с командой? Вотответ.

50 articles for 50 yearsот вышеупомянутого Джошуа Кириевски. С юбилеем!

Используете один из популярных Agile Scaling подходов и собираетесь проводить Overall Retrospective для всех команд и стейкхолдеров? Вот гид, как подготовиться и не напартачить.

Спиральная динамика: правила менеджерав бирюзовой организации.

Антипаттерныв проведении ретроспектив. Кто-то сможет дополнить список? :)

How to? Ретроспектива для удаленных команд

Отличные зарисовки на тему «День из жизни»:

• Scrum-мастер (часть 1, часть 2)
• Agile-коуч.

Fun

Классная визуализация Agile Manifesto, включая 12 принципов.

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

Вы там это, поосторожнее в высказываниях:

Привет от заказчика:

Life moments:

На этом все! Всех с наступающим новым годом!

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

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

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

Переїзд

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

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

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

Дозвіл на роботу в Швейцарії забезпечує компанія. Вона надсилає документ листом. Отримавши лист у Києві, я подав його у посольство разом із контрактом та паспортом. Після цього мені видали національну візу — її дають максимум на три місяці. Із цією візою я приїхав до Швейцарії. Упродовж 14 днів треба зареєструватися за місцем проживання, після чого отримав дозвіл на проживання — ID картку. З нею можна в’їжджати в Швейцарію та виїжджати з неї, відвідувати країни Шенгенської зони. Така ж картка була потрібна на період стажування. Коли після стажування поїхав додому, слід було виреєструватися зі Швейцарії, тож картка припинила діяти. Коли заїжджав знову, наново отримував візу і картку.

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

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

Житло

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

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

Винаймаю кімнату в швейцарця, який живе на першому поверсі триповерхового будинку. Ми з ним здружилися, жодних проблем не виникає. За оренду плачу 800 франків (або ж 800 доларів; 1 chf = 1,01 usd) у місяць — це дуже дешево, бо ми так домовилися як друзі. Оренда квартири в Цюриху на місяць вартує в середньому 2000 франків у місяць. У центральних районах вартість місячної оренди може сягати і 5000 франків. Що далі від міста — то дешевше. У Тальвілі це буде, наприклад, 1200-1600 франків.

Ціни на нерухомість теж високі: за мільйон франків можна купити непогану 2-3-кімнатну квартиру.

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

Робота в компанії

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

Якщо на стажуванні були можливі варіанти: виконувати це завдання чи інше, то на фултайм роботі проявляєш більше ініціативи. Зважаєш на пріоритети проекту: що потрібно робити зараз, що пізніше. Вибираєш оптимальний перетин між тим, що тобі цікаво, і тим, що потрібно для команди. У нас майже нема такого, що приходить менеджер і роздає завдання. Можливо, справа ще в специфіці нашої команди з research and machine intelligence. Люди самі організовані в проекті. Команда налічує 14 людей, а починалася вона з 5 людей три роки тому. Це маленький колектив, бо в запущених проектах, як Gmail або Youtube, працюють сотні людей.

Займаємося natural language processing. Є Knowledge Graph — різні факти про різні об’єкти світу, які можна знайти у вебі. Досліджуємо цю сферу, але проект ще не запущений. Я був відповідальний за алгоритми логічного виведення, а тепер більше переключився на перформенс. Слідкувати, щоб усе працювало швидко, оптимізувати всі ці штуки — це більше нагадує олімпіадне програмування, яке мені цікаво. У нас як у молодої команди є можливість випробовувати себе на різних позиціях. Я певний час навіть писав frontend, але не сподобалося, тому перейшов.

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

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

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

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

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

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

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

Загальні враження від країни

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

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

У Швейцарії мені подобається транспорт, який працює ліпше, ніж у будь-якій іншій країні Європи, де я був.

А найбільше до вподоби те, що близько гори і природа. Швейцарці люблять ходити в гори, це для них стандартні вихідні. Буквально над Цюрихом є невелика гора заввишки 900 метрів. Якщо проїхати годину від місця, де живу, на потязі, будуть гори висотою 2500-2600 метрів,за 2-3години — вже трьохтисячники.

Вид на масив Eiger-Mönch-Jungfrau з дороги на Mürren

ІТ-ринок Швейцарії

Із середини Google важко судити про ринок, бо нема бажання шукати інших позицій. Але з того, що бачив і знаю, можу сказати, що тут багато різних позицій, та як для європейської країни загалом — небагато. Є цікаві позиції в районі Базеля. У Швейцарії багато фармацевтичних компаній, тож можна знайти роботу у різних life science startups. Також є вакансії для розробників у банках та інших фінансових установах. Зарплати більші, ніж в інших країнах Європи, адже й ціни в країні вищі.

Зарплати й податки

Зарплати Google дозволяють жити комфортно, але не так, як в Україні, де можна відчувати себе Богом і купувати абсолютно все.

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

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

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

Нічний Цюріх з найближчого пагорба Uetliberg

Транспорт

Найкраще в ньому — те, що він ходить за розкладом. Буває, звісно, що спізнюється, але в такому випадку намагаються пустити додатковий транспорт. Є локальний транспорт у містах: тролейбуси, трамваї, автобуси, S-Bahn — приміська електричка, що ходить в районі одного кантону (територіально-адміністративна одиниця у Швейцарії — ред.). Є потяги далекого прямування.

На роботу їжджу на S-bahn, який, як і весь локальний транспорт, оплачується зонально. Кантон розділений на зони з певними номерами. Власник квитка на кілька певних зон має право протягом зазначеного часу подорожувати всередині цих зон скільки завгодно. Мені проїзний на всі зони навколо Цюриха вартує 90 франків на місяць.

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

Квитки на потяги далекого спрямування продаються на певний маршрут. Наприклад, якщо хочу поїхати з Цюриха в Берн, купую квиток, дійсний 24 години, і можу їхати туди будь-яким потягом. Для далеких маршрутів вигідніше купувати квиток на день на всю Швейцарію, що вартує 75 франків. Такий квиток дає змогу користуватися всіма потягами далекого спрямування по країні, але не локальним транспортом. Система видається складною, але насправді все зручно влаштовано.

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

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

Якщо разовий квиток на потяг із Цюриха в Тальвіль коштує 8,80 франків (із карткою — 4,40), то аналогічний шлях на Uber обійдеться в 30 франків. Звичайного таксі не викликав, але воно вартує ще більше — 40-45 франків.

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

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

Вид на гори з Тальвільского вокзалу

Медицина

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

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

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

Мови

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

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

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

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

Менталітет

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

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

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

Кухня

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

Погода

Погода схожа на вінницьку, але тут дещо м’якше. Зима в цілому тепліша: −15 °C в них давно не було, −10 °C — це суперхолодно, така температура була лише один раз за три роки мого перебування тут. Улітку більше дощів, ніж в Україні. У південній Швейцарії, ближче до Італії, значно тепліше. У південному Валлісі — частина між двома горами — теж тепло, росте багато абрикосів, абрикосовий сік — традиційний напій цієї місцевості.

Сніг у містах довго не затримується, тане, бо в місті температура вища, але в горах може бути і −25 °C, і сніг. Словом, зима, якої тільки можна побажати.

Плани

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

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

Статья создана в соавторстве с Шармином Хаятом, Data Specialist и с помощью Андрея Горобца, Front-end Developer.

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

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

Этот пост предназначен для освещения как теоретических, так и практических аспектов использования React Native в сравнении со Swift. Для теста, мы взяли два почти идентичных приложения в обеих структурах: React Native App, Swift App.

Мы постарались максимально упростить эти приложения, чтобы было легче сравнивать между важными аспектами обеих платформ. Ниже вы найдете подробный анализ приложений, разработанных на Swift и React Native, разницу в нагрузке процессора, графического процессора и памяти. Давайте исследовать!

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

Swift vs React Native

Swift

В отличие от других языков, Swift достаточно приятен в работе, особенно если сравнить его с предшественником Objective C. XCode, безусловно, является отличной IDE, и значительно упрощает разработку в сочетании со Swift.

React Native

По правде говоря, изучить JavaScript намного проще, чем Swift. В отличие от iOS, где вам приходится настраивать все самостоятельно, React Native позаботился об удобстве своих пользователей. Мы запустили приложение почти на всех версиях iPhone и знаете что? Никаких проблем с разметкой и расположением элементов — все четко :)

Полезно будет узнать о производительности React Native изолированно. Обратите внимание на официальную статью от Facebook.

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

Когда мы перемещали позицию на карте и выполняли ее масштабирование, приложение на React Native лагало больше, чем соперник на Swift. По данным Energy Usage Log, приложение на Swift расходовало меньше энергии в течение всего теста по-сравнению с React Native. В общем, в моем приложении есть всего 4 вкладки — страница логина Facebook, просмотр страницы, Page view и Карта.

CPU

CPU Profiler на экране карты

CPU Profiler на to-do list

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

1. Профиль пользователя Facebook

С точки зрения использования ЦП, React Native оказался более эффективен (на 1,21%), чем Swift.

2. To-do list

Во второй вкладке React Native снова стал победителем с эффективностью 0,66%. Выполняя задачу, пики потребления ЦП были записаны в то время, когда мы включили/удалили элемент из списка.

3. Просмотр страницы

На этот раз Swift определенно стал победителем (на 5,55% эффективнее, чем React Native). Выполняя эту задачу, мы отмечали падение производительности и пик потребления ЦП во время перехода на другую страницу в режиме просмотра.

4. Карты

Swift снова побеждает в этой категории, более рационально загружая CPU (на 9,7%). Следует отметить, что при выполнении этой задачи скачок в потреблении процессора появляется именно во время перехода на вкладку «Карты».

Своего рода ничья.

GPU

Следующий анализ, который мы проведем, это измерения GPU. Вертикальная ось достигает 60 кадров в секунду. Для оценки результатов мы будем использовать инструмент «Core Animation».

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

1. Профиль пользователя Facebook

С разницей в 1,08 фрейм/сек, Swift едва ощутимо лидирует. Результаты были зафиксированы при нажатии на вкладку «Войти в Facebook».

2. To-do List

Здесь React Native практически подтверждает свое превосходство, работая на 6 фреймов/сек выше, чем Swift. Замеры были произведены точно в момент добавления/удаления элементов из списка.

3. Просмотр страницы

Swift превосходит React Native на 1,37 фрейм/сек на вкладке просмотра страницы. Наблюдая за цифрами, мы обнаружили, что фрейм/сек увеличиваются до 50, если быстро перемещаться по страницам.

4. Карты

Swift здесь явный лидер, так как работает на 3,6 фрейма/сек быстрее, чем React Native. Данные получены во время нажатия на кнопку «Карты».

Что ж, с результатом 3-1побеждает Swift!

Memory Usage

Теперь сравним Swift и React Native по количеству используемой памяти. Мы выполнили по одной задаче на вкладку и построили график с памятью (%) по оси y.

1. Профиль пользователя Facebook

В этой категории Swift является победителем, потребляя памяти на 0,07% меньше. Хотя таким отклонением можно даже пренебречь. Скачок по памяти был записан в момент нажатия на кнопку «Войти в Facebook».

2. To-do List

В этой категории React Native превосходит Swift, используя на 0,35% памяти меньше. Пики потребления памяти были записаны при включении элемента в список. При удалении элемента произошел спад в использовании памяти.

3. Page view

Вновь React Native обошел Swift, затрачивая на 0,07% памяти меньше. При переключении между страницами всплесков памяти не наблюдалось.

4. Карты

React Native здесь твердый лидер, оставил Swift позади с массовым использованием памяти в 36,02% для этой категории. Всплеск памяти записан в момент нажатия на кнопку «Карты».

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

Выбор платформы

Тестируемые приложения на React Native и Swift очень схожи между собой. Из этого эксперимента мы можем заключить, что хотя React Native показал себя лучше в категории памяти, Swift эффективно использует процессор и графический процессор. В заключение можно сказать, что React Native довольно близок к Swift, и это радует. Однако со счетом 2-1наряду с высоким потенциалом по памяти Swift по праву становится победителем. К слову, тестировали на iPhone 7.

Популярность React Native меня совсем не удивляет, поскольку с его помощью мы сможем создавать приложения для нескольких платформ параллельно (повторно используя практически весь код приложения). Да, именно так :) Поскольку React Native напрямую зависит от JavaScript, вам почти не нужно разбираться в каких-либо других языках, в большинстве случаев, для создания приложений на iOS и Android отдельно. Кому интересны внутренние процессы выполнения Javascript кода на мобильных устройствах и как работает React Native, обратите внимание на статьи Bridging in React Native, JavaScript Environment.

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

React Native: плюсы

Повторное использование кода

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

Платформа: «Все включено»

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

Это как готовить целое блюдо из одного ингредиента. Невозможно создать целое приложение, используя только React. Определенно, вам понадобится webpack для сборки кода, подобие CSS для стилизации, что-то похожее на Firebase для обслуживания данных и много чего другого.

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

Что предлагает React Native

• React :)
• Вспомогательные средства для Android и iOS;
• Flexbox для стилизации пользовательского интерфейса;
• Различные виджеты и анимации.

И многое другое...

import React, { Component } from 'react';
import propTypes from 'prop-types';
import { View, Text } from 'react-native';
import { infoMessageStyles } from './styles';

export default class InfoMessage extends Component {
  static propTypes = {
    text: propTypes.string.isRequired,
  }

  render() {
    return (
      <View style={infoMessageStyles.wrapper}><Text
          allowFontScaling={false}
          style={infoMessageStyles.text}>
          {this.props.text}</Text></View>
    );
  }
}

Интегрируемые нативные компоненты

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

React Native предлагает ряд интегрированных компонентов, что позволяет разработчикам быстро и эффективно выполнять основные задачи. Некоторые из них включают:

• Текст: используется для отображения текста

import React, { Component } from 'react';
import { AppRegistry, Text, StyleSheet } from 'react-native';

export default class TextInANest extends Component {
  constructor(props) {
    super(props);
    this.state = {
      titleText: 'Nest',
      bodyText: 'This looks like a birds nest.',
    };
  }
  
  render() {
    return (
      <Text style={styles.baseText}><Text style={styles.titleText} onPress={this.onPressTitle}>
          {this.state.titleText}{'\n'}{'\n'}</Text><Text numberOfLines={5}>
          {this.state.bodyText}</Text></Text>
    );
  }
}
const styles = StyleSheet.create({
  baseText: {
    fontFamily: 'Cochin',
  },
  titleText: {
    fontSize: 20,
    fontWeight: 'bold',
  },
});

• Вид: используется для проектирования пользовательского интерфейса

class ViewColoredBoxesWithText extends Component {
  render() {
    return (<View style={{flexDirection: 'row', height: 300, padding: 300}}><View style={{backgroundColor: 'green', flex: 0.3}} /><View style={{backgroundColor: 'blue', flex: 0.5}} /><Text>Greetings !</Text></View>
    );
  }
}

• Текстовый ввод: позволяет пользователям вводить текст

import React, { Component } from 'react';
import { AppRegistry, Text, TextInput, View } from 'react-native';

export default class PizzaTranslator extends Component {
  constructor(props) {
    super(props);
    this.state = {text: ''};
  }

  render() {
    return (
      <View style={{padding: 10}}><TextInput
          style={{height: 40}}
          onChangeText={(text) => this.setState({text})}
        /><Text style={{padding: 10, fontSize: 43}}>
          {this.state.text.split(' ').map((word) => word && '🍕').join(' ')}</Text></View>
    );
  }
}

• Кнопка

<Button
  onPress={onPressLearnMore}
  title='A Basic Button'
  color='#841589'
  accessabilitylevel='A beautiful button'
/>

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

React Native: минусы

Ограниченный API

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

Различия платформ

Android и iOS используют различные принципы проектирования. Это означает, что с помощью React Native придется включить множество if-statements вместе с отдельным кодом, чтобы укладываться в рамки размещения графических элементов. В дополнение к этому, создание высококачественного пользовательского интерфейса также исключает парадигму React, и мы были вынуждены писать Swift библиотеки при разработке этого приложения. И мы уже не говорим о том, что нужно сопровождать сразу несколько конфигурационных групп.

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

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

Real Native: плюсы

Нет API ограничений

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

Разнообразие ресурсов для выбора

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

Real Native: минусы

Требование к разработке двух отдельных приложений

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

Сравнение React Native и Real Native Apps

Создание приложения на React Native

Если вы создаете приложение для iOS или Android, вам следует знать три важные вещи:

• предпочтительный язык программирования;
• подходящие инструменты;
• интерфейс программирования (API).

Что касается разработки на React Native, вы вынуждены использовать JavaScript или его суперсет JSX. К счастью, у вас сходу будет отличный набор инструментов. А вот что касается API — будет немного в новинку. Конечно, с помощью React Native вы не сможете сделать все.

Создание Native Android / iOS приложения

Objective-C и Swift — необходимые языки для создания native приложения в iOS. Для Android вам понадобится знание Java. Что касается инструментов, можно использовать IDE для отдельной платформы, а также представить, как IDE и соответствующий debugger помогут вам создать систему.

Что проще выучить

Конечно, JavaScript намного легче изучить, а также отладить, чем Swift, Objective-C и Java. Javascript — это чуть ли не единственный язык, на котором начинают писать еще до того момента, как изучат его, — вследствие его гибкости. Но имейте в виду, всему есть цена. Поскольку JavaScript — довольно простой язык, всегда есть большой риск ошибок в вашем коде.

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

Таким образом, React Native более легкий в изучении, но он приходит с проблемами JavaScript. Более того, как и с любой другой кросс-платформенной парадигмой, вам нужно принять парадокс «написать один раз, развернуть под каждую платформу отдельно».

Выводы

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

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

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

Привет! Меня зовут Евгений Рогов. Не так давно я перешел в компанию AgriEye на должность CMO и сейчас помогаю ребятам разрабатывать сервис рекомендаций по точному земледелию с важной миссией. С текущим темпом рождаемости, к 2050 году человечеству необходимо будет производить в десятки раз больше еды, чем сейчас, при том, что посевные площади будут только уменьшаться. Наш продукт позволит фермерам повысить эффективность земледелия в среднем на 30-40%.

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

Идея

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

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

Проанализировав все недостатки предыдущих компаний и собрав положительные стороны бизнеса, Андрей создал модель AgriEye — сервиса сбора и анализа данных, основанного на искусственном интеллекте. Пока происходила трансформация бизнес-идеи, ребята успели протестировать продукт на трёх континентах. Сейчас уже отсканировано порядка 180 тысяч гектаров полей в Украине, США, Эквадоре и Перу.

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

Украинская часть команды AgriEye

Реализация

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

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

Основной сложностью реализации была обработка спутниковых данных для оптимизации нагрузки и скорости работы. Из-за этого нам пришлось разделить часть работ на фронтенде, часть на бекенде. Если говорить про бекенд, то был выбран C# благодаря скорости обработки большого объема медиаданных и возможности работы с библиотекой GDAL/OGR. Кроме того, у нас был большой опыт работы с C# и изначальный план разворачивать сервис на мощностях AZURE.

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

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

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

CEO Андрей Севрюков презентует сервис AgriEye перед инвесторами на демодне акселерационной программы в Осло

Планы

За последние несколько месяцев мы взяли курс на завоевание рынка США. Сейчас мы ориентируемся на малые семейные фермерские хозяйства, которых в стране примерно 85%. Начать выход на рынок США было решено в штате Миссури, это один из наиболее сильных сельхоз регионов страны. Мы уже заключили стратегическое партнерство с Университетом Миссури и Missouri Partnership.

Всего пару недель назад мы вернулись из Нью-Йорка, где участвовали в партнёрской программе норвежского акселератора Katapult, от которого ранее получили 200К usd на доработку продукта. Сейчас мы активно готовимся к участию в выставке потребительской электроники CES, где собираемся презентовать первую часть нашего продукта.

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

Это кратко о нас и о том, что мы делаем. Будут вопросы — пишите на er@agrieye.io.

Спасибо!

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

Поехали! Заполнить анкету

Результаты опроса — приблизительно через месяц. Результаты предыдущих опросов можно посмотреть в отчетахили с помощью виджета.

Все вопросы, предложения и пожелания по поводу опроса можно оставлять в комментариях к этому посту или присылать по почте на cb@dou.ua.

Моя менеджерская карьера в сервисной IT-индустрии развивается уже более 10 лет. В 2007 году, оставив опыт разработки позади, я пришел в GlobalLogic на позицию Junior Project Manager. И за это время мне довелось руководить командами от двух человек до двух сотен специалистов из разных уголков мира.

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

Масштаб S

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

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

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

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

Масштаб M

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

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

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

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

Масштаб L

Вы отлично справились с этапом M, так что переходите на следующий уровень — руководство поручает вам еще пару клиентов.

Чем раньше была компания для вас? Местом, куда вы приходили каждое утро, вашим проектом, вашей командой, клиентом, с которым вы всегда на связи. Да, вы давали себе отчет о том, что в компании много заказчиков (могли даже перечислить топ-5 названий и почти без ошибки сказать, кто чем занимается), но это понимание было где-то на периферии сознания. Теперь же, когда клиентов несколько именно у вас, картина мира выглядит совсем иначе.

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

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

Раньше у вас даже не возникало мысли, что для клиента можно что-то сделать бесплатно (а что, и так можно было? о_О). У вас, скорее всего, даже не было таких полномочий, но сейчас понимаете, что это далеко не конец света. Вовлечь дополнительных людей на проект, приобрести программно-аппаратное обеспечение за счет компании, вложиться в разработку инновационных прототипов (когда двое инженеров в течение нескольких месяцев будут пилить proof-of-concept, и в перспективе это может перерасти в отдельный проект). Вы делаете первые инвестиции.

Масштаб XL

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

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

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

К вашим обязанностям добавляются операционные моменты обеспечения рабочего процесса. Нужно арендовать офис в Сиэтле для наших ребят? Сделаем! В Бангалоре пропала сеть, есть ли там запасной канал? Узнаем! Нужно перед релизом прогнать систему на всей линейке от Apple, где взять устройства? Найдём! Поменялось законодательство Европейского Союза в сфере информационной безопасности, как это нас коснётся? Переживём! :) Большая часть ежедневных задач уходит от исполнения (execution) к рецензированию, утверждению, консультированию (review, approval, advisory). Вы концентрируетесь на старте новых направлений, формулировании стратегических целей и работе с управленческой структурой.

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

Несколько мыслей напоследок

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

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

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

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

IT-индустрия в Украине продолжает набирать обороты, предлагая отличную платформу для профессионального развития не только в инжиниринге, но и в менеджменте — особенно в международных компаниях. И XL — далеко не последний размерчик. Only sky is the limit! :)

У рубриці DOU Labsми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

Привіт, мене звати Євген Богатирьов. Я очолюю український розробницький центр американської компанії Waverley Software. Вже понад 2 роки ми у партнерстві з бостонською компанією Jibo Inc.створюємо програмне забезпечення для першого соціального робота для дому. Йдеться про робота Джибо, якого було визнано ТОП інновацією 2017 рокуза версією журналу Time. Українські команди працюють над побудовою серверної інфраструктури, мобільних додатків під iOS та Android та забезпеченням якості продукту. Команди розподілені у харківському та львівському офісах компанії, а деякі спеціалісти працюють віддалено з Києва, Одеси та Чорногорії.

Історія

У 2015 компанія Jibo.Inc звернулась до Waverley по експертизу. На той час головний офіс компанії Waverley працював у Кремнієвій долині вже більше 20 років. Українському представництву компанії було лише три роки.

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

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

Джибо знайшов себе на обкладинці Time

Реалізація

Робота почалася у квітні 2015 року. Тоді була залучена невелика команда українських розробників для створення серверної інфраструктури робота. Для проекту ключовими вимогами було підтримання безпеки ти збереження надійності попри невпинний ріст навантаження.

Для досягнення цих цілей були використані такі практики та моделі:

1. Гнучкий підхід до побудови основної платформи

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

• Неоднорідні сервіси (Heterogenous services) — кожен сервіс може бути реалізований за допомогою технології та мови, яка найкраще відповідає його вимогам і використовується розробниками команди.
• Розширене горизонтальне масштабування — мікросервісна архітектура рекомендована для того, щоб кожна служба була максимально гнучкою і легко масштабувалася для взаємодії з різним навантаженням.
• Високий рівень ізоляції — кожен сервіс використовує інші сервіси лише за допомогою своїх API. Це допомагає зберегти складність коду без зайвих зусиль.

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

2. Якість

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

Кольоровий діапазон Джибо — один з засобів відобразити емоції робота

3. Продуктивність

Хоча сервіси призначені для лінійного масштабування, потенційно можуть виникнути проблеми з інфраструктурою, зовнішніми службами та іншими сервісами. Тому розподілені load-тести були розроблені та виконані так, щоб імітувати різну кількість роботів. До бета-тестингу серверна команда імітувала сценарії реального життя із завантаженням, еквівалентним 150 000 роботам. Під час тестування були виявлені та усунені різноманітні слабкі місця інфраструктури.

Сценарії базувались на поведінці користувачів, взятої безпосередньо з реального бета-тестування користувачами (аналіз поведінки через фактичні логи роботів).

4. Інфраструктура

На відміну від звичайної інфраструктури, де налаштування нового середовища займає кілька тижнів, а відтворення бага може розтягнутись на кілька днів, повна інфраструктура сервера Джибо може бути розгорнута протягом 1-2 годин.Це дозволяє створювати окремі середовища для Continuous Integration, тестування навантаження та тестування систем, а також профілювання за короткий час. Для досягнення цієї мети серверна команда використовувала метод Infrastructure as a Code, тобто створила 100% інфраструктури за допомогою скриптів, збережених та перевірених в системі керування версіями.

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

• гнучкості бекенду для подальшого зростання;
• гнучкості розробки, якої вимагає сама непостійна природа стартапу;
• високої надійності системи та можливості максимально швидкого відновлення при аварійних ситуаціях та системних помилках (Load balancing, AWS CloudFormation та ін.);
• повної сервісної автономності, тому кожен компонент може бути масштабований незалежно від інших.

З боку DevOps команда Waverley автоматизувала важливі частини процесу розробки, впровадивши безперервну інтеграцію (Сontinuous Іntegration) та безперервну доставку (Сontinuous Delivery), використовуючи централізовану систему керування програмним забезпеченням (управління користувачами, управління логами та системи моніторингу продукту).

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

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

Частина проектної команди Джибо у харківському офісі

Результати та плани

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

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

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

Від редакції: у рубриці DOU Booksспеціалісти розповідають про 5 своїх улюблених книжок — ті, які змінюють світогляд та корисні читачам-колегам.

[Микола Максименко — Research Lead у компанії SoftServe, кандидат фізико-математичних наук. Займався наукою в Інституті комплексних систем Макса Планка (Німеччина) та в Інституті Вайцмана (Ізраїль). Цікавиться фізикою нейронних мереж]

Радити щось почитати — це завжди дуже відповідально. Хочеться поділитись чимось таким, про що той інший, швидше за все, не мав нагоди почути раніше. Тому замість того, щоб робити ще один список стандартних книжок про ІТ чи підручників з Machine/Deep Learning, я вирішив зібрати список знахідок, якими і сам колись тішився.

Albert-Laszlo Barabasi «Network Science»

«Network Science» від Ласло Барабаші — напевно, одна з перших книжок, яка доступно і цікаво показує, як соціальні явища, економіка, поширення вірусів, генетика та біологія можуть бути описані мовою фізики складних систем. Добрий приклад того, що Big Data не є універсальним молотком для всього, і в багатьох випадках хороше моделювання з перших принципів може дати набагато зрозуміліші результати.

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

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

Peter J. Feibelman «A PhD Is Not Enough!: A Guide to Survival in Science»

У мене часто просять порад, куди піти навчатися в аспірантуру і чи варто це взагалі робити. Це стало особливо актуально у розрізі ML/AI, де PhD часто здається магічним ключиком до найкращих груп і цікавих задач в індустрії. Але часто люди не уявляють, наскільки складним є це питання, адже навіть у Кембриджі чи Гарварді можна робити тупикові дослідження, і місце тут явно не є визначальним.

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

Clayton M. Christensen «The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail»

В українському перекладі — Клейтон Крістенсен «Дилема інноватора. Як нові технології нищать сильні компанії»

Книжка must-read для будь-кого, хто хоче говорити про інновації і R&D. Книга базується на серії наукових праць на тему підривних інновацій і добре розставляє на полички, що це таке, як їх відрізнити і як перед ними встояти. На перший погляд вона виглядає дещо застарілою, адже за основу взяті не зовсім свіжі дані ринків екскаваторів та жорстких дисків, але, як виявилось, описані тенденції є більш загальними і легко прослідковуються в більшості сучасних «проривних» продуктів.

Нещодавно книжка отримала і непоганий український переклад, а теорія підривних інновацій доступна також в короткій вижимці в недавньому Harvard Business Review.

Roger Penrose «The large, the small and the human mind»

В російському перекладі — Роджер Пенроуз «Большое, малое и человеческий разум»

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

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

Petter Wittek «Quantum Machine Learning»

Щоб не боятися наступної AI-зими, пропоную сховатись під ковдру з книжечкою про Quantum Machine Learning і потроху придивлятись до нової хвилі AI. Не можу сказати, що мені дуже подобається саме ця книжка, але вона є непоганою першою спробою структурувати нову ділянку досліджень, яка досить швидко розвивається. Книжка є self-containing, і щоб її читати не обов’язково бути експертом в машинному навчанні чи квантовій механіці — перші розділи навчать як одному, так і іншому.

Сподіваюсь, що цей список стане корисним і пізнавальним. Але якщо для читання лонгрідів не завжди є час та натхнення, то для мене непоганою альтернативою виступають коротші тексти на Quanta Magazineчи MIT Technology Review.

Enjoy!

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

У меня же на фирме вследствие определенных ограничений (мы работаем на внутренний рынок и поэтому вынуждены держать рейты невозможно низко для аутсорса) мы стараемся оптимизировать расходы клиентов на разработку. И разработка на стеке Java EE оказалась существенно дешевле разработки на стеке Spring при некоторых ограничениях.

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

Начнем с истории вопроса

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

Итак, сначала было слово... А, нет, сначала была Java. И был Java Community Process (JCP), процедура в соответствии с которой и происходят все правки и выходят новые версии самой Java и связанные с ней спецификации. Например — Java EE и ее составные части.

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

Тут я должен сделать еще одно отступление (люблю их!) и напомнить, что Java — первопроходец в массе разных направлений. Поэтому сейчас, конечно, приятно ругать JCP за кучу принятых ошибочных решений. Проблема в том, что на тот момент просто не было опыта таких решений, и кто-то же должен был быть первым. Примером такого плохого решения как раз можно считать спецификации EJB 1.0 и 1.1, о которых в Wikipedia сказано мрачно: «The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999». Короче, ребята из JCP вообще не знали, как делать большие Enterprise проекты (и никто на тот момент как следует не знал!). Но вот ребята из IBM (между прочим — один из исполнительного комитета JCP) пришли и сказали: «Мы знаем, как это делать». И в непередаваемом IBM стиле наваяли спецификацию. Два года, потраченные на адаптацию этого решения намекают, что документация была еще та.

В итоге у Java EE появился ключевой его элемент — EJB. Я как сертифицированный специалист по этим первым EJB могу точно сказать: это было чудовищно сложно и криво. Однако у EJB были свои преимущества: автоматическая, прямо из коробки, масштабируемость путем поддержки кластеров серверов приложений, опять же из коробки поддержка авторизации и самое главное — это был стандарт!

Итогом появления первых EJB стали две вещи. Во-первых, страшный хайп в java-мире: «Вот сейчас мы завоюем мир. У нас есть мощные EJB!» Честно-честно, в те годы в мире Java было полно хайпа. Вообще хочу заметить, что если быть в IT больше 10 лет (а лучше 20), то можно увидеть, что хайпы повторяются с определенной цикличностью. Например, современный хайп по Front-end — уже третий. И я точно знаю, чем он закончится (спойлер — возвратом к ультратонкому клиенту). Если интересно, чтобы я рассказал об этом в отдельной статье — напишите здесь в комментариях.

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

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

Но как говорят, свято место пусто не бывает, и программистам все равно нужны были фреймворки для облегчения работы. И они, естественно, пришли. Были их сотни, большинство так и сгинуло, но несколько фреймворков выжило. И парочка из них определила все дальнейшее развитие Java. Я имею в виду Hibernate и Spring DI aka IoC.

История Hibernate не менее драматична, чем история со Spring, но ее я расскажу как-нибудь в другой раз, если вам будет интересно.

А сейчас разговор про Spring. Итак, Spring был маленькой, красивой и приятной в обращении библиотекой. Да, еще не было никаких аннотаций (их добавили позже — уже в Java 5), все конфигурирование заключалось в правке XML файла. Но он был один! Он имел простую и понятную структуру а-ля web.xml! И по сравнению с ужасом конфигурационных файлов Java EE того времени был просто лапочкой. О чем там говорить, все, включая меня, были в диком восторге от Spring. Прошло совсем немного времени, и наличие Spring на проекте стало просто обязательным.

Надо сказать, что JCP не стали ревновать выскочек к успеху и самоотверженно начали впиливать поддержку Spring IoC в стек Java EE. И всё чудесно вертелось. Все, кто хотели (скажем честно — вообще все), использовали Spring IoC в своих проектах, не обращая внимания на то, на чем проект написан.

Но время шло, и жизнь не стояла на месте. Компания Pivotal, разработчик Spring, решила захватить мир, в смысле... Ну да, захватить мир, а что — так нельзя было? И начала клепать новые проекты со словом Spring в названии, чтобы покрыть все возможные и невозможные потребности Java разработчиков. Постепенно то, что раньше называлось Spring, сначала стало одним из проектов, а потом и вовсе слепилось с несколькими другими проектами в то, что сейчас называется Spring Core. А список всех остальных проектов (который раньше висел на сайте в виде красивой инфографики) спрятали от посторонних лиц. И правильно. Если все эти проекты вынести на инфографику, то придется использовать 6-йшрифт, и то картинка будет во всю стену. Постепенно следить за всем этим адом из зависимостей стало уж совсем сложно и появилась необходимость в отдельной библиотеке, которая должна сама все загружать и запускать. Ага, привет, Spring Boot.

Что же случилось с забытой всеми J2EE? Ее переименовали в красивую Java EE, убрав пугающую новичков двойку. Все это время JCP работал над одним — добиться максимального упрощения всего, что только можно. В итоге в современном EJB для описания бина достаточно указать одну аннотацию над классом. Все, у вас уже есть доступ ко всей мощи EJB.

И что? Обрадованные Java разработчики повыкидывали ставший монстром Spring и вернулись к Java EE, который стал таким простеньким? А фиг там. Мыши плакали, кололись, но продолжали жрать кактус.

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

Но вступление, кажется, затянулось. Поехали ближе к теме, рассмотрим оба стека технологий в реальном использовании. Я уже говорил, что за последний год управлял несколькими проектами на Spring стеке и одним на Java EE стеке. Так что есть с чем сравнить.

Стек Java EE

Для начала вот вам картинка с простейшим Java EE приложением.

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

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

Но это мы изучали самое простое Java EE приложение. Посмотрим на что-то более мощное.

Вот так выглядит Java EE с точки зрения его документации. Опять же — скажем, не Rocket Science. Однако все необходимо есть, более того — есть из коробки в любом Enterprise Application Server. Причем все это работает из коробки вместе и на распределенном (кластерном) окружении так же.

Пока просто запомним это и двинемся вперед.

Стек Spring

Простое приложение на Spring стеке не сильно-то и отличается от Java EE.

Картинка отличается от предыдущей по большому счету только большей детализацией. Так что среднее приложение на Spring стеке от приложения Java EE не отличается практически никак.

Единственное отличие, которое сразу стоит озвучить, — это то, что приложение на Java EE может работать в общем случае только в рамках Enterprise Application Server’a (напоминаю, что Tomcat им не является), а приложение на Spring стеке может работать на чем угодно (на том же Tomcat) и даже вообще без сервера (так как запустит его внутри себя самостоятельно). Это делает Spring стек идеальным для реализации элементов микросервисной архитектуры, но за счет отказа от поддержки всех возможностей серверов приложений. В общем случае кластерное приложение — это не про Spring, и вопросы масштабирования для Spring приложения должны решаться отдельно. В большинстве случаев — существенно затратнее.

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

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

Каждый стек считает, что объекты предметной области должны быть тупыми Value Object, а сама логика бизнес-слоя должна храниться отдельно от них (в сервисах у Spring и в EJB у Java EE). А это, как вы понимаете, — разделение данных и поведение — ни разу не соответствует ООП. Это самый что ни на есть обычный процедурный код со всеми своими проблемами. Как минимум мы не можем использовать ни единого шаблона проектирования. Как будто и не было всех этих лет развития Computer Science.

Да, это тема для отдельного разговора. Если интересно — пишите в комментариях, может, я созрею написать статью и про это.

Попарное сравнение стеков

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

Итак, поехали.

Spring DI (Dependency Injection) vs CDI (Context Dependency Injection)

Даже из названия понятно, что ядра в обоих стеках совершенно идентичны по характеристикам. Так и есть. Фактически в Java EE стеке изначально и использовался спринговый DI. Но после того как его включили прямо в Core, использовать его отдельно стало невозможно. Пришлось делать свой DI с аннотациями и программистками.

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

Spring Beans vs EJB (Enterprise Java Beans)

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

Spring Service Locator vs JNDI

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

@Async vs JMS

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

Spring MVC vs Java Server Faces (JSF)

Проблема этого сравнения в том, что SpringMVC в качестве темплейтного движка обычно используется Thymeleaf или в более современном варианте — какой-либо Front-end движок (React, Angular & etc). В то время, как JSF — полноценное GUI решение с поддержкой AJAX из коробки и даже SPA приложений с помощью дополнительных библиотек, включая такие гиперудобные и красивые, как PrimeFaces и IceFaces.

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

Первый проект решили стартовать на стеке Spring. ТЗ было достаточно простое, куча бизнес-логики, но интерфейс достаточно простой и особых проблем вызывать не должен был. И надо сказать, поначалу все шло отлично — MVP мы нарисовали с опережением графика месяца на полтора. Заказчик сказал: «Вау, ребята, вы — молодцы. Делаем теперь основной проект. Мы же можем задействовать MVP?» Мы его заверили, что ни строчки кода не пропадет. Он сказал: «Отлично, давайте начнем с того, что добавим во все формочки AJAX». Все-таки сейчас 2017 год, перегрузка страниц для заполнения формы — как-то не очень.

И тут оказалось, что нативной поддержки AJAX в Spring MVC + Thymeleaf просто нет. Надо каждую операцию писать руками. А у нас практически каждый элемент требует AJAX поведения, причем в разных ситуациях — разного. И писать эту тонну JavaScript мои джаверы вообще не горят желанием. Ну что же. Скрепя сердце были вынуждены выкинуть весь написанный интерфейс и переделать все приложение на Angular (для чего взять еще и Front-end разработчика). И заняло это переписывание где-то больше месяца. Вот и считайте, в какие деньги вышло заказчику наше решение использовать стек Spring.

Второй проект был практически идентичен первому, но в нем заказчик изначально просил учесть серьезные нагрузки в будущем — надо мол будет обрабатывать миллионы обращений. Все обдумав, я решил делать проект на стеке Java EE. Думаю, сложнее морду рисовать, зато в будущем будет легкость масштабирования. И что бы вы думали? Мои разработчики нарисовали примерно аналогичное по объему MVP еще быстрее, но при этом сразу из коробки с поддержкой AJAX. Продолжают работать только джаверы, фронтендер им не нужен. Да, конечно, рано или поздно надо будет сделать красивый дизайн, но дизайнер парт-тайм — это не фронтендер фулл-тайм по деньгам.

Spring Data vs JPA

Это единственный пункт, в котором Spring кроет как бык овцу стек Java EE. Spring Data — прекрасна, великолепна, быстра и удобна. Снимаю шляпу. Очень жаль, что аналога в Java EE стеке нет...

Spring Security vs JAAS

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

Отличия фреймворков вы понимаете и сами. JAAS, естественно, поддерживает распределенность.

Spring Boot vs Enterprise Server

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

Напоминаю, что аналогом Spring Boot для стека Java EE является просто любой Enterprise server. Там уже есть все нужные фреймворки нужных и консистентных версий, уже настроенные для работы друг с другом.

Выводы

• Не надо пытаться все приложения делать на каком-то одном стеке — они предназначены немного для разных вещей. Но надо четко понимать, для чего каждый из стеков подходит лучше. Проще говоря, Java EE — для легко масштабируемого монолитного приложения, Spring — для совсем маленьких приложений с GUI на Front-end или для микросервисной архитектуры.
• Не надо забывать и о том, AJAX — это сейчас очень важно. Если вы планируете делать серьезное приложение на SpringMVC + Thymeleaf — готовьтесь серьезно терять во времени разработки. Писать AJAX руками — это больно. Так что либо React/Angular (модно, красиво, молодежно!) либо по старинке JSF + PrimeFaces. Не настолько прекрасно, но тоже весьма ничего. И без Front-ender. Заметим, что именно для приложений бек-офиса (всяких админок и т. п.) PrimeFaces и их аналоги предлагают запредельное количество готовых бизнес-компонентов, типа календарей, колор-пикеров, часовых поясов и всякого такого. Скорость разработки вы существенно повысите
• Ваши программисты могут и не знать стека Java EE. Как показала моя практика — учатся они ему очень быстро.
• И последнее. Я думаю, маятник, который когда-то вынес Spring на вершину, может пойти обратно к Java EE и скинуть Spring вниз. Я бы не исключал такой возможности.

Большая часть моего опыта в дизайне связана с проектированием и дизайном высоконагруженных энтерпрайз и финансовых систем. Эта область из года в год все стремительнее набирает обороты, но словосочетание enterprise software все так же не вызывает у UX-специалистов особого трепета. Часто работа с корпоративными приложениями воспринимается не иначе как слишком затяжной и консервативный процесс не только для дизайнеров. С точки зрения разработки — специалистов отталкивает рутинное взаимодействие с legacy code и порой абсурдными уровнями сложности, с точки зрения дизайна — слишком жесткие ограничения для дизайн-процесса или же вовсе его отсутствие.

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

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

Что же такое Enterprise UX

Enterprise UX заключается в построении пользовательского опыта для приложений, призванных автоматизировать различные бизнес-процессы внутри огромных корпораций. На первый взгляд, может показаться, что эти системы разрабатываются для того, чтобы решать проблемы бизнеса, а не их пользователей, что идет вразрез с Human Centered Design. Много раз я сталкивалась с мнением, что пользовательские нужды в такого рода проектах трактуются далеко не первым приоритетом, а бизнес-нужды — поразительно скучны. Многих дизайнеров отпугивает мысль о том, что невозможно построить органичный дизайн-процесс, поскольку в подобных продуктах проектирование и дизайн слишком долго покрывались возможностями распределенных девелопмент-команд. Для них скорость закрытия задач часто может быть важнее удобства взаимодействия, а необходимость дизайна в целом не воспринимается всерьез.

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

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

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

Enterprise UX как самое интересное испытание в карьере

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

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

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

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

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

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

Бизнес-цели.На самом раннем этапе важно глубоко разобраться не только в требованиях бизнеса, а и серьезно проанализировать дата-модели и бизнес-процессы, которые являются основой для приложения. По сравнению со многими другими приложениями, корпоративные продукты часто несут в себе большие объемы взаимосвязанных данных, которые требуют обстоятельного анализа, близкого взаимодействия c product owners/business analytics и что очень важно — доверительными отношениями с основными стейкхолдерами. С другой стороны, можно воспринимать ситуацию проще, однако так информационную архитектуру на должном уровне перестроить вряд ли удастся, из чего в дальнейшем будут вытекать самые непредсказуемые и неприятные проблемы.

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

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

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

Выводы

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

Разумеется, Enterprise UX не может нравится и подходить всем без исключения, поскольку это точно не станет праздным творением в перерывах между командировками. Работа в этом домене, по моим наблюдениям, ощутимо меняется. В энтерпрайзе начинается эпоха «Good enough is no longer enough», и, возможно, это та самая возможность работать над созданием чего-то по-настоящему глобального.

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

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

В выпуске: сравнение юникодных String и NSString, Xcode unit tests with ⌘+S, как устроены процессы в Яндексе, подборка хаков из твиттера.

Статьи

Key difference between Dictionary and NSDictionary
Интересная особенность, как сравниваются юникодные String и NSString и какие из-за этого могут быть баги.

Why <blank> Gets You Root
Разбор недавней уязвимости с пустым паролем для рута.

Coordinator and FlowController
Очередной лонгрид про координаторы. Кто еще не использовал — самое время.

Swift Analytics
Краткий разбор подходов к аналике от Chris Eidhof. Советую ознакомиться со всеми подходами, описанными в начале.

Hacks

Пост в Twitter Rick Ballard
Xcode Build System работает над тем, чтобы улучшить компиляцию свифта, вот только с документацией у них не очень получается.

Stop Xcode from constantly rebuilding your project because of @IBDesignable
Наверное, каждый, кто пытался сделать IBDesignable view, сталкивался с тем, что Xcode начинает бесконечно билдить проект. Оказывается, это можно отключить.

Optimizing Swift build times
Советы, как оптимизировать скорость компиляции свифта. Ключи -Xfrontend -warn-long-function-bodiesи -Xfrontend -warn-long-expression-type-checkingуже просто must-have для свифтовых проектов.

A Quick Tip For String Performance
Интересный хак, как улучшить производительность при работе со строками на 18%.

Best iOS hacks from Twitter: November Edition
Набор хаков из твиттера. Коротко и по делу.

Changing Xcode Header Comment
В Xcode 9 теперь легко можно поменять заголовок файла, который генерируется по умолчанию.

Tools

Hyperion-iOS
Очень интересный тул, с помощью которого можно измерить расстояние между объектами, посмотреть их размеры, атрибуты текста прям в приложении. Такой себе встроенный Zeplin.

stylesync
Еще один инструмент, который помогает при работе с дизайном. Генерирует Swift файлы со стилями, цветами и прочим из Sketch.

Getting Started with Fastlane.swift
Fastlane переходит на Swift. Пока в бете, но скоро можно будет писать конфигурации на Swift и не гуглить «как же это сделать на Ruby».

Xcode unit tests with ⌘+S
Сохраняешь файл и сразу прогоняются все тесты, которые с ним связаны. Магия да и только.

Видео

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

Avito iOS Winter Edition
Data-driven подход, как прокачать lldb, что такое Mach-O и dSYM, и архитектуры, куда же без них.

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

CocoaHeads Санкт-Петербург
Проблемы AutoLayout, библиотеки для работы с layout, как разрабатывали CocoaHeads приложение и также небольшая панельная дискуссия.

CocoaHeads Москва
Адаптация под iPhone X, блокчейн, Copy on Write в Swift, а также занимательный нетехнический доклад про сомнения и заблуждения в карьере программиста. И опять же панельная дискуссия.

Moscow Meetup CocoaHeads
Особенности работы с GPU, распределенная сборка IPA и уже излюбленный рассказ от ребят из Яндекса про оптимизацию запуска iOS приложений.

From iOS to Vapor developer
Интересное сравнение того, как привычные вещи для iOS разработчика сделать на бекенде с применением Vapor. Must-have для тех, кто боится, но хочет начать писать бекенд на Swift.

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

← Предыдущий выпуск: iOS дайджест #21

А также: Bitcoin Wallet, закрытие Project Tango, стоимость разработки мобильного приложения, доклады с KotlinKonf, работа с Flutter, новые требования Google Play Store, Model-View-Intent Architecture, история изменений Android SDK и еще много интересного!

Новости и аналитика

Официальный запуск Android 8.1 Oreo и Android Oreo (Go edition).

Google Play Store вводит новые требованияк приложениям. Усиление верификации APK, 64-битныеверсии, использование последнего API level.

Google is shutting down Project Tango. Цели проекта достигнуты, развитие дополненной реальности продолжится в проекте ARCore для массового рынка.

Сколько стоитмобильное приложение в 2017 году.

Announcing TensorFlow Lite: кросс-платформенное машинное обучение на мобильных устройствах.

Безопасность данных и приложений

 Encrypting Large Dataот Yakiv Mospan.

Diving into Android Oreo security changes.

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

Kotlin

Видео всех докладов с KotlinConf. Структурированы и прокомментированы.

Kotlin’s ‘Nothing’ Type.

Kotlin Design Patterns.

Почитать/посмотреть/попробовать

Почему Flutterне использует OEM виджеты.

MVP & Lifecycles & Dispatchers Oh My!Очередной бинго-набор паттернов от Mike Nakhimovich.

«Ok, Google —  How do you run Deep Learning Inference on Android Using TensorFlow?».

The Art of Android DevOps.

React Native: Is It Worth It?Кросс-платформенность не бывает бесплатной.

RecyclerView Pro Tips. Четыре простых совета под правильным соусом.

Quick Boot & the Top Features in the Android Emulator.

Migrating Crashlytics to the Firebase Console.

Best practices for Deeplinking in Android.

The Contract of the Model-View-Intent Architecture.

Creating Clean Architecture Multi-Project MVP App. Полный код на гитхаб с самыми трендовыми фреймворками сезона прилагается.

Полезные инструменты и библиотеки

Bitcoin Wallet: Open-source app for your Android device.

Daggraph: Dagger dependency graph generator.

AndroidSDKPoster: Wall poster with detailed changelog of Android SDK versions 14-27, broken down into 30 categories.

SimpleRatingBar: виджет для рейтинга, настраиваемый для ваших нужд.

Какие темы/материалы/ивенты стоит добавить в дайджест — пишите в комментариях, твиттер @sergiizhukили воспользуйтесь специальной формой.

← Предыдущий выпуск: Android дайджест #28

[В рубрике «Как я работаю»мы приглашаем гостя рассказать об организации своего воркспейса, полезных инструментах и лайфхаках]

Антон Багаев — web-программист в компании PDFfiller. Помимо основной работы, Антон с несколькими единомышленниками разрабатывает собственные проекты в команде Don’tgiveafish. В их числе сайт про курс валют Гривня Тудей, открытая база данных отделений служб доставки Smartdelivery, ремейк игры Space Invaders Rada Invaders. Сейчас в разработке — сервис Kukurudzaдля поиска сеансов в ближайших кинотеатрах.

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

Возраст и опыт: 27 лет, 8 лет работает в IT.
Модель смартфона: iPhone SE.
Модель ноутбука: MacBook Pro 13.
Суперспособности:находить потенциал и мотивацию у коллег даже там, где ничего не увидел Супермен.

— Как проходит ваш типичный рабочий день?

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

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

— Какие гаджеты, девайсы используете ежедневно?

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

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

— Как выглядит ваш воркспейс? Какими инструментами пользуетесь?

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

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

Из инструментов активно использую разные напоминалки (стандартные от Apple, Google-календарь, Productive), Trello, Slack или Telegram. Для пет-проектов список текущих задач веду там, где лежит код, — обычно это GitLab или GitHub. Кроме этого, веду списки дел в Evernote. Также записываю там идеи проектов, конспекты прочитанных книг, разные свои мысли и наблюдения — например, как по моему мнению должна выглядеть идеальная компания.

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

— Используете ли какие-то практики по тайм-менеджменту?

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

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

— Как часто проверяете почту, соцсети, мессенджеры?

Каждые 15 минут. Но, мне кажется, это слишком часто. Хочу ограничить до раз в полчаса-час.

— Ваш любимый to do менеджер?

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

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

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

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

— Сколько часов в неделю работаете?

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

В книге Роберта Мартина «Идеальный программист» говорится о том, что необходимо делать, чтобы стать хорошим программистом. Автор рекомендует 40 часов в неделю тратить на решение проблем клиента или работодателя и 20 часов заниматься своими проектами и учиться. Я к этому стремлюсь.

— А отпуск часто берете?

Несколько раз в год куда-то выбираюсь на неделю-две. Пытаюсь выезжать куда-то и на выходные. Иногда беру дополнительные отгулы на 1-2 дня.

— Что вас вдохновляет?

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

— Что помогает быть продуктивным?

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

— Вы экстраверт или интроверт?

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

— Что последнее прочитали или читаете сейчас?

Сейчас читаю книгу «Идеальный программист» Роберта Мартина. До этого читал Патрика Ленсиони — о том, как должна выглядеть корпоративная культура. В последнее время начал конспектировать и вести заметки во время обучения. Конспект последней книги выложил на фейсбуке. Если формат приживется, буду выкладывать свои заметки и дальше.

В планах — книга «Парадокс выбора» Барри Шварца — о свободе выбора и о том, как принимать правильные решения и не париться над сомнительными.

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

— С кем из известных личностей хотели бы встретиться? Что бы спросили?

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

Хотел бы повидать Дэвида Гилмора — он самый крутой музыкант в мире, и влияние музыки Pink Floyd на меня невозможно переоценить.

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

— За что любите и не любите свою работу?

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

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

— Что бы вы посоветовали себе 10 лет назад?

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

— Кем себя видите через 5 лет? :)

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

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