Хотите узнать, как создать эффективные ограничения и исключения для вашего документа о концепциях и границах? В этой статье мы раскроем секреты разработки требований, которые помогут вам точно определить рамки вашего проекта и избежать ненужных затрат и проблем в будущем.
Чтобы ответить на вопрос: “зачем на это нужно тратить время при разработке требований”, я приведу пример из жизни.
Когда я был совсем молодой, я был очень умным и считал разработку требований чем-то бессмысленным, за что не платят деньги, а приступать к разработке сразу, тем более на фрилансе, это считал само собой разумеющимся.
Однажды получив заказ на фрилансе по созданию сайта для одного небольшого завода, я утвердил ТЗ с заказчиком и приступил к разработке. К слову, в ТЗ было все как мы любим, расписано по пунктам только то, что нужно разработать в виде кода. Но, в результате того, как сайт был создан, пришло время его размещать.
Владельцы завода установили ограничения, что сайт необходимо располагать на хостинге зарегистрированный на них. В целом кажется здравым, но вот реализация захромала. Задачу отдали их местному системному администратору, который никогда с этим не сталкивался и решил оформить хостинг на свой паспорт. 🙂 В результате долгого ожидания мне выдали доступ к FTP, куда я загрузил сайт и предъявил результат работы заказчику.
Работу оценили, даже были готовы отдать распоряжение в бухгалтерию на выплату. Но произошло небольшое недоразумение, они пока оценивали работу, уже успели подключить рекламу, т.к. бизнес не требует ожидания и все в их представлении должно работать и приносить доход без задержек. Естественно пользователи повалили пачками, не такими и большими, но человек по 100 онлайн. Но тот системный администратор выбрал саааааааамый дешевый тариф, на котором можно просто тестировать свой сайт максимум до 10 онлайн пользователей.
Естественно сайт с его крайне ограниченными ресурсами хостинга испытал на себе ощущение DDOS-атаки и перестал отвечать на запросы, т.е. не открывался. Мне естественно сказали, что у меня ошибка и мне нужно срочно разобраться.
Перековыряв весь backend я так и не смог найти сценарий, который тормозил или валил систему. Потеряв много времени я выбил доступ не только к FTP, а к панели управления хостингом и увидел, что там взят самый дешевый тариф.
Вот так вот в молодые годы я умел экономить время на разработке требований и мажорно разбрасываться им на устранении проблем, которые были вызваны неоговоренными ограничениями и исключениями в разработке требований. Ой, но ведь и разработке требований у меня тогда тоже не было 🙂
Мы часто ложно надеемся, что ТЗ покрывает все наши задачи по разработке требований, но ТЗ - это следствие, а предпосылкой должно быть создание документа о концепции и границах. Если вы сразу попали на эту статью и не читали предыдущие, то начните с прочтения первой, т.к. это цикл статей по разработке требований.
Ограничения
На самом деле подраздел в документ о концепциях и границах имеет следующую цифровую последовательность и название “2.3. Ограничения и исключения”.
Его описание не представляет каких-то особых знаний или техник. Важно при его составлении задавать себе один вопрос до тех пор, пока ответы на него перестанут поступать и все это записывать в список. Этот вопрос звучит так “А что может ограничивать работу?”. Все пункты обязательно необходимо выписать, чтобы заказчик понимал проблему.
Вы же знаете правило “проблема записанная на бумаге - это 50% на пути к её решению”. Если вы оговорили с заказчиком все требования и они отражены в документе, то таких коллизий, как в моём примере выше у вас возникнуть не может. Для примера ответим несколько раз на данный вопрос и составим список для проекта, под который мы создаем документ о концепции и границах.
Вопрос “А что может ограничивать работу?”, ответы:
- Встроенные ограничения от Google на количество и интервал между запросами при работе с вызовом функций из вне;
- Объем оперативной памяти выделяемой для работы сценария. Нельзя в одной итерации обрабатывать больше 200 строк таблицы, если будешь хранить данные всех строк в массивах;
- Заполнить ведомость для сотрудника нельзя, если он не зарегистрировался в боте;
- Не соблюдение стандартов таблицы. Если будут изменены значения в столбцах таблицы, т.е. поменять местами премию и аванс или ЗП и часы. В таком случае бот будет отправлять неактуальную информацию.
Вот таким образом вы должны выписывать все ограничения, которые могут повлиять на работу разрабатываемой подсистемы. Сюда может входить любое ограничение, в том числе и законодательные регламенты, которые могут на него повлиять.
Исключения
Для исключений необходимо указать условия, при которых определенные функции, возможности или ресурсы будут исключены из общих правил или ограничений.
В данном пункте вы работаете по такому же принципу, только задаёте другой вопрос “А что может исключать правила работы?”. Но для ответа вы вначале пишите какое было правило, а затем указываете его исключение. Вот пример:
Правило: после регистрации пользовательские сообщения не будут обрабатываться ботом. Исключение: если в таблице в строке этого пользователя не стоит пометка, что он руководитель. Руководитель может отправлять запросы после команды /send.
В данном проекте не так много исключений, поэтому высасывать из пальца это тоже плохо. Но думаю, что вы поняли принцип описания исключений. Отражаем их в документе.
Заключение
В результате составленных ограничений и исключений вы создаете дополнительную безопасность для траты своего времени на неоговоренные доработки и поиски проблем. Главное правило разработки требований и причины создания документа о концепции и границах заключается в том, чтобы максимально информировать заказчика о всех нюансах разработки его проекта.
Подписывайся, если хочешь получать актуальную информацию в сфере разработки требований и программирования в частности.