Карта компетенций аналитика: собрала очередную версию и поняла, что оцениваю одно умение дважды

[Chemist_modeler]

В моем детстве запомнился плакат на турбазе:

Купили овощи, фрукты купили.

Не ешьте сразу, съедите потом!

Самое главное позабыли:

Покупку промыть и обдать кипятком.

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

Может быть, я невнимательно смотрел, но не увидел в Ваших таблицах таких вот "центровых" пунктов, определяющих переход.

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

[kseonyka]

Как же я соскучилась по таким развернутым комментариям! На разных площадках свои правила, и супер, что на Хабре статью действительно читают. Причем так внимательно, что потом приходится перечитывать собственную таблицу 😅 Спасибо вам за это.

По сути — я думаю так же. Найти противоречие, увидеть сценарий, который ломает правила, или спросить «а нам вообще нужна эта функция?» — для меня тоже признаки зрелости аналитика. Ведь требование можно прекрасно описать, а потом выяснить, что реализовывать его незачем.

Мы стремимся к AI-first в аналитике, и для меня это повышает требования к проверке. Можно попросить ИИ прочитать требования глазами разработчика, сыграть неудобного заказчика, поискать альтернативные сценарии. Но нужно еще понять, какие вопросы задать, какого контекста не хватает и насколько ответу можно верить. За решение все равно отвечает человек.

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

Вобщем, Excel, конечно, многое умеет и дает основу для сверки, но переход между грейдами пока остается на моей совести)

[Mik9856]

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

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

Инструментами можно овладеть, они лишь дополнения к грейду.

[Chemist_modeler]

Ии ошибается , потом просто просит прощения

Я прошу прощения, на что-то не то нажал и отправил два пустых комментария., если модератор может, очень прошу удалить их.

Хотел только заметить, что человек тоже нередко делает ровно то же самое: ошибается и потом просит прощения. И это не есть плохо! Хуже - когда не видит свою ошибку, или видит, но не хочет ее признать и за нее извиниться.

Различие, на мой взгляд, не в этом. ИИ не несет ответственности за свои предложения - просто потому, что не обладает таким правом, нести ответственность. Вся ответственность за иишные решения - на тех, кто их одобрил, и это не ИИ. Это мы, люди.

ИИшная аналитика может быть правильной или глючной. Но судить об этом - нам, а не ИИ. Если данный человек на это не способен - то аналитик здесь не он. Аналитик, в том числе, должен быть способным проверять предложения ИИ. А кто просит прощения и кто не просит - imho, не суть важно.

[kseonyka]

Ох, у меня как раз недавно был такой случай со стажером 🤦‍♀️ Поручила ему спроектировать модульную логику ERP и связать три личных кабинета (клиента, менеджера и поставщика): найти противоречия в текущей структуре и добавить ИИ-сценарии. В итоге логика стала еще сложнее -- так, что я не смогла её раскопать. Когда начали разбирать решение, он не смог объяснить, зачем нужны эти изменения, и последовательно пройти весь сценарий от одного кабинета к другому.

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

❓ Господа, а у вас есть ИИ-агенты-критики? 😈 Сталкиваетесь с ситуацией, когда нужно протестировать решение и выявить неточности? Интересно просто, сами вы это делаете или ИИшке поручаете.

[kseonyka]

Такие дела. Согласна, грейд должен отражать сложность задач, самостоятельность и ответственность за решение. Владение инструментами — лишь часть этой оценки.

С ИИ получить черновик стало проще, а проверить его логику, ограничения и последствия по-прежнему нужно человеку, несмотря на армию агентов-тестировщиков. Именно эту разницу я и пыталась учесть при пересмотре карты.

Опыт при этом ценен выводами из ошибок. Страдание — запоминающийся, но довольно дорогой способ обучения 🙂