cRoss_s Сообщение 15/06/2010 13:21 Копия темы
Бизнес-процессы разработки сайта Общая схема процессов разработки сайта

Рис.1, 2

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

Ответственные исполнители
Менеджер по продажам (вместе с менеджером проекта) – выясняет цель проекта, первичные даные, имеющиеся у Заказчика, требования по проекту, ограничения проекта, результаты проекта. Техлидер проекта (техдиректор) формирует объем работ по проекту.

Контроль
Руководитель отдела внедрения, исполнительный директор.

Входящие данные
Все, что может предоставить заказчик, переговоры с заказчиком, выяснение требований заказчика и целей заказчика.

Исходящие данные
Таблицы целей проекта и содержание проекта заполняются в Плане проекта, раздел Содержание проекта. Коммерческое предложение.[v1]

Написание ТЗ по проекту, разработка структуры сайта, сценариев работы с разделами сайта, требований.
Цель
Выявление всех уточненных требований по работе сайта, структуры разделов сайта, описание возможностей разделов сайта, сченариев поведения на сайте.

Ответственные исполнители
Аналитик проекта

Контроль
Менеджер проекта, заказчик.

Входящие данные
Таблицы целей проекта и содержание проекта, коммерческое предложение, запросы с доуточнениями заказчику (копия менеджеру проекта).



Исходящие данные
Техническое задание на сайт согласно ГОСТ. Пример ТЗ – «Приложение 2. ТЗ на разработку.doc» в папке примеров. Архив писем с вопросами и доуточнениями. Примечание: при обсуждении лично, по телефону, ICQ и т.д. после разговора должен отсылаться по e-mail запрос с изложением разговора и просьбой подтвердить правильность описанного.[v2]

Уточненное планирование
Цель
Формирование базовых планов проекта.

Ответственные исполнители
Менеджер проекта.

Исполнители
Техлидер (тех. директор), аналитик проекта, ответственный за дизайн и верстку, тестлидер.

Контроль
Куратор проекта, заказчик.

Входящие данные
Содержание проекта, ТЗ.

Исходящие данные
Заполнение разделов плана управления проектом: управление проектом, Роли и ответственнсти, взаимодействие в ходе проекта, ресурсный план, требования к команде.

Составление: плана управления рисками, структуры работ,[v3] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Разработка макета сайта
Цель
Разработка макета сайта, модели работы разделов, формирование всех необходимых элементов управления сайтом, их видов, необходимых рабочих слоев, проработка юзабилити сайта.

Ответственные исполнители
Дизайнер

Консультанты
Техлидер (тех. директор), аналитик проекта.

Контроль
Менеджер проекта, заказчик.

Входящие данные
Содержание проекта, ТЗ.

Исходящие данные
Модель сайта (макеты страниц) в формате Axure, в HTML.

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v4] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.



Разработка дизайн-макетов
Цель
Разработка графического исполнения страниц модели сайта.

Ответственные исполнители
Дизайнер

Консультанты
Техлидер (тех. директор), верстальщик.

Контроль
Менеджер проекта, заказчик.

Входящие данные
ТЗ, модель сайта.

Исходящие данные
Графические макеты в формате Photoshop, Flash, другие необходимые форматы.

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v5] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Верстка макетов
Цель
Перевод графического исполнения страниц модели сайта в язык разметки HTML.

Ответственные исполнители
Верстальшик

Консультанты
Техлидер (тех. директор), дизайнер.

Контроль
Дизайнер (контроль соответствия), менеджер проекта (сроки).

Входящие данные
Модель сайта, макеты дизайна.

Исходящие данные
Макеты страниц в HTML.

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v6] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Разработка функционала
Цель
Реализация функционала согласно ТЗ и модели сайта.

Ответственные исполнители
Программисты.

Консультанты
Аналитик, дизайнер, верстальщик.

Контроль
Техлидер (контроль соответствия), менеджер проекта (сроки).

Входящие данные
ТЗ, макеты дизайна, верстка.

Исходящие данные
Работающий сайт.

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v7] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Разработка документации пользователя
Цель
Предоставление заказчику полного пакета документов по сайту для обучения и работы редакторов и программистов заказчика.

Ответственные исполнители
Программисты.

Контроль
Техлидер (контроль соответствия), менеджер проекта (сроки).

Входящие данные
ТЗ, макеты дизайна, верстка, программный код.

Исходящие данные
- ТЗ в котором отражено все, что реализовано
- Описание структуры хранения файлов
- Конфигурационные файлы с комментариями
- Исходный код с комментариями
- Описание процедуры переноса сайта
- Описание развертывания сайта
- Требования к платформе хостинга для полноценного функционирования сайта
Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v8] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Тестирование проекта
Цель
Обнаружение ошибок, допущеных при разработке функционала, верстке, внедрении верстки.

Ответственные исполнители
Тестировщик

Консультанты
Аналитик, дизайнер.

Контроль
Тестлидер. В отсутствии – техлидер.

Входящие данные
ТЗ, макеты дизайна, верстка.

Исходящие данные
Список обнаруженных дефектов (багов).

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v9] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Устранение ошибок
Цель
Устранение ошибок, допущеных при разработке функционала, верстке, внедрении верстки.

Ответственные исполнители
Программисты

Консультанты
Аналитик, дизайнер, тестирощик.

Контроль
Техлидер.

Входящие данные
Отчет по багам (список дефектов).

Исходящие данные
Отчет об устранении дефектов.

Дополнительно
Корректировка опорных планов работ по пункту «Уточненное планирование». Составление уточненных: плана управления рисками, структуры работ,[v10] сводного ресурсного плана, ресурсного плана на этап, плана бюджета, плана управления качеством.

Сдача проекта
Цель
Ввод сайта в эксплуатацию.

Ответственные исполнители
IT-специалист, программисты.

Контроль
Техлидер.

Входящие данные
ТЗ.

Исходящие данные
Отчет о развертывании сайта и начале полноценной эксплуатации.

Дополнительно
Документальное закрытие проекта менеджером проектов. Получение отчета о закрытии от техлидера, составление аналитических записок о перерасходе/недорасходе бюджета, соответствии плану по времени, проведение совещания по возникщим проблемам на проекте и их причинам. Предложения по ликвидации таких проблем в дальнейшем.

Вячеслав Великопольский
VelikopolskyV@nologostudio.ru

cRoss_s Сообщение 08/06/2010 17:03 Копия темы
Место «фишечек» на сайте, или роль дизайнера в написании технического задания Предположим, ваш аналитик (или вы, если компания небольшая, и ТЗ пишет сам менеджер) рисует модель. Он собрал все данные, учел все требования заказчика, знает, на какой странице что должно выводиться, как обновляться, какой объем информации и в каком виде должен выдаваться, куда ведут ссылки, какие вообще элементы навигации на странице, в общем, полный пакет требований к страницам у него есть.



Но аналитик – не специалист по юзабилити. Аналитик – не специалист по видам и возможности представления информации. Что мы получим на выходе? Обычные схемы страниц, модели со стандартной отработкой форм, кликов по ссылкам, пейджингов. По которым, если идти буквально по ТЗ, получим скучный, может быть и опрятный, но безликий и обычный сайт. Казалось бы, ну и что? Придет дизайнер, внесет свое видение в проект, придумает хорошие и интересные ходы и все, сайт заиграет новыми красками.

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

Кроме того, в ряде случаев, новые идеи дизайнера могут потребовать (и часто требуют) дополнительного описания того, как же они на самом деле будут работать. Что фактически порождает еще один документ. Представьте себе лидера программистов, который сидит и мучительно сводит два документа в один в своем сознании, чтобы донести до команды, а как же реализовать тот или иной эффект, не потеряв при этом смысл, описанный в ТЗ.

В данном случае, мне видится реализации.

Один, на мой взгляд, наиболее удобный и правильный, подходит, если дизайнер и аналитик сидят недалеко, то есть в ситуации, когда не используются сотрудники на фрилансе. В таком случае аналитик каждую страницу после отрисовки в модели отдает дизайнеру, который, исходя из своего видения, вносит предложения по оптимизации того или иного элемента страницы, предлагает более оптимальное решение. И в конце концов, заказчику предоставляется для утверждения ТЗ уже с прописанными заранее удобными и интересными решениями.

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

Естественно, и в том и в другом случае задание пройдет ряд итераций по согласованию и утверждений со стороны специалистов исполнителя и ответственных лиц заказчика, но в общем виде проводимые итерации видятся мне именно такими.

Кстати, примерно такая же последовательность работ необходима, если сайт изначально оптимизируется под поисковую раскрутку.

cRoss_s Сообщение 04/06/2010 06:03 Копия темы
Написание ТЗ на сайт Введение
Казалось бы, необходимость формализации всех требований заказчика, сведение их в единый документ и оформление его как юридически значимый, очевидно и необходимо для исполнения всеми разработчиками, как компаниями, так и фрилансерами. Каждый наверняка сталкивался с проблемами, связанными с недостаточной ясностью в постановке задачи:
• Невозможность с приемлемой точностью оценить сроки работ, а вместе с тем и их реальную себестоимость, бюджет проекта;
• Двусмысленности в постановке задачи команде разработки, которые часто приводят к неприемлемым результатам на выходе;
• Трения с заказчиком, который, как выясняется, «совсем не то имел в виду»; в конечном итоге это может привести к расставанию с заказчиком, удару по репутации компании и потере денег.
Я думаю, каждый из вас может привести два-три последствия из своей практики. Но описанные выше, на мой взгляд, самые важные.
Конечно, полностью избежать проблем на проекте не удастся, однако можно существенно снизить последствия возникновения одних и вероятность появления других. Как? Отказаться от описания работ по сайту на 4-6 листах и перейти к написанию нормальных, полноценных технических заданий.

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

Цели и задачи проекта
Для начала давайте определимся, чем цель отличается от задачи.
Цель это то, что должно быть достигнуто. Увеличение продаж через интернет, продвижение продукта на рынке – цель. Представление максимально полной информации о товаре/услуге, способах приобретения, реализация онлайн-форм заказа – задачи.
Зачастую заказчик сам путается, что является целью сайта, а что задачей, и что он в итоге хочет получить от ресурса. Иногда даже озвучивает совсем не те цели, которые хочет в действительности. А на выходе получается совсем не то, что он ожидал увидеть.
Необходимо поработать следователем, задавать правильные наводящие вопросы, чтобы выяснить истинное положение дел.

Целевая аудитория
Согласитесь, есть разница между 40-летним топ-менеджером крупного банка и 15-летним школьником. То, что интересно на сайте одному, не нужно другому, то, что привлечет менеджера, абсолютно не интересно школьнику. Одна и та же информация должна подаваться по-разному разным группам людей. И чтобы определить, какие же методы подачи предусмотреть, необходимо понять, а кто будет работать с сайтом?

Материалы и периодика для размещения на сайте, ресурсы для работы с сайтом
Частая ситуация: заказчик хочет форум, FAQ, статьи, новости, рассылки. Но когда сайт готов, оказывается, что ни регулярно обновляющихся материалов, ни людей. Ответственных за регулярное обновление сайта просто нет и не предвидится. И в итоге сайт стоит как заброшенный дом с пустыми и пыльными комнатами. Казалось бы: проблема заказчика. Но ведь в конечном итоге удар за некачественный продукт будет нанесен по вам. Обида заказчика, что он доверился профессионалам, которые сделали все не так, совершенно неприглядный сайт в портфолио, который больше отбивает у вас клиентов, чем приносит, да и просто элементарная профессиональная гордость за некачественно сделанную работу. И все из-за одного незаданного вопроса.

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

Требования к поисковой оптимизации
Прошли времена, когда сайт был просто данью моды. Большинство понимает, что это инструмент привлечения денег. А чтобы сайт привлекал деньги, необходимо, чтобы он был виден, известен.
Наиболее часто используемым и дешевым методом повышения видимости и известности сайта в сети является поисковое продвижение. Но чтобы сайт продвигался, раскручивался, необходимо продумать структуру. В данном случае неоценимой будет помощь SEO-специалиста.

Формирование описания разделов и структуры сайта

Процесс
Мы получили данные. Необходимо их систематизировать, сформировать из них нечто, на основе чего могли бы работать сотрудники, заказчик понял, что мы верно поняли его проблемы, мы получили документ, к которому мы могли бы апеллировать в случае спорных ситуаций. Как это сделать?
Прежде всего нужно составить предварительную карту сайта. Определить количество разделов, их подразделы, взаимосвязи.
Для большей наглядности необходимо схематично отрисовать ВСЕ страницы и разделы (уникальные), их элементы управления, формы, навигацию, блоки и типы информации. Каждая модель страницы, каждый уникальный или типовой элемент должен быть описан. Как работают блоки, куда ведут, какой результат выдают формы, по какому принципу выводится информация на странице. Небольшой пример модели страницы представлен ниже.
После чего на основе описанных разделов необходимо скорректировать карту сайта (не исключено, что в процессе отрисовки модели появятся страницы, которые раньше были просто забыты).
Таким образом мы получаем некий прототип будущего ресурса.


Инструменты
Традиционно для отрисовки модели сайта (разделов сайта) используется Visio, Excel, Photoshop, для карты сайта – Visio или MindManager.
Я рекомендую использовать инструмент Axure (axure.com), который специально разработан для создания прототипа сайтов. Он имеет в своем составе типовые элементы, используемые в web, автоматически строит карту сайта, позволяет существенно ускорить разработку ТЗ и внесение исправлений. Кроме того, он способен сгенерировать работающий прототип сайта с обеспечением эмуляции работы всех элементов страниц. Что крайне удобно при юзабилити-тестировании элементов будущего сайта на фокус-группе. Подобные обследования проводятся редко, однако при разработке крупных порталов настоятельно рекомендуется, так как обилие информации на таких сайтах часто ставит нетривиальные задачи по ее удачному размещению.

Формирование требований к мероприятиям по обеспечению работоспособности сайта при заявленных нагрузках
Формирование требований формируется в основном на основе:
• Расчетной пиковой и средней нагрузке на сайт.
• Скорости загрузки и отрабатывания функциональных блоков сайта.
• Требований к безопасности, защиты от НСД.
На основе этого описывается:
• Конфигурация «железа», на котором размещается сайт.
• Настройки программной части.
• Требования к оптимизации запросов к БД.
• Максимальный вес страниц сайта.

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

Этапы работ
ТЗ является основным опорным документом разработки, и именно в нем, на основе описанных и оцененных работ проставляется этапность, последовательность и сроки проводимых работ, контрольные вехи и критерии успешности их прохождения. Обычно такие графики составляются либо в Excel или в Microsoft Project.

Изменения в проекте и их учет
Большие проекты редко бывают реализованы в том виде, в каком задумывались изначально И изменения – дело обычное. Естественно, при принятии изменений, необходимо вносить изменения в ТЗ, создавая и подписывая новую версию документа со скорректированным содержанием и сроками.
Для учета версий и внесенных изменений рекомендуется вести в конце ТЗ таблицу, где учитывается, когда, кем и в какой раздел было внесено изменение, кто был инициатором, кто утвердил внесение.

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

cRoss_s Сообщение 03/06/2010 11:31 Копия темы
Использование гугл-докс как системы простейшего документооборота для небольших компаний Не секрет, что многие студии используют большое количество внештатных специалистов.
Это могут быть дизайнеры, программисты, тестеры, верстальщики, да кто угодно, кто необходим компании. И в принципе эта ситуация полностью повторяет общую ситуацию в мире, когда коммерция переходит в рамки сетевых компаний, с распределением функций.
И компании, и отдельные фрилансеры могут находиться в других городах, часто даже странах. Коммуникации осуществляются посредством средств связи, благо технологии позволяют.
Однако удаленное общение накладывает определенные особенности на организацию деятельности. В частности оборота документов, организации систем планирования и контроля. Ведь нам необходимо сделать так, чтобы информация вовремя доставлялась партнерам, исполнителям, заказчикам. Необходимо, чтобы велся общий учет данных. Необходимо, чтобы разница часовых поясов не влияла на сдвиги рабочего времени или усложняла коммуникации.
Для всех таких целей есть программное обеспечение, которое способно решить эти проблемы. Но зачастую оно дорогостоящее, и не по карману небольшой веб-студии. Кроме того, для разных целей может использоваться разное ПО, что требует усложненной IT-инфраструктуры.
В своей практике для организации онлайн-документооборота я предлагаю использовать google docs. Конечно это не является полноценной заменой, однако может послужить как промежуточное решение проблемы до того момента, как компания разрастется и сможет позволить себе полноценную инфраструктуру на основе серьезных продуктов.
Для этого можно использовать таблицы, текстовые редакторы, все, чем сейчас располагает гугл докс.
Например для собственно учета проектов может быть использована таблица с несколькими вкладками: такими как проекты, заказчики, исполнители, сотрудники (штатные), поставщики, документы по проектам, документы по поставщикам, потенциальные клиенты.
Как выглядит вкладка «проекты», показано на рисунке 1.
Поля:
• Компания – тут все понятно, у студии есть список клиентов, для которых выполняются работы. Для кого-то одна, для кого-то постоянно, поэтому группировку разумно проводить по названию клиентов.
• Контактное лицо. Контактное лицо берется не просто написанием контактного лица, а проставлением соответствия из вкладки заказчиков (то же самое для других полей). Это делается для того, чтобы не потерять данные. В самом деле, вносим проект, собираемся проставить ссылку на контактное лицо, лезем во вкладку «заказчики», и видим к примеру, что такого контактного лица нет. Тут же его вносим, таким образом данные теряются с меньшей вероятность.
• Собственно название проекта.
• Этапы. Проекты удобно делить на этапы, так как и оплата в ряде случаев, и планирование сроков делается поэтапно.
• Бюджет проекта. Логично разделить его на безнал и нал, особенно фрилансерам-менеджерам, которые зачастую работают не по договору, а с джентльменскими соглашениями. Цветовая индикация определяет оплачен или нет этап.
• Документы. Опять же ссылка из отдельной вкладки «документы», где хранятся перечни документов. Делается такая вкладка затем, чтобы всегда можно было понять, какие документы есть по проекту, и где они в данный момент находятся. Поверьте, такой чет очень полезен, в случае, когда заказчик или вы забыли отправить или получить какие-либо доки.
• Колонки «Менеджер» и «Исполнитель». Собственно ответственное лицо, тот, кто ведет проект. Так же ссылка на либо ячейку вкладки, либо сотрудники, либо исполнители например, в зависимости, штатный специалист используется или удаленщик.
• Тип работы – тут все в общем-то понятно.
• Бюджет на исполнителя. Для простейшего контроля над затратами проекта колонка просто необходима. Кроме того, договоренности о финансах никуда не потеряются.
• Сальдо. Собственно разница между потраченным на работы специалистов и полученным как оплата.
Характеристики других вкладок:
• Заказчики, исполнители, поставщики и сотрудники. В этой вкладке общие две колонки – ФИО и контакты. Для Заказчиков кроме того – компания, для исполнителей – специализация, для сотрудников – специализация и зарплата и премии.
• Документы (поставщики и иосполнители) – компания, проект, список документов (с указанием, где сейчас документ).
• Потенциальные клиенты – особая вкладка. Для учета потенциальных клиентов, с которыми ведутся переговоры. Промеры полей на рисунке 2, в описании они в общем-то не нуждаются, за исключением колонки статуса. Цветовая индикация показывает, в какой стадии переговоры. Например серый – переговоры, красный – отказ, зеленый – договор подписан. Это нужно для анализа так называемой воронки продаж.
Рис. 2
Второй пример использования – фиксирование стандартов разработки, дизайна или верстки. Так как команда распределена, часто могу подключаться новые люди, полезно дать им документ, который поможет им ознакомиться с теми правилами, которые приняты в компании или данной конкретной команде. Это может быть просто текстовый файл или что-то, сделанное на ваш вкус.
Ну и третий – таблица замечаний по проекту, для проведения тестирования. Конечно есть онлайн-задачники, баг-трекеры и прочие возможности учета багов, однако в распределенной команде с большой текучкой и ротацией зачастую трудно привести всех к одному стандарту. А гугл докс доступен всем. Выглядит такой файл так, как показано на рисунке 3.
Рис. 3

Обсуждение бага может идти левее колонки комментария. Цветовая индикация – критичность. Основная сложность – прикрепление файлов. Можно ввести колонки привязки к конкретному исполнителю.

Вот такая вкратце система.
Возможно, у вас есть свои примеры использвания документов гугл в управлении процессами разработки. Или может быть, вы используете другие средства, я буду рад о них узнать.

cRoss_s Сообщение 27/08/2006 09:22 Копия темы
.
Интернет – магазин по продаже аудио- и видеотехники. Доработка под заказчика. Верстка, доработка до полноценного иагазина.
Hi-fi Sounds

cRoss_s Сообщение 08/04/2006 20:02 Копия темы
Аккаунт PRO . Зарегистрировал сегодня аккаунт PRO за $15… и до сих пор меня нигде нет. Письмо администрации написал – ответа нет.
Я так понимаю, предоставлением прав PRO занимается у них не робот.
Т.е. – ждать до понедельника?