Здравствуйте, bastrakov, Вы писали:
B>не в качестве поспорить, а просто. B>вот представте, что завтра... не, не будем думать, что он взял компанию за я... ну не вышел на работу. нет.
С другой стороны, если это единственный толковый человек в команде, то выбор довольно простой: или продолжать от него зависеть, и тогда если с ним что-то случится, будут неприятности. Или избавиться от него. Тогда неприятности случатся сразу. По-моему, риск неприятностей лучше, чем готовые неприятности без всякого риска
Мне, кстати, как-то "повезло" оказаться в компании, в которой я был такой "примадонной". Не самое приятное занятие, я Вам доложу. В частности, очень больно смотреть, как твои наработки, в которые ты душу вкладывал, превращают в дерьмо, и с этим ничего не можешь поделать. Я доделал все, что успел им наобещать (довольно много, на несколько месяцев хватило), и распрощался с ними. Судя по всему, мне удалось оставить дела в таком состоянии, что они сами там как-то выкарабкались.
Здравствуйте, 0rc, Вы писали:
0rc>Поэтому я больше схожусь во мнении с коллегами, которые сказали что придется этого сотрудника отделить + поговорить о дальнейшем прекращении сотрудничества.
Только скажите ему об этом сейчас. Очень может быть, что он тоже думает над этой проблемой — вы "экологично" расстанетесь и он о вас будет помнить только хорошее, в отличии от другого сценария.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, cencio, Вы писали:
C>>или вам заказчик платить за програмиские часы а не за результат?
0rc>Почти. За часы не выгодно получается, за результат тоже (ага и такое бывает). Начальство решило, не спрашивайте почему, просто решило и ему веднее, что лучшим мерилом денег будет — строчки кода. Но он пишет слишком компактный код, из-за этого все проблемы.
аж не вериться, что это серьезно сказано
такого маразмо в 2008 быть уже не может
. Такие истории заслуживают самого пристального рассмотрения. Смеяться там не над чем, к сожалению.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
КЛ>Форд считал, что главное для производства — это выпускать качественный товар по как можно меньшей цене. Т.е. главное, считал Форд, это качество товара, а не прибыль. Если товар будет качественным и дешёвым, то прибыль появится сама собой. И что самое интересное, Форд с такой философией создал успешный бизнес и зарабатывал хорошие деньги.
Кирилл, большое спасибо за ссылку — не раз слышал добрые слова про старика Форда, наверное пора искать время на прочитать
КЛ>Мне кажется, что Вашему руководству нужно ознакомиться с книгой Форда. Потому что, гонясь за капитализацией и содержа бесполезных сотрудников, они не способствуют дешёвому и качественному производству и, таким образом, разваливают собственный бизнес. Один из главных "звоночков" — это стремление избавиться от сотрудника, который слишком хорошо работает.
очень четко выражена соль! прошу прощения что влезаю со ссылкой на себя — просто для меня сюрприз, как все цитаты выше, из Форда, так сказать, "сверху" один в один перекликаются с моими размышлениями
"снизу" — суть которых в т.ч. и в том, что как правило не следует раздувать\содержать раздутый штат, гораздо разумнее повышать средний уровень команды — а значит и стандарты качества и качество продукта. Приятно получить подтверждение что, похоже, это работает везде
... << RSDN@Home 1.2.0 alpha rev. 0>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, 0rc, Вы писали:
0rc>В интернете часто возникают дискуссии, например Solving the problem of prima donna developers или Steve Jobs, TIME Но там к сожалению это — опыт иностранцев, что как правило не применим к нашим работникам и к нашим реалиям. Поэтому задал вопрос именно здесь, поскольку наверняка у многих были подобные ситуации в практике управления.
Странно, а почему тогда вы уверены, что опыт иностранцев, который вы почерпнули в книге Managing Talented People — применим к нашим реалиям?
От себя могу сказать, что человека, который своими действиями вносит разлад в работу команды, надо увольнять независимо от его технического уровня, потому что моральный дух и положительный климат в команде гораздо важнее ущерба от потери одного сотрудника, каким бы незаменимым он вам не казался. Скажу больше — вы удивитесь, до какой степени командная продуктивность возрастет после его увольнения. Во многих случаях вы с удивлением обнаружите, что остальные люди не так плохи технически, как вам казалось. Просто в той ситуации они не могли раскрыть свои способности — только и всего.
"Паттерн примадонна" тут совершенно не причем — причина такого поведения обычно кроется в избалованности, сознании собственной исключительности, преувеличения своих интеллектуальных способностей, пренебрежительного отношения к другим — и всего этого сразу. Грубо говоря — "комплекс отличника сельской школы". Это, вообще, проходит. Чтобы это прошло — 1) надо создать ему в команде противовес, 2) дать ему понять, что носиться с ним никто не будет, и он должен подчиняться общим правилам. Только и всего. Увольнять надо в клинических случаях — когда мотивация деструктивного поведения другая. Выделять его на отдельный проект — симптоматическое лечение, смысла особого в этом нет.
Здравствуйте, 0rc, Вы писали:
0rc>На проекте присутствует сотрудник с этим паттерном. Расскажите пожалуйста как с ним поступать?
Я думаю, вам надо его уволить. В конторе, где проводят тайные аудиты измерением строчек кода и меряют ценность команды количеством говно-кодеров, я думаю, хорошему программисту не место. Чем быстрее вы это сделаете, тем лучше будет для этого талантливого человека.
у нас разные позиции, я завязываю.
...но хотел бы тут еще пару слов вставить.
ГВ>>>Однохренственно, выводить из команды или увольнять. Вопрос ставится так: оставлять при делах или отводить от дел. Остальное — формальности. B>>для меня это разные вещи, потому что я могу сменить проект в рамках своей компании. ГВ>По существу это одно и то же.
нет.
B>>я здесь уже работал в одном проекте, который мы тащили втроем. потом другой проект вдвоем. B>>потом другой — была команда 12-14 человек. ГВ>То есть если завтра вы будете работать в другой компании, то и мнение относительно "разных вещей" тоже поменяется? И рекомендации, которые вы будете давать посторонним людям — тоже?
я работал в очень разных компаниях. включая полный фриланс, т.е. сидя дома и работая на дядю из другого конца света.
и даже в этом последнем случае "смена проекта" — это переход на другого дядю. но не смена компании, которая у меня в комнате и состоит из меня одного.
в рамках большой компании, в которой больше одного проекта, можно сделать переход от одной команды к другой, если по к-л причинам "не срослось". примеров я знаю навалом.
B>>изначально я предложил героя вывести из команды. дальше обсуждение ушло в русло "валить надо". в чем разница? B>>в том, что его не выводят, а он самовыводиться? результат тот же.
ГВ>Результат как раз разный. В одном случае плох работник, в другом — руководство. Соответственно — психологическая нагрузка при разрыве отношений тоже отличатеся. На практике это может иметь очень далекоидущие последствия.
гы... полстакана? по мне так как не считай, а все равно половина.
а про психологические нагрузки... ну а кто сказал, что бизнес — это детсадовская группа?!..
причем надо четко понимать, что это "получение прибыли" как компанией на рынке, так и работниками в компании.
B>>еще раз. у меня нет позиции по данному ...конфликту(? наверно еще нет, но где то рядом). ГВ>Это именно конфликт.
чуть выше вы говорили, что для оценки не хватает данных. как-то категорично мнение поменялось. вы внутри? тогда вам виднее.
B>>у меня есть позиция по решению. ГВ>Не смешно. Театр абсурда — через дорогу, два квартала направо. На наших глазах пытаются найти способ подставить ни в чём не повинного человека, да ещё и привлекают к этому захватывающему занятию аудиторию публичного форума. Не знаю, кому как, а мне такие игры не по нутру, мягко говоря. К счастью, не мне одному.
я понимаю, о чем вы, но... компания не названа, имена не названы, даже область разработки неизвестна.
вот честно, положа руку на сердце, я пишу по _моим_личным_ примерам.
во
Здравствуйте, 0rc, Вы писали:
0rc>Тут какая проблема: из команды разработчиков (три человека) в начале проекта на него приходилось 70-80% работ, сейчас (спустя время) объем работы возлагаемого на него стал примерно 30%-40% (плавное снижение его степени участия в работе над проектом со стороны руководства), сейчас получается что уменьшение степени участия этого сотрудника влияет на сроки сдачи в худшую сторону. Он сам просит выделить какой-нибудь проект, где он в чистую может показать только свою работу. Как быть?
Знакомо. Может быть пора начать соблюдать заветы старика Сен-Экзюпери
? Если уже сама примадонна об этом просто кричит отрытым текстом — неужели не слышно?
вообще интересны роли и сроки, проведенные примадонной в компании, на проекте и как давно пошли проблемы, а именно как давно и кого перестало устраивать положение вещей — примадонна захотела оформления статуса или там рук-во прочло книгу об управлении рисками или...? что было сделано чтобы уменьшить последствия отдаления от дела указанной примадонны? Или ему просто снизили нагрузку и на этом дело посчитали сделанным? А кстати сам проект вырос или объем работ постоянный остался — просто участие в проекте перебалансировали с 80\20 на 30\70? да и суть претензий пока неясна, характеры неизвестны... да, тут мнение однозначное не составить.
Гипотез же две — или даже одна из 2х частей: у человека амбиция некая (лидерская? авторская?), а проявить не дают, более того — пужаются и гасят. Может быть без него просто не осталось людей, которым проект реально нужен — вот и главная причина всех бед?
ведь возможно, что это авторские чувства помогали выдавать на-гора по-стахановски 80% и болеть за проект — а теперь фактически идет постепенное лишение родительских прав (или это проект так вырос?). И жуткая демотивация с побочными эффектами в виде поисков крайних уже с обоих сторон. А ребенку-то тем временем точно лучше не станет... тем более в долгосрочной перспективе может стать очень плохо, когда родителя — со своим знанием, пониманием и видением как именно надо развивать (и даже иногда куда) свое чадо — заменит очередной залетный... отчим получается? Это же тоже риск и его надо принимать во внимание и им управлять.
Разве только если прикинуть что тут вопрос уже стоит ребром: 1-2-3 человека на подхвате заменить\"отстранить" или 1 примадонну (которой адекватной замены не найти на рынке), выпестовавшую проект за неск лет до текущего состояния (хотя бы не загнулся) — может быть стоит выбрать проверенное гарантированное качество, а не количество?
просто судя по цитате выше — в коллективе из 3х чел "отец-основатель" запросто может весить те самые 80% (т.е. на остальную пару ударников соцтруда падает по 10% — я кажется начинаю понимать его претензии коллегам) и следует поговорить как раз с остальными двумя в том же ключе
? тем более что очень вероятно что у стахановца есть объективные причины быть недовольным их вкладом в проект. Может быть это их руководство слабо мотивирует и им нет смысла горбатиться как тот самый старичок — вот и катят на него бочку чтобы не работать? Или может он наоборот всегда работал один и еще не научился свой код отдавать на растерзание команде и теперь хандрит? Короче причин может быть много... слушать людей пробовали?
PS Конечно Гапертон прав что ситуация пока неочевидна, но все говорит за то что реконструктор Геннадий роет в правильном направлении... вот и я ему решил помочь, благо выходной Хотя кто его знает что там за примадонна... всякое бывает. Но строчки, ребята, строчки
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, bastrakov, Вы писали:
ГВ>>>>Однохренственно, выводить из команды или увольнять. Вопрос ставится так: оставлять при делах или отводить от дел. Остальное — формальности. B>>>для меня это разные вещи, потому что я могу сменить проект в рамках своей компании. ГВ>>По существу это одно и то же. B>нет.
Повторюсь, какая разница, перевели на другой проект или попёрли из компании? Здесь главное, что заставили прервать работу над начатым проектом. И мне сейчас важно понять — почему вывели из проекта, а не куда потом направили.
B>>>изначально я предложил героя вывести из команды. дальше обсуждение ушло в русло "валить надо". в чем разница? B>>>в том, что его не выводят, а он самовыводиться? результат тот же. ГВ>>Результат как раз разный. В одном случае плох работник, в другом — руководство. Соответственно — психологическая нагрузка при разрыве отношений тоже отличатеся. На практике это может иметь очень далекоидущие последствия. B>гы... полстакана? по мне так как не считай, а все равно половина.
Не знаю, как насчёт половины стакана, но уйти из-за несуществующих грехов и уйти, будучи уверенным в глупости руководства — суть два очень-очень разных ухода.
B>а про психологические нагрузки... ну а кто сказал, что бизнес — это детсадовская группа?!.. B>причем надо четко понимать, что это "получение прибыли" как компанией на рынке, так и работниками в компании.
Такими сентенциями хорошо студентам мозги полоскать. На большее оные буквицы не годятся.
B>>>еще раз. у меня нет позиции по данному ...конфликту(? наверно еще нет, но где то рядом). ГВ>>Это именно конфликт. B>чуть выше вы говорили, что для оценки не хватает данных. как-то категорично мнение поменялось. вы внутри? тогда вам виднее.
"Конфликт" есть противоречие интересов, а не эмоции, которыми сопровождаются отдельные инциденты. Ну и помимо этого, дополнительные данные появились (см. сообщения рядом).
B>>>у меня есть позиция по решению. ГВ>>Не смешно. Театр абсурда — через дорогу, два квартала направо. На наших глазах пытаются найти способ подставить ни в чём не повинного человека, да ещё и привлекают к этому захватывающему занятию аудиторию публичного форума. Не знаю, кому как, а мне такие игры не по нутру, мягко говоря. К счастью, не мне одному.
B>я понимаю, о чем вы, но... компания не названа, имена не названы, даже область разработки неизвестна.
Да не важна область разработки. Программирование, оно, в общем и целом везде одинаковое. И уж тем более не важны ни название компании, ни имена сотрудников.
B>вот честно, положа руку на сердце, я пишу по _моим_личным_ примерам. B>во
Да я верю, верю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 0rc, Вы писали:
0rc>Он полностью ответственен за (возможный) провал проекта. Но это маловероятно.
а чем такая ответственность подкреплена? ответственность без полномочий плохо работает... чревато.
0rc>Потому что паттерн "примадонна" применен исключительно к талантам + он не может работать со многими. Я не спорю что он справляется, но мы не в состоянии найти на рынке сотрудников такого же уровня за ту же цену что и он и таким образом уволить всех тех кем он не доволен: это просто невозможно. Поэтому я больше схожусь во мнении с коллегами, которые сказали что придется этого сотрудника отделить + поговорить о дальнейшем прекращении сотрудничества.
так в чем суть претензий-то?
0rc>Если у вас есть иные предложения или у вас была практика с такими сотрудниками, то я послушаю.
предложение рассмотреть замену "многих" уже поступало и оно может оказаться даже экономически более обоснованно
чем тупое решение в лоб — мол "коллектив превыше всего" из серии "незаменимых людей у нас нет, выплывем". В те годы, когда сей лозунг имел место, не было проблем с ресурсами и мотивацией, не забывайте! А сейчас Вы сами пишите чуть выше выделенное жирным. Т.е. на полях пометка: найти противовес — пока затруднительно.
Но так ли уж невозможно ничего сделать? Или кому-то просто очень не хочется? Что если ему выдадут карт-бланш и разрешат выбрать\найти себе 1-2 помощников самому (внутри проекта\компании или даже на улице) — и таким образом выразят свое доверие на деле, а также лишат повода в дальнейшем жаловаться на плохие кадры и вообще на что-либо — ибо сам будет подбирать, а за любой резалт и так уже сам отвечает? Что, если публично выдадут полномочия, адекватные ответственности (а она на нем — см выше, похоже максимальная! чего точно не скажешь о полномочиях, роли и уважении его вклада, судя по описательным постам) ? Т.е. фактически сделают не ключевым-на-словах сотрудником\теневым лидером, а реальным, что будет видно всем — возможно это сработает? Почему это не должно сработать, если до этого как-то работало в его стахановскую пору, когда вероятно проект был ему интересен? включить ему "доверяй но проверяй"?
И все что нужно получается
— выяснить суть претензий, возможно поменять пару человек между проектами\частями проекта хотя бы на время — обычно такое возможно, если просто поговорить нормально и выяснить кому с кем удобнее, кто с кем согласен работать, как и над чем. Мотивацию лишний раз попытаться уточнить.
— если ничего страшного в претензиях нет, затем просто объяснить наиболее подходящим кандидатам почему им лучше с примадонной попытаться поладить, хотя бы в течении некоего срока (оговорить) раз сами как дети в песочнице не желают первыми идти на компромисс без старшего посредника. Объяснить доходчиво и тактично почему именно компании сейчас нужно и важно чтобы именно он был "старшим" оговоренное время (сдача проекта\фичи\получение самими помощниками необх. для дальнейшего роста знания по проекту), вообще как-то заинтересовать каждого лично (да, что-то конкретное пообещать, а как?) и при этом попытаться объединить всю бригаду общей целью и общим критерием успешности\ответственности за результат — все это дабы не возникло желания лишний раз саботировать идеи\решения примадонны и был минимальный интерес в их выполнении, без постоянного привлечения вышестоящего ПМа или кто там есть.
— Ну и не забыть собственно доверие на этот раз официально закрепить за примадонной, оговорив с ним самим "исп срок" и объективные критерии его успешного прохождения — строчки кода если угодно или еще что. И право оставить за собой проект в случае успеха ну или что там его интересует.
Может за оговоренный срок дело сдвинется и пойдет потихоньку на лад. И увольнять не придется никого вот так сразу. Если поговорить получится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Кстати, юмор уже начался. Из твоих слов следует, что ваш непосредственный сотрудник не знает о таком положении дел, а мы тут, на публичном форуме — знаем. Забавно до дрожи...
0rc>Знает, и его предупредили. На что он сказал, что проект сдается во время ни одного проваленной на протяжении года итерации не было плюс вся функциональность имплементирована в полной мере. Но факт остается фактом, он пишет слишком компактный код.
У меня есть на примете несколько знакомых индусов, которые гарантированно решат ваши проблемы!
Я точно знаю, что ты здесь был и ничего не ответил, хотя вопрос подразумевает только "да" или "нет". Ну, тогда снова беру ход. Да... Подразумеваю, что ответ на мой вопрос о важности сроков — утвердительный.
ГВ>>Кстати, юмор уже начался. Из твоих слов следует, что ваш непосредственный сотрудник не знает о таком положении дел, а мы тут, на публичном форуме — знаем. Забавно до дрожи...
0rc>Знает, и его предупредили. На что он сказал, что проект сдается во время ни одного проваленной на протяжении года итерации не было плюс вся функциональность имплементирована в полной мере. Но факт остается фактом, он пишет слишком компактный код.
Ну так вот, ребята. Вы вкатилсь в полный аут.
Объясняю на пальцах.
1. Производительность человека в строках в день — величина постоянная. Тому подтверждением — рассуждения Гапертона и мои, озвученные где-то в этих форумах годами двумя ранее.
2. Производительность группы растёт в нелинейной зависимости от её численности. См. исследования IBM.
Так вот, фокус в том, что запросто можете не добиться необходимого большого количества строк на человека, одновременно соблюдя сроки.
Поясню на примере.
Пусть производительность Н. составляет 250 LOC/день (это очень круто). Производительность помощников — пусть будет побольше, они птупее, пишут больше кода для той же задачи. Итак, помощники — 350 LOC/день. Доведение продукта до ума требует, пусть 10000 LOC, т.е. — 40 дней. Эта цифра утверждена в планах, и т.д., и т.п. Это если считать на одного "гуру". Допустим, что появился помощник, который вываливает означенные 350 LOC.
Дык вот. Для доведения продукта до ума им потребуется уже не 10 KLOC. А ровно в (350+250)/250 = 2,4 раза больше строк. Вы же хотите загрузить их обоих, верно?
Однако! Однако, согласно исследованиям высокоуважаемой фирмы IBM вообще и мистера Брукса, в частности, производительность группы (в терминах результативности процесса в целом, а не объёма натайпленного кода) вырастет всего лишь в 1,4 раза (корень из соотношения численности). Что имеем? Правильно. Имеем, что либо строки будут написаны все, но значительно позже потребного срока, либо, что продукт будет сдан в срок, но строк будет совсем не столько, сколько хотелось. Вот такая вот тонкая магия процесса прграмирования. На самом деле, производительность обоих сотрудников — упадёт. Они потратят время и силы на обсуждения, согласования, переделки, и т.п. И в результате, либо напишут мало, но успеют вовремя. либо напишут много, но писать будут долго-долго.
Таким образом, коллеги, выбранный вами путь, это путь в никуда. В нуль. В пустое множество. В ангидрид перекиси. Вы там что, Кастанеды перечитались, что ли? Я не знаю, что там "виднее" начальству, но, похоже, ему видны только сновидения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Кстати, юмор уже начался. Из твоих слов следует, что ваш непосредственный сотрудник не знает о таком положении дел, а мы тут, на публичном форуме — знаем. Забавно до дрожи...
0rc>Знает, и его предупредили. На что он сказал, что проект сдается во время ни одного проваленной на протяжении года итерации не было плюс вся функциональность имплементирована в полной мере.
его предупредили, сам проситься на отдельный проект — что-то подсказывает, топик нужно переименовать в "как удержать примадону, а то свалит и не даст нам возможность его уволить"
Если я правильно понял ситуацию по этой ветке, то на вашем уровне эту задачу скорее всего не решить. Найдите понимание среди руководства, консультантов или заставьте руководство пригласить соответствующего консультанта.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Кстати, юмор уже начался. Из твоих слов следует, что ваш непосредственный сотрудник не знает о таком положении дел, а мы тут, на публичном форуме — знаем. Забавно до дрожи...
0rc>Знает, и его предупредили. На что он сказал, что проект сдается во время ни одного проваленной на протяжении года итерации не было плюс вся функциональность имплементирована в полной мере. Но факт остается фактом, он пишет слишком компактный код.
Слушайте, отдайте этого разработчика нам, раз вам не нужен человек, который _хорошо программирует_, раз вам такой не нужен
. Такие истории заслуживают самого пристального рассмотрения. Смеяться там не над чем, к сожалению.
Классический пример, когда бизнес и производство придумывали, придумывали и наконец придумали. При этом не удивлюсь, если каждый шаг каждого участника этой комедии абсурда был строго логичен и имел осмысленный смысл.
Только вот вопрос — как результатом этих всех действий стала ситуация, когда сотрудник работает плохо, если он работает хорошо (читай — пишет эффективный и компактный код)?
Здравствуйте, Enox, Вы писали:
E>Классический пример, когда бизнес и производство придумывали, придумывали и наконец придумали. При этом не удивлюсь, если каждый шаг каждого участника этой комедии абсурда был строго логичен и имел осмысленный смысл.
+1
E>Только вот вопрос — как результатом этих всех действий стала ситуация, когда сотрудник работает плохо, если он работает хорошо (читай — пишет эффективный и компактный код)?
Та-й... Нашёл, чему удивляться. В "бизнес-мире" и не такие загогулины случаются. Как правило, их существование объясняется тем, что кто-то кому-то чего-то недоговаривает, кто-то где-то сознательно что-то искажет, кто-то почему-то верит в невесть что, на худой конец, кто-то что-то пытается немедленно урвать, не глядя на последствия. Короче говоря — все пользуются частью общей картинки, которую достраивают по своему разумению.
Похоже, что и здесь тоже самое...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Хотя кто его знает что там за примадонна... всякое бывает. Но строчки, ребята, строчки
