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

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

Продукт — это не код

Необходимо понять, что обычно клиенту не нужен код. Ему нужен продукт, который приносит деньги. Поэтому вовсе не обязательно, чтобы у этого продукта был классный код с минимальным техническим долгом. Вы можете выбрать менее популярный stack, не самые модные инструменты. Критически важно лишь одно: полученный продукт должен решать поставленные задачи. И здесь, к слову, необходимо учитывать, в каких условиях работает клиент, например зависимость от сторонних сервисов (Auth0, Twilio и т. д.).

Технический долг как инструмент

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

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

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

Рекомендованные подходы с React

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

Среди основных подходов, на которые я рекомендую обращать внимание — использование модульной структуры. Я долгое время работал на бэкенде. Потом — fullstack-ром. Мне понятен и близок MVC-подход,где группировка компонентов происходит по типу данных (Model, View, Controller). С другой стороны, когда я перешел полностью во фронтенд и React в частности, то сделал для себя вывод, что группировка по модулям/компонентам — более профитная. Мы можем один компонент перенести в другой конец приложения, и это будет приемлемо. Ни для кого не секрет, что когда проект развивается, папка components разрастается и может стать необъятной при MVC-подходе,когда файлы группируются по назначению.

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

Отдельно хочу отметить, что командная разработка и разработка одним девелопером могут сильно отличаться. Если ты один на проекте, полностью знаешь его, то многие вещи можно упразднять. Например, можно прокидывать пропсы spread оператором (<Component ...props />). Но работа в команде требует четкого понимания процесса от всех участников. Переопределение тех же атрибутов позволит человеку за соседним столом не подниматься по всему дереву компонентов, а сразу видеть, какие из них передаются (<Component attr1={props.attr1} attr2={props.attr2} />). Для командной работы также очень актуальна типизация данных, определение PropTypes и defaultProps.

Redux — как инструмент для работы с данными

Помимо работы с компонентами, необходимо понять, где и как будут храниться данные. Например, сейчас я занимаюсь проектом Vantage (Transport Management System) — портал для перевозчиков и заказчиков перевозок. Для работы с данными наша команда использует Redux. Одна из основных причин, почему мы остановили наш выбор на нем — девелоперов с опытом Redux гораздо больше, чем с другим.

Основное преимущество Redux — это управление как состоянием данных, так и состоянием интерфейса. Redux — единственный источник истины при разработке. Все очень упрощается, когда ты знаешь, где искать последнюю и актуальную информацию. Есть множество способов и подходов при работе с Redux. Лично мне нравится duck-подход. Утиная типизация. Ее смысл можно передать английским выражением: «If it walks like a duck and it quacks like a duck, then it must be a duck». («Если нечто выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть»).

Концепт этого подхода заключается в том, что мы группируем в одном месте все модули: action creators, actions, reducers. Например, в нашем проекте мы все модули храним с компонентами. Есть подход группировки по constants, actionCreators, actions в отдельных файлах. Я пробовал такой подход в самом начале работы с Redux, и, на мой взгляд, намного проще, когда все сгруппировано именно в компонентах.

Работа с функцией высшего порядка

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

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

compose(
	withUsers,
	withBirthdays,
	withPresents,
	withoutYellow
)(BirthdayPresents)

Среди минусов — полная зависимость от порядка вызова. Например, если мы поменяем местами withUsers<code> и <code>withPresents, то наш HOC не сможет справиться с задачей — так как withPresents не найдет списка юзеров, что может быть обязательным параметром. Кроме того, HOC может сам менять данные. И когда мы столкнемся с такой проблемой, нам нужно будет сначала понять, что у нас с этим есть проблема, а в большинстве случаев это может быть сложно. Для ее решения, нам нужно либо писать новый HOC (такой же как исходный с некоторыми изменениями), либо править уже существующий, что может сломать логику в исправно работающих местах. Это основные подходы, которые мы используем в нашем приложении Vantage.

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

Хотелось бы еще затронуть тему настройки сборки на старте проекта. Есть старый добрый способ: подключаем bower или npm, конфигурируем webpack, настраиваем все сами. Это долго. Как правило, чтобы сократить время, конфигурация с предыдущего проекта просто переносится на новый. И казалось — работает и работает. Но по факту, мы перенесли устаревший код, и это может стать проблемой и ограничением. Поэтому мне больше нравится использование boilerplates. Самый популярный сейчас — Create React App от Facebook. Всего одной командой он конфигурирует все приложение.

Мой фаворит — React Redux Starter Kit, который, к сожалению, уже не поддерживается из-за появления React Router 4. Не поддерживает и plain routes в полном объеме — а они были основой этого boilerplate.

Работа со стилями

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

Есть JSS-подход. Мы работаем в JS и постоянно генерируем свои специальные классы. На проекте может быть сотня файлов с классом container. Но JSS каждый раз генерирует новый класс (container-1, container-2...). В таком случае эти стили мы можем хранить в компоненте. Что важно — стиль из одного компонента не может изменить стиль другого компонента без нашего участия. Это позволяет инкапсулировать данные. Функционал JSS библиотек, по большей части, соответствует функционалу препроцессоров.

Перед началом нового проекта

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

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

Выводы

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

Удачи с выбором «правильных» инструментов.

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

Першу в КНУ імені Тараса Шевченка вільну лабораторію робототехніки та мікроелектроніки Relab на факультеті радіофізики, електроніки та комп’ютерних систем (ФРЕКС) було відкрито у вересні 2017 року. Відтоді вона стала платформою для тих, хто хоче навчатися, розвиватися, знаходити однодумців та колег, реалізовувати власні ідеї та стартапи. Мене звуть Роман Куриленко, я студент 1 курсу магістратури факультету РЕКС та один з авторів ідеї цього проекту. Зараз я відповідаю за фандрайзинг та з’язки зі ЗМІ. Я розкажу, як створювалася й розвивається наша лабораторія.

Ідея

Навесні 2013 року на радіофізичному факультеті КНУ (теперішній ФРЕКС) на базі однієї з лабораторій виник безкоштовний гурток робототехніки. Ним керували засновники UA-Robotics та Heli, тоді ще наші студенти Віта Гайдар та Сергій Батарчук. Ми мали певне обладнання (плати Arduino UNO та набір модулів до них), а також дружній колектив, що прагнув навчитися. Гурток об’єднав близько десяти студентів-початківців у програмуванні мікроконтролерів. Через кілька місяців у гуртку залишилося 5 найбільш зацікавлених студентів, а ініціатива переросла в проект автоматизованої системи догляду за кімнатними рослинами «Eco-Box». На першому фестивалі роботехніки в Дніпрі цей проект отримав номінацію «Most Useful». Але головне в усьому цьому те, що ми здобули велику ідею: майбутнє нашого факультету не може існувати без робототехніки та ІоТ.

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

Відкриття лабораторії Relab 20 вересня 2017 року

Реалізація

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

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

Лабораторію було створено спільними зусиллями Студентського парламенту та адміністрації факультету за підтримки компаній Melexis, EPAM, Viakom. Melexis надала великі та зручні комп’ютерні столи, EPAM допомогла із комп’ютерним обладнанням (стаціонарні комп’ютери у повній комплектації), а Viakom надала базові електронні компоненти та інструменти, а також подарувала справжній 3D-принтер.

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

Відео студентського телебачення університету про Relab:

Перспективи та можливості

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

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

Кожного буднього дня в лабораторії працюють зацікавлені студенти, до команди яких може приєднатися будь-хто, хто хоче чомусь навчитися або втілити в життя свою ідею. Науковим керівником та ментором більшості студентів став заступник декана з наукової роботи доцент Вячеслав Францович Борецький. Проте і самі студенти допомагають одне одному: більш досвідчені навчають студентів молодших курсів, підтримують їх, коли вони цього потребують. Одним із найактивніших резидентів лабораторії є співавтор проекту, студент 3 курсу спеціальності «Телекомунікації та радіотехніка» Роман Андрійчук.

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

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

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

До розробки та реалізації ідеї розумного факультету «Smart Rex» долучилися усі активісти та резиденти лабораторії Relab, а також представники провідних молодіжних організацій КНУ імені Тараса Шевченка: Студентського парламенту університету (СПУ), Студентської ради студмістечка (СРС), — зокрема голова СРС Олександра Тиркалова. Якою стане оновлена лабораторія, побачимо вже восени цього року.

Наші контакти
Facebook: www.facebook.com/groups/416391268735797
Telegram: t.me/smartrex
Телефон: +38 (073) 419-74-15 (Роман)

[Катя Осадчук — СEO Indigo Tech Recruiters, экономист, профессиональный психолог и в прошлом HRD с более чем 10-летнимопытом]

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

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

Как обычно зарождается бизнес?

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

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

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

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

Собственник не может заряжать своим энтузиазмом каждого из 1000 сотрудников

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

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

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

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

Разрыв происходит даже в таких компаниях, как Apple. В 1985 совет директоров уволил Джобса и компания пошла вниз. Такая же история была и со Starbucks и Dell. И всем собственникам пришлось вернуться. Почему? Потому что они ушли вместе с энергией, миссией, видением, креативностью, которая не была передана дальше. Она была в их головах, в их личностях, в их харизме.

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

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

То, о чем вы думаете, что делаете и о чем говорите, — должно совпадать

Есть 2 способа ведения бизнеса:

1. Через вдохновение, доверие, отношения, общие цели и ценности.
2. Через манипуляцию или стимулирование.

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

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

Когда человек открывает крышку Maка в кафе, он хочет показать всем: смотрите, я креативный, я успешный, в моих ценностях — think different. Я — особенный.

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

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

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

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

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

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

Операционные круги бренда

Технологии не помогают формировать доверие

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

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

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

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

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

Для того, чтобы у компании были последователи — нужны 3 важные вещи

1. Мы должны понимать, зачем мы делаем то, что делаем.
Если мы не знаем, то как об этом будет знать кто-то еще? И это про миссию. Да, цель каждой компании заработать деньги, цель каждого человека — обеспечить себе и близким комфортную жизнь, и это тоже про деньги. Но не все про деньги.

2. Мы должны определить, как мы это делаем.
И это про видение и про ценности. По каким принципам мы работаем, а по каким нет.

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

Люди верят в то, во что верим мы. Они становятся приверженцами так называемого бренда.

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

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

Ах да... при условии, что нанят толковый СЕО. Но об этом в другой раз...

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

Петр Кореневпочти 2 года работает в Sigma Software, занимается разработкой под iOS около 6 лет. Часто выступает на конференциях, а также участвует в их организации: на его счету подготовка и проведение CocoaHeads Ukraine и UMT.

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

О себе

Я увлекаюсь программированием очень давно, где-то с 12 лет. Мне очень нравилось что-то создавать, начинал с графических программ в консоли. Тогда у меня еще не было компьютера: я ходил по родственникам, компьютерным клубам, уделял внимание информатике в школе. Поэтому, когда пришло время поступать вуз, вопрос о направлении не стоял. Я выбрал специальность «Компьютерные системы и сети» в ДонНТУ.

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

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

Впоследствии я за 6 лет поработал в 5-тиаутсорсинговых компаниях — в Донецке, затем в Днепре и Киеве. В Sigma Software пришел в августе 2016 как Senior/TeamLead iOS Developer.

Последние несколько лет я часто выступаю на конференциях (из последних — ITEM, CocoaHeads Ukraine, SE в Киеве), провожу тренинги и воркшопы. Чувствую ответственность перед сообществом, которое вырастило меня как профессионала, и хочется отдавать ему «долг». К тому же, очень мотивирует, когда после выступления ко мне подходят люди и говорят, что им очень понравилось.

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

Рабочие обязанности

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

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

Как правило, в Sigma сотрудники уровня Junior и Middle задействованы в одном проекте. Люди Senior+ разделяют свою экспертизу и время между несколькими разными проектами. Я сейчас работаю параллельно на двух. Один из них — в сфере Advertisement, другой — из игровой индустрии. Также сейчас начинаю работу над проектом в области Embedded.

Кроме этого, я занимаюсь preSales-активностями: помогаю оценить потребности нового клиента, перспективы проекта.

Если говорить о моих обязанностях как соорганизатора конференций CocoaHeads Ukraine и UMT, то я — технический модератор. Работаю со спикерами, заранее просматриваю их слайды, даю советы, как можно улучшить их выступления. Занимаюсь техническим оснащением, слежу за количеством розеток, доступностью Wi-Fi на локации, организовываю видео- и аудиозаписи выступлений. На подготовку одного митапа CocoaHeads уходит порядка 150-200 часов.

Типичный рабочий день

7:00-9:00.В это время я просыпаюсь, готовлю завтрак себе, жене и коту, затем еду на работу. В дороге обязательно что-то читаю — как правило, это статьи, которые отложил для чтения за предыдущие дни.

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

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

20:00.Еду домой. Офис Sigma расположен на Подоле — и утром, и вечером тут страшные пробки. Обычно я стараюсь «пересидеть» это время в офисе и выезжаю, когда дороги становятся более свободными.

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

Сейчас работаю над двумя тренингами — по темам Performance testing in Swiftи Mobile products security essentials. Они пройдут на базе Sigma Software University в мае и июне. Это довольно-таки большие мероприятия, которые требуют серьезной подготовки. Стараюсь выделять время для работы над ними каждый день.

Инструменты и продуктивность

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

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

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

Все коммуникации по рабочим проектам веду через Slack, также пользуюсь Telegram и Jira. Для разработки — Xcode. Люблю приложения, которые упрощают жизнь, — к примеру, книги и банкинг в телефоне.

Активно использую Google-календарь: планирую там все встречи и активности.

Почту и мессенджеры проверяю постоянно. Стараюсь отвечать на письма по рабочей почте ASAP — это позволяет выглядеть перед коллегами обязательным и пунктуальным. Facebook и Twitter в рабочее время стараюсь не проверять.

Я не использую какие-то особые практики по продуктивности, это происходит скорее интуитивно. Работая над проектом, постоянно задаю себе вопрос: «А не фигню ли я делаю?». Это помогает оптимизировать свои занятия.

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

Времени на отдых мне хватает, я не могу сказать, что работаю совсем на износ :) Перегрузить мозг позволяет телик — просмотр каких-то бессмысленных программ, типа «Голос країни». На эти 3 часа ты превращаешься в «диванного овоща» и неплохо расслабляешься. Также я раз в несколько месяцев путешествую и работаю из других стран — это тоже помогает перезарядиться.

Книжки и самообразование

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

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

До этого читал «Продавец обуви»Фила Найта. Это история успеха компании Nike, рассказанная ее основателем, — очень вдохновляющая.

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

Ретроспектива и планы на будущее

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

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

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

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

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

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

Мечты о продуктах

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

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

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

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

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

Готовность номер один

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

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

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

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

Критерии успеха

Теперь представьте себе, что вы владелец или CEO компании с теми самыми кофемашинами. По каким-то причинам вы решили передать на аутсорсинг разработку IT-системы для ваших кофеен. Какую информацию вы должны передать исполнителям, чтобы бизнес оставался эффективным? Business vision и Target audience: кто покупает у вас кофе, где места с высокой проходимостью. А также показатели, сигнализирующие, что продукт нужно подстраивать или менять. В данном случае таким показателем будет среднее количество покупок в день. Эксперименты можно ставить очень быстро: провести на месте целый день, учесть погодные условия. Казалось бы, не надо быть ни Эйнштейном, ни Коперником.

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

1. Кто и как сможет определить, успешен проект или нет?
2. Кто будет спрашивать, успешен ли проект?

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

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

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

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

Погружение в бизнес

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

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

Выводы

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

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

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

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

[Сергій Хлівненко — менеджер проектів у Lucky Labs. Упродовж останніх 7 років співпрацював з компаніями «Дотик технологій», Panasonic та Yaware, яким допомагав створювати та виводити на ринок власні ІТ-продукти. Основна експертиза та сфера інтересів: інформаційні технології, блокчейн, маркетинг, сучасна енергетика. Організовує тренінги із систематизації життя «Life Project Management»]

Я щодня вирішую задачі, пов’язані як з людьми, так і з процесами та проектами. Більшість із них вимагають комплексного підходу у виборі інструментів — для побудови ефективних комунікацій, проектування, досягнення результату «win-win» у домовленностях із замовником... Вирішив підготувати підбірку книжок про сучасні моделі менеджменту, аби допомогти початківцям зорієнтуватися у актуальних підходах в управлінні проектами. Порядок книг не випадковий: перші три найбільш концептуальні, демонструють чітку методологію сучасного менеджменту; дві останні більш практичні і для щоденного використання. Сподіваюся, ви знайдете їх корисними для себе.

Don Edward Beck, Christopher C. Cowan «Spiral Dynamics: Mastering Values, Leadership and Change»

В російському перекладі — Дон Бек, Крис Кован «Спиральная динамика. Управляя ценностями, лидерством и изменениями в XXI веке»

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

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

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

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

Клер Грейвз

Donella H. Meadows «Thinking in Systems: A Primer»

В російському перекладі — Донелла Медоуз «Азбука системного мышления»

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

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

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

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

Frederic Laloux «Reinventing Organizations»

В українському перекладі — Фредерік Лалу «Компанії майбутнього»

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

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

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

«Коли люди займаються осмисленою справою, коли вони мають право приймати рішення і у них є ресурси для здійснення ідей, їм не потрібні ні запальні промови, ні начальник, аби їх мотивувати».

Daniel H. Pink «Drive: The Surprising Truth About What Motivates Us»

В українському перекладі — Даніель Пінк «Драйв. Дивовижна правда про те, що нас мотивує»

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

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

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

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

«Один бізнес-лідер висловився з приводу мотивації цілком буквально. Коли він проводить співбесіду при прийомі на роботу, то потенційним працівникам заявляє: «Якщо вам потрібно, щоб я вас мотивував, то я, ймовірно, не найматиму вас».

David Allen «Getting Things Done: The Art of Stress-Free Productivity»

В російському перекладі — Дэвид Аллен «Как привести дела в порядок: Искусство продуктивности без стресса»

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

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

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

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

[Об авторе: Николай Лотоцкий — более 15 лет занимается разработкой программного обеспечения. Знаком со всеми этапами работы на проекте и развил карьеру от должности QA Engineer до Technology Expert. Несколько лет был JavaScript Software Architect и принимал активное участие в разработке сложных масштабируемых приложений. Кроме того, есть опыт работы с PHP, .NET, Python. Более трех лет проводит различные курсы и тренинги]

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

Техлид хочет видеть в соискателе самого себя

Сначала давайте разберемся, кто создает описания вакансий? Их создают техлиды. Как по мне, основная проблема в том, что каждый техлид хочет видеть в соискателе самого себя. То есть берем свой опыт, отнимаем от него 5-6 лет,берем свой багаж технологий, отнимаем от него то, что за эти 5 — 6 лет совершенно устарело, и вуаля — готовы требования к кандидату. По итогу нам нужен перспективный джун с опытом работы не менее 10-12 лет,со знанием PHP, JavaScript, .NET и Python и желанием выучить GoLang. После этого добавляется английский, знание процессов и методологий гибкой разработки. И как вишенка на тортике — «Большим плюсом будет»: опыт работы с BigData, опыт в создании нейронных сетей и т. д. Так гордо вырисовывается пунктиром портрет вашего техлида, помолодевшего на 5 лет и не отягощенного знаниями COM, VisualBasic и WinForms.

Когда рекрутер получает такую заявку, полагаю, что волосы у него на голове и не только на голове, встают дыбом. Потому что, если и есть такой человек, то это Толик из R&D, который составил описание требований и который и так уже работает у нас. Далее все бегут к проектному менеджеру, к которому, собственно, человек и пойдет работать, а он гордо заявляет рекрутерам: «Такие люди есть, и их много, вы просто плохо ищете». Ну и, как говорится, завертелось.

Зреет всеобщее недовольство

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

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

Что делать

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

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

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

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

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

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

Итак

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

Шел 22-йгод моей жизни или же 2016, если считать по общепринятым меркам. Я уже больше 2-хлет занимался разработкой под Android, и это неплохо у меня получалось. Работал в компании Eastern Peak Software, только получил диплом бакалавра ХНЭУ по специальности, близкой к Computer Science, и готовился к поступлению на магистерскую программу двойного диплома.

Однажды летом мне передали, что учительница информатики Яна Валентиновна Ефимова (дальше просто ЯВ) просит провести несколько уроков информатики в моей родной школе — ОСШИ II-IIIступеней «Одаренность» в Харькове. Целью занятий была подготовка школьников к олимпиадам по программированию (это когда нужно решать простые задачи на алгоритмы за определенное время). Предлагали вести 2 занятия в неделю на протяжении 2 семестров. Учительница обратилась ко мне, потому что у меня уже был опыт в этом деле: 2 года участия в школьных олимпиадах и 5 лет участия в университетских олимпиадах по спортивному программированию.

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

2016 учебный год

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

Занятия проходили как обычные уроки (первые 2 урока по четвергам), но оценки я не выставлял и присутствующих не отмечал — это было мое пожелание, которому администрация школы не стала препятствовать. Как организовывать занятия и какие темы рассматривать, определял я сам — в основном это было именно олимпиадное программирование с использованием C++. Посещение было свободным, поэтому приходили только те, кому было интересно — большая часть класса и еще несколько учеников из других классов.

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

• Неглухой телефон.
• A+B.
• Зарплата.
• Пятью пять — двадцать пять!
• Единицы.
• Скачки.

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

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

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

Code Marathon 1.0

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

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

Призовых мест было 6: 1 первое, 2 вторых, 3 третьих. Призы — фитнес-браслеты Xiaomi и флешки. Спонсорами стали я и ЯВ, призовой фонд — около $100.

CodeMarathon 1.0 начался 20 октября 2016 года и закончился 20 января 2017. На протяжении всего этого времени мы раз в неделю вывешивали листик A4 в кабинете информатики с первыми 6 участниками на текущий момент. Конкуренция была, но не сильная. Решили довольно много задач (в среднем по 25 на одного участника).

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

В этом же году один из школьников (Коваленко Юра) занял 3-еместона Всеукраинской олимпиаде по информатике в г. Ровно.

2017 учебный год

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

Ученики были с разной подготовкой. С одной половиной 11-Вя уже занимался в прошлом году (это были в основном олимпиадники), поэтому с ними мы разбирали довольно сложные алгоритмы и структуры данных. Со второй группой 11-В (которые были вроде как не очень расположены к программированию, именно так изначально поделились группы) мы довольно быстро прошли весь базовый синтаксис C++ и тоже под конец перешли к олимпиадным задачам. С 9-Ау нас было в 2 раза меньше времени, поэтому с ними мы успели пройти только синтаксис С++. Но и там были отдельные люди, которые быстро перешли на онлайн-курсы и сами смогли освоить Python (необходим для длинной арифметики) и STL в С++ (нужен за счет всех плюшек vector, set, map, sort).

На уроках мы в основном решали контесты, созданные на базе тестирующей системы DOTS, разработанной и поддерживаемой Арзубовым Николаем Алексеевичем. Это тренер по олимпиадному программированию для школьников в Харькове, учитель информатики в гимназии № 45, руководитель МНО «Q-BIT». Система действительно очень удобная, на ней же проходят областные олимпиады в Харьковской области.

Code Marathon 2.0

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

Первые шаги

Результаты на листе А4 раз в неделю? Конечно, нет. Нам определенно нужен был сайт с обновлением результатов онлайн. Поскольку я мобильный разработчик, то создание сайта вызывало у меня много вопросов. А время поджимало, поэтому я решил, что пора начинать регистрацию на соревнование, а уже потом по ходу делать сайт. Форму для регистрации я сделал на Google Forms с сохранением этого всего добра в Google Sheets. Для того, чтобы иметь доступ к этим данным с любого устройства, я решил использовать БД на Firebase. Для синхронизации я использовал сервис Zapier, который дергает Cloud Function из того же Firebase. В итоге все данные после регистрации оказываются на Firebase в удобной для работы форме.

Для решения проблемы с разрывом в уровне подготовки было решено разбить участников на 2 дивизиона. Div1 — для опытных олимпиадников, Div2 — для остальных. Но 9 классу было морально тяжело соревноваться с 10 и 11, поэтому для них был добавлен еще Div3. При этом, если было желание, они могли регистрироваться и в Div2, и в Div1.

Для подсчета текущего рейтинга было необходимо для каждого участника стягивать его страничку ACMP, доставать из нее данные и отправлять их на Firebase. Для этой цели я написал небольшое консольное приложение на Kotlin, которое каждые 10 минут выполняло описанную выше процедуру. Поначалу все это работало у меня на ноуте, поэтому работало не постоянно. Это было явной проблемой, поэтому я искал варианты, где бы это запустить. Бесплатные сервера типа Amazon EC2, Google Cloud Engine у меня по какой-то причине поднять не получилось (возможно, из-за отсутствия опыта). В итоге в голову мне пришла идея запустить мой скрипт на Raspberry PI — оставалось только ее раздобыть...

Поскольку в соревновании теперь было целых 3 дивизиона, то и призовых мест соответственно должно было быть больше в 3 раза. Я решил поискать дополнительных спонсоров среди своих друзей. К нам присоединились моя девушка Алла Дубовская и сокомандники по спортивному программированию Дмитрий Смерчинский и Виталий Обидейко. Благодаря им призовой фонд вырос до 6000 грн, и мы смогли позволить себе приобрести Raspberry PI Model 3B в качестве приза за первое место в Div1. Полный список призов можно посмотреть здесь.

Полный призовой фонд

Соревнование стартовало 2 ноября 2017 года. Пора было приниматься за сайт. Немного погуглив, я наткнулся на очень простое решение — сделать сайт на основе примера на Node.js от Heroku. Табличка с результатами была готова в течение 3 часов и залита на тот же Heroku.

Для того, чтобы усилить конкуренцию и поощрить общение между участниками, я создал чаты в Telegram, по одному на каждый дивизион. Кроме этого я сделал простенького Telegram-бота, который каждые 10 минут писал о том, кто и какие задачи решил и сколько рейтинга набрал. Если посмотреть на графики набранного рейтинга по дням (c 10 по 20), то 2 эти действия определенно сильно повлияли на активность участников чемпионата.

Суммарный набранный рейтинг по дням (X — день соревнования, Y — рейтинг)

Разработка

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

Я разослал приглашение по чатам и стал ждать — откликнулось 8 человек. Думаю, что желающих было больше, просто побоялись, что не справятся :) Контингент был абсолютно разный — кто-то умел только немного С++, кто-то умел Git и JS.

То есть, по сути, это была команда, в которой один опытный разработчик (это я о себе так скромно говорю) и 8 стажеров. Процесс работы мы организовали в стандартном виде — таски на GitHub, митинги раз в неделю, общение в чате Telegram и в живую, Git, Git flow и остальные серьезные штуки.

Часть задач выполненных во время марафона

Под конец марафона все школьники освоили базовые команды консольного Git, умели запускать сайт на Node.js локально, верстали на HTML/CSS, немного писали на JS и Kotlin. Полный список разработчиков можно посмотреть здесь.

Итоги

Второй чемпионат проходил на протяжении 81 дня. За это время зарегистрировалось 56 участников — 54 из них решили хотя бы одну задачу. В сумме школьники решили более 4000 задач, набрав при этом более 85 000 рейтинга. Максимальный набранный рейтинг — 8259, для сравнения мой текущий рейтинг на ACMP — 12836, а всего можно набрать — 28753.

По завершении Code Marathon 2.0 был проведен опрос, в котором приняло участие 26 респондентов. Вот несколько интересных графиков:

И напоследок несколько ответов на вопрос «Что вам больше всего понравилось в Code Marathon 2.0?»:

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

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

Выводы

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

• Очень умные, талантливые и перспективные ученики, которым можно указать путь развития, помочь определится с будущей профессией. У меня было несколько учеников, которые считали себя неспособными к программированию, а в итоге поднялись на уровень с лучшими программистами класса. В этот момент чувствуешь, что поменял чью-то жизнь к лучшему и от тебя есть хоть какая-то польза.
• Опыт организации занятий для большого количества участников (15-20)так, чтобы всем было интересно и полезно.
• Пространство для творчества и применения своих навыков программирования в реальной предметной области.
• Ревью кода — это на постоянной основе. Смотришь на код ученика и думаешь, как такое можно было написать :) А нужно разобраться и помочь сдать задачу — ты же учитель. А потом проходит несколько месяцев, и этот человек пишет уже хороший, понятный и даже красивый код. И ты понимаешь, что в этом есть и твоя заслуга.
• И, конечно, когда готовишь и проводишь уроки, сам лучше разбираешься в предмете.

Ссылки

• Официальный сайт чемпионата
• Исходный код приложения на Kotlin
• Исходный код сайта
• Вспомогательные скрипты
• Тестирующая система DOTS
• Презентация с награждения
• Исходный код Code Marathon 1.0
• ACMP
• Сайт школы

Мои контакты: LinkedIn, GitHub, Instagram.

Всем привет! Март порадовал Ruby-сообщество множеством интересных событий.

Прежде всего, вышли официальные версии Rails 5.0.7 и 5.1.6, а также бета-версия фреймворка Hanami — v1.2.0.beta2. Во-вторых, появились первые бенчмарки превью-версии Ruby 2.6 с JIT. Также обратите внимание на статьи Daniel P. Clark о Vue.js в качестве фронтенд-фреймворка для приложений на Rails.

Почитать

Ruby 2.6 preview 1: Timing JIT — в конце февраля вышла превью-версия Ruby 2.6, а уже в марте появились первые бенчмарки. Насколько эффективен JIT-компилятор? Все ответы — в статье.

Towards The Ruby 3×3 Performance Goal — узнайте, как сообщество Ruby работает над проектом CRuby и сможет ли версия 3 в три раза превосходить по производительности версию 2.

If the OS landscape was disrupted, would Ruby have survived until today?! — Keynote by Mr. Yukihiro «Matz» Matsumoto at Ruby25 — не пропустите главное из речи создателя языка Ruby Юкихиро Мацумото (Matz) на конференции Ruby25.

A New Ruby Application Server: NGINX Unit — обзорная статья о том, насколько сервер приложений Nginx подходит для приложений на Ruby.

TIOBE Index for March 2018 — Ruby вытеснил Delphi в первой десятки рейтинга популярности языков программирования по версии TIOBE.

Passenger 5.2.2: passenger_base_uri fixed, new Phusion product spoiler — если ваше приложение использует сервер Passenger, то самое время сделать апгрейд до версии 5.2.2. В статье говорится, как это сделать.

RabbitMQ is more than a Sidekiq replacement — автор подробно рассказывает о преимуществах RabbitMQ в сравнении с Sidekiq при работе с фоновыми задачами.

Practical Differences between Working in Ruby and iOS — на основе собственного опыта автор сравнивает разработку на Ruby и Swift; статья будет полезна full-stack программистам, а также тем Ruby-программистам, которые собираются попробовать себя в мобильной разработке под iOS.

My thoughts on Hanami — Райан Бигг делится своим мнением о Ruby-фреймворке Hanami.

Implementing a basic debug mode for your Ruby CLI — автор подробно описывает, как настроить сообщения об ошибках с помощью имплементации отладочного режима для Ruby CLI.

How I Built Timeasure: Part 1 — Motivation & Method Wrapping — первая статья из цикла, в котором автор детально описывает процесс создания гема Timeasure.

Solving CAPTCHAs with TensorFlow and Ruby — узнайте, как научить Ruby-приложение автоматически преодолевать капчи с помощью инструмента TensorFlow.

Using `yield_self` for composable ActiveRecord relations — автор рассказывает о том, как метод yield_self можно использовать в работе с Active Record.

Why proxying Bugsnag (or similar service) might be a good idea?— на примере сервиса проверки качества кода Bugsnag автор показывает, как проксировать сообщения об ошибках через back end.

An overview of Desktop Ruby GUI development in 2018 — краткий обзор инструментов для создания desktop-приложений на Ruby.

Setting up a Rails app for CodeBuild, CodeDeploy, and CodePipeline on AWS — читайте, как настроить continuous integration/delivery/deployment Rails-приложения с помощью сервисов AWS.

The correct emails configuration in Rails — простые советы о том, как правильно настроить отправку имейлов в Rails-приложениях.

Ruby on Rails: 5 Checks to Make Before Launching Your App — чек-лист по пунктам, на которые стоит обратить внимание перед запуском вашего Ruby on Rails приложения.

Use Ruby Objects to Keep Your Rake Tasks Clean — автор делится опытом оптимизации Rake-задачи с помощью объектов в Ruby.

Why Service Objects are an Anti-Pattern — многие Ruby-разработчики используют service objects в Rails-приложениях, однако автор статьи считает этот подход неверным. Узнайте почему!

Introducing Blueprinter — Blueprinter — новый инструмент для форматирования и сериализации API.

Is Ruby on Rails a Good Framework for Building a SaaS product?— в статье подробно разобран вопрос, насколько Ruby on Rails подходит для создания SaaS-приложений.

Qyu: A distributed task execution system for complex workflows — автор рассказывает о новом инструменте для распределения задач для Ruby.

Better passwords in Ruby applications with the Pwned Passwords API — если вы хотите обеспечить максимальный уровень защиты аккаунтов пользователей, используйте Pwned Passwords API.

From Rails to Clojure, then to Java, then back to Rails — почитайте мнение автора о нескольких языках программирования, а также плюсы и минусы каждого из них.

Rails test coverage: Measuring what matters with SimpleCov — статья рассказывает, почему важно анализировать степень покрытия кода тестами при помощи библиотеки SimpleCov.

Why should you learn multiple programming languages?— даже если вы первоклассный специалист по Ruby, не стоит пренебрегать другими языками программирования. Почему? Автор делится своим мнением.

Monitoring Sidekiq Using AWS Lambda and Cloudwatch — функционала Sidekiq может быть недостаточно для анализа обработки фоновых задач; данная статья расскажет, как это исправить с помощью AWS Lambda.

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

Подборка от Mensfeld

• Kafka on Rails: Using Kafka with Ruby on Rails — Part 2 — Getting started with Ruby and Kafka — во второй статье об Apache Kafka автор рассказывает, как запустить Kafka в Docker контейнере и настроить message publishing из Rails приложения с помощью WaterDrop.
• Karafka framework 1.2.0 Release Notes (Ruby + Kafka) — ознакомьтесь с подробным описанием новой версии фреймворка Karafka для Apache Kafka.

Подборка от Arkency

• Rails Event Store — better APIs coming — статья рассказывает о новых APIs в Rails Event Store v0.26.
• Using singleton objects as default arguments in Ruby — автор показывает, как использовать синглтон-объекты в качестве параметров по умолчанию.
• Ruby Event Store — use without Rails — узнайте, какие улучшения ожидают вас в Ruby Event Store v0.27.

Подборка от Engine Yard

• Memcached Security aka Don’t Attack GitHub — недавно хакеры использовали Memcached-сервер для атаки GitHub. В статье о том, как защитить Rails-приложение от подобных атак.
• Ajax on Rails with Unobtrusive JavaScript — автор подробно рассказывает, как использовать Ajax в Rails-приложениях.
• Pros and Cons of DevOps as a Service — узнайте о плюсах и минусах услуги DevOps as a Service.
• Using Rails and Vue JS, Part 1 — первая статья из цикла об использовании JavaScript-фреймворка Vue.js при создании Rails-приложения.
• Rails Encrypted Credentials Use AES 128-bit Key — статья отвечает на вопрос, безопасно ли 128-битноешифрование в функции Credentials в Ruby 5.2.

Подборка от BigBinary

GPG decryption without pin entry pop up using GPGME — краткое руководство о том, как раскодировать файлы, зашифрованные с помощью инструмента GnuPG (он же GPG).

Также продолжение серии статей о Ruby 2.5:

• Ruby 2.5 prints backtrace and error message in reverse order — автор показывает, как Ruby 2.5 облегчает отладку исходного кода благодаря обратной структуре сообщения об ошибках.
• Ruby 2.5 adds Exception#full_message method — в Ruby 2.5 добавлен новый метод, позволяющий отображать обработанные исключения так же, как и необработанные.

Подборка от AppSignal

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

Подборка от Paweł Dąbrowski

• Build your own RSpec — introduction to DSL and metaprogramming — автор показывает, как с помощью DSL и метапрограммирования можно создать аналог RSpec, популярного фреймворка для тестирования Rails-приложений.
• Ruby on Rails — your own slow query log, no sql configuration required — статья показывает, как документировать медленные запросы в Ruby on Rails; это облегчает рефакторинг кода и помогает разработчикам ускорить работу приложений.
• 4 ways to refactor and speed up RSpec tests — узнайте о 4 способах провести рефакторинг и ускорить тесты, написанные при помощи RSpec.
• 3 things that slow down and make your RSpec tests worse — советы по ускорению тестов на RSpec.
• 4 cool less known Rails features — part 1: ActiveJob, ActiveModel, command line — первая часть цикла статей, в котором автор делится опытом и рассказывает о некоторых малоизвестных возможностях Ruby on Rails.

Подборка от Nopio

• How to Setup Rails Application on Heroku — Redis, Sidekiq, Action Cable and Cron Configuration — статья описывает процесс установки Rails-приложения на хостинг Heroku, подробно останавливаясь на настройке отдельных элементов инфраструктуры.
• Blockchain App with Ruby — блокчейн — одна из самых горячих тем в мире технологий; эта статья расскажет вам, как создать децентрализованное приложение на Ruby.

Подборка от End Point

• Multi-Tenant Architecture — автор рассказывает о том, как реализовать multi-tenant архитектуру в Rails-приложениях с помощью гема Apartment.
• Rails Active Storage — узнайте, как с помощью Active Storage в Rails 5.2 можно загружать файлы в облачные хранилища (AWS, Google Cloud и Microsoft Azure).

Туториалы

Capistrano deploy to ubuntu with systemd, nginx/puma and rbenv — туториал по развертыванию приложения и (или) среды разработки на одном сервере при помощи Capistrano.

Bare Bones Rails Action Cable Tutorial — туториал по созданию чат-сервера при помощи Action Cable.

Upgrade Rails from 4.2 to 5.0 — статья обращает внимание на важнейшие аспекты при обновлении Rails-приложения с версии 4.2 до 5.0.

How to Track Down and Fix Slow Active Record SQL Queries in Rails — недовольны производительностью своего Rails-приложения? Не спешите вносить изменения в стак, возможно, проблема в базе данных, а этот туториал научит вас оптимизировать работу Active Record SQL запросов.

How I’ve Built a Profitable Slack Bot as a Side Project in Rails — чатботы становятся все более популярны; почитайте, как создать Slack-бота при помощи Ruby on Rails.

The Proxy pattern revisited — узнайте, как использовать Proxy дизайн-паттерн при помощи метода Module#prepend.

How to run Capybara feature specs with Selenium and headless Chrome — CircleCI 2.0 case study — туториал учит, как избежать проблем с популярными инструментами Capybara и Selenium при переходе с CircleCI 1.0 на CircleCI 2.0.

Yes, Ruby 1.9 can support TLSv1.2!— можно ли использовать TLSv1.2 в приложении на Ruby 1.9? Да! И этот туториал покажет, что нужно делать.

Only use named scopes outside models — как улучшить организацию кода и увеличить продуктивность, используя поименованные области действия.

Memoizing in Ruby — туториал по оптимизации работы приложения с помощью мемоизации.

The Local Variable Aversion Antipattern — многие Ruby-разработчики избегают локальных переменных, предпочитая извлеченные методы, однако насколько этот подход хорош? Автор делится опытом и показывает, как можно использовать локальные переменные.

Grpc Tutorial With Ruby — автор решил обновить руководство по настройке grpc для Ruby.

Convert an ActiveRecord object into the fixture — туториал демонстрирует, как превратить объект ActiveRecord в yaml формат.

Refactoring views with Ruby on Rails’ ActiveSupport helpers — автор делится опытом рефакторинга кода при помощи инструментария ActiveSupport.

JSON API Phase 3: API Server — третья из четырех статей цикла о разработке API при помощи Express и Swagger; в этой части описан процесс создания API сервера.

Dry Behaviour aka Protocol Pattern in Ruby — как использовать паттерн Protocol при создании приложения на Ruby.

Managing db schema changes without downtime — автор показывает, как избежать проблем при изменениях схемы данных в Rails-приложении.

JSONify your Ruby Translations — узнайте, как использовать формат JSON для Ruby трансляций.

How to test logs using RSpec expectations and StringIO in Ruby — статья показывает два способа тестирования логов.

UPGRADING TO RAILS 5.1X — разработчик компании RED Panthers делится опытом обновления одного из продуктов до версии Rails 5.1.

Focused `puts` debugging with STDERR — туториал поможет провести отладку не только написанного вами кода, но также кода используемых вами гемов.

Elapsed time with Ruby, the right way — узнайте, как правильно запрограммировать подсчет времени выполнения в Ruby-приложении.

JetRockets

• How we started using Redux-Form in our Rails apps — если вы используете фреймворк React для фронтенда в своем Rails-приложении, то этот туториал покажет вам, как использовать Redux и Redux-Form.
• Protocol OAuth2: let’s play with Doorkeeper & Omniauth/OAuth2. Part 1.— первая статья из цикла о протоколе OAuth2 рассказывает, как создать сервис авторизации с помощью Rails и Doorkeeper.

RubyGuides

• The Definitive Guide to Loops in Ruby — статья научит вас нескольким способам создавать циклы в Ruby.
• How to Write a Ruby C Extension — автор детально описывает, как создать расширение C для увеличения производительности Ruby-приложений.

Codeship

• VueJS as a Frontend for Rails — популярность Vue.js растет и самое время узнать, как использовать его в качестве frontend-фреймоворка в Rails-приложениях.
• VueJS Components with CoffeeScript for Rails — продолжение предыдущей статьи; автор показывает, как использовать компоненты Vue.JS с помощью CoffeeScript в Ruby on Rails.

Релизы

Rails 5.0.7 and 5.1.6 have been released — официально вышли новые версии Rails: 5.0.7 и 5.1.6. Узнайте, что изменилось по сравнению с предыдущими версиями!

Announcing Hanami v1.2.0.beta2 — вышла бета-версия фреймворка Hanami v1.2.0.beta2.

Rails 5.2.0 RC2: Active Storage, Redis Cache Store, HTTP/2 Early Hints, CSP, Credentials — Rails-сообщество завершает работу над новой версией нашего любимого фреймворка. Узнайте, что нового во второй предвыпускной версии 5.2.0 RC2.

NGINX Unit Beta — вышла бета-версия сервера приложений Nginx с поддержкой Ruby.

Ruby Gems

Interesting Methods — этот новый гем позволяет быстро просмотреть методы объектов в Ruby.

Deferral — гем позволяет использовать в Rails-приложениях метод defer по образцу Golang.

Pwned — Pwned позволяет использовать Pwned Passwords API для Rails.

Послушать

241: Upgrading Kickstarter to Rails 5 with Logan McDonald — ведущие подкаста обсуждают обновление приложения Kickstarter с Rails 4 на Rails 5.

The Bike Shed

• 147: Is a Lambda a Sandwich?— ведущие обсуждают новинки в Ruby 2.5, в том числе разницу между понятиями block, proc и lambda.
• 144: Fisher Price™ Tools — в этом подкасте авторы обсуждают повестку апрельской конференции RailsConf 2018, опыт использования Rails Твиттером и многое другое.

Ruby Rogues

• RR 352: React on Rails and Webpacker with Justin Gordon and Rob Wise — ведущие обсуждают библиотеку React on Rails, Webpacker (адаптация Webpack под Rails), а также многие другие интересные темы.
• RR 354: Music, Musicians, and Programmers with Catherine Meyers — послушайте увлекательную историю Кэтрин, которая сменила карьеру оперной певицы на карьеру успешного Ruby-разработчика.
• RR 353: Removing Business Logic from Rails Controllers with Aaron Sumner — ведущие обсуждают, как убрать бизнес-логику из Rails-контроллеров, преимущества и недостатки служебных объектов и многое другое.
• RR 355: Code Reviews with Jacob Stoebel — данный подкаст важен каждому разработчику, так как ведущие обсуждают анализ кода, делятся опытом и дают полезные советы.

RWpod

• 09 выпуск 06 сезона. Passenger 5.2.1, Flutter beta 1, Clowne, Pain Points of GraphQL, Reactive Search, Flatbush, Prompts и прочее
• 11 выпуск 06 сезона. Desktop Ruby GUI development, Let’s Encrypt support wildcard certificates, SmooshGate, IDEA и прочее
• 10 выпуск 06 сезона. Using Genetic Algorithms in Ruby, Standardizing lessons learned from AMP, AppBandit, Risk, Coördinator, Mutag и прочее
• 12 выпуск 06 сезона. Towards The Ruby 3×3 Performance Goal, Code editors for Mac, Webdash, ScrollBooster и прочее

Greater Than Code

• 073: Driven By Need, Guided By Example with Dan North
• 072: Story Time with Kerri Miller
• 071: Brein Power with Rein Henrichs
• 070: Trusting The Universe with Kale Kaposhilin

Посмотреть

Method Driven Development — автор описывает Method Driven Development (MDD) — технику, которую он использует при работе с гемом Geocoder.

Develop a Messenger Bot in Pure Ruby — Andy Barnov — Не пропустите видеотуториал о том, как создать чатбота на Ruby при помощи фреймворка Rubotnik.

CSV & XML Injections — YYCRuby Presentation — презентация Гэвина Миллера с митапа YYCRuby; узнайте, как предотвратить CSV и XML injections.

Новая подборка от GoRails, в которой ведущий рассматривает возможности ActiveStorage в Rails 5.2, а также учит создавать шаблоны для Rails-приложений:

• Debugging & Fixing a Bug in Rails 5.2 Active Storage
• How to Create an Active Storage Previewer
• Rails 5.2 ActiveStorage Introduction
• Rails Application Templates

Подборка платных скринкастов от Drifting Ruby в марте

• #123 Encrypted Credentials in Rails 5.2
• #124 SimpleMDE and ActiveStorage
• #125 Turbolinks 5
• #126 Turbolinks iOS Hybrid App

Мартовские выпуски платных скринкастов от Ruby Tapas

• www.driftingruby.com/...​turbolinks-ios-hybrid-app
• Episode #518: Humane Exceptions with Hiro Asari
• Episode #519 — Supporting Different Service Versions with OO — Emily Stolfo
• Episode #520: Bundler Tips and Tricks with Andre Arko

События

Remote Ruby — 5 апреля пройдет ежемесячный онлайн-ивент Remote Ruby. Идеально для тех, кто хочет быть в курсе событий в мире Ruby, не выходя из дома!

Rails Girls Rotterdam — 14 апреля в Роттердаме Rails Girls проведут бесплатный однодневный воркшоп.

Конференции

Ruby Meditation #21 — еще не поздно зарегистрироваться на Ruby Meditation, которая пройдет Харькове 14 апреля. Вас ждут интересные и полезные доклады, живое общение и дружеская атмосфера.

RailsConf — если у вас открыта виза в США, не пропустите RailsConf 2018, крупнейшую Ruby-конференцию в мире, которая пройдет 17-19апреля в Питтсбурге, штат Пенсильвания.

Isle of Ruby — с 13 по 15 апреля в Великобритании пройдет Isle of Ruby — фестиваль, где разработчики делятся опытом и отдыхают всем Ruby-комьюнити.

RubyConfBY 2018 — 21 апреля в Минске пройдет третья конференция RubyConfBY. Темы включают ускорение Ruby при помощи JIT-компилятора и перспективах использования языка Ruby в машинном обучении.

Касательно тем/материалов/ивентов, которые стоит добавить в следующий выпуск дайджеста, пишите в комментариях или на volodymyr.vorobiov@rubygarage.org. Спасибо за помощь в подготовке дайджеста команде RubyGarage.

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

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Java Next

(!) Вышла JDK 10, и это значит, что ваша Java 9 уже устарела

(!) Style Guidelines for Local Variable Type Inference in Java

Про Java 10 от Josh Long

Java 10: Parallel Full GC in G1GCот Heinz Kabutz

109 New Features In JDK 10. Я не пересчитывал, если что.

А для тех, кто не хочет пользоваться устаревшими технологиями, JDK 11 Early-Access Builds

Spring Next

(!) Вышел Spring Boot 2.0

Micrometer: Spring Boot 2’s new application metrics collector

Actuator in Spring boot 2.0. Еще немного про мониторинг Spring Bootприложений

Testing auto-configurations with Spring Boot 2.0. Делает ли кто-то из читателей свои автоконфигурации? Если да, то было бы интересно услышать о вашем опыте.

Servlet and Reactive Stacks in Spring Framework 5

Что-то вроде новостей

(!) Eclipse MicroProfile 1.3

Java EE Becomes Jakarta EE и pdf-ка с возможными логотипами Jakarta EE

Вышел JUnit 5.1.0. Поэтому поводу вопрос: Я единственный, кто все еще пользуется 4-йверсией?

Вышел Infinispan 9.2.0.Final

Вышел WildFly 12

Вышел WildFly Swarm 2018.3.3

Вышел Payara 5

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

(!) Почему люди возвращаются с Gradle на Maven. Несмотря на то, что я не планирую переходить с Gradle, статья довольно точно описывает проблемы этого сборщика.

Такой себе Spock для JUnit и Cucumber

CountDownLatch and CyclicBarrier

(!) CountDownLatch vs CyclicBarrier vs Phaserот Heinz Kabutz

Разное

(!) jEnv — довольно актуальная штука (на подобии rvm), с учетом релизного цикла Java

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

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

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

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

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

Поради начальникам

• Не визнавайте, що ви не знаєте чогось, інакше вас вважатимуть слабким. Завжди можна змінити тему розмови і повернутись до неї пізніше після відповідної підготовки або ж не повертатись ніколи, якщо не хочеться.
• Баланс між особистим та робочим життям — це всього лише модне, лівацьке словечко, виправдання, щоб працювати менше. Справжній успіх досягається важкою, невпинною працею. Не соромтеся писати повідомлення, листи вашим підлеглим чи навіть телефонувати після роботи, на вихідних та під час свят. Спостерігайте, як швидко вони відповідають. Іноді можна надіслати листа цілій команді чи навіть особисто запушити коміт посеред ночі, щоб продемонструвати, що на відміну від них, ви ніколи не відпочиваєте, і змусити їх почуватись винними.
• Не діліться ніякою інформацієюпро цілі та плани компанії з підлеглими. Менше знають — краще сплять.
• Попри всю привабливість Scrum як підходу, в ньому все ж є один фатальний недолік: стендапи трапляються лише раз в 24 години, а це ціла вічність. Ви повинні цікавитись прогресом щонайменше кожних кілька годин, в ідеалі — особисто. Так ви можете переконатись, що люди не байдикують і відчувають достатньо тиску, щоб не збавляти темп до наступної перевірки.
• Щодо процесів — це всього лише інструменти. Кому, як не вам, знати про всі поточні і нові пріоритети? Не соромтесь переривати будь-який процес та розставляти пріоритети заново.Якщо робити так достатньо часто, ваші підлеглі будуть готові до будь-чого і не зважатимуть на відсутність конкретних цілей. Це по-справжньому гнучко!
• Щоб краще планувати проекти — розбийте їх на якомога більше маленьких шматків та оцініть кожен з них наперед в годинах. Ваш начальник оцінить таку деталізацію в плануванні!
• Не засмучуйтесь щодо скасування чи перенесення запланованих зустрічей з вашою командою в останній момент. На відміну від підлеглих — ви зайнята людина і ваш календар не знає відпочинку.
• Інший спосіб досягати більше та натренувати вашу команду, як справжніх «Морських котиків», — це розумові вправи з перемикання контексту. Час від часу давайте підлеглим по кілька різних завдань, які потрібно виконувати одночасно та насолоджуйтеся подвійним чи потрійним приростом продуктивності!
• У певний момент ви відчуєте, що знаєте своїх підлеглих краще, ніж вони знають самих себе. Пора приймати рішення за них, щоб уникнути низької продуктивності! Один із перевірених часом способів — це призначати конкретні завдання конкретним підлеглим замість того, щоб дати автономії (інше словечко, що насправді маскує анархію) шанс закрастись у вашу команду. Підлеглі повинні відчувати абсолютну, особисту, майже батьківську відповідальність за виконання кожного призначеного та оціненого вами для них завдання!
• Ваші підлеглі повинні завжди пам’ятати, що помилки недопустимі. На кожну помилку повинен бути знайдений винуватець і жорстко покараний. З іншого боку, такі помилки часто перетворюються в прекрасні, невмирущі жарти для вечірок: «А пам’ятаєте, як Петя завалив базу даних в продакшені? Пацан ще кілька днів ходив білий, як папір, і пив валер’янку! Ха-ха-ха-ха!».
• Чесно кажучи, ви насправді не можете довіряти підлеглим, колегам чи людям загалом, але ви вже це, мабуть, знаєте.
• Коли настане час давати підвищення підлеглим, обирайте лише своїх друзів чи людей, що ніколи не піддають сумніву ваш статус та не задають дурних запитань.
• Ніхто не ідеальний: знайдіть кілька недоліків чи слабких місцьу кожному з ваших підлеглихта пам’ятайте про них, щоб мати причину відмовити у підвищенні, коли вони попросять. Це перевірений спосіб тримати їх самооцінку низькою і змушувати працювати більше.
• Коли ваш начальник злий і невдоволений роботою вашої команди — обов’язково передайте цю злість та невдоволення на своїх підлеглих. Вони повинні відчувати весь гнів та повну особисту відповідальність працювати ще краще, щоб встигнути до встановлених термінів!
• Але все-таки краще не зізнавайтесь своєму начальнику, коли є проблеми в роботі. Скажіть, що все добре, а самі використайте всі важелі впливу на своїх підлеглих, щоб вони усунули проблеми якнайшвидше і будь-якою ціною.
• Проекти зазнають невдач через недосвідченість вашої команди. Проекти стають успішними завдяки вашим унікальним лідерським якостям.
• Бути начальником означає контролювати все. Не дозволяйте будь-яким зовнішнім комунікаціям зійти з вашого радару: ваша команда не повинна консультуватись, розмовляти чи навіть дивитися в бік інших команд, не кажучи вже про інших начальників.
• Навіть якщо ви вже давно не писали ніякого програмного коду чи зовсім не маєте технічного досвіду — ви все одно повинні знати краще за підлеглих, які інструменти, технології, архітектури чи програмний дизайн вони повинні використовувати для вирішення задач.

Поради членам команд

• Не стримуйтеся, коли розмовляєте — говоріть так голосно, щоб колеги вас чули навіть в навушниках.
• Робота — це нудно. Час від часу розважайте колег посиланням на кумедну картинку чи зачитуванням останніх новин.
• Час — це гроші. Коли ви застрягли з якоюсь проблемою, не витрачайте навіть п’яти хвилин дарма на пошуки відповіді в Googleчи на спроби розібратися самостійно — одразу запитайте колегу. Бажано особисто.
• Коли не можете вирішити якусь проблему та соромитесь зізнатися в цьому — невинна брехня на стендапі допоможе виграти кілька годин, а то і днів часу.
• Один з найкращих способів зберігати позицію і мати повагу колег — володіти таємними знаннями. Тримайте при собі все, що дізнаєтесьі вивчите про вашу роботу та професію, щоб уникнути конкуренції.
• Додайте трохи складності в проект, коли відчуваєте, що він надто простий і легкий для розуміння. Інакше в чому ж ваша цінність як працівника, якщо ваш проект може збагнути і взяти на себе будь-хто?
• Інший спосіб залишатися затребуваним на ринку професіоналом — знати якнайбільше сучасних технологій та фреймворків. Використовуйте нові мови програмування та технології на кожному новому проекті. Якщо немає нових проектів — час від часу переписуйте існуючі з використанням новинок.
• Вас не повинні звинувачувати у помилках колег. Переконайтеся, що всім відомо, чия помилка це була.
• На противагу попередньому пункту, не соромтесь розповідати усім про ваші навіть найменші досягнення, щоб отримувати визнання та повагу.
• Працюйте лише над своїми завданнями. Не витрачайте час на допомогу колегам, це не входить у ваші обов’язки.
• Якщо є можливість — обирайте лише цікаві завдання. Рутиною нехай займаються інші.
• Намагайтеся уникати присутності більш досвідчених та талановитих колег, бо є ризик виглядати погано на їх фоні.
• Час від часу в присутності інших задайте колезі ніби мимохідь якесь складне запитання, на яке він точно не знає відповіді. Здобудете захоплення усіх інших вашими знаннями та досвідом.
• Хочете бути кращими за інших у своїй команді та отримувати підвищення? Просто працюйте більше!Якщо ви працюватимете всього лише на дві години довше за колег щодня, це дасть вам щонайменше 40 годин фори щомісяця!
• Не витрачайте час на комунікацію. Говоріть якомога менше під час зустрічі з колегами. Нехай додумують решту самі, а хто не зрозумів — його проблеми.
• Під час робочої суперечки не соромтесь поділитись посиланнями на блоги та статті відомих у вашій сфері людей, щоб довести щось колегам. Перекрийте точку зору колег стороннім авторитетом замість того, щоб вислухати її.
• Результати вашої роботи — це продовження вашого «Я», це ваше дитя, частина душі. Не дозволяйте критикувати вашу роботу нікому!
• Не соромтесь скаржитися на недосконалі рішення чи процеси. Рано чи пізно знайдеться хтось, хто нарешті все полагодить!
• Якщо колега не справляється з роботою — це тому, що він лінивий або дурний. Якщо ви не справляєтесь з роботою — це тому, що так складаються обставини.
• Будьте оптимістичними, оцінюючи складність завдань.

Висновок

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

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

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

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

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

Идея

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

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

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

Александр Пойманов, создатель CLAP

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

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

Поэтому мы решили объединить в нашем продукте все лучшие решения по автоматизации и сделать ставку на доступной цене при качестве премиум-класса.

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

Реализация

Создание CLAP, включая проектирование, разработку и тестирование, заняло 3 года. В общей сложности мы вложили в R&D около 7 млн долларов.

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

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

Команда CLAP

Если говорить о стеке технологий, мы использовали Java, Spring (MVC, Boot, Integration, Security), JMS, реляционные и нереляционные базы данных, Docker, Selenium, Cucumber. На сервере — микросервисная архитектура.

Для производства «железа» и всех необходимых микросхем мы построили в Виннице автоматизированную линию сборки. Оборудование закупали в Южной Корее и США.

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

Каким получился продукт

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

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

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

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

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

За время разработки мы несколько раз меняли дизайн датчиков, уменьшая их размеры. Конечные размеры устройств стали на 30-50%меньше, чем были первые прототипы. Речь идет не только об эстетике форм: от геометрии датчиков зависит и качество — к примеру, простота и легкость крепления.

Функциональность

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

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

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

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

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

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

С лета 2018 года CLAP будет устанавливаться в новых домах «Укрбуд»: мы заключили эксклюзивный контракт на более чем 160 тыс. устройств для 20 тыс. квартир. В то же время, пока длится контракт, мы не можем сотрудничать с другими застройщиками в Киеве.

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

Привет, меня зовут Влад, и я ... (нет, не то, что ты подумал) я — тимлид. «Войти в АйТи» случилось со мной в 2010 году на позиции системного администратора (или как сейчас стильно-модно-молодежно — SRE) маленькой сервисной компании, название которой нельзя произносить вслух :)

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

Если ты, как и я когда-то, мучал или продолжаешь мучить себя вопросом: «Есть ли жизнь после Senior?», то спешу с ответом — есть. Это либо все тот же Senior, когда ты любишь писать код с закрытыми глазами, при этом помешивая ложкой свой кофе, и это на самом деле ок! Либо архитектор, либо тимлид. Давай на последнем мы и остановимся.

Последние два года я работаю на позиции Team Lead в компании Provectus. Моя команда насчитывает 11 человек. И за этот период я собрал опыт, которым и хочу с тобой поделиться.

Так, мы уже определились, что с технической стороны ты определенно крут, но какими софт скиллами ты должен обладать на позиции Senior+ / Team Lead? Однозначный ответ дать достаточно сложно. Слишком много переменных и обстоятельств. Проект, команда, стиль управления, бизнес-боли, которые ты лечишь, — все это катализаторы различных навыков человека.

SOLID. Что в себе несет аббревиатура, понимает даже Middle Developer. Но не каждый осознает, какую цель преследуют эти принципы. На первый взгляд, все они направлены на стандартизацию и улучшение качества кода. Но если это так, то зачем размножать и без того описанные best practices? Будь то PSR, если говорить о PHP, или Coding Guidelines в случае с Java.

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

S — Smart

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

Окей. Мы с тобой пришли к факту knowledge sharing. Но к чему тут Smart? Делиться опытом или навыками — та еще головная боль. При неправильном подходе, например, выдаче готовых решений, которые ты генерируешь на сверхзвуке, велика вероятность получить команду кодеров. Кодер — существо ленивое, но результативное. Результативное в тех случаях, когда нужно решить задачу в лоб по описанию тикета. Но стоит ему выйти из зоны комфорта и столкнуться с проблемами — впадает в состояние стазиса. Отключаются все органы и функционирует только один — «пойди к гуру, он точно знает решение».

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

O — Obvious

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

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

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

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

L — Loyalty

Лояльность — композитное понятие. Оно проявляется во многом, начиная от пропаганды культуры и до общения 1-2-1.

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

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

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

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

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

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

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

А как насчет геймификации? Это работает! Преобразуй рутину в соревнование, где соперником для каждого является его «Я», а целью — командные достижения. Пример из нашего опыта: каждый успешный pull request засчитывается в общий счетчик достижений команды. Достигая определенных значений, приложение выдает achievement и усложняет достижение новой цели. Если кто-то допускает критическую ошибку (например, в разрез прописанным стандартам разработки) — команда голосует, счетчик обнуляется и виновник торжества ставит всем пиво. Назвали мы это Beer Mistake. Чем дальше прогресс, тем пристальнее и ответственнее ребята подходят к решению своих задач.

С применением подобной геймификации мы получили метрики производительности. Да-да, всякие Jira считают Burn Down, но это не про клиентские или менеджерские графики. Это про внутреннюю производительность, которую оценивает команда.

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

I — Initiative

Тут все просто. Развивай в себе навыки определения узких мест. Это может быть дырка в технологии или методологии. Внутренние процессы и стандарты. Или даже «мониторы должны смотреть на восход». Фундамент — это аргументация предлагаемых решений. Инициатива не проявляется в указании пальцем в сторону проблемы, а выражается в способах её решения.

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

D — Driver

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

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

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

Ты не начальник. Ты — лидер. Никто не любит боссов, кроме человека-кодера, которому нужны четкие задачи и оплата. Мы в своей практике упразднили вертикальный стиль управления. Строгая горизонтальность! Junior ты или Architect, не имеет никакого значения. Твое мнение — это Грааль. Мы работаем ради общей цели, а различает нас только круг обязанностей. Лидер всегда находится в лодке, а не у штурвала. Управлять лодкой можно и без руля, общими усилиями ;)

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

В заключение

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

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

Находите общий язык и вершите великие дела. Спасибо за внимание, у меня все :)

Полезное чтиво

Том ДеМарко «Deadline. Роман об управлении проектами»

Том ДеМарко «Человеческий фактор: успешные проекты и команды»

Ричард Брэнсон «Теряя невинность»

Робота техрайтера в Україні стає все затребуванішою. До прикладу, на момент написання цієї статті у розділі Technical writer на DOU міститься 56 вакансій. Парадоксальною особливістю цієї професії є те, що їй ніде не навчають. Спеціалізованих програм з technical writing немає ні в українських, ні в європейських університетах. Нібито такі програми все ж є в кількох університетах США, але навіть якщо і так, їх випускники навряд чи коли-небудь задовільнять попит на українському ринку праці.

Сьогодні в Україні налічується декілька сотень техрайтерів. Нещодавно з’явилася спільнота у Facebook Technical writers of Ukraineдля обміну досвідом і організації зустрічей. Тож як вони потрапляють у професію? Де навчаються і як знаходять своє перше місце роботи? Про це ми запитали українських техрайтерів з різних IT-компаній.

Заряна Ніколаєва, Information Manager в NetEnt

3 роки в техрайтингу

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

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

Згідно з описом вакансії вимагали, перш за все, гарну англійську. Зрозуміло, що професії Technical Writer у нас не вчать і що більшість додаткових навичок опановуватиметься в процесі. Тестове завдання мало визначити все: мій рівень володіння мовою, вміння дотримуватись заданого стилю, увагу до деталей і творчий підхід. Воно складалось із завдання на опис функцій гри та завдання на аналіз існуючого опису. Досвід копірайтингу став у пригоді! Чимала складність для мене полягала в тому, що такі ігри (відеослоти) я ще не бачила, і тому спочатку аналізувала їх сама, а потім описувала, як для таких самих новачків — щоб точно все було зрозуміло :)

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

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

Я намагаюсь популяризувати техрайтинг серед свого кола знайомих. Минулого року NetEnt разом зі спільнотою Girls in IT організували лекцію про цю професію, її плюси та мінуси та необхідність для бізнесу. Якщо вас цікавить Technical Writing, непогано буде про нього почитати або навіть розпитати знайомих, оскільки це дуже різноманітна сфера. Кожна компанія має свою специфіку — хтось пише інструкції для користувача, хтось правила гри, хтось описує функціонал програми. Треба знайти те, що буде цікаве саме вам.

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

Евгений Чеканов, Technical writer в Betlab

2 года в техрайтинге

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

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

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

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

Профессиональный рост.Я вот уже год в продуктовой компании, осваиваю новые шаблоны документации (BRD и Concept), изучаю MadCap Flare (интересная и мощная вещь, но не без изъянов). В перспективе считаю, что при должном изучении процессов анализа и менеджмента райтер может без особых усилий расти в сторону бизнес-анализа и управления проектами. Работа на данной позиции обязывает вникать в весь продукт и во все его направления и нюансы, и зачастую бывает так, что райтер владеет большей информацией, хоть и верхнего уровня, по продукту в целом.

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

Олег Романенко, Technical writer у GlobalLogic

понад 5 років у техрайтингу

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

Складно згадати, коли я вперше дізнався про професію техрайтера, можливо, нагуглив, але пам’ятаю розмову з моїм колегою в останньому ЗМІ, де я працював. Колега відповідав за розробку сайту нашого інформагентства. Він порадив мені спробуватись на техрайтера або бізнес-аналітика.

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

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

Поради людям, які хочуть стати техрайтером, але не знають з чого почати. Учіть технічну англійську. Я почав з того, що роздрукував «Microsoft Manual of Style» і читав його з ручкою, зазубрюючи незнайомі слова. Забудьте про рідномовну локалізацію своїх додатків, завжди обирайте американську англійську. Читайте англійською, гугліть англійською. Учіть основи програмування та баз даних. Це дасть вам можливість спілкуватися з розробниками їхньою мовою.

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

Марина Кібченко, Technical Writer в AltaReturn

4 роки в техрайтингу

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

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

Перша робота техрайтером. Під час написання магістерської роботи я паралельно допомагала колишньому колезі з домашнім завданням з технічної англійської, де треба було написати досить об’ємну інструкцію користувача до якоїсь програми. Подібного досвіду в мене не було, як, в принципі, і вимог до інструкції: більш-менш пристойного тексту було б достатньо, щоб закрити модуль. Проте завдання видалося мені цікавим, я ґрунтовно підійшла до справи, багато читала про технічну документацію. Оцінка за роботу була високою, і колега сказав: «А ти ніколи не думала працювати техрайтером? Мені здається, у тебе добре вийшло б. У нашій компанії є вакансія».

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

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

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

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

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

1. «Як писати?» — опанування навичок техрайтингу (специфічні програми та додатки; стиль письма, формати тощо).
2. «Про що писати?» — здобуття загальнотехнічних навичок, які зокрема допоможуть зрозуміти програму чи web-рішення, яке необхідно описати.
3. «Що писати?» — робота з вузькоспеціальною англійською, моніторинг галузевої термінології.

Це все не так складно, як може здаватися. Раджу бути допитливим, кмітливим і уважним до деталей.

Карина «Карен» Сорей, Technical Writer/Editor в Cossack Labs

3,5 года в техрайтинге

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

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

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

В Cossack Labs я попала благодаря DOU. Когда я на какое-то время решила отдохнуть от бешеного темпа работы в шоу-бизнесе и пофрилансить, меня спонтанно начали «хантить» рекрутеры в соцсетях. Активно я работу тогда не искала, но решила посмотреть, что вообще происходит на рынке вакансий для техрайтеров. И нашла на DOU вакансию от Cossack Labs, которая мне так понравилась, что cover-letter к формальному резюме у меня выглядел примерно как «Ааа! Чуваки, вы крутые, я хочу у вас работать!» (не рекомендую повторять в реальной жизни ;))

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

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

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

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

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

Главная проверка на профпригодность — сможете ли вы объяснить что-то действительно сложное так, чтобы вас понял 5-летнийребёнок. И это — не просто упражнение, это работает и на реальных читателей. «Объясни мне Zero-knowledge Proof так, будто мне 5 лет» — до сих пор одна из самых популярных статей в Medium-блоге Cossack Labs.

Читайте также:Каково это — быть техрайтером.

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

Антон Славута, Senior Software Engineer в ЕРАМ

6 лет в IT, в прошлом — проводил семинары по методике оздоровления и психологии

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

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

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

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

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

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

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

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

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

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

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

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

Единственное, что мне больше нравилось в бывшей работе — это возможность больше времени проводить на свежем воздухе :)

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

Если единственная мотивация для перехода в IT-сферу — это желание заработать, то я бы не советовал даже пробовать. Нелюбимая работа не будет стимулировать к развитию. Что касается обучения, для старта я бы рекомендовал «классические» языки: C# или Java. И, конечно, английский.

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

Андрей Лазарев, QA Technical Lead в Terrasoft

3 года в IT, в прошлом — экономист

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

До ІТ работал в 5-тиразных банках. Начинал с позиции младшего экономиста: обзванивал клиентов и собирал информацию о потенциальных заёмщиках. Впоследствии строил процессы принятия решений по выдачам кредитов. Участвовал в проектах по внедрению автоматизации принятия решений.

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

Ещё за 3 года до перехода в ІТ я понимал, что надо что-то менять. Я не сильно понимал, как мне развиваться дальше в банковской сфере. Однако сначала никаких телодвижений не производил, так как находился в комфортной зоне, не жаловался на доход, условия труда, рабочие задачи. Комфортная зона закончилась, когда курс доллара вырос с 8 до 16, а впоследствии до 25. Решение, что пора что-то менять, принял за один день.

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

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

О работе в ІТ.Рассылать резюме в компании я начал с первого дня обучения на курсах по тестированию. Составил систему с таблицами и графиками конверсии откликов на резюме, писал разные сопроводительные письма. Зачастую если моё резюме замечали и оно вызывало интерес, мне звонили спросить об опыте работы в тестировании. А так как его не было, то собеседование не назначали.

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

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

О возможностях.Людям, которые хотят поменять сферу на ІТ, я бы посоветовал спросить себя: а зачем? Если только из-за денег, то это плохая идея. Придется много учиться, работать, и если это не будет приносить удовольствия, то велики шансы быстро выгореть.

Андрій Воловик, Senior QA Engineer & Scrum Master в Digicode

3 роки в IT, в минулому — інженер-конструктор

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

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

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

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

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

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

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

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

Основними джерелами з теорії тестування були книжки «Testing Computer Software»Сема Канера та «How Google Tests Software»Джеймса Уіттакера, а також статті на DOU та інших подібних ресурсах. Для вивчення SQL, HTML, CSS, JSON, XML, XPath використовував W3Schoolsта книжку «Head First SQL Your Brain on SQL»Лінна Бейлі. Також дивився відеоуроки Portnov Computer School.

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

Про роботу в ІТ.Я влаштувався на свою першу роботу досить швидко. Коли вже відчув впевненість в своїх силах, то відразу створив резюме, дав його на рев’ю друзям і почав шукати відповідні вакансії. Відправив резюме приблизно 20 компаніям. На наступний день мені зателефонувала HR, задавала питання по теорії тестування та SQL. Далі була очна співбесіда з технічним спеціалістом, дуже тяжка та стресова. Згодом мені зателефонували і запропонували роботу.

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

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

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

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

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

Юрий Федорченко, Project Manager в Provectus

8 лет в IT, в прошлом — артист музыкального театра

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

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

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

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

Работая в театре, я для развлечения и «поддержания штанов» (ведь зарплаты госслужащих в нашей стране сами знаете какие) время от времени фрилансил. Пытался заработать на трендовых в то время сервисах Surveys и их Affiliate systems: множил собственные одностраничные сайты, где размещал контекстную рекламу. Попутно постигал азы веб-дизайна.

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

Об обучении.Азы менеджмента проектов и продукта я изучил еще в университете. Нужно было только освоить IT-контекст. Для этого читал PMBOK, книги по Agile-методологиям, QA-процессам, базам данных, ООП. Технические знания получал от ребят, с которыми работал: внимательно их слушал, пытался вникнуть, запоминал.

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

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

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

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

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

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

Выбрав направление, составьте себе реалистичный план обучения и стратегию трудоустройства. Определитесь с критериями успешности его реализации. Идите четко по нему: заведите To-Do List и планируйте свои задачи по обучению на неделю. Обязательно конспектируйте прочитанное.

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

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

Тетяна Гладій, Senior Front-end BI Developer в Infopulse

2,5 роки в IT, в минулому — бренд-менеджер

У мене дві вищі освіти: закінчила мехмат в КНУ ім. Шевченка та маркетинг в КНЕУ ім. Гетьмана. Ще студенткою працювала супервайзером і організовувала команду промоутерів.

Моя перша і єдина офіційна робота до ІТ була у відділі маркетингу в міжнародній компанії Henkel. Я прийшла туди на безкоштовне стажування і за короткий проміжок часу побудувала кар’єру. Протягом 2,5 років була бренд-менеджером відомих марок Somat, Pur, Clin.

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

Про роботу в ІТ.Я не прагнула працювати в ІТ і не навчалась спеціально — просто цікавилася тим, чим хотілося займатися. Згодом мій друг перейшов у Infopulse і подав моє резюме у HR-відділ. Через 5 місяців мені передзвонили — це було досить неочікувано для мене на той час.

Мене взяли на стажування з BI-розробки на випробний термін 3 місяці. Моїми перевагами на співбесіді були математичні знання та логічне мислення, а також досвід роботи зі сторони користувача: я точно знала, що зможу зрозуміти потреби клієнта.

Протягом стажування я отримала неосяжний багаж знань з Tableau, QlikView, Crystal Report, AO. Займались і теорією, і практикою. Вже через 2 місяці мене взяли на проект. З того часу я працюю у сфері Business Intelligence, займаюся розробкою звітів для бізнес-аналізу. Спочатку мені часто не вистачало айтішного бекграунду, але з часом я звикла до сленгу та почала розуміти речі, які здавалися незрозумілими раніше.

Саме в Infopulse я вперше познайомилася з робочим процесом Scrum. Люди, які працюють у не ІТ-компаніях, навіть не здогадуються, наскільки правильно може бути організований процес роботи. Також мене здивувала відсутність телефона на робочому місці. А тепер я думаю: навіщо він взагалі? :) Всі зустрічі ми проводимо по скайпу, що неймовірно зручно.

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

Про можливості.З того моменту, як я відчула всі переваги роботи в ІТ, я рекомендую змінювати своє життя всім, хто незадоволений сьогоднішнім днем. Якщо вас теж цікавить Business Intelligence, я раджу починати з курсів BI QA Engineer, адже тестування — найбільш посильний фах для людей з іншої галузі. Вам буде потрібно вивчити SQL, QlikView, Tableau. В інтернеті є безліч безкоштовних сервісів із задачками та відеоуроками — потрібно лише бажання та щоденна робота, хоча б по 2 години в день.

Владимир Арутин, QA Engineer в HYS Enterprise

2 года в IT, в прошлом — финансист

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

Год за годом я обрастал всевозможными связями, клиентским портфелем, опытом и новыми знаниями. Однако не нужно было обладать аналитическими способностями, чтобы рассмотреть мировой тренд развития коммерческих банков. Глобальная уберизация финансового сектора, расцвет финтех-стартапов и блокчейнов склоняли весы не в пользу банков. Знаменитое «Banking is essential, banks are not», сказанное Биллом Гейтсом еще в 2008 году, стремительно воплощалось в жизнь. Можно было подобно Eastman Kodak наслаждаться достигнутым положением дел, но правильней было смотреть в будущее и действовать на опережение.

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

Об обучении.Любовь к учебе с детства вела меня сквозь калейдоскоп учебников, книг, олимпиад, медалей, курсов и семинаров, поэтому мне было легко освоить первые книги по тестированию и разобраться с процессами. Сегодня учиться легко: вокруг нас есть колоссальный океан информации, которая доступна 24/7.

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

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

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

Позже я получил сертификацию ISTQB Foundation Level, прошел курсы QA Automation, обучение на Udemy, Coursera, Edx и успешно сдал ISTQB Advanced Level, Test Manager.

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

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

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

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

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

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

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

Виталий Залевский, Project Manager в DataArt

7 лет в IT, в прошлом — историк

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

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

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

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

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

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

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

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

Спустя 4 года я поменял продуктовый геймдев на аутсорс и работаю менеджером больших и малых игровых и софтверных продуктов.

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

Олег Шкода, Junior QA Engineer в Luxoft

1 рік в IT, в минулому — менеджер

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

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

Після закінчення університету декілька місяців працював у молодіжному центрі при КМДА. Потім — менеджером у відділі маркетингу логістичної компанії.

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

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

Я претендував на позицію тестера ПЗ. На той час навіть не мав чіткого розуміння, що це таке та що потрібно буде робити. Тестувати ПЗ я навчався за методом learning by doing — безпосередньо на роботі. Доводилося чимало вивчати самостійно, по книгах, статтях та відеороликах з YouTube.

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

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

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

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

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

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

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

Софья Герман, Lead QA Artist в Wargaming

4 года в IT, в прошлом — врач-реабилитолог

Я училась в НУФВСУ на факультете физической реабилитации. Затем работала в Главном военном госпитале в хирургических отделениях и в отделении травматологии. Позже — в Центре реабилитации инвалидов, с детьми, страдающими ДЦП.

Летом 2013 года я попала в ДТП на мотоцикле и временно потеряла трудоспособность. Врачи обещали, что примерно через год я смогу самостоятельно ходить без поддержки и специальных средств. Я поняла, что ближайшие 2-3года не смогу работать реабилитологом, так как для этой профессии требуется значительная физическая сила.

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

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

А потом узнала о вакансии Art QA в Persha Studiia и отправила резюме. Меня взяли на позицию Junior. Самым сложным на собеседовании было снова начать общаться с людьми после 10 месяцев отчуждения.

О работе в ІТ.За 2 месяца я практически полностью вошла в рабочий процесс и могла самостоятельно выполнять задачи. С рабочими системами и процессами разобралась достаточно быстро.

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

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

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

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

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

Константин Чижов, Game-дизайнер в Plarium

4 года в IT, в прошлом — инженер-исследователь

Я закончил ХНУ им. В. Каразина, выучился на инженера-радиофизика. Сразу после окончания университета пошел работать в Научный центр «ХФТИ». Там проработал 3 года, прошел путь до инженера-исследователя первой категории. Дальше моя карьера (если это так можно назвать) двигаться не могла, несмотря на наличие публикаций, — научный сотрудник обязан иметь кандидатскую степень.

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

Я начал искать работу по направлениям «копирайтинг/локализация» и так попал в Plarium на позицию копирайтера/сценариста.

Об обучении.Со временем я обучился мануальному тестированию, работе с репозиториями, освоил прототипирование в Axure, работу в Unity, научился базовому анализу KPI, конструкции/деконструкции игровых фич. Чтобы освоить дополнительные специализации, записался на QA Boot Camp от Ciklum, который дал мне общее понимание процессов тестирования.

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

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

Когда изучаешь теорию, то совершенно неясно, какие из этих знаний при столкновении с реальностью окажутся ключевыми, а какие — второстепенными. На тот момент я просто надеялся выучить все возможное. Сейчас понимаю, что намного больше пользы мне принесло бы участие в любом Game Jam или Indie проекте. Молодежь на западе регулярно ищет людей для так называемых Passion Projects, и это неплохой способ «устаканить» полученную теорию.

О работе в ІТ.Чтобы получить свою первую работу в отрасли, мне понадобилось порядка месяца активных поисков. В начале было тяжело «попасть в выборку», которую серьезно рассматривают HR, потому что у меня в резюме не было опыта работы в релевантной области. Потом товарищи рассказали мне, что личные/фан-проекты тоже учитываются как опыт работы, особенно если их можно показать в портфолио. Так дело сдвинулось с мертвой точки.

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

Стать «своим» было совсем нетрудно. У нас игровая компания, и у всех сотрудников есть как минимум один общий интерес — игры.

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

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

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

Сучасні технології IoT так стрімко інтегруються в наше повсякденне життя, що зараз вже нікого не здивуєш системою «розумний дім». Проте не все так просто, як може здаватися на перший погляд: незважаючи на широку популярність систем smart home, досі не існувало уніфікованого рішення, яке б дозволяло керувати пристроями (комплексними компонентами) від різних виробників. Команда розробників GlobalLogic створила своє програмне забезпечення Gateway SDK (software development kit), яке забезпечує керування комплексними компонентами розумного дому.

Реалізація

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

Наразі рішення представлене у вигляді функціонального демостенду: це міні-будинок, обладнаний новітнім устаткуванням з використанням провідних IoT-технологій (Java, Docker, реляційні бази даних).

Smart-home-платформа складається з під’єднаних до неї приладів, що раніше не взаємодіяли між собою в одному середовищі. Платформа доповнена референс-додатком для Android, що дозволяє керувати та/або слідкувати за усіма елементами розумного будинку віддалено, використовуючи смартфон чи комп’ютер. Рішення, яке розроблялося для компанії США, пройшло всі необхідні сертифікації у цій країні. На сьогоднішній день продукт представлений на світовому ринку. Вихід на український ринок не планується.

Як функціонує рішення та які прилади підтримуються хмарною платформою?

Унікальність рішення полягає в тому, що воно об’єднало керування приладами різних виробників в одну систему через модуль IFTTT (If This Then That). GL SmartHome Cloud Solution підтримує 55 приладів, і їх кількість постійно збільшується. Серед локальних приладів є кольорові лампи Philips, термостат Honeywell, камера Nest та ін. Ми вибирали найпопулярніші прилади, які доступні в США. Також ми використовували Amazon Web Services, інноваційні апаратні платформи (ARM Cortex: Raspberry PI 2-3, Qualcomm Dragonboard 410, x86-64: Any) та стеки з’єднання IoT. Віддалений доступ користувача зі з’єднаними між собою приладами розумного будинку здійснюється через такі бездротові інтерфейси, як Z-Wave, Zigbee та протоколи Wi-Fi.

Рішення підтримує високе навантаження — більше 50 000 одночасних запитів на cloud для зміни налаштувань доданих приладів.

GL SmartHome складається з референс-gateway, cloud-рішення з використанням Amazon-сервісів, референс-Android-додатка та демостенду розумного будинку з реальними приладами.

Яка архітектура Cloud-рішення?

Як вже було зазначено, Cloud-рішення побудоване за допомогою Amazon-сервісів, серед яких:

• EC2 (Amazon Elastic Compute Cloud) — задає інфраструктуру серверам;
• ECS (Amazon EC2 Container Service) — використовує докер для централізованого об’єднання контейнерів в кластери і безпосереднього управління ними;
• RDS (Amazon Relational Database) — окремий сервіс для баз даних, де зберігаються акаунти, користувачі та сценарії;
• VPC (Amazon Virtual Private Cloud) — сервіс для управління мережами, що створює приватні мережі (із закритим доступом);
• IoT — сюди входить MQTT брокер, який ми використовуємо;
• S3 (Amazon Simple Storage Service) — сховище з різними розділами (buckets), у яких ми створюємо свої дані — сертифікати. До прикладу, ми використовуємо firmware для gateway як storage;
• SQS (Amazon Simple Queue Service) — сервіс, який формує черги для Java-додатків;
• SES (Amazon Simple Email Service) — мейл-сервіс від Amazon;
• SNS (Amazon Simple Notification Service) — сервіс для сповіщень.

Всі використані сервіси Amazon і Java-додатки ми поділили на 3 кластери:

1. Кластер з додатками для web і API, завдяки яким елементи розумного будинку є доступними через зовнішню мережу.
2. Logic-кластер, який поділяється на:
   
   • Time Server — відповідає за виконання сценаріїв з попередньо визначеним часом;
   • Notification service — відповідає за push-notifications, e-mail, SMS;
   • Gateway to cloud server — з’єднує gateway з cloud-ом. Він розділений на 2 додатки: пересилання MQTT-повідомлень, керування повідомленнями у черзі;
   • Rule engine — відповідає за створення та виконання. Він теж поділяється на 2 додатки, за тим самим принципом, що і gateway to cloud server.
3. Кластер адаптерів, які з’єднують пристрої через наш cloud з cloud-ом виробників девайсів. Кластер складається з чотирьох компонентів: adapter, consumer, publisher та четвертий компонент для черги. Adapter опрацьовує повідомлення, які надсилаються в cloud. Коли повідомлення повертається з відповіддю, publisher закидає повідомлення в чергу, а consumer бере їх з черги і опрацьовує.

Сервіси Amazоn були обрані для реалізації проекту тому, що вони стабільні, є адаптивними та гнучкими. Крім цього, AWS вибудували надзвичайно якісну безпеку інфраструктури, як фізично так і у всесвітній павутині, а це велика перевага коли йдеться про контроль доступу до вашої домівки.

Як інтегрована Amazon Alexa?

Також ми додали Amazon Alexa, яку запрограмували для взаємодії з нашим cloud-ом і керування розумним будинком через той самий cloud.

Amazon Alexa Integration

Які ще референс-компоненти входять до комплексу?

Окрім cloud-рішення, було також створено два компоненти, що допомагають швидко інтегруватися з уже розробленим cloud API.

Перший компонент — це програмне забезпечення Gateway SDK на основі Raspberry PI 2/3, що здійснює зв’язок між локальними пристроями, які комунікують, використовуючи бездротові інтерфейси ZigBee, Z-Wave, Wi-Fi, та здійснюють двосторонній зв’язок з cloud-ом, застосовуючи MQTT-протокол.

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

• керувати пристроями, що працюють використовуючи бездротові інтерфейси ZigBee, Z-Wave, Wi-Fi;
• отримувати команди з мобільного додатку через cloud, використовуючи MQTT-протокол;
• виконувати IFTTT-сценарії, коли немає зв’язку з cloud;
• надсилати повідомлення про зміну стану девайсів на мобільний додаток.

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

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

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

Над рішенням протягом 5 місяців працювали 30 експертів з різних технологій. Зараз роботу GL SmartHome Cloud Solution демонструють потенційним замовникам та під час офісних турів. Ми не можемо сказати, що це кінець проекту, він знаходиться в нас на саппорті і з досвіду — ми постійно розвиваємо свої ж ідеї. Тому якщо вам цікаві технології, починаючи від Embedded і закінчуючи Data Science, — долучайтесь до нашої команди!

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

1. Что вернет условие 2 <> NULL?

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

2 <> NULL

возвращает ложь (FALSE), как впрочем и условие

2 = NULL

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

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

2. Что вернет условие 3 NOT IN (1, 2, NULL)?

Здесь та же история, что и в предыдущем случае. Условие

3 NOT IN (1, 2, NULL)

возвращает ложь (FALSE), как и условие

3 IN (1, 2, NULL)

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

Другими словами:

3 IN (1, 2, NULL)

это то же самое, что и

(3 = 1) OR (3 = 2) OR (3 = NULL)

В случае с NOT IN условие:

3 NOT IN (1, 2, NULL)

это то же самое, что и

(3 <> 1) AND (3 <> 2) AND (3 <> NULL)

Как мы знаем из предыдущего примера, 3 <> NULLвозвращает ложь, а значит и все условие
(3 <> 1) AND (3 <> 2) AND (3 <> NULL)

тоже будет ложным.

3. Выполнится ли этот запрос?

SELECT 
	order_id,
	order_code,
	SUM(order_value)
FROM 
	orders
GROUP BY
	order_id

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

Если этот запрос будет выполняться в MySQL, то колонка order_codeдобавится в выражение GROUP BYавтоматически и запрос выполнится нормально. Если же этот запрос будет выполняться MS SQL Server, то по умолчанию будет сгенерирована ошибка. Впрочем, это поведение настраивается.

4. Почему не выполнится этот запрос?

SELECT 
	user_name,
	YEAR(user_birth_date) AS year_of_birth
FROM 
	users
WHERE
	year_of_birth = 2000

Запрос не выполнится из-за обращения к псевдониму year_of_birth в выражении WHERE. Дело в том, что псевдонимы полей в SQL используются для форматирования данных уже полученных из базы. Поэтому их можно использовать только в выражениях, которые отвечают за оформление результата, таких как GROUP BY, ORDER BYи HAVING. В выражениях, отвечающих за получение данных, таких как WHERE, нужно использовать оригинальные имена полей.

WHERE
	YEAR(user_birth_date) = 2000

5. Имеет ли значение порядок колонок в составном индексе?

Да.

CREATE NONCLUSTERED INDEX MyInd on users (user_name, user_birth_date);

это не то же самое, что

CREATE NONCLUSTERED INDEX MyInd on users (user_birth_date, user_name);

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

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

6. Какая разница между TRUNCATE TABLE table_nameи DELETE FROM table_name?

Фактически обе эти команды вызовут удаление всех строк из таблицы под названием table_name, но вот произойдет это совсем по-разному:

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

7. Какая разница между типами CHARи VARCHAR?

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

1. Тип CHARхранит значение фиксированной длины. Если строка, помещаемая в колонку данного типа, имеет меньшую длину, чем длина типа — строка будет дополнена пробелами. Например, если в колонку типа CHAR(10)записать строку SQL, то она сохранится как SQL       .

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

2. Для типа CHARиспользуется статическое распределение памяти, из-за чего операции с ним быстрее, чем с VARCHAR.

Таким образом, тип CHARподходит для хранения строковых данных фиксированной длины (например, инвентарных номеров, хешей), а для остальных строк больше подойдут VARCHARили NVARCHAR.

8. Какая разница между типами VARCHARи NVARCHAR?

Тип NVARCHAR, пожалуй, самый универсальный из строчных типов данных в БД. Он позволяет хранить строки переменной длины в формате Unicode. В этом формате каждый символ занимает 2 байта, а сама кодировка содержит 65 536 символов и включает в себя все языки мира, в том числе иероглифы.

Тип VARCHARхранит данные в формате SACII. В этом формате каждый символ занимает 1 байт, но отельная кодировка содержит всего 256 символов. Из-за этого для каждого мирового языка выделяется своя кодировка.

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

9. Какая разница между UNIONи UNION ALL?

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

10. Какая разница между выражениями WHEREи HAVING?

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

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

Статья подготовлена на основе доклада Ярослава Святкинана конференции QA Fest. Ярослав — тренер QA Automation & Groovy, Senior Test Automation Engineer, Consultant, GlobalLogic. Специализации: автоматизация web и mobile (Android и iOS), пишет на Java и Groovy.

В этой статье я поделюсь, как быстро писать тесты на языке программирования Groovy, не думать о фреймворке, PageObjectи инициализации WebDriver. Фреймворк это сложно? Нет! Я покажу способ, который позволяет думать о тестировании приложения, а не о структуре кода. Я расскажу о трех фреймворках — Serenity, Selenide и Geb.

«Все, теперь начинаем автоматизацию!»

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

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

Велосипед, или Что мы все обычно делаем

Первое, что мы ищем, — как описывать страницы, что могло бы в этом нам помочь. В описании модели PageObjectцелесообразно использовать элемент Html Elements.PageObject. Кто-то его использует, кто-то — нет, но он дает возможность описать определенные элементы и использовать их повторно.

@Name("Search form")
@FindBy(xpath = "//form")
public class SearchArrow extends HtmlElement {

    @Name("Search request input")
    @FindBy(id = "searchInput")
    private TextInput requestInput;

    @Name("Search button")
    @FindBy(className = "b-form-button__input")
    private Button searchButton;

    public void search(String request) {
        requestInput.sendKeys(request);
        searchButton.click();
    }
}

Еще одно полезное средство — дополнительный фреймворк JDI UI Test Automation Framework. Он помогает в основном создавать объекты: check boxes, text areas и т. д. с дополнительным мета-тегами и всем необходимым. Этот фреймворк помогает описать PageObject.

@JSite(domain = "https://jdi.com")
public class JDIExampleSite extends WebSite {
    public static HomePage homePage;

    public static LoginForm loginForm;

    @FindBy(css = ".profile-photo")
    public static Label profilePhoto;

    public static void login() {
        profilePhoto.click();
        loginForm.loginAs(new User());
    }
}

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

Вот три готовых решения вам в помощь.

Стандартное решение — Serenity

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

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

Project structure

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

PageObject мы используем в следующем виде:

Я думаю, все видели FindBy и знают, как он пишется (селекторы и т. д.). А вот как выглядят шаги, описание бизнес-логики:

Что немаловажно — красиво оформленный, готовый к распечатке отчет:

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

Оптимальное решение — Selenide

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

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

Готовое решение — Geb

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

Первое преимущество Geb — использование языка Groovy. C одной стороны, это плюс. Во-первых, чтобы писать на Groovy, надо писать очень мало. Во-вторых, он использует Java, поэтому все Java-библиотеки, которые у нас есть, мы можем «переиспользовать». Дополнительно — в нем замечательные asserts, которые не надо расписывать, как в TestNG или JUnit. Большой минус в том, что, во-первых, чтобы команда начинала писать на Groovy, вам надо сначала обучить команду. Во-вторых, не всегда заказчик готов к использованию Groovy, чаще к Java, а лучше Java 7.

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

import geb.Browser

Browser.drive {
    go "http://gebish.org"

    assert title == "Geb - Very Groovy Browser Automation" 
 $("div.menu a.manuals").click() 
    waitFor { !$("#manuals-menu").hasClass("animating") } 
  $("#manuals-menu a")[0].click() 
assert title.startsWith("The Book Of Geb") 
}

Тяжело ли писать такой код? По-моему, очень легко. Естественно, у нас есть first-метод, с помощью которого можно выбрать все элементы со знаком $. В данном случае нам нужен первый, поэтому мы указываем единицу — «первый элемент» и «клик». Это классический вариант.

При использовании Groovy у вас появляется широкий спектр возможностей. Приведу несколько примеров. Например — создание random stringдля необходимого количества значений возможно в одну строку:

Следующее — когда перед вами стоит задача протестировать API и у вас есть HTTP-запрос, вы получаете JSON-файл, который нужно «распарсить» и получить определенный результат. В Java вам нужны сторонние библиотеки для работы с JSON-файлом. В Groovy же поддержка парсинга и разбора JSON-файла происходит «из коробочки».

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

В Groovy любой массив может быть объектом. Вы берете определенный массив и пишете: (massive as Duckling). Если все характеристики совпадают, у вас появляется объект Duckling. Кроме того, у вас есть возможности точно так же описывать JSON:

Выбор селекторов

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

Здесь можно использовать ID и клас By. Любимый класс By позволяет нам по тому или иному селектору сделать выбор тех или иных элементов.

Обратите внимание на assert в этом изображении. Здесь есть знак $. Выбираем все символы p в диапазоне с первого по второй. С помощью метода *.textвыбираем весь текст этих элементов (значок * свидетельствует о том, что используется метод языка Groovy), и нам возвращается полный текст со всех элементов.

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

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

Кроме этого, есть методы, с которыми можно работать почти как со строками:

Также еще есть и масса других методов:

Один из вариантов, где показано, что нам доступно, в рамках Geb и Groovy в целом, использовать XPath с передачей аргумента:

Если сравнивать написание кода с помощью Geb и классический подход, то 25 строчек кода на Java заменит одна строчка на Groovy c Geb.

Что еще может вам помочь в работе над проектами? У нас есть понятие методов wait, и не всегда на странице есть те или иные элементы. Для проверки мы пишем метод isElementPresent, делаем track catches, обрабатываем, возвращаем trueили false.

И снова в Geb все это есть в готовом виде. Первое, у нас есть wait, который определяет, ждать элемент на странице или нет. Мы можем не ждать появления этого элемента, а проверить его наличие.

Существует wait, который определяет, сколько секунд ждать при поиске элементов. Вы сразу задаете его в селекторе при описании PageObject. Элемент может также принимать параметр required true (или false), т. е. определяет, должен или нет этот элемент находиться на этой странице.

Для кэширования в Geb тоже есть вариант. Вы можете прямо в селекторах указать:

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

Работа с таблицами

Кроме того, что в Geb есть готовые элементы, также есть и возможность использования двух основных классов для построения PageObject-модели: страница и настраиваемый модуль.

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

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

Как это делается? Давайте посмотрим:

В описании PageObject в Geb есть NotificationModule, а также элементы:

• имя элемента;
• через фигурные скобки — селектор этого элемента;
• moduleList в рамках модуля, где мы вызываем еще один модуль.

Ссылка на элемент является ссылкой на набор объектов другого модуля. Это все пишется в одну строчку. Notification у нас является дополнительным модулем с именем и датой. Заметьте, на модуле сразу вызывается метод, который вызывает этот элемент.

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

Теперь о результатах. Благодаря searchResultбудут полностью возвращаться все найденные тексты для выбранных элементов. Если теперь вы будете использовать link, у вас получится следующее:

Если вам нужно вызвать все методы — ставите «звездочку» и точку (*.), и вам возвращается все, что вы хотите (это Groovy).

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

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

Если вам необходимо проверить, находитесь ли вы на странице, у вас есть замечательный метод isAt. Вы передаете текущую страницу, и у вас получается проверка true/false (на текущей странице или нет). Опять же в Geb это все идет «из коробочки».

Вот классический пример такой страницы (с логином и паролем):

Если вы хотите произвести метод логирования, у вас классически передаются логин/пароль, возвращаются элементы, вы их очищаете и с помощью Groovy вводите значение. Метод login.submitнаходит и вызывает кнопку, по которой вы сразу же кликаете.

Для описания этих действий на Java 7 с использованием Selenium придется создавать гораздо больший объем кода, чем приведенный выше. С точки зрения приложения, использование Geb очень упрощает описание PageObject.

Взаимодействие с мышью и поддержка кнопок

В Selenium у нас есть набор Actions — действий, которые мы можем использовать:

• наведение мыши;
• работа с веб элементами;
• drag-and-drop и так далее.

Для этого нужно создать объект Action, выполнить определенные действия для него и произвести эти действия. В Geb вы можете произвести те же действия — .clickAndHold, .moveByOffsetи любые другие. Разработчики фреймворка Geb предусмотрели все «под ключ». Остается единственный вопрос: почему мы это не используем?

Здесь есть и поддержание кнопок:

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

Ранее открытые окна и тесты

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

Для этого в Geb предусмотрены методы withWindowи withNewWindow. Чем они отличаются? Метод withWindow — новое окно открывается в существующем, производятся действия проверки и сразу же возвращается в предыдущее окно.

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

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

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

Показ скрытого элемента

Довольно часто мы используем в коде JS, так как есть вещи, которые без него сделать нельзя. Например, реализовать scroll. Для этого нужно написать определенный кусок кода, привести его к Java executor и прочее.

И снова в Geb есть все, что нам необходимо. Если вы хотите использовать JS-код, вам надо всего лишь написать js.execи указать, что именно вы хотите выполнить:

Кроме того, что в Geb есть встроенная поддержка JS, поддержка jQuery. Это может значительно расширить возможности с точки зрения фреймворка и оптимального описания необходимых действий.

Поддерживаемые браузеры

В Geb поддерживаются все браузеры, которые есть в рамках WebDriver. Обычно в наших решениях мы делаем driver factory, отдельно описываем необходимые браузеры, далее его «подтягиваем» и запускаем — с учетом специфики job. В фреймворке Geb это вынесено по умолчанию. Здесь уже есть отдельный файл — GebConfig.groovy, который мы должны создать по умолчанию и в нем описать браузеры, а также тестовую среду:

Сюда можно полностью вынести все необходимые для тестов константы (имя, пароль, e-mail), настройки тестов, правила проверки, тайм-аут по умолчанию и прочее. Далее — область тестовой среды (test environment), для которой мы задаем имена окружения (Chrome, Firefox, IE) и создаем те драйвера, которые необходимы.

Понятно, что в рамках используемого build (Gradle или Maven) создаются определенные tasks. При этом для Gradle build необходимо прописать свойства системы (System Properties), а именно с каким environment будут запускаться тесты, где лежат драйвера той или иной тестовой среды:

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

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

Интеграции с mobile

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

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

Библиотека Geb Mobileпомогает создавать и использовать Geb для нативного Android- или iOS-приложения. Конечно, кое-что не будет работать в связи со спецификой нативных мобильных приложений, но построение PageObject, модулей можно применять и к этим приложениям.

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

В заключение перечислим преимущества и недостатки использования Geb.

Преимущества:

• Использование языка Groovy (краткость).
• Готовая PageObject-модель, которую вы можете использовать для написания методов wait, переходов между страницами и пр.
• Поддержка всех тестовых фреймворков, сочетание с Cucumber, jUnit, TestNG.

Недостатки:

• Мало кто знает Groovy.
• Необходимо уговорить заказчика начать использовать новые фреймворки и технологии. Для заказчика главный вопрос — кто это будет поддерживать.

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

А также: Architecture Components, ускорение сборки приложения, профайлинг, Wear OS, модуляризация, Coroutines, Закон о защите данных, конференция в Киеве и еще много интересного!

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

Что нового в Android Studio 3.1и про переход на D8 dexerпо-умолчанию.

Google Wear OS — ребрендинги обновление старого доброго Android Wear.

Announcing Flutter Beta 2 (v0.2.8).

Time to Upgrade from GCM to FCM. Поддержка Google Cloud Messaging прекращается в апреле 2019 года.

What does GDPR mean for Mobile App Owners? 12 Use Cases. Новый закон о защите данных пользователей из ЕС.

Android P

Знакомьтесь: Android P.

Random Musings on the P Developer Preview 1. Традиционный комментарий от Mark Murphy о превью новых версии ОС.

Cryptography Changes in Android P.

Exploring Android P: Fingerprint Dialog.

About the Potential Android P App Ban.

Kotlin

Code Clean-up with Kotlin.

Kotlin coroutines vs RxJava: an initial performance test.

An Illustrated Guide to Covariance and Contravariance in Kotlin.

Simplify your Android code by delegating to sealed classes.

Kotlin on iOS. Генерируем Objective C код с помощью Kotlin/Native.

Архитектура и RxJava

The death of Presenters and the rise of ViewModels. Как Android Architecture Components захватывают мир.

A Guided Tour inside a clean architecture code base.

Repository Pattern with Store and Retrofit.

Modules, modules everywhere. Почему нужно делить ваше приложения на модули и как это делать.

RxJava & State: The Basics.

Flutter

Flutter: How I built a simple app in under an hour from scratch. And how you can do it too.

Времена паттернов: Introduction to Reduxи An MVC approach to Flutter.

Getting Your Hands Dirty with Flutter: Project Setup + Authorization.

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

RecyclerView  — More Animations with Less Code using Support Library ListAdapter.

Understanding how to reproduce crashes with Firebase Crashlytics Logs.

Practical ProGuard rules examples.

Unified Code Coverage for Android: Revisited.

Speed up your Build with Gradle Remote Build Cache.

UI Performance: Improving Text Rendering.

Migrating todo-mvp-kotlin to Coroutinesот GDE Dmytro Danylyk.

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

Kotlintest: Powerful, elegant and flexible Kotlin {junit} test framework.

Scrcpy: Display and control your Android device.

Hyperion: App Debugging & Inspection Tool for Android. Можно делать свои плагины.

Profilo: Understanding app performance in the wild от команды Facebook.

Анонсы и конференции

Конференция MobileFest: 2 июня в Киеве! Разработка мобильных приложений для Android и iOS, Google Developer Experts спикеры, игротека, и афтепати :) Скидка 10% по промокоду DOUDIGEST для наших читателей.

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

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

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

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

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

Ответственность

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

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

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

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

Арсений Оганов, Lead Solutions Architect в Netcracker:

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

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

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

Ирина Попова, Head of Development в Light IT:

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

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

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

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

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

Андрей Голомоз, Head of Traffic Quality department в Admitad:

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

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

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

Инициативность

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

Артем Дурнев, Unity Software Architect в Plarium:

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

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

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

Василий Иванов, СЕО KeepSolid:

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

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

Артур Мироненко, iOS Tech Lead в UPTech:

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

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

Діана Пекеліс, Senior QA Engineer в DataArt:

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

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

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

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

Пам’ятаю, коли я тільки став техлідом на проекті TenantCloud, переді мною стояло питання: залишити все як є і продовжувати розробку на старому стеку або ж переписати практично все з нуля. Це було складне рішення, оскільки потрібно було пояснити стейкхолдерам, що 2-3місяці не буде нових фіч, і, можливо, буде багато багів :) Зовсім непростий виклик. Однак ми прийняли правильне рішення і переписали все з нуля.

Гибкость

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

Діана Пекеліс, Senior QA Engineer в DataArt:

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

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

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Внимательность

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

Ирина Попова, Head of Development в Light IT:

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

Андрей Михайлов, CTO, Senior .NET & JavaScript разработчик в Zfort:

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

Честность

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

Тарас Романик, .NET Developer, Tech Lead у Conscensia:

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

Ціна чесно визнаної помилки — 5 хвилин ганьби, 2 дні для написання фікс-сервісу і кілька місяців роботи самого сервісу. Якби я приховав помилку, її ціною могли б стати судові позови. Якби намагався виправити «непомітно» для замовника, то довелось би овертаймити та порушувати дедлайни по основним завданням.

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

Александр Тарасенко, VAS Team Lead в EVO:

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

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

Еще одна сторона честности — открыто рассказывать о своих сильных сторонах, не скатываясь при этом в хвастовство.

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Зрелость

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

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

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

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

Елена Белкина, QA engineer, Internal SoftSkill Trainer в CoreValue:

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

Зрелость — это в том числе и надежность и предсказуемость в хорошем смысле этого слова.

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

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

Что еще почитать о развитии личных навыков:

• «Думай медленно, решай быстро»Даниэля Канемана — о принятии решений в условиях неопределенности.
• «Код уверенности. Почему умные люди бывают не уверены в себе и как это исправить»Роберта Келси — о том, что такое уверенность и как ее можно достичь, а также какие мифы и препятствия заставляют нас терять веру в себя.
• «Бойся, но действуй: как превратить страх из врага в союзника»Сьюзен Джефферс — о том, совладать со своими страхами и идти по жизни уверенно.
• «Начни: Врежь страху по лицу, перестань быть „нормальным“ и займись чем-то стоящим»Джона Эйкаффа — о том, что никогда не поздно отказаться от размеренной и привычной жизни и целенаправленно стремиться к чему-либо.
• «Сила воли»Келли Макгонигал — о том, как заменить вредные привычки полезными, как перестать откладывать дела на последний момент, научиться сосредотачиваться и справляться со стрессом.