Изучать лучшие практики проектирования систем и пробовать их на своих проектах всегда хорошо, а знать о возможных "подводных камнях" еще лучше.

Признаки, что на этапе проектирования что-то пошло не так:

• команда задает много вопросов к постановке задачи;
• разработчики находят нереализуемые требования и просят изменить их;
  
• тестировщики находят много неучтенных кейсов в процессе тестирования;
  
• приходит запрос на расширение функциональности от заказчика, и чтобы его поддержать, нужно добавлять "костыли".

Доклад посвящается ошибкам проектирования, которые встретились в моей практике, как их избежать, и как взять ситуацию под контроль, если они все же настигли. Он будет полезен как системным аналитикам, работающим с проектированием архитектуры систем, так и бизнес-аналитикам, собирающим и описывающим требования к разработке.

Организовывать правильные процессы в IT-проектах дорого. А если IT-проект запускают два разработчика – невозможно. Они берут на себя все роли: заказчиков, тестировщиков, дизайнеров, маркетологов, бухгалтеров и уж тем более аналитиков.

Успешный стартап-проект растет. Появляется потребность быстрее развиваться – новые разработчики, улучшать качество – тестировщики, рекламировать, много разных задач. И вот, маленький зверек превращается в огромного монстра, а как он работает «от» и «до» знает только текущая команда, но и это не точно.

Люди меняются – теряются знания о продукте. Как узнать о том, почему тот или иной процесс выполняется именно так, без поиска нужного разработчика и доступа к коду? Смотреть в документацию, которую надо создать.

В какой-то момент жизни IT-проекта остро встает вопрос документирования. Например, через 10 лет от момента запуска. Описать неописуемое, запустить процессы анализа и документирования – история внедрения системного аналитика в команду.