[Управление разработкой, Управление персоналом] Можно ли сэкономить набирая junior специалистов?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мало кто хочет брать джуниор-разработчиков в трещащий по швам проект. Однако берут. И я заметил, что есть компании, в которых боятся брать сеньоров. Компания предпочтет взять нескольких джуниоров вместо одного сеньора. Мысль взять одного сеньора вместо мидлов или джуниоров, можно сказать, даже и не рассматривается.
Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте.
Дисклеймер №1: Безусловно разделение на junior-middle-senior, используемое в статье, крайне условное и мало связано с опытом работы, а градация и зарплатные уровни сильно зависят от компании, в которой дается оценка. Однако мы живем в реальности, в которой на hh в вакансиях ведущих it компаний используется такая терминология, и все мы, так или иначе, понимаем о чем речь, и примерно какой набор требований предъявляется в том или ином случае. И предвосхищая дальнейший текст статьи, заверяю, что абсолютные величины не так важны для сделанных выводов.
Дисклеймер №2: Рассуждения по большему счету не про топ компании, в которых и так все в порядке, а скорее про остальное большинство. Так же разговор идет про технически сложные продукты, правда в возможность существования простых, в общем случае, особо и не верю. Простые продукты (вспоминая Пола Грэма и его книгу "Хакеры и Художники") вряд ли могут успешно существовать на конкурентном рынке, в противном случае их было бы слишком просто скопировать и повторить.
В классическом варианте конечно же есть стремление сэкономить.
Джуниору можно мало платить. Их много на рынке, их легче взять. Да, первые месяцы он будет бесполезен, но уже через несколько месяцев начнет приносить пользу, а через год отобьет все затраты. А еще можно сэкономить, или точнее мало потерять, если джуниор не прошел испытательный срок. Такая потеря не особо болезненна по сравнению с потерей более высокооплачиваемого специалиста. Один сеньор может распараллелить работу, нагрузив трех джуниров задачами не высокой сложности, беря на себя более высокоуровневые и сложные задачи. Тем самым сделаем продукт, а заплатим меньше, хотя может и не столь идеально и быстро. А еще беря джуниора на небольшую ЗП, мы не подрываем устоявшиеся зарплатные планки внутри компании.
Практически все доводы несостоятельны. Давайте по порядку.
Себестоимость продукта с джунами выше чем с профессионалами
Платя зарплату джуниору, вы не платите за работу над продуктом, вы платите этакий базовый минимум, чтобы ему было на что существовать, ну и конечно за надежду, что когда-то и он полноценно встанет у станка. Дальнейший рост зарплаты от старта сильно не пропорционален росту эффективности. Т.е. себестоимость выполненной работы у малоквалифицированного сотрудника выше, чем у более квалифицированного. Поясним это. Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла — это две ЗП джуниора, а сеньора — 3 зарплаты джуниора. Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов — 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности.
График построен на моем опыте. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым.
Фредерик Брукс, Пол Грэм, Дядя Боб считали, что высокопрофессиональные разработчики эффективнее остальных от пяти до десяти раз. Таким образом становится совсем очевидно, что каждый вложенный рубль в сеньора окупается гораздо быстрее, чем в джуниора.
"Мифический человеко-месяц":
Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной
производительности в среднем составило 10:1, а для времени работы программы и затрат памяти — 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)
Коммуникация — узкое место
Продолжая сравнивать 3 джуниоров против одного сеньора нельзя забывать и о том, что на коммуникацию и синхронизацию 3 джуниров уйдет порядка 10-20% общего времени. Чем больше людей, тем больше издержек. Таким образом, набор джуниоров идет и против стратегии сохранения наименьшего количества разработчиков работающих над проектом. То, о чем говорил Келли Джонсон в Skunk Works, ну и конечно же Брукс.
Джуниор — это инструмент, но не самодостаточная единица
Джуниор как правило совершенно не способен решать задачи высокой сложности. И есть иллюзия, что он может решать простые задачи. Да может, но если это задачи в вакууме. Но в рамках сложного продукта простота задачи может быть не столь очевидна.
Тут уже нужно виденье, которое есть только у сеньора. Моя практика говорит, что простых задач в сложных продуктах нет, есть лишь степень ответственности сеньора. Джуниор может не заметить, что "простая" задача на самом деле требует сложного решения, не увидеть потребности в рефакторинге. Зрение джуниора достаточно узко и не глубоко. И требует тщательного контроля, усиленного вникания старших товарищей в суть "простой" задачи, что бы не пропустить сложность. И как правило такое погружение и выполнение задачи по времени превышает время самостоятельного выполнения задачи сеньором.
На короткой дистанции джуниор может казаться эффективнее, чем он есть на самом деле, но только если не считать общую эффективность в долгую, учитывая что вернулось бумерангом.
Подобное к подобному
Профессионалу интересно работать с профессионалами, они тянутся друг к другу. Синергия их качеств рождает верные решения. Работа в интересной команде с интересным продуктом может привлекать не меньше, чем высокая оплата труда.
Джуниорам нужны профессиональные разработчики чтобы расти. Но большое количество мидлов и джуниоров просто топят синьоров. Талантливые джуниоры вымываются в более интересные коллективы. В команде на долго зависают вечные джуниоры и мидлы. Профессиональные разработчики тоже теряют интерес и уходят, либо тупеют под количественным давлением не компетенции. При таких звоночках скорее всего и остальные взгляды на построение продукта расходятся со взглядами талантливых джунов, что еще больше подпитывает их бегство в успешные компании. Дальше начинается замкнутый круг.
Наем профессионала vs джуниора
Сеньора отчасти проще проверить. Он знает чего хочет, с ним можно говорить и не быть снисходительным на молодость, на то, что человек не обстрелянный. Его можно гораздо более точно оценить и не гадать на кофейной гуще, что же вылупится из яйца в итоге. За плечами есть проекты, которые можно обсудить и оценить, посмотреть код на гитхабе, провести сеанс парного программирования.
Возможно величина ошибки при неудачном найме профессионала выше, но вероятность ошибки гораздо ниже.
Наем джуниоров — это гораздо большая лотерея. Какой процент джунов у вас выросли в сеньоры? Конечно же мы не рассматриваем явных талантов из хороших вузов, которые не светят в нашем случае.
Наличие блеска в глазах, психологической совместимости, способности писать алгоритмы и код почти всегда не является признаком, что из человека выйдет сеньор или даже добротный мидл. Сколько раз сталкивался с тем, что все этого присутствует, а способность решать задачи отсутствует.
По хорошему для эффективного найма требуется потоковая промывка джуниоров в поисках золотых песчинок на базе стажировки. Суммарные затраты на весь этот процесс на столько велики, что это не про маленькие или бедные компании.
Джуниоры крадут время у наиболее боеспособных единиц
При подключении нового разработчика, сеньор или другой опытный член команды будет тратить свое ценное время не на создание продукта, а на обучение и вовлечение в проект. Очевидно на джуниора придется потратить на порядок больше времени и умножить на 3, если джуниоров три против одного возможного сеньора.
Подводя итоги: команда мечты
Получается что вообще сторониться джуниоров? Куда же им тогда податься?
Конечно же джуниоров можно брать, но на "сдачу". Наем джуниоров как стратегия на далекое будущее, в некотором роде рискованные инвестиции. По моему опыту на команду из 5 человек максимально допустимо иметь 1 джуниора и 1 мидла. И это не история про то, что джун и мидл это тестеры, devops'ы, техписы.
Допустим у нас на команду есть бюджет 550-600 т.р.
Можно пойти двумя путями и попытаться сформировать классическую команду из 7 человек, либо сделать упор на максимальное количество профессиональных разработчиков.
Попытаемся представить как могла бы выглядеть первая команда:
Команда строящаяся на основе джуниоров
Для каждого разработчика в списке ниже расставим крайне усредненную производительность на основе озвученного ранее.
1) Сеньор-лид — 150 т.р. (8х — 4x (Половина времени на обучение и организацию) = 4x)
2) Мидл? — 110 т.р. (5х — 1х Обучение = 4х)
3) Мидл? — 80 т.р. (2x)
4) Мидл? — 65 т.р. (1x)
5) Мидл? — 60 т.р. (1x)
6) Джун — 55 т.р. (0.2x)
7) Джун — 50 т.р (0)
Общая производительность без учета потерь на коммуникацию: 12.2x
Принято считать, что добавление каждого нового члена в команду отъедает до 5% общего времени на коммуникацию. Т.о. общая производительность с учетом потерь на коммуникацию: 12.2x * 0.7 = 8.54x
КПД: 66 т.р. за 1x производительности.
Проблемы этого варианта, кроме низкого КПД:
- Сложность уменьшения текучки кадров. Много сотрудников находятся на этапе быстрого роста ЗП. Уровень ЗП должен соответствовать навыкам и рынку, а это бывает сложно синхронизировать. Проще уйти в другую компанию с повышением ЗП. Ко всему прочему, можно допустить, что такое стремление сократить издержки на людей негативно отразится и на ЗП ведущих разработчиков, заставив их чаще посматривать на сторону.
- Сложность удержания бюджета. Зарплаты у джуниоров на начальных этапах растут опережая инфляцию и производительность.
Команда на основе сеньоров
1) Сеньор-лид — 170 (8x — 2x (Орг. деятельность) = 6х)
2) Сеньор — 160 (8x)
3) Сеньор — 160 (6x)
4) Мидл — 100 (3x)
Общая производительность без учета потерь на коммуникацию: 23x
Общая производительность с учетом потерь на коммуникацию:23x * 0.8 = 18.4x
КПД: 32 т.р. за 1x производительности.
Дополнительные плюсы, кроме высокого КПД:
- Большой запас по КПД дает возможность увеличения ЗП для удержания сотрудников, прежде чем команда станет не эффективна по сравнению с командой на джуниорах
- Продукт качественнее (быстрее, эффективнее, юзабельнее, проще)
Выводы
Стратегия найма на основе джуниоров заведомо проигрышна по отношению к тем, кто будет набирать сеньоров. Команда из сеньоров экономически гораздо эффективнее команды с большим количеством джуниоров и мидлов в любой момент времени. Более щепетильный подсчет эффективности, хотя бы учитывая упомянутые выше факторы, только увеличит этот разрыв. Поводом брать джуниоров и растить сеньоров, может быть случай, когда сеньоров нельзя найти в принципе, либо как способ перехватить супер талантов, но держа в уме, что вернутся на прежнюю производительность после найма джуна можно будет не скоро.
===========
Источник:
habr.com
===========
Похожие новости:
- [.NET, Управление разработкой, Управление персоналом] Как быть тимлидом и продолжать программировать
- [Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] 5 мифов о тимлидах. Как стать тимлидом и избежать ошибок
- [Управление персоналом, Карьера в IT-индустрии] Где работать в ИТ в 2020: Тинькофф
- [IT-эмиграция, Управление персоналом, Карьера в IT-индустрии, IT-компании] Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
- [PostgreSQL, Управление разработкой, DevOps] Patroni cluster (with Zookeeper) in a docker swarm on a local machine
- [Управление разработкой, Управление персоналом] Заметки тимлида
- [Управление разработкой, Управление персоналом, Удалённая работа] Три проблемы удаленной работы: личный опыт от разработчика до менеджера
- [Исследования и прогнозы в IT, Управление персоналом, Карьера в IT-индустрии] Смотрим, сколько зарабатывают в Glassdoor
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом, Конференции] Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 2
- [Управление разработкой, Управление проектами, Управление персоналом, IT-компании] Грозовая туча помогает разрешать конфликты
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_hiring, #_junior, #_senior, #_versus, #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:36
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Мало кто хочет брать джуниор-разработчиков в трещащий по швам проект. Однако берут. И я заметил, что есть компании, в которых боятся брать сеньоров. Компания предпочтет взять нескольких джуниоров вместо одного сеньора. Мысль взять одного сеньора вместо мидлов или джуниоров, можно сказать, даже и не рассматривается. Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте. Дисклеймер №1: Безусловно разделение на junior-middle-senior, используемое в статье, крайне условное и мало связано с опытом работы, а градация и зарплатные уровни сильно зависят от компании, в которой дается оценка. Однако мы живем в реальности, в которой на hh в вакансиях ведущих it компаний используется такая терминология, и все мы, так или иначе, понимаем о чем речь, и примерно какой набор требований предъявляется в том или ином случае. И предвосхищая дальнейший текст статьи, заверяю, что абсолютные величины не так важны для сделанных выводов. Дисклеймер №2: Рассуждения по большему счету не про топ компании, в которых и так все в порядке, а скорее про остальное большинство. Так же разговор идет про технически сложные продукты, правда в возможность существования простых, в общем случае, особо и не верю. Простые продукты (вспоминая Пола Грэма и его книгу "Хакеры и Художники") вряд ли могут успешно существовать на конкурентном рынке, в противном случае их было бы слишком просто скопировать и повторить. В классическом варианте конечно же есть стремление сэкономить. Джуниору можно мало платить. Их много на рынке, их легче взять. Да, первые месяцы он будет бесполезен, но уже через несколько месяцев начнет приносить пользу, а через год отобьет все затраты. А еще можно сэкономить, или точнее мало потерять, если джуниор не прошел испытательный срок. Такая потеря не особо болезненна по сравнению с потерей более высокооплачиваемого специалиста. Один сеньор может распараллелить работу, нагрузив трех джуниров задачами не высокой сложности, беря на себя более высокоуровневые и сложные задачи. Тем самым сделаем продукт, а заплатим меньше, хотя может и не столь идеально и быстро. А еще беря джуниора на небольшую ЗП, мы не подрываем устоявшиеся зарплатные планки внутри компании. Практически все доводы несостоятельны. Давайте по порядку. Себестоимость продукта с джунами выше чем с профессионалами Платя зарплату джуниору, вы не платите за работу над продуктом, вы платите этакий базовый минимум, чтобы ему было на что существовать, ну и конечно за надежду, что когда-то и он полноценно встанет у станка. Дальнейший рост зарплаты от старта сильно не пропорционален росту эффективности. Т.е. себестоимость выполненной работы у малоквалифицированного сотрудника выше, чем у более квалифицированного. Поясним это. Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла — это две ЗП джуниора, а сеньора — 3 зарплаты джуниора. Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов — 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности.  График построен на моем опыте. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым. Фредерик Брукс, Пол Грэм, Дядя Боб считали, что высокопрофессиональные разработчики эффективнее остальных от пяти до десяти раз. Таким образом становится совсем очевидно, что каждый вложенный рубль в сеньора окупается гораздо быстрее, чем в джуниора. "Мифический человеко-месяц": Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной
производительности в среднем составило 10:1, а для времени работы программы и затрат памяти — 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.) Коммуникация — узкое место Продолжая сравнивать 3 джуниоров против одного сеньора нельзя забывать и о том, что на коммуникацию и синхронизацию 3 джуниров уйдет порядка 10-20% общего времени. Чем больше людей, тем больше издержек. Таким образом, набор джуниоров идет и против стратегии сохранения наименьшего количества разработчиков работающих над проектом. То, о чем говорил Келли Джонсон в Skunk Works, ну и конечно же Брукс. Джуниор — это инструмент, но не самодостаточная единица Джуниор как правило совершенно не способен решать задачи высокой сложности. И есть иллюзия, что он может решать простые задачи. Да может, но если это задачи в вакууме. Но в рамках сложного продукта простота задачи может быть не столь очевидна. Тут уже нужно виденье, которое есть только у сеньора. Моя практика говорит, что простых задач в сложных продуктах нет, есть лишь степень ответственности сеньора. Джуниор может не заметить, что "простая" задача на самом деле требует сложного решения, не увидеть потребности в рефакторинге. Зрение джуниора достаточно узко и не глубоко. И требует тщательного контроля, усиленного вникания старших товарищей в суть "простой" задачи, что бы не пропустить сложность. И как правило такое погружение и выполнение задачи по времени превышает время самостоятельного выполнения задачи сеньором. На короткой дистанции джуниор может казаться эффективнее, чем он есть на самом деле, но только если не считать общую эффективность в долгую, учитывая что вернулось бумерангом. Подобное к подобному Профессионалу интересно работать с профессионалами, они тянутся друг к другу. Синергия их качеств рождает верные решения. Работа в интересной команде с интересным продуктом может привлекать не меньше, чем высокая оплата труда. Джуниорам нужны профессиональные разработчики чтобы расти. Но большое количество мидлов и джуниоров просто топят синьоров. Талантливые джуниоры вымываются в более интересные коллективы. В команде на долго зависают вечные джуниоры и мидлы. Профессиональные разработчики тоже теряют интерес и уходят, либо тупеют под количественным давлением не компетенции. При таких звоночках скорее всего и остальные взгляды на построение продукта расходятся со взглядами талантливых джунов, что еще больше подпитывает их бегство в успешные компании. Дальше начинается замкнутый круг. Наем профессионала vs джуниора Сеньора отчасти проще проверить. Он знает чего хочет, с ним можно говорить и не быть снисходительным на молодость, на то, что человек не обстрелянный. Его можно гораздо более точно оценить и не гадать на кофейной гуще, что же вылупится из яйца в итоге. За плечами есть проекты, которые можно обсудить и оценить, посмотреть код на гитхабе, провести сеанс парного программирования. Возможно величина ошибки при неудачном найме профессионала выше, но вероятность ошибки гораздо ниже. Наем джуниоров — это гораздо большая лотерея. Какой процент джунов у вас выросли в сеньоры? Конечно же мы не рассматриваем явных талантов из хороших вузов, которые не светят в нашем случае. Наличие блеска в глазах, психологической совместимости, способности писать алгоритмы и код почти всегда не является признаком, что из человека выйдет сеньор или даже добротный мидл. Сколько раз сталкивался с тем, что все этого присутствует, а способность решать задачи отсутствует. По хорошему для эффективного найма требуется потоковая промывка джуниоров в поисках золотых песчинок на базе стажировки. Суммарные затраты на весь этот процесс на столько велики, что это не про маленькие или бедные компании. Джуниоры крадут время у наиболее боеспособных единиц При подключении нового разработчика, сеньор или другой опытный член команды будет тратить свое ценное время не на создание продукта, а на обучение и вовлечение в проект. Очевидно на джуниора придется потратить на порядок больше времени и умножить на 3, если джуниоров три против одного возможного сеньора. Подводя итоги: команда мечты Получается что вообще сторониться джуниоров? Куда же им тогда податься? Конечно же джуниоров можно брать, но на "сдачу". Наем джуниоров как стратегия на далекое будущее, в некотором роде рискованные инвестиции. По моему опыту на команду из 5 человек максимально допустимо иметь 1 джуниора и 1 мидла. И это не история про то, что джун и мидл это тестеры, devops'ы, техписы. Допустим у нас на команду есть бюджет 550-600 т.р. Можно пойти двумя путями и попытаться сформировать классическую команду из 7 человек, либо сделать упор на максимальное количество профессиональных разработчиков. Попытаемся представить как могла бы выглядеть первая команда: Команда строящаяся на основе джуниоров Для каждого разработчика в списке ниже расставим крайне усредненную производительность на основе озвученного ранее. 1) Сеньор-лид — 150 т.р. (8х — 4x (Половина времени на обучение и организацию) = 4x) 2) Мидл? — 110 т.р. (5х — 1х Обучение = 4х) 3) Мидл? — 80 т.р. (2x) 4) Мидл? — 65 т.р. (1x) 5) Мидл? — 60 т.р. (1x) 6) Джун — 55 т.р. (0.2x) 7) Джун — 50 т.р (0) Общая производительность без учета потерь на коммуникацию: 12.2x Принято считать, что добавление каждого нового члена в команду отъедает до 5% общего времени на коммуникацию. Т.о. общая производительность с учетом потерь на коммуникацию: 12.2x * 0.7 = 8.54x КПД: 66 т.р. за 1x производительности. Проблемы этого варианта, кроме низкого КПД:
Команда на основе сеньоров 1) Сеньор-лид — 170 (8x — 2x (Орг. деятельность) = 6х) 2) Сеньор — 160 (8x) 3) Сеньор — 160 (6x) 4) Мидл — 100 (3x) Общая производительность без учета потерь на коммуникацию: 23x Общая производительность с учетом потерь на коммуникацию:23x * 0.8 = 18.4x КПД: 32 т.р. за 1x производительности. Дополнительные плюсы, кроме высокого КПД:
Выводы Стратегия найма на основе джуниоров заведомо проигрышна по отношению к тем, кто будет набирать сеньоров. Команда из сеньоров экономически гораздо эффективнее команды с большим количеством джуниоров и мидлов в любой момент времени. Более щепетильный подсчет эффективности, хотя бы учитывая упомянутые выше факторы, только увеличит этот разрыв. Поводом брать джуниоров и растить сеньоров, может быть случай, когда сеньоров нельзя найти в принципе, либо как способ перехватить супер талантов, но держа в уме, что вернутся на прежнюю производительность после найма джуна можно будет не скоро. =========== Источник: habr.com =========== Похожие новости:
Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:36
Часовой пояс: UTC + 5