Заказная разработка vs. коробочные решения

Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.

Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:

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

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

Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется

Заказная разработка vs. коробочные решения: 5 комментариев

  1. 1. Формализованное управление процессами создания ПО делается для того, чтобы получать повторяющиеся предсказуемые результаты (производство) вместо непредсказуемого героического труда отдельных выдающихся личностей;
    2. Разработчикам, как и остальным людям, свойственно наступать на одни и те же грабли; грабли можно классифицировать и бороться с наступанием на них систематически (см. PSP = Personal Software Process), что сокращает время разработки и повышает качество ПО.

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

      А какие процессы выбрать для разработки: адаптивные, предсказуемые или coding&fixing это пусть сами разработчики и решают. Я им даже советовать не берусь как правильно. Главное чтоб получалось быстро, дешево и качественно – это раз 🙂

      1. А в чём, собственно, различие?
        Разве для продуктов собственной разработки не нужно фиксировать дефекты и отслеживать, исправлены они или нет? Разработчики обидятся?
        Да, знание причин возникающих инцидентов и способов их обхода – один из используемых в itSM принципов. И что делать, когда разработчики уже ушли, а продукт ещё эксплуатируется? А дефекты остались и инциденты периодически возникают? Ссылаться на уникальность продукта? Пользователям именно это надо?

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

    Так что отличия никакого, кроме ощущуения божественности со стороны внутреннего разработчика. 🙂

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

Добавить комментарий для Максим Смирнов Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *