Программист-прагматик. Путь от подмастерья к мастеру
Шрифт:
Некоторые консультанты называют этот процесс "управление ожиданиями" – активное управление тем, что пользователи надеются получить от их систем. Мы полагаем, что это несколько высокомерная позиция. Наша роль заключается не в том, чтобы управлять надеждами наших пользователей. Необходимо работать с ними, чтобы прийти к общему пониманию процесса разработки и конечного результата, наряду с теми ожиданиями, которые еще не выражены словами. Если команда свободно общается с внешним миром, то этот процесс практически автоматизирован; все
Существует ряд методик, которые могут использоваться для облегчения этого процесса. Из них наиболее важными являются "Стрельба трассирующими" и "Прототипы и памятные записки". Обе методики позволяют команде конструировать то, что может увидеть пользователь. Обе являются идеальными способами передать ваше понимание требований пользователей, обедают возможность вам и вашим пользователям практиковаться в общении друг с другом.
Небольшой довесок
Если вы работаете в тесном взаимодействии с вашими пользователями, разделяя их надежды и сообщая им о том, что вы делаете, то при завершении проекта практически не возникнет сюрпризов.
ЭТО ПЛОХО. Постарайтесь удивить ваших пользователей. Заметьте, их не надо пугать, их надо восхищать.
Дайте им немного больше, чем они ожидают. Небольшое усилие, которое потребуется, чтобы добавить в систему некое средство, ориентированное на пользователя, окупится доброжелательностью не один раз.
Прислушивайтесь к вашим пользователям в ходе работы над проектом, чтобы получить намеки на те средства, которые действительно могут их восхитить. Вот некоторые средства, добавляемые без особого труда, которые порадуют среднего пользователя:
• Всплывающая подсказка
• «Горячие» комбинации клавиш
• Краткое справочное руководство в качестве дополнения к руководству пользователя
• Расцвечивание
• Анализаторы журнала регистрации
• Автоматическая инсталляция
• Инструментальные средства проверки целостности системы
• Возможность запускать несколько версий системы в целях тренировки
• Экран-заставка, настроенный для фирмы-заказчика
Все эти вещи относительно поверхностны и особо не нагружают систему. Однако каждый из этих «довесков» говорит пользователям о том, что команда разработчиков позаботилась о создании отличной системы, предназначенной для использования в реальной жизни. Просто не забывайте о том, что работа системы не должна быть расстроена этими нововведениями.
• Неплохие программы
• Стрельба трассирующими
• Прототипы и памятные записки
• Карьер для добычи требований
• Иногда самыми жесткими критиками проекта являются те, кто над ним работал. Случалось ли вам испытывать разочарование, когда ваши собственные надежды не были оправданы тем, что вы создали? Как это могло произойти? Может быть здесь присутствует нечто большее, чем логика.
• Что говорят ваши пользователи, когда вы поставляете им готовую программу? Пропорционально ли их внимание к различным аспектам данной программы усилиям, которые вы в эти аспекты вложили? Что их восхищает?
46
Гордость и предубеждение
Вы восхищали нас довольно долго.
Программисты-прагматики не уклоняются от ответственности. Вместо этого они испытывают радость, принимая вызовы и распространяя свой опыт. Если мы несем ответственность за проектное решение или фрагмент программы, мы делаем работу, которой можем гордиться.
Подсказка 70: Ставьте вашу подпись под работой
В прошлом мастеровые гордились, подписывая свою работу. Вы должны следовать их примеру.
Проектные команды все еще состоят из людей, и это вызывает сложности. В некоторых проектах идея монопольных прав на программу может вызывать трения. Люди могут начать обособляться или не выказывать желания работать над общими фундаментальными элементами. Проект может закончиться феодальной раздробленностью. У вас возникнут предубеждения относительно и вашей программы, и ваших коллег.
Этого-то мы и не хотим. Вы не должны ревниво защищать свою программу от тех, кто вторгается в ее пределы; вы должны платить людям той же монетой и относиться к программам других разработчиков с уважением. Золотое правило ("Поступай с другими так, как бы ты хотел, чтобы они поступали с тобой") и взаимоуважение среди разработчиков является важным для действия подсказки, приведенной выше.
Анонимность, особенно при работе с крупномасштабными проектами, может оказаться благодатной почвой для небрежности, ошибок, лени и неудачных программ. Слишком легко рассматривать себя лишь в качестве винтика в большой машине, высказывая неубедительные извинения в бесконечных отчетах о состоянии, а не просто создавая хорошие программы.
У программы должен быть владелец, но он не обязательно является физическим лицом. Успешный метод eXtreme Programming [URL 45], разработанный Кентом Беком, рекомендует коллективную собственность на программу (но это требует дополнительных процедур типа парного программирования в целях защиты от анонимности).
Мы хотим, чтобы вы гордились правом собственности. "Я это написал, и я стою за своей работой". Ваша подпись должна стать признанным знаком качества. Люди должны увидеть ваше имя в заголовке программы и рассчитывать на то, что она будет солидной, хорошо составленной, проверенной и документированной. Эта должна быть поистине профессиональная работа. Написанная настоящим профессионалом.