Пользователь
0,0
рейтинг
4 июня 2010 в 23:45

7 способов вызвать ненависть разработчика (краткое руководство для заказчиков)

(UPD. Перенесла в ХабраЮмор. Господа, не воспринимайте все так серьезно :-) )

Что делать заказчику, который начинает новый проект с командой разработчиков и хочет оставить по себе долгую и яркую память? Следуя несложным советам этой статьи, вы сможете вызвать самые бурные эмоции за считанные недели даже у совершенно незнакомых людей.

Присылайте требования в файле Excel, а скриншоты ошибок — в Word



Разработчик — счастливый владелец рабочего компьютера образца 2005 года — получит массу удовольствия, пытаясь открыть мегабайтный файл, перекапывая все сто листов требований в поисках двух строк изменений и увеличивая масштаб просматриваемого файла, чтобы рассмотреть скриншот. Желательно также делать скриншоты максимально неинформативными, чтобы ваша приятная переписка подольше не заканчивалась. Еще можно творчески подойти к описанию проблемы, отображенной на скриншоте: лучше всего работает фраза «Посмотрите, пожалуйста!» (не забывайте смертельно обидеться на ответ «Посмотрели!»).


При оформлении таблиц проявляйте креативность



В каждом из нас живет художник. Поэтому если ваша переписка с разработчиком содержит таблицы — обязательно раскрасьте их! Чем больше цветов — тем лучше, и не стесняйтесь радикальных цветовых решений типа черных букв на красном фоне. Ни в коем случае не объясняйте, какой цвет несет информацию, а какой всего лишь призван поведать миру об изумительном оттенке глаз вашей собачки. Шрифты зачеркнутый и жирный курсив, как и ширина документа примерно в две ширины экрана, также доставят немало приятных минут человеку, читающему документ.

Меняйте требования не меньше двух раз в неделю



Это держит разработчика в тонусе. При этом требования должны быть максимально противоречивы, опираться на доселе неизвестные разработчику сущности (таблицы или алгоритмы) и допускать наибольшее возможное число различных толкований. Ах да, на уточняющие вопросы кокетливо отвечайте «А что, что-то неясно? Мы же все написали».

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



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

Требуйте присутствия разработчиков в вашем офисе



Этапы согласования техзадания, тестирования и внедрения — золотая пора в этом вопросе, но и другие этапы работы над проектом позволяют проявить принципиальность. Помните: в офисе заказчика ежедневно должна присутствовать минимум половина команды разработчиков (это требование лучше закрепить в договоре об оказываемых услугах). Что за глупости — «нам надо работать»? Работать можно и у нас, а в нашем офисе нам гораздо удобнее каждый пять минут дергать вас вопросами типа «ну когда же вы наконец это закончите?». И вообще, разработчик должен быть на виду — мы же платим за него!

Никогда не заказывайте для разработчика пропуск



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

Никогда не кормите разработчика



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

Тщательное соблюдение этих правил гарантирует, что ваша команда разработчиков будет вас вспоминать еще долгие, долгие годы. Мы вынуждены, к сожалению, предупредить, что соблюдение этих правил не гарантирует своевременное и качественное выполнение работы, для которой, собственно, вы нанимали команду. Ну что же, нельзя получить все и сразу.
Мария @Nicolette
карма
424,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (94)

  • +98
    • +6
      :-)
      Осталось придумать еще 493 способа — и можно издаваться :-)
      • +2
        Вас никто не обязан облизывать со всех сторон. Вы сами ставите рамки и диктуете правила. Если не так — этому стоит поучиться, а не глотать все, что вам вываливают и жаловаться потом, что вокруг не специалисты, не понимающие вас. Тем более, как я понял, здесь рассматривается фриланс — так это еще большие требования, к себе в первую очередь.
        • +1
          Нет, это не фриланс, обычная офисная работа. Фриланс я бы оговорила отдельно. Я работаю не одна, и правила устанавливаю не я. А так теорию я знаю :-)
          • 0
            Даже если это офис, никто вас не уволит, если вы просто требуете уважения, подкрепляя требования профессионализмом.
    • +2
      Где можно заказать?
    • 0
      +1 :))

      Сцуко, я смеялсо как дитя.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Это как-то сильно радикально, разработчик пошлет кудаподальше и будет прав. Хотя я, право же, не претендую на полноту раскрытия темы :-)
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Или еще круче, утверждать, что ему самому это поправить ничего не стоит, но времени нет. Или тоже весело что он поправил, но теперь все сломалось, и тебе конечно же ничего не стоит вернуть все как было. А еще можно гонять от человека к человеку за разъяснениями, а в результате заявить, что хотели совсем не то, что получили.
  • +85
    В Excel и Word, говорите?

    Пару лет назад мне прислали «изменение требований» в таком формате. Комментарий к рисунку: «Надо переделать!»


    • +4
      О, ну наш шедевр в этой области — комментарий «Посмотрите, пожалуйста». Каждый раз дружно уговариваем получателя ответить «Посмотрели».
    • +34
      Ну как тут не вспомнить :)
      • –6
        Сравнение тёплого с мягким. Глупая картинка.
        • +2
          имхо, тут совсем другое сравнение
      • +13
        Я каждый день работаю с гораздо более мудреным интерфейсом. Сейчас сделаю скриншот… Вот!
        • +14
          а где Insert? О.О!!!
          • –3
            и где кириллица? 0_О
            • +3
              Еще спросите где ссылка на сайт, с которого содрана картинка
          • –1
            А Вы часто пользуетесь Insert'ом? Я вот за последние полгода нажимал только пару раз, и то, чтобы вернуть случайно переключенный режим Insert/Overwrite.
            • +4
              ctrl-insert, shift-insert! (=
              • +1
                А, ну да. Забыл.
                Я просто переучился уже давно на Ctrl+C, Ctrl+V. На моей памяти только один случай, где работали только комбинации с Insert'ом.
                • 0
                  При вставке из буфера в консоль на Linux-е. Постоянно пользуюсь.
            • +1
              FAR — пользуюсь Insert'ом по 200 раз на день, не меньше
        • 0
          А где купить клавиатуру вообще без обозначений? Только «класическую»
  • 0
    > скриншоты ошибок — в Word

    А што, у нас так и делают часто: скриншот со скопированным стектрейсом — в Ворд, а документ крепят к заявке в баг-трекере.
    • +2
      … а ворд зипуют, чтоб «поменьше» был
      • 0
        А все потому, что в винде нет быстрого штатного средства «записать скриншот в картинку в файл»
        • 0
          а пеинт уже не работает?
          • +2
            А ведь belnetmon прав.

            1. PrintScreen
            2. запустить Paint
            3. Ctrl+V (или «Правка» — «Вставить»)
            4. Ctrl+S (или «Файл» — «Сохранить»)
            5. указать имя файла
            6. нажать ОК
            7. получить в итоге BMP, т.к. по дефолту пейнт сохраняет именно в этом формате %)

            Я прошу прощения, но это можно называть как угодно — но только не «быстрым штатным средством» (я даже не упоминаю про то, что этот вариант предполагает наличие у юзера знания того, что после нажатия PrintScreen скриншот попадает в буфер обмена, и что его оттуда можно вставить по Ctrl+V).

            Как по мне, так «быстрое штатное средство» — это как в МакОСи или как в Linux.
            MacOS:
            1. Cmd+Shift+3
            2. картинка на рабочем столе
            (хотя это предполагает наличие у пользователя знания неочевидного сочетания клавиш)

            Linux (конкретно — в GNOME, хотя я уверен, что в KDE делается аналогично):
            1. PrintScreen
            2. нажать кнопку «Сохранить»
            3. картинка на рабочем столе

            Вот это — «быстрое штатное средство», а то, что в Винде — тихий ужас.
            • +1
              Начиная с Vista появилась стандартная тулза «Ножницы» позволяющая захватить любой участок экрана и намалевать на ем что-нибудь маркером.
            • 0
              В KDE практически аналогично: при нажатии PrintScreen запускается апплет KSnapshoot, откуда уже можно сохранить картинку или «перефотографировать» с опциями
        • +11
          Как ни странно есть, ножницы! :)
          PS. Win7.
        • +1
          Есть специальные программы, обзор уже был на хабре.
          • 0
            так говорят же про _штатные_ средства
            специальные программы, как мне кажется, к ним не относится)
            • 0
              prtscr
              win+r
              pbrush
              ctrl+v
              ctrl+s
              • +2
                prtscr
                «сохранить на рабочий стол»
                ;) не win
              • +1
                О да, bmp, мой любимый bmp.
                • 0
                  а выбрать в раскрывающемся списке png или jpeg уже не судьба. ну ну
                  • 0
                    По вашему алгоритму получится bmp.

                    png появился только в win7. И он там по умолчанию. Я буду счастлив, когда 7рка станет общераспространненной виндой, только будет это лет эдак через 5.
                    • 0
                      у меня winXP. на картинке снизу представлен скриншот в формате PNG. то что умолчанию стоит bmp, я и не спорил. я поэтому и сказал «выбрать в раскрывающемся списке png или jpeg». так что ms paint вполне годится для сохранения скриншотов не только в семерке но в XP
                      • 0
                        Да, есть такое. Правда сжатие у него то еще, но есть. По моему был добавлен сервиспаком каким-то?
                        • +1
                          у меня сервис пак 3. paint версии 5.1. по моему и во втором сервис паке PNG был
                    • 0
                      а JPG был вроде уже в ХР?
                      • +2
                        Был. Сжатие там еще умильное.
                  • 0
                    Т.е. плюс ещё одно действие. Итого — 6. А если ещё добавить набор имени файла, то все 7.

                    А теперь сравним, например, с Ubuntu (а также с любым другим дистрибутивом на основе Gnome):
                    1. PrintScreen
                    2. кнопка «Сохранить»

                    Итого — 2. Почувствуйте разницу.
                • 0
                  Мне в клиентской поддержке ISP написали как-то что-то вроде «не прикрепляйте, пожалуйста, cкриншоты в BMP, они слишком долго загружаются»
      • 0
        если бы. Пока на HP Service Desk не поставили ограничение на размер вложенного файла — такие перлы валились.
    • 0
      Ага, и еще рисуют стрелочку в Ворде, развернув Ворд на полный экран.

      Разработчики ж обязательно сидят именно с полноразвернутыми экранами и видят стрелочку, указывающую туда куда надо!
  • +22
    «А еще разместите на нашем Белоруском сайте по продаже обоев прогноз погоды и курсы валют»
    • 0
      Чтобы люди заходили на наш сайт и смотрели прогноз погоды и курс валют, для чего еще же наш сайт предназначен?
    • 0
      Про анекдоты забыли!)
  • +1
    Так и мизантропом недолго стать Оо
    • +1
      А в пятницу в 6 вечера я людей, мягко говоря, недолюбливаю :-) К утру субботы я обычно согласна заключить с ними перемирие, а в субботу вечером возвращаюсь на обычные позиции :-)
    • 0
      Подавляющему числу вольнонаемных это успешно удается.
      Я не исключение, хотя мне везет на вменяемых заказчиков.
  • 0
    Видимо реально достали заказчики…
  • 0
    автор топика Григорий Остер?
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Это расщепление личности, не лечится
    • +1
      а последним нужно что нибудь «мы не знаем какой из вариантов выбрать, что вы подскажете»
    • 0
      Лёгка, клиент присылал именно такое. Причем были скриншоты из меню программы, где НЕмоноширинный шрифт ЕСТЕСТВЕНННО различался по ширине и клиент требовал одинакового размера :)
  • –27
    Заказчики платят деньги. Если вы на эти деньги не можете себе позволить компьютеры новее 2005 года — скорее всего, вам платят мало. Что обычно бывает при низком качестве результата.

    Если заказчик не знает, чего он хочет — значит вы не помогли ему узнать. Это не его, заказчика, проблема.

    В целом, при прочтении данной статьи вспоминается известный комикс про дизайнеров. Типа он д'Артаньян, а все остальные п......., что на самом деле не так.
    • +1
      Если заказчик не знает, чего он хочет — значит вы не помогли ему узнать. Это не его, заказчика, проблема.

      Это, так же, не проблема разработчика, для этого есть менеджер. Разработчик максимум может уточнить какие-то детали у заказчика напрямую.
      • –1
        Из текста создается впечатление, что менеджеры отсутствуют.
        • +1
          Тогда нужно заменить все пункты на один единственный.
          Увольте менеджера и будет у вас 7 лет несчастий.
          • 0
            Это не всегда так. Толковые ПМы — достаточно большая редкость.
    • 0
      Не соглашусь… Хотя я обычно как раз адекватных заказчиков видел, но половина проблем, если не больше — это исключительно вина неадекватных, упертых, твердолобых заказчиков, не желающих элементарно врубить мозги.
      • +2
        Узрите в корень, на самом деле это просто отсутствие достаточного количества денег, желание халявы и неуверенность в окупаемости потраченных средств у тех самых твердолобых заказчиков.
    • 0
      >Если заказчик не знает, чего он хочет — значит вы не помогли ему узнать. Это не его, заказчика, проблема

      аналогично: если заказчик идиот, это не его, заказчика, проблема. и к сожалению, часто так оно и есть. хотя, хороший разработчик должен понимать, когда с этим лучше смириться, а когда лучше прямо послать нахуй заказчика
    • 0
      у меня гиг рамы, 2.2 проц, на кой мне больше? на 2 экрана сидеть в одном AION/WoW/LA2, а в другом на PHP/C++ кодить? Ну извините, я не готов выкидывать деньги только на то, чтобы всего лишь кропать сайты на мощнейшем железе. Я лучше эти деньги на что-то более полезное потрачу.
  • 0
    Ага, рискуйте своей репутацией)
    После таких методов разработчик может легко накатать жалобу начальству на суетливого менеджера.
  • 0
    У меня обычно так происходит:
    Я: вы хотите это, это и это?
    Клиент: да, и чтоб все было как нибудь вот так
    Я: оО, но вы же сами себе противоречите?!
    Клиент: Ну почему, просто я хочу чтоб было…
    Я: Короче, вы сами не знаете что хотите, но хотите чтобы все было супер?)
    Клиент: Угу, поможите?
    Я: Конечно!

    Дословно конечно, но суть именно в этом. После такого как правило клиент выносит мне мозг на 90% меньше)
  • +25
    в тему, из старого:

    А вообще, я очень хочу чтобы наша профессия со временем стала такой же инженерной дисциплиной как например строительство — вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем — СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности — х*й в голове медецина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему… И заметьте, никто не кричит «Судостроители пи… сы не хотят переделать речной трамвайчик в ледокол». Ээээх мечты…
    via
    • 0
      именно, по-этому, необходимо создавать ТЗ, утверждать его с заказчиком, и давать подписать договор, в котором сказано — что изменение утвержденного ТЗ стоит денег.
      • +4
        даже в таком случае заказчик после первой-второй демонстрации ему продукта скажет свою коронную фразу «А вот теперь давайте сделаем… ». И пока заказчик это говорит, разработчик медленно стекает под стол.
      • 0
        И написание ТЗ стоит денег.
        Мы обычно практикуем примерно следующие вещи: бесплатно идет работа по выработке ПЗ (постановка задачи), которая отнимает и время и силы, но позволяет очень четко определить следующие моменты:
        1 — адекватность заказчика
        2 — основных участников проекта со стороны заказчика
        3 — официальных хозяев проекта
        4 — неофициальных хозяев проекта
        5 — основных саботажников проектов

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

        Проект это всегда конфликт, а конфликтами надо уметь управлять.
    • 0
      Конечно делают, и переделывают и за копеечки, еще потому что порог «входа» в профессию очень низок, прочитал пару книжек? Ты уже компьютерщик! Значит можешь ВСЕ! Заказчик тебя в этом убедит.
  • –2
    По-моему у автора топика наболело, особенно судя по последним пунктам :)
  • +2
    Извините, что я на юмор отвечаю серьёзно :) Но все эти проблемы реально решаются договором. Или прямо, или косвенно. Только отношение к нему во многих случаях очень и очень несерьёзное.
    • +1
      Один мой знакомый некоторое время тому назад к договору также взял себе подержанный лексус, часы и пиджак, говорил что все это волшебство работает и действует на клиента как магические чары. Не знаю как сейчас, может уже все по-другому…
  • –3
    А я заказчик :) Причём заказчик такой, что я сам из сферы IT, всегда работал админом, читал книги по проектированию и разработке, статьи на хабре про отношения заказчиков и разработчиков и был как-то на стороне разработчиков. А сейчас, когда столкнулся в реальной жизни с такой задачей, сразу возникло ощущение, что обе стороны разговаривают на разных языках (ну это и понятно), только вот разработчики хотят, чтобы заказчики изучили их язык, а заказчики — наоборот, и правы тут я думаю заказчики, потому что именно они платят деньги и заказывают музыку.
    • +2
      «Хочу по-другому» — вот как выглядит ваше ТЗ на языке заказчиков
  • 0
    А сами пункты (почти все), извините, детский сад, явно показывают, что разработчики не доросли до серьезной работы из-за излишней инфантильности. Бизнес в целом существует не для того, чтобы ублажать какую-либо из сторон, а для зарабатывания денег.

    > Присылайте требования в файле Excel, а скриншоты ошибок — в Word
    Почему нет? У заказчика это основные бизнес-приложения, и ради единственной необходимости пообщаться с разработчиком ему нужно изучить новые продукты? А если скриншоты и требования делают те, кто сильно далек от проекта, а его в рамках тестирования попросили на досуге проверить как всё работает в жизни?

    > При оформлении таблиц проявляйте креативность
    Просто попросите объяснить, что это всё значит. Какой-то смысл точно закладывался, просто тот кто это делает не знает как по-другому выразить свои мысли. Тут два варианта: либо помогите научиться, либо научитесь расшифровывать. Либо отпустите проект.

    > Меняйте требования не меньше двух раз в неделю
    С этим полностью согласен. Единственное, что можно добавить — частая смена требований может быть показателем того, что плохо проведён этап анализа и выяснения потребностей.

    > Назначайте тестирование и внедрение продукта на летнее время
    И? В это время у большинства компаний действительно спокойная пора и можно смело внедрять что угодно не опасаясь нарушить работу большого количества людей. Вам не нравится? Оговорите заранее, что вы предпочитаете внедрять новые разработки ТОЛЬКО в периоды максимальной загрузки, желательно начинать в момент подготовки финансовых отчётов (сарказм).

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

    > Никогда не заказывайте для разработчика пропуск
    :) Чисто процедурный момент, в офисе у заказчика неразбериха, которую вы возможно и автоматизируете своим проектом, так позаботьтесь о себе заранее — попросите пропуск на всё время разработки, напомните об этом, и вообще нужно проявлять настойчивость и даже наглость в таких вопросах, а не обсуждать потом на хабре, какие уроды, даже пропуск не выписали, а вы так негодовали. Заказчик этого негодования даже не заметит, а заметив рассмеётся «И все? Такая мелочь помешала внедрению проекта? Ха-ха, Олечка, выпиши этому забавному человеку пропуск до конца года.»

    > Никогда не кормите разработчика
    А может ещё в туалет водить? Купите себе бутерброд с куском мяса в два раза толще. Тем более, что сотрудники пьющие чай посменно, сами себе его и купили.
    • +2
      Ну так вот в том-то и проблема. Прочитав авторский пост и ваш ответ, можно сделать один глубокомысленный вывод… Правы все, но каждый по-своему! Каждый банально думает о себе, тянет одеяло в свою сторону, попутно высмеивая второго, и находит кучу причин собственной правоты и долбанутости и твердолобости всех оставшихся. Семейный спор, мужчина и женщина! Ситуацию осложняет только то, что один из них имеет на то право( или думает так). Заказчик, потому что у него деньги. Женщина, ну как правило потому, что она женщина & nuff said.
      • 0
        А если разработчик — женщина? :-)
    • 0
      >> Присылайте требования в файле Excel, а скриншоты ошибок — в Word
      >Почему нет? У заказчика это основные бизнес-приложения,

      т.е. набрать требования в Ворде религия не позволяет?

      >> При оформлении таблиц проявляйте креативность
      >Просто попросите объяснить, что это всё значит.

      Да все в статье расшифровано. Просто сталкивался с описанной ситуацией — уродские шрифты и никому не нужная расцветка в простом финансовом документе.
  • +1
    С таким подходом идите быдлокодить в гос компании там

    1) Кормят
    2) Релизы летом не делают т.к. их там вообще делают только по большим праздникам когда надо попилить бабосов
    3) Есть Меенеееджееер по одному на каждого программиста, который водит программиста срать, жрать и объясняет сложно оформленные таблицы
    4) Требования не меняются никогда так как продукты пишутся только для распила денег и ими никто не пользуется
    5) Скриншоты не делаются вообще и не только в ворде, а если вдруг сделал то мееенджееер все объяснит
    6) Вот только в офисе сидеть надо — зато полный соц пакет, стабильная зарплата, отпуск летом и кормят — главное ведь кормят.

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

    Я бы после первого залупона по поводу техзадания послал бы очень далеко, если чтото изменилось значит бизнес ситуация того требует а не из башки заказчик решил вам заплатить побольше денег, чтобы сделать чтото подругому.
  • +1
    Пункт про смену требований убил наповал. Так всё и было, когда я работал в мелкой фирме.

    Даже ещё круче. На наш — разработчиков — робкий вопрос про ТЗ последовал ответ (буквально): «А вот то, что вы напишете, и будет техническим заданием!». Разумеется, предполагалось, что это должно неким волшебным образом коррелировать с высказанными и невысказанными фантазиями и окказиональными замечаниями заказчиков и неким мифическим талмудом, включавшим их раздумья по теме, но так нам и не предъявленным.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      85% compressing

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