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

Оказывается, разработчик работает по методологии scrum: работа разбита на итерации (спринты) и для того, чтобы принять в работу новые задачи, он сначала должен закончить задачи из бэклога на текущий спринт.

"Лошадь останется всегда, а автомобиль – это всего лишь новшество, модное увлечение",– такой вот мудрый совет дал президент Сберегательного банка Мичигана адвокату Хорасу Рэкхэму, когда тот собирался проинвестировать в только что появившуюся компанию Ford Motor Co.

Большинство людей крайне негативно относятся к изменениям. У юристов же неприятие изменений – это что-то генетическое. Я начал работать в 2004 году. Адвокат ответчика в моем первом судебном деле предложил написать мировое соглашение от руки. Это не был перерыв в судебном заседании, просто он недолюбливал компьютеры. В 2006 году я застал период, когда юридическая компания общалась с клиентом исключительно бумажными письмами. Я подписывал письмо с отчетом о судебном заседании у партнера, отправлял его клиенту факсом, а затем почтой.

Но ничто так не осовременивает юриста, как клиент. Особенно клиент, который платит.

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

Оказывается, парная работа за компьютером – это одна из методик программирования. Она называется парное (или экстремальное) программирование: один программист пишет код, другой этот код сразу тестирует.

Индустрия информационных технологий привнесла в нашу жизнь кое-что еще – методологию гибкой разработки (a.k.a. Agile methodology).

Вернемся к примеру с юридической фирмой и разработкой веб-сайта. Разработчики в меру профессиональны, но сайт именно юридической фирмы делают впервые. Юридическая фирма также в курсе, что такое веб-сайт, но вот выступает в роли его заказчика впервые. Юридическая фирма попросит сделать обязательно "не хуже, чем у тех парней" ну и, разумеется, успеть к их годовщине.

Для того чтобы устранить дискомфорт от работы с совершенно неизвестным продуктом, стороны поступят мудро. Юридическая фирма настоит на том, чтобы стоимость была фиксированная, а разработчики согласятся, только если эта стоимость будет вдвое выше, чем за тот сайт, который они делали в последний раз.

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

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

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

В 2001 году несколько программистов, плюясь, чертыхаясь и проклиная подобные проекты, написали Манифест, содержащий всего четыре идеи:

– люди и взаимодействие важнее процессов и инструментов;

– работающий продукт важнее исчерпывающей документации;

– сотрудничество с заказчиком важнее согласования условий контракта;

– готовность к изменениям важнее следования первоначальному плану.

"Никто не будет покупать телефон за 599 долларов. И кому вообще нужен такой аппарат без клавиатуры?" – так Стив Баллмер (СЕО Майкрософт) отреагировал на просьбу журналиста поделиться впечатлением от презентации первого iPhone.

Если бы разработчик убедил юридическую фирму работать по этим принципам, то разработка сайта происходила бы так:

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

2. Команды собираются и обсуждают, как же должен выглядеть сайт. Именно на этом этапе устраняются все мемо-генераторы вроде "сделайте нам семь перпендикулярных красных линий, чтобы две были синими, три прозрачные и одна в форме Фемиды".

3. Результаты обсуждения превращаются в перечень "хотелок". Этот перечень еще называют бэклогом. Команда разработчиков сортирует "хотелки" по важности и сложности и согласовывает оценку с клиентом. Тут важный момент: важность и сложность оценивает разработчик. Причем не просто директор говорит своим сотрудникам, сколько времени уйдет на прорисовку дизайна, а вся команда договаривается между собой о том, сколько же времени уйдет у них на тот или иной элемент сайта.

4. Дальше задача разработчика – выбрать из списка ровно столько "хотелок", чтобы успеть их выполнить в течение, скажем, двух недель (это и есть спринт). Математика тут простая: каждый человек работает 8 часов в день; в команде 10 человек. Следовательно, за неделю они сделают ровно столько, сколько можно сделать за 80 часов (вот тут я понимаю, что посягнул на святая святых юристов: работу по ночам и на выходных, извините).

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

6. Дальше команда заказчика смотрит на сайт и удивляется, зачем вообще нужно делать оставшиеся "хотелки", если можно вместо них сделать вот это и еще вот это. Так формируется бэклог для следующего спринта.

7. И так далее.

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

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

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

При Agile-процессе мотивация иная.

Заказчик участвует в работе на всех этапах, и потому в конце его не будет ждать сюрприз. Разработчик заинтересован выполнять работу качественно и в сроки, поскольку от этого зависит продолжение контракта и, в конце концов, его репутация. Но и этого мало для того, чтобы все работало. Основной ингредиент тут – доверие.

Когда мы десять лет ходим к одному и тому же парикмахеру, мы без детального ТЗ доверим ему новую стрижку "как у Джорджа Клуни". И не беда, что у меня два подбородка и ни пряди седых волос. Я знаю, что парикмахер выдавит из моей лысины максимум схожести.

Этот "телефон" имеет слишком много недостатков для того, чтобы всерьез рассматривать его в качестве средства коммуникации. Для нас этот прибор бесполезен. Это дословный текст служебной записки, которая циркулировала в анналах Western Union в 1878 году.

В индустрии информационных технологий Agile крайне популярен. Это не панацея и не единственная религия. Более того, в рамках самого Agile есть несколько разных методик. Самые популярные из них это scrum (очень похоже на то, что я описал выше) и kanban (методология работы с однотипными задачами).

И вот тут у вас должно закрасться сомнение в практической необходимости всей этой информации. Ведь это только индустрии IT касается.

Но не тут-то было. Даже если компания делает сталь, у нее обязательно есть IT-отдел. И этот IT-отдел обязательно убедит руководство купить какой-то настолько особенный софт, что делает его только одна компания, да и та работает исключительно по scrum.

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

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

Кстати, в строительстве есть такой очень похожий на Agile-методологию подход – Integrated Project Delivery. В рамках этого подхода интересы всех участников инвестиционного цикла складываются в единый процесс, направленный на снижение затрат и повышение эффективности на всех стадиях планирования, проектирования и строительства.

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

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