(ФОТО) Рядом с базаром, школой, Лесным массивом…

 

 

 

 


Вообще интересно, где партия Зеленых? Где этот чувак с косичкой? Они только появляются во время выборов. А так их не видно и не слышно. Для них работы в Украине — море. И не работает тут аргумент мол, 
«людям в Украине не до экологии. Людям важнее зарплата, выживание, что покушать и т.д. Это там на западе, где все сытые и одетые, люди вышли на новый уровень ценностей, в том числе экология.»
Наша партия Зеленых когда бы шаг за шагом представлять и отстаивать интересы конкретных людей. В этом случае — продавцов базара Дарынок, продуктового Базара, работников офисов возле Радикала, жителей Лесного, учеников школы 129, студентов университета на Лесной.
А сколько еще точек по Киеву да и по Украине, где у людей есть конкретные проблемы с экологией возле дома или офиса.

 

ВИДЕО Киев: Лесной = Припять, Радикал = Чернобыльская АЭС


Киевский массив Лесной можно считать г. Припятью, а завод Радикал возле ст.м. Лесная — Чернобыльской АЭС.  
 
Справка о заводе Радикал
 

В 50-е годы «Радикал» начал изготавливать хлор, бертолетовую соль, соляную и серную кислоту, а также каустическую соду. Использовали ртуть. В конце 90-х завод обанкротился. В 1998 году на его территории (завод занимает 60 га) хранилось 134,6 т ртути, 109 т серной кислоты, 44 т ртутных шламов, 62 т соляной кислоты, 12,5 т аммиака и около 2500 т других отходов.

Демонтажом ртутного цеха занималось харьковское подразделение спасателей. Всю видимую ртуть — 120 тонн — они вывезли для переработки на Никитовский ртутный комбинат в Горловку. Но в грунтах под цехом осталось еще порядка 200 тонн опасного металла.

http://kp.ua/daily/130509/179725/

 
На заброшенном завод Радикал ртуть (которая обладает высокой летучестью) разлита везде — в цехах, в земле…
В радиусе 2 км находятся:
— 3 жилых массива
— Школа (1.5 км)
— Университет (1 км)
— Рынки (200 м)
 
 
Вот аматорский видео ролик, который демонстрирует этот кошмар.
 
 
Сообщение автора аматорского видео:
 

"В пяти минутах от станции метро "Лесная" находится такое, что просто несовместимо с нахождением людей в радиусе несколько сот километров. А люди здесь есть — рядом метро, рынки, офисы и жилой массив. Да и весь Киев дышит этим…

Чернобыль ничему не научил — экологическую КАТАСТРОФУ опять скрывают.
Преступление скрывают. Землю в этом месте перекопали бульдозером, а стены и потолок разрушают — чтоб побыстрее выветривалась."

Сюжет из новостей на Интере, 10 мая 2009
 
http://podrobnosti.ua/podrobnosti/2009/05/10/601350.html
 
Вот снова аматорское видео, но уже после огласки этой проблемы:

Сообщение автора аматорского видео: 
 

"Сегодня довелось побывать там снова. Как вы думаете, шум в интернете подействовал?
А как же? Подействовал! Преступление скрывают. Землю в этом месте перекопали бульдозером, а стены и потолок разрушают — чтоб побыстрее выветривалась. А что, это идея — можно разрушить саркофаг не ЧАЭС, радиация от туда выветрится и всё будет круто."

Лесной массив в советские времена считался грязным районом. Рядом с заводом Радикал находятся, а раньше и работали, Дарницкий шелковый комбинат, завод Химволокно, и др. Казалось бы, сейчас это промзона не работает, но от этого в округе не стало чище — наоборот стало грязнее.
 
Для справки:
Токсическое действие ртути

По современной классификации ртуть относится к чрезвычайно токсичным веществам (I класс опасности). При поступлении в организм в повышенных концентрациях ртуть обладает способностью накапливаться во внутренних органах: почках, сердце, мозге.
Интоксикация происходит главным образом через дыхательные пути, что обусловлено высокой летучестью ртути. Порядка 80 % вдыхаемых паров ртути задерживается в организме. Соли и кислород воздуха, содержащие в крови, способствуют поглощению ртути, ее окислению и образованию ртутных солей.
Величина концентраций паров ртути, способных привести к тяжелым хроническим заболеваниям, колеблется от 0,001 до 0,005 мг/м3. Острое отравление может возникнуть при концентрациях 0,13 — 0,80 мг/м3.
Интоксикация со смертельным исходом развивается при вдыхании 2,5 г ртути (паров)
При длительном воздействии даже относительно малых концентраций ртути (порядка сотых и тысячных мг/м3) происходит поражение нервной системы. Основные симптомы: головная боль, повышенная возбудимость, снижение работоспособности, повышенная утомляемость, расстройство сна, снижение памяти, апатия (ртутная неврастения). В отдельных случаях отмечается металлический привкус во рту и воспалительное изменение десен. Одновременно возникают катаральные явления верхних дыхательных путей.
Значительную опасность представляет возможность интоксикации ртутьорганическими соединениями, применяемыми в качестве пестицидов, консервантов, катализаторов. 
ПАК (предельно допустимая концентрация) паров ртути в атмосферном воздухе — 0,0003 мг/м.

http://www.npk-mercury.ru/index.php/toksicheskoe-deistvie-rtuti.html

С хотяновской фермы под Киевом сбежали свиньи. Больные?

Май 9-10, Хотяновка. Когда гуляли вечером 9 мая возле канала увидели Open Air Party. 20 молодых людей, дизель-генератор, диджейский пульт, здоровые колонки, ноутбуки — все прямо на берегу канала. Прикольно, подумали мы с женой. Народ в основном сидел на земле, пили пиво. Музыку было слышно на несколько км вокруг до поздна. Бедные дачники! Как нам показалось, все было цивилизованно. Молодежь висела там до утра. Но вот что мы увидели там на берегу на следующий день. Вот уж СВЫНОТА!

Техническая поддержка: сделай пользователя счастливым


Тема технической поддержки довольно-таки обширная. Условия предоставления, принципы, подходы, процессы и системы ПО для технической поддержки, зависит от сложности и качества продукта, от категории пользователей, на которых рассчитан продукт (бизнес, частные пользователи, техническая подготовка и т.д.), от популярности продукта, от компетенции персонала в вопросах тех поддержки и ряда других факторов.  
Я же хочу поделиться своим опытом и рассказать, как можно организовать техническую поддержку на небольшом проекте (до 30 человек), где производится и поддерживается "коробочный" продукт для конечных пользователей. Например, простенький графический редактор, просмотрщик картинок, почтовый клиент, или другой продукт, которым пользуется рядовые пользователи персонального компьютера или же специалисты из какой-либо отрасли.  
В этом контексте под технической поддержкой я понимаю процесс обработки обратной связи пользователей, в частности, сложности в использовании ПО. 
Далее я опишу критерии успешной технической поддержки, ответственность сторон в этом процессе, опишу некоторые подходы и технику ответов на жалобы пользователей, опишу особенности тех поддержки по почте и с помощью мгновенных сообщений (по чату). 
Почему правильная тех поддержка важна? Правильная тех поддержка: 
— минимизирует негативный опыт пользователей ПО 
— позволяет избежать возврата ПО 
— увеличивает удовлетворенность пользователей и заказчика 
— это положительный пиар вашего продукта 
— это важный источник информации для улучшения продукта 
Схематично процесс тех поддержки со своими входами и выходами будет, выглядит так: 
Вход: 
— Сообщение от пользователя 
Методы и инструменты: 
— Исследование 
— Техническая экспертиза 
— Проектная база знаний  
— Часто задаваемые вопросы 
— Поиск в сети, и др. 
Выход: 
— Уточняющий вопрос пользователю или заказчику (если нужно) 
— Решение для пользователя  
— Запись о проблеме ПО в багобазе  
— Исправление проблемы в ПО 
Критерии успешной тех поддержки 
Когда пользователь говорит что-то вроде "Лучшей тех поддержки я не встречал!" или "Я приятно удивлен как Вы быстро и, по сути, отвечаете!", это означает что, техническая поддержка организована правильно. Помимо этого, вне зависимости от каналов тех поддержки, критерии успешной тех поддержки могут выглядеть так: 
— пользователь ПО быстро получает от вас ответ 
— ответ является конкретным решением пользовательской проблемы 
— пользователь удовлетворен ответом 
— пользователь может продолжать использовать ПО 
— пользователь не возвращает ПО 
— минимизирован негативный опыт пользователя с вашим ПО 
— предприняты все действия по улучшению продукта 
Ключевыми критериями считаю первые 2 пункта — оперативность и полнота ответа. Когда вы обращаетесь за ремонтом автомобиля, вы хотите, чтоб вам помогли "здесь и сейчас" и чтоб в будущем ваш авто не приносил проблем. Вряд ли вас будет интересовать, как производитель авто изменил производственный процесс для улучшения модели в будущем. Улучшение процесса производства — это интерес производителя авто. 
Каналы технической поддержки 
Среди каналов тех поддержки можно выделить: 
— Телефон 
— Электронная почта 
— Мгновенные сообщения (чат) 
— "Часто задаваемые вопросы" (на сайте производителя или в документации пользователя) 
— База знаний 
— Веб-форумы 
Большая часть тех поддержки находится в сеть. Поэтому нужно иметь как минимум 1 канал, по которым Вы будете решать проблемы — э-почта. Со временем, создайте веб-поддержку в виде FAQ (часто задаваемые вопросы), knowledge base, форумы. Эти каналы помогут Вам более эффективно решать типичные и наиболее распространенные проблемы. 
Далее я буду рассказывать про особенности тех поддержки по почте и чату.  Конечно, если у вас есть корпоративные и ВИП клиенты, то нужно непосредственное общение при решении проблем.  
Кто учувствует в тех поддержке? 
В тех поддержке могут участвовать все подразделения проекта по разработке ПО. В первую очередь это менеджмент, программисты, тестировщики. Если объем тех поддержки велик, то возможно понадобится помощь отдельных членов команды — специалистов по тех поддержке, которые будут заниматься исключительно вопросами тех поддержки. Если речь идет о типичных проблемах, то участие программистов и тестеров может и не понадобиться — специалист по тех поддержке или же менеджер проекта вполне сможет решить проблему самостоятельно. Однако если речь идет о какой-то неизвестной, новой, специфичной проблеме, то без помощи программистов и/или тестеров не обойтись. Именно тестеры смогут восстановить конфигурация и окружение, отработать множество сценариев, для воспроизведения проблемы, внести проблему в багобазу. Если же тестеры безуспешно пытались воспроизвести проблему, то никто кроме программиста не сможет посмотреть в код, и возможно выяснить проблему "изнутри". 
Техническая поддержка — это командная работа, вовлеченность конкретных специалистов в которую зависит от сложности проблемы. 
Оперативность технической поддержки 
Скорость, с которой команда реагирует на пользовательские сообщения, отосланные в техническую поддержку, в первую очередь зависит от: 
— квалификации и компетентности персонала, который участвует в технической поддержке 
— правильная приоритетность в решении вопросов тех поддержки 
Компетентность и квалификация специалистов 
Персонал должен знать продукт досконально. Если есть возможность пользоваться продуктом для своей же работы, все должны им пользоваться. Это позволит команде выучить и понимать наиболее реалистичные и частые сценарии работы с продуктом. 
Заведите список типичных проблем и их решений, так чтоб можно было сразу же скопировать в почту. Заведите раздел "часто задаваемые вопросы" на сайте продукта.  
Организуйте процесс тех поддержки так, что персонал, который занимается технической поддержкой, имел доступ к техническому персоналу фирмы, на тот случаи, если вопрос сложный и требует детального технического исследования "внутренностей" продукта.  
Приоритеты 
Не редко отделы тех поддержек гарантируют письменный ответ в течение 8 рабочих часов. Но стремиться ответить "сразу" нужно всегда. Если же команда перегружена технической поддержкой или другими задачами, то полезно будет работать согласно приоритетам, отвечая на самые критические проблемы в первую очередь.  
Пример классификации проблем: 
— Критическая. Пользователь не может установить или запустить продукт. Не может пользоваться продуктом, так как сломана основная функциональность продукта. Потеря данных. Проблему не возможно обойти. 
— Очень серьезная. Не работает функциональность, описанная в документации. Пользователь ограничен в пользовании продуктом. Потеря данных. Но есть временное решение, которое позволяет выполнить необходимую работу. 
— Серьезная. Частичная, некритическая потеря функциональности. Проблема раздражает. Но проблему можно просто обойти. 
— Минорная. "Косметические" проблемы. Проблемы, не влияющие на использование продукта. Ошибки в документации или интерфейсе. Общие вопросы работы продукта. 
Иногда тех поддержка гарантирует определенную скорость ответа, в зависимости от критичности проблемы. Например: 
Критическая — 2 часа
Очень серьезная — 4 часа
Серьезная — 8 часов
Минорная — 12 часов 
Подходы и техника ответов  
  
В общем и целом отвечать нужно, так как бы вы хотели, чтоб отвечали вам. Будьте на стороне пользователя. 
Вот некоторые приемы и правила для повышения качества ответов и удовлетворенности пользователя или заказчика: 
Правило 1: Если Вам недостаточно информации от пользователя или информация не четкая, попытайтесь найти аналогичную проблему в вашем или чужом продукте. Поищите ответ в сети, FAQ, базе знаний. Попробуйте разные сценарии воспроизведения проблемы. Возможно, вам повезет, и вы найдете пользовательский шаги для воспроизведения проблемы. В противном случае, у вас будет подготовлен ответ для пользователя о том, что вы пытались делать для выяснения проблемы. В итоге, пользователь сможет подсказать вам в каком направлении вы должны исследовать проблему. Ну, как минимум, что не маловажно, заказчик или пользователь увидит, как вы стараетесь воспроизвести проблему, как серьезно вы относитесь к проблеме.  
Правило 2: Если исследование проблемы займет значительный промежуток времени, сообщите пользователю, что вы получили жалобу и работаете над ней. Важно, чтоб пользователь знал, что он/она услышан, и вы побеспокоитесь о проблеме.
Правило 3: Если вам нужна дополнительная информация от пользователя, спрашивайте конкретно. Попросите прислать проблемный файл, текст ошибки, или текст лог файла, если таковой создается программой. Избегайте вопросов типа: "Расскажите подробней о вашей проблеме". Лучше 5 конкретных вопросов, чем 1 общий. При этом вопросы должны иметь отношение к проблеме и не выглядеть глупыми. Не исключено, что пользователь, отвечая на конкретные вопросы, самостоятельно найдет решение или действительно уточнит проблему. 
Правило 4: Когда вы отвечаете по существу, Вы должны выйти к пользователю с предложением или гипотетическим решением проблемы, даже если Вы не уверены в правильности решения и вам необходима дополнительная информация. Опять-таки, возможно Вы угадаете с решением. Возможно, в ходе того, как пользователь будет пробовать Ваше решение, проблема сама по себе решится, или пользователь найдет правильное решение самостоятельно. В крайнем случае, пользователь скажет "нет, не получается" и даст уточнения. 
  
Правило 5: Старайтесь, чтоб одного пользователя "вел" один представитель технической поддержки. Если так не получается, то другой представитель должен войти в курс дела до того, как пользователь в очередной раз обратится за помощью. Вспомните, когда вы обращались с вопросом на горячую линию своего банка или интернет провайдера. Вы в сердцах рассказывали о проблеме сотруднику тех поддержки (или просто оператору), а потом этот сотрудник вас переключал на другого сотрудника компетентного в этом вопросе и вы заново должны были рассказать всю вашу историю. Это раздражает, не говоря о трате времени. 
Правило 6: Если Вы видите, что это проблема не вашего продукта, или не совсем вашего продукта (скажем, проблема системы или же другого продукта), то не посылайте пользователя в тех поддержку другой компании. Сперва убедитесь, что Вы действительно не знаете, как решить проблемы другого продукта. Отсылайте в другую тех поддержку только в крайнем случае, когда у Вас вообще нет идеи.  
Вспомните, как у вас пропал интернет, и как вы реагировали, когда ваш интернет провайдер сообщает вам, что у них "с сетью все ОК, обратитесь к вашему системному администратору", которого у вас нет. А проблема могла быть пустяковой — скажем, можно было бы просто посоветовать включить/отключить сервис системы "wireless zero configuration". Да, по умолчанию все должно было бы работать, но специалисты (если они специалисты), могли бы и сами подсказать вам об этом сервисе операционной системы. 
Покажите свой профессионализм, и ваше усердие будет замечено и оценено пользователем или заказчиком.  
Правило 7: В общении с пользователем, используйте простой, понятный язык. Если у пользователей нет технических знаний и опыта, избегайте сложных технических деталей.  Где имеет смысл, используйте скриншоты, демонстрируюше решение для пользователя. 
Помимо этих правил: 
  
— К проблемам, поступающим в тех поддержку можно относиться как к ошибкам в программе, которые находят тестеры. Если ошибка описана правильно, то программист исправляет ошибку сразу. Если ошибка описана не четко, то потребуется уточнения. И чем менее итераций во время уточнения, тем продуктивней работает команда. 
— Не навязывайте пользователям сложные требования к оформлению проблем. Не заставляйте заполнять сложные формы. С одной стороны Вам было бы лучше, если бы пользователи предоставляли исчерпывающую информацию. Но с другой стороны, практика показывает, что в лучшем случае сложные требования пользователь просто проигнорирует, в худшем — не обратится за помощью в тех поддержку, а потом еще и вернет продукт. 
Это приблизительно так же как иногда интернет-магазины требуют зарегистрироваться, заполнив десяток обязательных полей в форме, для покупки товара. Я такие магазины избегаю. 
Далее привожу пример того чего не надо требовать от пользователя, что может отпугивать пользователя. Это часть реальных инструкций по технической поддержке для пользователей, который я нашел в сети. 
2.4 How to submit issues to technical product support 
We ask that you perform the following steps before contacting technical product support to ensure that 
you can provide us with the information we need to resolve your issues: 
1. Gather information on your issues 
2. Save your application 
3. Log new case 
4. Use Case Management to manage your cases 
2.4.1 Gather information on issue 
Before submitting a case,gather the information needed to provide technical product support with data to reproduce and investigate the issue.It is very important to thoroughly prepare the description and supporting data to avoid delays in resolving your issue.We may need and request additional information depending on the nature of the issue. 
When you log a case,the following information is needed: 
• Priority of the problem based on the error classications presented earlier in this document. 
• Product name and version, e.g.Epic Editor 4.3. 
• Hardware platform and operating system version, e.g.Windows 2000. 
• Version of software, e.g.Epic Editor 4.3. 
• Exact full text of any error message and the error number. 
• Simple example of the conditions that trigger the error message.If your sample document is large or you have a complex application,we ask that you attempt to duplicate the problem with a smaller sample document, a distributed document type,or without your application .les. 
• The exact steps required to reproduce the problem.After documenting the steps,try them again before sending them to ensure that the steps are correct. 
•Other explanatory notes regarding the problem.For example,can you reproduce the problem or does it happen intermittently? Does the problem happen to all users or a select few?Does it happen on all workstations or only selected workstations? Does it happen with only one document or many? 
Конечно, это идеальный сценарий того как пользователь должен подавать свои проблемы в тех поддержку. Но цель тех поддержки — не обучить пользователя как обращаться в тех поддержку, а решать пользовательские проблемы. 
A вот такая форма для обращений пользователей на сайте тех поддержки выглядит уже лучше: 
Personal help from 
Which program and version do you need help with? 
Your name: [   ] 
Your email: [   ] 
Your phone (optional): [   ] 
Question topic: [   ] 
Please attach a program file (or other) that demonstrates the problem, if applicable. Click 'Browse' below to select the file to include with your question.(You can only attach one file. If you need to submit multiple files please zip/stuff them into one file.) 
Describe the technical support problem. Be as specific as possible. 

[Submit Request] 
During business hours, we usually answer within a few hours. 
If you have any problem with this form, send an email directly to [mail]  
— Избегайте нескольких адресов э-почты для службы тех поддержки. Не надо вынуждать пользователя присылать заказы на функциональность на zakazy@firma.ua , простые комментарии — на comments@firma.ua , а проблемы на support@firma.ua. Не надо усложнять процесс. Все равно присылать будут куда попало, и у вас будет риск пропустить важную информацию. Пусть пользователи все сообщения присылают на support@firma.ua. 
  
— Добавьте в свой продукт команду в меню "Помощь" — "Техподдержка". При выборе команды создается сообщение и автоматически в тело сообщения вставляется версия продукта, платформа, система и другая информация, которую важно получать от всех кто обращается в тех поддержку. 
  
— Убедитесь, что в ходе тех поддержки не теряются полезные советы по улучшению продукта. Особенно это актуально, когда техподдержкой занимаются отдельные специалисты или департамент по техподдержке.  Техподдержка — это, наверно, главный источник по улучшению продукта. Затраты на техподдержку, в какой-то степени, можно представить как стоимость исследований по улучшению продукта. Если пользователь жалуется "я не могу экспортировать TIFF c цветовой моделью CMYK", и это не просто ошибка, то в проекте требований к новой версии продукта, должна появится запись "Добавить возможность экспорта TIFF файла c цветовой моделью CMYK". 
  
— Проблема, поступившая от пользователя, считается закрытой только тогда, когда об этом сказал сам пользователь. Или если пользователь не отвечает определенный промежуток времени. 
Вот несколько примеров неудачных и удачных ответов на проблемы пользователей. 
Пользовательское сообщение о проблеме: 
"Я пытаюсь установить продукт на Windows 2000. Установка происходит нормально, но когда я ввожу серийный номер, я получаю сообщение "Невозможно сохранить серийный номер. Только администратор может установить продукт". Но я зашел под администраторской учетной записью. Что делать?" 
Вариант плохого ответа от технической поддержки: 
"Система или программа выдает сообщение? 
Вы уверены, что вы под администратором зашли в систему? 
Какой серийный номер вы вводите?" 
Почему этот ответ плох? 
1. Программисты сами могут выяснить, что выдает сообщение об ошибке — система или программа. Не составляет большого труда сделать поиск в исходном коде продукта по тексту сообщения.  
2. Пользователь четко дал понять, что он зашел в систему под администратором. Зачем еще раз спрашивать? 
Хороший ответ на проблему пользователя: 
"Сообщение, которое вы видите, указывает на то, что у вас старая версия продукта (3.0). Если это так, то сделайте бесплатное обновление до новой версии (3.1). Если обновление не поможет, убедитесь, что на системные папки установлены правильные права доступа. Инструкции как сделать такую проверку находятся в FAQ #123.  Сообщите нам, если вы не сможете разрешить проблему. Мы вам поможем." 
В результате пользователь ответил: "Спасибо! Обновление до последней версии помогло." 
Ответственность 
  
Вот пример распределения ответственности на проекте где нет отдельных специалистов по техподдержке и техподдержкой занимаются руководитель проекта, программисты и тестеры. 
  
Руководитель проекта: 
— Отвечает за работу технической поддержки 
— Организовывает и контролирует процесс тех поддержки на проекте 
— Получает сообщения по тех поддержке и отсылает их команде на обработку 
— Редактирует или составляет финальную редакцию ответов на вопросы тех поддержки 
  
Тестеры: 
— Вносит жалобу в багобазу как обычный баг 
— Исследует и воспроизводит жалобу 
— Если проблема ясна, предлагает временное решение для пользователя 
— Если проблема не ясна, описывает, что было предпринято для воспроизведения и составляет список вопросов заказчику 
  
Программисты: 
— Программист исследует жалобу с технической точки зрения — исследует код. Это позволит получить более широкую картину о том, когда проблема происходит, как ее обойти. 
— Если же тестеры не смогли воспроизвести проблему, то у программистов есть шанс выяснить проблему по коду и помочь тестерам воспроизвести и описать проблему. 
— Исправляет ошибку или улучшает продукт, чтоб по данному вопросу не было больше жалоб в техподдержку. 
 
*** 

Усадьбы слуг народа (ФОТО)


4 мая, 2009, Киевская область, Вышгородский район, с. Хотяновка, дачные товарищества "Лелека", "Расвет", обводной канал, соединяющий Киевское водохранилище и Днепр.
 
На противоположном берегу канала от дачных участков года 3 тому назад был еще один лес. Дачники ходили за грибами и ягодами. Люди приезжали на природу отдыхать, на шашлыки, с палатками… Рыбаки выходили на рыбалку. 
 
Однако с тех пор неизвестные начали огораживать гектарами куски того леса. Потом появились "протоптанные асфальтовые дорожки". Потом — начали появляться признаки строительства.
 
Вот участки обведенные пунктиром. Это снимки 2007 года. Как раз идут строительные работы.
 
Появились дома… точнее хоромы, пляжи, пристани для водного транспорта. На канале появились бешеные глиссеры, которые едва не сбивали, отдыхающих на дачных пляжах и плавающих по каналу дачников.
 
По Хотяновке ходят слухи, что эти участки имеют отношение к Азарову, Губскому.
Председатель сельсовета с. Хотяновки прикидывается дурачком, мол, "Та це самозахват. Ми не знаемо хто це!".
 
Вот для контраста дачные участки по другую сторону канала.