1 ...6 7 8 10 11 12 ...17
Вы осилили создание всей необходимой документации – поздравляю! Должен получиться примерно такой комплект:
– Рамочный договор.
– Заказ (с требованиями к результатам 1 итерации).
– Приложения к заказу (гайдлайны, исходный материал, и т.п.).
– Календарный план (в случае водопадной разработки).
– Шаблоны закрывающих документов (при необходимости).
Если вы чувствуете, что «перетягивание каната» в документах накаляет обстановку, попробуйте использовать другой способ договориться о результате – вспомните о целях ваших пользователей.
Совместное обсуждение целей пользователей.
Даже на этапе формирования первичных документов эта тема является ключевой как для вас, так и для разработчиков. Обсудите цели пользователей вместе с подрядчиком и опишите требования к функционалу. Совместное решение проблем пользователей позволяет сфокусироваться на результате до старта работ.
Может показаться, что документация недостаточно проработана и в юридическом плане много рисков. Или не обеспечена гибкость процесса – и придётся работать «по водопадной модели». Но всё это не так страшно по сравнению с ситуацией, когда между вами и разработчиками нет понимания и доверия. Ведь управление проектом – это в первую очередь работа с людьми. Перед подписанием договора обязательно пообщайтесь с командой, или человеком, который будет основным контактным лицом подрядчика. Возможно, вам даже не захочется подписывать договор.
Вы можете изменить решение по выбору процесса разработки, исходя из готовности подрядчика перебазировать к вам офис или приглашать на встречи финальных исполнителей (аналитиков, дизайнеров, программистов). В случае гибкой разработки участие людей, которые непосредственно будут разрабатывать продукт, очень важно, но не все агентства или студии готовы на это пойти. Обязательно решите этот вопрос до подписания договора.
Почему в договоренностях между неопытным менеджером и исполнителем часто возникает недопонимание?
Менеджер думает, что он согласовал одни условия, а подрядчик считает совершенно по-другому. Как такое возможно, если при встрече они пришли к согласию? Откуда взялось недопонимание?
Очевидно, что стороны не обсудили многие детали, либо не до конца разъяснили друг другу свои позиции. Но почему так произошло?
На менеджера давят обязательства со стороны клиента и работодателя. Он должен вовремя договориться с поставщиком и сдать проект в срок.
Переговоры начинаются с ключевых сложных моментов. У менеджера есть набор незыблемых условий, которые должны быть согласованы во что бы то ни стало. В противном случае лучше не начинать сотрудничество. Как только этот необходимый минимум согласован, начинается самое интересное.
Менеджер начинает бояться поднимать другие вопросы, ведь это может пошатнуть уже достигнутые договоренности. И другая сторона может внезапно отказаться, а «успех» в переговорах был так близко.
Он боится «провала» переговоров и умышленно закрывает глаза на небольшую недосказанность. Автор берет в кавычки слова «успех» и «провал», потому что нет никакого реального провала или успеха. Все это исключительно в голове менеджера.
Он понимает, что вопросы еще остались, но лучше мы запустим процесс, а потом решим по ходу дела. Иногда такая тактика работает, иногда – нет.
Любой юрист скажет вам, что нужно быть до конца дотошным. И со своей стороны будет прав – такая работа у юриста. Задача менеджера заключается не только в том, чтобы обезопасить себя со стороны документов, но и, самое главное, запустить проект вовремя.
Золотого правила, как действовать в такой ситуации не существует. В общем случае важно чувствовать ту грань, когда подрядчик посчитает вас абсолютным психом и не захочет продолжать переговоры только из-за вашей дотошности к условиям договора.
Олег Чулаков
В 2016 году я столкнулся с довольно неприятной ситуацией. Моя компания уже провела тендер на разработку собственного сайта и выбрала исполнителя. Третий месяц тянулся один из первых этапов работ по «водопадному» процессу – разработка эскизных дизайн-концепций.
Читать дальше
Конец ознакомительного отрывка
Купить книгу