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