Русский
Русский
English
Статистика
Реклама

Управление проектом

Сколько стоит сделать ролик об игре своими силами

29.06.2020 16:21:22 | Автор: admin


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

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

Написано в Alconost

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

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

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

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

  • Ролик: допустим, вам нужен ролик-трейлер, длительностью не больше минуты, для размещения на сайте игры и в Google Play. Пусть ролик будет на английском, с озвучкой диктором-носителем английского языка, с музыкой и звуковыми эффектами.
  • Команда: предположим, что в команде есть ребята, у которых достаточно знаний, навыков и квалификации, чтобы написать сценарий, создать графику для ролика и анимировать её, а также сделать звуковое оформление видео. Также предположим, что в команде полное взаимопонимание, и каждый в команде может выделять на эту задачу половину рабочего дня без ущерба прочим обязанностям.
  • Процесс: возможно, вы решите следовать процессу создания роликов в Alconost: написать сценарий, сделать раскадровку, записать озвучку, подобрать фоновый трек, собрать анимацию, смонтировать музыку, добавить звуковые эффекты. Не исключено, что в вашем случае процесс нужно подтюнинговать, но как именно можно судить, только зная особенности конкретной игры и конкретной команды. Раз сама ситуация, ролик и команда у нас условные, пусть хотя бы процесс будет конкретный и универсальный.

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


Фото: StartupStockPhotos, Pixabay

Сценарий


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

Чтобы художник, аниматор и диктор точно поняли, что им нужно делать, сценарий должен отвечать на такие вопросы:

  • В каком визуальном контексте будет происходить всё действие? Это простой градиент, плоский детализированный арт или 3D-окружение? С этим нужно разобраться в самом начале, чтобы все решения по визуальной части были консистентными. Добавляйте в сценарий референсы.
  • В каком порядке в ролике будут показаны главные фичи игры и каким именно образом? Если некоторые фичи выглядят недостаточно фотогенично (мешают кнопки, много текста, мелкие иконки), в сценарии нужно предусмотреть, как именно такие фичи будут демонстрироваться.
  • Каким будет закадровый текст? Диктор озвучивает предоставленные ему фразы, не внося корректировок на свой вкус, так что сценаристу нужно убедиться, что текст озвучки ёмкий, точный и складный.


Фото: Free-Photos, Pixabay

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

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

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

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

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

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

Раскадровка


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


Фото: VitalikRadko, Depositphotos

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

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

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

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

Анимация


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


Фото: sonerbakir, Depositphotos

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

Предположим, что анимация графики займет 30 часов, а работа с захватами 10. Допустим, полная черновая сборка в целом понравится команде, но без улучшений не обойтись. Пропустим черновик анимации через три цикла правок (пусть они займут 4, 3 и 2 часа: чем ближе к финальной версии, тем меньше корректировок) и дадим аниматору ещё часок на шлифовку финальной версии. При таком ходе работ трудозатраты аниматора составят 50 часов.

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

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

Звукорежиссура


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

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

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


Фото: princeoflove, Depositphotos

Будем считать, что на монтаж музыки, подбор звуковых эффектов и сведение у звукорежиссёра уйдет около 4 часов, и ещё час понадобится на внесение правок после согласования с командой (бдыщь не подошел надо буммм, и тому подобное). Итого 5 часов.

Остаётся только попросить аниматора свести финальное видео с финальной аудиодорожкой и ролик готов.

Менеджмент


Менеджер делает всё, чтобы процесс работы над роликом шёл продуктивно и был команде в кайф. Иначе зачем это всё?

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


Фото: ilixe48, Depositphotos

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

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

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

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

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

Суммируем время


Давайте подсчитаем, сколько приблизительно времени ушло на создание ролика в нашем случае.

  • Сценарий: 10 ч.
  • Раскадровка 20 ч.
  • Анимация: 50 ч.
  • Звукорежиссура: 5 ч.
  • Менеджмент: 30 ч.

Итого: 115 часов.

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

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

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

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

Переводим в деньги


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

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

Для этого воспользуемся исследованием компании InGame Job, которая в 2019 году опросила 2000 сотрудников геймдев-компаний из России, Беларуси и Украины и высчитала медианную зарплату специалистов на разных должностях.

Роли, которые сотрудники геймдев-студии исполняют в нашем условном проекте, мы соотнесём с должностями, упомянутыми в исследовании. Чтобы выяснить, сколько стоит один час работы каждого специалиста, разделим медианное значение зарплаты за месяц на 21 рабочий день, а полученное число разделим на количество часов в рабочем дне 8.
Роль в проекте / Должность в списке InGame Job Медианная зарплата, $ Стоимость 1 рабочего часа, $ Затрачено времени на ролик, ч. Стоимость часов, затраченных на ролик, $
Копирайтер / Narration Designer 1100 6,5 10 65
Художник / 2D Artist 950 5,6 20 113
Аниматор / Animator 1420 8,5 50 423
Звукорежисcёр / Sound Engineer 1200 7,1 5 36
Менеджер проекта / Project Manager 1800 10,7 30 321
Итого 958

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

Но есть кое-что ещё, что поддается относительно точной калькуляции, а мы это пока не отразили в расчётах.

Прочие расходы



Фото: Arek Socha, Pixabay

  1. Перевод: $20. Столько стоит перевод 1000 знаков с русского на английский в исполнении английского носителя языка в сервисе профессиональных переводов Nitro. 1000 знаков это как раз 120 слов озвучки (идеально для минутного видео) и 8 коротких слоганов.
  2. Дикторская озвучка: $100. Цены на озвучку зависят и от объема текста, и от конкретного исполнителя и его условий, в том числе от минимальной стоимости заказа. Предположим, что мы выбрали опытного диктора из США, который записывается в профессиональной студии и в списке услуг которого есть как раз то, что нам нужно: озвучка роликов для Интернета, длительность до 1 минуты за фиксированную ставку.
  3. Стоковый трек: $30. Бывают треки и по $15, и по $50, а ещё цена в разы увеличивается, если нужна лицензия расширенного типа например для использования в ролике, который будет размещаться на ТВ. Допустим, мы выбрали не самый дорогой трек по стандартной лицензии, которая как раз подходит для публикации ролика на Youtube.

Прибавим эти затраты ($150) к ранее вычисленной сумме. $960+150 = $1110.

Выводы


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

Заказать ролик на аутсорсе или всё же сделать самостоятельно? Каждая геймдев-команда решает на своё усмотрение.

Если вы решите аутсорсить видео посмотрите, какие ролики об играх делают в Alconost.

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

Об авторе


Статья написана в Alconost. Мы уже 8 лет создаём рекламные и обучающие видео, в том числе трейлеры, тизеры и прероллы для игр и приложений. А ещё мы занимаемся локализацией приложений, игр и сервисов на 80+ языков.

Подробнее: alconost.com. Подпишитесь на нас ВКонтакте, Фейсбуке или Твиттере, чтобы первыми увидеть наши свежие работы и анонсы новых публикаций.

Другие наши статьи о создании видеороликов


Подробнее..

Перевод Как мы боролись с техдолгом, или от 15 000 подключений к базе данных до менее чем 100

28.01.2021 14:21:54 | Автор: admin
Недавно новый сотрудник спросил меня за обедом: Какой у нас техдолг?

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

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

Глядя на нового сотрудника, я глубоко вздохнул и начал: Давай я расскажу о том, как у нас было 15 000 прямых подключений к БД

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



Как всё начиналось


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

Как и GitHub, Shopify и Airbnb, DigitalOcean начиналась как приложение Rails в 2011 году. Внутри компании приложение называли Cloud, оно управляло всеми взаимодействиями с пользователем как в интерфейсе пользователя, так и в общедоступном API. Сервису Rails помогали два сервиса Perl: Scheduler и DOBE (DigitalOcean BackEnd). Планировщик планировал и назначал дроплеты гипервизорам, а DOBE отвечал за создание реальных виртуальных машин дроплетов. В то время как Cloud и Scheduler работали как автономные службы, DOBE работал на каждом сервере парка машин.

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

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


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

Четыре года очередь сообщений базы данных составляла основу технологического стека DigitalOcean. В это время мы приняли архитектуру микросервисов, для внутреннего трафика заменили HTTPS на gRPC, вместо Perl внутренние сервисы стали писать на Golang. Однако все дороги по-прежнему вели к той самой базе данных MySQL.

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

С 2012 по 2016 год пользовательский трафик DigitalOcean вырос более чем на 10 000 %. Мы добавили больше продуктов в наш каталог и больше сервисов в нашу инфраструктуру. Событий в очереди базы данных стало больше. Повышенный спрос на дроплеты означал, что Scheduler, чтобы назначить их все серверам, работал с превышением штатной нагрузки. И, к сожалению для Scheduler, количество доступных серверов не было постоянным.


Чтобы не отставать от растущего спроса на дроплеты, мы добавляли всё больше и больше серверов для обработки трафика. Каждый новый гипервизор означал еще одно постоянное соединение с базой данных. К началу 2016 года у базы было более 15 000 прямых подключений, и каждое запрашивало новые события через одну-пять секунд. Если и этого было недостаточно, то SQL-запрос, который каждый гипервизор использовал для получения новых событий дроплет, также стал сложнее. Он превратился в колосс из более чем 150 строк и JOIN в 18 таблиц. Этот код впечатлял настолько же, сколько рискованно и трудно было его поддерживать.

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

Из-за тесной связи в системе не было чёткого или простого решения проблемы. Cloud, Schedule и DOBE оказались узкими местами. Патчи только одного или двух компонентов сместили бы нагрузку на оставшиеся узкие места. Поэтому после долгих раздумий инженеры разработали план исправления из трёх пунктов:

  1. Уменьшить количество прямых подключений к базе данных.
  2. Переписать алгоритм ранжирования Scheduler, чтобы повысить доступность этого сервиса.
  3. Освободить БД от ответственности за очередь сообщений.

Переписываем код: начало


Чтобы справиться с зависимостями базы данных, инженеры DigitalOcean создали Event Router. Маршрутизатор событий служил региональным прокси-сервером, который опрашивал базу данных от имени каждого экземпляра DOBE в каждом центре обработки данных. Вместо тысяч серверов, каждый из которых запрашивает базу данных, осталась только горстка выполняющих запрос прокси. Каждый прокси-сервер маршрутизатора событий будет извлекать все активные события в определённом регионе и делегировать каждое событие соответствующему гипервизору. Event Router также разбил гигантский опрашивающий запрос на запросы, которые проще поддерживать.


Когда Event Router был запущен, он сократил количество подключений к базе данных с более чем 15 000 до менее 100.

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

Хотя это звучит достаточно просто, Scheduler имел несколько недостатков. Его логика была сложной, работать с ней было непросто. Он был однопоточным, и его производительность снижалась во время пиковой нагрузки. Наконец, был только один экземпляр Scheduler и он должен был обслуживать весь парк. Это узкое место было неизбежным. Чтобы решить эти проблемы, команда инженеров разработала Scheduler V2.

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

Event Router и Scheduler v2 были большими достижениями, они устраняли многие недостатки архитектуры. Но даже с ними имела место большая препона [прим. перев. это несколько удивительно, но слово препона женского рода]. К началу 2017 года централизованная очередь сообщений MySQL всё ещё использовалась. Она обрабатывала до 400 000 новых записей в день и обновлялась 20 раз в секунду.

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

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



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

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

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

Первой задачей Harpoon было взять на себя обязанности по очереди сообщений из базы данных. Для этого Harpoon создал собственную внутреннюю очередь сообщений, состоящую из RabbitMQ и асинхронных воркеров. Пока Harpoon отправлял новые события в очередь с одной стороны, воркеры забирали их с другой стороны. А поскольку RabbitMQ заменил очередь базы данных, воркеры могли напрямую общаться с планировщиком и маршрутизатором событий. Таким образом, вместо того чтобы Scheduler V2 и Event Router опрашивали базу данных на предмет изменений, Harpoon отправлял обновления к ним напрямую. На момент написания этой статьи, в 2019 году, архитектура событий дроплет всё ещё работает.


Прогресс DigitalOcean


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



Подробнее..

Перевод Enterprise COBOL пример проекта

02.02.2021 22:08:40 | Автор: admin

Эта статья завершает Курс программирования на COBOL, освещая важные аспекты разработки программного обеспечения, такие как модульность кодовой базы, зависимости, модульное тестирование, мокинг, DevOps на z/OS и автодокументация. Современный подход представлен здесь наилучшим образом на примере.

Photo by Hunter Haley onUnsplashPhoto by Hunter Haley onUnsplash

TLDR

Скачайте архив с GitHub, разархивируйте от откройте папку sales.

Предварительные условия

Предполагается, что вы уже знакомы с основными принципами, методами и стандартами IBM Enterprise COBOL для z/OS проприетарного компилятора COBOL, который реализует значительную часть стандартов COBOL 85, COBOL 2002 и COBOL 2014. Мы будем запускать проект на z/OS проприетарной 64-разрядной операционной системе для мэйнфреймов IBM, которая вышла в октябре 2000 года и все еще обратно совместима с функциями, появившимися с 1960-х годов.

  • Убедитесь, что у вас установлен NPM, менеджер пакетов для JavaScript:

$ npm -v
  • У вас есть аккаунт мэйнфрейма IBM.

Вы можете получить аккаунт в учебных целях бесплатно. Зарегистрируйтесь в IBM и следуйте инструкциям. Вы получите емейл с указанным USER ID, IP и PORT. Затем войдите в Open Mainframe Project Slack и добавьте приложение zih через Apps меню. Отправьте приложению сообщение, например, Hi, и бот попросит ввести емейл и USER ID, которые вы получили. Отправьте эти данные, и бот создаст ваш PASSWORD.

  • Вам понадобится COBOLget, менеджер пакетов для COBOL:

$ npm i -g cobolget$ cobolget -v
  • Вам понадобится Zowe, платформа управления для мэйнфреймов с открытым исходным кодом, и ваш профиль Zowe, созданный с использованием указанных выше данных:

$ npm i -g @zowe/cli --ignore-scripts$ zowe -V$ zowe profiles create zosmf ztrial --host <IP> --port <PORT> --user <USER ID> --pass <PASSWORD> --reject-unauthorized falseProfile created successfully!

Вы можете выбрать любой текстовый редактор по вашему желанию, но я рекомендую Visual Studio Code с установленным расширением IBM Z Open Editor.

Спецификация

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

Region,Country,Units Sold,Unit Price,Total Revenue

Region и Country это PIC X(48), Units Sold это PIC 9(9), Unit Price и Total Revenue это PIC 9(9)V99 монетарные десятичные значения. Желаемый регион также PIC X(48). Для простоты мы определим фильтр по региону прямо в основной программе, и будем полагать, что строки CSV не могут превышать 80 символов.

Декомпозиция

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

Разберем спецификацию на функциональные блоки. В основном программа:

  1. Читает файл продаж.

  2. Разбирает строки одну за другой.

  3. Проверяет Region на соответствие.

  4. Агрегирует Total Revenue.

  5. Отображает агрегированное значение.

Таким образом, можно выделить как минимум четыре блока три программы и одну copybook. Точка входа определяет фильтр по региону, вызывает Reader и отображает результат. Программа Reader инкапсулирует операции с файлами (DataSet) и анализирует записи CSV, возвращаемые Parser. Программа Parser преобразует строки CSV в записи.

 src     parser.cbl     reader.cbl     sales.cbl     sales.cpy

Другими словами, наша copybook это структурированная форма строки CSV, совместно используемая в Reader и Parser. Поместим ее в файл CPY:

01 csv-rec.   05  Region              PIC X(48).   05  Country             PIC X(48).   05  UnitsSold           PIC 9(9).   05  UnitPrice           PIC 9(9)V99.   05  TotalRevenue        PIC 9(9)V99.

Зависимости

До того, как Zowe разделил среду разработки и исполнения, инженеры Enterprise COBOL использовали следующие блоки комментариев для документирования изменений:

****************************************************************** DATE       CHANGED BY    DESCRIPTION                          ** --------   ------------  -------------------------------------* * 99.99.99   Author        Description                          *

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

Тенденция разделения монолитных программ с огромным количеством SECTIONS на более мелкие и многократно используемые блоки была бы невозможна без Семантического Версионирования и Управления Пакетами. Несмотря на то, что в наших модулях мы не использовали никакой внешний код, встроенных в COBOL функций (Intrinsic functions) обычно недостаточно в более сложных проектах.

С 2020 года у COBOL есть собственный менеджер пакетов COBOLget, который стандартизирует повторное использования исходного кода разработчиками как открытого, так и проприетарного кода. Инструмент командной строки автоматизирует процесс установки и обновления библиотек, разрешения зависимостей и интеграции внешнего кода COBOL в проекты. Реестр COBOLget аккумулирует библиотеки на диалектах GnuCOBOL и Enterprise COBOL, помогая доставлять публичный и закрытый код командам.

Сердце COBOLget это Манифест modules.json, который описывает проект и его зависимости.

...  "modules": [    "src/parser.cbl",    "src/reader.cbl",    "src/sales.cbl"  ],  "dialect": "entcobol",  "dependencies-debug": {    "ecblunit": "*"  }...

Как видно, структура очень похожа на манифест в NPM. В свойствах modules перечислены COBOL-модули проекта, свойство dialect определяет целевую платформу. Назначение зависимости ecblunit будет объяснено в следующей главе.

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

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

 tests     tests.cbl     tests.jcl

Инструменты

Для этого IBM предлагает проприетарную среду модульного тестирования zUnit. zUnit реализует стандарт xUnit, позволяющий разрабатывать, выполнять и оценивать результаты тестов на любом языке z/OS. Конвейер выглядит так:

  • Test Runner читает файл Test Suite;

  • Test Runner по очереди вызывает Test Cases;

  • ADDTESTS добавляет тестовые программы в Test Case;

  • SETUP выделяет необходимые ресурсы;

  • тестовая программа вызывает модуль и проверяет результат;

  • TEARDOWN высвобождает выделенные ресурсы.

Test Runnerпрограмма z/OS, которая управляет процессом тестирования.
Test SuiteXML-файл, в котором перечислены Test Cases для Test Runner.
Test CaseCOBOL программа, вызывающая модуль.
Assertion COBOL условие, сравнивающее ожидаемые и фактические значения.
Test FixtureCOBOL программы для настройки, запуска и завершения тестов.

Проблема в том, что для одного минимального теста zUnit требуется более 100 строк типового кода, что в простых случаях применения чрезмерно. К счастью, имеется альтернатива с открытым исходным кодом ECBLUnit. В отличие от zUnit, этот инструмент ориентирован только на элементы Test Runner и Assertion. Написанный на Enterprise COBOL, инструмент полностью совместим с z/OS. Тесты ECBLUnit это программы на COBOL, намного более простые, чем тесты zUnit. Поскольку ECBLUnit это обычный пакет COBOLget, мы можем добавить его его как зависимость:

$ cobolget add --debug ecblunit$ cobolget update$ cobolget install

Мокинг

Кажется, в нашем проекте полностью изолированным элементом является только Parser. Reader требует поддержки z/OS для доступа к CSV-файлу. Тем не менее, мы можем изолировать Reader, создав его alter ego Мок. Цель имитации сосредоточиться на тестируемом коде, а не на поведении или состоянии его окружения. Мок реализует контракт исходного модуля с поддельной реализацией:

IDENTIFICATION DIVISION.PROGRAM-ID. READER.DATA DIVISION.WORKING-STORAGE SECTION.COPY SALES.01 csv-row PIC X(48) VALUE  'Europe,Germany,10,9.99,99.90'.LINKAGE SECTION.01 where PIC X(48).01 total PIC 9(9)V99 VALUE 0.PROCEDURE DIVISION USING where RETURNING total.   CALL "PARSER" USING csv-row RETURNING csv-rec.   MOVE TotalRevenue to total.END PROGRAM READER.

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

...01 expected-total PIC 9(9)V99 VALUE 99.90....CALL "READER" USING where RETURNING total.CALL "ECBLUREQ" USING  BY CONTENT ADDRESS OF expected-total  BY CONTENT ADDRESS OF total  BY CONTENT LENGTH OF expected-total.

Этот простой подход позволяет симулировать бизнес-логику любой сложности, избегая нежелательных зависимостей. Давайте теперь соберем и протестируем наши модули на z/OS:

$ cobolget run build...Modules modules.cpy and modules.cbl updated.$ cobolget run test...OKTests: 001, Skipped: 000Assertions: 002, Failures: 000, Exceptions: 000

DevOps

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

$ cobolget run setup

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

$ cobolget run setup:RES

Если все прошло успешно, то теперь можно развернуть и запустить проект Sales на z/OS:

$ cobolget run build$ cobolget run p...Total: 0033368932.11

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

CI

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

  • nodejs.ymlдля GitHub

  • .gitlab-ci.ymlдля GitLab

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

Если вы решите опубликовать проект в своем репозитории, не забудьте объявить переменные HOST, PORT, USER и PASS в Settings->CI/CD->Variables в GitLab или в Settings->Actions secrets в GitHub.

Документация

Программисты постоянно читают код. Обычно соотношение времени, потраченного на чтение и на запись, намного превышает 10:1. Говорящие названия переменных, разделов, абзацев, множество комментариев объясняют читателю, что происходит и почему. IBM рекомендует использовать IDENTIFICATION DIVISION для описания программ. Вот фрагмент, вставляемый IBM Z Open Editor:

*****************************************************************       IDENTIFICATION DIVISION.       PROGRAM-ID.  MYPROG.       AUTHOR. MYNAME.        INSTALLATION. COBOL DEVELOPMENT CENTER.        DATE-WRITTEN. 01/01/08.        DATE-COMPILED. 01/01/08.        SECURITY. NON-CONFIDENTIAL.*****************************************************************

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

В 2020 году Bruno Pacheco выпустил инструмент с открытым исходным кодом, который генерирует документацию из исходного кода COBOL coboldoc. Инструмент решает проблему несовместимости стандартов документации между диалектами COBOL. Coboldoc распознает теги Microfocus, MSDN и Free Format и может создавать документацию в форматах HTML и Markdown.

*>***> Detailed description.*> @summary <text> short description.*> @author <text> defines the author(s).*> @license <text> defines the license.*> @param <type> <name> defines the input*> @return <type> Defines the outout. *>**

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

$ npm i -g coboldoc$ coboldoc -v$ coboldoc generate src/*.cbl -o coboldoc

Заключение

60-летний язык программирования по-прежнему актуален. По оценкам Micro Focus, COBOL используется в 70% глобальных систем обработки транзакций, на нем написаны 220 миллиардов строк кода. Надеюсь, что аспекты, освещенные в этой статье, вдохновят вас на дальнейшее развитие экосистемы. Спасибо за чтение!


Вы энтузиаст COBOL? Давайте разрабатывать недостающие библиотеки вместе читайте далее Enterprise COBOL: реализация библиотеки.

Подробнее..

Управление приведенным освоенным объемом

13.06.2020 22:47:03 | Автор: admin
В данной статье рассматривается вариант использования управление освоенным объемом с нормированным бюджетом (Earned Volume Management with a normalized budget). Таким образом, сохраняются все преимущества управления освоенным объемом (EVM) и появляется конфиденциальность.

История вопроса


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

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

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

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

2. Бюджет проекта скрывается от членов проектной команды, как со стороны Заказчика, так и со стороны подрядчика. В этом случае, уже Заказчик не использует управление освоенным объемом чтобы ни показывать бюджет. Подрядчик, так же, вынужден скрывать данные, чтобы они не стали достоянием сотрудников Заказчика.

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

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

5. Подрядчик может привлекать для исполнения работ более дешевые ресурсы, по сравнению с ожидаемыми Заказчиком. В этом случае, использование управления освоенным объемом, покажет отрицательное отклонение по стоимости (CV) при нулевом или отрицательном отклонении по срокам (SV). Что может вызвать вопросы у Заказчика и привести к выявлению подмены. Данная причина ни является этичной, тем ни менее, она может иметь место в реальной жизни.

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

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

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

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

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


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

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

Если, данных для использования метода освоенного объема, не достаточно, можно провести дополнительное распределение затрат, и использовать метод освоенного объема на основе этого распределения.

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

Варианты нормализации


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

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

Реальная стоимость работ преобразуется с множителем


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

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

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


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

весь бюджет проекта приводится к трудозатратам на пакетах работ или операциях;

плановый бюджет проекта равен плановым трудозатратам всей проектной команды;

прямые затраты на пакет работ или операцию равны прямым трудозатратам;

косвенные затраты переводятся в трудозатраты распределяются на пакет работ или операции по прямым трудозатратам или по доле стоимости;

В примере ниже показано, как можно перевести все трудозатраты в затраты



В примере:

прямые трудозатраты сохранены;

трудозатраты на косвенные статьи (Управление), распределены на пакеты работ пропорционально трудозатратам на них;

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


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

Далее показатели планового объема (PV) и освоенного объема (EV) считаем в единицах нормированных трудозатрат.

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

Возможные затруднения


Адресация фактических косвенных затрат


Механизмы нормирования и распределения достаточно достоверно позволяют определить бюджет и, следовательно, плановый объем (PV) и освоенный объем (EV). А вот, при определении фактических затрат (AC) может возникать вопрос с адресацией затрат. Например, фактические затраты на управление оказались выше плановых, к какому пакету работ или операции они относятся? Могу предложить следующие варианты для обхода таких коллизий:

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

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

Есть данные о затратах только по крупным пакетам и этапам работ


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

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

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

Использование рекомендаций


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

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

Из песочницы Cоздавать или отказываться проверка идеи на прочность

15.06.2020 18:18:41 | Автор: admin

С чего начинается IT-стартап и вообще любая новая задача в IT-проекте? С идеи и вопросов к себе


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

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

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

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

Чек-лист с содержанием в коротких абзацах


Я хочу создать <Идея>, потому что <Кто Ваши пользователи и конкретные примеры реальных потенциальных клиентов?> имеют проблемы: <Какие проблемы у Ваших потенциальных пользователей?>.

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

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

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

Я планирую запустить разработку <Дата>.

Я готов и я уверен в своей Идее.

Use the Google, my Dear


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



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

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

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

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



Какую проблему я хочу решить и для кого?


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

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

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

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

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

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



Время, деньги и рок-н-ролл


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



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

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

Время создания минимальной версии не должно превышать 4-6 месяцев это тот простительный период, когда никто не успеет начать делать то же самое, а вдохновение будет еще сильным. Перед началом разработки обязательно нужно будет пройти этап описания минимальной версии проекта, для понимания масштабов на этом этапе. Это шаг формирования технического задания (только не думайте о ГОСТ нам это не надо).

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

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

Я дочитал до этого раздела и все еще уверен в себе


А если Вы все еще не сомневаетесь в своей идее, значит надо делать.

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



Спасибо за внимание!
Подробнее..

Из песочницы Ретроспектива проекта, на которую команде захочется приходить

03.08.2020 18:13:27 | Автор: admin
Как часто вы скучали на ретроспективе проекта? Как часто вы злились, что тратите на эту встречу целый час своего времени, пока рядом грустно догорает очередная задача? Слушали ли вас на ретро, или каждый ждал своей очереди, чтобы сказать пару формальностей и вернуться к работе? Мне однажды это страшно надоело. В этой статья я буду говорить о том, как с помощью простых правил мне удалось сделать ретро самой теплой встречей команды, не считая корпоратива.



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

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

  • Завершенный проект или большое количество спринтов по проекту в достаточно долгосрочный период. Например, за пару месяцев. Если проект большой, существует выделенная под проект команда и работа над проектом ведется активно, можно проводить ретро раз в месяц. Чаще не стоит.
  • Команда. Желательно, устоявшаяся и внутренняя. Проводить ретроспективу с аутсорсом или в ситуации, когда у вас ресурсы текут сильнее, чем вода из крана бессмысленно и беспощадно.
  • Обратная связь от команды. Будет отлично, если у команды будет возможность подготовиться к ретро. Будет идеально, если у команды будет выделено на это отдельное время в расписании.

В каком формате лучше всего собирать обратную связь


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

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

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

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

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

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

Не пытайтесь решить на ретро все проблемы скопом, это невозможно. Постарайтесь на каждой ретро соблюдать правило:

Три проблемы три решения


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

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

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



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

Шаг 2
Создаем таблицу.

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

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

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

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

Важное правило ретро:

Не команда слушает вас. Вы слушаете команду.

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

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

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

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

Шаг 11
Будьте последовательны и ритмичны. Раз в месяц (или с иной периодичностью) у вас ретро. Все решения, которые выделены на ретро априори или внедряются, или выносятся на следующее обсуждение, как провалившееся решение, для поиска нового.

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

Сделайте ретро хорошей традицией. Вам окупится.
Подробнее..

Платформа управления бизнес-процессами практика внедрения

01.06.2021 12:20:22 | Автор: admin

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

Производственные системы и их решения

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

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

Если говорить о программном продукте для оперативного управления производством компании Dassault Systemes - DELMIA Apriso и его архитектуре, то на его самом нижнем уровне лежит собственная, встроенная платформа управления бизнес-процессами Process Builder. И это единственный обязательный реквизит, необходимый для внедрения подобных систем. Именно здесь описываются все производственные процессы, входящие в контур цифровизации. Помимо самих процессов прописываются все интерфейсы подключения к оборудованию через системы автоматизации или непосредственно подключение бизнес-систем, таких как ERP. На эти бизнес-процессы наслаиваются функциональные модули, которые могут применяться на пользователями из различных производственных дисциплин: контроль качества, склады, ТОиР, декларация производства. Это те элементы, с которыми взаимодействует конечный пользователь оператор ЧПУ, плановик, сотрудники логистической или ремонтной службы и пр.".

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

Описание и моделирование бизнес-процессов

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

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

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

Также можно моделировать, как себя будет вести процесс "в реальной жизни" - ещё до его запуска в производство. С точки зрения конечного пользователя эти изменения не видны, то есть, если в процесс внесены какие-то улучшения или усовершенствования в рамках BPM-платформы, то пользователь не увидит изменений, которые произошли в бизнес-процессах. Такая интеграция и возможность работы с процессами рамках инструмента Process Builder позволяет постоянно улучшать процессы, то есть можно сделать какое-то изменение, чтобы посмотреть, как это выглядит в реальной жизни, получить обратную связь от производства, оценить такие показатели как объем производства, выявить "узкие места" или внести изменения в процесс системы управления производством.

Ядро и интерфейсы пользователя

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

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

Как и во многом другом, главное - найти баланс, "золотую" середину между уникальностью каждой производственной площадки и применяемыми лучшими стандартными корпоративными практиками. Если производственная площадка работает по своим уникальным процессам, не факт что применяется наиболее оптимальный/эффективный подход, но и при внедрении практик необходимо учитывать особенности производственной площадки: планировку, различные типы оборудования, логистику и прочее. Поэтому рекомендуется комбинировать процессы в соотношении 70/30: 70 стандартных и 30 локальных, или 80/20.

Масштабирование системы

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

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

Что даёт такой подход с точки зрения информационных технологий? Во-первых, это высокая скорость внедрения. Обычно 60%-70% времени тратится на разработку основного решения (core), а дальнейшее внедрение требует уже незначительного времени. Например, на подключение новой производственной площадки уходит 2-3 недели, что по меркам систем управления производством очень малый срок.

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

Интеграция с "Цифрой"

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

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

Зная, что данная операция выполнена, Apriso начинается "толкать" к выполнению следующей операции - далее по маршруту следующему обрабатывающему рабочему центру. Там оператор также получает уведомление о том, что он должен выполнить, заходит в свой рабочий интерфейс, декларирует начало операции, выполнение операции. Фактическое время её выполнения заносится в систему управления производством.

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

Рабочие инструкции, созданные ранее, на этапе технологической подготовки производства становятся доступны оператору на его персональном АРМ -непосредственно на рабочем месте и в различных форматах: чертежи, отсканированные pdf-файлы, или в виде 3D модели, как представлено ниже.

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

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

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

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

Преимущество такого решения в том, что оно позволяет собирать информацию c оборудования компании "Цифра". Есть система контроля процессов. Такой совместный подход дает большую синхронизированность работы всех производственных служб, увеличение эффективности использования оборудования и гибкости производства в целом. Всегда можно оперативно отреагировать на изменения, которые требует ситуация на рынке. Решение DELMIA Apriso обеспечивает глобальное управление процессами, контроль производительности, визуализацию и тщательный анализ влияния функциональных улучшений на всех производственных площадках в рамках предприятия.

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

Заинтересовала данная тематика?

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

Познакомьтесь с материалом "Системы управления производством и производственными операциями и современные вызовы".

Узнайте больше о продуктах DELMIA на официальном сайте компании

Подробнее..

Как не испортить своего джуна

12.11.2020 12:19:49 | Автор: admin


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

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

Страх, страх и еще раз страх


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

Точно такой же стереотип существует и в области разработки программного обеспечения. Сформулировать его можно так:

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

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

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

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

Я считаю, что программирование это история о созидании, о творчестве.

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

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

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

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

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

Давайте новичку настоящие и актуальные задачи


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

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

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

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

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

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

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

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

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

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

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

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

Практикуем парное программирование


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

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

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

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

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

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

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

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

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

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

Относитесь к джуну, как к равному


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

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

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

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

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

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

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

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

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

Итог


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

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

P.S.


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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru