Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.
Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:
Во-первых, люди, которые делают заказную разработку, как правило, являются ответственными профессионалами, испытывающими гордость за созданное решение. И поэтому, разработчики заказных систем готовы отвечать за результат своего труда и поддерживать свое решение и днем и ночью и в выходные и в праздники. Вытеснение таких разработчиков из продуктивной среды, замутнение коммуникаций формализованных процессами инцидент менеджмента и управления дефектами, приводит к тому, что мы не используем это благородное чувство ответственности. Это момент психологический.
Во-вторых, как известно, заказная разработка заключается в создании некоторого уникального продукта, созданного и используемого единожды. С другой стороны, ключевым фактором эффективности ИТ-процессов является экономия на объеме. Сервисная служба эффективна потому, что у разных пользователей возникают одинаковые проблемы, которые можно консолидировать, классифицировать и исправить. Т.е. выгода в том, что для большинства обращений мы уже заранее знаем, почему болит и как лечить. Вся эта логика не особо работает для заказной разработки, которая по определению уникальна. И проблемы в ней уникальны. И разобраться в этом может только тот, кто их создал.
Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется
1. Формализованное управление процессами создания ПО делается для того, чтобы получать повторяющиеся предсказуемые результаты (производство) вместо непредсказуемого героического труда отдельных выдающихся личностей;
2. Разработчикам, как и остальным людям, свойственно наступать на одни и те же грабли; грабли можно классифицировать и бороться с наступанием на них систематически (см. PSP = Personal Software Process), что сокращает время разработки и повышает качество ПО.
Сергей, я же не против процессов. Я о том, что процессы эксплуатации заказной разработки должны отличаться от процессов эксплуатации тиражируемых решений.
А какие процессы выбрать для разработки: адаптивные, предсказуемые или coding&fixing это пусть сами разработчики и решают. Я им даже советовать не берусь как правильно. Главное чтоб получалось быстро, дешево и качественно — это раз 🙂
А в чём, собственно, различие?
Разве для продуктов собственной разработки не нужно фиксировать дефекты и отслеживать, исправлены они или нет? Разработчики обидятся?
Да, знание причин возникающих инцидентов и способов их обхода — один из используемых в itSM принципов. И что делать, когда разработчики уже ушли, а продукт ещё эксплуатируется? А дефекты остались и инциденты периодически возникают? Ссылаться на уникальность продукта? Пользователям именно это надо?
Вопрос в том как внутренняя разработка делается, если это исключительно чей-то душевный порыв, энтузиазм, то скорее всего и поддержка будет на этом же энтузиазме. И надо быть готовым к тому, что по иссяканию этого энтузиазма у системы начнутся тяжёлые времена.
Если же к разработке подходят организованно, как к одному из регулярных видов деятельности, то можно формализовать и поддержку. Подготовить документацию, определить линии поддержки, наполнить базу типовых решений и т.д.
С другой стороны коробка она тоже уникальна в границах одной организации, и не всякая коробка содержит в себе базу решений накопленную в других организациях, а внедрение коробки тоже может осуществляться на энтузиазме и душевном порыве отдельных людей.
Так что отличия никакого, кроме ощущуения божественности со стороны внутреннего разработчика. 🙂
Павел, когда процессы поддержки не выстроены или же выстроены формально, действительно, пофиг что эксплуатировать. Когда мы хотим чтоб инциденты не только регистрировались, но и решались, нужен персонал, который сумел бы это сделать. И более-менее все равно, будет ли у него внутренне ощущение божествености или же комплекс неполноценности, главное, чтоб дефекты фиксились своевременно и не появлялось новых. И в этом эталонные модели процессов не помогут. Надо вникать в суть каждой системы