Помните ту шутку про команду разработчиков из Китая, получающих гонорар пропорциональный количеству написанных строк кода? А может это была и не шутка... На самом деле это не столь важно, ведь нас окружают вещи и куда более необъяснимые.
Что если я скажу вам, что многие программисты, получая оклад, на самом деле оценивают свою собственную работу по тем же самым метрикам, которыми пользуются герои этой истории?
Ну хорошо, строки кода действительно никто не считает. Но вот количество закрытых задач — такое встречается сплошь и рядом.
Окружение меняется быстрее, чем успевает подстроиться под него система координат оценки выполненной работы в голове.
У этой проблемы очень много проявлений:
- новоиспечённый тимлид с обострившимся синдромом самозванца;
- потерянный разработчик, впервые взявшийся за большую R&D задачу;
- демотивированный джун, который в ходе проектирования вдруг понял, что поставленную изначально задачу вообще по какой-то причине делать не нужно.
Удивительно, насколько далеко иногда заходит это ошибочное мышление. Однажды, я услышал от разработчика: "Я считаю, что мне не за что платить зарплату. Я потратил несколько дней на анализ требований и проектирование, но в итоге выяснил, что задача вообще не может быть реализована. Я ничего не сделал". Да нет же, сделал! Ведь иногда позитивный вклад — это отказ от реализации ошибочной задачи.
R&D задачи, столь романтизированные, кажущиеся уставшим от решения бесконечных бизнес-задач разработчикам по-настоящему "техническими", порой оказываются коварной ловушкой. Ведь исследовательские задачи, в отличие от бизнес-задач, как правило не имеют ни начала, ни конца, ни чёткой постановки. Не умея держать в фокусе цель, а в случае её отсутствия определять её самостоятельно, невозможно понять, движешься ли ты в правильном направлении. Ведь иногда позитивный вклад — не в создании артефактов, а в обретении видения.
А как часто начинающих тимлидов буквально съедает ощущение собственной ненужности на проекте. "За неделю я не закрыл ни одной задачи. Совсем код не писал. Я — балласт в своей команде". Быть может и так, но сперва стоит ответить себе на вопрос: так ли уж бесполезно прошли все эти встречи, оценки, проектирования, возня с инфраструктурой, онбординг новых разработчиков в команду, 1-1 и ретроспективы? Ведь иногда позитивный вклад — это организация процесса, позволяющего эффективно работать всей команде.
Именно поэтому столь важно всегда держать в голове максимально широкий контекст происходящего. Ведь ни одной достаточно объективной исчислимой метрики, оценивающей результат работы, просто не существует. Кроме финансовых, но это уже совсем другая история.