Как Agile помогает IT-подрядчику быстрее поставлять результат, а заказчику лучше контролировать разработку и изменения.
Разбираемся в нюансах, плюсах для заказчика и разработчика, ценностях подхода Agile. Представьте, вы хотите заказать разработку интернет-магазина, сервиса или B2B-портала и выбираете подрядчика. У вас два претендента: IT-компании с похожим опытом.
Каждая со своими плюсами: технологии, команда... Но одна из компаний заявляет преимущество: «Мы работаем по Agile!»
Что значит Agile для заказчика: больше прибыль?
Или больше проблем? Agile - это гибкий подход к разработке программного обеспечения.
Здесь работа разбивается на большое количество мелких этапов - спринтов.
Спринт может длиться от недели до месяца, и итогом каждого спринта является то, с чем клиент уже может работать - инкремент продукта (product increment). С таким подходом заказчику легко контролировать каждый этап работ, а результат получается максимально адаптированным к требованиям рынка.
1. Отсутствие бумажной волокиты С Agile нет необходимости в техническом задании, несмотря на то, что часто ТЗ включает важнейшие блоки по пояснению назначений компонентов и описывает общий план. Да, иногда у заказчика есть желание работать по чёткому ТЗ, особенно на старте проекта.
Но на практике неизбежны корректировки: тут не подписали договор с системой, с которой нужно было сделать интеграцию, зато подписали с другой, но там другая интеграция. А бизнес генерирует новые вводные. Т. е. чтобы работать по техническому заданию, приходится преодолевать сложности: очень тщательно составлять и подписывать его.
На практике, даже если заказчик уверен, что все его требования максимально описаны и понятны, на втором же демо ему придут в голову лучшие решения.
Но включить их в проект можно будет только в том случае, если в оценку временных затрат изначально был заложен большой резерв; тратить бюджет и время на разработку документа, который почти наверняка будет существенно скорректирован; при внесении изменений в ТЗ поддерживать большой слой документации, иначе потом заказчик не пройдёт внутренний аудит (если ТЗ не будет соответствовать реализованному), а исполнитель рискует не получить оплату; не затягивать его написание на многие месяцы.
Крупные клиенты часто не могут утвердить ТЗ - нужно согласование с большим количеством отделов.
Каждый отдел генерирует новые требования и не заинтересован в соблюдении сроков (у них есть более важные дела).
В итоге ТЗ на внедрение разрабатывается долго и уже в процессе разработки устаревает; всё равно придётся устраивать регулярные демо, потому что тестирование всего функционала целиком занимает очень много времени, а лишнего времени обычно нет; вопреки расхожему мнению, разработка по ТЗ, как правило, не выявляет проблемы с качеством, потому что в гибкой разработке вы добавляете инкремент ценности в каждый спринт.
И если количество сценариев с течением времени уменьшается или стоимость спринта увеличивается, это является одним из признаков ухудшения качества (чем хуже качество, тем выше стоимость изменений).
Простота договора: договор говорит о ежемесячной приёмке объёма работ по предоставленной детализации.
Проще договор - быстрее согласование и подписание, при этом документ защищает и исполнителя, и заказчика в равной мере. Процесс - прозрачен.
Заказчик максимально вовлечён, контролирует каждый этап.
Никакой бюрократии и проволочек - решения принимаются быстро.
Продукт быстрее выходит на рынок (в виде MVP), легче адаптируется под запросы потребителей. Прибыль - всегда в фокусе. Цель - быстро получить первую прибыль от MVP и увеличивать её за счёт лучшего удовлетворения нужд клиентов.
Без Agile: есть плановые показатели, которых нужно чётко придерживаться: дата начала проекта; дата окончания проекта; бюджет. Сначала бизнес строит гипотезы о том, каким должен быть идеальный IT-продукт (интернет-магазин, мобильное приложение, B2B-портал…), затем нужно подготовить чёткое техническое задание - по нему будет действовать подрядчик. И уже после сдачи работ подрядчиком бизнес принимает проект в эксплуатацию.
Даже если вы приглашали на промежуточные демо представителей всех отделов, это не поможет: только реальные пользователи начнут задавать реальные вопросы. Но подрядчика уже не интересует, как в действительности будут пользоваться продуктом, - важно обеспечить соответствие ТЗ. Для него главное - выполнить свою часть работы, уложиться в бюджет и сроки. Но что, если техническое задание не учитывало каких-то процессов (а это, подчеркнём, происходит практически всегда)?
За время разработки на рынке появился более выгодный заменитель, активный конкурент, сменились тренды, курс валют и другие факторы.
: здесь размер проекта уменьшается до размера спринта. В результате спринта появляется небольшой функционал, которым уже можно пользоваться. Да, на скорость работы программистов мы повлиять не можем. Но что Agile точно ускоряет, так это релиз минимально жизнеспособной версии продукта (MVP). Выпустить MVP на рынок реально за 1-3 месяца, затем начать корректировать функционал по требованиям бизнеса, на ходу уточняя приоритеты. А значит, получившийся продукт будет лучше соответствовать ожиданиям пользователей.
Как только MVP столкнётся с потребителями, мы сможем быстро увидеть обратную связь и подстроиться под новые требования. В случае нерентабельности мы не будем бездумно штамповать ненужный товар, а изменим его или создадим новый. То же самое касается каждой следующей версии продукта. В переводе с английского Agile означает «проворный», «подвижный», и сама эта система означает гибкость, подвижность, готовность к переменам. Улучшения можно вносить регулярно, а не разово, и с меньшими затратами.
Поэтому качество готового IT-решения максимально адаптировано к требованиям клиента. Это легко отследить не только по отзывам, но и по web-аналитике и анализу юзабилити.
Без Agile: заказчик не видит, что конкретно делают разработчики; готовый продукт, который так долго ждали, может разочаровать.
Если же прервать проект раньше, можно остаться ни с чем, ведь результат планировали получить в самом конце.
Вносить изменения в техническое задание сложно и долго, нужно много согласований - бюрократия.
Иногда составление первоначального ТЗ отнимает столько сил и времени у компании, что переделать его кажется невозможным.
Программисту важно закончить проект в срок, не учитывая стоимость поддержания и изменений в проекте потом.
Это серьёзная проблема проектного подхода.
: в Agile нет проектов с конечными сроками; здесь во главе угла - продукт, и его можно улучшать «маленькими шагами» столько, сколько потребуется.
Но в то же время процесс настолько гибкий, что в любой момент его можно остановить - и на руках останется готовый инкремент, который уже работает и взаимодействует с рынком. Растёт инженерная культура.
Движение в проекте мы считаем условно-бесконечным, поэтому технический долг потом придётся разгребать нам самим.
Это мотивирует делать код изначально красивым и в целом повышает мотивацию подрядчика.
И если большая часть работы направлена на борьбу с техническим долгом, удовлетворённость клиента будет снижаться. В Agile команда разработчиков постоянно общается с заказчиком.
Ежедневно проходят совещания - daily meeting.
Конечно, у заказчика не всегда есть подходящее время - в таком случае мы отправляем ему отчёт для понимания планов на сегодня и фактов, полученных вчера.
Главный проектный риск - это невозврат инвестиций.
Главный способ этого не допустить - попасть в потребность конечного покупателя.
Без Agile: вы готовы несколько месяцев или даже лет тратить деньги на создание продукта, рентабельность которого под вопросом? Помним, что результат при классическом подходе будет виден только в конце. С Agile: фокус команды сразу направлен на цели бизнеса.
Чем чаще выходят новые версии, тем чаще мы получаем ответную реакцию пользователей и/или рынка и делаем всё, чтобы рентабельность росла.
Agile не позволит долго и бездумно тратить силы (а значит, и деньги) на нерентабельные действия.
Цель бизнеса - извлекать прибыль. Программное обеспечение - это часто запутанные системы (по методологии Agile это системы с большим количеством факторов, где причинно-следственные связи непонятны). Для запутанных систем нам важнее быстрее получать обратную связь от реальных пользователей, а на сегодняшний момент можно уверенно говорить, что развитие и управление любым продуктом - запутанная система.
Если же перед вами стоят чёткие и однозначные задачи, вполне возможна работа по классической методологии: ТЗ, сроки, бюджет.
. Заказчик полностью контролирует процесс, а значит, не будет неприятных сюрпризов в конце.
Очень часто корпоративные клиенты задают вопросы о том, как быть с документацией.
Её создание встраивается в спринты как процесс разработки (должна быть документация по задаче - пишем) или как фиксированный пакет часов.
Принципы Agile в IT-разработке помогают нашим клиентам опережать конкурентов и снимать сливки с любого рынка.
Примеры проектов, работа над которыми велась именно по этому методу, вы можете посмотреть в нашем портфолио.
