Category: Common

Меня, собственно, вот что огорчает: любой человек, хоть раз в жизни занимавшийся оценкой коммерческой перспективы какого-либо подхода (способа, метода и т.д.), знает, что достоверная статистика составляется только при наличии и положительных, и отрицательных опытов. Рвать на себе рубаху с криками “да я блин десять лет делал сайты, и все работало!” это так же нелепо и глупо, как безымянное заявление на каком-нибудь форуме “за десять лет у меня было два жестких диска Samsung, и ни один из них до сих пор не сломался” по сравнению с официальной статистикой от сервис-центра “за десять лет мы поставили нашим клиентам более 2000 винчестеров Samsung, из них вышли из строя около 5 процентов”.

Практически все менеджеры проектов рано или поздно сталкиваются с явлением профессиональной апатии своих сотрудников. Впервые слово “конфигуратор” в подобном контексте использовал Роберт Шекли в своей известной фантастической повести “Необходимая вещь“. По сюжету, главный герой перед стартом космического путешествия вместо приобретения двух с лишним тысяч запасных деталей по контрольному списку – приобрел аппарат, мгновенно создающий любые мыслимые предметы и механизмы по первому же требованию. Но вот беда – лишь в далеких глубинах галактики обнаружилось, что разработчики заложили в машину черезчур много свободы воли, и ее искусственный интеллект отказывался производить более одной копии одного и того же предмета. Ему было скучно повторяться…

Синдром конфигуратора подстерегает всех тех разработчиков, которые достигли заметных результатов в своей профессиональной деятельности, но не достигли достаточного самоконтроля и самодисциплины. В каком-то смысле это напоминает йогу – развивая себя в творчестве, нужно развивать себя и в плане контролирования своих чувств, эмоций, желаний. Конечно, не до состояния зомби, в котором разработчик выполнял бы поставленные задачи как робот, но до тех пор, когда в его сознании сформируется баланс между реальными коммерческими целями компании и абстрактными задачами дальнейшего саморазвития.

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

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

Команда разработчиков доходит до абсурда: из-за крайнего нежелания переделывать вообще что-либо, сотрудники начинают требовать четко поставленного ТЗ и становятся неспособны к какой-либо аналитической или исследовательской деятельности, которая хоть на долю процента подразумевает выбрасывание части кода (вспомните известное утверждение: “всегда пишите первую версию с учетом того, что ее придется выкинуть в мусорную корзину”). В результате, вместо того чтобы использовать гибкие методики разработки (суть которых – с минимальными трудозатратами реагировать на изменения), разработчики начинают голосовать за четко поставленное ТЗ на годы вперед (что невозможно по определению) и начинают ненавидеть тех, кто вносит любые поправки в процессе разработки…

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

Сначала, дорогой дружок, мы научим тебя все делать через … и лишь потом, после того как ты потратишь полгода на освоение визивига, мы всей толпой соберемся вокруг тебя, чтобы чудовищными усилиями повернуть твое мировоззрение (привыкшее к драг-н-дропу и
копипасту) на то, что структура данных важнее оформления, что есть стандарты, что нужно закрывать тэги, что программирование начинается с написания тестов, а разработка – с правильной постановки задачи. Только не задавай нам, дорогой дружок, вопроса – “КАКОГО … ВЫ МНЕ СРАЗУ НЕ СКАЗАЛИ как надо делать правильно!”

В более клинических случаях мозг уже не способен воспринимать новое, и начинается паника на тему “мне этого не надо! я этого не понимаю! я хочу просто делать простые странички! я боюсь всего нового и непонятного!”

Собственно говоря, меня удивляет, насколько современные “разработчики” (именно так – в кавычках) не понимают, что клиент (не заказчик, а компьютер) имеет полный контроль над получаемым HTML-кодом.

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

Фильтры не только режут баннеры, но и удаляют бэкграунды, заливки-растяжки, жесткие размеры шрифтов и таблиц, переопределения курсора мыши, стили шрифтов и ссылок, яваскриптовые эффекты, скроллинги, выпадающие меню, фоновые и активные звуки… Говоря общими словами, если пользователь захочет, то фильтр может сделать все что угодно, хоть превратить табличную верстку в дивовую 🙂 То, что получается в итоге – чудовищно. Вопрос “почему” – думаю, риторический…

Чтобы сделать бренд, нужно работать и быть профессионалом во всём. Чтобы твоя работа “нравилась людям”, нужно работать и быть профессионалом во всём. Чтобы люди доверяли опыту твоей компании, нужно работать и быть профессионалом во всём. Точка.

Не нужно кривить душой и пытаться свалить все на “некультурность” заказчика – все знают, откуда эта некультурность берется. А берется она, давайте признаемся самим себе, из трусости, неуверенности, некомпетентности разработчика (или менеджера) и отсутствия знаний в предметной области.

Кто хоть раз видел менеджера, который не может сделать ничего кроме как принести в тех.отдел листы бумаги с записанными от руки пожеланиями клиента, кто хоть раз видел разработчика, который тратит день на поиск ошибки и находит ее в разнице наименований методов getCatalogueItems и getCatalogItems, тот знает, что такие фирмы просто обречены “двигать плашки” по странице, перекрашивать цвета и ставить в угол вертящийся логотип…