Creation and Promotion of Sites | Создание и продвижение сайтов

НЕпрофессионал для НЕпрофессионалов

Требования к сайту

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

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

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

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

Создание сайта – это стратегический проект развития компании (подробнее о проектах развития можно прочитать в моей книге «Стратегическое управление и эффективное развитие бизнеса»).

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

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

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

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

Итак, при создании сайта, а потом и при его продвижении я не рекомендую использовать самую распространенную стратегию создания и продвижения сайтов.

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

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

Первое требование к сайту: индексация всех страниц сайта

Для того, чтобы сайт приводил к вам потенциальных клиентов из поисковых систем, они должны его «видеть». Иными словами ВСЕ страницы вашего сайта должны быть проиндексированы, то есть внесены в память поисковых систем.

К сожалению, я сам один раз допустил такую ошибку. При разработке второй версии сайтов www.rik-company.ru и www.bud-tech.ru использовалась технология, которая не позволяет создавать индексируемые страницы.

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

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

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

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

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

Итак, индексируемость всех страниц сайта является одним из важнейших требований к сайту.

Второе требование к сайту: возможность самостоятельной дальнейшей поддержки сайта

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

Это значит, что у вас должна быть возможность как минимум самостоятельного добавления новых страниц в уже существующие разделы сайта. Хотя желательно, чтобы вы могли создавать и новые разделы сайта.

Есть два способа как этого добиться.

Первый вариант заключается в том, что вам нужно будет освоить хотя бы азы html. Первые версии сайтов www.rik-company.ru и www.bud-tech.ru были написаны даже не на html, а на php.

Тем не менее, ничего не зная об этом языке программирования, я смог разобраться с тем, как мне самостоятельно добавлять новые страницы, а потом и новые разделы на сайт.

Второй вариант намного проще первого (даже азы html знать не нужно). Для того чтобы им воспользоваться сайт должен разрабатываться с помощью какой-то CMS – Content Management System (система управления контентом).

Понятно, что в таком случае придется освоить саму CMS. То есть в любом случае придется что-то изучать.

Можно, конечно, и техническую поддержку сайта передать на аутсорсинг, например, той компании, которая занималась его разработкой.

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

Итак, в любом случае нужно сразу продумать каким образом в дальнейшем будет обновляться сайт. Возможно, стоит запланировать обучение. Такое обучение может провести, например, та компания, которая будет привлекаться для создания сайта.

Третье требование к сайту: кроссбраузерность

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

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

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

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

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

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

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

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

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

Четвертное требование к сайту: правильная работа сайта на всех основных типах устройств

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

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

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

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

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

Как составить требования к сайту

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

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

Как обычно поступают требования

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

Заказчик – не программист, ТЗ писать не умеет, от него этого не требуется. Что требуется от заказчика, который пришел с заданием, – это знать свою предметную область и отвечать на вопросы для уточнения требований. Случается, что добиться ответа довольно проблематично.

Какие бывают затыки

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

Почему мы не можем «сделать как-нибудь»

Если у заказчика возникают вышеописанные затыки, он предлагает сделать «как-нибудь», «на ваше усмотрение». Белые пятна в требованиях и предложения «сделать как-нибудь» – это зло. Алгоритм «как-нибудь» не напишешь, в нем все должно быть строго. Молодой разработчик, глядя на такое описание, сделает удивленные глаза, а опытный разработчик запрограммирует по-своему. В первом случае задача не будет выполнена, во втором – будет выполнена не так, как нужно бизнесу.

Смотрите так же:  Образец приказа об утверждении учетной политики на 2019 год

Как нам сделать, чтобы всем было хорошо

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

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

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

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

Не нужно усложнять. Это прекрасно, когда заказчик – опытный интеллектуал с IT-бэкграундом. Когда он способен придумать и изложить сложную логику. Как приятно с ним общаться и формулировать требования! Однако в реальности с этой сложной логикой придется работать не только аналитикам и программистам (они, как правило, способны ее понять), но и контент-менеджерам, редакторам, саппортникам, наконец. Да и не будем забывать про Пользователя, всегда ли ему нужно вникать в сложную логику нашего проекта, в перегруженный интерфейс или понятную только избранным навигацию? Есть такое правило – Упрощай (за бугром это правило известно как KISS — keep it simple stupid).

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

Приносите ваши требования, будем вместе их уточнять 🙂

Как написать функциональное техническое задание?

Всё про­сто: нор­маль­ным рус­ским язы­ком опи­сы­вайте нуж­ные функ­ции в фор­мате сце­на­рия исполь­зо­ва­ния. Сце­на­рий лучше всего опи­сы­вать в по схе­ме: [роль поль­зо­ва­те­ля] может [дей­стви­е], [опи­са­ние целей поль­зо­ва­те­ля, а также необ­хо­ди­мых шагов и вари­ан­тов раз­ви­тия собы­тий]. Опти­мально – раз­би­вать опи­са­ние боль­ших ком­по­нен­тов на малень­кие составляющие.

В конеч­ном ито­ге, пункты ТЗ должны быть объ­ек­тив­ны­ми, про­сто изло­жен­ными и эле­мен­тар­ным спо­со­бом про­ве­ря­е­мыми тре­бо­ва­ни­я­ми, напри­мер, вполне адек­ват­ные функ­ци­о­наль­ные тре­бо­ва­ния в фор­мате сце­на­рия:

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

Субъ­ек­тив­ные (некор­рект­ные) тре­бо­ва­ния – это все тре­бо­ва­ния с оце­ноч­ными при­ла­га­тель­ными типа удоб­ный, кра­си­вый, про­стой и тому подобными. Это никак нельзя про­ве­рить, а зна­чит при­нять рабо­ту, осно­вы­ва­ясь на таких кри­те­риях про­сто не получится.

Непо­нят­ные (некор­рект­ные) тре­бо­ва­ния – это тре­бо­ва­ния сфор­му­ли­ро­ван­ные так, что нельзя без долж­ной под­го­товки понять о чём вообще идёт речь, например:

Поль­зо­ва­тель дол­жен иметь воз­мож­ность реструк­ту­ри­зи­ро­вать ком­по­ненты сво­его акка­унта путём деком­по­зи­ции отдель­ных сущ­но­стей на про­из­вольно зада­ва­е­мое число вза­имно зави­си­мых ком­по­нен­тов.

Еще при­меры нор­маль­ных функ­ци­о­наль­ных тре­бо­ва­ний:

Гость на каж­дой стра­нице может войти на сайт. По нажа­тию кнопки «войти» откры­ва­ется форма для ввода логина и паро­ля. При кор­рект­ном вводе логина и пароля поль­зо­ва­тель вхо­дит на сайт и ему выво­дится уве­дом­ле­ние об этом, дальше он рабо­тает с сай­том как аутен­ти­фи­ци­ро­ван­ный поль­зо­ва­тель и ему ста­но­вятся доступны допол­ни­тель­ные воз­мож­но­сти. При некор­рект­ном вводе логина и/или пароля отоб­ра­жа­ется уве­дом­ле­ние о про­изо­шед­шем и поль­зо­ва­телю пред­ла­га­ется повторно запол­нить форму Заре­ги­стри­ро­ван­ный поль­зо­ва­тель при посе­ще­нии сайта дол­жен видеть пер­со­наль­ное при­вет­ствие «Здрав­ствуй­те, [Имя] [От­че­ство]!» и ссылку для выхода с сай­та. При нажа­тии на своё имя поль­зо­ва­тель попа­дает в лич­ный каби­нет, при нажа­тии на ссылку «выход» – выхо­дит из системы и дальше рабо­тает с сай­том как гость. Адми­ни­стра­тор может уда­лить стра­ницу сай­та. В списке стра­ниц напро­тив каж­дой стра­ницы есть кнопка для уда­ле­ни, по нажа­тию на эту кнопку выво­дится диа­лог под­твер­жде­ния уда­ле­ния. При под­твер­жде­нии стра­ница уда­ля­ет­ся, а при отказе — уда­ле­ния не про­ис­хо­дит.

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

Гость дол­жен иметь воз­мож­ность заре­ги­стри­ро­ваться на сай­те. Для этого он может с любой стра­ницы сайта по ссылке «заре­ги­стри­ро­ваться» перейти на стра­ницу с фор­мой реги­стра­ции.

Форма реги­стра­ции содер­жит поля: Фами­лия, Имя, Адрес элек­трон­ной почты, Пароль и его Под­твер­жде­ние, а также флаг согла­сия с пуб­лич­ной офер­той. Все поля явля­ются обя­за­тель­ными для запол­не­ния. Адрес элек­трон­ной почты дол­жен быть кор­рект­ным адре­сом e-mail , Пароль дол­жен быть не короче 6 сим­во­лов и содер­жать буквы и циф­ры, Пароль и Под­твер­жде­ние должны сов­па­дать, флаг согла­сия с пуб­лич­ной офер­той дол­жен быть уста­нов­лен. При некор­рект­ном запол­не­нии формы выво­дится спи­сок оши­бок при запол­не­нии фор­мы, а поля с ошиб­ками подсвечиваются.

Кор­ректно запол­нив и отпра­вив форму реги­стра­ции гость создаёт новую учёт­ную запись, а ему на ука­зан­ный адрес элек­трон­ной почты отправ­ля­ется письмо с уве­дом­ле­нием о реги­стра­ции и со ссыл­кой для акти­ваци акка­унта. Для акти­вации акка­ункта поль­зо­ва­тель дол­жен перейти по полу­чен­ной ссыл­ке, после чего он будет авто­ма­ти­че­ски аутен­ти­фи­ци­ро­ван (вой­дёт на сайт).

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

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

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

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

Требования к созданию сайта

Каким должен быть сайт? Ниже я структуирую информацию и проведу анализ факторов и требований к сайту

Общие требования к сайту

Среди требований к созданию сайта общего характера я бы выделил такие:

корректное отображение

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

структурированная информация

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

Приятный дизайн

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

Хорошая конверсия

сайт должен превращать посетителя в покупателя

иметь хорошую целевую посещаемость (в это статье как лучше раместить рекламу в интернете http://likiweb.ru/sozdanie/kak-razmestit-reklamu-v-internete

Это я описал в общем, а теперь подробнее по порядку.

Требования Яндекса к сайту

Существует такое понятие, как требование поисковых систем к сайту. Перед созданием ресурса стоит с ними ознакомиться. Вы можете изучить их, перейдя по ссылке http://help.yandex.ru/catalogue/site-owner/requirements.xml

Основные требования яндекса:

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

Однозначно что не следуя этим рекомендациям хороших позиций и целевых посетителей с яндекса или гугла вам не видать.

Требования к дизайну сайта

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

логичность структуры ресурса

нормальное боковое и/или верхнее меню, «хлебные крошки», понятная и удобная навигация при переходах по внутренним страницам − всё то, что помогает мне ориентироваться на незнакомом ресурсе, автоматически попадает в плюс;

адекватность цветовой гаммы

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

Технические требования к сайту

  • нормальная скорость открытия ресурса (не более 3 секунд);
  • кроссбраузерность (видимость во всех браузерах);
  • оптимизация под планшеты и телефоны.

Я могу сказать, что с графикой, как правило, возникает много проблем. Если она не оптимизирована, будут проблемы с загрузкой, и пользователь уйдёт. Поэтому графика должна быть легкой и при этом наглядной и крупной.

Требования к безопасности сайта

К вопросу безопасности сайта я рекомендую подходить комплексно. Нужно обращать внимание на:

CMS (система управления)

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

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

надёжный пароль

чем сложнее будет код, тем меньше вероятность того, что ваш сайт подвергнется атакам извне, я бы рекомендовал использовать большое количество символов в разных регистрах;

резервное копирование и хранение на локальном компьютере или естком диске даёт возможность сохранить информацию сайта, упростит его восстановление в случае хакерской атаки.

Требования к адресу сайта

  • Краткость — чем меньше символов, тем лучше.
  • Простота — имя ресурса должно быть легко произносимым (не должно быть двусмысленных букв — S C или K C).
  • Релевантность — желательно, чтобы адрес отражал суть деятельности.

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

Смотрите так же:  Бухгалтерская отчетность в налоговую сроки

Требования к контенту сайта

Я выделил бы такие требования к наполнению ресурса, как:

  • читабельность (нормальное соотношение ключевых слов и остальной лексики);
  • достаточный объём текста;
  • грамотность;
  • уникальность.

Как составить хорошее техническое задание на разработку сайта

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

Для начала разберемся с тем, что такое техническое задание на сайт. ТЗ – это документ, в котором указаны требования к сайту. Чем подробнее и понятнее они зафиксированы, тем лучше все стороны понимают, каким должен быть итоговый результат. Главная задача ТЗ: убедиться, чтобы каждая из сторон правильно поняли друг друга. Польза от этого довольно велика.

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

Кто составляет техзадание?

  • Познакомить исполнителя с компанией и ее продуктами или услугами.
  • Рассказать о целевой аудитории бизнеса.
  • Рассказать, зачем ему сайт, что хочет получить от него.
  • Показать ресурсы, которые нравятся и которые он считает хорошими со своей точки зрения.
  • Отвечать на все вопросы, которые задает исполнитель.

Как нужно писать техническое задание

Пишите однозначно и точно


Кому-то такой дизайн нравится

Также в ТЗ надо исключить формулировки наподобие:

  • Сайт должен понравиться заказчику. А это будет зависеть от того, что заказчик с утра съел горькую кашу?
  • Сайт должен быть удобным. Для кого?
  • Сайт должен выдерживать большие нагрузки. А большие это какие? 10 тысяч? 100 тысяч? Миллион?
  • Качественный экспертный контент. А какие критерии экспертности?

    Поэтому постарайтесь заменить все неоднозначности как можно более точными формулировками. Например:

    Как составить требования к сайту

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

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

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

    1. Обоснование необходимости ТЗ

    А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

    Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

    Под конец работы приходит дизайн от заказчика, и при его просмотре становится ясно, что заказчик понимает задачу несколько иначе. А именно так:

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

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

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

    Так вот, задача технического задания — это свести к минимуму разницу между представлениями двух строн: заказчика и исполнителя. Хорошее ТЗ дает маленький diff, плохое ТЗ — большой.

    Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

    И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д.
    Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот.

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

    Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

    Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

    Описываемый ниже подход, как раз и будет претендовать на ТЗ со степенью детализации близкой к оптимальной.

    2. Что в нем должно быть и чего нет. Формулировки

    Техническое задание — это документ, часть договора (не важно это договор с печатями и подписями или же только устная договоренность), которая регламентирует, какие работы должны быть выполнены. Всё что описано в ТЗ должно допускать возможность объективной оценки. Т.е. должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет.

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

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

    Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!».

    Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

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

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

    Смотрите так же:  Федеральный закон трудовой кодекс российской федерации

    Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.

    3.2 Эксплуатационное. назначение

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

    3.3 Функциональное назначение

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

    Очень часто на фрилансерских сайтах публикуются документы с гордым названием «Техническое задание», в которых содержатся вышеописанные три пункта. Однако, на самом деле, это только вводная часть ТЗ.

    3.4 Термины и определения

    Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
    Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

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

    3.5 Данные и списки

    Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.

    Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.

    Перечисление атрибутов сущности позволяет заметить мелочи, которые, оставшись незамеченными, могли бы привести к осложнениям.

    Для примера, та же самая новость:

    • Заголовок
    • Текст
    • Дата публикации

    Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

    Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
    Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

    Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.

    3.6 Страницы с описанием

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

    Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

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

    Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

    Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
    Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.

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

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

    3.7 Требования к надежности

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

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

    3.8 Требования к хостингу

    Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают. у меня другого хостинга нет, надо переделывать на PHP».

    Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.

    Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

    3.9 Наполнение контентом

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

    Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.

    Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

    3.10 Сдача и приемка

    Описание тех условий, при наступлении которых должен состояться расчет за работу.

    Возможны варианты, например, перенос на хостинг заказчика после 100% оплаты. Или же оплата после переноса на сайт заказчика плюс неделя на обкатку.

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

    Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.

    Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

    Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.

    Другие публикации:

    • Кто может дать доверенность на получение документов Правила оформления доверенности на получение пенсии? Ситуация, когда в день выплаты пенсии банки и почта ломились от очередей, постепенно уходит в прошлое. Сегодня пенсионеры могут получать свои деньги на банковскую карту, а в некоторых […]
    • Как оформить библиографию в диссертации Как оформить библиографию в диссертации Аспирантура.РФ Аспирантуры. Обучение в аспирантуре и защита диссертации. Далее--> Что такое аспирантура Обучение в аспирантуре. Очная, заочная аспирантуры. Далее--> Аспирантуры Москвы и […]
    • Нотариус в киеве на подоле частный нотариус Матвеев Владимир Адольфович Киев, Подол, ул. Почайнинская 53/55 консультация нотариуса Банковские платежи за услуги нотариуса не выходя из нотариальной конторы! Матвеев Владимир Адольфович частный нотариус […]
    • Трудовой договор образец в формате word Рабочие места в вашем городе Закройте вакансии, расскажите о фирме, продвиньте товары или услуги вашей компании. Оформите подписку на новые вакансии или резюме и получайте актуальные объявления на e-mail. Трудовой договор Образцы […]
    • Образец заявления в ук по порядку начисления платы за общедомовые нужды Как проверить правильность начисления платы за ОДН? В 2012 году Россия перешла на новые правила предоставления коммунальных услуг. С июня наличие в домах индивидуальных счетчиков вовсе не отменяет необходимости оплачивать общедомовой […]
    • Договор по сбору денежных средств Агентский договор по сбору средств для благотворительных и некоммерческих организаций Имеется такой расклад. Сейчас собираемся запустить краудфандинговую платформу суть которой такова: - благотворительные и некоммерческие организации […]
    Как составить требования к сайту