КОЛОНКИ · 31 августа 2016, 16:33 · alexander.panfilenok
Бизнес-аналитики будущего

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

Фото: William Iven via Unsplash

Статус-кво

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

В 1999 году в своей книге «Бизнес со скоростью мысли» основатель компании Microsoft Билл Гейтс описывал «электронную нервную систему» организаций. Он считал, что программное обеспечение позволит организациям моментально реагировать на изменения состояния рынка, а в эпоху цифровых технологий без этого конкурентного преимущества не будут возможны ни рост, ни выживание организации вообще. Сейчас можно с уверенностью утверждать, что его предположение оказалось верным и те, кто осознал и принял этот факт, так или иначе нуждаются в специализированном ПО. В некоторых случаях можно обойтись готовыми решениями (например, такими как 1С), но чаще конкретному бизнесу нужно программное обеспечение, разработанное специально для него.

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

Во-первых, разработать нечто способное конкурировать с уже успешно существующими решениями в плане технической сложности — нетривиальная задача. А во-вторых, владеть достаточным количеством знаний одновременно во всех областях, влияющих на успешность цифрового продукта, невозможно. Для решения этих проблем принято формировать команды разработки. В таких командах существуют узкоспециализированные роли, такие как специалист по обеспечению качества (Quality Assurance, QA), специалист по поисковой оптимизации (Search Engine Optimization, SEO), графический дизайнер, специалист по вёрстке, специалист по продажам, менеджер проекта, программисты, которые обычно специализируются на определённом направлении и стеке технологий и многие другие.

Такое разделение на роли является достаточно условным. Бывает так, что программист может справиться с задачами по вёрстке, потому что ему часто приходится вносить небольшие правки в шаблоны веб-страниц, Или QA начинает программировать, потому что он учится этому в процессе работы с автоматизированными тестами. Подобных схем довольно много.

Ещё один неотъемлемый участник проекта — бизнес-аналитик (Business Analyst, BA). Он является своего рода специалистом «по связям с общественностью», основная задача которого заключается в анализе запросов заказчика и составление функциональных требований, необходимых программистам для работы.

Проблема: аналитик как промежуточное звено

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

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

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

Проблема №1: Бизнес-цели заказчика перемешиваются с другими целями.

И тут в игру вступает бизнес-аналитик. Что он делает:

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

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

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

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

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

Фото: Jonathan Simcoe via Unsplash

Когда экспертиза субъективна

Если разобраться, знания, которыми обладает бизнес-аналитик в рамках конкретного проекта, сильно ограничены.

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

Проблема №2: Основаниями для функциональных требований является мнение заказчика.

Результат

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

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

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

Если проект представляет собой коммерческий продукт, пользователи просто уйдут к конкуренту.

Решение: проектировщики взаимодействия

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

Вот чем занимается этот специалист.

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

Фото: Benjamin Child via Unsplash

Бизнес-аналитики — завтрашние проектировщики взаимодействия

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

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

Уже сейчас встречаются проекты, на 80% состоящие из исследований и на 20% из процесса разработки. Крупные компании, имеющие опыт сотрудничества с разработчиками ПО, для заключения новых контрактов на разработку объявляют тендер, который выглядит примерно так: «Вот у нас форма пожертвований, сделайте что-нибудь, чтобы повысить конверсию». Чёткая бизнес-цель, никаких «нарисуйте собачку или цветочек». Таких проектов со временем станет всё больше, а за крупными компаниями, поступающими таким образом, подтянутся и другие.

Как быть с графическими дизайнерами?

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

Фото: Jeff Sheldon via Unsplash

Что могут сделать остальные?

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

  • какую пользу это принесёт бизнесу;
  • какую пользу это принесёт пользователям.

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

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

Например:

Как зарегистрированный пользователь

для того, чтобы чувствовать контроль над своим лицевым счётом,

я хочу видеть остаток своего лицевого счёта.

----------------------------------------------------------------------------------------

Допустим, в системе существует пользователь «Вася Петров».

А также я выполнил вход в систему как «Вася Петров».

Когда я перехожу на страницу «Состояние лицевого счёта»,

тогда я вижу остаток своего лицевого счёта.

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

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

Что почитать?

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

 

 

*Мнение колумнистов может не совпадать с позицией редакции.

Источник: dev.by
Новые комментарии

Обсуждение

Picture_432?1356409809
+2

Какой категоричный тон. Можно я не буду писать требования на языке Gherkin? Пожалуйста...

Missing

Пример в статье похож, скорее, на user story, а не на пример этого Геркина по ссылке. Что-то намудрил автор.

Missing
-1

Кстати, кто-нибудь ищет хорошего системного/бизнес-аналитика?

Picture_432?1356409809
+5

У меня к автору вопросы

1. В скольких проектах вы использовали Gherkin?

2. Сколько сценариев на этом языке вы написали?

3. Вы используете BDD? Если да, то сколько тестов реально работает?

Missing-male
+2

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

Missing-male
+3

1) 4

2) на последнем проекте мы написали около 150 таких тестов

3) Нет не используем BDD в классическом понимании. Используем геркин как описание задач в JIRA (заказчик пытается это делать с переменным успехом) и как системные\интеграционные тесты. На данный момент я не могу точно сказать, сколько из них зелёные, потому что они являются частью инструмента ручного тестирования.

Picture_432?1356409809
+1

Спасибо. Не поймите меня неправильно. У меня сложилось ощущение, что вы недавно в этой теме и очень радостно делитесь своими находками с другими. Это хорошо, потому что вообще статьи у нас мало кто пишет, а чтобы научиться писать, нужно писать. Я просто хочу сказать, что мне лично статья показалась несколько категоричной и недостаточно развернутой. А если вы уж хотите быть категоричным (что вполне нормально в целом), то нужно приводить красочные истории из собственного опыта, опыта других, статистику, графики там всякие и рисунки. Очень круто, если вы сделаете это сами. Любая картинка из клипарта снижает качество статьи на 10%.

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

Missing-male
+2

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

Picture_432?1356409809

Я не уверен, что "зарегистрированный пользователь" рассказывает нам что-то о пользователе. Вопросы, конечно правильные, задавать их нужно. Не стоит просто переоценивать полезность сценариев в формате BDD

Missing-male
+3

Михаил. Вы правы. "Заругистрированный пользователь" почти ничего не говорит. Но статья не вместила бы концепцию персонажей, описанную Аланом Купером, которая идеально стыкуется со сценариями на Gherkin. Если использовать концепции персонажей то сценарии будут звучать так:

Как Джо Трибиани

Для того, чтобы чувствовать контроль над своим счётом,

Я хочу видеть остаток своего лицевого счёта.

Причём кто такой Джо и почему он хочет чувствовать контроль над лицевым счётом и почему это ему важно - часть описания персонажа и его поведенческих характеристик.

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

Missing
+5

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

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

Missing-male

Нет. Этого не достаточно.

Missing
+1

Таки соглашусь, еще такой человек должен быть коммуникабельным...

C98442cb204054585617eaf3011b6079?1504985146

В идеале, аналитик соберет требования, нарисует UI, все сам закодит и выкатит на прод :D

Missing-male

В идеале, бизнес аналитика в вашем понимании вообще не должно быть на проекте.

Missing

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

Missing-male
+1

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

Missing-male

вполне адекватная статья (для идеального, правильного мира). правда в личном опыте, со стороны пользователя чаще всего сталкивался:

-- пользователь не знает, что он хочет

-- пользователь не хочет думать о том, что он хочет

со стороны исполнителя (менеджмент под видом бизнес аналитиков):

-- принятие всех желаний пользователя как отче наш, без какой либо аналитической переработки.

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

Missing

1С это не готовое решение

Missing
+3

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

Чито мешает подключить сюда мнение программиста? Ах да, наверное, программист - это человек, который просто программирует, и важность его очень условна.

Тогда мнение пользователя? Ах да, пользователь - это человек, который просто пользуется приложением. И важность его очень условна.

Тут, наверное, либо заказчик идиот. Либо бизнес-аналитик не умеет быть убедительным. Умеют же люди впарить никому не нужные кастрюли, пылесосы, дорогущие фильтры. Мот, и бизнес-аналитику надо чему-то подучиться :)

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

Таладнааа. Бизнес-аналитика в гугле забанили? Он никак прокачаться в области не может? Кроме как ждать, пока ему разжуют и в рот положат? Интересно, до пенсии дождётся? :)

> Решение: проектировщики взаимодействия

Если это решение, то мот не стоит придумывать новое слово, а отправить тех, кто выше в статье называется "бизнес-аналитиком" на курсы повышения квалификации? :)

> Действительно, графические дизайнеры (веб-дизайнеры или просто дизайнеры), за годы работы эмпирически освоили многие аспекты пользовательского взаимодействия и могут «нарисовать красиво и удобно». Однако, их навыки имеют эмпирический, а не теоретический базис

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

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

> В идеале, функциональные требования должны быть изложены на языке Gherkin

Ух ты. Тут не хватает каких-то аргументов в пользу такого утверждения. Не находите? :)

Запрос к гуглу "gherkin site:dev.by" выдаёт на удивление мало результатов для "идеала". :)

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

Хм. Так вы не аналитик? Тогда странно, что статья посвящена им. Мотивацию бы нам повидать. Можно и на языке Gherkin.

Итого:

спасибо за порыв.

но над формой изложения надо поработать.

Missing-male

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

Missing-male
Мікіта Бобчанка
– Бизнес-аналитик в УП «Софтвэр Секьюрити Системс»

+3

На мой погляд, аўтар прадставіў даволі аднабокі погляд на пытанне куды развівацца аналітыку і вось чаму:

На любым праэкце распрацоўкі праграмнага прадукта для канчатковых карыстальнікаў, ёсць пэўны набор роляў:

• Заказчык

• Праграміст

• Тэстоўнік

• Праэктны мэнэджэр

• Бізнес-аналітык

• Дызайнер

• UX-праектоўнік

І ў кожнай камендзе гэтыя ролі размяркоўваюцца па рознаму, у залежнасці ад памера каманды і стратэгіі кампанніі-распрацоўніка.

У маленькіх камандах могуць быць толькі праграмісты да тэстоўнікі. Аднак усе астатнія ролі будуць раскінуты на ўсіх чальцоў, такім чынам, што галоўны праграміст заадно і мэнэджэр праекта, ролю аналітыка выконваюць усе чальцы каманды на нарадах, калі абмяркоўваюць фічы, а ролю UX-праэктоўніка выконвае кожны з праграмістаў, у межах працы над сваёй задачай. Зразумела, што такія размазаныя ролі будуць выконвацца не якасана, але яны ўсёроўна, хучтэй за ўсё несвядома, будуць існаваць.

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

• Сістэмны аналітык

• Аналітык патрабаванняў

• Аналітык дадзеных

• І г.д.

А ў нашых рэаліях, у кампаніях сярэдняга памеру, часта аналітыкі ўжо ёсць, а UX-спецыялістаў яшчэ няма. Таму аналітыкі і спалучаюць выкананне гэтай ролі са своёй. Аднак, калі ў кампаніі UX-спецыяліст ёсць, то аналітык можа сумяшчаць ролю мэнэджэра, ці, што больш рэдка, быць чыстым аналітыкам.

Таму, супрацьпастаўляючы сваё меркаванне, меркаванню аўтара, я б сказаў, што ў аналітыкаў тры шляхі развіцця:

• UX-спецыяліст

• Праэктны мэнэджэр

• Бізнес аналітык высокага класу

І тут усё залежыць ад жадання самаго чалавека. Бо кожная з гэтых роляў важна пры распрацоўке праграм. Галоўнае не стаяць на месцы, а развівацца хоць у якім напрамку :)

Missing-male
-2

Спасибо за комментарий. Я не зря привёл ссылки на книги в конце статьи. Прочитав книгу Алана Купера вы поймёте, что программисты никогда не смогут выполнять роль проектировщиков взаимодействия в принципе, потому как они оперирует моделью реализации, а проектировщики - моделью представления с учётом ментальной модели пользователей. Прочитав книгу Расса Унгера, вы поймёте, что самый правильный путь для проектировщика обеспечить качество с точки зрения юзабилити - это быть в центре общения всех заинтересованных лиц, обсуждений разработчиков, постоянно следить за развитием проекта. Таким образом проектировщики должны выполнять все задачи, которые сейчас выполняют бизнес-аналитики а также имеют свой уникальный набор обязанностей.

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


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси