Комментарии

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

Хотелось бы по подробней узнать, зачем использовать паттерн MVC в DST Platform? Какие вообще преимущества и минусы MVC. Также было здорово понять MVC в реальной веб-разработке: как работает контроллер?

Хотелось бы по подробней узнать, зачем использовать паттерн MVC в DST Platform? Какие вообще преимущества и минусы MVC. Также было здорово понять MVC в реальной веб-разработке: как работает контроллер?

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

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

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

Я работаю в компании ICL, но мнение частное.

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

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

Я работаю в компании ICL, но мнение частное.

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

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

Я работаю в компании ICL, но мнение частное.

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

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

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

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

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

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

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

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

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

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

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

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

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

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

Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.

Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.

Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.

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

Вопрос, кто быстрее и дешевле решает эти критичные и не очень проблемы – собственные айтишники или аутсорсер?
И что делать с собственными айтишниками, если они не в состоянии решать проблемы достаточно быстро? Например, из-за перегруженности другими задачами в данный конкретный момент? В случае с аутсорсером — в договоре фиксируется время решения инцидентов в соответствии с критичностью (SLA). Так же фиксируются и штрафы, и если аутсорсер не выполняет обязательства, то штрафы покрывают возможные простои и потери бизнеса.

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

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

Вопрос, кто быстрее и дешевле решает эти критичные и не очень проблемы – собственные айтишники или аутсорсер?
И что делать с собственными айтишниками, если они не в состоянии решать проблемы достаточно быстро? Например, из-за перегруженности другими задачами в данный конкретный момент? В случае с аутсорсером — в договоре фиксируется время решения инцидентов в соответствии с критичностью (SLA). Так же фиксируются и штрафы, и если аутсорсер не выполняет обязательства, то штрафы покрывают возможные простои и потери бизнеса.

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