что делают с требованиями
Как отвечать на требования налоговой
Особенно если они странные
Если вы ИП или руководитель ООО, налоговая инспекция иногда присылает вам требования.
Я 16 лет работаю бухгалтером — сначала по найму, а теперь как ИП. Консультирую предпринимателей и веду учет. В статье расскажу, как отвечать на требования налоговой что-то пояснить или представить документы и почему делать это обязательно.
Зачем налоговая требует пояснения или документы
ИФНС может прислать требование, если у нее возникли к вам вопросы в следующих ситуациях.
Во время налоговой проверки. Она может быть выездной, то есть на территории налогоплательщика, или камеральной — когда ИП или ООО сдает декларацию, а налоговики проверяют ее у себя. Если ИФНС что-то непонятно, придется объясняться. Например, если в отчетности написано одно, а в документах, которые находятся в налоговой, — другое.
Когда проверяют конкретную сделку вне налоговых проверок. Например, фирма купила нежилое помещение. Налоговая инспекция считает, что продавец не уплатил положенные налоги, и проверяет именно эту сделку, запрашивая документы у продавца и покупателя.
Когда надо ответить на требование
Как присылают требования. Требование из ИФНС может прийти по почте или электронно. А иногда его даже вручают лично: например, когда предпринимателя вызывают в налоговую и уже там отдают требование. У требований во время камеральной проверки есть свои особенности — о них расскажу ниже.
Если организация или ИП сдает отчетность через интернет, то требование придет электронно. Обычно, если предприниматель или компания ведет электронный документооборот, операторы ЭДО сами сообщают о требовании по смс или электронной почте, чтобы оно не потерялось.
Сроки на ответ. После того как пришло электронное требование, есть 6 рабочих дней, чтобы отправить квитанцию о приеме. Если этого не сделать, через 10 дней ИФНС заблокирует расчетный счет.
Когда налогоплательщик отправит квитанцию, начинает течь срок исполнения требования. Для представления документов это 5 или 10 рабочих дней, для пояснений — 5 рабочих дней. Этот срок указан в требовании. Все сроки считаются в рабочих днях.
Если требование пришло обычной почтой, оно считается полученным на шестой день после отправки. Возможные задержки на почте — проблема налогоплательщика.
Если налоговики вручают требование лично, то делают это под подпись — надо расписаться в экземпляре ИФНС, подтвердив, что вы требование получили. С этого момента начинает течь срок представления документов.
Как продлить срок для ответа. Можно письменно попросить ИФНС об отсрочке. Сделать это надо не позже чем на следующий рабочий день после дня, когда получите требование.
Просьба об отсрочке составляется по утвержденной ФНС форме — в виде уведомления о невозможности представить документы или информацию в срок. Можно отправить просьбу через интернет или отнести лично — важно, чтобы был документ, подтверждающий отправку: подпись инспектора, который принял уведомление, или квитанция оператора ЭДО.
Основанием для отсрочки может быть командировка или болезнь руководителя. Или то, что налогоплательщику надо копировать много документов.
Предоставить отсрочку — право налоговой инспекции, а не обязанность. Поэтому отсрочку могут и не дать.
Что будет, если не ответить
Если проигнорировать требование о представлении документов, грозит штраф — 200 Р за каждый непредставленный документ о своей деятельности.
Если налоговики попросили пояснить или уточнить налоговую декларацию и вы ее уточнили — этого достаточно, дополнительные письма можно не писать. Но если не уточнить декларацию или не объяснить письменно, что в ней все верно, — грозит штраф. Игнорировать требования налоговой — дорогое удовольствие, поэтому отвечать на них надо обязательно.
Как правильно отвечать
На требование что-то пояснить необходимо ответить письменно. Еще нужно зафиксировать, что ответ передан в налоговую, — квитанцией оператора электронного документооборота или подписью и штампом инспектора. К пояснениям можно приложить подтверждающие документы, но это необязательно.
Если требование поступило во время камеральной проверки декларации по НДС, то пояснения надо передать электронно по утвержденному ФНС формату. Во всех остальных случаях пояснения можно составить в свободной форме и передать в инспекцию лично, по почте или электронно. Это относится и к требованию налоговой представить документы.
На требование представить документы. Когда ИФНС просит документы, надо представить их копии, заверенные налогоплательщиком. Не надо заверять копии нотариально или отдавать оригиналы: налоговики не будут копировать их за свой счет. Они вправе ознакомиться с оригиналами, но не более того.
На каждой копии должно быть написано «копия верна», дата, должность, подпись и расшифровка подписи того, у кого есть право заверять документы. Документы ИП может заверять сам предприниматель, ООО — руководитель фирмы. Они могут передавать свое право подписи по доверенности.
Многостраничные документы нужно прошить и заверить одной надписью в месте прошивания. Есть и другие правила, как заверять бумажные документы, — им посвящено приложение 18 к приказу ФНС от 07.11.2018 № ММВ-7-2/628@.
Документы надо передавать по описи, чтобы было документальное доказательство того, что вы свою обязанность выполнили. Если передаете документы в ИФНС лично, в описи должен расписаться сотрудник инспекции. Если отправляете почтой, опись подписывает оператор почтовой связи. Если электронно, то оператор ЭДО формирует электронную квитанцию.
Через ЭДО можно отправить электронные документы — те, что изначально были в электронном виде и подписаны электронной подписью, или сканы бумажных документов, заверенные ЭП.
Так процесс должен выглядеть в идеале. Но иногда налоговая хитрит или пишет в требовании то, что трудно понять и на что еще труднее ответить. Вот какие могут быть сложности с требованиями от налоговой и как на них реагировать.
Как должно быть. Если требование пришло по результатам камеральной проверки декларации, срок ответа на него — 5 рабочих дней. Такое требование приходит, если налоговики считают, что в декларации есть ошибки, противоречия и несоответствия имеющейся у них информации. Тогда ИФНС потребует дать пояснения или исправить декларацию.
Есть еще несколько поводов для требований от налоговой по закону. Например:
Ограничения по срокам есть не только у налогоплательщика, но и у ИФНС. Она вправе направлять требования в рамках камеральной проверки в течение 3 месяцев со дня, когда компания или ИП представит декларацию или расчет. Исключение — когда требование направили в рамках дополнительных мероприятий налогового контроля.
Провести дополнительные мероприятия вправе руководитель налоговой инспекции в ходе проверки. Это возможно, например, если нужны еще какие-то доказательства нарушения налогового законодательства. Тогда могут запросить дополнительные документы за пределами трехмесячного срока.
Декларацию по НДС налоговики проверяют в течение 2 месяцев, но этот срок могут продлить до 3 месяцев — также по решению руководителя инспекции.
Если ИФНС пропустила срок, выставлять требование она не вправе.
Как бывает. Иногда налоговая инспекция пропускает трехмесячный срок камералки, а потом спохватывается и хочет задать какой-нибудь вопрос о прошедшем периоде.
Например, у одного ООО произошла такая история. Организация не вела деятельность, в штате числился единственный учредитель — генеральный директор. Зарплата не начислялась, ведь деятельности не было и директор находился в отпуске за свой счет.
За 2019 год компания сдала нулевую форму расчета страховых взносов, РСВ, так как начислений взносов с зарплаты директора не было. Организация была на общей системе налогообложения, поэтому за этот же год сдала декларацию по налогу на прибыль. В ней был внереализационный доход — это списание старой задолженности с истекшим сроком, не востребованной кредитором. ООО обязано ее списать и исчислить с нее налог на прибыль, что компания и сделала.
Налоговой инспекции это показалось подозрительным: доход есть, а зарплату не начисляли. Задать этот вопрос вовремя можно было в течение 3 месяцев со дня сдачи РСВ или декларации по налогу на прибыль за 2019 год. Но налоговики срок пропустили. Поэтому они пошли на маленькую хитрость.
После первого квартала 2020 года организация, как положено, сдала очередные расчеты и декларации, в том числе РСВ с нулевыми показателями. В срок для камеральной проверки РСВ за первый квартал 2020 года инспекция прислала требование, в заголовке которого запрашивала пояснения по РСВ за этот квартал. А в тексте требования речь шла о 2019 годе, который ее интересовал на самом деле.
Как отвечать на требование. Не надо поддаваться на провокацию. Спрашивали про первый квартал 2020 года — отвечать можно только про него. Главное — ответить.
Естественно, в этот период у компании никаких расхождений уже не было, поэтому она так и написала.
В требованиях по результатам камералки есть еще одна тонкость. Если подать уточненную декларацию или расчет, камеральная проверка первоначальной декларации прекращается, начинается камералка новой. Срок при этом начинает течь заново — со дня сдачи уточненной декларации. То есть сдали уточненную декларацию — продлили срок камеральной проверки.
Еще во время камералки налоговые инспекторы могут требовать пояснения, но не вправе требовать документы. Если только это прямо не предусмотрено налоговым кодексом: например, могут требовать счета-фактуры при камеральной проверке декларации по НДС с суммой налога к возмещению. Поэтому документы к пояснениям, как правило, прикладывать не нужно — достаточно письменно ответить на вопрос.
Как должно быть. Налоговая инспекция должна запрашивать пояснения, только если обнаружит какие-то ошибки и несоответствия. Какие именно ошибки и несоответствия — должно быть указано в самом требовании.
Как бывает. Чаще всего из текста требования хорошо понятно, что именно случилось и почему запрашивают пояснения. Но бывает и иначе.
Расхождение — это разница между декларацией и суммой, которую ИП получил через банк. В какую сторону — инспекция не написала. Тут возможны два варианта:
Во втором случае разница огромная.
Как отвечать на требование. В первую очередь надо проверить свою декларацию и документы, из которых вы брали суммы для нее. На УСН это книга учета доходов и расходов и банковская выписка — та, что выдал банк, а не автоматически загруженная в программу учета.
Чтобы исправить ошибку, можно подать уточненную декларацию. Подавать уточненку, если сумма налога завышена, — право, а не обязанность налогоплательщика. Если уточненную декларацию вы решили не подавать, достаточно просто ответить на требование.
Предпринимателю повезло, что он завысил доход в декларации по сравнению с реальным, а не занизил его. Иначе пришлось бы заплатить штраф — обычно 20% от неуплаченной суммы — и пени. Сдавать уточненную декларацию в этом случае было бы обязательно.
В итоге предприниматель ответил налоговой, что расхождения совсем небольшие — 2 тысячи. Выяснять, почему в требовании спрашивают про 4 млн, необязательно. Главное — ответить по существу.
Как должно быть. Требование могут прислать в рамках проверки контрагента — это так называемая встречная налоговая проверка, встречка. По встречке просят документы, которые подтверждают сделки с каким-то одним контрагентом. Если с ним было мало взаимоотношений, то ответить просто. Если встречка прилетела по ключевому поставщику или покупателю — придется много копировать.
Срок представления документов по встречной проверке — 5 рабочих дней. К требованию о представлении документов во время встречки прикладывается копия поручения той налоговой, что проверяет контрагента. Запросить могут договоры, счета, акты выполненных работ, акты сверок, оборотно-сальдовые ведомости и другие документы.
Как бывает. Я ИП уже много лет — и однажды получила в рамках встречной проверки требование представить счет, договор, акты приемки-сдачи услуг, акты сверки и платежные поручения по контрагенту-организации.
Памятник я заказывала в интернет-магазине, оплачивала личной картой — никаких документов по сделке, кроме квитанции об оплате, у меня не было.
Как отвечать на требование. Налоговая инспекция вправе запрашивать информацию, необходимую для проверки, не только у налогоплательщиков, но и у любых других лиц. Однако если сделка личная, то обычный гражданин не обязан составлять и хранить документы по ней.
Даже если вы ИП, требовать у вас могут только те документы, что служат основанием или подтверждением начисления или уплаты налогов и сборов, а также основанием для подтверждения расходов.
Поэтому на требование я ответила, что заказ у организации делала в личных целях, к предпринимательской деятельности он отношения не имеет. Акт приемки-сдачи работ не подписывала.
Как должно быть. Налоговая инспекция может писать письма: рассылать информационные сообщения, напоминать о сроках уплаты налогов, пояснять свое мнение. Это справочная информация для налогоплательщика. На такие письма отвечать не надо.
Как бывает. Почему-то иногда вместо писем налоговая предпочитает присылать требования.
Например, один предприниматель нанимал работников, платил им зарплату и сдавал все положенные отчеты, включая расчет по страховым взносам. Потом работники уволились, а предприниматель продолжил сдавать отчеты, но уже с нулевыми показателями на всякий случай, чтобы не получить штраф за несдачу расчета.
Его налоговая решила разъяснить предпринимателю, что сдавать нулевой РСВ ему не надо. А сообщить это решила требованием.
Как отвечать на требование. Получить такое требование гораздо приятнее, чем любое другое. Ведь здесь предпринимателя освобождают от части ежеквартальной рутины. Главное — на радостях не забыть, что на требование надо ответить. Отправить квитанцию, написать ответ и послать его в налоговую — обязанность налогоплательщика. Она не зависит от того, что написано в требовании.
Предприниматель ответил так: «Нулевой расчет по страховым взносам обязуюсь не сдавать».
10 ловушек, связанных с требованиями, которых следует избегать
Небрежное отношение к разработке и управлению требованиями часто приводит к тому, что проекты по разработке программного обеспечения оказываются сложными или проваливаются. Вот десять распространенных ловушек, с которыми можно столкнуться, если не принимать требования всерьез. Я описываю симптомы, которые могут указывать на то, что вы стали жертвой одной из ловушек, а также некоторые возможные решения. Более подробную информацию обо всех этих ловушках можно найти в книге «Требования к программному обеспечению«, 3-е издание, авторы Karl Wiegers и Joy Beatty.
Первая ловушка: Непонимание того, что такое требования
Симптомы: Слово «требования» означает разные вещи для разных людей. В представлении руководителя требования могут быть высокоуровневой концепцией продукта или видением бизнеса. Требования разработчика могут выглядеть как дизайн пользовательского интерфейса. Требования, предоставляемые заказчиком, часто на самом деле являются идеями решений (см. ловушку № 10).
Одним из предупреждающих признаков является то, что заинтересованные стороны ссылаются на «требования» без уточняющих прилагательных. У участников проекта могут быть разные ожидания относительно того, насколько подробными должны быть требования. Другой признак — пользователи предоставляют «требования», но разработчики все еще не уверены, что именно нужно создавать. При обсуждении, сосредоточенном исключительно на функциональности, можно упустить из виду другую важную информацию о требованиях.
Решения: Все участники проекта должны понимать основные концепции, терминологию и практику разработки требований. Я мыслю в терминах трех уровней требований (Рисунок 1). Бизнес-требования описывают высокоуровневые бизнес-цели организации или клиента, запрашивающего систему или продукт. Они отвечают на вопрос: Почему мы беремся за этот проект?
Рисунок 1: Три уровня требований к программному обеспечению
На втором уровне рассматриваются требования пользователей: что пользователи смогут делать с продуктом. Они могут быть зафиксированы в виде сценариев использования или пользовательских историй. Однако сами по себе сценарии использования не обеспечивают достаточной детализации, чтобы разработчики знали, что нужно разрабатывать. Поэтому бизнес-аналитик (BA) должен вывести конкретные функциональные требования к программному обеспечению из примеров использования. Разработчики не реализуют напрямую требования бизнеса или пользователей — они реализуют отдельные функциональные требования.
Другие типы знаний о требованиях включают атрибуты качества, бизнес-правила, ограничения проектирования и реализации, а также требования к внешнему интерфейсу. Изучите их все во время разработки, чтобы не упустить что-то важное. Многие из этих типов требований обычно включаются в спецификацию требований к программному обеспечению или SRS.
Вторая ловушка: Недостаточное вовлечение клиентов
Симптомы: Однажды я видел, как клиенты отвергли новую информационную систему при первом же знакомстве с ней, то есть на начальном этапе внедрения. Это мощный, но запоздалый и болезненный признак недостаточного вовлечения клиентов. Пользователи иногда считают, что BA по техническому анализу или разработчики должны знать, что им нужно. Некоторые пользователи утверждают, что они слишком заняты, чтобы тратить время на требования.
Одним из ранних признаков недостаточного вовлечения клиентов является то, что требования предоставляют не реальные пользователи, а их заменители — менеджеры, сотрудники отдела маркетинга или даже разработчики. Другим признаком является то, что разработчики вынуждены принимать многие решения по требованиям, не имея достаточной информации. Если ни один из классов пользователей продукта не внес свой вклад, кто-то будет недоволен результатом.
Решения: Стремитесь к сотрудничеству между представителями заказчика, BA и командой разработчиков. Начните с определения различных классов пользователей. Классы пользователей — это группы, которые отличаются по частоте использования продукта, используемым функциям, уровню привилегий или другим признакам. Затем определите индивидуальных чемпионов продукта, которые будут представлять определенные классы пользователей. Представители продукта собирают информацию от других членов своего класса пользователей, предоставляют требования пользователей BA, а также вносят свой вклад в атрибуты качества и приоритеты требований.
Ваши представители пользователей также могут просматривать письменные требования, оценивать прототипы и предоставлять обратную связь по постепенным релизам, как в agile-разработке. Стремитесь к постоянному взаимодействию с пользователями, а не только к проведению семинара или двух семинаров в начале проекта.
Третья ловушка: Нечеткие, двусмысленные и неполные требования
Симптомы: Вы сталкиваетесь с двусмысленностью, если формулировка требования может иметь несколько различных значений, и вы не уверены, какое из них правильное. Более коварная форма двусмысленности возникает, когда несколько человек по-разному интерпретируют требование. Каждый приходит к выводу, что его интерпретация верна, и двусмысленность остается незамеченной до тех пор, пока ее не придется устранять.
Еще один признак нечетких или неполных требований — отсутствие в SRS информации, необходимой разработчикам. Например, если вы не можете придумать тесты для проверки правильности выполнения каждого требования, значит, ваши требования определены нечетко. Конечным симптомом нечетких требований является то, что разработчики вынуждены задавать много вопросов BA или заказчикам, или им приходится догадываться о том, что на самом деле предполагается.
Решения: Избегайте использования субъективных и двусмысленных по своей сути слов при написании требований. Такие термины, как минимизировать, максимизировать, оптимизировать, быстрый, удобный для пользователя, интуитивный, надежный, улучшенный, эффективный и поддержка являются особенно уязвимыми выражениями.
Чтобы устранить двусмысленность, поручите команде, включающей представителей различных точек зрения, тщательно проанализировать требования. В число подходящих специалистов входят:
BA, который написал требования, и, возможно, другой опытный BA
Клиент или представитель отдела маркетинга, который их предоставил
Разработчик, который должен их реализовать
Тестировщик, который должен проверить их в продукте
Написание концептуальных тестов на основе сценариев использования и функциональных требований кристаллизует видение того, как программное обеспечение должно вести себя при определенных условиях. Это позволяет выявить двусмысленности и недостающую информацию на ранних стадиях.
Прототипы делают требования более осязаемыми. Оценка прототипа — отличный способ прояснить пробелы в ваших знаниях и достичь общего понимания. Визуальные модели анализа, такие как диаграммы потоков данных, диаграммы взаимосвязей сущностей и диаграммы переходов состояний, предоставляют альтернативные представления требований, которые часто выявляют пробелы в знаниях.
Определите исключения, которые должна обрабатывать система, а также то, что пользователи должны делать с системой. Хорошие разработчики тратят много времени на написание кода для обнаружения, предотвращения и восстановления после всех вещей, которые могут пойти не так. Им и пользователям очень помогает, если бизнес-аналитик работает с пользователями, чтобы определить эти условия ошибок и способы их обработки.
4 ловушка: Неприоритетные требования
Симптомы: «Нам не нужно расставлять приоритеты в требованиях», — сказал представитель пользователя. «Они все важны, иначе я бы их вам не предоставил». Признание всех требований одинаково важными не помогает менеджеру проекта реагировать на новые требования или на изменения в реальности проекта (персонал, график, цели по качеству). Если неясно, какие функции можно отложить во время слишком распространенной «фазы быстрого анализа» в конце проекта, вы рискуете получить неприоритетные требования.
Другим симптомом этой ловушки является то, что почти все ваши требования считаются высокоприоритетными. Различные заинтересованные стороны могут по-разному интерпретировать «высокий» приоритет, что приводит к несовпадению ожиданий относительно того, какая функциональность войдет в следующий релиз. Пользователи могут не решаться расставить приоритеты, потому что боятся, что низкоприоритетные элементы никогда не будут реализованы. Но если вы не можете вместить все желания в рамки проекта, не лучше ли знать, какие из них отложить или опустить?
Решения: Относительный приоритет реализации — это важный атрибут каждого варианта использования, пользовательской истории, функции или функционального требования. Высокий приоритет может быть основан на ожидаемой частоте использования, удовлетворении наиболее важных классов пользователей, реализации основных бизнес-процессов или соответствии нормативным требованиям. Распределите каждый элемент в вашем бэклоге на конкретный релиз или итерацию на основе его приоритета.
Приоритет включает в себя как важность, так и сроки. Если вы используете трех- или четырехуровневую шкалу приоритетов, четко определите категории, чтобы способствовать последовательной классификации и общим ожиданиям. Вот мои определения:
Высокий: должно быть включено в следующий релиз или итерацию
Средний: необходимо, но может подождать до следующего релиза
Низкий: мы можем прожить без этого, если это необходимо
Пятая ловушка: Создание функциональности, которую никто не использует
Симптомы: Иногда я внедрял функции, которые, как клялись пользователи, были им необходимы, но потом никто никогда их не использовал. Это расстраивает. Остерегайтесь клиентов, которые не отличают блестящий «хром» от необходимой «стали», которая должна присутствовать, чтобы программное обеспечение было полезным. Остерегайтесь разработчиков, которые добавляют ненужную функциональность, которая может быть не нужна пользователям. Некоторые предлагаемые функциональные возможности не имеют четкой связи с известными задачами пользователей или достижением ваших бизнес-целей.
Решения: Отслеживайте каждое функциональное требование вплоть до его происхождения, например, конкретного случая использования, системного требования более высокого уровня или бизнес-правила. Создавайте функциональные требования на основе примеров использования, чтобы избежать бесхозных функций. Если вы не знаете, откуда взялось требование, задайтесь вопросом, действительно ли оно вам нужно.
Определите класс пользователей, которым нужна каждая функция или сценарий использования. Написание пользовательских историй в форме «Как ( ), я хочу ( ), чтобы ( )» позволяет четко определить, какой класс пользователей получит выгоду.
Аналитическое определение приоритетов функциональных требований, вариантов использования или функций также поможет вам избежать этой ловушки. Избегайте реализации требований, которые влекут за собой большие затраты и приносят низкую ценность для бизнеса.
Ловушка 6: Аналитический паралич
Симптомы: Если кажется, что разработка требований длится вечно, возможно, вы стали жертвой аналитического паралича. Новые версии SRS могут появляться так часто, что номера версий напоминают IP-адреса. Чрезмерно усердный BA может попытаться смоделировать все требования или создать прототип всей системы, прежде чем объявить требования готовыми к реализации. Возможно, лица, принимающие решения, так и не пришли к согласию относительно базовой линии требований. Аналитический паралич — это большой риск чисто водопадного подхода к разработке программного обеспечения.
Решения: Ваша реалистичная цель — это не идеальный SRS, а набор четко сформулированных требований, чтобы часть разработки могла продолжаться с приемлемым риском. Выберите такой жизненный цикл разработки, который позволит вам реализовывать части требований по мере их понимания. Инкрементные подходы к разработке, такие как agile, частично развились для того, чтобы избежать аналитического паралича. Обозначьте пробелы в ваших требованиях символом TBD (будет определено позднее) для обозначения дальнейших действий. Моделируйте и создавайте прототипы только сложных, новых или малопонятных частей системы, чтобы уточнить требования.
Седьмая ловушка: Расползание рамок
Симптомы: Большинство проектов сталкиваются с угрозой расползания рамок проекта, поскольку в процессе разработки постоянно добавляются новые требования. Как правило, сроки проекта не меняются, больше ресурсов не выделяется, и ничего не исключается для размещения новой функциональности.
Расползание рамок происходит наиболее вероятно, когда объем проекта изначально не был четко определен. Если новые требования были предложены, затем отклонены, но всплыли позже — с постоянными спорами о том, есть ли им место в системе, — значит, ваше определение рамок слишком размыто. Новые требования, которые проникают через заднюю дверь, а не через эффективный процесс изменений, могут привести к превышению сроков.
Решения: Во всех проектах следует ожидать некоторого увеличения требований. В ваших планах должны быть предусмотрены буферы для такого хода вещей. Всякий раз, когда кто-то предлагает новую функциональность, спросите: «Входит ли это в рамки?». Чтобы ответить на этот вопрос, задокументируйте видение и рамки проекта и используйте их как основу для принятия решения о том, какие изменения следует включить.
Расползание рамок часто указывает на то, что требования изначально были не учтены, поэтому эффективные методы получения требований очень важны. Установите значимый процесс для определения базового набора требований для следующего релиза или нового этапа разработки. Дополнительные идеи о том, как справиться с этой ловушкой, см. в моей статье «Managing Scope Creep: Why, When, and How».
8 ловушка: Несовершенный процесс внесения изменений
Симптомы: Наиболее ярким симптомом является то, что в вашем проекте отсутствует определенный процесс обработки изменяющихся требований. Новая функциональность может стать очевидной только во время тестирования системы. Некоторые люди обходят этот процесс, рассказывая своим приятелям-разработчикам о желаемых изменениях.
Другие признаки недостатков процесса изменений: неясно, кто принимает решения о предлагаемых изменениях, решения об изменениях не доводятся до сведения всех, кого они касаются, а статус каждого запроса на изменение не всегда ясен.
Решения: Определите практический процесс управления изменениями для вашего проекта. Вы можете дополнить этот процесс инструментом отслеживания проблем или вопросов для сбора, отслеживания и передачи изменений. Однако инструмент не заменит процесс. Создайте комиссию по управлению изменениями для рассмотрения предлагаемых изменений и принятия обязательных решений о внесении или отклонении изменений. Определите приоритет каждого предложенного изменения требований по отношению к списку требований, которые еще предстоит реализовать.
Следуйте своему процессу управления изменениями для всех изменений, учитывая, что при принятии новых требований может потребоваться пересмотр обязательств.
Девятая ловушка: Неэффективный анализ воздействия изменений
Симптомы: ВА, разработчики или руководители проектов иногда соглашаются внести предложенные изменения, не обдумав их последствия. Изменение может оказаться более сложным, чем предполагалось, занять больше времени, чем было обещано, оказаться технически или экономически невыполнимым или противоречить другим требованиям. Еще одним признаком неэффективного анализа воздействия изменений является то, что разработчики продолжают сталкиваться с более уязвимыми компонентами системы по мере внедрения изменений.
Решения: Прежде чем сказать: «Конечно, мы можем это сделать», поймите последствия согласия на внесение изменений, определите, какую работу необходимо выполнить, и оцените влияние на трудозатраты и сроки. Каждое изменение потребует ресурсов: изменения никогда не бывают бесплатными. Отслеживайте информацию об изменениях, чтобы определить все уязвимые компоненты системы. Предоставьте оценки затрат и выгод каждого предложения по изменению лицам, принимающим решения, чтобы они могли разумно принять на себя обязательства.
Десятая ловушка: Решения, представленные в виде требований
Симптомы: Многие из моих клиентов-консультантов говорили мне, что эта ловушка представляет собой их самую большую проблему с требованиями. Пользователи зачастую представляют эскизы экрана как свои требования, а обсуждения в рамках процесса выявления требований сосредоточены на дизайне пользовательского интерфейса, а не на базовых потребностях. Команда может рассчитывать на то, что прототипы заменят письменные спецификации требований. Если вы обнаружите, что обсуждение требований сосредоточено на том, как будет выглядеть продукт и его возможностях, а не на том, что пользователи смогут с ним делать, возможно, вы попали в эту ловушку.
Решения: Прежде чем команда погрузится в разработку дизайна экрана и детальной функциональности, BA должен провести обсуждение для того, чтобы выяснить требования пользователей. Сосредоточьтесь на бизнес-процессах и задачах пользователей, на том, что система должна помочь им выполнить. Из этих пользовательских требований BA может вывести необходимые функциональные требования, которые должны реализовать разработчики.
BA должен прислушиваться к сигналам, указывающим на то, что пользователи представляют решения, а не истинные требования. Когда вы слышите идею решения, задавайте вопросы, чтобы понять, какая реальная потребность стоит за каждым предлагаемым решением. Является ли эта идея решения истинным ограничением, которое должны соблюдать разработчики? Или это просто одно из представлений говорящего о том, как может быть реализована та или иная возможность?
Основные составляющие отличных требований
Эти десять ловушек — не единственные, скрывающиеся на минном поле требований, но они одни из самых распространенных и самых серьезных. Чтобы справиться с ними, попробуйте использовать следующие подходы.
Обучайте разработчиков, менеджеров и заказчиков как практическим требованиям, так и области применения.
Установите партнерские отношения между заказчиком и разработчиком.
Используйте итеративный и инкрементный подход к разработке требований.
Используйте стандартные шаблоны для концепции и объема, сценария использования и подробных документов требований.
Проводите как неформальные, так и формальные обзоры требований.
Заранее составляйте тесты на соответствие требованиям.
Вдумчиво расставляйте приоритеты требований, чтобы быстро получить максимальную ценность для бизнеса.
Прививайте дисциплину для последовательной и эффективной работы с изменяющимися требованиями.
Эти подходы помогут вашему следующему проекту заложить прочный фундамент для эффективного строительства и успешного внедрения. Это гораздо лучше, чем просто спросить у клиента: «Что вы хотите?», а затем сделать все возможное для того, чтобы получить результат.
Если вы интересуетесь требованиями к программному обеспечению, бизнес-анализом, управлением проектами, качеством программного обеспечения или консалтингом, Process Impact предлагает множество полезных публикаций, загрузок и других ресурсов. Последняя книга Карла — «The Thoughtless Design of Everyday Things».
Всех желающих приглашаем на открытый урок «Бизнес- и системный анализ как подготовка к тестированию качества программного продукта». На этом демо-уроке обсудим:
— Зачем нужны User story для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?