Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Большой проект vs маленький проект

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

© JoJoNeiL

Время/опыт

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

Решение проблем

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

Отпуск/отгулы

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

Коллектив

В маленьком проекте коллектив всегда более дружелюбный. Причиной тому является то, что в большом проекте просто-напросто много людей и сойтись со всеми, даже если вы душка, труднее, чем сойтись с руководителем и ещё парой человек.

Зарплата

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

Карьерный рост

Тут всё намного интереснее! =) С одной стороны, чтобы вырасти «вверх», первое, что для этого необходимо, это, собственно, открытие самой вакансии. То есть ваш руководитель перешёл в другой проект/отдел/компанию. Логично, что в маленьком проекте у вас будет меньше конкурентов на открывшуюся вакансию и, следовательно, заменить вашего бывшего руководителя, и торжественно поднять знамя над головой, в маленьком проекте — более реально, чем в большом. С другой стороны, руководить маленьким проектом, где работает 3 человека, куда менее престижно, чем возглавить команду из 20 и более человек. Кстати, вырасти «вверх» в другом проекте (то есть, когда вас переводят с повышением) более реально, находясь в большом проекте, чем в маленьком. В большом проекте вы более «обкатаны» в различных условиях, более приспособлены для выхода вовне, другими словами вы — серьёзный, тёртый калач, и опять же, заменить вас в большом проекте легче, чем в маленьком. А значит, ваш нынешний руководитель расстанется с вами менее болезненно, если вы находитесь в большом проекте, чем в маленьком.

Профессиональный рост

Безусловно, в маленьком проекте вы быстрее вырастете в незаменимого бойца. На вас сразу обрушится море ответственности. Cкорее всего, пройдёт всего пара месяцев, и ваш руководитель будет говорить что-то типа: «Сорри, у меня нет времени быть на этом звонке — пойди вместо меня». В маленьком проекте если что-то пошло не так и кто-то «накосячил», то на вас будет больше вины за содеянное, чем в большом. Ведь там, всегда, всё это можно спихнуть на огромный, трудный проект, сложность коммуникации и странные фазы Луны. Назовём это всё Эффектом ответственности. Ведь это элементарно просто: в маленьком проекте с самого начала на вас давит больше ответственности, и вы под этим грузом развиваетесь быстрее, чем вы развивались бы в большом.

В то же время в большом проекте разнообразнее технологии и присутствуют прочие, интересные штуковины. И в вашем профессиональном росте вы поднимитесь куда выше именно в большом проекте. То есть большой проект может дать вам больше возможностей в плане профессионального роста, хотя не так быстро. Назовём это всё Эффектом аквариума. Вы когда-нибудь задумывались над тем, что если посадить рыбку в 3-х литровый аквариум — то она вырастет до своего максимума в этом аквариуме и перестанет расти? А когда вы пересадите её в 60-литровый аквариум, то рыбка продолжит расти до своего максимума. Аналогичное происходит и с людьми в проектах: у вас есть свой личный максимум, которого вы можете достичь. Но достичь своего максимума вы сможете только в проекте, который позволит вам это сделать.

Кстати, встречается и другое определение эффекта аквариума: «Эффект аквариума — потеря свежести восприятия. Аквариумные рыбки живут в своем мирке, полностью потеряв связь с окружающей действительностью». Это тоже имеет место быть. Большие проекты обычно более долгоиграющие, чем маленькие. И, работая в большом проекте, вы можете там засидеться и потерять свежесть восприятия, так и не достигнув своего максимума. А маленькие проекты имеют обыкновение заканчиваться через полгода — год, и вас переводят в другой аквариум другого размера с другими рыбками и с другими технологиями. И для достижения своего максимума это тоже очень важно.

Вывод

Из всего этого потока сознания можно сделать вывод, что на вкус и цвет «все фломастеры разные». При этом нужно осознавать свои цели и, следовательно, выбирать проект по вкусу. А если выбирать не приходится, то нужно либо сделать так, чтобы выбор появился, либо «расслабиться и получать удовольствие», а не ныть и скулить, что где-то там по слухам кому-то лучше. Как говорится: «Хорошо там, где нас нет».

А что вы думаете по поводу достоинств и недостатков работы в больших и маленьких проектах? Оставляйте свои комментарии.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи



33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Однозначно маленький проект лучше.
Если Вы готовы идти вверх, в маленьком проекте Вы поднимаете саму карьерную лестницу. Именно развитие самого проекта — основной способ подняться. Более правильно сказать, Вы получаете часть того, над чем работаете.
В большом деле — Вы находитесе не на карьерной лестнице, а на карьерном эскалаторе. И как бы не двигались лично Вы — прежде всего всё зависит от эскалатора. Самое обидное, когда их несколько, и соседний всегда движется быстрее (закон Мэрфи про очередь). Ну и в один прекрасный день какого-нить боссам может посетить «озарение» в виде амбициозной инновации в менеджменте — ставить провинившихся в угол, или увольнять 30% в год, или отключить всем интернет — и весь эскалатор дружно уходит под землю.

Однако, опыт в большом деле может научить поднимать этот самый эскалатор. Поднимать большое дело. Сотрудничать со многими людьми. Учиться у многих. И как ни странно... удалённой работе!

Работая в большой компании — Вы всегда работаете удалённо. Я честно не понимаю, зачем существуют офисы, тем более в бизнес-центрах с заоблачными ценами — если всё равно иерархия разделяет компанию на маленькие группы. Разве только нахождение в одном городе позволяет собраться на пиво. Не более того.

Лучшее положение — это маленький проект, порождённый от большого. Когда бизнес-связи с большим делом поддерживаются, притом в очень горячем режиме. Но за успех или провал конкретного дела — ответственны вы и ещё несколько человек (до 30-50).

Главный козырь малых проектов — провал допустим. Если какая-та часть дела пошла не так, можно вовремя и смалыми потерями остановиться и поменять решение.
В больших — это невозможно, там только на согласование месяц уйдёт. Первое, чем Вас попытаются отучить (огнём и мечом) — рисковать. Нет никакого оправдания риску, даже самый малый провал развивается либо в увольнение, либо в потерю кармы. Руководитель любого уровня должен уметь только одно: избегать риска. Всегда и любыми способами отказываться от рисковых полезных затей. Именно от полезных — это важно. И с радостью брать бесполезные дела. Почему так: за провал бесполезного дела никто не накажет. А за успех полезного дела — накажут, притом накажут за все нюансы успешного внедрения (а это путь проб и ошибок), и загребут себе все лавры. Карма от этого падает ниже плинтуса. В лучшем случае уволишься сам. В худшем — навсегда утратишь способность к риску.

Риск малой компании, как и малого проекта — некомпетентность менеджера или владельца. Стоит ему хоть раз утратить контроль и пойти во все тяжкие, и что ещё хуже — если в результате получится решить проблему — и всё, звёздная болезнь и крах проекта. Именно «звёздная болезнь» — самые опасные грабли. С другой стороны, реальной звездой [не шизофреником] тоже можно стать в малом проекте. Разница — только в отношениях внутри. Если сумели построить доверие — звезда, если «не верь никому» — шиза.

Скажу одно — работать приятно и там, и там. Только перейдя во фриланс, замечаешь недостаток компании. И втайне мечтаешь построить собственную :)

очень познавательно!

Понравилась статья, почти со всем согласен.

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

А вообще когда на проекте 2 человека (или не дай Бог 1) — то очень скучно.

Согласен с Вами, я по своему опыту скажу.. что «идеальным» вариантом.. это будет приход в маленький проект, который способен вырасти до большого. =)

«идеальным» вариантом.. это будет приход в маленький проект, который способен вырасти до большого. =)
VS
что на вкус и цвет «все фломастеры разные». При этом нужно осознавать свои цели и, следовательно, выбирать проект по вкусу. А если выбирать не приходится, то нужно либо сделать так, чтобы выбор появился, либо «расслабиться и получать удовольствие», а не ныть и скулить, что где-то там по слухам кому-то лучше. Как говорится: «Хорошо там, где нас нет».
inconsistency какое-то.
Вы сами пишите что всё относительно и что более чем априори понятно, и ту же сами говорите про «идеальные» проекты. «Не понятно» ©
Jedem das Seine — поймите вы наконец, что тут обсуждать и спорить нечего и не о чем.
Вы еще обсудите что лучше?! — большая машина или маленькая, синий цвет или зелёный, брюнетки или блондинки, дом или квартира,...

Я считаю, что на вкус и цвет все фломастеры разные. А потом я озвучил свой вкус. =) вроде не противоречит ничему.

А вообще когда на проекте 2 человека (или не дай Бог 1) — то очень скучно.

Это точно. Ушла с компании, где люди в основном работали на удаленке и на проекте было немного народу. Теперь работаю в большом офисе, вокруг куча людей, и это прекрасно)))

Оффтоп: Логично что всё зависит от человека и от ситуации/проекта/компании/заказчика/отдела .... ну базово, мне кажется это вот так, как я написал.
Спасибо за комментарии, интересно почитать =)

Предпочитаю маленькие проекты.
Когда все под рукой.
Когда есть динамика.
Когда есть больше свободы.
Когда можно сделать качественно и не потратить на это 5 лет.
Когда есть быстрый фидбек.
Когда есть следующие маленькие проекты.

Вам надо идти работать к нам :)

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

чтобы вырасти «вверх», первое, что для этого необходимо, это, собственно, открытие самой вакансии
Интересно, что автор не упоминает компетентность как необходимое для повышения условие.
ru.wikipedia.org/.../Принцип_Питера

компетентность отдельного специалиста или проекта в целом?

Имеется в виду компетентность конкретного специалиста для конкретной должности, на которую его повышают.

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

Из всей статьи оставил бы это:

... что на вкус и цвет «все фломастеры разные». При этом нужно осознавать свои цели и, следовательно, выбирать проект по вкусу. А если выбирать не приходится, то нужно либо сделать так, чтобы выбор появился, либо «расслабиться и получать удовольствие», а не ныть и скулить, что где-то там по слухам кому-то лучше. Как говорится: «Хорошо там, где нас нет».

«Смешались в кучу кони, люди...» Я вообще не любитель резких слов, но такое притягивание фактов за уши я давно не встречал.

С одной стороны, чтобы вырасти «вверх», первое, что для этого необходимо, это, собственно, открытие самой вакансии.
Честно, не встречал ещё ни одной компании, в которой стояла бы эта проблема. Да и вообще в IT, честно говоря. Обычно — наоборот. Возможностей для роста — раздолье. А вот опыта/квалификации не хватает куда чаще.
С другой стороны, руководить маленьким проектом, где работает 3 человека, куда менее престижно, чем возглавить команду из 20 и более человек.
Не всё размером меряется.
В то же время в большом проекте разнообразнее технологии и присутствуют прочие, интересные штуковины.
А вот тут обычно с точностью до наоборот. «Большой проект» = «влили большое бабло» => «рассчитывают на прибыль» => «все риски к минимуму» => «использовать только проверенные и популярные технологии». Чтоб в большой проект продавить новую, но интересную технологию — зубы можно сточить и 2 сердца заменить. Но если получится — всё окупается )))
в маленьком проекте с самого начала на вас давит больше ответственности, и вы под этим грузом развиваетесь быстрее, чем вы развивались бы в большом.
в вашем профессиональном росте вы поднимитесь куда выше именно в большом проекте
Э-э-э?
А что вы думаете по поводу достоинств и недостатков работы в больших и маленьких проектах? Оставляйте свои комментарии.
Имхо, это сугубо индивидуально. Бывают маленькие скучные проекты. Бывают большие проекты, на которых рвёшь жо.. на кельтский крест, ибо так подписан контракт. Есть маленькие проекты, на которых обкатываются новые технологии, и есть маленькие проекты, где по накатанной делаешь одно и то же по инструкции по обкатанной дороге. Есть большие проекты, где всё меняется каждый день, и есть большие проекты, на которых отдыхаешь пару месяцев перед тем, как окунуться в очередные приключения.

А бывает карма. Куда бы ты ни пришёл — именно тебя там и не хватало. Твоих знаний, твоего азарта, твоего видения. Тебя.

People matter. Projects follow.

Большой проект не означает, что каждый участник в нем жалкий винтик. В любом проекте есть и первые скрипки, и пешечки, и это сильно зависит от самых участников.

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

С большого проекта на мелкий легко спрыгнуть, а вот наоборот — понадобится время, чтобы освоится.

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

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

# Потоки гуана:
## Вся заметка пронизана ошибочным посылом:

Безусловно, в маленьком проекте вы быстрее вырастете в незаменимого бойца.
Такая ситауция — это баг в управлении проектом (и рисками).

## Вторая ошибка:

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

# Попытка добавить позитива в коммент:
Спсыбо что напомнили об Эффекте аквариума.

Добрый День. Отвечу на 2 Ваши замечания:
1) Представим себе проект из 3-х человек, где есть лид и ещё 2 равноценных человека. Итого каждый делает примерно 33% работы и быстро растёт и развивается. Теперь представим себе проект из 20 равноценных( я понимаю так не бывает, но для примера лучше использовать равноценных людей) человек, где каждый составляет 5% от общекомандного выхлопа. Итого, что мы имеем? В первом случае человек будет более труднозаменим...это раз... будет быстрее развиваться, из-за давления ответственности.. это два... будет ограничен размерами проекта, но по причине малого размера проекта он быстрее сможет стать супер мета экспертом этого проекта.. это три.
Не вижу ничего здесь неправильного. Или Вы хотите сказать, что нужно не давать людям развиваться и ограничивать их в действиях? =)
2) Я согласен.. размер проекта напрямую не коррелирует с разнообразием технологий. Но опять таки, вы должны понимать... что в основном в больших проектах используется больше различных технологий. Мне кажется тут даже нет смысла дальше спорить

В первом случае человек будет более труднозаменим
незаменимого бойца.
Труднозаменим и незаменим — это разное. В первом случае, ценность человека определяется ленью манагера, во втором — качествами человека.
Не вижу ничего здесь неправильного.
Ошибка в том что все пункты которые вы описали, зависят от управления проектом, а не от размера комманды/компании.
будет быстрее развиваться, из-за давления ответственности
Из давления не получитсо ничего хорошего не получитсо. Помимо того есть люди обладающие тайтым намыком пофикизма. (Ошибка №следующая)
но по причине малого размера проекта он быстрее сможет стать супер мета экспертом этого проекта
Что значит «упер мета экспертом этого проекта»?
Экспертиза в предметной области, от проекта не зависит. Экспертиза в навыках программирования аналогично.
Вы говорите про то «какой метод в каком классе»? Если да, то тут явная проблема с качеством кода и коммуникациями.
что в основном в больших проектах используется больше различных технологий. Мне кажется тут даже нет смысла дальше спорить
Имеет. :)
Может быть унылый 10-летний проект с ограниченным набором энтерпрайз-технологий, а может быть молодой хипстерский проект, где есть и джава, и хаскелл. Это крайности.
Но в общем технологии зависят от проекта и от команды.

"

Труднозаменим и незаменим — это разное. В первом случае, ценность человека определяется ленью манагера, во втором — качествами человека.
"
Вам любой манагер скажет, что незаменимыых людей не бывает.. бывают труднозаменимые... а незаменимых — не бывает. Если вам Манагер скажет, что бывают незаменимые люди — значит он плохой манагер....
Ошибка в том что все пункты которые вы описали, зависят от управления проектом, а не от размера комманды/компании.
Я с Вами не соглашусь. Да, тут нет однозначного ответа.. всё зависит от очень многих факторов и нельзя написать статью учитывая это всё. Почитайте, пожалуйста, на досуге определение «Теории Хаоса».
Из давления не получитсо ничего хорошего не получитсо. Помимо того есть люди обладающие тайтым намыком пофикизма. (Ошибка №следующая)
Тут палка о двух концах... либо получится, либо через 2-3 месяца Манагер поймёт, что ничего не получится и будет искать замену.. желательно того, у кого «получится»
Что значит «упер мета экспертом этого проекта»?
Экспертиза в предметной области, от проекта не зависит. Экспертиза в навыках программирования аналогично.
Вы говорите про то «какой метод в каком классе»? Если да, то тут явная проблема с качеством кода и коммуникациями.

У вас все проекты сводятся только к программированию? А в тестировании или автоматизации не нужно быть экспертом проекта? Да пусть даже и программированием. Проект нужно знать хорошо... если вы программист, вы можете забить полностью на знание проекта? Грош цена вам тогда...
Имеет. :)
Может быть унылый 10-летний проект с ограниченным набором энтерпрайз-технологий, а может быть молодой хипстерский проект, где есть и джава, и хаскелл. Это крайности.
Но в общем технологии зависят от проекта и от команды.
Всё может быть... и неинтересный 10-летний проект и интереснй 1-месячный проект и наоборот интересный 10-летний проект и скучный 1-месячный проект.. где вам надо там... написать/потестить порносайт... Я говорю про базово.. про большинство... и моё имхо, что в большинстве случаев — я прав... а исключения, конечно, имеют место быть
всё зависит от очень многих факторов и нельзя написать статью учитывая это всё. Почитайте, пожалуйста, на досуге определение «Теории Хаоса».
Даже без теории хаоса. Дело в банальных завтыках в управлении, простой пример из вашего же текста:
В маленьком проекте вы можете столкнуться с тем, что, собравшись в отпуск, вы будете вынуждены сдать билеты и остаться на работе. Селяви. В маленьком проекте вас труднее подменить, а авралы и ЧП происходят с такой же регулярностью.
Человек (допустим разработчик, но для других специализаций можно выстроить подобную цепочку) сообщил что уходит в отпуск (как правило за месяц, а то и 6). Значит надо или добиться стабильности в проекте до его ухода, если у вас нет других разработчиков (в этом случае он незаменим как раз), или сделать так чтобы другие разработчики могли исправлять его баги и при этом не овертаймили, то есть снять с них нагрузку (это более правильный способ). Так или иначе все сведется к правильному планированию.
А в тестировании или автоматизации не нужно быть экспертом проекта? Да пусть даже и программированием. Проект нужно знать хорошо... если вы программист, вы можете забить полностью на знание проекта?
На знание проекта (я так и не услышал что это), скорее всего да. А вот:
Экспертиза в предметной области, от проекта не зависит.
И это же касается тестеров. Если тестер не может быстро влиться в работу (имея знание предметной области), то скорее всего у вас плохая документация и/или много «странной» логики (то есть кто-то что-то придумал, этим пользуются, но оно не соответствует стандартам в области)
что в большинстве случаев — я прав... а исключения, конечно, имеют место быть
Вы не показали что вы правы в большинстве случаев (нет ни строго доказательства, ни достаточной выборки).
Уверен что в вашем опыте подобное соотношение:
в основном в больших проектах используется больше различных технологий.
Имеет смысл.
Мой же опыт говорит о противоположном: большие проекты — это как правило стандартный энтерпрайз-стек 1998-2006 годов или проект Спринг(2.х)+Хибернейт (от и все технологии). В то же время есть проекты написанные на кложере+плей+монгоДБ, которым не более года и максимум 2 релиза, про однорелизные проекты на ерлангах+нода, я вообще молчу.
Посему ваше утверждение:
Мне кажется тут даже нет смысла дальше спорить
Немного ... импульсивно.
Такая ситауция — это баг в управлении проектом (и рисками).
А как вы поуправляете рисками, если в проекте 3 человека всего? Уходит один — это 33% команды. Я думаю, в любом проекте, который пилит 50 человек, если уйдет 17, то это будет катастрофа.
А как вы поуправляете рисками, если в проекте 3 человека всего? Уходит один — это 33% команды.
Но осталось то 2/3.
Я думаю, в любом проекте, который пилит 50 человек, если уйдет 17, то это будет катастрофа.
Есть такие люди — ПроджектМанагеры. Им платят деньги за то чтобы катастрофы небыло.

А если этот один под трамвай попадёт?

Уходит один — это 33% команды. Я думаю, в любом проекте, который пилит 50 человек, если уйдет 17, то это будет катастрофа.
Заменить и/или найти одного человека в 17 раз проще чем 17! © КО

когда уходит один Алексей, всегда найдется второй такой же, а вот если уйдет 17 из 50 — это настоящая проблема

Подписаться на комментарии