В теме 35 ответов, и 7 участников, последнее обновление сделано пользователем 
Igor Tkachenko 12 г, 9 мес. назад.
-
Сообщения
-
Всем привет.
Я постоянно изучаю этот форум. И вопросы здесь поднимаемые. И меня обеспокоил один нюанс. Здесь не обсуждаются реальные проблемы, типа задач которые не получается решить — которыми, например, кишит любой форум программистов. Получается, что либо я чего-то не замечаю, либо проблем у этих людей нет. Но мне кажется так не бывает
Поэтому пока крыша у меня от этого вопроса совсем не поехала. Мне было бы интересно если бы граждане аналитики поделились бы своими проблемами.
Именно проблемами типа "задач" которые не получается решить. Особенно интересны задачи которые появляются периодически.У меня, например, иногда при рисовании схемы процесса (даже существующего), не всегда получается учесть все важные (на мой взгляд) нюансы и сделать её одновременно достаточно простой. Чаще всего делаю две схемы: одну подробную, другую простую. Но мне это не оч нравится.
Хотя, если честно, мне кажется это тоже условно проблема. Т.к. анализ этой кухни я потом могу сделать чтобы получить конечный результат.Можно примеры задач, о которых идет речь, чтобы все понимали, о чем идёт речь?Из примера в первом посте вроде как выглядывает типовая проблема — достаточность описания.
Вся шутка в том что я как раз хочу увидеть примеры )Структура проблемы должна быть такая: Надо получить такой-то эффект, а известными средствами это не возможно или непонятно как.
Причем отсутствие этого эффекта приводит к тому что задачу закончить невозможно (а не просто решение будет менее качественным).Например, по аналогии с какой-нить программистской проблемой, аля: непонятно как составить определенный запрос к базе который бы делал бы то-то и то-то.
Да, я согласен, что здесь в основном люди общаются по теории. Мы не раз обсуждали, почему оно так:). Пришли к выводу, что возможно это связано со спецификой работы аналитиков. Вот у программера или DBA, допустим, может возникнуть проблема: решить надо именно таким способом, а не получается. Они об этом и спрашивают. Аналитик же на своем проекте чаще всего один (не считая крупных проектов) и он скорее будет действовать так, как он умеет.Если вопрос/пробема относится к системным требованиям — то его спрашивают у программистов или ищут на тех же форумах.
Вопросы уровня функциональных требований — спросить можно, но нужно ли? Можно посмотреть аналоги, можно придумать что-то самому.
Вопросы уровня бизнеса почти всегда индивидуальны, имхо. Или ищутся на тематических ресурсах.Хорошую тему подняли.
Есть у меня одна идея по этому поводу.
Как насчет запустить раздел на сайте с разбором проблемных / рабочих кейсов? Например, по одному кейсу в неделю с обсуждением.. Если кейсов будет очень много, то можно несколько раз в неделю. Имхо, главное — это в итоге делать какой-то вывод и "закрывать" кейс.. Я думаю, это поможет решать глобальные или типичные проблемы. Для более мелких всегда открыт форум и, вероятно, возможность видеть и участвовать в решении типичных кейсов простимулирует остальных обсуждать и более мелкие и нетипичные кейсы.Что скажете?
(Это, конечно, потребует некоторого апдейта сайта, но, имхо, оно того стоит)
Раздел запустить не проблема, главно е — кейсы
Хорошую тему подняли.
Есть у меня одна идея по этому поводу.
Как насчет запустить раздел на сайте с разбором проблемных / рабочих кейсов? Например, по одному кейсу в неделю с обсуждением.. Если кейсов будет очень много, то можно несколько раз в неделю. Имхо, главное — это в итоге делать какой-то вывод и "закрывать" кейс.. Я думаю, это поможет решать глобальные или типичные проблемы. Для более мелких всегда открыт форум и, вероятно, возможность видеть и участвовать в решении типичных кейсов простимулирует остальных обсуждать и более мелкие и нетипичные кейсы.Что скажете?
(Это, конечно, потребует некоторого апдейта сайта, но, имхо, оно того стоит)
Отличная идея! Поддерживаю!
Кстати, для начала могу предложить несколько кейсов. Первый из них можно взять из 2-1 части обзора по ТРИЗ про поддержку он-лайн связи с бензовозами. Я его могу подробнее расписать.Да, идея хорошая -поддерживаю (если я верно понимаю — это будет нечто по аналогии c рассылкой Александра Орлова).
Кстати я бы не называла это "проблемами" (негативный подтекст у слова) — пусть это буду "интересные случаи из практики" (или что-то вроде).Ну да. Если большинство проблем заключается в том чтобы сделать что-то чего нет. То решения приходят очень быстро.
Особенно если то чего нет уже озвучено клиентом )Есть тока два наивных вопрос:
1) Надо ли это клиенту?
2) А какие проблемы все сделанное вызовет вместе и по отдельности?И на выходе:
Достиг ли бизнес тех показателей к которым стремился, делая этот проект (хотя бы +-50%)? И если не достиг то что этому помешало?
Или не это главное? Проект же сдан, клиент увидел то что попросил и заплатил деньги )Я не хочу озвучивать эту насущную проблему. (Стесняюсь, вдруг их у других нету).
Но если кто углядит себя в сказанном и предположит что это касается хотя бы 15% завершаемых проектов с участием аналитика может это уже будет первым хорошим кейсом?Если я сказал слишком туманно. Отпишитесь — назову конкретные проблемы, которые на мой взгляд могут быть у аналитика.
P.S> Если я проявил невежество и просто чего-то не знаю ) Посоветуйте литературу. Я программист всё-таки. Хотя в душе с вами
Ну да. Если большинство проблем заключается в том чтобы сделать что-то чего нет. То решения приходят очень быстро.
Особенно если то чего нет уже озвучено клиентом )Есть тока два наивных вопрос:
1) Надо ли это клиенту?
2) А какие проблемы все сделанное вызовет вместе и по отдельности?И на выходе:
Достиг ли бизнес тех показателей к которым стремился, делая этот проект (хотя бы +-50%)? И если не достиг то что этому помешало?
Или не это главное? Проект же сдан, клиент увидел то что попросил и заплатил деньги )Я не хочу озвучивать эту насущную проблему. (Стесняюсь, вдруг их у других нету).
Но если кто углядит себя в сказанном и предположит что это касается хотя бы 15% завершаемых проектов с участием аналитика может это уже будет первым хорошим кейсом?Если я сказал слишком туманно. Отпишитесь — назову конкретные проблемы, которые на мой взгляд могут быть у аналитика.
P.S> Если я проявил невежество и просто чего-то не знаю ) Посоветуйте литературу. Я программист всё-таки. Хотя в душе с вами
Уважаемый phyro!
Бизнес-система развивается в каком-то направлении вовсе не по желанию собственников (или каких-либо лиц, принимающих решение), а по вполне объективным законам развития. Важная роль бизнес-аналитика — понимать, насколько правильны желания клиента.
"Правильные желания" означает, что желания соответствуют законам развития бизнес-систем. Многие проекты обречены на неудачу именно потому, что в них заложены "неправильные желания клиента".
Возможно, что эта мысль противоречит тому, чему вас учили, например, принципу "клиент всегда прав". Предлагаю подумать о предложенной антитезе.Ох, как стыдно бывает утром вспоминать то что было вчера.
Эндрю, вы очень шарящий и уважаемый мною товарищ. Но что-то мне подсказывает, что в данный момент не правы.
Ну либо вы сейчас прикалываетесь )Тем более это не единственная проблема заложенная в моем посте. И не главная (нет она на самом деле может даже и главная, но я бы начал с чего-то по проще).
Зачем ходить вокруг да около? Если есть конкретные проблемы — озвучивайте!1) Как понять после успешной сдачи проекта какие в нем были допущены ляпы (читай какие были проблемы)?
2) Как не потерять уже сделанные но неисправленные ляпы (читай проблемы) для работы надо ошибками?кто-нибудь этим вообще страдает? ну по логике должны. я просто ни разу "не присутствовал" при подобных действиях.
разъясню: все довольны ) никто не говорит о проблемах соответственно. но то что не дало по шее сейчас может прибить потом (на другом проекте). а потом докажи что ты не индюк…
ну и:
3) Как понять что идея клиента гавно и хотя бы минимизировать его потери (грубо говоря если проект лажа, то он является одной большой проблемой для всех. в том числе для клиента. так вот как минимзировать ущерб)? Или как вежливо подменить идею клиента на рабочую и втюхать ему как его собственную? И вообще нужно ли это делать?============
дополнительные условия задачи:
а) аналитик заниматься уже другим проектом
б) в некоторых орг. структурах аналитик может уже отвалиться от проекта к завершающим стадиям (например во время приемки и стабилизации — проблемы решают QA и PM если они не большие — хотя за большим кол-вом мелочей может стоять одна большая ошибка аналитика).
в) аналитику могут не разрешать тратить свое время на такие дела (искать себе проблемы
)
г) в организации могут понимать что фитбек вещ ценная для аналитика, но приоритеты могут быть другие, и ресурсы на решение этой проблемы могут не выделяться (как тогда аналитику решить эти проблемы для себя чтобы развиваться).
ну и можете придумать еще из своей реальности чего-то…По вопросу 1 есть следующие варианты:
1. "Само придет" — ждать, пока проблему не вскроются и аукнутся (например, при развитии ПО или при саппорте). Плохой, но всё же путь.
2. Работать над ошибками. Если они не видны самому, то используется:
а) Из неформального — спросить у менеджера/тим-лида.
б) Спросить опытных товарищей (не работавших на проекте) — опять же неформально, углябляться в детали они не будут, но могут что-нибудь подсказать.
в) Формально — аудит (внутренний или внешний). Здесь опытные товарищи (или нетоварищи) привлекаются к разбору вашей работы по косточкам. Степень углубления может быть самая разная.По вопросу 2:
Начинайте вести базу знаний. Один из способов — сделать пост-мортем проекта. То есть записать проблемы, выявить их причины, предложить пути по предотвращению в будущем. Если проблема повторяется/может повториться у нескольких людей — измените практики работы в компании и проведите обучение персонала.В любом случае без документирования "проблем нет". Держать в голове бессмысленно — либо забудутся, либо сгладятся.
По поводу дополнительных условий — такие ограничения характерны для компаний на начальных этапах развития (скажем CMMI 0-2). По мере развития компании приходит понимание и появляется необходимость в развитии системы качества, которая обязывает все эти вещи выполнять.
Если компания застревает на каком-то уровне развития, и качество её не волнует — скорее всего она либо умрет, либо будет постоянно выживать.Вопрос 3:
Да, нужно. Я не знаю универсального рецепта. Анализировать, искать слабые места, предлагать решения и убеждать-убеждать-убеждать. Применять активно ТРИЗ и навыки коммуникации
Вы должны авторизироваться для ответа в этой теме.
