Студийные истории #13. Что делает клиент, когда сайт ему не нужен, но уже заплатил предоплату.

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

Я просто обожаю людей, которые способны признать свои ошибки. В данной ситуации это значит, что клиент понимает “я заплатил 50%, сайт мне уже сделали, надо платить остальные 50%”. Самые шикарные клиенты. Периодически кто-то спрашивает “а дальше мне с ним что делать?”. Тут я пытаюсь посоветовать, чего реально с ним можно сделать, какую информацию лучше разместить и т.д. Read more

Студийные истории #12. Постановка задачи и люди.

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

2. Короткое описание задачи, но уже на e-mail.
К сожалению ICQ, Skype – это не так надежно. В почте меньше вероятность отмахаться по типу “ой, а я не получил”, “ой, а оно мне дома пришло и я забыл” и т.д.
Если вас слушают и хотят понять, то это отличный способ. Вы не тратите много времени, а результат получают. В других случаях основная проблема это, то что задача короткая. Велик шанс быть неправильно понятым. Это и есть самая классическая отговорка, с которой я сталкивался: “тут ни ясно написано”. Очень удачно использовать, когда задача маленькая и не требует больших затрат времени, но сотрудника нет на работе (в поле досягаемости). Подразумевается, что такая задача должна быть выполнена, как можно быстрее.

3. Полное описание задачи в каком-то софте (таск-трекер / какой-то софт по совместной работе и т.д.).
Это самое нормальное, когда ты не знаешь, с кем ты работаешь или большая и сложная задача. Если ты работаешь с проверенными людьми, которые не первый раз видят этот проект, или проекты шаблонные, то можно не расписывать каждую новую задачу по полной. Если мозг detected, то они сами знают и сделают как обычно. Если же задача новая, то надо описывать всё и полностью. Опять же, если человек “свой”, то важно донести цель и задачу того, что он пишет. Всегда помните о том, что вы не самый умный, а специалист всегда может что-то подсказать. Но для этого специалист должен понимать зачем оно это все надо. Если же это просто исполнитель (в плохом смысле), то не утруждайтесь донесением целей. Все равно будет сделано ровно то, что написано.
Подобные задачи не могут быть выполнены “как можно быстрее”. Такие задачи всегда должны иметь срок. Задача без срока – не задача.

4. Readme – сделай файл и спи спокойно.
Очень интересный аспект. Если вы ставите задачу профи, то профи (глядя на дизайн/верстку и т.д.) на 80% уже знает, что делать. Особенно учитывая, что я описываю опыт работы в веб-студии, а это конвейер, то и на все 99% каждый знает, что делать. Так вот в редких случаях достаточно сделать файл readme и отравить вместе с psd/html/etc. Но так можно только с проверенными людьми.

Все любят работать с людьми, которые добросовестно выполняют свою работу. Я не исключение. Висеть над душой у человека круглосуточно это не очень веселое занятие. К тому же если видно, что человеку плевать на то, что он делает, то как можно ставить такому человеку задачу? С такими людьми лучше не работать.
Сейчас работаю с верстальщицей (всем рекомендую! за контактами обращайтесь лично) – все супер. У всех есть свои недостатки. Но для этого собственно и есть менеджеры, которые знают их и умеют с этим работать. Начинали мы с тех. заданий на верстку, потом ТЗ уменьшались в объеме, потом некий свод правил, а сейчас просто readme файлы периодически и все.

Выводы (аккуратно, чистое ИМХО!):

  • если человек не хочет работать, не надо с ним работать;
  • незаменимых людей нет и вы полный @&#$#$%$#%, если сотворили в своей команде незаменимого человека;
  • донести зачем это надо важнее, чем донести детали чего непосредственно надо;
  • не работайте с теми людьми, которые к вам относятся плохо (пусть даже они выполняют свою работу) или к которым вы относитесь плохо. Команда включает понятие “единомышленники”.

Студийные истории #11. Кто и как делает коммерческое предложение

По сути только три человека могут сделать коммерческое предложение, контактируя с клиентом. Непосредственно менеджер по продажам, аккаунт-менеджер, и проект-менеджер.

Менеджер по продажам делает коммерческое предложение непосредственно при продаже – первый контакт. Далее, этот же человек может выполнять обязанности аккаунта и работать с клиентом дальше. Скорее всего сделать хорошее и правильное (в плане цифр и сроков) КП продажник сделать не сможет. Посудите сами. Откуда продажник или даже аккаунт знает, какие ресурсы сейчас свободны, какие будут свободны дальше, каким ресурсам можно дать эту работу, а каким нельзя. // Сорри всем кого обозвал ресурсами. :)

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

Как вывод. Коммерческое предложение составляется вместе с руководителем проектов и продажником/аккаунтом. Одни знают клиента и как лучше ему предложить и что ему предложить. Другие знают смогут ли они это сделать, за сколько и в какие сроки.

У некоторых компаний встречал темплейты для коммерческих предложений. Видел решения автоматической генерации. А учитывая открытость .docx такой генератор коммерческих предложений вполне может написать каждый.

Интересная идея для стартапа: геоинформационные технологии.

В университете на дипломной работе, я занимался тем, что делал некий аналог интернет карт. Самое интересное было – это работа с картографической информацией. Когда карты в сети стали более распространены, я обрадовался, т.к. можно делать весьма и весьма интересные вещи. Провозившись некоторое время с API Yandex.Maps, я понял, что инструмент есть, но надо много данных собрать.

Техническая часть идеи.
Яндекс.Карты позволяют наносить поверх карт точки, линии, полигоны. Рассчитывать где рисовать полигоны, линии и точки поможет PostGis для PostgreSQL. Осваивается PostGis достаточно легко. По крайней мере, для первого результата, достаточно бегло прочитать мануал.

Необходимая информация.
Что бы провести какие-либо вычисления в PostGis, необходимо иметь базу объектов с их координатами. На дипломной работе мы брали демо-версии карт MapInfo, парсили их и наполняли базу. Яндекс.Карты поддерживают геокодирование (и обратное тоже), но к сожалению получить просто так базу объектов города не получится. К тому же важна не только информация о координатах объектов, но и описание этих объектов. Небольшой нюанс, объекты это не только строения, но и дороги, поля, леса и т.д. Разная информация есть на разных ресурсах. Те же самые Яндекс.Карты, Мапия, порталы с недвижимостью.

Пару идей.
1) Для недвижимости это может быть оценка привлекательности жилья. Необходимо составить базу «положительных» объектов (магазины, школы, садики, больницы, транспортные развязки, парки) и «отрицательных объектов» (заводы, фабрики, стройки, оживленные трассы, отстойники и т.д.). Построив полигоны влияния «положительных» и «отрицательных» объектов, рассчитав пересечения этих полигонов и степень их влияния, можно вывести некоторую оценки привлекательности жилья.
2) Для бизнеса будет интересно проведение анализа с помощью диаграммы Вороного, а так же ее разновидности. Несколько лет назад слышал такой кейс. Клиент заказал у одной ГИСовской компании провести анализ. У клиента было несколько магазинов по городу. В каждом магазине можно было купить некий продукт. Построив диаграмму Вороного, видно, где лучше поставить еще магазин и куда надо завозить продукции больше.
3) Некий социальный проект, который подходит скорее правительственным структурам, чем бизнесу. Создание карты с экологической информацией.
4) Шуточная идея. Ставите точку где-то в городе. Задаете коэффициент увеличения. Т.е. точка каждую итерацию растет на 1км. Делается это по средствам построение буфера. Разрисовывая каждую новую итерацию можно получить интересную картинку. Потом можно баловаться двумя вещами: метод наращивания площади и скорость.

Студийные истории #10. Испорченный телефон.

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

Был, да и сегодня есть, у нас один клиент, который заказывал интернет-магазин довольно специфической тематики. Основное то, что товаров там уйма, десятки тысяч.

Клиента представляла девушка. Я не знаю, какую должность она занимает у себя в компании. Даже могу сказать, что девушка сама по себе хорошая и делала все что могла, что бы сайт сделали хорошо. Проблема заключалась в том, что она не принимала решений. Это еще пол беды. Основная проблема была в том, что замечания и пожелания поступали от высшего руководства. А руководство было достаточно умно и неплохо разбиралось в нюансах разработки сайтов.

Что получилось? Все довольно просто. Руководство ставило задачи девушке. Девушка в силу своего понимания всех этих технических требований руководства, доносила задачу до нас. А мы выполняли задачу. Думаю уже понятно, где получался испорченный телефон. В итоге ни к чему хорошему это не привело: частые переделки, угроза разрыва договора.

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

Прощайте «Альтернативы». Здравствуй «Фотобиблиотека».

Я уже писал об «Альтернативах». Леша, главный организатор решил завершить конкурс и не продолжать. Пару дней назад истек срок регистрации доменного имени. Очень жаль. Но, в любом случае, это был хороший опыт.

Следующим проектом стал проект «Фотобиблиотеки«. Не знаю, буду ли я там принимать непосредственное участие, но проект обещается быть интересным.

Студийные истории #9. Сколько стоит дизайн сайта?

Когда я пришел, цена за дизайн определялась двумя способами. Да, это само по себе уже интересно. Первый способ – это стандартная сумма, которую ставили в коммерческое на какие-то шаблонные сайты. Второй способ – была цена главной страницы и цена внутренних шаблонов, таким образом, по кол-ву модулей и страниц в них рассчитывалась общая цена на дизайн. Вопрос не в способе расчета, а откуда берется первая цифра? Например: почему дизайн первой страницы стоит $600, а не $300 или не $1000?

К тем, у кого промелькнула мысль: «за $300 полное гавно абсолютное некрасивое» – просьба прям сейчас нажать Alt+F4.

Мы все знаем, что цена должна каким-то образом конвертироваться в качество. Мереть качество дизайна как будем? Ничего более субъективного среди клиентов я не встречал.

Сколько стоит дизайн для ювелирного сайта и для строительного сайта? Ювелирный сайт должен быть шикарным, как и его товар. Строительный же сайт должен быть простым и крайне понятным, без лишней графики. – Это все моё виденье. Цены на дизайн явно будут отличаться. А есть клиенты, которые хотят, что бы строгий технический сайт выглядел разукрашенным и т.д. Как клиенту объяснить разницу в цене и как клиенту объяснить, что он получит?

Конечно же, надо показать. Я пошел к дизайнерам и попросил отобрать из всех работ за последние пару лет те, которые не стыдно показать. (Ой, давайте без этого. У всех студий есть работы, которые в портфолио ставить не хотят по разным причинам). Было отобрано около 100 работ. После мы их рассортировали на 4 уровня. Как? Да очень просто. Дизайнеры оценили свои работы от 1 до 4 и все. В итоге я получил четыре папочки с картинками. Теперь на вопрос «сколько стоит дизайн сайта«, я показываю примеры клиенту и говорю, что вот первая стоит дешевле, а четвертая дорого.

Интересно: процентное разделение выбора клиентов: 1 – 20%; 2 – 20%; 3 – 50%; 4 – 10%.

Студийные истории #8. Делим деньги коммерческого предложения.

В этой статье речь пойдет о том, как делить деньги в коммерческом предложении (КП). По сути это ответ на вопрос: если в КП указана цена конкретно за дизайн/верстку/программирование, то стоит ли столько же (пропорционально) отдать работникам?

Допустим, у нас есть коммерческое предложение на более или менее среднестатистический сайт в вакууме с ценами:

  • техническое задание – бесплатно разрабатывается для каждого проекта;
  • дизайн (~5 шаблонов страниц) – $500;
  • верстка – $170;
  • программирование – $1000;
  • базовое наполнение – бесплатно в рамках тестирования сайта.

Сумма: $1670

Почему за дизайн $500, а за программирование $1000? Несомненно, есть проекты, где это 100% обосновано сложностью кода и легкостью дизайна. Но я часто встречал случаи, когда клиенты говорили: «Ой. А в другой студии нам предлагают дизайн за $500. А работы такие же красивые как у Вас. Да и вообще нарисовать это не очень сложно», – и клиенты уходили. Некоторые таким же образом приходили к нам. Фокус в том, что большинство людей, не разбирающихся в технологиях создания сайтов, думают, что дизайн в разы легче, чем программирование. К тому же рассказать, почему программирование сложнее проще. Проще продать.
Вопрос второй: почему верстка $170? Это же практически чистая себестоимость? А как же прибыль? А как же % продажникам? А как же издержки и прочее?
Вопрос третий: руководитель проекта и контент-менеджер работают бесплатно?

Становится ясно, что сумма проекта распределяется между участниками иначе. Не так, как она отображена в КП. Но как?

Наша команда:

  • менеджер по продажам;
  • руководитель проектов;
  • дизайнер;
  • верстальщик;
  • программист;
  • контент-менеджер.

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

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

Часть разделения денег, которое я знаю и от которого не отступаю:

  • 20-40% руководителю проекта. 40% – обычно берется на маленьких проектах, т.к. время, потраченное на переговоры достаточно велико, а сумма заказа маленькая. К тому же клиент может потребовать какого-то изощренного способа коммуникации, например: менеджер, всегда должен приезжать к клиенту на встречу лично, и никаких телефонов. (Да, бывают извращенцы, и если Вы сейчас на мели, то приходиться работать с кем есть). В эти проценты входят и риски, т.к. ими распоряжается исключительно руководитель проекта.
  • 25% – строго на тестирование, отладку и базовое наполнение. Почему четверть? Да, просто потому, что все допускают ошибки – это раз. Во-вторых, когда клиент видит почти готовый продукт, ему обычно хочется что-то изменить. Можно попытаться брать за каждую мелочь деньги. Так можно прослыть крохобором или вообще поссорится с клиентом.
  • остальные деньги распределите сами исходя из издержек фирмы, уровня з/п специалистов, скорости работы специалистов, трудности какой-то конкретной задачи и т.д. Помните, что 25% тестирования – это не только работа тестировщика (или кто там выполняет его роль), а еще и работа программиста по исправлению багов и т.д. Очень хорошо получается распределять деньги, когда есть диаграмма Ганта, трудозатраты по часам и хороший архив проектов, где можно посмотреть как это уже было. MSProject вообще делает красивые отчеты по деньгам.

По некоторым предыдущим проектам разделение такое (от суммы очищенной от налогов и издержек):

  • 10% – менеджер по продажам;
  • 20% – руководитель проектов;
  • 25% – дизайнер;
  • 10% – верстальщик;
  • 20% – программист;
  • 5% – контент-менеджер;
  • 10% – риски.

* – Проекты небольшие, в основном все стандартно, есть шаблоны ТЗ, есть CMS, только дизайнер рисует всегда всё с нуля.

25% – тестирования, заложено в руководителя проекта, верстальщик, программиста, совсем чуть-чуть контент-менеджера.

По окончании проекта, если все прошло хорошо, то «рИсковые» деньги можно оставить себе (и забыть о команде), раздать премию команде и себе, вложить в дальнейшее развитие, или даже(!) купить кусок контекста для клиента с аргументацией «А Вы нам так понравились, вот Вам подарок от нас»! Не сомневаюсь, что куда деть эти деньги Вы всегда найдете.

Пару советов:

  • персонал никогда не должен видеть коммерческого предложения, точнее сметы. Это обусловлено тем, что персонал сразу думает, что все деньги по его работе будут ему. Можно объяснить, что там налоги, издержки и т.д., но мысль «за мою работу берут $1000, а я с нее получаю $300″, – совсем не греет. Иногда это служит причиной ухода на фриланс (мне жаль людей, которые ушли именно и только по этой причине). Так же персонал видя сумму, сразу может рассчитать время, которое ему должно быть выделено. Как показывает опыт, время всегда надо выделять ровно столько сколько надо, а денег брать больше – это наши «рИсковые» деньги. Сотрудник же понимая, что у него в запасе есть еще пару дней… Все знают, что бывает в таких случаях обычно.
  • клиенту лучше не знать, что в КП заложены риски. Даже если клиент закладывает риски в своих КП, то все равно большого желания платить он не испытвает. Я встречал клиентов, которые при слове «риски» пугались и уходили, и таких, что обсуждали, какие риски могут быть и как их уменьшить.

Студийные истории #7. Коммерческое предложение на разработку сайта.

Это первая, но не последняя статья о коммерческом предложении (КП).
В двух словах. Зачем оно нужно? Необходимо как-то сообщить клиентам о том за сколько денег и в какие сроки Вы выполните для них работу. Я считаю, что это основная цель коммерческого предложения. Все остальное менее главное.

Когда я пришел в веб-студию, КП имело приблизительно такой вид:

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

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

Лирическое отступление.
Всегда удивлял, удивляет и будет уделять, тот факт, что когда спрашиваешь у клиента ориентировочный бюджет, то 99% морозятся. Да, это именно то слово, ибо по другому невнятный ответ о том, что еще неизвестна сумма, назвать нельзя. А вот когда даешь в руки коммерческое предложение, то сразу же взгляд на сумму, а на лице вопрос: «Хватит ли денег?».
Почему удивляет? Потому что если я хочу купить ноутбук за $1000, то я выберу ноутбук максимальной конфигурации именно на эту сумму, а не буду радоваться, что на рынке есть унылое гавно что-то проще за $500. Так почему же не заказать сайт максимально классный в рамках бюджета?

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

Меня очень удивило то, что наша таблица с работами в коммерческом предложении состояла из 3 частей:

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

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

Я видел два больших недостатка:

  1. Разделение интерфейсной части и админ-части. Сегодня одно без другого уже не бывает (или нет?).
  2. В коммерческом предложении не было раздела «верстка». Работа есть, деньги за нее берут, но она размазана по разделу программирования. Это плохо, т.к. если верстает фрилансер, то проект надо разбивать на зарплату каждому и долю студии.

Таким образом я внес два важных изменения и маловажное:

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

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

Одна студия описала в коммерческом все работы и дополнительно, что и как будет происходить на этих работах. Идея мне очень понравилась, т.к. это делает для клиента Вашу работу прозрачнее, а значит доверия больше. Но вот само описание было более «разработчику от разработчика», чем «клиенту от исполнителя».

Вторая студия из коммерческого предложения сделала некую методичку по ликбезу. Документ был раздут до ~10 листов текста в вперемешку с картинками. Цифры были разбросаны по всему материалу, а материал носил настолько рекламный характер, что становилось дурно от такого.

На мой взгляд, основные цели коммерческого предложения такие (в порядке важности):

  • донести до клиента сумму и сроки выполнения работ, а также обоснование суммы и сроков;
  • увеличить доверие к Вашей компании и уверенность в Вас, как в профессионалах (полные контакты, примеры работ, возраст компании);
  • ознакомить с дополнительными услугами и расценками на них, где это возможно (понятное дело, что сдуру вписывать сумму по SEO Вы не станете).

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

Студийные истории #6. Хорошим верстальщикам ТЗ не обязательно.

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

Почему так? Рассмотрим небольшой сайт визитка на 3 макета: главная страница (она же текстовая/информационная), каталог страниц (что бы отобразить вложенность разделов), и какая-то страница с формой обратной связи и картой от Яндекс.Карты. Дизайнер отдал Вам (менеджеру) все три макета в PSD… все как положено.

Вопрос: что объяснять верстальщику?
Увидеть где и какие элементы будут ссылками совершенно не есть проблема – логика у всех работает (должна по крайней мере!!!). Должен ли сайт «тянутся»? Тут тоже все понятно: нормальные дизайнеры, если сайт фиксированной ширины, рисуют фоновые поля. Рассказывать верстальщику как должны меняться ссылки при наведении? А вот и нет! Это задача дизайнера показать все выделения и все варианты отображения. Можно попробовать рассказать о том, что нужно оставлять комментарии в коде, но это и так должно быть понятно: отсутствие комментариев не комильфо. Так же хороший верстальщик сам знает, что названия страниц надо делать h1, и как правильно дальше использовать h2,h3 и т.д. Хороший верстальщик знает, что поисковик читает страницу сверху вниз, ровно так как это написано в html-коде, а не так как это видит пользователь, потому более важные элементы выносятся выше по коду и т.д. О W3C я вообще молчу.

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