Форум Сообщества Аналитиков
Обсуждения => Сообщество Аналитиков => Тема начата: Denis Beskov от 24 Ноября 2009, 23:15:01
-
Давайте больше узнаем друг о друге.
Если мы будем лучше понимать, какие производственные вопросы волнуют больше всего, мы сможем более качественно строить и план семинаров и план публикаций и план обсуждений.
-
Вещи, которые волнуют меня сейчас:
Как организовывать взаимодействие по улучшению процессов в большой организации.
Как синхронизировать ценности представителей разных подразделений.
Как добиться слаженной работы людей.
Как научить профессионала пользоваться различными техниками по обстоятельствам, а не идти по проторенному пути.
Как увязать между собой различные методологические школы CMMI, XP, RUP, отобрав стоящее.
Какие производственные процессы стоит стабилизировать и улучшить в первую очередь.
Где взять методические и технические наработки по скоринговой модели для оценки кандидатов.
-
Если говорить о "производственных" вопросах, то меня волнуют такие.
Как научиться работать со стабильной производительностью.
Как мотивировать всю команду на продуктивную работу.
Как убедить руководителя в необходимости стабильных процессов (читай: набора новых сотрудников на недостающие роли).
Если о личных вопросах, то:
Нафига мне всё это надо и надо ли вообще. Попытки построения иерархии целей неизменно упираются в корневой вопрос о смысле жизни.
-
Как организовать взаимодействие между тестировщиками и остальной командой, чтобы известие об ошибки исходило не от руководителя проекта, а непосредственно от того, кто принял его, обнаружил и т.п.
Каким образом мотивировать коллег думать о других, учитывать их особенности деятельности и добиваться гармонии при достижении целей
Как увеличить отдачу системы тестирования, усилить и обеспечить ее прогностические качества, научиться оценивать эффективность тестирования и понимать куда двигаться
Как учить студентов, чтобы этот процесс был и интересен, и полезен, и не формален.
Как разработать хороший курс по Архитектуре ИС и Архитектуре ПО
Где и каким образом следует учить теории и практике аналитической работе при обучении студентов
Какая определить эквиваленты западным терминам в области ИТ
-
Отсутсвие опыта и практики.
-
1. Как организовать взаимодействие между менеджерами продуктов и аналитиками
2. Как управлять и вести требования для матрицы продуктов-сервисов (много сервисов на много платформ)
3. Как согласовывать и учитывать потребности большого количества заинтересованных лиц (больше 10)
4. Как "вырастить" хорошего аналитика и сделать так, чтобы он не сбежал
-
4. Как "вырастить" хорошего аналитика и сделать так, чтобы он не сбежал
Как вырасти в хорошего аналитика? :- )
С чего начать, если в компании нет роли аналитика?(хотя должна быть)
Как необходимость внедрения нормальных процессов довести до программистов (часть из которых бывшие военные и дрессировки не поддаются)?
Как остановить процесс хаотичной разработки и перевести его в нормальное русло (планирование, проектирование, документирование)
-
Куда расти дальше (как аналитик)?
Для чего накапливать новые знания, если для успешной работы хватает и старых?
Как перейти от "сбежать" к "замотивировали"?
Как научиться работать со стабильной производительностью?
-
1. Как спланировать аналитическую фазу проекта оптимальным образом?
2. Как повысить производительность аналитиков?
-
Кто и когда будет отвечать на все эти вопросы? :)
-
Кто и когда будет отвечать на все эти вопросы? :)
Как минимум - сами авторы будут, для себя. Твои предложения, ожидания?
-
Давайте больше узнаем друг о друге.
Если мы будем лучше понимать, какие производственные вопросы волнуют больше всего, мы сможем более качественно строить и план семинаров и план публикаций и план обсуждений.
по-моиму тут все ясно написано
-
Как минимум - сами авторы будут, для себя. Твои предложения, ожидания?
я в ожидании семинаров в таком формате, в какой всё вылилось на семинаре по концепции ПО, т.е. каждый выступит и поделится своим опытом какому-либо вопросов.
все озвученные темы интересны, из тех, где я мог бы добавить свои пять копеек, это несколько из озвученных Galogen'ом:
- Как учить студентов, чтобы этот процесс был и интересен, и полезен, и не формален.
- Где и каким образом следует учить теории и практике аналитической работы при обучении студентов.
- Как определить русскоязычные термины, эквивалентные западным терминам в области ИТ.
в остальном - с удовольствием послушаю (я лучше вникаю в суть вопроса при живом общении)
-
А где же ответы, соратники? Я надеялся, что тут найду ответы, а их так и нет(((
________________________
http://toptree.ru/uluny/dahunpao
-
Проблема - где взять драйв )
-
Проблем у аналитиков нет, есть задачи. Эта единственная такая профессия, за что и люблю...:)
-
Хороший вопрос.
Волнует, куда развиваться дальше. Уходить глубоко в предметную область одного Достаточно Большого Проекта или, наоборот, лучше поработать понемногу на нескольких разноплановых проектах.
Волнует, как повысить свою производительность. Есть ощущение, что когда идея ясна -формулировать надо быстрее.
Волнует, как планировать сроки согласования документов.
Волнует, стоит ли пытаться развиваться в сторону англоязычных проектов (язык пока pre-Intermediate). Тут и на русском то иногда призадумаешься правильно ли понял заказачика. А если ещё и чужой язык будет?
Иногда волнует, а не податься ли обратно в разработчики, после 7 лет аналитиком :).
-
а меня волнует эффективное построение горизонтальных коммуникаций на сложных проектах/в компаниях, где БА считаются не пойми чем и, с точки зрения разрабов не участвуют в техпроцессе производства ПО.
так же волнует процесс реабилитации после сложных задач: после сложного проекта скучно заниматься задачами в мелких.
а ещё волнует, что уроды все курилки во внуково сломали :)
-
а ещё волнует, что уроды все курилки во внуково сломали :)
это насильственное оздоровление населения, которое об этом не просило.
-
1. Коммуникации внутри команды и между командой и заказчиком.
Актуальность: в моей практике большинство крупных ошибок имели корни в недопонимании между заказчиками и аналитиками или менеждерами групп разработки.
2. Выявление и спецификация нефункциональных требований.
Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.
3. Навыки ведения презентаций и переговоров.
Актуальность: возможный карьерный рост для аналитика - высший менеджмент или должность представителя/партнёра, или иная, требующая ведения жёстких переговоров. Что касается презентаций, я замечаю на конференциях и slideshare много антипаттернов в оформлении слайдов (неуместные картинки) и в подаче материала :последовательность, темп, стиль речи.
4. Выбор направления для развития; как выбрать метод самообучения.
Актуальность: нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
-
2. Выявление и спецификация нефункциональных требований.
Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.
Многие группы НФТ давно уже превратились в самостоятельные дисциплины, с собственными специалистами: информационная безопасность, производительность, юзабилити.
-
Многие группы НФТ давно уже превратились в самостоятельные дисциплины, с собственными специалистами: информационная безопасность, производительность, юзабилити.
Гриша, эти дисциплины изучают методы обеспечения этих аспектов качества, а не задания требования к ним.
-
Гриша, эти дисциплины изучают методы обеспечения этих аспектов качества, а не задания требования к ним.
Эксперты по этим дисциплинам вполне в состоянии выявлять и описывать соответствующие требования, исходя из теории и собственного опыта. В отличие от многих аналитиков, которых до сих пор учат, что нефункциональная сторона системы - это что-то второстепенное.
-
Эксперты по этим дисциплинам вполне в состоянии выявлять и описывать соответствующие требования, исходя из теории и собственного опыта. В отличие от многих аналитиков, которых до сих пор учат, что нефункциональная сторона системы - это что-то второстепенное.
И что из этого следует?
-
И что из этого следует?
Цитата:
Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.
Раз есть целые отрасли, то есть и соответствующие техники. Нужно либо обучать аналитиков хотя основам этих дисциплин (что трудно и не всегда возможно - например, человек со сформировавшимся функциональным мышлением просто не понимает концепций юзабилити), либо приглашать команды узких специалистов для выявления таких требований.
Например, пригласить специалистов по высоким нагрузкам для участия в проектировании новой версии системы. Они не аналитики, но сумеют описать достаточно формализованные требования.
Или пригласить юзабилистов для участия в проектировании UI.
-
Цитата:
Раз есть целые отрасли, то есть и соответствующие техники. Нужно либо обучать аналитиков хотя основам этих дисциплин (что трудно и не всегда возможно - например, человек со сформировавшимся функциональным мышлением просто не понимает концепций юзабилити), либо приглашать команды узких специалистов для выявления таких требований.
Зачем изучать основы, если можно дать примеры и правила формулирования этих требований?
Или пригласить юзабилистов для участия в проектировании UI.
В проектировании-то да, но это опять про обеспечение. Мой опыт показывает, что большинство проектировщиков интерфейса не умеют разрабатывать НФТ по части пригодности.
-
Есть еще вариант - доучить аналитика в части usability (30-40 часов вполне, думаю, достаточно).
-
Зачем изучать основы, если можно дать примеры и правила формулирования этих требований?
Например, я выступаю на конференции и рассказываю о том, насколько важно удобство инструментов управления требованиями для разных участников разных процессов, а ко мне потом подходят и говорят: "ну так всё, о чём вы рассказывали, наша система умеет делать, в чём проблема?" Для них нет границы между ответами на вопросы "что" и "как". Они просто не слышат про нефункциональную сторону системы. В такие моменты я вспоминаю муху, пытающуюся вылететь из плоскости, через неё проходящей. И "просто правила и примеры" тут не помогут, нужно изучить основы - понять, почему и зачем эти примеры именно такие.
Именно поэтому, на мой взгляд, юзабилити и превратилось в самостоятельную отрасль: туда ушли те, кто понял разницу.
-
Например, я выступаю на конференции и рассказываю о том, насколько важно удобство инструментов управления требованиями для разных участников разных процессов, а ко мне потом подходят и говорят: "ну так всё, о чём вы рассказывали, наша система умеет делать, в чём проблема?"
Может тебе тоже стоит начать с требований к пригодности? Ты, насколько я помню, тоже рассказывал про интерфейсные РЕШЕНИЯ, а не про требования к пригодности, которые они обеспечивают.
-
Может тебе тоже стоит начать с требований к пригодности? Ты, насколько я помню, тоже рассказывал про интерфейсные РЕШЕНИЯ, а не про требования к пригодности, которые они обеспечивают.
Наверное, стоит. Я, честно говоря, ещё даже не знаю, что такое требования к пригодности. Пригодность - это что-то из стандарта ISO9126? Если да, то как оно называется в оригинале?
-
Наверное, стоит. Я, честно говоря, ещё даже не знаю, что такое требования к пригодности. Пригодность - это что-то из стандарта ISO9126? Если да, то как оно называется в оригинале?
Это я так перевожу usability. В русском ГОСТе переведено как Практичность: http://intexpro.ru/Doc/GOST_R_ISO_MEK_9126-93.pdf