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

[Про автора: Андрій Бас — співзасновник і Team Lead ІТ-компанії Uptech, фасилітатор Design Sprints. 2019 року посів 9-темісце в рейтингу MC Today «Новые лица 2019». За три роки без зовнішніх інвестицій побудував компанію, яка розширилася до 50 членів команди й успішно розробляє додатки для провідних стартапів з Каліфорнії, зокрема Dollar Shave Clubта Aspiration.com]

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

Коли йдеться про Discovery, то я маю на увазі метод, завдяки якому можна зрозуміти потреби цільової аудиторії й розробити продукт, що дає змогу їх задовольнити. В Інтернеті трапляються й інші назви цього методу: Product Discovery чи Customer Development.

Популярними є й книги на цю тему, зокрема «Sprint», «The Startup Owner’s Manual», «Lean UX», «The Mom Test», «Running Lean»тощо. Сьогодні я поділюся з вами деякими додатковими книгами для ефективного Discovery.

The Lean Startup by Eric Ries

Російською — Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

Ерік Рейс, учень Стіва Бланка (автора методології Customer Development), популяризував рух Lean Startup. Ерік поєднав підхід Бланка й метод Lean японських підприємств. Починаючи з 2011 року, його книга стала взірцем побудови стартапів.

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

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

Критики книги зазначають, що час Lean Startup уже минає, ринок стає зрілішим, натомість запити користувачів дедалі зростають, тому з маленьким MVP, що зроблено за кілька тижнів, малоймовірно чогось досягти. Наприклад, у книзі «Lost and Founder»Ренд Фішкін (засновник Moz) пише, що «сире» MVP нині може більше зашкодити, аніж допомогти, негативно вплинувши на майбутню репутацію бренда. Проте для компаній, які ще не дуже відомі, усе ще є нагода зробити тихий запуск «сирого» MVP без ризиків завдати компанії значної шкоди. Тут я погоджуюся з Рендом.

The Four Steps to the Epiphany by Steve Blank

Російською —Стив Бланк «Четыре шага к озарению. Стратегии создания успешных стартапов»

Книгу написав серійний підприємець Стів Бланк ще 2003 року. Багатьох компаній, які згадує автор, уже немає. Крім того, цю книгу досить важко сприймати. Та, попри це, її справді варто прочитати. Автор описує методологію Customer Development, що стала основою всього пізнішого руху Lean Startup.

Customer Development — це методологія створення нових продуктів і стартапів, у якій завдяки взаємодії з потенційними клієнтами валідують гіпотези про проблему та її розв’язання, а також ринок і канали залучення. Процес Customer Development охоплює чотири етапи: Customer Discovery, Customer Validation, Customer Creation і Company Building. Детальніше про них:

• Customer Discovery сфокусовано на перевірці бізнес-моделі стартапу й валідації, чи задовольняє продукт потреби клієнтів (що дістало назву Product / Market Fit і не дає нині спати всім засновникам стартапу на його ранній стадії).
• Customer Validation допомагає розробити повторюваний канал продажу й маркетингову стратегію, яку використовуватимуть майбутні команди маркетингу та продажу.
• Customer Creation зосереджено на створенні потреби в кінцевих користувачів і спрямуванні її до каналів продажу компанії.
• Під час Company Building стартап уже переходить від навчання до реалізації планів, створення функційних департаментів, зосереджених навколо своїх місій, тощо. Компанія переорієнтовується на зростання.

Саме Стів Бланк популяризував таку фразу: «There are no facts inside the building, so get the hell outside» (яка стала однією з основ іншої популярної книги про спілкування з клієнтами — «The Mom Test»).

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

Будьте уважні: не плутайте Customer Development-методологію з Custdev. Перше — це методологія побудови продуктів і стартапів, а друге — термін, що поширився здебільшого на пострадянському просторі й насправді означає user interview.

When Coffee and Kale Compete by Alan Klement

Офіційну книгу можна завантажитибезплатно.

Алан Клемент у книзі описує методологію Jobs-to-be-Done. Це потужний фреймворк, завдяки якому можна будувати продукти, що матимуть попит. В основі методології концепція, що користувач хоче змінити свою життєву ситуацію та стати кращим (це його Job), але на цьому шляху трапляються перешкоди й обмеження. Тож для досягнення своїх Jobs користувач «наймає» певні продукти або сервіси, що допомагають йому змінити своє життя на краще.

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

Найвідомішими популяризаторами концепції Jobs-to-be-Done є Клейтон Крістенсен, Алан Клемент і компанія Intercom (що опублікувала свою безплатну книгу «Jobs-to-be-Done»). Intercom також популяризувала концепцію Job Stories замість традиційних User Stories. Такі Job Stories більше сфокусовано на мотиві користувача й контексті, у якому він перебуває.

Ми вже застосовували підхід Job Stories під час розробки нашого продукту Plaiі задоволені результатом.

Lean Analytics by Alistair Croll & Benjamin Yoskovitz

Lean Analytics — це продовження серії Lean-книг, яку започаткувала «Lean Startup» Еріка Рейса. Алістер Кролл і Бенджамін Йосковіц, засновники акселератора Year One Labs, діляться своїм досвідом, як використовувати дані разом з підходом Lean, щоб розробляти, запускати й скейлити успішні стартапи.

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

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

Автори книги наголошують також і на тому, що потрібно фокусуватися на одній стрижневій метриці в кожен період життя продукту/стартапу (або, як вони її називають, One Metric That Matters or OMTM). І що важливо, ця метрика завжди буде іншою, залежно від стадії продукту. Щодо самого циклу, то автори пропонують власні п’ять стадій розвитку стартапу: Empathy, Stickiness, Virality, Revenue та Scale. Такий поділ, на мою думку, логічний, проте особисто мені підхід Lean Startup чи Customer Development здається практичнішим і кориснішим.

«Data is the antidote to delusion, making sure your feet are planted firmly on the ground of reality», — стверджують автори.

Inspired: How to Create Tech Products Customers Love by Marty Cagan

Російською —Марти Кэган «На крючке. Как создавать продукты-хиты»

Марті Каган, засновник Silicon Valley Product Group, є експертом і лідером у сфері Product Management у Кремнієвій долині. Марті стверджує, що те, як будують найкращі продукти, відрізняється від того, як створюють більшість продуктів. У книзі він пропонує поради щодо правильного Product Development. Аналізуючи найкращі технологічні компанії, автор стверджує, що процес створення продукту не є лінійним, як це заведено вважати. З лінійним підходом виникає багато проблем. Натомість Марті пропонує:

1. Працювати з ризиками на старті, а не в кінці.
2. Дизайнити проекти колаборативно, а не послідовно.
3. Фокусуватися на розв’язанні проблем, а не імплементації фіч.

Для реалізації такого підходу багато важить Product Management, який виношує ідею. Важливими навичками хорошого Product Manager є прототипування та швидке usability-тестування (яке він повинен уміти робити сам).

Для успішної побудови стартапу/продукту потрібно кілька складників: 1) правильні люди; 2) правильний продукт; 3) правильні процеси; 4) правильна культура. Автор детально розглядає кожен із цих складників і дає чимало практичних порад. Книга буде особливо корисна Product Managers-початківцям, щоб зрозуміти правильний Product Management-підхід та уникнути численних помилок.

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

Привет! Меня зовут Эллина Азадова, я одинадцать лет в IT, более семи из них работаю тестировщиком. Координатор сообщества QA talk Kherson, лектор в QA School в Херсоне и Софии.

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

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

Тотальный контроль

Я попадаю в новый проект как QA Lead. Стандартная команда: ВА, QA, команда разработки с девлидом. Все бы ничего, но, как оказалось, практически каждое действие в проекте обсуждалось и выполнялось только с одобрения девлида, которого для удобства мы назовем, допустим, Петровичем. Он же выполнял роль проджект-менеджера, напрямую общаясь с клиентом.

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

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

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

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

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

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

Опыт, который мы вынесли:

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

Негативный настрой

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

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

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

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

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

Опыт, который мы вынесли:

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

Проблема онлайн-коммуникации

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

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

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

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

Да, иногда в день прилетает много писем. Сейчас на мой основной адрес приходит по 500 писем в день, не все они адресованы лично мне, но сортировать их необходимо.

Опыт, который мы вынесли:

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

И напоследок

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

Ще далекого 2015 року в СКБД MySQL, починаючи з версії 5.7.8, додали підтримання нового типу даних JSON. Насамперед це створило нові можливості для роботи з даними, які з тих чи інших причин не потребують нормалізації. Однак мене це нововведення більше зацікавило суттєвим розширенням можливостей взаємодії зі збереженими процедурами.

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

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

Архітектура клієнт-сервер

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

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

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

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

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

А що робити, коли вам потрібно зберегти чи оновити значення великої кількості полів запису в таблиці? Чи передати велику кількість параметрів відбору для фільтрування вибірки з БД? У таких випадках кількість даних клієнта може деколи становити 20―30 штук чи навіть більше. Відповідно передавати ці дані через вхідні параметри процедури стає, м’яко кажучи, не дуже зручно.

І як саме в таких типових ситуаціях нам стане в пригоді новий тип даних JSON? З його допомогою ми зможемо в дуже зручному вигляді передавати в збережені процедури велику кількість даних з клієнта. До того ж на боці клієнта можна компактно опрацьовувати велику кількість змінних одним пакетом за допомогою, наприклад, асоціативного масиву чи об’єкта (Entity, Collection). А потім автоматично конвертувати їх у JSON-формат для передавання на сервер без потреби прописувати кожен параметр окремо.

Тип даних JSON

JSON — здавалось би, що може бути простіше? Хіба що CSV і, можливо, YAML. Але ж ні — для роботи з ним в СКБД MySQL довелося додавати цілий зоопарк нових функцій.

Найпоширеніші функції, з якими нам сьогодні доведеться мати справу це: ->, ->> та JSON_TYPE(). Хоча для виконання складніших завдань їх явно бракуватиме. А оскільки невідомо, які функції вам знадобляться в майбутньому проекті — пропоную весь перелік з коротким описом.

Крім цих функцій, є ще дві для агрегації: JSON_ARRAYAGG() та JSON_OBJECTAGG(). А також я не вказав функцію JSON_MERGE(), бо вона призначена для видалення в наступних версіях (deprecated 8.0.3).

З докладнішим описом наведених вище функцій для роботи з типом даних JSON можна ознайомитися в розділі «Довідник функцій JSON»офіційної документації MySQL.

Збережені процедури

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

В СКБД MySQL я створив гетери/сетери — процедури виконання типових операцій CRUD за аналогією з шаблоном проектуванням «Сховище» (Repository/Storage). У підсумку вийшло щось схоже на API для роботи з БД, що створило ще як мінімум три додаткові переваги порівняно з класичним підходом.

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

CREATE PROCEDURE ArticleGet (IN `_id` INT UNSIGNED) ...;
CREATE PROCEDURE ArticleGetByAlias (IN `_alias` VARCHAR(128)) ...;
CREATE PROCEDURE ArticleGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE ArticleSet (IN `_params` JSON) ...;
CREATE PROCEDURE ArticleUnset (IN `_id` INT UNSIGNED) ...;
CREATE PROCEDURE CategoryGet (IN `_id` TINYINT UNSIGNED) ...;
CREATE PROCEDURE CategoryGetAll () ...;
CREATE PROCEDURE CategoryGetByAlias (IN `_alias` VARCHAR(128)) ...;
CREATE PROCEDURE CategoryGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE CategorySet (IN `_params` JSON) ...;
CREATE PROCEDURE CategoryUnset (IN `_id` TINYINT(3) UNSIGNED) ...;
CREATE PROCEDURE CommentGet (IN `_id` INT UNSIGNED) ...;
CREATE PROCEDURE CommentGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE CommentSet (IN `_params` JSON) ...;
CREATE PROCEDURE CommentUnset (IN `_id` INT UNSIGNED) ...;
CREATE PROCEDURE PageGet (IN `_id` TINYINT UNSIGNED) ...;
CREATE PROCEDURE PageGetByAlias (IN `_alias` VARCHAR(32)) ...;
CREATE PROCEDURE PageGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE PageSet (IN `_params` JSON) ...;
CREATE PROCEDURE PageUnset (IN `_id` TINYINT UNSIGNED) ...;
CREATE PROCEDURE RoleGetIndex () ...;
CREATE PROCEDURE TagAutocomplete (IN `_title` VARCHAR(32), IN `_exclude` VARCHAR(32)) ...;
CREATE PROCEDURE TagGet (IN `_id` SMALLINT(5) UNSIGNED) ...;
CREATE PROCEDURE TagGetByAlias (IN `_alias` VARCHAR(32)) ...;
CREATE PROCEDURE TagGetByIDs (IN `_ids` VARCHAR(32)) ...;
CREATE PROCEDURE TagGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE TagSet (IN `_params` JSON) ...;
CREATE PROCEDURE TagUnset (IN `_id` SMALLINT UNSIGNED) ...;
CREATE PROCEDURE UserAuthorize (IN `_email` VARCHAR(32), IN `_password` VARCHAR(32)) ...;
CREATE PROCEDURE UserGet (IN `_id` TINYINT UNSIGNED) ...;
CREATE PROCEDURE UserGetByAlias (IN `_alias` VARCHAR(32)) ...;
CREATE PROCEDURE UserGetIndex (IN `_params` JSON) ...;
CREATE PROCEDURE UserSet (IN `_params` JSON) ...;
CREATE PROCEDURE UserUnset (IN `_id` TINYINT UNSIGNED) ...;
CREATE PROCEDURE _GetFoundRows () ...;

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

DELIMITER $$
CREATE OBJECT Article
BEGIN
    CREATE PROCEDURE Gеt (IN `_id` INT UNSIGNED) ...;
    CREATE PROCEDURE GetByAlias (IN `_alias` VARCHAR(128)) ...;
    CREATE PROCEDURE GetIndex (IN `_params` JSON) ...;
    CREATE PROCEDURE Sеt (IN `_params` JSON) ...;
    CREATE PROCEDURE Unset (IN `_id` INT UNSIGNED) ...;
END$$

Друге, на що ви могли звернути увагу — використання знака підкреслення _перед назвами змінних. Річ у тім, що в MySQL є чимало службових і зарезервованих слів, і подекуди назви змінних з ними збігаються. Тому під час використання змінних без знака підкреслення вони спеціально виокремлюють в IDE й це дуже збиває з пантелику.

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

Тому я вирішив використовувати знак підкреслення, передусім через його гарантовану ефективність і сумісність. Перед ним ще можна ставити додаткову літеру, наприклад v (v_id, v_time, v_text). А втім я не став мудрувати й поки що задовольнився застосуванням лише цього знака без ніяких додаткових літер.

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

CREATE TABLE `article` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `time` datetime NOT NULL,
    `title` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL,
    `description` varchar(256) COLLATE utf8mb4_unicode_ci NOT NULL,
    `text` text COLLATE utf8mb4_unicode_ci NOT NULL,
    `image` varchar(48) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `alias` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL,
    `category` tinyint(3) unsigned NOT NULL,
    `user` tinyint(3) unsigned NOT NULL,
    `status` tinyint(1) unsigned NOT NULL DEFAULT '1',
    PRIMARY KEY (`id`),
    KEY `category` (`category`),
    KEY `user` (`user`),
    CONSTRAINT `article_ibfk_1` FOREIGN KEY (`category`) REFERENCES `category` (`id`),
    CONSTRAINT `article_ibfk_3` FOREIGN KEY (`user`) REFERENCES `user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

І почнемо з першої збереженої процедури, яку використовують найчастіше — ArticleGet.

DELIMITER $$
CREATE PROCEDURE `ArticleGet`(IN `_id` INT UNSIGNED)
BEGIN
    SELECT      `a`.*, `u`.`id` AS `userID`, `u`.`title` AS `userTitle`,
                GROUP_CONCAT(DISTINCT `at`.`tag` SEPARATOR ',') AS 'tags'
    FROM        `article` AS `a`
    INNER JOIN  `user` AS `u` ON `u`.`id` = `a`.`user`
    INNER JOIN  `article_tag` AS `at` ON `at`.`article` = `a`.`id`
    WHERE       `a`.`id` = _id
    GROUP BY    `a`.`id`;
END$$

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

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

DELIMITER $$
CREATE PROCEDURE `ArticleGetByAlias`(IN `_alias` VARCHAR(128))
BEGIN
    SELECT      `a`.*, `u`.`title` AS `userTitle`, `u`.`alias` AS `userAlias`,
                GROUP_CONCAT(
                    DISTINCT CONCAT(`t`.`title`, '/', `t`.`alias`) SEPARATOR ','
                ) AS 'tags'
    FROM        `article` AS `a`
    INNER JOIN  `article_tag` AS `at` ON `at`.`article` = `a`.`id`
    INNER JOIN  `tag` AS `t` ON `t`.`id` = `at`.`tag`
    INNER JOIN  `user` AS `u` ON `u`.`id` = `a`.`user`
    WHERE       `a`.`alias` = _alias
    GROUP BY    `a`.`id`;
END$$

Процедура ArticleGetByAliasаналогійна до попередньої, за винятком вхідного параметра пошуку запису й метода компонування міток. Я навів її просто як приклад використання двох подібних процедур для двох різних клієнтів. Попередню процедуру використовує адміністративний сайт, де звернення до об’єкта редагування відбувається за його ідентифікатором. А другу процедуру використовує сайт для виведення статей, де звернення до статті відбувається за його адресою в посиланні (alias).

DELIMITER $$
CREATE PROCEDURE `ArticleGetIndex`(IN `_params` JSON)
BEGIN
  DECLARE _dateBegin DATETIME;
  DECLARE _dateEnd DATETIME;
  DECLARE _title VARCHAR(32);
  DECLARE _categoryID TINYINT(3);
  DECLARE _categoryTitle VARCHAR(32);
  DECLARE _tagID SMALLINT(5);
  DECLARE _tagTitle VARCHAR(32);
  DECLARE _userID TINYINT(3);
  DECLARE _userTitle VARCHAR(32);
  DECLARE _status TINYINT(1) UNSIGNED;
  DECLARE _orderField VARCHAR(32) DEFAULT 'id';
  DECLARE _orderDirection INTEGER DEFAULT 1;
  DECLARE _rowsOffset INTEGER UNSIGNED DEFAULT 0;
  DECLARE _rowsLimit INTEGER UNSIGNED DEFAULT 100;

  IF (JSON_TYPE(_params->'$.dateBegin') <> 'NULL') THEN
    SET _dateBegin = CONCAT(_params->>'$.dateBegin', ' 00:00:00'); END IF;
  IF (JSON_TYPE(_params->'$.dateEnd') <> 'NULL') THEN
    SET _dateEnd = CONCAT(_params->>'$.dateEnd', ' 23:59:59'); END IF;
  IF (JSON_TYPE(_params->'$.title') <> 'NULL') THEN
    SET _title = _params->>'$.title'; END IF;
  IF (JSON_TYPE(_params->'$.categoryID') <> 'NULL') THEN
    SET _categoryID = _params->'$.categoryID'; END IF;
  IF (JSON_TYPE(_params->'$.categoryTitle') <> 'NULL') THEN
    SET _categoryTitle = _params->>'$.categoryTitle'; END IF;
  IF (JSON_TYPE(_params->'$.tagID') <> 'NULL') THEN
    SET _tagID = _params->'$.tagID'; END IF;
  IF (JSON_TYPE(_params->'$.tagTitle') <> 'NULL') THEN
    SET _tagTitle = _params->>'$.tagTitle'; END IF;
  IF (JSON_TYPE(_params->'$.userID') <> 'NULL') THEN
    SET _userID = _params->'$.userID'; END IF;
  IF (JSON_TYPE(_params->'$.userTitle') <> 'NULL') THEN
    SET _userTitle = _params->>'$.userTitle'; END IF;
  IF (JSON_TYPE(_params->'$._status') <> 'NULL') THEN
    SET _status = _params->'$._status'; END IF;
  IF (JSON_TYPE(_params->'$._orderField') <> 'NULL') THEN
    SET _orderField = _params->>'$._orderField'; END IF;
  IF (JSON_TYPE(_params->'$._orderDirection') <> 'NULL') THEN
    SET _orderDirection = _params->'$._orderDirection'; END IF;
  IF (JSON_TYPE(_params->'$._offset') <> 'NULL') THEN
    SET _rowsOffset = _params->'$._offset'; END IF;
  IF (JSON_TYPE(_params->'$._limit') <> 'NULL') THEN
    SET _rowsLimit = _params->'$._limit'; END IF;

  SELECT SQL_CALC_FOUND_ROWS
         `a`.`id`, `a`.`time`, `a`.`title`, `a`.`description`, `a`.`image`, `a`.`alias`,
         `a`.`status`, `c`.`title` AS 'categoryTitle', `c`.`alias` AS 'categoryAlias',
         `u`.`title` AS 'userTitle', `u`.`alias` AS 'userAlias',
         GROUP_CONCAT(DISTINCT `t`.`title` ORDER BY `t`.`title` ASC SEPARATOR ', ') AS 'tags'
    FROM `article` AS `a`
    INNER JOIN `category` AS `c` ON `c`.`id` = `a`.`category`
    LEFT JOIN `article_tag` AS `at` ON `at`.`article` = `a`.`id`
    LEFT JOIN `tag` AS `t` ON `t`.`id` = `at`.`tag`
    INNER JOIN `user` AS `u` ON `u`.`id` = `a`.`user`
    WHERE `a`.`id` > 0
      AND (_dateBegin     IS NULL OR `a`.`time`     >= _dateBegin)
      AND (_dateEnd       IS NULL OR `a`.`time`     <= _dateEnd)
      AND (_title         IS NULL OR `a`.`title`    LIKE CONCAT('%', _title, '%'))
      AND (_categoryID    IS NULL OR `a`.`category` = _categoryID)
      AND (_categoryTitle IS NULL OR `c`.`title`    LIKE CONCAT('%', _categoryTitle, '%'))
      AND (_tagID         IS NULL OR `at`.`tag`     = _tagID)
      AND (_tagTitle      IS NULL OR `t`.`title`    LIKE CONCAT('%', _tagTitle, '%'))
      AND (_userID        IS NULL OR `a`.`user`     = _userID)
      AND (_userTitle     IS NULL OR `u`.`title`    LIKE CONCAT('%', _userTitle, '%'))
      AND (_status        IS NULL OR `a`.`status`   = _status)
    GROUP BY `a`.`id`
    ORDER BY
      (CASE WHEN _orderField = 'time'     AND _orderDirection = 1 THEN `a`.`time`     END) ASC,
      (CASE WHEN _orderField = 'time'     AND _orderDirection = 0 THEN `a`.`time`     END) DESC,
      (CASE WHEN _orderField = 'title'    AND _orderDirection = 1 THEN `a`.`title`    END) ASC,
      (CASE WHEN _orderField = 'title'    AND _orderDirection = 0 THEN `a`.`title`    END) DESC,
      (CASE WHEN _orderField = 'category' AND _orderDirection = 1 THEN `a`.`category` END) ASC,
      (CASE WHEN _orderField = 'category' AND _orderDirection = 0 THEN `a`.`category` END) DESC,
      (CASE WHEN _orderField = 'user'     AND _orderDirection = 1 THEN `a`.`user`     END) ASC,
      (CASE WHEN _orderField = 'user'     AND _orderDirection = 0 THEN `a`.`user`     END) DESC
    LIMIT _rowsOffset, _rowsLimit;
END$$

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

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

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

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

DELIMITER $$
CREATE PROCEDURE `ArticleSet`(IN `_params` JSON)
BEGIN
    DECLARE _i TINYINT(3) DEFAULT 0;
    DECLARE _id TINYINT(3) UNSIGNED;
    DECLARE _time DATETIME;
    DECLARE _title VARCHAR(128);
    DECLARE _description VARCHAR(256);
    DECLARE _text TEXT;
    DECLARE _image VARCHAR(48);
    DECLARE _alias VARCHAR(128);
    DECLARE _category TINYINT(3) UNSIGNED;
    DECLARE _tag SMALLINT(5) UNSIGNED;
    DECLARE _tags JSON;
    DECLARE _tags2 JSON DEFAULT '[]';
    DECLARE _user TINYINT(3) UNSIGNED;

    IF (JSON_TYPE(_params->'$.id') <> 'NULL') THEN
        SET _id = _params->'$.id';
    END IF;
    SET _time = _params->>'$.time';
    SET _title = _params->>'$.title';
    IF (JSON_TYPE(_params->'$.description') <> 'NULL') THEN
        SET _description = _params->>'$.description';
    END IF;
    IF (JSON_TYPE(_params->'$.text') <> 'NULL') THEN
        SET _text = _params->>'$.text';
    END IF;
    IF (JSON_TYPE(_params->'$.image') <> 'NULL') THEN
        SET _image = _params->>'$.image';
    END IF;
    SET _alias = _params->>'$.alias';
    SET _category = _params->'$.category';
    SET _user = _params->'$.user';

    IF (_id IS NOT NULL) THEN
        UPDATE  `article`
        SET   `time` = _time, `title` = _title, `description` = _description,
              `text` = _text, `image` = _image, `alias` = _alias, `category` = _category
        WHERE `id` = _id AND `status` = 1;
        DELETE FROM `article_tag` WHERE `article` = _id;
    ELSE
        INSERT INTO `article`
            (`time`, `title`, `description`, `text`, `image`, `alias`, `category`, `user`)
        VALUES (_time, _title, _description, _text, _image, _alias, _category, _user);
        SELECT LAST_INSERT_ID() INTO _id;
    END IF;

    IF (JSON_TYPE(_params->'$.tags') <> 'NULL') THEN
        SET _tags = _params->'$.tags';
        WHILE _i < JSON_LENGTH(_tags) DO
            SELECT JSON_EXTRACT(_tags, CONCAT('$[',_i,']')) INTO _tag;
            IF (JSON_CONTAINS(_tags2, CAST(_tag AS CHAR)) = 0) THEN
                INSERT INTO `article_tag` (`article`, `tag`) VALUES (_id, _tag);
                SELECT JSON_ARRAY_APPEND(_tags2, '$', _tag) INTO _tags2;
            END IF;
            SELECT _i + 1 INTO _i;
        END WHILE;
    END IF;
END$$

Як ви вже, мабуть, зрозуміли з назви, основна мета процедури ArticleSet— збереження даних статті. У неї за допомогою JSON-параметру легко й зручно передають значення всіх полів запису таблиці. Загалом вона схожа на попередню і складається з тих же трьох частин: декларування змінних, перенесення даних і формування запиту. Лише зверну увагу на те, що я об’єднав створення (INSERT) й оновлення (UPDATE) запису таблиці в одну процедуру, в якій потрібну дію визначають наявністю ідентифікатора у вхідних параметрах. У кінці процедури ви можете подивитися приклад використання інших функцій для роботи з типом даних JSON, за допомогою яких я зреалізував потрібний додатковий функціонал.

DELIMITER $$
CREATE PROCEDURE `ArticleUnset`(IN `_id` INT UNSIGNED)
BEGIN
    DELETE FROM `article_tag` WHERE `article` = _id;
    DELETE FROM `article` WHERE `id` = _id;
END$$

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

Виклики з боку клієнта

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

CALL ArticleGet(123456789);

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

CALL CategoryGetIndex('[]');
CALL ArticleGet(3);
CALL TagGetByIDs('14,15,18');

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

CALL ArticleGetIndex('{"_status":"1", "_orderField":"time", "_orderDirection":"0", "_offset":0,"_limit":"15", "dateBegin":"2018-01-01", "dateEnd":"2019-09-24", "title":"львів", "categoryTitle":"пол", "tagTitle":"львів", "userTitle":"стус"}');

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

CALL ArticleSet('{"title":"Заголовок ...", "description":"Опис ...", "text":"<p>Текст ...<\/p>", "image":"some_image.jpg", "category":"5", "tags":[14,15,18],"time":"2019-04-06T16:57", "alias":"заголовок...", "user":"1", "id":"3"}');

За допомогою подібних викликів ці статті в БД оновлюють. Якби поля idне було серед даних JSON, тоді б цей запит не оновлював наявний запис, а створював новий.

CALL ArticleUnset(3);

І нарешті — процедура видалення, в яку, так само як і в процедуру ArticleGet, передають лише один параметр.

Висновок

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

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

Наприкінці вересня ми провели опитування ІТ-спеціалістівщодо останніх ініціатив уряду. Зокрема, чи підтримують вони появу п’ятої групи ФОП для ІТ, створення фонду розвитку людського капіталу, а також що будуть робити, якщо все ж таки нові правила запрацюють. В опитуванні взяли участь 7177 спеціалістів, які наразі працюють у сфері ІТ. Дивимося, що думає спільнота про ці ініціативи.

Портрет респондента

80% проти створення п’ятої групи ФОП для ІТ

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

Не мають сумнівів у доцільності п’ятої групи лише 3% респондентів. Ще 14,2% готові підтримати, але за умови, що перехід буде добровільний.

Чи підтримуєте створення п’ятої групи ФОП для ІТ-КВЕДів

Тут і нижче наведіть на варіант відповіді, щоб побачити повну версію

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

Тестувальники частіше за інших вважають, що третьої групи достатньо для ІТ: 37,3% проти 29,4% серед ПМів.

З досвідом роботи зростає й рівень скептицизму: чверть спеціалістів, що менше року в ІТ, готові підтримати підвищення податку за умови добровільного переходу. Тоді як серед спеціалістів, у яких понад 10 років досвіду, таких лише 11,7%.

Схоже, що спеціалісти, яких потенційно не торкнеться підвищення, більш охоче підтримують ініціативу: 21,5% спеціалістів, що працюють у компаніях розміром до 50 осіб, готові за тих чи інших умов підтримати створення нової групи ФОП, а ось серед респондентів, що працюють у компаніях, де понад 1000 фахівців, погодилися з урядом лише 13,8%.

Чи підтримуєте створення п’ятої групи ФОП із розбивкою за посадами, досвідом, містами тощо

86% не підтримують створення фонду людського капіталу

З підтримкою створення фонду все ще гірше, ніж із п’ятою групою. По суті, фонд готові підтримати лише 3,3% опитаних. Ще 8,7% начебто й не проти фонду, але не готові оплачувати його роботу з власної кишені.

Чи підтримуєте створення фонду ІТ Creative?

Цікаво, що найчастіше варіант «Не підтримую, в Україні немає дефіциту джуніорів» обирали саме початківці з досвідом менше року: 32,2% проти 18,1% серед спеціалістів із досвідом понад 10 років. Щодо останніх, то половина цих спеціалістів не готові підтримувати фонд і вкладати в нього власні кошти.

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

Чи підтримуєте створення фонду ІТ Creative з розбивкою за посадами, досвідом, містами тощо

91% певен, що перейти на п’ять групу змусять усіх

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

Чи вірите, що підвищення податку торкнеться лише великих компаній?

47% залишаться в компанії, але за умови компенсації податків

Якщо компанії почнуть примусово переводити спеціалістів на п’яту групу, то 11,8% респондентів мають намір одразу звільнитися, ще 8% розпочнуть шукати нову роботу. Але все ж таки більшість спеціалістів не планує змінювати роботу, якщо новий податок компанія компенсуватиме. Але чи варто на це розраховувати? За нашим попереднім опитуваннямщодо підвищення податків, 57% ІТ-ФОПів самостійно сплачують податки. І лише третині респондентів компанія повністю компенсує податкові витрати.

Якщо ваша компанія переведе всіх працівників на п’яту групу, ваші дії?

Найменший відсоток тих, хто одразу звільниться, серед тестувальників: 6,8% проти 13,6% у програмістів і 12,8% у топ-менеджерів. Майже чверть спеціалістів із досвідом понад 10 років ще не вирішили, як будуть діяти. Але серед цієї категорії й найбільший відсоток тих, хто одразу звільниться — 15,1%. І це майже удвічі більше, ніж серед спеціалістів з досвідом менше двох років.

Якщо ваша компанія переведе всіх працівників на п’яту групу з розбивкою за посадами, досвідом, містами тощо

Спочатку позитивні зміни в державі, а потім — підвищення податків

Однозначно можна сказати, що більшість ІТ-спеціалістів спочатку хоче побачити, що ті 5%, які вони зараз платять, засвоюється за призначенням. І, як результат, очікують на позитивні зміни в державі. Це ті умови, за яких айтішники погодяться на підвищення податку. Водночас за жодних умов не підтримають підвищення менше чверті спеціалістів.

Що може змінити ваше ставлення до підвищення податку?

Візуалізація даних: Ігор Яновський

Product Engineer — понятие, которое наряду с software engineer все чаще встречается как на Западе, так и у нас. Ориентированность на продукт — одно из перспективных направлений, в которых может развиваться инженер, повышая свою ценность для продукта и, соответственно, свой уровень дохода.

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

Кто такой Product Engineer

Изначально термин Product Engineer пришел из промышленности. В производственном цикле это отдельный специалист, который управляет процессами дизайна и разработки продукта, контролирует его качество и отслеживает соответствие ожиданиям потребителей. Таким образом, он выступает связующим звеном между пользователем и производством. В IТ эту роль чаще всего выполняет связка Business Analyst и Project/Product/Delivery Manager.

Применимо к software engineering термин Product Engineer появился на форумах и блогах в последние несколько лет. Так, в 2017 году в Forbes вышла статья How Is A Product Engineer Different From A Full-Stack Engineer?, как результат дискуссии на Quora. В ней говорится о том, что product engineering — это, скорее, подход к разработке, где инженеры ориентируются не на набор фич, которые необходимо реализовать, а на свойства продукта, которые нужны пользователю.

Следовательно, Product Engineer, помимо расширения технических навыков и оттачивания своих ключевых компетенций (непосредственно software development), сосредотачивается на смежных областях: продакт-менеджменте, бизнес-аналитике и пользовательских интерфейсах. Это не значит, что Product Engineer должен уметь все и сразу и один заменять полноценную команду. Эта роль — классический пример концепции T-shape.

В основе навыков лежит software engineering — главная экспертная компетенция. Горизонталь — это так называемые кросс-дисциплинарные знания. В нашем случае это основы product managementи design, необходимые для того, чтобы инженер мог видеть целостную картину и не просто реализовывать техзадание, а предлагать технические решения с учетом «интересов» конечного продукта.

Таким образом, Product Engineer, вместо того чтобы ждать от Product/Project-менеджеров подготовленные задачи из бэклога, сам является активным участникомего формирования и при этом глубоко понимает потребности и ограничения бизнеса.

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

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

Процесс включает в себя изучение и валидацию идеи продукта, определение портретов пользователей, их проблем и существующих решений на рынке. Его цель — определить соответствие продукта требованиям рынка (product/market fit) и обозначить минимальный жизнеспособный продукт (MVP), который будет ему соответствовать. И только после этого мы переходим к технической детализации. Подробнее о процессе и его этапах можно почитать в статье Agile Product Inceptionв нашем блоге.

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

В Railsware мы отдали предпочтение продуктовости, потому что в основном работаем со стартапами и корпорациями, которые хотят построить новые продукты в рамках своей организации. О нашей модели бизнеса, трансформации и работе с продуктами вы можете прочесть в моих статьях «Product Studio как способ выйти из тупика аутсорсинга»и «Outsourcing vs software consultancy: как поднять рейты до 75 USD/час». В этой статье я хочу акцентировать внимание на особенностях и преимуществах такого подхода к инжинирингу, а не на том, как это все работает у нас.

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

Какие преимущества получает Product Engineer

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

Как это работает на практике, наш инженер Артур Терменжи описывал в статье «Что такое Implementation Plan, или Как планировать реализацию при разработке». Хочу еще раз подчеркнуть, что Product Engineer — это не должность, как, например, Product Manager. Это роль, это подход к разработке. Должности наших инженеров звучат как Full-Stack или Front-еnd Engineer, и при этом они развиваются как Product Engineers.

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

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

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

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

Ценность Product Engineer в том, что он предлагает продуктовые решения. Инженер владеет инструментарием — алгоритмами и технологиями — и с его помощью реализует функционал. Понимание того, как функционал позволит решить проблемы пользователя, — это та самая added value, которую предлагает Product Engineer.

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

Product Engineer: навыки и качества

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

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

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

Применение здесь и сейчас

Универсальной формулы успеха не существует. Product engineering — лишь одно из направлений, в которых может двигаться инженер.

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

• Посмотрите на то, над чем вы работаете, под несколько иным углом. Успех продукта зависит от решения пользовательских проблем (помимо кода, в продукте множество других важных составляющих).
• Стремитесь создавать то, что нужно продукту, а не только то, что хочет Product Owner. Исследуйте, анализируйте и думайте о долгосрочной перспективе.
• Помните о том, что продукты создаются командами, а не частными лицами. Выстраивайте коммуникацию.
• И забудьте выражение «это не моя работа». Можете что-то улучшить? Делайте. Коммуницируйте. Обсуждайте идеи. И неважно, кто вы — менеджер или начинающий инженер. Вы можете генерировать отличные идеи, которые могут сэкономить месяцы ненужной работы.

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

• «Как создать продукт, который купят»Синди Альварес;
• Product Leadership by Richard Banfield, Martin Eriksson, Nate Walkingshaw;
• INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

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

Передісторія

Після першого стажування у Microsoft в 2014-муменеджер хотів запросити мене на роботу: стажування виявилося успішним, мене хотіли бачити знову. Оскільки я лише закінчив другий курс КПІ, запропонували повторне стажування за рік. Про перебіг стажування я писав статтю на DOU.

Результат — фултайм офер. Я мав певні вагання, адже тодішньою компанією моєї мрії був Google, тож вирішив спробувати власні сили ще там. Перебуваючи в США на стажуванні, виділив кілька днів у липні, щоб пройти інтерв’ю в компанії. Їх (усього п’ять) призначили у Сан-Франциско. Усі пройшов, вочевидь, успішно, оскільки за два тижні отримав позитивну відповідь. Щоправда, пропонували релокейт у Лондон: є труднощі з оформленням візи до США, їхня кількість квотована, й апліканти отримують їх у лотерейному режимі (хоча всі вони — спеціалісти з переліку затребуваних професій).

Microsoft хотіла ж бачити мене саме в головному офісі, тож планувала оформити мені H-1B візу, хоча попереджала, що зі значною ймовірністю оформити її не вдасться, і тоді «запасним» містом буде Ванкувер у Канаді. Маючи два варіанти, я ще приблизно два місяці розмірковував, куди піти. Microsoft тим часом ще підняла зарплатню. Я мав можливість торгуватися з ними через дві наявні пропозиції. Це й було однією з причин, чому я пішов на ще одне інтерв’ю — щоб мати додаткові «козирі» і змогу поторгуватися. Google запропонував ліпші умови першим, але Microsoft потім підняла акції вдвічі. Зрештою, я взяв до уваги кілька факторів, вирішуючи, на яку пропозицію зголоситися:

• пропозиція вищої загальної зарплатні (включно з акціями та бонусами);
• у Google гірше налагоджена система інтерв’ю: по-перше, вони довго відповідають щодо оферу, по-друге, чітко не кажуть, де і над чим будеш працювати. У Microsoft я знав: працюватиму над певним проектом зі старою командою, в якій був на стажуванні, тобто вже добре знав цих людей. Та й перелік проектів, над якими працював Google в Лондоні, теж не подобався: гугл-пошук, реклама;
• країна проживання: якщо я потраплю до США, то отримаю набагато кращі фінансові умови, якщо до Канади, то там завдяки великій українській діаспорі почуватимуся певною мірою як вдома;
• Ванкувер входить до рейтингу найкомфортніших міст для проживаннябагато років поспіль.

Зрештою, я закінчив четвертий курс університету, ще півроку після бакалавріату подорожував — і в січні 2017 році переїхав до Канади.

Як переїжджав і шукав житло

Усі логістичні процеси в компанії системно налагоджені, оскільки регулярно працевлаштовується багато осіб з-за кордону. Компанія може або взяти на себе організацію переїзду, або виділити достатньо коштів, щоб влаштувати все самому. Щоправда, така опція існує лише в США, у Канаді мені все організували.

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

Компанія надає два місяці оплаченого проживання в квартирі, розташованій в одному з найелітніших центральних районів Yaletown. Така оренда, за моїми припущеннями, коштувала орієнтовно 3000-4000канадських доларів. Після переїзду я знайшов собі значно дешевший варіант: однокімнатне житло за 1500 канадських доларів, або ж 1200 американських.

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

Я прицільно шукав квартиру в центрі, щоб не їздити на роботу. Шлях з оселі до офісу — 15 хвилин пішки. Оскільки місто невелике, в межах downtown (площа центру приблизно 3,5 на 2 кілометри) усе близько.

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

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

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

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

Вид на Yaletown, джерело

Як влаштована робота

Я почав працювати у тій самій команді людей, які оточували мене під час стажування в США (займався Windows 10). Лише тоді я працював із канадським офісом, тепер же навпаки: офіс у Ванкувері, колеги за проектами — у Штатах. Знову по факту віддалена робота. Спілкування з командою відбувалося здебільшого по скайпу, поштою. Всі, хто сидів у Канаді, не були моїми колегами і займалися своїми справами. На початку через це виникали певні незручності, особливо коли чогось не знаєш і не можеш просто підійти спитати.

Офіс розташований у самому центрі, на п’ятому, шостому і сьомому поверхах CF Pacific Center. Сусідом зверху, на восьмому поверсі, була компанія Sony. Офіс Microsoft сучасний, мінімалістичний, але без таких «наворотів», як у Google. Два поверхи з’єднані між собою внутрішніми сходами. Кухні з безплатними фруктами, чаєм та кавою.

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

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

Як адаптувався

Оскільки я вже мав за плечима досвід двох стажувань по три місяці в США, та й загалом немало подорожував, особливо призвичаюватися до життя в новій країні не довелося. Хіба що не вистачало спілкування, тож відразу знайшов українське ком’юніті у фейсбуці. У Ванкувері багато саме молодих українців, у межах своєї спільноти вони якраз засновували організацію Ukrainian Youth of Vancouver. Я теж до неї долучився, це була спільнота зі своїм президентом, обраним за результатами внутрішніх виборів, та керівниками певних напрямків: медіа, культурні заходи тощо. Влаштовували собі дозвілля: щомісяця збиралися то в пабах посидіти або в чанах попаритися, коли холодно, то, коли теплішало, ходили на пляж або на барбекю, грали у фрізбі або ігри на свіжому повітрі в парку. На момент заснування організації вона налічувала осіб 20, згодом їх побільшало — до 50-60.То було моє основне коло спілкування у Ванкувері.

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

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

Зарплати

Якщо сказати незнайомій людині в Канаді, що ти програміст, вона подумає, що ти, вочевидь, розумний, але особливо цим нікого не вразиш. Програмісти у типових компаніях можуть отримувати всього на 20% більше середньої заробітної плати у Ванкувері (4000-4500канадських доларів, або ж 3000 американських). Що більші доходи, то більше у відсотках зростають податки. Співробітники Microsoft могли отримувати і вдвічі більше за цю суму — з урахуванням усіх акцій та бонусів.

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

Як я відкрив для себе фінансові ринки...

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

Я вирішив купувати цінні папери через відкритий рахунок. Почав із простих інструментів: mutual funds (в Україні це зветься ПІФ — пайовий інвестиційний фонд), exchange traded funds (ETF). Далі перейшов на індивідуальні технологічні акції, оскільки як програміст більше розумів, що відбувається в IT-індустрії. У період феноменального росту криптовалют багато уваги присвятив вивченню історії грошей, монетарної політики та базових понять у макроекономіці, щоб зрозуміти фундаментальну ідею, яка стоїть за біткоїном.

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

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

А тоді до мене потрохи підкралося емоційне вигорання.

... і як пішов із корпорації

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

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

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

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

Плюси і мінуси життя в Канаді

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

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

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

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

Перспективи

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

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

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

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

За допомогу в підготовці статті дякую Ярославі Тимощук

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

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

Иллюстрация Дарины Скульской

Зачем нужны встречи 1:1

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

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

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

Менеджер регулярно общается с командой в офисе и вне работы в формате:

• планирования:
• стендапов;
• ретроспективы;
• груминга;
• мозгового штурма;
• курилки;
• игровой зоны.

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

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

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

От чего зависит эффективность встреч

Встречи 1:1 работают и действительно приносят пользу. Но их эффективность зависит от следующих факторов.

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

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

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

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

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

Выделенное время. 1:1 требует затрат времени. Проведение встречи с одним сотрудником может занимать от 15 до 30 минут. На подготовку и подведение итогов в среднем тратится еще примерно столько же. Кроме того, нужно время на выполнение задач, которые формулируются на таких встречах. Всего получается около 1,5-2часов на встречу с одним сотрудником. Если у вас 2 команды по 5 человек и вы проводите 1:1 раз в 2 недели, то получается, что на это уходит до 40 часов в месяц. Неплохо, да? И это та активность, которая у большинства висит на фоне как второстепенная и не очень важная :)

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

Ибо встречи 1:1:

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

...не работают :(

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

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

Подготовка

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

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

Если никакие вопросы при подготовке не приходят на ум (а такое бывает), рассмотрите следующие четыре направления для встречи один на один:

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

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

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

Проведение

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

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

Вопросы для фидбэка по производительности:

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

Вопросы, которые помогают определить направление карьеры:

• В каких направлениях ты хотел бы быть лучше (прокачаться)?
• Чему бы ты хотел научиться? Что улучшить или в чем стать лидером?
• Есть ли область вне текущей роли, в которой ты чувствуешь, что можешь реализоваться?
• Если бы ты мог играть идеальную для тебя роль в компании, как бы она выглядела?

Личное:

• Как жизнь? Что нового?
• Как провел выходные? Где был?
• Как семья? Дети?
• Где вы отдыхали в последнее время, что понравилось?

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

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

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

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

Реализация

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

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

Как люди понимают, что тот или иной инструмент полезен? Благодаря простому сравнению: 1) раньше не было инструмента — было по-другому; 2) теперь он есть — стало лучше или хуже, но что-то точно изменилось! Раньше не было встреч 1:1 и каждый находился в своем мыльном пузыре. Да, комфортно, но жизнь проходит мимо, твой личный потенциал остается нереализованным.

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

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

Соблюдайте элементарное правило: пообещал — делай. А если пообещал и не делаешь, тогда не жужжи, что тебе что-то не так.

Отслеживание результатов

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

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

Когда я приходил в новый коллектив в качестве менеджера и начинал со встреч 1:1, я иногда сталкивался с непониманием. Когда у тебя в команде идеальные 5 +/- 2 человека, проводить встречи несложно. Когда с тобой взаимодействует несколько команд по 30 человек, стоит выбрать 7-9 человек,которые играют ведущую роль и которые, в свою очередь, проведут остальные 1:1 со своими командами.

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

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

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

Доверие

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

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

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

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

P. S. Предлагаю следующую статью посвятить только разбору примеров вопросов 1:1 и правильной самоустановке на конструктивное общение для таких встреч. Поставьте «+» в комментариях и добавляйте ваши пожелания в этом направлении. По количеству просмотров и плюсов буду ориентироваться о востребованности следующей статьи.

Любые предложения, пожелания также можете писать мне в Facebook.

Всем спасибо, ваш #dgorin ;)

Меня зовут Александр Черненко, и я 5 лет занимаюсь Front-end-разработкой. Я Technical Lead в компании Nullgravity, и мне удалось вырастить уже более 15 разработчиков с уровня Junior до Middle и выше. Я управлял разными командами, иногда приходилось задействовать на пять фронтов одновременно на одном проекте; бывало, что консультировал только одного человека, который самостоятельно разрабатывал проект.

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

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

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

Допустим, вы достаточно компетентны и умеете разрабатывать аккуратно и без code smells на JS или TS. Какой Front-end Stack по мере развития вашего приложения обеспечит надежность и хорошую производительность и при этом не сильно устареет с течением времени?

Казалось бы, лидирующие позиции давно уже захватили библиотека React и фреймворк Angular. Но их рейтинги могут стать шаткими в ближайшие годы, ведь на арену постоянно выходят конкуренты, такие как Svelte, Stencil и другие. Их авторы весьма амбициозно заявляют, что именно их инструменты лучше, быстрее, удобнее. А что, если их развитие подхватят крупные корпорации и они начнут по своим характеристикам догонять или даже выигрывать у старых добрых «реактов» и «ангуляров»?

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

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

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

В чем проявляется избыточная вариативность

Начинающим Front-end-разработчикам вообще трудно разобраться, какой инструментарий выбрать и чьим guidelines следовать. Что делать после того, как научился писать на JS? Учить Angular, React, Vue или, может, сразу Svelte?

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

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

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

У Android-разработчиков проблема вариативности инструментов не так явно выражена. В качестве основной IDEиспользуется Android Studio, а в плане архитектуры кода есть «мейнстримовый» подход — Clean Architecture, который уже полюбился Android-сообществу и устоялся в нем. Guidelines, code style, tools во многом рекомендуются компанией Google.

Схожая ситуация у iOS-developers. Есть экосистема, которую заботливо создала и поддерживает компания Apple. Для большинства случаевдостаточно использовать родные модули Swift, не прибегая к модулям сторонних библиотек. А в плане архитектуры существует Clean Swift Xcode — наиболее популярная IDE.

В Back-end-технологиях тоже много устоявшихся стеков. Литература, написанная для Java-разработчиков, устаревает не так быстро, как для разработчиков в web. Самый используемый фреймворк — Java Spring. Этого уже достаточно, чтобы решить, чему обучаться на начальных этапах.

У .NET developers экосистему поддерживает .NET Foundation и сам Microsoft.

Front-end выглядит иначе, ведь у нас нет единой «верховной» частной корпорации (такого уровня, как Google, Apple, Oracle или Microsoft), которая централизованно управляла бы правилами разработки для всех. Наши приложения должны одинаково хорошо работать на всех популярных операционных системах и браузерах.

Мы работаем со стандартами некоммерческих организаций, такими как W3С, WHATWG, TC39 и другими. И здесь, с одной стороны, полная свобода действий, с другой — полный хаос. За создание наиболее «правильного» инструментария и архитектурных подходов ведут конкурентную борьбу как Google и Facebook, так и менее крупные компании.

Вариативность в стандартах для web-приложений и ее причины

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

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

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

Front-end — это все, что касается клиентской части, и эта клиентская часть может технически существовать в разных формах.

Основные формы — Multi-Page application (форма классических веб-сайтов, существовавшая изначально), Single-Page application, Server-Side Rendering Application и модный сейчас Progressive Web Application. Не исключено, что в ближайшем будущем появятся другие варианты.

Также важно понимать, что деплоить Front-end-часть веб-приложения можно тоже по-разному: это может быть классический монолит, JAMstack-архитектура либо так называемые micro frontends.

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

Факторы развития Front-end Stack

Основными факторами, которые развивают Front-end Stack, являются следующие.

Развитие в протоколах прикладного уровня (application layer protocols)

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

Объемы и скорость потребляемого трафика в сети постоянно растут.

Особенно это касается передачи видео. На рынке медийного контента уже практически везде поддерживается формат 4K, и такие гиганты, как Netflix, YouTube и прочие регулярно решают проблемы трансляции видео в высоком качестве.

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

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

Возьмем, к примеру, протокол транспортного уровня.

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

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

Для их решения разработали протокол прикладного уровня QUIC, но не поверх TCP, а поверх UDP.

Схема работы протокола QUIC на основе UDP (источник)

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

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

Поверх слоя TCP браузеры сейчас умеют работать с 2 протоколами приложений — старым добрым HTTP/1.1 и многофункциональным HTTP/2, который с 2015 года поддерживают большинство вендоров; но, как по мне, он все еще находится на стадии активного освоения со стороны поставщиков инструментов для разработки.

Работа внутри HTTP/1.1 тоже постоянно расширяется за счет появления новых заголовков, поддерживаемых браузерами.

Когда появился HTTP/2, было много статей о том, что теперь не нужно прибегать к сборке application bundle в 1 файл и не нужно объединять картинки в sprites.

На практике же достичь этого результата не так просто, детальнее можете почитать почему.

Вторым важным преимуществом HTTP/2 стала возможность сразу отдавать браузеру необходимые assets благодаря Server Push. Опять же, для этого необходимо использовать ряд вспомогательных библиотек, которые разруливают в таком случае проблемы с кэшированием и другие нюансы.

Еще одной абстракцией прикладного уровня поверх TCP являются WebSockets.

Веб-сокеты, в отличие от HTTP, позволяют работать с двунаправленным потоком данных, что делает эту технологию совершенно уникальной. При этом WebSockets обязывают вас брать на себя решение ряда вопросов по поддержке стабильного соединения и передачи данных (решенные за вас автоматически в HTTP/1.1 и HTTP/2, так как там действует классическая синхронная модель «запрос — ответ»). Эти проблемы фактически оставлены на откуп разработчикам. Они, с одной стороны, дают свободу действий, с другой — плодят множество «велосипедов». Если не вдаваться в подробности, то по факту мы имеем ряд конкурирующих популярных библиотек типа Socket.IOили SockJS (которые нужно настраивать одновременно и в браузере, и на стороне сервера), и, естественно, каждая имеет свои плюсы и минусы.

Допустим, вам необходимо разработать веб-приложение с push-notifications в браузер. Какие технологии вы возьмете в 2019 году? WebSockets или HTTP/2 плюс SSE? Однозначного ответа нет. Подробнее о проблематике выбора можно почитать здесь.

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

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

Развитие возможностей браузеров

Новые протоколы расширяют возможности браузеров. Browser Api сейчас вообще разрастается сумасшедшими темпами. Уже никого не удивишь push-notifications или service workers.

Много обновлений выходят в контексте общей парадигмы Progressive Web Applications продвигаемой Google. Они запланировали внедрение ряда новых APIв будущем, которые еще сильнее расширят возможности браузеров. Из них меня больше всего впечатлил анонс «Native File System API», которая позволит считывать и редактировать файлы на ОС пользователя.

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

Из других интересных браузерных анонсов мне запомнились Task Scheduling API и экспериментальный проект CSS Houdini. Первый позволит разработчикам более явно контролировать и расставлять задачи JavaScript-движка по приоритету, второй дает возможность с помощью JS и вне MainThread описывать поведение своих произвольных CSS-правил.

Развитие форматов обмена данными

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

Из самых модных и часто используемых можно отметить GraphQL от Facebook, gRPC + Protobuf от Google (в связке с HTTP/2, но с «костылями» на фронте).

Еще довольно популярным является формат JSON-RPC.

Эволюция языков программирования

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

Начиная с 2015 года ES очень активно развивается и дополняется. Фактически мы каждый год получаем обновления в ECMAScript от Ecma International Technical Committee 39. Самое свежее обновление — это ES-2019 (ES10), ну а на стадии черновика в комиссии находится редакция ES-2020.

Мультипарадигмальность

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

Требования к продукту

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

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

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

Развитие фреймворков и библиотек

Во второй половине двухтысячных Single Page Application только начинали появляться. В большинстве своем за UI отвечали верстальщики, многие из них не знали толком JavaScript и довольствовались библиотекой jQuery (которую сейчас так ненавидят).

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

А еще в 2009 году Райан Дал разработал Node.js. С развитием и популяризацией Node.js и его пакетного менеджера npm появился популярный и простой способ размещать свои «библиотечки» на JS и совмещать их.

Вот тут на арену стали выходить большие фреймворки с сопутствующей инфраструктурой по сборке, тестированию, отладке и т. д. Например, в 2010 году вышел Backbone.js на архитектуре Model-View-Presenter.

Популярные фреймворки и библиотеки для Front-end (источник)

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

Суть js-фреймворков

Но также мы видим, как продолжают появляться достаточно интересные и элегантные способы — такие, например, как библиотеки lit-html или hyper-html.

Давайте взглянем на описание относительно молодого движка для веб-приложений Svelte: Svelte is a new way to build web-applications. It’s a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.

А еще есть Angular, React, Preact, Vue.js, Elm, Ember.js, Meteor, Mithril, Polymer, Aurelia и много других.

Так или иначе, на каком «велосипеде» вы поедете, решать только вам.

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

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

Есть vendors, которые занимаются созданием кроссплатформенных и изоморфных продуктов. Это Angular Universal, React Native, Flutter и другие, но это уже является отдельной темой для разговора и касается не только Web Front-end.

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

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

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

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

По сей день вся суть фреймворков и библиотек для построения web-applications состоит в том, чтобы предложить эффективный и удобный способ для работы с DOM (Document Object Model), деревом в браузере.

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

Существует множество вариантов решения этой задачи.

Я считаю, что сейчас на рынке наибольшую популярность в этом плане обрели React и Angular с их движками Fiber и Ivy.

Основные драйверы развития Frond-end Stack

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

О чем важно помнить, выбирая Front-end Stack

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

У фронтендеров, да и у большинства разработчиков, огромною роль играет community.

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

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

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

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

В таком формате я познакомился с Progressive Web Applications. В компании мы проводили research на внутреннем проекте, и одной из целей было получение практического опыта использования PWA. Мы тогда научились работать с service workers и узнали различные технические нюансы. К примеру, мы узнали, что, применяя service-workers для кэширования ajax-запросов, обязательно использовать только fetch, соответственно, невозможно кешировать данные для service-worker c помощью библиотек, под капотом которых используется старый браузерный метод XHR. Это может быть реальной проблемой, если вы используете готовые решения. Мы тогда использовали npm-пакеты для работы с firebase, у них под капотом был XHR. Правда, тогда нам повезло, так как для них уже была реализована своя библиотека для offline-кэширования. Также мы поняли, что настроить базовый конфиг PWA не составляет труда, а вот работа с настройкой кэширования для режима offline оказалась затратной.

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

Если же у вас совсем нет времени на проведение экспериментов, вы можете ознакомиться с проектом RealWorld. Это множество копий Medium, реализованных на разных стеках. Вы можете ознакомиться со всеми исходниками и пощелкать демки.

Я всегда обязательно смотрю на поддержку Typescript и наличие хороших test-suites, test-renderers, test-runners для изучаемого фреймворка, так как для больших проектов важно иметь статическую типизацию и наличие unit-tests.

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

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

Выводы

Устоявшихся подходов во Front-end еще не существует, эксперименты с технологиями, движками и с оптимизацией производительности продолжаются на уровне js-движков, фреймворков, компаний и даже стандартов.

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

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

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

При выборе определенного фреймворка рассматривайте не только его, но и всю сопутствующую или отсутствующую (как в случае с новейшими фреймворками) экосистему: возможности добавления статической типизации (TypeScript / Flow) и наличие типизированных npm-пакетов, testing tools, performance profiling tools и др.

Фреймворки ничто, мастерство все :)

Пишите код чисто. И да пребудет с вами сила!

На последнем проекте у меня как UX-дизайнера возникла необходимость поделиться базовыми знаниями UX с командой разработки. В будущем это должно помочь им избежать наиболее грубых юзабилити-ошибок в продукте. Также я подумала, что эти базовые гайды могут быть полезны и другим. Например, начинающим специалистам и мидлам в Front-end, QA, Product management, а также всем, кто занимается разработкой своих pet projects. Дизайнерам многие вещи, описанные ниже, скорее всего, известны. Все юзабилити-гайды не поместились бы в формат статьи, поэтому здесь наиболее критичные и частые ошибки, с которыми мне приходилось встречаться на разных проектах при оценке и редизайне существующих интерфейсов.

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

Controls

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

Я хочу акцентировать внимание на основном контроле — кнопках.

Buttons

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

По визуальным стилям различают следующие виды кнопок: сплошные (solid), контурные (outlined/ghost), в виде ссылки, с иконкой, только иконка без заголовка, комбо-кнопки, toggle-кнопки (встречаются реже).

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

Первое.Кнопка находится в состоянии disabled, то есть это визуально считывается: увеличивается прозрачность фона кнопки и текста, при этом текст должен оставаться читаемым; меняется цвет кнопки на оттенки серого. Если стайл-гайд фреймворка диктует использования кнопки с серым фоном для дефолтного состояния, не следует для него делать надписи на кнопке белого и серого цвета. Серый фон + серый/белый текст = disabled.

Второе.Какие условия пользователю нужно выполнить, чтобы вернуть кнопку к состоянию default (например, обозначение обязательных инпут-полей звездочкой *). Нельзя оставлять пользователя без объяснения, почему любой элемент системы задизейблен.

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

Возможные варианты на английском:

• verb (Create, Save, Delete, Copy, etc);
• verb + noun (Create Copy, Save Draft, etc.);
• редко noun, особенно для Action buttons, и чаще используется для ссылок (Details, Settings, Profile, etc).

Написание тайтлов.В одну строку. Всегда. Возможные варианты:

• все ЗАГЛАВНЫЕ буквы. Чаще для названия из одного слова, реже из двух, никогда для предложений (SIGN UP AND GET OUR SPECIAL OFFER);
• только первая буква заглавная, например Create, Save Draft.

Padding — расстояния от тайтла до границ кнопки. Бывают горизонтальными (по бокам от надписи) и вертикальными (сверху и снизу от надписи):

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

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

Action buttons and action button groups

Call to action (CTA) button — это кнопки, которые по своему функциональному назначению требуют от пользователя определенных действий или подталкивают его к таким действиям для завершения пользовательского сценария. Часто используются для подтверждения действия в диалоговых окнах, при сабмите данных. Являются обязательным шагом при манипуляции с контентом если его нельзя вернуть к предыдущему состоянию (undo, revert).

По смысловой нагрузке action buttonsмогут быть:

• primary — по смыслу желательные для системы/бизнеса;
• secondary — по смыслу «опциональные» для системы, именно наличие secondary buttons дает пользователю чувство контроля при взаимодействии с системой;
• tertiary (реже).

Action buttonsмогут состоять:

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

Визуальная иерархия выстраивается по логике:

• primary — сплошные кнопки;
• secondary — контурные или ссылки;
• tertiary — кнопки-ссылки или кнопки-иконки;
• иногда tertiary или одна из secondary визуально стоят обособленно от связки primary + secondary.

NB!Есть два главных паттерна расположения кнопок primaryи secondaryотносительно друг друга:

• primary — слевадля пользователей Windows OS;
• primary — справадля пользователей Mac OS, иногда mobile.

И тот и другой считается верным и зависит от профиля аудитории.

Антипаттерны:

• использование двух и более кнопок primary и/или трех и более secondary;
• без визуального различия между primary/secondary/tertiary;
• заменять primary Call to action buttonsкнопкой-иконкой.

Бывает, группы кнопок объединяют и выносят на Action Panel — панель над рабочей областью для манипуляции контентом этой области. Здесь чаще всего используют кнопки:

• только с иконками;
• комбо;
• сплошные и контурные.

Некоторые из кнопок, чаще всего сплошные или контурные, могут появлятьсяи прятатьсяна Action Panel как отклик системы на действие пользователя, в зависимости от контекста выполняемой им задачи (user task). Это вторичные действия с контентом в рабочей области. Например, выбор нескольких сообщений в меcсенджере или нескольких колонок/строк в таблице может вызывать дополнительные Action Buttons.

Icon button

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

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

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

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

Чем меньше размер иконки, тем менее детализированной она должна быть.

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

Selection controls

Toggle/switch(er)

По сути, это переключатель между состояниями ON/OFFили Enabled/Disabled, появился относительно недавно и перешел из мобильных в веб- и десктоп-интерфейсы.

• toggle, или switcher, имеет два состояния, on/off, для одного и того же атрибута сущности / для одной и той же функции этой сущности;
• всегда располагается справа от тайтла;
• включение и выключение toggle дает пользователю мгновенный фидбек, изменение в лейауте / в поведении системы и т. д.;
• всегда доступен для переключения между двумя состояниями: on/off;
• не требуетдополнительного подтверждения через Call to action buttons (CTA), а значит, не привносит в систему необратимых изменений при переключении on/off;
• антипаттерном считается переключение между двумя противоположнымипо смыслу сущностями через toggle (например, Save vs. Delete, Sound on vs. Mute, All vs. Custom).

• при активации (положение on) может раскрывать группу с дополнительными контролами: радиокнопками и чекбоксами.

• toggle при активации (положение on) не должен раскрывать дополнительную опцию с одним toggle;
• при активации (положение on) слабым паттерном считается раскрытие вложенной группы опций с множеством toggle.

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

Radio Buttons

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

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

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

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

Чекбоксы

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

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

• может быть или не быть дефолтное значение (on/off);
• подтверждение выбора требует использования CTA, идут перед CTA в лейауте (на практике не всегда);
• выбор опции on может активировать логически «вложенные» инпут-филды (текст-филд, селектор, календарь и т. д). Вложенные сущности должны быть доступны для превью без выбора конкретного чекбокса.

К чекбоксам в интерфейсах обычно нет критических замечаний, из последнего необычного могу назвать: расположение чекбокса справа от названия опции; перечень около 30 чекбокс-опций текстом в строку (а не сгруппированными multiselect-фильтрами); обязательный чекбокс «I have read terms and conditions» под CTA-кнопкой.

Dialogue windows / Modals / System Feedback

Одна из форм обратной связи и диалога с пользователем — это модальные или диалоговые окна. Также для обратной связи могут использоваться notification messages, или toasts. Модальные и диалоговые окна всегда требуют от пользователя подтверждения действий, то есть использования CTA в интерфейсе.

У эффективного диалога, а взаимодействие пользователя и системы по стандарту ISO 9241 рассматривается как диалог, есть свои ключевые параметры (в стандарте ISO дается более расширенно):

• контекст (о чем общаемся);
• понятность (мы говорим на одном языке с собеседником);
• разборчивость речи (все сказанное передается, распознается и интерпретируется с минимальным искажением);
• это свободное волеизъявление, то есть у участника есть возможность отказаться от диалога. К счастью, интерактивная система не может себе позволить игнорирование пользователя.

Сравним, как эти принципы переносятся при проектировании диалогового окна.

• Контекст.Диалоговые окна не должны прерывать основной сценарий пользователя; зачастую выступают как уточнение/подтверждение последнего/первого шага пользовательского сценария.
• Понятность.Текст сообщений придерживается контекста предшествующих действий и оперирует общепринятыми терминами (как в системе, бизнес-домене; другие устоявшиеся паттерны для текста в интерфейсах). Текст остается лаконичным и понятным.
• Разборчивость.Форматирование текста диалога удобочитаемо.
• Свобода.Диалоговое окно можно закрыть.

Также могут встречаться контекстные окна (Context/In-context windows), которые не прерывают, а дополняют или инициируют выполнение пользовательского сценария.

Например:

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

Fixed or draggable?

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

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

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

Часто понять, что нужно использовать: Fixed или Draggable, — можно изучив пользовательский сценарий или после тестирования, фидбэка от пользователей.

General notes

Flow interruption and Context

1. Старайтесь не разрывать выполнение пользовательского сценария (user flow / scenario), заставляя его избыточно навигировать или отвлекаться на сопутствующие второстепенные задачи.
2. Не забывайте о Back-навигации, если возникает необходимость разорвать сценарий.
3. Старайтесь избегать тупиковых ситуаций в user flow, подсказывая пользователю возможные последующие шаги.
4. Не забывайте о подсказках для Empty statesили во время Onboarding.

Empty States — «заглушка» для функционала в интерфейсе, когда еще не введены релевантные данные. Например, вместо пустой таблицы отображать сообщение для пользователя о том, как сделать так, чтобы наполнить эту таблицу данными. Или в разделе Uploads, когда еще не подгружены файлы, отображать сообщение о том, как добавить контент. Можно обобщить и сказать, что те сущности, которые могут быть созданы и будут отображаться в виде группы в дальнейшем, должны иметь скрин с состоянием Empty state. Подсказки во время Onboarding упрощают вход новичка в систему и ознакомление с базовым функционалом, основным flow. Оставляйте за пользователем возможность пропустить Onboarding, а также информируйте о его прогрессе, например сколько шагов пройдено и сколько осталось до окончания процесса. Слишком детализированный Onboarding, который объясняет, как работать с простыми контролами, скорее служит «костылем» в непродуманном дизайн-решении.

Custom UI elements and custom interactions

Избегайте придумывания уникальных UI-элементов, их новых интерактивных состояний, особенно если существуют устоявшиеся паттерны. Дизайн в игровой индустрии позволяет придумывать уникальные контролы (например, две стороны монеты и ее переворачивание могут работать как toggle on/off). В остальных случаях не надо.

Искажения существующих паттернов зачастую заводятся как UI-баги.

Duplication and Negative space

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

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

Выводы

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

Казалось бы, ничего особенно критичного в таких интерфейсных недочетах нет, если рассматривать частные случаи по отдельности. Однако если подобные ошибки есть, обычно их много. Более того, когда пользователь мотивирован и нет альтернативного (конкурентного вашему) решения, он/она все равно пройдет этот путь, обучится, придумает свои «костыли» и будет использовать продукт. Если захочет. Но на это все уйдет намного больше когнитивных ресурсов и времени. В том числе вашего времени и времени команды, отведенного на саппорт пользователей.

Я бы хотел поделиться своими наблюдениями по поводу культуры проведения собеседований на украинском IT-рынке, требований к кандидатам и процесса найма в общем. Занимая позицию QA Automation Lead, я имею достаточно опыта собеседований как со стороны компании, так и со стороны кандидата. Надеюсь, описанное ниже будет полезно и людям, которые ищут работу в IT, и тем, кто надеется найти талант.

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

Чего кандидату ожидать от собеседования на позицию QA

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

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

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

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

Чего ждут компании от кандидата на позицию QA

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

Junior

Теоретическая база

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

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

Способность к обучению

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

Простые вопросы вроде «Чем вы занимаетесь после работы?», «Как саморазвиваетесь?» и «Что вас мотивирует?» помогут понять, важен ли для соискателя рост.

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

Первые книги, которые я читал

Middle

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

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

Senior

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

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

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

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

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

Применение опыта

С хорошим Senior-специалистом всегда есть о чем поговорить. Особенно если это Senior SDET. (Привет пацанам из чата =))

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

Знание языков программирования

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

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

Lead Engineer

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

Soft skills

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

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

К вопросам о резюме

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

Влияние «известности»

Так как я являюсь автором одного из известных блогов по автоматизациии часто выступаю на различных QA-ивентах, меня, естественно, знают. И этот фактор неоднозначно влияет на процесс собеседования. У меня были собеседования в виде 15-минутногоразговора с последующим оффером и двухчасовое техническое с жесткими вопросами о Core Java и с кодом на бумажке.

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

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

О культуре собеседований

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

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

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

Зачастую интервьюеры проводят собеседования на низком уровне, потому что:

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

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

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

Собеседование — это всегда очень субъективная вещь.

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

Вывод

В целом на украинском IT-рынке низкая культура найма на работу. Во многом это связано с отсутствием HR-бренда компании.

Почему меня как кандидата это пугает? Я не хочу попасть в плохую компанию с непонятными процессами.

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

Удачи на собеседованиях!

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

Всем привет! Меня зовут Евгений Ткаченко. Я в IT уже более 10 лет и сейчас разрабатываю в основном под систему Android. Также я программист-энтузиаст со многими идеями и их реализациями, ведь ничто не может остановить разработчика, особенно когда он хочет создавать :) Сегодня я хочу поведать вам о своем продукте LocaleBro. Это веб-платформа для локализации мобильных приложений, заточенная под разработчиков, переводчиков и менеджеров.

Что такое LocaleBro

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

В системе есть такое понятие, как проект. Грубо говоря, это приложение или несколько приложений под Android/iOS, содержащие почти одинаковые тексты. К примеру, Facebook для Android и Facebook для iOS можно добавить в один проект, так как у них тексты практически идентичны.

Далее весь процесс сводится к следующему:

• Разработчик, не заморачиваясь с конвертацией, загружает файл фраз из кода в проект на платформу в существующем формате (xml/strings).
• Менеджер/разработчик дает переводчику доступ к проекту.
• Переводчик в свою очередь добавляет переводы на странице платформы, правит тексты.
• Разработчик делает экспорт файлов фраз в нужном формате (xml/strings) к себе в код.
• Все довольны, и можно релизить :)

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

Просто, быстро и без лишней работы. Далее подробнее.

Предыстория

На одном проекте мы столкнулись с ужасной реальностью перевода приложения под Android и iOS на 6 языков, и эти телодвижения мне показались дикими, особенно когда за окном 2019 год.

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

1. Android- и iOS-приложение на 90% состоят из одинаковых фраз и словосочетаний, и делать двойную работу по переводу никому не хотелось.

2. Иногда люди не понимают, что нельзя просто так удалять из файла что-либо, изменять ключи и т. д.
3. XML-форматне особенно удобно менять человеку, который не понимает, что такое tag и разметка.

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

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

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

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

LocaleBro предоставляет каждому проекту (а не пользователю) свой лимит, и после регистрации вы можете создавать сколько угодно проектов. По умолчанию предоставляется лимит на перевод 1000 строк для каждого из них (иногда есть акции, которые увеличивают этот лимит, но базовая цифра такая). Добавив 10 проектов, пользователь получает 10 000 переводов строк, а после добавления 100 проектов — 100 000 соответственно. Немало, правда?

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

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

В LocaleBro мы реализовали такое сопоставление при импорте текста. Работает оно следующим образом. Импортируем два таких файла:

И получаем 6 строк на перевод вместо 12, так как сам контент-то идентичный.

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

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

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

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

Мы вывели все фразы в одну таблицу с удобным поиском. При желании можно оставить только 2 локали на экране и просматривать оригинал и перевод с попутным его редактированием после двойного клика по тексту. Все просто до невозможности.

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

В нашем случае нет ограничений по количеству людей. Если вам надо, чтобы 5 человек работало с проектом, просто дайте им доступ. А для сохранения целостности проекта мы выделили 3 варианта ролей:

1. Boss — может делать с проектом все: давать доступ любому человеку, добавлять локали, добавлять/удалять фразы, добавлять/удалять переводы, импорт/экспорт, переименовывать, то есть все вплоть до полного и безвозвратного удаления проекта.
2. Developer — все то же самое, но вот только он не имеет права удалить, а также переименовать или назначать кого-то боссом.
3. Translator — эта роль позволяет только добавлять переводы и других переводчиков. Переводчику и не надо ничего удалять, так как потом могут возникнуть проблемы с кодом у разработчика.

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

Для регистрации на LocaleBro нужен только email и пароль (или вообще регистрация в 1 клик с Facebook/Gmail). Все остальное по желанию и для того, чтобы человек видел, кому дает доступ на проект, а не только email-адрес.

Собственно, это и есть основные пункты, которые подтолкнули на создание bro-локализации.

Как все это работает

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

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

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

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

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

Таким образом, переводчику не понадобится переводить текст кнопки Cancel дважды — один раз для Android и второй для iOS, ведь в проекте теперь это одна строчка для обеих платформ. Это не только экономия времени, но и денег, ведь каждый символ на счету :)

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

Как видим, ничего сложного в этом нет. Но беда в том, что в наш век делать все вручную как-то дико, что ли. И тут нам на помощь приходит... автоперевод текста с использованием Google Translate.

Просто нажимаем кнопку Translate using Google Translate — открывается окно с информацией о текущем состоянии проекта. И по нажатии на Start Translation мы видим сообщение All Done.

А это значит, что весь проект переведен на 2 дополнительных языка практически мгновенно.

Да, Google Translate далеко не идеален, и все переводы надо просматривать носителю языка, но поверьте, это намного быстрее, чем переводить все с нуля. Ну а если надо изменить какую-то строку, просто дважды кликаем на тексте (можно также воспользоваться меню).

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

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

Для любителей смотреть все в движении мы создали небольшую видеоинструкцию:

Стек, технологии

Руководствуясь правилом KISS, мы перебирали различные варианты создания, но остановились на следующем:

• Node.js — основной двигатель системы, быстрый и легковесный. Преимущество было в скорости разработки и работы самого веб-сервера. После создания ядра приложения на основе паттерна MVC добавление микросервиса в проект занимает минимум времени и усилий. При использовании Node.js можно довольно уверенно продвигаться, создавая страницу за страницей. Уже написанные модули и библиотеки упрощают разработку многократно. Например, для подстановки значений в HTML был выбран EJS, для HTTP-сервера — Expressи т. д.
• MySQL — хранитель данных, так как SQL позволяет гибко и точно создавать запросы, доставая из базы только нужную информацию, при этом легко оперируя таблицами.
• Bootstrap — ускоритель создания пользовательского интерфейса, потому что все уже написано до нас :) Если нужно создать html-страницу, то лучшего, пожалуй, не найти. Вам остается только скомпоновать элементы в нужную композицию тегов и классов.

Исходя из стека, в команде пригодился бы Node.js Developer, SQL Developer, верстальщик, человек, имеющий опыт локализации мобильных приложений, Project Manager, маркетолог, копирайтер. Прикинув, что по весу я могу сойти за очень маленьких двух человек, решил сделать все сам, так как порой создать лично будет быстрее и качественнее, чем найти и проконтролировать нескольких людей. К тому же немалый опыт разработки на back-end/web был, следовательно, почему нет? :)

Какой камень оказался самым тяжелым

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

Сейчас и в будущем

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

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

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

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

Спасибо, что дочитали до этого места :) Всем добра!

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

Аргументы в пользу JavaScript

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

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

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

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

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

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

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

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

Обзор JS-фреймворков для end-to-end-тестирования

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

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

Например, Protractorхорошо подходит для проектов, написанных на Angular, потому что в нем есть встроенные функции для специфических загрузок Angular-элементов.

Ниже статистикаколичества звезд и открытых issues в библиотеках. Здесь явно можно выделить WebdriverIO, который стабильно имеет хороший показатель закрытых проблем.

Protractor

Плюсы:

• Protractor — это единственный фреймворк, который из коробки поддерживает кастомные определения AngularJS-элементов. Если у вас Angular, используйте Protractor.
• Удобная поддержка TypeScript и разных фреймворков для unit testing (Jasmine, Mocha, Cucumber и пр.).

Минусы:

• Нет поддержки мобильного тестирования.
• Написан как обертка над WebDriverJS. Если будут проблемы с WebDriverJS, автоматически они будут и в ProtractorJS.

Базовый пример теста на ProtractorJS:

Nightwatch.js

Плюсы:

• Похож на WebdriverIO и тоже является кастомной имплементацией W3C WebDriver API.
• Легко добавить новую функцию.
• Не нужно выбирать между Jasmine и Mocha.

Минусы:

• Нет поддержки Mocha и мобильного тестирования.
• Меньше поддержки, чем у WebdriverIO и Protractor.

Cypress

Плюсы:

• В отличие от большинства end-to-end-фреймворков, не использует Selenium. Архитектура работы с браузером была написана полностью, и, в отличие от Selenium, Cypress не запускает удаленные команды через сеть, а работает напрямую с программой.
• Быстрая и удобная настройка. Необходимо запустить только одну команду для установки всех пакетов, и нет необходимости ставить все отдельно.

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

Минусы:

• Плюс, который в то же время является и минусом, — это тот факт, что Cypress не использует Selenium для end-to-end-тестирования. Что порождает много проблем в работе. Работа с браузером не всегда стабильна, и на сегодняшний день на GitHub висят открытыми более чем 900 проблем.
• Нет поддержки мобильного тестирования, и, судя по комментариям создателей нативной поддержки, никогда и не будет.
• Поддержка ограниченного количества браузеров: Canary, Chrome, Chromium, Electron.
• Платная параллелизация тестов. Хотите запускать в несколько потоков — придется платить.

WebdriverIO

Плюсы:

• WebdriverIO — это кастомная имплементация W3C WebDriver API. Не нужно привязываться к имплементации WebDriverJS.
• Поддержка синхронного кода. Можно забыть об асинхронности JavaScript.
• Удобная базовая настройка с помощью встроенного интерфейса для командной строки wdio.
• Поддерживает почти все тестовые фреймворки BDD и TDD.
• Поддерживает удобную библиотеку ‘webdrivercss’ для сравнения CSS-стилей элементов на странице.

Минусы:

• Большое различие между последними версиями (WebdriverIO 4 и 5).
• Хуже кастомизирован для автоматизации AngularJS, чем Protractor.

Пример теста Login. Основное, на что можно обратить внимание, это отсутствие await/async или Promises. В этом примере был использован паттерн Page Object, фикстуры и другие подходы, которые применяются при написании автоматизации.

Синхронность WebdriverIO обеспечивает технология Fibers, иногда ее еще называют coroutines. У этой технологии много плюсов и преимуществ, но существуют подводные камни, например запуск в асинхронном коде сделает весь код асинхронным. Как по мне, за этой технологией будущее.

Приступить к написанию первых тестов с помощью этой библиотеки очень просто. Для начала нужно установить npm-пакет @wdio/cliв новосозданном проекте.

npm i --save-dev @wdio/cli

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

./node_modules/.bin/wdio config

Я предпочитаю Mochaкак тестовый фреймворк и sync-режим для запуска тестов. Из репортеров на начальном этапе можно использовать Spec-репортер, который красиво выведет результаты тестов в консоль, при дальнейшем росте проекта несколькими строчками можно будет добавить Allure. В дополнение к этому при изначальной настройке проекта можно добавить wdio-selenium-standalone-service, который будет менеджить запуск Selenium WebDriver, без необходимости отдельно ставить СhromeDriver.

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

describe('dou.ua page', () => {
 it('should have the right title', () => {
 browser.url('https://dou.ua');
 const title = browser.getTitle();
 assert.strictEqual(title, 'Сообщество программистов | DOU');
 });
});

Где командой browser.url('') мы открываем браузер и можем сразу делать все необходимые проверки.

Автоматизация — это несложно. Как говорится, главное начать.

Полезные материалы

• 5 minutes for WebdriverIO
• WebdriverIO BDD
• WebdriverIO get started
• Github-репозиторий с примером базового окружения

Выводы

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

Преимущества:

• Скорость написания тестов значительно выше, чем на Java или C#.
• Ниже порог входа для старта проекта.
• Больше взаимодействия внутри команды (проявилось в нашей команде, что, может, и не относится к выбору фреймворка автоматизации).
• Большое количество готовых решений очень разных проблем, которые возникают.

Недостатки:

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

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

Меня зовут Николай Мозговой, я старший разработчик и ментор в Sigma Software. Сейчас занимаюсь разработкой облачного бэкенда для климатических систем.

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

Для таких случаев неплохо иметь напоминание или шпаргалку; поэтому я составил список вопросов, которым нужно уделить внимание. Этот список и не краткий, и не исчерпывающий, но, по крайней мере, он представляется вполне понятным и осуществимым. Должен признаться: на представленный ниже материал меня вдохновил один очень хороший курс, который я проходил несколько лет назад и который рекомендую всем, кого интересует вопрос InfoSec/Cybersecurity. Это курс Software Securityот Университета штата Мэриленд, свободно доступный на Coursera.

Особенности безопасности ПО

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

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

Свойства безопасности

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

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

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

• апгрейды приложений;
• продление прав на IP-адрес;
• продление прав на доменное имя;
• обновление сертификатов шифрования и аутентификации.

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

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

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

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

• Предотвращение (Prevention) — исчерпывающее устранение дефектов. Например, можно предотвратить целые категории дефектов, используя языки, безопасные для памяти, такие как Java или C# вместо C/C++.
• Смягчение (Mitigation) — уменьшение вреда от эксплуатации неизвестного дефекта. Например, вред от взломанной базы данных можно значительно уменьшить, если зашифровать сохраненные данные. Еще один пример — блокировка учетных записей с подозрительным поведением и требование дополнительного подтверждения для потенциально опасных действий.
• Обнаружение (Detection) — выявление и анализ атаки (то есть мониторинг). Необходимо как можно скорее получать информацию о потенциально вредоносных действиях. В этом случае очень помогает комплексная телеметрия в реальном времени.
• Восстановление (Recovery) — нейтрализация урона. «Быстро поднятое упавшим не считается». Поэтому всегда необходимо иметь резервную копию данных и дополнительные ресурсы, которые будут доступны в случае экстренной необходимости. Кроме того, крайне важно иметь процедуры восстановления взломанных учетных записей.

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

Отдавайте предпочтение простоте (Favor simplicity — prevention).

• Выбирайте простую архитектуру. «Keep it simple, stupid» — этот известный мем прекрасно работает в этом контексте. Например, подумайте дважды, когда вы выбираете между старомодным монолитом и сверхкрутыми микросервисами. Всегда учитывайте имеющиеся возможности и опыт.
• Применяйте безопасный выбор по умолчанию (fail-safe defaults). Никогда не используйте пароли, выданные по умолчанию, применяйте стандартную криптографию, отдавайте предпочтение белым спискам, а не черным и т. д.
• Не ожидайте продвинутого пользователя. Чем больше возможностей вы даете, ничего не ограничивая, тем выше вероятность злоупотребления ими. Например, установка приложений из ненадежных источников на Android (файлы APK) требует отдельной активации этой функции в настройках устройства.
• Отдавайте предпочтение простому пользовательскому интерфейсу (UI). Повторюсь, сложность — враг безопасности. Сложный UI повышает вероятность ошибки как со стороны разработчика, так и со стороны пользователя.
• Не позволяйте пользователям делать выбор в отношении безопасности. Вы не должны предполагать, что пользователи понимают схемы криптографии или хотя бы правила безопасного поведения в интернете, поэтому не позволяйте им выбирать алгоритмы и ключи шифрования или небезопасные пароли.

Доверяйте с осторожностью (Trust with reluctance — prevention & mitigation).

• Используйте минимальную доверенную вычислительную базу (trusted computing base). Чем больше компонентов — как аппаратных, так и программных — имеет ваша система, тем больше возможных направлений для атак. В этом смысле каждая новая платформа, которую вы собираетесь поддерживать, и каждый сервис, который вы интегрируете, должны рассматриваться как источники риска и опасности.
• Избегайте применения вашей собственной криптографии. Криптография — это настолько нетривиальный предмет, что попытка реализовать ее аспекты самостоятельно не более чем тщеславие, если, конечно, вы не являетесь экспертом. Правильный подход заключается в использовании открытых, стандартных для отрасли протоколов и алгоритмов.
• Максимально ограничивайте полномочия для компонентов и пользователей. Будьте осторожны при предоставлении прав своему приложению и пользователям (даже непрямым образом). Вашему приложению действительно нужен доступ к файловой системе? Точно ли нужно выполнять операции чтения из базы данных под учетной записью с более высоким уровнем доступа?
• Валидация входящих данных. Не скармливайте вашей системе некорректные данные. Четко определите границы корректности данных и проверяйте их, используя белые списки.
• Усиливайте конфиденциальность — ограничивайте доступ к персональным данным.Формальное определение персональных/личных данных может различаться в зависимости от местного законодательства, но общая характеристика личных данных — это прямая или косвенная возможность определить, какому лицу эти данные фактически принадлежат.
• Обособление (compartmentalization) — используйте процессы, контейнеры и «песочницы», чтобы отделить компоненты и даже операции друг от друга.

Защита в глубину (Defense in depth — prevention, mitigation & recovery).

• Безопасность в силу разнообразия (HTTPS + безопасный язык + шифрование данных + VPN). Объедините все механизмы безопасности, имеющиеся в вашем распоряжении. В то же время не используйте инструменты вне своей компетенции, а при необходимости найдите эксперта.
• Используйте стандартные и открытые решения. Избегайте принципа «безопасность через неясность» (security through obscurity). Избавьтесь от мысли, что проприетарное программное обеспечение или протоколы (особенно ваши собственные) обеспечивают защиту лишь на том основании, что они никому не известны. Только общедоступные и изученные инструменты и протоколы могут претендовать на безопасность.

Мониторинг и отслеживание (Monitoring and traceability — prevention & recovery).

• Собирайте логи и телеметрию. Не забывайте установить оповещение при обнаружении опасных/подозрительных событий.
• Создавайте резервные копии / снимки состояния (snapshots). Храните их на отдельных серверах и разрабатывайте механизмы их восстановления.

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

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

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

Требования:

1. Определите требования к безопасности (сценарии нарушения, abuse cases). Сценарий нарушения — противоположность сценарию использования (функционального требования, use case). Он четко определяет, что система не должна делать.
2. Определите необходимые свойства безопасности для компонентов системы (то есть конфиденциальность, целостность, доступность). Прямо обозначьте, какие части хранимых данных являются конфиденциальными. Определите, какие роли присутствуют в системе и с какими данными они должны работать. Опишите требования к доступности.
3. Определите механизмы безопасности для поддержки этих свойств (аутентификация, авторизация, аудит — три Au). Наличие механизмов этих трех Au считается золотым стандартом безопасности. Система не может быть безопасной, если в ней отсутствует один из них.
4. Моделируйте угрозы. Это означает необходимость определения злонамеренного агента и возможных видов атак (например, это может быть сетевой трафик, локальные файлы или даже отображаемые данные и т. д.).

Разработка:

1. Архитектура, учитывающая угрозы безопасности (ответ на ранее определенные модели угроз в архитектуре системы).
2. Анализ/оценка архитектурных рисков (выявление потенциальных недостатков в архитектуре).
3. Применение определенных выше принципов безопасности (предотвращение, смягчение, обнаружение, восстановление).

Реализация:

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

Тестирование:

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

Распространенные изъяны проектирования и реализации

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

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

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

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

OWASP и топ-10 уязвимостей

Open Web Application Security Project (OWASP) — это некоммерческая организация, ориентированная на повышение безопасности программного обеспечения. И вы можете найти отличное применение ее ресурсам. Эта организация предоставляет полезные рекомендации и «шпаргалки» для популярных платформ разработки, таких как .NETи Java.

OWASP в первую очередь известна своими списками «топ-десяток», описывающими наиболее распространенные уязвимости в разных доменах:

• OWASP Web Top 10.
• OWASP Mobile Top 10.
• OWASP IoT Top 10.

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

Выводы

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

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

Привіт, мене звуть Андрій. Я пройшов шлях від інженера до проектного менеджера, а згодом став СЕО компанії Stanfy. За цей час зроблено десятки різноманітних проектів ― від невеликих у мобільній розробці до монстрів у телекомі. Для Stanfy, сервісної компанії, важливою ланкою в роботі були проектні менеджери. У певний момент, через бажання бути ефективнішими, ми майже залишилися без них.

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

Ця стаття ― ретроспективний погляд на моделі роботи компаній Долини, з якими ми стикнулися й аналізували, а також значення проектного менеджера в цих процесах. Чимало інформації тут узято з десятків розмов з колегами на ринку США, а також під час інтерв’ю проектних менеджерів, де мені довелося побувати з обох сторін. І, чесно кажучи, найцікавішими виявилися кейси, де я був кандидат. Для початку погляньмо на одну з найпопулярніших моделей організації роботи в інженерній команді серед компаній Долини.

Менеджмент продукту й менеджмент інженерів

«Here we call PM a Product Manager not Project Manager», ― такою була відповідь одного з моїх клієнтів, коли ми лише починали працювати з компаніями Кремнієвої долини. Це був невеликий стартап тоді, а тепер це вже кілька сотень людей та успішний бізнес.

Абсолютне розуміння того, чому деякі компанії Долини мало знайомі з роллю проектного менеджера до мене прийшло значно пізніше. Розгляньмо структуру організації роботи в сучасних компаніях, зокрема Facebook, Amazon, Netflix, Google (FANG). Адже їхній підхід до роботи копіюють чимало компаній навколо, особливо стартапи, що наймають колишніх працівників цих гігантів.

У центрі таких технологічних компаній завжди був і є продукт. Але найчастіше це не монолітна структура, а набір багатьох елементів ― за аналогією до мікросервісів. Цим напрямом займаються Product Managers (PM) ― люди, що відповідають за бізнесову частину цифрового продукту: як його виводити на ринок, як розвивати і що нині в пріоритеті. У таких людей є велика автономія в ухваленні рішень без погодження з керівництвом, якщо запропоноване в межах загальної стратегії компанії. Менеджери продуктів, їхні директори й віце-президенти (VP) ― це майже окрема структура в межах компанії.

Комплементарно до цього існують інженерні команди, які й займаються технічною реалізацією та підтримкою продуктів. Саме в тісній співпраці PM та інженерів народжуються нові ідеї і запускаються експерименти в продуктах. З мого останнього спілкування з командами компанії Amazon: команди з 5―8 людей самі не лише генерують нові ідеї, а й ставлять собі цілі на майбутнє. Часто ніхто не приходить зверху й не каже, що робити ― команда повинна бути максимально автономна й відповідати за свою частину продукту. Звичайно, для масштабніших ініціатив може знадобитися кілька таких команд.

Інженерною командою формально керують Engineering Managers (менеджери інженерів). Це значить, що кар’єрні плани людей, цілі команди та координацію бере на себе саме Engineering Manager. Зазвичай таким менеджером є інженер з досвідом, хто вже працював тривалий час розробником і має серйозну технічну експертизу як для ухвалення технічних рішень, так і для роботи з людьми. Саме людина з релевантним досвідом може найліпше зрозуміти й організувати інженерів. Хоч бувають і винятки.

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

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

Така формула надзвичайно поширена в більшості стартапів Кремнієвої долини й серед гігантів індустрії.

Наприклад, ось історія активного стартапу. Компанія Samsara натепер налічує понад 150 інженерів і близько 1000 працівників загалом. За 4 роки її оцінка зросла до 6 мільярдів доларів, і компанію вже не перший рік додають до списку перспективних у Долині. У продуктній лінійці в неї близько десятка різних продуктів, об’єднаних платформою керування флоту автотранспорту. Перший проектний менеджер з’явився близько року тому. До цього ж десятки продуктних команд працювали в конфігурації: команда ― інженерний менеджер ― продуктний менеджер.

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

Кремнієвій долині не потрібні проектні менеджери?

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

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

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

Якщо для досягнення певної цілі потрібно декілька проектів, їх об’єднують у програму. Назва позиції при цьому може дуже сильно варіюватися: хтось і далі називається Project Manager, а хтось уже Program Manager. Щоправда, в розмовах із софтверними командами Google, Facebook, Amazon зазвичай фігурують Program Managers.

Проте в межах однієї назви є певний розподіл. Найперше такі ролі можна умовно розділити на дві категорії: узагальнена Program Manager (PgM) і Technical Program Manager (TPM). До того ж кількість різноманітних додатків перед словосполученням Program Manager просто гігантська і зазвичай визначає сферу роботи людини: Engineering (Hardware), Operations, Marketing, Software, Supply Chain тощо. До цього додається варіативність у назвах у межах різних компаній ― суть одна, а назви різні. Так в Apple частіше можна зустріти Software Engineering Program Manager, ніж Technical Program Manager.

У чому ж різниця між PgM і TPM? Банально, але це глибина технічних знань. Від TPM вимагають глибшого розуміння технологій і вміння з ними працювати. Усе задля того, щоб така людина могла ефективніше комунікувати між різними сторонами проекту й не бути лише проміжною ланкою. Наприклад, коли потрібно планувати розвиток потужностей дата-центру на наступні 5 років, то менеджер з власного досвіду повинен розуміти складнощі такого процесу й мати змогу оцінити інформацію.

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

Ось деякі з видів діяльності, якими займаються PgM у відомих компаніях і з якими я знайомий:

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

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

Наскільки технічним повинен бути TPM

Чудовим критерієм, щоб зрозуміти вимоги до таких людей є питання, що ставлять під час інтерв’ю, коли наймають на роботу. Отож, ключовим технічним питання тут є «System design» (проектування софтверної системи). Зазвичай у межах такого питання ставлять бізнес-завдання, а кандидат повинен у результаті спроектувати технічну систему, яка б дала змогу її розв’язати. Особливість таких питань ― їхня невизначеність і велика кількість можливих рішень, тобто тут немає однієї правильної відповіді.

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

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

У ширину чи в глибину

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

На моє запитання: «У чому ти бачиш основну цінність програмного менеджера для команди?» інженери з Долини найчастіше згадували такі чинники:

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

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

Що обрати для себе

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

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

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

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

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

3. Якщо у вас серйозний технічний бекграунд і ви не дуже хочете його втрачати або ж маєте цікаву спеціалізацію (наприклад, data science), то посада TPM вам може гарно пасувати. Там можна й технічно зануритися за потреби й відповідати за широку картину проекту або програми. Для деяких компаній вона дуже близька до менеджера інженерів ― принаймні за рівнем вимог.

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

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

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

Відповідно, якщо ви захочете опанувати роль PgM або TPM десь у Facebook або Google, то вам безпосередньо не будуть підпорядковані люди ― у них свої менеджери.

Висновки

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

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

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

В первой частицикла мы рассмотрели важность составления плана обучения, вопросы по Java Core и работе с БД. В этой части обсудим вопросы в комментариях и поговорим о двух популярных фреймворках: Spring и Hibernate.

Вопросы в комментариях

О происхождении вопросов для подготовки

Все они были заданы мне или моим коллегам на собеседованиях на позицию Junior/Middle людьми с уровнем Middle/Senior/Lead. Проекты: два крупных банка, сотовый оператор, внутренние квалификационные собеседования.

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

Зачем джуну знать про <любая технология или принцип>?

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

Выбор стратегии при подготовке

В девелопменте можно выделить две основные стратегии поиска работы:

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

Первая стратегия сильно доминирует и давно себя зарекомендовала. Не всем нравятся сложные цели, и не каждому они под силу. У кого-то семья, домашние заботы, сторонние занятия и банально некогда выкладываться на 150%. Да и, говоря на чистоту, стратегия трудоустройства в нетоповые компании имеет мало минусов. Ну попадется вам как-бы-сеньор в наставники, поделаете некоторое время ерундовые задачи исключительно на умение серфить Stack Overflow. Зато уже с зарплатой, опыт какой-никакой в копилку капает, и свободного времени для самообразования больше.

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

«Что дозволено Юпитеру, не дозволено быку»

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

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

Претендуешь — соответствуй

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

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

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

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

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

Приступим к темам и вопросам.

Spring

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

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

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

Обычно, когда на собеседовании дело доходит до Spring, происходит примерно следующий диалог:

• Из Spring с чем-то работали?
• Да, изучал вот это и вот то.
• Хорошо, давайте немного поговорим на эти темы.

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

О чем меня спрашивали часто: core, data, mvc.
Чуть реже — boot, security.
О чем не спросили ни разу за все время: aop, test.
Это статистические данные, не более.

Разделение по уровням джуновости достаточно условное.

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

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

Дальше вперемешку немного вопросов, связанных с перечисленными темами (только те, которые повторялись):

• Опишите механизм dependency injection простыми словами.
• Как работает модуль спринга <такой-то>, какой флоу выполнения (что куда заходит и как обрабатывается в процессе)?
• Как создается контекст? Каков порядок инициализации в контексте?
• Какие знаете различные способы конфигурации бина? Дефолтный скоуп бина? Какие вообще скоупы бывают? Для чего они используются?
• Какая разница между BeanFactory и FactoryBean?
• Расскажите об autowired-аннотации. Есть поле, помеченное autowired, как Spring находит бин и инжектит, какой алгоритм? Что, если реализаций интерфейса две? Можно ли вешать autowired на несколько конструкторов?
• Для чего нужен @PostConstruct? Что выполнится раньше — @PostConstruct или конструктор?
• Аннотация @Transactional, что знаете о ней? Какие у нее параметры? На что ее можно повесить? Какой паттерн используется как основа (прокси)? Опишите требования к методу, на который хотим повесить эту аннотацию.
• Дефолтные property в Spring boot: для чего они, где конфигурируются?
• Какой паттерн используется в основе spring security (chain of responsibility в виде цепочки фильтров)?
• Перечислите виды авторизации в Spring security. За что отвечает аннотация @Preauthorize?

Hibernate

Изначально я хотел объединить темы Spring и Hibernate в одну, но в итоге решил не создавать хаос в относительно структурированном подходе. После штудирования статей о том, что это за фреймворк и какие его функции, обязательно погуглите разницу между JPA, Spring Data JPA и Hibernate. И обязательно поймите ее, это сильно упростит процесс понимания взаимодействия Spring и Hibernate.

Вопросы:

• Как Hibernate формирует запросы? Что такое фетчинг, батчинг?
• В каких состояниях может быть entity? Расскажите немного о них.
• Кеш запросов — расскажите о всех уровнях.
• Когда возникает lazy initialization exception?
• Расскажите об известной в Hibernate проблеме N+1 select.
• Расскажите о стратегиях наследования сущностей.
• Если внутри сущности есть коллекции, подгружаются ли они по умолчанию?

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

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

Иллюстрация Дарины Скульской

Предыдущая статья:Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 1

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

Якщо хочете показати свої «ретро-світлини» — присилайте фото, коментарі та DOU-профіль на maria@dou.ua.

Олег Селін, PHP Developer в Clockwise Software

«Ніт, мені не стільки років, щоб цей самопальний Spectrum 48K був актуальний, просто що дядько з міста привіз, тому і радий був у 1999 році!», — кажу я, хлюпаючи і потираючи очі.

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

Тепер я — девелопер із крутим компом і офігенним почуттям гумору!

Ярослава Глинська, Senior Software Engineer в N-iX Lviv

Я почала вивчати програмування в університеті: навчалася в ЛНУ ім. І. Франка на факультеті прикладної математики. Одразу зрозуміла, що є неймовірно талановиті хлопці (мабуть, були і дівчата, але я тоді таких не зустрічала), які живуть і горять програмуванням. «Очевидно, що вони стануть ІТ-гуру та працюватимуть над цікавими міжнародними проектами, а мені нічого не світить», — пам’ятаю, що думала тоді.

На 4 курсі (2002 рік) пішла працювати у відділ програмного забезпечення комерційного банку. Банк мав власне ПЗ, написане на C++. Код не був мені доступний, але була база даних, а також stored-процедури з бізнес-логікою.

На роботі у мене часто просили складніші звіти, яких не було в стандартному ПЗ, тому була можливість вивчити SQL. Іноді при проблемах з новими версіями ПЗ я знаходила помилки в stored-процедурах і повідомляла про них розробникам.

Так працювала три роки, аж доки колишній однокурсник не порадив подати резюме на вакансію C++ девелопера в команду підтримки на шведський проект в молодій компанії N-iX. Я вчила C++ в університеті, тому подумала, що навряд чи зумію написати щось нове і якісне, але розібратися з існуючим зможу. В N-iX мені дали тестове завдання: зробити акваріум з хижими та мирними рибками, які мали плавати за правилами. У процесі демонстрації спочатку все йшло добре, але потім риби почали діяти не так, і програма припинила працювати. Мені пощастило, адже в компанії мені вирішили дати шанс і таки запропонували посаду Software engineer of maintenance team. Так почалася моя кар’єра в ІТ. Працюю в N-iХ з 2006 року.

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

Dmytro Ivanov, SVP of Technology в SoftServe

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

В 1994-1996-х роках ми вже гралися в «Warcraft», тоді ж в школі у нас з’явилась інформатика. Починали експериментувати, програмуючи для Spectrum на Basic, вчились спочатку просто копіювати програми, написані іншими людьми, а потім вже почали писати свої. Операційна система і сам редактор завантажувались зі стрічки аудіо-касети, тому коли комп’ютер виключався, всі програми, що були в пам’яті, зникали, і ми щоразу починали писати спочатку.

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

У мене одразу було внутрішнє розуміння, що я вступатиму на якусь з кафедр, де викладали комп’ютерні науки та програмування. Тоді ще близько не йшлося про якісь заробітки, або про розуміння, що саме це стане моїм фахом — просто мені подобалося і подумав, чому б і ні. У результаті, я вступив до Львівської політехніки на «Програмне забезпечення». На момент вступу вже мав досвід роботи на Visual Basic. Уже в університеті я працював спочатку на Turbo Pascal, згодом на assembler x86, потім вже прийшов Borland Delphi 4, C++ з майкрософтівським MFC, далі PHP, трохи lisp, VBA for MS Access, JavaScript і, зрештою, у 2002 році на 6-мукурсі навчання SoftServe мене звів із .NET Framework 1.0, на якому я на довший час і зосередився.

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

З 16 липня 2002 року почав працювати в SoftServe. Моїм першим проектом стала десктопна аплікація під Windows, яка допомагала модернізувати shipment та order management processes. Мені доводилося спілкуватись з американським клієнтом, на той час англійської я не знав. Розумілися ми мовою програм, жестів та міміки, а також «видозміненою» англійською в емейлах. Було дуже цікаво пояснювати людині щось, не розуміючи толком мови. Потім вже були перші поїздки до США, перші проекти в ролі технічного консультанта.

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

На фото — 2006 рік.

Володимир Мельник, IT Manager в Tucha

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

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

Андрей Котульский, Senior Back-end developer в LetyShops

Когда я родился, калькулятор еще назывался ЭВМ и занимал две комнаты. Чуть позже, в 89-м,папа подарил нам с братом-близнецом (он тоже сейчас разработчик) новомодный калькулятор МК-52. Так и началось мое знакомство с программированием.

Тогда мы могли задавать ему алгоритмы, по которым вычислялись сложные уравнения. Правда, написанием кода это сложно назвать. А вот почувствовать, что это такое, получилась, когда нам купили компьютер «Радио-86РК». Отец не стал загружать на него игры, а записал только Basic. Поэтому мы от безысходности решили сами написать игру. Один строчил в тетради, а другой набирал. В итоге у нас получился аналог игры «Сокобан». Исходники до сих пор лежат где-то на чердаке в школьной тетрадке в клеточку. Мы были очень довольны, все запускалось. Перед нами была наша собственная игра!

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

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

Первый оплаченный заказ из программирования я получил в 2002 году. Это был сайт римско-католической церкви Украины. Писал его на чистом PHP и HTML без фреймворков, а затем поддерживал работу сайта и администрировал. Этот период из жизни и запечатлен на фото.

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

Алексей Пальчик, Senior Director в EPAM Kharkiv

Я начинал карьеру в продуктовой компании, работы было много. Надо было совмещать задачи инженера, тестировщика, администратора баз данных, а через несколько месяцев после старта еще и тимлида, бизнес-аналитика, проектного и product-менеджера. Java была основным языком программирования, потому что на ней уже была написана большая часть нашего продукта. Кроме того, она была знакома мне еще со студенческих времен. В те времена мы выделяли технологическую специализацию, а изучали и применяли конкретные вещи по мере необходимости. Осознанно заниматься самообразованием я начал пару лет спустя, уже в ЕРАМ: проходил Sun-сертификации для Java-инженеров.

На этих фото — 2005 год, моя первая работа в IT и вторая в жизни командировка к клиенту. Я провел в Африке три недели (кстати, в 150 метрах от офиса, где были сделаны эти фото, протекает река Нигер, в которой водятся крокодилы). В той командировке я совмещал обязанности системного администратора, администратора баз данных, программиста SQL и Java-инженера. Внедрял программное обеспечение для биллинга в местной телекоммуникационной компании и помогал с переездом серверного центра. И хотя для клиента меня представляли как консультанта по внедрению технологических решений, по меркам ЕРАМ я был скорее full-stack middle-инженером.

Кстати, в силу того, что с заказчиками мы общались чаще всего в ICQ и по телефону (видеосвязь была еще мало распространена), в первой командировке со мной и коллегой произошла забавная история. В 2005 мы полетели в Ирландию, в офис клиента, внедрять продукт, над которым работали несколько месяцев. Оба впервые были на таком задании и как выглядят зарубежные заказчики не знали. Решили одеться так, как на наш взгляд было правильно: в костюмы с галстуками. Конечно, на фоне местных резидентов технологического парка, куда мы прибыли, одетых в стиле, который сейчас называют smart casual, мы с коллегой выглядели забавно. Почти как люди в черном, только с неуверенными походками :) Урок мы усвоили и уже на следующий день от пиджаков и галстуков отказались.

На моем рабочем месте — мониторы и клавиатуры от двух серверов клиента и ноутбук, который я привез с собой. На экранах можно увидеть код, написанный на Java 1.4, консоли операционной системы AIX (UNIX-подобной ОС от IBM) и окно ICQ — самого популярного IM на тот момент.

Олександр Соловйов, Head of Product в Kasta.ua

Це 2004 рік, моя кімната в общазі, де ми мешкали вчотирьох на 18 м². Другий або третій курс (схоже, що третій, бо вже купив 19″ монік, який важив майже як я сам). Часи великої кількості металу, пива та NNTP-груп news.ntu-kpi.kiev.ua. Згори стоїть книга з чорно-білою обкладинкою, і чогось мені здається, що то одне з видань «Programming Perl». На щастя, за гроші я почав писати вже на Python’і :)

Не працював у той час, але у кінці 2003 — на початку 2004 рр. працював черговим сисадміном у Colocall за $120 на місяць :) З Колоколу більше за всього запам’яталося, як я проникав на замкнений двір Леонтовіча, 9 у новорічну ніч. Там у другій гермозоні (перша була на Тургенєвській) здох один з серверів у нас на обслуговуванні і довелось не дуже тверезому вночі йти його рятувати.

Юрій Возій, Software Architect у Luxoft

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

— Ти HTML знаєш?
— Ну так, робив трохи верстку.
— О, тоді будеш вести наш сайт.
— Ммм, ок.

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

А зарплата була 750 гривень на місяць :)

На фото приблизно 2004: найбільш жестякова ніч. Ми з колегою Станіславом Гричкосієм опівночі оновлювали сєрвак «Сороки» до FreeBSD 5.0. У цю ніч зрозуміли, що увесь сайт треба переписати з PHP 3 на PHP 5, інакше ніяк далі не просунутися. Я переписую сайт на PHP 5, а Стас перезбирає всі ці Апачі та Постгреси з сорців. Якийсь параметр з configure забули — починай наново. Працювали всю ніч. Нам тоді вдячно оплатили таксі додому.

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

Дмитро Єригін, Senior .NET Developer в Redwerk

2005 рік. Це фото зроблене в Лювені, Бельгія. Тоді я працював в компанії Materialise NV, де розробляв систему OnSite для онлайн замовлення 3D prototyping.

Andreas Flodstrom, СЕО в Beetroot

У 2012 році ми з Густавом Хенманном приїхали до Києва на старенькому «Жигулі» та оселилися у квартирі свого друга. Ми мріяли започаткувати ІТ-компанію, тому одразу взялися до справи. Роботи було багато, а грошей на оренду офісу — мало, тому просто працювали, не відходячи від ліжок (якщо надувні матраци можна так назвати).

Денис Ступак, Data Scientist в SPD-Ukraine

На момент, коли зроблене фото, я тільки-но захистив дисертацію та став доцентом кафедри із зарплатнею в 600 грн. Того року, Університет обладнали 3-макомп’ютерними класами, на комп’ютерах встановили нову CAD-систему Компас. На фото ми якраз намагаємося розібратись з нею (креслили).

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

Борис Концевой, СEO в Intetics

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

К слову, для начала работы я купил 3 компьютера в офис. Это были новенькие Pentium, которые на тот момент стоили по $3 000 за штуку. При том, что средняя зарплата программиста была $200-250. И в первую же ночь их вынесли из офиса. Компьютеры так и не нашли. На этом история компании могла бы и закончиться. Но американские партнеры пошли на встречу и одолжили еще $10 000.

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

В то время мы работали на американские страховые компании, и все проекты крутились вокруг страховки жизни. С этим было интересно, т.к. что такое «страховка жизни» в наших краях не знал никто. Тогда не было таких страховок, да собственно и не уверен, появились ли они сейчас. Поэтому изучали «на ходу». Помню, купил в книжном магазине в Сан-Франциско 5 экземпляров «Толкового словаря страховых терминов». Там страшно удивились, что 5. А я был приятно удивлен, что такая книга существует! Она и была настольной у всех. Позволяла читать спеки. Благодаря партнеру в Сан-Франциско мы как-то сразу начали с крупных фирм: AIG, AllState, Travelers, Equifax и других.

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

Интересный факт: смешно, но мой современный лэптоп не добавил ничего к моей продуктивности. Что кардинально изменилось, так это способ получения информации: ответ на любой вопрос, поиск которого занимал 2-4часа и больше, сейчас доступен в течение 5-15 минут.

Павло Почуєв, Managing Partner в SSA Group

Наша перша команда у 2007 році складалася з трьох програмістів: двоє писали на С++ і один (тобто я) працював з PHP, бо тоді стало популярним піднімати сайти на WordPress. Тож у нас в колективі була гармонія між хардкором та чимось попсовим :)

Ця дружня атмосфера зігрівала і прикрашала сірі будні, витягуючи морально у часи старту компанії. Іноді ми навіть потопали, не образно, а в прямому сенсі. Наш перший офіс постійно затоплювало від злив та снігопадів. Але ті, хто варився в суміші з С++ та Вордпресу, звикли долати перешкоди :)

Ірина Галицька, Project Manager в SoftServe

В IT я потрапила через суперечку з другом. Він казав, що в мене ніколи не вийде вивчити FreeBSD та отримати роботу. Я вивчила, пройшла співбесіду і досі працюю в цій сфері.

Я тоді була студенткою 5-гокурсу університету Тараса Шевченка на факультеті «Радіофізика та електроніка». Самостійно почала вивчати нетворкінг, протоколи та інше для IP-телефонії, адже за нашою суперечкою, я повинна була працевлаштуватись в конкретну компанію, яка вимагала цих навичок. Паралельно я почала вивчати FreeBSD на курсах, була там єдиною дівчиною. Постійно в центрі уваги.

У той час, коли я починала (2006 рік), дівчата були рідкістю в IT. На одну зі співбесід, крім мене, прийшли 15 кандидатів — всі хлопці.

Щоправда, на тій першій співбесіді я також шокувала PMа: коли ми говорили про FreeBSD та TCP/IP, він сказав що не вірить, що дівчина-блондинка так може. Суперечку я таки виграла повністю, а от в IT працюю досі. З того часу дівчат в ІТ, не лише в управлінні проектами, але й в програмуванні та навіть R&D все більше — і це круто.

Yevhen Mionchynskyy, Performance Testing Service Lead в SoftServe

У 1992 році я був в 9-мукласі і в нашу школу привезли комп’ютерний клас з комп’ютерами «Електроніка УК-НЦ». Інформатика в ті часи починалась з 10 класу, проте ми з другом постійно ходили, заглядали до аудиторії. Врешті-решт, вчитель інформатики Пасічник Олена Георгіївна «здалась» та дозволила нам займатись зі старшими 10-11класами (за що їй величезне дякую!).

Ми почали ходити на уроки та позакласні заняття, на яких писали ігри-лабіринти, вирішували математичні задачки на BASIC на базі операційної системи РАФОС.

Я навчався на факультет прикладної математики та інформатики ЛНУ ім. Івана Франка. На 4-мукурсі влаштувався в «Укртелеком» (міські телефонні мережі). Офіційно моя посада називалась електромеханік, адже в штатному розкладі того підрозділу не було нічого пов’язаного з IT.

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

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

У жовтні 1999 року, будучи студентом, я прийшов в SoftServe, в команду, яка писала на Visual FoxPro. Щоправда, мені завжди цікавіше було розбиратися в системах, шукати проблеми, возитися з комп’ютерами і тому з часом я переключився на системне адміністрування.

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

Загалом, сфера IT моє життя не змінила, бо це і є моє життя.

Александр Горбатовский, CEO в Dom-3D

25 мая 1990 года я был принят на работу в НИАТ. Рабочее место у меня было за терминалом ЭВМ ЕС-1036. Иногда я работал за машиной СМ-1420. ЕС-1036 имела около 10 терминалов, это значит, что 10 человек могли якобы одновременно работать за одной ЭВМ. Кстати, мощность ее была на уровне IBM PC-AT 386. Вскоре я себе взял в личное пользование самую мощную персоналку в нашем отделе. Меня еще удивляло, что никто особо и не хотел на них работать.

ЕС-1036 — это типичный мейнфрейм того времени. Занимаемая машиной ЕС-1036 площадь составляет около 100 м², потребляемая мощьность 40 кВ. Я думаю что стоила ЕС-1036 около миллиона советских рублей. По своим возможностям (память и быстродействие) персоналки уже превосходили ЕС-1036.

Все было монстроидальным, не только цены. Между прочим, персоналка IBM PC-AT 386 тогда стоила $5 тыс.

Это мое рабочее место в 1990-93году терминал ЕС-7927-01 от машины ЕС-1036.

Volodymyr S. Chornyy, Program Manager в SoftServe

З інформатикою вперше познайомився в школі в 7 класі (1997 рік). У нас був спецкурс, ми вчили ази програмування, Pascal. Викладачі з Кам’янського університету вчили нас С++. Приблизно тоді в мене вдома з’явився комп’ютер, це був Pentium II.

Згодом мене зацікавила робототехніка та слово «кібернетика». На факультет економічної кібернетики я не пройшов, але почав навчатись на комп’ютерних технологіях та інформаційних системах в Національному транспортному університеті. Першими мовами програмування були Pascal С++, далі Асемблер. Ми з другом ще займалися user support та програмним забезпеченням в обчислювальному центрі на кафедрі.

Паралельно ми почали «занурюватись» в програмування в гуртожитку, робили курсові та лабораторки за гроші. Скажімо, одна робота коштувала 150 грн, прийшло 10 людей і ми за один вечір мали вже 1500 грн. Місячна стипендія тоді ж була приблизно 300 грн.

А ще ми за одні вихідні запроектували першу мережу в гуртожитку, це був 2004 рік, а нас вже підключили до інтернету. То були 3 поверхи з десь близько 30-50комп’ютерів на кожному. Покрили тоді всіх за допомогою з’єднання «дерево».

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

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

Володимир Біловус, CEO в UKEESS Software House

Свій шлях програміста починав з FoxPro для DOS у ДРФО ДПА у Львівській області ще в далеких 90-х.Перший комерційний досвід здобув на початку 2000-хяк ColdFusion Developer.

Спробувавши себе у Desktop/Web/Database/Design розробках, свою нішу знайшов, зосередившись на непопулярному напрямку HTML/CSS/JavaScript. Занурившись з головою у дослідження тонкощів DHTML, став провідним Front-end розробником у компанії, де на той час працював. Як приклад, почав використовувати ідею Ajax підходу ще задовго до того, як цей підхід став мейнстрімовим.

Успішний розвиток одного з freelance-проектів підштовхнув до створення власної справи і вперше назва UKEESS Software House пролунала на початку 2004 року. У ті далекі часи вся краса для юзерів творилась на ще пузатеньких екранах і громіздких системних блоках. Від тепла роботи комп’ютера, до речі, можна було непогано прогріти кімнату, де я і зібрав однодумців :)

P.S. Мій перший комп’ютер був побудований на базі процесора Intel^® Pentium^® II з тактовою частотою 350 МГц.

Андрій Когут, CТO в UKEESS Software House

Вирішив, що Back-end — це моя стихія ще у студентські часи бурних 90-хроків. І, як всі молоді й талановиті розробники, почав активно програмувати вже на останніх курсах університету не просто на базі лабораторок :) Перший комерційний досвід прийшов із freelance ще в 1999 році. Проект був доволі великим, адже пов’язаний зі сферою будівництва і включав дуже громіздкі математичні обчислення для проектування будинків. Основою цієї розробки стала мова програмування Object Pascal та середовище Delphi, а стартовим залізом — комп’ютер на базі процесора Intel^® Pentium^® Pro з тактовою частотою 166 МГц. Пішло на це замовлення близько пів року недоспаних ночей (навчання в університеті на стаціонарі ніхто не скасовував). Опісля було ще багато інших комерційних проектів на Delphi та цікавих челенджів, пов’язаних із Assembler.

А на початку 2000-хпочав писати код на доброму .NET. Хоча не C#-ом і Delphi єдиними: FireBase, Fortran, Object Pascal, Java, Python, TypeScript. Тому можу похвалитись участю в розробці великих успішних інфраструктурних рішень. До речі, на старті своєї кар’єри (в 2001 році), я був одним із перших українських розробників, котрі долучились до створення першої та найбільшої того часу e-commerce платформи типу shopify.

А от так ми з Володимиром Біловусом творили історію компанії UKEESS Software House: трохи код писали, трохи й майстрували ;) Тепер — це 2 комфорті офіси в Львові і понад 70 однодумців. Ось така вона успішна історія початку двохтисячних років!

Ігор Андрейчин, Co-Founder and Head Of Technology в company42

Навчався в Національному авіаційному університеті. У 2006 році захистив дипломну роботу, що була пов’язана з ІТ. Далі розвивав власний продукт і вже в 2009 році заробив перші гроші від Google.

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

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

До 1997 года я вообще не знал о существовании компьютеров. Но в том же году из небольшого районного центра моя семья переехала в Луганск, я пошел в 9 класс физико-математического лицея и там на уроках информатики «вошел в ИТ». Наверное, это то, что называется призванием: увидев впервые компьютер, я почувствовал, как что-то во мне кликнуло. Я больше не хотел быть экономистом, а хотел работать только с компьютерами.

На уроках информатики мы учились программировать на Pascal. Это были еще те компы («Поиск −2»), куда вставляешь дискету, запускаешь с нее DOS, меняешь дискету на ту, где записан язык Pascal. До сих пор помню, как проходил процесс этого программирования: я дома писал программу на листе бумаги, приходил на урок, набирал текст и успевал запустить программу. Выводилась ошибка и звучал звонок с урока. Ошибку было важно запомнить и исправить за неделю до урока. Дома компьютера по-прежнему не было, и я думал над ней, крутил разные варианты решения просто у себя в голове. Думаю, эти обстоятельства и выработали у меня полезный скилл, которым я пользуюсь до сих пор — отлаживать программы в уме. Такими были первые программы, а высшим пилотажем было выводить картинки на монитор или делать анимацию.

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

Следующий большой шаг в программировании случился со мной еще до универа.

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

Первой моей работой в ИТ-сфере стала небольшая компания одного из преподавателей. Пилили бухгалтерскую систему наподобие 1С на языке FoxPro. У нас не было процессов, методологий, но продукт был серьезный — установлен на заводе в бюро технической инвентаризации, на разных предприятиях, им пользовались реальные люди для решения реальных проблем. Это был мой «промышленный опыт». Бывало, нам звонили из бухгалтерии предприятия с проблемой: баланс не сходится на 1 копейку. Мы выезжали «на объект», искали в бесконечных распечатках, где потерялась эта одна копейка, потом ехали смотреть расчеты нашей системы и дебажить код. Иногда это занимало полдня.

В этой же компании познакомился с ребятами, которые уже программировали на C#, они и познакомили меня с .NET. Уже в 2003 мы с друзьями писали софт для торгов на бирже — платформу forex server и forex client. Я писал сервер на C#, а друг писал Java апплет, который мы тоже вместе осваивали на практике. В 2008 меня по телефону собеседовали в Eclipse SP (сегодня Sigma Software) на проект Volvo. Здесь я вырос до Chief Software Architect.

2009 год, первая командировка в Швецию

На жаль, не у всіх ІТ-спеціалістів, що виявили бажання поділитись своїми історіями про старт кар’єри, збереглись фотографії. Але історії варті публікації!

Андрей Сыровенко, Team/Tech Lead в Daxx Kharkiv

Здравствуйте, меня зовут Андрей, мне 42, я программист...

Как я докатился до жизни такой? Ну... Это всё тлетворное влияние друзей и знакомых. А началось всё ещё в школе. Уроки информатики у нас должны были начинаться с 9 класса, но уже в 8 у меня возникло стойкое ощущение, что буквально все одноклассники уже «шарят» в компьютерах, и один я «пасу задних». Срочно нужно было что-то делать, и, по совету одноклассника, я начал учить BASIC. Сначала просто по книгам.

Свою первую программу я написал в тонкой тетрадке в клеточку, всё ещё не имея при этом доступа к компьютеру. Это была реализация популярной в своё время игры Sokoban, сценарий которой я прочитал в какой-то книге или журнале. Случилось это летом 1991 года, во время «летней практики» — в колхозе, «на кабачках». А вскоре после этого у меня появился и регулярный доступ к компьютеру — отец начал брать меня с собой в центральный офис организации, в которой работал, и куда он ездил по вторникам на совещание; там была какая-то «персоналка» (то ли AT, то ли XT, еще из тех «динозавров», у которых в ПЗУ, помимо BIOS, был прошит и интерпретатор BASIC). Именно там я за несколько вторников набрал и отладил свой Sokoban.

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

C (тогда ещё без плюсов) я тоже сначала учил по книгам, и тоже под влиянием кого-то из одноклассников, который как-то сказал, что мол «самый крутой язык программирования — это С». Позже, уже на 3 или 4 курсе университета, аналогичная история у меня произошла и с базами данных — кто-то из знакомых высказал мнение, что Oracle — это круто и перспективно... В ближайшем ларьке был куплен CD с пиратской версией Oracle 7 Server for Windows NT, и жизнь снова перестала быть скучной.

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

В 1997 году (я тогда уже учился на 4 курсе ХГТУРЭ, нынче ХНУРЭ) я уволился из школы, и устроился работать в коммерческую компанию, работавшую в сфере торговли. Выполнял типичный набор «админских» задач и разрабатывал ПО для складского учета. На Visual C++ и Oracle. Кажется, я точно не искал лёгких путей... А ещё в 1997 году у меня впервые появился доступ в Интернет. Конечно же это был Dial-Up. Нам не повезло с АТС, соединение редко работало стабильно на скоростях больше 2400 Bd, и свои первые 40 MB... сами догадайтесь чего я скачал именно на этой скорости.

А в 2003 году я наконец «вошёл в IT» — устроился C++ разработчиком в харьковский филиал компании MaxBill. Но это уже совсем другая история...

Геннадій Зарайський, Database administrator в N-iX Kyiv

Йти в ІТ я вирішив у 20 років (1989 рік), коли був в армії. Я прочитав книгу «War Games»про школяра-програміста, який рятує світ, і захотів вивчати програмування.

Після армії за рекомендацією отримав місце техніка в УКРГІДРОСПЕЦБУД, а паралельно вступив в КПІ на факультет «Інформатика та обчислювальна техніка», відділення робототехніки. Оскільки факультет був вечірній, багато я там не вивчив. Ходив туди як в клуб по інтересах.

Перша мова програмування, яку вивчив — Fortran. Адже саме з нею потрібно було працювати на комп`ютері См-1420. Машина була за розміром як декілька шаф-купе та мала 128 кілобайт пам’яті.

Чотири роки я працював в Інституті ядерних випробувань у Києві, де вивчив мову С, С++ і базу даних Іnformics. Ми писали програми, які збирали показники датчиків, встановлених на ядерних реакторах атомних електростанцій.

Після цього працював у ще декількох місцях та вивчив SQL. На початку 2000-х Delphi, з якою працював тоді, припиняли використовувати, і я вирішив сфокусуватися на роботі з базами даних. З цим працюю і сьогодні на проекті Lebara (телекомунікаційна компанія) у N-iX у Києві.

Станіслав Сисоєв, JavaScript Developer в Clockwise Software

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

У 2016 я отримав перший проект на Upwork. Продовжував працювати в Обленерго, проте хотів увійти в IT повністю :) Перші співбесіди не принесли успіху, але вказали шлях до розвитку. Платиновим квитком в IT став нетворкінг! Свою першу IT-компанію знайшов, коментуючи тред на Facebook. У 2018 за пів року інтернатури, 3 місяці стажування із ментором, я отримав комерційний проект. Тепер вже рік працюю в IT-команді, програмую на JS та розповідаю про свій кейс :)

Yaroslav Hrabar, Software Engineer в SoftServe

Я вчився в математичному класі, відповідно і з предметом інформатики я познайомився в школі. Ми дуже сильно «штудіювали» консольку MS-DOS — тобто команди операційки і різні способи їх виконання в командному рядку.

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

Вчитель інформатики водив в комп’ютерний клас педагогічного університету. То, напевне, і було перше знайомство з компом. Згодом у школі теж з’явилися перші комп’ютери, на яких ми вантажили Бейсік з 5-дюймовихдискет та грали в Комерсанта та Tower.

Насправді, першим мені пригадується саме досвід гри на комп’ютері, а не роботи на ньому. Пам’ятаю, я ходив до своєї мами на роботу в університет і «зависав» там в Heroes, Duke Nukem, Heretic на Pentium 100.

Я мріяв бути військовим — серйозно роздумував про Президентську Гвардію, поки не почав «гратися» на комп’ютері. У результаті я вступив на факультет кібернетики Рівненського економіко-гуманітарного інституту (сьогодні Міжнародний економіко-гуманітарний університет). Першою мовою програмування для мене був Turbo Pascal. Важко пригадати саме першу програму, написану, скомпільовану та запущену, але то точно був якийсь алгоритм — щось на кшталт сортування масиву методом бульбашки.

Якщо ж говорити про досвід роботи, то першою мовою для мене була мова С, а проект — OpenMotif — бібліотека для написання десктопних програм з GUI для Unix-подібних операційних систем. На той час цими Graphical User Interface могли користуватися NASA, чи метрополітен якогось із міст США.

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

Leonid Terentyev, Senior PHP developer в Scalors

У дитинстві комп’ютери в нашому домі дуже часто змінювалися. Мій батько тоді працював з великою електронною лічильною машиною, яка була розміром з кімнату. Приблизно коли мені було вісім років (1989-1990 рр.),з’явився наш перший комп’ютер ДВК (діалоговий обчислювальний комплекс), на зміну прийшов ES-1841, далі «Пошук» та ZX Spectrum. У той час всі комп’ютери підключали до телевізорів, які слугували моніторами.

Потім з’явилися процесори Intel 286, 386 та 486. У молодших класах у Миколаєві користувалися великою популярністю комп’ютерні клуби з комп’ютерами БК-001. Пам’ятаю, я приходив з розумним виглядом і говорив: «Дайте мені, будь ласка, Бейсік», — всі дивилися на мене величезними очима. Перші іграшки, які написав на Basic — це були геометричні візерунки, наприклад, «зоряне небо». Зазвичай малював, створював різну красу, але пам’ятаю, одного разу навіть написав «Змійку». Приблизно тоді я зацікавився вивченням Paskal. В основному, займався сам, інколи допомагав батько або старший брат, який той час навчався в комп’ютерній школі.

У 8-мукласі комп’ютерної школи (1994-1995 рр.)у нас з’явилися модеми, які поширювали Фідонет. З ними весь світ був доступний. Там були різні форуми з 3D-графіки, програмування, де можна було навчитися всього. Фідонет працював за такою схемою: в усьому світі були вузли, ключові станції, які працювали цілодобово або в певний час. У кожної станції були підписники, хтось відправляв повідомлення в конференцію, на вузлову станцію, а та, у свою чергу, була пов’язана з іншими станціями і передавалася модемами. Можна було спілкуватися по всьому світу, але в основному це були російськомовні країни СНД.

Андрій Кладочний, Software Engineer в SoftServe

Мене з дитинства цікавили комп’ютери. На першому курсі, коли я жив в гуртожитку, стабільного інтернету не було, але була мережа студмістечка, де студенти «шарили» між собою різноманітні файли. Там я і знайшов перші книжки з С++, які взявся вивчати.

Наступним кроком було вивчення предмету «Технології програмування», де ми почали вивчати С++ Builder. Це вже було більш схоже на щось практичне, адже без особливих зусиль можна було «зібрати» якусь програмку з більш-менш пристойним інтерфейсом. Наприкінці курсу (2011 чи 2012 рік) у нас була курсова робота, де потрібно було реалізувати «клієнт-серверний» додаток із базою даних на MySQL для відображення розкладу руху автобусів по автостанціях. Хоч це і була лише курсова робота, проте це вже було схоже на щось реальне і корисне.

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

Alexey Gurzhiy, Project Manager в Clockwise Software

Cвого часу працював інструктором у Буковелі, а там і вершини грузинськіх гір були скорені! Згодом і в Дніпровській Лавині довелось працювати!

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

Читайте також: Українське ІТ в 90-тіта на початку 2000-х:перші офіси компаній.

Привет, меня зовут Артур Селецкий. Я Co-Founder/Partner в It Network. Мы с коллегами занимаемся развитием комьюнити бизнес-аналитиков и руководителей проектов в Украине.

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

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

Техники

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

1. Stakeholder analysis.
2. User story mapping.
3. Ролевая модель и сценарии использования.
4. Прототипирование.
5. Объектно ориентированная модель.
6. Диаграмма состояний.
7. CRUD.
8. Навигация.
9. Администрирование.
10. Отчетность.
11. Нефункциональные требования.

Теперь рассмотрим каждую из техник детально и с примерами.

Stakeholder analysis

Стейкхолдеры (stakeholder) — физические лица или организации, которые оказывают влияние на проект.

Стейкхолдерами выступают:

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

Вспоминаю забавную историю, которая произошла со мной на старте карьеры. В то время я работал в банке на должности инженера ИТ-поддержки. Основной моей задачей было сопровождение АБС (автоматизированной банковской системы) Б2.

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

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

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

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

На утро следующего дня я пришел на работу к 10 часам. Подхожу к своему руководителю ИТ-отдела и докладываю: «Все сделано, вот смотри». Открываем АБС, а там... ничего нет. Все комиссии, которые рассчитала система, успешно удалены менеджерами. Подхожу к менеджерам и спрашиваю: «А почему удалили, что-то неправильно начислила система?»

Ответ меня поразил: «Нет, все верно. Вот только что мы будем делать целый день, если система сделает все за нас?»

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

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

Классифицируют стейкхолдеров по влиянию на проект и их заинтересованности.

Влияние — это степень воздействия стейкхолдера на проект (бюджет и влияние на людей).

Заинтересованность — это степень поддержки проекта или противодействия ему.

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

Матрица влияния и заинтересованности стейкхолдеров

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

Квадрант 2 (поддержка, слабое влияние) — стейкхолдеры, которые также есть союзниками проекта, но не имеют на него большого влияния.

Квадрант 3 (противодействие, слабое влияние). В этом квадранте находятся слабые противники проекта. Они противодействуют нашему проекту и при этом не имеют большого влияния на сам проект.

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

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

При выявлении стейкхолдеров я задаю следующие вопросы:

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

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

User story mapping

В XVI веке Козимо I заказал фрески для капеллы собора Сан-Лоренсо во Флоренции у Якопо де Понтормо. Понтормо более 11 лет расписывал потолок капеллы сценами из Библии: сотворение мира, Ноев ковчег, Адам и Ева, Христос... Художник работал, практически не покидая капеллу и никому не показывая результаты своего творения.

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

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

На практике в рамках этапа анализа требований я использую следующий процесс построения user story mapping:

1. Определить ключевые шаги (каждый шаг описать на отдельной карточке).
2. Расположить их в порядке использования справа налево.
3. Определить отдельные задачи, которые составляют каждую активность.
4. Расположить задачи в одной строке в логическом, последовательном порядке.
5. С помощью стейкхолдеров проверить на полноту картины активности и задачи и обновить при необходимости.

User story mapping процесса согласования отпусков

Ролевая модель и сценарии использования

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

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

1. Должностная — выделение ролей на базе должностных обязанностей.
2. Функциональная — выделение ролей на базе функциональных задач.
3. Гибридная — совмещение подходов должностной и функциональной ролевой модели.

В ходе построения должностной ролевой модели часто сталкиваюсь со следующими трудностями:

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

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

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

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

Таблица отображает пример гибридной ролевой модели и сценарии использования в разрезе ролей.

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

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

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

И вот моя первая встреча с заказчиком, руководитель проекта представляет ему меня и цели встречи — согласование требований. На что получаем много недовольства со словами: «О ужас! Еще один аналитик».

Я начал со слов: «Правильно ли я понимаю...», а задавая вопрос, сразу взялся рисовать на листе А4. Через полтора часа у нас было изрисовано порядка 20 экранных форм. Я поблагодарил заказчика и побежал в офис разрабатывать кликабельные прототипы.

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

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

Рекомендую использовать следующие инструменты:

• Axure;
• Balsamiq;
• Visio;
• карандаш и бумага;
• любой другой инструмент.

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

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

Жизненный цикл прототипа: от создания на доске до разработки дизайна

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

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

Вместо итога

В первой части мы рассмотрели 4 техники: stakeholder analysis, user story mapping, ролевая модель и сценарии использования, а также прототипирование. Мне они помогают в ежедневной и далеко не самой простой проектной роли — бизнес-аналитика.

Ожидайте вскоре следующие части по этой теме на страницах DOU.

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

SpriteKit — это нативный игровой движок от Apple, представленный впервые в iOS 7 и Mac OS 10.9. Обычно он используется для создания 2D-игр. Но это не мешает ему быть хорошим инструментом при создании анимаций, 2D-текстур и не только. Например, на WWDC 2017 Apple раскрыла, что задействовала SpriteKit в UI для Memory Debugger в Xcode.

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

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

SpriteKit очень удобен для создания несложных анимационных сцен, таких как полноэкранная анимация загрузки, иллюстрация в Onboarding- и Tutorial-экранах или в других элементах пользовательского интерфейса. Для наглядности попробуем создать анимацию загрузки, в которой будут использоваться 4 emoji: Tangerine, Lemon, Peach, Mango.

Настройка сцены

Все содержимое в SpriteKit-сцене представлено объектом SKScene. Затем ее наполнение определяется с помощью так называемых нод (node), позволяющих создавать иерархию наподобие применяемой в UIViewsили CALayers. Сцена является root-нодой в иерархии.

Для наполнения сцены используются определенные сабклассы SKNode:

• SKSpriteNodeподойдет для создания контента на базе спрайтов;
• SKLabelNode — для работы с текстовым контентом;
• SKLightNode — для управления светом на сцене;
• SKEmitterNode — для создания эффекта частиц, то есть дыма, огня, искр и других;
• SKShapeNode — для создания простых графических элементов из математических точек, линий и кривых;
• SKReferenceNode, SKAudioNode, SKCameraNode, SKVideoNode... Полный список можно посмотреть в документации.

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

Благодаря этим приемам мы сможем оживить нашу картинку и привести ее элементы в движение.

Итак, приступим!

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

func makeScene() -> SKScene {
        let minimumDimension = min(view.frame.width, view.frame.height)
        let size = CGSize(width: minimumDimension, height: minimumDimension)
        let scene = SKScene(size: size)
        scene.backgroundColor = .white
        return scene
 }

Мы презентуем SKScene через SKView (который является сабклассом от UIView), добавив определенные манипуляции по изменению размера и центрированию. Теперь можно сделать present сцены:

import UIKit
import SpriteKit
final class ViewController: UIViewController {
  private let animationView = SKView()
  override func viewDidLoad() {
    super.viewDidLoad()
    view.addSubview(animationView)
    let scene = makeScene()
    animationView.frame.size = scene.size
    animationView.presentScene(scene)
  }
  override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    animationView.center.x = view.bounds.midX
    animationView.center.y = view.bounds.midY
  }
}

Добавление нод

Имея сцену для рендеринга, можно начать добавлять контент.

Так как в текущем примере будут использоваться самые простые emoji-смайлики в качестве текстур, удобнее всего будет применить SKLabelNode (аналог UILabel в UIkit).

Итак, приступим к созданию extension для SKLabelNode, позволяющего рендерить emoji:

extension SKLabelNode {
  func renderEmoji(_ emoji: Character) {
    fontSize = 50
    text = String(emoji)
    verticalAlignmentMode = .center
    horizontalAlignmentMode = .center
  }
}

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

func addEmoji(to scene: SKScene) {
    let allEmoji: [Character] = ["🍊", "🍋", "🍑", "🥭"]
    let distance = floor(scene.size.width / CGFloat(allEmoji.count))
    
    for (index, emoji) in allEmoji.enumerated() {
      let node = SKLabelNode()
      node.renderEmoji(emoji)
      node.position.y = floor(scene.size.height / 2)
      node.position.x = distance * (CGFloat(index) + 0.5)
      scene.addChild(node)
    }
 }

Пробуем оживить анимацию

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

func animateNodes(_ nodes: [SKNode]) {
    for (index, node) in nodes.enumerated() {
      // Создаем Delay для каждой ноды в зависимости от индекса
      let delayAction = SKAction.wait(forDuration: TimeInterval(index) * 0.2)
 
      // Анимация увеличения, а затем уменьшения
      let scaleUpAction = SKAction.scale(to: 1.5, duration: 0.3)
      let scaleDownAction = SKAction.scale(to: 1, duration: 0.3)
 
      // Ожидание в 2 секунды, прежде чем повторить Action
      let waitAction = SKAction.wait(forDuration: 2)
 
      // Формируем Sequence (последовательность) для SKAction
      let scaleActionSequence = SKAction.sequence([scaleUpAction,
                             			scaleDownAction,
                            			waitAction])
 
      // Создаем Action для повторения нашей последовательности
      let repeatAction = SKAction.repeatForever(scaleActionSequence)
 
      // Комбинируем 2 SKAction: Delay и Repeat
      let actionSequence = SKAction.sequence([delayAction, repeatAction])
 
      // Запускаем итоговый SKAction
      node.run(actionSequence)
    }
 }

И хотя приведенный выше код является рабочим, он достаточно сложен для понимания, если убрать из него комментарии. Однако у нас есть прекрасная возможность легко исправить этот недостаток, используя dot notation syntax в Swift. Это поможет существенно сократить размер кода, убрав временные let-присваивания:

func animateNodes(_ nodes: [SKNode]) {
    for (index, node) in nodes.enumerated() {
      node.run(.sequence([
        .wait(forDuration: TimeInterval(index) * 0.2),
        .repeatForever(.sequence([
          .scale(to: 1.5, duration: 0.3),
          .scale(to: 1, duration: 0.3),
          .wait(forDuration: 2)
          ]))
        ]))
    }
 }

Теперь можно запустить нашу анимацию, добавив вызов написанных выше методов в makeScene().

func makeScene() -> SKScene {
    let minimumDimension = min(view.frame.width, view.frame.height)
    let size = CGSize(width: minimumDimension, height: minimumDimension)
    let scene = SKScene(size: size)
    scene.backgroundColor = .white
    addEmoji(to: scene)
    animateNodes(scene.children)
    return scene
  }

Результат:

Добавим изюминку

Получив очень наглядный и легко читаемый анимационный код, мы можем слегка развлечься и добавить немного движений. Например, заставить выполнять повороты на 360° с одновременным изменением размеров. Для этого нам просто потребуется объединить два действия по изменению размера и поворотам в одно целое:

func animateNodes(_ nodes: [SKNode]) {
    for (index, node) in nodes.enumerated() {
      node.run(.sequence([
        .wait(forDuration: TimeInterval(index) * 0.2),
        .repeatForever(.sequence([
          .group([
            .sequence([
              .scale(to: 1.5, duration: 0.3),
              .scale(to: 1, duration: 0.3)
              ]),
            .rotate(byAngle: .pi * 2, duration: 0.6)
            ]),
          .wait(forDuration: 2)
          ]))
        ]))
    }
  }

В результате получается:

Анимация текстур

Под конец покажу, как можно с помощью этих инструментов создавать полноценную живую анимацию. Для этого использую набор последовательных картинок. Каждый может взять видео-анимацию и разбить ее покадрово. Логика примерно такая же, как и при создании гифок. В моем случае анимация будет разбита на 28 кадров (изображений). Каждый кадр имеет название «warrior_walk_00XX», где XX — это число от 1 до 28. Все изображения помещаются в Assets проекта. Затем нужно собрать вместе этот массив текстур:

func animationFrames(forImageNamePrefix baseImageName: String,
                         frameCount count: Int) -> [SKTexture] {
        var array = [SKTexture]()
        for index in 1...count {
            let imageName = String(format: "%@%04d.png", baseImageName, index)
            let texture = SKTexture(imageNamed: imageName)
            array.append(texture)
        }
        return array
    }

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

func createSceneContents(for scene: SKScene) {
        let defaultNumberOfWalkFrames: Int = 28
        let characterFramesOverOneSecond: TimeInterval = 1.0 / TimeInterval(defaultNumberOfWalkFrames)
        let walkFrames = animationFrames(forImageNamePrefix: "warrior_walk_",
                                         frameCount: defaultNumberOfWalkFrames)
        let sprite = SKSpriteNode(texture: walkFrames.first)
        sprite.position = CGPoint(x: animationView.frame.midX,
                                  y: animationView.frame.midY + 60)
        scene.addChild(sprite)
.       // Анимация текстур
        let animateFramesAction: SKAction = .animate(with: walkFrames,
                                                   timePerFrame: characterFramesOverOneSecond,
                                                   resize: true,
                                                   restore: false)
        // Анимация поворота персонажа на 90 градусов
        let rotate: SKAction = .rotate(byAngle: .pi / 2, duration: 0.3)
        let newPosition: CGFloat = 100
        let moveDuration: TimeInterval = 1.0
        sprite.run(.repeatForever(
            .sequence(
                [.group([ // Движение вверх
                    animateFramesAction,
                    .moveBy(x: 0.0, y: newPosition, duration: moveDuration)]),
                 rotate,
                 .group([ // Движение влево
                    animateFramesAction,
                    .moveBy(x: -newPosition, y: 0.0, duration: moveDuration)]),
                 rotate,
                 .group([ // Движение вниз
                    animateFramesAction,
                    .moveBy(x: 0.0, y: -newPosition, duration: moveDuration)]),
                 rotate,
                 .group([// Движение вправо
                    animateFramesAction,
                    .moveBy(x: newPosition, y: 0.0, duration: moveDuration)]),
                 rotate])
            ))
    }

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

Подводя итоги

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

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

Итоговый код проекта можно посмотреть в репозитории.

При написании статьи использовался материал со Swift by Sundellи Apple.

Привіт! Я Олексій Машаров, Technical Delivery Manager, консультант компанії Infopulse. Хочу з вами поділитися деталями проекту міграції інфраструктури SAP на хмару Azure, який ми зреалізували для фармацевтичної компанії ФФ «Дарниця». Зі статті ви дізнаєтеся про переваги застосування систем на базі хмарних технологій і як з on-premise-інфраструктури змігрувати в хмару з мінімальними ризиками для підприємства. Матеріал стане в пригоді як менеджерам, які ухвалюють рішення щодо оптимізації процесів у компанії, так і технічним спеціалістам, які займаються розробкою сервісів та рішень на базі Microsoft і SAP.

Виклики для бізнесу

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

На користь рішення щодо подальшої цифрової трансформації бізнес-процесів впливали такі чинники:

• Рівень використання локальної інфраструктури системного ландшафту SAP ставав критичним через потребу підвищення її продуктивності й потужності. Це так само потребувало вартісного оновлення апаратного забезпечення.
• Підтримка традиційного апаратного забезпечення для серверів/сховищ, даних/мереж за допомогою резервування або використання високодоступних рішень була занадто дорогою, як порівняти з хмарними ресурсами.
• Потреба уникнути збільшення кількості інженерів підтримки ІТ-інфраструктури, зокрема для обслуговування апаратного забезпечення та для підтримки on-premise-ландшафту SAP.
• On-premise-рішення за наявних потреб бізнесу потребувало додаткових витрат і було недостатньо гнучким в керуванні ресурсами.

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

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

Infopulse, як сертифікований партнер Microsoft, запропонував допомогу щодо проведення міграції його SAP-системи на Azure з підвищеною гнучкістю, зменшеною сумарною вартістю утримання й витрат на зберігання, підвищеною доступністю та інноваціями.

Чому серед низки хмарних постачальників для проекту обрали Azure? SAP на Azure зараз використовує 90% компанійзі списку Fortune 500. Їй віддають перевагу через масштабованість і здатність проводити понад 5 трлн операцій зі сховищами даних щомісяця. До того ж міграція SAP на Azure уможливлює запустити віртуальні машини за хвилини й забезпечує рівень послуг щодо доступності віртуальних машин на 99,9% для всіх цих продуктів SAP. Хмарні технології Azure повністю задовольнили потреби замовника в реалізації стратегії цифрової трансформації компанії як у напрямі зростання продуктивності роботи користувачів, так і в розвитку інфраструктурних сервісів.

Рішення

З допомогою Microsoft Ukraine ми провели повномасштабну багатофазову міграцію ландшафту SAP до інфраструктури MS Azure, виконавши перехід з Oracle DB на SAP HANA. Така міграція на IT-ринку України відбулася вперше.

Рішення обрали через низку переваг:

1. Сервіс повної підтримки: Infopulse запропонував універсальний набір послуг керування, який охоплює:
   
   • Microsoft Premier Support;
   • пакетну пропозицію Professional SAP Basis;
   • хмарну підтримку в режимі 24/7/365 відповідно до умов договору про надання послуг та опцію обслуговування за викликом.
2. Відповідність вимогам: Azure — надійна платформа обробки інформації в хмарі, повністю сертифікована компанією SAP для продуктивного використання, що зазначено, зокрема, у SAP Hardware Directory.
3. Надійність і зручність: рішення втілювали на сертифікованій обчислювальній платформі SAP, що забезпечує високий рівень використання інструментів і керування безпекою, а всі дані розміщено в єдиних високошвидкісних дата-центрах.
4. Значне заощадження витрат: до 80% завдяки гнучкості MS Azure Reserved Instances у поєднанні з доданою вартістю Azure Hybrid Benefit. Для втілення цього рішення не потрібно закуповувати й обслуговувати додаткове обладнання.

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

Реалізація проекту

Проект втілювали в кілька етапів:

1. Пілот (перевірка продуктивності й можливості міграції баз даних).
2. Підготовка середовища Azure.
3. Міграція інфраструктури SAP і тестування якості.
4. Оптимізація продуктивного середовища.

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

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

Також ми замінили систему керування базами даних з Oracle DB на SAP HANA. На користь такого рішення свідчили результати тестування роботи в середовищах обох баз даних. В обраних замовником умовах у середовищі Azure продуктивність роботи додатків SAP ERP у SAP HANA була вищою. Після підготовки цільових серверів ми виконали міграцію за допомогою класичної технології гетерогенного копіювання систем SAP. Ми обрали саме цей метод, оскільки не мали часових обмежень недоступності системи.

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

Загалом під час пілотного проекту здійснили оцінку наявного системного середовища SAP, розробили пілотну архітектуру SAP у MS Azure, розгорнули середовища SAP QAS і PROD з використанням різних систем керування базами даних Oracle та SAP HANA, протестували робочі навантаження в Azure і презентували результати замовникові. Після затвердження результатів PoC із замовником ми:

• розробили архітектуру SAP ERP в інфраструктурі Azure;
• забезпечили умови для міграції з Oracle DB на SAP HANA;
• зінтегрували рішення аварійного відновлення (DR) і резервного копіювання даних.

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

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

Проектна команда складалася із 6 експертів нашої компанії (Technical Delivery Manager, SAP Architect/Consultant, Azure Architect/Consultant, Contract Manager, Account Manager and Supervisor Manager) та спеціалістів замовника. Оскільки проект вимагав чіткого дотримання послідовності етапів реалізації й дотримання строків, його зімплементували з використанням waterfall-моделі на базі MSF.

Цінність

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

• скоротилися витрати на зберігання даних і апаратне забезпечення;
• доступ отримало 300 користувачів (керівництво й відповідальні особи);
• прискорилася ініціалізація та скоротився час виходу на ринок для нових бізнес-вимог. Систему можна швидко змасштабувати залежно від навантаження. Azure дає змогу вимикати ресурси, які на певний час не потрібні. Наприклад, ресурси середовища DEV/QAS можна запустити лише під час активної роботи розробників систем. Було підвищено безпеку й рівень дотримання вимог Загального регламенту про захист даних (GDPR).

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

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

Image Source

1. Не проводить интервью с клиентами

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

Когда-то я проходил собеседование в 500 startups с одним из своих старых продуктов. Это был продукт для поиска аномального падения метрики в разрезе сегментов. Конечно же, я тщательно готовился, прописывал ответы на всевозможные вопросы и был готов сразу начать питч на пару минут. Но первый вопрос, сразу же после «Привет!», был: «Кто ваши конкуренты?» То есть меня даже не спросили, что мы делаем или как. Сразу прозвучал вопрос про рынок. А дальше мой собеседник открыл Crunchbaseи принялся изучать, что же там по инвестициям. На основании этих данных он сразу для себя решил, что рынок в зачаточном состоянии, хоть и перспективный.

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

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

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

Почему это важно? Наличие проблемы означает существование рынка. И для него может существовать много решений. Самый банальный пример: сотрудник хочет быстро поесть во время обеденного перерыва. Что тут можно предложить? Доставку на определенное время, забронить столик и оплатить еду заранее — да хоть бы сделать еду в тюбиках! В таком случае что McDonald’s, что Salateira — конкуренты, так как решают одинаковую проблему глобально. Очень часто, наслушавшись про «голубые океаны», стартапы бросаются строить продукт там, где нет рынка. Не то чтобы это было совсем неправильно. Действительно, иногда необходимо создавать рынок. Но, честно, в местных реалиях от этой идеи стоит отказаться. На то, чтобы создавать и обучать рынок и поддерживать свою жизнь, требуется немало ресурсов. Я не видел ни одного достойного примера в нашей экосистеме. Думаю, это связано с большим объемом средств, которые надо потратить, чтобы продукт мог выжить с таким подходом.

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

Тут есть несколько подходов. Основные — создание персон и Jobs-to-be-done (JTBD). Суть заключается в том, что вы пытаетесь лучше понять своего клиента, используя интервью. Различие только в том, на чем вы фокусируете внимание. В случае персон — вы точно понимаете, кто ваша целевая и как ее найти. В случае JTBD — что строить. Я, к примеру, обычно комбинирую эти варианты. Опрос состоит из трех блоков. Первый — касается персоны. В случае с В2В это могут быть вопросы про должность, размер компании, индустрию, KPI/OKR. Второй — JTBD. Тут я пытаюсь понять проблемы и различные «работы», который мой продукт может решить для пользователя. Третий блок — чисто маркетинг-вопросы. Пытаюсь узнать, какие медиа читают, на кого подписаны и все то, что в дальнейшем поможет правильно запустить кампанию.

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

Персона

1. Сколько вам лет?
2. Где вы работаете?
3. В какой индустрии работает компания?
4. Сколько лет вы на этой позиции?
5. Сколько лет вы в индустрии (пример: маркетинга)?
6. Сколько людей работает вместе с вами?
7. Какая ваша основная зона ответственности?
8. Какие цели у вашей команды и как вы их измеряете?
9. Какие у вас KPI/OKR?

JTBD

1. Важен ли емейл-маркетинг для вашей компании? Почему?
2. Сколько у вас сейчас подписчиков? Какой был рост в прошлом месяце?
3. Какой был суммарный объем базы, на которую вы делали рассылку в прошлом месяце?
4. Какую цель вы поставили для емейл-маркетинга?
5. Почему именно такая? Чем она важна?
6. В прошлый раз, когда вы отправили кампанию, на какие метрики вы смотрели? Почему?
7. Бывало ли у вас, что метрика ниже, чем вы хотели? Когда такое случилось в последний раз?
8. Что вы предприняли?
9. Какие инструменты вы использовали для решения этой проблемы? Как вы их нашли?
10. Сколько вы за них заплатили? Или сколько вы инвестировали в решение этой проблемы?
11. Какими инструментами для емейл-маркетинга вы пользовались вчера?
12. Неделю назад?
13. В этом месяце?
14. Вы платите за них? Почему?
15. Зачем вам вообще емейл-маркетинг?
16. Знаете ли вы ROI своей последней компании?
17. Как вы его измеряли?

Маркетинг

1. За кем стоит следить в вашей нише?
2. Какую профессиональную статью вы прочитали последней?
3. Как вы ее нашли?
4. Где она была?
5. Слушаете ли вы подкасты? Какие? О чем был последний эпизод?
6. Смотрите ли вы какие-нибудь обучающие видео? Если да, о чем было последнее?
7. Можете ли посоветовать хорошие комьюнити в своей нише?
8. Я бы хотел узнать об этом больше. Можете подсказать какие-то курсы? Почему эти?

2. Наши клиенты — все

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

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

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

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

Еще одна история из личного опыта с Quokka. Мне всегда хотелось построить продукт, который помогал бы небольшим стартапам делать маркетинг эффективнее. Исходя из своего желания, я определил нашу ЦА на старте как небольшие SaaS компании. Я никогда не был так далек от истины...

После проверки оказалось, что идеальная персона для нас — онлайн-ритейл с базой от 1М подписчиков и с определенным уровнем затрат на рекламу. А мои любимые SaaS-ы оказались... антиперсоной!

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

Еще один пример — Superhuman. В своей статье «Как правильно измерить product-market fit»я писал про более поздние этапы, которые следуют после запуска и получения Solution fit. Называется эта стадия Product Market fit. История Superhuman — емейл-клиента — похожа на классический гаражный подход. Продукт разрабатывался пару лет, а потом внезапно стал одной из самых быстрорастущих компаний. Как так получилось?

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

Сегмент, по определению, это группа людей, внутри которой каждый участник является друг для друга рефералом. То есть участники одной группы доверяют друг другу. Что сделал Superhuman? Они ограничили свою целевую аудиторию. Должностями, количеством входящих писем и даже одним городом. Подходящих под описание людей было, пускай, 5000. С таким подходом становится предельно понятно, где искать. Но, что еще важнее, когда вы вручную, пусть даже через cold outreach, получите из этой группы 250 участников, сколько часов уйдет на то, чтобы вся группа узнала о вашем продукте? Чертовски мало.

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

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

3. Разговаривать фичами

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

• закрывай сделки быстрее;
• вовлекай клиентов;
• помогай своим клиентам.

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

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

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

Такая ситуация очень часто встречается с В2С продуктами, и к этому надо быть готовым. Но ответьте себе честно: кто все-таки ваша целевая аудитория? Ситуация с Ahrefs, по большей части, исключение из правил. И если у вас есть всего 2-4персоны и 2-4сценария — рассказывайте про ценности, а не про фичи.

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

Идея-то в том, чтобы помочь нашему клиенту решить эту проблему. С нами, без нас, с конкурентами — все равно. Если мы это сделаем и подскажем правильные шаги, они все равно останутся (и остаются) с нами. На каждую фичу, которую вы построили, спросите себя: «Зачем?». Когда мне сложно ответить на этот вопрос, я подхожу с другой стороны: «Что поменяется у клиента, после того как он будет это использовать 1-3-12 месяцев?». Вот в этом ответе и заключается ценность.

4. Не общаться с пользователями и не слать емейлы

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

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

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

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

• Почему он решил зарегистрироваться?
• Почему он не сделал действие Х во время триала?
• Почему он его сделал?
• Почему он заплатил?
• Почему он не заплатил?

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

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

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

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

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

5. Ждать, что все само пойдет

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

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

Вспомните про Uber: какие там есть решения, основанные на рефералке в том или ином виде? Отправить промокод, поделиться маршрутом, пошерить поездку (uber pool). И это еще не все, что подталкивает пользователей отправлять ссылку на Uber своим друзьям. Действительно, продукты, построенные таким образом, демонстрируют рост лучше, чем их конкуренты. Но это все работает в масштабе. Сначала все равно стоит вопрос трафика.

Не самый идеальный, но все равно рабочий вариант выглядит вот так:

• показываете продукт друзьям и друзьям друзей;
• запускаетесь на Product Hunt, Hacker News;
• отвечаете на тематические вопросы на Quora;
• запускаетесь на платформе типа SaaS Mantra;
• доделываете все что надо и запускаетесь на AppSumo.

В результате все это даст примерно $100k прибыли, которую вы сможете потратить на настройку уже нормальной рекламной кампании в масштабируемых каналах.

6. Не масштабироваться

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

Грубо говоря, работа с рекламой состоит из трех этапов:

• тестируем;
• оптимизируем;
• растем.

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

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

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

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

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

Выводы

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

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

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

Сами по себе даже котики не рождаются, что уж говорить про «единорогов». Придется вливать в маркетинг, а лучше после A раунда вливать туда больше, чем в разработку. Иначе вы не сможете масштабироваться, а мечты про свой небоскреб, как у Salesforce, в Сан-Франциско, разрушатся о компанию, которая стала просто «семейным бизнесом». Но никак не историей на $1B.

Масштабируйтесь. Или хотя бы пробуйте.