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

«Что будем публиковать, дорогой хабрачеловек?» — спрашивает меня Хабр. Вот ведь как — мною дорожат здесь, даже не зная, какая публикация пойдёт в блог — поскольку эта запись в персональном блоге первая (надеюсь, не последняя).

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

Почти год назад, 3-го ноября, впервые в России праздновался день Юзабилити. Организаторы мероприятия — World Usability Day — проект Usability Professionals' Association, предназначенный для продвижения концепции и методик юзабилити во всем мире. Тогда же, год назад, были опубликованы результаты опроса «Юзабилити в России», на основании которых можно точно сказать, что тема юзабилити уже привлекает внимание.

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

19 октября в Москве пройдет семинар RusCHI #12 (российское отделение ACM SIGCHI), на котором Екатерина Сугак расскажет о методике проектирования интерфейса, а Дмитрий Филёв — об открытии UsabilityLab в IT-Online Group. RusCHI многим известен с 2001 г. еще в качестве неформального сообщества, сформировавшегося вокруг интернет-сайта Usability.ru и его форума.

К теме usability наблюдается очередная волна интереса — и со стороны разработчиков коммерческих сайтов, и со стороны seo-мастеров (Юзабилити — это будущее поисковой оптимизации). Информации же не так много — есть серия публикаций переводных материалов (Нильсена) в соответствующей рубрике на webmascon.com, тот же usability.ru или комплексный блог с несколькими авторами gui.ru — там публикуют заметки Платон Днепровский, Андрей Седельников, Дмитрий Сатин, Дмитрий Павлов, Иван Дегтяренко, есть ЖЖ-сообщество, посвященное всем аспектам User Centered Design. И все же — судя по качеству сайтов (в среднем) — в рунете или вообще — мало информации, мало.

Пора уже составить словарь спецтерминов, связанных с хабрахабром.

Хабрахабрить (модно) — читать, писать, комментировать, голосовать на хабре.
хабратопик — запись в блоге
хабрапочта — обмен личными сообщениями между участниками, внутренняя почта на хабре;
За- Отхабренные — тексты и объекты, вошедшие в «популярные» и, соответственно, вышедшие оттуда.
Хабрабета — перманентное (опять же как теперь стало ясно из последнего интервью Дениса Крючкова) состояние хабрахабра, т.е. бесконечное развитие

Еще встречались такие чудные определения:
хабрасила
хабрабалансировка
хабратайна (по всей видимости некая идея, которая зреет и готовится к реализации, но о которой никому нельзя говорить)
— А еще были негативные "хабрагеноцид" (злобно понизили карму) и "хабравойна" (с дорвейщиками); в комментариях к интервью на ВебПланете Андреев посылает читателей нах абр…

Интересно просто, а будет ли доступна более подробная информация из блока «Статистика»? Сейчас этот блок… конфетку ребёнку показали и обратно в буфет заперли. «Откуда мы?» -> «Украина: 41»
И так хочется кликнуть на этом «Украина: 41» — а там текст.
«Где мы?» -> «Киев: 15» — вот ведь близко как получить информацию — 15 участников! А кто?
Хотелось бы на эелементах списков ссылки на открывающиеся списки участников — это ведь не нарушение прайвеси, информация публична — из профайлов, но искать ее по каким-то общим спискам (которых, кст, как я поняла, нет) — это не правильно. Если сервис будет способствовать тому, чтобы находить единомышленников в своем регионе — это было бы здорово.

Можно ли ожидать, что будет возможность уже опубликованные записи «редактировать» (не только корректором, но и автором записи)? Я не говорю о комментариях, но посты в колонках… бывают банальные опечатки, ошибки, очень хочется исправить. А никак.

И мелочь — из профайла пользователя сделать параллельные кнопки «добавить» — такие, как из общего раздела «колонки» — в пользовательском разделе «колонки», и т.д. Вроде как логично было бы.

В 207-м выпуске рассылки Библиотеки Сайтостроительства обсуждалась тема разработки малобюджетных сайтов. Говорили о том, что, в принципе, при наличии опыта сайтостроительства, а так же когда случайным образом складываются обстоятельства, веб-разработчик может согласиться принять участие в создании сайта за очень не высокую оплату. После выхода рассылки мне приходили письма от подписчиков — читатели говорили о том, что ситуация никогда не разрешится — всегда будут клиенты, желающие получить проект «почти» на халяву, и всегда найдутся разработчики, которые возьмуться исполнить требуемое. Перечислять все причины, отчего проблема малобюджетных сайтов остается актуальной, бессмысленно, большая часть из них очевидна.

Прежде всего, разумеется, причины следует искать в социуме в целом, в уровне жизни, который будет отличаться от региона к региону. Московские цены на веб-сайты разительно отличаются от питерских, те, в свою очередь — от региональных российских. В постсоветских странах — в Беларуси, Молдове, Украине, ниже уровень жизни, значит, ниже возможности заказчиков сайтов — при совсем не более низком уровне квалификации специалистов. В Москве уже давно не удивляются бюджету на разработку сайта в десятки и сотни тысяч условных едениц, в Гомеле и Харькове это будут в лучшем случае считанные тысячи, а то и сотни тех же буржуйских денег. Но при этом обратите внимание — один из самых достойных инфоресурсов для веб-разработчиков — сайт Алекса Качанова webmascon.com — проект (изначально) беларусских мастеров, а если посмотреть на тот же украинский г. Харьков глазами «Яндекса», мы увидим индустриальный город с развитой промышленностью и впечатляющим количеством вузов, большей частью технических. А сейчас в каждом первом лицее, институте, университете на многих специальностях преподают программирование, в том числе и веб-программирование. Следовательно что? Количество высококвалифицированных, образованных и опытных IT-специалистов на душу населения настолько высокое (при сравнительно не высоком уровне жизни в пересчете на среднюю зарплату), что становится ясно — веб-разработки здесь дешевле, и заметно.

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

Посмотрим на типичного малобюджетного заказчика. Как правило, это организация или человек, которые довольно мало осведомлены о реальной глубине проблемы, которую намереваются решать, т.е. о реальной стоимости правильного решения. В качестве примера в прошлом выпуске мы приводили заказчика (не придуманного), возжелавшего себе полноценный портал с большим количеством сервисов — движка для создания и управления текстами (новостями и статьями), чатов и форумов, каталога товаров и учета статистики и прочих мелких приятных штучек — с бюджетом в $300; и что вы думаете? Частью специалистов бюджет был поднят на смех, сам же заказчик был обозван лохом. Но тут же нашлись разработчики, которые объявили, что минимум работ за указанные деньги они выполнить смогут, и еще за столько же — отдать полноценный работающий проект «под ключ».

В ходе обсуждения выяснилось, что этот конкретный заказчик на самом деле очень слабо себе представляет, что ему на самом деле нужно, не сталкивался с проблемами безопасности, защиты информации, а так же не имеет опыта поддержки и администрации проектов желаемого уровня. Оценить полученный за $300 проект он сможет только через какой-то период времени, когда попробует его настроить на реальную работу и столкнется с обычными житейскими проблемами — когда на сыром движке он не сможет ни поменять, ни даже доработать, причесать визуальный дизайн своего детища, а поставщики движка — они-то, возможно, согласятся, за дополнительные деньги. А при том движении на рынке веб-программистов, которое присутствует во всех регионах — и с высоким уровнем жизни, и с низким, может быть и так, что он уже не найдет этих программистов вообще, а если даже и найдет, то окажется, что они уже работают не в одной команде, и первый без второго помочь не сможет, а второй работает в крутой компьютерной фирме и ему просто не интересно возвращаться к разработке того движка, который дорабатывать никто не планирует (а смысл, если бюджеты символические), и вообще некогда, всем пока. Ситуация так же не придуманная, сталкивались с этой проблемой многие «экономисты».

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

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

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

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

1. Возможно, что кого-то это удивит, но цена услуги для многих является показателем её качества (чем выше цена — тем выше воспринимаемое качество услуги, ну и наоборот). Назначая цены ниже рыночных, Вы вселяете в покупателя сомнения в качестве Ваших услуг. Если Вы сами не цените свои услуги, то почему их должны ценить другие? Да и к тому же многие помнят поговорку: “бесплатный сыр бывает только в мышеловке”. Серьёзно снижая цены на услуги Вы скорее не привлекаете, а отпугиваете хороших клиентов.

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

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

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

5. Работать в нижнем ценовом сегменте чаще всего экономически невыгодно, при тех же трудозатратах Вы зарабатываете меньшие деньги.

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

С другой стороны — в общем-то не мало известно проектов, которые создавались и поддерживались практически «на голом энтузиазме» его авторов, и вот собрать список и истории развития подобных веб-проектов хотелось бы уже в ближайшее время :) так что если есть что вам рассказать — пишите здесь или на мейл nundesign@gmail.com.

История рекомендательных писем насчитывает несколько сот лет. И сто, и двести лет назад служащий, который приходил устраиваться на новое место работы, вручал будущему работодателю документ, в котором либо в вольной форме, либо официальным тоном сообщалось о том, что «этот порядочный молодой человек положительно зарекомендовал себя…» или «девушка из хорошей семьи наших друзей, мы рекомендуем ее как честную и ответственную…» — и при наличии таких писем вероятность получения места увеличивалась на порядки.

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

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

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

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

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

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

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

Современные онлайновые социальные сети пытаются исправить подобное упущение. Задача любой такой сети – построить цепочки знакомств, показать связи между людьми. Следовательно, если сеть позиционирует себя как «деловая», «бизнес-сеть», она отчасти может решать проблему поиска деловых, партнерских и рекрутинговых контактов, предоставляя помимо общих данных участника сети, которые можно получить из его профайла, нужные цепочки его связей с другими участниками сети.
И все же большинство таких деловых сетей в рамках работающих моделей не позволяют внедрять базу рекомендаций. Т.е. реализуется обычная система цепочек знакомств, перенесенная из оффлайнового мира в онлайновый, и вся гибкость модели заключается в том, что участник, заинтересованный в поиске делового контакта, может изучить информацию из профайлов других участников и послать запросы через систему обмена личными сообщениями в сети или вне сети своим знакомым.
Но ведь более расширенная реализация модели так близка! Как правило есть все данные для того, чтобы сформировать на базе существующих деловых сетей систему рекомендаций по отраслям.

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

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

Некий наниматель ищет в свою организацию хорошего технического директора, важное условие – у него должна быть определённая база знаний и определённый опыт в той же отрасли. Разумеется, он будет искать нужного работника, используя личные связи, а не агентства по трудоустройству. Теоретически в рамках развитой социальной сети он сможет найти того самого технического директора, и даже предположить, что тот согласится перейти из маленькой фирмы в его, известную и крупную организацию. Но ему нужны подтверждения того, что он не ошибся в своем выборе. Если он попытается получить эти подтверждения в рамках той же сети, ему придется так же как и в оффлайновой жизни делать запросы через системы обмена сообщениями или опубликованные контакты других участников сети. А ведь как можно оптимизировать такую структуру данных:

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

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

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