Итого

Юрий Драбкин, консультант по сопровождению жизненного цикла инфраструктуры ЦОД, Schneider Electric

В каких случаях целесообразно привлечь внешних специалистов по инженерной инфраструктуре ЦОД, чтобы повысить эффективность использования его вычислительных ресурсов в интересах бизнес-пользователей?

Прежде всего в случае, если бизнес готов поставить перед службой эксплуатации ЦОД конкретные задачи. То есть бизнес совместно с руководителем ИТ-департамента должен предложить проект, в рамках которого будут выявлены и реализованы конкретные потребности в ИТ – например, внедрение новых сервисов для клиентов или повышение надежности архитектуры критичного для предприятия ИТ-решения. Если такие цели определены, остается только выбрать подходящий инструмент для их достижения. Это могут быть формирование регламента службы эксплуатации инженерной инфраструктуры, монтаж блока системы кондиционирования или внедрение компонента DCIM. Но даже лучшими инструментами нужно уметь пользоваться – необходимы специалисты внутренние или внешние. Внешних специалистов целесообразно привлекать, если площадка корпоративного ЦОД вмещает и задействует более 20 стоек с оборудованием, при этом бизнес организации основан на применении ИТ и не может функционировать, если предоставление ИТ-сервисов остановится.

Разве соответствующие службы предприятий, включая ИТ-департаменты, не могут самостоятельно оптимизировать инженерную инфраструктуру ЦОД под потребности бизнеса в ИТ-ресурсах и сервисах?

Оптимизировать они могут. Но только сторонние эксперты могут дать финансовые гарантии того, что оптимизация проведена качественно и не в ущерб бизнесу организации. Потому что только внешние специалисты способны объективно оценить состояние инфраструктуры ЦОД и предложить проверенные решения для ее оптимизации. Специалисты службы эксплуатации заказчика, конечно, досконально знают свой объект, но иногда именно это мешает добиться нужного результата – им сложно самостоятельно перенести на действующую модель ЦОД лучшие отраслевые практики. Правильнее будет привлечь экспертов, которые уже имеют достаточный опыт выполнения подобных работ на аналогичных площадках. У внешних специалистов и оснащение гораздо лучше. Например, наша компания только в рамках первичного аудита площадок использует специальные технические средства общей стоимостью в сотни тысяч долларов. Приобрести подобный комплекс для анализа и оптимизации инженерной инфраструктуры собственного ЦОД целесообразно, если мощность его потребителей составляет не менее 5-8 МВт. Вместе с тем оптимизация инженерной инфраструктуры – это не только сокращение избыточных мощностей, но и перепрофилирование имеющихся ресурсов. Помнится, у одного российского клиента из финансовой отрасли служба эксплуатации при помощи наших специалистов выявила недогруженные системы инженерной инфраструктуры на двух площадках в Москве и задействовала их, перенеся оборудование с третьей площадки, где находилось 15 стоек. После чего третью площадку вывели из эксплуатации. Проект начинали, чтобы повысить надежность сервиса, а удалось значительно сократить операционные расходы.

Всегда ли бывает экономически выгодно приглашать внешних экспертов для оптимизации инженерной инфраструктуры ЦОД? Когда этот подход не работает?

Опыт нашей работы с российскими организациями показывает, что для решения большинства стандартных бизнес-задач нецелесообразно оптимизировать малые площадки ЦОД, рассчитанные на 10-15 стоек. В этих случаях намного проще и дешевле построить новые площадки, точно спроектированные под требования бизнеса. Помню, как одно российское предприятие из производственной сферы строило ИТ-системы, время простоя которых в течение 20 часов никак не сказывалось на результативности бизнеса. Если ЦОД может не работать сутки подряд и это не влечет никаких убытков, то организации не требуются наши услуги. Но такое невозможно вообразить в финансовой сфере, в телекоммуникационной отрасли или в государственном секторе.

Проникновение цифровых технологий в бизнес стирает привычные границы компаний и даже целых отраслей, расширяя их возможности. Как отметила в своем выступлении на форуме Smart Company 2015 Мария Григорьева, руководитель российской практики Accenture Technology, наблюдается переход к целым цифровым экосистемам. Происходит «объединение необъединяемого» – интеграция предприятий и цифровых платформ, физического и виртуального мира, а также бизнесов самых различных отраслей.

Accenture выделяет пять тенденций. Первая получила название «Интернет имени меня» и заключается в персонификации пользователей. Вторая тенденция – «Экономика результата», когда целью становится продажа не отдельно взятого продукта или услуги, а конечного результата пользователю, заинтересованному в нем. Третья – «Эволюция ИТ-платформ», в ходе которой происходит интеграция самих систем с предприятиями. Четвертая – «Интеллектуальные системы». Тенденция заключается в интеграции устройств, технологий и данных для предложения новых услуг на новых рынках. Наконец, появляется «Новое представление о ресурсах» – устройствах, пользователях и навыках, которыми они обладают. Теперь компаниям приходится думать не только о сотрудниках, но и об их устройствах, а также используемых ими приложениях.

Мы попросили Григорьеву прокомментировать последствия, которые эти тенденции будут иметь для компаний.

Какая из озвученных вами тенденций играет наиболее разрушительную для сложившегося положения вещей роль и почему?

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

Какие выводы должны сделать компании из наблюдаемых на рынке тенденций, каковы должны быть их действия?

Каждая тенденция имеет свои последствия. Во-первых, следует осознать многомерность среды своих покупателей и возможные многоканальные пути коммуникаций с ними, чтобы быть в нужное время в нужном месте и с нужной информацией. Оценить привычки покупателей, увидеть, что и где им нужно, изменить свои технологии и способы выхода на клиента.

Экономика результата требует от компании почувствовать себя на месте клиента и понять, что ему нужно. Придется «обернуть» продукт или услугу дополнительными «бантиками» или конкретными сервисами, чтобы решить проблему клиента, а не только дать ему инструмент. Для этого надо подобрать технологии и методы, а главное – контролировать, что такая деятельность приносит результат.

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

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

Что будет самым сложным на пути цифровой трансформации компаний?

Найти себя в строящихся экосистемах и не быть раздавленными другими системами. Построить доверительные отношения с партерами по экосистеме, чтобы занять свою нишу в цепочке.

Остальное – уже дело техники, которая развивается быстрыми темпами; надо лишь извлечь из нее то, что нужно компании. Получаемый большой объем данных должен быть правильно запрошен и проанализирован, а на основе анализа требуется сделать выводы и применить их на практике, чтобы оценить результат своих действий.

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

«Мы доказали, что в России есть системы, способные полноценно заменить зарубежные. После анализа функционала российских и западных решений, проведенного еще в 2010 году, выяснилось, что отечественные продукты на 80–90% соответствуют западным», — считает Валерий Бордюже, председатель Координационного совета по ИТ предприятий оборонно-промышленного комплекса (КС ИТ-ОПК). Отставание отечественных решений от западных не такое уж сильное — в первую очередь оно касается удобства и «красоты». Тот отчет чиновники просто приняли к сведению. Когда же грянули санкции, они стряхнули пыль с отчетов и стали доказывать, что замещать есть на что.

Совет, возглавляемый Бордюже, состоит из трех групп: ИТ-директора предприятий ОПК, руководители отечественных ИТ-компаний и представители регуляторов (министерства, ФСБ, ФСТЭК и т. п.).

Ни в одну из национальных программ развития ИТ традиционно не попадали. Ситуация постепенно начала меняться лишь в 2010 году, когда при президенте появился Совет по информатизации. Заговорили о монополиях, и ИТ приобрели новое качество. Фактически ИТ стали продукцией двойного назначения, официально появились такие термины, как «кибератака» и «информационная война».

Надо было показать, что ИТ не придется поднимать с нуля, что уровень отечественных разработок отнюдь не «ниже плинтуса» — а именно такое мнение культивировалось долгие годы с подачи западных производителей ИТ и даже звучало на уровне руководства страны. Например, сколько бы ни старалась «1С», в массах есть убеждение, что она выпускает продукты недостаточно высокого уровня. Но на самом деле, по мнению Бордюже, она совершила национальный ИТ-подвиг, при полном отсутствии поддержки от государства и игнорировании отечественной ИТ-отрасли собственными ресурсами создав конкурентоспособный продукт и в последние годы тесня на рынке зарубежных конкурентов.

«Мы терпели, когда западные продукты внедрялись в добывающих отраслях. Там речь шла о “вхождении в клуб” мировых поставщиков и готовности играть по сложившимся правилам. Однако столь веские аргументы были далеко не всегда. Мы просили Счетную палату оценить, во сколько обошлось стране чрезмерное увлечение продуктами SAP, но наша просьба пока осталась без ответа», — говорит Бордюже.

Ситуацию усугубляет то, что взаимодействие между различными поставщиками отечественных ERP-систем (компаниями «1С», «Галактика», КСТ, «Парус», «Информконтакт») далеко от идеала. На оборонных предприятиях есть всего лишь несколько случаев полноценной интеграции различных отечественных систем. Одним из позитивных примеров является Рязанский радиозавод, где интегрированы и работают как единая система продукты компаний «1С», АСКОН и КСТ. Во многом это произошло потому, что руководителем проекта там стал генеральный директор.

«Пока взаимодействие между поставщиками идет откровенно вяло. Этого недостаточно, надо активнее дружить!» — призывает Бордюже. Возможно, даже следует принудить российских разработчиков к более глубокой интеграции друг с другом. В свете появившихся тенденций, когда за голову схватились не только оборонные, но и многие химические и нефтехимические предприятия, деньги на отечественные решения выделяются и отношение к ним будет меняться.

«Открытое ПО, об использовании которого много говорится в последнее время, — это хорошо, однако оно уязвимо. Для критически важных объектов без проприетарного системного ПО не обойтись», — подчеркивает Бордюже. Есть примеры достаточно успешных отечественных систем — например, СУБД «Линтер», разработка воронежского НТЦ «Релэкс». Может, она по широте функционала и уступает другим, но зато превосходит по защищенности, в отдельных случаях пользуясь спросом даже за рубежом. Разработчики отечественных ERP уже тестируют ее для спецприменений, пытаясь перевести на нее свои продукты.

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

На кривой зрелости технологий Gartner (Hype Cycle) Большие Данные уже прошли «пик завышенных ожиданий» и скатываются сейчас по «желобу разочарований». Первый ажиотаж постепенно схлынул, и компании более вдумчиво относятся к предлагаемым решениям. В результате на смену традиционному вопросу «Как продать Большие Данные?» приходят более осмысленные — кому и зачем нужны технологии Больших Данных. Эта тема стала одной из центральных на круглом столе в рамках форума Big Data 2015, организованного издательством «Открытые системы».

Участники дискуссии сошлись во мнении, что сейчас интеграторы в первую очередь должны готовить почву для будущих проектов, обучая клиентов и готовя кадры, которых на рынке не хватает. Как только возникает новая технология, надо осознать, что, вложившись в обучение потенциальных клиентов, можно выиграть очень много.

Например, «Яндекс» уже несколько лет имеет школу анализа данных, Mail.ru также запустил свою школу на эту же тему. Это пример «правильных» действий, направленных на зарабатывание денег в будущем. Для этого надо прилагать определенные усилия, вкладывать деньги, готовить площадки, делать пилоты, беря на себя определенные риски, которые в случае Больших Данных довольно велики.

«Продавайте честно. Имеющийся опыт взаимодействия с различными игроками рынка нельзя признать позитивным», — говорит Александр Аникин, руководитель отдела аналитики Wikimart. Зачастую заказчику обещают золотые горы, а впоследствии выясняется, что специалисты интегратора не имеют даже опыта работы с решением. Это очень обидно и неприятно: заказчик хочет, чтобы интегратор был умнее его и мог чему-то научить, а не только продать технологию.

«Возврат инвестиций оценить несложно: и банк, и сотовый оператор знают, сколько стоит конкретный клиент, сколько стоит каждая услуга. Эффективность проекта может быть измерена на этапе пилотирования или апробации идеи», — подчеркивает Анджей Аршавский, директор центра компетенции супермассивов данных «Сбертеха».

Однако сейчас у заказчиков совершенно разная степень зрелости — степень понимания того, что ему нужно. Если она нулевая, то нужен комплексный подход: надо помочь ИТ-департаменту «продать» идею топ-менеджменту, затем провести пилотные проекты, демонстрирующие результативность, помочь развернуть инфраструктуру, обучить специалистов. Этап продажи имеет много стадий; не факт, что деньги пойдут с самого начала, часто необходимы инвестиции.

«Если возникают сомнения в окупаемости того или иного проекта, значит — ее, скорее всего, нет», — констатирует Аникин. По его мнению, при верно выбранном подходе у проектов Больших Данных должен быть возврат инвестиций, видимый невооруженным глазом, — на уровне тысяч процентов.

«Могу сказать, как продавать не надо: не имеет смысла приходить с технологиями. Выглядит некрасиво, когда заказчику пытаются продать функциональность, доступную бесплатно в открытых решениях», — отмечает Сергей Сотниченко, руководитель направления хранилищ данных и отчетности банка «Тинькофф. Кредитные системы». Заказчики очень ждут от интеграторов готовых локализованных бизнес-продуктов, решающих конкретные проблемы и имеющих российскую специфику. Теоретические же изыскания всегда вызывают определенный скепсис.

«Большие Данные — это пока только технологии. Их продажа должна начинаться с ответа на вопрос, зачем они нужны и какие проблемы могут решить», — согласен Михаил Жохов, в прошлом ИТ-директор «Атомэнергомаша» и «Трансмашхолдинга».

Свои идеи надо нести не айтишникам, которые и без того продвинутые, а бизнес-заказчикам — финансистам, маркетологам, сбытовикам. Когда они поймут, что в результате анализа данных изменятся финансовые результаты компании, решение будет продаваться.

«В настоящее время наблюдается тектонический сдвиг парадигмы рождения и жизненного цикла продукта», — говорит Аршавский. Этот сдвиг отчетливо виден на примере Hadoop: продукт зародился в недрах интернет-компании, затем вышел на рынок в виде открытого решения, которым могли пользоваться все желающие. К нему появился интерес, его начали широко применять, и в какой-то момент он смог весьма успешно конкурировать с дорогостоящими решениями, существовавшими на рынке. Сами вендоры, увидев успех Hadoop, стали его использовать.

«Между возможностями открытых решений и реальными потребностями клиентов есть очень хороший бизнес», — уверен Аршавский. В какой-то степени это соответствует ожиданию рынка: продукты Оpen Source хороши бесплатностью, но отсутствуют поддержка, интеграция, нет решения возникающих проблем. Рождается другой формат бизнеса, которым занимаются, например, Cloudera и Hortonworks, предлагая поддержку Hadoop. Крупные вендоры тоже двинулись в этом направлении: многие открывают свои проприетарные решения, пытаясь соответствовать духу рынка, а рынок становится другим, очень быстро меняясь.

Для большинства компаний управление сотрудниками и их мотивация превращаются в нетривиальную задачу. Как выяснилось в ходе исследования, проведенного Oxford Economics, у компаний нет стратегий, которые позволили бы эффективно управлять сотрудниками поколения миллениума. Руководители кадровых служб понимают, как важно уметь управлять все более разнообразным и мобильным персоналом, но им не хватает стратегий и готовых решений.

Ситуацию усложняет явное доминирование в мотивации сотрудников материальных факторов. При этом многие компании действуют во многом интуитивно, «на глазок». Лишь в последнее время у HR-специалистов начали появляться инструменты в виде систем управления человеческим капиталом (Human Capital Management, НСM) и корпоративных порталов, обеспечивающих создание полноценных социальных сетей.

Как отмечают в Gartner, хотя 70% компаний уже используют социальные технологии, только 10% делают это успешно. В большинстве случаев внедрение социальных средств проходит по принципу «обеспечить и надеяться». Сотрудникам предоставляется доступ к социальной технологии, а руководство рассчитывает на то, что в результате сами собой сформируются сообщества и взаимодействие сотрудников положительно скажется на работе компании.

Как сошлись во мнении участники дискуссии «Пряники и ИТ-инструменты» на портале Global CIO, без точно определенной и убедительной цели большинство социальных проектов не приносит выгоды бизнесу. Да и нематериальные «вишенки» начинают работать, только когда материальный «торт» более-менее в порядке.

«Я считаю, что применять корпоративные порталы необходимо. При грамотном подходе они очень помогают сделать человека не просто сотрудником, а частью коллектива, команды. Но все это действенно, если дополнять, а не подменять материальную мотивацию», — отметил Илья Козлов, директор по ИТ концерна «Энергомера». Многие крупные вендоры сейчас интегрируют в свои продукты для корпоративных порталов элементы социальных сетей — достаточно посмотреть на новые функции Microsoft SharePoint.

«Нам удалось сделать корпоративный портал инструментом живой работы: если сейчас его выключить, работа встанет, хотя еще несколько лет назад никто о нем даже не задумывался», — продолжает Козлов. Очень многие задачи, которые требуют участия сотрудников разных подразделений, сейчас «живут» на корпоративном портале: назначаются и отслеживаются задачи, составляется отчетность. При этом портал существует не сам по себе, а в тесной интеграции с другими информационными системами компании, а также с почтой, офисными приложениями и системой корпоративных коммуникаций.

Хорошим примером мотивационного подхода стало внедрение социальной сети в компании «Кьези Фармасьютикалс». В качестве коммуникационной среды там используется платформа «Пряники», интегрированная в портал на «1С:Битрикс». В ее рамках используется корпоративная социальная сеть — для проведения опросов и обмена идеями, виртуальная валюта — для вовлечения сотрудников в проявление благодарности друг к другу, значки (беджи) — для популяризации историй успеха сотрудников и т. п.

«Основные надежды на "пусковой механизм" активности пользователей были возложены на виртуальную валюту для проявления благодарности. Это самый простой и приятный способ проявить активность и установить коммуникацию с коллегами, и он становится хорошим фундаментом для выстраивания уже более сложного взаимодействия», — считает Павел Карасев, ИТ-директор «Кьези Фармасьютикалс». По его словам, построенная корпоративная сеть улучшает общий эмоциональный климат в компании, заставляет задуматься о том, что люди работают не только за зарплату, но и ради интереса, общей цели и прочих «высоких материй», о которых часто говорят со скепсисом и которых при этом всем катастрофически не хватает. Через благодарности коллеги часто рассказывают друг другу об успехах, о которых раньше никто не узнавал, — например, благодарят за выигранный тендер или продажу крупной партии товара.

«После запуска социальной составляющей посещаемость портала выросла в четыре раза, и это относится не только к новому коммуникационному разделу, но и корпоративным новостям, и базе документов», — отмечает Карасев. Благодаря использованию беджей степень участия сотрудников в обучающих программах и тестированиях увеличилась более чем втрое.

В будущем платформа будет задействована для выбора сотрудников в ежегодной номинации «Лучший сотрудник года», а летом будет открыта «Лавка пряников», чтобы накопленные благодарности можно было потратить на призы материального или статусного свойства. Кроме того, планируется внедрить «адаптационные квесты» для новичков, чтобы они проходили свои первые шаги в компании в игровом, неформальном формате, а не отвлекали по одним и тем же вопросам руководителей.

Scrum: результат в условиях неопределенности

Гибкие (agile) методики реализации ИТ-проектов — иногда, в зависимости от контекста, встречается вариант перевода «скорые» — получают все большее распространение. 84% ИТ-департаментов, опрошенных VersionOne, ответили утвердительно на вопрос, применяют ли они гибкие методики разработки. Среди них 54% заявили об использовании методики Scrum. Более того, компетенции в Scrum, наряду с технологиями in-memory и предсказательной аналитикой, входят в рейтинг наиболее востребованных ИТ-навыков, составленный Foote Partners.

Гибкие методики соответствуют изменившимся требованиям рынка: устранить риски и увеличить скорость разработки, снизить вероятность провала проекта. По данным The Standish Group, число неудач в Scrum-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше.

Гибкие подходы избавляют от многих рисков благодаря более активному взаимодействию команды разработчиков между собой и с заказчиками. За двухнедельные интервалы разработок — «спринты» — гораздо проще создать продукт, отвечающий базовым требованиям пользователей, и затем дорабатывать его на основе полученной обратной связи, чем ждать реализации крупного функционала, который в итоге не будет соответствовать бизнес-требованиям.

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

Гибкие методики являются крупным изменением для компаний, стремящихся уйти от традиционного «водопада». Такие методики подразумевают принципиально иное управление проектами. Для этого требуются специалисты, чей стиль работы, опыт и мировоззрение соответствуют методикам гибкой разработки. Проблема не в том, чтобы найти хороших разработчиков, а в том, чтобы увидеть у них «гибкий» образ мышления. Нужен определенный профиль человека: помимо коммуникабельности, это любопытство, умение решать проблемы, способность работать в команде. Старое представление о программисте как об «одиноком волке», работающем соло, ушло в прошлое — сейчас такой подход не является предпочтительным.

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

Как отметил Михаил Петров, заместитель директора департамента проектов по информатизации Министерства связи и массовых коммуникаций РФ, в рамках дискуссии «Мы за скрам!» на портале Global CIO, любая методология имеет область адекватного применения. «Scrum подразумевает намного большую квалификацию исполнителя — как с точки зрения управления объемом и ресурсами, бюджетом, рисками, так и в плане управления ожиданиями заказчика, требует вовлечения заказчика в процесс и создания определенного партнерства», — подчеркивает он. «Классически» воспитанный ИТ-менеджер к такому не привык, но для некоторых проектов (когда делать надо в четко определенный срок, но что — до конца не понятно) такая методология становится единственным выходом. Иногда традиционный подход дает вполне приемлемые результаты, но в ситуации, когда среда меняется, Scrum будет все более и более востребован.

«Традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Эти требования меняются настолько динамично, что то видение, которое было в начале проекта, становится кардинально иным к его концу», — констатирует Тагир Яппаров, председатель совета директоров «АйТи». «Водопад» при таком положении дел дает плохие результаты, ведет к неудачам или превышению по бюджетам и срокам. Поэтому начали активно применяться более динамичные методологии, и Scrum стал элементом крупных проектов. Даже у SAP появились методологические изменения, которые отражают видение таких подходов.

«Мне кажется, что все эти разговоры про быстро меняющиеся процессы — просто фиговый листочек, прикрывающий слабую осознанность бизнесом собственных операционных процессов», — говорит Евгений Алешин, директор службы ИТ компании «Монт». Младший персонал, как правило, понимает процессы на уровне нажимания кнопок, а менеджеры не хотят знать ни про эти кнопки, ни про системы в целом — их интересует отчет о прибыли и убытках. Итеративный подход просто дает возможность постепенного понимания командой разработки предметной области. Гибкие подходы работают, тем более что они в себе содержат элементы самоорганизации команды (ежеутренние собрания) и элементы работы с заказчиком (демонстрация после каждой итерации). А вот с архитектурой систем в гибкой разработке есть определенные проблемы.

«В 90-е годы я сам использовал методологию Scrum — правда, не зная об этом: прямой контакт с заказчиком, реализация с его слов, короткие циклы, постоянные презентации», — вспоминает Александр Огнивцев, руководитель управления сервисной поддержки «АльфаСтрахования». Разница в том, что в те годы заказчик, как правило, точно знал, чего хочет, но не знал, что это можно реализовать через ИТ. Теперь заказчик точно знает, что с помощью ИТ реализовать можно все, но не знает, чего хочет. Ситуация неопределенности воспроизвелась: теперь на новом витке и в иной ситуации, — и конечно, гибкие технологии становятся востребованными.

«Мне кажется, что на открытом конкурентном рынке заказчики вряд ли примут решение в пользу Scrum, потому что основной его минус — неясные результаты за непонятный бюджет», — признает Георгий Давыдов, архитектор интеграционных решений R-Style Softlab. — Покупатель, понятное дело, предпочтет определенные сроки и цифры. Из-за этого приходилось даже скрывать свой «внутренний» Scrum от заказчика, хотя сейчас его элементы используются даже на «водопадных» проектах».

Преимущества этой методики управления прямо проистекают из ситуаций, когда ее выгодно применить. Например, заказчик не знает, что ему нужно; говоря более обобщенно — нет технического задания, что позволяет вообще исключить такой обязательный для «водопада» этап. «С одной стороны, экономия налицо, с другой стороны, привязка к партнеру становится катастрофической, да и сам исполнитель «подсаживается» на ключевых сотрудников. Как вы думаете, полетел бы Гагарин в космос, если бы ракету строили по Scrum?» — задается вопросом Давыдов. Другими примерами могут быть ситуации, когда по каким-либо причинам не получается оценить сроки и бюджет проекта, нужны быстрые результаты или когда исполнитель, не зная инструментов, изучает технику и предметную область на ходу. Наконец, возможен вариант, когда команда устала от однообразия и нужно привнести драйва, а текущая эффективность никого не устраивает.

«Как человек, имеющий команды разработчиков в штате и работающий с аутсорсерами, согласен, что по Scrum хорошо работать, когда обладаешь штатной командой, а запросы от подразделений меняются по два раза на день», — говорит Дмитрий Тепляков, ИТ-директор компании «Донбасс Арена». Тогда работа спринтами имеет смысл: заказчику сразу выдается небольшой работающий кусок, а он корректирует направление работ. Если заказчику результат не нравится — потеря времени на переделки небольшая.

Но ситуация совершенно иная, когда крупный проект заказывается у аутсорсера. «Как заказчика меня совершенно не устраивает работа по принципу открытого бюджета. Точнее, меня-то она, может, и устроит, но вот финансовый директор будет против», — отмечает Тепляков. В итоге нужно получить хотя бы рамочное понимание затрат, а это по Scrum сделать практически невозможно. А потому приходится идти по стандартной методике, составляя детальное техническое задание и создавая прототип, — по сути классический «водопад».

«Противопоставление фиксированной для реализации задачи («водопад») и нефиксированной (scrum) в корне неверно», — уверен Алексей Лапшин, руководитель проектного сервиса «АйТи». Ни та ни другая методология не отвечают на вопрос, что будет реализовано, а отвечают на вопрос, как будет реализовано и кто для этого нужен. Это как с геометриями Лобачевского и Евклида — вторая является предельным случаем первой. Если установить продолжительность «спринта» во время, отведенное на весь проект, то Scrum превратится в «водопад».

Scrum позволяет лучше контролировать ход проекта и отслеживать проблемы в нем, быстрее получать обратную связь от заказчика и не делать пустую работу. «Водопад» тоже позволяет все контролировать, отслеживать и получать, но для этого требуется много больше усилий и времени.

«Сама методика «водопада» никаким образом не препятствует внедрению гибких методов разработки», — согласен Борис Позин, технический директор «ЕС-Лизинг». Скорее, ему препятствует модель Fixed Price, которая применяется в большинстве случаев, и в госзаказах прежде всего. Таким образом, не надо путать экономику, менеджмент и технику.

Следует рассматривать проекты еще и в таких измерениях, как сложность, масштаб, суммарная трудоемкость. Авторы COCOMO и других методик оценки проектов экспериментально выявили, что производительность труда сильнее всего зависит от опыта работы программистов в конкретной прикладной области и технологической среде, от размера или сложности создаваемого ПО. Подобные важные обстоятельства при обсуждениях гибких методов почти не принимаются в расчет.