{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Как договориться заказчику с программистом

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

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

Откровенный развод

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

Как может кинуть программист:

  1. Берёт в работу произвольную задачу, предлагая очень вкусную цену
  2. Особо не вникает в детали и просит предоплату 30‑50%
  3. Просит не беспокоить до дедлайна — всё под контролем
  4. Делает какие-то простые вещи по проекту
  5. В момент дедлайна резко сливается, либо игнорируя, либо заявляя, что реализованный объём как раз укладывается в предоплату и далее он продолжать не может, т.к. [придумайте причину сами].

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

Как может кинуть заказчик:

  1. Даёт обтекаемое ТЗ
  2. Отправляет предоплату 30‑50%
  3. После получения результата сообщает, что имел ввиду совсем иначе
  4. Требует переделать бесплатно
  5. После двух-трёх итераций переделок сообщает, что программист не справился и остатка не будет, мол он пойдёт на оплату работы другого программиста.

Как правило, программиста дотапливают почти до конца и доработка будет стоить явно не 50‑70% от бюджета, если она вообще будет заказываться…

Проблемы недоговорённостей

Однако, чаще всего, проект заваливается и заказчик с программистом ссорятся не из-за изначального умысла, а из-за недоговорённостей.

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

В итоге, в конце проекта, а, чаще всего, спустя несколько месяцев после сдачи, заказчик внезапно «вспоминает», что без этой валидации никак нельзя запускать проект и требует её переделать, добавив валидацию. При этом очень часто не стесняясь в выражениях в стиле «Ничего не работает», «это и так очевидно», «я покупал продукт».

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

Очевидно, что желания работать с таким клиентом у программиста не появится. На самом деле, возможно, изначальная цена бы и не изменилась, если бы заказчик озаботился тем, чтобы указать все принципиальные для него моменты в рамках ТЗ. А в приведённом примере, ситуация выглядит так, что заказчик не хочет вникать в проект ни на старте, ни во время приёмки, а потом считает, что можно передоговориться задним числом.

Чтобы максимально избежать таких ситуаций и, как минимум, помочь программистам задать наводящие вопросы, мне и пришла идея канала с типовыми заготовками, на основе которых можно уже дописывать индивидуальное ТЗ. 50‑70% в схожих проектах идентично и всё внимание как раз концентрируется на принципиальных нюансах — шанс недосказанности уменьшается.

Иллюстрации

Пообщавшись с заказчиками и программистами выявил ещё ряд проблемных точек, при которых они сталкиваются лбами. Решил оформить их в виде цитат и написать, как это выглядит со стороны.

Доверие

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

Евгений, Программист

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

Сергей, Заказчик

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

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

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

Недавно мы проиграли тендер на приложение интернет-магазина. Заказчик выбрал подрядчика, который предложил чек в 1,5 раза больше. Даже не получив заказ я почувствовал уважение к этому выбору — у нас магазинов в портфолио не густо, у победителей — это основная специализация. Заказчик предпочёл переплатить 50%, но получить снижение риска завала проекта.

Коммуникации

Коммуникации с программистом важно свести к минимуму.

Евгений, Программист

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

Сергей, Заказчик

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

Адекватно будет договориться об отчёте каждые 2 дня в формате что было сделано за 16 часов и как это проверить. Если отчёта нет или он написан в формате «сделано огого, но проверить можно будет только в конце» — это повод волноваться.

Вместе с тем, заказчику стоит избавить программиста от дерготни в стиле «как дела» в несогласованное время. Разработка — дело творческое и выдернув программиста в неправильный момент, можно на несколько часов увеличить срок реализации. Отвлекли 10 раз — вот вам и недельная задержка.

Оценки и доработки

Вдруг у меня пришла идея доработок и мне нужно оценить её? Это же выгодно для программиста — он денег больше получит.

Сергей, Заказчик

Её можно поставить после реализации текущего спринта. Отвлекая и отменяя задание можно запороть в принципе текущий спринт.

Евгений, Программист

Заказчика, как человека из бизнеса, постоянно посещают идеи по развитию проекта. Само собой, он хочет понимать сколько это стоит, причём, не факт, что он будет это заказывать.

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

Крайне важно идти недельными спринтами, в рамках которых задание не меняется и программист не отвлекается от текущего объёма. При правильной коммуникации — это даёт ускорение в 20‑30% и адекватного программиста в финале, который будет только рад продолжить работу с таким заказчиком.

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

Постоянная дерготня в произвольно время — это как раз один из красных флажков для программиста.

Заказчик тоже работает

Как лучше делить на спринты? Я планировал отправить 50%, уехать в отпуск проверяя раз в 2 дня отчёт и, в конце, увидеть конечный продукт.

Сергей, Заказчик

Любой проект должен развиваться версионно, в первые несколько спрнтов у вас должна появится главная функция, вплоть до авторизации и какой-то ленты событий. Затем формируются спринты увеличивающие этот функционал. Так вы действительно сможете увидеть рост функциональности, а не результат в конце.

Евгений, Программист

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

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

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

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

Программист чувствует некий обман со стороны заказчика и безответственность за ранее сказанные слова. Очень часто это подкрепляется угрозами в стиле «делай, а то не подпишу акт» и обида переходит в открытый конфликт.

Резюме по всем иллюстрациям можно свести к нескольким тезисам:

  • Все ключевые вещи, не важно, считаете ли вы их входящими в работу «по умолчанию» или нет, нужно оговаривать и прописывать в ТЗ. Если что-то не написано, значит вы доверяете программисту и готовы доплатить, если что-то не понравится.
  • Нужно минимально отвлекать программиста на произвольные разговоры о будущем и максимально контролировать текущую работу, как можно быстрее давая обратную связь, что что-то пошло не так, если видите несоответствие своим изначальным идеям.
  • В случае возникших проблем, важно уметь слушать и слышать вторую сторону. Желание продавить силой часто приводит к неожиданным последствиям как для одной, так и для другой стороны.
0
32 комментария
Написать комментарий...
Виталий Подольский

Толковый материал. Но еще есть проблема гарантийной поддержки продукта. Часто заказчик думает, что проект после запуска будет дорабатываться бесплатно. Это же поддержка, типа, а не новые фичи. Ну и собственно, сама поддержка и багфикс должен быть осуществлен бесплатно и через пару лет, даже если это проблема изменений АПИ операционной системы, а приложение до того работало стабильно.

Ответить
Развернуть ветку
Фёдор Гребенников

Мы в договоре учитываем.
Может кому пригодится, а может кто посоветует, как улучшить:

2.5. Гарантийное обслуживание 

2.5.1. Гарантийное обслуживание начинается с момента размещения сайта в сети Интернет на рабочей площадке и доменном имени. Срок гарантийного обслуживания составляет 6 (шесть) месяцев. 

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

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

2.5.4. Подрядчик, получив от Заказчика уведомление (рекламацию, претензию) по недоработкам, обязуется в течение 5 (Пяти) рабочих дней рассмотреть требования Заказчика, провести диагностику проблемы, и предоставить письменный ответ в адрес Заказчика. 

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

2.5.6. В случае, если в ходе диагностики выявлено, что ошибка в работе сайта не является качественной или количественной недоработкой, Подрядчик выставляет Заказчику счет за ее диагностику и устранение по фактически затраченному времени по действующим тарифам Подрядчика на техническую поддержку – ___ рублей за 1 час работы специалиста. Фактически затраченное на диагностику и устранение время устанавливает Подрядчик на основании табельного учета часов, отработанных каждым специалистом Подрядчика по данным работам. 

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
Фёдор Гребенников

А потом жалуетесь...
Самый сложный этап любой кастомной разработки - корректно перенести мысли из головы заказчика в голову исполнителя. По сути, задача программиста – реализовать ваши бизнес-процессы в виде работающего кода/продукта. А чтобы их реализовать – надо их досконально понять. 
Нафиг никому не нужна ваша "информация о бизнесе" и "комуниздить подноготную" вне контекста решения задачи по разработке.

Ответить
Развернуть ветку
Anna Nelson

Ага, потом на рынок вылезают клоны сервисов или копии продуктов. Никому ничего не надо, наверное так же как и личная информация, которую не собирает каждый первый.

Ответить
Развернуть ветку
Фёдор Гребенников

Вот не работает это так.

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

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
АНТИРИУС

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

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
АНТИРИУС

Кто сделал и кто воспользовался наработками?)

> Не думаете же вы, что программисты мечтают всю жизнь программировать, нет, все ищут рабочие схемы по заработку

Это само собой, все ищут. Но вот Ваша идея взлетит, ЕСЛИ ТОЛЬКО у Вас есть какие-то знакомства или дофига денег на раскрутку. Везде полно идей, вот только идея не стоит ничего, точнее она стоит МИНУС дофига денег. Из которых затраты на ИТ систему - это капля в море.

Ответить
Развернуть ветку
Виталий Подольский

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

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Есть такое понятие, как сграбить вёрстку. 

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
Валерий Позднев

Предположим, нам заказали доработку продукта по функционалу. Мы его сделали, не передавая никаких прав заказчику. Теперь у нас есть модуль, который мы с радостью продадим ещё 10 или 100 раз. Понятно, что Вы больше про лендинги говорите, но в целом, ИТ так работает, если заказчик не оформляет эксклюзивную разработку. В любом случае, Ваши сетования на то, ИТ выясняют детали о бизнесе - мимо кассы. Детали нужны для понимания и реализации, а то, что продукт получился благодаря этому хороший и его теперь можно продать потоком - ну, так это гордость команды разработки )

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
Валерий Позднев

Ок, попробуем ещё раз. Я сейчас работаю в системном интеграторе. Допустимая мы поставили клиенту какой-то продукт, спустя время клиент спрашивает, а нет ли у нас функционала к нему, который поможет в бизнесе. Ну, не знаю, например - возможность показать объект на карте. Такого функционала нет, но мы обсуждаем детали, и приходим к выводу, что можем такое допилить. Пробуем. Получается. Говорим клиенту, что сделали доработку, покупаете? Клинт радостно берет, а в портфеле фирмы появляется продукт, который может быть продан кому-то ещё. В чем проблема-то? Допустим, в монтаже: пришел клиент, заинтересованный в высотных работах. Фирма этого не делала, но наняла высотника, все сделали. Теперь Вы требуете: раз работа была сделана в консультации с Вами, то после завершения работ мы должны уволить монтажника и больше не вести таких работ, вместо того, чтобы добавить их в портфолио команды. Степень маразма ощущаете?

Ответить
Развернуть ветку
Anna Nelson

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

Ответить
Развернуть ветку
Валерий Позднев

Толсто. Любое творчество ложится в портфолио. Если просят сделать винтик ещё раз, никто не станет строить отдельный завод по производству винтиков с нуля. Хотите, чтобы винтик был только ваш - патентуйте, платите за производственную линию и указывайте эксклюзивность отдельным договором. Вот только любой суд завернет ваши гениальные претензии на уникальность , если вы сделали сайт, которого не было ни у кого - такие разработки не могут быть монополией. Ютуб же не гоняется за всеми видео-клонами. Брать надо коммерческими выгодами от использования вашей идеи, а не ее недоступностью другим участникам рынка. Так и до антимонопольных законов можно доиграться ).

Ответить
Развернуть ветку
Anna Nelson

Да все верно, только речь идет о вопросах, которые задают конторы и которые, на мой взгляд, они не должны задавать)  

Ответить
Развернуть ветку
Валерий Позднев

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

Ответить
Развернуть ветку
Anna Nelson

Послушайте, если бы я была по другую сторону баррикады, я бы может еще и дописала вопросов) Но я выступаю в качестве клиента и я пытаюсь донести, что если бы вопросов не по теме было бы меньше, то это на мой скромный взгляд, улучшило бы ситуацию, ну а пока это 100% отказ, опять же лично для меня.

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

Ответить
Развернуть ветку
David Evdoschenko

Все эти проблемы вам приходится решать в силу отсутствия конкуренции. На самом деле этих проблем нет, когда есть рынок. А когда его нет - нет и пилюли волшебной. 
Что такое программист вообще? Примеры кейсов из статьи очень забавны. 
И вот пример реальной задачи для программирования:
"Имеется 20 больших файлов (по гигабайту). В каждом файле записаны 32-битные числа в неубывающем порядке. Нужно найти медиану множества всех этих чисел. В распоряжении имеется только компьютер с 4 килобайтами свободной оперативной памяти".

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

Ответить
Развернуть ветку
АНТИРИУС

У Вас в ТЗ нет требований к вводу данных и как вывести результат, вот о чем статья)

Ответить
Развернуть ветку
Лев Щенин

Только человек, которого несколько раз обманывали программисты (первый раз - в 1994 году, последний - в 2013 году) может понять некоторые пункты статьи господина Гордиенко. Я понимаю.
Сам господин Гордиенко сейчас борется на форумах с одним из "обманутых заказчиков", так что многое из его статьи "написано кровью проваленных проектов". (в смысле "не стреляйте в пианиста, он так играет").
Открыть проект готовых технических заданий - отличная идея, которая сэкономит миллионы рублей заказчиков и миллиарды нервных клеток программистов. 

Ответить
Развернуть ветку
Виталий Подольский

Адепт секты брайтмобайл? 

 Сам господин Гордиенко сейчас борется на форумах с одним из "обманутых заказчиков"

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

Ответить
Развернуть ветку
Лев Щенин

Виталий, я за правду.
Я сам задавал господину Гордиенко вопрос про "обманутого Егора".
Вместо ответа господин Гордиенко дал ссылку на другую ветку форума.
Единственный выход узнать "кто прав,кто виноват" - это дождаться заявления следующего заказчика, "обманутого" господином Гордиенко.
По словам и видеороликам господина Гордиенко, его компании - более 10 лет, число заказчиков за это время должно перевалить за сотню.
Один "обманутый" заказчик из ста за десять лет - недостаточно, чтобы обвинить 
 господина Гордиенко в плохой работе.
Виталий, вам понятна моя логика?

Ответить
Развернуть ветку
Виталий Подольский

Да, понятна

Ответить
Развернуть ветку
АНТИРИУС
не в той ветке ответил
Ответить
Развернуть ветку
Федя Родион

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

Ответить
Развернуть ветку
АНТИРИУС

Так тут статья про фрилансеров. 

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

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Вот примерно об этом я и писал. Мало того, что вы не потрудились прочесть первое предложение моей статьи, так ещё и попытались всех верстальщиков оскорбить. 
Обязательно верну вам деньги заплаченные за статью. 

Ответить
Развернуть ветку
29 комментариев
Раскрывать всегда