Страшный изъян разработчиков

Разработчиков постоянно ставят в трудное положение, но при этом мы не являемся жертвами, хоть самые истеричные из нас и норовят выставить себя оными. Часть нашей ворчливости идет изнутри, это связано с причиной, зашитой глубоко внутри большинства разработчиков. У нас есть ужасный изъян, и заключается он в том, что мы переоцениваем свои знания и возможности.

Этот изъян проявляется по-разному, но чаще всего при оценке времени на задачу. Почти все из моих знакомых разработчиков хронически недооценивают время, которое им нужно потратить на ту или иную задачу. Только самые лучшие из нас способны поставить себе срок и уложиться в него. Большинство обычно ошибаются раза в два, а то и больше. Это происходит из-за того, что, как и любые другие творческие люди, разработчики часто не могут заранее предвидеть все проблемы, с которыми им придется столкнуться.

Даже несмотря на то, что многие разработчики жалуются, что менеджеры продуктов меняют свое мнение, почти никто из них не берет это в расчет во время оценки времени на задачу. Никто не учитывает время на совещания, уточнение требований и возможные изменения. Баги? Да в нашем идеальном коде их и быть не может, тут и беспокоиться не нужно (а если вдруг что, то тестеры же все отыщут, да?). Важные для проекта люди уйдут в отпуск или заболеют? Ничего страшного, кто-нибудь обязательно их заменит.

Все это прямой дорогой ведет к срыву сроков, но ничто так сильно не задерживает проект, как то, что разработчики не учитывают время на изучение проблемной области. Это напрямую связано с нашим главным недостатком. Мы думаем, что уже знаем все, что нам нужно для выполнения задачи, хотя нам часто приходится работать с технологиями, которые мы видим в первый раз в своей жизни. Сроки, которые мы определяем, подразумевают идеальные знания, с которыми мы можем писать ПО как будто бы по икеевской инструкции. На деле же многие задачи требуют от нас детального изучения их подноготной.

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

Компьютерные вузы не готовят вас к испытаниям, которые ждут вас в индустрии. Они в первую очередь дают вам концептуальные знания по большому спектру тем, чтобы вы потом не опозорились, столкнувшись с ними во время настоящей работы. Вас учат переменным, функциям и объектам, так как именно с ними вы будете работать большую часть своего времени. Вас учат базам данных и запросам к ним (хотя нормальные формы окажутся бесполезными на практике). Вы тратите ненормально большую часть времени на изучение алгоритмов сортировки и структур данных, которые во время профессиональной разработки будут скрыты от вас под слоем абстракций. Короче, компьютерные вузы рассматривают решение проблем, которые вам на практике никогда не придется решать. Если мне нужно что-нибудь отсортировать, я просто вызову метод sort(). Если мне нужна очередь или связанный список, я использую нативную реализацию языка, на котором я пишу. Все эти проблемы уже решены за меня.

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

Частично эта проблема возникает из-за нашего такого хрупкого самолюбия. Мы боимся, что если мы установим слишком длинные сроки, то люди поставят под сомнение нашу компетентность. Нам говорят, что «хорошие разработчики» должны работать быстро, и мы с этим поневоле соглашаемся. Меня всегда поражали ситуации, в которых разработчики вначале определяют срок проекта, а потом кто-нибудь из их руководителей начинает жаловаться, что это слишком много. Во-первых, как я уже заметил, срок и так скорее всего слишком маленький. Во-вторых, разработчик должен лучше менеджера знать, сколько времени потребуется на разработку, не так ли? И это приводит к еще одной проблеме.