556

Обучение / Re: Совместная разработка лекционных курсов

« : 06 Августа 2009, 20:16:44 »

ыстчо раз повторю "неважно для какой области разрабатываются ИС, т.к. они должны разрабатываться по некоторым единым правилам", поэтому упоминание отраслей просто бессмысленно.
Проблема в том, что ГОС идет от вуза вверх, а Рособр в этом НИФИГА не понимает. Вот и плодится полная чухня! Хотя бывают и исключения.

557

Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?

« : 06 Августа 2009, 20:13:27 »

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

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

пункт три я бы дополнил требованиями, которые помогают устранить имеющиеся проблемы, связанные как с предметной областью в принципе, так и с ее реализацией в старых системах

пункт четыре дополню планом реализации и ввода в эксплуатацию новой системы плюс план постепенного прекращения существования старой системы по мере ввода новой в эксплуатацию.

а вообще-то постановка вопроса непонятна? вас интересует как должен выглядеть этот документ с требованиям, чтоли?

558

Конференции Семинары и Тренинги / Re: Мастер класс Управление производством на основании численных

« : 06 Августа 2009, 14:15:39 »

численных чего?

559

Обучение / Re: Совместная разработка лекционных курсов

« : 06 Августа 2009, 14:10:58 »

Выдержка из ГОС:

вот же ужас! если госстандарт так написан, то что будет на выходе???
я как-то видел ГОСы по медицинским специальностям, так там такой перечень знаний, умений и навыков, что закачаешься. Эх, если бы у ИТ-ишников хотя бы половина от этого по объему была написана (мечтат.)
правда это не отменяет того факта, что в большинстве своем медики наши, мягко скажем, лучше бы не медициной занимались, а чем-то другим. хотя, конечно, есть и очень-очень хорошие исключения.

560

Обучение / Re: Совместная разработка лекционных курсов

« : 05 Августа 2009, 19:44:37 »

Не соглашусь. Вузы не учат работать. Если, конечно, не считать всякие дисциплинарные и балловые штрафы за опоздания, не вовремя сделанные задания и т.п. Работать должны учить уже сами предприятия.

В свою очередь не соглашусь.
Во-первых, штрафы и задания - это не работа, а дисциплина. Она везде нужна: и в учебе, и в работе.
А во-вторых, вузы, по-моему, должны учить операциям, в идеале отдельным функциям. Чтобы потом молодой специалист мог придти в любое место и сказать, какие рабочие операции он может выполнять. А действующая на предприятии технология работы должна быть совместима с такими операциями (или наоборот). Это позволит выпускникам в принципе встроиться в технологический процесс (конечно, они и так со временем встроятся, но затраты при этом будет совсем другие). Тут конечно есть над чем работать.
Насколько мне известно, что-то подобное происходит с инженерными специальностями в области проектирования. Сейчас "все" выпускники "умеют" проектировать с помощью AutoCAD и каких-то других CAD-систем. Для этого производители этих систем вкачивают в вузы большие деньги, в том числе предоставляя льготные версии своих продуктов. У них, правда, цель другая, но тем не менее это происходит в довольно больших масштабах.
И, наконец, в-третьих, нужно учить (или хотя бы давать обзор) разным технологиям, чтобы у выпусников была эрудиция в выбранной области. чтобы он мог не только по RUP работать, но и по другим подходам. Вот это самая больная тема, по-моему, т.к. хорошо знать именно разные технологии довольно сложно. Не говоря уже о том, чтобы уметь обоснованно их выбрать и внедрять (хотя, думаю, от вчерашних студентов этого и не потребуется, если они свой бизнес не начнут).

561

Работа / Re: Технический писатель

« : 05 Августа 2009, 18:11:21 »

впрочем, большинство компаний численностью до 30 человек умудряются передавать техпису не только обязанности по анализу требований, но и тестирование, и внедрение

а также всё, что имеет отношение к терминам "документация" и "документирование"

562

Вакансии / Re: Вакансия Ведущий Системный Аналитик_ Москва_ до 100 000 р.

« : 05 Августа 2009, 18:10:11 »

нее, можно идти, там научат, обучение ведь есть.

563

Обучение / Re: Совместная разработка лекционных курсов

« : 05 Августа 2009, 18:08:16 »

сейчас мне нужно разработать курс Проектирование ИС для специальности ИСИТ.

What is it Ваш ИСИТ?
IMHO проектирование систем - это проектирование систем, и проектировать их надо независимо от какой-то там специальности. другое дело, что базовый набор знаний у разных специальностей может отличаться и в таких случаях надо будет восполнять пробелы.

564

Работа / Re: Технический писатель

« : 05 Августа 2009, 17:58:13 »

IMHO нет.
Техпис должен описывать технические/программные системы, например, их поведение, пользовательскую документацию писать и т.п.  Хотя возможны варианты

565

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 29 Июля 2009, 19:37:58 »

Подозреваю, что мы говорим о разных вещах относительно западных методов и отечественной специфики.

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

566

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 29 Июля 2009, 19:36:29 »

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

567

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 29 Июля 2009, 19:26:24 »

А знаете, к сожалению, действительно бывают ситуации, когда лучше не брать на себя ответственность. (Я искренне завидую тем, кому не доводилось с ними сталкиваться!) И дело даже не в том, что лень, а в том, что тем, кто такую ситуацию создал, им-то хорошо, они так и так сухими из воды выйдут, а вот отвечать-то тебе придется... Реальный пример: у софтверной организации 2 активных проекта, по одному имеется четкий план, согласованный с заказчиком, по второму - лишь смутное представление о том, что вот эти вещи по-любому должны быть сделаны. Куратором второго проекта является начальник подразделения анализа, куратором первого - ведущий аналитик. В итоге начальник, будучии извещенным о наличии согласованного с заказчиком плана по 1-ому проекту и предупрежденный куратором этого проекта, перебрасывает запланированных на него людей на 2-ой проект... В итоге: летят сроки по 1-ому проекту, из-за отсутствия четкого плана срывается также и 2-ой проект, но вся ответственность за проблемы  1-ого проекта перекладывается этим же самым начальником на куратора, который находится в его подчинении и в общем-то и сделать-то ничего не может... Вот так вот

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

568

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 29 Июля 2009, 19:21:57 »

Дело не в "перечитать все книжки", а в том, что если какая-то вновь написанная книжка будет в сотый раз (пардон) пережёвывать темы, обмусоленные в предыдущих книжках (из-за того, что автор не удосужился ознакомиться с ними или поработать тщательнее над проблемой), ее просто никто не купит, тем более что сейчас о содержании (не об оглавлении) книги можно узнать до покупки.

По поводу неизменения ситуации у меня есть своё личное мнение. Заключается оно в отсутствии критической массы, знакомой (хотя бы просто знакомой) с литературой. ЛюдЯм кажется, что проще и дешевле будет сначала самому попробовать наступить на грабли. Но как говорит один мой знакомый: Опыт хорошая школа, но только дураки не учатся ни в какой другой.

Конечно же очередное упоминание о роли человеческого фактора лишним не будет (что мы и имеем в рамках этого обсуждения). Так что, наверное, да, нужно и кричать тоже. Вопрос: о чём? От прописных истин люди быстро устают, всем обычно нужны конкретные советы, но советы без соответствующего контекста тоже бессмысленны.

В отношении применимости западного опыта в нашей российской практике от себя могу сказать, что он вполне работает. Никакой особой специфики, "свойственной именно отечественным предприятиям", просто нет - это выдумки.
  

569

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 29 Июля 2009, 15:00:27 »

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

Думаю, что это не PMBOK'у не хватает техники (его-то как раз практики пишут, см. список авторов), а его имплементаторам. Сами же пишете про умелые руки. Так что руки (да и голову) пока никто не отменял, собственно, это ключевой тезис в разговорах о человеческом факторе. Как пишут в книжках "Хорошее программное обеспечение создается людьми. Так же как и плохое. "

Или может быть книгу?...
Хорошо будет продаваться...

не факт, к сожалению. хотя хороших книг у нас катастрофически мало.

По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния

Почему только форума? Непонятно желание ограничить себя в каком-то мирке, пусть довольно амбициозном, но тем не менее узком.
Между прочим, всё уже придумано до нас. Про влияние человеческого фактора (который, кстати, может иметь не только отрицательное влияние, но и положительное) написано несколько довольно известных даже у нас книг, навскидку приходят на ум: Peopleware Демарко и Листера, книга с подобным названием (The Peopleware Papers) Ларри Константина.
Если есть, что сказать нового - было бы очень полезно иметь такую книжку. Впрочем, для самовыражения и сам факт неплох.

По классификации рисков посмотрите Рассела Арчибальда, правда у него приведены риски, связанные не только с человеческим фактором.
Да и с примерами придётся непросто.

570

Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...

« : 28 Июля 2009, 14:11:15 »

Пока не научились полностью автоматизировать внедрение проекта. Но полностью в хаос превращать нельзя. Поэтому придумали всякие шкалы CMM для того, чтобы с Initial перейти в Repeatable, из него в Defined и всякий раз есть что развивать. Также были придуманы всякие PMBoK, PRINCE2 и т.д.

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

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

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