Привет!
Наверное, свой текстовый выход в свет стоило начать с ожиданий, а не с подсчета рабочей мощности. Себе объясняю такую последовательность тем, что сначала надо было копнуть, чтобы подтвердить хотя бы часть ожиданий.
Начну с того, что я 3 года занимаюсь методологией управления требованиями в телекоммуникационной компании в параллель с техническим управлением командой системных аналитиков\инженеров по требованиям. Хоть это и небольшой срок, но количество и размер вопросов, которые мы через себя пропустили достойно очень большого разговора. Здесь постараюсь выделить текущее и наболевшее в виде своих ожиданий.
Итак, мои ожидания от руководств, стажировок ШСМ и его сообщества:
1. Натренировать в себе навыки построения логичных, аккуратных и пригодных для коллективной работы моделей и их анализа.
Один из кейсов из рабочей жизни, который проявил эту необходимость:
В разработке нашего решения задействовано множество команд, у которых есть свои создаваемые артефакты, объекты размышлений, обсуждений. Артефакты появлялись, объекты выделялись достаточно стихийно и спонтанно исходя из опыта работы в других компаниях и благодаря каким-то светлым точечным идеям. Вопрос объединения этих процессов в какую-то стройную уровненную структуру, в которой понятно:
- кто каким уровнем управляет (например, программный менеджмент, проектный менеджмент, управление отдельной функциональной областью, отдельным компонентом)
- какой тест какое требование покрывает (acceptance, system, integration, unit…)
- какие требования из какой архитектуры, и наоборот, следуют (слоистая структура)
- какими факторами оперируют те или иные артефакты (то есть, где начинается и заканчивается “черный ящик”. Например, артефакт уровня решения не должен описывать структуру компонентов его составляющих)
Вопрос построения такой модели иногда возникал, но почему-то не получил должного внимания. И поэтому были очень частые и сложные вопросы по:
- помещению той или иной информации в тот или иной артефакт
- детализации артефакта
- ответственности тестирования за уровень системы
- построению traceability
Я такую модель построил и оказалось, что “дребезг” в ней не просто кажется, он виден невооруженным взглядом! Есть компонент, который разные команды помещают в абсолютно 2 разных уровня!
В рамках обучения хочется научиться понимать, насколько модель получается жизнеспособной, удобной. И отвечать на вопрос, скрывается ли в ней фатальный риск, который проявит себя в будущем каким-нибудь жестоким перекраиванием организации или системы артефактов. То есть, какие огрехи в модели можно считать особенностью ведения дел в организации и закрыть на них глаза, а какие тикающей бомбой.
2. Натренировать системное мышление. Как я его понимаю для себя, научиться учитывать в своих решениях всё то внешнее, окружающее, на что мое решение повлияет.
Примеры из рабочей жизни связаны с тем, что практически любой “чих” в команде аналитики приводит к изменению взаимодействия с какой-то другой командой: тестировщиками. писателями, разработчиками, проектным менеджментом и т.д. И вот часто такие безобидные на первый взгляд “чихи” приводят к большим пересмотрам процессов, переделками, откатам назад.
На текущий момент всё. Есть стремление к обретению понимания именно на высоких, абстрактных уровнях, после которых можно будет приземлять это понимание на большое (надеюсь) число приземленных задач.