Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - anton morozov

Страницы: « 1 2 3 4 »
31
ПО Аналитика / Axure практика
« : 09 Сентября 2013, 14:39:41 »
Уважаемое сообщество.

Понимаю что Axure, это не совсем ПО Аналитика. Всё же, аналитикам частенько приходится иметь дело с интерфейсами.
Предлагаю поднять темы по этому продукту и по практикам вокруг него.

Если у вас есть конкретные вопросы из разряда "как бы это сделать", то я готов попробовать ответить на них.
Сейчас все реализации смогу показывать в рамках версии 6.5, т.к. седьмая ещё полноценно недоступна.

32
Проектирование / Re: Шаблоны GUI для Visio
« : 06 Сентября 2013, 21:57:19 »
Бегло посмотрел список шаблонов не залезая в них. Веб вообще никак не раскрыт.
Нет стандартных аккордионов, каруселей, галереек и всего того что встречается в каждом первом веб проекте.

33
Проектирование / Re: Шаблоны GUI для Visio
« : 06 Сентября 2013, 21:31:28 »
Цитировать
2 Подбор нужного шаблона исходя из ответов на заданные вопросы.
Например: Проблема – Надо  защитить web – приложение от ботов. Надо убедиться что приложением взаимодействует человек.
Решение: Шаблон Captcha

Проблема сформулирована неправильно и вы влезаете в область реализации и навязываете фронтендщикам решение, хотя вы только гуи разработчик. Это рано или поздно плохо кончается.

Сейчас объясню  почему.


То, что боты ходят по сайтам - нельзя назвать проблемой для веб приложений. Некоторые боты нужны и полезны. Проблема - это когда бот гадит в форму, создает нагрузку, грабит ваш контент или парсит ваши цены и т.д. Защищать нужно только уязвимые участки от вреда, а не от ботов. Причем, вы должны не просто  указать уязвимое место, а что именно вы хотите защитить, потому что кроме капчи есть ещё и другие средства защиты. Капча  - это не панацея, и навязав разработчикам только её, вы можете создать угрозу  безопасности.
Умиляют формы, которые выкидывают капчу, но хавают элементарны Xss.

Капча имеет ещё побочный эффект, поскольку она ко всему прочему, затрудняет взаимодействие.  Если использовать её без меры, то вы сольете не только ботов,  но и пользователей.

Ещё один момент. Разработчики прочитают ваше требование как "использовать капчу". Есть капча, есть рекапча, через пол года выйдет ререкапча. Есть шанс что ваc поймут буквально и окажется вы используете устаревшее средство.

34
Проектирование / Re: Шаблоны GUI для Visio
« : 06 Сентября 2013, 20:11:44 »
Цитировать
1 паттерны взаимодействия (interaction patterns)
2 паттерны пользовательского интерфейса (user interface patterns)
3 паттерны юзабилити (usability patterns)
4 паттерны web-дизайна (web design patterns)

Вы можете привести реальный кейс, как вы это всё потом будете использовать ?

Паттерны веб дизайна - это вообще что такое  ? Я погуглил, и мои сомнение ещё больше усилились.

35
Средства для создания прототипов подбираются в зависимости то того, зачем вы его делаете.

Как по мне, так их можно делать вот зачем:

1. Уменьшить expectation gap. Использование прототипа с высокой детализацией для проб на реальных пользователях, проведения разных юзабилити тестов.
Самый тугой и классный вид прототипов одновременно. Очень их люблю.

Я не уверен что ко всем пунктам ниже вообще можно использовать термин "прототип", но тем не менее.

2. Ради проверки целостности экранов и того, как пользовательские сценарии мепятся по этим самым экранам.  Можно мепить UC и прочими сущностями. Всё зависит от того, что вы хотите проверить.

3. Прототипы ради иллюстрации разработчикам что д.б. на экранах.
4. Ради того, чтобы показать связи между экранами тоже можно использовать средства прототипирования, но можно и диаграмму диалогов, так называемую. Об этой диаграмме есть у Вигеса http://www.youtube.com/watch?v=KUuyxdFb3Pw&list=UULy9Y3p9SZB4us8UJ8Rh8BQ
 
Для каждого пункта используется свой подход и свои инструменты.

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

Из инструментов я бы рекомендовал axure. В ней можно и верхний уровень накидать быстро и сделать достаточно детальный рабочий прототип. У неё есть свои ограничения, но для большинства мне известных кейсов она подходит и проста в освоении. Как по мне - инструмент дешевый для тех, кто полноценно занимается интерфейсами, особенно со всеми возможностями новой 7й версии.

36
Опишите подробно один какой-нибудь случай из вашей практики. Слишком мало информации.

37
Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня.

У нас реализация недели по 1-3 на один реквест. Задачи на день - это скорее к починка аварий и подобное, но там надо просто починить скорее.

На счет метрик. Мы снимаем время выполнения задач в команде. Я могу сказать сколько времени ушло аналитику, кодинг на фиксы, развертывание и т.д в рамках проекта, его версии или на одну какую то задачу.

Поскольку виды деятельности привязаны к должностям и конкретному человеку, то я могу приблизительно сказать сколько стоило в деньгах. Могу сказать  сколько времени ушло на факапы аналитика(т.е. меня) или косяк в рисках,  залеты программистов на подводные камни.

Оценка ЧЧ на проблемах.  Например, когда убираешь рутину, то  пишу скринкаст по повторяющейся операции. Затем  нахожу как узнать сколько этот сотрудник таких операций выполняет в день. Наблюдаю недельку. Ищу данные как рутина изменяется в рамках сезонности ну и много чего ещё проверяю. Иногда используются всякие логеры и прочее. Там много вариантов и много случаев как чего и в каком объемах измеряется. Я не занимался особо изучением этого вопроса по книжкам. М. б. есть какие то решения, но судя потому что у нас нет внедрений, с которых я бы мог взят эти параметры автоматически, мне придется делать это ручками.

На счет цифры в 50%/ 9 мес. было бы точнее.  Положа руку на сердце, это почти отфонарно. Я не знаю в какую сторону тут думать чтобы сформулировать эту цифру. Знаю, что смогу заметить её в графике по нашей метрике.  :) НА этом мысли заканчиваются.

При таком подходе функциональность ваших решений будет неуправляемо "разбухать"

Поддержка наших же решений нас действительно давит. Чем больше пишем, тем больше поддерживаем.  Я не понимаю, что значит "разбухает".

Кстати, с увеличением размера команды этот показатель, скорее всего, снизится

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


Многие задачи вообще не высвобождают ЧЧ, при том что они объективно полезны. Например, что-то направленное на улучшение клиентского сервиса
Согласен. Мой показатель показывает картину только на определенном круге задач, а не характеризует всю моею деятельность.

Про увеличение команды:
Есть у меня теория, что поток мелких реквестов обычно интересует бизнес только на
предмет занять чем-нибудь команду между деланием Больших Проектов, исправления багов и задачек, которые реально интересует топов. Сделает команда 30 мелких реквестов или 50 бизнес волнует очень мало. Для компании в целом они ничего принципиально не меняют - высвобожденные ЧЧ будут потрачены на ещё какую-нибудь малозначимую хрень - не только вам веселее работать в большой команде. Предположу, что именно поэтому эту задачу у вас заделегировали чуть ли не на уровень ИТ. Т.е. наращивание описываемого вами KPI - это плохое обоснование для увеличения команды. Лучше это обосновывается под какой-то проект который топам заметен.

Всё верно. На что потратят освобожденные ЧЧ решают другие люди.  Надеюсь что они хорошо решают.
Я не знаю как смотрят наши топы и на какие проекты. М.б им заметно только то, что у них с бизнесом всё ок или не ок.     

Если не получится с командой тут - перейду в другое место.  Буду там получать удовольствие от работы :) Я люблю аналитику и интерфейсы. Меня вполне устроило бы место в команде где всё решено и организовано до меня и без меня, когда можно идти и работать на благо компании/проекта.

Про процесс в целом:
Обслуживание маленьких реквестов дело принципиально неблагодарное. Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня. Помножьте это на то что реквесты заводят потенциально все сотрудники организации, а делают сами знаете сколько программистов. Но т.к. человек альтруистично потратил свои 15 минут, на то чтобы сделать организацию лучше, а тупые бюрократы не оценили его порыв, то весь это процесс сопровождается плохими вибрациями. Истерики, письма президенту, разочарования итп. Ну и конечно же виноваты во всём неэффективные ИТшники, которые непонятно чем занимаются, вместо того чтобы тупо выполнить все реквесты в трекере.

Этот нехитрый расклад, рано или поздно понимают в большинстве организаций. Что, по моему опыту, с этим делается:
- Процесс создания реквеста максимально усложняется - нужно заполнить 100500 листов специальной хитрой формы, подсчитать хитрые показатели эффективности итд.
- Реквесты фильтруются путём утверждения по всей вертикали начальников подразделения, где работает заявитель.
- Реквесты фильтруются на входе в ИТ. Тут разные подходы я видел и слышал:
- Специальный комитет, который утверждает [план ближайших работ]. Чем более влиятельны его участники тем лучше. На моей прошлой работе туда даже CEO входил (компания среднего размера - ок.1000 сотрудников). Подразделения-заказчики защищают свои доработки перед Комитетом. CIO, естественно, был участником комитета.
- В большой компании, где я сейчас работаю, запросы поступают в особое бизнесовое Подразделение-Координатор, которое, среди всего прочего, курирует развитие нескольких взаимосвязанных систем. Подразделения-заказчики договариваются с менеджерами этого подразделения. Подразделение-координатор путём переговоров с ИТ, формирует скоуп следующего релиза системы.
- Слышал про систему жетонов. Подразделениям-заказчикам раздаются жетоны из каких-то общих соображений. Эти подразделения покупают на эти жетоны время ИТ-подразделения. Тут много подробностей не знаю, сам слышал только рассказы.
Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.

Слушайте, а это очень полезная для меня информация.  :)
И теперь я пожалуй немного больше стал понимать что bas имел ввиду под Хабаровском.
 

38
За годы варки в своей ситуации глаз замыливается капитально. Реакция и вопросы leha и bas - это взгляд со стороны, которого мне крайне не хватает. 
Есть ощущение, что местами мутно понимаю свою ситуацию. За время темы я пересмотрел некоторые моменты. Позволю себе последнюю порцию оффтопика в надежде на избавления от этой мутности.     

Антон,
У Вас какие-то противоричивые показания:

Противоречие действительно читается.  Оно вызвано тем, что я криво использовал термин "бизнес".  Пожалуй, больше не буду. А ещё тем, что я не уточнил дофига моментов вроде, кто для меня является бизнесом, какое мое место в организации, масштабы моей деятельности и прочее. Не важно. Важно что в итоге получится.     

Вообще тех, кто есть в моей организации   я классифицировал след образом:

1) Те,  которые распоряжаются ресурсами и рулят стратегическими решениями.  (босы или тот самый бизнес)
2) Те, которые управляют направлениями бизнеса и просят ресурсы, отвечают за их использование. (руководители)
3) Те, кто отвечает за какой-нибудь один процесс и просят дать им решение их проблем (большая часть реквестов приходит именно из этой группы) (исполнители)

Я не знаю как это называется в терминологии БА. Классификация : топ, среднее звено, высшее звено в данном контексте не прикладывается.


leha очень правильно замечает:
" У вас в организации есть большая(?) коммуникационная проблема между бизнесом и ИТ. Скорее всего по вине ИТ."

Да и эта проблема лежит отношениях между босами и руководителями. Я не знаю какие именно проблемы коммуникации там есть. 
руководители попросили меня поискать решение, которое поможет им систематизировать информацию о проблемах (сделать набор отчетов).  По их мнению это должно помочь вылечить коммуникации о выделении ресурсов.   М.б. это поможет им в работе над ошибками  и лучше понять что просить. Нет информации как именно меняется процесс коммуникации там, какие критерии успешности.     

Т.е. инструмент я ищу нашел в рамках задания от них. Попутно я использую его и для своих целей, но об этом ниже.
 
 
Далее leha пишет:
"Вы довольно радужно видите как трудозатраты на моделирование БП так и результаты этого моделирования. И верите в волшебные Инструменты :)"

и bas пишет:
"с внедрением системы качества БП"

У меня нет задачи  делать модели БП или внедрять систему их качества, и при этом ещё пользоваться волшебными инструментами. Нет ну правда, где я такое говорил ?   Я вполне четко обозначил что у меня проблемы с ранжированием.  Да, я не обозначил какой масштаб моих задач и какое мое положение внутри холдинга, и что для меня бизнес, но я и не уверен что должен был всё это расписывать.

То, что я собрал в Cradle, больше похоже на трекер  "проблема - решения".  БП в виде элемента к проблеме сбоку прицеплен ради сортировки.
Описание БП сводится к тому, что него выставляется значение категории, которая очень приблизительно обозначает значимость этого БП.
Диаграммы я использую только для случаев, когда решение проблемы в изменении БП, и я делаю "было / стало". Иногда мне нужно понять, что предлагаемое решение не идет наперекор БП и для этого составляю краткую схему. Мало времени ещё прошло, но вроде пока это то что нам нужно. 

Далее про Хабаровск

Вообще моя команда  достаточно успешно делает проекты, если смотреть  именно с точки зрения разработки.   
Мы пилим решения только посильного масштаба с понятной пропускной способностью. Если посмотреть на все проблемы бизнеса(хотя их реальный объем я не знаю), которые подлежат техническому решению, то мы в лучшем случае закрываем процентов 5-10%, а может и меньше. Понятно, что внутри этих 5-10% задачи мелкого, иногда среднего масштаба.
Непосредственно стратегические задачи босов слишком большие для нас обычно, поэтому  "манипулировать бизнесом" - это не про нас. Манипулировалка маловата да и чем там манипулировать ? Очередью на конвейере однотипных задач ?

Мы работаем с одним руководителями, который как раз рулит вопросы ранжирования. Этот человек имеет дело с проблемами внутри и между минимум 8 компаний внутри холдинга. Мне иногда кажется что это очень много для этого человека и что проблемы систематизации такого объема данных неизбежны, потому что превышают человеческие способности. Особенно когда проблемами этих 8 организаций больше особо никто не занимается.
   
Отношение именно боссов к проблемам, которые решает моя команда такое: "все эти проблемы б д решены вчера", и никакого стратегического ранжирования с их стороны не задается. Мы просто пилим всё подряд и чем быстрее, тем лучше.   

Бардак в систематизации проблем приводит к тому, что в разработку выбираются те, что удержались у нашего руководителя в голове к моменту назначения очередной порции в redmine.
В итоге мы берем проблемы из "короткого списка", а на самом деля рядом то лежали пожирнее.   
Может быть единый реестр проблем сделал  выбор на реализацию эффективнее жирнее. Я не говорю что там должны быть все проблемы(хотя со временем д.б.), но это лучше, чем ограничиваться памятью одного руководителя.   

Ещё один момент, где мы ошибаемся в ранжировании. Мы оцениваем проблемы перед ранжированием. Ошибки в оценке приводят и к ошибкам ранжирования. 
Инструмент не поможет в правильности оценки, но он позволит отслеживать где оценка проведена на должном уровне, а где ещё надо поработать.
В идеале нужно добиться чтобы в ранжировании не участвовали проблемы с мутной оценкой.

Я запихнул в Cradle уже часть данных и видно, что  моя фраза "Я связываю это с тем, что мы изучаем БП, не в том масштабе, в котором нужно." не верна как бы я не трактовал слово "масштаб". Дело скорее именно в фиговой работе с оценками проблем/решений. Да значение БП для бизнеса играет роль, но не может быть решающим фактором.

Ещё риски можно к решениям привязать и по тяжести ситуации с ними ранжировать :)

Вообще успешность этого мероприятия я вижу след образом:

1)  У нас есть средний показатель высвобожденных (человеко-часов / рублей/мес) за единицу времени работы команды. Задача минимум за счет более четкого ранжирования увеличить этот показатель на 50%.

2) Задача максимум - выбить ресурсов увеличить команду в 2 раза, чтобы работать было поинтереснее :)

Вообще очень много буков. Прошу простить, но мне стало интересно


И про вот этот кейс:

"Прикольный кейс получился, как раз для Аналитика:
Заказчик - хочу внедрить систему класса Х, посоветуйте мне какую.
Аналитик - а нет, давайте про цели сначала поговорим"

Если под "внедрить систему класса Х" понимается вопрос " посоветуйте что имплементить ?" Если да, то я спрошу про цели и область проблем, потому что как иначе я пойму что советовать ?  Нет, м. б. если бы у меня был менталитет аутсорсера, я бы наверное задумывался в сторону "что же мне такое посоветовать чтобы попроще продать внедрение".


39
1. В оценке тех спец должен участвовать обязательно
2. Отрезать реквесты, кот превышают определенные трудозатраты: ну не может курица отложить страусиные яйца
3. Приоритет реквеста = К*Приоритет_Бизнеса/Трудозатраты
4. Требовать критерии у каждой задачи, которые должны быть достигнуты по факту внедрения, не достигнуты - по башке/снижение приоритета других реквестов и т.д.
5. Договариваться с бизнесом о выделении определенного времени на задачу в зависимости от трудозатрат, не соблюдают ...
6. Нужен чел, кот будет разрешать конфликты в приоритетах между разными нач отделами
7. Задачи/проекты больше определенных трудозатрат отдавать на аутсорс.
См. п. 4 выше
Поставить процесс работы с реквестом жестко и соблюдать для всех реквестов, исключение - реквесты от совсем топа.

Сами Вы этот процесс не поставите, нужно привлекать каких-то топов, да хотя бы ИТ директора.

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


40
Антон, описанная вами проблема  хорошо знакома.
Смущает, что вы ищете решение именно в описании БП, не важно даже в каком инструменте.
Мне кажется, никакое описание БП не поможет правильно ранжировать хотелки бизнеса.

Вот скажите:
- Кто принимает решение, что вы ранжировали хотелки правильно? Вы сами? Владелец бизнеса? Аудиторы\консалтеры? Начальники отделов?
- Как вы видите описанные вами ситуации, после того как вы правильно описали БП в правильном инструменте? Начальник отдела приходит с хотелкой, а вы нажали кнопочку и говорите, эээ дружище чего-же ты меня с ROI то хочешь обмануть - приоритет 110 твоему проекту никак не больше. Или даже так, приходит к вам владелец бизнеса и говорит Антон, вот тут начальник транспортного цеха проект предлагает, что думаешь про ROI?
- Как вы думаете, ситуация, когда CIO принимает за бизнес решения чему развиваться, а у чего по хитрому описанию БП нет перспективы, она долго продлится? Думаю полгодика покряхтят все, а потом чего-нибудь и сделают с "оборзевшим" CIO. Благо повод будет - ИТ-отдел совсем перестал развивать собственно ИТ, а половину времени схему БП перерисовывает :)

Про описания БП

Я уже писал выше - описания БП сами по себе мне не помогут  решить проблемы ранжирования. Из моего описания даже понятно какое именно место я уделяю непосредственно описанию БП и кажется даже привожу примеры.

И далее по теме, откуда вы взяли что я делаю ставку на  "правильно описали БП в правильном инструменте"  ? Я не знаю что такое "правильный инструмент и правильное описание БП". 
 
Про хотелки

Я бы не стал употреблять слово "хотелки". Большинство реквестов  - это проблемы, которые уже нанесли ущерб в рубликах и от которых надо закрыться. Я бы даже сказал, что от них закрываться надо было "ещё вчера". С другой стороны нельзя отрицать существование именно "хотелок", обусловленных какой то подноготной у ЗЛ. Ни я первый это описываю в общем то.   

Про решения

Я писал что "меня оставили и разрешили участвовать в ранжировании". Откуда вы сделали вывод что я принимаю решение единолично  и что-то диктую бизнесу?
Конечное решение принимает бизнес. Мое участие сводится к вспомогательным информационным и аналитическим функциям. Просто есть некие механизмы, которые позволяют не брать в разработку реквест, которые имеют большой шанса фейла или реквесты, которые не по зубам, или мутные реквесты.     
 
Абсолютно правильное ранжирование  - а такое вообще может быть ? Если знаете как - расскажите.

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

В общем, вы верно описываете крайность, когда CIO решает слишком много сам, но вы видели крупный бизнес, где это допускается ?. Я такое видел в мелких конторах и это неприятное зрелище.

С другой стороны. Я видел много печальных историй, когда бизнес принимает "стратегические решения", но без должной компетенции с его стороны это превращается в бестолковый бесконтрольный слив бюджетов. Притом достаточно больших.

Я думаю, что есть золотая середина в вопросе кто и в какой степени участвует в процессе ранжирования, но я уверен что он не может быть отдан полностью на откуп одной из сторон.
 

41
Да - интересно, Антон. Тем более я сам хотел сделать нечто подобное но на более абстрактном уровне. Готов чем-то помочь.

Давайте начнем .
Скидывайте что вы конкретно хотели реализовать. Что есть "нечто подобное".

42
Кстати.

Я погорячился на счет цены Cradle. Там всё приемлемо.

Удалось собрать все необходимые структуры данных для анализа на этом продукте и пока я решаю вопрос с покупкой.

Понятно, что мне понадобится пару месяцев чтобы всё обкатать и понять как это вообще всё работает.

Тут есть  вопрос к сообществу:

Я обещал сделать сравнение реализации в Cradle и EA своей задачи. Это действительно кому-нибудь интересно  ?
   

43
Что-то мне кажется, что Автор хочет быть умнее бизнеса, а это, как минимум, опасно, как максимум, очень и очень долго, а главное скорее всего не даст ожидаемого эффекта.

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

Может вы и правы.  Я приблизительно так пробовал, как вы описали, но у меня не вышло построить это так, чтобы работало.  Может вы поможете мне разобраться. Ниже пойдет немного истории.

Была приблизительно след. картина, когда ранжирование и прочие решения были полностью на стороне бизнеса:

Ситуация 1.
Много реквестов  не по зубам моей маленькой команде.  Зарефьюзить крайне сложно, потому что "так босс сказал" и местами проще было уволиться. Не рефьюзить я пробовал - провалил проекты, потерял команду, потом долго и болезненно её пересобирал.

Бизнес упорно не хочет понимать, что для больших реквестов нужно больше ресурсов.
Вот вы отдали ранжирование на откуп бизнесу. Он выделил "приоритетные" реквесты для себя, но при этом не готов выделять ресурсы на "самые важные для себя решения" 
Вам не кажется это странным ?

После всех фейлов, изменить систему ранжирования мне удалось  ультиматумом вида "можете продолжать ранжировать и распоряжаться ресурсами как раньше, но без меня и моей команды, либо мы изменим систему ранжирования."

Тогда бизнес предпочел поступиться своими принципами и меня оставили и разрешили участвовать в ранжировании.
После этих изменений у меня стали получаться проекты, эффект от которых бизнес чувствовал и признавал это. 

Ситуация 2.
Были реквесты, которые на самом деле оказывались амбициозными хотелками ЗЛ "хочу эту штуку как у конекурентов и это важно, потому что ...". Я имел несчастье поддаться разок и на это.  Испытал сильную боль от выброшенных месяцев работы над фигней, которой так и не суждено заработать, потому что она никому на самом деле не нужна. Но это было в самом начале.


Ситуация 3
Есть реквест который, казалось, бы вполне обоснован.  Ты реализуешь, вешаешь метрики после реализации, а метирики показывают, что решение не играет особой роли. Заранее это понять сложно, а иногда это даже не хочется делать потому что реквест "такой очевидный и такой жирный".

Ваша схема работает на бизнесе, который имеет высокую корпоративную аналитическую культуру. Когда каждый руководитель почитал хоть какой-нибудь pmbok и своей попой отвечает за растрату ресурсов команды разработчиков +  понимает что нельзя требовать "написать любую программу", просто потому что в штате оплачивается пара программистов.

Если этого нет, и если вы относитесь к своей работе как перфекционист, то не анализируя реквесты самостоятельно,  вы рискуете получить много много много боли. Я в свое время получил.

Я верю что "другой" бизнес справился бы с задачей ранжирования своих же потребностей лучше, но это пока не мой случай.

Я не хочу быть "умнее бизнеса". Неужели вы думаете, что бизнес бы просто так позволил за него думать какому то начальнику отдела разработчиков ?   Бизнес сейчас дозрел чтобы внедрить систему анализа и ранжирования. Поскольку на мне лежат решения технического характера, то я буду одним из основных пользователей системы. Я эту систему построить давно чаял.  Кроме меня есть ещё люди, которые отвечают за реинжиниринг процессов.  Им это тоже нужно.


44
Антон, я думаю многим участникам поднятой Вами дискуссии было бы интересно узнать, чем именно не устраивает EA. Конкретизируйте, пожалуйста,  что значит "EA немного тяжеловат". Это позволит всем сэкономить время.


Я не вижу дискуссии тут никакой.
Я могу собрать в ЕА и других средствах и выложить. Можем хоть сравнение устроить. Нужно только время.

Другое дело, что в бизнес анализе я совсем не шарю, поэтому моя реализация может быть далека от "правильных" или "рекомендованных практик", а может даже содержать какие-нибудь антипаттерны. Я сейчас всё собираю по наитию. Про книжки я тоже не просто так спрашивал.



Я думаю тяжелость ЕА почувствуется только когда я в него запихну процессы для всех моих 8 организаций :(

На самом деле, тяжел ли ЕА для моей задачи можно будет сказать только когда я её выполю )

45
Антон, а на EA у Вас приобретены лицензии?

Да, причем для работы и для домашнего использования.

Страницы: « 1 2 3 4 »