Про кашу в головах работодателей -- аналитик\техпис ...(Прочитано 29226 раз)
Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":

Западная компания, поставщик высококачественного электрооборудования для строительства и промышленности открывает вакансию «Программиста (Бизнес - аналитика)»

Требования к кандидатам:
Высшее профессиональное образование
Опыт работы в сфере информационных технологий не менее 3-х лет
Знание SQL, OLAP
Владение СУБД, системами построения отчетности Reporting Services
Владение принципами работы ERP-систем
Владение основами теории организации

Основные обязанности:
Разработка, построение и внедрение максимально эффективной системы отчетности, отвечающей потребностям пользователей и бизнеса
Сопровождение системы отчетности компании
Моделирование и анализ бизнес-процессов, их оптимизация
Участие в составлении бюджетов компании, анализ проблемных мест в бизнесе, подготовка рекомендаций для принятия управленческих решений
Участие в поддержке ERP-системы iScala
Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. (Карл Вигерс)
http://infiniti-gk.livejournal.com/



Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":
А потом?



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

Если речь идет именно о разработке состава отчетов, тогда, может, еще не все так плохо. Но почему тогда они написали, что им нужен "программист, бизнес аналитик"?

В общем, у меня наступает когнитивный диссонанс, когда я пытаюсь понять, что эти работодатели имели в виду. :) А было время, когда я объем того, что необходимо знать и уметь, по объявленным вакансиям определяла...  ::)
Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. (Карл Вигерс)
http://infiniti-gk.livejournal.com/



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



Пусть будет так - "Не судите, да не судимы будете". А вообще, это же почти несовместимые виды деятельности: программирование и выявление требований. Умение программировать (я имею в виду не базовые знания, а досточные для решения большинства возникающих задач), как правило, служит своего рода ограничением при формировании требований - сужу исходя из своих личных наблюдений.
Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. (Карл Вигерс)
http://infiniti-gk.livejournal.com/



Простите, что вклиниваюсь, на протяжении вот уж 5-ти лет, я совмещаю и тех. писателя, и аналитика и поддержку, что на первом месте работы, что на втором. Когда меняла работу, тоже не знала как себя подать, как первого, второго или третьего... но очень многим работодателям требуется все три в одном лице и на одном окладе...



Цитировать
Умение программировать ... служит своего рода ограничением при формировании требований
Скорее, не умение программировать, а само положение разработчика. Если специалист, в чьи обязанности входит написание кода, начнет активно выявлять требования - так ему ж и реализовывать их придется. :)



На основании того,что видел функции аналитика могут существенно различаться исходя из:
1. Специфики проектов данной компании(коробочный софт,заказной, внедрение решений вендора, собственные разработки в продуктовой организации)
2. Видения руководства, ставившего процесс разработки,внедрения итп
3. Прижимистости работодателя



<...>Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текст??? Ниже оригинал объявления ...<...>

ЕСПД (которую, скорее всего, имели в виду)  - это не только ТЗ/ЧТЗ/ЭП/ТП, но и различные руководства. В т.ч. пользователя, администратора, системного программиста, программиста. Содержание у них - IMHO вполне здравое. И чтобы удобоваримо написать такое - нужно иметь порядок в голове и уметь принять сторону пользователя. Или, что страшнее, вжиться в роль администратора, а то и самого программиста. В общем, Станиславский отдыхает :). Так вот, надо рассказать этому пользователю-администратору-программисту, как ему удовлетворить его потребности при помощи существующей, великой, могучей, до конца не познанной системы, созданной, чтобы получить просветления, а не ради удовлетворения земных нужд. Причём лучше описать языком Пришвина и снабдить занимательными цветными картинками а-ля "Мурзилка".

Некоторые системы обладают большой сложностью, естественной и/или наведённой. Чтобы написать руководство по такой системе, нужно обладать высокой квалификацией. В т.ч. побывать в роли пользователя, администратора, разработчика. Что в этом удивительного? Хорошее руководство написать непросто. Особенно если кто-то в жизненном цикле ПО до тех. писателя сделал свою работу... не очень хорошо. Особенно - если системный аналитик и дизайнер UI.
« Последнее редактирование: 31 Октября 2009, 00:32:50 от AlexTheRaven »



Скорее, не умение программировать, а само положение разработчика. Если специалист, в чьи обязанности входит написание кода, начнет активно выявлять требования - так ему ж и реализовывать их придется. :)
Мне не нравятся такого рода постановки вопроса. Так, получается, и аналитик, не заинтересован в выявлении требований, проблем заказчика, задач, требующих решения посредством внедряемого ПО, - ему ж их потом описывать и анализировать придется!

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

Человек, ответственно относящийся к своей работе и представляющий и понимающий последствия собственной безответсвенности, вряд ли утаит важное требование просто потому, что ему потом его придется реализовывать. :)
Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. (Карл Вигерс)
http://infiniti-gk.livejournal.com/



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

Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда. Для этого вся команда должна видеть общую цель, а не свою частную задачу (даже если я "утаю" сейчас  требование, рано или поздно мне всё равно придётся его реализовывать, причём команде это обойдётся, скорее всего, намного дороже).
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Цитата: InfinitI
Человек, ответственно относящийся к своей работе и представляющий и понимающий последствия собственной безответсвенности, вряд ли утаит важное требование просто потому, что ему потом его придется реализовывать.
Вы правы. Именно поэтому и не стоит утверждать, что программирование и выявление требований есть несовместимые виды деятельности. Когда программисты разделяют такую точку зрения - проекту на пользу это не идет. 
Цитата: InfinitI
Я сталкивалась с ситуациями, когда разработчики являлись хорошими специалистами в предметной области
Опытный разработчик обычно хорошо разбирается в предметной области.
Цитата: greesha
Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда
У всех свои предпочтения складываются... Мне очень импонируют гибкие методологии разработки. По моим наблюдениям, они довольно эффективны, особенно если не пренебрегать фиксацией достигнутых соглашений.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19