что такое постановка задачи в программировании
Идея программы
Жизнь новой программы начинается с идеи использования компьютера для новой задачи. Идея может родиться у программиста наблюдающего, как мучаются его коллеги, у самих информационных тружеников, просто у любознательного и умного человека. Одна и та же идея может быть реализована несколькими программами, в одной программе может быть заложено несколько идей. Но, без хорошей идеи не будет и программы. Например. Замечательная идея Питера Нортона, автора » Norton Commander «, в последствии была повторена в десятке различных программ, разбивающих экран на два окна со списками файлов и позволяющих в наглядном виде осуществить процедуры копирования и переноса файлов.
Кто Ваш пользователь и зачем ему нужна эта программа?
Неквалифицированный пользователь может заполнять числовые поля буквами или другими символами. Поэтому в программе необходимо предусмотреть проверку типа данных. Если тип вводимых данных не соответствует требуемому, программа должна вежливо объяснить пользователю: в чем его ошибка и попросить ввести правильные данные.
Поиск программ-аналогов
В настоящее время в мире работают миллионы программистов. Задачи, которые они решают, очень часто схожи с Вашими задачами. Вполне может оказаться, что и для решения Вашей задачи уже есть готовая программа. Вы можете ей воспользоваться. Но для этого Вам нужно выполнить необходимые условия использования объектов чужой интеллектуальной собственности. Например, приобрести лицензию. Несмотря, на то, что лицензионное программное обеспечение стоит дорого, Вы можете сэкономить много сил и времени, отказавшись от разработки собственной программы.
Разработка общей структуры программы
Данные и функции
К условно постоянной информации относятся данные, которые не надо менять при каждом обращении к программе. Это могут быть характеристики объекта расчетов (например, твердость стали в программе расчета стальных конструкций), нормативные данные (например, формы бухгалтерских документов) или другая не часто меняющаяся информация. Ввод условно-постоянной информации обычно происходит при создании программы. Переменные данные нужно вводить в компьютер при каждом обращении к программе. Обычно этим занимается пользователь. Он же отвечает за достоверность вводимых данных. В программе должна быть специальная подсистема ввода данных. Для исключения ошибок, желательно организовать входной контроль данных.
Система меню
Хорошо организованное меню как бы вступает с пользователем в диалог, последовательно уточняя, что ему нужно и предлагая варианты возможных действий. Структура дерева, принадлежность подменю пунктам основного меню должна быть интуитивно понятной пользователь и соответствовать его представлениям о решаемых задачах. Названия пунктов меню должны соответствовать вызываемым действиям, быть привычными и понятными пользователю. Инструменты, которые часто используются должны быть на виду: в основном меню или хотя бы в высших уровнях подменю.
Контекстная подсказка
Топик — раздел подсказки, посвященный одному вопросу. Топик имеет заголовок и идентификатор. Рабочий топик — посвящен техническим вопросам работы с конкретным окном программы. Методический топик — посвящен вопросам теории и методики решения задач пользователя с помощью программы.
Формирование конкретных требований к программным модулям
Что нужно сделать, чтобы модуль смог выполнить поставленную перед ним задачу? Часть необходимой информации модуль получит из входных данных, остальное должны передать ему другие модули, стоящие раньше в цепочке решения задачи. Так формулируются требования к предыдущим модулям. Рассматривая их как последние, сформулируем требования к модулям, стоящим в цепочке раньше. И так до начала цепочки. Это похоже на волну, прокатывающуюся от конца цепочки до начала, поэтому такой метод получил название «Обратная волна требований».
Может показаться, что описанный путь постановки задачи слишком долгий и скучный. Гораздо проще и интереснее сразу приступить к программированию, хотя бы того, что понятно уже сейчас. Потом можно дописывать программу по мере осмысления задачи и требований пользователя.
Однако, поступив так, Вы достаточно скоро поймете, что разработка Вашей программы зашла в тупик. Добавление нового модуля требует существенной реорганизации данных и изменения логики работы всей программы. Поэтому каждый новый модуль добавляется все с большими трудностями. В конце концов, трудности становятся такими непреодолимыми, что проще написать всю программу заново.
Еще такой путь программирования напоминает строительство жилья богатеющим купцом. В центре, фасадом на улицу, стоит хибара. (Когда-то у купца денег хватило только на нее). Поодаль, в виде пристройки к хибаре, стоит добротный кирпичный дом (разбогател купец). А на отшибе, там, где у других стоит туалет, возведен роскошный особняк.
Хотелось бы Вам жить в таком доме?
Как менеджерам научиться ставить задачи разработчикам
Когда речь заходит о разработке, менеджеры и управленцы сразу вспоминают накопившийся массив задач, которые ждут своей очереди, непредсказуемые сроки их реализации, имеющие свойство постоянно меняться, натянутые отношения с IT-отделом, который использует систему «свой-чужой», и множество других проблем, тормозящих развитие бизнеса. Чтобы решить все эти проблемы, необходимо научиться грамотно ставить задачи и общаться с разработчиками. О том, как менеджеры должны ставить задачи, чтобы они были выполнены в срок и в соответствии с заданием, рассказывает Николай Хлебинский, СЕО и сооснователь платформы Retail Rocket.
Генерируйте идею правильно
В наши головы постоянно приходят идеи по доработке и улучшению продукта — как поднять конверсию сайта, ускорить работу отдела, усовершенствовать бизнес-процессы, автоматизировать какие-то функции и т.д. Существуют даже специальные должности и отделы, в обязанности которых входит мониторинг новой функциональности, которая появляется у ведущих игроков рынка. Еще одним отличным источником идей служит обратная связь от клиентов. Весь этот массив данных, мнений и предложений накапливается и требует постоянной сортировки, оценки и приоритезации.
Новые идеи двигают продукт вперед и создают конкурентные преимущества, но если бы каждый сотрудник сразу шел с возникающими идеями к разработчикам, у последних просто не оставалось бы времени на работу. Им пришлось бы либо погрязнуть в череде бесконечных обсуждений, как лучше реализовать тот или иной момент, и тогда разработка шла бы крайне медленно. Либо наоборот, стремясь как можно быстрее внедрять новые функции и фичи, пришлось бы кодить «костылями», добавляя изменения без оглядки на другой функционал, что создавало бы трудности в дальнейшем.
Первая и самая важная проблема, которую нужно решить — это процесс генерации идей.
У нас в Retail Rocket идею может сгенерировать любой член команды, и она заносится на определенную доску в Trello. В своей работе мы используем идеологию Канбан и для каждого процесса в компании, для каждого отдела, есть своя доска. Идеи по продукту записываются в определенный столбец, но чтобы это сделать, менеджер (или любой сотрудник) должен сформулировать ее краткое описание. То есть не просто «ограничить количество символов в отзывах» или «добавить кнопку быстрого заказа», а внятное описание, из которого будет понятно, зачем нужна новая функция и чем она будет полезна.
То есть человек, у которого появляется идея, не идет сразу в отдел разработки, и даже не идет в продакт-менеджеру, а прежде всего пытается сформулировать идею в слова. Это позволяет избежать множества проблем и вопросов при дальнейшей разработке и внедрении новых функций.
Поэтому первое правило: Задача может быть внесена в идеи, только если человек готов сформулировать её краткое описание.
Описывайте задачу максимально подробно
После этого в дело вступает продакт-менеджер — это отдельная роль, которая занимается управлением продуктом. Задача этой роли – сбор требований и подготовка этих требований к передаче в разработку. То есть постановщик идеи не общается с разработкой напрямую.
Продакт-менеджер должен составить описание, по которому разработчики будут принимать решение о том, как реализовывать эту конкретную идею и оценивать сроки выполнения задачи.
Отсюда второе правило: первоначальная функция продакт-менеджера состоит в том, чтобы поставить и описать задачу так, чтобы снять все вопросы у разработки.
Например, в случае задачи ограничения количества символов в отзыве, должно быть описано, что происходит, если отзыв длиннее заданной величины, должен ли быть счетчик символов, меняются ли CSS-стили при приближении счетчика к нулю или показывается сообщение об ошибке и т.д. На все эти вопросы должны быть ответы, чтобы разработчикам не пришлось уточнять детали в процессе.
Третье правило: product-менеджер должен сформировать список тех, кто будет тестировать фичу и определять ее эффективность.
Это значит, что во-первых, идея не может идти в разработку, пока не определен список тех, кто будет отвечать за ее проверку, после того, как она выйдет из IT-отдела. И во-вторых, пока не будут четко определены критерии эффективности.
То есть сотрудник, который заказывает новую фичу, должен сказать: «Тестировать будут эти конкретные люди, и тестирование будет считаться успешным, если наступило такое событие».
Оценивайте каждую задачу
Самый важный момент, который происходит на этом этапе — получение оценки по задаче в деньгах. Это означает, что любая задача, которая дается в разработку, должна быть оценена в деньгах ее постановщиком, т.е. сотрудник должен посчитать, сколько бизнес на этом заработает. Многим кажется, что невозможно оценить, сколько денег принесет выполнение той или иной задачи, но это не так. Да, это может быть сложно, но опыт показывает, что по большинству задач это вполне реально. А если нельзя — именно эти задачи оказываются бизнесу не нужны. Если вы не знаете, сколько принесет задача, точно ли нужно тратить на нее время?
Четвертое правило: каждая задача должна быть оценена в деньгах
Приведем пример. Существуют триггерный сценарий — письмо о «брошенной корзине», которое интернет-магазин отправляет пользователям, которые добавили товар в корзину, но не оформили заказ. Один из клиентов попросил отправлять повторное письмо в случае, если цена на один из товаров в корзине снизилась. Чтобы посчитать стоимость этой задачи, менеджер продукта пришел с запросом к аналитикам и попросил посчитать, на какое количество товаров снижается цена за неделю на 5% и более. Аналитики посчитали, что около 10% товаров, оставленных в корзине, в сегменте fashion за неделю снижают цену на 5% и более. Это означает, что мы можем увеличить количество отправок писем о брошенной корзине на 10% и, соответственно, получить на 10% больше заказов. Таким образом за неделю мы получили оценку задачи в деньгах.
И все эти процессы происходят пока без участия разработчиков, т.е. мы не отрываем их от текущих задач.
Приоритезируйте задачи
После оценки задачи в деньгах, нужно получить оценку выполнения задачи по времени — на этом этапе подключается отдел разработки.
По описанию, которое составил менеджер продукта, разработчики обсуждают, как можно выполнить поставленную задачу и сколько времени это займет. Для оценки мы используем Planning Poker.
После оценки всех задач в бэклоге, можно их приоритезировать, т.е. понять, какие из задач можно выполнить максимально быстро и какие принесут наибольшую финансовую отдачу. За них нужно браться в первую очередь.
Пятое правило: первыми в работу должны идти задачи, которые принесут наибольшую финансовую выгоду и требуют минимальных затрат по времени.
Только теперь начинается работа IT-команды над задачей.
Сначала создавайте MVP
Когда доходит дело до разработки, важно первую версию фичи сделать максимально дешевой и простой в производстве, чтобы максимально быстро протестировать гипотезу. То есть создать MVP (Minimal Viable Product). На этом этапе важно проверить критерии эффективности, которые были определены при описания задачи.
На примере задачи с уведомлением о снижении цены на товар в корзине, не нужно сразу делать интерфейс, маркетинговые материалы и т.д. Мы просто пишем код, который срабатывает практически вручную, предлагаем нескольким магазинам на тестирование, чтобы проверить, как это повлияет на продажи и подтвердить расчеты аналитиков на практике. Проводим тестирование в ручном режиме и измеряем результаты. И только после того, как мы получили доказательства того, что гипотеза сработала, в зависимости от результатов, мы принимаем решение, стоит ли разрабатывать полноценную фичу (разрабатываем интерфейс, рисуем дизайн, делаем верстку и т.д.).
Шестое правило: разрабатывайте полноценную версию фичи после подтверждения ее эффективности через MVP
Увеличивайте продуктивность команды разработки
Никто, кроме менеджера продукта и, возможно, генерального директора, не должен общаться с разработчиками. Они должны находиться в отдельной комнате и никто не должен к ним заходить. Это поможет в разы увеличить эффективность работы IT-отдела. Потому что человеку, чтобы сконцентрироваться даже на простой задаче, нужно потратить 15-20 минут, чтобы только приступить к выполнению. И если через 15 минут к нему подходит кто-то с вопросом (а такое случается постоянно, и чем больше компания, тем чаще), человек выходит из состояния концентрации. А значит, ему снова нужно 15-20 минут для погружения. Т.е. как минимум 30-40 минут уже потеряно впустую. И если 5-7 человек в день подойдут к разработчику с вопросом, можно считать, что за день он ничего не сделал.
Седьмое правило: Ограничьте до минимума круг тех, кто общается с разработчиками. В идеале это должен быть только менеджер продукта и в некоторых случаях генеральный директор.
Мы решили эту задачу выделив под IT отдельную комнату, вход в которую всем остальным сотрудникам запрещен. На двери висит отдельный замок, ключ-карта к которому есть только у самих инженеров и еще нескольких людей в компании.
Еще один важный момент: нужно построить вокруг IT-отдела «защитный купол», т.е. оберегать от любых проблем, решать все вопросы, обеспечить инфраструктуру, чтобы они не занимались ничем, кроме производства кода. Неслучайно в корпорациях, таких как Яндекс или Google, офисы полностью обустроены так, чтобы человеку можно было практически не уходить домой. Если сотрудник будет заниматься поисками чая, кофе или батарейки для мышки, он будет гораздо меньше времени тратить на свои непосредственные обязанности. Обеспечить дорогостоящих квалифицированных специалистов всем необходимым гораздо дешевле, чем тратить их время на нецелевые действия.
Восьмое правило: организуйте инфраструктуру и обеспечьте разработчиков всем необходимым
Это важно еще и потому, что хороших разработчиков действительно мало, и конкурировать за них только по цене бесполезно, потому что всегда найдется тот, кто готов платить больше. Поэтому чем более комфортные условия вы сможете создать, тем более продуктивной сможет стать команда разработки и тем большую лояльность будут проявлять сотрудники.
Станьте своим
Еще один простой, но очень эффективный способ более эффективно общаться с разработчиками — это научиться разговаривать на их языке. Пройти курсы по HTML, CSS (например на codecademy.com), т.е. потратить 10-20 часов своего времени, чтобы в будущем гораздо лучше понимать IT-команду.
А как вы строите взаимодействие с IT-командой? Делитесь своими подходами в комментариях!
Постановка задач для начинающих тимлидов
Когда люди говорят о постановке задач — они очень любят вспоминать про SMART.
Ну, дескать, цель должна быть Specific, Measurable, Attainable, Relevant, Time-bound.
И есть даже удивительные люди, которые пытаются это пихать программистам.
Но есть задачи, а есть задачи. И между ними большая разница!
Разработчик — существо потоковое, драйвовое. В отличие от проджект-менеджеров, тимлидов и прочих замечательных людей, которым неизбежно приходится переключать фокус внимания раз в 10 минут. И здорово, если процессы позволяют разработчику находиться в этом потоке и создавать код без отвлечения на точки согласований и ошибки коммуникации. Для этого есть модель TOTE. И есть мнение, что именно от неё нужно отталкиваться при формулировке таска разработчику. Поясню сначала, что за модель, а потом — как её применить.
T1 — Test — желаемое состояние, к которому мы стремимся, какое оно?
О — Operation — какие действия мы должны делать, чтобы достигнуть результата?
T2 — Test2 — по каким признакам мы поймём, что продвинулись в сторону результата?
E — Exit — по каким критериям мы поймём, что результат окончательно достигнут?
Эта модель очень алгоритмична и хорошо подходит для задач до 20 часов (я надеюсь, вам не нужно объяснять, почему линейным разработчикам не нужно ставить задачи больше 4..8 часов? 🙂 ).
Приведу пример, как это ложится на постановку тасков при плановой разработке. Конечно, приведённый рецепт не подходит в случае работы в стиле Research and Development, организации работ по эксплуатации или работы по срочному затыканию дыр.
Сперва (T1) идёт краткое описание, что мы делаем (не путайте с заголовком задачи!). Одно предложение, обобщающее, что и зачем мы делаем.
Вообще говоря нет смысла браться за задачу, если вы не можете это сформулировать. Это может выглядеть вот так: «Сделать стандартное REST API профиля пользователя, чтобы с ним работали фронтэнд приложения», «Учим метод создания брони принимать параметр gender и сохранять его», «Необходимо написать миграции, которые расставят ключи в соответствии со схемами из merge request (uml диаграммы таблиц)».
В качестве Operation и чуть-чуть T2 выступает глава «какие действия нужно сделать для достижения результата».
Это нумерованный список тех конкретных действий, что нужно сделать линейному разработчику. Возможно с оценкой по времени. Например:
1. Создать миграцию (30 минут)
2. Прописать модель с валидацией (2 часа)
3. Прописать контроллер (2 часа)
Важно, что он нумерованный и вы понимаете, сколько времени должно занять выполнение каждого шага. Особенно это важно — если вы работаете с джуниорами и миддлами. Ибо как только ваш разработчик «закопается», данный список — хороший способ быстро понять, на чём он застопорился и какие дальнейшие у него должны быть шаги.
Ну и в завершение глава «Ожидаемый результат» выступает в качестве правил Exit и немножко T2. «Ожидаемый результат» — это ненумерованный чек-лист проверки задачи. Фактически мы формулируем сценарии тестирования задачи, языком QA. То есть, они в идеале должны содержать как позитивные, так и негативные сценарии и не должны содержать отсылок к коду в стиле «написан класс такой-то». Только функциональные проверки.
Например:
— При создании пользователя через API, он появляется в БД
— Ответы API при создании пользователя соответствуют документации
— Пользователя можно создать только администратору
— Не-администратор при попытке создания пользователя получает 403 ошибку
К слову, высокий процент багов в сделанных задачах — это как раз повод уделить больше внимания «ожидаемому результату» при формулировке, чего вы хотите от разработчиков.
А не слишком ли много буков?
Конечно, на практике может быть не рентабельно прописывать все задачи таким образом. Нужно найти баланс, и об этом тоже хочется немного сказать.
Постановка задач через TOTE полезна как временная мера при подключении новичков, джуниоров и миддлов, пока они не освоятся с новой для них системой и подходами, принятыми в коллективе.
Можно смело упрощать постановку задач квалифицированным, проактивным и продвинутым сотрудникам. Можно смело урезать формулировки, если у вас один человек берёт один блок работ и безотрывно, без отпусков и болезней решает его с гарантированным результатом. Если с людьми приходится «играть в шашечки», перекидывать с задачи на задачу и тасовать их между командами, если блоки работ «ставятся на холд» — ТОТЕ необходим.
Что такое постановка задачи в программировании
12-летний опыт работы в IT в качестве разработчика, аналитика, руководителя проектов, методолога системного анализа
Опыт работы в энергетике,
разработке государственных информационных систем
(контрольно-надзорные органы, образование),
транспортной логистике
Автор и ведущий курсов по архитектуре предприятия и
управлению проектами в ВУЗах (СПб ГУТ, СПб ГУАП)
Опыт в IT 5 лет в качестве аналитика,
методолога бизнес/системного анализа
Техническое задание — это не то же самое, что и постановка на реализацию. Техническое задание — это результат обработки исходных (организационных, бизнес-) требований, их уточнения и перевода на системный/технический уровень.
Постановка задачи на реализацию — это описание способа реализации исходных требований, технического задания, архитектурного решения, изложение требований к устройству спроектированного решения (на этом этапе исходные требования уже обработаны).
Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.
Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации готового ИТ-решения
Техническое задание разрабатывается на этапах Инициации и Определения метода решения бизнес-задачи. Здесь мы говорим про выявление проблемы, сбор исходных требований, формирование какого-то запроса на решение этой проблемы.
Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.
Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.
Разделы постановки на реализацию
Предположим, компания занимается продажей товаров через интернет (e-commerce). В целях привлечения новых клиентов и удержания существующих, компании требуется предоставить клиентам возможность получать дополнительную информацию при заказе товара.
Необходимо разработать сервис по расчету и предоставлению клиенту плановых сроков доставки заказа. Считаем, что до этого мы никаких сроков потенциальному клиенту не озвучивали.
Контекст задачи – это краткая информация о ситуации и проблемах, из-за которых возникла стоящая перед вами задача по автоматизации. Данная часть постановки – это, по сути, срез бизнес-требований, которые были собраны бизнес-аналитиком на предыдущем этапе.
Кейс: возможность предоставления клиенту плановых сроков доставки заказа
Компания не имеет собственных средств доставки грузов.
Базовые сроки доставки предоставляются сервисами компаний-перевозчиков, далее в них учитываются сроки подготовки заказа и риски, которые может учесть компания.
Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.
Для чего этот бизнес-контекст разработчикам?
Ведь решение уже есть, для чего давать исходные данные в виде контекста? Дело в том, что в некоторых случаях описание решения может быть менее конкретным. Риски по формированию детального решения можно переложить на команду. Если члены команды являются экспертами в предметной области, понимают как пользователь и бизнес будут этими функциями пользоваться, то они сделают более качественное решение.
Пример из практики:
Делали систему для компании, где работали операторы 24 часа в сутки. Специфика работы компании заключалась в том, что ночью было принято работать без света. Если не знать этой специфики, можно было бы сделать какой-то вырвиглазный интерфейс, в котором ночью работать было бы невозможно. А зная и понимая это, проектировщик интерфейсов разработал такие интерфейсы, которые позволяют работать одинаково удобно и днём, и ночью.
В этом разделе постановки речь идёт о едином перечне источников информации, описание которых снижает риск использования недостоверной информации.
Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.
Заинтересованные стороны (далее ЗС) — это перечень людей, которые будут влиять на принятие решений и от которых зависит успех реализации.
Роли заинтересованных сторон
Разница между проектными ролями и бизнес-ролями ЗС
Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.
Мы можем смотреть на то, кем является заинтересованная сторона в конкретном проекте и кем она является в рамках бизнес-процессов, которые мы автоматизируем.
Например, у нас есть директор по развитию. На проекте он является куратором (улаживает какие-то вопросы и проблемы) — это его проектная роль. В качестве бизнес-роли он никем не выступает (строка №1).
Проектная роль директора по взаимодействию с подрядчиками — это заинтересованная сторона от какой-нибудь службы по взаимодействию с подрядчиками.
Но как у человека этой области бизнеса у него есть компетенции, которые позволяют ему выступать от лица менеджера по работе с клиентами. То есть директор по взаимодействию с подрядчиками может грамотно сформулировать требование от лица менеджера, понимает, как менеджер работает, может ответить на все необходимые вопросы — это бизнес-роль (строка №2).
Маркетолог также может иметь и проектную, и бизнес роль. Т.к. маркетолог смотрит на то, как готовым продуктом будут пользоваться, то можно сказать, что он является клиентом компании и может диктовать требования от имени клиентов компании — это его бизнес-роль (строка №2).
В контексте постановки в большей степени важна будет проектная роль, потому что она определяет отношение заинтересованной стороны и ее полномочия. Например, куратор имеет максимально широкий спектр полномочий, в том числе в части согласования.
Бизнес-роль важна прежде всего на уровне сбора требований, т.к. отвечает за содержательную их часть. Бывает и так, что требования дособирают на этапе постановки, потому что иногда все то, что было наработано в техническом задании, к моменту реализации уже не совсем актуально, потому что бизнес меняется, и это нормально.
Наличие в постановке реестра заинтересованных сторон позволяет команде разработки на этапе выполнения задачи понимать, с какой из заинтересованных сторон нужно коммуницировать по какой конкретной части решения.
Критерии приемки результатов — критерии, выполнение которых может говорить о том, что решение реализовано (definition of done постановки).
Нефункциональные требования — требования к видам обеспечения и ограничений реализации. НФТ нужны, чтобы их учитывать при принятии решения в рамках постановки.
Ошибки при их проработке в последствии могут привести к очень серьезным проблемам и полной неработоспособности решения
В состав поставки могут также входить ключевые требования на систему в целом, если это необходимо.
Описание решения — это основная часть постановки, описывающая способ и границы реализации
При определении объема документирования важно:
Конкретика
Документацию необходимо писать просто, кратко и точно, применяя лексику, понятную пользователям, во избежание расхождений в интерпретации артефактов и фраз в постановке.
Команда
Счастливые тестировщики понимают, какие есть пользовательские сценарии использования продукта, внутренних алгоритмов
Счастливые тимлиды понимают, как можно разбить задачу между исполнителями