Выбор между «что надо сделать» и «как надо сделать»

В процессе неоднократных поисков работы мне постоянно приходилось сталкиваться с всевозможными формальными требованиями к соискателю, причём зачастую, мягко говоря, не вполне обоснованными. Одно дело, когда у крупной коммерческой компании существует отработанная практика работы с 1С и Битриксом, и с этими инструментами работает штат программистов-разработчиков; другое дело, когда эйчары небольшой фирмы принудительно навязывают соискателям будущие методы работы и инструментарий.

Почему я завёл об этом речь?

Главным образом потому, что мне необычайно повезло: в настоящее время я работаю под руководством человека, которому совершенно до фонаря, как будет выполнена задача — ему важно, что она будет выполнена в приемлемые сроки. Выбор методов выполнения и инструментария он оставляет на усмотрение разработчика (то есть на моё усмотрение).

Как это выглядит на практике?

Скажем, требуется разместить на сайте какой-то текст. Мне поступает соответствующая задача, дальше включается мозг и принимается решение, как выполнить эту задачу, на основе выбора из нескольких вариантов. Если тексту предстоит провисеть на сайте несколько лет без изменений — можно просто сверстать страницу в HTML. Если в тексте содержатся динамические параметры (имена пользователей, текущая дата, количество материалов на сайте) — пишется PHP-модуль и добавляется в структуру сайта.

То же самое с изображениями. К примеру, поступает задача: в каждой проценке стоимости кузовного ремонта автомобилей должно присутствовать некое количество превьюшек (картинок маленького размера), которые должны разворачиваться в полноразмерное изображение по клику. Затем следует стандартная формулировка от руководства: «Делай как считаешь нужным». Всё, что волнует моего руководителя — а) результат, и б) время, которое будет затрачено на выполнение задачи. Всё. Приступаю к решению. Нужен водяной знак на каждой фотографии? Фотографии должны быть качественными и масштабируемыми? Вероятно, голого HTML недостаточно, да и ручная прошивки каждой картинки — слишком хлопотно и накладно, а стало быть — PHP-библиотека GD2 и JQuery. Пара дней, и задача выполнена.

В результате, другие компании долго и упорно ищут соискателей непременно со знанием Битрикса, фреймворков, примерами работ на Гитхабе и опытом общения с системами контроля версий — для выполнения тех самых задач, которые в нашем техцентре давно уже решены. Причина простая: «долгоискатели», вместо того чтобы предоставить специалистам список задач и право решать, как их выполнить — предпочли самостоятельно принять решение о том, как нужно решать эти задачи (чаще всего не имея ни профессионального опыта, ни понятия о программном инструментарии, но зато твёрдо зная от знакомого, что Битрикс — универсальное решение во всех случаях жизни).

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

Самое невозможное, немыслимое, в принципе невообразимое для меня на нынешнем месте работы явление — это что-то вроде заявления руководства типа «Обязательно используй для этого JQuery» или «Сделай это на AJAX». Руководство нередко ставит передо мной довольно сложные задачи, но менее всего ему придёт в голову предписывать мне, как их выполнить. Потому как специалист на то и специалист, чтобы принять решение о методах решения задач. Да, вынужден признать, изредка в системе обнаруживаются недоработки, для ликвидации которых приходится сменить один метод на иной (скажем, всунуть упомянутый AJAX вместо Header-редиректа), но всё равно это всегда остаётся на усмотрение разработчика. Невозможно передать словами, сколько времени это экономит в работе и мне, и руководству, и персоналу техцентра.

А причиной — всего лишь выработанный моим руководством принцип «Что нужно сделать?» вместо «Как надо сделать». И разумеется, доверие к своему разработчику (об этом, возможно, речь пойдёт в следующей записи).