Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Портал №1 по управлению цифровыми
и информационными технологиями
И опять из навеянного недавними встречами и обсуждениями с Заказчиками. Вообще назначение процесса управления релизами и его организация вызывают массу вопросов:
Часть из этих вопросов уже поднималась в предыдущих обсуждениях на этом сайте.
Стремясь привести свои давние мысли на этот счёт в порядок, я решил освежить свои знания первоисточников, коих использовал три: ITIL, BMC Service Management Process Model (SMPM), IBM Tivoli Unified Process (ITUP). Свои выводы (наверняка для многих весьма спорные) решил обнародовать.
И так, несмотря на то, что в разных источниках используется одно и то же название «Release management», речь на самом деле идёт о разных процессах (что и вызывает путаницу). Разных не только по способу организации, а по назначению, по месту в процессной модели. Для того чтобы лучше с этим разобраться, возьмём произвольную ИТ-организацию и выделим в ней два подразделения: одно будет отвечать за эксплуатацию информационных систем, другое – за разработку и сопровождение (границы между эксплуатацией и сопровождением берём согласно ISO 12207 «Software Life Cycle Processes»). Так вот в такой ИТ-организации возможны два разных взгляда на управление релизами.
Первый: управление релизами осуществляется в рамках подразделения разработки / сопровождения.
В этом случае на вход процесса попадают требования к изменению ИС (неважно, в виде запроса на изменение или просто в виде служебки с функциональными требованиями), на выходе будет релиз, которые эти требования реализует. Содержание процесса:
Далее релиз передаётся в подразделение эксплуатации (то есть выполняется приёмка релиза), где в рамках управления изменениями внедряется в продуктив. Похоже, именно о таком процессе написано в SMPM. Вот характерные признаки такого процесса:
То есть управление релизами подразделения разработки и сопровождения стыкуется с управлением изменениями подразделения эксплуатации (хотя может быть корректнее здесь говорить об общем — сквозном — управлении изменениями). Значит есть основание для выделения управления релизами в отдельный процесс.
Второй: управление релизами осуществляется в рамках подразделения эксплуатации.
В этом случае получаем привычный Release management, который отвечает за объединение нескольких изменений в релиз и организует безопасное и контролируемое внедрение. Содержание процесса (каноническое, жизнь потребует корректив):
Именно о таком процессе написано в ITIL и в ITUP. Вот характерные признаки такого процесса:
То есть управление релизами отвечает за определённый этап общей деятельности по управлению изменениями, выполняемой подразделением эксплуатации. Именно поэтому управление релизами может быть реализовано не в виде отдельного процесса, а как часть процесса управления изменениями.
Что называется, почувствуйте разницу. Если в беседе вы зафиксируете тему не просто в виде «Release management», а договоритесь, о каком именно управлении релизами идёт речь, вы сможете избежать непонимания и обоснованно ответить на заявленные вопросы в начале поста.
Релиз-менеджер Zeptolab Илья Коротков о жизненном пути, устройстве в компанию и личных впечатлениях
Релиз менеджер Zeptolab Илья Коротков написал колонку о своём жизненном пути и попадании в мобильную компанию. Он рассказал о переезде в Москву, раскрыл детали собеседования и поделился первыми впечатлениями.
Мой путь в игровую индустрию начался еще в пятилетнем возрасте из привокзального игрового салона города Чимкент, куда меня привел брат. Там я впервые увидел игру для Спектрума River raid («Полёт над рекой») и уже тогда приблизительно понял, чем хочу заниматься, когда вырасту. Даже окончание гуманитарного ВУЗа по специальности юриспруденция не стало препятствием.
В игровую индустрию меня окончательно затащил друг, с которым я познакомился в студенчестве. Он, как и я, увлекался играми с самого раннего детства и знал о них почти все. Чуть позже мы организовали довольно успешное общее дело по розничной продаже опять-таки игр и прочей мультимедийной продукции, но из-за стремительного развития в городе быстрого интернета и цифровой дистрибуции прибыльность нашего маленького предприятия пошла на спад, и мы приняли решение это дело закрыть.
Друг ушел в отельный бизнес, я устроился в ипотечное агентство. Но спустя полтора года, благодаря своему жизненному упорству и будущей жене, друг устроился продюсером в наше сибирское игровое издательство «Алавар», после чего сделал максимум, чтобы туда взяли и меня.
Этот трудовой опыт был со всех сторон замечательный: отличный коллектив, полное отсутствие свойственных отечественным организациям корпоративных болезней и свежее понимание давно известной мне сферы, про которую раньше только читал в интернете. Я начинал с позиции тестировщика в отделе контроля качества. Через полгода мне предложили стать QA Lead нового отдела, а еще через полтора года я взял на себя функцию менеджера по продукту в отделе free-to-play. Но спустя некоторое время понял, что для меня в этом качестве скоро почти не останется интересных задач, и мы расстались по обоюдному согласию с моим непосредственным руководителем.
Долго без работы я не просидел. Мой бывший коллега, с которым мы работали в «Алавар», предложил место в его новой студии GameOn Production. Там я за пять месяцев успел поработать в роли менеджера продукта и сценариста в одном лице над двумя небольшими проектами, которые неплохо себя показали в месенджере Телеграм. В студии меня поражала скорость и качество разработки, несмотря на немногочисленную команду из семи человек. Тратить на создание полноценного проекта таким составом от двух до шести месяцев было выше моего понимания, пока я сам в этом не поварился.
Я бы, наверное, и дальше продолжал работать в GameOn, если бы совершенно неожиданно не позвонила Дарья Карякина из агентства Spice IT и не предложила пройти собеседование в Zeptolab. Согласился без особых колебаний, ведь не каждый день выпадает возможность трудоустроиться к одному из основателей мобильного игрового рынка.
На протяжении всего цикла собеседований Дарья ненавязчиво контролировала наши коммуникации, постоянно интересовалась, как прошел тот или иной этап, и после трех Skype-сессий (с HR-специалистом, моим будущим руководителем и одним из основателей компании), которые заняли не больше трех дней, я получил предложение с довольно интересными условиями на должность релиз-менеджера.
Сами собеседования длились не больше получаса. Первый разговор был с HR-специалистом. Девушка пробежалась по резюме, уточнила про пробелы между трудоустройствами, про мои технические навыки, а потом дала быстрый тест на знание языка. Скинула небольшой текст на русском и попросила тут же перевести его на английский. Я потратил пять минут и вернул результат, не прерывая звонка. Ответ её удовлетворил, после чего она спросила про мои ожидания. Я озвучил, как мне показалось, довольно наглые условия моего трудоустройства, но она, не изменившись в лице, просто сделала себе пометку без особых возражений.
Потом девушка спросила, есть ли у меня еще полчаса, т.к. была возможность сразу пообщаться с руководителем отдела, в который меня собеседуют. Я согласился. Через 10 минут меня набрал мой непосредственный руководитель Пётр. Вопросы от него поступали четкие и по делу: какие основные умения, сколько проектов запустил, сообщил, что позиции придется это делать еженедельно. Также поинтересовался техническим бэкграундом, я честно признался, что в плане программирования не так подкован, как хотелось бы, а он мне также честно сказал, что график у меня будет очень гибкий, но не на регулярной основе, только в период запуска важных проектов, которые находятся в производстве не один месяц.
Меня как человека, работающего в IT больше трех лет, таким было не напугать.
Хотели в этот же день поговорить с одним из основателей компании, но он был очень занят. Перенесли на следующий. Но даже собеседование с ним длилось около двадцати минут и больше было похоже на официальное знакомство, чем на тест. На удивление обошлось без вот этого клишированного, бесящего любого соискателя «Кем вы видите себя через пять лет?». Вместо него было конкретное условие: «Нам нужен сотрудник минимум на два года. Мы можем на тебя рассчитывать?». Вот тут я взял паузу подумать, и ребята из Zeptolab тоже. Но на следующий день меня снова набрала уже знакомая мне HR-специалист и спросила, точно ли я готов к такой работе и переезду, потому что я вполне соответствую их ожиданиям. И после этого вопроса я понял, что думать тут нечего. Ехать надо.
Выйти на работу попросили в течение двух недель, к чему я оказался не готов, так как хотел сначала съездить в отпуск в горы. Будущие коллеги отнеслись к этому с пониманием и попросили мои паспортные данные для покупки билета на самолёт и оформления номера в отеле в центре Москвы, пока я не сниму свое жильё. Это было приятной неожиданностью. Такой релокационный бонус — большая редкость. Переезд мне почти ничего не стоил.
Мне и раньше поступало несколько предложений перебраться на работу в столицу, но я не спешил покидать свой родной город. Не отпускала личная жизнь и ощущение дома, поэтому я такие предложения несколько раз отклонял и старался с переменным успехом налаживать дела в Сибири. Но на момент звонка из Spice IT начало приходить понимание, что меня уже ничего здесь не держит, и я принялся собирать вещи.
Семья моим переездом была очень довольна, потому что часть родных живет в Краснодарском крае, а другая в Подмосковье. Так что теперь могу видеться с ними чаще. Друзья из Сибири тоже были рады. Большая часть из них ведь уже давно живет в Москве, другие сибиряки тоже собираются перебираться.
Моя нынешняя должность подразумевает работу со всеми вышедшими и только готовящимися к выходу проектами, а также получение необъятной экспертизы во всём, что касается запуска проектов и текущего производственного процесса.
Про то, что обязанностей у меня будет много, я был в курсе еще до приезда. Никто от меня ничего особо не скрывал. Первое время приходилось непросто из-за огромного объема информации, состоящего из сотен мелких деталей. Мне постоянно приходилось активировать все свои внутренние ресурсы, напрягать внимание и концентрироваться на нескольких задачах одновременно. Таск-менеджер и бумажный ежедневник стали моими лучшими друзьями. Но без понимания и помощи коллег меня бы эти вещи не спасли. Поэтому на испытательном сроке я себя комфортно ощущал в первую очередь, потому что меня активно поддерживали коллеги.
В общем, в новом коллективе уже спустя неделю я почувствовал себя так, как будто работаю с этими людьми не меньше года.
Это как раз та команда, в которой можно подойти к любому сотруднику (в том числе и к одному из основателей компании) и на любой, даже самый идиотский вопрос, получить терпеливый и подробный ответ. Более того, с новыми коллегами оказалось не только интересно работать, но и отдыхать во в нерабочее время, а это тоже дорогого стоит. Здесь работают очень разносторонние люди, у каждого из которых десятки необычных хобби и богатый жизненный опыт.
На данный момент я уже освоил почти все процессы. Скорость выполнения задач существенно выросла, ну, и с каждой неделей у меня остается всё меньше вопросов, которые я постоянно задавал коллегам в первые месяцы работы. За это время я помог компании выпустить несколько десятков обновлений и одно новое приложение Om Nom Toons, контент которого полностью состоит из мультиков о дико популярном персонаже большинства игр Zeptolab — зелёном монстрике Ом Номе. Приложение получилось очень удачным и сейчас довольно быстро набирает десятки тысяч установок во множестве стран. Производственная, продуктовая и маркетинговая команды явно знали, что и для кого они делают.
Что касается атмосферы и рабочего комфорта, здесь всё просто идеально. Уютное помещение в корпоративных цветах компании занимает целый этаж бизнес-центра. Кабинеты, оборудованные новинками удалённой коммуникации, игровые комнаты, заваленные самыми последними гаджетами, коферумы с никогда не пустеющими холодильниками. Любая просьба по организации рабочего места удовлетворяется в этот же день. Так что в этом плане реальность превзошла мои ожидания.
В целом, я очень доволен тем, как поменялась моя жизнь. Сейчас я живу в том же районе, в котором расположен офис Zeptolab. Стоит заметить, что это очень приятное место, которое одновременно напоминает центр моего родного города и его отдаленные районы, такие как посёлок учёных Академгородок. Добираюсь до работы максимум за пять минут быстрым шагом, а до исторического центра Москвы за полчаса, включая дорогу до метро. Проживание и работа в этом районе позволили оценить все достоинства летнего сезона в столице. Уверен, что осенью здесь будет не менее красиво.
Про родной город вспоминаю очень часто. Там у меня прошла большая часть жизни. Но пока есть интересная работа в Москве и чётко обозримые перспективы развития, смысла возвращаться туда не вижу. Хотя, в некотором будущем не исключаю такой возможности. Только не с пустыми руками и головой, а с существенными ресурсами и конкретной идеей, которая позволит не только мне жить с комфортом, но и будет востребована среди горожан и местного бизнеса, позволит участвовать в развитии города. Это был бы идеальный вариант.
Пока же в планах на ближайшие несколько лет продолжать работать в игровой индустрии, повышать уровень экспертизы, учиться взаимодействовать с внешними партнёрами и постигать тонкости производства качественного продукта. Моё нынешнее место работы для этого подходит как нельзя лучше.
Разнорабочий под красивым названием Релиз менеджер
Всем привет. Мой первый пост. Давно было желание излить душу и вот свершилось.
Так случилось, что будучи ранее в разных стезях процесса разработки и как консультант, и как разработчик, и как руководитель, и «всех_вопросов_решитель», сейчас на принудительно добровольной основе занимаю должность релиз менеджера. И хочу сказать, создаётся впечатление, что никто не знает, чем я занимаюсь. Даже я.
Доступ ставить обновления в рабочую среду есть только у меня (не считая начальников).
Вот и всё отличие от служб поддержки и разработки.
Ах нет, ещё у меня есть уникальный рабочий инструмент, который выглядит так:
А история моя короткая о том, как я с радостью в душе работу на дом приношу.
Сейчас идёт внедрение одного масштабного и многообещающего проекта, сделанного, простите, из говна и палок. И вот те на, как он пошёл в промышленную эксплуатацию, все разработчики тактично испарились в отпуска.
Толи рыцарство взыграло, толи ЧСВ затрепетало, но бросить этого новичка с растерянными глазами в беде мне не позволила совесть.
И вот я два дня отчаянно ношусь по кабинетам, добывая информацию как это должно работать, разбираю проблемы, организую удалённые подключения, консультирую пользователей, договариваюсь об алгоритмах решения, выдаю руководителям проекта указания, новичку тех задания на словах, тестирую вместе с ним, устанавливаю.
И с чувством искренней радости в пятницу праздную пройденные важные итерации функционала, пронесённые на заботливых руках меня и новичка. Мы словно Моисеи, разведшие воды Красного моря для спасающихся евреев. Евреи ликуют и величают нас славными чародеями.
Я удаляюсь в тень. Занавес.
А в понедельник релиз.
И 20 обновлений в него ещё не готово.
Сижу делаю дома, яжрыцарь.
какое-то отчаянное геройство, никому не нужное. У проекта проблемы, а вы в одиночку пытаетесь тащить, по описанию
Сперва увидев картинку с кодом я подумал что ТС несчастный 1c программист.
Свойство эффектов зоны? Серьезно? Ты же перед этим Area of effect перевел как область действия, может «свойства области действия» было бы более логичным?
Технический долг
Увольнение каждые два года.
Записки модели: «профессиональные травмы»
Да какие у моделей могут быть профессиональные травмы? Я вас умоляю, пришла, тебя накрасили, тебя одели, ты чуть чуть покривлялась на камеру и едешь себе на свои маникюры и спа!
По крайней мере именно так большинство людей видят нас. Но я вам хочу показать чуть больше, чем вы видите в Инстаграмме)
Надеюсь в комментариях знающие люди прольют свет на это магическое недоразумение о коленях
Иногда случается, что какая-то зараза передаются через кисти макияжа. С такими визажистами стараемся не работать, но почти у каждой модели хоть раз за всю карьеру, да был Опыт болячки на глазах или коже лица.
5) Съёмочные травмы. Как ни прискорбно, до сих пор нет хорошей ТБ при съёмках. Потому что они (съёмки) всегда разные. Для лучшего представления запишу все, что приходит в голову за последний год:
— ассистент защемляет молнией одежды кожу. Ассистенты меняются, как перчатки, поэтому так часто косячат новенькие. Они ещё не умеют делать все аккуратно в условиях нашей бешеной спешки. Самое частое
— во время переодевания минимум раз в день кто-то заедет в чье-то лицо. Опять же из-за спешки
— про солнечные, тепловые удары летом, и застужение почек зимой на холодном полу я уже писала
— одна модель плюс-сайз в этом году сломала ногу из-за несоблюдения ныне несуществующей техники безопасности.
— однажды с потолка свалилась плохо закреплённая крышка от кондиционера мне прямо на голову. Самое забавное, что даже где-то было видео, но я его уже не найду
— часто туфли под отдельный образ не совсем по размеру, поэтому при позировании регулярно теряешь равновесие и падаешь, либо наступаешь на свою же ногу. Всегда обидно за такие ситуации и мизинчик на ноге
— синяки. На съёмке очень много всего и очень тесно. Неопознанные новые объекты появляются в самых неподходящих местах
— накладные ресницы, линзы и прочие экзекуторы глаз. Если с линзами я работаю редко, то накладные ресницы не часто приклеят удобно. Красиво, но дискомфортно с ними работать. Хочется оторвать их и потереть глаза украдкой.
7) стресс. Плохое или нерегулярное питание, постоянные недосыпы, постоянные поездки, постоянная пререработка очень плохо сказываются на здоровье физическом и психологическом. Каждый божий день надо быстро быстро быстро и пытаться сделать качественно. Иногда просто хочется взять и убежать от всех жить в лес. Иммунитет всегда трещит по швам и из последних сил поборется со всякими невзгодами)
Для большего понимания этого поста прошу учесть, что я фото модель каталогов, и работаю только в одном месте и одной стране и поделилась с вами своим субъективным опытом, который может сильно отличаться от моделинга в других странах, где нет наших китайский скоростей и требований.
Также прикрепляю коллажи со своих работ за 3й квартал 2020 для большего понимания о том, в чем же состоит моя работа. Моя работа делать продающие фотографии для брэндов и фабрик e-commerce бизнеса, типо вот таких что ниже. Может пригодиться девушкам, которые начинают учиться позированию, или тем, кто стесняется фотографироваться, потому что не знает как. Ну а остальным поможет понять, что же за профессия такая: «модель каталогов»