Григорий Добряков

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

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

Но мы обо всем этом скромно умолчим 🙂