Просмотр исходного текста страницы «Мы видим тренды расширения сферы заказной разработки»

<blockquote>''[[:Категория:Беспальчук Игорь (Статьи)|Игорь Беспальчук]], наш руководитель отдела технологического развития, рассказал порталу [http://www.npsod.ru/page/about/ «Содействие»] о&nbsp;специфике и&nbsp;преимуществах заказной разработки, вариантах технической поддержки и&nbsp;дальнейшего развития разработанных систем, а&nbsp;также способах поддержания высокого уровня качества услуг компании. Подробнее читайте в&nbsp;интервью с Игорем [http://www.npsod.ru/blog/interviews/6040.html#cut «Мы видим тренды расширения сферы заказной разработки»].''</blockquote>

'''«Содействие»: Игорь, я хотел бы начать наш разговор с&nbsp;вопроса о&nbsp;преимуществах заказных работ по сравнению с&nbsp;разработками внутри компании. Когда вы встречаетесь с&nbsp;потенциальным клиентом, как вы описываете преимущества вашего подхода?'''

'''И. Беспальчук:''' Когда мы говорим о&nbsp;заказной разработке, мы отделяем её от того, что называется «коробочным» продуктом, и&nbsp;от того, что называется «in-house». Ваш вопрос про второе различение. Если вы имеете дело с&nbsp;большим предприятием, с&nbsp;большой информационной системой, с&nbsp;серьёзным тяжёлым проектом, то разработка бывает весьма непростым делом. Даже не столько сама разработка, сколько организация большого коллектива, управление им, выдерживание долгосрочных аспектов качества, выстраивание процессов, которые помогут вам это качество в&nbsp;дальнейшем поддержать. В&nbsp;in-house это всё тоже можно сделать. Есть много примеров, когда в&nbsp;in-house это сделано, и&nbsp;сделано так, что позавидовать можно. В&nbsp;больших компаниях с&nbsp;многолетней историей это вполне нормальный вариант. Но часто бывает, что компания хочет уделять больше внимания собственному бизнесу, его логике развития и&nbsp;собирать большой штат и&nbsp;заниматься выстраиванием системы производства нет возможностей. В&nbsp;этой ситуации есть смысл обратиться к&nbsp;профессионалам. Почему люди не делают всё сами? Потому что профессионалы сделают лучше. Здесь работает тот же принцип.

'''«Содействие»: Но всё же&nbsp;— что обходится заказчику дороже или дешевле?'''

'''И. Беспальчук:''' Сложно оценивать такого масштаба вещи, что совокупно дешевле или дороже. Всё, что вы делаете сами, особенно в&nbsp;моменте, окажется дешевле. Но непонятно, как можно сравнивать стоимость суммарной разработки в&nbsp;масштабе 10 лет, например.

'''«Содействие»: А&nbsp;такой критерий, как стоимость владения?'''

'''И. Беспальчук:''' Он есть, о&nbsp;нём много говорят, но покажите мне того, кто смог его хоть раз посчитать адекватно. А&nbsp;главное&nbsp;— с&nbsp;чем его сравнивать, если системы уникальны? Невозможно вернуться на 10 лет назад и&nbsp;попробовать решить ту же задачу другим способом, а&nbsp;потом сравнить. Если взять банковские системы, которые более стандартизованы, то по стоимости всегда выигрывает коробочный продукт благодаря эффекту масштаба. Он всегда будет дешевле. Но как только вы отходите от чего-то стандартного и&nbsp;вам нужно создать информационную систему под ваши процессы, под ваш особенный бизнес, вы сталкиваетесь с&nbsp;необходимостью разработать что-то новое, стоимость предсказать гораздо сложнее.

'''«Содействие»: Используете ли вы в&nbsp;ваших разработках в&nbsp;качестве основы собственные «коробочные» продукты? '''

'''И. Беспальчук:''' У нас есть опыт создания малотиражных информационных систем, например биллинговой системы для ЖКХ. Она внедрена в&nbsp;нескольких регионах Российской Федерации в&nbsp;достаточно крупных городах и&nbsp;служит информационным ядром для ЕИРКЦ. В&nbsp;некотором смысле ее можно считать коробочным продуктом.

И все же основная наша специализация&nbsp;— это именно заказная разработка. Но это не значит, что мы каждую систему делаем с&nbsp;нуля. Когда мы подходим к&nbsp;абсолютно новой для нас задаче, мы заинтересованы в&nbsp;том, чтобы сделать это наименьшими усилиями, поэтому стремимся наработки и&nbsp;технологии как на уровне проектных концепций, так и&nbsp;на уровне реализаций в&nbsp;виде кодов и&nbsp;библиотек накапливать и&nbsp;организовывать для дальнейшего использования.

'''«Содействие»: Несколько лет назад для больших компаний было очень популярно формализовывать свой накопленный опыт, чтобы новый персонал мог получать доступ к&nbsp;наработкам компании. На это тратились достаточно большие деньги. У вас существует формализованная база знаний?'''

'''И. Беспальчук:''' Это не просто база знаний. Я бы назвал это инженерным арсеналом. Знания&nbsp;— часть этого инженерного арсенала. Методики, коды. Мы стараемся всё это формализовать. Наиболее развитый опыт в&nbsp;этой сфере у нас касается методологии учёта. Изначально мы специализировались на учётных системах. Это не принципиальное стратегическое ограничение, но на текущий момент это наша основная специализация. За много лет мы не только накопили инженерно-технологический опыт, но и&nbsp;разработали методологию проектирования учётных систем. На эту тему у нас разработан внутренний учебный курс, и&nbsp;мы обязательно читаем его новым сотрудникам&nbsp;— аналитикам, ведущим разработчикам, архитекторам. Это и&nbsp;отличает профессионалов&nbsp;— багаж знаний и&nbsp;опыта, и&nbsp;— обязательно&nbsp;— коллекция собранных «граблей».

'''«Содействие»: Есть ли у вас предпочтения в&nbsp;выборе направлений разработок, сферы, в&nbsp;которых вы считаете себя лучшими?'''

'''И. Беспальчук:''' На текущий момент это проектирование, разработка и&nbsp;сопровождение на полном жизненном цикле учётно-аналитических систем. Учёт мы трактуем максимально широко&nbsp;— это и&nbsp;бухгалтерский, и&nbsp;финансовый, и&nbsp;управленческий учет, это может быть учет товародвижения и&nbsp;даже радиоактивных отходов. Тема учёта охватывает большой спектр отраслей&nbsp;— банки, ритейлеры, ЖКХ, госсектор…

'''«Содействие»: Кто в&nbsp;дальнейшем ведёт сопровождение&nbsp;— обученные люди заказчика или саппорт привязан к&nbsp;вам?'''

'''И. Беспальчук:''' Это зависит от того, как заказчик захочет выстроить наше взаимодействие. Госструктуры и&nbsp;банки хотят полностью отвечать за функционирование системы и&nbsp;быть способными её сопровождать самостоятельно. В&nbsp;этом случае производится обучение по сопровождению их специалистов, их горячей линии, первого эшелона, второго&nbsp;— и&nbsp;так далее. В&nbsp;любом случае мы всегда остаёмся рядом, пока длится наше партнёрство, а&nbsp;мы ориентируемся на долгосрочные отношения. В&nbsp;других ситуациях с&nbsp;другими клиентами нет таких ограничений, и&nbsp;третья линия техподдержки, которая работает достаточно регулярно,&nbsp;— на нашей стороне. Наши специалисты, участвовавшие в&nbsp;разработке этой системы или очень близко связанные с&nbsp;разработчиками, осуществляют ежедневный мониторинг и&nbsp;диагностику работы системы. В&nbsp;больших проектах, о&nbsp;которых мы говорим, и&nbsp;в случае нестандартных систем ее развитие не останавливается в&nbsp;момент сдачи. Система развивается очень интенсивно с&nbsp;момента ввода в&nbsp;эксплуатацию. После того как система разработана и&nbsp;введена в&nbsp;эксплуатацию, дальнейшее её развитие в&nbsp;течение долгих лет приводит к&nbsp;«нарастанию» функционала, которого становится в&nbsp;несколько раз больше, чем было вначале: может происходить декомпозиция систем, интеграция с&nbsp;другими системами на стороне заказчика и&nbsp;т. д. Система растёт и&nbsp;развивается, и&nbsp;мы её холим и&nbsp;лелеем с&nbsp;обеих сторон: со стороны заказчика и&nbsp;с нашей стороны. В&nbsp;этом&nbsp;— суть долгосрочного партнёрства на живом информационно-техническом объекте.

'''«Содействие»: А&nbsp;заказчик имеет право по условиям контракта самостоятельно развивать систему? Кому принадлежат коды?'''

'''И. Беспальчук:''' Мы всегда оставляем заказчику право и&nbsp;возможность самостоятельно развивать систему. Как правило, коды и&nbsp;вообще всё, что было разработано по требованию заказчика, принадлежит ему. Хотя могут быть и&nbsp;более сложные схемы лицензирования, если использовались существующие наработки. Важно изначально договориться с&nbsp;клиентом о&nbsp;вариантах дальнейшего развития системы. У нас есть опыт, когда заказчик самостоятельно разрабатывает фрагменты системы, через специальные «точки расширения» дорабатывает отчеты или что-то подобное. В&nbsp;таких случаях мы просто договариваемся об интерфейсах взаимодействия. Заказчик знает, что у него есть определённые механизмы, и&nbsp;он может самостоятельно дорабатывать систему. Но он не может в&nbsp;любой момент влезть в&nbsp;любое место системы и&nbsp;что-то там подправить. Это гораздо сложнее организовать, и&nbsp;в нашей практике пока такого не было. Но кто знает, с&nbsp;чем мы столкнёмся в&nbsp;следующий раз и&nbsp;как придётся выстраивать совместную работу. Мы стараемся действовать гибко, ориентируясь на ситуацию заказчика, которая всегда уникальна.

'''«Содействие»: Резюмируя сказанное вами: заказчик не является привязанным к&nbsp;вам, поручив вам разработку и&nbsp;получив готовый продукт. В&nbsp;принципе, он может самостоятельно в&nbsp;дальнейшем развивать созданную систему.'''

'''И. Беспальчук:''' У нас был опыт, когда мы передавали клиентам технологии разработки и&nbsp;прекращали партнёрство, а&nbsp;их системы продолжали развиваться. Так было, например, в&nbsp;нескольких банках, где клиенты полностью забирали себе сопровождение и&nbsp;развитие АБС, и&nbsp;с&nbsp;системами для ЖКХ, когда организовывалось предприятие ЕИРКЦ и&nbsp;технический центр рядом с&nbsp;ним. Мы организовывали этот технический центр, обучали людей, передавали туда технологии, по которым была построена система, и, если наше партнёрство прекращалось, технический центр продолжал развитие этой системы.

'''«Содействие»: Любой программный продукт имеет определённый жизненный цикл. Как это происходит в&nbsp;вашей практике?'''

'''И. Беспальчук:''' Есть аналитик или группа аналитиков, которые проводят исследование, пишется анализ клиентской ситуации, задачи информационного IT-ландшафта, с&nbsp;которым предстоит интеграция, или замена существующих систем. Производится концептуальное проектирование, и&nbsp;мы предпочитаем, чтобы оно осуществлялось совместно с&nbsp;представителями заказчика. Со стороны заказчика обычно есть люди, которые компетентны в&nbsp;этих вопросах,&nbsp;— те или иные представители IT-службы или управленцы, хорошо понимающие задачу, и&nbsp;они могут участвовать в&nbsp;её структуризации, или, как минимум, в&nbsp;верификации этого концептуального проекта. После этого формируется проектная команда. Обозначается некая веха, нередко&nbsp;— в&nbsp;долгосрочной перспективе. Мы демонстрируем промежуточные результаты, идёт параллельное детализированное проектирование отдельных фрагментов системы, проводятся интервью с&nbsp;соответствующими специалистами и&nbsp;руководителями и&nbsp;идёт разработка того, что уже проанализировано, с&nbsp;последующей демонстрацией компетентным представителям заказчика. Уже на этом этапе, когда эксплуатации продукта зачастую ещё нет, мы стараемся плотно взаимодействовать с&nbsp;заказчиком. После этого происходит фаза внедрения. После внедрения начинается эксплуатация, связанная с&nbsp;поддержкой и&nbsp;диагностикой системы. Растут объёмы данных, растут масштабы использования, и&nbsp;вместе с&nbsp;ними идет процесс изменения потребностей заказчика. Мы говорим о&nbsp;динамично развивающемся бизнесе, о&nbsp;лидерах рынка, о&nbsp;каких-то нестандартных процессах. Это отличается от ситуации, когда изменения вызваны регламентированными государственными положениями и&nbsp;постановлениями: там есть предсказуемость. Хотя нестабильность принимает другую форму: принято новое постановление&nbsp;— и&nbsp;срочно нужно вносить корректировки к&nbsp;определённой дате. В&nbsp;случае же, когда мы работаем с&nbsp;коммерческими предприятиями и&nbsp;информационными системами, обслуживающими какой-то бизнес, мы сталкиваемся с&nbsp;другой ситуацией. Там всегда кипит мысль предпринимателя, он каждый день придумывает что-то новое, и&nbsp;на это необходимо реагировать.

'''«Содействие»: Правильно ли я понимаю, что тот период, который характерен для коробочного продукта, когда продукт начинает устаревать, у вас либо растягивается, либо вообще не наступает?'''

'''И. Беспальчук:''' Он растягивается. Он всё же наступает, но сильно растягивается по времени. Устаревают концепции, заложенные очень глубоко в&nbsp;продукт. Устаревает технология. Иногда с&nbsp;этим удаётся справиться более-менее плавно, а&nbsp;бывает так, что систему приходится переделывать целиком. Случается также, что бизнес меняется самым радикальным образом. В&nbsp;таком случае старая система максимально адаптируется к&nbsp;новым условиям и&nbsp;проводится реинжиниринг.

'''«Содействие»: А&nbsp;как у вас решается вопрос с&nbsp;качеством кода? Как обстоят дела с&nbsp;соответствием каким-то общим и&nbsp;внутренним стандартам?'''

'''И. Беспальчук:''' Когда мы говорим о&nbsp;заказной разработке, нужно рассматривать не только качество кода, но и&nbsp;качество услуги в&nbsp;целом. Качество кода может быть хорошим, а&nbsp;остальные аспекты услуги могут не отвечать поставленным заказчиком задачам. У нас есть внутренние стандарты качества и&nbsp;процессы, направленные на его обеспечение,&nbsp;— Code Review, автоматизированное и&nbsp;ручное тестирования и&nbsp;т. д. Если же говорить о&nbsp;стандартах&nbsp;— мы их знаем и&nbsp;стараемся соответствовать тем требованиям, которые предписываются признанными методологиями разработки ПО. Хотя мы никогда не проводили официальных оценок по методикам CMMI, ключевым требованиям третьего уровня мы соответствуем. Говоря о&nbsp;качестве, сложно опираться только на стандарты. Качество&nbsp;— всегда ответ на представления потребителя о&nbsp;качестве, а&nbsp;эти представления нестандартны.

'''«Содействие»: Сталкивались ли вы с&nbsp;сопротивлением персонала заказчика во время внедрения ваших систем?'''

'''И. Беспальчук:''' Серьёзных проблем с&nbsp;этим не припоминаю. Работая с&nbsp;позиции заказной разработки, мы находимся на шаг дальше от конечного пользователя, чем в&nbsp;случае с&nbsp;in-house-разработкой, или в&nbsp;сравнении с&nbsp;представителями заказчика, непосредственно работающими с&nbsp;пользователями. Возможно, они как-то экранируют негативную реакцию конечного пользователя и&nbsp;преодолевают его сопротивление. Нам в&nbsp;любом случае ценна обратная связь, и&nbsp;у нас есть практика: каждый член проектной команды должен побывать у непосредственного заказчика и&nbsp;посмотреть на тех людей, которые будут пользоваться нашим программным продуктом. Порой это оказывает удивительное воздействие на разработчиков и&nbsp;на их отношение к&nbsp;работе.

'''«Содействие»: Любая учётная система делает некие процессы прозрачными, но иногда люди не заинтересованы в&nbsp;прозрачности, поскольку учёт может показать объём их персонального вклада в&nbsp;процессы. Некоторые системы не могли быть внедрены только из-за человеческого фактора.'''

'''И. Беспальчук:''' Обратную связь мы ценим, но ощущения сопротивления у нас не было. Если наш заказчик понимает, что проблема&nbsp;— исключительно в&nbsp;эмоциональной сфере, то эта проблема выпадает из сферы нашего с&nbsp;ним партнёрства.

'''«Содействие»: Какие тренды вы наблюдаете в&nbsp;России? Как обстоят дела с&nbsp;заказными разработками?'''

'''И. Беспальчук:''' Объём заказных разработок не будет сокращаться. Он может лишь расти, потому что объёмы автоматизации различных отраслей далеко не исчерпаны, и&nbsp;применение коробочных продуктов возможно лишь в&nbsp;случае, когда деятельность сильно стандартизована, а&nbsp;это не может произойти быстро. Мы видим тренды расширения сферы заказной разработки.

[[Категория:Беспальчук Игорь (Статьи)]]
[[Категория:Содействие_(Публикации)]]
[[Категория:2013 год (Статьи)]]
{{replicate-from-custiswiki-to-lib}}