Найдите одно отличие:
Подумаем из-за чего же так может получиться, что мы сдаем не то, что хотел заказчик:
- клиент сам не знает, что хочет
- клиент не следит за тем что происходило по ходу проекта
- клиенту вообще не важно, что ты сделаешь ему - просто осваивает бюджет
- ...
и самая плохая для нас, как для исполнителя, причина - мы облажались!
РЕЗЮМЕ:
В конце любого проекта, заказчик остается либо доволен, либо не доволен.
Наша задача оставлять его всегда довольным, иначе следующий к нам может и вовсе не прийти. Поэтому мы должны сделать все, чтобы клиент становился HAPPY, даже когда пришел к нам абсолютно UNHAPPY, в отчаянии от безысходности. Мы должны понять, "приютить, приласкать, обогреть и обобрать", держать его в курсе, не дать потратить лишних денег, даже если они просто "осваиваются" впустую. И будет нам вселенское счастье, респект и уважуха.
Алексей Булат
Подумаем из-за чего же так может получиться, что мы сдаем не то, что хотел заказчик:
- клиент сам не знает, что хочет
- клиент не следит за тем что происходило по ходу проекта
- клиенту вообще не важно, что ты сделаешь ему - просто осваивает бюджет
- ...
и самая плохая для нас, как для исполнителя, причина - мы облажались!
РЕЗЮМЕ:
В конце любого проекта, заказчик остается либо доволен, либо не доволен.
Наша задача оставлять его всегда довольным, иначе следующий к нам может и вовсе не прийти. Поэтому мы должны сделать все, чтобы клиент становился HAPPY, даже когда пришел к нам абсолютно UNHAPPY, в отчаянии от безысходности. Мы должны понять, "приютить, приласкать, обогреть
Алексей Булат
Сообщения
1 комментарий:
Исходя из вашей картинки, вы всегда получите «unhappy» заказчика (IMHO). Почему?
1. На первых этапах ("инвестор с баблом") заказчик толком не знает чего он хочет. Ну да, конечно, он хочет чтобы "все было клево". Но это очень абстрактные понятия... А разработчикам нужны более конкретные инструкции. Поэтому на 2/3 шаге (sailes и RA) мы начинаем что то додумывать, что то придумывать, а на что то "забИвать". Самое печальное, что если даже очень напрячься, то не удается выдавить из заказчика четких требований. Поэтому разумно делать 2 вещи:
1а) заставлять заказчика постоянно/периодически думать над тем, что же ему нужно (а не только при старте проекта). Ну и конечно же, слушать и слышать эти пожелания.
1б) давать заказчику "пищу для размышлений". Прототипы, моки интерфейсов, анализ аналогичных систем и т.д.
2. Как правило у разработчиков критерии качества совершенно другие ( чем у заказчика). Разработчики следят за техническим совершенством системы, а не за бизнес фичами. Поэтому разумно сделать так, чтобы не только RA думал над бизнес фичами, но и разработчики/тестеры тоже.
Как вариант можно посмотреть в сторону Agile методов – там многие вышеупомянутые проблемы «пофикшены».
Отправить комментарий