Маркетолог пишет ТЗ, а секретарша занимается информационной архитектурой

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

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

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

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

Профессионалы в простых проектах не окупаются?

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

Реалии повторного использования кода в современной разработке

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

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

Поддержим отечественного производителя

Делать свою ос, совместимую с чем-то там, это баловство, изобретение
велосипеда, и вообще проеживание государственных денег ничуть не хуже
чем на постройке правительственных дач. Нужно знать что присутствует
на рынке в виде готовых продуктов или технологий, и уметь применить
это в своем бизнесе, или в бизнесе государственных масштабов. А такая
политика что нам иностранного не надо, у нас будет хоть слабенькое и
сырое, но свое, – это нацизм, достойный Гитлера. Прежде чем давить
пиратов, нужно понять, что от этого выйграет конечный потребитель,
ради которого вообще все и происходит. Я как разработчик и управленец
хорошо представляю, что если мой продукт интересен, то его купят,
потому что к этому прилагаются такие необходимые действия как
установка, поддержка, обучение персонала, обновление и т.д., и
огромная толпа халявщиков в России не только не принесет мне убытка,
но наоборот, на каждом углу напишет “а где достать кряк к …”
– “а что это?” – “а это такая программа классная, делает то-то и то-то”.
И лозунг “поддержим отечественного производителя” – огромнейшая
нелепость в этой сфере рынка и профанация для дураков, потому что если
отечественному производителю хочется быть поддержанным – он идет и
продает свой продукт в другие страны, благо что в IT-сфере и через
интернет нет разницы куда продаешь, за исключением некоторых
бухгалтерских проблем, и при этом, замечу, осуществляется ввоз валюты
в страну…

Покажите примеры удачного дизайна, товарищ

На мой взгляд, основной, единственно понятный и легко применяемый критерий правильного веб-дизайна – это “когда в дизайне нет ничего лишнего, кроме логотипа”, т.е. нет ни одного элемента, у которого нет функционального назначения. Например, сайты mail.ru, yahoo.com, tnk-bp.ru этому признаку достаточно полно отвечают.

Когда такие лишние элементы есть, то легко прочитать мысли команды разработчиков и заказчика:

“Вчера я выучил два новых фильтра фотошопа, сейчас попробуем!” – думает дизайнер, читая анекдоты.

“Я не умею структурировать информацию, пусть ребята нарисуют здесь два десятка визуалов, зато будет красиво” – делая серьезное лицо, думает арт-директор.

“Контент? Стандарты юзабилити? Я даже в школе таких слов не слышал. Нам надо чтобы было как у всех – о компании, новости, проекты” – хмуря брови, думает старший менеджер.

“Хочу чтобы вот здесь в уголке вертелся наш логотип” – потирая руки в предвкушении, думает генеральный директор.

Также легко предугадать и мысли будущих посетителей сайта:

“Блин, очередной тупой сайт” – думают продвинутые, вспоминая Кирсанова и Нильсена.

“А слабо было сделать кнопку Пропустить Заставку?” – думают счастливые владельцы выделенных каналов с оплатой траффика, вручную находя и добавляя в избранное ссылку на /index2.php

“М-да, похоже этот сайт надо смотреть с отключенной графикой” – думают модемные пользователи, внося адрес в рекламный фильтр.

“Выложен прайс-лист трехмесячной давности? Похоже, проще им позвонить. Хотя, вот в соседнем окне открылся другой сайт” – закрывая окно, думают потенциальные покупатели…

В чем суть? В анекдоте:
На светофоре остановился мерседес, а по пешеходному переходу идет панк с раскрашенными волосами и обвешанный разными феньками. Из мерседеса высовывается лысая голова с толстыми щеками:
– ты, типа, нафига такой разрисованный весь?
– ну как это, чтобы типа выделяться!
– умом надо выделяться, парень! – говорит лысая голова, поднимая
стекло…