За круглым столом, состоявшимся в рамках конференции «TerraLink IT­Summit 2006», участники обменялись опытом внедрения систем управления информацией на своих предприятиях. Что необходимо для успеха проекта внедрения СЭД? Помимо традиционных для ИТ­проекта — поддержка руководства, хорошее управление и правильное планирование — есть несколько факторов, специфических для проектов этого типа.

Участники круглого стола
Елизавета Лобова, заместитель директора Центра компетенции
электронного документооборота группы компаний "МегаФон".
Татьяна Иванова, начальник отдела документационного
обеспечения ОАО "МегаФон".
Рон Льюин, управляющий директор "ТерраЛинк",
член совета директоров Американской торговой палаты.
Юрий Ибрагимов, директор по региональным продажам,
EMC Documentum.
Дмитрий Садков, разработчик ПО, корпорация "
ИНКОМ-Недвижимость".
Евгений Стаханов, начальник отдела продаж корпоративных
решений компании "ТерраЛинк".
Амир Давлетбаев, специалист по технологиям, Microsoft.
Павел Тараканов, директор по консалтингу, "ТерраЛинк".

Intelligent Enterprise: Что позволяет сделать проект внедрения систем документооборота успешным? Каковы здесь основные факторы успеха?

Юрий Ибрагимов:

На 80, а то и на 90 % успех определяют действия, которые предшествуют проекту. К сожалению, хороший продукт не гарантирует, что и проект хорош. Я бы выделил три момента.

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

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

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

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

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

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

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

Дмитрий Садков: Я хотел бы продолжить тему общения, взаимопонимания с заказчиком. В России очень специфическая ситуация. На Западе есть стандартные бизнес-школы, стандарты на ведение проектов, на управление. У нас это все еще только начинает приживаться, так что даже банальный вопрос терминологии иногда сильно осложняет ведение проекта. Кроме того, в России, как заметил еще наш великий физиолог Иван Петрович Павлов, есть тенденция фетишизации слов: для нас слова значат немножко больше, чем реальность.

Задача проекта должна быть сформулирована достаточно просто и так же просто должна восприниматься заказчиком. Например, что такое система документооборота? Может быть, заказчику проще понять, что такое "автоматизация согласования платежных заявок в данном конкретном подразделении"? Это вопрос языка, на котором происходит общение.

Есть и более глубокие сложности, например, когда бизнес не воспринимает какие-то термины в принципе. Допустим, все мы сейчас говорим о бизнес-процессах. Что такое бизнес-процесс? Это некоторая последовательность действий, на каждом этапе которых имеется определенный исполнитель; всё это ограничено какими-то формальными правилами, и этот процесс регулярно воспроизводится на предприятии - что собственно и делает его процессом. Но что бывает на самом деле? В одной компании мы пытались автоматизировать процесс подготовки проектной документации. Документация готовилась там довольно долго, несколько месяцев. Процесс проходил через разные подразделения, и последовательность прохождения была достаточно жёсткой. Мы попытались описать этот процесс - кто что делает и кто за что отвечает, оптимизировать его и в таком виде внедрить. Не прижилось абсолютно! Как потом выяснилось, процесс подготовки проектной документации де-факто бизнес-процессом не являлся, поскольку не воспроизводился. Условия подготовки документации регулярно менялись в зависимости от желания заказчика, нарушался порядок этапов, переделывались правила определения исполнителей и ответственных лиц. То есть слово "бизнес-процесс" в данном случае оказалось не соответствующим сути происходящего. Очень важно выбрать терминологию, адекватную той деятельности, которая осуществляется на предприятии.

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

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

Евгений Стаханов: Тема языка и взаимопонимания очень интересна, мы сталкиваемся с ней на каждом шагу начиная с самой первой попытки установить контакт с клиентом. Внутри компании мы периодически спорим о том, как позиционировать предлагаемые решения. Лично я считаю, что в России заказчики не очень хорошо воспринимают термин Enterprise Content Management и гораздо лучше понимают словосочетание "электронный документооборот".

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

Елизавета Лобова: Рабочая группа проекта по внедрению корпоративной системы электронного документооборота в "МегаФоне", о которой упоминал Дмитрий Садков, продолжает работать и остаётся командой единомышленников. Она состоит из сотрудников центра компетенции, экспертов головного офиса и специалистов компании-разработчика "ТерраЛинк". Каждую неделю мы встречаемся и проводим "разбор полетов", уточняем планы, выясняем сложные ситуации, если они возникают. Таким образом, рабочий процесс регулируется еженедельно.

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

Особенностью проекта в "МегаФоне" является то, что проект у нас территориально распределенный. В нем участвуют компании, независимые юридические лица из девяти регионов России. Внедрение типовых решений ведётся во всех регионах. Специфика нашего проекта продиктовала такую схему работы: мы сначала разрабатываем типовое решение для московского "МегаФона" (компания "Соник Дуо"), тестируем его здесь и внедряем. Затем оно внедряется в головном офисе "МегаФона", устраняются все замеченные шероховатости - и дальше уже отлаженное решение устанавливается в других регионах. В этом году на базе "Соник Дуо" был создан центр компетенции, который руководит проектом внедрения корпоративной системы электронного документооборота и организует его продвижение. Кроме того, мы привлекаем к работе над каждым модулем системы экспертов из бизнес-подразделений, которые специализируются в определенном направлении.

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

Татьяна Иванова: Я хотела бы добавить несколько слов о центре компетенции. Помимо корпоративной системы документационного обеспечения в "МегаФоне" внедряются другие решения, например SAP R/3, и ведутся другие проекты. Внедрение SAP R/3 - первый крупный проект, и для его управления и координации работ был создан центр координации. Когда было решено внедрять корпоративную систему документационного обеспечения и выбрана компания-разработчик, приказом была организована рабочая группа, в которую вошли руководители отделов "МегаФона" и "Соник Дуо" и руководители ИТ-подразделений обеих компаний. Это был этап описания существующих бизнес-процессов и осмысления того, что мы хотим получить в результате проекта. Затем началось поэтапное внедрение модулей.
Вот на этом этапе был создан центр компетенции, который стал не только централизованно руководить внедрением, но и координировать этот процесс, одновременно учитывая и контролируя своевременное выполнение доработок и удовлетворение запросов на изменение функциональности системы. В центр вошли функциональные эксперты "МегаФона", а его руководителями стали сотрудники "Соник Дуо". Мы регулярно собираемся, активно обсуждаем и спорим по всем вопросам внедрения. В спорах рождались и принимались окончательные решения и ставились точки в обсуждениях. Эти встречи продвигали и продолжают продвигать исполнение проекта.

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

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

Приходилось ли вам сталкиваться с такой проблемой, как сопротивление со стороны пользователей при внедрении электронного документооборота? Как известно, люди пугаются всего нового, и некоторые сотрудники яростно сопротивляются всему ходу работ.

Елизавета Лобова:

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

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

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

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

Елизавета Лобова: Внутреннее сопротивление практически неизбежно. Конечно, можно просто от самого высокого руководства спустить приказ об обязательном исполнении нововведений. Но проблема в том, что в России существует сколько угодно мертворожденных приказов, которые идут сверху и не поддерживаются снизу. Структура российской компании отличается от западной. Действительно, если в западной компании издается приказ, то сначала он, наверное, обсуждается на уровне топ-менеджмента. До принятия решения еще возможны какие-то сомнения, обсуждения - а после об этом уже не идёт речи. К сожалению, российская специфика, видимо, такова, что решение, принятое таким образом, приводит к тому, что люди используют любую возможность пассивного сопротивления нововведениям и жалуются на их несовершенство. Все-таки у нас оптимальный метод - идти с двух сторон, и сверху, и снизу. И находить золотую середину.

Павел Тараканов: Добавлю один пример. Мы начали проект в Карачаганаке (Karachaganak Petroleum Operating BV. - Прим. ред.) в малоприятной обстановке. До нашего прихода там уже было три неудачных проекта по внедрению системы документооборота. Когда мы туда приехали, отношение к нам было примерно такое: вы здесь, как и все остальные, проработаете пару месяцев и поедете назад с провальным проектом. То есть полный пессимизм как среди ИТ-специалистов, так и среди конечных пользователей.

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

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

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

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

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

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

Ещё - должен существовать план и процедура, в котором четко сформулировано, как будет происходить приемка результатов проекта. Это следует зафиксировать до начала работы. Любая фаза, любые работы по проекту, все принимаемые изменения должны быть полностью задокументированы. Это позволит использовать наработанный опыт на следующей фазе проекта, на следующих проектах.

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

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

Второй важный момент касается того, как проект структурирован. Есть два подхода. В соответствии с первым проект должен быть жестко структурирован - в этом случае есть детальный план проекта, разработано техническое задание. И второй подход - не структурированный, а гибко развивающийся проект. Большинство присутствующих здесь считают, что структурированный подход наиболее успешен и наиболее надежен - именно об этом говорил сегодня Павел Тараканов. Однако недавно мы сделали проект для компании British Petroleum в соответствии с гибким подходом. Разумеется, если бы я мог выбирать, я всё-таки выбрал бы структурированный подход - но мы работали с British Petroleum так, как они захотели. И хотя мы очень скептически относились к такому решению, результат был великолепным и превзошел все наши ожидания.

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