http://lib.custis.ru/index.php?title=%D0%97%D0%B0%D0%BA%D0%B0%D0%B7%D0%BD%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BA%D0%B0%D0%BA_%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B0&feed=atom&action=historyЗаказная разработка как услуга - История изменений2024-03-29T07:17:15ZИстория изменений этой страницы в викиMediaWiki 1.26.4http://lib.custis.ru/index.php?title=%D0%97%D0%B0%D0%BA%D0%B0%D0%B7%D0%BD%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BA%D0%B0%D0%BA_%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B0&diff=42299&oldid=prevGalinaTsaturyan в 15:23, 26 декабря 20122012-12-26T15:23:41Z<p></p>
<p><b>Новая страница</b></p><div><blockquote><br />
[[:Категория:Беспальчук Игорь (Статьи)|Игорь Беспальчук]], руководитель отдела технологического развития, в [http://www.pcweek.ru/themes/detail.php?ID=144878 интервью] для PC Week/RE рассказал об особенностях средств и методов заказной разработки, о сервисном подходе и новом уровне аутсорсинга ИТ-услуг.<br />
</blockquote><br />
<br />
'''PC Week:''' Какие средства и методологии разработки отличают создание заказной прикладной системы от тиражируемой?<br />
<br />
'''Игорь Беспальчук:''' Если взглянуть на современный процесс разработки, то он эволюционирует, смещая уровень сервиса ближе к потребителю. Поставщик ПО становится все ближе к заказчику и гораздо внимательнее смотрит на то, что тому нужно. Уже недостаточно просто продать программный продукт или разработать систему по спецификации. Нужно, глубоко понимая бизнес заказчика и его динамично меняющиеся потребности, быть готовыми к тому, чтобы действовать оперативно (а иногда и проактивно), при необходимости внося изменения как в ИС, так и в деятельность организации.<br />
<br />
В низкоуровневом проектировании, разработке и тестировании для нас нет каких-либо заметных отличий от тиражной разработки. Мы используем вполне обычные и распространенные IDE-среды (Microsoft Visual Studio для систем на базе Microsoft .NET и IntelliJ IDEA для Java), системы контроля версий (Subversion), баг-трекеры (Bugzilla). С другой стороны, иногда сотрудники организации-заказчика имеют непосредственный доступ к нашему трекеру задач, в котором осуществляется и фиксируется довольно интенсивный поток общения на проектные темы. Это позволяет выстроить более оперативное и прозрачное взаимодействие с заказчиком.<br />
<br />
'''PC Week: '''Достаточно ли заказному разработчику и в частности вашей компании имеющихся на рынке коммерческих инструментальных средств или вам приходится создавать для себя и собственные инструменты?<br />
<br />
'''И. Б.:''' Процесс разработки или методология разработки — это тоже инструменты, с помощью которых вы добиваетесь результата. В любой момент времени вы можете поменять свой инструмент и взять другой, более совершенный, более тонкий или более эффективный. Это одинаково справедливо и для заказной, и для тиражной разработки. Поэтому, на наш взгляд, разница между ними в большей степени не в методологиях и инструментах, а в целях и результатах.<br />
<br />
На этапе подготовки требований к новой системе или для доработки существующей важно эффективно воспринять замысел заказчика и сформировать понятную всем участникам концепцию решения. С нашей стороны в совещаниях и интервью с ключевыми представителями заказчика участвуют несколько экспертов — по архитектуре, в предметной области, а также руководитель проекта. Наиболее эффективными инструментами тут являются маркерная доска и диктофон.<br />
<br />
Результаты совещаний фиксируются в форме протоколов и эскизов решений. Чтобы не возникало проблемы консолидации множества исправлений, мы используем централизованную систему работы с документами MediaWiki. Для каждого заказчика делается отдельная инсталляция вики-системы, что обеспечивает необходимый уровень конфиденциальности. Вся проектная информация структурируется и провязывается гиперссылками и системой категорий. Очень помогает также полнотекстовый поиск.<br />
<br />
Для различного рода схем и диаграмм (а это один из самых ценных артефактов при проектировании) используются или фотографии маркерной доски, или Microsoft Visio. Наша практика показывает, что на этом этапе важнее гибкость изобразительного средства, и хотя мы часто рисуем диаграммы UML, в любой момент сохраняется возможность отойти от стандартной нотации и ввести свою, более подходящую и творческую. Например, для проектирования учетных аспектов наших систем мы разработали собственную нотацию — диаграммы учета. Специализированные инструменты, ориентированные на строгое соблюдение нотации UML, у нас не приживаются, поэтому хорошей альтернативы Microsoft Visio мы пока не видим, хотя регулярно изучаем аналоги.<br />
<br />
Конечно, как и у любого другого производителя ПО, за многие годы работы у нас накопилось большое количество библиотек, паттернов и инструментов, специфичных для нашей области. Основным таким активом для наших задач является Учетная Машина — специализированная платформа для разработки учетно-аналитических систем. Эти средства уникальны, но их вряд ли можно отнести к специфике именно заказной разработки.<br />
<br />
Специфические отличия иного рода возникают на более поздних стадиях работы. Тесно взаимодействуя с заказчиками в решении их бизнес-задач, мы нередко берем на себя часть деятельности по внедрению, сопровождению и администрированию разработанных нами программных продуктов — в духе популярной сегодня концепции DevOps. При этом регулярно приходится заниматься масштабными инсталляциями или обновлениями ПО и БД (десятки и сотни серверов и рабочих мест). Выполнять эту работу вручную невозможно, поэтому мы разработали собственный инструмент CUSTIS Patcher, позволяющий централизованно управлять накатом обновлений с контролем ошибок и запретом на работу в некорректных состояниях. Часто этим инструментом пользуются и специалисты заказчика, устанавливая очередные версии нашего ПО самостоятельно. Полноценных аналогов этого инструмента на рынке мы не встречали.<br />
<br />
'''PC Week: '''В последнее время в ИТ все большую популярность приобретает сервисный подход. Находит ли он применение в разработке ПО, в частности заказного?<br />
<br />
'''И. Б.:''' По сути своей заказная разработка с самого начала близка к сервисному подходу. При взаимодействии с заказчиком один на один гораздо естественнее не ограничиваться только разработкой ПО, а активно участвовать в более близких к бизнесу заказчика процессах внедрения, сопровождения и администрирования. Но и в этом случае встает вопрос о расширении уровня сервиса с тем, чтобы каждому клиенту предоставить более качественную услугу.<br />
<br />
Для одного из заказчиков было организовано ''постоянное ''присутствие нашего специалиста на его площадке. Такой подход позволяет в максимально короткие сроки решать задачи сопровождения — проводить консультации пользователей, диагностировать и решать проблемы, оперативно производить настройку ПО. Конечно, это стоит недешево, но клиент готов платить за хороший сервис, когда понимает, насколько он упрощает себе жизнь.<br />
<br />
Крупные информационные системы рано или поздно под давлением возрастающих масштабов бизнеса или в силу необходимости обновления технологий начинают нуждаться в модернизации и перепроектировании. Если этого не делать, то со временем заказчик с удивлением обнаруживает, что система перестает справляться со своими задачами, а ее сопровождение дорожает. Обычно к моменту, когда он готов сформулировать новый заказ, всё уже слишком запущено, систему надо переделывать целиком, а это выливается в очень долгосрочный и дорогостоящий проект, с которым через пять лет повторяется та же история.<br />
<br />
Решение проблемы мы видим в расширении сервиса. От просто разработки по заказу мы переходим к долгосрочному управлению созданным нами ИТ-активом предприятия. Оно включает мониторинг активности и нагрузки, анализ устойчивости и запасов производительности, своевременное предложение по модернизации и масштабированию системы. Мы берем на себя дополнительную ответственность, но и от заказчика это требует большего доверия к нам как к партнеру. Для выполнения таких обязательств мы, к примеру, должны быть лучше осведомлены о стратегических планах компании-заказчика.<br />
<br />
'''PC Week: '''Можно ли называть это передачей разработки ПО на аутсорсинг?<br />
<br />
'''И. Б.:''' По сути всё, о чем мы говорим, вполне можно назвать аутсорсингом. Но нужно понимать, что большинство проблем и неудач с аутсорсингом связаны именно с неправильно проведенными границами, неверно выстроенными отношениями, низким уровнем ответственности и доверия между заказчиком и подрядчиком. Попытка отдавать на аутсорсинг «только кодирование» приводит к негативному эффекту: контракт включает в себя детально прописанные требования, и в результате заказчик получает то, что было зафиксировано в спецификации, а не то, что ему действительно нужно. Если нашу модель заказной разработки рассматривать как аутсорсинг, то это «аутсорсинг с человеческим лицом».<br />
<br />
'''PC Week: '''Каковы более отдаленные перспективы развития такого подхода?<br />
<br />
'''И. Б.:''' Скорее всего продолжением этих тенденций в будущем станет включение в состав сервиса вопросов аппаратного обеспечения. Но, как и в случае простого облачного сервиса хранения, крупный бизнес пока не готов отдавать контроль над своими данными сторонним подрядчикам. На взращивание нового уровня ответственности и доверия нужно время.<br />
<br />
Акцент на сервисном подходе и удовлетворении нужд заказчика постепенно сдвигает границы контрактов ближе к его бизнес-задачам и отдаляет от кажущейся более четкой и очевидной, но на деле очень неустойчивой парадигмы «требования — код». В экономике есть понятие «неоклассического контракта», описывающего долгосрочный договор о сотрудничестве в условиях неопределенности. В неоклассическом контракте стороны активно взаимодействуют друг с другом, причем личные отношения играют важную роль. Именно такой тип отношений исповедует философия Agile, которую мы понимаем как готовность сконцентрироваться на том, что нужно заказчику.<br />
<br />
<br />
[[Категория:PCWeek (Публикации)]]<br />
[[Категория:Беспальчук Игорь (Статьи)]]<br />
[[Категория:2012 год (Статьи)]]<br />
<br />
{{replicate-from-custiswiki-to-lib}}</div>GalinaTsaturyan