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

Виявляється, розробник працює за методологією 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, але мало ким з нас керує передбачена договором відповідальність за невиконання.