Лучшее, чему меня научила школа — задавать вопросы. Не бояться выглядеть глупой и не бояться «потерять репутацию». Общаясь с коллегами, я пришла к выводу, что этого пути придерживаются далеко не все: сотрудники, которые боятся потерять работу или с различными синдромами вроде самозванца, предпочитают помалкивать и во всем разобраться самостоятельно, «потом, после дейлика».

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

А ведь порой вопрос — единственный способ услышать, что от тебя хотят, расставить приоритеты и, иногда, вовсе закрыть проект. Почему? Вопросы помогают открыть, что • заказчик знает, чего хочет, но не может сформулировать, а вопросами мы ему помогаем; • заказчик думает, что знает, как решить проблему (сразу приносит решение), а мы на этапе сбора сведений уже поняли, что проект надо вести по другим рельсам; • исполнители считают, что знают лучше заказчика, поэтому на этапе вопросов мы проясняем реальную ценность, чтобы не отклониться и снова не потерять деньги.

Это небольшое пособие, в котором собраны главные мы ли по сбору требований к ПО. Читается быстро и может выступать в роли памятки для проджектов —> https://clck.ru/3NsQFM

Такие дела.