Однозначность и постоянство.

Ваши позиция и действия должны быть однозначны. Нельзя указать стоимость своего часа, а затем назвать цену за проект, которая при пересчёте в часы взлетает до небес или наоборот стремится к нулю.

Также ваша почасовая оплата не должна вдруг сменяться на попроектную, ваш официальный тон на дружеский, а заявление «я не рисую порно» в вашем профиле не должно становиться «но для вас сделаю исключение» в личном общении.

Чтобы проект считался удачным, следует решить определенные
задачи: I

· удовлетворить требования заказчика— проект должен выполнить
требования заказчиков и пользователей;

· соблюсти ограничения— разработчики проекта должны уложиться
в финансовые и временные рамки;

· выполнить техническое задание, основанные на требованиях пользователей и заказчика— спецификации — это подробное описание продукта, создаваемое группой для заказчика; они представляют собой соглашение между проектной группой и клиентом и регулируют вопросы, касающиеся приложения, в основе этого требования лежит принцип «сделать все, что обещано»;

· выпустить продукт только после выявления и устранения всех проблем;

· повысить эффективность труда пользователей— новый продукт должен упрощать работу пользователей и делать ее более эффективной;

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

В проектную группу входят такие ролевые кластеры:

· управление программой

· управление продуктом

· разработка

· тестирование

· управление релизом

· удовлетворение потребителя

Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

1. Роль команды разработчиков не может быть объединена ни с какой другой ролью.

2. Избежание сочетания ролей, имеющих предопределенные конфликты интересов.

Работа над проектом начинается с формулирования Технического задания.

Составление ТЗ — репетиция решающей битвы, поэтому составляться оно должно с одной стороны при участии человека, отвечающего непосредственно за утверждение дизайн-макета, а с другой стороны при участии дизайнера или арт-директора. Во-первых, это даст возможность сразу на месте устранить все неясности по ТЗ. Во-вторых, это позволит отчасти понять, чего ждать от человека на том конце и в соответствии с этим скорректировать работу, подготовить презентацию и продумать тактику переговоров. В-третьих, на стадии формирования ТЗ можно как бы между делом убедить клиента отказаться от каких-то ошибочных требований к дизайну, которые будут мешать выработке оптимального решения поставленной задачи.

В процессе разработки необходимо личное общение, при граммтном соталении ТЗ оно сводится к минимому, однако представление готовых макетов необходимо представлять лично, а не по электронной почте. Так как сам заказчик может что-то упустить, чего-то не понять, а так же личное обсуждение проекта дает возможность правильного восприятия выполненной работы.

Есть распространенное мнение, что клиента нельзя «допускать до тела» дизайнера и общаться с клиентом должны специально обученные люди. Это заблуждение. Необходимое и достаточное условие скорейшего принятия дизайн-макета это отсутствие промежуточных звеньев между дизайнером и человеком ответственным за утверждение дизайна.

Звеньев, на самом деле может быть очень много. Идеальный вариант, когда их вообще нет, но такое встречается довольно редко. Эти самые звенья могут быть как со стороны, производящей дизайн, так и со стороны, его принимающей.