Я начал работать с фреймворком Angular 2 в мае 2015-го.Тогда он был в альфа-версиях, и наша компания активно искала JavaScript-фреймворк для замены фронтенда большого приложения, сделанного на Adobe Flex. К тому времени мы уже попробовали Ext JS и Angular JS и не были в восторге. Зато нам понравилась комбинация компонентной структуры Ангуляра, типизированного языка TypeScript и хорошей поддержки IDE. Прошло почти три года, и мы довольны своим выбором. Эта статья — обзор Ангуляра.

Ваше приложение — дерево компонентов

Когда разработчик получает картинку с прототипом будущего приложения, он начинает с разбивки его на компоненты. Любое приложение на Ангуляре имеет один корневой компонент, который может включать другие компоненты («дети»), а те, в свою очередь, могут включать своих детей («внуков»). Допустим вы решите переписать Twitter UI на Ангуляре. Начните с разбивки его на компоненты.

Корневой компонент показан в красной рамке, и он включает несколько детей. В середине сверху можно разместить компонент New Tweet (в синей рамке) под которым пойдут экземпляры компонента Tweet (показаны в желтых рамках), у которых тоже есть «дети», показанные в черных рамках (reply, retweet, like, and direct messaging).

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

Чистое разделение между UI и апликационной логикой

Компонент — это TypeScript-класс, аннотированный декоратором @Component, где вы указываете метаданные компонента: HTML и CSS. Их можно имплементировать либо в отдельных файлах, либо прямо в декораторе (inline), как в этом примере:

@Component({
  selector: 'home',
  template: `<div class="home">Home Component<input type="text"/> </div>`,
  styles: [`.home {background: red; padding: 15px 0 0 30px;
                   height: 80px; width:70%;
                   font-size: 30px; float:left;}`]})
export class HomeComponent {
   // Implement business logic here
}

Когда темплейт (HTML) или стили состоят из многих строк, их можно держать в отдельных файлах:

@Component({
  selector: 'home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css']
export class HomeComponent {
}

Навигация на клиенте с помощью раутера

Ангуляр хорош для создания single-page apps (SPA). Браузер не перезагружает всю страницу, а только ее фрагменты, по мере того как пользователь взаимодействует с приложением (жмет на кнопки, ссылки и т. д.). У Ангуляра есть Router для навигации внутри приложения. Внутри темплейта компонента с помощью тега <router-outlet>можно выделить одну или больше областей для отображения разных фрагментов страницы. Например, в приложении Twitter вы можете выделить среднюю часть страницы под <router-outlet>, и, если пользователь нажмет на меню Notifications, в этой области будет показан другой компонент.

Модуляризация приложения

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

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

Dependency injection

Компоненты — это классы, у которых есть UI, а сервисы — это классы, содержащие аппликационную логику. Вы пишете такой класс, например, ProductService, а Ангуляр создает его экземпляр и вставляет (injects) его в ProductComponent. Для этого нужно просто указать сервис аргументом конструктора компонента и не нужно создавать экземпляр класса оператором new:

@Component(...)
class ProductComponent{

  constructor (public productService: ProductService){ }

  onClick(){
    this.productService.getProducts();
  }
}

В этом примере мы используем API сервиса в обработчике события click.

TypeScript и ECMAScript

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

Typescript легко изучить любому, кто знает Java, C#, PHP или Python. Этот язык поддерживает классы, интерфейсы, наследование, дженерики и многое другое. Вы пишете на TypeScript и компилируете код в JavaScript, который понимают все браузеры. Взгляните на вот этот скриншот и сравните TypeScript-код слева со сгенерированным эквивалентом на JavaScript (ES5) справа. Не знаю, как вам, а мне больше нравится версия на TypeScript.

Все браузеры поддерживают синтаксис JavaScript версии ECMAScript 5 и большинство современных браузеров уже поддерживают ES6, который добавил много элементов, включая классы. ES7 и ES8 добавили немного, хотя важным улучшением является введение ключевых слов asyncи await, которые позволяют вырваться из ада колбэков. Если вы будете писать на TypeScript, то можете пользоваться последними новинками уже сегодня, а компилятор сам преобразует код в ту версию JavaScript, которая поддерживается всеми браузерами.

Шлепаем формы

Трудно представить веб-приложение, где не нужны формы. Ну, хотя бы залогиниться надо?

За каждой формой стоит объект с моделью данных, хранящей все значения, введенные пользователем. Ангуляр предлагает два API для форм: template-driven и reactive. Тот, который template-driven, позволяет кодировать формы, не парясь созданием модели в TypeScript. Просто спрысните HTML-формы несколькими директивами, а Ангуляр сам создаст модель.

Для более продвинутой работы с формами используйте reactive Forms API. Здесь вы сами будете кодировать объект модели в TypeScript, зато у вас будет больше контроля над поведением формы.

И template-driven и reactive API имеют встроенные валидаторы и позволяют использовать кастомные, чтобы пользователь не вводил невесть чего. Можно и на сервере организовать валидацию с использованием так называемых асинхронных валидаторов.

Реактивное программирование

В последнее время стали популярными реактивные (RX) библиотеки, которые построены на работе с observable потоками данных, которые асинхронно генерируются каким-либо источником, например событиями мышки,сенсорами, сокетами и т. д. Такие библиотеки включают большой набор операторов, которые легко собирать в цепочку для манипуляции данными по дороге от источника данных до подписчика. Ангуляр поставляется с библиотекой RxJS и вы можете либо подписываться на готовые observable streams предоставляемые разными APIs, либо создавать такие потоки сами.

Допустим, пользователь вводит название акции из финансовой биржи в поле searchInput. Следующий код подписывается на поток valueChanges (он есть у всех ангуляровских элементов форм) и хочет сделать запрос к серверу, чтобы получать меняющиеся цены на эти акции. Чтобы миниизировать количество запросов к серверу, мы используем оператор debounceTime, чтобы функция getStockQuoteFromServer() вызывалась, только если пользователь ничего не вводит в течение 500 милисекунд.

this.searchInput.valueChanges
  .debounceTime(500)
  .subscribe(stock => this.getStockQuoteFromServer(stock));
 }

Код получается компактным, но будьте готовы потратить время на изучение библиотеки RxJS. В этом примере я поместил один оператор debounceTimeмежду источником данных и подписчиком, но я мог собрать цепочку из нескольких операторов, например mapи filter. Можно добавить одну строку с оператором switchMap, который автоматически будет отписываться от запросов, которые еще не вернулись (медленный интернет), а пользователь уже вводит новое значение. Попробуйте отменять ненужные запросы у простых Ajax-вызовов — oдной строчкой не обойдетесь.

Современный UI

Многие веб-приложения используют популярную библиотеку Bootstrap для стилизации и разметки (layout) страниц. Вы можете пользоваться этой библиотекой и в приложениях на Ангуляре. Bootstrap поддерживает responsive web design, чтобы расположение UI-компонентов автоматически адаптировалось к ширине экрана устройства пользователя.

Есть и другие библиотеки, сделанные специально для Ангуляра. Angular Material — это библиотека, включающая 30 современных компонентов, сделанных согласно спецификации Google Material Design. Если вам нужно больше компонентов, используйте одну из сторонних библиотек. Так, например, PrimeNG включает 75 UI компонентов, сделанных специально для Ангуляра.

Тулзы

Генерация нового проекта с установкой всех зависимостей занимает около минуты с помощью Angular CLI — программы, запускаемой с командной строки. Angular CLI не только генерирует новые проекты, но и компоненты, сервисы и другие артефакты в процессе работы над проектом. Angular CLI включает веб-сервер с автоперезагрузкой кода. В вашем проекте могут быть сотни файлов, однако одной командой они собираются в несколько JavaScript-файлов (bundles). Размер минимального приложения, обработанного gzip, — 55KB, а скоро будет значительно меньше. Не вау? Читайте статью до конца. При правильной разбивке приложения на модули оно быстро грузится.

Дебажить TypeScript-код можно либо прямо в браузере, либо в IDE.

Проекты, сгенерированные Angular CLI, включают полностью сконфигурированные библиотеки для unit и end-to-end тестирования.

Ангуляр на мобильных устройствах

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

• Используйте один и тот же код для десктопов, планшетов и смартфонов, но имплементируйте приемы responsive web design для изменения содержимого и разметки экрана в зависимости от его размера.
• Используйте одну из библиотек (например Native Script), которые предлагают набор тегов для применения в темплейтах компонентов Ангуляра с автозаменой их на нативные компоненты iOS или Android.

Server-side rendering

Sever-side rendering (SSR) еще более улучшает скорость рендеринга в браузерах. SSR еще на сервере готовит HTML-страницу из вашего ангуляровского приложения. Это особенно полезно, если ваши пользователи используют мобильники или вам важно, чтобы приложение лучше находилось поисковиками. Angular Universal — это технология, которая генерирует статические веб-страницы на сервере.

Если у вас уже рука тянется к клавиатуре, чтобы написать: «А Реакт лучше Ангуляра», — не тратьте время зря. Не будем сравнивать мягкое с теплым. Хотя почему бы и нет?

Так Angular или React?

Вы сможете нагуглить много статей «Почему мы перешли с Ангуляра на Реакт» и «Почему мы перешли с Реакта на Ангуляр». Помните, что Ангуляр — это полноценный фреймворк, который поддерживает быструю отрисовку страниц, навигацию, dependency injection, стильные UI-компоненты, server-side rendering, сконфигурированные тулы для тестинга, минимизации, деплоймента и много чего другого. Реакт — это библиотека для быстрой отрисовки страниц, и вам придется самому собирать набор других библиотек для routing, UI-компонентов, сборки и т. д.

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

Если вы работаете в маленьком стартапе, где есть только 2-3сильных разработчика, выбор фреймворка менее критичен. Эти 10X разработчики продуктивны с любым фреймворком, библиотекой или просто с чистым JavaScript. Да и увольняются из стартапов реже, чем с галер.

Что день грядущий нам готовит

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

Angular Elements. Ангуляр хорош для создания single-page applications, а создание виджетов, которые можно использовать на любой HTML-странице, — непростая задача. Новый модуль Angular Elements позволит создавать отдельный компонент и публиковать его как Web Component, который можно будет использовать на любой HTML-странице. Эта фича — киллер, которая откроет еще больше дверей для Ангуляра.

Ivy renderer. Этo новый движок для рендеринга, который уменьшит размер минимального приложения до 3KB (gzipped). Разработчики Ангуляра обещают сделать переход на Ivy Renderer гладким. Если они это сделают, я сниму шляпу.

Bazel and Closure Compiler. Bazel — это сборщик, используемый внутри Google почти для всех приложений, включая 300 приложений, написанных на Ангуляре. Closure Compiler отлично оптимизирует билды, генерирует бандлы и лучше, чем Webpack и Rollup, убирает неиспользуемый код. В новых релизах Angular CLI будет использовать эти тулзы.

Component Dev Kit (CDK). Этот пакет уже есть и используется UI-компонентами из Angular Material. А что если вы захотите сделать свою библиотеку UI-компонентов и контролировать разметку страницы? CDK позволяет это сделать.

Schematics. Angular CLI генерирует код на основе калек (blueprints). Если вы решите создать свои кальки, чтобы Angular CLI ими пользовался при генерации, Schematics вам поможет.

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

Для тех, кто уже знает основы Ангуляра, предлагаю записаться на мои короткие онлайн-тренинги. Одинпо созданию симпатичного UI — за две сессии под моим чутким руководством вы сделаете фронтенд небольшого онлайн-магазина. Второйворкшоп о state management в стиле Redux с помощью библиотеки ngrx. Для читателей DOU — скидка 25% с промо кодом «dou». Оба воркшопа на английском, звиняйте.

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

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

Александр Ненько, 56 лет, Senior Java Developer в Ignite

Я работаю в IT 37 лет, включая 3 года работы во время учебы в КПИ. За это время занимал такие позиции: программист (много раз), тимлид, проектный менеджер (и настоящим PM’ом был, и Delivery-менеджером), директор небольшой IT-фирмы. В последние 8 лет — Senior Java Developer в разных компаниях. Это самое то для меня — спокойно и денежно.

Я считаю, что возрастная дискриминация в IT существует. Свежий пример: люди всерьез обсуждают, как сложно устроиться на работу в 37 лет. И пусть они заблуждаются, но высказывают общепринятое мнение, что старикам тут не место.

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

Об общении с коллегами.Проблемы коммуникации с молодыми в коллективе — встречались. Когда в отделе 10 человек по 23-30 лет,а ты один — 55, то влиться в коллектив бывает сложно.

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

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

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

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

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

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

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

Алексей Пузыренко, 51 год, Senior Database Developer в HYS Enterprise

В IT я работаю с 1990 года, сразу после окончания Одесского политеха. Мне очень повезло с первым местом работы. В те времена после института в обязательном порядке направляли на конкретное место, где нужно было отработать не менее 2 лет. Меня «распределили» в Москву, в Институт точной механики и вычислительной техники им. Лебедева при Академии наук СССР. Несмотря на зубодробительное и тяжело произносимое наименование, народ собрался просто отличный — молодые ребята, «больные» компьютерами. Мы занимались разработкой советского mainframe Эльбрус-3.

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

Сначала работал в основном как Full Stack, но c 2009 года больше углубился в базы данных. Занимался обычными реляционными БД, строил Data Warehouse, занимался BI/ETL, разрабатывал Business Intelligence portals.

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

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

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

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

Влиться — не значит «втиснуться». Смешно и глупо смотрится человек, который ведет себя как «ветеран первой пунической войны». Типа «у меня +100500 лет опыта, что вы, сопляки молодые, можете знать» :) Так же нелепо выглядит человек, который пытается вести себя «по-молодежному»: нарочито и напоказ использовать, как ему кажется, молодежные словечки. Не стоит изображать из себя «инфантильного пэнсионэра».

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

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

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

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

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

Ігор Хомяк, 56 років, Senior iOS Engineer в Lohika

Я працюю програмістом з 1979 року — вже 38 років поспіль. Почав кар’єру ще на першому курсі Львівської Політехніки у студентському конструкторському бюро: брав участь у розробці баз даних для заводів радіотехнічної галузі. Далі — науково-дослідна робота (тепер — модне R&D) і керівництво групою у свої 23 роки (тепер — це Senior/TeamLead) у дослідному бюро телевізійного концерну. Після цього займався наукою, викладав у Політехнічному інституті, керував студентськими розробками. Згодом працював у бізнесі на посаді, яка відповідає теперішній посаді СТО.

Коли мені було 37 — це був 1999 рік — переїхав до Києва та почав працювати в ІТ-компанії. Провів там 11 років, з них майже 10 — як TeamLead. У 46 років відчув нестримне прагнення розвитку та спробував себе в ролі Senior/TeamLead у декількох топ-компаніях та стартапах. Наразі прийшов у Lohika і надіюсь на тривалу співпрацю.

Про пошук роботи.Минулого року я міняв роботу 3 рази: вибирав стартапи зі своїх міркувань. Але перехід на нову роботу та адаптація там — це все одно стрес. Останній перехід був недавно: в лютому цього року. Цього разу я вирішив перейти в стабільну компанію.

Особливих складнощів не виникло, на пошук роботи та перехід знадобилося менше місяця. Мені навіть довелося відмовити двом компаніям.

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

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

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

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

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

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

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

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

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

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

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

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

Я знаю дуже мало випадків пізнього старту кар’єри в ІТ, але вони є. На минулому проекті мав колегу: він колишній військовий, який не програмував до звільнення в запас. Він займався фотографією і в якості першого проекту створив власний сайт зі своїми роботами. Зараз він програміст екстра-класу з C++.

Борис Подпоринов, 50 лет, Senior .NET Developer в SoftElegance

Работаю в IT 27 лет. Начинал как инженер-математик в институте кибернетики на 5-мкурсе КПИ. Затем — в Институте космических исследований. Интересный случай у меня был при приеме на работу после окончания КПИ. Во время собеседования мне предложили должность математика 2-йкатегории. Но пока я добирался до отдела кадров на другой конец города, коллеги убедили шефа, что зарплата для этой должности слишком маленькая. Начальник отдела перезвонил в отдел кадров, и, когда я туда пришел, меня приняли на работу как математика 1-йкатегории. Такой вот стремительный карьерный рост за 1,5 часа :)

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

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

Об общении с коллегами.С проблемами в общении с молодыми коллегами я не сталкивался. Надеюсь, они тоже не сталкивались, общаясь со мной.

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

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

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

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

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

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

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

Александр Шеховцов, 52 года, ITSM-менеджер в Zone3000

Я работаю в IT почти 29 лет. В начале своей трудовой деятельности работал инженером в НПО «Хартрон» — занимался администрированием компьютерной сети и программированием. Потом много лет работал в международной компании Philip Morris Украина. Мои обязанности были сосредоточены вокруг IT: поддержка пользователей, поддержка серверной и сетевой инфраструктуры, внедрение SAP ERP, информационная безопасность и IT-аудит. В последние годы занимался координацией сервисов в рамках Eastern Europe and Middle Africa кластера и контроля услуг от глобальных поставщиков.

Сейчас работаю в IT-компании Zone3000, занимаюсь внедрением ITSM-процессов, формализацией процедур и практик компании.

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

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

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

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

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

Сейчас очень много интернет-ресурсов, где можно найти необходимую информацию. Главная сложность — время.

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

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

Владимир, 55 лет, Scala Developer

Рассказчик пожелал остаться анонимным

Я начал программировать в 90-хгодах, то есть имею уже около 20 лет опыта. Писал на Clipper, Delphi, затем Java и сейчас — на Scala.

О поиске работы.В нынешней компании я с начала 2017 года. До этого в течение примерно года-полтора сменил 2 места работы. Даже на 3 месяца уезжал поработать в Европу — во второй раз. Впервые я там работал с 2010 по 2012 год по контракту.

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

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

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

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

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

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

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

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

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

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

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

Каким будет продукт, предстояло решить нам

Работа над проектом началась в июне 2016 года. Заказчик показал свои идеи, иллюстрации и ориентировочный workflow. На первый взгляд всё было логично. Дьявол же прятался в деталях. Мы задавали массу вопросов: «Что должна делать эта фича? А вот эта? Как система отреагирует, если превысить лимит загрузки документов?». Ответов не было. Для клиента это был первый продукт и новый рынок частных компаний. Каким он будет, предстояло решить нам.

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

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

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

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

Параллельно команда работала над технологиями. И это было True Technical Madness. Платформа — одно из первых решений на .NET Core и AWS для заказчика. Он хотел построить его на базе новейших технологий: Angular 2.0, .NET Core 2.0, Amazon Cloud, Docker. Летом 2016 года часть из них действительно были новейшими и совершенно сырыми. Большинство — пререлизы и бета-версии — компилировалось плохо, вылезали незадокументированные результаты. А на стороне заказчика не было ни одного технаря. Поэтому нам самим пришлось «подружить» Amazon Cloud с .NET, который к тому же запускался на Linux-машинах. У кого ни спрашивали — почти никто не работал с большинством сервисов, которые мы учились использовать. И используем сейчас.

Выбросить все несрочное

К сентябрю выстроили архитектуру процессов, расставили приоритеты в разработке фич. А в октябре команда отправилась в Нью-Йорк представлять планы по разработке. Мы надеялись, что заказчик, увидев объем работ, перенесет релиз на весну 2017 года.

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

Раз время стало критичнее функционала, значит, долой лишний функционал.

«Давайте упрощать первую версию портала и оставлять только ключевые инструменты», — предложили мы. Без вариантов.

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

Что делает сторонняя команда?

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

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

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

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

Все дискуссии и обсуждения из области бизнеса мы перевели исключительно в техническую плоскость и перешли на общение контрактами. Четко формулировали требования исходя из мокапов для нашего приложения: «Для этого скрина нам нужен от вас сервис, который принимает АВС и отдает XYZ, а для этого — все то же самое, только чтобы работал, как google autocomplete search». На это ушло еще три недели офлайн-обсуждений, но ребята оперативно выдали нам то, что мы от них ожидали.

Собственно разработка и роль delivery manager

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

В команде нас было шестеро. Каждый работал над своими заданиями. Задачи по infrastructure & server-side development распределялись между 4-мя .NET developer’ами. Client-side development и верстку взяли на себя front-end developer’ы. Работали в режиме конвейера: кто первый закончил задачу, тот берет следующую в очереди.

После успешного MVP команда увеличилась до 9, а сейчас насчитывает 30 человек

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

MVP удалось завершить вовремя. В январе product owner уже провел презентацию менеджменту в Нью-Йорке. Продукт не был суперкрасивым и идеально удобным, но мог жить и выполнять задачи.

С тестового сервера в продакшн

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

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

Мы понимали, что без кеширования получить хороший перформанс будет невозможно, поэтому добавили кеширование наиболее часто запрашиваемой и легко инвалидируемой информации. Увы, перевести тяжеловесные процессы на асинхронную модель выполнения получилось не сразу. Это нам аукнулось, когда появился пользователь, который превысил изначально планируемые NFR’ы в 10 (!) раз.

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

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

Уроки

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

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

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

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

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

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

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

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

Возможность поучаствовать в «Формуле 1» в роли Product Owner’а показалась мне очень привлекательной. Как говорит мой друг, в крайнем случае у меня бы не получилось и я остался бы там, где начинал. Я рисковал всего лишь парой часов Borderlands в неделю. Так я думал в самом начале. Забегая вперед, скажу, что на сегодня это одна из крупнейших ошибок в оценке проектов.

Итак, расскажу об Android-приложении «Общественный транспорт — Одесса», которое мы разработали во время стажировки.

Идея

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

Мы долго обсуждали другие возможные идеи. Эта показалась самой привлекательной по двум причинам: достаточно широкий диапазон функциональности, чтобы стажерам было интересно, и достаточно небольшой объем работ, чтобы вложиться в период стажировки. Раз Uber, Facebook, Chatroulette и Dota 2 уже готовы — что нам оставалось?

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

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

Как работает приложение

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

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

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

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

Android-технологии

Мы использовали Android SDK, минимальная версия ОС 4.4 (19), Room для работы с базой. Из сторонних либ: ButterKnife, Retrofit 2, RxJava, Dagger 2, EventBus.

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

Бывало, что при разработке возникали сложности. Например, корректное построение маршрутов: они должны были проходить по улицам, где есть остановки общественного транспорта, а не поперек карты — через жилые кварталы и дома. Также были трудности с созданием удобного UI/UX и кешированием данных на клиенте.

Набор стажеров и коммуникация на проекте

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

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

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

Мы разделились на группы по 3-7 человек,и каждая группа начала работать над своим проектом. Вместе с другими менторами мы написали User Story, сделали декомпозицию задач, оценили трудозатраты с поправкой на навыки и знания стажеров, набросали матрицу рисков, разложили таймлайн и диаграмму Гантта. Нам показалось, что мы успеваем начать и закончить проект за четыре месяца разработки.

Потом пришло время набирать стажеров. Я на собеседованиях не присутствовал, так как выполнял в проекте роль Product Owner’а и мне стажеры не полагались. В результате, к нашей команде присоединились два Android-разработчика, два разработчика Java (Backend) и четыре QA-инженера.

Команда проекта «Общественный транспорт — Одесса»

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

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

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

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

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

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

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

Проект завершился успешно. Приложение доступно для скачивания в Google Play. Сейчас у нас больше 10 000 тысяч скачиваний и 1 500 и 2 000 пользователей в день. В команде есть люди, которые планируют поддерживать работу сервиса и расширять функциональность.

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

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

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

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

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

Для чего нужно прототипирование

• Выявление и написание требований к функционалу, интерфейсу, веб-сайту.
• Управление ожиданиями заказчика.
• Иллюстрирование user stories или use cases для того, чтобы они стали более понятными (в том числе и для самого аналитика).
• Создание собственно дизайна, когда в команде нет дизайнера (редко).
• Утверждение основных блоков и расположения с заказчиком.
• Передача требований дизайнеру.
• Тестирование расположения блоков, кнопок, да и валидация идей.

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

Визуальное представление, понимание, оценка и изучение идей также лежат в основе методологии Design thinking.

Какие бывают прототипы

Так как чаще всего мы работаем с иностранными заказчиками, то и термины будут звучать на английском: wireframe и prototype (low-fidelity prototype, high-fidelity prototype).

Wireframe

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

Что даёт wireframe:

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

Кто делает:менеджеры, бизнес-аналитики, маркетологи, дизайнеры и UX-дизайнеры.

Олег Руденко, Senior Business Analyst в EIS Group:

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

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

Low-fidelity prototype (прототип малой детализации)

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

Прототип малой детализации чаще всего применяется для окончательного утверждения расположения функциональных блоков с заказчиком или другим ответственным лицом (product owner). При создании переходов по кнопкам и ссылкам между страницами используется для пользовательского тестирования. Создать готовый кликабельный прототип такого типа можно в Axure. Отдельно переходы можно сделать в Invision или Marvel.

Если хотите сделать прототип более привлекательным для клиента, но вы не Web- или UI-дизайнер, сделайте равные расстояния между блоками и определите иерархию размеров шрифта (заголовки 1, 2, 3 уровней и основной текст, ссылки).

Кто делает: менеджеры, бизнес-аналитики, маркетологи, дизайнеры и UX-дизайнеры.

Ирина Тищенко, Marketing Ninja of Ministra TV platform в Infomir:

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

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

High-fidelity prototype (прототип высокой детализации)

Этот вид прототипа уже выглядит как готовый продукт с подобранным стилем и pixel perfect элементами. Он тестируется на соответствие требованиям по доступности для людей с разными видами нарушения восприятия цветового диапазона. Утверждается с заказчиком и передаётся в разработку.

Кто делает: только дизайнеры.

Выводы

Любой из представленных видов прототипа можно (и нужно) сделать кликабельным и протестировать на ваших потенциальных пользователях. Для этого есть такие приложения как Balsamiq, Axure, InVision, Marvel и многие другие.

Расскажу об одном продукте, который отправили в продакшн, минуя стадию тестирования. Приложение было предустановлено на устройствах, но люди им не пользовались. Тестирование показало, что большинство респондентов не поняли, что с ним делать. В чём была проблема? Прототипы не были протестированы на реальных людях. Что это значит? Работу пришлось делать дважды, но теперь правильно. Представьте себе рейт минимально необходимой команды из дизайнера, разработчика, тестировщика и менеджера.

Делайте прототипы: экономьте ваше время, деньги проекта и нервы ваших пользователей :)

DOU много лет проводит опросы программистов на самые разные темы, от зарплатного опроса до портрета ИТ-специалиста, но практически никогда не опрашивает «другую сторону» — работодателей. Мы решили исправить это на Джиннеи провели опрос среди работодателей и рекрутеров. Опрос проходил в феврале 2018 года, собрали 897 анкет.

Ищут не только рекрутеры

Должность

Неудивительно, что программисты часто путают HR и рекрутеров. HR занимаются поиском сотрудников почти так же часто, как и «чистые» рекрутеры. В 14% случаев рекрутингом занимается «непрофильный» сотрудник: директор небольшой компании, тимлид, CTO, PM.

Опыт работы в рекрутинге

По сравнению с опытом работы программистов, нет такого перекоса в джуниор, но и меньше доля специалистов с опытом работы 10+ лет (5.74% среди рекрутеров и 9.8% у программистов).

Профиль компании

Размер компании

Каждый третий рекрутер работает в продуктовой компании. В агентствах же работает чуть меньше 5% всех рекрутеров.

Город

По данным нашего зарплатного опроса, 44% программистов работает в Киеве и 15% в Харькове, по сравнению с 52.5% и 19.7% рекрутеров. Вероятно, Джинном больше пользуются в Киеве и Харькове, отсюда такое расхождение.

Главная трудность — найти подходящих по требованиям кандидатов

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

Сколько вакансий в месяц вы закрываете?

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

Опыт работы и количество закрываемых вакансий

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

1. Тяжело найти подходящих по требованиям кандидатов.
2. Несоответствие пожеланий по зарплате кандидата и ожиданий компании (заказчика).
3. Конкуренция со стороны других компаний.
4. Слабый английский у кандидатов.
5. Длительное «утверждение» кандидата у заказчика или менеджера проекта.

Зарплаты и бонусы

Зарплаты в рекрутинге заметно выше в Киеве, по сравнению с регионами. Медиана зарплаты рекрутера в Киеве составляет $1000 против $600 в других городах. Меньше всего разница для рекрутеров с опытом работы до 2-хлет, самая большая — для рекрутеров с 5-10годами опыта.

Интересно, что медиана зарплат в Киеве для рекрутеров 10+ лет опыта меньше, чем у рекрутеров с 5-10годами опыта. Возможно, это недостатки малой выборки (29 человек) или то, что опытные рекрутеры активнее переходят на другие позиции.

Средние зарплаты (медиана, с учетом бонусов)

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

Зарплаты и бонусы

Чем меньше компания, тем больше доля зарплаты и меньше доля бонуса.

В продуктовых компаниях 70% рекрутеров/HR получают только зарплату, без бонусов. В крупных аутсорсинг-компаниях только 25% получают зарплату без бонусов, а у большинства есть и зарплата, и бонус.

Особняком стоят рекрутинговые агентства — только там 20% рекрутеров работает на бонусах, без зарплаты. И почти нет таких, кто получает только зарплату, без бонусов.

Лучшие каналы поиска: LinkedIn, Джинн и рекомендации сотрудников

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

Эффективность каналов поиска (от более эффективных к менее)

Разные каналы поиска работают с разной эффективностью для разных групп работодателей. Например, среди работодателей не-рекрутеров почти каждый второй выбрал Джинн в качестве топ-инструмента поиска и лишь 13% выбрали LinkedIn (столько же, сколько GitHub).

Среди рекрутеров до 2-хлет опыта 40% назвали LinkedIn топ-инструментом поиска, 30% Джинн и только 2% — GitHub. У рекрутеров с 5+ годами опыта на первом месте оказались рекомендации сотрудников, этот вариант выбрали 42%. 25% выбрали Джинн и 5% — GitHub.

Базой резюме пользуются в основном только рекрутеры с 2+ годами опыта, у остальных ее, по-видимому, просто нет (хорошей). Доля job-сайтов от опыта работы почти не зависит и колеблется от 15% для DOU до 7-8%у Work.ua.

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

Когда вы основатель early-stage стартапа, ваша основная задача — собрать сильную команду и быстро захватить кусочек рынка со своим Minimum Viable Product. И вроде вам повезло: вокруг столько сильных и опытных инженеров, свежеиспеченных джунов и студентов техвузов с горящими глазами. Вот только на все эти технические кадры охотятся конкурентоспособные работодатели в Украине, а самых толковых с радостью берут в забугорные компании.

Основатели Flawless App: Ахмед Сулейман и Лиза Дзюба

Вместе с кофаундером Ахмедом Сулейманом нам «повезло» столкнуться с многими проблемами найма разработчиков во Flawless App. С момента основания нашего стартапа в 2015 году мы сменили всю изначальную команду. В разные периоды с нами работало от одного и до шести разработчиков. Сейчас в команде 3 инженера (iOS/macOS, front-end и back-end разработчики) и два маркетолога. Таким маленьким составом мы пивотнули продукт, запустили платную версию и добились роста без каких-либо внешних инвестиций. Поиск, удержание и мотивация команды в период постоянного «пиздеца» — это критически важный навык для любого руководителя. На наших ошибках и успешных примерах мы расскажем, как замотивировать инженеров пойти работать в стартап на ранней стадии развития.

Что такое стартап ранней стадии в Украине

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

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

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

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

Как early-stage стартап может привлечь сотрудников

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

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

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

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

Обговорите возможность получения опционов

Не так давно я спрашивала у американских разработчиков о возможности работы на условиях ниже рыночных. Самый популярный ответ был о получении взамен «Shares/Equity/Profit Share». В украинских реалиях разговор об опционах со стартапом ранней стадии — это скорее джентльменское намерение. Если компания зарегистрирована в стране, где нет легальной поддержки механизма опционов, то и реализовать вы его никак не сможете. Более того, есть много подводных камней, о которых как вы, так и ваши сотрудники могут не знать. Поэтому стоит обсудить ваши намерения и политику с опционами как важный бонус в будущем.

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

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

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

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

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

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

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

Вовлекайте команду в принятие решений

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

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

Пусть сотрудник учится на вашем проекте

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

• новым технологиям, фреймворками, подходами, инструментам;
• soft навыкам: управление командой, найм сотрудников, публичные выступления;
• business skills: общение с клиентами, user интервью, запуск продукта, написание статей;
• developer skills: code review, devops, testing.

Например, у нас macOS-продукт для iOS-разработчиков, который сравнивает желаемый дизайн с реализацией прямо во время разработки (на iOS-симуляторе). Это позволяет увидеть визуальные различия и быстро их исправить. Работа над core продуктом позволит инженеру научиться писать и деплоить плагины для iOS-симулятора, настраивать и оптимизировать канал коммуникации между macOS и iOS симулятором и многое другое. Дальше по плану продукта: автоматизация сравнения, запуск сервиса для дизайнеров, поддержка Android, web, AR & VR. Такой стек задач может прокачать любого инженера, и мы готовы быть полевой площадкой для обучений. Думаю, многие early-stage стартапы придерживаются такой же идеологии.

Простой, но полезный совет основателям стартапов — при планировании учитывайте, какие задачи будут способствовать развитию сотрудника. Будьте готовы помочь вашему лиду стать СТО, делегируйте талантливому интерну запуск новой фичи, а новому дизайнеру расскажите, как разработать дизайн-системы для вашего продукта. Так сложилось, что в каждом объявлении про работу обещают «challenging tasks». Задачи в стартапе и вправду могут быть такими. Тогда проработав над сложным продуктом, сотрудник вырастет профессионально в десятки раз. И не забывайте, что делать все самые скучные задачи должны фаундеры.

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

(Юрій Чухліб, iOS Software Engineer в Wikr)

Дайте возможность максимально развиваться вне основного профиля

В early-stage стартапе сотрудник может решать разнообразные проблемы и пробовать свои силы практически во всех сферах. Цитируя Андрея Никишаева, Freelance ML Engineer: «Стартап дает возможность реализовать самые дерзкие фантазии». Используйте эти возможности. Замечаете, что сотруднику интересна iOS-разработка, но он занимается версткой — расскажите про базисы, найдите хорошие курсы онлайн и выделите время на личные сессии.

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

Я macOS/iOS-разработчик в первую очередь. Однако с 2015 года я начал изучать UI/UX. Во-первых, мне было интересно понять, как процесс создания приложения происходит на стороне дизайнеров, а во-вторых, уже тогда я догадывался, что эти навыки пригодятся нам в компании в будущем. Наличие предыдущего опыта работы с различными интерфейсами и понимание базовых принципов организации информации существенно помогли в изучении. Таким образом на данный момент я полностью ответственен за все UI-задачи в компании (интерфейс основного продукта, иллюстрации для блога, дизайн писем и т. д.).

(Ахмед Сулейман, сооснователь Flawless App)

Постоянно менторите и учите своих сотрудников

Крутые разнообразные задачи, подкрепленные менторством, могут стать сильным аргументом для работы именно в стартапе. Ведь когда сотрудник сидит в одной комнате с командой, которая построила продукт от нуля до стабильных продаж, он или она могут получить все эти знания. Например, мы собрали целый репозиторий по запуску своего проекта с фокусом на разработчиков («Marketing for Engineers»). Это 300+ статей, видео, инструментов, которые мы освоили, запуская Flawless App. Все эти знания мы передаем команде.

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

Еще меня очень вдохновляет пример компании IDAP, которая проводит свои курсы и «выращивает» разработчиков с нуля. Курсы — это, конечно, роскошь для стартапа, но минимальную их версию тоже реально внедрять:

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

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

(Александр Корин, CTO в IDAP Group)

Подбирайте полезные мероприятия для команды

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

Обычно я пролистываю календарь DOU, AIN, Facebook events и выбираю релевантные мероприятия, потом бросаю в наш Slack-канал. Я потрачу 30 минут и могу быть уверена, что команда получит что-то полезное вне работы. Признаюсь, я также стараюсь достать бесплатные билеты, если это возможно.

Product Hunt meetup, 03/2018

Способствуйте развитию личного портфолио сотрудников

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

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

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

(Сергей Бутенко, Software Engineer в MacPaw)

Знакомьте команду со своим профессиональным окружением

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

Например, мы еще участвуем в организации CocoaHeads Ukraineи знаем многих спикеров, инженеров из крупных компаний, HRов, продуктовых менеджеров и рады знакомить с ними команду. Благодаря активному маркетингу в нашем близком кругу общения — iOS & macOS инженеры из международных компаний и лидеры мнений. Эти контакты открыты и доступны нашей команде. Early-stage стартапы могут помочь даже самому большому интроверту найти новые знакомства :)

CocoaHeads Ukraine, spring 2017

Старайтесь не доводить до выгорания

Работа в стартапе — это новые знакомства, мероприятия, куча сложных задач, ответственности в перемешку с постоянным стрессом и подкладыванием рельсы под едущий поезд. Когда у вас early-stage стартап, то вы играете наперегонки со временем. Требуя от команды выкладываться на все 100%, вы толкаете сотрудников в пропасть. Недавно на Product Hunt митапе в MacPaw один из панелистов сказал интересную вещь:

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

(Ярослав Степаненко, Product Manager в Setapp)

Пару месяцев назад мы столкнулись с такой ситуацией в Flawless App. Нужно было получить желаемый рост, и один наш сотрудник дни напролет занимался однотипной задачей для получения traction. Как результат — полное моральное выгорание. Другой пример был 1,5 года назад. Мы настояли, чтобы сайт был сверстан за меньше, чем пару суток, так как тогда это казалось нам очень важной задачей. Результат, как и в первом примере, печальный — демотивация, оправданный негатив и отсутствие желания продолжать работу в стартапе. Сейчас мы следим за задачами, которые могут привести к выгоранию и стараемся планировать правильно.

Большие цели маленького стартапа

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

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

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

Следите за work-life balance

Так как Flawless App сейчас в стадии активного роста, основатели работают очень много. Обычный наш рабочий день длится с 10 утра и до 22 вечера, иногда даже по выходным. Хвастаться тут откровенно нечем, и мы бы хотели поскорее вернуться к более здоровому образу жизни. Требовать такой же маниакальной вовлеченности от сотрудников нельзя. Наоборот, стоит культивировать здоровый трудоголизм с обязательным отдыхом.

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

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

(Данил Голота, маркетолог)

За пару суток до релиза, или пример плохого work-life balance

Оберегайте сотрудников от рутинных задач

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

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

Скучные задачи основатели должны делать самостоятельно

Слушайте фидбэк вашей команды

Практика ретроспектив популярна в разработке, но о ней почему-то забывают в отношениях между людьми. Примерно 3 месяца назад мы начали тестировать «человеческие ретроспективы» в Flawless App. Каждую пятницу мы спрашиваем, что команда думает об отношениях в команде, больших целях и коммуникации, интересны ли ей задачи. Еще важнее спрашивать, что будет мотивировать сотрудников на данном этапе их работы. Когда у вас много стрессовых задач, можно не заметить важные для команды вещи, которые не стоит упускать. Конечно, идеальный вариант — это one-on-one встречи или личный коучинг, но не всегда на это хватает времени и экспертизы. Какой бы вариант вы ни выбрали, умение слушать и сопереживать сотрудникам поможет вам конкурировать с компаниями, где люди — это просто хорошо оплачиваемый ресурс.

Не бойтесь говорить о ваших планах, успехах и провалах

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

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

(Анастасия Войтова, Product Engineer в Cossack Labs)

Будьте открыты в своих финансах

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

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

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

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

Мы выделяем время на помощь в нерабочих вопросах: консультации по личным проектам или дипломной работе

Создайте гибкие условия работы и хорошую рабочую обстановку

Если вы хотите, чтобы опытный разработчик пошел к вам, а не в популярную продуктовую компанию, то придется идти на компромиссы. Стоит рассмотреть частично удаленную работу, очень гибкий график, сокращенные рабочие часы и другие гибридные варианты, которых не сможет предложить другой работодатель. Например, part-time вовлеченность как опция для сотрудников, которым нужен определенный уровень дохода или работа с 9:00 до 14:30, чтобы проводить больше времени с ребенком после школы. Возможно, вы не сможете в будущем взять человека полноценно в штат. Однако на данном этапе это поможет вам двигаться быстрее, а человек получит желаемый технический или бизнес-опыт.

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

Делайте маленькие приятные вещи

Меня очень вдохновила практика MacPaw с их внутренней валютой (в некоторых компаниях это еще называется «kudos»). One Fix, внутреннюю валюту MacPaw, можно получить за хорошую заслугу или когда сотрудник прожил еще одну неделю в компании. Фиксы можно обменять на еду с Salateira, Ritter Sport или другие вкусности. С ограниченным бюджетом свою валюту не введешь. Но можно давать сотрудникам сертификаты на покупку книг за крутые заслуги. Мелочь, но приятно. Думайте о таких мелочах почаще. Постарайтесь построить такую компанию, в которой самому хотелось бы работать.

Внутренняя валюта в MacPaw как метод мотивации команды

Делайте сотрудников частью вашей миссии

Ценность и миссия равноценна product market fit. Важно ежедневно показывать сотрудникам ту приземленную миссию, которую выполняет продукт и давать им возможность стать ее частью. Например, мы часто спрашиваем у подписчиков Flawless App в Twitter, что им интересно и почему они нас зафолловили. Ответы в 99% случаев очень позитивные. Пользователи рассказывают, как помогает продукт, как им нравится контент, что они думают про фичи и как приятно, что им написал кто-то из нашей команды. Эти задачи мы всегда даем команде, чтобы сотрудники чувствовали позитив от комьюнити, понимали ценность продукта и могли стать частью этой ценности.

Будьте лидером, за которым хочется идти

Лидеры вдохновляют. За ними хочется идти даже в маленький стартап без зарплаты. Главный вопрос — как стать такой сильной и харизматичной личностью, чтобы топовые специалисты мечтали с вами общаться, работать и заряжаться вашим драйвом. И кроме всего прочего, вы должны быть прокачанным специалистом, эдаким мифическим «10x engineer» со знанием новых подходов и широким взглядом на все процессы. Как говорил Паша Педенко:

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

(Павел Педенко, Product manager в MacPaw)

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

Как найти золотую середину

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

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

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

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

Внеурочная работа.Иногда вы будете просить сотрудников поработать внеурочно (ура! У вас запуск на Product Hunt и куча фич еще не готовы...). Чтобы быть честными, нужно оговаривать, как будет учтено это время. Например, если это полный рабочий день в субботу, то у сотрудника будет возможность взять выходной на неделе. Иначе это превратится в социальный долг. Ведь если вы просите сотрудников об одолжении, как вы сможете отказать, если попросят они? Мне очень понравились советы на эту тему в книге Бена Хоровица «Hard things about Hard things». Почитайте, эта книга поможет вам избежать многих ошибок в работе с командой.

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

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

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

[В серії «Огляд IT-ринку праці»ми розповідаємо про IT-індустрії в різних містах України]

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

Середні зарплати програмістів у Рівному:

• Junior — $300;
• Middle — $1000;
• Senior —$2200.

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

Компанії

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

SoftServe

Українська аутсорсингова компанія
240 спеціалістів у Рівному, 4863 в Україні

Компанія займається розробкою ПЗ для клієнтів із США та Європи, серед яких — HomeAway, Vovici, Avery, Cisco, Medhost. Експертні сфери: корпоративний сегмент, охорона здоров’я, фінанси, роздрібна торгівля, медіа.

В Рівному багато проектів на С++, а також на .NET, Python, Java Web UI та Go.

Можливості для початківців:SoftServe IT Academyзапрошує студентів на безкоштовні курси та надає можливість працевлаштуватись після їх закінчення. Навчання триває 2-3 місяці.Відбір проводиться на конкурсній основі. Окрім цього, SoftServe у Рівному започаткував курси англійської мови з акцентом на ІТ.

SoftGroup

Українська аутсорсингова та аутстафінгова компанія
100+ спеціалістів у Рівному, 280+ в Україні

Компанія розробляє ПЗ для клієнтів з Європи та США. Експертні сфери: Business Intelligence, Enterprise Architecture, Mobile Application Services.

Основні технології: .NET, Delphi, PHP, HTML5/CSS3, Python, Perl, iOS/Android.

Можливості для початківців: SoftGroup Academy — безкоштовні курси з можливістю подальшого працевлаштування. Навчають PHP, Drupal, Wordpress, Ruby, Python, Angular/JavaScript, iOS, Java/Android. Щоб стати студентом академії, необхідно володіти базовими технічними знаннями і англійською.

Renome-Smart

Українська продуктова та аутсорсингова компанія
40+ технічних спеціалістів у Рівному

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

Розробками Renome-Smart користуються банки та фінансові організації 15 країн світу. В Україні продукти компанії використовують 26 Центрів надання адміністративних послуг, а також кожен третій АТМ.

HoneyComb

Українська аутсорсингова компанія
30 спеціалістів у Рівному, 40 в Україні

Компанія розробляє ПЗ для клієнтів з США, Канади, Ізраїлю, Швеції, Німеччини та Австралії. Експертні сфери: e-Commerce, транспорт, охорона здоров’я, проекти, пов’язані з благодійністю.

Ноneycomb Software спеціалізується на веб-розробці на платформі .NET. Основні технології: C#, ASP.NET MVC, ASP.NET Core, MS SQL Server, PostgreSQL, MySQL, Angular, ReactJS, Azure, AWS.

Можливості для початківців: компанія надає можливість пройти інтернатуру за детальною програмою з сучасними технологіями. Окрім цього, Ноneycomb Software активно співпрацює з місцевими ВНЗ. Раз на місяць проводить«Годину коду» зі студентами.

Zagrava Games

Українська аутсорсингова та продуктова компанія
30 спеціалістів у Рівному

Студія надає аутсорсингові послуги з розробки ігор, а також створює власні продукти. Команда розробила більше 30 мобільних та веб-ігор, найвідоміші з яких — «The Hunt for Red Panda» та «Chasing Chaster».

Основні технології: C++/C#, Unity 3D, Cocos 2Dx, HTML5, Flash, HAXE, iOS/Android.

Selecto

Українська аутсорсингова компанія
23 спеціалістів у Рівному, 25 в Україні

Компанія займається веб- та мобільною розробкою, а також UI/UX дизайном. Експертні сфери: фінанси, нерухомість (CRM), розваги, соціальні мережі, B2B, охорона здоров’я.

Основні технології: iOS, Android, Python (Django, Flask), NodeJS (Expres, Sails, Adonis), JavaScript, TypeScript, PHP (Symfony, Llaravel), MySQL, MSSQL, MongoDB, PostgreSQL.

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

Також у Рівному є офіси таких IT-компаній:

• Adyax — створює web-сайти та додатки на базі Drupal для відомих світових брендів і урядових установ. Експертні сфери: корпоративні бізнес-додатки, платформи e-Commerce, ритейл, багатоканальне поширення мультимедіа, сайти на базі платформи Drupal.
• Gekos — створює сайти, займається контекстною рекламою, SEO, SMO, PR кампаніями, консультує щодо становлення бізнесу в інтернеті.
• InternetDevels — займається веб-розробкою на Drupal. Окрім розробок для бізнесу, бере активну участь у технічному розвитку платформи Drupal в цілому.
• QATestLab — надають повний спектр послуг з тестування ПЗ, консультування по якості.
• /shortcute — розробляє UI&UX дизайн веб-, десктоп- та мобільних проектів. Експертні сфери: банківська справа, e-Commerce, e-Learning, інтернет-трансляції, месенджери.
• Testmatick — займається ручним і автоматизованим тестуванням ПЗ. Експертні сфери: фітнес, готельно-ресторанний бізнес, облік витрат, email-маркетинг, подорожі, фінанси.
• Virtuace — розробляє ПЗ, використовуючи Java та PL/SQL. З 19 березня розпочинає програму стажування для нових співробітників.
• Wedes Web Studio — створює мобільні додатки під iOS та Android для клієнтів з Америки та Європи, веб-додатки та сайти для Рівного, України та Європи. Основні технології: JavaScript, MySQL, Node.js, Angular, Ionic, React/Redux, React Native, TypeScript, RESTful, Symfony, Redis. Для новачків можливе стажування з подальшим влаштуванням на роботу.
• ZoomSupport — займається цілодобовою дистанційною підтримкою користувачів продуктів Microsoft та Apple у всьому світі.
• 32×32 — створює сайти, а також займається їхнім просуванням та підтримкою.

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

• AB Games — створює ігри для мобільних платформ та соціальних мереж. Найвідоміша розроблена гра — «HiddenCity: Загадка Тіней», в яку грають мільйони гравців у більше, ніж 14 країнах світу. Компанія відкрита для набору початків до відділу розробки: відбір проходить на основі тестового завдання із написання гри, яке потребує базового рівня C++.
• Axxos — розробляє власний продукт для моніторингу виробничих ліній, оцінки ефективності виробництва, аналітики для покращення рівня доступності і продуктивності виробництва.
• Splynx s.r.o.— займається розробкою платформи для білінга та управління ISP. Продукт використовують більш ніж 400 провайдерів по всьому світу.

За вакансіями в місті можна стежити тут.

Спільноти та події

Rivne IT Talks — зустрічі ІТ-спеціалістів міста. Регулярно організовують зустрічі, присвячені різним технологіям та напрямкам в ІТ. Організатор — компанія SoftServe. Учасниками заходів можуть стати всі охочі.

Drupal IT Talks, лютий 2018

IT-Weekend Rivne — найбільша ІТ-конференція регіону від компанії SoftServe. Кожного року захід присвячують різним технологіям: минулого року обговорювали .NET та Project Management.

Слідкувати за подіями у Рівному запрошуємо в Календарі.

Освіта

ІТ-спеціалістів у Рівному готують у чотирьох вишах:

• НУВГП (інститут автоматики, кібернетики та обчислювальної техніки);
• МЕГУ ім. С. Дем’янчука (факультет кібернетики);
• Рівненська філія ЄУ (кафедра інформаційних систем);
• РДГУ (факультет математики та інформатики).

Найбільші ІТ-школи:

• SoftServe IT Academy (.NET, Java, Web UI, C++, DevOps, iOS, QC, ATQC, DataBases, UX);
• SoftGroup Academy (PHP, Drupal, Wordpress, Ruby, Python, Angular/JavaScript, iOS, Java/Android);
• 4WEB (Front-end, Back-end, Mobile, SEO, SMM);
• Kid’IT (Python, Scratch, Tynker, Lego Mindstorm);
• КА «Шаг» (розробка ПЗ, комп’ютерна графіка та дизайн, мережеві технології та системне адміністрування).

Перспективи Рівного як ІТ-регіону

Сергій Сидорчук, директор рівненського офісу SoftServe:

Попри те, що Рівне є досить компактним містом, тут зосереджена низка потужних вищих навчальних закладів, де вчать майбутніх ІТ-спеціалістів. Серед них НУВГП, НУ «Острозька академія», РДГУ, КА «ШАГ». Університети є відкритими для співпраці: минулого року за підтримки SoftServe НУВГП відкрив нову спеціалізацію «Інтернет речей», яка, я впевнений, з кожним роком набиратиме обертів.

Завдяки співпраці з випускниками вишів, а також різноманітним освітнім програмам SoftServe IT Academy ми маємо великий потік Junior-спеціалістів, яких вчимо та розвиваємо завдяки внутрішній навчальній екосистемі. Попри це, у рівненському девцентрі SoftServe працює 60% спеціалістів рівня Middle та Senior.

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

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

Олександр Семенюк, СЕО Honeycomb Software:

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

IT в Рівному має ті самі проблеми, що і IT України в цілому:
— відсутність кваліфікованих спеціалістів;
— перегрітий ринок праці;
— відставання освітніх програм від потреб ринку;
— міграція цінних спеціалістів до Києва, Львова, за кордон.

Окремо хочу відмітити цікавий факт, що з ростом кількості IT-компаній до Рівного почали повертатися ІТ-спеціалісти. Погодьтесь, що витрачати 2 години на проїзд у великих містах — нераціонально.

Юрій Мамончук, СЕО Selecto:

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

Які тут є перешкоди? Наразі основна проблема не в наявності робочих місць, а у належній підготовці спеціалістів. Перш за все, нам треба забезпечити високоякісну ІТ-освіту у Рівному. Бо погодьтеся, якщо людина поїде навчатися до Львова, Києва чи Харкова, вірогідніше, там вона і лишиться. Статистика показує, що у студентські роки люди здобувають найбільшу кількість контактів і завдяки ним вже обирають роботодавця.

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

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

Див. також огляд IT-ринку праці інших міст:
Вінниця, Дніпро, Житомир, Запоріжжя, Івано-Франківськ, Луцьк, Львів, Миколаїв, Одеса, Полтава, Рівне, Суми, Тернопіль, Ужгород, Харків, Херсон, Хмельницький, Черкаси, Чернівці, Чернігів

Я постараюсь описать весь свой опыт и те подводные камни, которые я встретил при подготовке к собеседованию в Google и другие компании Долины (Microsoft, Amazon, Snapchat, Evernote, Cruise Automation, Uber и др.). Я ставил цель получить оффер от Google или Facebook, а еще лучше от обоих, все остальные компании были из разряда «ну если там будет очень интересно, то можно». С первого дня, когда я начал подготовку, до момента, когда я получил оффер от Google, прошло 1 год и 5 месяцев. Первый оффер я получил после 1 года и 2 месяцев подготовки. Всего было 7 онсайтов (интервью в офисе компании), из них 3 оффера (Google, Evernote, Cruise Automation). Итак, начнем.

Предыстория

Я был вендором в Google в Mountain View на протяжении полутора лет. Там же было несколько гуглеров, которые тоже были вендорами до этого. Конечно, мозг постоянно подсказывал, что они «другие», что они «умнее-лучше-круче», чем я. А мой удел — быть вендором. Я даже один раз попробовал решить задачку на LeetCode. Осилить я смог 5-ю easy задачку, которая получилась на 120 строк кода и в результате так и не прошла тесты. На это ушло 5 часов прекрасного субботнего калифорнийского дня. Я окончательно понял, что вот всем вокруг «дано», а мне нет.

Но все же, проводя с друзьями-гуглерами много времени, я понял приблизительный алгоритм — что и как нужно делать. Я сделал в точности, как они сказали, и получил оффер (чему был немало удивлен). Второй нюанс — в Google я делал front-end, все мои друзья были back-end, и подготовку они описывали именно для back-end. Я подумал и решил: «А back-end тоже хорошо (я же когда-то писал на .NET, хотя и давно), буду идти в точности как они, но сделаю больше, чем они, и тогда точно получу оффер».

Мотивация

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

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

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

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

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

Пример 2: «Я хочу в Google, чтобы вывезти свою семью в США и дать детям хорошее образование», «Я смогу, имея деньги от Facebook, сделать это и это». В моем случае мотивация звучала так: «Я хочу быть ближе к дому». Я рассматривал переезд в Лондон либо Цюрих. Когда я начал подготовку, я себе так сказал: «Пацан, ты следующий раз полетишь домой, когда получишь оффер, и только так». Домой хотелось, и это давало энергию. Я думаю, это работает не для всех и не всегда, но для меня сработало.

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

Процесс в общем

Весь путь можно разделить на несколько этапов:

1. Решение задач на LeetCode или InterviewBit.
2. Изучение алгоритмов и структур данных.
3. Повторение решенных задач на LeetCode.
4. Подготовка к дизайн-интервью.
5. Mock-интервью (телефонные и на вайтборде).
6. Реальные интервью.
7. Оффер и алкогольное забвение.

Решение задач

Это самая важная и самая длительная часть подготовки.

Сколько задач нужно решить? Я считаю — 200-250,из которых 40-50% easy, 40-50% medium, 10-20% — hard. Я решил около 300, мои друзья — 120-160.

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

А что если я сначала прочитаю всю книжку «Cracking Coding Interview»с решенными задачками и уже весь подготовленный пойду в бой? Не стоит:) Решение, которое я просто прочитал, я не мог вспомнить даже под конец того же дня, не говоря уже через несколько дней.

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

Перед тем как начать решать задачки на определенную тему можно прочитать решение схожих задач в «Cracking Coding Interview». Причины тут две:

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

А какие вообще существуют задачи, какие темы нужно покрыть?Понять, какие вообще тематики существуют, можно с InterviewBit. Мне не очень понравилось там решать задачи, но вот общее представление я получил. Ну и кроме того, можно полистать «Cracking Coding Interview».

В какой последовательности стоит решать задачи?Нужно идти от простых тем к сложным (InterviewBit подскажет порядок). В каждой теме решать задачки до тех пор, пока не начнет хоть чуть-чуть получаться, и в этот момент сразу переключиться на следующую тему. Начинать, конечно, с уровня easy. Я пытался решать каждую задачу на протяжении около получаса-часа. Если не смог — шел смотреть решение. На LeetCode к каждой задаче есть форум, где люди постят свои решения, обсуждают, голосуют. Я выбирал топ решений и изучал их, так и учился. Наверное, эти форумы — самое ценное место для обучения. Далеко не все решения просто понять, даже те, под которыми стоят комментарии «This is absolutely awesome!!!».

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

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

1. Читаем условие задачи, ни в коем случае не пытаемся придумать решение до того, как условие прочитано до конца. Это важно!!! Мозг пытается найти похожую задачу, решение которой он знает, и выдать за требуемое.
2. Пытаемся придумать уточняющие вопросы. Пример 1: есть задача, в которой нужно как-то трансформировать строку. Что спрашивать? — Какие символы могут быть в строке — ASCII или Unicode? Могут ли рядом стоять несколько пробелов? Могут ли быть пробелы в начале или конце строки? Есть ли спецсимволы типа -,.^/ ? Есть ли разница для анализа между большой и маленькой буквами? Насколько длинная входная строка? Помещается ли она в память машины? Пример 2: есть массив из Integer, в нем нужно что-то найти. Вопросы: есть ли повторяющиеся элементы? Есть ли отрицательные числа? Что если в результате подсчета мы получим больше, чем Integer.MAX_VALUE?
3. Рисуем примеры, лучше парочку — один классический, второй с corner cases. После этого мы +/- должны быть уверены в том, что задачу мы поняли правильно.
4. Придумываем решение «в лоб» и оцениваем его сложность. Сложность решения нужно уметь определить всегда.
5. Придумываем более оптимальное решение, оцениваем его сложность.
6. Разрабатываем API решения — какие будут методы (приватные и публичные).
7. Пишем код в тетрадке.
8. Дебажим код по тетрадке на новом примере. Не нужно брать один из примеров, который мы рисовали в начале. В этом случае очень высока вероятность, что мы написали решение именно для этого случая, а не для всех возможных. Лучше взять новый пример с corner-кейсом, такой, чтобы потенциально мог решение сломать.
9. Перебиваем код в любимую IDE, при этом не смотрим в бумажку. Таким образом, мы повторяем решение два раза.
10. Копируем код из IDE в LeetCode и запускаем. В случае идеального выполнения должно cработать правильно с первого раза. У меня такое получалось в 10% случаев.

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

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

Все свои решения я заливал на GitHub. Хорошо видна статистика, и всегда есть доступ к коду. Это я начал делать после того, как LeetCode затер все мои решения. Так что LeetCode — не лучшее место для хранения своих решений.

Важно вести статистику (вот моя), в которой будет следующее:

• что когда решил;
• Group A — список задач, которые не решил самостоятельно;
• Group B — список задач, которые решил самостоятельно, но при этом очень страдал.

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

Ноу-хау «дверь».После того, как я решил порядка 230 задач (это был мой изначальный план), я переключился на изучение алгоритмов (об этом позже). Когда в алгоритмах я прокачался, что заняло около двух месяцев, пришло время задачи повторять. И вот здесь получилась интересная штука: повторить задачу — по времени не многим меньше, чем решить ее (так как шаги нужно использовать те же, только код из тетрадки не переписывать в IDE). И тут пришла долгожданная демотивация — не чувствует организм, что делает что-то полезное, и все тут. Я стал думать, как проблему решать, понял, что я визуал и мне нужно визуальное подтверждение своей деятельности. И оно нашлось. Каждую задачу, которую повторил, я записывал на стикере: номер задачи, сложность (easy, med, hard), тема и краткое решение. Краткое решение — это не код. Как оказалось, код запомнить почти невозможно, а вот простые шаги типа «1. Создаем мапу с каунтерами, 2. Находим в ней Х ...»- вполне. Задачи из одной темы попадают в один ряд, сложность можно отмечать цветами (это я понял позже).

Цель была следующая — все решенные задачи должны быть повторены и появиться на двери как стикеры. Когда я наклеил первые 10 стикеров и это отняло несколько дней, честно скажу, хотелось плакать. Мозг подсказывал: «До 230 осталась бесконечность».

В результате на моей двери появилось 218 наклеек. Некоторые задачи я так и не успел повторить.

Дверь в начале и дверь в конце

Алгоритмы

Я изучал алгоритмы по курсам дедушки Седжвика на Coursera (Part 1, Part 2). Видео этих курсов можно найти на торрентах.

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

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

Дизайн-интервью

Дизайн-интервью состоит из так называемых открытых вопросов по дизайну, типа «как задизайнить YouTube». По началу я совсем не мог понять, что требуется и как это должно выглядеть. Потом я нашел курс «Grokking the System Design Interview», который мне открыл глаза. Он стоит свои 80 баксов.

Вот еще одно видео от Джексона (Facebook guy), которое даст понимание процесса. Хорошее обсуждение на Quora.

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

Behavioral-интервью

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

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

Mock-интервью

Mock-интервью — это то же самое, что и обычное интервью с той разницей, что его проводят друзья, коллеги или специальные компании. А потом дают свой отзыв — что хорошо, что нужно поправить. Это тоже критически важный шаг, упускать его не стоит. Конечно, будучи в Долине, сделать это в разы проще. Вокруг меня было много друзей гуглеров, действительно клевых ребят, которые мне провели порядка 20-ти mock-интервью. Я был как Том Сойер, который взялся красить забор, а в результате красили забор все. Интервью мы проводили, конечно, на английском на вайтборде со строгим ограничением по времени.

Телефонные mock-интервью (а потом и реальные) я проходил на interviewing.io. Я просто полюбил этот ресурс, ребята реально молодцы. Но они сейчас заточены под США и предоставляют этот сервис по США. Бывали дни, когда у меня в неделю было около 7-8собеседований на interviewing.io.

Сначала было страшно и некомфортно. Но к 10-муразу я привык, и стало нравиться. Первые интервью я валил, потом стало получаться. Средняя конверсия была 50%, то есть половину прошел, половину — нет. Всего телефонных собеседований (реальных и mock) было около 30-35.

Как подаваться

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

Второй способ — сайты работ типа Hired.com. Ты заполняешь все данные о себе, а потом компании, которым ты подходишь, сами с тобой связываются. Сервис ориентирован на рынок США. Без H1 или грин-карты там делать нечего.

Способ третий — interviewing.io, о котором я упоминал выше, и схожие сервисы. Они работают так: сначала ты проходишь на их платформе телефонные mock-интервью. Как только ты успешно проходишь два, они дают тебе возможность проходить анонимные телефонные интервью с реальными компаниями на их платформе. К примеру, сотрудник Uber и ты заходите в одно и то же время, и он тебя собеседует. Если прошел — дальше онсайт. Mock-телефонное и реальное телефонное интервью не отличаются вовсе. Минусов в interviewing.io несколько. Первый — они больше сотрудничают со стартапами, больших компаний мало. Второй — ориентированы на Штаты (нужна H1 или грин-карта).

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

Резюме

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

Лариса, инженер в Google, много пишет на тему интервью, Google, Долины в своем блоге. У нее есть интересный раздел «Резюме на проверку». Здесь люди открывают доступ к Google doc со своим резюме, Лариса и другие читатели его комментируют и пытаются улучшить.

Телефонное интервью

Стандартное телефонное интервью включает в себя общение голосом (по телефону, скайпу, hangouts и т. д.) и написание кода в shared Google doc или shared online IDE. Занимает по времени 1 час либо 45 минут, это нужно уточнить заранее.

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

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

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

Самый эпический пример этой ошибки у меня случился на онсайт-интервью в Evernote. Задача была следующая — распарсить CSV-файл с расписанием поездов и написать программку, которая будет подбирать оптимальный поезд по определенным условиям. Можно гуглить. Я до этого код для работы с файлами на джаве не писал и растерялся. Решил так, я сейчас быстренько с файлами разберусь, а там уже как-то алгоритм построю. Времени на все — 1 час 15 мин. Я полчаса строил красивые врапперы вокруг чтения из файла, пучок сущностей, описывающих поезда, маршруты и прочий мусор. При этом мало представлял, как алгоритм выбора будет работать. Дальше я понял, что я не успеваю, не понимаю, как строить алгоритм, подступила паника. За 12 минут до конца собеседования я понял, как оно должно быть. За 15 минут (с опозданием в 3 минуты) я написал код (с парой ошибок, правда). Так быстро я не писал код никогда в своей жизни.

Онсайт-интервью

Если телефонное интервью прошло успешно, следующий шаг — онсайт. Компания покупает тебе билеты на самолет, оплачивает отель, и ты летишь к ним в гости. Я так летал в Лос-Анджелес на интервью в Snapchat.

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

Какие бывают типы интервью на онсайте и как к ним подготовиться.

Классическое техническое интервью с задачами.Тут все относительно понятно — то же самое, что и на телефонном. Нужно держать в голове следующий факт — уложиться нужно в ⅔ времени и ⅓ оставить на непредвиденные обстоятельства, поверьте они будут. В Google одно интервью 45 минут, это означает, что после знакомства у вас есть 25 минут на все. Из них 2-5минут на то, чтобы понять задачу и нарисовать примеры, 2-5 —чтобы придумать решение и 15-20 нанаписание кода и дебаггинг. Во время дебаггинга, конечно, всплывут ошибки, и их нужно быстро и красиво пофиксить. Именно на это и нужна та заветная ⅓.

Нюанс — всегда нужно идти на интервью со своим лэптопом. Первым делом нужно спросить, можно ли кодить на нем. В Facebook меня спросили: есть лептоп? хочешь на нем кодить? Ответ — конечно, да! Это быстрее, и вероятность ошибки в разы ниже. К тому же, переписывать код на вайтборде и в IDE — это две большие разницы. У меня неоднократно была ситуация, когда я исправлял ошибки на вайтборде, в результате чего код становился абсолютно нечитаемым (и, скорее всего, с новыми ошибками). Интервьюеры смотрели на это с грустью и слезами.

На лэптопе должны быть любимая IDE и проектик с типовыми шаблонами:

• работа с файлами;
• парсинг CSV-файлов;
• считывание по http;
• HTML- документ с подключенными стилями.

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

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

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

Я успел дописать свое решение с опозданием в 5 минут. Если бы послушал его, то не написал бы ничего и провалил интервью на 100%. А после такого в космонавты не берут. Штука в том, что он прикидывал, сколько времени нужно ему для написания задачки на доске, зная решение досконально.

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

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

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

Мои выводы по этому типу интервью:

• Первым делом нужно собрать требования. Очень четкие и конкретные требования, которым должна отвечать система. Типовые вопросы, которые можно задать: how many users, active users, time zones (one or few). Acceptance criteria — network bandwidth (in-going/ out-going traffic), RAM, storage, latency, battery life (for mobile) etc.
• Представь, что интервьюер — это твой заказчик (или пользователь), для которого строится система. Что ему нужно? А что можно предложить сверх этого (сбор статистики, админпанель)?
• Какие будут пользователи у этой системы? Часто их несколько — general users и administrators. И требования для них могут быть кардинально разные. Понимая это, нужно собрать все use cases. Один use case будет отвечать одному методу в API.
• Определяем три ключевых элемента — UI (если таковой имеется), API, DB schema. Часто, рисуя UI, можно найти новые use cases и обговорить их.
• Оценить все, что только можно, — number of users, requests (queries) per second (QPS), latency, API latency, disk space you need (for 5 years for instance), cache space, in-going/out-going traffic.
• Отдельно оценить read-write ratio. Наша система read heavy или write heavy? В зависимости от этого, как мы будем писать и читать данные?
• Как будет организовано хранилище данных, кеширование? Возможно, нужна очередь для обработки дорогостоящих операций? Как будут организованы replicas и shards (нужно хорошо понимать различие между этими понятиями)?
• Для упрощения понимания сначала можно построить систему для 100 пользователей. После того как интервьюер согласится с таким дизайном, можно подумать, как будем его масштабировать до тысяч и миллионов пользователей.
• Найти trade-offs и обсудить их. К примеру, это может быть trade-off между consistency и speed. Что важнее в данном контексте? Как этого добиться?
• Когда мы рисуем диаграммы, ни один блок не должен быть в единичном экземпляре, это всегда сет из многих. При падении одного узла его тут же должен заменить его клон. Нужно продумать, какие могут быть аварийные ситуации и как мы будем с ним бороться.
• И самое главное — внимательно слушать интервьюера и никогда-никогда с ним не спорить. Это кажется очевидным, но многие (и я среди них) об этом забывают.

Вопросы интервьюеру

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

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

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

За 10 дней до важного онсайта

У меня было два самых важных онсайта — Google и Facebook. Google был первым, и я достаточно сильно переживал. За 10 дней до онсайта я составил расписание на каждый день, что нужно сделать. Оно содержало следующее: повторение алгоритмов, типовых задач, задач, которые встречались на собеседованиях в Google, вопросы по дизайну. 5 дней до интервью я не ходил на работу и ушел в подготовку с головой.

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

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

Финал

Через несколько дней после онсайта мне позвонил рекрутер. Поздравил, сказал, что я молодец, все прошло хорошо. Мне нашли команду в Швейцарии в Цюрихе. Официальная позиция — Software Engineer. Я выдохнул. Голова была абсолютно пустой, я добежал. Забег в 1 год и 5 месяцев объявляется закрытым.

Привіт, мене звати Євгеній Коваль, я PHP-розробник в компанії Wikr Group. Сьогодні хочу поговорити про наставництво — або, як частіше кажуть в нашій індустрії, менторство.

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

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

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

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

Що таке наставництво

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

• Чи можу я стати ментором?
• Чи достатньо я володію інформацією щоб бути ментором?
• Чи гарний з мене ментор?

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

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

Здобувайте практичний досвід

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

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

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

Розберіться в психології

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

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

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

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

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

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

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

Налагоджуйте комунікацію

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

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

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

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

Ставте складні цілі

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

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

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

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

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

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

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

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

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

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

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

Якщо ви хочете бути гарним наставником, мотивуйте себе ним бути. Робіть все, щоб ви були прикладом для свого учня.

Корегуйте напрямок

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

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

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

Післямова

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

Наостанок додам декілька посилань з матеріалами, цікавими для ознайомлення:

• Basics of Communication — дуже цікава стаття про те, як ми говоримо і сприймаємо інформацію;
• What Are the Most Effective Communication Skills to Have?— навички, на які потрібно звернути увагу для побудови ефективної комунікації;
• 3 Psychological Theories To Help You Communicate Better With Anyone — цікаві погляди на комунікацію з точки зору психології та досліджень в цьому напрямку;
• The Most Powerful Motivator You’ll Ever Find — коротко про головне;
• How to Stop Making Excuses — стаття про те, як перестати виправдовуватись і почати діяти.

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

Мене звуть Володимир Бондаренко, я співвласник компанії Mauris та один з творців мобільного сервісу Movie Expert. Наш додаток допомагає за 15 хвилин створити список фільмів та серіалів для перегляду на півроку вперед.

Ідея

Напевно, кожному відоме почуття «хочу подивитися щось, не знаю що, і ніхто мені не допоможе». Думка про створення кіносервісу приходила до нас неодноразово, але сформувался остаточно в 2013 році. Трудові будні хотілося скрасити хорошою підбіркою фільмів на вечір, в черговий раз стало зрозуміло: не все те подобається, чому ставлять високі оцінки. Ні рейтинг «Імхонет», ні «КиноПоиск» та IMDb не змогли допомогти в пошуку відповідних фільмів. Кінострічки з високим рейтингом були або переглянуті раніше, або не цікаві, що, власне, ставило в ступор. А фільми із середнім рейтингом було важко оцінити і відібрати. По-перше, коментарі і рецензії ділилися на два повноцінних табори: за і проти. По-друге, сам процес підбору фільмів займав досить багато часу (адже щороку тільки в Голлівуді випускають більше 800 фільмів і серіалів), і в більшості випадків часу на перегляд кінострічки просто не залишалося.

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

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

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

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

Проблема 1.Розробка зручного і зрозумілого інтерфейсу для користувача.

Спочатку потрібно було відтворити в пам’яті переглянуті фільми. Коли ресурс вимагав ввести в пошуковий рядок 10 улюблених фільмів, половина користувачів впадала в ступор: вони просто не могли їх пригадати.

Рішення.Швидкий хотфікс з постійно оновлюваною підбіркою фільмів з найкращим рейтингом — хороша підказка для забудькуватих.

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

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

Злет і падіння

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

Весь back-end був написаний на PHP, а в якості БД використовували MySQL. Для виправлення ситуації потрібно було максимально прискорити ресурс, тобто:

• оптимізувати запити в БД;
• змінити алгоритм;
• змінити конфігурацію сервера;
• дати можливість використовувати частково попередньо згенеровані дані (batch process) і кеші даних.

... до чого ми і приступили.

Виконану роботу можна розділити на кілька етапів:

1 етап.Сайт був багатомовним: мав російську і англійську локалізації. Нам довелося впровадити Memcached — систему кешування, в якій було закладено переклад контенту, а також інтерфейсу. У підсумку, всі сторінки почали відображатися вдвічі швидше — за рахунок вивантаження з оперативної пам’яті і усунення запитів в БД на переклад інтерфейсу.

2 етап. Об’єднав декілька операцій:

• Зміна алгоритму отримання даних.
• Розбивка складних запитів на підзапити.
• Застосування табличних індексів.
• Оптимізація обробки рядків (якщо просто з’єднати таблиці між собою через JOIN, не факт, що БД обере оптимальний варіант роботи сама).
• Використання memory-таблиць. Щоб з автоматичного JOIN-a таблиць використовувати ручне з’єднання, ми зробили ряд простих запитів — вони отримували ті ж дані, але в певному порядку. Це зменшило кількість оброблюваних даних.

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

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

Також ми застосували ручне партиціювання БД: зробили розбиття — оцінки фільмів певних груп відвідувачів зберігалися в різних таблицях. Тобто ми горизонтально розбивали оцінки по n-ій кількості таблиць в залежності від зростаючої бази користувачів. Розмір кожної таблиці був обмежений 1 мільйоном записів: це дозволяло виконувати SQL-запити з необхідною нам швидкістю.

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

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

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

Зміна концепції

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

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

• оптимізувати шлях користувача при роботі з сервісом (ввести навчання);
• розробити алгоритм по «утриманню» і залученню користувача.

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

Отож, у грудні 2016 року ми знову провели перезапуск сервісу, змінивши його формат. Вирішили замість сайту створити додаток під дві платформи — iOSі Android.

Ми бачили, що перспектива розвитку проекту на мобільному пристрої значно вища:

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

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

Щоб спростити інтерфейс програми, за основу взяли принцип Tinder. На головному екрані користувач повинен оцінювати фільми за допомогою свайпів вправо та вліво. У додатку доступні такі розділи: «Хочу подивитися», у якому зібрані фільми, які планує переглянути користувач; «Ми рекомендуємо» — рекомендації додатка; «Пошук фільмів» — де можна знайти фільми та серіали.

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

Складнощі

Крос-платформа.Одна з проблем полягала в тому, що ми хотіли випустити мінімально життєздатний продукт (MVP) на крос-платформі, щоб протестувати актуальність проекту і перенести його на Native. Тоді, коли почали розробку програми, з’явився React Native. З огляду на те, що хотіли запустити проект в найкоротші терміни, вирішили використовувати Cordova. Після реалізації низки проектів на React, побачили, що ця технологія більш продуктивна.

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

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

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

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

Розчарування у фільмах.Перша підбірка для оцінки складалася з фільмів з високими балами топових рейтингів — і при цьому більшість з них люди просто не дивилися. Після 3 свайпів «не дивився» вони розчаровувалися і закривали додаток. Спочатку для вирішення проблеми просто поставили фільтри (стали показувати фільми останніх 10 років), але це не допомогло.

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

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

Зі специфічних проблем:

• У додатку ми використовуємо трейлери фільмів з YouTube. Щомісяця 10% YouTube-роликів стають недоступні, тому довелося розробити алгоритм аналізу і швидкої заміни недоступних відеороликів.
• Однойменні фільми. Як виявилося, їх існує досить багато. Доводиться ретельно аналізувати контент.
• Існує низка трейлерів, які захищені авторськими правами. Вирішуємо проблему автоматичним відсіюванням таких трейлерів.
• Основна частина проблем була юридичного характеру, а саме пов’язана з авторським правом на постери, які використовуються в додатку. Нам довелося витратити багато часу на складання звернення до правовласників, підбір постерів з певним типом ліцензії, а також розробку механізму, який допомагає швидко виключити фільм в разі запиту від правовласника.

Після випуску першого масштабного оновлення аудиторія Movie Expert почала активно зростати (наразі є близько 18 тис. користувачів). Ми ретельно аналізували всі коментарі, а також побажання людей. І тоді побачили, що у деяких користувачів iOS-пристроїв (з Android проблем немає) відбувається автоматичний вихід з облікового запису. Почалася активна робота над пошуком і відтворенням цього бага.

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

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

Що в результаті

Перша версія додатку була доступна у липні 2017 року. Ми провели бета-тестування, зібрали фідбек, впровадили ряд доробок і в кінці січня 2018 року випустили оновлену версію, яка вже доступна в Google Play та AppStore. З iOS-версією все виявилося складніше — нам довелося пережити 5 перевірок від прискіпливих модераторів: співробітники компанії Apple ретельно тестують кожен додаток на всіх iOS-гаджетах. Вони змогли відловити баг при запуску iPhone додатку на iPad, який полягав у тому, що при свайпі картка не зникала, її потрібно було вести пальцем до кінця екрану.

Додаток безкоштовний. Можна придбати одну з підписок на 3, 6 або 12 місяців. Вона дає доступ до всіх фільмів без перегляду реклами.

В оновленій версії користувачів очікують такі фічі:

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

У найближчих планах:

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

Завантажуйте додатки в AppStoreі Google Play, оцінюйте, залишайте відгуки. Будемо вдячні за будь-який зворотній зв’язок про виконану нами роботу!

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

Competera была основана в 2014 году. Главный офис находится в Киеве, где сегодня работает более 50-тисотрудников в продуктовых и сервисных командах, из них 20 — технические специалисты.

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

В округе и поблизости

Офис Competera находится на мансардном этаже здания по адресу ул. Сечевых Стрельцов, 72А. До ближайшей станции метро «Лукьяновская» — 10 минут спокойным шагом.

С поиском кафе или общепитов поблизости проблем точно не будет. В минуте ходьбы от офиса находятся такие кафе, как «Кухня Полли» (стоимость обеда — около 100 грн), «Канарейка» (средний чек — 100-150 грн),веганское кафе Orang+utan Bar (50-100грн за блюдо), Domino’s Pizza, гастропаб Seven Hills. В близлежащих домах есть различные кофейни, кондитерские и эко-лавки.

Несмотря на изобилие мест, у сотрудников нет острой необходимости выходить на обед за пределы офиса: компания полностью оплачивает обеды для команды. Сейчас специалисты выбирают себе меню на неделю у нескольких поставщиков, и каждый день к 12:00 в офис доставляют комплексные обеды, тем самым снимая проблему готовки еды дома и выбора блюд на ланч. В офисе также стоит автомат с едой от Fred & Fresh.

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

Рабочее пространство

Офис Competera — это 500 м²рабочего пространства. Здесь нет больших опенспейс-пространств. Офис поделен на кабинеты, где работают команды по 8-15 человек.

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

График работы гибкий, офис открыт с 7:30 утра и до последнего человека. «Время пребывания в офисе не трекается, главное — не количество отработанных часов, а результат. У каждой команды есть свои ежедневные ритуалы. Обычно ребята синхронизируются со своей командой и проводят встречи в комфортное для всех время. Некоторые сотрудники приходят в офис в 8:00 утра, чтобы не стоять в пробке, а другие наоборот добираются к 11:00 после часа пик», — утверждает представитель компании.

Количество квадратных метров на человека в рабочем помещении составляет 8 м² (по данным компании).

Отдых и вдохновение

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

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

На стенах офиса Competera много картин современных украинских художников. Они и в коридоре, и в митинг-руме, и в рабочих кабинетах. Это коллекция одного из сооснователей — Александра Сазонова, который находит вдохновение в современном искусстве. В офисе есть оригиналы работ Владимира Кузнецова и Ильи Чичкана.

DOU Ревизор спрашивает

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

Игорь, QA Engineer, 8 месяцев с компанией:

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

Дмитрий, Python Developer, Data Delivery Team Lead, 4 года с компанией:

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

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

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

Дмитрий, Product Designer, 9 месяцев с компанией:

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

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

Дана, Junior Python Developer, 6 месяцев с компанией:

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

Ідей, що покращити, — в мене немає.

Стас, Python Developer, больше 2 лет с компанией:

В офисе самое важное — команда, как ни странно. Люди, которые тебя вдохновляют, помогают тебе, которым ты помогаешь. Хорошее месторасположение офиса.

Что улучшить? Как такового ничего нет. Тут и так комфортно.

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

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

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

Смотрите закулисные кадры того, что не проходит нашу цензуру на Instagram — instagram.com/dourevisor

Подписывайтесь на видеоканал DOU Ревизор на YouTube.

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

Ігор Магадапрацює QA-інженером в компанії Astound Commerce в Ужгороді, Павло Генов — Front-end Developer в Svilta. Вже більше 10 років хлопці грають в рок-гурті «Триставісім», який створили з двома іншими айтішниками ще у студентські часи. Ігор грає на барабанах, а Павло — вокаліст та гітарист.

Ми розпитали в Ігоря та Павла, як було засновано гурт, як часто і де колектив виступає сьогодні та як поєднувати музику з роботою в ІТ.

Гурт «Триставісім», Ігор — другий, Павло — п’ятий зліва

— Ігоре, Павле, розкажіть про ваш гурт. Що ви граєте?

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

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

— Як було створено «Триставісім»? Чому обрали саме таку назву?

Ідея гурту з’явилася у нас та ще двох однокурсників у 2003-2004 роках.В той час ми вчились в Природничо-гуманітарному коледжі в Ужгороді за напрямком «Комп’ютерні науки». А назву ми взяли на честь номеру кабінету заступника директора коледжу і кабінету студради, де проходили перші репетиції — № 308.

Троє з нас продовжують грати в гурті і зараз. Окрім нас двох, барабанщика та вокаліста й гітариста, є бас-гітарист Андрій Шаповалов, який також працює на позиції Front-end Developer в компанії SharpMinds.

Наша історія створення гурту та його ранній період дуже нагадує історію гурту «The Offspring» — з різницею в часі рівно 20 років. І в них, і в нас однокурсники, небайдужі до рок-музики, репетиції поміж навчанням і канікулами, і перший вокаліст залишив гурт, а його місце посів гітарист :)

— З чого ви починали і як змінювалась ваша музика?

На початкових етапах нам вистачало 4 музикантів. Згодом, пишучи нові пісні, ми відчули, що їм не вистачає мелодійного забарвлення, і вирішили, що було б добре додати акордеон та духовий інструмент. Тоді ж гурту пощастило отримати колоритну мелодійну складову в лиці професійних музикантів Вови Щобака (вокал, труба) та Стаса Микульця (акордеон). Це був 2010 рік, який ми офіційно і вважаємо роком створення гурту «Триставісім».

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

Спочатку ми зіграли десятки концертів для друзів і знайомих в рідному Ужгороді. Перший виїзний концерт дали в «Етноклубі» у Львові. Через 3 роки, у 2013, записали перший ЕР альбом «Перча»і з ним об’їздили всі найбільші фестивалі України: ZaxidFest, Faine misto та інші.

«Варошська туса» — живий виступ в клубі клуб «Фантом», Ужгород

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

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

В 2017 повернулись в студію для запису другого повноформатного альбому — «Мусай». До нашого основного складу приєднався Dj Vibes.

— Новий альбом уже видано?

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

«Карпатос» — останній сингл гурту

— Як часто виступаєте зараз? Де?

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

— Які найцікавіші виступи можете згадати?

У 2013 році в рамках еко-арт-фестивалю «Карпатський потяг» виступалипрямо у потязі «Івано-Франківськ — Рахів» під час руху. Такий захід протягом декількох років організовували наші друзі, музиканти з франківського гурту «КораЛЛі». Дуже авантюрна і цікава затія була. До того ж, під час нашого виступу пропала електроенергія, і ми вже догравали як могли :)

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

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

Взагалі протягом історії гурту ми розділяли сцену з такими колективами, як Enter Shikari, Hollywood Undead, Zdob și Zdub, «Ляпіс Трубецкой», Noize MC, «Скрябін», «Воплі Відоплясова», «Брати Гадюкіни», «Танок на майдані Конґо», «Тартак».

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

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

Репетируємо ми зазвичай після роботи двічі на тиждень по 2-3 години.

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

«Щастя» — ще один сингл з майбутнього альбому

— Чи впливає якось музика на роботу в ІТ?

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

— В чому секрет успіху для музикантів? Як вийти на рівень, коли вас починають знати не лише друзі й родичі?

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

— Які у вас плани на майбутнє щодо музики? Чого від вас очікувати?

Плануємо дописати та видати наш другий повноформатний альбом «Мусай» і відіграти його влітку на фестивалях :)

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

Введение

«Тяжела и неказиста жизнь простого программиста»
© Диалог в баре

О программистах знают все. Даже дремучие постсоветские кумушки перестали пихать детей в повара: «Компьютерщиком будешь, в тёплом кабинете бабло зашибать». Но популярность имеет отрицательные стороны. Это на опытных есть спрос. А для начинающих ситуация обратная: на одну должность стажера в EPAM или GlobalLogic приходит до ста резюме. Чтобы попасть туда, нужно пройти семь кругов ада без гарантий дальнейшего трудоустройства. И никого не интересует, что в вузе ты хорошо учился, участвовал в самодеятельности и бегал за факультет в спартакиаде. Что же делать? Остальной текст посвящён тому, как сделать, чтобы «не было мучительно больно за бесцельно прожитые годы». Большую часть ошибок совершил я сам, остальные видел. Да-да, вот такой я дурак. Не будьте как я — учитесь на чужих ошибках.

Зачем учиться

Я спросил одного кадровика, почему все непременно требуют высшего образования.
Он ответил:
«Чтобы была гарантия, что этот человек в состоянии пять лет подряд бесплатно заниматься тупой неинтересной фигнёй».
© Анекдот

Вот ты (или твой ребёнок)... Думаешь надо решать все, когда закончишь школу? А вот фиг — поздно! Поступил в девятый выпускной класс (десятый уже поздновато, но что делать — тоже покатит) — всё, детство кончилось. Нужно думать, куда идти дальше. И, как следствие, возникает вопрос: чего ты хочешь от жизни? Ни родители, ни друзья ответа на самом деле не знают, решение за тобой! Учитывай их мнение, но думай сам.

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

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

«По моему опыту, сейчас заканчивают практически все. Действует негласный запрет на отчисления. Так что уходят только те, кому очень нужно (состояние здоровья, выезд на пмж за границу и т. п.) А вот с работой по специальности — сложнее. Процентов 20 — точно работают не по специальности. Остальные — как придется. Именно разработчиками работает процентов 20-25от всех выпускников, остальные — тестировщики, техподдержка и в смежных областях (типа дизайн сайтиков рисуют)».

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

Но для чего всё-таки нужен вуз? «Умение учиться, полезные знакомства» — чушь всё это! Высшее образование направлено на получение фундаментальных знаний:математика, физика, теоретические основы информатики. Далеко не каждая работа требует так углубляться: фундамент — дело хорошее, но для небольшого домика на две комнаты плюс кухня не надо рыть котлован, как для небоскрёба. И польза от котлована будет только, если небоскрёб достроить до конца. В то время как небольшой дом из пеноблока можно возвести за несколько дней и жить всю жизнь. Так и с фундаментальными знаниями — они нужны много погодя начала карьеры. Мне 37 лет, я в индустрии с 2004-гогода, но только сейчас мне понадобилась часть, остальные не нужны до сих пор!

Так что вывод из этой части статьи такой: если вопрос с военкоматом урегулирован (как вариант, собираешься служить — напомню, отношение к армии мы не обсуждаем) и ты не собираешься в околонаучные сферы — высшее образование нафиг не нужно! Вместо него, пойди на Coursera и пройди курсы в рамках какой-то специализации, например, Java, выучи английский и иди устраиваться на работу. К тому времени, как твои более зависимые от общественного мнения одногодки закончат вуз, у тебя будет два года опыта, деньги и уверенность в жизни. Уважаемые родители, убедительная просьба: не заставляйте детей пять лет протирать штаны, получая никчёмноевысшее образование, особенно если у них есть чёткий план в жизни.

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

Как поступить

Человек, находящийся на самой вершине горы, не упал туда с неба.
© Конфуций

Никаких секретов здесь нет — учиться надо. Пока не поздно браться за ум. Раньше для поступления нужно было сдавать экзамены в вузе и это было нехилым источником дохода для особ, приближённых к императору. Сейчас же вам повезло — введено ВНО. Вполне реально его сдать на 170 баллов. За третье место во всеукраинской олимпиаде дадут 10 дополнительных баллов, за второе 20, за первое 30. Максимальное количество составляет 200, и с ними, как мне шепнули на ушко, можно поступить куда угодно на бюджет. Приёмная комиссия ничего не может сделать, хоть захлебнись слюной — на процесс сдачи ВНО повлиять не в состоянии.

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

Куда поступать

«Не место красит человека»
© Слащавая и ложная поговорка

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

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

Как известно, заказчики в украинском IT сплошь иностранные (местный рынок умер не родившись). Что легче: прилететь в Киев и всё или тащиться потом на поезде в Каменец-Подольский вместе с клиентом, мягко говоря офигевшим от украинского сервиса?

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

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

Что учить, на что забить

«От сессии до сессии живут студенты весело,
а сессия всего два раза в год»
© Поговорка отчисленного из института

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

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

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

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

Как выбрать специализацию

«Учись студент, или будешь всю жизнь ключи подавать»
© Голос сантехника, вынырнувшего из люка с гавном

Вы, наверное, уже знаете, что программисты бывают разные, более того — в IT есть ещё тестеры, системные аналитики, менеджеры и так далее. Что делать?

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

Геймдев? Не вляпайтесь!

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

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

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

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

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

Не витайте в облаках

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

Сейчас я побуду занудой и произнесу фразу: «А вот в наше время». Так вот, теперешним студентам очень повезло — работа в украинском IT есть весьма разнообразная. В моё время выбор был весьма ограничен (можете считать меня дедушкой, но это действительно так), однако я не воспринял этого всерьёз. Вместо изучения Java Enterprise, .NET или ещё чего-то, на что был спрос, я упрямо решал дифференциальные уравнения. В моих розовых мечтах представлялось, что где-то там, в далёком Киеве, Москве или Нью-Йорке знания теории вероятностей или языка пролог будут оценены. Как же, ведь это гораздо сложней, чем делать сайтики или писать. Прошли годы, я вышел на рынок труда и с удивлением увидел, что Common Lisp не нужен, от слова «совсем». В итоге, мне пришлось спешно осваивать что-то, с чем можно получить хоть какую-то работу.

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

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

Начало рабочей жизни

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

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

Привіт! Мене звуть Роман Нога, я працюю Software Engineer у EPAM Ukraine (Львів). Вже не перший рік цікавлюся та слідкую за розробками інженерів Google. Хочу поділитися своїми дослідженнями можливостей Cloud Spanner. Хочу одразу зазначити, що наразі досвіду в продакшені з Cloud Spanner у мене немає. У статті поділюся враженнями від знайомства із сервісом і буду радий коментарям тих, хто має реальний досвід роботи зі Spanner.

Коротко про Google Cloud Spanner

У 2017 році Google анонсував Cloud Spannerяк першу горизонтально масштабовану послідовну реляційну базу даних. Він був розроблений інженерами Google для внутрішніх сервісів корпорації і зараз використовується для Google+ і Gmail. Також заявлено, що Spanner дозволяє системі масштабуватись на мільйони обчислювальних вузлів через сотні дата-центрів і працювати з трильйонами рядків даних. Мене дуже зацікавили такі обіцянки, і я вирішив розібратись трошки глибше. Звісно, я не використовував таких великих обсягів даних, як згадано вище, але результати роботи Spanner мені дуже сподобались. До того ж, як і інші сервіси Google, Spanner має дуже зручну веб-консоль для створення таблиць, надає безліч репортів про використання бази та рекомендацію, коли потрібно маштабуватись. Отже, мені сподобалось експериментувати зі Spanner, тому вирішив написати про нього.

Проблеми скейлінгу

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

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

Також можна використати горизонтальне масштабування NoSQL. Для цього застосовуємо, наприклад, Cassandra, HBase, MongoDB, DynamoDB та BigTable. Тут слід пам’ятати, що ми позбуваємось деяких реляційних функцій, таких як JOIN, які приводять до того, що параметри запиту стають більш обмеженими. База даних, яка розміщена на хості, може бути виграшним рішенням в плані підтримки, однак перехід на NoSQL може бути неможливим через редизайн аплікації із сотнями таблиць і запитів.

Яке рішення пропонує Google

Spanner — горизонтально масштабована послідовна служба реляційних баз даних:

• Повністю керована DBaaS з горизонтальним масштабом та автоматизованим шарінгом даних.
• Традиційна модель реляційної семантики та послідовності: схеми, ACID транзакції, SQL.
• Автоматична синхронна реплікація в межах та між регіонами.
• Стандартний SQL.
• Моніторинг, логування, IAM.
• Клієнтські бібліотеки популярних мов (Java, Python, Go, C#, Node.js тощо).
• JDBC драйвер для підключення до популярних сторонніх інструментів.

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

Початок роботи зі Spanner

Google надає 300 у. о. на рік під час реєстраціїусім для використання всіх своїх сервісів. Цього насправді більш, ніж достатньо, щоб розібратись і спробувати попрацювати з Spanner-ом та іншими сервісами. Після реєстрації в консолі ми можемо створити наш інстанс, де ми вказуємо ім’я інстансу, ID, регіон та кількість нодів, які ми хочемо.
Після створення інстансу формуємо нашу базу даних. Для цього ми вказуємо ім’я нашої бази та починаємо створювати схему бази.

Перед початком роботи з базою нам необхідно все «засетапити». Google надає туторіалдля різних популярних мов програмуванні. Після сетапу, у випадку .NET, нам необхідно заінсталювати Google.Cloud.Spanner.Data через NuGet.

Далі все просто: створюємо connection string ($"DataSource=projects/{projectId}/instances/{instanceId}"), формуємо SpannerConnection та робимо звернення до бази. Spanner підтримує всі необхідні запити, такі як: SELECT, JOIN, GROUP BY, HAVING.

Cloud Spanner підтримує прості типи даних, такі як INTEGER, а також більш складні типи — ARRAY та STRUCT. Максимальний розмір значення стовпця — 10 Мб.

Нововведеням в Spanner є interleaved table. Interleaved table використовується, коли необхідно мати доступ до рядків двох таблиць для заданого первинного ключа (кожен раз, коли ми отримуємо дані рядка одної таблиці, нам також потрібно отримати доступ до рядків другої таблиці), або іншими словами, це заміна звичайного foreign key. Буде корисним, наприклад, при CASCADE DELETE.

Для створення таких таблиць нам необхідно в таблиці, що наслідується від базової, вказати два PRIMARY KEY, нашої таблиці та батьківської.

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Отримаємо такий вигляд:

Image source

Також Google гарантує, що всі зміни у схемі бази, наприклад, ALTER TABLE Singers ADD COLUMN Age INT64;будуть відбуватися на льоту (zero-downtime).

Такі заяви Google підтверджує тим, що Spanner тестувався більше 5 років на їхніх продуктах (GooglePlay, AdWords).

Як працює Google Spanner

На малюнку зображено інстанс з трьома нодами і трьома репліками в трьох зонах. У кожній зоні є повна копія даних. Кожна Cloud Spanner нода забезпечує 10 тисяч QPS запитів та 2 тисячі QPS записів і має ліміт в 2 TiB/ноду.

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

Cloud Spanner використовує Data Splits:

Під час звернення до бази даних репліка запитує в лідера, чи має актуальні дані:

SELECT * FROM Table WHERE Name = ‘DOU’;

1. Запит.
2. Чи можна читати?
3. Так.
4. Відповідь.

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

1. Читання.
2. Лок.
3. Відповідь.
4. Запис.
5. Запис в репліки.
6. Підтвердження запису від реплік.
7. Зняття локу.
8. Відповідь.

TrueTime API

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

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

Рекомендація Google, коли використовувати Spanner

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

Недоліки та обмеження

Cloud Spanner не є дешевим. Очевидно, що через ціну він не підійде на будь-який проект.

Cloud Spanner рекомендує використовувати interleaved table для перформенсу та для каскадного оновлення та видалення. В іншому випадку каскадні операції не будуть виконуватись.

Ключі таблиці не можуть змінюватися. Ми не можемо додавати key column до існуючої таблиці або видалити з існуючої таблиці. Це означає, що якщо ми хочемо змінити PK таблиці, то нам доведеться дропнути та створити заново цю таблицю.

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

Підсумки

Google Spanner є новим типом БД (NewSQL), який об’єднує в собі два світи SQL та NoSQL. Він надає можливість для обробки величезної кількості транзакцій. При цьому гарантує цілісність даних з можливістю їх розподілення по всьому світі без обмежень розміром сховища, що вражає. Хоча наразі технологія має відносно невеликий список клієнтів та побудованих на її основі сервісів, але вона заслуговує на увагу широкого кола ІТ-спеціалістів.

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

Google Cloud Spanner
Spanner. NewSQL хранилище от Google
Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL
Работа с временем в Google
Introducing Cloud Spanner: a global database service for mission-critical applications

Привет, меня зовут Андрей, я Data Science инженер в SMART business. В этой статье я расскажу, как мы для сервиса такси Uklon ускорили время подачи машины и оптимизировали расчет стоимости с помощью машинного обучения. Ниже пойдет речь о реальном кейсе применения ML в бизнесе, который показал результаты.

Про конкуренцию и мотивацию

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

Жители крупных городов все активнее заказывают такси онлайн. Если в начале 2016 года доля таких заказов была 5-10%из общей массы, то через год их стало уже в два раза больше. Ожидаемо, что доля онлайн-заказов на рынке будет только увеличиваться. Чтобы оставаться на плаву, некоторые традиционные службы такси начали вводить и у себя возможность заказа такси через сайт или мобильное приложение. Первым онлайн-сервисом вызова такси в Киеве стал Uklon. Сегодня компания получает в среднем около 3 тысяч запросов на вызов в день. Главная фишка в том, что цена на поездку — управляемая. То есть ты можешь назначить любую цену заказа и ждать, пока кто-то из водителей подтвердит её.

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

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

Упор был сделан на улучшение двух показателей: ожидаемое время прибытия такси (Estimated Time of Arrival — ETA) и процент выполнения заказа (или так называемый «процент вывоза»). Время прибытия такси влияет на то, будет ли клиент дожидаться подачи машины или отменит заказ и воспользуется другим сервисом. Процент выполнения заказа — это KPI, который в целом характеризует популярность сервиса и влияет на уровень продаж и долю рынка.

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

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

Переходим к решению

Используемые данные для работы модели

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

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

Описание работы модели (алгоритма)

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

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

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

Для разделения города по регионам вывоза клиентов и точки назначения, а также для сегментации клиентов, мы использовали кластеризацию (k-means алгоритм).

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

Также использовали классификацию и регрессию (Random forest алгоритм) для следующих задач:

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

Этапы работы над моделью

Отобрав наборы данных и загрузив их в базу данных в Azure SQL Database service, мы взяли часть данных для тренировки модели в Azure Data Science Virtual Machine. Для разных задач использовали разные модели, например, для кластеризации города или сегментации клиентов использовался k-means алгоритм, для прогнозирования цены — дерево решений (к слову, сейчас дерево решений для определения оптимальной цены содержит около 300 ветвей). После тренировки модели мы взяли стандартные параметры, которые задает модель, и проверили работу модели на определенной выборке данных. Результат был удовлетворительным.

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

Далее полученная в Azure Data Science Virtual Machine модель, которая решает задачи клиента, была развернута в производственной среде в виде веб-сервиса — а именно в Azure Machine Learning web service. Схема работы решения такова: потенциальный пассажир создаёт заказ в мобильном приложении с параметрами точки вывоза и точки назначения, на основе чего рассчитывается стандартная цена поездки по километражу, и эти входные данные отдаются через сервер «Уклона» к развёрнутому веб-сервису. Далее модель просчитывает оптимальную цену для данной поездки, при которой пассажир не будет торговаться, а таксист наиболее вероятно возьмёт заказ. Просчитанная моделью цена возвращается на сервер «Уклон» и уже оттуда — в клиентское приложение, где пассажир может видеть предложенную цену для данной поездки. Скорость просчёта оптимальной цены настолько высока, что пользователь мобильного приложения не замечает никаких задержек.

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

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

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

Результаты работы модели

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

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

При использовании новой модели машина находится на 18 секунд быстрее. При количестве около 3000 заказов в день — это около 15 часов экономии времени для всего города. Если брать в расчёт среднюю семью, которая ездит на такси приблизительно 4 раза в неделю, экономия времени составляет около 1 час в год.

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

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

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

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

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

Продукт — это не код

Необходимо понять, что обычно клиенту не нужен код. Ему нужен продукт, который приносит деньги. Поэтому вовсе не обязательно, чтобы у этого продукта был классный код с минимальным техническим долгом. Вы можете выбрать менее популярный stack, не самые модные инструменты. Критически важно лишь одно: полученный продукт должен решать поставленные задачи. И здесь, к слову, необходимо учитывать, в каких условиях работает клиент, например зависимость от сторонних сервисов (Auth0, Twilio и т. д.).

Технический долг как инструмент

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

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

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

Рекомендованные подходы с React

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

Среди основных подходов, на которые я рекомендую обращать внимание — использование модульной структуры. Я долгое время работал на бэкенде. Потом — fullstack-ром. Мне понятен и близок MVC-подход,где группировка компонентов происходит по типу данных (Model, View, Controller). С другой стороны, когда я перешел полностью во фронтенд и React в частности, то сделал для себя вывод, что группировка по модулям/компонентам — более профитная. Мы можем один компонент перенести в другой конец приложения, и это будет приемлемо. Ни для кого не секрет, что когда проект развивается, папка components разрастается и может стать необъятной при MVC-подходе,когда файлы группируются по назначению.

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

Отдельно хочу отметить, что командная разработка и разработка одним девелопером могут сильно отличаться. Если ты один на проекте, полностью знаешь его, то многие вещи можно упразднять. Например, можно прокидывать пропсы spread оператором (<Component ...props />). Но работа в команде требует четкого понимания процесса от всех участников. Переопределение тех же атрибутов позволит человеку за соседним столом не подниматься по всему дереву компонентов, а сразу видеть, какие из них передаются (<Component attr1={props.attr1} attr2={props.attr2} />). Для командной работы также очень актуальна типизация данных, определение PropTypes и defaultProps.

Redux — как инструмент для работы с данными

Помимо работы с компонентами, необходимо понять, где и как будут храниться данные. Например, сейчас я занимаюсь проектом Vantage (Transport Management System) — портал для перевозчиков и заказчиков перевозок. Для работы с данными наша команда использует Redux. Одна из основных причин, почему мы остановили наш выбор на нем — девелоперов с опытом Redux гораздо больше, чем с другим.

Основное преимущество Redux — это управление как состоянием данных, так и состоянием интерфейса. Redux — единственный источник истины при разработке. Все очень упрощается, когда ты знаешь, где искать последнюю и актуальную информацию. Есть множество способов и подходов при работе с Redux. Лично мне нравится duck-подход. Утиная типизация. Ее смысл можно передать английским выражением: «If it walks like a duck and it quacks like a duck, then it must be a duck». («Если нечто выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть»).

Концепт этого подхода заключается в том, что мы группируем в одном месте все модули: action creators, actions, reducers. Например, в нашем проекте мы все модули храним с компонентами. Есть подход группировки по constants, actionCreators, actions в отдельных файлах. Я пробовал такой подход в самом начале работы с Redux, и, на мой взгляд, намного проще, когда все сгруппировано именно в компонентах.

Работа с функцией высшего порядка

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

Допустим, мы создаем компонент BirthdayPresents, который должен отображать подарки на день рождения. Перед тем, как его вызвать, нам нужно получить данные. Эти данные можно получить в самом компоненте: посылаем запрос на сервер и получаем список людей, а также их подарки. Есть второй способ. Мы можем сначала вызвать функцию withUsers — получаем список юзеров. Дальше мы вызываем функцию withBirthday — получаем список пользователей, у которых сегодня день рождения. Дальше мы получаем список подарков с помощью withPresents. Потом мы можем исключить из списка подарков, скажем, желтые с помощью функции withoutYellow. Таким образом, перед тем как мы получили наш основной компонент BirthdayPresents, мы уже получили все данные, просто сформировав цепочку этих данных:

compose(
	withUsers,
	withBirthdays,
	withPresents,
	withoutYellow
)(BirthdayPresents)

Среди минусов — полная зависимость от порядка вызова. Например, если мы поменяем местами withUsersи withPresents, то наш HOC не сможет справиться с задачей — так как withPresents не найдет списка юзеров, что может быть обязательным параметром. Кроме того, HOC может сам менять данные. И когда мы столкнемся с такой проблемой, нам нужно будет сначала понять, что у нас с этим есть проблема, а в большинстве случаев это может быть сложно. Для ее решения, нам нужно либо писать новый HOC (такой же как исходный с некоторыми изменениями), либо править уже существующий, что может сломать логику в исправно работающих местах. Это основные подходы, которые мы используем в нашем приложении Vantage.

Установка и настройка сборки проекта

Хотелось бы еще затронуть тему настройки сборки на старте проекта. Есть старый добрый способ: подключаем bower или npm, конфигурируем webpack, настраиваем все сами. Это долго. Как правило, чтобы сократить время, конфигурация с предыдущего проекта просто переносится на новый. И казалось — работает и работает. Но по факту, мы перенесли устаревший код, и это может стать проблемой и ограничением. Поэтому мне больше нравится использование boilerplates. Самый популярный сейчас — Create React App от Facebook. Всего одной командой он конфигурирует все приложение.

Мой фаворит — React Redux Starter Kit, который, к сожалению, уже не поддерживается из-за появления React Router 4. Не поддерживает и plain routes в полном объеме — а они были основой этого boilerplate.

Работа со стилями

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

Есть JSS-подход. Мы работаем в JS и постоянно генерируем свои специальные классы. На проекте может быть сотня файлов с классом container. Но JSS каждый раз генерирует новый класс (container-1, container-2...). В таком случае эти стили мы можем хранить в компоненте. Что важно — стиль из одного компонента не может изменить стиль другого компонента без нашего участия. Это позволяет инкапсулировать данные. Функционал JSS библиотек, по большей части, соответствует функционалу препроцессоров.

Перед началом нового проекта

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

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

Выводы

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

Удачи с выбором «правильных» инструментов.

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

Першу в КНУ імені Тараса Шевченка вільну лабораторію робототехніки та мікроелектроніки Relab на факультеті радіофізики, електроніки та комп’ютерних систем (ФРЕКС) було відкрито у вересні 2017 року. Відтоді вона стала платформою для тих, хто хоче навчатися, розвиватися, знаходити однодумців та колег, реалізовувати власні ідеї та стартапи. Мене звуть Роман Куриленко, я студент 1 курсу магістратури факультету РЕКС та один з авторів ідеї цього проекту. Зараз я відповідаю за фандрайзинг та з’язки зі ЗМІ. Я розкажу, як створювалася й розвивається наша лабораторія.

Ідея

Навесні 2013 року на радіофізичному факультеті КНУ (теперішній ФРЕКС) на базі однієї з лабораторій виник безкоштовний гурток робототехніки. Ним керували засновники UA-Robotics та Heli, тоді ще наші студенти Віта Гайдар та Сергій Батарчук. Ми мали певне обладнання (плати Arduino UNO та набір модулів до них), а також дружній колектив, що прагнув навчитися. Гурток об’єднав близько десяти студентів-початківців у програмуванні мікроконтролерів. Через кілька місяців у гуртку залишилося 5 найбільш зацікавлених студентів, а ініціатива переросла в проект автоматизованої системи догляду за кімнатними рослинами «Eco-Box». На першому фестивалі роботехніки в Дніпрі цей проект отримав номінацію «Most Useful». Але головне в усьому цьому те, що ми здобули велику ідею: майбутнє нашого факультету не може існувати без робототехніки та ІоТ.

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

Відкриття лабораторії Relab 20 вересня 2017 року

Реалізація

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

Університет за кошти спецфонду закупив для нас базові необхідні меблі: шафи та стільці. Косметичним ремонтом аудиторії зайнялись ініціативні студенти та викладачі факультету. Разом із нами фарбували стелю, штукатурили стіну заступники декана Вікторія Віталіївна Ніконова та Вячеслав Францович Борецький.

Лабораторію було створено спільними зусиллями Студентського парламенту та адміністрації факультету за підтримки компаній Melexis, EPAM, Viakom. Melexis надала великі та зручні комп’ютерні столи, EPAM допомогла із комп’ютерним обладнанням (стаціонарні комп’ютери у повній комплектації), а Viakom надала базові електронні компоненти та інструменти, а також подарувала справжній 3D-принтер.

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

Відео студентського телебачення університету про Relab:

Перспективи та можливості

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

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

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

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

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

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

До розробки та реалізації ідеї розумного факультету «Smart Rex» долучилися усі активісти та резиденти лабораторії Relab, а також представники провідних молодіжних організацій КНУ імені Тараса Шевченка: Студентського парламенту університету (СПУ), Студентської ради студмістечка (СРС), — зокрема голова СРС Олександра Тиркалова. Якою стане оновлена лабораторія, побачимо вже восени цього року.

Наші контакти
Facebook: www.facebook.com/groups/416391268735797
Telegram: t.me/smartrex
Телефон: +38 (073) 419-74-15 (Роман)

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

Петр Кореневпочти 2 года работает в Sigma Software, занимается разработкой под iOS около 6 лет. Часто выступает на конференциях, а также участвует в их организации: на его счету подготовка и проведение CocoaHeads Ukraine и UMT.

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

О себе

Я увлекаюсь программированием очень давно, где-то с 12 лет. Мне очень нравилось что-то создавать, начинал с графических программ в консоли. Тогда у меня еще не было компьютера: я ходил по родственникам, компьютерным клубам, уделял внимание информатике в школе. Поэтому, когда пришло время поступать вуз, вопрос о направлении не стоял. Я выбрал специальность «Компьютерные системы и сети» в ДонНТУ.

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

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

Впоследствии я за 6 лет поработал в 5-тиаутсорсинговых компаниях — в Донецке, затем в Днепре и Киеве. В Sigma Software пришел в августе 2016 как Senior/TeamLead iOS Developer.

Последние несколько лет я часто выступаю на конференциях (из последних — ITEM, CocoaHeads Ukraine, SE в Киеве), провожу тренинги и воркшопы. Чувствую ответственность перед сообществом, которое вырастило меня как профессионала, и хочется отдавать ему «долг». К тому же, очень мотивирует, когда после выступления ко мне подходят люди и говорят, что им очень понравилось.

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

Рабочие обязанности

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

Около 70% всего времени непосредственно пишу код. Остальное время уходит на работу с процессами и проектами, репортинг, код-ревью, менторинг, обучение.

Как правило, в Sigma сотрудники уровня Junior и Middle задействованы в одном проекте. Люди Senior+ разделяют свою экспертизу и время между несколькими разными проектами. Я сейчас работаю параллельно на двух. Один из них — в сфере Advertisement, другой — из игровой индустрии. Также сейчас начинаю работу над проектом в области Embedded.

Кроме этого, я занимаюсь preSales-активностями: помогаю оценить потребности нового клиента, перспективы проекта.

Если говорить о моих обязанностях как соорганизатора конференций CocoaHeads Ukraine и UMT, то я — технический модератор. Работаю со спикерами, заранее просматриваю их слайды, даю советы, как можно улучшить их выступления. Занимаюсь техническим оснащением, слежу за количеством розеток, доступностью Wi-Fi на локации, организовываю видео- и аудиозаписи выступлений. На подготовку одного митапа CocoaHeads уходит порядка 150-200 часов.

Типичный рабочий день

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

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

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

20:00.Еду домой. Офис Sigma расположен на Подоле — и утром, и вечером тут страшные пробки. Обычно я стараюсь «пересидеть» это время в офисе и выезжаю, когда дороги становятся более свободными.

21:00.Вечером дома или что-то читаю, или готовлю программы своих курсов и тренингов. Это не связано непосредственно с рабочими обязанностями в Sigma, но я все равно отношу это к сфере работы — в данном случае это работа над моим личным брендом. И, к тому же, источник дополнительного дохода.

Сейчас работаю над двумя тренингами — по темам Performance testing in Swiftи Mobile products security essentials. Они пройдут на базе Sigma Software University в мае и июне. Это довольно-таки большие мероприятия, которые требуют серьезной подготовки. Стараюсь выделять время для работы над ними каждый день.

Инструменты и продуктивность

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

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

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

Все коммуникации по рабочим проектам веду через Slack, также пользуюсь Telegram и Jira. Для разработки — Xcode. Люблю приложения, которые упрощают жизнь, — к примеру, книги и банкинг в телефоне.

Активно использую Google-календарь: планирую там все встречи и активности.

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

Я не использую какие-то особые практики по продуктивности, это происходит скорее интуитивно. Работая над проектом, постоянно задаю себе вопрос: «А не фигню ли я делаю?». Это помогает оптимизировать свои занятия.

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

Времени на отдых мне хватает, я не могу сказать, что работаю совсем на износ :) Перегрузить мозг позволяет телик — просмотр каких-то бессмысленных программ, типа «Голос країни». На эти 3 часа ты превращаешься в «диванного овоща» и неплохо расслабляешься. Также я раз в несколько месяцев путешествую и работаю из других стран — это тоже помогает перезарядиться.

Книжки и самообразование

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

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

До этого читал «Продавец обуви»Фила Найта. Это история успеха компании Nike, рассказанная ее основателем, — очень вдохновляющая.

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

Ретроспектива и планы на будущее

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

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

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

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

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

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

Мечты о продуктах

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

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

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

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

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

Готовность номер один

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

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

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

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

Критерии успеха

Теперь представьте себе, что вы владелец или CEO компании с теми самыми кофемашинами. По каким-то причинам вы решили передать на аутсорсинг разработку IT-системы для ваших кофеен. Какую информацию вы должны передать исполнителям, чтобы бизнес оставался эффективным? Business vision и Target audience: кто покупает у вас кофе, где места с высокой проходимостью. А также показатели, сигнализирующие, что продукт нужно подстраивать или менять. В данном случае таким показателем будет среднее количество покупок в день. Эксперименты можно ставить очень быстро: провести на месте целый день, учесть погодные условия. Казалось бы, не надо быть ни Эйнштейном, ни Коперником.

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

1. Кто и как сможет определить, успешен проект или нет?
2. Кто будет спрашивать, успешен ли проект?

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

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

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

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

Погружение в бизнес

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

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

Выводы

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

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

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