Сколько должен получать IT-аутсорс специалист за час работы?

среднегодовое берется 168

 

6.8.1. Указанного тобой госта. Сопровождаемость определяется до разработки.

 

Caps,
не путай спровождение и сопровождаемость.
также можешь прочесть пункт 7.2

 

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

 

Caps,
можно сказать, что нет
сопровождаемость - это характеристики
сопровождение - это процесс

 

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

 

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

Да эксплуатационщики должны участвовать в проекте разработки/внедрения, но участие их выглядит как ты уверен знаешь в виде экспоненты. Т.е. на начальном этапе они должны всего лишь заявить что нам нужна масштабируемость, нужно выполнить capacity planning на такую нагрузку и т.п. И тихо отойти в сторонку. Потом чуть больше, ну и т.д. Но им нафик не нужна методология разработки. Им нужна методология эксплуатации, где будет описана стыковка с нужными моментами. Как и есть MSF/MOF. Две методологии, а не одна. MOF можно использовать даже если разработка была не используя MSF и наоборот.

 

А я их и не сопровождаю. Я их _поддерживаю_. Это две очень большие разницы.

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

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

я (впрочем я не одинок) не люблю MSF/MOF. за что - это отдельная тема

 

ОФФ:Так и хочется сказать про не умение готовить Это шютка, без обид ок.
А вообще за что его любить/не любить. И чем так уж принципиально отличается MOF от того же ITIL.

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

Вообще я недаром употребляю слово эксплуатация. Бизнесу в общем то по фигу имеете вы код, меняете вы его или нет.
Вы мне вот в ITIL'е приведите соответствующие термины (сопровождению и поддержке). Что-то не припоминаю. А ведь все методологии они оттуда. Местных что-то не видно.

добавлено через 8 минут

Тут вообще непонятно. Для 1. делается карта зависимости сервисов OLA и т.д. Причем тут методологии внедрения?
Про 2. Я не знаю что такое требования сопровождения. Есть только требования заказчика которые формализуются с помощью SLA, естественно в диалоге с эксплуатирующей службой. Или мы про разное.

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

добавлено через 10 минут

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

 

Смотря что понимать под словом "принципиально". Будем считать что это сугубо мои кулинарные пристрастия.

Вобщем-то нет. Разные тарифы будут на эксплуатацию.

Так с этого и начинали. Что там есть SD, а Chg касается только по большому счету изменения инфраструктуры. С некоей натяжкой его можно затащить под сопровождение, но опять же с некоей натяжкой. Управление релизами тоже касается этого дела, и тоже поверхностно. Детально - нет там понятия "сопровождение". В том виде, что есть в госте/исо.

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

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

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

Да.

 

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