Author: dobryakov

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Десять лет назад, как и сейчас, стоимость последней (самой новой) модели домашнего компьютера составляла 1200 долларов. Ценовая политика осталась прежней. Почему тогда никому и в голову не приходило “жаловаться на переплату”? Ладно бы просто появилось желание купить более дешевую технику для менее ресурсоемких задач, так нет же, люди,
стремящиеся сэкономить, ужаться, купить подешевле, найти на другом конце города магазин, поездка до которого съест всю разницу, эти люди размножаются и заражают своим образом мышления других, вместо того чтобы не мешать им думать своей головой и приобретать просто самую надежную технику в пределах класса. Из ниоткуда в журналах возникло море статей, в сетевых конференциях появились оравы тестеров, бенчмаркеров, файлопомойки заполонили всевозможные попугаеметры, люди стали разводить годовые флеймы и проводить соревнования кто больше попугаев намеряет, производители видеокарт стали подозреваться в специальной заточке своих карт под определенные попугаеметры…

Выброшенные на ветер деньги? При разгоне на пять сотен MHz с одним штатным вентиллятором в БП, иметь 38 градусов на процессоре в условиях 20 одновременно запущенных программ – это не выброшенные деньги, это надежность, которой можно похвастаться.

А принцип – один, как был, так и остался: ставишь на первое место надежность и производительность – будь добр действительно ставить именно их на первое место, а не цену.

А Вы знаете, КАКОЕ ЭТО СЧАСТЬЕ, когда вся группа разработчиков, все несколько десятков человек, используют одинаковый софт, одинаковый зенд, одинаковый навикэт, одинаково понятно называют файлы, таблицы в БД и алиасы таблиц в БД при джойне, классы, методы, константы, переменные, применяют стандартные паттерны программирования, кладут макеты в одинаково названные папки с одинаковыми именами… Когда можно открыть папку X:\Storage\Projects\Sites\KTX\Design\Final\ и быть уверенным в том, что поменяв в строке проводника “KTX” на “ATG” я попаду в папку утвержденных дизайнов проекта ATG… и мне ни за что не придется менять в строке “Design” на “Дизайны”, “Final” на “Full”,
а главная страница называется index.jpg, а не main и не glavnaya – знаете, КАКОЙ это кайф?.. И если мне после всего этого кто-то попытается сказать, что мол стандарты это шняга такая ненужная…

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

И все-таки откуда-то с завидной периодичностью возникают люди, которые переворачивают все с ног на голову и несут ересь в массы. Они делают фигню и гордятся ей, потому что сделали сами. Их мучают и раздирают внутренние комплексы, они стремятся все время доказать что-то себе и окружающему миру. Они проповедуют идею о том, что всему можно
научиться, если купить книжку “Самоучитель” по нужной сфере деятельности, и верят в способности любого человека стать неким универсальным творцом, стоит только захотеть. Они сами не в состоянии понять свои задачи, а тем более донести до разработчиков, и в припадке гнева обвиняют во всем кого угодно, но только не себя.

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

Специалист по логистике будет делать сайт. Менеджер продаж пойдет разгружать вагоны. Генеральный директор будет заниматься версткой, а секретарша будет планировать расстановку мебели в рабочем помещении.

Хорошо, если эта картина не приснится мне ночью.

Очень больной вопрос 🙂 Этот вопрос нормально не решается практически ни в одной российской веб-девелоперской фирме, да и во многих зарубежных тоже. Есть две крайности: одна – следовать стандартам ISO или ГОСТ (если Вам это надо – Вы их найдете), и другая – нарисовать пару схемок на бумажке и отдать программисту. На практике обычно создается нечто среднее, среднего же качества.

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

На практике есть море тонких вопросов:
1. Ваш собственный уровень квалификации. Способны ли Вы оперировать терминологией типа “здесь применяется позднее инстанцирование с обратным вызовом” 🙂
2. Уровень квалификации разработчиков. Если их уровень низок, то даже если вы и напишете про позднее инстанцирование – они все равно нифига не поймут.
3. Основа системы – ядро, движок. Откуда он берется? Это частный продукт, коммерческий продукт, уникальный (еще не написанный) продукт и т.д. – решен ли этот вопрос, или он будет решаться? И кем?
4. Сложность бизнес-модели проекта и уровень понимания этой бизнес-модели. Описана ли она вообще где-то, если проект сложный, или она слишком проста и не описана никак, или вообще отсутствует и не имеет смысла (бывает и такое).
5. Объединяя предыдущие вопросы, можно говорить о уровне абстрактности документа. Если у Вас есть понимание бизнес-модели, и есть хорошие разработчики – обсудите с ними бизнес-модель на словах и договоритесь, что именно будет изложено в документе. Если бизнес-модели нет, и/или разработчики никудышные, то можете писать любую фигню – просто описать в документе что-то вроде:

а) что будет на сайте (перечислить)
б) как Вы хотите управлять этим (описать)
в) как взаимосвязаны материалы сайта
г) как сайт должен реагировать на определенные действия пользователя

Собственно, спорить с очевидным я не буду 🙂 Правильно, здесь не нужен штатный специалист по UI. Но здесь ошибка в другом: в бизнесе практически не бывает линейно возрастающих ценовых категорий услуг, а в IT – особенно. Это вилка, два основных сектора продаж, один из них это низшая ценовая категория, второй – эксклюзив. Золотой середины не бывает. Так вот, принципы организации работы на эти сектора кардинально отличаются друг от друга. Во втором случае – это тщательное планирование, итеративная разработка, техпроцесс и прочее. Но в первом – это должен быть конвейер. Налаженный процесс поставки сайтов, установка и настройка которых (с учетом дизайна) сводится к одному часу работы в рамках штатного функционала. Поэтому, нельзя говорить “вот маленькая веб-студия, в ней программист общается с клиентами, а директор верстает макеты”. Такая студия занимается просто не тем делом, и болтается между двух секторов как цветок в проруби. Процесс в ней организован неправильно, и эта студия обречена либо на прозябание, либо на мощную реорганизацию.