27 июня 2012 в 19:49

Управление без управления — часть 1

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

Итак, обладая 10 летним опытом работы в IT, и пройдя множество ролей: тестировщик, дизайнер, программист, ведущий программист, руководитель: группы, отдела, подразделения, департамента интернет проектов, директора по развитию и наконец директора.

Я не претендую на авторство — скорее это народное творчество: «слова народные, музыка народная, исполняет — автор».

Поехали!


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

Хороший и профессиональный менеджер управляет по результату:



1. Ориентация на результат

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

2. Всегда установлено время когда результат должен быть представлен

Это правило так же важно, так как даже очень хорошие идеи не будут реализованы, не имей временных границ по их реализаций. Причем нужно не просто спустить срок сверху — исполнитель должен в идеале предложить нужный срок менеджеру. То нужно этим управлять, как? Правильно — не управляя, т.е. не навязывая своего срока сверху. У менеджера есть огромное множество инструментов для этого, алгоритм такой:
  1. попросить специалиста изложить задачу своими словами и дать как можно более полную декомпозицию работ по задаче со своей оценкой
  2. если что-то было не правильно понятно — нужно это уточнить, так как часто исполнитель закладывается в плюс на «туманную постановку»
  3. если все понятно, можно разделить задачи на части, ту часть что нужно сделать к нужной дате с нужным функционалом, а остальное потом
  4. можно поменять приоритетность выполнения задач у исполнителя.

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

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

3. Любой вопрос вне уровня компетенции исполнителя должен быть эскалирован вверх в течении часа

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

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

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

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

Кстати, не забывайте про печеньки и плюшки — это все любят, в любом виде

4. Разбор полетов — обсуждается не вина, а причина.

Самое важное — не говорить критику личности, даже если Вы будете на 120% правы (что очень сомнительно) человек никогда с Вами не согласится и будет очень сильно обижен. Обсуждать надо поступки.

Ошибки возникают всегда, без этого никуда — так мы экономим энергию компании, решая возникающие проблемы и снижая возможность возникновения рисков.

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

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

5. Пожизненный найм

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

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

Здесь вы сами должны определять степень не наказуемости за деяния, но если что-то позволили, то нельзя этот уровень снижать. И чем этот уровень выше — тем более точная обратная связь будет доходить.

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

6. Постоянное повышение качества

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

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

Из практики: сложно только в начале, что нужно всем все объяснять, но зато получается что:
каждый знает, кто/что и зачем делает.

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

Могу сказать, что такое работает или даже рекомендуется в условиях, когда разработка распределенная географически.

Источником это послужила книжка «Альтернативного менеджемента» и теории Деминга, которая легла в основу систему менеджмента Тойоты. Там это работает в промышленных масштабах :), а ваш покорный слуга рискнул создать такую систему в России в веб-разработке и что самое замечательное — получилось!
Если интересны подробности — опишу в следующих частях.

7. Обратная связь

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

Например, когда мы едем на автомобиле мы же не задумываемся, что нужно выжать педаль газа на 3 см, или сцепление на половине двигать плавно. Мы начинаем движение и получаем обратную связь, как реагирует автомобиль на наши изменения. Это и есть нужная нам обратная связь.

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

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

8. Резюме — памятка

  1. важен только результат, а не причина
  2. у всего должен быть срок завершения
  3. эскалирование проблем вверх
  4. делайте разбор полетов сразу после завершения задачи/проекта
  5. пожизненный найм
  6. обратная связь


Важно всегда знать, на верном пути ты или нет. Задавайте себе такой вопрос, каждый день!
Для меня мерило такое — если есть время спокойно попить кофе и никто не орет, что что-то не работает, сломалось, не успеваем (не нужное зачеркнуть) — то ДА, я на верном пути!



И в заключении, для тех кто дочитал до конца — я дам ценный совет:
Хотите быструю и успешную карьеру? Я считаю, что очень важно для менеджера — это брать на себя ответственность и достигать результатов.
Roman Petrov @rms
карма
21,0
рейтинг 0,0
Lean евангелист
Самое читаемое Управление

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

  • +2
    возьмем например
    разработчика, у него возникла какая-то
    проблема с алгоритмом, который он может
    решить самостоятельно, при этом это было
    не запланировано и ему придется сегодня
    задержаться на работе на часик — значит он
    самостоятельно задерживается


    не понимаю я студийное рабство, хоть убей не понимаю!
    • –1
      в каком либо виде оно есть в любом случае
    • +1
      Это что же получается — риски и непредвиденные проблемы перекладываются на исполнителя?
    • +3
      Здесь есть тонкая грань в слове «придется». Если вы работаете один, как фрилансер, или на свой проект, то «придется» или «надо доделать» говорите себе вы. По разным причинам: не хочется откладывать на завтра, терять контекст, завтра есть жругие вещи и т.д. Если в «студийном рабстве» вы руководствуетесь этими же мотивами, то это называется ответственность. Не прнимаю, почему в одном случае это рабство, а в другом свобода настоящей работы на себя.
      • 0
        Согласен. Есть емкое слово — самоменеджмент. У тебя есть в распоряжении свое время — ресурс (день, неделя максимум) и есть задачи — которые решаешь в этих временных рамках. Сделал быстрее отлично, не успел — организовывайся. Никто не даст работы больше, чем реально можно сделать за нормальный день в 8 часов.

        А то, что сотрудник задерживается на работе после 19:00, то это уже сигнал руководителю. Даже у великих спортсменов есть тренер — не задавали почему? Потому, что сам себя не заставишь перейти какие-то рамки и достичь лучших результатов.

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

        Собственно начальник смотрит на приоритеты задач и стратегическое направление.

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

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

        Мир очень справедливый и сбалансированный и вы имеете ровно то, что заслуживаете :). Не нравится? Меняйте себя — а мир под вас подстроится. Хотите обсудить это — пишите в личку
  • 0
    Спасибо за статью, есть над чем подумать.
    Очень интересует пункт «Постоянное повышение качества», какую еще литературу или ресурсы можете посоветовать для изучения в области ИТ?
  • +5
    Между «менеджментом» и «управлением» есть очень существенная разница.

    И по пониманию этой разницы сразу видно или теоретика или практика — практики кстати стараются слово «менеджмент» не упротреблять, поскольку оно настолько изгажено, что любой человек под ним понимает что-то исключительно свое никак не связанное с тем что подразумевает другой.

    Именно по этому самые лучшие менеджеры — это девочки в салоне связи, а руководители себя называют управленцами.

    PS. Хотел было ответы по пунктам разобрать, но махну рукой — Ваши соображения слишком далеки от реальности.
    И кроме учебников по «менеджменту» попробуйте три года творческим коллективом программистов покомандовать — мигом всю эту чушь выбросите из головы.
    • +1
      Это все написано из жизни и собственного опыта.

      У меня опыт 7+ лет управления, в том числе создание департамента разработки интернет проектов с нуля до 50+ человек + распределенное по стране матушке (региональные офисы) в компании 5000+ человек (очень известной, но называть не буду).

      Это управление современное, оно реально работает, возьмите например, Яндекс или Битрикс.

      PS: то что у вас не получилось, не значит, что это не работает.
      Я за свои слова отвечаю! :)
      • 0
        =) Т.е. Вы — управленец среднего звена действующий в рамках заданных руководством? Я правильно Вас понял?
        • 0
          Да, причем данный оазис я сделал только в рамках своего департамента, по своей личной инициативе и соответственно под свою за… ответственность — за что меня и ценят ;)
          • 0
            Не принципиально «сами» или нет — принципиально «среднего» или «высшего». Вы пишите о компетенции высшего руководства, но не особо пока понимаете что это такое покольку им не являетесь.

            Ответственность неотемлемо есть у всех руководителей без исключения и что тут ценить мне лично не понятно — это все равно что хвастаться тем что «дышишь воздухом».
            • 0
              дир. депа я был три года назад ;)
              • +2
                =) И что? Судя по мыслям в посте — Вам еще рано.
                • 0
                  Ну раз уж взялись так критиковать, расскажите о своем опыте, а то получается как-то не солидно.
                  • 0
                    Юношеский задор «чем-то мериться» и «доказывать» как правило проходит после 30.

                    Кстати и публично учить чему либо других начинают как правило только начинающие в этом деле, на самом первом этапе знакомства с оным, когда кажется что надо всем это знать, с повышением профессионального уровня это желание исчезает.
                    • –1
                      Ну по крайней мере теперь мы знаем, что вам не больше 30 :)
                  • –1
                    «Сперва добейся»?
    • 0
      А можете кинуть ссылку на какой-нибудь внятный текст, где описано, в чем же заключается эта существенная разница? Давно хотел понять, да никто не мог объяснить.

      ПС Автору за статью спасибо. Многое из сказанного подтверждено и моим опытом.
      • 0
        Рекомендую Александра Фридмана, в интернете много информации по его тренингам.
  • +4
    Хм…

    Итак, обладая 10 летним опытом работы в IT, и пройдя множество ролей: тестировщик, дизайнер, программист, ведущий программист, руководитель: группы, отдела, подразделения, департамента интернет проектов, директора по развитию и наконец директора :)

    Это как? Я насчитал 7 должностей (тестировщик, дизайнер, программист, ведущий программист, руководитель, директора по развитию, директора ) на 10 лет работы, это получается в среднем 1,5 года на каждой должности?

    И в каждой должности за 1,5 года используя выше изложенный подход можно достигать вершины совершенства?

    За статью спасибо, но верится с трудом и очень похоже на летуна или прыгуна (как там в терминах HR правильно), хотя не исключаю что автор стати действительно Гений.
    • 0
      Дизайн и тестирование, как и программист и ведущий программист уложатся максимум в год, суммарно — это была студенческая подработка и начальный опыт, в основном у меня идет все по управлению с технической подковкой.

      Для HR — компаний менял мало, но часто менял должности вверх :)
      По поводу Гений ли я — оставлю на ваш суд
      • 0
        Спасибо за ответ.

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

    Уже не первый раз встречаю такое мнение, мол, вот ТВОРИТЬ — это престижно, а багфиксинг — мура и неблагодарный рабский труд. Почему? В моих глазах человек, способный исправить баги и заставить продукт работать как раз и является творцом и объектом уважения, а вот чудики, которые в отрыве от внешнего мира лабают чёрти-что, содержащие эти самые баги в огромных количествах и не отвечающие за них — чудики и есть.
    • –1
      Так-то оно так, но разбираться в чужом говнокоде чем-то сродни чистке чужих сортиров. Это надо уважать, но делать это не хочется — вот почему это наказание.

      Еще одна непрестижная профессия — написание тестов. Написать тест, способный поймать ошибку (да еще в сложных условиях, например в многопоточной среде) — большое искусство, но почему-то плятят за это меньше, чем тем, кто эти ошибки делает.
      • 0
        Про написание тестов вы ошибаетесь. И я даже больше скажу, от QA лесенка до архитектора/проджект менеджера существенно короче.

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

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

      Ну это же просто: аргументируем позицию, просим собеседника аргументировать свою. Неужели два взрослых человека не могут договориться, с какой стороны должна быть кнопка?
    • +2
      Попробуйте перенести споры про кнопки на этап перед реализацией. И постройте диалог в стиле — «а как ты думаешь что бы сказал Раскин если кнопку перенести туда-то?». А если пофиг с какой стороны кнопка то и не тратить на это время вообще.
    • 0
      Для начала попробуйте задать себе вопрос — почему у меня не получается указывать на ошибки людей, чтобы их это не задевало?

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

      И третье, тех кто самый спорщик или ярый противник всего и вся :), получите от него план решения какого-то вопроса, поспрашивайте почему так и эдак (т.е. тут вы меняетесь местами — он вам доказывает что нужно сделать, а вы только слушаете и задаете вопросы. Здесь лучше воздержаться от оценок плохо, совсем не то и тд, если что-то звучит правильно и созвучно с вашей мыслью — говорит хорошо, отлично. Это поможет сотрудникам адаптироваться под вас и лучше понимать что нужно предлагать.

      И четвертое — назначьте ответственным за решение такого рода вопросов именно на этого самого ярого противника, тем самым он будет самым лучшим партнером и сам будет подсказывать в будущем, куда лучше двигаться

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

      Более подробно можете почитать литературу по коучинг и корпоративный кроудсорсинг
  • +7
    Приходит консультант на свиноферму, собирают там колхозников.
    -Ну, господа колхозники! Свиней надо кормить.
    -Верно!
    -Ну, а еще их надо держать в тепле.
    -Верно!
    -А еще надо навоз убирать.
    -Ну а как же! Господин консультант, а как же привес у поросят повысить?
    -Ну это вы уж как-нибудь сами, я стратегией занимаюсь…
    ;)
  • +1
    только за его косяки он может выполнять больше не престижной работы, например, для разработчика — это правка багов.


    А как по-вашему стоит наказывать «отдел технической поддержки» (занимаемся допиливанием и модификацией сайтов, у нас 70% работы — правка чужих багов)?

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


    Очень трудно планировать сроки, если знаешь, что каждые пол часа тебя будут дергать «найти вот это», «поправить другой более срочный баг», «переключиться 5 раз на разные другие срочные новые задачи». А руководитель же снял с себя всю ответственность, сотрудник ведь сроки сам предложил, мог бы и догадаться, что будет от 1 до 10 других срочных задач!
    • 0
      В точку.
      И везде нужно успевать — сроки то уже озвучил и обязался сделать…
      И этот «супер-экстра критичный баг» не можешь не исправить!

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

      Отсюда и конфликты.
    • 0
      Делегирование не равно спихиванию ответственности. Почитайте об этом :)

      А во вторых, для этого есть пункт 3, к вам приходят с новым супер срочным багом, а вы говорите — ок, что двигаем? Этот вопрос уже не в вашей компетенции, вы его тут же эскалируете и получаете решение (расстановку приоритетов) и идете дальше выполнять задачи.

      Бывает так, что пришел какой-то постановщик с маленькой задачкой, например, на час, а в процессе выполенения давал уточнения, корректировки на пять часов :) было такое? Так вот тут нужно сразу ставить своего руководителя в известность и это уже его профессиональная работа разруливать такие вопросы.
  • 0
    Соглашаюсь с предыдущими ораторами в комментариях, но также отмечу, что в статье есть и дельные советы. Спасибо.
  • 0
    Спасибо за статью.
    Хороший практический опыт.
    Ждём продолжения.

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

    Какие вы можете посоветовать способы поощрения/наказания для сотрудников?
    Системы мотивации? Не материальные, т.к. не всегда можно влиять на з/п сотрудника.
    Как повысить заинтересованность сотрудников — которым на всё и на всех наплевать?
  • 0
    up
  • +1
    следующий пост по данной теме

    habrahabr.ru/post/146774/ «Позитивный менеджмент»
  • 0
    К сожалению, не работает. Подобные процессы возможны исключительно на основе какой-нибудь бюрократии, что неизбежно влечёт пробуксовку. Простейший пример:

    1. Нашёл проблему, написал менеджеру.
    2. Работа стоит.
    3. У менеджера стопицот подобных запросов.
    4. Работа стоит.

    666. 70% времени тратится на пробуксовку.

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

    Такой подхож возможен разве что в какой-нибудь конвейерной системе, где 90% сотрудников взаимозаменяемы, задачи разбиты на атомарный подзадачи, которые кто угодно может делать. А если не конвейер, а разработка в условиях непрерывно меняющихся требований?
  • 0
    Материал очень интересный, спасибо.

    Единственный недостаток: ваш русский язык хромает, как минимум на полторы ноги.
    • 0
      как бы не на все две :)

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