Давно прошли те времена, когда понятия ЭВМ и программисты были в какой-то степени синонимами, или, точнее, “близнецами-братьями”. Когда программисты олицетворяли все сообщество вычислительных пользователей: сами писали техническое задание, сами разрабатывали ПО, сами его эксплуатировали. С тех пор минуло уже более двух десятилетий в нашей стране, а на Западе — и того больше. ЭВМ стали называться компьютерами, программисты — разработчиками, а сами они составляют мизерную часть пользовательского сообщества. Всего каких-то одиннадцать миллионов профессиональных разработчиков ПО в 2012 году (по теоретическим оценкам IDC) среди как минимум двух-трёх миллиардов ИТ-пользователей на планете.
И тем не менее нет нужды пояснять: мал золотник, да дорог! Ведь все достижения ИТ становятся доступны пользователям только через ПО, которое создают именно разработчики. И значимость той или иной страны в мировом ИТ-рейтинге во многом определяется именно числом программистов (по оценкам той же IDC, лидируют тут США с 3,1 млн., Россия находится на шестом месте в мире с 300 тыс., занимая при этом первую позицию в Европе).
Что касается освещенности темы средств разработки ПО в целом, которая в середине 1990-х занимала чуть ли не 50% объема ИТ-СМИ, то в последнее десятилетие явно ушла на задний план внимания широкой ИТ-общественности, уступив первые места вопросам внедрения и эксплуатации ИТ. Однако и тут снижение “публичной освещаемости” совсем не означает, что проблемы создания ПО стали менее актуальными, чем раньше. Просто эти вопросы сместились в профессиональную среду.
Однако сейчас тема разработки ПО опять выходит из тени в зону повышенного внимания всего ИТ-рынка. Причина понятна: мир ИТ переживает серьезные качественные изменения, связанные с переходом в “облачное состояние”. Это сопровождается существенной коррекцией подходов к разработке ПО, преобразованиями на платформенном уровне, появлением качественно новых платформ и обострением конкуренции между различными платформами. Между поставщиками платформ опять началась активная борьба за независимых разработчиков как главный фактор успеха своей продукции.
Еще один важный аспект — смешение видов и жанров разработки ПО (клиентские, серверные и Web-приложения, базы данных, Web-дизайн), ранее существовавших в значительной степени независимо друг от друга. Отдельно нужно сказать и о доминировании в ИТ-отрасли комплексного подхода к решению задач разработки и эксплуатации ПО. Еще в конце 1990-х годов вопросы разработки ПО на рынке стали перерастать в проблематику управления жизненным циклом приложений (ALM).
Что сегодня представляет собой рынок средств разработки и их использования? Какие тенденции тут наблюдаются и что можно ожидать в будущем? Глубокие ответы на эти вопросы вполне легко потянуть на серьезную исследовательскую работу. И все же мы решили начать поиск этих ответов, обратившись к ряду экспертов российской ИТ-отрасли.
Рынок средств разработки сегодня
Даже просто сформулировать, что представляет собой рынок средств разработки, оказалось (впрочем, как и можно было ожидать) почти нереальной задачей. Огромный спектр инструментария и платформ разнообразного назначения. Традиционные параметры оценок рынка в денежном выражении тут изначально не работают: огромная доля инструментов не продаются за деньги. Обратите внимание — не являются бесплатными (таких тоже много), а не продаются, например, поставляются в составе комплексных платформ. Именно поэтому аналитики для оценки размеров рынка средств разработки обычно используют “штучные” показатели, чаще всего — число их пользователей, разработчиков. В мире такие исследования проводятся (хотя, кажется, все меньше и меньше), в России этот вопрос не изучался фактически никогда.
На качественном уровне можно — хотя и довольно условно — выделить такие группы разработчиков по типу создаваемого ПО: серверное, клиентское, мобильное и Web. Еще одна важная градация — по уровню отчуждаемости ПО: программные продукты (независимые софтверные вендоры — ISV), заказные разработки (то, что раньше назывались “офшорники”) и внутрифирменные. Как эти группы соотносятся между собой, сказать сложно, но доля in-house, возможно, находится на уровне 30—50%. Еще лет двадцать назад была весьма большая группа “программистов для себя” — непрофессиональных программистов, пишущих код для собственного потребления (например, научные расчеты). Сейчас их число, кажется, снизилось до малозаметной величины.
В старые времена ПО обычно делилось на две части: системное и прикладное, и была соответствующая градация среди программистов. Можно предположить, что не менее 95% российских программистов занимаются созданием прикладных программ.
Еще одно важное деление: средства разработки общего назначения и специализированное ПО. Для этой характеристики можно еще использовать другой аспект — низко- и высокоуровневые средства. Сейчас, наверное, не стоит развивать эту во многом спорную тему о категоризации средств разработки, но в качестве иллюстрации отметим, что есть системы разработки вроде Java или .NET, а есть такая, как “1С:Предприятие”.
В целом можно сказать одно: структурировать самом понятие “рынок средств разработки” очень сложно, поэтому давайте узнаем мнения экспертов с качественными оценками ситуации. Сразу отметим, что в одном они единодушны: мы сейчас переживаем интересный период перемен.
Руководитель направления стратегического развития бизнеса Intel в России и СНГ Вадим Сухомлинов представил именно системное видение ситуации в отрасли (приятно отметить некоторое совпадение наших подходов к структуризации темы): “Рынок средств разработки ПО очень обширен и представляет собой совокупность из различных групп решений. Можно попытаться классифицировать их по типу платформ, для которого предназначены разрабатываемые приложения — прикладные приложения под “классические” десктопы, ноутбуки, серверы независимо от типа ОС. Другой сегмент — веб-приложения, сюда можно включить средства по разработке и отладке на языках Ruby, PHP, Python, HTML5 и другие. Средства для разработки мобильных приложений под ОС типа IOS, Android, Windows 8 и т. д. Ну и платформенные языки — вроде “1С”, SAP и т. п. Для каждого сегмента характерны свои особенности. В первом случае (“классика”) довольно распространены как open-source-решения (GCC, Eclipse и др.), так и коммерческие пакеты (MS Visual Studio, Intel Software Development Tools, IBM COBOL и многие другие). Особенность этого сегмента в том, что сейчас в связи с ростом популярности мобильных и веб-приложений количество задействованных там разработчиков практически не растет. В то же время наблюдается рост числа приложений для веба (SaaS, веб-сайты, облачные решения) и для мобильных платформ. Заметно растёт интерес к средствам автоматизированного тестирования приложений, проверки корректности. Это связано с сокращением сроков разработки под требования рынка и соответственным фокусом на разработку функционала, определяющего конкурентные преимущества вместе с балансом по качеству”.
Руководитель отдела технологического развития компании CUSTIS Игорь Беспальчук отметил качественные изменения на рынке, указав, что за последние годы появилось несколько новых ниш. При этом развитие процесса определяется тремя основными факторами: стремительное развитие коммуникаций, повышение мобильности и персонализации вычислительных устройств и общий сдвиг к сервисной парадигме. В образовавшееся рыночное пространство хлынули все от мала до велика, и это движение порождает соответствующий информационный шум — кажется, что вне облаков и мобильных устройств жизни нет. Но на самом деле это конечно же не совсем так, просто в этой области сейчас проявляется наибольшая активность и идут самые быстрые изменения. Наш эксперт считает, что за пять — десять лет бум утихнет и даже произойдет частичный откат. Со ссылкой на мнение мировых авторитетов (например, Стив Возняк, напарник Стива Джобса по созданию Apple) он говорит о чрезмерной увлеченности облаками и потере контроля над данными.
Генеральный директор “1С-Битрикс” Сергей Рыжиков видит тему “рынка средств разработки” несколько с другой стороны. В качестве главного аспекта он выделяет два направления:
- использование самих средств для веб-разработки, таких как .NET и другие привычные инструменты. Большинство облачных продуктов по сути представляют собой веб-сайты с особенностями технологий;
- адаптация имеющихся средств разработки для создания облачных сервисов, и примером тому является платформа “1С:Предприятие 8.3”.
Однако такое видение ситуации все же представляется довольно упрощенным и, наверное, во многом объясняется позиционированием на рынке компании, возглавляемой экспертом. Достаточно хотя бы сказать о том, что такие облачные направления, как IaaS и PaaS, вообще не связаны с сайтостроением, а назвать самый известный в мире SaaS-сервис — salesforce.com — веб-сайтом было бы очень большой натяжкой.
Руководитель направления по продвижению инструментов для разработчиков Microsoft Russia Денис Котляров также включился именно в облачную тему, говоря о том, что средства разработки развиваются в соответствии с требованиями к инструментальной поддержке со стороны разработчиков облачных приложений. Он сказал о необходимости обеспечивать принцип максимальной доступности инструментов и платформ для разработчиков, выделив несколько моментов: “Во-первых, средства разработки предоставляются бесплатно, во-вторых, их настройка и управление компонентами, необходимыми для создания облачных приложений, также полностью автоматизированы; на нашей платформе эту задачу решает инструмент Web-Platform Installer. И наконец, самое важное — это повсеместное проникновение стандартов”. Далее он отметил, что при создании облачных приложений разработчики стремятся использовать технологии и инструменты, созданные в соответствии с последними стандартами, такими как HTML5, это заставляет поставщиков облачных услуг внедрять поддержку соответствующих технологий, что в свою очередь делает облака более открытыми, доступными и позволяет разработчикам быть гибкими в выборе платформы, на которой будет работать решение. В целом же, по его мнению, тенденцией последних лет становится переход самих инструментов разработки в облака, в результате чего средства программирования поставляются в виде SAAS-решений. Именно в таком направлении развиваются и средства разработки Microsoft: в качестве примера г-н Котляров привёл платформу разработки c кодовым именем Napa (для создания приложений под Office 2013), которая доступна из облака. Пока она, правда, сильно уступает настольным решениям по разработке облачных приложений, но все же позволяет делать полезные вещи. “В ближайшие годы нас ждет все больше SAAS-решений по разработке приложений”, — оптимистично обещает сотрудник Microsoft.
“Российский рынок средств разработки начал активно развиваться чуть более четырёх лет назад”, — считает лидер направления Rational в департаменте программного обеспечения компании IBM в России и СНГ Дмитрий Ханецкий. Если судить по такой оценке, создается впечатление, что история российского рынка средств разработки началась с прихода сюда Rational… Но в целом с последующими высказываниями эксперта вполне можно согласиться: “Как раз года четыре назад заказчики начали относиться к процессу создания и сопровождения ИТ-систем с большим вниманием — стало очевидно, что для устойчивого развития бизнеса требуются специализированные продуктивные системы, способные решать вопросы поддержки процесса разработки бизнес-критичных систем. Именно тогда системы уровня ALM начали закрепляться в бизнес-практиках российских компаний. На сегодняшний день рынок средств разработки поделен между предложениями крупных вендоров и комбинированными, нишевыми решениями, включая open-source-решения”.
Своеобразный итог этой части обсуждения подвел первый заместитель генерального директора компании “Прогноз” Максим Балаш: “Вопрос слишком широкий, поскольку можно говорить и о разных сферах разработки ПО, и о разных классах продуктов (от базовых языков и сред программирования до высокоуровневых платформ настройки приложений)”. Говоря же о сфере интересов собственной компании — разработка продуктов для бизнес-аналитики, он отметил, то рынок развивается очень динамично, в том числе и в России: “Российским разработчикам и бизнес-пользователям доступны самые современные инструменты большинства крупных вендоров, представленных в “магическом квадранте платформ бизнес-аналитики” компании Gartner (А. К.: где представлен и сам “Прогноз”!)”.
Тут нужно отметить, что современные BI-платформы — это не только продукты для конечных пользователей, но и высокоуровневые специализированные средства разработки BI-решений. И в этой связи Максим Балаш особо отмечает высокий уровень компетенций относительно возможностей различных средств разработки BI-приложений как среди исполнителей, так и среди заказчиков ПО: “Современный заказчик уже вполне уверенно ориентируется в особенностях тех или иных продуктов, исходя при принятии решения не только из известности бренда, но и из конкретных задач своей организации, будь то бизнес или сфера госуправления”.
Какие тенденции на рынке: куда идем?
Тенденций много, они проявляются в разных аспектах и срезах, при этом все они — если приглядеться — сильно взаимосвязаны. Получилось так, что почти все наши эксперты не очень “пересекались” во мнениях, выделив наиболее важные для себя аспекты темы.
“Важная тенденция состоит в объединении инструментов разработки с облачными платформами для развертывания сервисов. Это происходит и в Amazon Web Services, и в разработке “1С”, и при интеграции в Azure”, — говорит Сергей Рыжиков, судя по всему, имея в виду переход к использованию модели PaaS, и добавляет: “В дальнейшем мы будем видеть тенденцию формирования неразрывной связи инструментов разработки и облачной инфраструктуры эксплуатации. На рынке уже несколько лет идет процесс создания операционных систем нового поколения, где средой является непосредственно облако — оно предоставляет разработчику не только API и процессорные мощности, но и готовые сервисы, упрощающие разработку, и даже систему биллинга для своих приложений”. Со своей стороны тут, правда, нужно добавить, что процесс тесной интеграции средств разработки и операционных платформ начался давно, еще в конце прошлого века (Java, Microsoft, та же “1С” и др.). Именно тогда аналитики стали говорить об исчезновении направления средств разработки как самостоятельного рынка.
Безусловно, ключевыми направлениями всего современного ИТ-рынка является движение в сторону сплошной облачности и всеобщей мобильности. И в этой связи Игорь Беспальчук отмечает, что сейчас все производители средств разработки всерьез озабочены тем, чтобы занять место в “сервисно-мобильной” сфере, а для этого нужно завоевать приверженность разработчиков сервисов. При этом стандартом де-факто становится требование обеспечения возможности представления сервиса на самых разных устройствах с минимальными затратами пользователя на поиск и разворачивание клиентского приложения. Решение же этой задачи обеспечивается несколькими в существенной мере конкурирующими между собой способами, на рынке все это хорошо видно на примере значительных различий в подходах к разработке клиентских приложений для разных программно-аппаратных платформ.
Так, еще несколько лет назад считалось, что магистральным путем решения вопроса поддержки многоплатформенного интерфейса должны стать Web-технологии. Казалось, создание нового стандарта HTML5 сможет уравнять возможности Web-клиентов с традиционными настольными приложениями, унифицировав подход к программированию для различных устройств. Перспективы HTML5 казались настолько “безоблачными”, что по пути его горячей поддержки пошла даже Microsoft, фактически забросив собственную (и по мнению многих специалистов, весьма удачную) технологию Silverlight.
Но за последний год стало видно, что HTML5 не очень все же отвечает возлагаемым на него надеждам. Комментируя этот момент, Игорь Беспальчук указывает, что большую фору в решении задач создания унифицированных клиентских приложений и сейчас имеют разработчики веб-браузеров на базе HTML5, но их унификация этого подхода имеет следствием значительные ограничения (о чём недавно публично заявил и глава Facebook Марк Цукерберг). По направлению к единой клиентской платформе для всех устройств идет и Google с инициативой NativeClient, преодолевающей ограничения HTML, но она пока не получила широкого распространения, поскольку, очевидно, не выгодна производителям HTML-браузеров. Корпорация Microsoft в свою очередь предлагает в качестве решения традиционный вариант использования единой платформы под лозунгом “One OS to rule them all” (“одна ОС для всех”), подразумевая, само собой, что “ОС” и “Windows” — это синонимы. Компания даже пытается привлечь на свою сторону легионы JavaScript-разработчиков, чем сильно пугает своих традиционных сторонников. Правда, такие “угрозы” (и противникам и сторонникам) со стороны Microsoft пока никто всерьез не воспринимает, поскольку, по мнению нашего эксперта, на мобильном рынке ее перспективы довольно призрачны. Тем не менее он отмечает, что рынок разделился на тех, кто замер в ожидании, и тех, кто активно “проталкивает” какое-либо средство, проча его в качестве универсального (на что никакое из существующих претендовать пока не может). Скорее всего, если миру разработки клиентского ПО и суждено объединиться под общей крышей единой платформы, то эта платформа не будет похожа ни на какую из нынешних.
Со своей стороны отметим, что ИТ-мир уже не первое десятилетие решает подобные проблемы унификации технологии, и потому ответ на вопрос, что нас ожидает в этом направлении, в целом хорошо известен: полной унификации не будет никогда, мир будет находиться в состоянии динамического равновесия с более или менее значительными амплитудами колебательных движений под действием большого комплекса центростремительных и центробежных сил.
Денис Котляров, говоря о тенденциях на рынке, выделяет в первую очередь облачную сферу, отмечая тут два тренда. Первый, он уже говорил о нем, — постепенный переход инструментов в облака. Развивая эту мысль, он указывает, что ряд таких решений доступен уже сейчас и все больше компонентов будет доступно из облака в ближайшее время. В качестве примера он приводит такие требовательные к вычислительным ресурсам решения, как нагрузочное тестирование — идеальный кандидат для переноса в облако — или сборка решений, также ресурсоемкая задача, уже решенная для приложений Windows Phone 8 (вот он, пример “единой ОС”), которые можно компилировать в облаках (опять же в облаках Microsoft).
Второй тренд, который видит представитель Microsoft, — расширение сценариев применения облака разработчиками: “Как и с другими технологиями, чем доступнее становятся облака, тем больше сценариев их применения появляется. Например, сейчас уже доступны решения по организации бэк-энда мобильных приложений в облаке, что является идеальным решением для разработчиков мобильных приложений, так как содержать свою собственную инфраструктуру им не выгодно. Не за горами активный переход веб-разработчиков в облака, в том смысле, что дата-центры, в которых сейчас публикуются веб-сайты, будут сами постепенно переходить в облака, а за ними и веб-разработчики. Уже сейчас на рынке есть интересные предложения для веб-разработчиков с самыми разными запросами. И конечно же все новые сценарии потребуют инструментальной и технологической поддержки, которая обязательно появится в средствах разработки”.
Вадим Сухомлинов в своем комментарии решил сосредоточить внимание на другой важной тенденции в области ИТ — консьюмеризации, затронувшей сферу средств разработки в виде появления простых инструментов для создания типового функционала, которые могут применяться непрограммистами: “Сейчас такие решения появляются для веб- и простых мобильных приложений. Возможно, с развитием технологий обработки естественного языка и жестов появятся системы автоматической обработки требований, а в будущем — и создание приложений по описанию”. Разумеется, он не мог обойти стороной и облачные дела, сказав, что основными направлениями тут являются вопросы работы с распределенными данными, обеспечение высокой доступности и масштабируемости, а также сфера Big Data (тут заметен интерес к разработке приложений для Hadoop, NoSQL и других решений). Что касается языковых средств, то он выделил очередной рост интереса к кросс-платформенным решениям, подстегнутый распространением мобильных платформ и их различиями. Вадим Сухомлинов оптимистично оценивает перспективы HTML5, отмечая, что этот язык, изначально предназначенный для разметки веб-страниц, сейчас начинает приобретать свойства, позволяющие использовать его для разработки приложений. Соответственно можно ожидать развития специализированных средств разработки облачных приложений, аналитических решений для “больших данных”, средств разработки мобильных и социальных (для социальных сетей) приложений.
Разумеется, важной — и давней — тенденцией развития инструментальных средств разработки является переход к пониманию процесса разработки в контексте концепции ALM. Говоря о будущем ALM-систем, Дмитрий Ханецкий указывает на необходимость четко понимать не только их бизнес-роль, но и функциональное предназначение, которое легко можно уложить в несколько слов: обеспечение эффективной командной работы участников процесса создания и сопровождения ПО. Будущее, по его мнению, за интеграционными платформами, в которых будет организована не просто вся процедура обеспечения жизненного цикла разработок, но и надежная и удобная среда взаимодействия пользователей различных функциональных подразделений. Сейчас же большинство решений в этой области представляют собой разрозненные пазлы, состоящие из модулей систем различных производителей, при этом далеко не всегда легко совместимых между собой.
Решение проблемы несовместимости довольно очевидно (мы о нем уже говорили выше на примере мобильных приложений) — использование единой системы от одного поставщика. Вполне естественно, Дмитрий Ханецкий в данном случае имеет в виду платформу IBM. Представитель корпорации затронул также тему соотношения между open-sourсe-решениями и узкоспециализированными вендорными продуктами с централизованной платформой создания и сопровождения ПО. По его мнению, открытое ПО, как правило, выбирают для того, чтобы закрыть отдельные “куски” процесса, решить отдельные задачи, но если говорить о создании инфраструктуры для разработки масштабного решения, то единый подход, единая стратегия и единое решение оправданны. При децентрализованном решении заказчик несет риски, связанные с интеграционной составляющей, а также с передачей данных между различными модулями системы. Для большинства заказчиков процесс разработки связан с бизнес-критичными системами, что, в свою очередь, определяет высокую стоимость затрат в случае их неработоспособности. Поэтому важно понимать, что цена ошибки в разрабатываемой системе может быть намного дороже единовременных затрат на внедрение надежного программного комплекса, способного обеспечить выпуск качественных программных продуктов.
Весьма любопытную точку зрения о “драйверах рынка” высказал Максим Балаш. Оказывается, важным фактором развития новых технологий и разработки новых продуктов является планка требований, задаваемая консалтинговыми агентствами (Gartner, Forrester, IDC). Поясняя такое мнение, он указывает, что лидеры мировой аналитики опираются на реальные подходы, уже в том или ином виде реализованные в конкретных продуктах, а заказчики, ориентируясь на такие исследования, общие тренды и “моду”, проявляют интерес к новым возможностям, используют их для решения своих задач и тем самым развивают сами инструменты и расширяют сферу их применения. В сфере прикладных систем, в том числе и в бизнес-аналитике, видно проявление современных трендов — SaaS, мобильность, технология In-Memory. Ключевой тенденцией, как считает Максим Балаш, является ориентация на бизнес-пользователя даже в технологическом слое системы. Речь идет о том, что возможности интерфейса должны позволять ему на интуитивно понятном уровне настраивать решение под свои конкретные задачи без навыков программирования и привлечения ИТ-специалиста.
Разработчики и бизнес-руководители — их роль в создании новых ИТ-решений
Тут вроде бы все понятно: без разработчиков никакие новые решения появиться не смогут, и никто из разработчиков не будет создавать новые решения, если на них не будет в том или ином виде спроса со стороны потребителей. Тем не менее вопрос увязки интересов и возможностей разработчиков и пользователей был и остается очень актуальным, и сегодня он проявляется в формате концепции DevOps, суть которой можно определить так:
Подход к предоставлению ИТ-сервисов, основанной на agile-философии (быстрая, гибкая разработка и внедрение), с ориентацией не на ортодоксальные процессы, а на конечные бизнес-результаты.
Нацеленность на конечный бизнес-результат! Казалось бы, качественно новая постановка всей проблематики. Но если вспомнить историю ИТ, то можно увидеть, что именно так и была организована разработка ПО всего каких-то двадцать-тридцать лет назад. И все же — “так, да не так”: времена, когда программисты были и единственными пользователями своего ПО, уже никогда не вернутся.
Говоря о роли разработчиков, Вадим Сухомлинов отмечает, что именно их компетенция является скорее всего наиболее важным фактором, определяющим успех проекта. Именно разработчики могут скорректировать выбор инструментальных средств, архитектуру системы исходя из бизнес-требований, обеспечить сроки разработки и качество решения.
Развивая эти же мысли, Сергей Рыжиков подчеркивает, что разработчики выбирают инструменты, которые дают им больше контроля, помогают увеличить скорость разработки и обеспечивают возможность максимально быстро перенести имеющиеся приложения в облачную инфраструктуру.
Смещение уровня сервиса ближе к потребителю — это сегодня один из главных сегодняшних трендов в ИТ-индустрии, считает Игорь Беспальчук. Он уверен, что сейчас уже мало кого устраивает просто разработка программного продукта по подготовленным требованиям. Сегодняшний поставщик ИТ-решений должен быть готов предоставить сервис значительно более высокого уровня, включающий более тесное взаимодействие с заказчиком для решения бизнес-задач. Компания-разработчик при этом выступает не как ресурс по созданию ПО по спецификациям и не как ресурс специализированной рабочей силы, а как целостный ресурс развития бизнеса. При этом отмечается, что для достижения синергетического эффекта в таком партнерстве от заказчика требуется высокий уровень доверия к поставщику, а от поставщика — высокий уровень ответственности за качество сервиса в целом, от анализа проблем и разработки ПО до поддержки и эксплуатации. Тут Игорь Беспальчук отмечает набирающую зрелость концепцию DevOps, акцентируя важный момент: команды разработчиков должны понимать новую философию, воплощенную в принципах Agile и DevOps, но большинству компаний в нашей стране еще предстоит культурная ломка, чтобы перейти к новой парадигме.
Тут, наверное, стоит вспомнить о классическом вопросе о сути программирования — это наука или искусство? — который был поставлен еще в 60-е годы прошлого века (в общем-то на заре ИТ) и на который довольно быстро был найден ответ: это технология. И тем не менее давняя мечта руководителей ИТ-проектов — перевести процесс разработки ПО в вариант “автоматической конвейерной сборки” — до сих пор так мечтой и остается. Об этом фактически говорит и Денис Котляров: “Несмотря на все значительные улучшения технологий и стандартов, роль разработчика трудно недооценить. Хотя новые инструменты помогают разработчику концентрироваться на основной задаче путем автоматизации рутинных операций, поддержки стандартов, что облегчает разработку под различные платформы и появление большого набора библиотек, никто пока не научился создавать решения без участия инженера-программиста. В этом смысле роль разработчиков стала только важнее, так как ПО проникло во все сферы деятельности человека и потребность в разработчиках ПО с каждым годом неуклонно растёт. Чего стоит только бум последних лет с разработкой приложений под мобильные устройства”.
Со своей стороны, Дмитрий Ханецкий все же делает акцент на важность инструментов: “Аналитики, разработчики, тестировщики — это люди, которые реализуют бизнес-требования заказчика. От квалификации зависит очень многое, но важно и то, какими инструментами они пользуются. Продуктивность увеличивается в разы, если команда пользуется удобным инструментарием, позволяющим отслеживать продукт на всех этапах его жизненного цикла”.
Максим Балаш иллюстрирует сложность и порой непредсказуемость процесс развития продукта на примере инструмента In-Memory. Сначала эта технология появлялась в отдельных “легких” BI-продуктах, которые начинают применять кэширование информации на стороне клиента как один из основных подходов к ускорению аналитических операций. Этот тренд подхватывается аналитиками: в их требованиях к функционалу появляется поддержка подобной технологии. На это реагируют другие вендоры, и в итоге технология, зародившись в одном классе продуктов, перекочевывает в совершенно другой, в данном случае — в аппаратно-программные комплексы. Тут эксперт показывает: сначала технология была преимущественно клиентской, а потом стала серверной и, более того, программно-аппаратным комплексом с высоким уровнем распараллеливания.
Что же касается роли бизнес-руководителей, то здесь Дмитрий Ханецкий отмечает, что они “…отвечают за здоровье проекта в целом — за соблюдение сроков исполнения, стоимость реализации, качество, а также исполняют функции контроля и управления командой”. Логично развивая свое видение процесса разработки, он указывает, что руководителями для этого опять же необходимы специальные инструменты.
Сергей Рыжиков концентрирует свое внимание на облачных перспективах и потому уверен: для руководителей проектов на первом месте стоит скорость переноса текущих решений в облачную инфраструктуру. Именно это позволяет им максимально быстро перейти к коммерческой эксплуатации облачных сервисов, чтобы получать выгоду на новых рынках.
Игорь Беспальчук смотрит на проблему участия бизнеса в создании новых ИТ-решений в комплексной постановке вопроса, отмечая, что руководство компаний должно относиться к ИТ (будь то внутренняя ИT-служба компании или внешний подрядчик) как к полноправному партнеру, от которого с каждым годом все больше и больше зависит течение бизнеса. Соответственно необходимо, чтобы стратегическое движение бизнеса формировалось совместно с ИТ-представителями исходя из общего понимания целей организации и новых возможностей ИТ. При этом кроме общего понимания целей важно представление о качестве сервиса. Необходимо, чтобы именно эти высокоуровневые представления о целях (“чего мы хотим достичь?”) и качестве (“что мы считаем достаточным уровнем качества?”) были максимально объективированы и согласованы. Исходной точкой во взаимодействии должно быть именно согласование целей и критериев качества, а не директивное руководство. Естественно, что это возможно только в том случае, когда ИТ-служба или подрядчик обладает достаточной компетентностью для самостоятельного успешного ведения проектной деятельности и управления процессами.
Задача бизнес-руководителя состоит в том, чтобы максимально четко определить бизнес-требования к разрабатываемой ИС, причем важно это сделать с учетом времени, запланированного на разработку, чтобы избежать ситуации, когда создаваемое решение устаревает еще до завершения разработки. Таково мнение Дениса Котлярова, который далее подчеркивает, что решение такой задачи включает в себя выбор перспективной платформы и технологий разработки. Понятно, что роль эта важная и ответственная и чтобы “исполнять ее”, нужно быть дальновидным специалистом, не бояться принимать ответственные решения на перспективу, в том числе не опасаясь недопонимания. В то же время он отмечает, что бизнес-руководитель должен быть хорошим администратором, правильно планировать распределение ресурсов, следить за соответствием трех сторон важного треугольника: “ресурсы — качество — время”. Сегодня все это нужно делать буквально в реальном времени, так как циклы разработки сократились до нескольких недель. И тут он согласен с высказанной ранее точкой зрения о важности технических средств: “За последние годы появилось множество улучшений, и инструментальная поддержка гибких методологий разработки, управления требованиями, а также другие инструменты позволяют руководителям эффективно решать такие задачи”.
Вадим Сухомлинов считает, что основная роль бизнес-руководителей состоит в том, чтобы обеспечить процесс разработки и необходимые ресурсы. При этом под процессом он имеет в виду определение и сбор требований (включая привлечение разного рода специалистов), определение, согласование и отслеживание финансовой составляющей и сроков. Очень важно при этом понимать тенденции развития рынка в целом, что особенно актуально, когда речь идет о разработке рыночного продукта.
