Ситуация
- На входе в студию стоит клиент (виртуально/реально не имеет значения).
- Клиент хочет у нас что-то заказать - систему, сайт, приложение, приложение, что угодно - что угодно, что можно разработать и даже потом скрестить бульдога с муравьедом, например (1С Битрикс, просто 1С, другие системы и наше развитие).
- Он присылает нам что-то (как мы это видим), называя это "цк" (как он это видит) и говорит - оцените/посчитайте/задайте вопросы и далее везде, ожидая в ответ, как правило, получить вполне конкретную точную цифру и срок (возьму для примера экстремальную клинику), когда она будет готова.
- Ожидающий.
Соглашение о терминологии
- Артефакт – это физическое представление в реальном мире чего-то, созданного человеком.
- Идея – это то, что в голове или головах клиента.
- Желания — это артефакт дизайна.
- Требования – это пожелания, соответствующие реальности.
- Физика среды — в случае с сайтом это все компоненты, из которых он может быть составлен по мнению консорциума w3c. В случае с мобильным приложением — это программа для разработчиков Apple или разработка для Android и т. д.
- Архитектурное решение — это устно сформулированное предложение по реализации требования, без использования элементов физики конечной среды (речь идет об экранах, речь не идет конкретно об экранах iPhone или Android).
- Техническое задание – подробная конфигурация строящейся системы с описанием свойств, характеристик назначения каждого элемента и узла, документ на производство, а также документ на приемочные испытания.
Мухи отдельно – котлеты отдельно.
Давайте очень кратко рассмотрим жизненный цикл любой идеи и ее воплощение в реальность:
- Идея (какая) -> хотелось бы вина
- Пожелания (сформулированные и записанные) -> послать гонца за бутылкой вина
- Требования (контрольная точка) -> Французское сухое красное
- Архитектурное решение -> будем потреблять дома из бутылок, а не наливать из бочки в ресторане.
- Техническое задание -> в магазине №5 купить 2 бутылки французского по 5 рублей каждая.
- Строительство (производство, исполнение) -> пошел купил принес принес показал
- Приемка (проверка) -> принята по запросу, при необходимости детали сверены с техническими характеристиками.
- Ввод в эксплуатацию -> открытие бутылок
- Эоперация -> разлейте по стаканам, употребите пользу.
- Идея (какая) -> Мне нужен суперсервис, который сможет выполнить эту работу
- Пожелания (сформулированы и записаны) -> нужен сервис, который сделает эту работу X, Y, Z
- Требования (контрольная точка) -> сервис должен выполнять X, Y и Z невозможно, если присутствуют X и Y, вместо этого давайте сделаем H. ХОРОШО.
- Архитектурное решение -> Сделаем X в виде страницы.
Y будет похоже на игру, а H будет на запрос через форму.
- Техническое описание -> Х 5 экранов (нарисовано), 24 элемента (отмечены, все данные описаны), назначение каждого (выход с работы), сценарии поведения для каждого (нажал увидел, выиграл), эксплуатирующие персонажи (менеджер, домохозяйка на iPad), результаты выполнения того-то и того-то (полученная информация, выполненное достижение, отправленное письмо, информация о товаре передана на сборку в складскую систему и т.д.)
- Строительство (производство, исполнение) -> кодирование, сборка, тестирование по заданию, запуск скриптов.
- Получение (проверка) -> развертывание (развертывание в производственной среде, магазине приложений, Amazon.)
- Ввод в эксплуатацию -> работы приняты, баннерная реклама, регистрация.
- Эработа -> сервис работает, конверсии растут, кэш поступает в кассу.
Кто кому и что должен?
Если говорить о том, что обычно может выразить клиент, то это всегда пожелания, даже некоторые из них (малая часть) - ведь неспециалист не может описать все желание просто по определению - это не его контекст, и он не должен его понимать..
Для наглядности я набросал одному из своих клиентов диаграмму жизненного цикла одного (!) требования и по сей день показываю ее, чтобы ответить на вопрос, что делать: 
Если у вас есть идея, вам нужно выкинуть ее из головы, чтобы начать работать — мы понимаем, чего хотим, и записываем.
Это пожелания.
Артефакты плана клиента – это может делать только клиент, план – это его часть работы.
Обычно идея оформляется в виде пожелания и ее отправляют по почте, ошибочно называя ее техническим заданием, а это даже не требования.
Клиент начинает выражать свои пожелания в любом формате – мы не рекомендуем в этот момент много рисовать и присылать огромные проекты – все равно все равно будут разрабатываться исходя из простого списка требований, а потому не стоит просто тратить время время на это.
На заметку хозяйке : ожидание, что какая-то фирма-подрядчик возьмется за производство без доработки вашего технического задания (если вдруг, например, есть проработанное техническое задание на детали - оно будет добавлено к ним в процесс) говорит только о качестве процесса в данном случае компания - если они могут так изменить ее снаружи, значит работают хаотично, на глазок.
Практика показывает, что в сложных (от слова сложение, сложный) проектах (а это любая разработка или внедрение любой бизнес-системы – от сайта компании до сложных внедрений нескольких систем) – это качество и отлаженность процесса реализации.
подрядчика, что является не только гарантией качества результата, но и в целом получения конечного результата, а не зарывания бюджета в провода.
В общем, техническое задание – это документ, который по сути не так важен для работы над проектом со стороны клиента, а важна возможность в любой момент обратиться к любому из элементов системы и посмотреть, как он будет работать.
работы, а также принять ее готовность согласно заявленному документу.
Этот документ гораздо важнее для производства внутри компании-подрядчика, а также для контроля выпускаемой продукции на соответствие всем заявленным требованиям и ограничениям – именно так мы добиваемся качества.
Вот простые правила, которые я применяю к любой технической задаче:
Требования к техническим характеристикам
- Техническое задание должно быть
- Он составляется подрядчиком вопреки оговоренным требованиям и подписывается сторонами.
- Техническое задание содержит полное и исчерпывающее описание создаваемой системы в терминологии физики решения, среды ее эксплуатации и четко и однозначно дает ответы на вопросы:
- как именно, шаг за шагом, будет работать тот или иной элемент системы в ответ на конкретные воздействия пользователя.
- как это будет выглядеть?
- какова его цель внутри всей системы
- как этот элемент будет обслуживаться в процессе эксплуатации и кем
- и т. д.
- Содержит критерии принятия результата – что именно в рамках физики системы дает четкое понимание того, что конкретный элемент или сценарий системы работает правильно и успешно.
- Написано совместно со специалистом (с поддающейся проверке квалификации) в области проектирования системных требований и специалистом по проектированию взаимодействия систем.
О требованиях
Требования — это описание (модель) системы, которой мы приписываем деонтическую модальность.(Анатолий Левенчук) Также стоит отметить, что бизнес-требования — это требования к тому, как должна работать система.
Требования отличаются от пожеланий по простому принципу: требование = желание + обоснование.Чтобы обосновать требование, необходимо предоставить артефакты, свидетельствующие о том, что требования определяются реальной потребностью и их реализация будет перекрывать (согласовываться) с миссией всего проекта.
Все требования записаны списком в одну большую таблицу с тремя столбцами:
| 1. требование | 2. для чего это нужно | 3. возможное решение |Не существует требований второго порядка или вложенных требований — требования — это конкретные требования к выводу из системы во внешний мир, которые система должна выводить в определенный момент времени и в определенном месте.
Требования всегда располагаются на выходе результатов функции системы и на входе в реальный мир - в котором ею управляет пользователь системы.
Самое главное, что нужно указать, что делается (прошу указать это во второй графе, и это самое главное, что может быть) - так как требования пишутся вместе с клиентом - мы всегда помогите это сформулировать, иногда для многих это сложный процесс.
Примеры требований из реальных проектов:
- Каталог должен показывать (в ваших глазах) продукцию
- Логистическая система должна выдать маршрут (на бумаге, в электронной почте, опять же глазам и мозгу), чтобы доставка прошла по плану.
- СМС об обучении нужно отправлять на телефоны (устройства) - чтобы не звонить всем подряд.
- Страница товара должна передавать конкретную информацию x y z (глазам) – для принятия решения о.
Все должно быть синим.
Если какое-либо пожелание из видения решения становится крайне важным, оно переносится в раздел документа под названием «Ограничения решения».
Стоит отметить, что ограничения всегда усложняют процесс создания решения и не всегда диктуются потребностями внешнего мира, поэтому мы записываем их в третий столбец и стараемся указать, что это для нас своего рода подсказка, так как если клиенту будет приятнее или удобнее решить ту или иную проблему.
Все это позволяет нам синхронизировать онтологию мира клиента и нашего для более четкого взаимопонимания.
Когда у нас есть требования, то все обрабатывается автоматически — процесс просто осуществляется.
Это вопрос техники – хороший исполнитель, как правило, не заржавеет. Требования обязательно и всегда согласуются друг с другом, формулируются обоснования, проверяется их осуществимость, отслеживается и т. д. Требования должны быть обоснованы – что вы не выдумали все на пустом месте.
Документы, решения и другие артефакты всегда под рукой.
Трассировка требований — это инструмент, позволяющий показать степень разработки и влияние требования на компоненты системы.
На этом этапе можно понять степень влияния требований.
Требования изменились - изменилась конфигурация - это тоже указывает на след и степень влияния.
Требования подписывают стороны.
Требования легко изменяются и постоянно дополняются в процессе работы; это фиксируется и не мешает работе.
Требования пишет заказчик, согласовывает с исполнителем и подписывает стороны.
Если говорить о распространенных заблуждениях о том, что всегда следует формулировать выгоду от создания продукта или функции, то всегда следует иметь в виду, что мы говорим лишь о части работы, связанной с вводом системы в эксплуатацию и эксплуатацию, и никогда не говорили о бизнес-стратегия или бизнес-требования.
Подробнее о поиске решения через истории вакансий я написал здесь.
deppkind.livejournal.com/3259.html .
Поэтому, когда мы говорим о требованиях и технических характеристиках, мы всегда говорим – не польза, а доставка.
Стоит понимать, что назначение технического задания – точка контроля входа и выхода производства.
Целью документа требований является выработка пожеланий и контроль результата.
Если ваше техническое задание на самом деле является лишь ожиданиями или непроработанными пожеланиями, задайте себе вопрос: как вы будете контролировать выход из производства достаточно сложного изделия?
Где я могу получить требования?
- Сесть и написать — в этом нет вообще ничего сложного.
Требования – это ваши ожидания.
- Если совсем сложно, то можно заказать требования, кто сколько за это берет (это собеседование с вами, где и как это делать, каждый решает сам - я это делаю только в студии и за деньги), это крест между работой секретаря+машинистки.
Ну и контрольные вопросы от нас, конечно)
- Решения можно давать по собранным требованиям — но у каждого решения уже может быть цена и сроки.
Можно за 5 рублей, а можно за 50 лямов.
Вот кто вам что предложит на рынке, каковы ваши потребности и ситуация.
- Подождите и потребуйте подробное техническое задание от подрядчика.
- Только после четкого понимания систему следует пускать в постройку (разработку).
- На этом все, от себя могу добавить, что могу с удовольствием проработать ваши ТЗ и требования с публичным анализом ошибок бесплатно (или конфиденциально в качестве экспертизы за отдельную плату).
Найденные опечатки исправляются и добавляются новые.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какая сейчас средняя температура в больнице? 17,54% Мы не фиксируем требования, не пишем техническое задание, работаем вживую по техническому заданию или со слов клиента.
10 45,61% Не фиксируем требования; мы работаем по техническому заданию, которое сами написали вместе с клиентом.
Мы не разделяем технические характеристики и требования.
26 36,84% Фиксируем требования, отделяем их от ТУ (технологической документации) и работаем по мере необходимости.
Проголосовали 21 57 пользователей.
18 пользователей воздержались.
Теги: #техническое задание #требования заказчика #системные требования #требования #Управление проектами #Управление продуктом
-
Создайте Свой Сайт За Несколько Часов
19 Oct, 24 -
Издатели Lifehacker Закрыли Проект Mcradar
19 Oct, 24 -
Медиаплеер Xtreamer
19 Oct, 24
