К моему восхищению, несколько глав книги посвящены автоматизированному тестированию, которое продолжает встречать активное сопротивление в отрасли.
Запомнить все пять аспектов помогает аббревиатура QUANTS
Стив Джобс сказал: «Отличники нанимают других отличников, но хорошисты нанимают троечников»
Не будьте «начальником» в традиционном смысле: сосредоточьтесь на лидерстве, влиянии и служении команде.
• Делегируйте все, что сможете; не старайтесь сделать все сами.
• Обратите особое внимание на сосредоточенность, направление и скорость работы команды.
Всегда принимайте решения: неоднозначные проблемы не решаются как по волшебству — все они связаны с поиском правильных компромиссов в данный момент и повторными попытками.
• Всегда уходите: ваша задача как лидера состоит в том, чтобы построить организацию, которая автоматически решает целый класс неоднозначных проблем без вашего присутствия.
• Всегда масштабируйте себя:
Вместо этого внимательно определите мячи, которые попадают в верхние 20 %, — критические задачи, которые можете сделать только вы, — и сосредоточьтесь только на них. Позвольте себе уронить остальные 80 %.
эту идею популяризировал президент США Дуайт Эйзенхауэр в своем высказывании в 1954 году:
«У меня есть два вида задач — срочные и важные. Срочные не важны, а важные не срочны»
Главная идея этой главы в утверждении, что разработка ПО — это командная работа. Чтобы добиться успеха в команде инженеров или другом творческом коллективе, нужно организовать свое поведение в соответствии с основными принципами: смирением, уважением и доверием.
Мы твердо верим в решения, основанные на данных, но понимаем, что данные со временем меняются. Поэтому время от времени в течение срока службы системы решения должны пересматриваться. Для долгоживущих проектов важно иметь возможность менять направление после принятия первоначального решения, и лица, принимающие решения, должны иметь право на ошибки. Вопреки стереотипам лидеры, способные признавать ошибки, пользуются большим уважением.
Очевидно, что в программной инженерии, как и везде, хороший выбор ведет к хорошим результатам. Однако на практике эту истину легко упустить из виду. В Google неприемлема фраза: «Потому что я так сказал». В любом нашем обсуждении по любой теме участвуют человек, принимающий решения, и люди, не согласные с этими решениями. Наша цель — согласие, а не единогласие. Это нормально, и я привык слышать фразу: «Я не согласен с вашими метриками/оценками, но я понимаю, как вы могли прийти к такому выводу». В основе этого подхода лежит идея, что всему должна быть причина, а аргументы «просто потому», «потому что я так сказал» или «потому что все так делают» — это признаки плохих решений. Мы всегда должны уметь объяснить и обосновать выбор между затратами двух инженерных решений.
