В новом подкасте №468 Николай Шмичков и Алексей Подлипный рассказали про NFR или нефункциональные требования — что это и зачем нужно (даже сеошнику).
Текстовая версия выступления:
“Всем привет.
Вы слушайте подкасты, и смотрите подкасты на канале SEOquick.
Меня зовут Николай Шмичков.
В гостях Алексей Подлипный.
Привет.
Привет.
И сегодня тема нашего разговора – это NFR, или нефункциональные требования, и что это, из-за чего нужно даже сеошнику.
Ну и собственно эта аббревиатура на самом деле меня немного даже заинтриговала и заставила погуглить.
А почему?
Потому что никогда не сталкивался с этим методом номенклатуры, вообще, что это за особые виды требований.
В чём разница между функциональными и нефункциональными требованиями, и что нужно прописывать обычно в нефункциональных требованиях NFR заданиях?
И собственно Алексей делал на эту тему большой доклад, и конечно же поделится самыми важными тезисными мыслями, которые вам нужно знать.
Ещё раз всех приветствую.
Как уже сказал Николай, меня зовут Алексей Подлипный.
Я занимаюсь веб-разработкой, по сути ответственный за наш сайт, всё что с ним происходит, интеграция, в общем все, что касается веб-разработки.
На счет темы доклада, тут наверное имеет смысл в несколько слоёв развернуть эту тему.
На самом деле она действительно очень такая серьезная и объемная, но мы сегодня пройдемся по потому, что будет полезно, например, владельцам сайтов, просто практикующим сеошникам.
Просто нужно этот момент всегда держать в уме, даже не обязательно досконально в нем разбираться, но важно понимать что это такое.
И так, если упрощать и вообще в одном предложении писать, что это такое, то по сути, это ответ на вопрос “Как?”.
То есть, всё то, что ставится, например, в ТЗ на разработку, в ТЗ на SEO-оптимизацию, там технички, по сути, как правило ограничивается именно функциональными требованиями.
То есть, какая разметка должна быть размещена на страницах, какие принципы генерации Title, ТЗ на контент, на тексты, какие картинки должны быть.
Это всё ответ на вопрос “Что?”.
И, к сожалению, часто этим и ограничиваются.
На самом деле это уже тоже не так плохо, это, скажем так, второй уровень того, как может быть.
Первый уровень – это просто сделайте хорошо, не знаю как.
Второй уровень – это, по крайней мере, люди понимают, что им нужно сделать.
То есть там: нам нужны такие вот Title, нам нужна такая-то микроразметка, картинки должны быть таких типов, и все такое.
Это уже неплохо, это уже продвинутый уровень.
Но, для того, чтобы всё было действительно хорошо и правильно, нужно дойти до третьего уровня, до NFR и до ответа на вопросы “Как?”.
Всё.
Это, скажем так, вводная информация.
А теперь попробуем расшифровать глубже о каких “Как?” идет речь.
Самое простое, что нужно понимать, на самом деле основных NFR есть 14.
Но, по крайней мере, в той доктрине, которую я изучал, их 14.
Сейчас перечислять всё не буду, это по сути 7 основных групп.
Первое – это доступность и надежность.
То есть, ну естественно, все должны прекрасно понимать, если у вас идеально с технической точки зрения оптимизированная страница, на ней есть все необходимые элементы, атрибуты, все прекрасно.
Но посещают её googlebot и, например, эту страницу уже посещают ещё два клиента одновременно, и в принципе сервер начинает отвечать медленно, а посещает ещё там два человека или вы, например, запустили крутую акцию, на нее пришло 20 человек сразу, и сервер вообще лёг.
Ну всем, наверное, понятно, что никакая техническая оптимизация не перекрывает того, что страница отдает все.
Поэтому помимо того, чтобы сделать хорошо именно функционалу, оно должно еще открываться, оно должно быть, стрессоустойчивое, доступное, надежное.
Это, скажем так, самое первое, самое основное.
Что ещё может быть?
Ну, не достаточно просто там купить самый дорогой сервак и типа заходите все, кто хочет, потому что нужно учитывать еще такой фактор как безопасность.
То есть даже самый мощный там сервер, если не стоит никакой защиты, например, на количество запросов с одного IP адреса, то в принципе можно положить даже самый мощный сервер, если, например, у вашего конкурента есть такая потребность, есть такое желание.
Поэтому это уже как-бы следующий уровень.
Кроме того, чтобы просто выдерживать там любой адекватный наплыв, нужно уметь выдерживать и любой неадекватный наплыв.
То есть какие-то системы защиты есть.
На самом деле сейчас это несложно, для этого не нужно нанимать там отдельного эксперта по безопасности, потому что, ну разумеется, если у вас там какой-то небольшой сайт, у вас попросту может не быть бюджета на это.
В этом нет необходимости, есть решения достаточно простые и подключаемые даже без разработчиков, самый широко известный в этом смысле это CloudFlare.
То есть вы просто переключайте свой сайт на CloudFlare, и там уже внутри его кабинета манипулируете настройками.
То есть, можно даже там на самых стандартных, в принципе, оставаться, их тоже будет достаточно.
То есть, все нормальные пользователи будут получать адекватные веб-страницы, если же произойдет какая-то атака, то с большой вероятностью CloudFlare её самостоятельно заблокирует, и не вы, не другие нормальные пользователи этого даже не заметят.
Только потом в логах собственного дашбордов самого CloudFlare вы это можете увидеть.
Это тоже важно учитывать.
Что еще важно учитывать?
Следующий такой важный не функциональный момент – это поддержка и сопровождение.
Приведу пример, как это использовать, или там какие-то готовые решения, или cms, либо делать что-то своё.
Своё почти всегда выигрывает, ну как бы в соответствие ожиданиям и конкретным потребностям, то есть почти никогда там готова cms-ка не будет соответствовать на 100% тому, чего вы хотите, что вы там себе представили, на визуализировали.
Но поддерживать свою систему – это отдельная, скажем так, задачка.
То есть вам нужно держать профильного разработчика, который, ну в идеале, тот, который писал решение, но тоже это не всегда возможно, люди уходят, болеют, по любым причинам могут исчезнуть из вашего проекта, и вы уже находитесь после этого в кандалах.
Вам нужно найти такого же по скилам, по стеку разработчика, чтобы хотя бы просто даже поддерживать.
И тут возникает еще конечно сразу проблема, так сказать, легаси кода, когда новый программист почти всегда недоволен тем, что делал старый, начинают копаться в коде, говорить “Кто вам это написал? Надо ему руки оторвать”, и вот это извечная штука.
Хотя на самом деле это далеко не всегда отражает реальную ситуацию, но это норма.
Поэтому очень-очень взвешенно нужно подходить к выбору технологий, и заглядывать немножко вперёд, немножко в будущее с мыслей о том, что это всё нужно будет поддерживать, это всё нужно будет обновлять, апгрейдить, подключать какие-то дополнительные интеграции модулей, поэтому нужно думать наперед.
Я не буду говорить тут, что лучше, cms-ки или самописы, реально это вопрос каждого отдельно взятого случая.
Но каждый может, скорее всего, правильно на него ответить, если действительно проанализирует, что будет, какие планы через год, какие планы через 2 года, если они вообще есть, и соответственно подобрать что-то оптимальное.
Получается фактически, вот есть функциональные требования, и есть нефункциональные.
Функциональные требования – это то, что мы, допустим, ставим задачу разработчикам, как оно должно работать.
Правильно?
То есть, вот конкретные задачи, что нужно делать.
Да, конкретные функции, что должно на странице быть.
А нефункциональные требования – это, фактически, требования, которые должны обеспечить, что то, что внедрится, будет стабильно, то, что не сломается, не собьется и, желательно, фактическимим функциональным требованиям вводится там классические задачи по логированию.
Правильно?
Я правильно понял?
По бекам, то есть какие-то вещи, то есть они обычно попадают.
Или я неправильно понял?
Ну в целом да.
То есть, можно просто выполнить задание, и клиент его открывает, эту страничку, и всё, она отлично работает, для него одного сейчас.
Но потом мы её как-бы релизим и начинаются проблемы: она там недоступна из какой-то страны, потому что там, не знаю, хостинг заблокирован, она там падает при небольшом количестве посетителей, ну в общем любые могут проблемы возникать.
То есть, вот это всё обеспечение качества.
То есть, просто сделать услугу – это одно, а так, чтобы она ещё работала, поддерживала.
Ну, а этот случай, когда ты пилишь плагин, допустим, под подкасты, например, да, и просто вот я сделал, вот работает.
А когда ты запилил к нему ещё и мануал, блок логирования, блок бекапов, которые изначально не задумывались, какой-то информационный раздел, справку даже, где, что подписано, как оно должно находится, хотя оно не было так изначально задумано.
Это можно тоже практически отнести в эту рубрику?
Да, это, буквально, одно из следующих требований, о которых я хотел сказать.
Дальше – это не для всех может быть актуально, но есть такой момент, как, например, сертификация и соответствие.
Тут тоже, вы сделали, например, прекрасный интернет-магазин, он там и доступен, и всё круто, сеошка пошла, но потом у Вас, например, возникла задача подключить его, допустим, к Розетке, или к любому другому маркетплейсу, где требуется, например, там выгрузка в соответствующем формате xml.
Вы этого не предусмотрели, и всё, вам нужно теперь тратить время на то, чтобы подключать какое-то стороннее решение, или писать самим эту доработку.
То есть, просто делая даже какой-то функционал, надо задумываться, к чему он может быть подключен впоследствии.
Вот например, моему клиенту нужно сделать сейчас (это как раз тема нашего следующего подкаста про парсинг), и вот ему нужно создать интернет-магазин по автозапчастям, но автозапчастям не обычным, а которые продаются в Польше, вот эти всевозможные разборки.
То есть, когда разбирают автомобиль на запчасти и вот эти бэушные запчасти активно в Украине покупаются.
Ему нужно поставить задачу по созданию этих карточек товаров.
Я со своей стороны выкинул только технические требования, которые однозначно нужны будут по сеошки, то есть требования мерчанта, требования гугла, требования микроразметки, то есть весь контент, который ему нужно парсить.
Но, это я выбросил, как сегодняшних, но я же ещё понимаю, что ему нужно интегрировать удобный интерфейс по редактированию, удобный интерфейс по загрузки картинок, удобный интерфейс по сжатию картинок, внутренний, который должен быть, по обработке, по подписыванию всего контента.
И фактически вот это оно ж то мне не нужно, оно находится в бэкенде, и фактически даже я уверен, что какие-то вещи бэкенда тоже нужно грамотно уметь прописывать.
Если ему это не реализуют, фактически, это будет не выполнено вот эти NFR.
Правильно я понимаю?
Да.
Какие ещё есть моменты?
Мы даже, наверное, не будем проходится по всем, только то, что действительно касается сеошки, просто вебмастеров.
Дальше такой момент, как совместимость и портируемость.
То есть, мы открыли на своем последнем браузере Chrome, на обычной какой-нибудь 10 винде сайт, и тоже посмотрели, чтобы всё в порядке, заплатили разработчику деньги, довольные ушли.
Мы не проверили работает ли он на Windows 7, где уже по-другому работают сертификаты безопасности, как он работает на Маке, на Линуксе, на Windows XP…
То есть, очень простые моменты.
Ну, или то, что, наверняка, все знают – это просто даже адаптивность для мобильных устройств.
Ну, очевидный момент, но это тоже NFR.
То есть, кроме того, что функционал должен работать, он должен адекватно работать на 768 планшете, на 320 мобильной верстке, и вот это вот всё.
И самое главное, уметь масштабироваться, уметь грамотно включать режим чтения на нужных элементах, если это необходимо и тому подобное.
На самом деле тема очень интересная.
Если будет очень много лайков, ребята, от вас все зависит, мы будем разжевывать эту тему в следующих подкастах.
Ещё буквально пару моментов могу рассказать.
Например, сам с этим сталкивался когда-то.
Это – локализируемость, то есть иногда, создавая сайт, например, мы не задумываемся вообще о том, что когда-то он может нам понадобится ещё и в другой стране, на другом языке.
И если самые базовые требования к этому не предусмотреть сначала, то впоследствии навернуть мультиязычность уже может быть или сложно, или даже невозможно, просто придётся какие-то делать костыли, делать второй сайт точно такой же, но для другого языка.
Но на самом деле это достаточно просто предусматривать еще на этапе разработки.
То есть, вам не обязательно внедрять сразу больше, чем один язык, но предусмотреть, чтобы не была жесткой завязке, ну чтобы были, так если просто сказать, вместо харт кода должны внедряться переменные, и пускай у них пока будет только одно состояние там ru.
Но впоследствии вы сможете спокойно для этой переменной внедрить дополнительное локалии и соответственно сделать сайт мультиязычный.
Владельцам сайтов Украины сейчас куда проще.
Самый популярный язык по статистике на Востоке русский сейчас, на Западе становится популярным украинский.
Поэтому сейчас все сразу делают две версии.
Они будут более подготовлены, чем россияне, которые все делают только на одном языке.
Этот момент уже сейчас учитывают изначально все вот разработчики в Украине, кстати, я считаю, что более подкованные разрабы, чем в России, я с этим сталкиваюсь каждый день.
Украинские разработчики более подкованные и знаю про эти нюансы.
Ребята, рад, что вы дослушали эту тему до конца.
В следующих подкастах мы еще даже подискутируем, поэтому оставайтесь с нами, не забывайте подписываться на нас.
Всем Пока Пока.”
