Точка сборки. Системно-аналитическое мышление

Что отличает хорошего аналитика? Существует много разных ролей аналитиков, но мы сейчас говорим про тех, которые обеспечивают реализацию всех задумок бизнеса в разработке ПО.

Какими навыками и умениями он должен обладать? Часто в обсуждении подобных тем встречается упоминание некоторого системно-аналитического (или системного, или аналитического мышления) — хорошо бы, чтобы аналитик им обладал. Но что это такое? Если рассматривать карты компетенций аналитиков, то на них встречается и знание нотаций, и знание предметных областей, и умение договариваться, и навыки выполнения конкретных действий, и многое другое. И иногда скупая строчка про аналитическое мышление. А ведь основной инструмент аналитика — это мозг, а умение его использовать существенно повышает эффективность всех остальных умений. И мы решили разобраться, что же стоит за словами аналитическое мышление, как его можно развивать и как проверять его наличие.

Вместо введения

Здесь и далее под системно-аналитическим мышлением (аналитическим мышлением, системным мышлением итп) мы понимаем те особенности мышления, которые отличают хороших аналитиков от не очень хороших.

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

Аспекты:

• умение смотреть на все с различных точек зрения/уровней абстракции/сторон итп, правильно выбирать эти точки зрения:
• умение видеть причинно-следственные связи:
• умение держать (определять и своевременно изменять) контекст:
• умение объективно/адекватно/качественно оценивать вероятности тех или иных событий/сценариев и т.п.

Умение смотреть на все с различных точек зрения/уровней абстракции/сторон итп, правильно выбирать эти точки зрения

Самый простой и всем известный пример: обсуждая требования с заказчиком не стоит (если в этом нет прямой необходимости) вдаваться в детали реализации. Добавление нового чекбокса на интерфейсе может порадовать функционального пользователя, но при этом стоить полгода разработки, что совсем не обрадует того, кому за это платить. Начальник отдела у заказчика не согласовывает ФС, потому что не хочет брать ответственность за сложные решения за год до пенсии. Для проекта выбирается технология X, потому что у нас есть специалисты по этой технологии. Для проекта выбирается технология Y, потому что мы хотим за счет этого проекта вырастить у себя специалистов по этой технологии. Для проекта выбирается технология Z, потому что у заказчика уже закуплены соответствующие лицензии.

Как развивать:

• общаться с различными заинтересованными лицами. Причем не только со стороны заказчика;
• изучать чужой опыт и пытаться понять, почему выбрано то или иное представление, решение, чьи интересы учитываются;
• при рассуждениях, моделировании одевать «шляпу» того или иного заинтересованного лица и пробовать смотреть на вещи с его точки зрения. Например, описать систему для потенциального покупателя/бизнес-заказчика;
• изучать и фиксировать терминологию различных заинтересованных лиц;
• развивать абстрактное мышление;
• искать неожиданные точки зрения, свежие взгляды на проблемы;
• пробовать переносить и адаптировать практики из одной области в другую;
• анализировать всегда и везде. Даже в бытовых вопросах пытаться применить практики анализа;
• ездить на обследования к заказчику и пытать реальных пользователей как они работают в системе или хотели бы работать.

Как выявлять:

• попросить человека примерить разные «шляпы», порассуждать о чем-то с точки зрения различных ролей;
• дать задание (конкретный кейс) и попросить расписать несколько точек зрения на функциональность. Попросить посчитать сколько заинтересованных лиц в кейсе;
• дать абстрактную задачу (типо разработать идеальный фломастер) и посмотреть на представленные точки зрения;
• спросить у предыдущего работодателя;
• попросить описать проект с разных точек зрения. Например описать систему в трех предложениях для различных заинтересованных сторон: потенциального заказчика, рекламного плаката, архитектора, пользователя, разработчика.

Умение видеть причинно-следственные связи

Примеры можно брать из предыдущего пункта. Анализ причин или последствий различных решений подразумевает, что на каждом этапе такого анализа мы смотрим на результат с различных точек зрения. «Заказчик не знает чего хочет» — я слышал эту фразу от многих опытных аналитиков. Не менее часто сталкивался с тем, что говорят не ЧТО хотят, а КАК это сделать.

Как развивать:

• играть в игры. Игры, подразумевающие логическое мышление и установление причинно-следственных связей;
• читать литературу с примерами установления причинно-следственной связи (например, Шерлок Холмс);
• рефлексировать о себе. Оценивать последствия своих действий;
• расширять кругозор (больше информации — больше причинно-следственных связей);
• изучать дисциплины, требующие соответствующего мышления (например, матан, языки программирования);
• поработать Product Manager. Таким, который изучает рынок, формулирует и проверяет гипотезы;
• визуализировать причинно-следственные связи для лучшего запоминания;
• проходить обучение с обратной связью, когда на твои решения тебе быстро дают обратную связь по последствиям;
• изучать опыт успешных проектов;
• заниматься функциональным тестированием;
• проводить научные эксперименты (или ненаучные, но с соблюдением требований к научным экспериментам);
• использовать моделирование и трассировки между моделями и элементами моделей.

Как проверять:

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

Умение держать (определять и своевременно изменять) контекст

История выше хорошо показывает важность контекста. Самая первая диаграмма, с которой обычно начинается анализ — это контекстная диаграмма — описание контекста.

Как развивать:

• регулярно общаться с экспертами. Задавать правильные вопросы экспертам и анализировать обратную связь;
• пробовать себя в разных ролях: например руководителя проекта;
• следить за трендами и актуальностью. Сопоставлять тренды с текущим проектом;
• самому стать экспертом/лидером;
• расширять кругозор;
• изучать best-practice;
• производить оценку проекта/требований с учетом имеющихся ресурсов, приоритетов заказчика, смежных проектов, целей компании, последующих внедрения, эксплуатации и поддержки решения;
• описывать систему/свой проект от общего к частному;
• фиксировать окружение проекта в концептуальном виде;
• выстраивать систему проектных артефактов и документов так, чтобы они подсказывали о необходимости учитывать контекст. Например: определить несколько уровней детализации описания бизнес-процессов или сделать шаблон описания БП который требует обязательно выделять взаимодействующие системы, сделать шаблон спецификации, который требует фиксировать исходную проблематику и тд.

Как проверять:

• спросить о предыдущем опыте (роли и предметные области);
• задать логическую задачу;
• дать конкретный кейс на выявление контекста;
• дать задачу на выявление рамок проекта;
• попросить описать DoD какой-нибудь задачи.

Умение объективно/адекватно/качественно оценивать вероятности тех или иных событий/сценариев

«Нам никогда не понадобится эта функциональность» — уверенно говорит заказчик, чтобы через 2 недели (в хорошем случае) прийти и спросить, как бы это сделать. Не всегда необходимо автоматизировать 100% того, что хочет заказчик, но достаточно автоматизировать 90%, если правильно определить, что в эти 90% входит. Что следует относить к process management, а что к case management. На какие предполагаемые изменения стоит закладываться, а на какие нет. Сколько в конце-концов накидывать к оценке на риски.

Как развивать:

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

Как проверять:

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

Итого

Попробуем обобщить результаты и понять, какие способы развития мышления будут наиболее полезны для аналитика:

• расширение кругозора. Здесь и изучение best-practice, и общение с коллегами и экспертами, и попытки примерить другие роли и так далее;
• самоанализ. Регулярный анализ последствий своих решений, действий и предположений;
• структурирование. Моделирование и визуализация полученной информации;
• постоянное обучение. Использование любой возможности для повышение тех или иных своих аналитических умений.

И способы проверки:

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

Узнаете типичные вопросы на собеседовании? Как ни странно, многие нелюбимые соискателями задачи типа «как сдвинуть гору фудзи», «написать требования к фломастеру» и.т.п на самом деле дают достаточно материала для оценки кандидата, если вы, конечно, в состоянии этот материал правильно оценить.

Опытный аналитик прищурит глаз и скажет: так я вам то же самое мог сказать и без всяких конференций. Мог, но это было бы частное мнение одного, пусть и хорошего, аналитика. Вы же в курсе про теорию вероятности и все такое?

 

Вершинин Егор (@GoryinyichZmey), Митропольский Артем (@AMitropolskiy).

@spbcoa