Расширенный поиск

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

Генеральный директор компании «Облакотека» Максим Захаренко.

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

Никита Трундаев, директор по продукту IT-компании NEIRIKA

Без следования определенной модели управления компания не может контролировать сроки решения задач, правильно распределять человеческие ресурсы, за чем также следуют незапланированные расходы. На сегодняшний день в России часть компаний пользуется моделью Waterfall («Водопад»), которая распределяет задачи поочередно друг за другом, является негибкой и строго ограничена в ресурсах. Она уже много лет используется в России и широко применяется на крупных предприятиях и заводах. Другая часть организаций до сих пор не придерживается ни одной из популярных моделей управления, вследствие чего допускается большое количество ошибок, отсутствует контроль и возможность определить сроки и требуемые ресурсы. Лишь единицы применяют agile-подходы для управления корпоративной инфраструктурой IT-компаний. Потенциальными проблемами отсутствия использования agile могут быть: низкая скорость разработки, отсутствие конкурентоспособности, неравномерное распределение нагрузки между сотрудниками, потеря контроля ведения работ, отсутствие явных сроков и понимания итоговой стоимости кампании. В современной рыночной гонке потеря гибкости и производительности может привести к утечке клиентов к конкурентам. Использование грамотной методики управления равноценно правильному подбору персонала и выбору инструментов разработки. Предприниматель должен иметь понимание о том, кто, чем и как выполняет свою работу. Agile со своими спринтами (на них делится календарный график разработки) отвечает за вопрос «как» и способствует упрощению процессов контроля и менеджмента. Agile является основополагающим элементом в целой группе моделей управления. Каждая компания может использовать релевантные для нее подходы в достижении высоких показателей. Гибкость постановки задач и быстрое переключение между различными процессами помогут руководителю менять вектор развития, оперативно вносить изменения и улучшать созданное, стремясь к совершенному продукту.

Светлана Гацакова, директор департамента корпоративных информационных систем ALP Group

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

Третья причина иная. Когда в проекте мы используем подходы agile, происходит очень серьезное вовлечение команд как заказчика, так и исполнителя. При стандартном проектном управлении такой полноты вовлечения добиться крайне трудно или даже практически невозможно, что негативно влияет на проект и может становиться источником серьезных конфликтов. И именно применение подхода agile (в сочетании с DevOps) значительно смягчает, а иногда и полностью предотвращает все эти проблемы.

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

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

Сергей Стрелков, директор по разработке ПО компании КРОК

Гибкость – один из ключевых вызовов бизнесу 21 века. Очевидно, что малая маневренность бизнеса, низкая адаптивность к меняющемуся спросу и уровню сервиса, меняющимся запросам клиента приводит к сокращению числа клиентов, и такой бизнес рано или поздно умирает. Естественная «чистка» рынка происходит постоянно, иного в условиях рыночной экономики быть не может. Даже крупные и, казалось бы, неповоротливые гиганты давно уяснили необходимость как предоставления коробочных решений – для наиболее распространенных запросов и наиболее быстрого начала предоставления услуги, – так и индивидуального подхода к каждому заказчику, чьи задачи не стандартны и требуют качественного осмысления. Кроме того, требование к ИТ-компании, если она планирует оставаться  в топ, — это постоянный анализ уже оказываемых услуг, оптимизация задач клиента и предложение нового, более актуального. Учитывая скорость развития технологий на протяжении последних 10 лет, это условие – просто необходимость для того, чтобы удержать клиента. На рынке выживает лишь тот, кто постоянно изменяется и развивается. Исключением являются монополии. Принципы Agile сложно применять только в случае госконтрактов, так как agile подразумевает гибкость по отношению к техническому заданию, в отличие от нашего законодательства. Однако кое-что можно воплощать и тут. Например, в ходе работы техническое задание может быть детализировано с порождением частных ТЗ, функциональных спецификаций и прочих документов, которые уточняют требования.

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

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

Василий Савунов, agile-Коуч компании ScrumTrek

Работа без agile-подходов в целом эффективна, если у нас небольшие задачи, все работают слаженно и коммуницируют между собой. Это все в какой-то степени agile. Но зачастую мы видим, что в компании идет разделение по отделам специалистов. Есть функциональные колодцы и каждый тянет в свою сторону. Соответственно, решения принимаются долго, а для бизнеса это все выглядит, как черный ящик. Единственное, что они могут попытаться сделать – прийти, пнуть и спросить: когда будет? Им говорят: через неделю. И не делают. Или могут сказать: через полгода. И тоже не делают.

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

Соответственно, да, agile является конкурентным преимуществом, но не «серебряной пулей». Это тоже надо учитывать и каждый случай рассматривать отдельно. Например, если в IT-компании делают какие-то железки, то железная составляющая в данном случае – та часть, которую надо ускорять. И тут речь уже идет не про IT, а про то, как нам вообще контактировать между собой, как ускорять взаимодействие с поставщиками, проведение приемо-сдаточных испытаний, выпуска испытательной партии. Поэтому надо смотреть в каждом случае: в какой степени действительно IT, а в какой – что-то другое. И предлагать конкретные варианты.

Если под корпоративной инфраструктурой подразумевается какой-то технологический ландшафт, то это является одной из составляющих любой IT-разработки (например, автотесты, нагрузочные вещи, сервера и прочие). И если мы хотим ускоряться, а нас это будет сдерживать, то, конечно, нам надо задумываться, в том числе и об agile, но в таком плане: корпоративную структуру технологическую надо подстраивать под конкретную потребность.

Если, допустим, наша корпоративная структура технологическая позволяет выкладывать новые релизы только раз в месяц, а мы делаем результат раз в две недели, то очевидно именно здесь корень проблемы. И надо это исправлять. А если обратная ситуация – когда технологическая инфраструктура позволяет выкладывать релизы раз в день, а принятие решения занимает месяц, понятно, что корпоративная инфраструктура тут совершенно не при чем. И надо думать об организационных моментах на старте.

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

Сергей Баранов, agile-Коуч компании ScrumTrek

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

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

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

Об авторе

Владимир Волков

Белорусский журналист, автор многочисленных публикаций по развитию телекоммуникационной отрасли в Беларуси и России. Работал в "Белорусской деловой газете", информационном агентстве БелаПАН и белорусском портале TUT.BY. Занимается исследованиями в области информационных коммуникаций, преподаватель института журналистики Белгосуниверситета.

Написать ответ

Send this to a friend

Перейти к верхней панели