Size: a a a

Архитектура ИТ-решений

2021 May 05

VR

V R in Архитектура ИТ-решений
По-разному получается - зависит от очень разных вещей. Но интерес, конечно, получить клиента на долгую.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Так низкое качество этому скорее способствует )
источник

VR

V R in Архитектура ИТ-решений
ну, в компаниях занимающимся аутсорсом есть команды разного уровня и умных людей тоже там хватает - вопрос кто конкретно попадется :)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, тут дело не в умных (умные скорее сделают нечистый код), а в отсутствии хоть каких-то причин делать в аутсорсе хороший проект  )
источник

VR

V R in Архитектура ИТ-решений
субъективно :)
- в любых компаниях в большинстве случаев employee это наемный работник  за фиксированные деньги - у него причин делать хороший проект нет нигде (в общем). так что аутсорс тут ни при чем.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Хороший проект делают от лени что бы не тратиться на сопровождение, пассивный доход обеспечить
источник

VR

V R in Архитектура ИТ-решений
поэтому и цель на аутсорсе чтобы получить на поддержку, а дальше делать видимость работы - получаем что на аутсорсе это очень даже хорошо :)
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Ну капитан очевидность одобряет)))
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, вот в продуктовых компаниях обычно вовлеченность сотрудников заметно выше, нежели в аутсорсе (где тоже она иногда бывает, но реже).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Неа. Нужно еще, что бы никуда с поддержки не убежал, а для этого проект должен быть плохим (жуткое API, избыточно сложная архитектура, отсутствие документации, нестандартный стек и игнорирование стандартов)
источник

VR

V R in Архитектура ИТ-решений
пофиг. решение о том кто будет саппортить принимается бизнесом из цены и им нет никакого дела до API/архитектур/и т.д.
источник

VI

Vladimir Ivanov in Архитектура ИТ-решений
это очень странный тезис. Ровно по этим же причинам бизнес может хотеть поменять подрядчика
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Угу. Но потом регулярно рассматривается вариант "а давайте поддерживать сами или другим аутсорсером, а то что-то дорого". И тут есть два варианта: новый аутсорсер смотрит, говорит "фигня вопрос, все понятно" и берет контракт.
Или смотрит, говорит "нафиг-нафиг за такие деньги" и не берет контракт.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Если в договоре нет требований к качеству (а их обычно нет за пределами числа багов и, если повезет, НФТ), то поменять подрядчика на разработку  - не получается. А вот поддержка - уже отдельный вопрос.
источник

VR

V R in Архитектура ИТ-решений
не думаю что это так работает :) - никто ничего не смотрит. бизнес запрашивает X гребцов у аутсоурсинговой компании и если устраивает цена забирает их на саппорт. Перебирать на аутсорсе проекты.... - хм :) такое себе развлечение
источник

VI

Vladimir Ivanov in Архитектура ИТ-решений
с аутсорсом 2 договора - Master Service Agreement и Statement of Work
источник

VI

Vladimir Ivanov in Архитектура ИТ-решений
во втором легко существуют требования по качеству
источник

VI

Vladimir Ivanov in Архитектура ИТ-решений
а в первом - процедура растрожения контракта, если желание заказачика не удовлетворяются
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Бывает, бывает. Обычно стараются всю систему поменять, но иногда и только поддержку - когда та или не успевает или ценник выставляет большой. Я такое видел.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А в каком они виде, кстати, описываются?
источник