В теме 16 ответов, и 10 участников, последнее обновление сделано пользователем 
Sergey.Shimansky 14 г, 3 мес. назад.
-
Сообщения
-
Некоторые, например, считают, что технический бэкграунд вообще мешает аналитику рассуждать без привязки к технологиям. Кто-то считает, что аналитику достаточно поверхностное знание ИТ.. А кто-то уверен, что необходимо глубокое понимание..
А что скажете вы?Я верю в то, что практический любой опыт, полученный в IT (будь то работа QA, девелопмент, да хоть веб-дизайн), аналитику только в помощь. Что касается формирования установок, обусловленных предыдущим занятием… ну тут аналитик он на то и аналитик, чтобы уметь абстрагироваться и смотреть на ситуацию свежим взглядом. Если он этого не умеет совсем, то тут любой предыдущий опыт будет помехой. Как говорится: "Если все, что у тебя есть, это молоток, любая проблема начинает выглядеть как гвоздь."
Согласен с Belle Morte — любой багаж знаний из IT области аналитику только в помощь.
Да, поверхностное знание IT во-многих случаях достаточно, но глубокое понимание IT — это бесценный плюс.
В общем, если сравнивать, к примеру, с лингвистическим либо экономическим образованием, то я считаю, что IT опыт здесь важнее.Согласен с Belle Morte — любой багаж знаний из IT области аналитику только в помощь.
Да, поверхностное знание IT во-многих случаях достаточно, но глубокое понимание IT — это бесценный плюс.
В общем, если сравнивать, к примеру, с лингвистическим либо экономическим образованием, то я считаю, что IT опыт здесь важнее.мне кажется, некорректным данное сравнение: образование и опыт. Естественно, ИТ опыт важнее, как опыт вообще, так как образование-это знания без опыта.
Глубокое знание ИТ для аналитика —багаж, который чаще всего останется неиспользованным (особенно, если мы говорим про БА), но, как любое наличие знаний, не является бесполезным.
Знание и понимание основ и принципов, на мой взгляд, необходимо и достаточно.мне кажется, некорректным данное сравнение: образование и опыт. Естественно, ИТ опыт важнее, как опыт вообще, так как образование-это знания без опыта.
Глубокое знание ИТ для аналитика —багаж, который чаще всего останется неиспользованным (особенно, если мы говорим про БА), но, как любое наличие знаний, не является бесполезным.
Знание и понимание основ и принципов, на мой взгляд, необходимо и достаточно.Согласен со взаимотношением "образование-опыт". Насчет неиспользованного багажа — тоже верно (для БА), но вопрос — много ли чистых БА у нас в республике? Насколько я знаю, абсолютно доминируют так называемые аналитики требований. А вот им и нужен как раз весомый опыт в этом деле. В любом случае, спасибо за коммент, ведь сколько людей, столько и мнений.
Вот другое мнение к размышлению: технический background аналитику мешает тем, что формирует мышление программиста (low-level мышление), в то время как от аналитика очень часто требуется абстрагирование от технологий/способов реализации, и high-level мышление. Естественно, знания в IT-сфере необходимы, но не на глубоком уровне. Аналитику простительно не знать, как разработать тот или иной контрол или запрос в базу.Анна, я согласен с такой постановкой проблемы.
На своем примере я не замечал, что это каким-либо образом мешает мне выполнять аналитические функции или что я пытаюсь вдаваться в детали реализации, не поднимаясь на уровень выше. Может тут либо знания программирования не настолько высоки, чтобы вжиться в роль девелопера, либо просто понимаю, что всему свое время и место. Но я согласен, что если сейчас взять обычного закоренелого разработчика и начать растить из него аналитика, то ему придется какое-то время сознательно преодолевать этот барьер.
В любом случае специфика работы на разных проектах разная. У нас я многократно замечал, что если аналитик умеет написать SQL запрос средней сложности, оценить сложность разработки придуманного им же самим видения и, собственно, в момент генерации требований опираться на их потенциальную сложность + трудоемкость / невозможность в рамках выбранной технологии, то это экономит большое количество времени и помогает избежать проблемных ситуаций.Опыт разработчика потребовался лишь однажды.
Заказчиками проекта были южнокорейские IT-ки
Личное мнение выражу цитатой:
Знания бесполезными не бывают. Бывает зря потраченное время.Мое мнение: аналитик не знающий архитектурных паттернов, методов разработки, возможностей фреймворков и т.д. это большая головная боль для ПМа, "лишние" эффорты и дорогой риск для проекта.
Перефразирую: аналитик не столько должен иметь "боевые" навыки программирования, сколь иметь навыки архитектора и доскональное (не поверхностные) знание возможностей применяемых языков/фреймворков/готовых систем.
Ответ на вопросы "почему" и "дану…" затянет на много слов. Если кому будет интересно, спрашивайте. =)аналитик не столько должен иметь "боевые" навыки программирования, сколь иметь навыки архитектора и доскональное (не поверхностные) знание возможностей применяемых языков/фреймворков/готовых систем.
Извините, Вы тут явно аналитика с проектировщиком перепутали!
[quote] аналитик не столько должен иметь "боевые" навыки программирования, сколь иметь навыки архитектора и доскональное (не поверхностные) знание возможностей применяемых языков/фреймворков/готовых систем.
Извините, Вы тут явно аналитика с проектировщиком перепутали![/quote]
Извиняю =) Отчего же у Вас возникло такое ощущение?p.s. Ко мне можно на "ты" =)
Приведу кстати ряд утверждений на данную тему:
- аналитик без скилов в проектировании, разработке, это жирный минус бюджету на проекте, а также резко возрастающие риски получить в итоге недовольного Заказчика.
- разработчик без скилов аналитики и тестирования, это регулярные проблемы/конфликты на проекте. Или тихий "саботаж".
- тестировщик без скилов аналитика, это жирный минус бюджету проекта, а также потенциальные риски что мерило качества не будет отражать реальные потребности Заказчика.
- менагер без скилов аналитика, разработчика, проектровщика и немного тестировщика, это либо полный капец проекту, либо "пятая нога".Есть различные вариации успешных комбинаций:
- если проект позволяет, то аналитик может очень тесно работать с функциональным архитектором и забить на скилы в проектировании. (кстати в такой тесной работе он их и так приобретет)
- если проект позволяет, то у тестировщиков может быть выделе QA-аналитик для понимания ключевых узлов системы. (остальные тестировщики всеравно постепенно перетянут часть его экспертизы на себя)
- ну и если это реальная скрам-команда, то там тут уже товарищи всегда подставят кредитное-плечо своей экспертизы.В условиях же среднего проекта в вакууме, обычно есть аналитик, тестировщик, серия разработчиков с выделенных техническим лидером. Все дополнительные роли в виде "менеджер", "архитектор" и прочие, являются дополнительными и в проект погружаются ровно в рамках свей экспертизы и границ бюджета.
- аналитик без скилов в проектировании, разработке, это жирный минус бюджету на проекте, а также резко возрастающие риски получить в итоге недовольного Заказчика.
Я хоть и сам бывший разработчик, но не берусь утверждать, что скилы по разработке аналитику очень нужны. В проектировании — быть может. В своем сообщении ты упоминаешь связку "аналитик-архитектор".. вот это, имхо, правильнее.
- разработчик без скилов аналитики и тестирования, это регулярные проблемы/конфликты на проекте. Или тихий "саботаж".
Смотря что подразумевать под скилами аналитики и тестирования. И про какой уровень разработчика мы говорим. Вот навыки написания Тест Планов, Тест Сценариев и Тест Кейсов разработчику, наверное, не очень нужны. Навыки проведения facilitation sessions, выявления требований, их грамотного документирования, наверное, тоже не нужны в полной мере разработчику. Тем более, если мы говорим про младшего разработчика (junior developer).
- тестировщик без скилов аналитика, это жирный минус бюджету проекта, а также потенциальные риски что мерило качества не будет отражать реальные потребности Заказчика.
Опять же, речь про QA или QC? И речь про младшего, среднего или старшего специалиста? Не уверен, что junior QC офигенно нужны именно скилы аналитика. Общее понимание — несомненно.
- менагер без скилов аналитика, разработчика, проектровщика и немного тестировщика, это либо полный капец проекту, либо "пятая нога".
Манагер выходит и жнец, и швец, и на дуде игрец.. я не уверен, что в нем должны быть сконцентрированы скилы всех-всех его подчиненных.. Играющий тренер — это хорошо, но, наверное, для небольших команд. А если речь про проект размером в 50 человек? Там на первое место выходят совершенно другие качества и скилы.
Ведь начинали мы именно с того, что один человек (разработчик) играл все роли (носил все шляпы). Потом придумали специализацию. А теперь опять начинаем её размывать. И на выходе получится вот такая очень нужная и очень функциональная штука:
Я думаю как минимум настолько глубокое, чтобы иметь возможность самостоятельно написать прогу для просева данных, SQL-запрос к базе, действующий макет интерфейса. В любом случае считаю, что уж помешать аналитику глубокое знание ИТ никак не может.Коллеги,Соглашусь с тем, что лишними эти знания не будут. Тем не менее , мое личное мнение, что отсутствие технических знаний не должно являться причиной отказа, скажем, при трудоустройстве или вообще оценке профессионализма аналитика. Взять к примеру, BABOK или вопросы к CBAP сертификации — там вообще нету технических вопросов.
Корни, как мне кажется, растут из наших белорусских/оутсорсинговых реалий. Зачастую от аналитика ожидают сильных технических знаний. И обусловлено это обычно проектом и прямыми требованиями Заказчика к кандидатам, например, глубокое понимание SQL, архитектуры распределенных систем, и т.д.Еще одно наблюдение — аналитик, долгое время проработавший девелопером, имеет склонность углубляться в детали дизайна, т.е. писать документацию для разработчика, а не Заказчика. Такая документация, хочет ответить на вопрос
"как", а не "что" должна делать система. Собственно, и это решаемо — всех можно перевоспитать)В любом случае, знания лишними не бывает и всегда могут пригодиться.
Вы должны авторизироваться для ответа в этой теме.
