Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Мощь и удовольствие

Семь раз отмерь | Производство фильмов | Хорошая сделка | Документируйте замысел, чтобы дать ему жизнь | Проектирование влияет на код | Проектировочные документы приносят пользу программистам | Проектировочные документы идут на пользу маркетингу | Кто отвечает за качество продукта? | Включение проектирования в процесс | Откуда берутся проектировщики взаимодействия |


Читайте также:
  1. Дорогое это удовольствие
  2. Если вы стара­тельно будете искать, что доставляет Господу удо­вольствие и удовлетворение, Он, в свою очередь, обеспечит вас тем, что доставляет удовольствие и удовлетворение вам.
  3. Запомните, что для людей гораздо важнее избежать боли, чем получить удовольствие.
  4. И доставлял удовольствие читателям
  5. Мы тщательно готовимся, предвкушая удовольствие.
  6. Надеюсь, что работа с этими ресурсами доставила вам удовольствие и круг ваших друзей расширился, а также вам понравились новые возможности.

 

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

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

Следует четко и ясно дать понять всем участника проекта, что проект – это чертеж, которому необходимо следовать, а не просто предложение. Если приверженность проектированию не демонстрируется энергично и открыто, разработчики будут предполагать, что лишь на них возложена ответственность за создание успешного продукта.

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

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

На команду проектировщиков возлагается ответственность за все, с чем вступает в контакт пользователь. Не только за программное, но и за аппаратное обеспечение. Следует принимать во внимание и сопутствующие программные модули, такие как программы установки.

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

 


Дата добавления: 2015-07-19; просмотров: 52 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Создание команд проектировщиков| Пример налаженного проекта

mybiblioteka.su - 2015-2024 год. (0.02 сек.)