Эта простая перемена радикально изменила мой подход к работе. Оказалось, существует много способов говорить. Когда слышишь: «Послушай, это приложение станет в сто раз круче, если мы сделаем все окна круглыми и прозрачными!», можно отвергнуть это предложение как нелепое. Но обычно лучше сначала спросить: «А почему?». Часто существует реальный и убедительный довод, почему этот человек требует круглые прозрачные окна. Например, ведутся переговоры с новым крупным клиентом, у которого комиссия по стандартизации требует эти самые круглые прозрачные окна.
Обычно, ознакомившись с контекстом просьбы, обнаруживаешь, что открываются новые возможности. Зачастую просьба может быть выполнена в рамках существующего продукта каким-то другим способом, что позволяет ответить
Иногда у людей появляются идеи, которые кажутся несовместимыми с вашим видением продукта. Я обнаружил, что в этом случае обычно полезно обратиться с вопросом «почему» к самому себе. Порой сама попытка объяснить себе причину помогает понять ошибочность первой реакции. Если это не так, то можно облегчить ситуацию, включив в обсуждение других ответственных лиц. Помните, что цель всего этого — сказать
Если вы сможете убедительно объяснить, почему предложенная функция не совместима с существующим продуктом, это даст возможность конструктивно обсудить, нужный ли продукт вы создаете. Независимо от результатов обсуждения каждый участник более четко осознает, чем продукт является, а чем не является.
Начинать с
Я работал с программистами, которые в ответ на просьбу посчитать количество строк кода в модуле открывали файлы в текстовом процессоре и пользовались функцией «счетчик строк». То же самое они повторяли через неделю. И еще через неделю. Это было ужасно.
Я участвовал в проекте с неуклюжей процедурой развертывания: требовалось подписать код, скопировать подписанный код на сервер, выполнить множество щелчков мышью. Кто-то автоматизировал процедуру, и этот сценарий запускался сотни раз во время финального тестирования — гораздо чаще, чем ожидалось. Это было замечательно.
Так почему же люди делают одну и ту же работу многократно, вместо того чтобы остановиться и потратить время на ее автоматизацию?
Да, автоматизация тестирования — это классно, но зачем останавливаться на этом? Любой проект изобилует повторяющимися задачами: управление версиями, компиляция, сборка JAR-файлов, генерация документации, развертывание системы и составление отчетов. Для многих из перечисленных задач эффективнее использовать сценарий, а не указатель мыши. Выполнение рутинных задач ускоряется и становится надежным.
Приходилось ли вам участвовать в спорах с коллегами на тему «А на моей машине все компилируется (все загружается из репозитория, все тесты проходят)»? Современные IDE предлагают тысячи настроек, и фактически невозможно гарантировать, что у всех участников команды настройки будут одинаковыми. Системы автоматизации сборки, такие как Ant или Autotools, обеспечивают контроль и повторяемость.
Можно успешно построить систему автоматизации на базе хорошего языка командной оболочки (например, bash или PowerShell). Если требуется взаимодействовать с веб-сайтами, воспользуйтесь такими инструментами, как iMacros или Selenium.
Если ваш процесс требует работы с документами Word, электронными таблицами или графикой, автоматизация действительно может стать сложной проблемой. Но так ли вам необходимы эти форматы? А нельзя ли использовать обычный текст? Значения, разделяемые запятой? XML? Средства генерации графики из текстовых файлов? Часто достаточно немного изменить процесс, чтобы получить хорошие результаты и резко сократить рутинные операции.
