Имеем:
1. Компанию, занимающуюся разработкой железа и софта для телекоммуникационной сферы.
2. Команда программистов (3 чел.) + "идейный лидер".
3. В команде используется принцип: "сели, обсудили общие черты нового проекта, примерно распределили направления и пошли сразу кодировать". Результат такой работы всем известен, думаю писать не стоит.
4. Из инструментария используется только CVS и делаются первые шаги по внедрению баг тракера (Mantis).
Хочется получить:
1. Воспитать из "идейного лидера" настоящего ПМа.
2. Создать из команды "костяк" для будущего наращивания числа программистов, а также привлечения аутсорсеров.
3. Обучить команду достаточно легковесному и эффективному процессу с использованием соответствующего инструментария.
Пробовал разобраться сам. Почитал существующие подходы (процессы) к разработке. Предпринял попытку разработать архитектуру уже реализованного ранее проекта, с нуля, "закрыв глаза", на существующий код. Столкнулся с тем, что на определенном уровне детализации архитектуры не могу абстрагироваться от кода, т.е. вся архитектура просматривается сквозь призму конкретной реализации. Мне кажется это не правильно.
Всерьез задумался о тренинге. Посоветуйте как поступить рациональнее всего, пока есть немного "свободного" времени.
Может и правда поехать на тренинг (возможен вариант обучения в Киеве или др. городах Украины) самому или всей командой?
Или же есть такие наемные консультанты, которые могут к нам приехать и "поставить" процесс?
Здравствуйте, _SAV, Вы писали:
_SA>Хочется получить: _SA>1. Воспитать из "идейного лидера" настоящего ПМа.
это разные профессии. первый — технарь, второй — не технарь.
вы их можете попытатся совместить в одном человеке, но в результате, есть шанс потерять приличного технаря и получить плохого пм-а.
если только он сам хочет.
_SA>Буду благодарен всем советчикам!
совет такой. тут типа кризис. опытного человека можно перехватить из падающей компании.
рекомендациями озаботтесь. во
_SAV пишет: > > Имеем: > 1. Компанию, занимающуюся разработкой железа и софта для > телекоммуникационной сферы. > 2. Команда программистов (3 чел.) + "идейный лидер". > 3. В команде используется принцип: "сели, обсудили общие черты нового > проекта, примерно распределили направления и пошли сразу кодировать". > Результат такой работы всем известен, думаю писать не стоит.
Пункт 3.5. Прежде чем класть кирпичи вы нарисовали хотя бы, что хотите
построить. Извини, за иносказательность, но так, мне кажется понятнее.
Перед тем как кодить и после того как поговорили необходимо нарисовать и
разработать (на языке программном, одном или нескольких) архитектуру,
описать хотя бы словесно, но достаточно точно, что вы хотите в итоге
получить, какие промежуточные этапы предполагаете, результаты этих этапов. > 4. Из инструментария используется только CVS и делаются первые шаги по > внедрению баг тракера (Mantis).
Этот момент не важен, главное чтобы была хоть какая система управления
версиями, отслеживания багов и фич (хоть табличка в текстовом файле)
> > Хочется получить: > 1. Воспитать из "идейного лидера" настоящего ПМа.
Чем бы дитя не тешилось... > 2. Создать из команды "костяк" для будущего наращивания числа > программистов, а также привлечения аутсорсеров.
Смешал все в кучу. В этом пункте у тебя два больших момента. Второй —
аусорс, пока не научитесь точно и четко формулировать задачи в имеющемся
коллективе аутсорсеру вы задачу не поставите — в итоге потеря нервов и
денег. > 3. Обучить команду достаточно легковесному и эффективному процессу с > использованием соответствующего инструментария.
п.4 выше — выше крыши.
> > Пробовал разобраться сам. Почитал существующие подходы (процессы) к > разработке. Предпринял попытку разработать архитектуру уже > реализованного ранее проекта, с нуля, "закрыв глаза", на существующий > код. Столкнулся с тем, что на определенном уровне детализации > архитектуры не могу абстрагироваться от кода, т.е. вся архитектура > просматривается сквозь призму конкретной реализации. Мне кажется это не > правильно.
А ты не пытайся детализировать архитектуру до предела в итоге доводя до
маразма. Просто остановись на минимально необходимом уровне детализации
и сам же реализуй ее на уровне пустышек. Дальше разработка — это
заполнение этих пустышек. Ну и кроме того архитектура и реализация
взаимно-зависимы — невозможно разработать архитектуру не думая о ее
реализации (простейший пример: выбор фабрика или pImpl) > > Всерьез задумался о тренинге. Посоветуйте как поступить рациональнее > всего, пока есть немного "свободного" времени. > Может и правда поехать на тренинг (возможен вариант обучения в Киеве или > др. городах Украины) самому или всей командой? > Или же есть такие наемные консультанты, которые могут к нам приехать и > "поставить" процесс?
Забей. Бабки сымут, а толку не будет.
_SAV пишет: > > Или же есть такие наемные консультанты, которые могут к нам приехать и > "поставить" процесс?
Не внимательно прочитал. Могу с другом приехать, поставим вам процесс,
только слушаться беспрекословно.
V>Пункт 3.5. Прежде чем класть кирпичи вы нарисовали хотя бы, что хотите V>построить. Извини, за иносказательность, но так, мне кажется понятнее. V>Перед тем как кодить и после того как поговорили необходимо нарисовать и V>разработать (на языке программном, одном или нескольких) архитектуру, V>описать хотя бы словесно, но достаточно точно, что вы хотите в итоге V>получить, какие промежуточные этапы предполагаете, результаты этих этапов.
На самом деле все не так просто из-за специфики проектов. Дело в том, что, как правило, предметная область проекта в начале малознакома (например, реализация в производимом оборудовании новых для нас сетевых/телекоммуникационных протоколов, сервисов). Поэтому архитектуру прикидываем слишком "на глазок". Потом крупные кубики разбираются людьми и каждый уже более плотно изучает свою часть работы (RFC, рекомендации, даташиты, примеры кода и т.д.). Но это процесс очень длительный, поэтому народ не выдерживает и начинает писать код уже на основании того, что успел освоить. И код по сути рождается в процессе изучения и соответственно по ходу переписывается n-е число раз. В таких условиях просто нереально вырисовать этапы, а также хоть как-то спрогнозировать сроки этих этапов.
_SAV пишет: > > > На самом деле все не так просто из-за специфики проектов. Дело в том, > что, как правило, предметная область проекта в начале малознакома > (например, реализация в производимом оборудовании новых для нас > сетевых/телекоммуникационных протоколов, сервисов). Поэтому архитектуру > прикидываем слишком "на глазок".
И получаете кучу головной боли.
Первым делом, в начале проекта ни в коем случае не избегайте написания
таких документов, как "Видение", "ТЗ", даже для себя, когда делаешь,
кажется, что это лишнее, а потом понимаешь, что именно они тебе
позволили понять четко, что ты хочешь сделать. Не надо их делать
навороченными, главное, чтобы они были конкретными, четкими и ясными.
Затем, обязательно документ по архитектуре, взаимосвязям модулей
(железный, программный) и их ответсвенностям, не надо разрисовать до
каждого мелкого класса, но четко определите интерфейсы и протоколы
взаимодействия частей системы. Этот документ должен быть всегда
актуален, посему лишняя детализация там вредна.
Затем реализуйте архитектуру на пустышках, чтобы убедиться, что идеи в
документе выше работают.
При реализации архитектуры придерживайтесь принципа минимализма (всегда
легче что-то добавить, чем модифицировать что-от имеющееся).
После всего выше вы уже будете видеть что и в какие этапы (не сроки) вы
сможете реализовать.
Реализацию бейте на минимальные этапы по 2-3 недели (первый обычно
дольше, не не больше 2 мес.). Легко учитывать текущую ситуацию и
перебрасывать силы, если надо. Но не пытайтесь планировать детально на
год вперед — это типичный глюк местного манагерства. Ставьте просто
ключевые места разработки, этапы.
Ну и ко всему добавлю, у Джоэла есть 12 принципов, старайтесь их
придерживаться.
> а также хоть как-то спрогнозировать > сроки этих этапов.
Это всегда хочет видеть высокое начальство и никуда от этого не деться,
остается принимать, как дождь, снег... Т.е нарисуйте то, что хочет
видеть начальство, причем не занижайте сроков.
Но если вы будете выдавать каждые 2-3 недели что-то работающее и нужное
по проекту в случае непопадания в оценки и по мере развития проекта,
вполне возможно, что некотрые задачи сами отомрут, но появятьс яновые о
которых вы даже предположить не можете.
Невозможно спланировать будущее, можно только сделать очень
приблизительные оценки на основе предыдущего вашего опыта, и самое
плохое, что вы можете как угадать с точностью до минуту, так и ошибиться
в 5 раз. Причем обе эти ситуации практически равновероятны.
P.S. Специфика проектов — это просто отмазка. Прекрасно управляются даже
чисто научные проекты, причем с выдачей положительного результата.
Сам всегда понимал серьезность нормальной постановки процесса. Около года назад нашел в Киеве фирму — заказчика и начал делать для него проект. Нашел аналитика, 2х программистов, тестировщика, сисадмина. Всех нашел в инете, работа в основном удаленно (программисты в России и Казахстане, остальные в Киеве). Сам совмещал роли ПМа, архитектора, программиста.
Решил серьезно отнестись к настройке процесса разработки. Руководствовался идеями, описанными в книге Крега Лармана "Применение UML и шаблонов проектирования" (лет 5 назад взял ее вруки и понял, это то, что искал — частично применял в некоторых проектах). В книге речь идет о RUP. Сама по себе штука довольно тяжеловесная, но хороша тем, что какбы состоит из рекомендацией, и можно брать из нее только то, что считаешь необходимым и самому контролировать ее "тяжесть".
Настроил дома сервак с CVS и баг-трекером, все нормально подключаются и работают. Аналитик выясняет требования и представляет в документации в ввиде, близком к описанному в книге Лармана. Дальше я на основе этого описываю архитектуру в виде диаграмм (тоже из книги) и текста. Ставлю таски разработчикам, они уже по описанной архитектуре ориентируются и пишут код. Очень удобно обсуждать по нарисованным диаграммам. Дальше таски ставятся тестировщику по реализованному функционалу (он описывает тест-кейсы, по документам аналитика), выявляются баги — фиксятся. Раз в пару месяцев выпускались демо для заказчика (сейчас версии). По результатам создаются новые таски и т.д.
Сил и времени на организацию всего процесса ушло немало. Зато все работает как часы, по документации хорошо видно что и для чего реализовывалось, легко вносить изменения в код, находить баги.
Система недавно поставлена и работает у заказчика. Багов у него не вылазило. Заказчик хочет что-нить добавить\изменить — легко делается, я участия принимаю намного меньше — в основном создаю таски и контролирую результат.
Самое главное, все получилось как и планировал — четкий процесс, документация, все прозрачно и ясно, система работает и легко модернизируется.
Если интересно — могу рассказать подробней, показать примеры документов, помочь в настройке процесса
Аська 310-396-070
Здравствуйте, Vzhyk, Вы писали:
V>Не внимательно прочитал. Могу с другом приехать, поставим вам процесс, V>только слушаться беспрекословно.
Откуда вы сами?
Сколько дней (недель) может потребоваться для "постановки процесса"?
Во что это выльется по финансам (совсем примерная оценка, для ориентира)?
_SAV пишет: > > > V>Не внимательно прочитал. Могу с другом приехать, поставим вам процесс, > V>только слушаться беспрекословно. > > Откуда вы сами?
Из Минска. > Сколько дней (недель) может потребоваться для "постановки процесса"? > Во что это выльется по финансам (совсем примерная оценка, для ориентира)?
По большому счету, подобным я не занимался, постановкой процесса кому-то
стороннему (только на конторах, где работал). (Хотя может и подумать на
будущее , не ожидал, что кто-то так быстро согласиться)
Если серьезно. Забейте на всех таких платных консультантов. Все уже
давно разработано и описано в инете в немерянном количестве. Конечно,
хвататься за какой-то один процесс (RUP, XP ...) нельзя. В каждом
конкретном случае эффективнее выбирать некий симбиоз из нескольких.
Но правило одно, ваш процесс должен иметь минимальное количество
различных бумажек, но позволять достаточно быстро квалифицированному
разработчику вникнуть в проект.
По мне наиболее эффетивной оказался симбиоз RUP с элементами XP
(непрерывная интеграция и TDD).
Кратко, что надо минимально, ИМХО:
1. Система управления версиями (это у вас уже есть) — тут есть подводный
камень, если ваши разработчики не привыкли ее использовать, придеться
первые полгода их заставлять ее использовать.
2. Билд-сервер — на нем должна происходить еженощная сборка проекта и
прогон различных автоматических тестов (UT и др.) — это фича вам
позволит быстрее приучить разработчиков к системе контроля версий.
3. Система учета багов и фич — что-то у вас уже есть, главное
обязательно всех заставить ее использовать.
4. Планирование :D, самая нелюбимая вещь всеми. Прекрасно отрабатывает
следующий подход: каждый разработчик ведет диаграмму Ганнта(MS Project,
GanntProject...) с планом работы на ближайшие 2 недели с детализацией
порядка 3 дней (в среднем). По мере разработки, по необходимости
разработчики правят и модифицируют свой план: в первую очередь
инструмент самодисциплины и видения дальнейшей разработки самим
разработчиком, во вторую — это фактически информация для менеджера о
текущем состоянии проекта и ближайшем пути движения каждого разработчика.
5. Все разработчики обязаны сопровождать свой код юнит-тестами, здесь
дополнительная задача на лидера, помогать разработчикам в их написании —
особенно первое время, потом все сами поймут их эффективность и
полезность. Есть в данном один минус, первые этапы разработки идут
медленнее, чем хотелось, временной выйгрыш начинается где-то после
полугода их применения и разработки
6. Тестирование — без него никуда — но эту часть я не знаю.
7. По самой разработке:
7.1 Документы Vision и SRS — эти обязательно (должны быть четкими и
понятными), остальное, что там по RUP по необходимости.
7.2 Архитектура в виде документа с картинками на человеческом языке —
обязательно с презентацией, которую необходимо защитить перед
разработчиками на митинге.
7.3 Проект из пустышек, по архитектуре. При его реализации архитектуру
придется править.
7.4 Два прикольных словосочетания: test driven development и непрерывная
интеграция.
7.5 Обязательно все алгоритмы, разработки документировать и держать
недалеко от кода.
Как бы и все.
Да чуть не забыл — немеряно терпения на уговоры и заставления всех
двигаться по процессу. Первое время будет тяжело — сопротивляться будут
все, затем покатится само.
Vzhyk пишет:
> 6. Тестирование — без него никуда — но эту часть я не знаю.
Заполняю нишу
Во-первых, вышеуказанное TDD даст возможность производить первичный
контроль. Это первый этап.
Второй этап — это автотесты, если конечно софтина поддается
автотестированию. Т.е. если функционал сильно меняется от версии к
версии — автотесты придется каждый раз переписывать, и тогда проще все
сразу делать руками. Если же добавление новых фич не задевает старые —
автотесты ваше все.
Количество тестов выбирается исходя из стоимости их написания (чтобы
окупилось). Покрытие — берем список требований, детализованный до
логических единиц, отбрасываем непригодные для автотестинга, каждому
требованию присваиваем степень критичности от 0 до 5 (можно до 10, до
100), потом сортируем по убыванию и откусываем с начала списка сколько
можем себе позволить.
Третий этап — ручное тестирование ака обезьянья работа. Подход тот же,
только список требований можно брать либо весь, либо только отброшенные
на прошлом этапе. Список проверок обычно формализуется в виде тест
кейсов или чеклистов — смотрите что вам больше подходит. Как правило и
то и то можно организовывать в сценарии — цепочку проверок, к примеру
запуск программы — просмотр данных — добавление записи — редактирование
— печать — удаление. Это позволяет оптимизировать расходы времени.
Самые важные моменты:
1) поступающие требования пропускать через тест лида. требования должны
поддаваться тестированию. заодно получим прикидки по бюджету на тестирование
2) тестировщик — друг разработчика, это должны понимать все. больше общения.
3) баги должен обрабатывать по возможности один человек — тест лида. это
гарантирует полноту/вменяемость багрепортов и единство стиля.
4) если один и тот же дефект переоткрывается по нескольку раз или
создается новый, очень похожий на свежезакрытый старый — это признак
того, что либо девелопер лажает, либо кто-то не понял требования. опять
же тест лид должен в таких случаях бить тревогу.
5) бойтесь ситуаций типа "одно пофиксил — другое поломал", это говорит о
кривизне архитектуры или полном раздолбайстве команды — вылавливать как
можно раньше и выправлять.
5) найденные дефекты фиксить по убыванию важности, самые маловажные
можно не фиксить вообще, если на это нет времени и заказчик согласен.
еще такой нюанс — схему основных флоу процесса разработки надо бы
нарисовать и повесить на видном месте, особенно пока народ не привык и
сам процесс не устаканился. Чтобы не было ситуаций, когда кто-то что-то
забыл сделать или стоял в непонятках, что делать с той или иной проблемой.
Все вопросы и затруднения придется первое время прогонять через себя, но
не увлекайтесь, иначе превратитесь в ходячий дом советов и
фундаментальное и незаменимое звено системы, и вам не дадут ни
отлучиться, ни заболеть, ни в отпуск сходить — будете круглые сутки
работать регулировщиком на перекрестке вместо того чтобы заниматься
полезным делом.
Здравствуйте, Vzhyk, Вы писали:
V>Не внимательно прочитал. Могу с другом приехать, поставим вам процесс, только слушаться беспрекословно.
Хм. "Беспрекословное послушание" консультанта, который не несет ответственности за результат проекта — это круто. Учитывая, что надо каким-то образом заставить беспрекословно вас слушаться еще 4 человек, от которых как раз в первую очередь и зависит успех предприятия. Думаете, они прям так сразу это захотят?
Еще интересно, что вы уже дали ему кучу советов и готовы "ставить процесс", не поинтересовавшись спецификой их работы и их проблемами. А там вроде как не веб-сайт на PHP, а программно-аппаратная разработка для телекома, там такая интересная специфика может всплыть, что даже с другом не разгребешь. Отважный вы человек, короче.
Здравствуйте, _SAV, Вы писали:
SA>2. Команда программистов (3 чел.) + "идейный лидер".
Исключения конечно бывают, но это слишком маленькая команда, чтобы имело смысл вводить какой-либо процесс, кроме процесса регулирующего внешние взаимодействия вашей команды — а именно обработка дефектов и фичреквестов, единая для customer support, тестеров, и разработчиков аппаратуры. У вас к тому все и так идет, вон, багтрекер внедряете.
SA>3. В команде используется принцип: "сели, обсудили общие черты нового проекта, примерно распределили направления и пошли сразу кодировать". Результат такой работы всем известен, думаю писать не стоит.
Вы самого главного не написали — конкретных наблюдаемых симптомов проблем. Процесс — это что, таблетка от всех болезней? Они известны только людям с телепатическими способностями. Результат такой работы зависит от того, что именно и как они обсудили, а также — насколько долго они работают вместе и хорошо понимают друг друга, и может быть самым разным.
Gaperton пишет: > > > Хм. "Беспрекословное послушание" консультанта, который не несет > ответственности за результат проекта — это круто. Учитывая, что надо > каким-то образом заставить беспрекословно вас слушаться еще 4 человек, > от которых как раз в первую очередь и зависит успех предприятия. > Думаете, они прям так сразу это захотят?
А кто их спрашивать будет. Кризис на дворе... В кандалы, нам по
плетке-треххвостке, ради такого дела с собой привезу — на галерах вполне
себе гребли .
> > Еще интересно, что вы уже дали ему кучу советов и готовы "ставить > процесс", не поинтересовавшись спецификой их работы и их проблемами.
Да (это относительно советов). Специфика — это более отмазка,
управление версиями, багами, фичами и разработкой, оно либо есть, либо
его нет. И неважно, какой степени навороченности процесс придуман,
просто, чем процесс навороченнее, тем больше он ради процесса, а не
результата работы.
Gaperton пишет: > > SA>2. Команда программистов (3 чел.) + "идейный лидер". > > Исключения конечно бывают, но это слишком маленькая команда, чтобы имело > смысл вводить какой-либо процесс,
Категорически не согласен. Вы здесь можете быть правы только в случае,
если эта команда собралась на 3 месяца, а через три месяца разбежится,
попилив бабло.
И автор, абсолютно прав, что решил внедрить процесс производства софта и
железа. Все разница с очень большой конторой и гигантскими проектами —
это количество бюрократии. Но без некоторого минимального набора техник
и артефактов — они просто не смогут обойтись, иначе 99 шансов и 100 "бег
по кругу" в разработке.
В любом случае, без issue tracking (баги, фичи), управления версиями,
планирования, а также Vision, SRS, Architecture они не обойдуться. Ну а
наличие еженощный билдов с прогонками тестов — это еще облегчит им жизнь
на порядок (первые 2-3 месяца придеться привыкать и ровнять свои
привычки, а потом уже на автомате людьми делается).
Здравствуйте, Vzhyk, Вы писали:
V>Gaperton пишет: >> >> Хм. "Беспрекословное послушание" консультанта, который не несет >> ответственности за результат проекта — это круто. Учитывая, что надо >> каким-то образом заставить беспрекословно вас слушаться еще 4 человек, >> от которых как раз в первую очередь и зависит успех предприятия. >> Думаете, они прям так сразу это захотят? V>А кто их спрашивать будет. Кризис на дворе... В кандалы, нам по V>плетке-треххвостке, ради такого дела с собой привезу — на галерах вполне V>себе гребли .
"процессы" в нашем деле — это технология организации человеческого общения, а не совместной грёбли и сессий BDSM . Как можно наладить процесс общаясь с его участниками в одностороннем режиме?
>> Еще интересно, что вы уже дали ему кучу советов и готовы "ставить >> процесс", не поинтересовавшись спецификой их работы и их проблемами. V>Да (это относительно советов). Специфика — это более отмазка, V>управление версиями, багами, фичами и разработкой, оно либо есть, либо V>его нет.
Специфика может состоять например в том, что они пользуются не готовым оборудованием, и даже не готовыми комплектующими, а делают свое собственное, активно применяя ПЛИСы. Для "отмазки" как-то знаете-ли слишком сильно. "Ты бы еще на мехмат МГУ поступил, чтобы от армии откосить". Если имеет место быть эта специфика, то источник большинства проблем будет вовсе не в том, как там именно программисты пишут свои SRS и учитывают дефекты, а в координации работ аппаратчиков и программистов.
Даже в программерской компании специфика может состоять в количестве и размере клиентов (сильно влияет на схему процесса управления дефектами, фичами, и релизами), и в размере и возрасте продукта. Да и вообще — продуктовая компания или "заказная" — очень вполне себе специфика, радикально влияющая на процессы и организацию работы.
V>И неважно, какой степени навороченности процесс придуман, V>просто, чем процесс навороченнее, тем больше он ради процесса, а не V>результата работы.
Чем меньше вы интересуетесь спецификой — тем в большей степени ваш процесс является "наукой чистого разума" ради самого процесса, а не результата работы. Потому, что тем больше он от самой сути работ и связанных с ней проблем далек — не интересуясь спецификой вы просто не оставляете себе шанса принести пользу. Даже при органиации системы билдов и багтрекера (что "процессом" можно с натяжкой назвать) эти вещи стоит принимать во внимание.
Впрочем, это мое мнение, я его не навязываю — напротив, мне очень интересно узнать, как оно пройдет с плеткой семихвосткой .
Здравствуйте, Gaperton, Вы писали:
G>Впрочем, это мое мнение, я его не навязываю — напротив, мне очень интересно узнать, как оно пройдет с плеткой семихвосткой .
Просто нужно команду набирать на сайтах мазохистов
Gaperton пишет: > >> > Думаете, они прям так сразу это захотят? > V>А кто их спрашивать будет. Кризис на дворе... В кандалы, нам по > V>плетке-треххвостке, ради такого дела с собой привезу — на галерах вполне > V>себе гребли . > > "процессы" в нашем деле — это технология организации *человеческого > общения*, а не совместной грёбли и сессий BDSM .
Т.е ты утверждаешь, что везде делание софта идет только в виде
"процессов" в вашем деле?
К несчастью, в многих конторах, о которых я знаю, процесс идет в
варианте близком к галере античной. А вот найти контору с процессом,
который ты имеешь в виду — это еще поискать надо.
Cyberax пишет: > > G>Впрочем, это мое мнение, я его не навязываю — напротив, мне очень > интересно узнать, как оно пройдет с плеткой семихвосткой . > Просто нужно команду набирать на сайтах мазохистов
jobs.tut.by пойдет?
Vzhyk пишет: > >> Просто нужно команду набирать на сайтах мазохистов > jobs.tut.by пойдет?
Да, что какой-то tut.by (там есть и вполне адекватные конторы).
Достаточно посмотреть о работе здесь, чтобы увидеть этих мазохистов в
больших количествах.
, не ожидал, что кто-то так быстро согласиться)
.
