Как стать автором
Обновить

Как решить извечный конфликт между разработкой и эксплуатацией?

Время на прочтение7 мин
Количество просмотров7.3K
Всего голосов 10: ↑7 и ↓3+4
Комментарии13

Комментарии 13

Тема конфликта пользователя и разработчика резво свернула в рекламу. Доступность — пожалуй, самая незначительная причина отказа пользователей работать с навязываемой ИС. Ваша ServiceNow тут не поможет никак. Решайте насущные проблемы пользователей, делайте их жизнь легче, и «продавливать» у начальства ничего не придется.
НЛО прилетело и опубликовало эту надпись здесь
olku, Да, конфликт пользователя и разработчика существует, но мы говорим не о нем. Мы говорим о другом конфликте, между программистом и администратором системы, которые работают вместе с пользователем в одной компании. Этот конфликт выгдялит так: программист написал код, который решает насущную проблему пользователя, а админ говорит: «У вас что ни новый релиз, так куча глюков, проблема мелкая, пусть пока потерпят со старой версией». Статья о том, что мы такой конфликт предлагаем решать через «бюджет простоев», а в качестве системы автоматизации предлагаем использовать ServiceNow и показываем, как система в этом контексте работает.
Конфликт между эксплуатацией и разработкой существует, и дабе такая компания как Google открыто признает, что там такая проблема есть.
Спасибо за ответ. То есть, статья про ServiceNow, который с помощью метрики «простой» пытается решить проблему отсутствия управления качеством ИС?
olku, спасибо, что читаете нас! Мы говорим об одной из идей в подходе к управлению сервисами Site Reliability Engineering (SRE) — «бюджете простоев». Для реализации этой идеи нужны система мониторинга и ITSM-система, в качестве которой мы рассматриваем ServiceNow.
«У вас что ни новый релиз, так куча глюков, проблема мелкая, пусть пока потерпят со старой версией»

Эмм… А версии что тестировать не надо прежде чем накатывать на боевые системы?
Одна версия — стоит, следующая — тестируется и дебажится, а новый функционал добавляется в ещё более следующую.

Спасибо за статью! У нас как раз идет вечная война между разработкой и эксплуатацией, а мы — тестирование, как миротворцы, подносим всем успокоительное. Мысль про «бюджет простоев» попробуем донести до руководства «ведущих боевые действия» сторон.
Nomad_gdv, спасибо! Нужны будут дополнительные доводы — обращайтесь! :)
НЛО прилетело и опубликовало эту надпись здесь
Как вы оцените отток клиентов при простое системы электронного документооборота внутри компании?
НЛО прилетело и опубликовало эту надпись здесь
система внутренняя. Например кадровый документооборот. Или бухгалтерский. Оно же вообще в лояльность клиентов не конвертится.
Если проблема вам знакома и интересна, далее в статье приведён практический способ её решения

Есть куда более простой и эффективный путь решения — заставить поддерживать ПО ту же команду что и делает доработки, раз уж они в одной компании.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий