Общее наше дело

Сергей Авдеев, специалист отдела компьютерных технологий СКТБ "Наука"

А.Б. Проблемы создания того, что раньше называлось "АСУ-город", все чаще обсуждаются на самых различных уровнях, от "круглых столов" краевой администрации до курилок. Можно выделить три подхода к решению этой задачи. Первый - традиционный, вертикальный: администрация назначает генерального исполнителя, финансирует его и наделяет полномочиями. Второй - горизонтальный, когда АСУ-город внедряется явочным порядком в результате добровольного объединения имеющихся технологий. И, наконец, третий подход - попытки создать некий координирующий орган, чем занимается, например, Валерий Иванович Подшивалов. Тема больная, тема горячая. Мы считаем, что нужно дать возможность высказаться на страницах журнала всем заинтересованным людям и организациям.

С.А. Сначала нужно сказать два слова о нашей фирме, чтобы было ясно, откуда корни растут. История наша началась два года назад с того, что некая группа людей взялась писать прототип системы для банка ЕНИСЕЙ, одну-единственную задачу, которая называлась "Терминал межбанковских расчетов". Задача была экспериментальной: попытаться сделать что-то в технологии "клиент-сервер". Все это продолжалось почти год, а затем мы вышли на задачу коммунальных платежей. Этой работой мы занялись с подачи Василия Васильевича Шабанова, нашего непосредственного начальника, который в некотором смысле работает на более высоком уровне. После того, как была проведена нормальная постановочная работа, начался этап разработки. На данный момент мы имеем такую ситуацию: отдел вырос, у нас уже пять секторов, каждый из которых занимается вполне конкретными вещами. От нас (точнее, от задачи коммунальных платежей) отпочковался учебный центр. Борис Федосеев начинал с того, что отвечал за обучение сотрудников ЖПЭТ, но затем эти рамки стали ему тесны, и учебный центр вырос в отдельную структуру. Отпочковался отдел, связанный с разработкой систем автоматизации предприятий. Остался отдел, занимающийся банковскими технологиями. Плюс к тому мы создали отдел перспективных технологий. Это один из коньков, на которых мы сидим, и мы считаем, что именно этот отдел поможет нам вытащить себя, как Мюнхгаузена, из болота. Современные технологии - это не просто технологии кодирования, а именно технологии проектирования. Разговор с заказчиком начинается с общего обсуждения проблемы, кончается выходом готовой системы с полным набором документации, с инструментальными средствами, которые поддерживают все этапы проектирования (CASE-средствами). Мы работаем с этими средствами уже полтора года, причем последние полгода - вплотную, поскольку по договору с банком мы обязаны предоставить документацию только с использованием CASE-средств.

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

А.Б. Ну, положим, все выглядит несколько иначе...

С.А. Близко к этому. Я общался с людьми в разных организациях (а это не маленькие организации в 3-5 человек, а организации, в которых сотни компьютеров и несколько сетей). Уровень очень разный - и уровень систем, и уровень персонала. Даже класс задач разный и уровень технических средств, на которых эти задачи решаются. Совершенно разный софт.

Вторая проблема - в подходе к решению задач. Так или иначе, автоматизацией занимаются два слоя специалистов, хотим мы этого или не хотим. Это так называемые "динозавры", которые занимались этим делом до перестройки и сейчас так или иначе остались. Но был резкий скачок где-то в 1987 году, когда пошли персоналки, и все поменялось. Некоторые из них остались на плаву, некоторые бросили все и занялись администрированием. Затем пошла вторая волна, к которой я отношу себя. Они немного захватили старый подход и знают, что это такое. Но это люди сегодняшнего дня, и это - более-менее реальная сила. Сейчас можно говорить о третьей волне, о тех молодых ребятах, которые только-только вышли. Они в принципе выше нас, потому что они начали жить при компьютерах. Мы столкнулись с компьютерами уже в зрелом возрасте. Но им еще нужно войти в этап нормальной зрелости.

А.Б. Они могут быть хорошими хакерами, но еще не понимают важности организационных и методологических проблем.

С.А. Это технологическая проблема: то, какими будут системы, зависит от того, какие люди стоят у руля той или иной системы. Начиная с нормальных SQL-технологий, сделанных, положим, на Oracle (как бухгалтерия шинного завода), и кончая расчетами на Суперкальке для бухгалтерии завода такого же масштаба. Причем каждый приводит доводы, обосновывает принятое решение. Можно бросать в них камни, но все это как-то работает. Можно заявить, что мы настроим кучу шлюзов и будем все это конвертировать, но все это будет нежизнеспособно. Уже хотя бы потому, что при переходах и шлюзованиях информация неизбежно будет теряться и искажаться. Но главное даже не в этом. До сих пор в городе на политическом уровне, на уровне руководства, нет понимания того, что любая автоматизированная система в масштабах города должна опираться на организации, целевая функция которых - отвечать за хранение определенных данных. Положим, по роду своей деятельности я пришел я в городскую администрацию, в отдел архитектуры, с вопросом: "У Вас есть электронный справочник улиц. Каким образом я могу им воспользоваться?" Мне отвечают, что положение об этом разрабатывается, но для широкого круга пользователей это пока недоступно. А другие организации, которым нужен справочник улиц, разрабатывают их самостоятельно. Им, может быть, в голову не приходит этим справочником воспользоваться. Но только тот справочник, который есть в отделе архитектуры, единственно правильный с юридической точки зрения, потому что это - административный орган, который именно этим должен заниматься.

А.Б. Вопрос лишь в том, должна ли эта инициатива идти сверху или высокие договаривающие стороны могут придти к соглашению "по горизонтали".

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

А.Б. Потратились вообще-то мы, налогоплательщики... Но Вы, фактически, признаете, что подход "сверху" тоже не дает результата. Он так же не дает результата, как и "низовой". К сожалению.

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

Поэтому предпочтительнее наш подход, подход одновременно и сверху и снизу. Заявляя о том, что наша задача как головной научной организации (Академии наук) - в разработке систем масштаба города и края и выпуская соответствующие документы, одновременно мы автоматизируем низовые звенья, готовим те АРМы, которые работают на вполне конкретных рабочих местах и занимаются связью между собой. Теперь наша цель - свести эти две точки между собой, чтобы на каждом горизонтальном уровне они подпирались сквозной информационной связью, а вертикально - одна общая идея. Возникает одно маленькое "но": почему именно мы должны стать этой головной организацией. Изначально политика, которой мы придерживались - это полноправное сотрудничество. С любой организацией, будь то ТЕХНОПОЛИС, КЛЮЧ, ГЕОСЕРВИС, мы готовы сесть за стол переговоров и начать разговор о том, как мы можем помочь друг другу в решении задач. Это наш основной принцип, и нарушить его может только нежелание партнера. Говорить о том, что мы - сверхзамкнутая система, было бы неправильным.

А.Б. Однако компьютерная общественность Красноярска была раздражена тем, как был получен этот заказ. Решение принималось закрыто, не было тендера... Вы можете прокомментировать это?

С.А. Комментировать трудно. Открытый тендер - вещь хорошая. Если говорить о нормальном тендере, то все участники должны готовить некие пакеты документов (технико-экономическое обоснование и т.д.), представлять их... Кому? Кто войдет в экспертный совет? В городе есть несколько организаций, претендующих на это. Это и общественные организации, и государственные структуры. Но можно ли найти независимую комиссию, состоящую из достаточно квалифицированных людей? Людей, которые могут квалифицированно провести такую экспертизу, очень мало. Можно привлекать их со стороны, из организаций, занимающихся разработкой. Но тогда человек приходит оценивать самого себя. А если они висят в воздухе, то через какое-то время к ним перестают обращаться. Если не вращаешься в нашем круге, быстро отстаешь. Я очень скептически отношусь к ситуации, когда проводится крупный тендер в государственной структуре. Академия наук могла бы стать независимой организацией, которая могла бы проводить такую экспертизу. Но опять-таки получается парадокс: поскольку я - представитель Академии наук, упреков в предвзятости не избежать. Все другие фирмы - частные. Их отношение к этой проблеме совершенно однозначное. Для них государство - один из клиентов. Они просто конкурируют с другими фирмами за этого клиента. У меня ситуация иная, хотя я тоже на самоокупаемости, я работаю в похожих условиях. Но я - представитель государственной структуры. Может, все это не совсем все было корректно, но мы себя оправдывали морально тем, что мы относимся к государственной структуре, научной структуре и мы имеем возможность работать с остатками институтов и лабораторий, которые сейчас есть. Все очень просто организационно: я приехал, положим, к Олегу Якубайлику на ВЦ СО АН. У нас могут возникнуть нюансы, но у нас есть общий начальник. Он может выдать распоряжение, которое нас на некий момент времени соберет в одну структуру и никто не будет задавать вопрос "а почему это так?". Я думаю, ни КАМИ-Красноярск, ни КЛЮЧ не будут спорить: совокупные ресурсы, которые мы можем мобилизовать для решения задачи (какими способами - финансовыми, организационными - другое дело...) на порядок выше, чем ресурсы любой организации. И спектр этих ресурсов широк: учебный центр, подразделения, занимающихся, например, производством электронных компонент. Что могут предложить другие организации, которые занимаются отдельно взятыми разработками? Как они будут решать финансовые, договорные, юридические моменты? У нас все гораздо проще. И, когда идет внутренний тендер - с кем мы будем работать из сторонних организаций, мы исходим из принципа целесообразности. Если есть наработка, удовлетворяющая требованиям определенного класса, с этими организациями можно разговаривать. Есть и корпоративные интересы, их тоже надо учитывать. Любая коммерческая структура в первую очередь будет взаимодействовать со своими партнерами, а уже потом с другими организациями, пусть даже более лучшими. Но мы не замыкаемся на одном партнере. Вот простой пример: полтора года назад мы начали работать с ГИС-технологиями, год назад у нас был готов макет, прототип системы, работавший на реальной информации, он был обкатан в Академгородке. У нас была лаборатория в Институте леса, которая занимается ГИС, был ГЕОСЕРВИС. Садимся, начинаем разговаривать. Сейчас появился третий партнер - экологическая лаборатория. Если у них есть ресурсы, которые можно привлечь на благо нашего общего дела - ради бога.

Я думаю, что это и есть ответ на Ваш вопрос: почему тендер был закрытым, с одним участником.

А.Б. А что будет дальше? Как вы представляете себе дальнейшее развитие АСУ-город? Что уже работает?

С.А. В Октябрьском ЖПЭТ внедрена система коммунальных платежей. Опыт полуторагодичной работы показывает, что подготовленность городской инфраструктуры весьма средняя. Техническая база слабая, подготовленность персонала недостаточна. За последние четыре года высшая школа практически упала, люди, которые выходят из ее стен, имеют квалификацию ниже средней. Либо приходят люди из других областей, которые не занимались компьютерным делом, но теперь переучились. Всем им нужно время на то, чтобы войти в курс дела. Он может быть умный, сообразительный, но он не имеет базового образования. При эксплуатации такого рода систем очень многое завязывается на одного человека. Когда все решалось одним компьютером, проблемы не было. Когда появились сетевые технологии, встал вопрос о квалификации персонала. На ту зарплату, которая положена администраторам сети, трудно найти квалифицированного человека. И вот дилемма: с одной стороны, мы являемся проводниками современных технологий, с другой стороны, мы бежим впереди паровоза. Если мы начнем сейчас внедрять эти современные технологии, то это не будет работать: нет нормальных каналов связи, квалифицированного персонала, современной техники. Изначально у нас была жесткая этапность: DOS-овский вариант, откатываем его, потом переходим на технологию "клиент-сервер". "Клиент-сервер" остается для нас базовой технологией, однако сейчас мы вынуждены эксплуатировать вариант системы, написанный на FoxPro. Обкатывается технология внедрения такого класса систем. Такого класса системы - не коробочные. Нельзя продать коробку и считать дело сделанным. Существует целая технология внедрения. Перевести систему из неавтоматизированного состояния в автоматизированное - это процесс.

А.Б. Понятно, что организационные проблемы в таким задачах сложнее, чем чисто программистские. Как Вы их решаете? Я думаю, что самая больная проблема все-таки - это совместимость нормативной базы. Как Вы наладили взаимодействие ЖПЭТ, паспортного стола и т.п.?

С.А. Для меня, как представителя СКТБ "Наука", нет большой проблемы попасть в приемную начальника паспортного стола Октябрьского района. У нас были в гостях представители ВЦ краевого УВД, фонда обязательного медицинского страхования, фонда занятости. Проблемы на уровне взаимодействия государственных организаций краевого и городского масштаба практически нет. Такого, чтобы я куда-то хотел попасть и не попал, не бывает.

А.Б. Я имел в виду не взаимоотношения людей, а взаимоотношения баз данных.

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

А.Б. Но такого практически не бывает!

С..А. А если неодинаковая, то предложение принять за базовую структуру данных нашу структуру не встречается в штыки. Бывает и наоборот. В УВД есть картотека жителей. Поскольку они - ведущая организация, мы приняли их терминологию и принцип организации данных. Если встанет вопрос: может ли ЖПЭТ передать информацию в паспортный стол, отвечу: может, один в один. Если мы решим еще пару нюансов, то сможем смасштабировать решение на город и край. Модель - она и есть модель, она имеет только количественные показатели. Если машина или база данных позволяет хранить некий объем информации, значит, все нормально. Вот если бы модель была некорректной...

А.Б. Масштабировать можно в том случае, если вертикально, по районам, эти стандарты соблюдаются...

С.А. В Красноярске есть три-четыре организации, которые занимаются автоматизацией коммунального хозяйства. Это УВД, земельный комитет, архитектура, ЖПЭТ, БТИ, налоговая инспекция. Если их корректно связать, дальше все пойдет нормально. Мы организовали у себя учет собственности (фактически это функция БТИ), и информация по жилому фонду у нас нормализована, данные хранятся корректно. Этой информацией без проблем может пользоваться ЖПЭТ и налоговая инспекция.

Стандартизация - не единственная проблема. Есть целый клубок проблем, и подходов к их решению. ГИС-технология решает проблему специфического представления информации. Технология Internet решает проблемы с доступом к данным. Есть, например, проблема закрытости данных. Проблема репликации данных очень серьезна: нужно, чтобы информация, обслуживаемая сейчас несколькими системами, была одинакова. Нужен регламент: кто должен обновлять базу, кто несет ответственность за то, что Вам передали. Есть два способа разрешать конфликты: по-человечески или официально. Сейчас-то у нас в суд обращаются в крайнем случае, когда уж либо в петлю либо в суд. Но наступит время, когда в суд будут идти при всяком удобном поводе. Вот тогда вопрос об ответственности встанет очень остро. Кажется, в Таганроге, начальник службы занятости начал свою работу с того, что подготовил описание деятельности организации в условиях автоматизированной системы. Все действия персонала были описаны не с точки зрения должностных инструкций, а с точки зрения АСУ. Эти поля вносить, эти не вносить, до пятого числа смотришь в эту колонку, после пятого - в эту. Надо сделать новый отчет - отдел готовит требования, и требования обязательно визируются отделом АСУ. Только тогда появляется ДОКУМЕНТ. Иначе получается хаос, причем в случае автоматизированной системы - автоматизированный хаос. У нас такого подхода, к сожалению, нет. Все наши контакты - частная инициатива отдельно взятых людей. Юридически это не оформлено.

А.Б. Я вообще пребываю в пессимизме. Любые попытки выработать общую стратегию проваливаются. Круглые столы, проводимые краевой администрацией, сводятся к тому, что одни всенародно плачутся в жилетку о недостатке всего, а другие затевают перепалку и всенародно сводят давние счеты. Даже если принимается какой-то документ, он теряется где-то в коридорах власти. Усилий много, сухой остаток -ноль.

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

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

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

А.Б. А что, вертикаль власти не спасает от этого?

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

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

А.Б. Ну, положим, серьезные вещи иначе и не делаются.

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

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

С.А. Тогда совершенно конкретный вопрос. Есть продукты класса 1С. Каков минимальный набор документации нужен? И есть продукты класса автоматизации ЖПЭТ. Какой минимум документации нужен для ее функционирования и модернизации, чтобы заказчик был совершенно спокоен? Заметим, что организация, использующая систему, имеет горизонтальные и вертикальные связи. Как обеспечить стабильность разработки в условиях ротации кадров?

А.Б. Система должна быть отчуждаемой от разработчика. ГОСТ ЕСПД, кажется, еще не отменен. Правда, он недостаточен. Я в свое время руководствовался комплектом документации, описанным Р. Гантером. Это сотни три страниц.

С.А. Если книга, описывающая то, как должна выглядеть документация, занимает триста страниц, сколько должна занимать сама документация?

А.Б. Этот пункт я не собираюсь оспаривать. Качество документации, как проектной, так и пользовательской, во многих случаях оставляет желать лучшего. Одно время я даже подрабатывал на том, что брал документацию по какой-нибудь системе и излагал ее человеческим языком. На эту тему мы в ON LINE как-нибудь поговорим. Вернемся к теме разговора.

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

А.Б. Наш разговор подходит к концу. Что бы Вы хотели сказать в качестве, так сказать, последнего слова?

С.А. Мне хотелось бы высказать пожелание. Наш город маленький, наш компьютерный мир тесный. Бывает, конечно, что ситуация толкает к конкуренции: тендер, конкурс, работа локтями, отношения обостряются. Но, когда речь идет о конкретных решениях, нужно относиться друг к другу более терпимо. Каждый из нас имеет наработанный годами взгляд, и сдвинуть его с места трудно. Тем не менее нужно садиться за стол переговоров, а не огульно ругать: "как у них все плохо, как у нас все хорошо". Банка кофе и сахара всегда найдется, и это лучший способ решения проблем.

А.Б. В общем, ребята, давайте жить дружно и делать общее наше дело.