Комментарии 21
Во «Многоруком боге далайна» финал, когда весь далайн трансформирован, похож на описанное превращение аналитика в overqualified «шамана». Перейдет ли он в итоге на «темную» сторону заказчика?
Внезапно захотелось перечитать Логинова «Многорукий бог далайна».
Интересная статья, спасибо.
Касательно концовки, где указывается, что непонятно, что делать дальше: попробуйте отойти от внедрения коробочных решений в крупных компаниях.
Мне самому кажется, что на такого рода деятельности аналитик проявляет себя ярче всего — во-первых, ему интересно быть экспертом и моделировать разные проекты с одними «исходными» данными (коробка), а-ля разработчик, где вместо кода твой инструмент — система, которую ты крутишь так, как нужно заказчику. А во-вторых, когда две стороны проекта, бизнес и разработка, находятся настолько далеко (разные компании), то мост коммуникации как раз-таки полностью на аналитике (да, еще на ПМе, но у него больше коммуникация с точки зрения сроков, у аналитика с точки зрения требований).
Но все-таки, попробуйте отойти от коробок. Попробуйте быть аналитиком системы, которая строится не из блоков и готовых механизмов терасофта/сапа/1с, а которая строится только из чистого кода и светлых идей архитекторов. Тут у вас будет и новый вызов, и интересные задачи, и самое главное — никаких ограничительных рамок (кроме бюджета и сроков, конечно же). В таких системах вы можете развиваться как технически (новые технологии и современные паттерны), что в итоге сделает вас системным архитектором, или развиваться в сторону бизнеса, идти по продуктовому пути — метрики, развитие системы с точки зрения продукта, бизнесовые идеи.
Таким развитие аналитика я вижу в компаниях, которые занимаются производством некоробочного софта :)
Касательно концовки, где указывается, что непонятно, что делать дальше: попробуйте отойти от внедрения коробочных решений в крупных компаниях.
Мне самому кажется, что на такого рода деятельности аналитик проявляет себя ярче всего — во-первых, ему интересно быть экспертом и моделировать разные проекты с одними «исходными» данными (коробка), а-ля разработчик, где вместо кода твой инструмент — система, которую ты крутишь так, как нужно заказчику. А во-вторых, когда две стороны проекта, бизнес и разработка, находятся настолько далеко (разные компании), то мост коммуникации как раз-таки полностью на аналитике (да, еще на ПМе, но у него больше коммуникация с точки зрения сроков, у аналитика с точки зрения требований).
Но все-таки, попробуйте отойти от коробок. Попробуйте быть аналитиком системы, которая строится не из блоков и готовых механизмов терасофта/сапа/1с, а которая строится только из чистого кода и светлых идей архитекторов. Тут у вас будет и новый вызов, и интересные задачи, и самое главное — никаких ограничительных рамок (кроме бюджета и сроков, конечно же). В таких системах вы можете развиваться как технически (новые технологии и современные паттерны), что в итоге сделает вас системным архитектором, или развиваться в сторону бизнеса, идти по продуктовому пути — метрики, развитие системы с точки зрения продукта, бизнесовые идеи.
Таким развитие аналитика я вижу в компаниях, которые занимаются производством некоробочного софта :)
Классная статья, практически пособие про «кто такой аналитик в IT что он делает». А что касается эпик фейла, то он найдет выход, т.к. он же аналитик :)
Спасибо за статью! Очень информативно и по полочкам.
Насчет наставничества — очень крутая и полезная вещь для обеих сторон.
Я только начинаю свой путь в качестве бизнес-аналитика и попал в компанию, где я первый на такой позиции. И это очень сложно развиваться самому, когда внутри компании руководство даже не понимает как можно меня использовать и какие задачи дать.
Поэтому приходится по факту совмещать кучу обязанностей и учиться всему. Такое ощущение, что скоро я и код буду писать )
Насчет наставничества — очень крутая и полезная вещь для обеих сторон.
Я только начинаю свой путь в качестве бизнес-аналитика и попал в компанию, где я первый на такой позиции. И это очень сложно развиваться самому, когда внутри компании руководство даже не понимает как можно меня использовать и какие задачи дать.
Поэтому приходится по факту совмещать кучу обязанностей и учиться всему. Такое ощущение, что скоро я и код буду писать )
Спасибо =)
Я лично знаю аналитиков, пишущих код. Не скажу, что мне близка эта позиция (нужно же хоть что-то оставить другим людям в команде :D ), но факты неумолимы.
Что касается наставничества, у меня были мысли написать об этом следующую статью, вам было бы интересно?
Я лично знаю аналитиков, пишущих код. Не скажу, что мне близка эта позиция (нужно же хоть что-то оставить другим людям в команде :D ), но факты неумолимы.
Что касается наставничества, у меня были мысли написать об этом следующую статью, вам было бы интересно?
Ну вот по факту я работаю бизнес-аналитиком только 3 месяца и уже писал бота с помощью RPA, пытался сделать интеграцию с помощью специального блочного софта, а конкретно по бизнес-анализу было только несколько предварительных митингов с заказчиками для будущей оценки проекта )
Насчет статьи — уверен, что будет интересно. Причем с одной стороны потому что лично я сейчас жадно глотаю всю информацию по бизнес-анализу, так и та информация, что Вы пишите, очень интересная и наполненная.
Так что обязательно почитал бы еще )
Насчет статьи — уверен, что будет интересно. Причем с одной стороны потому что лично я сейчас жадно глотаю всю информацию по бизнес-анализу, так и та информация, что Вы пишите, очень интересная и наполненная.
Так что обязательно почитал бы еще )
А вы пробовали обсуждать с непосредственным руководителем круг ваших предполагаемых задач и функций? Я уж не спрашиваю про должностную инструкцию =)
Да, причем даже не один раз.
Должностной инструкции нету, так как хоть и компании 15+ лет и работает 250+ разработчиков, но бизнес-аналитиков они не использовали. У них все «административные» задачи выполняют начальники отделов + тимлиды )
А так — лучше я хоть чем-то буду заниматься, пока не появится новых проектов, где я буду необходим.
Должностной инструкции нету, так как хоть и компании 15+ лет и работает 250+ разработчиков, но бизнес-аналитиков они не использовали. У них все «административные» задачи выполняют начальники отделов + тимлиды )
А так — лучше я хоть чем-то буду заниматься, пока не появится новых проектов, где я буду необходим.
Я понимаю вас, с точки зрения персонального развития и рационального использования рабочего времени. Но это рискованная история с той точки зрения, что если вас будут занимать непрофильными задачами, в которых вы прокачаете конкретный круг навыков, есть риск так и не вернуться к непосредственным профессиональным функциям и обязанностям. Но если, как вы говорите, аналитиков в компании нет вообще, видимо особого выбора у вас нет.
Да, выбора действительно многовато.
Но я в принципе поговорил уже с руководством. Мол я уже прошел испытательный срок и они не хотят от меня избавляться. Но если мы обоюдно в течении еще 3ех месяцев не найдем решение, которое всех устроит, то придется искать новое место работы.(
Но все равно определенную экспертизу я уже получил, многие проекты компании просто просмотрел, что и как делается. Так что в любом случае это проходит не бесследно)
Но я в принципе поговорил уже с руководством. Мол я уже прошел испытательный срок и они не хотят от меня избавляться. Но если мы обоюдно в течении еще 3ех месяцев не найдем решение, которое всех устроит, то придется искать новое место работы.(
Но все равно определенную экспертизу я уже получил, многие проекты компании просто просмотрел, что и как делается. Так что в любом случае это проходит не бесследно)
А кто у вас формализует требования и держит в голове общую картину системы? Разработка общается с пользователями напрямую? Или нач.отделов + тимлиды?
Общается нач.отдела + тимлид проекта.
Когда доходит дело уже до непосредственной разработки — то начинают обсуждать требования уже разработчики на митингах.
Кроме того большая часть заказов приходит от иностранных IT компаний уже с полностью расписанными и проанализированными требованиями. Такая полная спецификация в виде SRS и v&s документов
Когда доходит дело уже до непосредственной разработки — то начинают обсуждать требования уже разработчики на митингах.
Кроме того большая часть заказов приходит от иностранных IT компаний уже с полностью расписанными и проанализированными требованиями. Такая полная спецификация в виде SRS и v&s документов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многорукий бог дедлайна или Широкое Использование Возможностей Аналитика