Всем привет. Я всего пару лет работаю аналитиком в IT, фактически совмещая в себе функции бизнес и системного аналитика. Недавно я пришёл работать в один стартап, где я сейчас единственный аналитик, фактический я являюсь лидом аналитики. В отличии от компаний где я работал раньше - тут я несу ответственность за всю аналитику в компании, по бизнес и системной части. И я столкнулся с проблемой, что я не могу выстроить процесс вокруг своей работы. От меня требуется составление технической документации, и формализация бизнес требований, но у меня как будто ступор, за что бы я не взялся - сталкиваюсь со стеной из неопределенности. Мой предыдущий опыт из более или менее крупных компаний тут не работает.
Отсюда несколько вопросов:
1) Возможно кто-то уже сталкивался раньше с подобным и может рассказать о своём опыте?
2) У меня не очень большой опыт работы и я отдаю себе отчёт в том, что мне может не хватать каких-то компетенций для выстраивания корректного подхода, если у кого-то есть статьи или материалы, которые вы могли бы мне посоветовать - с радостью приму!
3) Возможно есть какие-то конкретные методики или инструменты для разрешения ситуаций подобных моей, когда нигде ничего не понятно, а нужно в сжатые сроки добиться определенности и получить результат, если порекомендуете курсы или материалы, буду также очень благодарен!
Я не аналитик, но раз у вас не хватает опыта в предметной области - спрашивайте у заказчика всё ято не понятно.
По технической документации - уточняйте у разработчиков, что им нужно. Если разработчик что-то спрашивает, значит документация не достаточно полная, тогда надо дополнять.
Для корректного ответа вы не указали главного - а какое у вас образование? Что вы реально знаете и какими компетенциями обладаете. Одно дела советовать бывшему сеньору-девелоперу, перешедшего на путь системного аналитика потому как "замордовали заказчики", а совсем другое вчерашнему школьнику, написавшему (или даже нет) полтора скрипта и решившего, что системному аналитику больше платят, чем юниор-программисту.
Без понимания этого даже непонятно, что вам советовать. А вот то, что вы сами не указали это в вашем вопросе - по сути ТЗ на некую работу (консультацию) которую вы просите для вас произвести других - очень плохой признак с точки зрения того, как думает (или должен думать) системный аналитик.
В общем- ждем вашего разъяснения.
dmshar, вы правы, с моей стороны это было некорректно.
У меня неполное высшее физфак МГУ, учился на общей физике, но так вышло, что институт пришлось оставить в пользу работы.
Первое время я работал менеджером проектов и с IT моя работа в принципе не было связана. После опыта манагером решил попробовать себя в бизнес анализе в IT, и пошёл в банк аналитиком. Собственно после банка я и пошёл в стартап.
Из компетенций могу выделить навыки сбора и формализации требований, базовые знания SQL и тестирования, пользование нотациями BPMN и UML.
Надеюсь ответил на ваш вопрос, спасибо!
Если вы аналитик то используйте эти навыки для достижения своей цели. Сформируйте цель, определите слабые места, недостаток компетенций, декомпозируйте. Если вы этого не можете сделать то вы не аналитик, а самозванец. Аналитик это одна из самых гибких профессий где умение номер ноль это справляться с новыми для себя проблемами
Моя проблема была в том, что в сложившейся ситуации я встал в удобную позицию «жертвы», ведь приятно просто опустить лапки и лечь на спину, даже не попытавшись повлиять на ситуацию.
Тем, кто столкнулся с похожей проблемой, могу сказать одно - если вы в тупике/ступоре/застряли, то не опускайте руки - пробуйте, пытайтесь, перебирайте варианты, набивайте шишки - опыт от ошибок станет для вас почвой под ногами. В ином случае вы просто утонете в болоте бездействия, апатии и саможаления.
Хороший аналитик должен разгонять туман неопределенности и делать абстрактные вещи конкретными, даже если придётся идти наощупь неделями или месяцами.
Если задача кажется неподъёмной - хороший аналитик вгрызается в неё, разрывает на кучу частей и ищет решение каждой части, чтобы потом склеить все в месте и создать цельную картину, и предложить решение.
Это даже не столько вопрос компетенций и опыта - сколько вопрос подхода. Ты либо занимаешь проактивную позицию и идёшь набивать шишки, чтобы в итоге найти решение, либо опускаешь руки и так никогда и не добираешься до истины.
Алексей Иванов, всегда пожалуйста. Сам сталкиваюсь регулярно с той же проблемой, хоть и Архитектор Решений и аналитика является одной из моих обязательных компетенций. Это все действительно больше о позиционировании и целеполагании. Ситуация тупика всегда связано именно с отсутствием видимого выхода, но это не значит что его нет - мы как-то в него же попали. То что мы попали в тупик означает то что либо мы плохо видели (сформировали) свою цель изначально (аналогия с густым темным лесом, который надо пересечь на пути к морю), либо что мы свернули куда-то не туда на своем пути. Это значит в обоих случаях что самым простым шагом будет вернуться в последнее место где мы четко понимали где находимся и откуда видно конечную цель. Иногда для этого надо вернуться к стартовой точке, но это не плохо по тому что мы уже знаем гарантированно один тупик - шансов попасть во-второй чуточку меньше
Посмотрите мой вопрос как объяснять. Он реально дал хороший отклик. Что же до вашей ситуации разбивайте все на подзадачи и жестко контролируйте, потом отпускайте возки где видите нормальное исполнение по графику. Где факап там спрашивайте в чем затык, часто люди запираются и роют не туда, простой вопрос выводит их на нужную дорогу, но нужно соблюсти баланс между навязчивостью и мягкой поправкой направления
Мой предыдущий опыт из более или менее крупных компаний тут не работает.
те на новом рабочем месте требования по созданию рабочей техдокументации отличаются? В чём? В применяемом ПО? Та же боль и с формализацией бизнес-требований? А результат должен быть вчера? Тогда, да, - в-однёх утопия(
3) Возможно есть какие-то конкретные методики или инструменты для разрешения ситуаций подобных моей, когда нигде ничего не понятно, а нужно в сжатые сроки добиться определенности и получить результат, если порекомендуете курсы или материалы, буду также очень благодарен!
Есть методика - Domain Driven Design, но там не про то чтобы раз-раз и за деньгами в кассу, там про проект в целом как уменьшить его сложность. И DDD не ограничивается бизнес или системным анализом, оно про всех участников, включая заказчиков и разрабов.
Более частное решение - хорошо изучить предметную область, хорошо изучить архитектуру ПО.
Простой
Простой
Простой
