AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.11.2009, 15:56   #1  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
? Нормирование труда по сопровождению Аксапты
Являясь руководителем отдела сопровождения аксапты на клиенте, сталкиваюсь с проблемой выработки оптимального метода нормирования работ в системе.
Мне необходимо адекватно поощрять труд моих подчиненных с одной единственной целью: чтобы производительность труда и качество продукта были на высоком уровне. Причем оценивать нужно как программистов, так и консультантов, тех, кто отвечает на звонки, пишет ТЗ, анализирует проблемы...
Читал литературу, искал в инете, но пока окончательной картины для себя не вижу. Мне известны следующие способы:
  1. Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.
  2. Сравнительный. За эталон берем, к примеру, количество произведенного кода за прошлый месяц и сравниваем с текущим, если количество кода возросло, значит производительность увеличилась
  3. Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.
  4. Количественный способ. Утрировано, оцениваем количество строк кода в месяц. Китайские и индусские программисты, я так понимаю, его в основном и используют.
  5. Можно еще количественный превратить в количественно-качественный, задав стоимость в у.е. для типичных операций, например, создание простой таблицы, сложной формы и т.п.
Стоймостной не подходит, так как мы не продаем свою продукцию в чистом виде. Сравнительный грешит тем, что оценивается только количество кода, а не качество. Оценочный уязвим, когда дело доходит до работы, которую в команде еще никто не выполнял. Количественный вообще, на мой взгляд, устарел лет 20 назад. Единственное, что сейчас кажется более-менее приемлемым, это 5-й способ. Но опять же 100 рублей за 3 if'а и 2 select'а при высокой скорости работы метода, сложно сравнить с 200 рублями за 6 if'ов и 4 select'а, которые работают, но с тормозами.
В общем, вопрос для меня не решенный. Может, опыт есть у кого в этом направлении, свои наработки?
__________________
ѣ
Старый 10.11.2009, 16:19   #2  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Берёте месяц для оценки (ни кому не говорите).
Смотрите у каждого какие задачи, сами лезете в код и смотрите каждую задачу как что реализовывалось. Так вы поймёте и сложность самой задачи и качество реализации. Не поверхностно (даже если вы супер пупер), а лезем и смотрим.
Не забудьте приплюсовать информацию о результатах тестирования от консультантов.
Через какое-то время процедуру повторяем.
У консультантов не знаю.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
За это сообщение автора поблагодарили: DSPIC (1).
Старый 10.11.2009, 16:36   #3  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.
Старый 10.11.2009, 16:40   #4  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от ice Посмотреть сообщение
ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.
Над проектом работают все. Как определить степень участия каждого?
Или вы про Аксаптовский проект(модификацию).
Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 10.11.2009, 16:50   #5  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от miklenew Посмотреть сообщение
Над проектом работают все. Как определить степень участия каждого?
Или вы про Аксаптовский проект(модификацию).
Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?
определять команду проекта(не аксаптовский проект). степень участия например поровну, и вводить различные поправочные коэффициенты. если по каждой конкретной модификации, то ведущий разработчик(консультант) в состоянии оценить сложность модификации(анализа) и время.
Старый 10.11.2009, 17:03   #6  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от ice Посмотреть сообщение
то ведущий разработчик(консультант) в состоянии оценить сложность модификации(анализа) и время.
А ещё класно будет если будут идеальные ТЗ.
Всё сразу понятно где и чё.
Я уже наслушался сказок про то, что ведущие могут определить срок.
Исключения сплошь и рядом.
Мелкие да могут. Крупные нет.
Причём времени убьют меньше если увидят уже реализованную задачу.
Просмотр кода занимает минуты.
Поиск сделал по номеру модификации. И вот те весь расклад, какие классы использовались.
Вобщем я не верю, что на то что ведущие могут спрогнозировать может что-то дельное получиться в отношении нормирования.
Прогнозируй пожалуйста, после того как задача закончена.
И смотри разницу своего анализа времени и реального.
PS: А если у автора не хватит на это знаний и умений нефиг вообще в эту тему лезть.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 10.11.2009, 17:07   #7  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
ИМХО проссмотр кода обязателен для проверки качества, а не для оценки сложности.
Старый 10.11.2009, 17:27   #8  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от ice Посмотреть сообщение
ИМХО проссмотр кода обязателен для проверки качества, а не для оценки сложности.
А не надо вникать. Абстрагируйся.
Смотри чё за объект, класс, таблица, метод.
Циклы, ифы нафиг в них вникать.
Если метод показался подозрительным, ну можно конечно и вникнуть.
А так общие снимки просмотрел. И нормалёк.
Естественно если ты думал задача займёт одну строчку коду (к примеру), а она занимает 10. Надо разобраться либы ты не правильно понял и оценил задачу.
Либо косячок.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 10.11.2009, 17:35   #9  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Ключевая фраза "На клиенте".
В фирме-партнере есть достаточно четкое разделение обязанностей между консультантами, программистами, постановщиками задач и т.п. (конечно и в них есть смешение задач но, все таки, есть какой-то контроль над тем, кто чем занимается). Есть ли такое разделение на клиенте? Не беру очень крупные фирмы, где каждый может заниматься своей задачей, беру среднестатистическую фирму в Росиии. Нужен ли на клиенте программист, не знающий бизнес-процессы фирмы? Думая, что нет. Нужен ли на клиенте консультант, который не может в случае возникновения проблем посмотреть в код? Думаю что нет.
Как мотивировать сотрудника на клиенте? Кто его знает, подход должен быть индивидуальный (хотя конечно хочется найти какой-то общий подход, но пока у меня не получилось).
Цитата:
Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.
На клиенте? Мы же не фронт, а бэк офис. Как определить что мы сделали для увеличения выручки?
Цитата:
Cравнительный. За эталон берем, к примеру, количество произведенного кода за прошлый месяц и сравниваем с текущим, если количество кода возросло, значит производительность увеличилась
Есть стар анекдот про секретаршу "Печатаю 300 слов в минуту, но такая ерунда получается". В аксапте бывают случаи, когда две-три строчки кода в нужном месте решают задачу, но найти это место может занять день-два.
Цитата:
Количественный способ. Утрировано, оцениваем количество строк кода в месяц. Китайские и индусские программисты, я так понимаю, его в основном и используют.
Бывает ,что такой способ подходит для нового функционала, но для внедрения в существующий код может сработать, а может нет.
Цитата:
Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.
На клиенте бывают специалисты, которые могут это оценить? Конечно можно привлекать сторонниих экспертов, но как часто это бывает на клиенте?
Цитата:
А на клиенте много ли таких специалистов, которые могут выполнить такую оценку?
Можно еще количественный превратить в количественно-качественный, задав стоимость в у.е. для типичных операций, например, создание простой таблицы, сложной формы и т.п.
Вот это - вариант. Мы обычно подготавливаем описание задания и указываем, сколько бы доработка стоила, если её отдавать на аутсорс (при этом собираем данные о том, сколько просят за эту работу внешние исполнители). Когда руководство видит сумму затрат на доработку, то оно имеет возможность понять что выгоднее - отдавать внешним исполнителям или делать самим. Как раз по сумме разницы можем играть по поводу того, стоит ли выделять бюджет для поощрения своих людей. Если есть экономия по сравнению с внешними исполнителями - есть повод премировать, если внешние исполнители более эффективны - то получай только оклад.

Последний раз редактировалось Raven Melancholic; 10.11.2009 в 17:39.
Старый 10.11.2009, 17:38   #10  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Скажите, у вас есть система оценки работы системы в целом?

Цитата:
Как определить что мы сделали для увеличения выручки?
Для затратных подразделений определяется "что вы сделали чтобы её не уменьшить"

Цитата:
Если есть экономия по сравнению с внешними исполнителями - есть повод премировать, если внешние исполнители более эффективны - то получай только оклад.
Как правило, внешняя ставка, выше внутренней. Но здесь есть нюансы.
В блоге я описывал, тезисы работы внутренней команды.

По-моему мнению, необходимо отталкиваться от работы системы, а не людей, сделавших её Тогда картина будет ясной.

Последний раз редактировалось Vals; 10.11.2009 в 17:47.
Старый 10.11.2009, 17:44   #11  
slava09 is offline
slava09
Участник
Аватар для slava09
MCBMSS
Дети Юза
1C
 
1,642 / 237 (11) ++++++
Регистрация: 06.03.2003
Адрес: Украина, Киев
Я бы предложил такой вариант:

1. Аналитиком формируется ТЗ и ставится в очередь заданий, для задания аналитик выставляет желательный срок выполнения (можно еще приоритет).
2. Руководитель программистов выставляет уровень сложности задания и назначает исполнителя в соответствии с загрузкой и желаемым сроком исполнения
3. Исполнитель (программист) оценивает срок исполнения задания и согласовывает его с руководителем програмистов. В задании фиксируется оценочный срок исполнения.
4. После исполнения задание передается на тестирование и выставляется дата передачи в тестирование
5. Аналитик тестирует задачу и если не принимает то возвращает на исполнение.

Таким образом мы имеем следующие параметры каждого задания:
1. Уровень сложности
2. Оценочное время выполнения, подтвержденное экспертной оценкой руководителя
3. Фактическое время выполнения, зафиксированое системой учета заявок

По каждому исполнителю мы получаем отчет, который показывает абсолютные и относительные (от общего времени) отклонения фактического времени от оценочного, а также некий показатель "Скорректированный уровень отклонения (СУО)", на который влияет сложность задачи. Сложность задачи влияет таким образом: для каждого уровня сложности устанавливается приемлемый уровень отклонения, который "гасит" это разницу в показатале СУО. Например для несложных задача это один день, для средних 3 дня, для сложных 7 дней. Причем этот уровень может устанавливаться индивидуально для каждого программиста в зависимости от его квалификации, стажа работы, личных отношений с руководителем
Статистика по показателю СУО и покажет вам как кто работает.

К сожалению, в моей схеме не учитывается качество кода.
__________________
С уважением Шатохин Святослав.
Старый 10.11.2009, 17:58   #12  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
По поводу мотивации на клиенте пробовал всякие варианты. Но пока получается так, что максимальная мотивация работает в том случае, кода сам являешься фанатом идеи. По принципу "Ребята, можно сделать такое, что все будут рады, вы со мной?". Сделаем - все довольны и это вознаграждается. Не сделали - ну что же, сами виноваты - премия накрылась.
Старый 10.11.2009, 21:08   #13  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Сообщение от ice Посмотреть сообщение
ИМХО смотреть по коду полный бред. можно назначать заранее премию за выполнение проекта в срок, тогда будет стимул, и штрафовать(лишать части премии) за баги.
Ссылку не нашел, но имел место быть следующей эксперимент. Двум группам людей дали одинаковые математические задачи. Одной из групп пообещали достаточно большую премию, за самое быстрое решение задач. Люди из этой группы затратили больше времени на решение задач, чем люди из немотивированной группы.

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

Источник: www.ted.com

p.s. Даже не обращаясь к авторитетным источникам неужели вы сами не чувствуете это на своей шкуре?
За это сообщение автора поблагодарили: _scorp_ (1).
Старый 10.11.2009, 21:13   #14  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Тогда встаёт ещё более сложный вопрос: Как определять сроки модификаций?
Спрашиваем у разработчика, который будет выполнять ее. Потом умножаем на коэффициент, больший единицы и зависящий от разработчика. Коэффициенты для разработчиков подберете в первые несколько месяцев совместной работы

Цитата:
Смотрите у каждого какие задачи, сами лезете в код и смотрите каждую задачу как что реализовывалось.
Не представляю, как можно это осуществить при количестве разработчиков > 5. Разве только самому ничего не делать.

Цитата:
поощрять труд моих подчиненных с одной единственной целью: чтобы производительность труда и качество продукта были на высоком уровне
Причем акцент я бы смещал на качество, а не на производительность. Этак в отношении 1/10. Хорошее качество доработок сегодня залог высокой производительности в будущем, так как снижает затраты на поддержку и развитие функционала.

IMHO, оценка должна быть сугубо личностной, но не обязательно завязанной на одного человека.

Цитата:
Стоимостной способ. Награда программиста прямо пропорциональна выручке с продаж изготовленного программного продукта.
90% программистов не знают и ничего не хотят знать о выручке. Да, я понимаю, что "все здесь собрались, чтобы зарабатывать деньги", но постройте систему мотивации программистов основываясь на марже и вы демотивируете 90% своих сотрудников, которые тут же начнут заниматься халтурой

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

Цитата:
Сравнительный. За эталон берем, к примеру, количество произведенного кода за прошлый месяц и сравниваем с текущим, если количество кода возросло...
... и что это значит ? Это значит только одно - теперь у вас стало больше кода, который вам надо поддерживать. Все - больше это ничего не значит.

Цитата:
Оценочный. Когда эксперт(ы) оценивает сложность задачи на основе своего опыта/знаний.
Угу. В качестве экспертов могут выступать пара руководителей отделов (разработки и консалтинга) + менеджер проекта.

Цитата:
Количественный способ. Утрировано, оцениваем количество строк кода в месяц. Китайские и индусские программисты, я так понимаю, его в основном и используют.
Первое, что в первую очередь вам напишут - это кодогенератор

Цитата:
Но опять же 100 рублей за 3 if'а и 2 select'а при высокой скорости работы метода, сложно сравнить с 200 рублями за 6 if'ов и 4 select'а, которые работают, но с тормозами.
Не мелочитесь, вы же if-ы не как петрушку на базаре продаете.

Цитата:
К сожалению, в моей схеме не учитывается качество кода
То есть, самое главное

Последний раз редактировалось Андре; 10.11.2009 в 21:37.
За это сообщение автора поблагодарили: gl00mie (2), maximka (1), axbegin (1).
Старый 10.11.2009, 22:24   #15  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от Андре Посмотреть сообщение
Не представляю, как можно это осуществить при количестве разработчиков > 5. Разве только самому ничего не делать.
5-10 минут достаточно, чтоб посмотреть и понять, что сделал разработчик за день.
Если ты конечно разработчик хороший.
Ну сколько он за день сделает 5 таблиц 5 форм 5 классов (максимум). Ну и сопутствующая мелочёвка, которую и смотреть не обязательно.
Неужели это сложно просмотреть.
Когда создаёт с нуля пишет больше.
Если модифицирует старый функционал меньше. Значит и смотреть меньше.
Вот и получается 5*10(макс)=50 минут каждый день.
А что вы хотели? Изобрести волшебную кнопку, получить за неё премию и пусть она всё делает. Автор гений. Разработчики счастливы. Клиент доволен.
Ага. Щаз.
Смотреть конечно надо не каждый день, а по завершению задачи.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 10.11.2009, 22:49   #16  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Ну сколько он за день сделает 5 таблиц 5 форм 5 классов (максимум). Ну и сопутствующая мелочёвка, которую и смотреть не обязательно.
Неужели это сложно просмотреть.
Вопрос не в том, что это сложно, а в том, что я не вижу в этом смысла. Лично я предпочитаю смотреть только архитектуру, а точнее обсуждать ее до модификации, а не после того, как она свершилась.

Если мы говорим про code review - то тут здорово помогает автоматическая проверка Best Practices, соблюдения которой последнее время MBS требует от своих партнеров.

Но упаси меня бог оценивать результативность (я предпочитаю это слово) разработчика основываясь на просмотре форм и таблиц - если только на испытательном сроке.

Цитата:
Вот и получается 5*10(макс)=50 минут каждый день.
Разработчик может добавить пару символов в стандартный класс и если детально не владеть данной областью, понадобится немало времени, чтобы оценить последствия модификации.

Цитата:
А что вы хотели? Изобрести волшебную кнопку, получить за неё премию и пусть она всё делает
Я ничего не хотел Меня устраивает работающая схема, основанная на знании сильных сторон людей в команде плюс способность делегировать не только часть работы, но и контроль за ее выполнением.
Старый 11.11.2009, 09:05   #17  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
систему мотивирования в ИТ придумать очень сложно, на каждом предприятии решают ее по-разному, ищется компромис, всегда чем-то жертвуется, в итоге люди подстраиваются под эту систему, постепенно увеличивая свои показатели, но это вовсе не означает, что стали лучше работать, и что система становится лучше, чаще наоборот
Старый 11.11.2009, 09:44   #18  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
http://local.joelonsoftware.com/wiki...86%D0%B8%D0%B8
За это сообщение автора поблагодарили: mazzy (2), raz (1), lev (4), oip (1), maximka (1).
Старый 11.11.2009, 10:58   #19  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Да-да!
Продолжение: http://www.effman.ru/2008-05-19/104
__________________
ѣ
Старый 11.11.2009, 12:23   #20  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Работаю на клиенте рук.проекта, проекта в стадии сопровождения и развития.
Стоит та же задача оценки, предварительно написал такую табличку: показатель и его целевое значение, т.е. к которому нужно стремиться по итогам отчетного периода (скажем, квартал, полугодие, год). Подразумевается, что все показатели измеримые, и сейчас уже есть кое-какая статистика по этим показателям (чтобы было с чем сравнивать - ухудшаются показатели или улучшаются).

Обработка заявок тех.поддержкой
1 Среднее время реагирования на заявку
2 Среднее время закрытия заявки
3 Динамика закрытия заявок (например, закрытие 90% заявок за Х часов, Закрытие 100% заявок за N часов)
4 Среднее ежедневное число заявок, не более
5 Удовлетворенность тех.поддержкой (определяется периодическими опросами пользователей, несколько типовых вопросов, оценки например по 5-ти бальной системе)

Выполнение программных модификаций
1 Исправление ошибок (не более Х часов на каждую)
2 Новый отчет (не более Х часов на каждый)
3 Прочий функционал (не более Х часов на каждый - да, посчитать конечно очень сложно, но берём в среднем за длительный период, а задачи стараемся разбивать на такие модификации, по которым результат можно было бы получить оценить отдельно до окончания задачи в целом).

Отказоустойчивость
1 Число приостановок работы системы (в месяц) для перезагрузки и по прочим техн.причинам
2 Общее время недоступности системы за месяц (в минутах) (от него вычисляется % надежности)
Теги
нормирование, программист

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Шутка над пользователями Аксапты TasmanianDevil Курилка 12 09.04.2010 23:55
Портрет участника 2009: Как сильно модифицировано ваше приложение Аксапты? (в процентах) mazzy Информация для участников 4 09.11.2009 10:57
Российская модель рынка труда gl00mie Курилка 0 18.02.2008 14:59
Хотел вывесить в Рынок труда... komar Курилка 7 18.12.2007 10:38
Администрирование форума в плане "Взлом Аксапты" ans Обсуждение форума 23 18.09.2003 19:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.