Договорённости — без ссылок

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

Например:

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

В чём проблема со ссылками? В том, что непонятно, какую именно договорённость фиксирует добавленная в документ ссылка, и у сторон могут быть на этот счёт разные мнения.

Вот, допустим, поставили мы ссылку на Дропбокс, и что? Дизайнеры вообще посмотрели, что там? Вникли? Поняли что-то? А как то, что они поняли, отразится на проекте? Потом ещё случайно окажется, что в папку залили не ту версию документа, и весь проект мы смотрели не на то. Из-за ссылки возникает иллюзия договорённости. Клиент думает: «мы им дали все подробные материалы, теперь они всё сделают как надо». Дизайнер думает: «там ещё какие-то ссылки были, надо бы их посмотреть на досуге, вдруг там что-то полезное». В результате клиент считает дизайнера идиотом, который не вник в задачу и не соблюдает договорённости.

Ну или записали ссылки на конкурентов. Дизайнер их посмотрел и составил какое-то своё впечатление; что-то захотел использовать, что-то нет. А клиент потом на любую вещь говорит: «Так а вы что, не посмотрели, как сделано у „Рогов и копыт“?» «Так а в чём проблема как у „Лютика“ нарисовать?» «Да зачем вы изобретаете велосипед, эту задачу отлично уже решили в „АКМЕ“, вы что, не смотрели ссылки, которые я вам давал?». Клиенту что-то понравилось у каждого из конкурентов, и он решил, что мы возьмём каждую из этих вещей (которые нигде не перечислены и ни разу даже не обсуждались) ровно в том виде, как ему понравилось.

Или вот поставили ссылку на страницу сайта «Доси», и написали, что ввод даты должен вести себя так же. Клиент замечает ссылку где-то в переписке о разработке, идёт по ней, ходит по сайту и запоминает: «ок, у нас будет как у „Доси“». Разработчик смотрит сайт и радуется: «о, там стандартный выпадающий календарик из знакомого фреймворка, тоже поставим его». Время проекта подходит к концу, а клиент вдруг спрашивает: «А когда уже заработает трекинг доставки заказов? И я думал мы хотели сделать красивое видеообъяснение работы сервиса» Дизайнеры недоумевают: откуда эти требования вообще взялись? А потом выясняется, что это есть у «Доси», а клиент считает, что мы договорились делать как у них.

Содержимое по любой ссылке ещё и может поменяться, но, как видите, даже без этого проблем хватает.

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

К: Там Маша и Федя собрали большую подборку материалов в Дропбоксе, надо, чтобы вы их изучили и тоже учли при работе. Давайте добавим ссылку в ваше Понимание задачи, чтобы не потерялось!
Д: Простите, я боюсь, что мы что-нибудь там не поймём или упустим. Как бы нам это с самими Машей и Федей обсудить, чтобы они нам рассказали всё, что накопали? И мы тогда в Понимании задачи сразу запишем всё то, что нам нужно сделать в связи с этим.
К: Хорошо, я вас свяжу. Я там вам потом ещё кстати скину ссылки на конкурентов наших.
Д: Насчёт Маши и Феди: давайте тогда быстрее это устроим, чтобы мы докрутили Понимание задачи с учётом всего важного. А про конкурентов — может, давайте вместе сейчас посмотрим? Покажете, что именно вам там нравится и не нравится, и мы выпишем, что там важно. А то вдруг мы там обратим внимание не на то.

Дизайнер и разработчик:

Д: Ещё ввод даты надо сделать как у «Доси».
Р: А в чём там особенность? Чем отличается от нашего обычного календаря из фреймворка, который мы использовали на прошлом проекте? Давай опишем в спеке.