Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Я открыл PMBOOK (ANSI/PMI 99-001-2004)Сколько же можно. Где вы вообще это слово гадкое берёте — BOOK?
Если бы была задача -описать и успакоиться,да,отдел было бы нецелесообразно создаватьКаких технологий, например? Почему открытие новых проектов приводит к изменениям БП?
Но тут будут постоянные изменения(я уже обдумываю про регламент изменения текуших БП),внедрения каких-либо новых технологий,открытие новых проектов.
У нас это актуально-отделов много,информационные потоки тоже немалые,и зачастую люди желая сделать хорошо в одном краю компании забывают о другом.Так всё-таки вы должны только процессы организации развития ПК и отчётной системы описывать, или всей компании?
Думаю то,что многие руководители не совсем понимают что подразумевается под должностью бизнес-аналитика,вам известно лучше меня.Бизнес-аналитик — это функция менеджера, делегированная в отдельную роль/должность.
небольшой IT-отдел вывозит сфот,разрабатываемый сторонней организацией,но очень тесно свазянной с нашей.поясните плз содержание ключевого процесса — что такое «вывозит софт?»
В организации началась реструктуризация отделов вследствии слияния нескольких компанийА каковы объёмы этих отделов? Что-то я сомневаюсь, что вообще в ваших условиях целесообразно выделять отдел «реинжиниринга БП».
В новой структуре наконец-то разделили и IT-отдел,появились новые:
-разработки
-тестирования
-внедрения
и отдел реинжиниринга БП.
Данные отдел было предложено отдать под мое руководство.Уже не первое обращение с подобным вопросом за последнее время.
И начать естественно со структуры, функционала, разработки критериев
оценки деятельности каждого сотрудника и отдела в целом.
Общаясь в высшим руковдоством я поняла, что для них результат работы отдела
-это итоговая инструкция, руководство, реализованное ТЗ.
Я опять столкнулась,что БА путают с Тех.писом.
Да,в данном отделе тех.пис подразумевался изначально.
На мой взгляд- это лишь малая толика выхода данного отдела.Главная задача- выработка решений,оптимизирующий работу компании,итоговый БП,а сопровождающая документация (технологии,инструкции,руководства)- работа тех.писа. может я заблуждаюсь?Ну в идеальном мире может быть есть:
У меня возникли следующие вопросы:Верно или неверно, определяется ценностями, доминирующими в компании.
Верно ли я вижу результат работы отдела реинжиниринга?
Каким образом определить количество необходимых сотрудников?На каждую сотню человек производства вам может понадобиться 1 (ОДИН) описыватель процессов.
(видимо тут необходимо оценить объем обрабатываемой информации,частоту изменений системы)?
Ага, а еще там написано что мне 21 год.
А на заборе *** написано. А там дрова
— Девушка, а девушка. Как вас зовут?
— Таня!
— А меня Федя.
— Ну и ****!
Если Вы хотите удостовериться, что я думаю именно так, посмотрите http://lnew.ucoz.ru, Моделирование заинтересованных лиц в TOGAF.Я тоже похвастаюсь непониманием, как работает конкретный движок сайта.
А вот, как вставить файл картинки в сообщение, я так и не узнал. Может, этого вообще нельзя сделать?Под формой комментария:
Бедный Alexeyzf!Действительно! Откуда?!
Но откуда мы знаем, что он аналитик или собирается им стать?
И кто сказал, что он не выполнил анализ требований (в своей голове)?И кто же этот малый?
Мало того! Откуда такая уверенность, что рисовать диаграммы нужно после анализа?Действительно, откуда?
Каждый работает по-своему. Я, например, анализирую, когда рисую, и считаю анализ успешным, когда мне удается внятно отобразить свои мысли (информацию об объекте) в модели.Мне кажется, вы путаете режим обучения и режим производства. В режиме производства можно и нужно выбирать эффективные для себя методы. В режиме обучения нужно осваивать лучшие практики, чтобы потом уже из них отбирать нужное.
Кто-то использует диаграммы только для иллюстрирования.
Все правы, если добиваются успеха.
Вот, великий Коберн вообще на UML плюется, и нам повезло: иначе мы не читали бы его замечательную книгу. Я по этой книжке многому научился. Но, тем не менее, без UML так описывать прецеденты не смог бы.Не понял тезиса. Вы против того, что потребности и ожидания ЗЛ первичны, а модели внешних продуктов системы — вторичны?
А если Вы посмотрите мои спецификации, они очень похожи на "эффективные юзкейсы", хотя получены генерацией из модели.Мастер может начать строить ракету хоть с туалета.
Alexeyzf ничего не спрашивал про анализ требований. Он хочеn писать код и учит UML.А я придерживаюсь другой школы. Что не надо идти на поводу у больного и давать ему ту таблетку, которую он просит, а надо находить источник боли и устранять его.
Так давайте следовать опыту Золотой рыбки!
Прошу побольше критики и советов! Очень помогут. Системка маленькая, но думаю для начального этапа достаточно.Проектированию систем предшествует анализ требований.
Простите, картинку вставить не научился.
Никак не получается.
Если хотите посмотреть, пожалуйста, расскажите, как Вы свою вставляли.
Или могу выслать по почте.
