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

Ідея

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

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

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

Саме тоді у мене і мого гарного товариша Віктора Андрусівавиникла ідея проекту «Каратєль». Ми з командою громадської організації «Фундація.101», яку я очолюю, вирішили створити мобільний додаток, через який можна було б дуже легко і швидко поскаржитися на проблему, яка вас турбує, і винні у її виникненні були б так само швидко покарані :)

Реалізація

Я звернувся до своїх давніх партнерів і, мабуть, найпрозорішої в Україні краудфандингової платформи People’s Project, яка нас підтримала. Зібраних коштів (376 819 грн) нам вистачило, щоб створити та запустити проект. Ми розробили мобільні додатки під iOS та Android (завантажити їх можна на сайті «Каратєля»), ну і, звичайно ж, бекенд, який керував їхньою роботою. До речі, окрема подяка команді Aejis, яка не просто класно реалізувала все в технічному плані, але так само, як і я, «загорілася» цим проектом і в усьому допомагала. Не можна також не сказати і про команду StartIT, яка допомогли нам з тестуванням системи.

Серверну частину ми вирішили робити на Ruby on Rails з використанням системи керування базами даних PostgreSQL.

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

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

Окрім мене, над реалізацією проекту працювало ще три людини: піарниця Олександра Кузнєцова, юристка Ірина Макухата фахівець з аналітики Ганна Переїденко.

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

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

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

Проект запущено 20 квітня 2017 року, і станом на сьогодні наш сервіс налічує близько 16 тисяч користувачів. За цей час ми обробили понад 4 тисяч звернень та вирішили більше 3,6 тисяч проблем громадян, серед яких: відновлення парканів та фасадів будинків, ремонти доріг і зламаних сходів, прибирання сміття, спилювання гілок на аварійних деревах, зафарбовування реклами наркотичних засобів, притягнення до відповідальності за продаж прострочених товарів у магазинах тощо. Ми регулярно пишемо про наші історії успіху в соціальних мережах, які можна знайти за хеш-тегом #КаратиЛегко.

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

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

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

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

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

Кодить, забыв об опасности

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

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

Непреднамеренный вред

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

Классический пример такого дуэта в IT — вынос недостаточно защищенного сервиса в публичный интернет. Разработчик, который этот сервис написал, отдавал себе отчет, что тот, возможно, защищен достаточно примитивно, но он также знал, что это внутренний сервис, он находится в относительно безопасной сети, недоступен «снаружи». Проблема в том, что свое знание о возможных проблемах с безопасностью он никому не передал, а в через какое-то время новое задание получил уже другой человек. Например, компания, в которой сервис сделали, начала аутсорсить часть работы, и доступ к системе потребовался работникам извне. И вот уже сервер прощупывают сотни скриптов, ищущих уязвимости, делается brute-force подбор паролей, которые для маленького внутреннего сервиса, скорее всего, простые, наверняка и тестовые аккаунты остались, да и SSH-сервер без секьюрити-патчей за два года.

Кто тут самый виноватый? Здравый смысл подсказывает, что тот, кто выставил сервис в интернет — он не обеспечил его должную защиту. Но ведь он мог и не знать, что там есть аккаунт «admin» с паролем «test» или что по определенному URL разработчик оставил страницу диагностики, которая вообще не защищена паролем. Если бы первый разработчик не экономил на безопасности и делал систему «как для врагов» — может быть, многих проблем можно было бы избежать. Именно поэтому забота о безопасности должна начинаться с первого дня — это то, что называется «security in depth».

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

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

Buffer overflow

Я предполагаю, большинство разработчиков знают, что такое buffer overflow и почему, когда пишешь на языке C, нельзя использовать функции стандартной библиотеки, которые форматируют строчку, не ограничивая ее длину. Просто потому что в сервисе с открытой регистрацией какой-нибудь пользователь попытается создать себе имя такой длины, которая переполнит буфер и заставит процессор выполнять уже не ваши, а его команды. Это тема, казалось бы, заезжена. Об этой проблеме известно десятки лет, но на GitHub и сейчас можно найти какой-нибудь свежий opensource-проект, в котором первой же строчкой будет форматирование текста в не ограниченный по длине буфер, где в качестве параметров используется информация «out of control of the application, т. е. полученная от пользователя.

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

В Java такое слабое место, как buffer overflow, отсутствует как класс. Но каким бы ни был язык, не составляет труда накодить на нем какую-нибудь классическую дыру. Скажем, вроде сервера, возвращающего файл из upload-каталога по его имени, где окажется, что в имени можно передать ../../.. и выйти за пределы upload-каталога. Подобные проблемы известны много лет, и в 2018 году не должно быть ни одной программы, которая позволяет этим воспользоваться. Но они продолжают появляться.

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

Опасные связи

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

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

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

Готовность к стандартам, труду и обороне

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

В IoT особенно ярко проявляется стремление как можно скорее вывести на рынок новейшее гениальное устройство. Поэтому вопрос стандартов оказывается вторичен — если приложение может управлять устройством, производитель уже счастлив. Позже на него начинают сбоку прикручивать, например, интеграцию с Amazon Alexa, чтобы им можно было управлять голосом. Но это уже пример after thought (мысли вдогонку).

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

Слабое звено

Производители бытовой техники теперь стараются вывести в интернет любой новый прибор. Я с большим удивлением узнал, что микросхема ESP32 (есть еще и более ранние варианты, в том числе ESP8266) стоит меньше доллара. Она позиционируется как «system on chip with integrated Wi-Fi» — в принципе, это маленький процессор со встроенной памятью и Wi-Fi-модулем. Стоит копейки, да и размером тоже с монету. Какой соблазн для производителя микроволновой печи воткнуть в нее такую штуку! А сколько возможностей для утюга!

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

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

Почему засилье connected (без нужды) устройств — это проблема?

Кофеварка тоже может сходить в интернет, чтобы узнать свежие цены на кофе или курсы валют. И хотя она не может рассказать о тебе слишком многого, кроме, пожалуй, режима владельца, с ней может возникнуть другая проблема: «Цепь настолько крепкая, насколько крепким окажется ее самое слабое звено». Я имею в виду, если ваша кофеварка будет взломана, под ударом окажутся еще 25 ваших unhackable устройств. Тот, кто сумеет взломать любую бытовую технику, подключенную к вашей сети, по большому счету войдет к вам домой и сможет там разгуляться. Такое уже было, правда, не с кофеваркой, а с чайником. Его производитель использовал чип со встроенным Wi-Fi, поддерживавший TELNET с дефолтным паролем. А зайдя в чайник, через пару команд можно было получить Wi-Fi-ключ. В общем и целом, чем больше разных устройств в доме, тем больше того, что называется attack surface — потенциальных мест для атаки.

Например, у какого-то устройства может быть механизм, подразумевающий автоматический трансфер данных конфигурации. Если одно из них выйдет из строя и будет заменено новым, первое просто передаст данные о локальном окружении: ключи, пароли, а новое не нужно будет мучительно конфигурировать. Но, если в это механизме есть дырки, проходящий под окном человек сможет заставить устройство передать эти данные и ему. Проблема в том, что пользователь, как правило, понятия не имеет, на что способно его устройство. У него может быть всего одна кнопка, оно может не уметь ничего умного, и common sense подсказывает нам, что и угрозы оно представлять не должно. А представьте, что оно принимает команды по Bluetooth, и в нем забыли отключить режим диагностики... А всегда ли вы готовы доверять результатам security testing производителей бытовой техники? Да и было ли оно?

Выводы

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

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

Я всю жизнь проработал в сфере телекоммуникаций, время от времени разрабатывая программы: вместе с развитием индустрии переходил от одной технологии к другой. Программировать начал в 80-х,застал еще БК-0010 и БЭСМ-6, и это стало увлечением на всю жизнь. Сейчас пишу в основном под Node.js c React. Из последних технологий — VR с помощью Android или Unity.

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

Мы однажды с удивлением узнали, что на родине Интернета его цена в долларах за пределами больших городов зачастую превышает цену в гривнах в Украине, а спутниковый и мобильный интернет имеет лимиты на объем трафика. Чтобы прояснить ситуацию, взяли туристическую визу и в феврале 2015 года проехали по США. Поскольку цель была поселиться поближе к морю, то выбрали Калифорнию. Также у нас был товарищ в Сан-Франциско, который очень помог по приезде и познакомил с украинской общиной.

Увидеть Америку на машине

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

Дороги в США в отличном состоянии, и движение по ним со скоростью 70 миль в час воспринимается как стояние на месте. В этом есть опасность, так как превышение скорости быстро фиксируется и карается штрафом в $300-800 в зависимости от места и превышения скорости. Мы неоднократно были свидетелями того, как мимо нас проносились ребята, а через нескольких миль мы уже наблюдали их на обочине в компании полиции. Полиции, кстати, на дороге не видно. Нам встречаться с ней на пути за все время пребывания в США не приходилось.

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

Открытие бизнеса

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

Рассвет в нашей деревне

Новую компанию в США мы открыли за $1000. Пользовались услугами BizFiling. Открыть компанию может любой человек — никаких ограничений нет. Для этого нужен только скан паспорта. Процедура заняла два месяца, и осенью 2015 года, к нашему приезду, мы получили документы по почте.

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

Налоги штата Калифорния составляют $800 в год для дохода до $200 тыс. в год, федеральные налоги — это история сложнее. Шкала федерального налога прогрессивная, то есть с первых 9 тыс. ничего не платишь, со следующих $20 тыс. платишь 15% и т. д. Часть дохода не обкладывается налогом, если были сделаны затраты на определенные нужды. В общем это не очень просто, но любой бухгалтер оформляет все отчеты за $700-$1500, и делать это нужно один раз в год.

По приезде договорились с владельцем радиовышки и местными властями о начале работы. В США есть много диапазонов частот, для работы в которых не требуется никаких разрешений. Вообще для начала работы нам понадобилось только разрешение от мэрии для установки оборудования на радиовышку и разрешение вести бизнес. Подозреваю, что можно было бы не получать разрешение на установку оборудования, но нам, по украинской привычке, очень хотелось иметь побольше документов. Разрешение обошлось в $140, а лицензия на ведение бизнеса $70. Теперь платим $70 каждый год за продление лицензии. Стоимость лицензии зависит от места ведения деятельности и, возможно, ее вида. Самая высокая стоимость в нашем городке — это $350 в год. Больше всего мы волновались, ожидая каких-то проверок по бизнесу, как в Украине, но такого испытать не довелось.

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

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

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

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

Оформление визы Е2

Получение консультации в любом государственном учреждении — задача очень сложная, так как тебе сразу говорят, что ты должен обратиться к юристу. Выдавить информацию о том, что необходимо вписать в ту или иную форму, невозможно. Хорошо, что с появлением интернета почти все необходимое можно найти там. Стоимость услуг юристов в США за помощь в заполнении любой формы на 1-2страницы стоит минимум $1-2 тыс. Помощь в подготовке документов на Е2 визу обойдется в $5-10 тыс.

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

Быт в Калифорнии

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

Мы арендовали симпатичный дом на две спальни с апельсиновым садом. Получилось далековато от океана, зато дешево. Стоит $750 в месяц и коммуналка в среднем еще $50. Сейчас, кстати, сезон — апельсины самые сладкие именно в это время.

В США необычные правила аренды дома. Можно снять только апартаменты, а для того, чтобы арендовать дом, необходима ваша история аренды недвижимости в США. Нам пришлось просить владельца вышки выступить нашим гарантом, и только на таких условиях нам разрешили арендовать дом. Договор аренды — очень важный документ. Во время визитов в банк или DMV (местное ГАИ) необходимо его показывать, так что есть смысл сделать копию. Дом сдается с холодильником и стиральной машиной, но без кроватей и мебели. В первое время нас выручило то, что в любом магазине можно за $80-100 купить надувную кровать, которая не сильно отличается от настоящей.

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

Купить машину и зарегистрировать ее — просто. Есть места, где машины стоят на улице со специальными стандартными табличками под стеклом. Выбрав машину, звонишь владельцу и договариваешься о встрече. Когда он приезжает, проверяешь машину и, если готов брать, то платишь ему, а он выдает тебе бумажку для DMV. Ты должен с этой бумажкой посетить любое отделение DMV, заполнить форму, заплатить сбор и тебе по почте через 10 дней пришлют документы на машину. В Калифорнии обязательное страхование машины. Делается через веб-сайт быстро и просто, хотя и стоит от $800 в год. Мы пользуемся Gekko, вроде как самая адекватная страховая компания.

Получение прав в Калифорнии стоит $33 и занимает неделю. Для этого надо записаться на экзамен в DMV, прийти и сдать письменный тест, можно на русском языке. После этого можно проходить тест на вождение. Для тех, кто сдает на права в США первый раз, это обязательно. Требования к стилю вождения отличаются от украинских. Здесь нужно во время езды поворачивать голову, беглого взгляда в зеркала не достаточно. Это знание стоило мне $17 за пересдачу.

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

Недостаток общения

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

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

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

Визиты соотечественников позволяют немного заполнить вакуум общения. Но, к сожалению, даже с учетом того, что билеты на самолет дешевые, знакомые с визитами не частят. Например, билеты из Стокгольма до Сан-Франциско и обратно возможно приобрести за $350.

В Сан-Франциско с братом, купаться не стоит

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

Выводы

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

Позитивные моменты:

• Е2 виза — это простой и относительно дешевый способ получить опыт не просто проживания, а именно жизни в США, то есть с проблемами, контактами с местными жителями и государственными учреждениями.
• Жизнь в Калифорнии безопасная и комфортная, дороги хорошие, цены на товары довольно низкие.
• Стандартные вопросы — купить машину, получить права, отправить детей в школу — решаются без трудностей.
• Бизнес в США вести просто. Регулирование на самом минимальном уровне. Всякие лицензии и разрешения, даже если это необходимо, получить несложно. Отчетность подается один раз в год. В любом случае можно нанять бухгалтера, который за $700-1500 заполнит и подаст отчеты. Налоги платятся тоже один раз в год. И хотя их расчет выглядит сложно, на самом деле все достаточно просто и на сумму дохода до $300 тыс. в год — очень немного.
• Местное население очень радушное и простое. Может, это потому, что Калифорния или потому, что это деревня, но для нас это было в удовольствие.
• Климат значительно лучше, чем в Украине. В марте у нас днем + 22-24°C, ночью температура около + 8-10°C.
• По визе Е2 оба заявителя получают номер социального страхования (возможность получить кредитную карту и кредитный рейтинг), а супруг или супруга главного заявителя, при желании, может получить разрешение на работу, которое не ограничено созданной компанией.
• Наличие бизнеса позволяет легче адаптироваться, так как постоянное вовлечение в бизнес расширяет круг знакомых и не оставляет времени на депрессию и тоску по Родине.

Негативные моменты:

• Главный недостаток для нас — это то, что океан в Калифорнии холодный в течение всего года везде за исключением Сан-Диего. Но там достаточно дорого, да и граница с Мексикой приносит много хлопот.
• Разница во времени в 10 часов оставляет только несколько часов утром для контактов с родственниками и знакомыми.
• Два холодных месяца — это декабрь и январь. Хотя днем температура около + 20 °C, по ночам бывают заморозки, и из-за этого много людей болеет простудой и гриппом. В июле и августе дневные температуры превышают + 40 °C, что тоже некомфортно. Климат на побережье сильно отличается. Например, в Сан-Франциско почти круглый год прохладно — около + 20 °C, ветрено, и океан опять же холодный.
• Медицина дорогая и медикаменты труднодоступные. Мы привезли медикаменты из Украины, а услугами местных врачей не пользовались. Медицинскую страховку также не покупали, так как посчитали, что дешевле слетать в Украину, если понадобится.
• Пища и полуфабрикаты не вкусные.

В целом это было очень полезно и интересно. Этот опыт позволил посмотреть на жизнь в США изнутри за счет доходов, получаемых в США, но нашу задачу жить у теплого моря — не решил. Так что в следующем году планируем перебраться в Мексику (правда, комарами пугают) или Гавайи. Гавайи уже проверили, теперь собираемся в Мексику съездить посмотреть.

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

Вакансии

Приватвакансия для яваджаваскрипт девелоперов

Вот так в Playtech ждали аниматора в команду

Вакансия C ++ Developer от Akvelon

Blackthorn Vision искали в свое королевство рыцаря .NET

О разработчиках

Суровые будни разработчиков Playtika

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

Первый рабочий день новичка в Innovecs

В Mobilunity лучшего работника месяца выбирали между голливудскими актерами и Кличко

Cleveroad’s coding

О компаниях

Как бы выглядел Netpeak Software во времена СССР

Новогоднее поздравление от Terrasoft

С днем рождения, Crytek

Корпоративный дух Do IT Programming Solutions

AR-технологии в офисе Softjourn

См. также подборку за 2016 год.

Дайджест создан в соавторстве с Егором Папышевым.

00h > Интро

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

01h > Горячее

В феврале этого года в Google Play появилось вредоносное приложение «Универсальный мобильный банкинг». Целью мошенников были клиенты крупных украинских банков. С разбором инцидента от специалистов Cys Centrum можно ознакомиться тут.

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

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

21-гоапреля в Киеве пройдет конференция «Security BSides Kiev 2018», на которой можно будет встретиться с одним из авторовсего дайджеста. Приходите, конференция обещает быть крутой ;)

02h > Около секьюрити

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

Внезапно ники пользователей XBox были заменены реальными именем и фамилией. Подробнее на Kotaku.

The Los Angeles Times стал жертвой злоумышленников, используя неправильно сконфигурированный S3. Майнербыл размещен в одном из скриптов новостного сайта.

Любителям Raspberry Pi будет интересна инструкция по настройке Pi-Hole и OpenVPNна своем девайсе.

Материал о применении искусственного интеллектадля противодействия кибератакам.

03h > Интересное

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

Интересный материал об обходе ASLR на Linuxнаписал исследователь @blackzertиз PTSecurity. Рекомендуем к обязательному ознакомлению.

Анализ бэкдора Coldroot под OSX. Да-да, читатель, для твоего любимого MacBook также существует различного рода вредоносное программное обеспечение.

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

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

04h > Уязвимости && Эксплоиты

Замечательный врайтап по нахождению и эксплуатации уязвимостей в PS4. Части материала: первая, вторая, третья.

Еще один врайтап по эксплуатации PS4. На этот раз через уязвимость в WebKit.

Пример эксплойта под Metasploitна редко встречающуюся в наше время уязвимость «Stack-Based Buffer OverFlow» в CloudMe Sync.

Мисконфигурация сервера memcachedпозволяет злоумышленникам использовать сервер для амплификации DDoS-атак. Эксплойт.

Множественные уязвимостив Trend Micro Email Encryption Gateway.

05h > Фан

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

Когда решил заняться багбаунти, но хакнулне того вендора.

06h > Аутро

В этом выпуске вместо аутро мы хотим порекомендовать к прочтению «Don’t click shit»от Volodymyr Styran. Данный текст содержит много полезной информации о личной безопасности в информационном пространстве.

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

Всем привет, меня зовут Саша Емельянов, я Product Manager в MacPaw.

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

Почитать

ML для продакт-менеджеров. Интересная статья о том, как можно использовать Machine Learning на благо своего продукта. И сразу вторая частьстатьи.

Продолжая тему Machine Learning, еще 1 марта ребята из BigML предсказали победителей премии Оскари оказались на 100% точны.

Hard first or easy first?С чего начинать делать продукт? Взяться за самое сложное (и, скорее всего, сорвать сроки) либо начать с простого и понемногу увеличивать сложность реализуемых фич? Простой вопрос, на который у каждой команды разный ответ. В статье — мнение CEO Basecamp.

Не NPS единым. Статья Nielsen Norman Group об измерении степени удовлетворенности UX другими методами.

Itmar Gilad, ex-Google product manager (Gmail, Youtube) пишет о том, почему нам нужно отказаться от стандартных продуктовых роудмэпов и попробовать GIST-планирование (Goals, Ideas, Step-projects, and Tasks).

Александр Агеев написал о геймификации на примере продукта Gemini 2.

Почему мы не используем User Personas? Согласитесь, у каждого был такой опыт: вы попытались выделить сегменты юзеров, объединить их поведенческими паттернами, усреднили возраст, место работы, подобрали красивые фото, после чего аккуратно поместили все в Confluence (а может даже распечатали на стену) и не использовали ни разу. Знакомо? Если да — статьяот Nielsen Norman Group для вас.

Письмо начинающим продакт-менеджерам, которое начинается с простого утверждения — вы не CEO. Стоит внимания.

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

Посмотреть

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

10 UX-вызововна ближайшие 25 лет от Nielsen Norman Group.

Vivek Bedi, который 13 лет проработал в Goldman Sachs, рассказал о качествах потрясающего продакт-менеджераи проблемах менеджмента в энтерпрайзе.

Послушать

Снова об AI. Margaret Mitchell (Research Scientist в Google) рассказывает о том, как создать AI, который поможет человечеству (и не убьет нас всех в итоге).

CEO Mixpanel делится опытом проведения правильных количественных ресерчейи использования аналитики.

Rachel Hepworth (Head of Growth Marketing в Slack) в подкасте Intercom проводит ретроспективу того, как ее команда внедрила growth marketing в одном из самых быстрорастущих стартапов мира.

Лучшее с ProductHunt

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

EasyEmail — Gmail-плагин, который анализирует то, что вы пишете, и создает пресеты для более быстрой почтовой коммуникации.

Overflow — удобный инструмент для создания интерактивных юзер-флоу.

Flow — еще один инструмент для проджект/таск/продакт-менеджмента, но очень красивый.

Work In Progress — закрытое сообщество предпринимателей, объединенных одной целью, — быстрее создавать новые продукты. Аналог Trello/Quora/групповых тематических чатов в одном продукте.

Drag Pro — утилита, трансформирующая Gmail в борд наподобие Trello.

Deckset 2 — напишите все, что хотите, в любимом текстовом редакторе и Deckset 2 сделает из этого красивую презентацию.

Спасибо, что дочитали до конца. Увидимся через месяц!

Подписывайтесь на мой канал в Telegram Product Management Digest, чтобы быть в курсе всего интересного каждый день.

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

Менее чем две недели назад все информационное пространство шумело новостью о том, что Amazon покупает стартап Ring. Мы не стали медлить и решили сами посмотреть, чем же живет киевский R&D центр компании, которую Amazon оценил ни много ни мало в $1 млрд (по данным Reuters).

Ну что ж... В этот раз DOU Ревизорпобывал в киевском офисе Ring Ukraine — R&D центре американской компании Ring. Основной продукт компании — умный дверной звонок Ring Video Doorbell. Это решение для безопасности: звонок мгновенно отправляет уведомление на смартфон, планшет или компьютер, когда кто-то нажимает на кнопку девайса или когда срабатывают встроенные сенсоры движения.

В Киеве в Ring Ukraine работает 500 человек, включая офисы, где работает более 200 операторов. В офисе БЦ «Торонто» на сегодняшний день 228 человек, 175 из них — технические специалисты и разработчики.

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

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

Мы уже писали о самом бизнес-центре и его расположении, когда в 2015 году делали обзор офиса MacPaw. C того времени здесь немногое поменялось: можно съесть комплексный обед в ресторане отеля Holiday Inn (100-150 грн),выпить кофе и перекусить в кафе One Love Espresso Bar (средний чек 100-150 грн)или заглянуть в ресторан Bassano, где цены уже будут на порядок выше. На пути к метро «Олимпийская» очень много кафе и ресторанов на любой вкус и кошелек: «Евразия», «Руккола», «Мураками», «Мафия», «Челентано», Salateira, Daily Fish.

Особой необходимости выходить на обед за пределы офиса нет: компания оплачивает комплексные обеды своим специалистам. Каждую пятницу они заполняют форму, в которой выбирают еду на каждый день. Компания работает с тремя ведущими поставщиками обедов в Украине: «Файна Фамiлiя», Gud Food и Father Kitchen.

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

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

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

Офис Ring Ukraine — это 2000 м²рабочего пространства. Основные рабочие зоны выполнены в стиле open space. Кабинеты — лишь у менеджмента компании и руководителей направлений. Стоит отметить: как для такой квадратуры, в этом офисе довольно много митинг-румов: 12 полноценных румов и 1 sync up зона, event-зона для проведения конференций, митапов и all-hands встреч.

Так как команда работает не только с софтверной частью, но и интегрирует технологии искусственного интеллекта, машинного обучения, компьютерного зрения и анализа данных на устройствах Ring — в офисе есть своя Image Quality лаборатория. Здесь используют систему автоматического управления светом, в том числе невидимого инфракрасного, интеграционную сферу для создания однородного освещения, роборуку, которая позволяет автоматически позиционировать камеру и производить измерения без участия человека, 3D-принтер для печати деталей и переходников, Light box для измерения динамического диапазона камер, спектрометр для измерения спектра источников света. В лаборатории также используют магнитные стены для фиксации предметов.

Ring Ukraine работает по гибкому графику. Офис открыт 24/7, но важно приходить к 11:00, так как в это время начинаются стендапы во всех командах (по данным компании).

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

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

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

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

Во втором блоке есть еще одна кухня с большим обеденным столом, барной стойкой, холодильником для еды и необходимой мелкой бытовой техникой.

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

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

Александр, Head of Hardware Team, 1,5 года в компании:

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

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

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

Александр, Research Lead, 1 год в компании:

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

Что можно улучшить? Критичного ничего. Но, наверное, это первая IT-компания, в которой нет теннисного стола. Можно его добавить и не один. Нас почти 400 человек. А так даже не знаю, что улучшить. Стулья, мониторы, компьютеры — все штуки, которые должны быть хорошими, — они хорошие.

Игорь, Software Engineer, 3 месяца в компании:

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

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

Влад, QA Lead, 1,5 года в компании:

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

Что улучшить? Я вообще люблю такую семейную атмосферу. Но тут это никак не сделаешь, потому что нас очень много. А так меня все устраивает. Хоть и много людей, но не тесно. Пытаются сохранить пространство. Для меня это даже важнее — чтобы у меня был широкий стол, было, где сесть, чем то, как красиво в офисе. Хотя муралы мне нравятся. Не буду спорить.

Вероника, Researcher, 1,5 года в компании:

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

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

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

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

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

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

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

Всеволод Шашарин — Front-end Developer родом из Беларуси, в 2015 году приехал в Украину как политический беженец.

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

— Сева, почему вам пришлось уехать из Беларуси?

Так случилось, что еще в 13 лет я влез в молодежную движуху «Молодой фронт» (в Украине есть аналог — «Национальный альянс»). В подростковом возрасте очень хотелось бороться с режимом. Начал вариться в этой теме, и постепенно это превратилось в работу — я стал менеджером в одной белорусской оппозиционной партии. В IT я тогда еще не работал фултайм, только фрилансил по верстке и JavaScript.

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

— За что арестовывали? Какие были поводы?

К примеру, после выборов в 2010 году было много уголовных дел. В рамках одного из них пришли в офис, задержали, допрашивали. Один раз мне в административном порядке присудили 9 суток за участие в митинге, и я все их просидел в камере один, не выходя вообще. В РБ так бывает :)

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

— Что было дальше?

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

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

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

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

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

— А как на это отреагировали семья, окружение?

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

— Были какие-то проблемы при выезде из Беларуси?

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

— А при пересечении границы России и Украины не возникло трудностей?

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

— Почему выбрали именно Украину и Киев?

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

Так что вопрос «куда» особенно не стоял. Украине я всегда симпатизировал. Примерно представлял процедуру получения статуса беженца, понимал, как функционирует государство.

— Как быстро удалось получить статус беженца в Украине? Как вообще проходит эта процедура?

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

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

Я не заплатил ни копейки, чем даже в некотором смысле горжусь: во-первых, просили, а во-вторых, в год в Украине статус беженца запрашивает примерно 5-6 тыс.человек (в основном это афганцы, сирийцы, ливийцы), а получает примерно 20. Так что это в каком-то смысле нехилый челлендж.

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

— А как проходила адаптация в Украине? Были ли какие-то трудности — к примеру, с языком?

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

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

Кстати, с польским — похожая история. Тоже специально не учил, много слов похожи.

— Быстро ли нашли работу в Киеве? Как оформлялись?

Нашел практически сразу — на позицию Front-end Developer в ІТ-компании.

Пока ждал статус беженца, у меня не было никаких документов. Белорусский паспорт у меня изъяли, он до сих пор лежит в сейфе в ДМС. Вместо него у меня была бумажка — «Довідка про звернення за захистом». С ней вроде как можно работать, но на деле ее нужно каждый месяц продлевать, а потом запрашивать разрешение на работу, которое делается две недели. То есть, по сути, ты можешь работать легально только две недели в месяц :) Так что я просто работал в черную, получал зарплату на руки.

— Какой у вас сейчас статус? Уже получили гражданство?

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

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

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

— Вы не закончили вуз в Беларуси. Отсутствие высшего образования как-то влияет на поиск работы, карьеру?

В Минске я учился в Академии Связи на инженера по телекоммуникациям, поступил туда после 9 класса. Если бы закончил обучение, мог бы получить среднее специальное образование, затем через три года — высшее.

Я 2 года проучился на стационаре, потом перевелся на заочное: работал же, боролся с режимом :) Оттуда меня раза два отчисляли, я то забивал, то восстанавливался. Все это было растянуто во времени на 7 лет. А потом уехал в Киев, и вопрос отпал сам собой.

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

Направление пока не выбрал: мне было бы интересно что-нибудь на стыке финансов и менеджмента. Может, банковское дело или публичное администрирование.

— Какие у вас впечатления после нескольких лет жизни в Украине? Чем Киев отличается от Минска?

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

Вот даже сейчас:

Из Киева гораздо ближе до моря.

В Киеве все цены ниже, чем в Минске — процентов на 20, а может и на 30. Точно помню, что килограмм говяжьей вырезки в минском супермаркете стоил $10. Бокал пива в баре — $5, причем не немецкое или бельгийское, а белорусское или российское. Нормальное будет еще дороже. Бизнес-ланч в ресторане — $10. Поездка на транспорте — 30 центов.

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

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

В РБ грустно с интернетом: почти вся страна до сих пор сидит на ADSL. Мне повезло, в моем доме был Ethernet. За 100-мегабитныйпорт я платил что-то вроде $30 в месяц. И за эту стоимость я мог выкачать аж 300 Гб — потом скорость падала до 2 мегабит. Более того, даже на 100 мегабитах посмотреть вечером YouTube в 1080p не получится. В стране есть госмонополия на «право присоединения к сетям электросвязи иностранных государств» — проще говоря, на внешний трафик. Все коммерческие провайдеры покупают его у Белтелекома и еще у пары прикорытных контор, и в этом месте образуется «бутылочное горлышко» — внешнего трафика на всех не хватает. Я уже не говорю про NAT везде, где можно и где нельзя.

В Киеве я плачу за гигабитную (!) полосу $6 в месяц — в Минске за такой канал можно душу продать, там такого в принципе не бывает. И адрес у меня белый и статический вообще бесплатно.

Как город Киев сам по себе гораздо приятнее и интереснее. В Минске чистенько, конечно... Но село :) Зато там общественный транспорт классный: ходит по расписанию, подвижной состав новый.

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

— В чем, по вашему мнению, заключается эта обратная сторона?

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

Или история с копателями янтаря — ну как это вообще? Или «евробляхи», или нелегальные таксисты — я видел, как в РБ эти проблемы решались в один момент. А в Украине, я так понимаю, боятся обострять. Ай :)

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

— А если сравнивать IT-рынки Беларуси и Украины, где какие плюсы и минусы?

В РБ государство пытается активно лоббировать интересы отрасли: есть ПВТ, парк высоких технологий. Его резиденты не платят НДС, не растамаживают оборудование, платят налог на доходы 9% (у всех остальных — 13%) и соцстрах от минимальной зарплаты, а не от фактической. Валютную выручку не продают, налог на землю не платят. Государство решило таким образом вывести этот бизнес из тени, чтобы айтишники платили тут хоть что-то, а не получали зарплату на карточки Rietumu Banks. Это, наверное, единственный пример, когда в РБ государство пытается помочь бизнесу, а не наоборот.

С другой стороны, на ІТ-рынке Беларуси меньше людей. Меньше вузов, которые готовят специалистов. Ну и все это только в столице — за кольцевой никакого IT нет (в Минске — почти 90%всех IT-специалистов). Формально ПВТ за кольцевой, метрах в 100 от нее, но суть ясна. Поэтому компаний и проектов меньше. Из тех, что есть, как и в Украине, большинство — аутсорсинг. Зарплаты — примерно такие же.

— Какие у вас планы на будущее? Думаете ли о возвращении в Беларусь или планируете и дальше жить в Украине?

Мне в Украине больше нравится. Жить тут однозначно приятнее, и вообще тут сейчас особенно интересно :)

Как выйдут сроки давности по делу, съезжу в гости в Минск. Но переезжать пока не планирую.

Традиционно 8 марта женщин в IT-компаниях поздравили с праздником. Вот как это было.

Если хотите добавить в статью ваши фото, присылайте их на alyona@dou.ua.

AB Soft

Acceptic

Admitad

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

Agilie

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

Appus Studio

Artjoker

Ascendix Technologies

Утром 8 марта девушек встречали охапками тюльпанов, лакомствами и комплиментами.

Astound Commerce

Attract Group

Мужчины компании Attract Group подготовили для своих сотрудниц конкурсы, оригинальные именные подарки и вкусные угощения.

B2B Soft

Blackthorn Vision

У львівському офісі компанії BlackThorn Vision святкували прихід весни з чудовими подарунками: букети квітів, щирі побажання та подарункові сертифікати.

Brander

CHI Software

«С весной, красотка», — именно с этой фразы начался праздник 8 марта у каждой девушки в CHI Software. Целых три дня сотрудники праздновали начало весны: сделали красивую рамку для фото на мастер-классе по квиллингу, посетили лекцию приглашенного beauty-специалиста и повеселились на коктейльной вечеринке.

Ciklum

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

Cleveroad

Codemotion

Настоящие Ninjas порадовали дам Codemotion букетами, комплиментами и вкусностями.

EPAM

Во все офисы EPAM Ukraine заглянула весна и принесла с собой цветы, улыбки и приятные пожелания.

Exoft

В компанії Exoft чоловіча половина колективу окрім теплих слів подарувала дівчатам подарунковий набір з тортика, ігристого вина, букету квітів та сертифікату в SPA.

EIS Group

Ребята EIS Group встречали девушек бокалами шампанского и мартини, а тех, кто придерживается здорового образа жизни — смузи из свежих фруктов. Днём их ожидали фотосессия и вкусный обед, а вечером — мастер-класс по парфюмерии.

ELEKS

В усіх офісах ELEKS відбулось святкування приходу весни під назвою «Spring Day». Влаштували виставку весняних фотографій, які зробили колеги, а також пригощались морозивом. Крім того, співзасновник компанії Олексій Скрипник виступив із лекцією на тему «Чому жінки правлять світом».

Fgfactory

HYS Enterprise

После рабочего дня в офисе девушек HYS Enterprise ждал концерт кавер-группы, угощения и подарки.

Inoxoft

Компанія InoXoft привітала своїх дівчат майстер-класом по виготовленню мила, а хлопці зробили їм сюрприз та подарували вироби ручної роботи.

Intego Group

Intellias

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

Itera

Jelvix

Утро в компании Jelvix началось с поздравлений мужского коллектива. Мужчины читали стихи, играли на гитаре и носили девчонок на руках!

LetyShops

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

Light IT

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

Lohika

Весна завітала до трьох офісів Lohika і наповнила серця радістю і натхненням, ароматом квітів, вспишкою фотокамер, новими світлинами у колі друзів.

LoopMe

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

Lucky Labs

В преддверии 8 марта в Lucky Labs украсили офисы цветочными инсталляциями, а также пригласили артистичных мимов, которые встречали девушек с цветами, и стилистов, делавших им прически и макияж.

Luxoft

В компании Luxoft первая неделя весны ознаменовалась проведением серии вдохновляющих встреч и вебинаров Women’s Week. Сотрудницы говорили о вкладе женщин в IT и поддержке гендерного равенства в этой сфере. Во время мероприятий с признанными лидерами в различных областях девушки делились своими формулами самореализации, лидерства и построения успешной карьеры.
Кроме того, представительницы компании провели встречи со студентками технических специальностей, чтобы рассказать о возможностях построения карьеры в IT индустрии.

NIX Solutions

«Квітніть невпинно!» — пожелали ребята NIX Solutions девушкам и превратили офис в цветущий сад. Здесь девушек ждали всевозможные развлечения и уютный кинозал, а завершился день выступлением Артема Пивоварова, стендапом Никиты Шевчука и общим караоке..

Perpetio

Preply

В Preply решили отметить праздник под девизом «A girl should be two things: who and what she wants», тем самым подчеркивая сильную женскую составляющую как лидов, так и остальных членов команды. 40% девушек — это действительно girl power!

PROBEGIN

Provectus

8 марта ребята поздравили девушек живым акустическим концертом: популярные и авторские песни о любви в исполнении тестировщиков, разработчиков и проджект-менеджеров :)

Relote

Relote отпраздновал 8 марта игрой в боулинг и экзотическим ужином в корейском ресторане.

Roobykon Software

Мужская половина «Roobykon Software» дарила весеннее настроение и сертификаты для похода в кино.

Quantum

Харьковская компания Quantum поздравила прекрасную половину компании сертификатами и цветами, также всех ждали вкусные угощения.

RiverSoft

Roll’n’Code

У Запорізькому офісі Roll`n`Code святкування International Women`s Day подарувало весняний настрій: танці, посмішки та букети.

Sigma Software

Skywell

Конфеты, шоколадки, цветы, праздничная лотерея и много-много внимания и приятных поздравлений — таким было 8 марта в компании Skywell.

TEAM International Services

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

Terrasoft

В холле Terrasoft 8 марта расцвели цветы, а сотрудников ждали легкие десерты.

The APP Solutions

TIW AG

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

Vakoms

8 березня у Vakoms дівчата зустріли у рожевих тонах з подарунками та квітами.

Vilmate

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

ZONE3000

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

ЛІГА:ЗАКОН

Жінок компанії зранку зустрічав fasion-фотограф імпровізованого модного журналу. Селфі на фоні весняних квітів і шоколадний фонтан із фруктами і зефірками піднімали настрій протягом всього дня. Стиліст L’Officiel и лектор в Kiev Fashion Institute Євгенія Скварська, яка щойно повернулась із Паризького тижня моди, провела майстер-клас із актуальних трендів сезону і побудови базового гардеробу в цьому сезоні.

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

Привет, меня зовут Дима. Я разработчик проекта YoutubeTutor — это Chrome extension, дополняющий функционал YouTube для комфортного самообучения.

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

Идея

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

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

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

Реализация

Chrome extension был выбран, чтобы не «пересаживать» пользователя на другой сервис —  просто заходи на Youtube, как и раньше, и проводи время с пользой. Стоимость разработки равна времени разработчика + $5, поэтому это лучший вариант проверить идею на востребованность.

Главный недостаток Chrome extension’ов, на мой взгляд, — отсутствие шаблонов. Есть обходной путь  - внедрить JS, который подтягивает и инжектит необходимые templates. Но сейчас появился JSX и шаблонные строки, поэтому всё стало значительно приятней.

Вторая проблема — это корректное слежение за изменением URL и инжект готового HTML, так как YouTube использует spfjs. Поэтому сейчас применяется Gistс использованием setInterval, что мне не очень нравится.

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

Также есть проблемы с синхронизацией между устройствами. Chrome extension предоставляет chrome.storage.sync, но с большими ограничениями, поэтому этот storage использовать для хранения больших данных нельзя. Была идея уменьшить и оптимизировать данные, которые хранятся, за счет увеличения запросов к YouTube API, но со временем хранилище всё равно быстро заполняется. Поэтому решил в дальнейшем сделать авторизацию и синхронизировать данные на любой cloud NoSQL database.

Результаты

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

Буду рад поддержке проекта на ProductHunt, а также любым корректным отзывам и предложениям.

Я начал работать с фреймворком 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 (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 вам поможет.

Это была обзорная статья, но я регулярно публикую технические блоги об Ангуляре у себя на сайте. Я слышал, что вышел перевод на русский язык первого издания нашей книжки по Ангуляру, однако я советую взять второе издание здесь. А промокод «fcfain» снизит цену на 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 и многие другие.

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

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

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

Project Management

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

Полезно для всех, но обязательно для ПМов. Советы по персональной эффективности от Илона Маска.

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

Стоит ли инвестировать в DevOps?Мировая статистика за 2017 год в отчете.

10 things I love about managing projects.

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

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

Коллеги ПМы, если вдруг кто никогда не слышал про Vasa story — иллюстрацию провального управления изменениями, это видеодля вас.

Статья от Ивана Селиховкина о шести направлениях роста менеджера.

Taras Fedoruk начал вести блог на медиум, что есть очень здорово. Читаем дебютную статью о том, почему ПМ меняет работу, и ждем продолжения!

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

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

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

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

Внедрение Scrum’a технарем: реальный опыт, подводные камни, tips&tricks

Есть проблемы с Daily Scrum?Почитайте gap analysis, может, узнаете свои симптомы и воспользуетесь советами по улучшению.

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

«It may be tempting to collect metrics on every aspect of the work, but that often results in just another data management headache. Resist the urge and don’t make this more difficult than it needs to be».

Scrum Checklistот отцов-основателей: Джеффа Сазерленда и Хенрика Книберга

5 Books I’ll Read to Facilitate Software Engineering Practices

Несколько толковых Agile quotes:

«Change your mindset, and you’ll change your behavior. Change your behavior, and you’ll change their behavior. Change their behavior, and you’ll change their performance. It’s that simple».

Brian Souza «Weekly Coaching Conversation»

Fun

Время скупать jiracoin’ы...

Stand Up time!

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

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

Більшість респондентів — спеціалісти з досвідом у галузі понад 3 роки. 35% опитуваних мають стаж більше 5 років. Новачків (без досвіду та до 1 року) — тільки 18%.

Скільки у вас років досвіду в ІТ?

Лише кожен 10-йчитач має свій блог. Окрім DOU аудиторія ще заглядає на Хабр (162 анкети), AIN (45), Medium (34), Ebanoe (27), Stackoverflow (26), Geektimes (24). Ці ресурси респонденти згадували найчастіше.

Чи є у вас свій блог?

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

Чи хотіли б ви опублікувати статтю на DOU?

Читачі оцінили Стрічку на 7 балів з 10. Ми не вимірювали індекс підтримки споживача (NPS), бо не мали цього за мету і тому не формулювали питання за цим методом. Нам було важливо побачити вашу оцінку та побудувати правильний курс для розвитку.

Оцініть, наскільки вам цікаво читати розділ Стрічка?

1 — не цікаво, 10 — дуже цікаво

Читачі віддають перевагу аналітиці, технічним статтям та матеріалам про кар’єру і професійний розвиток. До речі, 24% респондентів цікавляться фотозвітами :)

Що вам подобається найбільше у Стрічці?

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

Telegram-канал редакції

Також ми запустили свій 12-й Telegram-канал — @dou_editors. Так, у DOU їх вже дюжина. У попередніх одинадцятипонад 30 тис. підписників. Але новий канал для редакції буде особливим.

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

Обіцяємо вкладати душу в цей проект, приєднуйтесь!

Побажання щодо наповнення каналу пишіть у коментарях.

В выпуске: DDoS на GitHub, хайлоад Elasticsearch, Envoy, Kubernetes и Мартин Фаулер.

В мире появилось что-то новое

Custom Vega Visualizations in Kibana 6.2
В Кибану завезли какие-то сумасшедшие визуализации! Ну вот очень крутые!

First Beta Version of Kubernetes 1.10 is Here
Появился Kubernetes 1.10 в статусе beta. Это для тех, кто любит крутить и щупать раньше всех. Развлекайтесь!

Announcing Gloo: The Function Gateway
Новая штука: Gloo — это ингресс для Envoy Proxy.

Like cURL, but for gRPC: Command-line tool for interacting with gRPC servers
Если у Вас gRPC (ну а вдруг?), то эта тулза будет супер полезна.

GPUs in Kubernetes Engine now available in beta
Теперь можно крутить Kubernetes в GCE на gpu инстансах! Как-то я непонятно завернул. Если у вас есть задачи, для которых нужен GPU и Kubernetes — то это ваш кейс.

Небольшая нагрузка

Elasticsearch Performance Tuning Practice at eBay
Как eBay эластик тюнили: > 5 TB данных, 2000 нод, > 4 000 000 поисков за день на отдельных кластерах. Крутой хайлоад!

February 28th DDoS Incident Report
Постмортем от GitHub после огромной DDoS атаки. Крутые перцы!

GitHub немного пригрузило

Наставничество от больших ребят

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

How to know if Kubernetes is right for your SaaS
Как понять, подходит вам кубер или нет? Мое мнение — нужно двигаться от проблем и запросов. Если технология решает больше проблем, чем порождает — есть смысл смотреть в ее направлении. Бытует мнение, что Kubernetes и маленькие проекты — вещи не взаимосвязанные. Но в то же время, если вы хотите деплои, ролбеки, балансеры из коробки — то даже для маленького проекта Kubernetes будет в тему. И еще такой момент: рано или поздно вам придется его внедрять, так почему не начать прямо сейчас?

HTTP Analytics for 6M requests per second using ClickHouse
«ClickHouse не тормозит» © ClickHouse core developers. В Cloudflare поверили в этот тезис и сделали аналитику на его основе. Если вам нужна крутая и быстрая аналитика — статья будет полезной.

Building Ambassador, an Open Source API Gateway on Kubernetes and Envoy
Набор топовых продуктов и архитектурный взгляд на то, как качественно готовить Ambassador. Это как Tesla Model X, только в DevOps.

Можно улучшить в вашей компании

Testing of Microservices
Статья о тестировании микросервисов в Spotify. Если бы у всех был подобный подход — жить было бы легче!

Пирамида тестирования (внезапно!)

Secure Access to 100 AWS Accounts
Есть хорошая тема — дробить продукты на разные AWS аккаунты. Ребята разделяли еще больше: выносили каждое окружение в отдельный аккаунт. И в результате столкнулись с проблемой — это же нужно как-то менеджить! В двух словах, они описали политики в Terraform и добавили SAML через Okta провайдер. Получилось интересно. Если это ваша проблема — есть готовое решение.

Нудная теория

What I Talk About When I Talk About Platforms
Мой любимый Мартин Фаулер! Вы знаете, что я очень люблю его цитировать. В данной статье он рассматривает понятие «платформы» и что именно он подразумевает под этим термином. Очень интересно, рекомендую!

A Practical Introduction to Container TerminologyЕсли вы ничего не знаете про «контейнерные словечки» — то это то, что нужно! А если знаете, то можно хорошенько структурировать это у себя в голове. Рекомендую засесть на вечер, и полностью разобраться со всеми терминами и подходами, описанными в статье, — это будет хорошее конкурентное преимущество.

The quest for availability in the cloud
Автор рассматривает все аспекты доступности сервиса: SLA, SLO, SLI. Это цикл статей, достаточно качественных и концептуальных. Тут можно найти ответ на вопрос «Сколько девяток на самом деле нужно моему кастомеру?»

Девопс месяца: Антон Кошевой

Новая рубрика — Девопс месяца: Антон Кошевой. Выбирал лично я, из одного кандидата.

Антон любит наваливать по бездорожью на Mitsubishi Outlander 4wd, занимается разным экстримом (кайт, вейкборд, тайский бокс) и вообще очень приятный и дружелюбный человек. «Делать все идеально» — это про него. Будь как Антон!

Антон был Head of Technical Operations в Grammarly, помогал по контракту с Swiftype, а в прошлом году ездил на O’Reilly Velocityконференцию. И еще он — почетный член UkrOps клуба. К тому же, молодой папа.

Лайфстайл

«Чувак! Почему так давно не было дайджестов? Что мне делать?» — вы спросите. Куча всяких штук навалилась в последнее время. Например:

• я создал свой личный телеграм-канал ДевОпс Инженер, там уже круто, а будет еще круче;
• мы (DevOps команда) в MacPaw вписались в кубер и зарелизили в нем новый продукт;
• меня заставили выступить на Kyiv DevOps Community (передаю привет Диме Лавриненко);
• ездил с девушкой в Варшаву пше отдохнуть;
• сегодня (17.03) выступаю в Одессе на местном DevOps митапе, никто не заставлял, но я думал тепло будет — а тут дубак −100500 (передаю привет Игорю Бородинуи Вове Цапу);
• немного коцнул чужую тачку на парковке (виноват, 100 год тюрми).

Заключение

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

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». Почитайте, эта книга поможет вам избежать многих ошибок в работе с командой.

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

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

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