Category: Common

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

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

Кто хоть раз видел менеджера, который не может сделать ничего кроме как принести в тех.отдел листы бумаги с записанными от руки пожеланиями клиента, кто хоть раз видел разработчика, который тратит день на поиск ошибки и находит ее в разнице наименований методов 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. Объединяя предыдущие вопросы, можно говорить о уровне абстрактности документа. Если у Вас есть понимание бизнес-модели, и есть хорошие разработчики – обсудите с ними бизнес-модель на словах и договоритесь, что именно будет изложено в документе. Если бизнес-модели нет, и/или разработчики никудышные, то можете писать любую фигню – просто описать в документе что-то вроде:

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