Category: архитектура

Category was added automatically. Read all entries about "архитектура".

alexander pavlyut

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

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



NOTE: В жж верстка просто какой ад и израиль - нет желания с ней бороться, жж использую как хранилище черновиков. Нормально прочитать и обсудить можно у меня в фейсбуке - https://www.facebook.com/notes/alexander-pavlyut/как-проектируется-полезный-сайт-или-система-гид-для-чайников-или-как-уволить-сво/10205278553112242


Как я делаю архитектурное описание проекта - или в средневековом простолюдье “техническое задание”.

У системы есть назначение (функция) - что она выдает окружающий мир своим существованием.

У системы есть архитектура которая реализует это назначение.

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

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

Дальше мы подходим к кажой странице как к системе - у нее есть назначение (то что выходит внаружу) и как она это делает (архитектура внутри).

У каждой страницы есть два вида целей (логистики информации) - выдача или получение.

1. Выдача информации (не просто показать, а достчичь пользу в голове читающего) - как достичь - выполнить пункты по раскрытию : как? почему? для чего? цена? как получить? сколько стоит? почему доверять? кто вы такие? примеры в контексте моей проблемы? статьи? видеозаписи?
2. Получение информации от пользователя. Тут все про формы и прочие кнопки воздействия на сайт.

Цели эти живут часто вместе.

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

Элементы отранжированы по важности - самый важный большой и первый (заголовок, суть), потом поменьше (подзаголовок и картинка) и поменьше.

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

Задаем себе вопрос - какой информацией находящейся в элементе мы выполним это назначение?

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

Если все хорошо - переходим к технической части сайта.

Из чего состоит элемент - опись под ключ: форматы, размеры, цвета, слова, фразы, картинки, размеры - все под точные измеримые параметры.

Отвечаем на вопрос - что делать дальше с элементом - как информация этого элемента должна оказаться на странице?

Как часто эта информация планируется изменяться на сайте?

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

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

Если есть понимание что это нужно добавлять на сайт менеджером - нужно описать сценарий добавления / удаления / изменения / публикации / снятия с публикации / классификации (категоризации) этого элемента.

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

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

На каждом экране описываются следующие сценарии поведения:

1. Планируемое движение по информации - оно должно быть логично, просто и комфортно - результат должен быть удовлетворение ответа на искомый вопрос (назначение информационной страницы).

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

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

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

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

Одна страница - одна цель для пользователя.

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

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

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

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

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

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

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

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

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



http://www.pavlyut.com/cases/artefactor
alexander pavlyut

Требования к создаваемой системе. Практическое руководство по инжинирингу требований (черновичек).

Управление требованиями - это логистка требований.

Многие считают что управление требованиями это и есть процесс выявления требований. Нет это не так.

Требования выявляются как-то кратко если то вот:

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

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

  3. Потом каждую их этих нужд надо отметить "тегом" или меткой чтобы после отработать по теме.

  4. После по каждому тегу или метке записать все хотелки в простом формате: Я хочу _хотелку_ для того чтобы _получаемая_польза_через_хотелку_ и я вижу решение (хочу чтобы были розовые кнопочки) этого так _возможное_видение_решения_.

  5. Финальный список даем таких "требований" (система должна ДЕЛАТЬ) и ограничений (система должна делать это ТАК) - это и есть требования.


На требования пишутся уже решения, или то что назвается Техническое задание в производство.

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

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

  1. Единичность — требование описывает одну и только одну вещь.

  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

  3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

  4. Атомарность — требование нельзя разделить на более мелкие.

  5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.

  6. Актуальность — требование не стало устаревшим с течением времени.

  7. Выполнимость — требование может быть реализовано в рамках проекта.

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

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

  10. Проверяемость — реализованность требования может быть проверена.

Мы пишем требования в формате JobStory:
Находясь в __контексте_ситуации-context__ (под воздействием _внешней_принуждающей_силы__) я как __стейкхолдер__ хочу что-то сделать с система имела  __возможность_как_требование__, для того чтобы сбылась моя _хотелка-userneed__.
Необходимо указать артефакт-обоснование что данное требование решит потребность.
В результате составленного списка требований мы извлекаем стейкхолдера и модели данных, которые точно так же подшиваются к требованию, а так-же извлечение алгоритма (критичного для клиента правила поведения).
На основании данной информации мы составляем базовые последовательности - воздействия пользователя в месте входа - выдача от системы в месте выхода.
После этого хотелка считается отработана и закрывается - от нее остаются только требования.
После того как у нас извлечено большинство требований мы спокойно переходим к построению архитектурного описания.
Итак, начнем с того что архитектура решения есть всегда.
Для того чтобы сделать хорошую архитектуру - необходимо иметь знания о различных видах архитектуры, и поддерживать навыки их создания и эксплуатации, чтобы "мочь" хотя бы их повторить, а тем более описать.
Также нужно использовать ТРИЗ для поиска наилучших архитектурных решений.
Архитектура системы задается интерфейсами - страницы, элементы, кнопки. Вот как раз на языке этой архитектуры описывается решение.
На архитектуру навешивается взаимодейсвтие с системой по сценариям в деталях. UseCases.
Это и есть контрольная конфигурация выпуска.
Рабочая документация - это и есть то самое Техническое Задание которое нужно реализовать, оно состоит из сценариев, экранов, структур данных, и тд.

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