Comments 8
Не так давно прочел книгу: «Алан Купер об интерфейсе. Основы проектирования взаимодействия» (ISBN 978-5-93286-132-5, 978- 0-470-08411-3;). Примерно 700 страниц о том, о чем вы тут написали. Очень рекомендую, книжка поможет разобраться в том, что же такое интерфейс, что такое взаимодействие, что такое ментальная модель, и чего собственно хочет пользователь. Понимая это, и ещё кучу вещей, вы легко определите границу компетенции дизайнера, заказчика и проектировщика (т.е. свою), и сможете концентрироваться в ТЗ на тех вещах, которые действительно важны. Книгу можно купить за рубль на буксах, была ссылка на хабре на акцию, она ещё действует.
А можно чуть более понятным языком — какой именно сайт, ссылку на акцию?
Коль настаиваете: books.ru :) Просто негоже рекламу писать первым комментом… хотя на таких условиях, какая к черту реклама!
Спасибо за комментарий и наводку на книгу. Я про нее слышал, но найти пока не сподобился. Теперь купил, читаю.
Запомнил формулировку «ложное согласие».
Частая проблема менеджеров в том, что они хотят сделать так, как хочет клиент. А не так, как будет лучше для пользователей.
Ну, вообще вопрос клиента, заказчика, пользователя — довольно запутан. Есть проект, где подрядчик делает что-то для заказчика, не имея контакта ни с клиентом (тем, кто платит за продукт), ни с пользователем (тем, кто использует продукт в интересах клиента). Я бывал в разных позициях. Как клиент, могу сказать, что далеко не все интересы пользователя я готов удовлетворять за свой счет. Если меня интересует определенный функционал, меня может мало волновать мнение пользователя (моего сотрудника) о том, насколько ему хочется этот функционал использовать (ему может быть вообще не хочется эту работу делать)
Поэтому не проблема, а задача менеджера проекта, понимать, кто клиент и за что он платит деньги, что должен делать пользователь и в каком случае его нужно слушать, а в каком — отправлять к руководителю за взбучкой. Если же я подрядчик, у меня есть заказчик, который заказывает систему, представляя для меня и клиента, и пользователя, то тут, конечно же, от меня требуется, прежде всего, правильное взаимодействие с заказчиком (т.е. полезные советы, хорошая исполнительность и документальная защищенность от произвола)
Поэтому не проблема, а задача менеджера проекта, понимать, кто клиент и за что он платит деньги, что должен делать пользователь и в каком случае его нужно слушать, а в каком — отправлять к руководителю за взбучкой. Если же я подрядчик, у меня есть заказчик, который заказывает систему, представляя для меня и клиента, и пользователя, то тут, конечно же, от меня требуется, прежде всего, правильное взаимодействие с заказчиком (т.е. полезные советы, хорошая исполнительность и документальная защищенность от произвола)
Sign up to leave a comment.
Менеджер проекта: как дружить с дизайнером и не потерять клиента (или инвестора)