Разница между профессионалом и любителем

То, что вам платят за вашу работу, еще не делает вас профессионалом. В этом посте объясняется ключевое отличие профессионала от любителя.

Перевод статьи: The Difference Between a Professional and an Amateur by Mike Cohn

Профессионал вы или любитель?

Хочу спросить, считаете ли вы себя профессионалом. Но прежде чем я спрошу, а вы ответите, давайте убедимся, что под словом профессионал мы понимаем одно и то же.

Для меня разница очевидна: профессионал делает все, что необходимо для выполнения задачи. Любитель же выбирает только интересное ему.

Пример

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

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

Профессионалы и любители в разработке ПО

Разница между профессионалами и любителями в команде разработки, становится видна, когда появляются люди, которые делают только ту часть работы, которая интересна им.

Это может проявиться на любой роли на проекте. Это может быть тестировщик, который не любит общаться с представителями заказчика (“Это должны делать аналитики”, — говорит он). Или это может быть владелец продукта, который предпочитает думать только о стратегии и больших новых фичах, не вникая в ход реализации текущих задач.

Программист — любитель

Самый распространенный тип любителей, которых я встречал в последнее время, это программисты, которые пишут код в полной точности с поставленной задачей. “Я даю вам именно то, что вы просите”, — говорят они. В некоторых случая ничего плохого в этом ответе, конечно же, нет. Но это работает не всегда.

Профессиональный программист использует в работе все свои знания, опыт и креативность. Когда ему дают задачу, он первым делом задает себе вопросы. А все ли у меня есть для решения этой задачи? Существует ли другое и более правильное решение? Не приведет ли текущее решение к проблемам в будущем?

Затем программист обсуждает эти вопросы с владельцем продукта и только после этого понимает, как будет выглядеть реализация фичи в конечном счете.

Ну а любитель просто скажет: “Хорошо, я сделаю так, как вы просите. Так проще.” Программист-любитель не думает о задаче шире, чем описано в спецификации. Он просто пишет код, как его и просят.

Так же, любитель скажет: “Я только пишу код, я не тестирую.” Ну или он немного протестирует только свой код. Но когда команда будет близка к окончанию спринта и понадобится помощь в тестировании: программист-любитель предпочтет писать код для новых фич, а не заниматься более полезным, но менее приятным для некоторых, тестированием.

Не делать всю работу — роскошь

Не делать всю необходимую работу — это роскошь, предоставляемая только любителям. Любитель может выполнить мощный удар на 300 метров, а затем просто подобрать мяч и не закатывать его в лунку. Любитель может уделить внимание только коду, и не думать о том, что пользователи не получат никакой пользы от этого кода, пока тестировщик не протестирует его неделей позже.

Профессионалы этого делать не могут.

Профессионал знает, что самая важная его задача — делать все возможное, чтобы помочь команде. Часто это означает, что нужно потратить время на обсуждение или заняться менее приятными для сотрудника задачами.

Команда из любителей делает разработку сложной

Трудно быть гибким к команде, в большей степени состоящей из любителей. Любители придерживаются негибких правил “Это не моя работа” и “Я делаю только это”.

Любители предпочитают быть более узкоспециализированными и работать только в рамках этой одной специализации. Безусловно, при таком подходе это может привести к тому, что такие любители сами по себе будут более эффективны, но эффективность всей команды пострадает. (то есть, вся команда будет работать медленней, несмотря на то, что один сотрудник работает быстрее других).

Поэтому, команда из любителей, делает процесс разработки ПО более сложным.