В теме 15 ответов, и 9 участников, последнее обновление сделано пользователем 
Николай Киреев 13 г, 9 мес. назад.
-
Сообщения
-
В каждой работе есть свои приятные и неприятные особенности. А что в работе аналитика лично вам нравится меньше всего? Что неинтересно, но, тем не менее, приходится делать?Первое, что пришло в голову — писать meeting minutes. Хотя я осознаю их необходимость и пользу.Для меня, наверное, только проведение презентаций и лекций (так как выступление перед толпой это всегда немного стресс).1) проводить демо на полурабочем приложении, где шаг вправо-влево =эксепшин
2) Сообщать плохие новости.У меня чем-то похоже на ответ Сары, но немного по-своему (:
Отвечать за чужую некачественно/невовремя выполненную работу или.. вообще невыполненнуюНе поверите: не люблю писать документы. Так иногда хочется на словах всё объяснить!
Полностью согласен с Юрой.
Сообщать о чужих неудачах это очень не приятно. В таком случае приходиться выступать в роли психолога, дабы заверить клиента, что не смотря на задержку или трудности все усилия команды направлены на решение проблемы.Да, подумав, я соглашусь с Юрой. Я очень не комфортно себя чувствую, например, когда заказчик находит баг на проде, особенно при мне. Или срок срывается.Есть ещё одна неприятная сторона.
В виду того, что профессия молодая, не всем понятная (да и нам самим в том числе), многие, даже те, кто рядом с нами в тяжелые минуты, считают, что аналитики не очень-то нужны. Относятся к нам соответствующим образом, ну и разговоры всякие разговаривают (:. Мол, разработчики и так справятся, нечего тут писульки писать и вообще бюрократию разводить ненужную. Откуда ноги растут лично мне-то понятно (я и про некоторых разработчиков могу сказать, что они не очень-то нужны с таким качеством работы), и я отношусь к этому ко всему нормально (ведь это повод доказать обратное), но я бы всё же отнёс это к неприятной стороне. Слушать такое постоянно, мягко говоря, не очень приятно.Кстати, по поводу последней проблемы (которая уже обсуждалась более детально вот в этом топике) добавлю, что иногда в этом виноваты сами аналитики/организаторы аналитического процесса на проекте.
Иногда возникает такая ситуация, что владельцем процесса анализа на проекте является неопытный/неквалифицированный аналитик. Разработчики в силу процесса ждут требований/грамотных решений/хороших идей, а получают на выходе отсутствие требований (= заморозка работы) или явный бред. В таких ситуациях у меня и самого возникает вопрос, зачем нужны такие аналитики.. Если копнуть глубже, то обусловлено это опять тем же, что "аналитик" — профессия с первого взгляда несложная и иногда на проектах активности аналитика ограничиваются минимумом (написать письмо иностранцу и задокументировать его ответ). Вот в условиях такого минимума многие люди (не имея желания развиваться) и застаиваются, тем самым стремительно теряя/замораживая свою квалификацию.У меня чем-то похоже на ответ Сары, но немного по-своему (:
[b]Отвечать за чужую некачественно/невовремя выполненную работу или.. вообще невыполненную[/b]Замечу, данная "неприятность" есть неприятность для всех, кто вынужден отвечать за проект, в котором осознанно принимал опосредственное участие.
Для того чтобы это не было неприятность, достаточно проект/работу стать личным делом/проектом. IMHO.Есть ещё одна неприятная сторона.
В виду того, что профессия молодая, не всем понятная (да и нам самим в том числе), многие, даже те, кто рядом с нами в тяжелые минуты, считают, что аналитики не очень-то нужны. Относятся к нам соответствующим образом, ну и разговоры всякие разговаривают (:. Мол, разработчики и так справятся, нечего тут писульки писать и вообще бюрократию разводить ненужную. Откуда ноги растут лично мне-то понятно (я и про некоторых разработчиков могу сказать, что они не очень-то нужны с таким качеством работы), и я отношусь к этому ко всему нормально (ведь это повод доказать обратное), но я бы всё же отнёс это к неприятной стороне. Слушать такое постоянно, мягко говоря, не очень приятно.Все очень просто. Источники кроются в истории. А история любой индустрии это кустарное производство, а до этого мастерство/ремесленничество.
Аналогично с IT.
Изначально IT было ремеслом/мастерством. Тогда "программист" был единым мастером/творцом. Индустрии не существовало и она казалось фантастикой. "Творец" был всем. И все что он создал за "7 дней" было высшим и не оспоримым искусством.
Потом появилось кустарное производство, ремесло. Спрос превышал предложения в сотни раз. Разработчик оставался "мастером" и "творцом". Один человек творил историю. "Программист" уже не был магом, но все равно продолжал быть единым началом и венцом для "продуктов".
Сейчас IT стало индустрией/"фабрикой"/"конвейером". И пришла необходимость "вспомогательных" профессий: бизнес-аналитики, менеджеры, администраторы, сейлсы и пр. Естественно, что тому, кто изначально был "всем", весьма не комфортно видеть столько якобы необходимых для него профессий вокруг. В итоге конфликты. Нет еще понимания целостности механизма. Есть понты, гонор и самомнение. Притом зачастую не только со стороны разработчиков. =)
Радостно другое. Это временно. Пройдет пяток-десяток лет и старые "мамонты" вымрут, все устаканится и любая из профессий в IT будет сравнима с сантехниками, электриками и строителями. Т.е. станет рутиной для всех. Это еще и печально кончено. =)Изначально IT было ремеслом/мастерством. Тогда "программист" был единым мастером/творцом…
…Один человек творил историю. "Программист" уже не был магом, но все равно продолжал быть единым началом и венцом для "продуктов".
Сейчас IT стало индустрией/"фабрикой"/"конвейером". [b]И пришла необходимость "вспомогательных" профессий:[/b] бизнес-аналитики, менеджеры, администраторы, сейлсы и пр. Естественно, что тому, кто изначально был "всем", весьма не комфортно видеть столько якобы необходимых для него профессий вокруг. В итоге конфликты. Нет еще понимания целостности механизма. Есть понты, гонор и самомнение. Притом зачастую не только со стороны разработчиков.Уважаемый коллега, Вы просто забыли о том, что программные системы тогда и сейчас, ну просто гиганская разница! До ООП было алгоритмическое программирование, как прикладная дисциплина, обеспечивающая расчеты в, например, физике или математике и т.д. Ну какая уж тут при расчете формул потребность в бизнес-аналитике — ни какой. Потом, задачи и требования к программным продуктам изменились, пришел объектно-ориентированный подход и программные системы стали обеспечивать функционирование систем сбора и храния информации, а также систем контроля и управления. Но, при этом, и предметные области системы, и сами системы были таковыми, что все, относящееся к их разработке, включая анализ предметной области (бизнес-анализ), анализ функциональных требований (Requirements Engineering), проектирование (Design) и, конечно, кодирование мог делать один единственный, как Вы тут написали, "Мастер/Творец" (аж с Господом Богом ассоциации возникают!), ну иногда требовалось несколько таких творцов. Программная системы могла иметь десяток классов, под сотню объектов.
При этом, заметьте, что тот самый бизнес-, системный анализ, и даже Use Case-анализ существовали уже тогда, когда объектно-ориентированные языки только-только начинали развиваться.
Теперь пришло время глобальных распределенных информационных систем, обеспечивающих задачи бизнеса. Предметная область, процессы, архитектура системы настолько усложнились (тысячи классов, миллионы объектов), что один или несколько "гениев" будут создавать такую систему вечность. Теперь, совмещать все специальности разработчиков в одном "гении" нет никакой возможности, особенно, когда производство ПО промышленное.
Выход один, каждый должен заниматься строго своими обязанностями, четко знать за что он отвечает, какие артефакты и для кого, и с какой целью должен содавать, а чьи использовать. Только тогда в команде будет мир и порядок, и все найдут свое место в процессе разработки, не будет "понтов" и "самомнения". А по поводу специальностей аналитика — это одни из самых ключевых игроков команды разработчиков, ошибки которого самые дорогие для бригады, и если ценность кодировщиков постоянно и неуклонно падает (а скоро придет автоматическое кодирование по архитектурным диаграммам. Rational Rose Real Time была первой попыткой автоматического кодирования в том числе и методов по оптимальным алгоритмам), то ценность аналитиков и проектировщиков постоянно возрастает. "Целостные механизмы" понимания процесса разработки и обязанностей участников разработки уже давно есть, гдавное, чтобы в наших мозгах не было каши-размазни!Уважаемые коллеги. Тема, которую вы развиваете, мегаинтересна (и это действительно так), но она не совсем совпадает с темой этой ветки. В размышлениях на тему необходимости аналитиков, истории развития индустрии разрботки ПО и т.д. я тоже готов поучаствовать, однако в предназначенных для этого ветках.Итак, переносим дискуссию в другую ветку (если её нет, создаем).
"nousy123", я понял Вашу позицию и не согласен с ней.
При этом я согласен с Юрой, эта дискуссия не для данной ветки.
Вы должны авторизироваться для ответа в этой теме.
