[Путь стажера — постоянная рубрика, в которой начинающие IT-специалисты делятся своим опытом стажировок как в иностранных, так и в украинских компаниях. Если вы хотите рассказать свою историю, пишите на vlada@dou.ua]

Привет, меня зовут Никита. Я студент Киевского политехнического института, учусь на 4 курсе ФИВТа. Среди моих интересов — программирование, новые технологии, а также спорт (плавание и бокс). На стажировку в MacPaw я подавался два раза и сегодня хочу поделиться своим опытом, разочарованиями и выводами, которые сделал за два последних года.

На момент подачи заявки на стажировку в 2016 году у меня не было коммерческого опыта в iOS разработке. Но около полугода до этого я самостоятельно изучал стек технологий Cocoa Touch, языки Swift и Objective-C, пытаясь написать несложные приложения. К тому же получил неплохие базовые знания в университете: математика, алгоритмы, параллельное программирование и опыт написания объемных работ на C++ и Java.

О стажировке в MacPaw я узнал через социальные сети — увидел в паблике «IT KPI» пост о летних стажировках в Киеве. Тогда я буквально горел идеей получить любой опыт работы, поэтому и решил податься на направление Cocoa Development. Не буду скрывать, в первую очередь я ожидал получить знания и перенять опыт менторов, чтобы стать более востребованным разработчиком на рынке. Я также хотел узнать, как все-таки создать целостный продукт и увидеть, как это все работает вживую. У меня было свободное лето, так что я решил, почему бы не провести его в продуктовой компании, познакомиться с новыми людьми и сделать что-то крутое.

Отбор

Отбор на MacPaw Summer Internship 2016 состоял из двух этапов:

1. Заполнение онлайн-формы регистрации (общие вопросы, вопросы на логику, мотивацию и тестовое задание по выбранному направлению). Важно было подать заявку до установленной даты (тогда это было 9 мая).

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

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

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

2. Собеседование с ментором и HR-специалистом в офисе компании.

Собеседование назначили на среду, 25 мая, на 11:45. Встреча длилась около часа и делилась на две части — беседа с двумя менторами по технической части и разговор с HR.

Мы начали с базовых технических вопросов (алгоритмы сортировки, обход дерева, общее понимание ООП и применение паттернов), далее углубились в стек технологий, обсуждая особенности Objective-C и принципы работы с Cocoa Touch. После перешли к задаче на алгоритмическое мышление и только потом начали рассматривать мою программу. Ребята задавали вопросы, как я могу улучшить тот код, который написал. Я ответил где-то на половину вопросов менторов, но с трудом понимал, как можно улучшить приложение, так как это была одна из первых моих программ на таком стеке технологий. Сейчас я смотрю на нее и понимаю, что код очень далек от идеала.

Разговор с HR оказался тяжелее, чем собеседование с разработчиками. Тогда я до конца не осознавал, какое значение для меня может иметь работа в компании, а гнался исключительно за опытом, поэтому и не подготовился как следует. Мне задавали простые, понятные и очевидные вопросы: «Какие есть продукты в компании? Почему я хочу здесь работать? Чего я для себя хочу?». Также достаточно подробно спрашивали о том, как я работаю в команде и прочее. Хотели понять мои сильные и слабые стороны, чтобы я больше о себе рассказал.

Разочарование

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

Год между стажировками 2016 / 2017

Началось лето, я находился в состоянии фрустрации, поскольку уже успел настроить себе планов, что я буду работать в MacPaw. Но мне в любом случае нужно было набраться опыта и я решил все же найти работу. Мне представилась возможность заняться аутсорс-проектом. Работал удаленно, в команде с back-end разработчиком из США. Мы разрабатывали программное обеспечение для кассового аппарата на планшете — iPad. Это был серьезный опыт, который включал работу с запутанной логикой и всевозможными сторонними девайсами: от кардридеров до принтера для чеков. Это помогло мне стать более уверенным в своей области и немного подтянуть английский.

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

Весной мне снова попалось на глаза объявление о стажировке в MacPaw, но уже 2017 года. Глаза загорелись и я принял решение податься еще раз. Я понимал, что отбор будет еще жестче и не очень надеялся пройти на стажировку. Но все же решил попробовать.

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

В этот раз я решил серьезно подготовиться и к разговору с HR. Нашел вопросы в интернете и постарался ответить на них прежде всего для себя. После такой подготовки я был уверен в своих силах и надеялся на хороший исход собеседования.

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

Стажировка 2017

В первый рабочий день я познакомился в офисе с другими 6-юстажерами (2 человека на Mac Development, 1 — Win Development, 1 — Public Relations, 1 — Copywriting, 2 — Product Marketing). Непосредственно на направлении Cocoa Development нас было две — я и Настя Старченко, тоже студентка ФИВТа КПИ.

Вся команда в сборе. Стажеры MacPaw Summer Internship 2017

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

Мне повезло, и меня сразу направили в команду Setapp. Это новый продукт компании, над которым работает более 50 человек. Из дополнительных плюсов — проект написан на двух языках: Swift и Objective-C, что позволяло получить больше опыта. Также команда в то время выбирала новую Agile-методологию, и я мог увидеть проблемы в коммуникациях, принять участие в их решении и ощутить на себе все прелести технологии Kanban. Работать мне нужно было по 6 часов в день, но, конечно, за это время я не удовлетворял свой интерес и часто засиживался на полный рабочий день.

Мой обычный день на стажировке выглядел примерно так. Я приходил, обсуждал планы с командой. Потом приступал к решению своей задачи, изучал код, копался в документации. Стоит отметить, что для меня никто не выделял отдельных тасок, придуманных заданий, как я этого ожидал. Задачу нужно было взять из приоритета беклога. Далее, после тщательного просмотра моими менторами и прохождения всех кругов тестирования, моя работа шла в релиз. Из примеров — поправить поведение кнопки, добавить логику для возможности тестирования, написать миграцию Core Data. Иногда я пытался решить задачу очень-очень прикольно, но мне говорили, что все решается проще. Или наоборот, что нужно было просто применить более common-practice решение, убрав костыли.

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

Бенефиты

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

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

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

Мое рабочее место находилось прямо напротив MacPaw Museum, экспозиции винтажных компьютеров Mac

Финальный проект

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

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

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

В реализации возникали трудности. Когда делали прототип и модель монетизации, потратили тратили кучу времени на споры, ссорились и мирились, иногда звали на помощь скрам-мастера.

Для реализации проекта нам нужны были дизайнер, front-end и back-end разработчики. Пришлось идти на существенные компромиссы: Win Dev ушел в разработку API, заменили веб-приложение на iOS, а задачи по дизайну взяла на себя стажер направления PR. Мы работали над проектом по 10-12часов в день. При этом хочется сказать огромное спасибо проджект-менеджерам и менторам стажировки, которые были доступны 24/7, выделяя время на наше детище. Мы допустили кучу ошибок, из которых вынесли ценный опыт: сделали 90 слайдов презентации, половина всего времени хакатона ушла на архитектуру проекта, много лишних сил и времени потратили на выбор нейминга. Последние 10 дней остались в памяти самыми яркими за весь период стажировки.

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

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

Результат

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

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

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

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

Советы стажерам

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

Ответьте на ключевые вопросы HR для себя.Главное понять, что вы вообще ищете в этой стажировке и быть откровенным с самим собой. И, конечно, быть честным на собеседовании. Если вы что-то скроете, то стажировка не принесет пользы ни вам, ни компании.

Получайте удовольствие. Во время стажировки нужно брать максимально все, что вам предлагают. Используйте все, что пригодится для вашего опыта и дальнейшего развития. У вас есть такая возможность — почему бы ею не воспользоваться? Дедлайн заполнения заявки на MacPaw Summer Internship 2018 — 6 мая.

Мы узнали у IT-компаний их потребность в trainee/junior специалистах и источники поиска молодых сотрудников в 2017 году.

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

Ниже под джуниорами мы подразумеваем специалистов без опыта работы или с опытом менее 1 года (в некоторых компаниях такие специалисты называются Trainee или Intern).

Как и в прошлом году, 76% новичков начали сотрудничество с компаниями от 800 специалистов.

46% джуниоров нашли работу в ТОП-3 крупнейших IТ-компаний Украины — EPAM, SoftServe, Luxoft. 3% от общего количества принятых специалистов было уволено в течение первого месяца после найма. Не увольняли джуниоров 47% опрошенных IТ-компаний.

Лидерами относительного прироста по джуниорам стали GlobalLogic (на 95% больше начинающих специалистов, чем в 2016 году), Sigma Software (на 75%), а также Intetics — в компанию приняли в 11 раз больше новичков, чем в 2016-м (с 7 до 76 человек).

В этом году мы узнали у компаний, в каких городах они нанимали специалистов. Больше всего джуниоров нашли работу во Львове (30%), далее идут Киев (27%) и Харьков (19%). Высокая доля Львова связана в первую очередь с активностью SoftServe — более 50% джуниоров начали сотрудничество именно со львовским офисом компании. В то время как найм других крупных IТ-компаний практически одинаково разделился между Киевом, Харьковом и Львовом.

Как и в прошлом году, самыми популярными IT-направлениями в разрезе найма остаются QA, Java, C#/.NET. Также в 2017 году почти в два раза больше приняли C++ специалистов — 216 против 111 в 2016-м.

Более 50% джуниоров вошли в IТ через внутренние курсы и учебные центры при компаниях. Также популярными источниками найма остаются job сайты и рекомендации сотрудников. Ниже сводная таблица с разбивкой по компаниям и источниками найма.

Инфографику подготовил Игорь Яновский

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

Всем привет, меня зовут Михаил Боднарчук. Пишу эту статью, пока нахожусь в Остине, штат Техас. Здесь выступаю с докладом на конференции Longhorn PHP. При этом сам я живу в Киеве и да, я не пожалел 16 часов своего времени, чтобы добраться сюда. Билет в обе стороны оплачивает приглашающая сторона, ровно как и проживание. А если так — то почему бы и не съездить, раз приглашают?

Доклад на Bulgaria PHP 2016

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

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

Зачем мне это

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

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

Как перестать бояться и стать докладчиком

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

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

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

В Европе очень много митапов и конференций проходят на английском при том, что никто на нем в быту не говорит (шутка про Брексит № 2). Поэтому у меня просьба к сообществу: раз уж мы идем в Европу, не забывайте её построить у себя. Поощряйте доклады на английском. Толерантнее относитесь к уровню английского у спикера. А лучше — поддержите его. Если мы хотим, чтобы к нам приезжали и делились опытом, то создайте для этого благоприятную атмосферу. По своему опыту скажу — гораздо комфортнее выступать в тех регионах, где все говорят на английском и где нет разделения на «чужие англоговорящие спикеры» и «наша местная братва». Опять таки, в ваших же интересах улучшать свой английский. А для этого не стесняйтесь говорить на нем.

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

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

PHPCE 2017

Как искать конференции

Тут работает обратный принцип Голливуда: это вы должны искать конференции, а не конференции вас. Заходите в Гугл и ищите слово «CFP» по вашей экспертизе: CFP JavaScript conference, CFP PHP, Python и т. д. CFP расшифровывается как «Call For Papers» — это форма подачи докладов. Обычно она открыта для всех желающих и закрывается за несколько месяцев до начала конференции. Просмотрите, какие конференции ищут докладчиков и когда у них дедлайн.

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

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

Какие доклады готовить

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

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

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

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

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

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

Экскурсия для спикеров в Варшаве. PHPCE 2017

Как готовиться

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

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

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

Так что же делать на конференциях

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

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

Что делать после конференции

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

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

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

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

TL;DR;МНОГА БУКАФ;О ЧЕМ СТАТЬЯ?

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

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

[Андрій Трофімов — Director, Software Engineering в EPAM, MBA, PMP. В ІТ з 2000-гороку. Працював як System Administrator, Delphi, PHP, Java розробник та тімлід, QA manager, Project manager. З 2005-гороку сфокусований на general management. Цікавиться літературою з управління та розвитку]

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

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

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

Robert Anton Wilson «Quantum Psychology: How Brain Software Programs You and Your World»

У російському перекладі — Роберт Уилсон «Квантовая психология. Управление сознанием. Практично, остроумно, увлекательно»

Книга написана в жанрі соціальної психологічної фантастики із властивим автору почуттям гумору. Деякі називають книгу матеріалістичною, інші — містичною. Читачі поділяються на тих, хто вважає Уілсона генієм, та тих, хто не зміг дочитати твір до кінця. У будь-якому разі книга, безсумнівно, варта уваги. Вона докорінно змінила мій підхід до мислення та комунікації з людьми. Вітання тим, кому так само сподобався термін «sombunall = some but not all» :) Щонайменше ви навчитеся уникати непотрібних узагальнень (generalization) та висловлювати думки від власної особи (наприклад, «я вважаю, що цей код — поганий» замість «цей код — повна нісенітниця»). Це дуже допомагає уникати неконструктивних суперечок.

Robert I. Sutton «The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t»

В українському перекладі — Роберт Саттон «Мудакам тут не місце. Як вижити в офісних джунглях»

У російському перекладі — Роберт И. Саттон «Не работайте с мудаками. И что делать, если они вокруг вас»

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

Patrick M. Lencioni «The Ideal Team Player: How to Recognize and Cultivate The Three Essential Virtues»

В українському перекладі — Патрик Ленсіоні «Ідеальний командний гравець. Як розпізнати та розвинути три основні якості»

У російському перекладі — Патрик Ленсиони «Идеальный командный игрок: как распознать и развить три ключевых качества»

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

Жаков Каллистрат, Поварнин Сергей «Логика. Искусство спора»

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

Neal Stephenson «Seveneves»

У російському перекладі — Нил Стивенсон «Семиевие»

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

На завершення — «родзинка». Окрім книг, рекомендую звернути увагу на блог Дениса Петеліна «Факел», де він у легкій, доступній формі ділиться власними менеджмент-секретами.

Во всем мире микросервисы — уже практически мейнстрим. В .NET мы только начинаем двигаться в этом направлении. Благодаря усилиям «Майкрософт» в последние несколько лет у нас появилась возможность запускать .NET в контейнерах Windows. У нас есть платформа .NET Core, которая позволяет делать это под различными версиями Linux. Соответственно, мы теперь можем запускать сервисы и микросервисы в контейнерах.

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

Преимущества и недостатки микросервисов

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

Ключевые преимущества микросервисной архитектуры:

• Если у вас обширный домен и бизнес хочет развиваться сразу во многих направлениях, то микросервисная архитектура позволит создать отдельные команды, каждая из которых занимается разработкой своих микросервисов. Вы сможете развивать решения параллельно, не сталкивая разработчиков лбами друг с другом.
• Каждый микросервис можно разворачивать независимо. Если одна из команд закончила разработку своей функциональности, она может запустить ее в production. При этом бизнес уже получит какие-то преимущества, пока другие команды доделывают свою часть функциональности.
• Масштабируемость. Каждый из сервисов можно запускать во многих экземплярах. Если у вас есть трудности только в одном высоконагруженном месте, то можно именно это место размножить и горизонтально масштабировать.
• Каждый из микросервисов по отдельности — намного более простое решение, чем общая монолитная система. В крайнем случае, если конкретный микросервис перестает удовлетворять конкретным требованиям бизнеса, его можно выбросить и переписать заново. Это не будет настолько сложным и дорогостоящим, как если бы вам сказали переписывать монолит, потому что вы ошиблись в выборе технологии.
• Возможность применять разные технологии. Если у вас есть специализация в конкретных сервисах, например для GPU в высоконагруженных вычислениях, вы можете написать этот сервис на C++ или библиотеке, которая работает непосредственно в GPU. Если другие сервисы .NET вам не подходят, вы можете написать front-end на Node.js и т. д. У вас появляется возможность выбирать различные технологии. Но это не означает, что вы должны строить у себя «зоопарк». Стандартизация должна быть, но если есть достаточно оснований поменять технологию, вы можете это сделать.

Среди недостатков микросервисной архитектуры можно выделить следующие:

• Усилия, которые нужно затрачивать несколько раз для решения одних и тех же задач. У каждого сервиса появляется свой CI, свое независимое тестирование. Существует множество задач, которые в мире монолита делаются один раз, и про них забывают, тогда как в мире микросервисов к этим задачам нужно постоянно возвращаться. К примеру, если вы приняли решение сменить подход к развертыванию решения, то его придется менять для каждого из микросервисов.
• Все вместе микросервисы будут более сложными для разработки, чем монолит. Есть очень хорошая фраза: «Если вы не можете построить хорошо структурированный монолит, то кто сказал, что микросервисы вам помогут?» («Distributed big balls of mud»). И это действительно так, потому что микросервисная архитектура на самом деле более сложная, чем монолит. В монолите у вас все связано: вы скомпилировали и убедились, что одна часть подсистемы, по крайней мере на уровне контрактов, взаимодействует с другой частью подсистемы. В микросервисной архитектуре приходится проверять интеграционными тестами, что контракты соблюдены.
• Увеличение операционных расходов. У вас может быть десяток, а то и сотня микросервисов. С каждым их этих микросервисов нужно поддерживать свои процессы CI, свои процессы развертывания. За каждым из сервисов нужно следить независимо: сервис может упереться в ограничение по памяти, связь с другим сервисом может оборваться и автоматически не восстановиться, могут быть утечки памяти, дедлоки и т. д. Намного усложняется процесс сопровождения вашего решения: вместо одного-двух или трех процессов приходится следить за сотнями.
• Целостность контрактов и данных. Каждый микросервис работает со своим хранилищем, данные не интегрированы между собой: нет внешнего ключа (foreign key), и, соответственно, намного сложнее сохранять целостность данных.
• Поскольку каждый из сервисов можно разрабатывать независимо (преимущество), точно так же независимо он может и поменять свой контракт. Хорошо, если мы заметим это во время интеграционного тестирования. Хуже, если мы заметим это в production.

Автоматизация всех процессов

В рамках микросервисов непрерывная интеграция (Continuous Integration или CI) выглядит немного по-другому: на выходе конкретного микросервиса должен получиться какой-то пакет, артефакт либо контейнер, который универсальным образом развертывается в production. Если Node.js будет собираться совершенно по-другому, чем .NET Core, Java и другие решения, то разворачивание таких решений в production усложняется. Поэтому на выходе микросервисов должен быть универсальный пакет, который можно было бы развернуть в любом окружении.

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

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

В рамках использования Continuous Integration с микросервисами мы ожидаем повторяемости: если у вас есть некий коммит и вы запустили дважды одну сборку (build) для этого коммита, вы ожидаете одинаковый результат. Отличие состоит в том, что в монолитах эти сборки создаются для всего решения часто. Если на агент сборки (build agent) вы установите обновление (обновление ОС Windows, установка новой версии .NET Framework) и из-за этого поломается сборка, вы сразу это заметите, устраните неисправность и продолжите работу.

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

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

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

Контейнеры

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

Основная особенность контейнеров — это то, что они являются неизменяемыми (immutable). Если вы создали контейнер один раз, он сохраняет полный слепок файловой системы. В любой момент, независимо от среды запуска, это будет полностью идентичная копия сервиса, включая ОС и все необходимые вам dll-библиотеки.Такой контейнер будет работать везде одинаково: на машине разработчика, в тестовом окружении или в production.

Очень часто контейнеры пытаются сравнивать с виртуальными машинами. Надо понимать, что между ними существует принципиальное различие. Принцип работы виртуальных машин: есть некая хост операционная система (далее — гипервизор), которая абстрагирует хост ОС от виртуальных машин, и образы, в каждом из которых работает сама ОС, а в ней файловая подсистема и ваше приложение. Обычно ОС на порядок больше по размерам и по потреблению ресурсов, чем непосредственно приложение, которое там работает. Использовать такую архитектуру для микросервисов — очень избыточно. Когда Azure только начинал развиваться, у них было решение PaaS Application Services. Запуская на этой платформе небольшой веб-сайт в трех экземплярах, необходимо было физически запустить три виртуальные машины, на которых процессор был загружен на 1 %, а 60 % оперативной памяти забирала на себя ОС.

Рисунок 1. Сравнение виртуальных машин и контейнеров

Как работают контейнеры? В контейнерах есть хост ОС, поверх которой работает подсистема контейнеризации (container engine). Самая популярная сейчас подсистема контейнеризации — Docker. Далее сама подсистема абстрагирует родительскую ОС от контейнеров. Каждый из контейнеров видит, что он работает в своем маленьком окружении. При этом он продолжает выполнять свои действия непосредственно в хост ОС. Это и есть ключевое преимущество, поскольку мы не тратим никаких ресурсов ОС внутри виртуальной машины. Но также это и особенность, которую нужно понимать: если конкретное приложение требует определенных действий по настройке в ядре ОС, эти настройки могут быть несовместимы с другими контейнерами, которые работают непосредственно на этой машине. Например, чтобы Redis обеспечивал низкую задержку (latency), есть рекомендацияпо настройке параметров в ядре Linux (Transparent huge pages must be disabled from your kernel). Такие параметры могут быть несовместимы с другими контейнерами, для которых они имеют другое значение.

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

Ключевая особенность контейнеров — слои файловой системы. По умолчанию в Docker используется AuFS — файловая система, которая основана на слоях. Каждый слой является immutable, а следующий слой строится как дельта от предыдущего слоя. Это можно рассматривать по аналогии с коммитами: у нас есть предыдущий коммит, мы внесли изменения и сделали новый коммит. При этом в новом коммите хранится только дельта по отношению к предыдущему. Здесь такая же ситуация: есть предыдущий слой, поверх этого слоя мы добавляем новый файл в нужную папку. В следующем слое хранится только этот файл. В программировании также есть объекты immutable, которые можно легко совместно использовать между разными процессами и потоками (threads). Мы не боимся, что кто-то может случайно поменять этот объект. Такая же ситуация и со слоями: если у нас разные контейнеры используют общие слои, эти слои не нужно сохранять независимо. Один слой может обслуживать сразу несколько контейнеров.

На рисунке 2 показан рецепт построения Docker-контейнера.

Рисунок 2. Слои контейнера

Читать снизу-вверх (в самом верху находится самый последний слой контейнера).

Рассматривая рисунок 2 более подробно, мы видим операции, которые проводятся над контейнерами. Где-то внизу есть базовый контейнер. Следующая операция — добавление переменной окружения (новый слой). Еще добавление нового окружения (еще переменная окружения) и еще один новый слой. После этого мы запускаем команду на выполнение, которая скачивает что-то из Интернета и выкладывает в каких-то папках — еще один слой, который добавляет 50 МБ и т. д.

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

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

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

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

На рисунке 3 наглядно представлено повторное использование слоев (layers reuse).

Рисунок 3. Повторное использование слоев

Представим ситуацию, что на определенной машине нужно запустить несколько экземпляров одного образа. На рисунке 3 мы видим пять экземпляров, пять контейнеров для одного образа Ubuntu. Поскольку слои являются immutable, каждый их этих контейнеров ссылается на один и тот же образ. Они не мешают друг другу, так как все эти слои доступны только для чтения (read-only). Если при выполнении контейнеру нужно будет что-то записать у себя локально, запись будет осуществляться в тонкий слой непосредственно внутри контейнера. В этом случае применяется логика копирования при записи (Copy-On-Write). Если во время выполнения контейнер захочет изменить существующий файл, который расположен в одном из этих слоев, то этот файл скопируется в слой контейнера, и дальнейшее редактирование будет происходить уже в этом слое.

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

Принципы работы контейнеризации

Рассмотрим принцип работы контейнеризации на примере .NET Core (см. рис. 4).

Рисунок 4. .NET Core для Web API приложения

Для демонстрации я добавил проект .NET Standard с контрактами и обычное ASP.NET Core Web API приложение, которое ссылается на него. После этого я включил поддержку Docker на проекте средствами Visual Studio. Dockerfile — рецепт, в котором описан способ построения нового образа контейнера для нашего проекта. Несмотря на простоту демонстрационного примера, в получившемся Dockerfile достаточно много чего происходит. Чтобы потом его модифицировать и улучшать, важно для начала понимать, почему автоматически сгенерированный файл имеет именно такой вид. В данном рецепте объединены два аспекта:

1. Возможность переиспользования закодированных слоев от предыдущей сборки Docker-контейнера. Как только поменялся какой-то слой контейнера, все последующие слои уже не смогут быть переиспользованы из кеша. Поэтому то, что чаще всего меняется, опускается вниз Dockerfile, а то, что наиболее стабильно, вынесено наверх. Таким образом, максимальное количество слоев можно будет взять из кеша.
2. Уменьшение результирующего Docker-контейнера. Поскольку каждая операция приводит к новому слою в контейнере, то при копировании файлов или генерировании файлов во время компиляции это все сохранится в слое: bin, obj и т. д. Следующей операцией может быть удаление этих файлов. Но при этом в предыдущем слое все эти файлы уже останутся, так что удаление файлов не повлияет на размер контейнера.

Сначала определяется базовый контейнер, на основании которого будет строиться окончательный образ. В нашем примере это базовый слой — aspnetcore вер. 2.0, в котором устанавливается рабочая папка /app и внешний порт: 80. Этот базовый слой умеет запускать скомпилированные ASP.NET Core приложения, но не билдить их.

После этого идет непосредственно описание процесса сборки нашего проекта. Для этого мы используем другой образ, в котором есть SDK и который позволит запустить компиляцию проекта. Устанавливаем рабочую папку внутри контейнера /src и копируем туда только файлы солюшена (.sln) и проектов (.csproj). Почему только файлы проекта? Потому что они намного реже меняются, чем все остальные cs-файлы. Операция dotnet restore достаточно тяжелая и может выполниться только на основании csproj-файлов. Соответственно, намного больше вероятность того, что операция dotnet restore будет кеширована, и нам не нужно будет скачивать все nuget-пакеты при создании каждой сборки проекта. Следующая операция уже копирует все файлы проектов. Первая точка (первый параметр) указывает, откуда копировать из source-машины, вторая — куда копировать. Откуда — это контекст сборки. Во время запуска сборки Docker-контейнера мы указываем, из какой папки мы начинаем сборку. Мы копируем все файлы из нашей текущей папки, из которой мы начинали. Поскольку мы указали в качестве рабочей папки /src, то мы скопируем файлы в эту папку. После этого создаем обычную сборку dotnet с версией release и выводом в папку /app.

Мы дали название (alias) нашему контейнеру AS build — временный alias, чтобы можно было создавать связи между разными сборками. Далее мы запускаем dotnet publish в версию release. И последний шаг: за основу мы берем базовый образ, объявленный в самом в начале, копируем из сборки publish папку /app. В ENTRYPOINT указываем, что нам нужно вызывать. Таким образом, если мы запустим этот рецепт на выполнение, получим минимальный образ, из которого мы начинали, и в него скопируем только финальные опубликованные dll-библиотеки.

Как это выглядит при запуске из консоли? На рисунке 5 показано, как я запустил мою сборку дважды.

Рисунок 5. Запуск операций из кеша

При запуске указанного выше рецепта все операции используются из кеша на основе существующей сборки. Все слои могут повторно использоваться из кеша без выполнения самой сборки. Запустив дважды сборку Docker на одних src-файлах, мы за секунду получаем финальную сборку. Если какие-то cs-файлы изменились, то будут переиспользованы все операции вплоть до dotnet restore. И по-новому слои будут строиться, только начиная с копирования всех файлов.

На рисунке 6 показано, как это выглядит на уровне слоев.

Рисунок 6. Полученный контейнер, развернутый по слоям

Самые нижние слои — это слои Майкрософт (можно видеть операции, в результате которых получились эти слои): начиная от базовой ОС, из которой добавляются файлы в контейнер, далее Майкрософт добавляет/устанавливает свои слои и проставляет окружение. Дальше начинаются мои финальные операции. Весь контейнер будет занимать суммарно 300 МБ. Но если на хост-машине будут запущены несколько разных контейнеров, основанных на базовом образе aspnetcore вер. 2.0, то все эти слои будет использоваться повторно, и каждый контейнер будет добавлять только непосредственно свои файлы, как в нашем случае — 306 КБ. Если запустить образ и посмотреть его размер, вы увидите, что это минимальное решение весит 300 МБ. Не нужно пугаться: ваш слой занимает лишь маленькую часть всего образа.

Дальнейший запуск контейнеров в production

«Everyone gets upset when a kitten dies. On cloud platforms no one hears the kitten dying»

(«Cattle vs Kittens»)

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

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

На рисунке 7 приведен набор технологий для Docker-контейнеров.

Рисунок 7. Набор технологий для оркестрации контейнеров

В таких технологиях, как Docker Compose, вы все еще работаете со своими серверами — домашними животными, где вы указываете, что на конкретной машине нужно развернуть определенное количество экземпляров своих контейнеров. Существуют технологии, которые позволяют вам запускать контейнеры на личном кластере серверов локально (on-premises). Есть cloud-решения, которые либо используют одно из указанных выше решений для хостинга кластера серверов, либо предлагают индивидуальные решения. Например, у Amazon ECS есть индивидуальное решение Fargate или Amazon EKS Kubernetes — менеджер кластера Kubernetes в облаке. Azure предлагает Kubernetes, Docker Swarm и т. д. У вас есть выбор, на чем запускать эти решения.

Важно! Для возможности масштабирования контейнеров необходимо, чтобы контейнеры или другие исполняемые компоненты понимали, где развернут ваш контейнер. Для этого используется понятие service discovery. В облаке выполняется автоматическая адресация: само облако предоставляет готовое решение. У Kubernetes есть специальное понятие «сервис», где вы создаете сущность под названием «сервис» и указываете, что некое подмножество контейнеров (либо в их терминологии — Pods, которые могут объединить несколько контейнеров) объединены под одним названием. Вы можете использовать это название, чтобы адресовать в режиме балансирования нагрузки или прокси вызов на ваш контейнер.

Выводы

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

Необходимо все по максимуму автоматизировать: начиная от Continuous Integration и заканчивая разворачиванием и сбором логов в production.

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

Всем привет! Уже 9 лет я работаю в Intetics PMом. Первые 8 лет я занимался проектом в области геоинформационных сервисов (ГИС), где мы практически с нуля создавали покрытие качественными геоданными для очень крупного заказчика.

Пару лет назад, когда появилась необходимость повысить эффективности процессов на проекте, мой руководитель подбросил статью о так называемой революции роботов. Автор во всех подробностях рассказывал о том, какие профессии со временем вымрут и почему. Где-то между строк упоминалась технология Robotic Process Automation (RPA). Заинтересовавшись, я начал более глубокое изучение этого направления бизнеса. Очень хотелось взбодрить нейроны, выйти из зоны комфорта и попробовать что-то новое, тем более что AI и ML активно используются в ГИС-сервисах.

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

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

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

Что такое RPA

Robotic process automation — это использование технологий для автоматизации бизнес-процессов. Путем построения алгоритмов на базе специальной платформы, разработчик дает роботу четкие инструкции и настраивает его на выполнение необходимых задач. А при добавлении функционала machine learning инструкции могут стать менее четкими, и у робота возникает определенная свобода действий.

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

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

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

Некоторые считают, что RPA — это синоним AI (artificial intelligence) и ML (machine learning), но это не так. В роботизации робот не может отклониться от заданных правил и четко их выполняет — в этом и заключается суть RPA. Суть технологий AI и ML в том, чтобы обучить машину принимать решения автономно, отходя от установленных инструкций.

Тем не менее, роботизация может включать в себя элементы AI и ML — а это самые «горячие» технологии современного мира IT.

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

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

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

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

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

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

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

Как стать RPA-разработчиком с нуля

При приеме на работу на должность RPA-инженера обращают внимание в первую очередь на алгоритмическое/процессное мышление.

Но есть определенный набор навыков, которые все же нужны, если вы хотите попробовать себя в RPA. Это:

• Знание технологий Microsoft Technology (VB .NET, Windows, SQL Server, Web Services, MS Office) на базовом уровне.
• Понимание правил и принципов анализа, дизайна, разработки, внедрения и поддержки кода в разных контекстах — но будет достаточно и базового уровня (к примеру, просмотра видеоуроков).

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

А если вы хотите в будущем углубиться в такие технологии, как машинное обучение и искусственный интеллект, а также в более «продвинутое» RPA, то, во-первых, нужно изучить наиболее известные платформы и инструменты RPA: Automation Anywhere, UiPath, Blue Prism, Softomotive, Kryon Leo, WorkFusion и т. п. Во-вторых, научиться писать код. В основном рекомендуют изучать Java, также можно выучить Python, .NET, C#. С самого старта уметь кодить необязательно, но если есть желание углубляться в RPA, то придется учить один из языков программирования, чтобы расширить существующий функционал RPA-платформы, если его перестанет хватать.

Возвращаясь к теме обучения RPA с нуля, новичкам рекомендуется пройти курс от академии UiPath. Есть еще один похожий и не менее полезный ресурс — Automation Academy от WorkFusion, там будет нужен курс Automation Essentials, он описывает бизнес-аспекты автоматизации и содержит глоссарий.

У нас также открыт бесплатный курс для новичковпо направлению RPA.

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

• Phil Fersht, Saurabh Gupta «The RPA Bible: your practical & technical guide to RPA»;
• «Rewiring the robots within your organization»;
• Владимир Репин «Бизнес-процессы: моделирование, внедрение, управление».

И напоследок полезная статьяс Хабра.

На начальных этапах этих материалов должно хватить.

Какие перспективы открывает RPA

Несмотря на то, что рынок RPA пока еще невелик, он стабильно растет. К 2020 году расходы на RPA достигнут $1 миллиарда (согласно прогнозамодного из ведущих аналитических агентств мира Gartner), и к тому времени 40% крупных организаций уже будут пользоваться инструментами RPA. Прибавьте к этому востребованность AI и машинного обучения, которые интегрируются с RPA решениями, — и у вас будет представление о перспективах роста в этом направлении.

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

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

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

Конечно, в будущем многие рабочие места, которые существуют сейчас, утратят свою актуальность. Согласно оценкамБюро статистики труда США, к 2026 году сокращение занятости среди 11 профессий с оплатой более 60 000 долларов в год составит более 74 тысяч позиций по сравнению с 2016 годом или около 6,4 млрд долларов в заработной плате. При этом занятость программистов снизитсяна 7,6% с 294 900 до 272 300. Это, конечно, не говорит о том, что уже не стоит учиться на программиста, но как минимум указывает на то, что рынок будет становиться все более конкурентным.

В это время в Индии, где сфера информационных технологий стремительно развивалась в последние годы благодаря аутсорсингу, уже сегодня сокращаетсяколичество вакансий. Похоже, индустрия, которая генерирует годовой доход в размере более 150 млрд долларов и в которой задействовано около 4 млн человек, начинает давать сбой. Пока что масштаб сокращений не ясен. Но согласно исследованиюНациональной ассоциации компаний по программному обеспечению (Nasscom) и McKinsey India за 2015 год, к 2020 году от 50% до 70% нынешних рабочих навыков станут неактуальными.

«Текущие сокращения в аутсорсе (из-за автоматизации) в конечном итоге приведут к сценарию, в котором (только) 30 процентов рабочей силы будут оставаться актуальными», — считает ДД Мишра, директор по исследованиям консалтинговой компании Gartner.

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

Мы больше не будем писать код

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

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

В свою очередь Карлос Е. Перес, автор книги «Deep Learning AI Playbook» пишет: «Лично я не думаю, что разработка программного обеспечения скоро исчезнет. Даже если эта роль эволюционирует — назовите ее „инженер программного обеспечения 2.0“ или „ученым-исследователем 2.0“ или как-либо по-другому — есть пути, которые позволят нынешнему программисту оставаться актуальным».

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

Александр Кондуфоров, Data Science Competence Leader в AltexSoft

Об опасениях

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

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

Об ограничениях машинного обучения

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

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

О роли программистов в будущем

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

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

Артем Чернодуб, Chief Scientist в Clikque Technology, доцент УКУ

Об опасениях

Технологии искусственного интеллекта действительно развиваются, что делает возможным автоматизировать решение задач, которые раньше выполнялись исключительно людьми, homo sapiens. Очень хорошо, что этот высокотехнологичный процесс происходит, в том числе и у нас, в Украине — я навскидку могу вспомнить сервис Flawless AppАхмеда Сулеймана и Лизы Дзюбы для отладки визуального дизайна мобильных приложений, а также магистерский дипломАнатолия Стегния, посвященный генерации кода программ по текстовым описаниям, защищенный в этом году в УКУ.

Об ограничениях машинного обучения

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

В свое время появление Smalltalk и C++ произвели революцию в индустрии за счет использования новой парадигмы объектно-ориентированного программирования. Потом появление визуальных сред Visual Basic и Delphi позволило упростить и ускорить процесс разработки пользовательских интерфейсов, появление Java со встроенным механизмом «уборки мусора» позволило значительно ускорить разработку по сравнению с С++ и так далее. Однако все эти прорывы не снижали количество разработчиков в целом, и оно продолжалось увеличиваться вместе с развитием информационных технологий и их проникновением в повседневную жизнь. Проблемы с трудоустройством появлялись только у тех, кто не хотел идти в ногу со временем, осваивая новые идеи.

О роли программистов в будущем

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

Подобные «умные» алгоритмы в некоторых местах значительно отличаются от «обычных» алгоритмов, и этому нужно специально учиться. Более конкретно, рекомендую следующие 5 книг по машинному обучению, а также онлайн курсы по Data Science/Machine Learning/Neural Networks на Coursera/Udemy/Udacity/Prometheus или поступать к нам на магистерскую программу Data Scienceв УКУ.

Александр Романко, старший научный сотрудник IBM Canada, профессор Университета Торонто

Об опасениях

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

Об ограничениях машинного обучения

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

О роли программистов в будущем

Такие направление в IT как Data Science, искусственный интеллект и аналитика будут долгое время оставаться востребованными.

Андрей Яворский, VP Engineering в GlobalLogic

Об опасениях

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

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

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

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

Об ограничениях машинного обучения

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

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

О роли программистов в будущем

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

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

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

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

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

Олександр Краковецький, CEO DevRain Solutions, Ph.D., CTO ДонорUA

Про побоювання

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

По-перше, в усьому світі катастрофічно не вистачає ІТ-спеціалістів, і з кожним роком ця тенденція стає дедалі гіршою. Передусім не вистачає саме спеціалістів з Machine Learning та Data Scientists. У свою чергу, розвиток хмарних технологій, IoT, блокчейну та криптовалют створив величезний запит на нові професії та навики. Коли все перепишуть на блокчейн, вже з’явиться умовно «новий і покращений blockchain 2.0» і «3.0 beta», і всі одразу захочуть мігрувати туди. Це безперервний процес, допоки людство не стане цивілізацією другого або третього типу, але і після того можливі неприємні нюанси, не пов’язані зі штучним інтелектом, — або метеорит жахне, або Сонце вибухне, або українці знову виберуть якогось пришелепкуватого президента.

По-друге, є гарний вислів Вільяма Гібсона: «Майбутнє вже тут, воно просто нерівномірно розподілене». Десь вже запускають 5G, а у нас і 3G ще досить погано працює. Дуже багато корпорацій до сих пір сидять на Delphi та екселі з макросами, тому необхідність підтримувати ці системи ще довго буде гальмувати впровадження та використання штучного інтелекту.

Про обмеження машинного навчання

Ще не так давно говорили, що з приходом хмарних сервісів адміни стануть непотрібними, а вже через 5 років «нові адміни», або як їх тепер називають — девопси, — мають одну з найвищих зарплат серед ІТ-спеціалістів (маю на увазі США, в першу чергу).

Про роль програмістів у майбутньому

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

Что же делать разработчикам

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

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

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

«Котики» — нова платформа ГО «Канцелярська сотня», де в ігровій формі кожен може виконати нескладне завдання. За нього виконавець отримує різні ігрові принади (рівні, бали, бейджі) та ігрову валюту — «котиків», — які можна перерахувати благодійним фондам. Фонди отримують справжні гроші за курсом котик=гривня. Дуже проста ідея. Шлях до її реалізації зайняв 3 роки...

Задум

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

Наш флагманський проект — «Декларації». Це база декларацій чиновників з пошуковою та аналітичною системами. У квітні 2018 сайт відвідали майже 2 мільйони користувачів. А створений він був наприкінці 2014-го,коли ми отримали величезну (як нам тоді здавалося) кількість відсканованих декларацій доходів та статків українських високопосадовців.

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

Ми побудували зовсім просте рішення та покликали волонтерів. За місяць отримали перші дані у машиночитному форматі і досвід. Дані ми конвертували в бета-версіюdeclarations.com.uaта вперше відкрили статки та доходи ТОП-чиновників України для постмайданого суспільства. А досвід використали для побудови власної краудсорсинг-платформи під назвою «Вулик». За два роки за допомогою цього open source рішення ми змогли оцифрувати майже 20 тисяч декларацій (по 10 сторінок кожна!) та залучити тисячі волонтерів до спільної справи. Цей доволі простий інструмент допоміг перетворити кавалки вільного часу (5-10 хв)людей, котрих ми ніколи в житті не зустрічали, у найбільший на той час набір відкритих даних.

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

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

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

Платформа

У нас вже був робочий та перевірений фреймворк «Вулик», створений на базі стеку Python/Flask/Mongo. Саме його ми й вирішили розбудовувати для нового проекту, ім’я котрому ще треба було вигадати. Почали ми з повного рев’ю наявного коду, бо увесь цей час він розвивався у хакатонному стилі, а потім пропрацював майже 3 роки. Потім мій колишній колега, один з головних розробників «Вулика» Дмитро Гамбаль зробив стовідсоткове покриття тестами ядра проекту та перевів його на Python3. І тільки після цього ми взялися за гейміфікацію.

Але спочатку розберемо власне, як працює наш краудсорсинг. Фреймворк вміє працювати з різними типами завдань (насправді, кожен тип завдання — це невеличкий плагін до фреймворка). Самі завдання завантажуються у систему вигляді батчів — набору довільного розміру, зазвичай у 200-300 завдань.Через те, що ми не знаємо наших користувачів та не можемо бути впевнені у тому, що кожен з них виконає своє завдання без помилок, всі завдання виконують декілька волонтерів, обраних випадково. Так, декларації розпізнають щонайменше три волонтери, а потім їх результати зводяться до загального за допомогою правил та опрацьовуються редактором.

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

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

Гейміфікація

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

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

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

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

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

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

У різний час над проектом працювали:

• Денис Бігус, ідейний натхненник та product owner;
• Дмитро Чаплинський, тобто я;
• Дмитро Гамбаль, що займався розробкою оригінального фреймворка та ігровою механікою;
• Андрій Турик, що закрив питання дизайну та фронтенду;
• Катерина Жук, що опікувалася спілкуванням з фондами та питаннями благонадійності;
• Ольга Тургенева та Ігнат Зайцев, котрі намалювали усіх котів, що ви бачите на сайті;
• багато інших працівників і ще тисячі волонтерів.

Команда Bihus.info

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

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

Доволі довго проект пробув у статусі напіввідкритої деми. Це допомогло протестувати ігрову механіку, знайти помилки, що не були покриті тестами, та зібрати фідбек.

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

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

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

Післямова

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

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

Привет. Меня зовут Максим Носатов, я Game Developer, работаю с UE4 и Unity3D. Мой стаж в геймдеве — около 5 лет. Я начинал свою карьеру как Unity3D & C++ разработчик в аутсорсинговой компании iLogos, проработал там полтора года.

В 2014 году я заинтересовался Unreal Engine 4. Как и Unity, это компонентно-ориентированный движок. Каждый месяц платил $30 со своей джуниорской зарплаты за лицензию. Надо сказать, это здорово било по бюджету. И спустя некоторое время я решил найти работу по этому профилю. Так как в Украине на тот момент практически не было проектов на UE4, искал вакансии за границей. Получив оффер от польской компании VividGames, я поехал в город Быдгощ на позицию UE4 & C++ разработчика. Там тоже проработал около полутора лет: сначала в UI-команде, позже — в Engine.

Затем я вернулся в Украину и около года сотрудничал с компаниями ProgramAce и CommuniClique. Несколько месяцев назад основал собственную компанию. Мы занимаемся разработкой игр и VR-приложений. Помимо этого, я преподаю на курсе разработки игр games.education.

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

Специализации программистов в геймдеве

Сначала пару слов о технологиях: в геймдеве чаще всего пишут на C++. Всевозможные тулзы и сборки в Unreal Engine написаны на C#. Также используется визуальный язык программирования Blueprints — на нем сделано большинство поверхностных систем UE, например, анимационные графы. Если вы заинтересованы в мобильной разработке, вам также пригодится знание нативных языков — к примеру, Objective-С и Java.

Обычно в геймдев-компаниях есть такие роли разработчиков:

• Gameplay Developers;
• Engine Developers;
• Animation Developers;
• DevOps Developers;
• Tools Developers;
• UI Developers;
• Graphics Programmers;
• Audio Developers;
• Client Developers;
• Back-end Developers.

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

Рассмотрим каждую роль подробнее:

Gameplay Developers — отвечают непосредственно за механику. При этом Gameplay-разработчики плотно сотрудничают с гейм-дизайнерами, которые и поставляют им механику. Что касается технологий, в Unreal Engine можно быстро прототипировать за счет Blueprints и писать базовые классы для геймплея за счет С++.

Engine Developers — разрабатывают непосредственно движок: утилиты, тулзы для других разработчиков, занимаются SDK-интеграцией.

Animation Developers — занимаются разработкой анимационных систем, работают со Skeletal animation, делают тулзы для разработчиков и аниматоров. Чаще всего такие специалисты нужны в компаниях, которые работают с кастомными движками — например, Ubisoft, Gameloft, Deep Silver. Так, Ubisoft разрабатывают собственную систему симуляцию одежды, и у них есть вакансии для Animation Developers, которые занимаются непосредственно физикой.

DevOps Developers — занимаются микросервисами, работают с клиентами, такими как Battle.net от Blizzard, Uplay от Ubisoft, которые позволяют пользователям игр совместно играть через интернет, а также покупать и обновлять игры онлайн. DevOps Developer — это одна из самых новых специализаций в геймдеве.

Tools Developers — пишут непосредственно тулзы для гейм-дизайнеров: на Qt или прямо внутри движка.

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

Graphics Programmers — отвечают за качество картинки, работают с низкоуровневым слоем: OpenGL, DirectX. Пишут шейдеры, оптимизируют графику конечного продукта.

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

Client Developers — занимаются обработкой событий, работают с верхними интерфейсами.

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

Геймдев в Украине и за рубежом

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

На собеседованиях в заграничных компаниях, как правило, спрашивают, чего вы хотите, какая специализация вам наиболее интересна. Проверяют знание базовых вещей: к примеру, если вы идете на Graphics-программиста, у вас спросят об опыте работы с anti-aliasing, моделью Фонга.

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

Чтобы попасть в заграничную компанию, помимо хорошего английского требуется опыт работы 2-3 года,так что, скорее всего, вам придется столкнуться и с украинскими компаниями. Из компаний с собственным продакшном на украинском рынке есть Ubisoft, Plarium, Wargaming, Vostok Games, Gameloft и другие.

Что касается Unreal Engine, с весны 2015 года UE4 стал бесплатным, и с тех пор и украинские гейм-компании более активно начали работать с этим движком.

Полезные ссылки

UE4 Resources — это блог разработчика, где он выкладывает все проекты, семплы своих игр. По сути, это его портфолио. Если вы только изучаете Unreal Engine, посморите, как реализованы его проекты, попробуйте сделать по аналогии. Возможно, примеры реализации пригодятся вам при выполнении тестового задания :)

Tom Looman — сайт разработчика, который, можно сказать, вытянул на себе отрасль, написав много статей для Википедии, гиды по C++ и Unreal Engine. В блоге — материалы по Unreal Engine в частности и геймдеву в общем.

Rleonardi.com — интерактивное резюме гейм-разработчика. Отличный пример самопрезентации.

Как развиваться в геймдеве

Чтобы разобраться с геймдевом, вам понадобятся базовые знания объектно-ориентированного программирования, а также языка С++. Изучив азы, можно переходить к игровой специфике.

Вот примерные темы, которые должен освоить начинающий Unreal Engine разработчик:

• особенности кодинга на С++ в движке UE4;
• базовые элементы геймплея — Actors;
• система управления памятью и система обработки игровых объектов;
• работа с физическими симуляциями и силами, воздействующими на объекты;
• создание пользовательского интерфейса, виджеты на C++;
• создание искусственного интеллекта;
• интегрирование SDК, разработка собственных плагинов;
• Unreal Build System, коллекция инструментов для автоматизации разработки;
• непосредственно разработка игры: создание инвентаря, Save System, системы событий и т. д.

Если вас интересует 3D-наполнение для уровней, работа с освещением, материалами, анимацией и динамикой, необходимо освоить:

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

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

Если у вас есть вопросы, пишите в комментариях, постараюсь ответить.

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

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

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

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

Можно это показать так:

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

Как формируется цена работника

У интеллектуального труда нет себестоимости. Цена определяется исключительно рынком и осведомленностью работников о нем.

Факторы, влияющие на цену человека на рынке труда:

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

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

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

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

Соответственно, следующий уровень, который может колебать цену на рынке, — памп/дамп (искусственное завышение/занижение цены) активов через нагнетание в медиа информации, склоняющей людей к занижению или завышению своей цены. Например, Вася прочитал на DOU, что средняя зарплата джуниора — $1000, а он получает $400. Вася пошел просить больше и искать вакансию на $1000.

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

Алгоритм поиска первой работы

Рынок труда в IT в целом несколько отличается от других рынков:

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

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

Давайте разберем каждый пункт более детально.

Понять, какие есть направления работы

Могу порекомендовать хороший цикл статей на DOU — «Карьера в IT».

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

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

Выбор специализации

Этот пункт наиболее актуален для разработчиков, поскольку есть множество технологий. Тут мы имеем палку о двух концах. Выбирая наиболее популярную технологию, вы конкурируете с бо́льшим количеством людей. Выбирая менее популярную, уменьшаете свои шансы найти работу. Можно попробовать сравнить статистику по Djinni, поставив фильтры «ваш город, страна», «меньше года опыта» и соответствующую технологию. Затем посмотреть количество вакансий, например, на DOU. Общее количество вакансий может быть косвенным показателем количества вакансий для новичков, есть определенная корреляция.

Я могу выделить такие факторы выбора технологии:

1. Привязка к месту жительства.

Если вы привязаны к определенному городу и не хотите переезжать — выясните:

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

Если вы не привязаны к месту:

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

2. Личный интерес. Если вам нравится делать конкретно UI или работать с базами, поищите работу в этом направлении.

3. Опора на ваши уже развитые сильные стороны и навыки. Это может быть вполне хорошей базой для движения в новом направлении. Например, если в школе вы любили администрировать Linux, почему бы не стать DevOps?

4. Простота входа. Чтобы разобраться в технологиях типа HTML, CSS, Wordpress, нужно куда меньше времени, чем на изучение Java или C# вместе со всеми фреймворками. Однако и потолок заработка будет не такой высокий, особенно если вы пойдете получать первую практику на фриланс. Но это может стать отличной точкой входа для дальнейшего развития.

5. Возможность найти первую работу удаленно. Если у вас есть портфолио на GitHub, вы знаете английский, никто не мешает вам написать в любую веб-студию или IT-компанию в мире и предложить свои услуги. Но удаленщики без значительного опыта скорее будут работать с HTML, PHP, CMS, чем с языками, заточенными под Enterprise (промышленную разработку корпоративных решений) — C# или Java. Когда-то я помог другу с минимальным опытом в PHP найти работу в малазийской веб-студии на неплохой рейт, но он переоценил свои силы, и сработаться у них не получилось.

Понять, какие навыки необходимы

Достаточно очевидный и при этом очень неочевидный пункт.

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

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

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

1. Изучить базовый синтаксис, IDE, методы фреймворков.
2. Найти уже готовые приложения, выяснить, почему они построены именно так, сделать свое по образцу.
3. Повторить это несколько раз в нескольких конфигурациях, чтобы научиться видеть потенциальные проблемы и нестыковки — это уже опыт.

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

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

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

Собственно, вам необходима литература о том, как выявлять потребность клиента, схематизировать (например, IDEF0), организовать UI, писать требования.

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

Обучение

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

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

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

Но работодателю вы будете интересны, если сможете реализовать минимальный работающий продукт по своей специализации. Попробуйте поискать в интернете тестовые задания в разные компании. Думаю, именно такого рода поделки будут лучше всего. Поищите в Гугле «тестовое задание <вставить название вашей технологии>». Также не забывайте выкладывать их на GitHub! Но об этом поговорим ниже.

Точки входа в первую работу

1. Фриланс-биржи.
2. Помощь знакомым, например, сделать сайт мебельного магазина мужу сестры.
3. Знакомые фрилансеры могут отдать вам свой несложный заказ за небольшие деньги или вовсе бесплатно, но с условием, что укажут вам на ваши ошибки и дадут обратную связь.
4. Участие в любых программах университета, помогающих устроиться на работу. Поговорите с людьми с кафедры, может, они подскажут.
5. Стартапы или просто личные проекты людей, которые уже где-то работают. Больших бюджетов нет, но и требования к коду и знаниям там минимальны — лишь бы работало.
6. Курсы IT-компаний, после которых возможно трудоустройство.
7. IT-компании, набирающие людей на оплачиваемую/неоплачиваемую интернатуру.
8. Удаленная, возможно, даже поначалу неоплачиваемая работа.
9. Вход в смежную специализацию для набора опыта. Например, идете в manual QA, чтобы перейти в Automation.
10. Случай довольно редкий, но, если вы хорошо ориентируетесь в какой-то сфере и можете заработать, решив чью-то проблему в вашей предметной области с помощью IT-средств. В худшем случае это опыт, который поможет в дальнейшем, в лучшем — деньги.

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

Продвижение себя в инфопространстве

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

1. Заполните социальные профили и четко укажите, что вы ищете:

• LinkedIn — в статусе можете написать «looking for a job», опишите, какие курсы прошли, где учились, работу какого направления ищите.
• Facebook — добавляйтесь в максимальное количество групп, связанных с вашей специализацией, отслеживайте сообщения о любых возможностях участвовать в чьем-то проекте или интернатуре.
• DOU — следите за анонсами интернатур — Junior дайджест, Календарь.
• Work.ua , AIN.ua — тоже лишним не будет залить сюда свое резюме или искать вакансии.
• Обязательно заведите на GitHub профиль со своими поделками.
• Создайте профиль на Djinni. Сумму поставьте не очень большую или вообще символическую, можете ориентироваться на те, что есть. Обязательно добавьте ссылку на GitHub, это выделит вас среди остальных.
• Дружите с рекрутерами, добавляйте всех подряд на LinkedIn, они вам еще пригодятся.
• Подпишитесь на рекрутерские группы на Facebook, типа такой.

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

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

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

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

5. Можете воспользоваться услугами карьерного коучинга. В Украине есть компании, которые помогают переучиваться свитчерам (тем, кто хочет сменить работу на IT).

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

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

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

На западе также популярны cover letter и CV. Разница между резюме и CV в том, что CV — детальное описание того, чем вы занимались, ваш опыт, навыки, образование и прочее; резюме — краткая выжимка на одну страницу. Cover letter — по сути, письмо, объясняющие мотивацию работать у конкретного работодателя. В нашей культуре, думаю, достаточно будет одного резюме, но новичкам желательно подойти к этому более скрупулезно. Можно написать cover letter — указать, почему именно вы хотите работать у конкретного работодателя. Из сотен резюме, которые получают рекрутеры на вакансию джуниора, именно ваше может приглядеться благодаря cover letter.

Также не стесняйтесь писать follow-up’ы — письма, напоминающие о вас.

Просмотрите статистикупо каналам найма за 2017 год, берите их на заметку.

Собеседования

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

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

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

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

Часто на собеседованиях задают вопросы, о которых придумано немало шуток:

— Кем вы видите себя через пять лет?

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

— Почему вы хотите работать именно в нашей компании?

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

— Опишите свои сильные стороны?

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

Немного о найме не только для начинающих

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

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

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

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

О деньгах

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

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

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

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

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

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

Истории реальных людей и их путь поиска первой работы

Для начала моя история. Я знал, что хочу в IT еще в школе, поэтому и поступал на прикладную математику. Начинал фрилансить на втором курсе университета — PHP/HTML/CSS/CMS, в конце третьего курса попал на Agile-практику в местную аутсорс-компанию на .NET направление. Потом нас взяли на работу джунами, и наш проект продлился несколько месяцев. С таким опытом мне было куда проще найти следующую работу. Хотя изначально в университете я больше смотрел в сторону Flex/Java, но в связи с такой удачей решил использовать этот опыт для развития в сторону .NET.

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

Кейс #1 Верстальщик

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

Руслан Бей, работаю верстальщиком-фрилансером на протяжении трех лет.

— Твое образование, куда поступил?

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

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

— Когда решил что хочешь работать в IT?

Думал, что поступлю в институт, и там уже будет ясно, чем заняться. Но скоро стало понятно, что после института буду работать на заводе максимум за 4000 грн в месяц, поэтому на 3-мкурсе института, понял, что нужно что-то менять и пошёл на курсы PHP. Раньше вообще не слышал об этом ничего, но так как мне порекомендовали, то доверился совету грызть PHP. Но по окончании обучения понял, что это PHP грыз меня. Я ничего не вынес из курсов, так как было очень сокращенно и непонятно. Решил, что IT — не мое и забросил.

— Как обучался?

Через некоторое время знакомый мне посоветовал пойти на курсы верстки в Spalah IT School. Так как многие начинали с верстки, подумал, что и у меня зайдет. Так и произошло.
Обучение длилось 3 месяца.

— Как нашел первую работу?

На 2-ммесяце обучения на курсах начал искать работу. Так как портфолио у меня не было, то, естественно, резюме было не очень, да и опыта 0, но я не сдавался и мониторил доски объявлений. И вот мне написал директор мелкой студии из Киева, говорит: «Нас заинтересовало ваше резюме, выполните тестовое задание, и мы посмотрим, подходите вы нам или нет».

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

Кейс #2 Фронтенд-разработчик

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

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

— Твое образование, куда поступил?

У меня среднее техническое образование, я инженер-ракетчик, учился 4 года в ракетном техникуме, потом 3 и 4 курс в ДНУ на физтехе. Недоучился полгода.

— Когда решил, что хочешь работать в IT?

Где-то в 15 прочитал толстенную книгу HTML4.0, вроде понравилось, но опять же забросил, потому что гулять было интереснее и легче :) Вернулся к осознанию того, что все-таки пора учиться, к 21-22году своей жизни.

— Как обучался?

Начинал обучаться, будучи на работе, не связанной с IT. Когда понял, что мне это нравится — уволился и еще обучался сам около месяца — HTML Academy, Codeacademy, learn.javascriptи тому подобные мне очень помогли. Также почитал немного книг, например, «Javascript» от Ильи Кантора.

— Как нашел первую работу, в деталях?

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

Пользовался Work.uaи Djinni.co, спустя какое-то время я удаленно поработал пару недель на киевскую фирму на React Native. Меня туда взяли на испытательный срок, после того как я неплохо справился с тестовым, хотя раньше ни строчки не писал на React Native. Но долго там поработать не вышло. И тут меня позвали в местную компанию, работать с ReactJS в качестве джуна в моем городе. Сейчас тут и работаю, быть джуном сложно, но интересно — ничего не знаешь, но делаешь.

В заключение

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

Если кто-то захочет со мной связаться, пишите лично в Facebook Vladislav Furdak.

Привіт! Мене звуть Наталія Дзюбенко, з жовтня минулого року живу в Нідерландах і працюю Java-розробником у компанії Lunatech Labs, що в Роттердамі. Цілеспрямовано шукала роботу в цій країні або в Німеччині. Перед тим попрацювала в Одесі (моє рідне місто), потім переїхала до Польщі, але хотіла далі в Європу. Найцікавішими виявилися Нідерланди: тут легше з документами (менше бюрократії), податками, мовою, ставленням до мігрантів. Ще раніше, коли подорожувала Нідерландами, склалось дуже гарне враження про країну.

Робота і переїзд

Роботу шукала роботу на багатьох ресурсах, але найзручнішим виявився LinkedIn. Зацікавила вакансія experienced Java developer, яку опублікувала компанія Lunatech Labs. Раніше теж працювала Java developer і мала досвід більше 2 років. Коли надіслала резюме, зі мною зв’язалися, торік наприкінці серпня почали спілкуватися. Було декілька співбесід. Перша — з одним із рекрутерів та з технічним спеціалістом. Потім вислали тестове завдання, на нього мені дали тиждень, але я впоралася на кілька днів раніше. Через тиждень призначили code review із демонстрацією проекту, опісля чого запросили на фінальну співбесіду з CEO. Наступного дня після нашої розмови отримала офер. Це була середина вересня, а ще приблизно через півтора місяці я потрапила в Нідерланди (стільки часу знадобилося на оформлення документів).

Компанія майже все зробила за мене в оформленні візи. У мене попросили скани документів для візи MVV, спеціальної для highly skilled migrants. Організація в Нідерландах, яка займається міграційними питаннями (ind.nl), мала розглянути заявку, після чого — підтвердити її. Затим я поїхала в Київ подаватися на візу, попередньо обумовивши appointment на сайті посольства. Процес подачі документів не був складним (потрібно було принести паспорт і заповнити форму). Через тиждень забрала паспорт з візою.

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

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

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

Офіс, де я працюю, розташований в центрі Роттердама. Є ще офіс у Франції. Багато людей працює в офісах замовника (у нас є такі великі замовники, як ING (банк)). Компанія розробляє софт виключно на JVM (Java/Scala/Kotlin) та орієнтується на Big Data технології. На моєму проекті були нові для мене технології, з якими раніше небагато працювала: SBT, Spark, Mesos, Akka, Cassandra, Kafka, DC/OS, AWS.

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

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

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

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

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

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

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

IТ-ринок

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

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

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

Податки мені вираховує роботодавець. У моїй візі обумовлена 30-відсотковазнижка на податки — тобто цю суму мені повертають як іноземцю (є список країн, для жителів яких можлива така опція; у моїй компанії майже всі мають таку знижку). Про її оформлення треба обов’язково цікавитись у роботодавця під час пошуку роботи (називається 30% ruling).

Менталітет

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

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

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

Мови

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

Житло

Мінімальна ціна, за яку можна орендувати більш-менш нормальну квартиру з побутовою технікою (шукала в Гаазі, Роттердамі, Східамі), — 800 євро. У Нідерландах є ліміт типу «якщо ти заробляєш менше цього і більше цього ліміту, то таку квартиру тобі не можна». Це робиться для того, щоб ті, хто заробляють більше, не займали дешевші квартирки, і їх усім вистачило. У Роттердамі за 1,5 тисячі євро можна знайти щось досить величеньке і з крутим ремонтом. Комунальні послуги обійдуться ще десь в 100-200 євро.Помітила, що всі, кого знаю, винаймають житло самостійно, не складаються разом.

Я сплачую за оренду суму, що посередині між цими двома цифрами (800 і 1500 євро), я задоволена. Шукала помешкання в інтернеті, знайшла на сайті pararius.com (цей сайт мені здався найзручнішим, до того ж один із небагатьох має англійську версію) через ріелтора. Сама з ним зв’язалася, і досі не розмовляла безпосередньо з господарем, лише з ріелтором (господар оплачував ці послуги). Майже завжди при переглядах квартир приходило ще багато людей, крім мене, і ймовірність, що саме я отримаю цю квартиру, була завжди невелика. Тому я, майже не міркуючи, обрала ту, яка мені одразу сподобалась і відповідала моїм вимогам (побутова техніка і т. д.).

Моя квартира розташована у спальному районі, транспорт добре ходить, можна доїхати до Schiedam Centrum (центральна станція Східама), а звідти вже їхати куди завгодно. Можна було б і ближче знайти житло, але мені сподобалося тут: і ціна непогана, і місто гарне. Східам відчувається майже як частина Роттердама, але тут спокійніше, тихіше.

Транспорт

Їжджу громадським транспортом, а зараз, коли погода стала хороша, добираюся велосипедом. Що транспортом, що велосипедом витрачаю 40 хвилин на дорогу до Роттердама.

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

Картку можна поповнити на фіксовану суму, а можна прив’язати до банківської картки, і вона буде автоматично поповнюватися. Ціна проїзду рахується по дистанції. Поїздка до центру у Східамі мені коштує 50 центів, потягом до Роттердама — два євро, в Гаагу — 3-4 євро.

Є багато транспорту, який курсує між містами. Наприклад, метро, яке їздить від Роттердама до Гааги (приблизно 20 км), і дорогою об’їжджає багато інших населених пунктів. Але не між усіма містами є таке сполучення, іноді доводиться користуватися потягом. Він — зручний і часто ходить. Потягом зручно їхати також до Амстердама — менше, ніж годину.

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

Ще за транспортом зручно слідкувати через спеціальні додатки (наприклад, 9292.nl), тому відомо з точністю до хвилини, як доїхати в будь-яку точку (з пересадками між різними видами транспорту і т. д.).

Велосипеди

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

Досить просто взяти велосипед напрокат на будь-якій станції. Але якщо живеш у Нідерландах довго, краще придбати власний, це не так уже й дорого. Я так і зробила: придбала міський велосипед разом з надійним замком приблизно за 200 євро. Їжджу не щодня, але десь половину разів за місяць набралося. Мені 10 кілометрів до роботи, тож якщо є настрій, їду на велосипеді.

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

Медицина

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

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

Дозвілля

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

Кухня та продукти

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

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

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

Плани

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

І поступово вчуся у голландців бути завжди щасливою :)

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

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

BetterMe — это достаточно молодой проект украинской продуктовой компании Genesis. Мы создаем мобильные приложения в категории Health and Fitness, ориентируясь на развитые страны. За 8 месяцев существования проекта нашими продуктами воспользовались более 6 млн пользователей, и мы закрепились в ТОП-3 приложений в своей категории на рынке США.

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

Структура продуктовой команды

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

1. В рамках проекта BetterMe разрабатывается 3 продукта. На каждый продукт назначается отдельный Product Manager (PDM), который отвечает за формирование беклога, приоритизацию User stories, рост метрик и в целом за успех продукта.
2. Facilitator (он же PM),в свою очередь, отвечает за построение и поддержку наших процессов на высоком уровне. Основная цель этой роли — «бесперебойное производство», которого можно достичь посредством поддержки эффективной коммуникации на разных стадиях разработки и контроля качества поступаемого материала инженерам:
   
   • детально продуманные и прописанные User stories;
   • подготовленный и выверенный дизайн;
   • сформированные аналитические события и др.
3. Команда инженеров, дизайнеров и тестировщиковперераспределяет свои ресурсы в зависимости от потребностей и целей BetterMe, то есть эти команды не привязаны к конкретному продукту.

Такая структура команды позволяет нам получить необходимую глубину понимания и развития благодаря отдельному Product Manager (PDM) на каждом продукте, не увеличивая при этом команду инженеров до неэффективных размеров.

Приведу пример. Как правило, для эффективной поддержки продукта каждое приложение потребовало бы по 2-3 iOS и Android инженера. Итого, на 3 продукта — по 9 инженеров на каждую мобильную платформу. Наш же подход требует 4-5инженеров на каждой платформе, потому что команда «плавает» между продуктами в зависимости от заданного приоритета.

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

Процесс планирования и роли

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

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

Учитывая нашу реальность, мы вывели ключевой принцип: планируем не фиксированные по времени спринты, а релизы (версии приложений, которые включают в себя набор User stories). То есть длительность итерации зависит от времени, необходимого для реализации следующей версии приложения, которая и является основным продуктом разработки. Кроме того, релиз можно «пощупать» как целостный продукт и измерить его влияние на метрики.

Перейдем к деталям.

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

Процесс планирования релиза имеет несколько этапов:

1. Выбор фич-кандидатов для релиза

Product Manager определяет перечень фич, которые необходимо реализовать в следующей версии приложения, исходя из приоритизированного User Story Map. Кстати, для построения User Story Map используем удобнейший инструмент RealtimeBoard, а каждая карточка User Story — это ссылка на конкретный User Story в Jira (cм. ниже).

2. Формирование первичного релиз-беклога

PDM формирует в Jira беклог из user stories, отобранных из User Story Map для следующей версии приложения; описывает user stories, определяет в них приемочные критерии (acceptance criteria). UI/UX team, исходя из описания User stories, создает мокапы для покрытия acceptance criteria и согласовывает их с PDM. Кстати, для подготовки дизайн-ресурсов мы используем Zeplin, что значительно уменьшает головную боль инженеров и дизайнера. Кроме того, в Zeplin мы сразу разделяем дизайн экранов по версиям приложения, что тоже позволяет быстро ориентироваться в наборе задач, которые попадут в релиз (cм. ниже).

3. Разбор user stories из первичного релиз-беклога

Facilitator организовывает встречу под названием «груминг», на которой происходит разбор пользовательских историй, выбранных PDM для релиза. На груминге присутствуют PDM, UI/UX, PM, команда разработки (состав команды разработки варьируется в зависимости от user stories) и QA команда.

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

Основные цели груминга:

• Корректировка User stories на ранней стадии;
• Обнаружение подводных камней, так как задачу рассматривают с разных углов (development, QA, аналитика);
• У команды есть полное понимание, что мы делаем дальше, и ориентация в том, как мы это делаем.

4. Доработка user stories из релиз-беклога

PDM и UI/UX, при необходимости, по результатам груминга вносят правки в описание user stories и дизайн в соответствии с договоренностями, достигнутыми командой на груминге.

5. Формирование набора аналитических событий (events)

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

6. Оценка user stories инженерами

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

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

Итог

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

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

Основной вывод:не бойтесь нарушать правила и адаптируйте свои процессы под вашу реальность в поисках максимальной эффективности.

В серии статей о софт скиллах мы собрали и упорядочили 18 личностных навыков и качеств, которые, по мнению Senior- и Lead-специалистов украинских IT-компаний, наиболее важны для профессионального роста.

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

Умение решать задачи

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

Максим Ковтун, Chief Software Architect в Sigma Software:

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

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

Мало заметить и обозначить проблему. От Senior- и Lead-специалистов ожидают инициативу в поиске ее решения.

Андрей Завадский, Engineering Team Lead в Innovecs:

Senior — это problem-solver. Заметив какую-то проблему, он не просто ее констатирует, а берет на себя проработку вопроса и формирует возможные варианты решения. В моем мире этот навык формируется где-то от Middle (зародыш навыка) до Middle+.

Есть неплохая книга: «Grit: The power of passion and perseverance» — о том, почему одни достигают успеха, даже если изначально нет таланта, а другие — нет, даже если он и есть. Меня этому научила работа. Меня очень «парило», что я приходил с проблемой, а решение принималось долго. Я понял, что нужно готовить анализ. Приходил с анализом, и все равно принятие решения было долгим. Понял, что нужны варианты: тогда человек быстрее выберет один, и я уйду довольным.

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

Іван Попович, Java Developer & Team Lead у Conscensia:

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

Я розділяю технічних спеціалістів на 4 основні групи:

• тобі допомагають виконувати задачі;
• ти виконуєш їх сам;
• ти допомагаєш іншим виконувати задачі;
• ти допомагаєш бізнесу замовника.

Щоб перейти на 4-йрівень, необхідно бути максимально сфокусованим на результаті.

Константин Захаров, Solution Architect EPAM Ukraine:

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

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

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

Целостное видение

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

В’ячеслав Калашников, Software Architect в Luxoft:

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

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

Максим Сидоренко, Senior Developer в Sitecore Украина:

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

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

Константин Захаров, Solution Architect в EPAM Ukraine:

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

Управление временем

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

Александр Крачун, Full Stack Developer & Team Lead в Adtelligent:

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

Рекомендую ознакомиться с 26 лайфхаками. Осознайте, обдумайте и начните вводить в практику несколько таких принципов. Как только они станут для вас в порядке вещей, приступайте к следующим «постулатам». Практикуйте, не ленитесь — результат не заставит себя ждать. Также рекомендую почитать статью «Тайм-менеджмент: управление временем».

Константин Захаров, Solution Architect в EPAM Ukraine:

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

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

Координируя команду, вы управляете не только своим личным временем, а и таймлайнами проекта.

Діма Павлов, Software Tech Lead в Terrasoft:

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

Щодо інструментів, для декомпозиції задач і предметної області ми використовуємо mind maps, для індивідуального планування — Asana.

Умение делегировать

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

Владимир Гарбар, Team Lead в HYS Enterprise:

Умение доверять помогает делать то, что в одиночку попросту невозможно. Если вы заслуживаете доверия, то почему другие не заслуживают? Только не надо наивно верить, что вас не подведут. Даже очень хороший специалист дает осечку в 5% случаев или около того. Будьте готовы к ситуации, когда что-то пойдет не по плану. Случилось — ну и что? Вовремя приходите на помощь. Согласитесь, 95% успешных случаев — это лучше, чем ноль, при полном недоверии.

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

Александр Крачун, Full Stack Developer & Team Lead в Adtelligent:

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

Рекомендую начать с прочтения книги «Делегирование и управление» Брайана Трейси.

Задача лида — не делать все в одиночку, а наладить рабочие процессы. Главное — не скатиться в микроменеджмент.

Павел Свинцицкий, Team Lead в Mobilunity:

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

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

Артем Петров, Web-department Team Lead в Appus Studio:

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

Навыки People-менеджера

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

Артем Петров, Web-department Team Lead в Appus Studio:

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

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

Павел Свинцицкий, Team Lead в Mobilunity:

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

Ваша задача — помогать развиваться остальным членам команды.

Максим Ковтун, Chief Software Architect в Sigma Software:

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

Іван Колодій, СЕО Ukietech та TechLead на проекті TenantCloud:

Якщо ви керуєте командою, критично важливим є knowledge sharing. Зазвичай програмісти жадібні і не хочуть викладати свої «конкурентні переваги» у вільний доступ. Цієї звички потрібно позбуватись і впроваджувати таку культуру, при якій всі будуть охоче ділитися знаннями. В такому випадку корисними будуть бонуси (матеріальні чи нематеріальні) та різні заохочення для контриб’юторів.

Стройте отношения с командой на принципах взаимоуважения.

Олег Дмитриев, TechLead в Webinerds:

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

Что еще почитать о менеджменте:

• «Мифический человеко-месяц, или Как создаются программные системы»Фредерика Брукса — об управлении проектами в области разработки ПО: повышение производительности труда программистов, организация коллективной работы, планирование и выполнение графика реализации.
• «Программист-прагматик. Путь от подмастерья к мастеру»Эндрю Ханта — охватывает темы от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации.
• «Менеджер 80/20. Главный принцип высокоэффективных людей»Ричарда Коха — о том, как работать меньше, а получать больше. Как известно, 80% результатов проистекает из 20% причин, а за 20% времени мы успеваем сделать 80% дел.
• «Тайм-драйв. Как успевать жить и работать»Глеба Архангельского — советы по организации рабочего времени и отдыха, мотивации и целеполаганию, планированию, расстановке приоритетов, эффективному чтению.
• «Deadline. Роман об управлении проектами»Тома ДеМарко — о работе с людьми: как выбрать из множества кандидатов нужного вам человека, каково оптимальное число людей в команде на разных этапах проекта, как оптимизировать работу, если перед вами поставлены жесткие сроки, как определять и решать конфликты.
• «7 навыков высокоэффективных людей»Стивена Кови — системный подход к определению жизненных целей, приоритетов человека и о том, как их достигать.
• «Черная книга менеджера» — о честном ежедневном труде и смелости.
• «The First-Time Manager»Лорен Белькер и Гэри Топчика — о менеджменте, найме и увольнениях, мотивации, доверии, управлении временем и стрессом.

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

[Сергей Сыроватченко — SQL Server DBA в EPAM. Работает с SQL Server уже 7 лет. Увлекается тематикой администрирования серверов и оптимизацией запросов. В свободное время пишет технические статьи и делает мини-тулы для обслуживания и мониторинга производительности SQL Server]

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

Марио Пьюзо «Крестный отец»

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

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

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

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

Михаил Булгаков «Собачье сердце»

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

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

— Хочу предложить вам взять несколько журналов в пользу детей Германии. По полтиннику штука.
— Нет, не возьму.
— Вы не сочувствуете детям Германии?
— Сочувствую.
— Жалеете по полтиннику?
— Нет.
— Так почему же?
— Не хочу.

Стивен Кинг «11/22/63»

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

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

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

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

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

Itzik Ben-Gan «SQL Server 2012 T-SQL Fundamentals»

В русском переводе — Ицик Бен-Ган «Microsoft SQL Server 2012. Основы T-SQL»

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

Когда у меня спрашивают, с чего бы начать обучение T-SQL, то на этот вопрос отвечаю примерно так: «Если хочешь стать точно такой же „машиной для убийства“ при работе с SQL Server и в будущем рвать на британский флаг запросы любой сложности, то крайне советую эту книгу».

Фактически этот литературный источник — отправная точка для всех, кто хочет научиться писать запросы на T-SQL. В книге даются базовые знания о синтаксисе, порядке выполнения запроса, нормализации данных, работе с индексами и еще о многих других полезных вещах. Практические задания, которые идут после каждой главы, рекомендую не игнорировать, поскольку они хорошо закрепляют теорию и часто встречаются на собеседованиях на Junior/Middle позиции, которые так или иначе связаны с .NET стеком.

Dmitri Korotkevitch «Pro SQL Server Internals»

Если вы изучили базовый синтаксис T-SQL и начали работать с SQL Server, но хочется копнуть глубже, то эта книга даст вам целостное представление о внутренних механизмах работы данной DBMS.

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

Автор книги — один из самых опытных специалистов по SQL Server и регулярно выступает на SQL Saturday, поэтому за качество материала можно не переживать. Все систематизировано и написано простым для понимания языком.

Книга очень близка по духу с «Microsoft SQL Server 2012 Internals»под авторством весьма авторитетных людей в мире SQL Server: Kalen Delaney, Benjamin Nevarez и Paul Randal. Последний автор приложил свою руку к Storage Engine и CHECKDB, поэтому в этой книге тоже можно почерпнуть очень много полезной информации.

На правах небольшой рекламы хотелось бы пригласить на SQL Saturday Kiev 2018, который будет проходить 19 мая. Лично я уже зарегистрировался и взял билеты. Не упустите шанс послушать интересные доклады и получить море новых знаний :)

В этот раз DOU Ревизорпобывал в Daxx — голландской IT-компании, которая с 1999 года создает удаленные команды программистов в Украине для клиентов из Европы, США и стран Ближнего Востока (другими словами, аутстаф). В Украине офисы компании расположены в Киеве, Харькове, Днепре и есть небольшой офис во Львове. Глобально здесь работает 300+ человек.

Основная команда разработчиков и административного персонала находится в Киеве и составляет 154 человека, из них 134 — технические специалисты. В дополнение к украинским офисам, у Daxx есть штаб-квартира в Амстердаме и представительство в Нью-Йорке.

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

Киевский офис компании расположен в бизнес-центре «Форум Кинетик» по адресу Куреневский переулок, 12 и занимает 1, 3 и 7 этажи. Не так давно часть команд переехала в соседнее трехэтажное здание (корпус B того же БЦ), заняв там еще 1 этаж. Сказать по правде — это промзона, а сам бизнес-центр вырос на месте когда-то существовавшей обувной фабрики № 4, которую позже назвали в честь 10-летиякомсомола Украины.

Офис расположен между тремя станциями метро: 1,8 км до «Почайна», 2,1 км до «Оболонь» и 2,6 км до «Дорогожичи». Добраться до метро можно как на общественном транспорте, так и на организованной развозке от бизнес-центра.

На территории бизнес-центра есть мини-маркет и несколько кафе: Apple Café (средний чек — 80 грн), «Филин» (стоимость обеда — около 120 грн), «Печена картопля» (средний чек — 60 грн) и Fresh Factory (стоимость обеда — около 150 грн).

Через дорогу находится Куреневский парк, где можно прогуляться в обеденное время, а также концерт-холл Freedom. Неподалеку от офиса расположен Sport Life и спорт-клуб Sport & Spa. Рядом также есть химчистка, заправка, отделение «Райффайзен Банка Аваль», а в самом здании бизнес-центра — терминал «ПриватБанка» и банкомат «УкрСиббанка».

Возле здания есть отдельная открытая парковка для автомобилей общей площадью 120 м². Стоимость паркоместа в месяц — 96 долларов (просчитывается в гривневом эквиваленте). Компания компенсирует 50% стоимости. Для велосипедистов на заднем дворе бизнес-центра есть открытая велопарковка, а в офисе — душ.

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

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

Рабочий день сотрудники обычно начинают в 9:00 — 10:00 и работают до 18:00 — 19:00, но все зависит от графика коммуникаций с клиентами (по данным компании).

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

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

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

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

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

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

Лилия, Senior Front-end Engineer, 3,5 года с компанией:

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

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

Іра, QA Engineer, 4 роки з компанією:

Офіс подобається. У нас простора кімната, багато місця. Ми не сидимо один на одному.

Раніше Daxx знімав офіс в «Альта Центрі». Офіс був гірший, але там «Ашан» був поряд, а тут нема :)

Богдан, Software Developer, 2 года с компанией:

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

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

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

Влад, Front-end Engineer, почти 2 года с компанией:

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

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

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

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

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

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

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

Цю статтю створено у співавторстві з Анастасією Білоус.

Машинне навчання і штучний інтелект за останні кілька років стали дуже гарячими темами. В тих чи інших варіантах вони сьогодні є частиною величезної кількості продуктів, і мало хто не задумується над їхнім запровадженням. Приклади застосування ML (Machine Learning) — від автоматичного визначенняважливих листів і швидких відповідей в Gmail, створення музикиза допомогою машинного навчання до AlphaGo. Ця стаття також буде прочитана роботами швидше і більше разів, ніж людьми :)

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

Знайти рішення

Візьмемо за приклад таку історію. Всесвітньо відомий український політехнічний університет (скорочено ПТУ) запровадив платну перездачу екзаменів. І у фінансового директора університету Іван Івановича виникла проблема: обсяги цих надходжень дуже складно запланувати наперед. Складніше ніж погоду, яка і так корелює з успішністю студентів. А Ryanair і all inclusive треба ж бронювати наперед.

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

def predict_num_failed_exams():
  result = 0
  for student in self.all_students:
    for exam in student.exams:
      if self.predict_exam_failure(student, exam):
        result = result + 1
  return result

Він задумався над реалізацією методу predictExamFailure(). Очевидно, що реалізація має брати до уваги попередні оцінки студентів, але як саме виразити це в коді — він не знав.

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

* Для здачі екзамену необхідно набрати мінімум 51 бал

Розглянувши результати, Коля повернувся до коду:

def predict_exam_failure(student, exam):
  return student[exam.subject].test1_grade < 51 or student[exam.subject].test2_grade < 51

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

return (student[exam.subject].test1_grade + student[exam.subject].test2_grade) < 100

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

return (0.6 * student[exam.subject].test1_grade + 1.4 * student[exam.subject].test2_grade) < 100

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

def calculate_accuracy(students):
  num_correct = 0
  num_total = 0
  for student in students:
    for exam in student.exams:
      num_total += 1
      if predict_exam_failure(student, exam) == exam.final_grade > 50:
        num_correct += 1
  return 100.0 * num_correct / num_total

Точність

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

Коля витратив дуже багато часу, підбираючи різні варіанти коефіцієнтів у своїй функції, тестуючи її кожен раз на точність. Десь під ранок у нього була функція, точність якої сягала 75%! Самооцінка Колі піднялася до такого ж рівня. Але перед тим як святкувати, він вирішив перевірити точність функції також на студентах інших факультетів. Після чого його самооцінка опустилася до 45%. Очевидно, що він так довго працював над своєю функцію, що «витиснув» з неї максимальну точність на екзаменах свого факультету, але це зробило її ще гіршою для інших. Цю ситуацію називають надмірне навчанняабо перенавчання (анг. overfitting).

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

Зобразивши результати екзамену точками різних кольорів, Коля отримав такий малюнок:

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

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

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

Моделі

Оскільки функція (модель) передбачає провал на екзамені, результат Правда (True) означає, що ми передбачаємо провал, і навпаки, Неправда (False) означає, що вона передбачає успішно зданий екзамен. Надалі ми абстрагуємося від екзаменів і будемо називати записи відповіді позитивними i негативними. При застосуванні та оцінювані моделі ми будемо пам’ятати, що означає «позитивний» в нашому випадку. Метрика точність (accuracy) не залежить від того, що ми називаємо позитивним, а що — негативним, тому що ми рахуємо кількість правильних передбачень.

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

Розглянемо наступний приклад, для простоти запису якого приймемо Х1 = бали за перший тест, Х2 = бали за другий тест. Наша функція виглядатиме так: F(X1, X2: number) => Y: boolean — приймаємо два чисельні аргументи і повертаємо булевий результат. Цю функцію вище ми називали predict_exam_failure().

Для прикладу розглянемо одну з попередніх реалізацій нашої функції:

 F(X1, X2) => 0.6 * X1 + 1.4 * X2 < 100

Виділені константи 0.6 та 1.4наша машина і буде підбирати. Ми будемо називати їх параметрамимоделі і позначатимемо W1 і W2, а Х1 і X2 — це властивостіданих. Y — вихідна властивість моделі. Модель зазвичай має більше, ніж дві вхідні властивості, узагальнений запис функції-моделі виглядає так: F(X1, X2, ... Xn) => Y. Звернемо увагу, що реалізація цієї функції з нашого прикладу матиме N параметрів — W1, W2, ... Wn. Такі моделі називають лінійними. Є багато інших способів зображати моделі, які ми опишемо в наступній статті, якщо буде до них інтерес :)

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

def calculate_accuracy(students, model_func):

Реалізація її залишається такою ж, як вище.

Тренування моделі

У найпростішому варіанті машинного навчання ми будемо використовувати код, який перебере багато різних параметрів і поверне той набір, для яких наша функція демонструє найбільшу точність. Цей процес називають тренуванням (training)моделі. Алгоритм тренування відповідно учителемчи тренером (trainer). Цей код реалізовує тренера для нашого методу повного перебору:

def brute_force_train(data, min_w, max_w, train_step):
  best_model = None
  best_accuracy = 0
  w1 = min_w
  while w1 <= max_w:
    w2 = min_w
    while w2 <= max_w:
      model = lambda datum: w1 * datum[0] + w2 * datum[1]
      accuracy = calculate_accuracy(data, model)
      if accuracy > best_accuracy:
        best_model = model; best_accuracy = accuracy
      w2 += train_step
    w1 += train_step
  return best_model

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

Параметри min_w, max_w, train_stepфункції brute_force_trainназиваються гіперпараметрами (hyperparameters). Набір параметрів залежить від тренера (алгоритму навчання), і їх вказують ті, хто тренує модель. На противагу параметрам W, які власне тренер сам і підбирає.

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

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

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

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

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

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

Розміри наборів для оцінки (і репрезентативність даних в них) є важливими для статистичної значущості метрик, які рахуються на їх основі. Вище ми використовували точність (accuracy) як спосіб оцінки нашої моделі, і для даної проблеми ця метрика підходить. Але давайте припустимо, що позитивні записи є рідкістю, наприклад, модель передбачає ймовірність рідкісної хвороби і тільки 0,1% усіх записів є позитивними. У такому випадку модель, яка всі записи класифікує як негативні незалежно від їхніх властивостей, матиме точність 99,9% — неймовірну високу для будь-якого способу прийняття рішень. Але, як ми розуміємо, користь такої моделі дуже обмежена :)

Висновки

Тепер ми вже можемо дати і визначення.

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

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

Чем чаще упоминают Общий регламент по защите данных (англ. General Data Protection Regulation, GDPR), тем больше появляется трактовок и многочисленных версий законодательства, и тем сложнее становится разобраться и эффективно применить эту информацию на практике.

На самом деле именно на принятие необходимости, изучение и понимание этого вопроса уходит половина отведенного на эту активность времени. Railsware, успешно преодолев этот этап, находится на финальной стадии внедрения принципов GDPR. Хотим поделиться опытом еще и потому, что у нас была возможность пройти этот процесс от А до Я не только как консалтанси, но и как продуктовая компания — внедрив GDPR на Mailtrap, а также Smart Checklist плагине для Jira.

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

Стоит ли бояться GDPR

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

Вам нечего бояться, если вы:

• Не покупаете списки email адресов и не делаете холодных рассылок.
• Открыто говорите о типах персональной информации, которую собираете, то есть предупреждаете посетителей сайта с помощью всплывающих окон о политике конфиденциальности (Privacy Policy), положении, описывающем все cookie-файлы (Use of Cookies, Navigational Information Statement). В этих документах человек сможет прочесть, какие именно персональные данные вы собираете, с какой целью, на какой срок, а также узнать о своих правах.
• Не запрашиваете у пользователей ненужные для работы продукта или предоставления услуг данные.
• Обеспечиваете должный уровень сохранности данных, то есть:
  
  • стараетесь использовать шифрование чувствительных данных;
  • внимательно следите за тем, чтобы чувствительные данные не попадали в логи в чистом виде;
  • по возможности, ограничиваете доступ к продакшен-базе.
• Предоставляете клиентам возможность «отписаться» от рассылок.

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

Почему GDPR-ом интересуются не только в ЕС

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

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

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

С чего начать

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

1. GDPR представил расширенную трактовку персональных данных, которая теперь включает в себя информацию, относящуюся не только к идентифицированному (identified) физическому лицу, но и к тому, которое можно идентифицировать по косвенным признакам (identifiable). Таким образом, концепция персональных данных дополнилась такой информацией, как Client ID и User ID (online identifier), месторасположением и другими факторами, которые имеют отношение к физическому, физиологическому, генетическому, экономическому, культурному и другим отождествлениям человека (личности). В общем этот пункт не вызвал особых проблем, а, скорее, внес ясность, которую мы постарались отразить в официальных документах компании (Privacy Policy, Navigational Information Statement).
2. GDPR установил четкие требования к персональным данным. Они должны быть корректными, актуальными и собираться лишь в том количестве, которое необходимо для работы продукта, предоставления услуги, либо достижения любой другой цели, для которой они запрашивались. Также положение рекомендует сократить сроки хранения этой информации до минимума. Для этого стоит установить четкий временной промежуток, по истечении которого все данные будут пересматриваться (groomed) или удаляться. Этот вопрос вызвал немало споров внутри нашей компании, поскольку такой подход противоречил бытующему мнению, что любые данные — одинаково полезны. В результате мы пересмотрели объемы и сроки хранения персональной информации (а также сроки хранения логов, бекапов и информации в аналитических системах, Google Analytics) и отобразили эти изменения в политике хранения данных (Data Retention Policy).
3. В регламенте есть интересная статья (№ 13, стр. 8), которая, если перевести дословно, говорит, что «регламент включает послабления относительно ведения учета для организаций с менее чем 250 сотрудниками». При этом каждое государство-член ЕС должно принимать необходимые меры по применению регламента на местах. В Польше, например, пытались использовать эту статью и освободить малый бизнес от необходимости соответствовать принципам GDPR, что прилежно обозначили в драфте польского Закона «О защите информации» (Data Protection Act, «DPA»). Но после многочисленных дебатов раздел убрали, а закон отправили на согласование.

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

Как GDPR повлияет на разработку

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

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

«Privacy by design» призывает минимизировать сбор персональной информации, необходимой для работы любого продукта, сервиса или проекта внутри компании. Для этого перед началом какого-либо процесса GDPR рекомендует оценить риски, которым будет подвержен человек (субъект персональных данных) в результате сбора и обработки вашим ресурсом (отделом, сотрудниками) его персональной информации (Data Privacy Impact Assessment). В дальнейшем проведение таких аудитов можно интегрировать в процесс управления проектами и при необходимости повторять на каждом следующем этапе развития проекта.

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

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

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

Что кардинально изменится в работе с персональными данными

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

А именно:

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

Выводы

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

Мы составили один план по имплементации GDPR для продуктов и консалтанси. Но уже в процессе адаптировали каждый его пункт под конкретный проект исходя из:

• Количества клиентов/лидов и их географии.
• Объемов данных, которые продукт или консалтанси собирает и обрабатывает.
• Активностей, связанных со сбором данных. В консалтанси, например, у нас также хорошо развито направление рекрутинга и HR, которое активно собирает и обрабатывает персональные данные аппликантов.
• Каналов, через которые эти данные поступают. Railsware консалтанси получает данные лидов через заполненную на сайте форму, тогда как соискатели могут отправлять нам свои резюме и через другие сайты и платформы. А Smart Checklist for Jira получает лишь минимальное количество данных, потому что основной объем информации собирает и обрабатывает сама Jira.

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

Удачи!

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

Меня зовут Александр Жебряков. Я несколько лет строю собственный бизнес, стремлюсь к возможности работать когда угодно и откуда угодно.

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

Идея

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

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

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

Работаю удаленно в Исландии

Идея Y-Productive родилась, когда мне в руки попала книга «Your Brain at Work»Дэвида Рока. Она написана понятным языком и с примерами, поэтому помогла мне понять главные проблемы, которые бывают у каждого:

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

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

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

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

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

Так и родилась идея Y-Productive — простого приложения, которое помогает понять и улучшить свою продуктивность в контексте рабочих задач.

Реализация

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

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

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

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

График написан при помощи D3.js. Во время разработки мы задавались вопросом — как интегрировать D3 и React, если каждая библиотека хочет управлять DOM? Поделюсь статьей, которая нам помогла. Наш выбор пал на React Faux DOM. Подробнее об этом в статье с детальным разбором подхода. Это решение позволило нам достаточно быстро и без особых трудностей создать рабочий вариант графика, который прекрасно работает и сейчас.

Так как Y-Productive — кросс-платформенное десктопное приложение, в его основу лег Electron. Для front-end части используем связку React + Redux, локально храним данные в NeDB. Также у нас есть небольшой Node.js сервер для авторизации, обработки платежей и прочих мелких задач. Еще мы выпустили браузерные расширения для Chrome, Firefoxи Safari.

Изначально приложение было создано для macOS. За трекинг тогда отвечал трекер ОС, написанный нативно Objective C. Когда мы приняли решение портировать приложение на Windows, возникла необходимость написать нативный трекер под эту ОС. Нужно было обращаться к Win32 API и передавать эту информацию в основное приложение через IPC, но знатоков С++ у нас в команде не было. Мы обошлись решением на .NET, так как он предоставляет обертки над системным API.

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

Focus Mode реализован через расширения для Chrome, Firefoxи Safari. При включении они блокируют отвлекающие сайты. Через них мы также передаем информацию о работе с вкладками. Нативные трекеры работали с ошибками, теряли или путали данные. На тот момент у нас было расширение для Google Chrome. Идея трекать через него еще и сайты оказалась прекрасным решением. В результате мы написали расширения для Firefox и даже для Safari.

Поддержка Safari — это серьезный аргумент при скачивании Y-Productive, так как половина пользователей macOS пользуется только этим браузером. Расширение пришлось писать с нуля, так как у Safari нестандартный API и подход к архитектуре расширений. Релиз в Safari Extensions Gallery проходит ревью, который может занять от одной недели до месяца. Если ваше расширение отклонили, вы получаете уведомление с причиной отказа... или без нее. Для стартапов время — ресурс ценный, и долгие ревью стоили нам целого месяца — мы зарелизились с четвертой попытки. Зато у нас есть очень полезная функция для всех популярных браузеров.

Focus Mode служит барьером для неосознанных действий, помогает понять: «А точно ли я хочу зайти на Фейсбук именно сейчас или отвлекаюсь?» Так мы помогаем сохранить вовлеченность в работу над задачей дольше:

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

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

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

Одна из основных его особенностей — наличие двух связанных между собой процессов Main и Renderer (кому интересно, вот ссылка на документацию). Благодаря тому, что в нашей архитектуре Renderer процесс — это чистый UI (он отрисовывает полученные от Main процесса данные), мы смогли относительно быстро и безболезненно сделать из него веб-приложение. По факту, мы дописали заглушки в тех местах, где Renderer обращался к Main. Очень повезло, что NeDB поддерживает работу в браузере, не пришлось переписывать работы с данными. В итоге демо выложили на Amazon S3 и раздаем через CloudFront.

Приложение мы разместили на собственном сайте. Чтобы выйти на ранних пользователей, использовали рекламу в Facebook и AdWords. Ведем партизанский маркетинг в нишевых блогах, на Quora и Reddit. Последние два ресурса дают хороший результат, именно оттуда приходит большинство пользователей. Подробнее об этом мы рассказали в статье.

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

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

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

У Y-Productive есть все что нужно, чтобы сконцентрироваться над задачей или обнаружить непродуктивные привычки: задачи, проекты и отчеты, отзыв об эффективности, счетчик отвлечений, блокировщик непродуктивных сайтов и очень простой интерфейс. Благодаря этому еще до выхода из беты у нас более 300 пользователей.

Опытным путем мы нашли оптимальные каналы. Y-Productive хорошо подходит людям, которые знают цену своему времени и стремятся работать на результат. Приложением интересуются в таких комьюнити, как IndieHackers, сабреддитах по бизнесу и продуктивности на Reddit, тематических вопросах на Quora.

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

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

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

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

alex@y-productive.com — Саша, СEO Y-Productive
kyrylo@y-productive.com — Кирилл, маркетолог и комьюнити-менеджер:

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

Сейчас я студент магистратуры в Сингапуре, программа «Master of IT in Business». Тема образования и подготовки кадров поднимается в медиа, на форумах регулярно. Надеюсь, что мой опыт дополнит информационное поле и, возможно, даже кому-то поможет.

По сведениям вики, Сингапур (страна № 37 по общему ВВП и № 9 по ВВП на душу населения) тратит на образование 20% национального бюджета. Два сингапурских вуза входят в ТОП-20 в мире, что для страны размером примерно с Киев весьма неплохо. И в целом система считается одной из самых продвинутых в мире — «Thinking Schools, Learning Nations».

Моя специальность — Analytics в School of Information Systems (SIS), Singapore Management University (SMU). Сейчас там готовят специалистов по двум направлениям — финансовая аналитика и аналитика данных. В августе собираются открыть еще одну специальность — искусственный интеллект.

Магистратура считается «postgraduate education», и поступают туда обычно не сразу после бакалавриата, а после нескольких лет работы. Большинство студентов имеют 2-5лет опыта работы, но студентов постарше тоже немало. Расписание сделано так, чтобы учебу можно было совмещать с полным рабочим днем — part-time студенты учатся вместе с full-time. В общем публика разнообразная.

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

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

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

1. Определиться с курсом и сконтактировать с офисом приема студентов, узнать, что конкретно нужно.
2. Сделать перевод документов — диплома бакалавра, например (список может быть длиннее). Перевод нотариально заверенный, но не обязательно локальным нотариусом.
3. Предоставить подтверждение знания английского — обычно и IELTS, и TOEFL подходят.
4. Для магистерских программ — сдать GMAT (The Graduate Management Admission Test) или GRE (The Graduate Record Examinations) с соответствующим проходным баллом.
5. Заполнить официальный application (online), может быть вариант — пройти вступительное интервью. Если все успешно, координатор от университета отправит заявку и выдаст логин и пароль для подачи на визу в системе SOLAR (Student’s Pass Online Application & Registration) и расскажет, когда и куда приходить на matriculation day.
6. Последнее, но, пожалуй, самое главное — иметь достаточно денег на оплату обучения и на жизнь.

Если есть желание (план) оставаться в Сингапуре, при поиске нужно обратить внимание на тип школы. Для начала посмотреть список «Institutes of Higher Learning» — все выпускники этих вузов имеют право подаваться на долгосрочную визу (Long-Term Visit Pass) по окончании обучения. К тому же студенческая виза от вузов из списка будет давать право на работу до 16 часов в неделю. Если выбранная школа не в списке, то после выпуска будет 30 дней социального визита, как по обычной туристической визе, — и все.

Кроме этого, для STP (Student Pass — документ для пребывания в стране, который выдает миграционная служба) в «обычные» школы и IHL подается разный комплект документов. В первом случае надо будет указывать в анкете данные по родителям и членам семьи, их финансовое положение, а также доказывать свою платежеспособность — показывать счет в банке от себя или от поручителя с гарантийным письмом. IHL не требует подтверждения по финансам, но при этом сама программа, скорее всего, будет стоить дороже. В Сингапуре вообще нет бесплатного университетского образования, даже для местных. Стоимость магистерской программы обычно порядка 40 тыс. SGD (30 тыс. USD). Для граждан Сингапура могут быть скидки, но необязательно.

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

В двух словах: если программа обучения в списке (об этом надо узнавать), то можно заключить контракт, при котором часть стоимости (например, половину) заплатит MOE (Ministry Of Education). Для иностранцев это накладывает дополнительные обязательства — такие же как в Украине с «бюджетниками», то есть работа в сингапурской компании в течение трех лет после учебы. Если не отработаешь — возвращаешь потраченные на тебя деньги плюс 10%.

Есть университетские стипендии. Они распределяются в основном по оценкам — прошлым и текущим (да, это то место, где краснота вашего диплома наконец пригодится). Также учитываются баллы, полученные на GMAT. Все очень просто — у кого больше, тот и молодец.

Для моей программы просили любой инженерный диплом бакалавра (не обязательно IT) от «recognizable» университета и GMAT не ниже 560 баллов. Опыт программирования как и опыт в отрасли вообще — не обязателен, но будет преимуществом. На вступительном интервью обсуждали в основном мою мотивацию и ожидания.

Инфраструктура

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

Отдельное пространство на минус первом этаже — фудкорт, банк, несколько кафе, медклиника, турагенство, книжный магазин, служба безопасности (не та которая следит за порядком, а та, которая учит пользоваться AED (automated external defibrillator), и при случае спасает). Чистые туалеты и фонтанчики с питьевой водой.

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

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

Кроме этого, есть три внутренних портала:

1. Для оргмоментов — там можно записываться и бросать курсы (курс можно бросить после двух занятий без незачета по предмету и других последствий), бронировать комнаты для обсуждения в библиотеке, найти все ссылки и все контакты, которые могут понадобиться.
2. Чисто для обучения — с разделами по каждому курсу, материалами для скачивания, списками, онлайн-тестами, форумом и пр. Примерно как на курсере. Туда же, как правило, нужно подгружать свои лабораторные работы, задания и прочее.
3. Для поиска работы и/или интернатуры — с твоим профилем, резюме, вакансиями и разными ивентами для карьерного развития, на которые тут же можно регистрироваться.

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

Learning Environment

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

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

Учебная программа

Для того чтобы закончить обучение, нужно набрать 13 кредитов. Из них два можно закрыть capstone-проектом (похоже на наш дипломный проект) или стажировкой. 1 курс = 1 кредит. Говорят, были курсы по 0,5 кредита, но я их не застала.

Три курса обязательны, все остальное выбираешь сам из расписания, учитывая что в разных термах (1 терм = 4 месяца) преподают разный набор предметов.
При этом есть некоторый минимум из разных блоков, который нужно выбирать — минимум пять моих курсов должны быть из блока аналитики, минимум три — из бизнеса, остальные добирать по желанию — сюда же финансовый блок и блок AI.

На моей специальности обязательные базовые курсы — это «Applied Statistics with R», «Spreadsheets Modeling (Excel)» и «Data Analytics Lab» (с использованием JMP и SAS Enterprise Miner). По умолчанию на них записывают еще в первом терме, четвертый и пятый (5 — это максимум за терм) — на выбор.

На каждом курсе — разные виды работ со своими оценками, которые вместе составляют 100%. Может быть микс из индивидуальных заданий, тестов (open book / closed book), экзамена или нескольких экзаменов, группового проекта. 10-15% —это участие в классе.

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

Стажировка (internship) — та же работа, только на нее не нужно получать разрешение иностранцам, так как существует договор с иммиграционной службой, но, конечно, платят меньше. При этом вся остальная процедура не меняется — нужно отправлять резюме на вакансии, ходить на собеседования, делать тестовые задания и пр. В чем плюс: резюме через университетский портал попадают в верхнюю стопку рекрутера, и с большой вероятностью тебе все же позвонят (обычный поиск «с улицы» из-за большой конкуренции не работает — чаще всего письма идут в никуда). Зарплата у postgraduate интерна — 1500-2000 SGD(1100-1500 USD).Напомню, что годовой доход до 20 тысяч SGD в Сингапуре налогами не облагается.

Capstone project — что-то вроде нашей «дипломной работы» с той разницей, что писать его можно по желанию. Его можно делать под руководством научного руководителя со стороны университета или же где-то в работающем бизнесе. Некоторые компании предлагают стипендии за написание проектов у них и для их целей. Все, конечно же, на конкурсной основе, с этапами собеседований, переговоров и пр. Но и суммы не такие уж и символические, например стипендия от DHL — это одноразовая выплата 7500 SGD (5600 USD) по окончании проекта.

Карьерное развитие и поддержка, менторство

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

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

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

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

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

А еще каждый может попробовать себя в роли teaching assistant на конкурсной основе, университет за это платит 500 SGD (370 USD) за курс.

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

Командная работа

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

Здесь включается очень много факторов. Можно быть лентяем и проехаться «на шару» на своих трудолюбивых коллегах, но на следующем курсе никто не захочет взять тебя в свою команду. Можно наоборот вкалывать, но твой сосед завалит кусок работы — и результат получится на троечку. Плюс культурная разница. В моем проекте по R (мы делали Shiny app) был микс студентов из Сингапура, Индии, Китая, Азербайджана и я — из Украины. И мы неплохо сработались. Но в другой команде был и негативный опыт — необязательность и безинициативность со стороны некоторых сокомандников.

С уровнями заданий — тоже все хорошо. Уже на первый assignment (индивидуальное выполнение) по Data Lab после нескольких лекций мы получили задание с международного Data Challenge. Знаю ребят, которые потратили на его выполнение больше 100 часов. Никто не мешает свои результаты подать потом официально. Это даже приветствуется.

Для группового курсового проекта, кроме прочего, пишешь статью, и она должна отвечать требованиям SAS Global Forum.

Выводы

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

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

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

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

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

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

Я считаю, что прокрастинация — это неопределенность. Она проявляется по-разному, и причины её возникновения тоже разнятся.

Почему возникает прокрастинация

В своей скромной теории я выделяю две главные причины — нежелание и непонимание процесса.

Нежелание

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

Непонимание

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

Как бороться с прокрастинацией

Главный совет — ищите «свой метод», проверяя разные техники на практике, и уверен, у вас всё получится.

Найти энергию

Очень много людей жалуются на то, что они очень устают и поэтому не могут выполнять дополнительную работу. То ли почитать книгу, которая откладывается уже полгода, то ли наконец-то сделать нормальную уборку — нет и всё. Что же мы можем сделать в этой ситуации?

Физические упражнения

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

— Повышается обучаемость

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

— Укрепляется и очищается организм

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

— Улучшается сон

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

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

Медитация

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

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

В своей книге «Зависимый мозг»Жадсон Брюер отлично рассказывает о том, что такое медитация, как она способна изменить вашу жизнь и помочь бросить вредные привычки. Если же у вас нет времени, чтобы прочитать целую книгу (а она шикарна и стоит прочтения), то можете воспользоваться приложением Prana Breath.

Сон

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

Хобби

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

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

Отдых

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

Найти мотивацию

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

Всё начинается с формулировки

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

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

Подталкивающие мысли

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

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

Просто начни

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

Осознай

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

Исключить непонимание

— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно... — сказала Алиса.
— Тогда все равно, куда и идти.

Бесцельная деятельность

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

Понимание процесса

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

35\7 = 5. Проект\задачи = рациональный план

Разумно ли тратить время на деление задач на подзадачи, когда можно их просто делать? Этот вопрос не имел бы смысла, если бы всё было именно так просто, но, к сожалению, человек — существо сложное. Чем проще кажется задача — тем больше вероятность её выполнения. Когда делим задачи на подкатегории, мы избавляемся от абстрактности и не упускаем важные составляющие.

В грамотном планировании помогает дополнительный софт. На своём телефоне я использую Business Calendar в связке с Habit Loop Tracker. На компьютере стоит Y-Productive — программа, помогающая сфокусироваться на главном. Также для более долгосрочных целей помогает Evernote и Trello.

Выстраиваем маркеры

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

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

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

Что думают программисты

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

Артур Решетников, Software Engineer в Y-Productive

Как прокрастинация проявляется

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

Суть прокрастинации

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

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

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

Как бороться

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

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

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

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

Максим Корабельский, Senior JavaScript Developer в Devico solutions

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

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

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

Дмитрий Усик, Android Software Developer в Riseapps

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

1. Список дел должен быть написан от руки (это позволит подробнее продумывать свои дела и способы их решения);
2. При выполнении какого-либо дела — зачеркивать пункт в списке. Это позволит визуализировать результаты и будет показывать вам, что вы не стоите на месте;
3. При накоплении большого количества зачеркнутых пунктов нужно переписать оставшиеся дела на новый лист бумаги. Это позволит избавиться от желания отложить оставшиеся дела на потом. В итоге новый список дел будет пополнятся новыми пунктами, и совсем скоро это войдет в постоянную привычку.

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

Выводы

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

Полезные книги:

Максим Дорофеев «Джедайские техники»
Джон Рейти «Зажги себя»
Брэд Сталберг, Стив Магнесс «На пике. Как поддерживать максимальную эффективность без выгорания»

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

Любые вопросы вы можете задать мне в Telegram.

А что вам помогает бороться с прокрастинацией? Пишите в комментариях свои способы!