Спасибо за статью. Очень распространенная ситуация.
Похоже, что проблема также связана с недостатками в стандартах и процессах проектного управления внутри компании. Правильно ли я понял, что DevOps-специалисты не были выделены, не были закреплены за ИТ-проектом с функциональным подчинением руководителю проекта, а также не были назначены ответственными за этап развертывания в рамках проекта? Из описания можно сделать вывод, что коллектив DevOps действовал в рамках своей "текущей деятельности" и в лучшем случае руководствовался стандартами и внутренним SLA. Если реализация проекта зависела от этапа развертывания, то данный этап и необходимые ресурсы должны были быть включены в календарный и ресурсный план ИТ-проекта.
Не до конца понял про сам конфликт. В качестве причин недопонимания между заказчиками и PO в статье перечислены ключевые области проектного управления:
Скрытый текст
Заказчикам не всегда понятно, как формируется оценка больших проектных задач.
Заказчикам не всегда понятно, какие риски команда закладывает и почему.
Заказчики не верят, что команда загружена на 100%, и хотят пруфы, ведь они ее финансируют.
РО считает, что его работу обесценивают и ему не доверяют.
Управление человеческими ресурсами;
Управление стоимостью и финансированием;
Управление рисками.
Судя по описанным действиям, ситуацию удалось стабилизировать за счет внедрения ряда проектных практик:
Распределение ролей и ответственности между участниками (например, через RACI), стандартизация процессов разработки;
Усиления функциональной области управления коммуникациями;
Усиление и стандартизация управления изменениями продукта/проекта;
Использование инструментов управления качеством: как на уровне продукта (обратная связь от пользователей, добавление метрик), так и на уровне процесса разработки (внедрение DoR, DoD).
В связи с этим вопрос: как Вы считаете, почему на старте развития направления не использовались стандарты и лучшие практики проектного и продуктового управления, которые впоследствии помогли улучшить ситуацию? Если бы процессы разработки, постановки задач, оценки требований, согласования бэклога и взаимодействия с заказчиком изначально были более стандартизированы и прозрачны (как для команды, так и для заказчика), позволило бы это избежать или хотя бы минимизировать негативные последствия возникшего недопонимания?
Говоря о роли РП стандарт: знание, результативность, личные навыки. К hard (знания) и способностям успешно применять эти знания (результативность) в обязательном порядке должны прилагаться soft skills, которые и позволят управлять командой проекта, ожиданиями заказчика и взаимодействию со стейкхолдерами при достижении целей и уравновешивании ограничений проекта.
Как обстоят дела с геймингом на КПК в 2000-х? В 2007 г. пробовал оптимизировать работу эмулятора PlayStation (FPSEce) на КПК HP iPAQ hx2490. На его борту был процессор Intel Xscale PXA (520 МГц). Частота кадров в эмуляции Gran Turismo 1 с включенным фреймскипом не превышала 19 FPS. Однако для WinMobile были порты Fallout и Heroes of Might and Magic, которые успешно запускались на этом устройстве.
✔ Аэрофлот, UT и другие — автоматизация регистрации на рейс. Ещё один пример успешной автоматизации, который заслуживает внимания.
Сегодня вышел пресс-релиз: автоматизация пошла дальше, и теперь пассажиры Аэрофлота смогут самостоятельно не только регистрироваться на рейс, но и регистрировать свой багаж. На первом этапе опция будет доступна для внутренних рейсов.
Все верно, теорий и догадок может быть очень много. Нужно считать. Мы можем развеять подозрения, а решения принять с большей легкостью, если у нас появится ТЭО - технико-экономическоеобоснование целесообразности реализации проекта автоматизации. Может ли и оно быть ошибочным? Несомненно, может, как и многое в этом мире.
Абсолютно уверен, что если бы в вопросе автоматизации не было так много экономически целесообразных "исключений в жизни", то мы бы до сих пор ударно вспахивали поле плугом, косили траву косой, ковали железо молотом, а картошку копали лопатой. А про ЭВМ и IT можно было бы забыть.
Спасибо, стало понятнее. Мы прямо раскрыли п. 5 чек-листа, когда перед началом работ можно честно ответить на вопрос: «Зачем мы автоматизируем процесс?» и определить финансовые цели.
В свою очередь видел впечатляющие результаты оптимизации с высвобождением персонала при внедрении «устройств самообслуживания» (по сути, многофункциональных банкоматов) и после появления мобильных приложений банков. Также наблюдал серьёзные сокращения при переоборудовании птицефабрик, мясокомбинатов, молочных заводов и заводов по производству колбасных изделий. Они просто начинали работать в круглосуточном режиме с небольшой командой техников и инженеров на борту вместо трёх или четырёх смен, которые требовали огромного количества персонала с вилами, разделочными ножами и вёдрами в руках.
Не до конца понял комментарий. Что вы имеете в виду под автоматизацией, "целью которой является увеличение дохода"? Поделитесь примерами?
Доходы делятся на два типа: денежные и неденежные. Вероятно, речь об увеличении денежных доходов за счет оказываемых компанией работ, реализуемых товаров или услуг? Соответственно, речь идет об автоматизации процессов продаж товаров или автоматизации процессов предоставления платных услуг?
В моей практике были такие примеры. Например, автоматизация процесса подготовки и отправки клиенту платных справок/выписок и автоматизация процесса онлайн-продаж. Однако финансовая модель и окупаемость данных проектов опирались скорее на рост прибыли (прибыль = доходы − расходы) за счет сокращения расходов, а не только на росте объемов продаж товаров и услуг.
Пример из фильма действительно получился каноническим.
Насчёт пункта соглашусь с Вами. Для этого в чек-листе использую п. 7 «Наличие пилота». В пилоте можно в полной мере попробовать реализовать пункты (а) и (б), о которых Вы упомянули.
Пункт 8 «Сопротивление изменениям и переиспользование высвобождаемого ресурса» — также даёт варианты для размышления о будущем персонала. Увы, автоматизировать «ручной» процесс или заменить 1000 сотрудников промышленно-производственного персонала автоматизированной производственной линией и при этом сохранить весь состав для этого направления не получится. Здесь открывается простор для переквалификации высвободившихся ресурсов, расширения производства и даже для открытия новых направлений работы с помощью команды, которая уже нанята.
Хороший пример. Достаточно распространенный сценарий. В частности, когда внедряются системы без готовых модулей или создаются с нуля под специфические процессы.
✔ McDonald's – автоматизированные киоски самообслуживания. Сеть ресторанов быстрого питания внедрила цифровые терминалы, позволяющие клиентам самостоятельно делать заказы. Это ускорило обслуживание, снизило вероятность ошибок и увеличило средний чек за счет дополнительных опций, предлагаемых системой.
✔ Airbus – автоматизация контроля качества. На заводах Airbus применяют дроны с компьютерным зрением для инспекции самолетов. Ранее этот процесс занимал несколько часов и требовал участия нескольких специалистов, теперь он выполняется за 10–15 минут.
✖ Nike – роботизированное производство обуви. В 2017 году компания запустила проект автоматизированного производства обуви, но столкнулась с проблемами: роботы не справлялись с тонкими материалами, а сложность в настройке оборудования сделала процесс невыгодным. В результате компания вернулась к традиционному производству.
✖ Foxconn – роботизация производства. Компания Foxconn, известная как производитель электроники для Apple и других брендов, попыталась заменить большую часть рабочих роботами. Однако оказалось, что роботы не справляются с задачами, требующими высокой точности и гибкости, например, сборкой мелких компонентов. В итоге компания вернулась к использованию человеческого труда.
Добрый день. Спасибо, что поделились своим мнением.
Эдвард был отличным программистом в Америке 70-90х. Книгу 1997 года выпуска спустя почти 30 лет можно назвать занимательной и интересной, автор приводит примеры из своего опыта в 1983-1999гг. и активно рекомендует подходы и инструменты проектного управления, большинство из которых на сегодняшний день являются «базой» и включены в международные стандарты, а также в ГОСТ Р ИСО 21500—2014.
Есть нюанс, книга про конкретный тип проектов и работу с ним, в ней идет речь про «безнадежные проекты».
Под безнадёжным проектом (death march) я понимаю такой проект, параметры которого изначально отклоняются от нормальных значений по срокам, ресурсам, бюджету и требованиям по крайней мере на 50%, вероятность провала свыше 50%. Путь камикадзе. Эдвард Йордон.
Несомненно, такой тип проектов существовал, существует и будет существовать, но совершенно неуместно называть проекты, которые попали в "красную" зону системы мониторинга "безнадежными". Благодаря современным методологиям, стандартам и процессам, запуск "безнадежных" проектов стал скорее исключением, чем правилом, прерогативой стартапов и небольших компаний, в которых культура разработки ПО и компетенции проектного управления отсутствуют или находится на уровне ниже среднего.
Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Путь камикадзе. Эдвард Йордон.
В своей статье не является «индивидуальной проектной рекомендацией») я делюсь информацией о том какие бывают статусы проектов в современных системах управления, делюсь личным мнением о том, что приводит проекты в "красную зону" и предлагаю алгоритм работы с ними. Все это актуально для проектов из среды крупных IT и Fintech компаний с развитыми стандартами разработки ПО и системами управления ИТ-проектами, а также для небольших команд с экспертом по проектному управлению на борту.
В части моего личного мнения по участию в "безнадежных проектах", о которых Эдвард написал свою книгу: частично соглашусь, но абсолютно уверен, что любой "безнадежный" проект при должном внимании можно трансформировать в окупаемую и реализуемую инициативу.
Самое главное – это осознать и понять в самом начале безнадёжного проекта свою собственную мотивацию с тем, чтобы вы могли принять взвешенное решение – участвовать в проекте или поискать другую работу. Путь камикадзе. Эдвард Йордон.
Добрый день, спасибо, что поделились своим мнением.
Я лично из неё сделал вывод, что проект становится красным, если его нельзя реализовать в поставленные сроки/деньги либо произошло что-то непредвиденное..
Все верно, система статусов «зеленый-желтый-красный» используется в проектном управлении крупных компаний для мониторинга «здоровья» проекта. Она позволяет агрегировать результаты мониторинга (проектных работ, использованных ресурсов, бюджетов, закупок, рисков, результатов и их качества) и проинформировать всех заинтересованных лиц об имеющихся отклонениях.
чтобы её решить нужно просто... запросить ещё сроков/денег, чтобы решить возникшую проблему?
Неверно, в первую очередь необходимо определить и проанализировать причины возникших отклонений, которые привели проект в красную зону. Далее потребуется подготовить план необходимых изменений для продолжения реализации проекта. Проблема не «решается» изменением сроков или бюджетов, она требует подробного анализа, выводов и поиска возможных решений. Одним из решений может быть выделений дополнительных ресурсов или бюджета, но это только одно из возможных решений. Как я указал в статье:
«Потребуется запросить у лиц, принимающих решения, конкретные изменения, которые помогут стабилизировать ситуацию.»
Причем никак не затронут вопрос, если, например, после введения новых законов/изменившихся условий ваш проект вообще перестал быть рентабельным и что делать в таком случае, или если ваша команда не прошла испытание факторов автобуса и ушёл ключевой разработчик с большей частью знаний, как в таком случае замещать потерю?
Это отличные вопросы, которые требует подробного обсуждение, подойдет для новой статьи. Одним из объектов управления в проектном управлении являются риски. На этапе планирования проекта все или часть указанных в ваших вопросах рисков могут быть идентифицированы, проанализированы и запланирован план действий в случае реализации.
Давайте вместе раскроем тему. Что из вашего опыта наиболее эффективно в сложившихся ситуациях? Вот мои варианты нивелирования и реагирования на перечисленные риски:
Отрицательная рентабельность - пересмотр фин. модели, ТЭО, CF, сокращения расходов, поиск новых статьей доходов и окупаемости проекта. При провале - варианты переиспользования или реализации промежуточных результатов проекта на рынок.
Человеческие ресурсы и ключевые компетенции — страхование участников, кадровый резерв, параметры трудового договора с ключевым игроками (key players) предусматривающие дополнительную мотивацию при успешном завершении работ, а также применение финансовых санкции при преждевременном выходе участника из проекта.
Рад, что вам понравился этот термин. Знакомая ситуация. Возможно, существуют и другие проекты, которые также имеют критичные зависимости от вашего и того, другого проекта. Для улучшения ситуации видится целесообразным выявить и объединить все связанные проекты в программу или в портфель. Это поможет установить все зависимости, расставит приоритеты, централизовать и скоординировать работы. Если это уже реализовано, то о выявленных вами рисках следует проинформировать ответственного за реализацию программы/портфеля проектов руководителя.
Гривна: полфунта чистого золотого песка из которого чеканят 60 флоренов (Петер Эвертсен, глава №5 «Час презрения»);
Курс темерского орена к нильфгаардскому флорену 100:9. "Это другая разница. Энто будет.. Дайте подумать. Пять сотен, с позволения вашей милости, ежели в темеркой валюте. Если же вашими флоренами, то сорок пять." (Торгаш, глава №2 "Крещение огнем");
Интересные цены в нильфгаардских флоренах.
Лошадь Цыри (Кельпи): 100 флоренов (Хотспорн, глава №2 «Башня ласточки»);
Убить Фальку (Цыри): 100 флоренов (Бонарт, глава №10 «Башня ласточки»);
Выйти против вооруженной Цыри на арену: 30 флоренов. (Хувенагель, глава №4 «Башня ласточки»);
Убить ведьмака Геральта: 100 флоренов (Полуэльф Ширру, глава №6 «Башня ласточки»);
Мечи с кованной головкой (стандартные): 5-9 флоренов (Эстерхази, глава №4 «Башня ласточки»);
Спасибо за статью. Очень распространенная ситуация.
Похоже, что проблема также связана с недостатками в стандартах и процессах проектного управления внутри компании. Правильно ли я понял, что DevOps-специалисты не были выделены, не были закреплены за ИТ-проектом с функциональным подчинением руководителю проекта, а также не были назначены ответственными за этап развертывания в рамках проекта? Из описания можно сделать вывод, что коллектив DevOps действовал в рамках своей "текущей деятельности" и в лучшем случае руководствовался стандартами и внутренним SLA. Если реализация проекта зависела от этапа развертывания, то данный этап и необходимые ресурсы должны были быть включены в календарный и ресурсный план ИТ-проекта.
Спасибо за статью. Интересный пример.
Не до конца понял про сам конфликт. В качестве причин недопонимания между заказчиками и PO в статье перечислены ключевые области проектного управления:
Скрытый текст
Управление человеческими ресурсами;
Управление стоимостью и финансированием;
Управление рисками.
Судя по описанным действиям, ситуацию удалось стабилизировать за счет внедрения ряда проектных практик:
Распределение ролей и ответственности между участниками (например, через RACI), стандартизация процессов разработки;
Усиления функциональной области управления коммуникациями;
Усиление и стандартизация управления изменениями продукта/проекта;
Использование инструментов управления качеством: как на уровне продукта (обратная связь от пользователей, добавление метрик), так и на уровне процесса разработки (внедрение DoR, DoD).
В связи с этим вопрос: как Вы считаете, почему на старте развития направления не использовались стандарты и лучшие практики проектного и продуктового управления, которые впоследствии помогли улучшить ситуацию? Если бы процессы разработки, постановки задач, оценки требований, согласования бэклога и взаимодействия с заказчиком изначально были более стандартизированы и прозрачны (как для команды, так и для заказчика), позволило бы это избежать или хотя бы минимизировать негативные последствия возникшего недопонимания?
В идеале это зона ответственности PMO, но всё может зависеть от имеющихся в компании ресурсов, процессов и инструментов. Возможна автоматизация.
Соглашусь с автором. Сердечки и сомнительного рода смайлики вызывают недоумение, когда получаешь их от коллег в рабочем чате на 50+ человек.
Спасибо за статью. Соглашусь с выводами автора.
Говоря о роли РП стандарт: знание, результативность, личные навыки. К hard (знания) и способностям успешно применять эти знания (результативность) в обязательном порядке должны прилагаться soft skills, которые и позволят управлять командой проекта, ожиданиями заказчика и взаимодействию со стейкхолдерами при достижении целей и уравновешивании ограничений проекта.
Спасибо за статью, было интересно прочитать.
Как обстоят дела с геймингом на КПК в 2000-х? В 2007 г. пробовал оптимизировать работу эмулятора PlayStation (FPSEce) на КПК HP iPAQ hx2490. На его борту был процессор Intel Xscale PXA (520 МГц). Частота кадров в эмуляции Gran Turismo 1 с включенным фреймскипом не превышала 19 FPS. Однако для WinMobile были порты Fallout и Heroes of Might and Magic, которые успешно запускались на этом устройстве.
Спасибо.
✔ Аэрофлот, UT и другие — автоматизация регистрации на рейс. Ещё один пример успешной автоматизации, который заслуживает внимания.
Сегодня вышел пресс-релиз: автоматизация пошла дальше, и теперь пассажиры Аэрофлота смогут самостоятельно не только регистрироваться на рейс, но и регистрировать свой багаж. На первом этапе опция будет доступна для внутренних рейсов.
Все верно, теорий и догадок может быть очень много. Нужно считать. Мы можем развеять подозрения, а решения принять с большей легкостью, если у нас появится ТЭО - технико-экономическое обоснование целесообразности реализации проекта автоматизации. Может ли и оно быть ошибочным? Несомненно, может, как и многое в этом мире.
Абсолютно уверен, что если бы в вопросе автоматизации не было так много экономически целесообразных "исключений в жизни", то мы бы до сих пор ударно вспахивали поле плугом, косили траву косой, ковали железо молотом, а картошку копали лопатой. А про ЭВМ и IT можно было бы забыть.
- напридумывал, чтобы не работать...Спасибо, стало понятнее. Мы прямо раскрыли п. 5 чек-листа, когда перед началом работ можно честно ответить на вопрос: «Зачем мы автоматизируем процесс?» и определить финансовые цели.
В свою очередь видел впечатляющие результаты оптимизации с высвобождением персонала при внедрении «устройств самообслуживания» (по сути, многофункциональных банкоматов) и после появления мобильных приложений банков. Также наблюдал серьёзные сокращения при переоборудовании птицефабрик, мясокомбинатов, молочных заводов и заводов по производству колбасных изделий. Они просто начинали работать в круглосуточном режиме с небольшой командой техников и инженеров на борту вместо трёх или четырёх смен, которые требовали огромного количества персонала с вилами, разделочными ножами и вёдрами в руках.
@vadimr
Не до конца понял комментарий. Что вы имеете в виду под автоматизацией, "целью которой является увеличение дохода"? Поделитесь примерами?
Доходы делятся на два типа: денежные и неденежные. Вероятно, речь об увеличении денежных доходов за счет оказываемых компанией работ, реализуемых товаров или услуг? Соответственно, речь идет об автоматизации процессов продаж товаров или автоматизации процессов предоставления платных услуг?
В моей практике были такие примеры. Например, автоматизация процесса подготовки и отправки клиенту платных справок/выписок и автоматизация процесса онлайн-продаж. Однако финансовая модель и окупаемость данных проектов опирались скорее на рост прибыли (прибыль = доходы − расходы) за счет сокращения расходов, а не только на росте объемов продаж товаров и услуг.
Пример из фильма действительно получился каноническим.
Насчёт пункта соглашусь с Вами. Для этого в чек-листе использую п. 7 «Наличие пилота». В пилоте можно в полной мере попробовать реализовать пункты (а) и (б), о которых Вы упомянули.
Пункт 8 «Сопротивление изменениям и переиспользование высвобождаемого ресурса» — также даёт варианты для размышления о будущем персонала. Увы, автоматизировать «ручной» процесс или заменить 1000 сотрудников промышленно-производственного персонала автоматизированной производственной линией и при этом сохранить весь состав для этого направления не получится. Здесь открывается простор для переквалификации высвободившихся ресурсов, расширения производства и даже для открытия новых направлений работы с помощью команды, которая уже нанята.
Хороший пример. Достаточно распространенный сценарий. В частности, когда внедряются системы без готовых модулей или создаются с нуля под специфические процессы.
✔ McDonald's – автоматизированные киоски самообслуживания. Сеть ресторанов быстрого питания внедрила цифровые терминалы, позволяющие клиентам самостоятельно делать заказы. Это ускорило обслуживание, снизило вероятность ошибок и увеличило средний чек за счет дополнительных опций, предлагаемых системой.
✔ Airbus – автоматизация контроля качества. На заводах Airbus применяют дроны с компьютерным зрением для инспекции самолетов. Ранее этот процесс занимал несколько часов и требовал участия нескольких специалистов, теперь он выполняется за 10–15 минут.
✖ Nike – роботизированное производство обуви.
В 2017 году компания запустила проект автоматизированного производства обуви, но столкнулась с проблемами: роботы не справлялись с тонкими материалами, а сложность в настройке оборудования сделала процесс невыгодным. В результате компания вернулась к традиционному производству.
✖ Foxconn – роботизация производства. Компания Foxconn, известная как производитель электроники для Apple и других брендов, попыталась заменить большую часть рабочих роботами. Однако оказалось, что роботы не справляются с задачами, требующими высокой точности и гибкости, например, сборкой мелких компонентов. В итоге компания вернулась к использованию человеческого труда.
Добрый день. Спасибо, что поделились своим мнением.
Эдвард был отличным программистом в Америке 70-90х. Книгу 1997 года выпуска спустя почти 30 лет можно назвать занимательной и интересной, автор приводит примеры из своего опыта в 1983-1999гг. и активно рекомендует подходы и инструменты проектного управления, большинство из которых на сегодняшний день являются «базой» и включены в международные стандарты, а также в ГОСТ Р ИСО 21500—2014.
Есть нюанс, книга про конкретный тип проектов и работу с ним, в ней идет речь про «безнадежные проекты».
Несомненно, такой тип проектов существовал, существует и будет существовать, но совершенно неуместно называть проекты, которые попали в "красную" зону системы мониторинга "безнадежными". Благодаря современным методологиям, стандартам и процессам, запуск "безнадежных" проектов стал скорее исключением, чем правилом, прерогативой стартапов и небольших компаний, в которых культура разработки ПО и компетенции проектного управления отсутствуют или находится на уровне ниже среднего.
В своей статье
не является «индивидуальной проектной рекомендацией») я делюсь информацией о том какие бывают статусы проектов в современных системах управления, делюсь личным мнением о том, что приводит проекты в "красную зону" и предлагаю алгоритм работы с ними. Все это актуально для проектов из среды крупных IT и Fintech компаний с развитыми стандартами разработки ПО и системами управления ИТ-проектами, а также для небольших команд с экспертом по проектному управлению на борту.В части моего личного мнения по участию в "безнадежных проектах", о которых Эдвард написал свою книгу: частично соглашусь, но абсолютно уверен, что любой "безнадежный" проект при должном внимании можно трансформировать в окупаемую и реализуемую инициативу.
Добрый день, спасибо, что поделились своим мнением.
Все верно, система статусов «зеленый-желтый-красный» используется в проектном управлении крупных компаний для мониторинга «здоровья» проекта. Она позволяет агрегировать результаты мониторинга (проектных работ, использованных ресурсов, бюджетов, закупок, рисков, результатов и их качества) и проинформировать всех заинтересованных лиц об имеющихся отклонениях.
Неверно, в первую очередь необходимо определить и проанализировать причины возникших отклонений, которые привели проект в красную зону. Далее потребуется подготовить план необходимых изменений для продолжения реализации проекта. Проблема не «решается» изменением сроков или бюджетов, она требует подробного анализа, выводов и поиска возможных решений. Одним из решений может быть выделений дополнительных ресурсов или бюджета, но это только одно из возможных решений. Как я указал в статье:
«Потребуется запросить у лиц, принимающих решения, конкретные изменения, которые помогут стабилизировать ситуацию.»Это отличные вопросы, которые требует подробного обсуждение, подойдет для новой статьи. Одним из объектов управления в проектном управлении являются риски. На этапе планирования проекта все или часть указанных в ваших вопросах рисков могут быть идентифицированы, проанализированы и запланирован план действий в случае реализации.
Давайте вместе раскроем тему. Что из вашего опыта наиболее эффективно в сложившихся ситуациях? Вот мои варианты нивелирования и реагирования на перечисленные риски:
Отрицательная рентабельность - пересмотр фин. модели, ТЭО, CF, сокращения расходов, поиск новых статьей доходов и окупаемости проекта. При провале - варианты переиспользования или реализации промежуточных результатов проекта на рынок.
Человеческие ресурсы и ключевые компетенции — страхование участников, кадровый резерв, параметры трудового договора с ключевым игроками (key players) предусматривающие дополнительную мотивацию при успешном завершении работ, а также применение финансовых санкции при преждевременном выходе участника из проекта.
Рад, что вам понравился этот термин. Знакомая ситуация. Возможно, существуют и другие проекты, которые также имеют критичные зависимости от вашего и того, другого проекта. Для улучшения ситуации видится целесообразным выявить и объединить все связанные проекты в программу или в портфель. Это поможет установить все зависимости, расставит приоритеты, централизовать и скоординировать работы. Если это уже реализовано, то о выявленных вами рисках следует проинформировать ответственного за реализацию программы/портфеля проектов руководителя.
Дополню про деньги Континента.
Валюты и курсы.
Коппер: 1/100 новиградской кроны (Торги купцов, «Вечный огонь» книга «Меч предназначения»);
Гривна: полфунта чистого золотого песка из которого чеканят 60 флоренов (Петер Эвертсен, глава №5 «Час презрения»);
Курс темерского орена к нильфгаардскому флорену 100:9. "Это другая разница. Энто будет.. Дайте подумать. Пять сотен, с позволения вашей милости, ежели в темеркой валюте. Если же вашими флоренами, то сорок пять." (Торгаш, глава №2 "Крещение огнем");
Интересные цены в нильфгаардских флоренах.
Лошадь Цыри (Кельпи): 100 флоренов (Хотспорн, глава №2 «Башня ласточки»);
Убить Фальку (Цыри): 100 флоренов (Бонарт, глава №10 «Башня ласточки»);
Выйти против вооруженной Цыри на арену: 30 флоренов. (Хувенагель, глава №4 «Башня ласточки»);
Убить ведьмака Геральта: 100 флоренов (Полуэльф Ширру, глава №6 «Башня ласточки»);
Мечи с кованной головкой (стандартные): 5-9 флоренов (Эстерхази, глава №4 «Башня ласточки»);
Стенобойная машина: 50 флоренов, осадная машина: 200 флоренов, камнемет: 150 флоренов, баллиста: 80 флоренов (Петер Эвертсен, глава №5 «Час презрения»)
Интересные цены в новиградских кронах.
Убить ведьмака Геральта: 200 крон (Риенс и братья Мишеле, глава №6 «Кровь Эльфов»);
Лук Мильвы (прибыл с дальнего севера): 400 крон. (Глава №1 «Крещение огнем»);
Серебрянный наконечник для стрел: 5 крон (Мильва, глава №3 «Крещение огнем»);
Имущественный залог (поручительство): 500 крон (госпожа судья Керака, глава №3 «Сезон Гроз»);
Обучение в Аретузе: 1200 крон (Джианкарди, глава №2 «Час презрения»);
Взятка министру иностранных дел: 1000-1500 крон. (Диалог Дийкстры и короля Эстерада Тиссена, глава №8 Башня Ласточки»);