Управляемая гибкость
Тот, кто халатно относится к документам, рискует потерять деньги в случае разногласий. Мелкие компании обращают на них мало внимания, а крупные могут несколько месяцев согласовывать каждый пункт в договоре. Самое главное на данном этапе – зафиксировать предмет, процесс, риски и ответственность каждой стороны и сделать это достаточно гибко, чтобы было комфортно работать.
С одной стороны, необходимую гибкость может обеспечить создание «рамочного» договора и дополнительных соглашений к нему («заказов»). Такой подход будет удобен в большинстве проектов, но может не применяться в очень крупных организациях или, например, в госкомпаниях.
Вы сможете делить заказы по проектам или отдельным этапам – в зависимости от ситуации.
Рамочный договор и заказы.
С другой стороны, гибкость обеспечивает формулировка предмета разработки: «произведение». Произведением может быть и концепция, и стратегия, и контент. Вне зависимости от того, какие именно будут произведения, не забудьте указать в договоре условия отчуждения прав.
Для таких работ, как поддержка или сопровождение, обычно создаются отдельные договоры с отдельными условиями. При комплексной разработке лучше сразу заказывайте год технической поддержки у того же самого исполнителя или рекомендуемых им компаний.
Гибкий процесс вы сможете обеспечить документально, если зафиксируете часы для получения результатов работ вместо подробных субъективных требований.
Это не значит, что требования совсем не нужны. Просто в некоторых случаях для получения наиболее эффективного результата нужно предоставить исполнителю возможность предлагать различные варианты реализации.
Процесс и результат
Наверное, вы уже поняли, что я рекомендую придерживаться гибкости и свободы в процессе разработки. Однако нельзя не упомянуть самую старую модель, которая называется «каскадной» (или водопадной). Ее используют, когда требования на протяжении проекта не меняются и целесообразно полностью документировать каждый этап.
Применяйте каскадную модель, только если уверены, что со временем ничего менять в проекте не захотите.
Каскадная и гибкая модели. Источник – http://slideshare.net.
Если вы решили работать над проектом по каскадной модели, то в дополнительных соглашениях укажите конкретный результат, который вы планируете получить от разработчика за один или несколько этапов, и количество трудозатрат каждого специалиста.
Результатами этапов водопадной разработки могут быть:
– Схемы процессов или маршрутов пользователя (UML-диаграммы).
– Дизайн-макеты в виде изображений (или формате графических редакторов).
– Графический или текстовый контент (в соответствующих форматах).
– Программный код (размещённый на определённом сервере).
– Готовый функционал (доступный по определённому url).
– Результаты тестирования (отчёты в виде таблиц).
– Инструкции (в текстовом или видеоформате) и т. п.
Современные «гибкие модели» разработки позволяют постоянно менять требования и поэтапно, «спринтами», двигаться к новым целям. Все промежуточные результаты разработки команда создаёт сама и их не нужно документировать. С точки зрения лучших практик гибкой разработки, только то, с чем взаимодействуют пользователи, и является результатом разработки, «произведением».
Исследования, схемы процессов, макеты, и т.д., заставляют команду разработчиков смещать фокус с результата на процесс и плодить «полуфабрикаты», часть которых не принесет коммерческой пользы.
Решив работать по гибкой модели, просто перечислите проблемы и цели пользователей в заказе и дополните их критериями приемки, важными для бизнеса. Не углубляйтесь слишком сильно в детали, чтобы не создавать субъективных ограничений. В следующей главе мы подробно рассмотрим, как формировать функциональные требования и декомпозировать задачи.
Предоставив такую свободу себе и исполнителям, важно не забыть об ответственности с обеих сторон. Обязательно укажите, кто конкретно с вашей стороны и со стороны исполнителя (ФИО, должность, контакты) отвечает за отправку и приёмку результатов, а также требования по срокам и качеству. Не забудьте указать, по каким каналам будет осуществляться передача материалов:
– Электронная почта (укажите все варианты, откуда и куда будет отправляться).
– Онлайн-хранилище (url к папке с материалами).
– Корпоративный таскменеджер (Jira/trello и т.п.).
– Мессенджеры (будьте осторожны: это не самое надёжное хранилище).
– Общая рабочая папка (вы сможете смотреть статистику создания текстовых документов в ней).
– Сервисы шеринга и обсуждения дизайн-макетов (после регистрации вы будете получать статистику по загрузке новых макетов каждый день).
– Системы контроля версий (после регистрации вы сможете видеть объём кода, который пишут разработчики).
Если со сроками всё более-менее понятно, то контроль качества следует проработать отдельно. Включите в требования регулярную публикацию новых материалов по проекту на ваших ресурсах. Если разработчики будут трудиться фултайм, то изменения лучше публиковать два раза в день.
Финансовый вопрос
Может возникнуть ситуация, когда подрядчик откажется передавать еще не оплаченный материал. В таком случае осуществляйте 100% предоплату этапов работ, а закрывающие документы подписывайте после приёмки. Выбирая модель разработки, обратите внимание на схему оплаты. Для каскадной разработки подходит Fixed Price, с предварительным утверждением сметы. А для гибких процессов – удобнее использовать Time and Materials с расчетом стоимости спринтов. Среди крупных компаний набирает популярность схема «выкупа команды разработки». Многие агентства и студии даже предлагают перебазировать своих сотрудников в офис заказчика на время проекта. Это дороже, чем удаленная работа с командой, но результат появится быстрее и будет более качественным.
Бумажная усталость
Вы осилили создание всей необходимой документации – поздравляю! Должен получиться примерно такой комплект:
– Рамочный договор.
– Заказ (с требованиями к результатам 1 итерации).
– Приложения к заказу (гайдлайны, исходный материал, и т.п.).
– Календарный план (в случае водопадной разработки).
– Шаблоны закрывающих документов (при необходимости).
Если вы чувствуете, что «перетягивание каната» в документах накаляет обстановку, попробуйте использовать другой способ договориться о результате – вспомните о целях ваших пользователей.
Совместное обсуждение целей пользователей.
Даже на этапе формирования первичных документов эта тема является ключевой как для вас, так и для разработчиков. Обсудите цели пользователей вместе с подрядчиком и опишите требования к функционалу. Совместное решение проблем пользователей позволяет сфокусироваться на результате до старта работ.
Может показаться, что документация недостаточно проработана и в юридическом плане много рисков. Или не обеспечена гибкость процесса – и придётся работать «по водопадной модели». Но всё это не так страшно по сравнению с ситуацией, когда между вами и разработчиками нет понимания и доверия. Ведь управление проектом – это в первую очередь работа с людьми. Перед подписанием договора обязательно пообщайтесь с командой, или человеком, который будет основным контактным лицом подрядчика. Возможно, вам даже не захочется подписывать договор.
Вы можете изменить решение по выбору процесса разработки, исходя из готовности подрядчика перебазировать к вам офис или приглашать на встречи финальных исполнителей (аналитиков, дизайнеров, программистов). В случае гибкой разработки участие людей, которые непосредственно будут разрабатывать продукт, очень важно, но не все агентства или студии готовы на это пойти. Обязательно решите этот вопрос до подписания договора.
Заметки и истории
Давайте все проговорим
Почему в договоренностях между неопытным менеджером и исполнителем часто возникает недопонимание?Олег Чулаков
Менеджер думает, что он согласовал одни условия, а подрядчик считает совершенно по-другому. Как такое возможно, если при встрече они пришли к согласию? Откуда взялось недопонимание?
Очевидно, что стороны не обсудили многие детали, либо не до конца разъяснили друг другу свои позиции. Но почему так произошло?
На менеджера давят обязательства со стороны клиента и работодателя. Он должен вовремя договориться с поставщиком и сдать проект в срок.
Переговоры начинаются с ключевых сложных моментов. У менеджера есть набор незыблемых условий, которые должны быть согласованы во что бы то ни стало. В противном случае лучше не начинать сотрудничество. Как только этот необходимый минимум согласован, начинается самое интересное.
Менеджер начинает бояться поднимать другие вопросы, ведь это может пошатнуть уже достигнутые договоренности. И другая сторона может внезапно отказаться, а «успех» в переговорах был так близко.
Он боится «провала» переговоров и умышленно закрывает глаза на небольшую недосказанность. Автор берет в кавычки слова «успех» и «провал», потому что нет никакого реального провала или успеха. Все это исключительно в голове менеджера.
Он понимает, что вопросы еще остались, но лучше мы запустим процесс, а потом решим по ходу дела. Иногда такая тактика работает, иногда – нет.
Любой юрист скажет вам, что нужно быть до конца дотошным. И со своей стороны будет прав – такая работа у юриста. Задача менеджера заключается не только в том, чтобы обезопасить себя со стороны документов, но и, самое главное, запустить проект вовремя.
Золотого правила, как действовать в такой ситуации не существует. В общем случае важно чувствовать ту грань, когда подрядчик посчитает вас абсолютным психом и не захочет продолжать переговоры только из-за вашей дотошности к условиям договора.
Тот же бриф
В 2016 году я столкнулся с довольно неприятной ситуацией. Моя компания уже провела тендер на разработку собственного сайта и выбрала исполнителя. Третий месяц тянулся один из первых этапов работ по «водопадному» процессу – разработка эскизных дизайн-концепций.
Дизайнеры нарисовали шесть вариантов эскизов, но бизнес-заказчику ни один из них не нравился. Однажды директор подошла ко мне и спросила: «Дима, может быть, я слишком требовательна, но по-моему, у них получается как-то не очень».
Дизайн действительно был низкого уровня. Создавалось впечатление, будто макеты собрал стажёр из бесплатных шаблонов.
В течение нескольких итераций правок по моим комментариям ситуация незначительно улучшилась: дизайнер рисовал точь-в-точь как я писал, однако признаки низкого уровня так и не исчезли. Это отражалось уже не в идеях, а в технике. На просьбы подключить более сильного дизайнера агентство отвечало какими-то отписками вроде «Пожалуйста, укажите конкретные детали, в чём макеты не соответствует брифу».
В итоге наше терпение лопнуло и мы заказали дизайн-концепцию у другого исполнителя – маленькой студии всего с тремя дизайнерами. И результат не заставил себя долго ждать: уже через две недели эта студия провела нам потрясающую презентацию, а директор радостно восклицала: «Дима, тот же бриф, надо же! Тот же бриф!»