Category: Common

Десять лет назад, как и сейчас, стоимость последней (самой новой) модели домашнего компьютера составляла 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 – особенно. Это вилка, два основных сектора продаж, один из них это низшая ценовая категория, второй – эксклюзив. Золотой середины не бывает. Так вот, принципы организации работы на эти сектора кардинально отличаются друг от друга. Во втором случае – это тщательное планирование, итеративная разработка, техпроцесс и прочее. Но в первом – это должен быть конвейер. Налаженный процесс поставки сайтов, установка и настройка которых (с учетом дизайна) сводится к одному часу работы в рамках штатного функционала. Поэтому, нельзя говорить “вот маленькая веб-студия, в ней программист общается с клиентами, а директор верстает макеты”. Такая студия занимается просто не тем делом, и болтается между двух секторов как цветок в проруби. Процесс в ней организован неправильно, и эта студия обречена либо на прозябание, либо на мощную реорганизацию.