Возникла потребность разложить по полочкам проблему планирования: решение исследовательских задач в проектах, особенно в проектах исследовательских (научных и технических). В качестве области применимости, рассмотрим "родное" нам пересечение: ИТ + разработка ПО + прикладная математика + ИБ + проектирование систем и процессов (иначе можно было бы пришлось методы типа опытов над животными добавить).
Камень преткновения при обсуждении таких задач - риски выполнимости и сроки/трудоемкость. При попытке декомпозиции задачи для детализации рисков - часто ступор ("исследование - это же понятно что надо исследовать") или уход в рекурсию:"чтобы сделать обзор нужно подготовить критерии и сделать обзор".
Уже на этом этапе менеджеры и специалисты могут войти в клинч: программисты включат песню про выпас котов, исследователи/учёные закатывают глаза и просят полжизни на задачу "Подумать о...", проектировщики требуют калькулятор, нормирующий каждую задачку.
Если не получается договориться о внятных входах/выходах/параметрах задачи - видимо мы не пришли к общему пониманию сути исследования. Опыт показывает, что осознание этого - первый шаг к дальнейшему прояснению ситуации. Не нашел годных классификаций, напишу как вижу - по мотивам интернетов и википедий [wiki].
qПервичное исследование/изучение вопроса – например контент анализ [wiki], формирование векторов сбора информации, уточнение постановки задачи
qСбор информации. Проведение экспериментов (замеров). Экспертный опрос, анкетирование
qСистематизация информации – обзор, каталогизация, тегирование, классификация. Нормализация и фильтрация данных
qСтруктурный анализ. Выявление (неочевидных) характеристик и свойств и их параметров (категорий, допустимых значений)
qОбработка данных. Статистический анализ, кластеризация, выявление скрытых закономерностей и т.п. задачи, отталкивающиеся от фактических данных
qСинтез - проектирование решения/объекта под заданные характеристики
qЭкстраполяция и интерполяция. Выявление трендов, прогноз, восполнение отсутствующей информации
Перечень не претендует на соответствие требованиям к классификациям - скорее механизм, позволяющий "раскачать" диалог менеджера и исследователя, выработать обоюдно приемлемую структуру работ. В зависимости от многих факторов этот перечень может сильно отличаться даже у одного менеджера в разных проектах не говоря уже об организации или претензии на общность.
Важным результатом уточнения типа задачи будет проработка требований входов/выходов: если для сбора информации о, допустим инновационном подходе нано-кванто-антивирусного анализа достаточен вектор поиска информации, то в задаче типа "синтез" - нужны требования и ограничения. Если их нет, то и говорить надо о задаче разработки требований (а каким методом - опять же зависит).
Казалось бы довольно простая идея, а сколько раз во время разбора полётов выяснялось, что в плане проекта были оставлены подобные сюрпризы - ибо договориться так и не получилось.
