Разные виды требований отражают разные точки зрения на продукт:

  • Бизнес-требования — взгляд на систему со стороны заказчика / спонсора.
  • Пользовательские — точку зрения пользователей.
  • Системные (по Вигерсу — «функциональные») — взгляд со стороны разработчиков (в широком смысле).

«Функциональные» требования во втором значении (левая сторона картинки с видами требований в первом издании Вигерса) — это довольно искусственная попытка нарезать продукт на>>>

(Показать весь текст)

Разные виды требований отражают разные точки зрения на продукт:

  • Бизнес-требования — взгляд на систему со стороны заказчика / спонсора.
  • Пользовательские — точку зрения пользователей.
  • Системные (по Вигерсу — «функциональные») — взгляд со стороны разработчиков (в широком смысле).

«Функциональные» требования во втором значении (левая сторона картинки с видами требований в первом издании Вигерса) — это довольно искусственная попытка нарезать продукт на отдельные функции.

Из-за этой искусственности возник уродливый термин «нефункциональные требования».

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

Но было поздно, метастазы уже пошли — в русском переводе книга Коберна «Writing Effective Use Cases» называется «Современные методы описания функциональных требований к системам» (очевидно, выпендрился научный редактор). И здесь под «функциональными требованиями» понимаются требования всех трёх уровней.

Законы, которые нужно учитывать при создании сайтов

Закон Для каких сайтов

Федеральный закон "О персональных данных" от 27.07.2006 N 152-ФЗ

http://www.consultant.ru/document/cons_doc_LAW_61801/

Для всех сайтов, хранящих персональные данные пользователей

Федеральный закон "О применении контрольно-кассовой техники при осуществлении расчетов в Российской Федерации" от 22.05.2003 N 54-ФЗ

http://www.consultant.ru/document/cons_doc_LAW_42359/>>>

(Показать весь текст)

Законы, которые нужно учитывать при создании сайтов

Закон Для каких сайтов

Федеральный закон "О персональных данных" от 27.07.2006 N 152-ФЗ

http://www.consultant.ru/document/cons_doc_LAW_61801/

Для всех сайтов, хранящих персональные данные пользователей

Федеральный закон "О применении контрольно-кассовой техники при осуществлении расчетов в Российской Федерации" от 22.05.2003 N 54-ФЗ

http://www.consultant.ru/document/cons_doc_LAW_42359/

Для сайтов, принимающих оплату

Правила продажи товаров дистанционным способом, утверждённые Постановлением Правительства РФ от 27.09.2007 N 612

http://www.consultant.ru/document/cons_doc_LAW_71418/

Для сайтов интернет-магазинов

Закон РФ от 07.02.1992 N 2300-1 (ред. от 24.04.2020) "О защите прав потребителей"

(статья 26.1 «Дистанционный способ продажи товара»)

http://www.consultant.ru/document/cons_doc_LAW_305/

Для сайтов интернет-магазинов

Федеральный закон "О рекламе" от 13.03.2006 N 38-ФЗ

(Статья 8. Реклама товаров при дистанционном способе их продажи)

http://www.consultant.ru/document/cons_doc_LAW_58968/

Для сайтов интернет-магазинов

Расскажу, как я познакомился с жизненным циклом АСУ по ГОСТу.

В 1980 году Совет министров СССР принял решение о разработке одной автоматизированной системы управления для военно-воздушных сил. Это было ещё при товарище Брежневе.

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

Время шло, я>>>

(Показать весь текст)

Расскажу, как я познакомился с жизненным циклом АСУ по ГОСТу.

В 1980 году Совет министров СССР принял решение о разработке одной автоматизированной системы управления для военно-воздушных сил. Это было ещё при товарище Брежневе.

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

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

Страна тоже не стояла на месте. Товарища Брежнева сменил товарищ Черненко, которого сменил товарищ Андропов, которого сменил товарищ Горбачёв, который объявил перестройку, гласность, новое мышление и борьбу с алкоголизмом.

Пришёл 1987 год. Я окончил школу. И как раз к этом году несколько крупных НИИ авиационной промышленности совместно с ВВС наконец разработали и согласовали Техническое задание на ту самую автоматизированную систему, решение о разработке которой было принято Советом министров СССР в 1980 году. Но я по-прежнему об этом не знал, да и не мог знать, потому что только что поступил в военное авиационное инженерное училище, на специальность «математическое обеспечение автоматизированных систем управления».

Время шло дальше. Я успел изучить архитектуру и язык ассемблера «больших» ЕС ЭВМ (советских клонов IBM/360), на смену которым внезапно пришли IBM PC, архитектуру и ассемблер которых тоже пришлось изучить. Женился, родилась дочка, заработал первые деньги в «левом» коммерческом проекте.

В 1992 году я выпустился из военного училища и молодым лейтенантом прибыл служить в Научно-испытательный институт ВВС. И вот тогда, наконец, узнал о проекте той самой АСУ, решение о разработке которой было принято в 1980 году Советом министров несуществующего уже СССР. К этом моменту группа НИИ авиационной промышленности как раз закончила разработку эскизного проекта и приступила к разработке технического проекта — то есть, собственно, к созданию системы.

Если вы подумали, что система существовала только на бумаге, то вы ошибаетесь. НИИ, отвечающий за её разработку, даже начал писать код! В отделении из нескольких десятков человек была одна женщина-программист (тогда уже пенсионного возраста). Она как раз осваивала новомодный тогда язык C++, и решила (довольно справедливо), что это язык гораздо лучше подходит для разработки новой системы, чем указанный в ТЗ Фортран. А остальные сотрудники отделения занялись разработкой и согласованием этого изменения в ТЗ.

Кстати, именно тогда я проникся мудростью людей, причисливших первый советский клон IBM PC к семейству Единой серии ЭВМ, назначив ему индекс ЕС-1840. Персоналки к тому времени уже окончательно вытеснили «большие» ЕС ЭВМ, которые гнили нераспакованными по всем НИИ бывшего Советского Союза. Но ТЗ в этой части менять было не нужно! В нём было указано, что АСУ должно использовать ЭВМ Единой серии как основу технического обеспечения.

В 1998 году я поступил в адъюнктуру Военно-воздушной инженерной академии имени Жуковского и уехал в Москву. Адъюнктуру я через год бросил, уволившись из армии, и началась у меня совсем другая жизнь. Поэтому я так и не знаю, чем закончилась история с этой АСУ, решение о разработке которой было принято Советом министров СССР в 1980 году.

Но, возможно, и теперь, спустя 40 лет, она продолжает кормить целые институты авиационной промышленности.

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

Как научить разработчиков фронтенда проявлять эмпатию.

Заведите в команде девочку-юзабилиста, все обязанности которой будут сводиться к одному: смотреть на разработанный ими UI и плакать.

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

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

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

В процессе разработки ПО главное – это организация взаимодействия людей.

Смиритесь и живите с этим.

Чтобы разработчики принимали правильные решения, влияющие на качество, им, во-первых, в принципе должно быть дано право принятия решений. А во-вторых, им нужно давать самый широкий контекст для принятия таких решений. То есть они должны не получать набор уже пережёванных архитекторами, аналитиками и менеджерами «тасков» в трекере, а активно участвовать в  проектировании, начиная с самых ранних стадий.
Искусственно созданными >>>

(Показать весь текст)

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

Важнейшими в работе аналитика являются два правила. Вот они.

Правило первое. Программные продукты создаются (пока ещё) для людей.

Правило второе. Программные продукты создаются (пока ещё) людьми.

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


Если продукт создаётся для людей, значит, нужно выявить этих людей, и >>>

(Показать весь текст)

Важнейшими в работе аналитика являются два правила. Вот они.

Правило первое. Программные продукты создаются (пока ещё) для людей.

Правило второе. Программные продукты создаются (пока ещё) людьми.

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


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

Нет выявленного интереса — нет требования.

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


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

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

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


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

Деление на бизнес-аналитиков и системных аналитиков уже не модно. Теперь в тренде универсалы: Buisness, Data, System and Market Analysts. Или, сокращённо, BDSM Analysts.

Как быстро послать заказчика на три буквы?

Очень просто: «Мы сделаем вам выгрузку в CSV».