Сегодня:

Главнвя. История. Род Аексеевых. Алексеев Н.А. Кащенко П.П. Психиатрия в России. Меценаты строительства. Здравохранение в Москве. Храм больницы. Ландшафт. Фотогаллерея.

КЛИЕНТУРА:

Практика. Впечатления. О себе.

ЮМОР:

Анекдоты. Юмор. Рисунки.

НОВОСТИ:

Сообщение.

Сайт основан 02.10.2000 года.

Обновлено 12.02.2005г.

Избавляясь от управления, ориентированного на фиксированные сроки сдачи, и торга по поводу функций продукта, документальное описание продукта направляет все внимание компании на его качество, которое неизбежно радикально повышается. Качество, в свою очередь, умножает запасы самого бесценного актива компании: лояльности клиентов.
Кто отвечает за качество продукта?
Если за качество продукта отвечает каждый, это означает, что за качество продукта не отвечает никто. Слишком уж легко предположить, что решением проблемы качества займется ваш коллега, пока вы работаете над чем-то еще. Программисты несут ответственность за уничтожение всех дефектов кода. Отдел продаж отвечает за закрытие сделок, а маркетологи - за упаковку и позиционирование. Однако в настоящий момент нет лиц, отвечающих за качество и пригодность продукта. Иногда этим лицам не хватает инструментов, чтобы обнаружить и разрешить проблему.
Иногда не хватает умения, чтобы выразить решение. Иногда у них нет авторитета достаточного для того, чтобы их решение было реализовано. Как мы видели в предыдущих главах, написание кода подрывает способность программиста думать о целях пользователя. Руководителям разработки и без того есть чем заняться, они не могут концентрироваться на деталях поведения продукта. Маркетологам не хватает технической подготовки, и это снижает их способность общаться на технические темы, а значит, подрывает доверие к ним со стороны программистов. При отсутствии тщательно документированного проекта нет надежды на его правильную и эффективную реализацию.
Главная рекомендация этой книги: за качество продукта в конечном итоге должен отвечать проектировщик взаимодействия. Необходимо разрешить ему определять содержание и поведение программы. Он должен работать со списком функций, и даже график разработки, в основном, должен быть на его совести. Он защищает пользователя и должен обладать властью над всеми внешними аспектами продукта.
За всю эту власть проектировщик взаимодействий получает и ряд очень серьезных обязанностей. Без такого сочетания авторитета и ответственности программисты не будут уважать проектировщиков и вернут себе контроль над продуктом. Проектировщики должны быть кровно заинтересованы в успехе. Мандат доверия команды проектирования взаимодействия включает проектирование реальных, простых в применении, привлекательных продуктов, позволяющих пользователям достигать практических целей, не отказываясь от целей личных. Более того, проектировщик взаимодействия должен создавать исчерпывающие письменные спецификации, исходя из которых программисты и будут строить продукт. Проектировщик взаимодействия должен предоставить маркетологам прозрачные описания пользователей и того, как продукт удовлетворяет потребности этих пользователей. И самое важное - он принимает на себя ответственность за качество конечного продукта.
Включение проектирования в процесс
В предыдущей главе мы видели, что многие профессионалы, предлагавшие свою помощь в проектировании взаимодействий, не добились успеха. Речь шла о юзабилити-специалистах, промышленных дизайнерах и других, кто пытался и не смог решить эту проблему. В настоящее время в индустрии не существует группы, способной решить эту проблему.
Ряды проектировщиков взаимодействий медленно пополняются, и здесь следует иметь в виду, что важнее правильно подготовить процесс разработки к включению проектирования, а не нанять самых талантливых проектировщиков взаимодействий. Самое важное - принять решение что программированию будет предшествовать проектирование. Самый блестящий проектировщик мира ничем не поможет, если продукт на следующей неделе переходит на стадию бета-тестирования.
Многие империи, про изводящие программное обеспечение, выросли на усилиях очень молодых и. очень неопытных программистов. Вероятно они получали свободу действий в вопросах программирования, а сочетание невероятной ответственности с безграничными полномочиями часто становится плавильным тиглем, рождающим великие вещи. Те же правила действуют в проектировании взаимодействия. Если человек получает ответственность за качество продукта и соразмерные полномочия, то он может принять на себя эту ношу независимо от своего опыта. Если взять подходящего человека и дать ему полную власть над качеством и поведением продукта, вы получите продукт намного, намного лучший, чем если этого не сделать. Проблема не в людях, но в процессе. Разумеется, при прочих равных всегда лучше нанять специалиста с подходящим опытом. Однако если специалисты не вписываются в бюджет или просто не существуют, менее опытные проектировщики все равно лучше, чем совершенно неподконтрольные программисты.
Что значит быть «подходящим человеком»? Лучше всего подойдет человек, отдаленный от процесса реализации продукта настолько, чтобы он мог легко ставить себя на место пользователя. Это может быть и программист, но определенно не из числа тех, что будут создавать эту программу. Иначе возникает слишком большой конфликт интересов. ..далее 

Неофициальная страница о психиатрической больнице им. Алексеева Н. А.
Персональное спасибо всем медсёстрам, врачам.13 отделения больницы им. Алексеева.
и лично Мозиасу Михаилу Романовичу.