С одной стороны, Техническое задание умереть не может. Спецификация требований есть прямое выражение сути системного подхода и мышления. Чем сложнее система тем больше аккуратности и внимательности требуется при внесении любых изменений. И создаваемые системы проще не становятся...
С другой стороны, Факты упрямая вещь - честная процессная/архитектурная работа с каскадом сформированных спецификаций, классические переходы As-Is To-be попадаются гораздо реже, из стартапов рождаются единороги, и там точно не было и не ожидается никаких спецификаций...

Приглашаем к обсуждению на круглом столе:

• Влияние на Бизнес и Системный анализ двух парадигм: проектной и продуктовой.
• Как переходить от одной парадигмы к другой с минимальными личными и организационными потерями.
  
  

В этом году для нашего отдела системного анализа была задача: найти людей на 15 вакансий системных аналитиков. 6 вакансий было в моей группе. Последнюю из 6 вакансий я закрыла в конце декабря. Сотня с лишним резюме, десятки первичных собеседований, 3-5 результирующих собеседований на каждую вакансию. В докладе хочу рассказать о полученном опыте: карьерные паттерны, типичные наборы знаний кандидатов, несовпадение их с профилем вакансии и нашим представлением о сферическом аналитике в вакууме. 

История внедрения и использования EA и TFS в Лаборатории Касперского

Современные решения Лаборатории Касперского содержат в себе не только приложения/продукты, но и сервисы и инфраструктуру, позволяющие в кратчайшие сроки обновлять антивирусные базы, получать вердикты о вредоносном программном обеспечении из облака и многое другое. Кроме того, во времена широкого распространения кросплатформенных решений резко возросла роль сервисов, которые позволяют клиентским приложениям на разных платформах отображать и обрабатывать одну и ту же информацию. Эти и подобные решения разрабатываются и поддерживаются в ЛК в виде инфраструктурных проектов. В докладе рассматриваются особенности активностей и техник анализа в инфраструктурных проектах в сравнении с продуктовой разработкой.

В процессах создания ПО у нас в лаборатории Касперского закреплены только основные вещи, каждая команда вправе сама определять, как управлять границами (scope) релиза своего продукта, компонента, сервиса. За последние 2 года в результате естественного отбора сформировались несколько общих, наиболее удобных для большинства команд типов трассировок, которые позволяют вести учет как скоупов релизов для менеджера проекта (исполнителя), так и учет требований, предъявляемых к нескольким продуктам, для владельца требований (заказчика). Мы описали такие общие варианты трассировок, подготовили для них инструментальную поддержку и теперь переиспользуем их там, где это помогает проекту эффективней достигать его целей. В этом докладе я опишу получившиеся варианты как шаблоны (pattern'ы) и покажу примеры их использования.