Так и есть, мы сторонники основательного подхода. Но при этом нисколько не осуждаем MVP подход. Мы часто восхищаемся эджайл-командами, которые умеют быстро «зарелизить» продукт. Но успешных среди таких мало. Чаще всего получается так, что выпущенный минимально жизнеспособный релиз настолько не оправдывает ожиданий пользователей, что последующие усовершенствованные версии их уже мало интересуют. Убытки и подорванная репутация как итог.
Там, в тексте, было упоминание про FabricPath. Мы опасаемся, что вендор не будет достаточно быстро развивать этот продукт. Даже субъективно: выступления на последних NANOG от Cisco не про FP, а про Segment Routing и EVPN. Также, стремясь к гибкости архитектур, мы стараемся избегать vendor lock.
Спасибо вам за отзыв! Я считаю, что продакту в ИТ сфере лучше всего иметь техническое образование, которое дает системное мышление. А маркетинговые знания «нанизывать» на эту основу. Систематизировать свои знания и опыт лучше всего на курсах, где выдают диплом государственного образца, сейчас таких много. В Нетологии, например, неплохой курс продуктовой разработки, по итогам которого даже помогают с трудоустройством, во ВШЭ есть курс «Продакт- менеджмент технологического продукта». Но некоторым могут помочь и непродолжительные серии семинаров, например при MBS по продуктовому маркетингу. В любом случае дальше надо будет накопленные знания применять к бизнес процессам, которые в каждой компании разные. Но по опыту судя, отнюдь не везде проработана процедура разработки продукта, и продуктологу, пришедшему со своими знаниями и навыками, иногда приходится просто налаживать процесс разработки продукта с нуля.
Действительно, во многих компаниях получается такая ситуация. Я же описала, как идет процесс продуктовой разработки у нас. И снова хочу подчеркнуть: мы говорим не о софтверной разработке, а о разработке сервиса.
Облачный провайдер управляет ресурсами. И для него нет никакой сложности в том, чтобы выборочно ограничить одного из клиентов в предоставлении какой-либо услуги или ресурсах. Хотя вы правы — это очень странное решение.
Не буду комментировать политику продаж компании VMware. Я написал о нашем опыте, надеясь, что он кому-то окажется полезным. Уверен, что за виртуализацией будущее, но не все сервисы будут виртуализированы.
У нас есть Гос-Облако, инфраструктура которого аттестована по К1, то есть требования к системам классов К2 и К3 выполняются… Есть Бизнес-Облако, оно не аттестовано по К1, но позволяет размещать системы персональных данных УЗ-3 и УЗ-4. На счет 1К — сорри, опечатались, тут имелась ввиду аттестация информационных систем персональных данных класса К1. Данная классификация была введена трехглавым приказом 2008 года, который ныне не действуют. Но частенько встречаются заказчики, которые, несмотря на то, что прошло много лет, не знают, что классификация ИСПДн изменена. Единственное, в этом же приказе вводились четыре категории ПДн, о которых мы и пишем. Теперь ПДн так не категорируются.
Мы можем содействовать заказчику в создании стокового шифрованного пула для хранения данных, ключами к которому будет обладать лишь заказчик такого пула. Заказчик берет на себя риски потери ключей доступа к пулу и как следствие полной потери данных без возможности их восстановления.
Есть достаточно много о средств шифрования, которые надежно защитят данные даже в случае физического доступа к серверам клиента. Если клиент использует шифрование дисков (VeraCrypt ) или пулов в самой виртуальной машины, обладая эксклюзивным ключем, который остается у него всегда, то получить доступ туда мы не сможем при всем желании.
Шифрование лишает нас “простого” доступа к данным заказчика. При оценке допустимых мер по защите информации за основу всегда берется стоимость защищаемой информации. Любой алгоритм шифрования подвержен брутфорсу, для его выполнения нужны вычислительные мощности. А мы их используем для продажи нашим клиентам, а не с целью переборки ключей к данным заказчика.
Исходя из этого, репутационные потери для нас выше, чем одноразовая финансовая выгода от продажи информации клиента.
Мы практически с каждым заказчиком проводим расчёт ТСО. И почти всегда облачная модель выигрывает. Нужно понимать, что у провайдера есть точки экономии, которые заказчик, если это не огромная корпорация, просто не может получить. Например, специальные программы с производителями ПО, когда его можно получить по подписке. Или стоимость оборудования, которая у нас ниже. Или построенные процессы и большой объём, которые снижают стоимость эксплуатации. Если хотите, можете скинуть нам свои данные на почту team@ts-cloud.ru, а мы в ответ пришлем такой расчет.
Простите, что повторяемся, но тут снова всё зависит от провайдера. Мы, например, не только в SD работаем, а еще постоянно на связи по телефону или через telegram. Мы информируем заказчика о статусе работ и часто работаем совместно с ним, помогая решать проблемы на границе ответственности. Наконец, заказчик всегда может попросить персонального СМ.
Мы рискуем бизнесом в неменьшей степени. Для любого провайдера репутация — ключевой вопрос. Любая проблема с облаком, если она сколько-нибудь серьёзна, становится публичной. Конечно, такая проблема вредит репутации и даже один инцидент может похоронить провайдера.
Итого для нас проблема одного клиента может означать потерю многих или бизнеса с целом.
Особенно это важно для нас, работающих со средними и крупными клиентами, где репутация вообще является главным аргументом для заказчика.
Конечно, нам выгоднее сто раз перезаложиться и обеспечить максимальное резервирование. Что до изъятия, то скажу прямо: мы заинтересованы максимально отстаивать интересы клиента. В некоторых продуктах существует возможность включить шифрование, которое целиком лишит нас возможности даже теоретического доступа к данным. В остальных случаях мы подключаем нашу юридическую службу для оценки правомерности запроса. Как и в случае с отказоустойчивостью, это вопрос репутации.
Я бы не делал особый уклон в сторону управления рисками, РП должен управлять всеми областями знаний. Просто в одном проекте особое внимание надо уделить именно рискам, в другом, например, срокам, в третьем — содержанию. Поэтому РП необходим даже в том проекте, где риски понятные и управляемые либо минимальные.
Теперь по существу вопроса. В Техносерв управление рисками осуществляется на всем жизненном цикле проекта — от пресейла до полного исполнения обязательств.
Так, на этапе пресейла и конкурса риски оцениваются не только руководителем проекта и архитектором/ГИПом, но и юристами, финансистами, бухгалтерией, договорным отделом. Составляется сводный реестр рисков и принимается решение go/no go.
На этапе исполнения проекта ответственный за управление рисками — РП, который ведет реестр рисков со следующими минимальными атрибутами: наименование риска, вероятность наступления, возможные последствия, меры противодействия. Такого реестра достаточно для поставочных проектов. Для более сложных проектов набор атрибутов шире. Добавляются причины возникновения риска, тактика работы с риском (принятие, снижение, уклонение, передача и разделение), степень влияния, оценка риска в деньгах. Рискам, которые имеют высокую степень наступления и влияния присваивается максимальный вес и уделяется особое внимание. В задачи РП входит регулярная актуализация реестра рисков.
Сложно дать конкретный совет без понимания специфики компании и самого проекта (организационная структура, модель бизнеса, устоявшиеся бизнес-процессы и т.д.).
Тем не менее, начать нужно со следующих вещей:
1. Определить цели проекта
Зачем он нужен в принципе, какие задачи/проблемы бизнеса решает, какой результат ожидают заинтересованные стейкхолдеры, если они вообще есть. Любой заинтересованный VIP — ваш потенциальный союзник в преодолении бюрократических барьеров.
2. Определить ролевую модель проектной команды
Она будет зависеть от специфики самого проекта. Если это верхняя часть пирамиды (бизнес-процессы, разработка ПО) — она будет одна, если инфраструктурный проект — другая, стройка и инженерные системы — третья. Из этого будет понятно, какие подразделения необходимо будет привлечь для выполнения поставленных задач. Возможно, окажется так, что требуемых компетенций внутри компании не окажется, придется искать их на рынки (подрядчики, срочные трудовые договора и т.д.).
В любом случае, вам понадобятся ключевые участники команды:
Системный архитектор — будет отвечать за всю технологическую часть, чтобы результат проекта соответствовал требованиям и решал поставленную задачу. По сути за качество в проекте(соответствие заданным параметрам). Он должен декомпозировать глобальную задачу на составные части, определить численность и квалификацию необходимых для реализации ресурсов, и при их наборе поставить частные задачи каждому исполнителю.
ПМ — будет отвечать за всю организационную часть проекта (комментарии излишне, собственно об этом статья)
Специалисты по направлениям — например, проектировщики, аналитики. Кол-во и компетенции будут сильно зависеть от самого проекта.
3. Закрепление проектной команды
Если в компании "… вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин..." пишите и протаскивайте через руководство приказ о старте проекта с назначением ответственных исполнителей (согласно ролевой модели), а также Устав проекта, где должны быть описаны ответственность и полномочия каждого исполнителя. Это поможет персонализировать ответственность, как за результат в целом, так и за отдельные его части между исполнителями.
ВАЖНО! В описанной вами ситуации, если вы не найдете заинтересованных союзников среди ТОП-менеджеров, взаимодействие с горизонтальными подразделениями превратится в позиционно-осадную борьбу. Результат будет низким, а его достижение долгим. Должен быть арбитр данного взаимодействия.
Основная проблема, как я понял, что культура проектной деятельности в компании отсутствует, либо находится в крайне зачаточном состоянии.
Если в вашей компании проекты — это не мероприятия носящие разовый характер, нужен диалог с руководством о создании проектного офиса и внедрения процессов проектной деятельности на системной уровне. В противном случае, каждый старт и реализация нового проекта будет «как в первый раз».
Желаю вам удачи! Надеюсь все получится!
Специфика «Техносерва» в том, что у нас за уровень «какую проблему решает проект», все-таки отвечает не столько ПМ, сколько архитектор. Про его работу мой коллега недавно подробно писал — habrahabr.ru/company/technoserv/blog/344702. На самом деле этот вопрос отражен в разделе по управлению качеством (требования и ожидания). Решение данного вопроса мы делегируем системному архитектору, поскольку именно он отвечает за то, чтобы техническая реализация проекта отвечала требованиям заказчика, в том числе, решала его бизнесовую и функциональную проблематику.
Решение принимается всегда индивидуально. Все зависит от организационной сложности проекта и его территориально распределенности. Например, если это региональный проект, то часто назначают одного РП в Москве и одного в регионе, иногда в этом нет необходимости. У меня бывали случаи, когда в одном проекте участвовало 12 РП (он состоял из 800 объектов по всей России, работы велись параллельно), и было в точности наоборот — один РП вел 12 небольших проектов.
Вы, разумеется, правы — от команды очень многое зависит, умение договориться и замотивировать — обязательная компетенция ПМ'а. И любая часть работы — и управление рисками, и управление качеством, и бюджетом — так или иначе в команду упирается.
А то, что вы описали — «грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики. Поэтому на специфику я и сделал упор. Работа с командой — огромная тема, которая тянет на отдельный пост.
Управление проектами, как и любая другая профессиональная деятельность, требует получения профессиональных знаний.
Их получение не составляет большого труда, ведь рынок сейчас дает большое количество предложений по обучению руководителей проектов. Начинать нужно именно с этого.
Выбирая тренинговый центр, нужно понимать, что большинство из них предлагает лишь получение академических знаний, основанных на одной из наиболее популярных и часто применяемых методологий (PMI, PRINCE2, Agile, Scrum и пр.). Если вы начинающий ПМ, и ваша текущая должность подразумевает только администрирование проектов без принятия управленческих решений, этого обычно бывает достаточно, чтобы «втянуться» в профессию. На рынке есть и более продвинутые тренинги, которые помимо погружения в методологию, основываются на практикумах и тренировке необходимых навыков. Некоторые центры предлагают даже специальные образовательные проекты, построенные на использовании бизнес-симуляторов для формирования/развития компетенции проектного управления. С одним из таких центров мы дружим и обмениваемся опытом — STS-VostoK (www.stsvostok.ru) Тут, как говориться, на вкус и цвет…
Стоит помнить, что любая методология — это всего лишь набор инструментов и описание правил по их применению: «отвертка — чтобы закручивать шурупы», «молоток — чтобы забивать гвозди». И это только часть решаемой задачи по выращиванию профессионального ПМ'а. Чтобы управлять большими комплексными проектами, нужна практика, опыт и навыки, полученные в реальных проектах.
Умение взвешенно принимать самостоятельные управленческие решения и нести за них ответственность — основное отличие руководителя проекта от администратора.
Вообще для профессионального ПМ'а обучение это процесс непрерывный. Оно помогает не только получать новые знания, но и систематизировать/улучшать полученные ранее.
Его можно сравнить с профессиональным хирургом, который владеет множеством инструментов и техник, но в конкретном случает применяет именно ту, которая спасет пациенту жизнь).
Есть достаточно много о средств шифрования, которые надежно защитят данные даже в случае физического доступа к серверам клиента. Если клиент использует шифрование дисков (VeraCrypt ) или пулов в самой виртуальной машины, обладая эксклюзивным ключем, который остается у него всегда, то получить доступ туда мы не сможем при всем желании.
Шифрование лишает нас “простого” доступа к данным заказчика. При оценке допустимых мер по защите информации за основу всегда берется стоимость защищаемой информации. Любой алгоритм шифрования подвержен брутфорсу, для его выполнения нужны вычислительные мощности. А мы их используем для продажи нашим клиентам, а не с целью переборки ключей к данным заказчика.
Исходя из этого, репутационные потери для нас выше, чем одноразовая финансовая выгода от продажи информации клиента.
Итого для нас проблема одного клиента может означать потерю многих или бизнеса с целом.
Особенно это важно для нас, работающих со средними и крупными клиентами, где репутация вообще является главным аргументом для заказчика.
Конечно, нам выгоднее сто раз перезаложиться и обеспечить максимальное резервирование. Что до изъятия, то скажу прямо: мы заинтересованы максимально отстаивать интересы клиента. В некоторых продуктах существует возможность включить шифрование, которое целиком лишит нас возможности даже теоретического доступа к данным. В остальных случаях мы подключаем нашу юридическую службу для оценки правомерности запроса. Как и в случае с отказоустойчивостью, это вопрос репутации.
Теперь по существу вопроса. В Техносерв управление рисками осуществляется на всем жизненном цикле проекта — от пресейла до полного исполнения обязательств.
Так, на этапе пресейла и конкурса риски оцениваются не только руководителем проекта и архитектором/ГИПом, но и юристами, финансистами, бухгалтерией, договорным отделом. Составляется сводный реестр рисков и принимается решение go/no go.
На этапе исполнения проекта ответственный за управление рисками — РП, который ведет реестр рисков со следующими минимальными атрибутами: наименование риска, вероятность наступления, возможные последствия, меры противодействия. Такого реестра достаточно для поставочных проектов. Для более сложных проектов набор атрибутов шире. Добавляются причины возникновения риска, тактика работы с риском (принятие, снижение, уклонение, передача и разделение), степень влияния, оценка риска в деньгах. Рискам, которые имеют высокую степень наступления и влияния присваивается максимальный вес и уделяется особое внимание. В задачи РП входит регулярная актуализация реестра рисков.
Тем не менее, начать нужно со следующих вещей:
1. Определить цели проекта
Зачем он нужен в принципе, какие задачи/проблемы бизнеса решает, какой результат ожидают заинтересованные стейкхолдеры, если они вообще есть. Любой заинтересованный VIP — ваш потенциальный союзник в преодолении бюрократических барьеров.
2. Определить ролевую модель проектной команды
Она будет зависеть от специфики самого проекта. Если это верхняя часть пирамиды (бизнес-процессы, разработка ПО) — она будет одна, если инфраструктурный проект — другая, стройка и инженерные системы — третья. Из этого будет понятно, какие подразделения необходимо будет привлечь для выполнения поставленных задач. Возможно, окажется так, что требуемых компетенций внутри компании не окажется, придется искать их на рынки (подрядчики, срочные трудовые договора и т.д.).
В любом случае, вам понадобятся ключевые участники команды:
Системный архитектор — будет отвечать за всю технологическую часть, чтобы результат проекта соответствовал требованиям и решал поставленную задачу. По сути за качество в проекте(соответствие заданным параметрам). Он должен декомпозировать глобальную задачу на составные части, определить численность и квалификацию необходимых для реализации ресурсов, и при их наборе поставить частные задачи каждому исполнителю.
ПМ — будет отвечать за всю организационную часть проекта (комментарии излишне, собственно об этом статья)
Специалисты по направлениям — например, проектировщики, аналитики. Кол-во и компетенции будут сильно зависеть от самого проекта.
3. Закрепление проектной команды
Если в компании "… вертикально ориентированной компании, где отделы, как правило, занимаются прикрыванием собственных спин..." пишите и протаскивайте через руководство приказ о старте проекта с назначением ответственных исполнителей (согласно ролевой модели), а также Устав проекта, где должны быть описаны ответственность и полномочия каждого исполнителя. Это поможет персонализировать ответственность, как за результат в целом, так и за отдельные его части между исполнителями.
ВАЖНО! В описанной вами ситуации, если вы не найдете заинтересованных союзников среди ТОП-менеджеров, взаимодействие с горизонтальными подразделениями превратится в позиционно-осадную борьбу. Результат будет низким, а его достижение долгим. Должен быть арбитр данного взаимодействия.
Основная проблема, как я понял, что культура проектной деятельности в компании отсутствует, либо находится в крайне зачаточном состоянии.
Если в вашей компании проекты — это не мероприятия носящие разовый характер, нужен диалог с руководством о создании проектного офиса и внедрения процессов проектной деятельности на системной уровне. В противном случае, каждый старт и реализация нового проекта будет «как в первый раз».
Желаю вам удачи! Надеюсь все получится!
А то, что вы описали — «грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам» — на мой взгляд, куда лучше, чем массовик-затейник без понимания специфики. Поэтому на специфику я и сделал упор. Работа с командой — огромная тема, которая тянет на отдельный пост.
Их получение не составляет большого труда, ведь рынок сейчас дает большое количество предложений по обучению руководителей проектов. Начинать нужно именно с этого.
Выбирая тренинговый центр, нужно понимать, что большинство из них предлагает лишь получение академических знаний, основанных на одной из наиболее популярных и часто применяемых методологий (PMI, PRINCE2, Agile, Scrum и пр.). Если вы начинающий ПМ, и ваша текущая должность подразумевает только администрирование проектов без принятия управленческих решений, этого обычно бывает достаточно, чтобы «втянуться» в профессию. На рынке есть и более продвинутые тренинги, которые помимо погружения в методологию, основываются на практикумах и тренировке необходимых навыков. Некоторые центры предлагают даже специальные образовательные проекты, построенные на использовании бизнес-симуляторов для формирования/развития компетенции проектного управления. С одним из таких центров мы дружим и обмениваемся опытом — STS-VostoK (www.stsvostok.ru) Тут, как говориться, на вкус и цвет…
Стоит помнить, что любая методология — это всего лишь набор инструментов и описание правил по их применению: «отвертка — чтобы закручивать шурупы», «молоток — чтобы забивать гвозди». И это только часть решаемой задачи по выращиванию профессионального ПМ'а. Чтобы управлять большими комплексными проектами, нужна практика, опыт и навыки, полученные в реальных проектах.
Умение взвешенно принимать самостоятельные управленческие решения и нести за них ответственность — основное отличие руководителя проекта от администратора.
Вообще для профессионального ПМ'а обучение это процесс непрерывный. Оно помогает не только получать новые знания, но и систематизировать/улучшать полученные ранее.
Его можно сравнить с профессиональным хирургом, который владеет множеством инструментов и техник, но в конкретном случает применяет именно ту, которая спасет пациенту жизнь).